| Message ID | 20190503165342.30139-1-pure.logic@nexus-software.ie (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add i.MX8MM OCOTP support | expand |
On Fri, May 03, 2019 at 05:53:37PM +0100, Bryan O'Donoghue wrote: > V6 RESEND: > - Adding Greg to sender list. Greg looks like you are the right person to > apply this. $ ./scripts/get_maintainer.pl --file drivers/nvmem/imx-ocotp.c Srinivas Kandagatla <srinivas.kandagatla@linaro.org> (maintainer:NVMEM FRAMEWORK) Shawn Guo <shawnguo@kernel.org> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) Sascha Hauer <s.hauer@pengutronix.de> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) Pengutronix Kernel Team <kernel@pengutronix.de> (reviewer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) Fabio Estevam <festevam@gmail.com> (reviewer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) NXP Linux Team <linux-imx@nxp.com> (reviewer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) linux-arm-kernel@lists.infradead.org (moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) linux-kernel@vger.kernel.org (open list) Why me???
On 04/05/2019 09:39, Greg KH wrote: > On Fri, May 03, 2019 at 05:53:37PM +0100, Bryan O'Donoghue wrote: >> V6 RESEND: >> - Adding Greg to sender list. Greg looks like you are the right person to >> apply this. > > $ ./scripts/get_maintainer.pl --file drivers/nvmem/imx-ocotp.c > Srinivas Kandagatla <srinivas.kandagatla@linaro.org> (maintainer:NVMEM FRAMEWORK) > Shawn Guo <shawnguo@kernel.org> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > Sascha Hauer <s.hauer@pengutronix.de> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > Pengutronix Kernel Team <kernel@pengutronix.de> (reviewer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > Fabio Estevam <festevam@gmail.com> (reviewer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > NXP Linux Team <linux-imx@nxp.com> (reviewer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > linux-arm-kernel@lists.infradead.org (moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > linux-kernel@vger.kernel.org (open list) > > > Why me??? > Looked like you were doing the merges to me. commit 38e7b6efe997c4eb9a5a809dc2b2fe6c759b7c4b Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Ping, Srini, any chance you can merge this to your tree ? --- bod
On Sat, May 04, 2019 at 03:49:05PM +0100, Bryan O'Donoghue wrote: > On 04/05/2019 09:39, Greg KH wrote: > > On Fri, May 03, 2019 at 05:53:37PM +0100, Bryan O'Donoghue wrote: > > > V6 RESEND: > > > - Adding Greg to sender list. Greg looks like you are the right person to > > > apply this. > > > > $ ./scripts/get_maintainer.pl --file drivers/nvmem/imx-ocotp.c > > Srinivas Kandagatla <srinivas.kandagatla@linaro.org> (maintainer:NVMEM FRAMEWORK) > > Shawn Guo <shawnguo@kernel.org> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > > Sascha Hauer <s.hauer@pengutronix.de> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > > Pengutronix Kernel Team <kernel@pengutronix.de> (reviewer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > > Fabio Estevam <festevam@gmail.com> (reviewer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > > NXP Linux Team <linux-imx@nxp.com> (reviewer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > > linux-arm-kernel@lists.infradead.org (moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) > > linux-kernel@vger.kernel.org (open list) > > > > > > Why me??? > > > > Looked like you were doing the merges to me. I might do merges, but that does not mean I do the initial review/acceptance of the patches. That's up to the real maintainer of the driver/subsystem. I do not circumvent them unless something really odd happens. thanks, greg k-h
On 04/05/2019 15:49, Bryan O'Donoghue wrote: > On 04/05/2019 09:39, Greg KH wrote: >> On Fri, May 03, 2019 at 05:53:37PM +0100, Bryan O'Donoghue wrote: >>> V6 RESEND: >>> - Adding Greg to sender list. Greg looks like you are the right >>> person to >>> apply this. >> >> $ ./scripts/get_maintainer.pl --file drivers/nvmem/imx-ocotp.c >> Srinivas Kandagatla <srinivas.kandagatla@linaro.org> (maintainer:NVMEM >> FRAMEWORK) >> Shawn Guo <shawnguo@kernel.org> (maintainer:ARM/FREESCALE IMX / MXC >> ARM ARCHITECTURE) >> Sascha Hauer <s.hauer@pengutronix.de> (maintainer:ARM/FREESCALE IMX / >> MXC ARM ARCHITECTURE) >> Pengutronix Kernel Team <kernel@pengutronix.de> >> (reviewer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE) >> Fabio Estevam <festevam@gmail.com> (reviewer:ARM/FREESCALE IMX / MXC >> ARM ARCHITECTURE) >> NXP Linux Team <linux-imx@nxp.com> (reviewer:ARM/FREESCALE IMX / MXC >> ARM ARCHITECTURE) >> linux-arm-kernel@lists.infradead.org (moderated list:ARM/FREESCALE IMX >> / MXC ARM ARCHITECTURE) >> linux-kernel@vger.kernel.org (open list) >> >> >> Why me??? >> > > Looked like you were doing the merges to me. > > commit 38e7b6efe997c4eb9a5a809dc2b2fe6c759b7c4b > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Ping, Srini, any chance you can merge this to your tree ? Thankyou for your patience. Normally I don't take patches that are sent after rc5 into next merge window. Unless there is an urgent fix. In this case I will be applying these series to nvmem next branch once rc1 is released for 5.3 merge window. Also any device tree bindings changes need to Reviewed by DT maintainer before I pick up these patches. --srini > > --- > bod
On 04/05/2019 18:10, Srinivas Kandagatla wrote: > Normally I don't take patches that are sent after rc5 into next merge > window. Unless there is an urgent fix. In this case I will be applying > these series to nvmem next branch once rc1 is released for 5.3 merge > window. Great, that'll done fine Srini no rush. I sometimes do a round of pings of outstanding patches I have to make sure they don't get lost in the ether. So long as its on your radar that's good enough. --- bod
V6 RESEND: - Adding Greg to sender list. Greg looks like you are the right person to apply this. - Adding devel@driverdev.osuosl.org to sender list - History: https://www.spinics.net/lists/arm-kernel/msg723454.html https://www.spinics.net/lists/arm-kernel/msg723321.html https://www.spinics.net/lists/arm-kernel/msg722655.html https://www.spinics.net/lists/arm-kernel/msg722449.html https://www.spinics.net/lists/arm-kernel/msg722441.html https://www.spinics.net/lists/arm-kernel/msg722350.html V6: - Drop BV_ prefix from u-boot timing defines - Add RB Leonard V5: - Adopt u-boot method of calculating timings. On the basis that the OTP registers have a programming time that is not related to the ipg_clk rate specify the various timing inputs to the RELAX, STROBE_READ and STROBE_PROG as-is done in u-boot. The wait time to burn a given OTP fuse is not documented anywhere except in code in u-boot. The ipg_clk then is used to clock the registers in the OCOTP block and to tell the OCOTP block how long to wait for programming to complete and how long to delay before doing an automatic re-read of the registers. Tested on the i.MX8MM-EVK relax = 1 strobe_read 6 strobe_prog 670 V4: - Change the RELAX fix to drop subtraction of -1 for all users - Leonard - Expand register definition from the 60 documented OTP registers to the entire 256 registers putatively in the address space* - Add Reviewed-by as indicated - Leonard - Added Suggested-by where it made sense - Bryan * Dumping the expanded address space shows that there are indeed OTP values present that can be read back from registers that are not formally documented for i.MX8MM eg. Bank 20 0x55000801 0x00014d14 0xd503201f 0x55000801 Bank 21 0x00014d20 0xd503201f 0x00000000 0x00000000 V3: - Fix commit log for the expanding the ADDR field i.MX6 uses seven not four bits, which is why the existing define says 0x7F not 0x0F - bod V2: - Rebased to linux-next/master to align with i.8MQ work - Two patches dropped as a result of rebase - Added patch to expand OCOTP_CTRL_ADDR to 8 bits for all users - Leonard - Makes sure nregs = 60 not 64 for i.MX8MM - Tested imx8mm-evk, imx7s-warp7 V1: This set adds support for the i.MX8MM. When adding support for this processor there are two interesting gotchas to watch for. #1 We current do not preserve the WAIT field for i.MX6 and since we are reusing the i.MX6 set_timing() values, this would also affect i.MX8. On the face of it, it appears to be an inocuous error with no real side effects. #2 Secondly the i.MX8MM will calculate a zero value for the RELAX bit-field when programming up OTP fuses. This is fine for programming the fuses but, it introduces a strange failure state with reloading the shadow registers subsequent to blowing an OTP fuse. The second important patch here then is ensuring the RELAX field is non-zero to avoid the failure state. Bryan O'Donoghue (5): nvmem: imx-ocotp: Elongate OCOTP_CTRL ADDR field to eight bits nvmem: imx-ocotp: Ensure WAIT bits are preserved when setting timing nvmem: imx-ocotp: Change TIMING calculation to u-boot algorithm nvmem: imx-ocotp: Add i.MX8MM support dt-bindings: imx-ocotp: Add i.MX8MM compatible .../devicetree/bindings/nvmem/imx-ocotp.txt | 1 + drivers/nvmem/imx-ocotp.c | 48 ++++++++++++++++--- 2 files changed, 43 insertions(+), 6 deletions(-)