dmaengine: Add support for BCM2835
Subsystems (4)
PATCH v4 1/1 dmaengine: Add support for BCM2835
Add support for DMA controller of BCM2835 as used in the Raspberry Pi. Currently it only supports cyclic DMA.
---
Besides of many minor improvements (thanks to your helpful comments), this fourth version does the assignment of the virtual to the hardware channel already in probe. This simplifies things a lot (first of all the complex alloc_chan_resources is now gone).
Regarding the maximum segment size: 0x3FFFFFFF is the maximum possible DMA transfer length value and I have no evidence that the maximum segment size is smaller.
.../devicetree/bindings/dma/bcm2835-dma.txt | 59 ++ drivers/dma/Kconfig | 6 + drivers/dma/Makefile | 1 + drivers/dma/bcm2835-dma.c | 750 ++++++++++++++++++++ 4 files changed, 816 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/bcm2835-dma.txt create mode 100644 drivers/dma/bcm2835-dma.c
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +59 -0
@@ -0,0 +1,59 @@ +* BCM2835 DMA controller + +Required properties: +- compatible: Should be "brcm,bcm2835-dma". +- reg: Should contain DMA registers location and length. +- interrupts: Should contain the DMA interrupts associated + to the DMA channels in ascending order. + First cell is the IRQ bank. + Second cell is the IRQ number. +- #dma-cells: Must be <1>, used to represent the number of integer cells in + the dmas property of client devices. +- dma-channels: Maximum number of DMA channels available. +- dma-requests: Number of DMA Requests. +- brcm,dma-channel-mask: Bit mask representing the channels available. + +Example: + +dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16 + 1 17 + 1 18 + 1 19 + 1 20 + 1 21 + 1 22 + 1 23 + 1 24 + 1 25 + 1 26 + 1 27 + 1 28>; + + #dma-cells = <1>; + dma-channels = <16>; + dma-requests = <32>; + brcm,dma-channel-mask = <0x7f35>; +}; + +DMA clients connected to the BCM2835 DMA controller must use the format +described in the dma.txt file, using a two-cell specifier for each channel: +a phandle plus one integer cells. +The two cells in order are: + +1. A phandle pointing to the DMA controller. +2. The DREQ number. + +Example: + +bcm2835_i2s: i2s@7e203000 { + compatible = "brcm,bcm2835-i2s"; + reg = < 0x7e203000 0x20 + 0x7e101098 0x02>; + + dmas = <&dma 2 + &dma 3>; + dma-names = "tx", "rx"; +};
drivers/dma/Kconfig +6 -0
@@ -300,6 +300,12 @@ config DMA_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS +config DMA_BCM2835 + tristate "BCM2835 DMA engine support" + depends on (ARCH_BCM2835 || MACH_BCM2708) + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + config TI_CPPI41 tristate "AM33xx CPPI41 DMA support" depends on ARCH_OMAP
drivers/dma/Makefile +1 -0
@@ -38,6 +38,7 @@ obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o obj-$(CONFIG_DMA_SA11X0) += sa11x0-dma.o obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o obj-$(CONFIG_DMA_OMAP) += omap-dma.o +obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o obj-$(CONFIG_TI_CPPI41) += cppi41.o
drivers/dma/bcm2835-dma.c new file +750 -0
750 lines not on this page · raw message
Signature · 5 lines
1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Florian,
Seems like I accidentally replied to some old version of this patch. Not sure how many of those comments were still relevant for V3, but let me look at this version and see whether we can still improve things a bit. Please see my comments inline.
Quoted 32 lines · On Wednesday 13 of November 2013 18:53:23 Florian Meier wrote:
Add support for DMA controller of BCM2835 as used in the Raspberry Pi. Currently it only supports cyclic DMA.
Signed-off-by Florian Meier <florian.meier-oZ8rN/[email protected]>---
Besides of many minor improvements (thanks to your helpful comments), this fourth version does the assignment of the virtual to the hardware channel already in probe. This simplifies things a lot (first of all the complex
alloc_chan_resourcesis now gone).Regarding the maximum segment size:
0x3FFFFFFFis the maximum possible DMA transfer length value and I have no evidence that the maximum segment size is smaller..../devicetree/bindings/dma/bcm2835-dma.txt | 59 ++ drivers/dma/Kconfig | 6 + drivers/dma/Makefile | 1 + drivers/dma/bcm2835-dma.c | 750 ++++++++++++++++++++ 4 files changed, 816 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/bcm2835-dma.txt create mode 100644 drivers/dma/bcm2835-dma.cDocumentation/devicetree/bindings/dma/bcm2835-dma.txt new file +3
-0@@ -0,0 +1,59 @@ +* BCM2835 DMA controller + +Required properties:
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 13
Quoted 10 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +10
-0+- compatible: Should be "brcm,bcm2835-dma". +- reg: Should contain DMA registers location and length. +- interrupts: Should contain the DMA interrupts associated + to the DMA channels in ascending order. + First cell is the IRQ bank. + Second cell is the IRQ number. +- #dma-cells: Must be <1>, used to represent the number of integer cells in + the dmas property of client devices. +- dma-channels: Maximum number of DMA channels available. +- dma-requests: Number of DMA Requests.
The two properties above do not seem to be used anywhere in the driver.
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 14
Quoted 1 line
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +1
-0+- 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?
Quoted 9 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +9
-0+ +Example: + +dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16 + 1 17 + 1 18
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 33
Quoted 10 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +10
-0+ 1 19 + 1 20 + 1 21 + 1 22 + 1 23 + 1 24 + 1 25 + 1 26 + 1 27 + 1 28>;
There are 13 interrupts specified here, but...
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 36
Quoted 3 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +3
-0+ + #dma-cells = <1>; + dma-channels = <16>;
...16 channels here...
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 38
Quoted 2 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +2
-0+ dma-requests = <32>; + brcm,dma-channel-mask = <0x7f35>;
...and 11 set bits here. May I ask you to explain this to me, please?
[snip]
Quoted 5 lines
drivers/dma/bcm2835-dma.c new file +0
-0
[snip]
Quoted 9 lines
drivers/dma/bcm2835-dma.c new file +9
-0+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]
drivers/dma/bcm2835-dma.c line 666
Quoted 1 line
drivers/dma/bcm2835-dma.c new file +1
-0+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?
Quoted 14 lines
drivers/dma/bcm2835-dma.c new file +14
-0+const void *chan_mask; + +/* Device-tree DMA controller registration */ + rc =of_dma_controller_register (pdev->dev.of_node, + bcm2835_dma_xlate, od); +if (rc) { +dev_err (&pdev->dev,"Failed to register DMA controller\n" ); +dma_async_device_unregister (&od->ddev); +bcm2835_dma_free (od); +return rc; + } + +/* Request DMA channel mask from device tree */ + chan_mask = of_get_property(pdev->dev.of_node,
drivers/dma/bcm2835-dma.c line 690
Quoted 10 lines
drivers/dma/bcm2835-dma.c new file +10
-0+ "brcm,dma-channel-mask", NULL); + +if (!chan_mask) { +dev_err (&pdev->dev,"Failed to get channel mask\n" ); +dma_async_device_unregister (&od->ddev); +bcm2835_dma_free (od); +return -EINVAL ; + } + + chans_available =be32_to_cpup (chan_mask);
You can use of_property_read_u32(), which will do both of_get_property() and be32_to_cpup() for you.
drivers/dma/bcm2835-dma.c line 693
Quoted 3 lines
drivers/dma/bcm2835-dma.c new file +3
-0+ +/* do not use the FIQ and BULK channels */ + chans_available &= ~0xD ;
I'm clearly lacking the information about hardware here, but it would be nice to hear what these channels are.
Otherwise, the driver looks pretty good.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Tomasz Figa
Hi Florian,
Seems like I accidentally replied to some old version of this patch. Not sure how many of those comments were still relevant for V3, but let me look at this version and see whether we can still improve things a bit. Please see my comments inline.
Some were still helpful (especially the idea to use the chan_init function for setting the irq), thanks.
Quoted 14 lines
Quoted 14 lines
....
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +7
-0@@ -0,0 +1,59 @@ +* BCM2835 DMA controller + +Required properties: +- compatible: Should be "brcm,bcm2835-dma". +- reg: Should contain DMA registers location and length. +- interrupts: Should contain the DMA interrupts associated + to the DMA channels in ascending order.
Quoted 8 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 13
Quoted 6 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +6
-0+ First cell is the IRQ bank. + Second cell is the IRQ number. +- #dma-cells: Must be <1>, used to represent the number of integer cells in + the dmas property of client devices. +- dma-channels: Maximum number of DMA channels available. +- dma-requests: Number of DMA Requests.The two properties above do not seem to be used anywhere in the driver.
Aren't they necessary for the DMA engine core?
Quoted 33 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 14
Quoted 1 line
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +1
-0+- 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?
Quoted 9 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +9
-0+ +Example: + +dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16 + 1 17 + 1 18Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 33
Quoted 10 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +10
-0+ 1 19 + 1 20 + 1 21 + 1 22 + 1 23 + 1 24 + 1 25 + 1 26 + 1 27 + 1 28>;There are 13 interrupts specified here, but...
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 36
Quoted 3 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +3
-0+ + #dma-cells = <1>; + dma-channels = <16>;...16 channels here...
Quoted 4 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 38
Quoted 2 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +2
-0+ 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;
Quoted 17 lines
[snip]
Quoted 5 lines
drivers/dma/bcm2835-dma.c new file +0
-0[snip]
Quoted 9 lines
drivers/dma/bcm2835-dma.c new file +9
-0+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]
Quoted 5 lines
drivers/dma/bcm2835-dma.c line 666
Quoted 1 line
drivers/dma/bcm2835-dma.c new file +1
-0+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.
Greetings,
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · On Wednesday 13 of November 2013 20:35:22 Florian Meier wrote:
Quoted 6 lines · Tomasz Figa
Hi Florian,
Seems like I accidentally replied to some old version of this patch. Not sure how many of those comments were still relevant for V3, but let me look at this version and see whether we can still improve things a bit. Please see my comments inline.
Some were still helpful (especially the idea to use the
chan_initfunction for setting the irq), thanks.
Good. You're welcome.
Quoted 24 lines
Quoted 15 lines
Quoted 15 lines
....
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +7
-0@@ -0,0 +1,59 @@ +* BCM2835 DMA controller + +Required properties: +- compatible: Should be "brcm,bcm2835-dma". +- reg: Should contain DMA registers location and length. +- interrupts: Should contain the DMA interrupts associated + to the DMA channels in ascending order.Quoted 8 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 13
Quoted 6 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +6
-0+ First cell is the IRQ bank. + Second cell is the IRQ number. +- #dma-cells: Must be <1>, used to represent the number of integer cells in + the dmas property of client devices. +- dma-channels: Maximum number of DMA channels available. +- dma-requests: Number of DMA Requests.The two properties above do not seem to be used anywhere in the driver.
Quoted 1 line
Aren't they necessary for the DMA engine core?
Honestly, looking at the DMA bindings documentation, these two are quite a mystery for me. They don't seem to be used in DMA engine core, but instead several drivers use them for private purposes.
So, since they are optional and you don't seem to need them, I wouldn't list them.
Quoted 49 lines
Quoted 34 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 14
Quoted 2 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +1
-0+- 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?
Quoted 9 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +9
-0+ +Example: + +dma: dma at 7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16 + 1 17 + 1 18Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 33
Quoted 10 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +10
-0+ 1 19 + 1 20 + 1 21 + 1 22 + 1 23 + 1 24 + 1 25 + 1 26 + 1 27 + 1 28>;There are 13 interrupts specified here, but...
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 36
Quoted 3 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +3
-0+ + #dma-cells = <1>; + dma-channels = <16>;...16 channels here...
Quoted 4 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 38
Quoted 2 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +2
-0+ 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:
Quoted 2 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?
Quoted 24 lines
Quoted 18 lines
[snip]
Quoted 5 lines
drivers/dma/bcm2835-dma.c new file +0
-0[snip]
Quoted 9 lines
drivers/dma/bcm2835-dma.c new file +9
-0+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]
Quoted 5 lines
drivers/dma/bcm2835-dma.c line 666
Quoted 1 line
drivers/dma/bcm2835-dma.c new file +1
-0+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?
Quoted 3 lines
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.
Best regards,
Tomasz
Quoted 25 lines · Tomasz Figa
Quoted 24 lines · On Wednesday 13 of November 2013 20:35:22 Florian Meier wrote:
Quoted 22 lines · Tomasz Figa
Quoted 10 lines
....
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +3
-0@@ -0,0 +1,59 @@ +* BCM2835 DMA controller + +Required properties:Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 13
Quoted 10 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +10
-0+- compatible: Should be "brcm,bcm2835-dma". +- reg: Should contain DMA registers location and length. +- interrupts: Should contain the DMA interrupts associated + to the DMA channels in ascending order. + First cell is the IRQ bank. + Second cell is the IRQ number. +- #dma-cells: Must be <1>, used to represent the number of integer cells in + the dmas property of client devices. +- dma-channels: Maximum number of DMA channels available. +- dma-requests: Number of DMA Requests.The two properties above do not seem to be used anywhere in the driver.
Quoted 8 lines
Quoted 1 line
Aren't they necessary for the DMA engine core?
Honestly, looking at the DMA bindings documentation, these two are quite a mystery for me. They don't seem to be used in DMA engine core, but instead several drivers use them for private purposes.
So, since they are optional and you don't seem to need them, I wouldn't list them.
Ok
Quoted 51 lines
Quoted 48 lines
Quoted 33 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 14
Quoted 1 line
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +1
-0+- 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?
Quoted 9 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +9
-0+ +Example: + +dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16 + 1 17 + 1 18Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 33
Quoted 10 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +10
-0+ 1 19 + 1 20 + 1 21 + 1 22 + 1 23 + 1 24 + 1 25 + 1 26 + 1 27 + 1 28>;There are 13 interrupts specified here, but...
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 36
Quoted 3 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +3
-0+ + #dma-cells = <1>; + dma-channels = <16>;...16 channels here...
Quoted 4 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 38
Quoted 2 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +2
-0+ 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:Quoted 2 lines
/* do not use the FIQ and BULK channels */ chans_available &= ~0xD;
Quoted 7 lines
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.
Quoted 27 lines
Quoted 23 lines
Quoted 17 lines
[snip]
Quoted 5 lines
drivers/dma/bcm2835-dma.c new file +0
-0[snip]
Quoted 9 lines
drivers/dma/bcm2835-dma.c new file +9
-0+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]
Quoted 5 lines
drivers/dma/bcm2835-dma.c line 666
Quoted 1 line
drivers/dma/bcm2835-dma.c new file +1
-0+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?
Quoted 3 lines
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.
Quoted 5 lines
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 nopdev->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.
Greetings,
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 90 lines · On Thursday 14 of November 2013 08:12:46 Florian Meier wrote:
Quoted 25 lines · Tomasz Figa
Quoted 24 lines · On Wednesday 13 of November 2013 20:35:22 Florian Meier wrote:
Quoted 22 lines · Tomasz Figa
Quoted 10 lines
....
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +3
-0@@ -0,0 +1,59 @@ +* BCM2835 DMA controller + +Required properties:Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 13
Quoted 10 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +10
-0+- compatible: Should be "brcm,bcm2835-dma". +- reg: Should contain DMA registers location and length. +- interrupts: Should contain the DMA interrupts associated + to the DMA channels in ascending order. + First cell is the IRQ bank. + Second cell is the IRQ number. +- #dma-cells: Must be <1>, used to represent the number of integer cells in + the dmas property of client devices. +- dma-channels: Maximum number of DMA channels available. +- dma-requests: Number of DMA Requests.The two properties above do not seem to be used anywhere in the driver.
Quoted 8 lines
Quoted 1 line
Aren't they necessary for the DMA engine core?
Honestly, looking at the DMA bindings documentation, these two are quite a mystery for me. They don't seem to be used in DMA engine core, but instead several drivers use them for private purposes.
So, since they are optional and you don't seem to need them, I wouldn't list them.
Ok
Quoted 53 lines
Quoted 48 lines
Quoted 33 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 14
Quoted 1 line
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +1
-0+- 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?
Quoted 9 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +9
-0+ +Example: + +dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16 + 1 17 + 1 18Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 33
Quoted 10 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +10
-0+ 1 19 + 1 20 + 1 21 + 1 22 + 1 23 + 1 24 + 1 25 + 1 26 + 1 27 + 1 28>;There are 13 interrupts specified here, but...
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 36
Quoted 3 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +3
-0+ + #dma-cells = <1>; + dma-channels = <16>;...16 channels here...
Quoted 4 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 38
Quoted 2 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +2
-0+ 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:Quoted 2 lines
/* do not use the FIQ and BULK channels */ chans_available &= ~0xD;OK, this makes it much more clear.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 30 lines
Quoted 30 lines
Quoted 24 lines
Quoted 18 lines
[snip]
Quoted 5 lines
drivers/dma/bcm2835-dma.c new file +0
-0[snip]
Quoted 9 lines
drivers/dma/bcm2835-dma.c new file +9
-0+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]
Quoted 5 lines
drivers/dma/bcm2835-dma.c line 666
Quoted 1 line
drivers/dma/bcm2835-dma.c new file +1
-0+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?
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
What I meant is that your probe won't call
bcm2835_dma_chan_init()at all if there is nopdev->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?
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.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
2013/11/14 Tomasz Figa <[email protected]>:
Quoted 65 lines · On Thursday 14 of November 2013 08:12:46 Florian Meier wrote:
Quoted 55 lines · Tomasz Figa
Quoted 54 lines · On Wednesday 13 of November 2013 20:35:22 Florian Meier wrote:
Quoted 48 lines
Quoted 31 lines
Quoted 1 line
+- 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?
Quoted 9 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +9
-0+ +Example: + +dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16 + 1 17 + 1 18Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 33
Quoted 10 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +10
-0+ 1 19 + 1 20 + 1 21 + 1 22 + 1 23 + 1 24 + 1 25 + 1 26 + 1 27 + 1 28>;There are 13 interrupts specified here, but...
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 36
Quoted 3 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +3
-0+ + #dma-cells = <1>; + dma-channels = <16>;Quoted 6 lines
...16 channels here...
Documentation/devicetree/bindings/dma/bcm2835-dma.txt line 38
Quoted 2 lines
Documentation/devicetree/bindings/dma/bcm2835-dma.txt new file +2
-0+ 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:Quoted 2 lines
/* do not use the FIQ and BULK channels */ chans_available &= ~0xD;OK, this makes it much more clear.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 33 lines
Quoted 33 lines
Quoted 32 lines
Quoted 19 lines
Quoted 19 lines
[snip]
Quoted 5 lines
drivers/dma/bcm2835-dma.c new file +0
-0[snip]
Quoted 9 lines
drivers/dma/bcm2835-dma.c new file +9
-0+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]
Quoted 1 line
+ if (
pdev->dev.of_node) {Quoted 7 lines
Quoted 3 lines
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 nopdev->dev.of_node, because the loop iterating over channels is under the if clause.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 5 lines
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
Quoted 73 lines · On Thursday 14 of November 2013 15:44:05 Florian Meier wrote:
2013/11/14 Tomasz Figa <[email protected]>:
Quoted 65 lines · On Thursday 14 of November 2013 08:12:46 Florian Meier wrote:
Quoted 55 lines · Tomasz Figa
Quoted 54 lines · On Wednesday 13 of November 2013 20:35:22 Florian Meier wrote:
Quoted 48 lines
Quoted 31 lines
Quoted 1 line
+- 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?
Quoted 9 lines
(quoted diff) +9
-0+ +Example: + +dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16 + 1 17 + 1 18Review
Quoted 10 lines
(quoted diff) +10
-0+ 1 19 + 1 20 + 1 21 + 1 22 + 1 23 + 1 24 + 1 25 + 1 26 + 1 27 + 1 28>;There are 13 interrupts specified here, but...
Review
Quoted 3 lines
(quoted diff) +3
-0+ + #dma-cells = <1>; + dma-channels = <16>;Quoted 6 lines
...16 channels here...
Review
Quoted 2 lines
(quoted diff) +2
-0+ 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:Quoted 2 lines
/* do not use the FIQ and BULK channels */ chans_available &= ~0xD;OK, this makes it much more clear.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 11 lines
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 thisfirmware->devicetreeinterface will take place, but since I didn't want to run in circles I hardcoded it in the device tree.
OK. So the firmware defines what set and clear bits in the mask mean. It's fine then.
Quoted 50 lines
Quoted 34 lines
Quoted 34 lines
Quoted 33 lines
Quoted 20 lines
Quoted 20 lines
[snip]
Quoted 5 lines
drivers/dma/bcm2835-dma.c new file +0
-0[snip]
Quoted 9 lines
drivers/dma/bcm2835-dma.c new file +9
-0+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]
Quoted 1 line
+ if (
pdev->dev.of_node) {Quoted 7 lines
Quoted 3 lines
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 nopdev->dev.of_node, because the loop iterating over channels is under the if clause.Quoted 5 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 4 lines
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'm just presenting you the possible options. You are still free to have non-DT support in the driver, but if you don't need it (because you can't have any new non-DT platforms in mainline) then you can simplify some code.
However the driver shouldn't be left with illusionary support for non-DT platforms until you decide to implement that. Instead, if you don't want to add non-DT support now, just make the driver DT-only, while keeping its design in a way allowing you to add non-DT support in future.
In other words, a driver should not be able to probe using board files if support for such probing method is not available in it yet.
Quoted 2 lines
I am becoming desperate anyway that this migration will ever fully take place....
Why not? It's just a matter of people like you working on this (and addressing some review comments ;)).
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
2013/11/14 Tomasz Figa <[email protected]>:
Quoted 86 lines · On Thursday 14 of November 2013 15:44:05 Florian Meier wrote:
Quoted 73 lines
2013/11/14 Tomasz Figa <[email protected]>:
Quoted 65 lines · On Thursday 14 of November 2013 08:12:46 Florian Meier wrote:
Quoted 55 lines · Tomasz Figa
Quoted 54 lines · On Wednesday 13 of November 2013 20:35:22 Florian Meier wrote:
Quoted 48 lines
Quoted 31 lines
Quoted 1 line
+- 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?
Quoted 9 lines
(quoted diff) +9
-0+ +Example: + +dma: dma@7e007000 { + compatible = "brcm,bcm2835-dma"; + reg = <0x7e007000 0xf00>; + interrupts = <1 16 + 1 17 + 1 18Review
Quoted 10 lines
(quoted diff) +10
-0+ 1 19 + 1 20 + 1 21 + 1 22 + 1 23 + 1 24 + 1 25 + 1 26 + 1 27 + 1 28>;There are 13 interrupts specified here, but...
Review
Quoted 3 lines
(quoted diff) +3
-0+ + #dma-cells = <1>; + dma-channels = <16>;Quoted 6 lines
...16 channels here...
Review
Quoted 2 lines
(quoted diff) +2
-0+ 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:Quoted 2 lines
/* do not use the FIQ and BULK channels */ chans_available &= ~0xD;OK, this makes it much more clear.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 11 lines
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 thisfirmware->devicetreeinterface will take place, but since I didn't want to run in circles I hardcoded it in the device tree.
Quoted 2 lines
OK. So the firmware defines what set and clear bits in the mask mean. It's fine then.
Yes, this mask is actually an "I am not using this channel"-mask.
Quoted 59 lines
Quoted 49 lines
Quoted 33 lines
Quoted 33 lines
Quoted 32 lines
Quoted 19 lines
Quoted 19 lines
[snip]
Quoted 5 lines
drivers/dma/bcm2835-dma.c new file +0
-0[snip]
Quoted 9 lines
drivers/dma/bcm2835-dma.c new file +9
-0+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]
Quoted 1 line
+ if (
pdev->dev.of_node) {Quoted 7 lines
Quoted 3 lines
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 nopdev->dev.of_node, because the loop iterating over channels is under the if clause.Quoted 5 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 4 lines
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'm just presenting you the possible options. You are still free to have non-DT support in the driver, but if you don't need it (because you can't have any new non-DT platforms in mainline) then you can simplify some code.
Quoted 4 lines
However the driver shouldn't be left with illusionary support for non-DT platforms until you decide to implement that. Instead, if you don't want to add non-DT support now, just make the driver DT-only, while keeping its design in a way allowing you to add non-DT support in future.
This statement hits the nail on the head. Thank you!
Quoted 2 lines
In other words, a driver should not be able to probe using board files if support for such probing method is not available in it yet.
That is meaningful. So would the following be ok?
+ .....
+ if (pdev->dev.of_node) {
+ .....
+ } else {
+ dev_err(&pdev->dev,
+ "Failed to initialize channels, because device
tree not available: %d\n", rc);
+ bcm2835_dma_free(od);
+ return rc;
+ }
+
+ dev_dbg(&pdev->dev, "Initialized %i DMA channels\n", i);
+
+ .....
Quoted 5 lines
Quoted 2 lines
I am becoming desperate anyway that this migration will ever fully take place....
Why not? It's just a matter of people like you working on this (and addressing some review comments ;)).
The most common comment about this is that people will not put effort in the upstream kernel as long as there is no comfortable way for debugging in the upstream kernel (i.e. at least USB support).......
Greetings,
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 84 lines · On Thursday 14 of November 2013 16:41:56 Florian Meier wrote:
2013/11/14 Tomasz Figa <[email protected]>:
Quoted 63 lines · On Thursday 14 of November 2013 15:44:05 Florian Meier wrote:
Quoted 52 lines
2013/11/14 Tomasz Figa <[email protected]>:
Quoted 35 lines · On Thursday 14 of November 2013 08:12:46 Florian Meier wrote:
Quoted 34 lines · Tomasz Figa
Quoted 32 lines · On Wednesday 13 of November 2013 20:35:22 Florian Meier wrote:
Quoted 18 lines
Quoted 18 lines
Quoted 5 lines
drivers/dma/bcm2835-dma.c new file +0
-0[snip]
Quoted 9 lines
drivers/dma/bcm2835-dma.c new file +9
-0+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]
Quoted 1 line
+ if (
pdev->dev.of_node) {Quoted 7 lines
Quoted 3 lines
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 nopdev->dev.of_node, because the loop iterating over channels is under the if clause.Quoted 5 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 4 lines
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'm just presenting you the possible options. You are still free to have non-DT support in the driver, but if you don't need it (because you can't have any new non-DT platforms in mainline) then you can simplify some code.
Quoted 4 lines
However the driver shouldn't be left with illusionary support for non-DT platforms until you decide to implement that. Instead, if you don't want to add non-DT support now, just make the driver DT-only, while keeping its design in a way allowing you to add non-DT support in future.
This statement hits the nail on the head. Thank you!
Quoted 2 lines
In other words, a driver should not be able to probe using board files if support for such probing method is not available in it yet.
That is meaningful. So would the following be ok?
+ .....
(quoted diff) +5
-0+ if (pdev->dev.of_node) { + ..... + } else { + dev_err(&pdev->dev, + "Failed to initialize channels, because devicetree not available: %d\n", rc);
Review
Quoted 7 lines
(quoted diff) +7
-0+ bcm2835_dma_free(od); + return rc; + } + + dev_dbg(&pdev->dev, "Initialized %i DMA channels\n", i); + + .....
I mean, something closer to:
static int bcm2835_dma_probe(struct platform_device *pdev)
{
uint32_t chan_mask;
// ...
if (pdev->dev.of_node) {
rc = of_property_read_u32(..., &chan_mask);
if (rc) {
// Error out
}
} else {
// Error message
return -EINVAL;
}
// ...
// Channel registration loop (independent of any OF functions)
// ...
if (pdev->dev.of_node) {
rc = of_dma_controller_register(...);
// ...
}
// ...
}Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
I am becoming desperate anyway that this migration will ever fully take place....
Why not? It's just a matter of people like you working on this (and addressing some review comments ;)).
The most common comment about this is that people will not put effort in the upstream kernel as long as there is no comfortable way for debugging in the upstream kernel (i.e. at least USB support).......
Right, you need USB to have ethernet working. Still, IMHO UART (for console) + ethernet (for file transfer or NFS root) is the reasonable setup allowing you to debug further drivers in a comfortable way.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines
I mean, something closer to:
.....
Ok :-)
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
I am becoming desperate anyway that this migration will ever fully take place....
Why not? It's just a matter of people like you working on this (and addressing some review comments ;)).
Quoted 7 lines
Quoted 3 lines
The most common comment about this is that people will not put effort in the upstream kernel as long as there is no comfortable way for debugging in the upstream kernel (i.e. at least USB support).......
Right, you need USB to have ethernet working. Still, IMHO UART (for console) + ethernet (for file transfer or NFS root) is the reasonable setup allowing you to debug further drivers in a comfortable way.
I am fine with UART and switching SD cards :-)
But apparently this is not generally accepted.
Greetings,
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · On Thursday 14 of November 2013 17:14:31 Florian Meier wrote:
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
I am becoming desperate anyway that this migration will ever fully take place....
Why not? It's just a matter of people like you working on this (and addressing some review comments ;)).
The most common comment about this is that people will not put effort in the upstream kernel as long as there is no comfortable way for debugging in the upstream kernel (i.e. at least USB support).......
Quoted 6 lines
Quoted 3 lines
Right, you need USB to have ethernet working. Still, IMHO UART (for console) + ethernet (for file transfer or NFS root) is the reasonable setup allowing you to debug further drivers in a comfortable way.
I am fine with UART and switching SD cards :-)
But apparently this is not generally accepted.
Still, isn't some work on USB support for RPi already going on? I believe Matt Porter (now on Cc) has been working on unifying dwc2 host-mode driver with Samsung s3c-hsotg device-mode driver (for the same IP) to get full OTG support on all applicable platforms.
Best regards,
Tomasz
2013/11/14 Tomasz Figa <[email protected]>:
Quoted 15 lines · On Thursday 14 of November 2013 17:14:31 Florian Meier wrote:
Quoted 14 lines
Quoted 13 lines
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
I am becoming desperate anyway that this migration will ever fully take place....
Why not? It's just a matter of people like you working on this (and addressing some review comments ;)).
The most common comment about this is that people will not put effort in the upstream kernel as long as there is no comfortable way for debugging in the upstream kernel (i.e. at least USB support).......
Right, you need USB to have ethernet working. Still, IMHO UART (for console) + ethernet (for file transfer or NFS root) is the reasonable setup allowing you to debug further drivers in a comfortable way.
Quoted 7 lines
Quoted 2 lines
I am fine with UART and switching SD cards :-)
But apparently this is not generally accepted.Still, isn't some work on USB support for RPi already going on? I believe Matt Porter (now on Cc) has been working on unifying dwc2 host-mode driver with Samsung s3c-hsotg device-mode driver (for the same IP) to get full OTG support on all applicable platforms.
That sounds great! I never heard about that.
Maybe some day it really happens that Raspbian uses the upstream kernel :-) --
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 15 lines · Tomasz Figa
Quoted 14 lines · On Thursday 14 of November 2013 17:14:31 Florian Meier wrote:
Quoted 13 lines
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
I am becoming desperate anyway that this migration will ever fully take place....
Why not? It's just a matter of people like you working on this (and addressing some review comments ;)).
The most common comment about this is that people will not put effort in the upstream kernel as long as there is no comfortable way for debugging in the upstream kernel (i.e. at least USB support).......
Right, you need USB to have ethernet working. Still, IMHO UART (for console) + ethernet (for file transfer or NFS root) is the reasonable setup allowing you to debug further drivers in a comfortable way.
Quoted 7 lines
Quoted 2 lines
I am fine with UART and switching SD cards :-)
But apparently this is not generally accepted.Still, isn't some work on USB support for RPi already going on? I believe Matt Porter (now on Cc) has been working on unifying dwc2 host-mode driver with Samsung s3c-hsotg device-mode driver (for the same IP) to get full OTG support on all applicable platforms.
Baby steps in that direction, yes. I need to finish the basic s3c-hsotg and dwc2 host only enablement for my platform and then will be focused on combining them.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html