From: Arnd Bergmann <arnd@arndb.de>
To: Peter Chen <hzpeterchen@gmail.com>
Cc: Li Yang <leoli@freescale.com>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Peter Chen <Peter.Chen@nxp.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rajesh Bhagat <rajesh.bhagat@nxp.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT
Date: Fri, 18 Mar 2016 08:28:26 +0100 [thread overview]
Message-ID: <3761533.8BImebjOQF@wuerfel> (raw)
In-Reply-To: <20160318015414.GA30851@shlinux2.ap.freescale.net>
On Friday 18 March 2016 09:54:14 Peter Chen wrote:
> >
> > I don't think it's a very widespread problem, there are only very few
> > developers that intentionally use this method, and some use the
> > platform_device_register_full() call to create a device with a known
> > mask, which is generally ok for the limited case where the driver
> > is only ever going to run on a single platform, but not in the
> > more general case that of_dma_configure is designed to handle.
>
> Even only for qualcomm platforms, it may be possible have different
> DMA masks at ARM64 platforms, so we may can't use a fixed value
> at glue layer driver. So, using of_dma_configure is suitable choice
> for DT platforms for this case, right?
Yes.
> > I think we should fix the drivers to consistently use the device
> > that was created by the platform (DT or ACPI or board file)
> > to pass that into the DMA API, anything else will just cause
> > more subtle bugs.
> >
>
> Although I don't know what kinds of bugs it may have, it may be
> met before, otherwise, why most of platform drivers need to call
> dma_set_coherent_mask or dma_coerce_mask_and_coherent explicitly
Any driver that wants to do 64-bit addressing on DMA should call
dma_set_mask()/dma_set_coherent_mask() on its device and check the
return code.
No driver should call dma_coerce_mask_and_coherent() on its own
device, it's basically always a bug and we named the function
to make that more obvious. The problem with dma_coerce_mask_and_coherent()
is that it just overrides whatever the platform knows about the
device when the driver thinks it knows better.
The reason for having those calls in a lot of drivers is that
traditionally, ARM platforms booting with DT did not set up any DMA
mask and the drivers worked around it by manually setting up a mask
that happened to work for them (almost all 32-bit ARM devices need
a 32-bit mask without coherency or offset or iommu, so that's easy).
We now call of_dma_configure() for all devices that get probed from
DT, so we should be removing those calls.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] usb: chipidea: Configure DMA properties and ops from DT
Date: Fri, 18 Mar 2016 08:28:26 +0100 [thread overview]
Message-ID: <3761533.8BImebjOQF@wuerfel> (raw)
In-Reply-To: <20160318015414.GA30851@shlinux2.ap.freescale.net>
On Friday 18 March 2016 09:54:14 Peter Chen wrote:
> >
> > I don't think it's a very widespread problem, there are only very few
> > developers that intentionally use this method, and some use the
> > platform_device_register_full() call to create a device with a known
> > mask, which is generally ok for the limited case where the driver
> > is only ever going to run on a single platform, but not in the
> > more general case that of_dma_configure is designed to handle.
>
> Even only for qualcomm platforms, it may be possible have different
> DMA masks at ARM64 platforms, so we may can't use a fixed value
> at glue layer driver. So, using of_dma_configure is suitable choice
> for DT platforms for this case, right?
Yes.
> > I think we should fix the drivers to consistently use the device
> > that was created by the platform (DT or ACPI or board file)
> > to pass that into the DMA API, anything else will just cause
> > more subtle bugs.
> >
>
> Although I don't know what kinds of bugs it may have, it may be
> met before, otherwise, why most of platform drivers need to call
> dma_set_coherent_mask or dma_coerce_mask_and_coherent explicitly
Any driver that wants to do 64-bit addressing on DMA should call
dma_set_mask()/dma_set_coherent_mask() on its device and check the
return code.
No driver should call dma_coerce_mask_and_coherent() on its own
device, it's basically always a bug and we named the function
to make that more obvious. The problem with dma_coerce_mask_and_coherent()
is that it just overrides whatever the platform knows about the
device when the driver thinks it knows better.
The reason for having those calls in a lot of drivers is that
traditionally, ARM platforms booting with DT did not set up any DMA
mask and the drivers worked around it by manually setting up a mask
that happened to work for them (almost all 32-bit ARM devices need
a 32-bit mask without coherency or offset or iommu, so that's easy).
We now call of_dma_configure() for all devices that get probed from
DT, so we should be removing those calls.
Arnd
next prev parent reply other threads:[~2016-03-18 7:29 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 5:32 [PATCH] usb: chipidea: Configure DMA properties and ops from DT Bjorn Andersson
2016-02-22 6:02 ` Peter Chen
2016-02-22 6:14 ` Bjorn Andersson
2016-02-22 10:03 ` Srinivas Kandagatla
2016-02-22 22:07 ` Bjorn Andersson
2016-02-23 1:31 ` Peter Chen
2016-03-02 22:59 ` Li Yang
2016-03-08 19:52 ` Li Yang
2016-03-08 19:52 ` Li Yang
2016-03-08 19:52 ` Li Yang
2016-03-09 3:40 ` Bjorn Andersson
2016-03-09 3:40 ` Bjorn Andersson
2016-03-09 23:16 ` Li Yang
2016-03-09 23:16 ` Li Yang
2016-03-09 23:16 ` Li Yang
2016-03-14 10:51 ` Peter Chen
2016-03-14 10:51 ` Peter Chen
2016-03-17 15:52 ` Arnd Bergmann
2016-03-17 15:52 ` Arnd Bergmann
2016-03-18 1:54 ` Peter Chen
2016-03-18 1:54 ` Peter Chen
2016-03-18 3:25 ` Rajesh Bhagat
2016-03-18 3:25 ` Rajesh Bhagat
2016-03-18 3:25 ` Rajesh Bhagat
2016-03-18 7:28 ` Arnd Bergmann [this message]
2016-03-18 7:28 ` Arnd Bergmann
2016-03-18 10:56 ` Russell King - ARM Linux
2016-03-18 10:56 ` Russell King - ARM Linux
2016-03-25 4:02 ` Peter Chen
2016-03-25 4:02 ` Peter Chen
2016-03-25 4:39 ` [PATCH 1/1] usb: chipidea: add DMA mask configuration API kbuild test robot
2016-03-25 4:39 ` kbuild test robot
2016-03-25 4:39 ` kbuild test robot
2016-10-21 16:59 ` [RESEND PATCH] usb: chipidea: Configure DMA properties and ops from DT Bjorn Andersson
[not found] ` <1477069159-12399-1-git-send-email-bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-10-21 17:38 ` Stephen Boyd
2016-10-21 17:38 ` Stephen Boyd
[not found] ` <20161021173827.GJ26139-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-10-21 17:53 ` Bjorn Andersson
2016-10-21 17:53 ` Bjorn Andersson
2016-10-22 6:22 ` Sriram Dash
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3761533.8BImebjOQF@wuerfel \
--to=arnd@arndb.de \
--cc=Peter.Chen@nxp.com \
--cc=bjorn.andersson@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=hzpeterchen@gmail.com \
--cc=leoli@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rajesh.bhagat@nxp.com \
--cc=srinivas.kandagatla@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.