2013/11/14 Tomasz Figa tomasz.figa@gmail.com:
On Thursday 14 of November 2013 08:12:46 Florian Meier wrote:
On 13.11.2013 21:39, Tomasz Figa wrote:
On Wednesday 13 of November 2013 20:35:22 Florian Meier wrote:
+- brcm,dma-channel-mask: Bit mask representing the channels available.
What does the value of this property depend on? Could you describe the structure of this DMA controller?
+Example:
+dma: dma@7e007000 {
compatible = "brcm,bcm2835-dma";reg = <0x7e007000 0xf00>;interrupts = <1 161 171 181 191 201 211 221 231 241 251 261 271 28>;There are 13 interrupts specified here, but...
#dma-cells = <1>;dma-channels = <16>;...16 channels here...
dma-requests = <32>;brcm,dma-channel-mask = <0x7f35>;...and 11 set bits here. May I ask you to explain this to me, please?
How I understand this DMA controller: There are 16 DMA channels in the DMA controller, but only 13 interrupts are available at the IRQ controller. Therefore, the upper DMA channels can just not be used. Maybe because there are to many other IRQs and they didn't want to implement another IRQ bank. Furthermore, some of the DMA channels are already used by the VideoCore/GPU/firmware. This is what dma-channel-mask indicates. This should be automatically set by the firmware in the future. Finally, there are some channels with special functionality that should not be used by DMA engine, too. Therefore, these lines: /* do not use the FIQ and BULK channels */ chans_available &= ~0xD;
OK, this makes it much more clear.
So, my only comment remaining here is that you shouldn't include the channels without interrupt signal in the mask. This would allow you to define it as a mask of channels that are operable and then just iterate over all set bits in the driver, instead of using tricks with interrupt resources. What do you think?
Since the mask will come directly from the firmware, this would require patching the firmware. I think that is not worth the effort.
Now I'm slightly confused. Do you already have code in your firmware that adds this property to your device tree?
Otherwise in what circumstances such patching would take place? On given hardware (unless it's an FPGA) the configuration of available DMA channels that have interrupt signals should not change.
It is very confusing. I agree. There is already a DMA driver with a proprietary API in the downstream kernel. The firmware already creates this mask and passes it to this proprietary driver. There was already a discussion about this in the first version thread that (as long as I understand it) resulted in "we should pass this mask on to the driver via device tree". So I did that. I have no idea about how this firmware->devicetree interface will take place, but since I didn't want to run in circles I hardcoded it in the device tree.
[snip]
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c new file mode 100644 index 0000000..baf072e --- /dev/null +++ b/drivers/dma/bcm2835-dma.c
[snip]
+static int bcm2835_dma_probe(struct platform_device *pdev) +{
struct bcm2835_dmadev *od;struct resource *dma_res = NULL;void __iomem *dma_base = NULL;int rc = 0;int i = 0;int irq;uint32_t chans_available;[snip]
if (pdev->dev.of_node) {Is this driver supposed to support non-DT based instantation (aka board files)? If not, maybe it would be cleaner to simply check for !pdev->dev.of_node at the beginning of probe and return an error?
I would like to maintain the possibility for board file based instatiation, because the Raspberry Pi downstream kernel still doesn't support device tree. If this is a no-go, I will accept that.
Sure, you are free to do so.
What I meant is that your probe won't call bcm2835_dma_chan_init() at all if there is no pdev->dev.of_node, because the loop iterating over channels is under the if clause.
Yes you are right, but I think it will make the patching easier, later. Currently, nothing bad happens without device tree - it just allocates no channels.
But isn't it really an error condition, if no channels are allocated?
A fridge is still a working fridge, even if no beer is inside ;-) Ok, bad example, but you will get an error message anyway when you try to get a channel.
Anyway, back to my point about leaving non-DT support in a driver, the point is still valid only for drivers, not for platforms/boards. So if there are no boards supported using board files in mainline that could benefit from this driver, then this driver can be safely made DT-only, because no new non-DT platforms/boards can be added.
I don't have a telling argument against this, but just thought writing it this way will make the migration of the downstream kernel to upstream easier, but if you say I should change it, I will of course do that. I am becoming desperate anyway that this migration will ever fully take place....
Greetings, Florian