[EXT] Re: [PATCH 4/4] imx8mq_evk: Enable the USB3.0 host port

[Patrick Wildt]

Am Wed, Mar 03, 2021 at 08:53:52AM +0000 schrieb Bough Chen:
> > -----Original Message-----
> > From: Ye Li
> > Sent: 2021年2月27日 14:05
> > To: festevam at gmail.com; Bough Chen <haibo.chen at nxp.com>
> > Cc: Peng Fan <peng.fan at nxp.com>; u-boot at lists.denx.de; dl-uboot-imx
> > <uboot-imx at nxp.com>; sbabic at denx.de
> > Subject: Re: [EXT] Re: [PATCH 4/4] imx8mq_evk: Enable the USB3.0 host port
> > 
> > Hi Fabio,
> > 
> > On Thu, 2021-02-25 at 10:49 -0300, Fabio Estevam wrote:
> > > Caution: EXT Email
> > >
> > > Hi Ye Li,
> > >
> > > On Thu, Feb 25, 2021 at 10:34 AM Ye Li <ye.li at nxp.com> wrote:
> > >
> > > >
> > > > Sure, I have tested it on 8mq evk. I can reproduce the two issues
> > > > you met.
> > > > The first issue is caused by the ALIGN. The implementation of
> > > > standard ALIGN requires the aligned size to be power of 2. But the
> > > > ALIGN in imx8mimage does not have this requirement. So below result
> > > > is wrong by using the standard ALIGN. Your fix should be OK for this
> > > > issue.
> > > Good, could you please reply to my ALIGN macro patch with your
> > > Tested-by tag then?
> > >
> > Replied it.
> > 
> > > >
> > > > For the second issue, I did not debug into it. But our vendor tree
> > > > also uses off-on-delay-us in both u-boot and kernel. So it is likely
> > > > caused by other change.
> > > Considering we are already at 2021.04-rc2, I think it would be safer
> > > to go with my patch that removes off-on-delay-us.
> > >
> > > What do you think?
> > >
> > > Thanks
> > My debug shows the issue is triggered by below commit:
> > 
> > commit 9098682200e6cca4b776638a51200dafa16f50fb
> > Author: Haibo Chen <haibo.chen at nxp.com>
> > Date:   Tue Sep 22 18:11:43 2020 +0800
> > 
> >     mmc: fsl_esdhc_imx: remove the 1ms delay before sending command
> > 
> >     This 1ms delay before sending command already exist from the beginning
> >     of the fsl_esdhc driver added in year 2008. Now this driver has been
> >     split for two files: fsl_esdhc.c and fsl_esdhc_imx.c.
> > fsl_esdhc_imx.c
> >     only for i.MX series. i.MX series esdhc/usdhc do not need this 1ms delay
> >     before sending any command. So remove this 1ms, this will save a lot
> >     time if handling a large mmc data.
> > 
> >     Signed-off-by: Haibo Chen <haibo.chen at nxp.com>
> > 
> > 
> > The first "go idle" command in mmc_get_op_cond seems not put SD card to
> > idle status, but if adding a delay before it (like 1ms delay), then everything
> > works. This commit removed 1ms delay in sending command, so the issue is
> > triggered.  The root cause might be "startup-delay-us"
> > needed for this regulator to reach a threshold voltage for SD working.
> > Below change also can fix the issue.
> > 
> > --- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> > @@ -1,6 +1,7 @@
> >  // SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > 
> >  &reg_usdhc2_vmmc {
> > +       startup-delay-us = <1000>;
> >         u-boot,off-on-delay-us = <20000>;
> >  };
> > 
> > 
> > @Haibo, Could you help looking into the issue. What's your opinion to add the
> > startup-delay-us or revert your commit?
> > 
> 
> Hi Fabio,
> 
> I co-debug with Ye, and find the issue is also related with clock enable/disable. For current logic on imx usdhc, hardware automatically gate off the card clock when idle.
> So before the first command "go idle", there is no clock on the clock line, which not align with the sd spec.
> Refer to SD3.0 spec 6.4.1 Power UP
> The host shall supply power to the card so that the voltage is reached to Vdd_min within 250ms and
> start to supply at least 74 SD clocks to the SD card with keeping CMD line to high. In case of SPI
> mode, CS shall be held to high during 74 clock cycles
> 
> if we give the card the correct clock rate before the first "go idle" command, this issue gone.
> Please try to apply the patch I send on 2021/1/27   [PATCH] mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to control card clock output 
> 
> > Best regards,
> > Ye Li

Hi,

is this patchset still being reviewed?  I think the discussion has moved
to some SD card problem, which is fixed now?  Would be nice if USB 3.0
worked on i.MX8MQ platforms.

I can also have a look at reviewing the functionality, but I don't think
I can spot U-Boot coding style issues.

Best regards,
Patrick