[GIT PULL] TI changes for v2020.10-rc3

[Tom Rini]

On Tue, Aug 11, 2020 at 08:42:40PM +0530, Lokesh Vutla wrote:
> Hi Tom, Jan
> 
> On 11/08/20 8:32 pm, Jan Kiszka wrote:
> > On 11.08.20 16:56, Tom Rini wrote:
> >> On Tue, Aug 11, 2020 at 04:02:37PM +0530, Lokesh Vutla wrote:
> >>
> >>> Hi Tom,
> >>>     Please find the pull request for v2020.10-rc3 containing TI specific
> >>> changes. This should have been sent for rc2 but delayed due to some
> >>> comments in the last minute. Please look at the PR description for the
> >>> details on the PR.
> >>>
> >>> Travis-CI build:
> >>> https://travis-ci.org/github/lokeshvutla/u-boot/builds/716796052
> >>>
> >>> The following changes since commit c045207f96f7f7ae8c7f1341111a6010e636176b:
> >>>
> >>>    Prepare v2020.10-rc2 (2020-08-10 16:10:09 -0400)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>    https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.10-rc3
> >>>
> >>> for you to fetch changes up to ce2e881bb791dca33b122fd901820deef303f6df:
> >>>
> >>>    arm: dts: k3-j7200-common-proc-board: Enable CPSW2G port (2020-08-11
> >>> 10:22:11 +0530)
> >>>
> >>> ----------------------------------------------------------------
> >>> Below are the major changes in this PR:
> >>> - Added support for J7200 evm
> >>> - DM_ETH and DM_USB migrations for omap3
> >>> - USB DFU and mass storage support for AM65x evm
> >>> - RTI watchdog support for K3 devices
> >>> - Fix an issue with L3 cache on K3 devices
> >>> ----------------------------------------------------------------
> >>> Andrew F. Davis (1):
> >>>        arm: mach-k3: Clean non-coherent lines out of L3 cache
> >>>
> >>> Dave Gerlach (1):
> >>>        arm: dts: k3-j7200: Add R5 specific dts support
> >>>
> >>> Derald D. Woods (1):
> >>>        ARM: omap3: evm: Complete DM_ETH and DM_USB migrations
> >>>
> >>> Faiz Abbas (14):
> >>>        mmc: am654_sdhci: Use MMC_MODES_END value instead of hardcoded value
> >>>        spl: usb: Create an API spl_usb_load()
> >>>        spl: usb: Only init usb once
> >>>        armv7R: K3: am654: Use full malloc in SPL both pre and post reloc
> >>>        arm: mach-k3: sysfw-loader: Add support to load SYSFW from USB
> >>>        arm: mach-k3: am6_init: Gate mmc related configurations with the
> >>> appropriate config
> >>>        arm: mach-k3: am6_init: Do USB fixups to facilitate host and device
> >>> boot modes
> >>>        arm: mach-k3: am6_init: Add support for USB boot mode
> >>>        arm: dts: k3-am654-r5-base-board: Add USB0 nodes
> >>>        arm: dts: k3-am654-base-board: Add support for USB0 in SPL
> >>>        configs: am65x_evm: Add support for DFU related configs
> >>>        configs: am65x_evm_a53: Enable USB Mass storage and DFU boot modes
> >>>        configs: Add defconfig for USB DFU bootmode
> >>>        configs: Add new config for supporting USB mass storage boot
> >>>
> >>> Jan Kiszka (3):
> >>>        watchdog: Add support for K3 RTI watchdog
> >>>        arm: dts: k3: Add RTI watchdogs
> >>>        am654_sdhci: mmc fail to send stop cmd
> >>
> >> OK, so the last change from Jan here is:
> >>
> >> commit 6bc290047b6e0209dd8183ce78be2f9297feb3c6
> >> Author: Jan Kiszka <jan.kiszka at web.de>
> >> Date:   Sat Jul 18 16:47:04 2020 +0200
> >>
> >>      am654_sdhci: mmc fail to send stop cmd
> >>
> >>      Hi all,
> >>
> >>      on one device with one specific SD-card (possibly an aging one), I'm
> >>      seeing frequent "mmc fail to send stop cmd" messages, followed by read
> >>      errors when loading kernel and dtb. -ETIMEDOUT is returned by
> >>      mmd_send_cmd. However, I can always resolve this by simply retrying the
> >>      stop command like this:
> >>
> >>      Hardware is our IOT2050, baseline is today's master (1c4b5038afcc) with
> >>      board-enabling and a bunch of patches from your tree [1]. However,
> >>      already 4d6da10ce611 exposes the problem.
> >>
> >>      What could cause this?
> >>
> >>      Jan
> >>
> >>      [1] https://github.com/siemens/u-boot/commits/jan/iot2050
> >>
> >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> >> index d79cdef62ed2..2aca8d3a4d32 100644
> >> --- a/drivers/mmc/mmc.c
> >> +++ b/drivers/mmc/mmc.c
> >> @@ -407,7 +407,11 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst,
> >> lbaint_t start,
> >>   #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
> >>               pr_err("mmc fail to send stop cmd\n");
> >>   #endif
> >> -            return 0;
> >> +            pr_err("retrying...\n");
> >> +            if (mmc_send_cmd(mmc, &cmd, NULL)) {
> >> +                pr_err("failed again\n");
> >> +                return 0;
> >> +            }
> >>           }
> >>       }
> >>
> >> Which is a generic MMC change, grows everyone by a little bit and lacks
> >> both an S-o-B from the author and Reviewed-by of the MMC maintainer.
> >> Please drop this patch.  Thanks!
> >>
> > 
> > That was an instrumentation hunk for the issue described above. Never
> > intended to be a patch.
> 
> Sorry my bad. I did remove this patch from my queue, but not sure how it got here.
> 
> Tom,
> 	Updated the tag without this patch. Build is going on, once it completes will
> send a v2.

OK, thanks.  BTW, if you put the changes in the tag message I don't have
to copy/paste them in :)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200811/4da309a1/attachment.sig>