* Re: Kernel panic : Unable to handle kernel paging request at virtual address - dead address between user and kernel address ranges
From: Ulf Hansson @ 2020-08-28 12:23 UTC (permalink / raw)
To: Anders Roxell
Cc: Naresh Kamboju, Viresh Kumar, Stephen Rothwell, Arnd Bergmann,
Rajendra Nayak, open list, Linux-Next Mailing List, linux-clk,
linux-mmc, lkft-triage, John Stultz, Daniel Lezcano,
Michael Turquette, Stephen Boyd, Lars Povlsen,
madhuparnabhowmik10
In-Reply-To: <CADYN=9K3D3OZ5T_K+6MfcgVLRoktPB6LvwDiXGj-+Zpq3faYfg@mail.gmail.com>
On Fri, 28 Aug 2020 at 12:29, Anders Roxell <anders.roxell@linaro.org> wrote:
>
> On Fri, 28 Aug 2020 at 11:35, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > >
> > > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > > >
> > > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > > >
> > > > > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > > > > [ 3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > > > > [ 3.683431] sdhci_msm_probe+0x284/0x9a0
> > > > > >
> > > > > > dev_pm_opp_put_clkname() is part of the error handling in the
> > > > > > probe function, so I would deduct there are two problems:
> > > > > >
> > > > > > - something failed during the probe and the driver is trying
> > > > > > to unwind
> > > > > > - the error handling it self is buggy and tries to undo something
> > > > > > again that has already been undone.
> > > > >
> > > > > Right.
> > > > >
> > > > > > This points to Viresh's
> > > > > > d05a7238fe1c mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
> > > > >
> > > > > I completely forgot that Ulf already pushed this patch and I was
> > > > > wondering on which of the OPP core changes I wrote have done this :(
> > > > >
> > > > > > Most likely this is not the entire problem but it uncovered a preexisting
> > > > > > bug.
> > > > >
> > > > > I think this is.
> > > > >
> > > > > Naresh: Can you please test with this diff ?
> > > >
> > > > I have applied your patch and tested but still see the reported problem.
> > >
> > > The git bisect shows that the first bad commit is,
> > > d05a7238fe1c mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
> > >
> > > Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> > > Reported-by: Anders Roxell <anders.roxell@linaro.org>
> >
> > I am not sure what version of the patch you tested. However, I have
> > dropped Viresh's v1 and replaced it with v2 [1]. It's available for
> > testing at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next
> >
> > Can you please check if it still causes problems, then I will drop it, again.
>
> I tried to run with a kernel from your tree and I could see the same
> kernel panic on db410c [1].
Anders, Naresh - thanks for testing and reporting. I am dropping the
patch from my tree.
Viresh, I suggest to keep Anders/Naresh in the cc, for the next
version. Then I can wait for their tested-by tag before I apply again.
Kind regards
Uffe
^ permalink raw reply
* RE: [RFT] mmc: tmio: reset device on timeout, too
From: Yoshihiro Shimoda @ 2020-08-28 12:18 UTC (permalink / raw)
To: Wolfram Sang, linux-mmc@vger.kernel.org; +Cc: linux-renesas-soc@vger.kernel.org
In-Reply-To: <20200821081654.28280-1-wsa+renesas@sang-engineering.com>
Hi Wolfram-san,
> From: Wolfram Sang, Sent: Friday, August 21, 2020 5:17 PM
>
> When a command response times out, the TMIO driver has been resetting
> the controller ever since. However, this means some initialization like
> bus width or tuning settings will be forgotten. To ensure proper working
> in all code paths, we will enforce a reset of the remote device, too.
> Many thanks to the Renesas BSP team for the detailed description of the
> problem.
>
> Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> This patch depends on the TMIO reset refactorization:
>
> [RFT 0/6] mmc: refactor reset callbacks
>
> Looking also for tests here. Thanks!
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Also, I tested on R-Car H3 ES3.0 and confirmed that this patch resolved
an issue which any commands of eMMC could not work after
tmio_mmc_reset_work() was called. So,
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Best regards,
Yoshihiro Shimoda
^ permalink raw reply
* Re: Kernel panic : Unable to handle kernel paging request at virtual address - dead address between user and kernel address ranges
From: Anders Roxell @ 2020-08-28 10:29 UTC (permalink / raw)
To: Ulf Hansson
Cc: Naresh Kamboju, Viresh Kumar, Stephen Rothwell, Arnd Bergmann,
Rajendra Nayak, open list, Linux-Next Mailing List, linux-clk,
linux-mmc, lkft-triage, John Stultz, Daniel Lezcano,
Michael Turquette, Stephen Boyd, Lars Povlsen,
madhuparnabhowmik10
In-Reply-To: <CAPDyKFrpOqpBiSvkvO7sXHiQDOwdXYmx-80Ji5wW79QF-MrOuQ@mail.gmail.com>
On Fri, 28 Aug 2020 at 11:35, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >
> > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > >
> > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > >
> > > > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > > > [ 3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > > > [ 3.683431] sdhci_msm_probe+0x284/0x9a0
> > > > >
> > > > > dev_pm_opp_put_clkname() is part of the error handling in the
> > > > > probe function, so I would deduct there are two problems:
> > > > >
> > > > > - something failed during the probe and the driver is trying
> > > > > to unwind
> > > > > - the error handling it self is buggy and tries to undo something
> > > > > again that has already been undone.
> > > >
> > > > Right.
> > > >
> > > > > This points to Viresh's
> > > > > d05a7238fe1c mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
> > > >
> > > > I completely forgot that Ulf already pushed this patch and I was
> > > > wondering on which of the OPP core changes I wrote have done this :(
> > > >
> > > > > Most likely this is not the entire problem but it uncovered a preexisting
> > > > > bug.
> > > >
> > > > I think this is.
> > > >
> > > > Naresh: Can you please test with this diff ?
> > >
> > > I have applied your patch and tested but still see the reported problem.
> >
> > The git bisect shows that the first bad commit is,
> > d05a7238fe1c mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
> >
> > Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> > Reported-by: Anders Roxell <anders.roxell@linaro.org>
>
> I am not sure what version of the patch you tested. However, I have
> dropped Viresh's v1 and replaced it with v2 [1]. It's available for
> testing at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next
>
> Can you please check if it still causes problems, then I will drop it, again.
I tried to run with a kernel from your tree and I could see the same
kernel panic on db410c [1].
Cheers,
Anders
[1] https://lkft.validation.linaro.org/scheduler/job/1717770#L1912
^ permalink raw reply
* Re: Kernel panic : Unable to handle kernel paging request at virtual address - dead address between user and kernel address ranges
From: Naresh Kamboju @ 2020-08-28 10:08 UTC (permalink / raw)
To: Ulf Hansson
Cc: Viresh Kumar, Stephen Rothwell, Arnd Bergmann, Rajendra Nayak,
open list, Linux-Next Mailing List, linux-clk, linux-mmc,
lkft-triage, John Stultz, Daniel Lezcano, Michael Turquette,
Stephen Boyd, Lars Povlsen, madhuparnabhowmik10, Anders Roxell
In-Reply-To: <CAPDyKFrpOqpBiSvkvO7sXHiQDOwdXYmx-80Ji5wW79QF-MrOuQ@mail.gmail.com>
On Fri, 28 Aug 2020 at 15:05, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >
> > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > >
> > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > >
> > > > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > > > [ 3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > > > [ 3.683431] sdhci_msm_probe+0x284/0x9a0
> > > > >
> > > > > dev_pm_opp_put_clkname() is part of the error handling in the
> > > > > probe function, so I would deduct there are two problems:
> > > > >
> > > > > - something failed during the probe and the driver is trying
> > > > > to unwind
> > > > > - the error handling it self is buggy and tries to undo something
> > > > > again that has already been undone.
> > > >
> > > > Right.
> > > >
> > > > > This points to Viresh's
> > > > > d05a7238fe1c mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
> > > >
> > > > I completely forgot that Ulf already pushed this patch and I was
> > > > wondering on which of the OPP core changes I wrote have done this :(
> > > >
> > > > > Most likely this is not the entire problem but it uncovered a preexisting
> > > > > bug.
> > > >
> > > > I think this is.
> > > >
> > > > Naresh: Can you please test with this diff ?
> > >
> > > I have applied your patch and tested but still see the reported problem.
> >
> > The git bisect shows that the first bad commit is,
> > d05a7238fe1c mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
> >
> > Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> > Reported-by: Anders Roxell <anders.roxell@linaro.org>
>
> I am not sure what version of the patch you tested.
I have applied The v2 patch series on top of linux next-20200824.
and tested again the reported kernel panic still there on db410c [1]
https://lkft.validation.linaro.org/scheduler/job/1717611#L1874
- Naresh
^ permalink raw reply
* Re: [PATCH 01/22] dt-bindings: gpio: fsl-imx-gpio: Add i.MX 8 compatibles
From: Linus Walleij @ 2020-08-28 9:42 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM, Linux ARM,
linux-mmc, linux-mtd, linux-pwm, open list:SERIAL DRIVERS,
Linux PM list, LINUXWATCHDOG, Thierry Reding, Anson Huang
In-Reply-To: <20200823161550.3981-1-krzk@kernel.org>
On Sun, Aug 23, 2020 at 6:16 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> DTSes with new i.MX 8 SoCs introduce their own compatibles so add them
> to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@30200000:
> compatible:0: 'fsl,imx8mm-gpio' is not one of ['fsl,imx1-gpio', 'fsl,imx21-gpio', 'fsl,imx31-gpio', 'fsl,imx35-gpio', 'fsl,imx7d-gpio']
> From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@30200000:
> compatible: ['fsl,imx8mm-gpio', 'fsl,imx35-gpio'] is too long
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@30200000:
> compatible: Additional items are not allowed ('fsl,imx35-gpio' was unexpected)
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
I'm just waiting for some review from the i.MX people on these FSL things,
then I can apply it.
Yours,
Linus Walleij
^ permalink raw reply
* Re: Kernel panic : Unable to handle kernel paging request at virtual address - dead address between user and kernel address ranges
From: Ulf Hansson @ 2020-08-28 9:34 UTC (permalink / raw)
To: Naresh Kamboju
Cc: Viresh Kumar, Stephen Rothwell, Arnd Bergmann, Rajendra Nayak,
open list, Linux-Next Mailing List, linux-clk, linux-mmc,
lkft-triage, John Stultz, Daniel Lezcano, Michael Turquette,
Stephen Boyd, Lars Povlsen, madhuparnabhowmik10, Anders Roxell
In-Reply-To: <CA+G9fYvSEHua0EpW64rASucWuS-U2STAZxufrfN75UDspGt2cA@mail.gmail.com>
On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >
> > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > >
> > > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > > [ 3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > > [ 3.683431] sdhci_msm_probe+0x284/0x9a0
> > > >
> > > > dev_pm_opp_put_clkname() is part of the error handling in the
> > > > probe function, so I would deduct there are two problems:
> > > >
> > > > - something failed during the probe and the driver is trying
> > > > to unwind
> > > > - the error handling it self is buggy and tries to undo something
> > > > again that has already been undone.
> > >
> > > Right.
> > >
> > > > This points to Viresh's
> > > > d05a7238fe1c mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
> > >
> > > I completely forgot that Ulf already pushed this patch and I was
> > > wondering on which of the OPP core changes I wrote have done this :(
> > >
> > > > Most likely this is not the entire problem but it uncovered a preexisting
> > > > bug.
> > >
> > > I think this is.
> > >
> > > Naresh: Can you please test with this diff ?
> >
> > I have applied your patch and tested but still see the reported problem.
>
> The git bisect shows that the first bad commit is,
> d05a7238fe1c mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Reported-by: Anders Roxell <anders.roxell@linaro.org>
I am not sure what version of the patch you tested. However, I have
dropped Viresh's v1 and replaced it with v2 [1]. It's available for
testing at:
https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next
Can you please check if it still causes problems, then I will drop it, again.
Kind regards
Uffe
[1] https://lkml.org/lkml/2020/8/28/43
^ permalink raw reply
* Re: [PATCH 09/10] sh: don't allow non-coherent DMA for NOMMU
From: Ulf Hansson @ 2020-08-28 9:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Rich Felker, Yoshinori Sato, Linux-sh list,
Linux Kernel Mailing List, linux-mmc@vger.kernel.org, linux-spi
In-Reply-To: <20200828042422.GA29734@lst.de>
On Fri, 28 Aug 2020 at 06:24, Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, Aug 27, 2020 at 10:11:53PM -0400, Rich Felker wrote:
> > > This change broke SD card support on J2 because MMC_SPI spuriously
> > > depends on HAS_DMA. It looks like it can be fixed just by removing
> > > that dependency from drivers/mmc/host/Kconfig.
> >
> > It can't. mmp_spi_probe fails with ENOMEM, probably due to trying to
> > do some DMA setup thing that's not going to be needed if the
> > underlying SPI device doesn't support/use DMA.
>
> Adding the linux-mmc and linux-spi lists, as that seems pretty odd.
The mmc_spi driver needs modernizations, so I am not surprised to see
odd things.
My guess is that in ->probe() we check "if
(spi->master->dev.parent->dma_mask)" - > and runs dma_map*()
operations, which fails and leads to bailing out of ->probe() to
return an error code.
However, by looking at the code, one get the feeling that the DMA
support is somewhat prepared to be made optional. I guess it has never
been really tested, as the Kconfig option has "depends on HAS_DMA" -
and it's been like that as long as I can remember.
Kind regards
Uffe
^ permalink raw reply
* Re: Kernel panic : Unable to handle kernel paging request at virtual address - dead address between user and kernel address ranges
From: Naresh Kamboju @ 2020-08-28 9:22 UTC (permalink / raw)
To: Viresh Kumar, Stephen Rothwell, Ulf Hansson
Cc: Arnd Bergmann, Rajendra Nayak, open list, Linux-Next Mailing List,
linux-clk, linux-mmc, lkft-triage, John Stultz, Daniel Lezcano,
Michael Turquette, Stephen Boyd, Lars Povlsen,
madhuparnabhowmik10, Anders Roxell
In-Reply-To: <CA+G9fYv=XLtsuD=tVR1HHotwpKLkbwZVyPr4UhY-jD+6-duTmw@mail.gmail.com>
On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> On Thu, 27 Aug 2020 at 15:42, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >
> > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > [ 3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > [ 3.683431] sdhci_msm_probe+0x284/0x9a0
> > >
> > > dev_pm_opp_put_clkname() is part of the error handling in the
> > > probe function, so I would deduct there are two problems:
> > >
> > > - something failed during the probe and the driver is trying
> > > to unwind
> > > - the error handling it self is buggy and tries to undo something
> > > again that has already been undone.
> >
> > Right.
> >
> > > This points to Viresh's
> > > d05a7238fe1c mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
> >
> > I completely forgot that Ulf already pushed this patch and I was
> > wondering on which of the OPP core changes I wrote have done this :(
> >
> > > Most likely this is not the entire problem but it uncovered a preexisting
> > > bug.
> >
> > I think this is.
> >
> > Naresh: Can you please test with this diff ?
>
> I have applied your patch and tested but still see the reported problem.
The git bisect shows that the first bad commit is,
d05a7238fe1c mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reported-by: Anders Roxell <anders.roxell@linaro.org>
>
> - Naresh
^ permalink raw reply
* Re: [PATCH] mmc: sdhci-msm: When dev_pm_opp_of_add_table() returns 0 it's not an error
From: Naresh Kamboju @ 2020-08-28 9:15 UTC (permalink / raw)
To: Douglas Anderson
Cc: Ulf Hansson, Arnd Bergmann, vbadigan, Rajendra Nayak,
Adrian Hunter, Andy Gross, Bjorn Andersson, Viresh Kumar,
linux-arm-msm, open list, linux-mmc
In-Reply-To: <CA+G9fYtWpBQb8Ew_G=bjcR7wBHMgKm=EXV7vuk6FE9m0-4Ef3A@mail.gmail.com>
On Fri, 28 Aug 2020 at 01:57, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> On Thu, 27 Aug 2020 at 21:03, Douglas Anderson <dianders@chromium.org> wrote:
> >
> > The commit d05a7238fe1c ("mmc: sdhci-msm: Unconditionally call
> > dev_pm_opp_of_remove_table()") works fine in the case where there is
> > no OPP table. However, if there is an OPP table then
> > dev_pm_opp_of_add_table() will return 0. Since 0 != -ENODEV then the
> > "if (ret != -ENODEV)" will evaluate to true and we'll fall into the
> > error case. Oops.
> >
> > Let's fix this.
> >
> > Fixes: d05a7238fe1c ("mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()")
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
>
> I will test this patch and report again on this email thread.
Sorry this patch did not solve the reported problem.
However, I would be testing the V2 set from Viresh Kumar.
and report the test results on the other patch set [1].
[1] https://lore.kernel.org/linux-pm/cover.1598594714.git.viresh.kumar@linaro.org
^ permalink raw reply
* Re: [PATCH v3 12/19] dt-bindings: mmc: fsl-imx-esdhc: Fix i.MX 8 compatible matching
From: Krzysztof Kozlowski @ 2020-08-28 9:12 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Miquel Raynal, Mark Rutland, Thierry Reding,
Anson Huang, Li Yang, Han Xu, Frank Li, Fugang Duan, DTML,
Linux Kernel Mailing List, open list:GPIO SUBSYSTEM, Linux ARM,
linux-mmc@vger.kernel.org, linux-mtd, linux-pwm, linux-serial,
Linux PM, linux-watchdog
In-Reply-To: <CAPDyKFp9m6xBJMGn2TgwD8VEUZ0JwzgowU32qUbL1qgEPua-GA@mail.gmail.com>
On Fri, Aug 28, 2020 at 10:45:40AM +0200, Ulf Hansson wrote:
> On Tue, 25 Aug 2020 at 21:37, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > The i.MX 8 DTSes use two compatibles so update the binding to fix
> > dtbs_check warnings like:
> >
> > arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: mmc@30b40000:
> > compatible: ['fsl,imx8mn-usdhc', 'fsl,imx7d-usdhc'] is too long
> > From schema: Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> >
> > arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: mmc@30b40000:
> > compatible: Additional items are not allowed ('fsl,imx7d-usdhc' was unexpected)
> >
> > arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dt.yaml: mmc@30b40000:
> > compatible: ['fsl,imx8mn-usdhc', 'fsl,imx7d-usdhc'] is too long
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> Rob, Krzysztof - do you want me to pick this one?
dt-bindings are independent so they can be applied individually.
I don't mind you taking it but still Rob's ack/review would be needed.
Other choice is that entire dt-bindings series go through Rob's tree.
Rob, what's your preference?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] mmc: sdhci-msm: Enable restore_dll_config flag for sc7180 target
From: Ulf Hansson @ 2020-08-28 8:51 UTC (permalink / raw)
To: Veerabhadrarao Badiganti
Cc: Adrian Hunter, Doug Anderson, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, linux-arm-msm, Andy Gross,
Bjorn Andersson
In-Reply-To: <1598541694-15694-1-git-send-email-vbadigan@codeaurora.org>
On Thu, 27 Aug 2020 at 17:22, Veerabhadrarao Badiganti
<vbadigan@codeaurora.org> wrote:
>
> On sc7180 target, issues are observed with HS400 mode due to a
> hardware limitation. If sdcc clock is dynamically gated and ungated,
> the very next command is failing with command CRC/timeout errors.
>
> To mitigate this issue, DLL phase has to be restored whenever sdcc
> clock is gated dynamically. The restore_dll_config ensures this.
> Enabling this flag with this change. And simply re-using the sdm845
> target configuration for this flag.
>
> Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-msm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 5a33389037cd..d4c02884cca8 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -2151,6 +2151,7 @@ static void sdhci_msm_dump_vendor_regs(struct sdhci_host *host)
> {.compatible = "qcom,sdhci-msm-v5", .data = &sdhci_msm_v5_var},
> {.compatible = "qcom,sdm845-sdhci", .data = &sdm845_sdhci_var},
> {.compatible = "qcom,sm8250-sdhci", .data = &sm8250_sdhci_var},
> + {.compatible = "qcom,sc7180-sdhci", .data = &sdm845_sdhci_var},
> {},
> };
>
> --
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
^ permalink raw reply
* Re: [PATCH v3 12/19] dt-bindings: mmc: fsl-imx-esdhc: Fix i.MX 8 compatible matching
From: Ulf Hansson @ 2020-08-28 8:45 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring
Cc: Linus Walleij, Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Miquel Raynal, Mark Rutland, Thierry Reding, Anson Huang, Li Yang,
Han Xu, Frank Li, Fugang Duan, DTML, Linux Kernel Mailing List,
open list:GPIO SUBSYSTEM, Linux ARM, linux-mmc@vger.kernel.org,
linux-mtd, linux-pwm, linux-serial, Linux PM, linux-watchdog
In-Reply-To: <20200825193536.7332-13-krzk@kernel.org>
On Tue, 25 Aug 2020 at 21:37, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> The i.MX 8 DTSes use two compatibles so update the binding to fix
> dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: mmc@30b40000:
> compatible: ['fsl,imx8mn-usdhc', 'fsl,imx7d-usdhc'] is too long
> From schema: Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
>
> arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: mmc@30b40000:
> compatible: Additional items are not allowed ('fsl,imx7d-usdhc' was unexpected)
>
> arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dt.yaml: mmc@30b40000:
> compatible: ['fsl,imx8mn-usdhc', 'fsl,imx7d-usdhc'] is too long
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Rob, Krzysztof - do you want me to pick this one?
Kind regards
Uffe
>
> ---
>
> Changes since v2:
> 1. Remove moved compatibles.
>
> Changes since v1:
> 1. Handle also fsl,imx8mm-usdhc and fsl,imx8qxp-usdhc
> ---
> .../bindings/mmc/fsl-imx-esdhc.yaml | 37 ++++++++++---------
> 1 file changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> index 10b45966f1b8..e71d13c2d109 100644
> --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> @@ -21,23 +21,26 @@ description: |
>
> properties:
> compatible:
> - enum:
> - - fsl,imx25-esdhc
> - - fsl,imx35-esdhc
> - - fsl,imx51-esdhc
> - - fsl,imx53-esdhc
> - - fsl,imx6q-usdhc
> - - fsl,imx6sl-usdhc
> - - fsl,imx6sx-usdhc
> - - fsl,imx6ull-usdhc
> - - fsl,imx7d-usdhc
> - - fsl,imx7ulp-usdhc
> - - fsl,imx8mq-usdhc
> - - fsl,imx8mm-usdhc
> - - fsl,imx8mn-usdhc
> - - fsl,imx8mp-usdhc
> - - fsl,imx8qm-usdhc
> - - fsl,imx8qxp-usdhc
> + oneOf:
> + - enum:
> + - fsl,imx25-esdhc
> + - fsl,imx35-esdhc
> + - fsl,imx51-esdhc
> + - fsl,imx53-esdhc
> + - fsl,imx6q-usdhc
> + - fsl,imx6sl-usdhc
> + - fsl,imx6sx-usdhc
> + - fsl,imx6ull-usdhc
> + - fsl,imx7d-usdhc
> + - fsl,imx7ulp-usdhc
> + - items:
> + - enum:
> + - fsl,imx8mm-usdhc
> + - fsl,imx8mn-usdhc
> + - fsl,imx8mp-usdhc
> + - fsl,imx8mq-usdhc
> + - fsl,imx8qxp-usdhc
> + - const: fsl,imx7d-usdhc
>
> reg:
> maxItems: 1
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v7 0/7] Fix timeout clock used by hardware data timeout
From: Ulf Hansson @ 2020-08-28 8:44 UTC (permalink / raw)
To: Sowjanya Komatineni
Cc: Adrian Hunter, Thierry Reding, Jon Hunter, Rob Herring,
linux-tegra, Linux Kernel Mailing List, linux-mmc@vger.kernel.org,
DTML, # 4.0+
In-Reply-To: <1598548861-32373-1-git-send-email-skomatineni@nvidia.com>
On Thu, 27 Aug 2020 at 19:21, Sowjanya Komatineni
<skomatineni@nvidia.com> wrote:
>
> Tegra210/Tegra186/Tegra194 has incorrectly enabled
> SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support.
>
> Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK)
> all the time for hardware data timeout instead of SDCLK and this TMCLK
> need to be kept enabled by Tegra sdmmc driver.
>
> This series includes patches to fix this for Tegra210/Tegra186/Tegra194.
>
> These patches need to be manually backported to 4.19.
>
> Will send patches for 4.19 backport separately.
>
> Delta between patch versions:
> [v7]: v7 has below change
> - v6 has implementation for retrieving tmclk irrespective of
> clocks order. But based in internal discussion with Thierry
> this is not required as typically order specified in DT
> bindings is the order validator want to see in DT.
>
> [v6]: v5 is sent out mistakenly with incorrect patches.
> v6 includes proper patches addressing v4 feedback
> - updated dt-binding doc to be more clear
> - updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
> based on no. of clocks in sdhci device node as old device trees
> do not use sdhci clock name and this allows proper clock retrival
> irrespective of sdhci and tmclk clocks order in device tree.
> - Added separate quirk for identifying SoC's supporting separate
> timeout clock to be more clear.
>
> [v5]: Include below changes based on v4 feedback
> - updated dt-binding doc to be more clear
> - updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
> based on no. of clocks in sdhci device node as old device trees
> do not use sdhci clock name and this allows proper clock retrival
> irrespective of sdhci and tmclk clocks order in device tree.
> - Added separate quirk for identifying SoC's supporting separate
> timeout clock to be more clear.
>
> [v4]: Include additional dt-binding patch
>
> [v3]: Same as v2 with fixes tag
>
> [v2]: Includes minor fix
> - Patch-0006: parentheses around operand of '!'
>
> Sowjanya Komatineni (7):
> sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
> sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186
> dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later
> arm64: tegra: Add missing timeout clock to Tegra210 SDMMC
> arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes
> arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes
> sdhci: tegra: Add missing TMCLK for data timeout
>
> .../bindings/mmc/nvidia,tegra20-sdhci.txt | 32 +++++++++++--
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 20 ++++----
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 15 +++---
> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 20 ++++----
> drivers/mmc/host/sdhci-tegra.c | 55 ++++++++++++++++++++--
> 5 files changed, 113 insertions(+), 29 deletions(-)
>
> --
> 2.7.4
>
Applied for fixes, thanks!
Kind regards
Uffe
^ permalink raw reply
* Re: [RFT 0/6] mmc: refactor reset callbacks
From: Ulf Hansson @ 2020-08-28 8:44 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-mmc@vger.kernel.org, Linux-Renesas, Yoshihiro Shimoda,
Niklas Söderlund, Masahiro Yamada
In-Reply-To: <20200820132538.24758-1-wsa+renesas@sang-engineering.com>
On Thu, 20 Aug 2020 at 15:26, Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
> While debugging something else, I noticed that the SDHI driver
> doesn't use the 'hw_reset' callback as intended. It was used to reset
> the tuning block but not the remote card via RSTn.
>
> So, this patch series fixes it by moving stuff to the reset callback. In
> addition, calls within the TMIO core are converted to 'reset' and the
> 'hw_reset' callback is only used by the MMC core now.
>
> This allow for further cleanups which make the code a tad smaller and
> much more readable.
>
> I did some testing here, and tuning etc... still works, no regressions,
> both with eMMC and SDXC. I send this out as RFT because I want to give
> our BSP team also a chance to test more advanced cases. Also, I will be
> thinking of more ways to verify this all is correct. A branch for
> testing can be found here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/sdhi/refactor_hw_reset
>
> The branch is based on top of v5.9-rc1.
>
> Looking forward to comments!
>
> Happy hacking,
>
> Wolfram
>
>
> Wolfram Sang (6):
> mmc: renesas_sdhi: move wrong 'hw_reset' to 'reset'
> Revert "mmc: tmio: fix reset operation"
> mmc: tmio: remove indirection of 'hw_reset' callback
> mmc: tmio: factor out common parts of the reset routine
> mmc: tmio: don't reset whole IP core when tuning fails
> mmc: tmio: remove indirection of 'execute_tuning' callback
>
> drivers/mmc/host/renesas_sdhi_core.c | 58 ++++++++++++++--------------
> drivers/mmc/host/tmio_mmc.c | 8 ----
> drivers/mmc/host/tmio_mmc.h | 7 ----
> drivers/mmc/host/tmio_mmc_core.c | 45 ++++-----------------
> drivers/mmc/host/uniphier-sd.c | 5 ++-
> 5 files changed, 39 insertions(+), 84 deletions(-)
>
> --
> 2.20.1
>
Applied for next, also adding the tested-by tag from Shimoda-san to
all the patches, thanks!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v2] mmc: sdhci_am654: Add workaround for card detect debounce timer
From: Ulf Hansson @ 2020-08-28 8:44 UTC (permalink / raw)
To: Faiz Abbas
Cc: Linux Kernel Mailing List, linux-mmc@vger.kernel.org, Linux ARM,
Adrian Hunter
In-Reply-To: <20200825170015.32285-1-faiz_abbas@ti.com>
On Tue, 25 Aug 2020 at 19:00, Faiz Abbas <faiz_abbas@ti.com> wrote:
>
> There is a one time delay because of a card detect debounce timer in the
> controller IP. This timer runs as soon as power is applied to the module
> regardless of whether a card is present or not and any writes to
> SDHCI_POWER_ON will return 0 before it expires. This timeout has been
> measured to be about 1 second in am654x and j721e.
>
> Write-and-read-back in a loop on SDHCI_POWER_ON for a maximum of
> 1.5 seconds to make sure that the controller actually powers on.
>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> v2: Use read_poll_timeout() standard macro
>
> drivers/mmc/host/sdhci_am654.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
> index f9d24af12396..9a048c80dad4 100644
> --- a/drivers/mmc/host/sdhci_am654.c
> +++ b/drivers/mmc/host/sdhci_am654.c
> @@ -6,6 +6,7 @@
> *
> */
> #include <linux/clk.h>
> +#include <linux/iopoll.h>
> #include <linux/of.h>
> #include <linux/module.h>
> #include <linux/pm_runtime.h>
> @@ -272,9 +273,19 @@ static void sdhci_j721e_4bit_set_clock(struct sdhci_host *host,
> sdhci_set_clock(host, clock);
> }
>
> +static u8 sdhci_am654_write_power_on(struct sdhci_host *host, u8 val, int reg)
> +{
> + writeb(val, host->ioaddr + reg);
> + usleep_range(1000, 10000);
> + return readb(host->ioaddr + reg);
> +}
> +
> +#define MAX_POWER_ON_TIMEOUT 1500000 /* us */
> static void sdhci_am654_write_b(struct sdhci_host *host, u8 val, int reg)
> {
> unsigned char timing = host->mmc->ios.timing;
> + u8 pwr;
> + int ret;
>
> if (reg == SDHCI_HOST_CONTROL) {
> switch (timing) {
> @@ -291,6 +302,19 @@ static void sdhci_am654_write_b(struct sdhci_host *host, u8 val, int reg)
> }
>
> writeb(val, host->ioaddr + reg);
> + if (reg == SDHCI_POWER_CONTROL && (val & SDHCI_POWER_ON)) {
> + /*
> + * Power on will not happen until the card detect debounce
> + * timer expires. Wait at least 1.5 seconds for the power on
> + * bit to be set
> + */
> + ret = read_poll_timeout(sdhci_am654_write_power_on, pwr,
> + pwr & SDHCI_POWER_ON, 0,
> + MAX_POWER_ON_TIMEOUT, false, host, val,
> + reg);
> + if (ret)
> + dev_warn(mmc_dev(host->mmc), "Power on failed\n");
> + }
> }
>
> static int sdhci_am654_execute_tuning(struct mmc_host *mmc, u32 opcode)
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH RFC] mmc: sdhci-msm: enable compile-testing on !ARM
From: Ulf Hansson @ 2020-08-28 8:44 UTC (permalink / raw)
To: Alex Dewar
Cc: Adrian Hunter, Andy Gross, Bjorn Andersson, Baolin Wang,
Arnd Bergmann, Andrew Jeffery, Chunyan Zhang, Masahiro Yamada,
Martin Blumenstingl, Angelo Dureghello, Takao Orito, Guo Ren,
linux-mmc@vger.kernel.org, Linux Kernel Mailing List,
linux-arm-msm
In-Reply-To: <20200824171854.406157-1-alex.dewar90@gmail.com>
On Mon, 24 Aug 2020 at 19:20, Alex Dewar <alex.dewar90@gmail.com> wrote:
>
> There seems to be no particular reason to only test for ARM, so allow
> for build-testing on other platforms to increase coverage.
Agree.
>
> Build-tested on x86 with allyesconfig.
>
> Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
I have applied this for next, let's see what the build bots reports, thanks!
Kind regards
Uffe
> ---
> Let me know if there is some extra dependency needed for COMPILE_TEST! I
> don't want to break anything.
> ---
> drivers/mmc/host/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index f6c6eed5227a..7707f7385b5b 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -525,7 +525,7 @@ config MMC_ATMELMCI
>
> config MMC_SDHCI_MSM
> tristate "Qualcomm SDHCI Controller Support"
> - depends on ARCH_QCOM || (ARM && COMPILE_TEST)
> + depends on ARCH_QCOM || COMPILE_TEST
> depends on MMC_SDHCI_PLTFM
> select MMC_SDHCI_IO_ACCESSORS
> select MMC_CQHCI
> --
> 2.28.0
>
^ permalink raw reply
* Re: [PATCH] mmc: host: sdhci-esdhc-imx: remove unused code
From: Ulf Hansson @ 2020-08-28 8:44 UTC (permalink / raw)
To: Haibo Chen
Cc: Adrian Hunter, linux-mmc@vger.kernel.org, dl-linux-imx, Shawn Guo,
Sascha Hauer, Sascha Hauer, Fabio Estevam
In-Reply-To: <1598265914-23606-1-git-send-email-haibo.chen@nxp.com>
On Mon, 24 Aug 2020 at 12:51, <haibo.chen@nxp.com> wrote:
>
> From: Haibo Chen <haibo.chen@nxp.com>
>
> Value assigned to a variable(err) is never used, so remove it
>
> Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-esdhc-imx.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
> index 3d6eaf490d4a..3d2615eb7d56 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -1673,10 +1673,8 @@ static int sdhci_esdhc_imx_probe(struct platform_device *pdev)
> goto disable_ipg_clk;
>
> imx_data->pinctrl = devm_pinctrl_get(&pdev->dev);
> - if (IS_ERR(imx_data->pinctrl)) {
> - err = PTR_ERR(imx_data->pinctrl);
> + if (IS_ERR(imx_data->pinctrl))
> dev_warn(mmc_dev(host->mmc), "could not get pinctrl\n");
> - }
>
> if (esdhc_is_usdhc(imx_data)) {
> host->quirks2 |= SDHCI_QUIRK2_PRESET_VALUE_BROKEN;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] mmc: sd: Use kobj_to_dev() instead of container_of()
From: Ulf Hansson @ 2020-08-28 8:43 UTC (permalink / raw)
To: Tian Tao
Cc: (Exiting) Baolin Wang, Jisheng Zhang, Pali Rohár,
Philipl Langdale, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, linuxarm
In-Reply-To: <1598230956-58523-1-git-send-email-tiantao6@hisilicon.com>
On Mon, 24 Aug 2020 at 03:04, Tian Tao <tiantao6@hisilicon.com> wrote:
>
> Use kobj_to_dev() instead of container_of()
>
> Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/core/sd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
> index 5a2210c..a0d2c34 100644
> --- a/drivers/mmc/core/sd.c
> +++ b/drivers/mmc/core/sd.c
> @@ -735,7 +735,7 @@ static struct attribute *sd_std_attrs[] = {
> static umode_t sd_std_is_visible(struct kobject *kobj, struct attribute *attr,
> int index)
> {
> - struct device *dev = container_of(kobj, struct device, kobj);
> + struct device *dev = kobj_to_dev(kobj);
> struct mmc_card *card = mmc_dev_to_card(dev);
>
> /* CIS vendor and device ids are available only for Combo cards */
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH V2 4/8] mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
From: Ulf Hansson @ 2020-08-28 8:43 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rajendra Nayak, Adrian Hunter, Andy Gross, Bjorn Andersson,
Linux PM, Vincent Guittot, Rafael Wysocki, Stephen Boyd,
Nishanth Menon, Douglas Anderson, Naresh Kamboju, linux-arm-msm,
linux-mmc@vger.kernel.org, Linux Kernel Mailing List
In-Reply-To: <1d7c97524b9e1fbc60271d9c246c5461ca8a106c.1598594714.git.viresh.kumar@linaro.org>
On Fri, 28 Aug 2020 at 08:08, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> find the OPP table with error -ENODEV (i.e. OPP table not present for
> the device). And we can call dev_pm_opp_of_remove_table()
> unconditionally here.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Replaced v1 with v2 on my next branch, thanks!
Just to be sure, this patch doesn't depend on any changes for the opp
core that are queued for v5.10?
Kind regards
Uffe
>
> ---
> V2:
> - Compare with -ENODEV only for failures.
> - Create new label to put clkname.
> ---
> drivers/mmc/host/sdhci-msm.c | 14 +++++---------
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 5a33389037cd..f7beaec6412e 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -263,7 +263,6 @@ struct sdhci_msm_host {
> unsigned long clk_rate;
> struct mmc_host *mmc;
> struct opp_table *opp_table;
> - bool has_opp_table;
> bool use_14lpp_dll_reset;
> bool tuning_done;
> bool calibration_done;
> @@ -2285,11 +2284,9 @@ static int sdhci_msm_probe(struct platform_device *pdev)
>
> /* OPP table is optional */
> ret = dev_pm_opp_of_add_table(&pdev->dev);
> - if (!ret) {
> - msm_host->has_opp_table = true;
> - } else if (ret != -ENODEV) {
> + if (ret && ret != -ENODEV) {
> dev_err(&pdev->dev, "Invalid OPP table in Device tree\n");
> - goto opp_cleanup;
> + goto opp_put_clkname;
> }
>
> /* Vote for maximum clock rate for maximum performance */
> @@ -2453,8 +2450,8 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> clk_bulk_disable_unprepare(ARRAY_SIZE(msm_host->bulk_clks),
> msm_host->bulk_clks);
> opp_cleanup:
> - if (msm_host->has_opp_table)
> - dev_pm_opp_of_remove_table(&pdev->dev);
> + dev_pm_opp_of_remove_table(&pdev->dev);
> +opp_put_clkname:
> dev_pm_opp_put_clkname(msm_host->opp_table);
> bus_clk_disable:
> if (!IS_ERR(msm_host->bus_clk))
> @@ -2474,8 +2471,7 @@ static int sdhci_msm_remove(struct platform_device *pdev)
>
> sdhci_remove_host(host, dead);
>
> - if (msm_host->has_opp_table)
> - dev_pm_opp_of_remove_table(&pdev->dev);
> + dev_pm_opp_of_remove_table(&pdev->dev);
> dev_pm_opp_put_clkname(msm_host->opp_table);
> pm_runtime_get_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> --
> 2.25.0.rc1.19.g042ed3e048af
>
^ permalink raw reply
* Re: [PATCH] mmc: sdhci-msm: When dev_pm_opp_of_add_table() returns 0 it's not an error
From: Ulf Hansson @ 2020-08-28 8:43 UTC (permalink / raw)
To: Viresh Kumar, Douglas Anderson, Naresh Kamboju
Cc: Arnd Bergmann, Veerabhadrarao Badiganti, Rajendra Nayak,
Adrian Hunter, Andy Gross, Bjorn Andersson, linux-arm-msm,
Linux Kernel Mailing List, linux-mmc@vger.kernel.org
In-Reply-To: <20200828050935.m32njmxdrgbudw4r@vireshk-i7>
On Fri, 28 Aug 2020 at 07:09, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 27-08-20, 08:33, Douglas Anderson wrote:
> > The commit d05a7238fe1c ("mmc: sdhci-msm: Unconditionally call
> > dev_pm_opp_of_remove_table()") works fine in the case where there is
> > no OPP table. However, if there is an OPP table then
> > dev_pm_opp_of_add_table() will return 0. Since 0 != -ENODEV then the
> > "if (ret != -ENODEV)" will evaluate to true and we'll fall into the
> > error case. Oops.
> >
> > Let's fix this.
> >
> > Fixes: d05a7238fe1c ("mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()")
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> > drivers/mmc/host/sdhci-msm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> > index b7e47107a31a..55101dba42bd 100644
> > --- a/drivers/mmc/host/sdhci-msm.c
> > +++ b/drivers/mmc/host/sdhci-msm.c
> > @@ -2284,7 +2284,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> >
> > /* OPP table is optional */
> > ret = dev_pm_opp_of_add_table(&pdev->dev);
> > - if (ret != -ENODEV) {
> > + if (ret && ret != -ENODEV) {
> > dev_err(&pdev->dev, "Invalid OPP table in Device tree\n");
> > goto opp_cleanup;
> > }
>
> Wow!
>
> How many bugs did I introduce with a simple patch :(
>
> @Ulf, since this is material for 5.10 I was planning to resend the
> original patch itself with all the things fixed. Will you be able to
> rebase your tree? Or do you want to apply fixes separately ?
I have rebased my tree, to get rid of the problems completely.
Thanks everybody for helping out!
Kind regards
Uffe
^ permalink raw reply
* Re: [v5,2/3] arm64: dts: mt7622: add reset node for mmc device
From: Ulf Hansson @ 2020-08-28 8:43 UTC (permalink / raw)
To: Matthias Brugger, Wenbin Mei
Cc: Rob Herring, Chaotian Jing, Philipp Zabel,
linux-mmc@vger.kernel.org, DTML, Linux ARM,
moderated list:ARM/Mediatek SoC support,
Linux Kernel Mailing List, srv_heupstream, # 4.0+
In-Reply-To: <1dfc1938-f5e8-c4c8-57c7-d7b6c33dcb1d@gmail.com>
On Thu, 27 Aug 2020 at 10:23, Matthias Brugger <matthias.bgg@gmail.com> wrote:
>
>
>
> On 24/08/2020 11:50, Ulf Hansson wrote:
> > On Fri, 14 Aug 2020 at 03:44, Wenbin Mei <wenbin.mei@mediatek.com> wrote:
> >>
> >> This commit adds reset node for mmc device.
> >>
> >> Cc: <stable@vger.kernel.org> # v5.4+
> >> Fixes: 966580ad236e ("mmc: mediatek: add support for MT7622 SoC")
> >> Signed-off-by: Wenbin Mei <wenbin.mei@mediatek.com>
> >> Tested-by: Frank Wunderlich <frank-w@public-files.de>
> >
> > I can pick this for my fixes branch, together with the other changes,
> > however deferring that until Matthias acks it.
>
> Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
>
> My understanding is, that this will land also in v5.9-rc[3,4], correct?
Correct.
Applied for fixes, thanks!
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH mmc-next] dt-bindings: mmc: Fix mmc node name in DT example
From: Ulf Hansson @ 2020-08-28 8:43 UTC (permalink / raw)
To: Lars Povlsen
Cc: Rob Herring, Adrian Hunter, Microchip Linux Driver Support,
linux-mmc@vger.kernel.org, DTML, Linux Kernel Mailing List,
Alexandre Belloni
In-Reply-To: <20200826130106.22889-1-lars.povlsen@microchip.com>
On Wed, 26 Aug 2020 at 15:01, Lars Povlsen <lars.povlsen@microchip.com> wrote:
>
> This changes the "mmc0@600800000" node name to "mmc@600800000" to be
> compliant with devicetree naming rules.
>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
Applied, but squashing this into the original commit, thanks!
Kind regards
Uffe
> ---
> .../devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml b/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
> index c9a572863b88..55883290543b 100644
> --- a/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
> @@ -50,7 +50,7 @@ examples:
> - |
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/clock/microchip,sparx5.h>
> - sdhci0: mmc0@600800000 {
> + sdhci0: mmc@600800000 {
> compatible = "microchip,dw-sparx5-sdhci";
> reg = <0x00800000 0x1000>;
> pinctrl-0 = <&emmc_pins>;
> --
> 2.27.0
^ permalink raw reply
* [PATCH V2 4/8] mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
From: Viresh Kumar @ 2020-08-28 6:07 UTC (permalink / raw)
To: rnayak, Adrian Hunter, Andy Gross, Bjorn Andersson, Ulf Hansson
Cc: Viresh Kumar, linux-pm, Vincent Guittot, Rafael Wysocki,
Stephen Boyd, Nishanth Menon, Douglas Anderson, Naresh Kamboju,
linux-arm-msm, linux-mmc, linux-kernel
In-Reply-To: <cover.1598594714.git.viresh.kumar@linaro.org>
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V2:
- Compare with -ENODEV only for failures.
- Create new label to put clkname.
---
drivers/mmc/host/sdhci-msm.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 5a33389037cd..f7beaec6412e 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -263,7 +263,6 @@ struct sdhci_msm_host {
unsigned long clk_rate;
struct mmc_host *mmc;
struct opp_table *opp_table;
- bool has_opp_table;
bool use_14lpp_dll_reset;
bool tuning_done;
bool calibration_done;
@@ -2285,11 +2284,9 @@ static int sdhci_msm_probe(struct platform_device *pdev)
/* OPP table is optional */
ret = dev_pm_opp_of_add_table(&pdev->dev);
- if (!ret) {
- msm_host->has_opp_table = true;
- } else if (ret != -ENODEV) {
+ if (ret && ret != -ENODEV) {
dev_err(&pdev->dev, "Invalid OPP table in Device tree\n");
- goto opp_cleanup;
+ goto opp_put_clkname;
}
/* Vote for maximum clock rate for maximum performance */
@@ -2453,8 +2450,8 @@ static int sdhci_msm_probe(struct platform_device *pdev)
clk_bulk_disable_unprepare(ARRAY_SIZE(msm_host->bulk_clks),
msm_host->bulk_clks);
opp_cleanup:
- if (msm_host->has_opp_table)
- dev_pm_opp_of_remove_table(&pdev->dev);
+ dev_pm_opp_of_remove_table(&pdev->dev);
+opp_put_clkname:
dev_pm_opp_put_clkname(msm_host->opp_table);
bus_clk_disable:
if (!IS_ERR(msm_host->bus_clk))
@@ -2474,8 +2471,7 @@ static int sdhci_msm_remove(struct platform_device *pdev)
sdhci_remove_host(host, dead);
- if (msm_host->has_opp_table)
- dev_pm_opp_of_remove_table(&pdev->dev);
+ dev_pm_opp_of_remove_table(&pdev->dev);
dev_pm_opp_put_clkname(msm_host->opp_table);
pm_runtime_get_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
--
2.25.0.rc1.19.g042ed3e048af
^ permalink raw reply related
* [PATCH V2 0/8] opp: Unconditionally call dev_pm_opp_of_remove_table()
From: Viresh Kumar @ 2020-08-28 6:07 UTC (permalink / raw)
To: rnayak, Adrian Hunter, Andy Gross, Bjorn Andersson, Daniel Vetter,
David Airlie, Fabio Estevam, Greg Kroah-Hartman, Jiri Slaby,
Mark Brown, NXP Linux Team, Pengutronix Kernel Team, Qiang Yu,
Rafael J. Wysocki, Rob Clark, Sascha Hauer, Sean Paul, Shawn Guo,
Ulf Hansson, Viresh Kumar
Cc: linux-pm, Vincent Guittot, Stephen Boyd, Nishanth Menon,
Douglas Anderson, Naresh Kamboju, dri-devel, freedreno, lima,
linux-arm-kernel, linux-arm-msm, linux-kernel, linux-mmc,
linux-serial, linux-spi
Hello,
This cleans up some of the user code around calls to
dev_pm_opp_of_remove_table().
All the patches can be picked by respective maintainers directly except
for the last patch, which needs the previous two to get merged first.
These are based for 5.9-rc1.
Rajendra, Since most of these changes are related to qcom stuff, it
would be great if you can give them a try. I wasn't able to test them
due to lack of hardware.
Ulf, I had to revise the sdhci patch, sorry about that. Please pick this
one.
Diff between V1 and V2 is mentioned in each of the patches separately.
Viresh Kumar (8):
cpufreq: imx6q: Unconditionally call dev_pm_opp_of_remove_table()
drm/lima: Unconditionally call dev_pm_opp_of_remove_table()
drm/msm: Unconditionally call dev_pm_opp_of_remove_table()
mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
spi: spi-geni-qcom: Unconditionally call dev_pm_opp_of_remove_table()
spi: spi-qcom-qspi: Unconditionally call dev_pm_opp_of_remove_table()
tty: serial: qcom_geni_serial: Unconditionally call
dev_pm_opp_of_remove_table()
qcom-geni-se: remove has_opp_table
drivers/cpufreq/imx6q-cpufreq.c | 10 ++--------
drivers/gpu/drm/lima/lima_devfreq.c | 6 +-----
drivers/gpu/drm/lima/lima_devfreq.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 14 +++++---------
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
drivers/gpu/drm/msm/dsi/dsi_host.c | 8 ++------
drivers/mmc/host/sdhci-msm.c | 14 +++++---------
drivers/spi/spi-geni-qcom.c | 13 +++++--------
drivers/spi/spi-qcom-qspi.c | 15 ++++++---------
drivers/tty/serial/qcom_geni_serial.c | 13 +++++--------
include/linux/qcom-geni-se.h | 2 --
11 files changed, 31 insertions(+), 66 deletions(-)
base-commit: 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5
--
2.25.0.rc1.19.g042ed3e048af
^ permalink raw reply
* Re: [PATCH] mmc: sdhci-msm: When dev_pm_opp_of_add_table() returns 0 it's not an error
From: Viresh Kumar @ 2020-08-28 5:09 UTC (permalink / raw)
To: Douglas Anderson
Cc: Ulf Hansson, arnd, naresh.kamboju, vbadigan, rnayak,
Adrian Hunter, Andy Gross, Bjorn Andersson, linux-arm-msm,
linux-kernel, linux-mmc
In-Reply-To: <20200827083330.1.I669bb4dc3d92bd04e9a695f97904797dc8241b79@changeid>
On 27-08-20, 08:33, Douglas Anderson wrote:
> The commit d05a7238fe1c ("mmc: sdhci-msm: Unconditionally call
> dev_pm_opp_of_remove_table()") works fine in the case where there is
> no OPP table. However, if there is an OPP table then
> dev_pm_opp_of_add_table() will return 0. Since 0 != -ENODEV then the
> "if (ret != -ENODEV)" will evaluate to true and we'll fall into the
> error case. Oops.
>
> Let's fix this.
>
> Fixes: d05a7238fe1c ("mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> drivers/mmc/host/sdhci-msm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index b7e47107a31a..55101dba42bd 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -2284,7 +2284,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
>
> /* OPP table is optional */
> ret = dev_pm_opp_of_add_table(&pdev->dev);
> - if (ret != -ENODEV) {
> + if (ret && ret != -ENODEV) {
> dev_err(&pdev->dev, "Invalid OPP table in Device tree\n");
> goto opp_cleanup;
> }
Wow!
How many bugs did I introduce with a simple patch :(
@Ulf, since this is material for 5.10 I was planning to resend the
original patch itself with all the things fixed. Will you be able to
rebase your tree? Or do you want to apply fixes separately ?
--
viresh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox