> -----Original Message----- > From: Aisheng Dong > Sent: 2019年3月5日 11:35 > To: Stefan Agner <stefan@xxxxxxxx>; BOUGH CHEN <haibo.chen@xxxxxxx> > Cc: Christina Quast <cquast@xxxxxxxxxxxxxxxxxxx>; festevam@xxxxxxxxx; > shawnguo@xxxxxxxxxx; kernel@xxxxxxxxxxxxxx; linus.walleij@xxxxxxxxxx; > robh+dt@xxxxxxxxxx; mark.rutland@xxxxxxx; linux-gpio@xxxxxxxxxxxxxxx; > devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; BOUGH CHEN > <haibo.chen@xxxxxxx> > Subject: RE: [PATCH] Document: dt: binding: imx: Fix PAD_CTL_DSE_X* > > + Haibo > > > From: Stefan Agner [mailto:stefan@xxxxxxxx] > > Sent: Tuesday, February 26, 2019 9:22 PM > > > > On 26.02.2019 13:21, Aisheng Dong wrote: > > >> From: Christina Quast [mailto:cquast@xxxxxxxxxxxxxxxxxxx] > > >> Sent: Saturday, February 23, 2019 1:01 AM > > >> > > >> In the iMX7d datasheet, the PAD_CTL_DSE_X* values are different > > >> from the documentation. > > >> > > > > > > It's a doc problem. > > > Latest RM seems got updated. > > > > > > As here it's a reference definition in binding doc and device tree > > > actually does not use it (IMX Pinctrl use raw data to set pad > > > configuration). So it won't cause any compatibility issue to me. > > > > > > Please update the patch title to: > > > dt-bindings: pinctrl: imx7d: xxxxx > > > > > > Otherwise: > > > Ack-by: Dong Aisheng <aisheng.dong@xxxxxxx> > > > > Btw, I saw that imx7d-sdb.dts (and probably other i.MX 7 boards too) > > use three different settings for usdhc pinctrl: 0x59, 0x5a and 0x5b > > (for default, 100MHz and 200MHz respectively). One would expect that > > higher frequency use higher driver strength (and this is the case for i.MX 6). > > But with this new/corrected pad values this means we use x4, x2 and x6 > > for default, 100MHz and 200MHz respectively. This hardly seems right..? > > Probably needs fixing too? > > > > Yes, that's true. > Especially 100Mhz setting should be updated. > > Haibo, > Can you please help double check if X2 for 50Mhz and X4 for 100Mhz can work > stably on MX7D SDB? > If yes, we'd like to update the pad setting according to new RM version. > X2 for high speed and x4 for ddr50/ddr52 can work stable on MX7D SDB. I think all the 7D related dts need to fix this. Not sure whether 7S need this fix, can you confirm? Best Regards Haibo Chen > Regards > Dong Aisheng > > > -- > > Stefan > > > > > > > > > > Regards > > > Dong Aisheng > > > > > >> Signed-off-by: Christina Quast <cquast@xxxxxxxxxxxxxxxxxxx> > > >> --- > > >> .../devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt | 6 +++--- > > >> 1 file changed, 3 insertions(+), 3 deletions(-) > > >> > > >> diff --git > > >> a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt > > >> b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt > > >> index 6666277c3acb..8ac1d0851a0f 100644 > > >> --- > > >> a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt > > >> +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.t > > >> +++ xt > > >> @@ -48,9 +48,9 @@ PAD_CTL_HYS (1 << 3) > > >> PAD_CTL_SRE_SLOW (1 << 2) > > >> PAD_CTL_SRE_FAST (0 << 2) > > >> PAD_CTL_DSE_X1 (0 << 0) > > >> -PAD_CTL_DSE_X2 (1 << 0) > > >> -PAD_CTL_DSE_X3 (2 << 0) > > >> -PAD_CTL_DSE_X4 (3 << 0) > > >> +PAD_CTL_DSE_X4 (1 << 0) > > >> +PAD_CTL_DSE_X2 (2 << 0) > > >> +PAD_CTL_DSE_X6 (3 << 0) > > >> > > > > > > > > >> Examples: > > >> While iomuxc-lpsr is intended to be used by dedicated peripherals > > >> to take > > >> -- > > >> 2.20.1 > > >> > > >> > > >> > > >> > > >> > > >> Please consider the environment before printing this email > > >> > > >> > > >> > > >> > > >> > > >> The information transmitted is intended only for the person or > > >> entity to which it is addressed and may contain confidential and/or > > >> privileged material. Any review, retransmission, dissemination or > > >> other use of, or taking of any action in reliance upon, this > > >> information by persons or entities other than the intended > > >> recipient is > > prohibited. > > >> If you received this in error, please contact the sender or > > >> postmaster > > >> (postmaster@xxxxxxxxxxxxxxxxxxx) and delete the material from any > > >> computer. > > >> Although we routinely screen for viruses, addressees should check > > >> this e-mail and any attachment for viruses. We make no warranty as > > >> to absence of viruses in this e-mail or any attachments. > > >> Our Company's email policy is to permit incidental personal use. If > > >> this email is of a personal nature, it must not be relied upon as > > >> expressing the views or opinions of the company.
