On Mon, 2017-06-19 at 16:40 +0300, Leonard Crestez wrote: > On imx6sx accessing the ocotp memory area directly is wrong because the > ocotp clock needs to be enabled first. Fix this by reinterpreting the > fsl,tempmon-data phandle as a reference to a nvmem_device and doing all > the read through that. > > This clock requirement does not apply to older imx6qdl chips because > there the ocotp access clock (clk_ipg_s) is always enabled. > > This is visible by comparing the "System Clocks, Gating, and Override" > tables (OCOTP rows) in the 6DQ and 6SX manuals: > http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6SXRM.pdf > http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf > > This happens to work right now without this patch because the ocotp > clock might be enabled for some other reason. In particular it might be > enabled from the bootloader and it only gets disabled late during boot > in clk_disable_unused, after imx-thermal has completed probing. > > If imx-thermal is compiled as a module then the system can hang on > probe. > > This makes IMX_THERMAL depend on NVMEM_IMX_OCOTP but that driver seems > be already available for all chips that contain tempmon so it's > acceptable. > > Reported-by: Lothar Waßmann <LW@xxxxxxxxxxxxxxxxxxx> > Signed-off-by: Leonard Crestez <leonard.crestez@xxxxxxx> > > --- > > This was reported as a comment to a patch adding tempmon support for > imx6ul (which is very similar to imx6sx). Since it already affects a > supported chip this patch is sent as a separate bugfix. > > Link: https://lkml.org/lkml/2017/6/9/578 > > There are various other ways to fix this problem. The main advantage of > this solution is that it does not add a new binding but rather preserves > compatibility with old DTBs. It also aligns with the idea that > devicetree describes hardware relationships rather than a specific linux > implementation. > > An alternative would have been to add a nvmem-cells binding to imx-thermal and > use that if available instead of fsl,tempmon-data. It might not be good to > sidestep the official nvmem bindings, the devicetree people were added so that > they have an opportunity to object. > > In theory the "thermal grade" is a two-bit quantity and might be a > candidate for using a cell with a "bits" binding. However this causes > the nvmem core to issue reads of length and alignment less than 4 to the > imx-ocotp driver so additional fixes might be required. > It's been two weeks without a reply, any advice on how to proceed? Since the original message is quite long I will summarize the main question: Is it OK to reinterpret the fsl,tempmon-data property as a nvmem reference instead of a "raw" syscon regmap? -- Regards, Leonard -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
