mbox series

[v5,0/7] sunxi: Add DT representation for the MBUS controller

Message ID cover.f8909884585996f28d97f4ef95efbcab19527dc4.1554108995.git-series.maxime.ripard@bootlin.com (mailing list archive)
Headers show
Series sunxi: Add DT representation for the MBUS controller | expand

Message

Maxime Ripard April 1, 2019, 8:56 a.m. UTC
Hi,

We've had for quite some time to hack around in our drivers to take into
account the fact that our DMA accesses are not done through the parent
node, but through another bus with a different mapping than the CPU for the
RAM (0 instead of 0x40000000 for most SoCs).

After some discussion after the submission of a camera device suffering of
the same hacks, I've decided to put together a serie that introduce a
special interconnect name called "dma" that that allows to express the DMA
relationship between a master and its bus, even if they are not direct
parents in the DT.

Let me know what you think,
Maxime

Changes from v4:
  - Fixed the commit logs that had some leftovers from earlier versions
  - Removed spurious whitespaces
  - Added tags
  - Rebased on next

Changes from v3:
  - Rebased on top of current next
  - Use a function pointer instead of the parent device node to fix the
    recursive cases
  - Fix the usage of the device_node index in __of_get_dma_parent
  - Refer to the DT Specification for dma-ranges in the MBUS binding
  - Used dma-mem as the property instead of dma

Changes from v2:
  - Rewrite commit logs still mentionning dma-parent
  - Removed dma-parent-cells left over in the binding example
  - Removed dma-parent still being mentionned in comments

Changes from v1:
  - Change to use the now merged interconnect bindings
  - Move the DMA parent retrieval logic to its own function
  - Rebase on top of 5.0

Maxime Ripard (7):
  dt-bindings: interconnect: Add a dma interconnect name
  dt-bindings: bus: Add binding for the Allwinner MBUS controller
  of: address: Retrieve a parent through a callback in __of_translate_address
  of: address: Add support for the parent DMA bus
  drm/sun4i: Rely on dma interconnect for our RAM offset
  clk: sunxi-ng: sun5i: Export the MBUS clock
  ARM: dts: sun5i: Add the MBUS controller

 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt      | 36 ++++++-
 Documentation/devicetree/bindings/interconnect/interconnect.txt |  4 +-
 arch/arm/boot/dts/sun5i.dtsi                                    | 13 ++-
 drivers/clk/sunxi-ng/ccu-sun5i.h                                |  4 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c                           | 28 +++--
 drivers/of/address.c                                            | 40 +++++--
 include/dt-bindings/clock/sun5i-ccu.h                           |  2 +-
 7 files changed, 109 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt

base-commit: e3ecb83ee707a3b2a4d12e19509ecbda7f793cc2

Comments

Rob Herring (Arm) April 6, 2019, 6:06 a.m. UTC | #1
On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> Hi,
> 
> We've had for quite some time to hack around in our drivers to take into
> account the fact that our DMA accesses are not done through the parent
> node, but through another bus with a different mapping than the CPU for the
> RAM (0 instead of 0x40000000 for most SoCs).
> 
> After some discussion after the submission of a camera device suffering of
> the same hacks, I've decided to put together a serie that introduce a
> special interconnect name called "dma" that that allows to express the DMA
> relationship between a master and its bus, even if they are not direct
> parents in the DT.
> 
> Let me know what you think,
> Maxime

LGTM.

How do you propose merging this? I can take 1-5, and 6 and 7 thru 
arm-soc?

Rob
Maxime Ripard April 8, 2019, 8:11 a.m. UTC | #2
On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > We've had for quite some time to hack around in our drivers to take into
> > account the fact that our DMA accesses are not done through the parent
> > node, but through another bus with a different mapping than the CPU for the
> > RAM (0 instead of 0x40000000 for most SoCs).
> >
> > After some discussion after the submission of a camera device suffering of
> > the same hacks, I've decided to put together a serie that introduce a
> > special interconnect name called "dma" that that allows to express the DMA
> > relationship between a master and its bus, even if they are not direct
> > parents in the DT.
> >
> > Let me know what you think,
> > Maxime
>
> LGTM.
>
> How do you propose merging this? I can take 1-5, and 6 and 7 thru
> arm-soc?

You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
arm-soc

Thanks!
Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Chen-Yu Tsai April 8, 2019, 8:14 a.m. UTC | #3
On Mon, Apr 8, 2019 at 4:11 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > We've had for quite some time to hack around in our drivers to take into
> > > account the fact that our DMA accesses are not done through the parent
> > > node, but through another bus with a different mapping than the CPU for the
> > > RAM (0 instead of 0x40000000 for most SoCs).
> > >
> > > After some discussion after the submission of a camera device suffering of
> > > the same hacks, I've decided to put together a serie that introduce a
> > > special interconnect name called "dma" that that allows to express the DMA
> > > relationship between a master and its bus, even if they are not direct
> > > parents in the DT.
> > >
> > > Let me know what you think,
> > > Maxime
> >
> > LGTM.
> >
> > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > arm-soc?
>
> You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> arm-soc

Wouldn't there be some runtime dependency between 3, 4, and 5?

ChenYu
Maxime Ripard April 8, 2019, 8:21 a.m. UTC | #4
On Mon, Apr 08, 2019 at 04:14:53PM +0800, Chen-Yu Tsai wrote:
> On Mon, Apr 8, 2019 at 4:11 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > We've had for quite some time to hack around in our drivers to take into
> > > > account the fact that our DMA accesses are not done through the parent
> > > > node, but through another bus with a different mapping than the CPU for the
> > > > RAM (0 instead of 0x40000000 for most SoCs).
> > > >
> > > > After some discussion after the submission of a camera device suffering of
> > > > the same hacks, I've decided to put together a serie that introduce a
> > > > special interconnect name called "dma" that that allows to express the DMA
> > > > relationship between a master and its bus, even if they are not direct
> > > > parents in the DT.
> > > >
> > > > Let me know what you think,
> > > > Maxime
> > >
> > > LGTM.
> > >
> > > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > > arm-soc?
> >
> > You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> > arm-soc
>
> Wouldn't there be some runtime dependency between 3, 4, and 5?

What issue did you have in mind?

I guess the only issue would be if we have the new DT properties, but
not the new core code. But that seems pretty unlikely, since each of
the trees will work independently, and next should have all of them.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Chen-Yu Tsai April 8, 2019, 8:26 a.m. UTC | #5
On Mon, Apr 8, 2019 at 4:21 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Mon, Apr 08, 2019 at 04:14:53PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Apr 8, 2019 at 4:11 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > > > Hi,
> > > > >
> > > > > We've had for quite some time to hack around in our drivers to take into
> > > > > account the fact that our DMA accesses are not done through the parent
> > > > > node, but through another bus with a different mapping than the CPU for the
> > > > > RAM (0 instead of 0x40000000 for most SoCs).
> > > > >
> > > > > After some discussion after the submission of a camera device suffering of
> > > > > the same hacks, I've decided to put together a serie that introduce a
> > > > > special interconnect name called "dma" that that allows to express the DMA
> > > > > relationship between a master and its bus, even if they are not direct
> > > > > parents in the DT.
> > > > >
> > > > > Let me know what you think,
> > > > > Maxime
> > > >
> > > > LGTM.
> > > >
> > > > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > > > arm-soc?
> > >
> > > You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> > > arm-soc
> >
> > Wouldn't there be some runtime dependency between 3, 4, and 5?
>
> What issue did you have in mind?
>
> I guess the only issue would be if we have the new DT properties, but
> not the new core code. But that seems pretty unlikely, since each of
> the trees will work independently, and next should have all of them.

I got it wrong. Even in your case since the interconnect property is
ignored, and the driver would just fall back to using the fixed offset.

Sorry for the noise.

ChenYu
Rob Herring (Arm) April 10, 2019, 2:01 p.m. UTC | #6
On Mon, Apr 08, 2019 at 10:11:26AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > We've had for quite some time to hack around in our drivers to take into
> > > account the fact that our DMA accesses are not done through the parent
> > > node, but through another bus with a different mapping than the CPU for the
> > > RAM (0 instead of 0x40000000 for most SoCs).
> > >
> > > After some discussion after the submission of a camera device suffering of
> > > the same hacks, I've decided to put together a serie that introduce a
> > > special interconnect name called "dma" that that allows to express the DMA
> > > relationship between a master and its bus, even if they are not direct
> > > parents in the DT.
> > >
> > > Let me know what you think,
> > > Maxime
> >
> > LGTM.
> >
> > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > arm-soc?
> 
> You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> arm-soc

Done.

Rob
Maxime Ripard April 10, 2019, 2:34 p.m. UTC | #7
On Wed, Apr 10, 2019 at 09:01:28AM -0500, Rob Herring wrote:
> On Mon, Apr 08, 2019 at 10:11:26AM +0200, Maxime Ripard wrote:
> > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote:
> > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > We've had for quite some time to hack around in our drivers to take into
> > > > account the fact that our DMA accesses are not done through the parent
> > > > node, but through another bus with a different mapping than the CPU for the
> > > > RAM (0 instead of 0x40000000 for most SoCs).
> > > >
> > > > After some discussion after the submission of a camera device suffering of
> > > > the same hacks, I've decided to put together a serie that introduce a
> > > > special interconnect name called "dma" that that allows to express the DMA
> > > > relationship between a master and its bus, even if they are not direct
> > > > parents in the DT.
> > > >
> > > > Let me know what you think,
> > > > Maxime
> > >
> > > LGTM.
> > >
> > > How do you propose merging this? I can take 1-5, and 6 and 7 thru
> > > arm-soc?
> >
> > You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through
> > arm-soc
>
> Done.

Thanks!

Applied 5, 6 and 7

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com