RE: [PATCH] Document: dt: binding: imx: Fix PAD_CTL_DSE_X*

[BOUGH CHEN]

> -----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.