On Saturday 15 September 2012, Russell King - ARM Linux wrote:
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
quoted
3. Supporting legacy devices not using DMA Engine
These devices present a problem, as there may not be a uniform way to easily
support them with regard to device tree. Ideally, these should be migrated
to DMA engine. However, if this is not possible, then they should still be
able to use this binding, the only constaint imposed by this implementation
is that when requesting a DMA channel via of_dma_request_slave_channel(), it
will return a type of dma_chan.
As far as devices not using DMA engine, the answer is we don't support
their specification in the DT model. Note that the legacy OMAP DMA
API is scheduled for removal next year, so it's not going to be around
that much longer.
There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge),
and I agree that they are unlikely to see OF support, although if they did, it
wouldn't be unreasonable to encode their DMA channels using the same binding.
The other ones that are currently around with their own DMA implementation are
bcmring --> platform is going away
samsung --> gradually getting moved to dmaengine, already has its own binding
that needs to be replaced with this one, so best do it at the same
time.
tegra --> old dma code gone in 3.7
pxa/mmp --> dmaengine implementation being worked on, should wait for that.
msm --> dma implementation only used by two drivers (serial and mmc).
Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their
own dma APIs based on the ISA interfaces. I don't currently see any of them
moving towards DT, but it's definitely possible.
Among the above MSM seems to be the most likely candidate to use the binding
before moving to DT. The msm_sdcc driver is (like much of the msm platform
code) lagging far behind the internel version that qualcomm have, and the
device tree binding they are using is incompatible with the common MMC
binding (and of course the DMA binding here) as well. For getting MSM up
to speed compared with the other platforms, they have to use proper DT
bindings as well as proper DMA engine support. Between those two, I'd prefer
fixing the DT binding first, in order to limit the amount of changes that
have to be done to external device tree files.
Arnd
On 9/18/2012 4:42 AM, Arnd Bergmann wrote:
On Saturday 15 September 2012, Russell King - ARM Linux wrote:
quoted
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
quoted
3. Supporting legacy devices not using DMA Engine
These devices present a problem, as there may not be a uniform way to easily
support them with regard to device tree. Ideally, these should be migrated
to DMA engine. However, if this is not possible, then they should still be
able to use this binding, the only constaint imposed by this implementation
is that when requesting a DMA channel via of_dma_request_slave_channel(), it
will return a type of dma_chan.
As far as devices not using DMA engine, the answer is we don't support
their specification in the DT model. Note that the legacy OMAP DMA
API is scheduled for removal next year, so it's not going to be around
that much longer.
There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge),
and I agree that they are unlikely to see OF support,
(Warning - historical rambling follows)
There is a delicious irony here with respect to Shark. Shark has real
Open Firmware. It's the platform that I used for the first OFW port to
ARM. We (the Shark design team) had a version of NetBSD that would run
on Shark without any native drivers, calling into the Open Firmware
drivers. It was very useful for bringup.
I wonder when was the last time anyone turned on a Shark? I ran my mail
server on one until 8 years ago, when the incoming spam load began to
saturate the 10 Mbit Ethernet. Shark had decent computational power,
but the I/O system, built around a low cost PC I/O chip, didn't have
much bandwidth.
Also in that time frame (early 2000s), some of us Shark designers
managed to grab a pile of Sharks that HP was going to scrap. (HP had
inherited them as part of Compaq, who had acquired them as part of
Digital.) We used them as production unit testers for a consumer gadget
that we were building. But, alas, even that usage fell to the wayside.
I redesigned the tester around an ATSAM7 chip and put the entire test
setup into a tiny box. I still have a couple of Sharks, but they
haven't been turned on for at least 6 years.
Is there ever a point when old architectures leave the Linux tree, or
will people have to see grep hits from them until the end of time?
although if they did, it
wouldn't be unreasonable to encode their DMA channels using the same binding.
The other ones that are currently around with their own DMA implementation are
bcmring --> platform is going away
samsung --> gradually getting moved to dmaengine, already has its own binding
that needs to be replaced with this one, so best do it at the same
time.
tegra --> old dma code gone in 3.7
pxa/mmp --> dmaengine implementation being worked on, should wait for that.
msm --> dma implementation only used by two drivers (serial and mmc).
Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their
own dma APIs based on the ISA interfaces. I don't currently see any of them
moving towards DT, but it's definitely possible.
Among the above MSM seems to be the most likely candidate to use the binding
before moving to DT. The msm_sdcc driver is (like much of the msm platform
code) lagging far behind the internel version that qualcomm have, and the
device tree binding they are using is incompatible with the common MMC
binding (and of course the DMA binding here) as well. For getting MSM up
to speed compared with the other platforms, they have to use proper DT
bindings as well as proper DMA engine support. Between those two, I'd prefer
fixing the DT binding first, in order to limit the amount of changes that
have to be done to external device tree files.
Arnd
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss at lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Tuesday 18 September 2012, Mitch Bradley wrote:
There is a delicious irony here with respect to Shark. Shark has real
Open Firmware. It's the platform that I used for the first OFW port to
ARM. We (the Shark design team) had a version of NetBSD that would run
on Shark without any native drivers, calling into the Open Firmware
drivers. It was very useful for bringup.
Very interesting, thanks for sharing this bit of history. Are you aware
of other ARM systems using open firmware that we still support in Linux
(besides the XO-1.75)?
Is there ever a point when old architectures leave the Linux tree, or
will people have to see grep hits from them until the end of time?
As long as someone is interested in keeping an architecture or driver
alive, it stays. If something is causing problems and we have reason
to assume it will never be used again with current kernels, we toss
them out. Russell has recently removed support for ARMv3 CPUs, but
some of the StrongARM targets (especially SA-1100) are still being
actively used, so the CPU support is not going away any time soon.
If you have a bunch of Shark machines for testing and would like to
port it over to device tree passing from its open firmware, you are
definitely welcome ;-)
Arnd