[PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
segher at kernel.crashing.org
Thu Jul 12 04:01:54 EST 2007
>>> Some hardware has DMA channels hardwired to certain peripherals,
>>> such as
>>> an audio codec. This keeps them from being used as general
>>> purpose DMA
>> I think you need this knowledge in the kernel drivers anyway,
>> or at the very least, the device node for for example that
>> audio codec needs to refer to the DMA channel in the device
>> tree, so this "reserved" property is unnecessary.
> The generic DMA driver needs to know not to touch the reserved
The generic DMA driver can look at the device tree, too. It's
more convenient to only have to look at the dma-controller node,
true. But with the proposed tree you have to look at all the
channel nodes already.
>>> I'd rather just treat the different DMA channels as independent
>>> rather than children of a dma "bus", and change the compatible
>>> name if
>>> they're not general purpose. There's only one register that's
>>> among the channels, and it's a superfluous status summary register.
>> If you make separate nodes for the channels, they need to have
>> a parent. I don't think it makes sense to have the channel
>> nodes and the "master" node as siblings -- maybe it all should
>> be just one node with a "#channels" property or such?
> I don't see the need for a master node -- there are no shared
> registers (other than a redundant read-only status summary
> register) to synchronize access to. Each channel would be an
> independent device under the SoC bus.
The "master" node is needed to describe its register block. It
doesn't matter whether you want to use those registers currently
> The benefit is that if a channel needs to be driven by (for
> example) a sound driver, it can have a different compatible that
> will be matched by the sound driver,
Nah, the sound node should just point to the channel node, or
point to the DMA controller and describe the channel # some
other way. There is no need to make a special "sound DMA
channel" device name.
> and the generic DMA driver will never see it unless the sound
> driver explicitly chooses to make use of the generic DMA code --
> and most of the time I think it'd be simpler for the special-
> purpose driver to manage the descriptors itself.
Sure. But you yourself already say "most of the time" -- and
the device tree doesn't describe how the kernel uses the hardware,
it simply describes the hardware itself. The sound DMA channel
is part of the DMA controller, it is only _connected_ to the
sound controller, it shouldn't be described as being more closely
connected to the sound stuff than it actually is.
More information about the Linuxppc-dev