mbox series

[GIT,PULL] i.MX fixes for 4.19, round 2

Message ID 20181001023923.GQ26692@dragon
State New
Headers show
Series [GIT,PULL] i.MX fixes for 4.19, round 2 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.19-2

Message

Shawn Guo Oct. 1, 2018, 2:39 a.m. UTC
The following changes since commit 57361846b52bc686112da6ca5368d11210796804:

  Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.19-2

for you to fetch changes up to 4d8d4712e47c028306149bda04b79f70325aefb0:

  soc: imx: gpc: set DMA mask for PD platform devices (2018-09-26 10:38:38 +0800)

----------------------------------------------------------------
i.MX fixes for 4.19, round 2:
 - There appears an uninitialized DMA mask warning on i.MX GPC driver
   with 4.19-rc kernel.  Set the DMA mask for powerdomain platform
   device to fix the warning given by device core.
 - i.MX53 QSB board stops working when cpufreq driver is enabled,
   because the default OPP table has the maximum CPU frequency at
   1.2GHz, while the board is only capable of running 1GHz.  Fix up
   the OPP table for the board to get it work with cpufreq driver.

----------------------------------------------------------------
Lucas Stach (1):
      soc: imx: gpc: set DMA mask for PD platform devices

Sascha Hauer (1):
      ARM: dts: imx53-qsb: disable 1.2GHz OPP

 arch/arm/boot/dts/imx53-qsb-common.dtsi | 11 +++++++++++
 drivers/soc/imx/gpc.c                   |  1 +
 2 files changed, 12 insertions(+)

Comments

Arnd Bergmann Oct. 2, 2018, 9:59 a.m. UTC | #1
On Mon, Oct 1, 2018 at 4:39 AM Shawn Guo <shawnguo@kernel.org> wrote:
>
> The following changes since commit 57361846b52bc686112da6ca5368d11210796804:
>
>   Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.19-2
>
> for you to fetch changes up to 4d8d4712e47c028306149bda04b79f70325aefb0:
>
>   soc: imx: gpc: set DMA mask for PD platform devices (2018-09-26 10:38:38 +0800)
>
> ----------------------------------------------------------------
> i.MX fixes for 4.19, round 2:
>  - There appears an uninitialized DMA mask warning on i.MX GPC driver
>    with 4.19-rc kernel.  Set the DMA mask for powerdomain platform
>    device to fix the warning given by device core.

I don't think this is the right fix, we should generally not just make up a dma
mask pointer.

Lucas, do you have any more information regarding that warning?
Are we trying to do DMA on a virtual device? What operation
causes that warning?

      Arnd
Lucas Stach Oct. 2, 2018, 11:42 a.m. UTC | #2
Hi Arnd,

Am Dienstag, den 02.10.2018, 11:59 +0200 schrieb Arnd Bergmann:
> On Mon, Oct 1, 2018 at 4:39 AM Shawn Guo <shawnguo@kernel.org> wrote:
> > 
> > The following changes since commit
> > 57361846b52bc686112da6ca5368d11210796804:
> > 
> >   Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
> > tags/imx-fixes-4.19-2
> > 
> > for you to fetch changes up to
> > 4d8d4712e47c028306149bda04b79f70325aefb0:
> > 
> >   soc: imx: gpc: set DMA mask for PD platform devices (2018-09-26
> > 10:38:38 +0800)
> > 
> > ----------------------------------------------------------------
> > i.MX fixes for 4.19, round 2:
> >  - There appears an uninitialized DMA mask warning on i.MX GPC
> > driver
> >    with 4.19-rc kernel.  Set the DMA mask for powerdomain platform
> >    device to fix the warning given by device core.
> 
> I don't think this is the right fix, we should generally not just
> make up a dma
> mask pointer.
> 
> Lucas, do you have any more information regarding that warning?
> Are we trying to do DMA on a virtual device? What operation
> causes that warning?

The warning we are silencing here is generated by of_dma_configure() if
the dma_mask is not set, which gets called for all devices with a OF
node, regardless if the device is actually DMA capable.
As the platform bus code calls this function with force_dma = true, the
absent dma-ranges won't stop this function from trying to set up the
dma stuff, so I don't really see another clean way to get rid of this
warning.

Regards,
Lucas
Arnd Bergmann Oct. 2, 2018, 12:09 p.m. UTC | #3
On Tue, Oct 2, 2018 at 1:42 PM Lucas Stach <l.stach@pengutronix.de> wrote:
> Am Dienstag, den 02.10.2018, 11:59 +0200 schrieb Arnd Bergmann:
> > On Mon, Oct 1, 2018 at 4:39 AM Shawn Guo <shawnguo@kernel.org> wrote:
> > >
> > > The following changes since commit
> > > 57361846b52bc686112da6ca5368d11210796804:
> > >
> > >   Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
> > >
> > > are available in the git repository at:
> > >
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
> > > tags/imx-fixes-4.19-2
> > >
> > > for you to fetch changes up to
> > > 4d8d4712e47c028306149bda04b79f70325aefb0:
> > >
> > >   soc: imx: gpc: set DMA mask for PD platform devices (2018-09-26
> > > 10:38:38 +0800)
> > >
> > > ----------------------------------------------------------------
> > > i.MX fixes for 4.19, round 2:
> > >  - There appears an uninitialized DMA mask warning on i.MX GPC
> > > driver
> > >    with 4.19-rc kernel.  Set the DMA mask for powerdomain platform
> > >    device to fix the warning given by device core.
> >
> > I don't think this is the right fix, we should generally not just
> > make up a dma
> > mask pointer.
> >
> > Lucas, do you have any more information regarding that warning?
> > Are we trying to do DMA on a virtual device? What operation
> > causes that warning?
>
> The warning we are silencing here is generated by of_dma_configure() if
> the dma_mask is not set, which gets called for all devices with a OF
> node, regardless if the device is actually DMA capable.
> As the platform bus code calls this function with force_dma = true, the
> absent dma-ranges won't stop this function from trying to set up the
> dma stuff, so I don't really see another clean way to get rid of this
> warning.

Ok, I see. So I think the warning is wrong here, and your change
actually makes it worse, because we really /don't/ want to do DMA
on this node.

>From what I can tell, the change that introduced this behavior
was commit 09515ef5ddad ("of/acpi: Configure dma operations at
probe time for platform/amba/pci bus devices") in 4.12.

Before that, we did not try to call of_dma_configure() on a manually
added device, which I think was the correct behavior. Does that
correspond to what you are seeing?

For the moment, I'd prefer to hold off on this patch, until we have
resolved what the best fix is going to be. Since there is no DMA
on the device, the behavior will be correct, aside from the
annoying warning.

Shawn, should I cherry-pick the other fix, or do you want to
follow up with a new pull request for the fixes?

      Arnd
Shawn Guo Oct. 3, 2018, 2:48 a.m. UTC | #4
On Tue, Oct 02, 2018 at 02:09:10PM +0200, Arnd Bergmann wrote:
> Shawn, should I cherry-pick the other fix, or do you want to
> follow up with a new pull request for the fixes?

Arnd, I just updated the pull request with the patch in question dropped.

Shawn


The following changes since commit 57361846b52bc686112da6ca5368d11210796804:

  Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.19-2

for you to fetch changes up to eea96566c189c77e5272585984eb2729881a2f1d:

  ARM: dts: imx53-qsb: disable 1.2GHz OPP (2018-09-12 14:44:33 +0800)

----------------------------------------------------------------
i.MX fixes for 4.19, round 2:
 - i.MX53 QSB board stops working when cpufreq driver is enabled,
   because the default OPP table has the maximum CPU frequency at
   1.2GHz, while the board is only capable of running 1GHz.  Fix up
   the OPP table for the board to get it work with cpufreq driver.

----------------------------------------------------------------
Sascha Hauer (1):
      ARM: dts: imx53-qsb: disable 1.2GHz OPP

 arch/arm/boot/dts/imx53-qsb-common.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)
Arnd Bergmann Oct. 4, 2018, 3:34 p.m. UTC | #5
On Wed, Oct 3, 2018 at 4:48 AM Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Tue, Oct 02, 2018 at 02:09:10PM +0200, Arnd Bergmann wrote:
> > Shawn, should I cherry-pick the other fix, or do you want to
> > follow up with a new pull request for the fixes?
>

> ----------------------------------------------------------------
> i.MX fixes for 4.19, round 2:
>  - i.MX53 QSB board stops working when cpufreq driver is enabled,
>    because the default OPP table has the maximum CPU frequency at
>    1.2GHz, while the board is only capable of running 1GHz.  Fix up
>    the OPP table for the board to get it work with cpufreq driver.
>
Pulled into fixes, thanks for respinning this!

      Arnd
Lucas Stach Dec. 17, 2018, 4:42 p.m. UTC | #6
Hi Arnd,

Am Dienstag, den 02.10.2018, 14:09 +0200 schrieb Arnd Bergmann:
> On Tue, Oct 2, 2018 at 1:42 PM Lucas Stach <l.stach@pengutronix.de>
> wrote:
> > Am Dienstag, den 02.10.2018, 11:59 +0200 schrieb Arnd Bergmann:
> > > On Mon, Oct 1, 2018 at 4:39 AM Shawn Guo <shawnguo@kernel.org>
> > > wrote:
> > > > 
> > > > The following changes since commit
> > > > 57361846b52bc686112da6ca5368d11210796804:
> > > > 
> > > >   Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)
> > > > 
> > > > are available in the git repository at:
> > > > 
> > > >  
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.gi
> > > > t
> > > > tags/imx-fixes-4.19-2
> > > > 
> > > > for you to fetch changes up to
> > > > 4d8d4712e47c028306149bda04b79f70325aefb0:
> > > > 
> > > >   soc: imx: gpc: set DMA mask for PD platform devices (2018-09-
> > > > 26
> > > > 10:38:38 +0800)
> > > > 
> > > > -------------------------------------------------------------
> > > > ---
> > > > i.MX fixes for 4.19, round 2:
> > > >  - There appears an uninitialized DMA mask warning on i.MX GPC
> > > > driver
> > > >    with 4.19-rc kernel.  Set the DMA mask for powerdomain
> > > > platform
> > > >    device to fix the warning given by device core.
> > > 
> > > I don't think this is the right fix, we should generally not just
> > > make up a dma
> > > mask pointer.
> > > 
> > > Lucas, do you have any more information regarding that warning?
> > > Are we trying to do DMA on a virtual device? What operation
> > > causes that warning?
> > 
> > The warning we are silencing here is generated by
> > of_dma_configure() if
> > the dma_mask is not set, which gets called for all devices with a
> > OF
> > node, regardless if the device is actually DMA capable.
> > As the platform bus code calls this function with force_dma = true,
> > the
> > absent dma-ranges won't stop this function from trying to set up
> > the
> > dma stuff, so I don't really see another clean way to get rid of
> > this
> > warning.
> 
> Ok, I see. So I think the warning is wrong here, and your change
> actually makes it worse, because we really /don't/ want to do DMA
> on this node.
> 
> From what I can tell, the change that introduced this behavior
> was commit 09515ef5ddad ("of/acpi: Configure dma operations at
> probe time for platform/amba/pci bus devices") in 4.12.
> 
> Before that, we did not try to call of_dma_configure() on a manually
> added device, which I think was the correct behavior. Does that
> correspond to what you are seeing?
> 
> For the moment, I'd prefer to hold off on this patch, until we have
> resolved what the best fix is going to be. Since there is no DMA
> on the device, the behavior will be correct, aside from the
> annoying warning.

Do you have an idea how to better fix this? The warning is annoying
(especially for people that aren't aware that this device doesn't need
any DMA setup).

I don't really see how we could fix this without regressing
functionality for other drivers. Thoughts?

Regards,
Lucas