search for: nvkm_falcon_get

...ret; + /* did you try turning it off and on again? Apparently we need this + * on pascal, otherwise secboot will just fail. + */ + nvkm_mask(device, 0x200, 0x1000, 0x0000); + nvkm_mask(device, 0x200, 0x1000, 0x1000); + nvkm_pmu_pgob(gr->base.engine.subdev.device->pmu, false); ret = nvkm_falcon_get(gr->fecs, subdev); -- 2.14.3

...afe, but I kind of hoped somebody with more knowledge about these kind of things would respond and tells us this has to be done or maybe not. > > Greetings, > > Tobias > > > >> nvkm_pmu_pgob(gr->base.engine.subdev.device->pmu, false); >> ret = nvkm_falcon_get(gr->fecs, subdev);

..., using the existing nvkm_falcon structure as a basis. Note that this currently makes struct nvkm_falcon used for two different purposes: this fact is acknowledged, and temporary. It just makes it easier to review this first step. Using the library, falcons are now acquired by a given subdev using nvkm_falcon_get(), and released with nvkm_falcon_put(). This allows different engines to share a falcon (as devinit, secboot and pmu will need to do), but forces us to think about falcon ownership and handling them to the next engine properly. A falcon's features are detected using its version and secure regi...

...gt; + nvkm_mask(device, 0x200, 0x1000, 0x1000); > + It is needed with pascal, but does it harm other generations calling this init? Maybe guard it against exectution on maxwell Greetings, Tobias > nvkm_pmu_pgob(gr->base.engine.subdev.device->pmu, false); > > ret = nvkm_falcon_get(gr->fecs, subdev);

..., using the existing nvkm_falcon structure as a basis. Note that this currently makes struct nvkm_falcon used for two different purposes: this fact is acknowledged, and temporary. It just makes it easier to review this first step. Using the library, falcons are now acquired by a given subdev using nvkm_falcon_get(), and released with nvkm_falcon_put(). This allows different engines to share a falcon (as devinit, secboot and pmu will need to do), but forces us to think about falcon ownership and handling them to the next engine properly. Right now the most obvious ownership issue is between secboot and pmu....

...(*wait_for_halt)(struct nvkm_falcon *, u32); + void (*set_start_addr)(struct nvkm_falcon *, u32 start_addr); + void (*start)(struct nvkm_falcon *); + int (*enable)(struct nvkm_falcon *falcon); + void (*disable)(struct nvkm_falcon *falcon); + struct nvkm_sclass sclass[]; }; + +struct nvkm_falcon *nvkm_falcon_get(const struct nvkm_subdev *, + enum nvkm_falconidx); +void nvkm_falcon_put(struct nvkm_falcon *falcon); + +static inline u32 +nvkm_falcon_rd32(struct nvkm_falcon *falcon, u32 addr) +{ + return nvkm_rd32(falcon->subdev->device, falcon->addr + addr); +} + +static inline void +nvkm_falc...

Sending things in a smaller chunks since it makes their reviewing easier. This part part 2/3 of the secboot refactoring/PMU command support patch series. Part 1 was the new falcon library which should be merged soon now. This series is mainly a refactoring/sanitization of the existing secure boot code. It does not add new features (part 3 will). Secure boot handling is now separated by NVIDIA