All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: robh+dt@kernel.org, devicetree@vger.kernel.org,
	frowand.list@gmail.com, linux-arm-kernel@lists.infradead.org,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, dmaengine@vger.kernel.org,
	etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	xen-devel@lists.xenproject.org, linux-tegra@vger.kernel.org,
	linux-media@vger.kernel.org, linux-pci@vger.kernel.org
Cc: mbrugger@suse.com, robin.murphy@arm.com, f.fainelli@gmail.com,
	james.quinlan@broadcom.com, wahrenst@gmx.net,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	Dan Williams <dan.j.williams@intel.com>,
	freedreno@lists.freedesktop.org
Subject: [PATCH 00/11] of: Fix DMA configuration for non-DT masters
Date: Tue, 24 Sep 2019 20:12:31 +0200	[thread overview]
Message-ID: <20190924181244.7159-1-nsaenzjulienne@suse.de> (raw)

Hi All,
this series tries to address one of the issues blocking us from
upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that
devices not represented in DT which sit behind a PCI bus fail to get the
bus' DMA addressing constraints.

This is due to the fact that of_dma_configure() assumes it's receiving a
DT node representing the device being configured, as opposed to the PCIe
bridge node we currently pass. This causes the code to directly jump
into PCI's parent node when checking for 'dma-ranges' and misses
whatever was set there.

To address this I create a new API in OF - inspired from Robin Murphys
original proposal[2] - which accepts a bus DT node as it's input in
order to configure a device's DMA constraints. The changes go deep into
of/address.c's implementation, as a device being having a DT node
assumption was pretty strong.

On top of this work, I also cleaned up of_dma_configure() removing its
redundant arguments and creating an alternative function for the special cases
not applicable to either the above case or the default usage.

IMO the resulting functions are more explicit. They will probably
surface some hacky usages that can be properly fixed as I show with the
DT fixes on the Layerscape platform.

This was also tested on a Raspberry Pi 4 with a custom PCIe driver and
on a Seattle AMD board.

Regards,
Nicolas

[1] https://patchwork.kernel.org/patch/9650345/#20294961
[2] https://patchwork.kernel.org/patch/9650345/

---

Nicolas Saenz Julienne (11):
  of: address: clean-up unused variable in of_dma_get_range()
  of: base: introduce __of_n_*_cells_parent()
  of: address: use parent DT node in bus->count_cells()
  of: address: introduce of_translate_dma_address_parent()
  of: expose __of_get_dma_parent() to OF subsystem
  of: address: use parent OF node in of_dma_get_range()
  dts: arm64: layerscape: add dma-ranges property to qoric-mc node
  dts: arm64: layerscape: add dma-ranges property to pcie nodes
  of: device: remove comment in of_dma_configure()
  of: device: introduce of_dma_configure_parent()
  of: simplify of_dma_config()'s arguments

 .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi |   1 +
 .../arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   5 +
 .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi |   1 +
 drivers/base/platform.c                       |   2 +-
 drivers/bcma/main.c                           |   2 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c               |   2 +-
 drivers/dma/qcom/hidma_mgmt.c                 |   2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c         |   2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c         |   2 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c         |   2 +-
 drivers/gpu/drm/xen/xen_drm_front.c           |   2 +-
 drivers/gpu/host1x/bus.c                      |   4 +-
 drivers/media/platform/qcom/venus/firmware.c  |   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc.c      |   2 +-
 drivers/of/address.c                          | 136 +++++++++---------
 drivers/of/base.c                             |  69 +++++++--
 drivers/of/device.c                           |  59 +++++++-
 drivers/of/of_private.h                       |   5 +
 drivers/pci/pci-driver.c                      |   3 +-
 drivers/xen/gntdev.c                          |   2 +-
 include/linux/of_address.h                    |   8 +-
 include/linux/of_device.h                     |  23 ++-
 22 files changed, 223 insertions(+), 113 deletions(-)

-- 
2.23.0


WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: robh+dt@kernel.org, devicetree@vger.kernel.org,
	frowand.list@gmail.com, linux-arm-kernel@lists.infradead.org,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, dmaengine@vger.kernel.org,
	etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	xen-devel@lists.xenproject.org, linux-tegra@vger.kernel.org,
	linux-media@vger.kernel.org, linux-pci@vger.kernel.org
Cc: f.fainelli@gmail.com, freedreno@lists.freedesktop.org,
	mbrugger@suse.com, wahrenst@gmx.net, james.quinlan@broadcom.com,
	Dan Williams <dan.j.williams@intel.com>,
	robin.murphy@arm.com,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Subject: [PATCH 00/11] of: Fix DMA configuration for non-DT masters
Date: Tue, 24 Sep 2019 20:12:31 +0200	[thread overview]
Message-ID: <20190924181244.7159-1-nsaenzjulienne@suse.de> (raw)

Hi All,
this series tries to address one of the issues blocking us from
upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that
devices not represented in DT which sit behind a PCI bus fail to get the
bus' DMA addressing constraints.

This is due to the fact that of_dma_configure() assumes it's receiving a
DT node representing the device being configured, as opposed to the PCIe
bridge node we currently pass. This causes the code to directly jump
into PCI's parent node when checking for 'dma-ranges' and misses
whatever was set there.

To address this I create a new API in OF - inspired from Robin Murphys
original proposal[2] - which accepts a bus DT node as it's input in
order to configure a device's DMA constraints. The changes go deep into
of/address.c's implementation, as a device being having a DT node
assumption was pretty strong.

On top of this work, I also cleaned up of_dma_configure() removing its
redundant arguments and creating an alternative function for the special cases
not applicable to either the above case or the default usage.

IMO the resulting functions are more explicit. They will probably
surface some hacky usages that can be properly fixed as I show with the
DT fixes on the Layerscape platform.

This was also tested on a Raspberry Pi 4 with a custom PCIe driver and
on a Seattle AMD board.

Regards,
Nicolas

[1] https://patchwork.kernel.org/patch/9650345/#20294961
[2] https://patchwork.kernel.org/patch/9650345/

---

Nicolas Saenz Julienne (11):
  of: address: clean-up unused variable in of_dma_get_range()
  of: base: introduce __of_n_*_cells_parent()
  of: address: use parent DT node in bus->count_cells()
  of: address: introduce of_translate_dma_address_parent()
  of: expose __of_get_dma_parent() to OF subsystem
  of: address: use parent OF node in of_dma_get_range()
  dts: arm64: layerscape: add dma-ranges property to qoric-mc node
  dts: arm64: layerscape: add dma-ranges property to pcie nodes
  of: device: remove comment in of_dma_configure()
  of: device: introduce of_dma_configure_parent()
  of: simplify of_dma_config()'s arguments

 .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi |   1 +
 .../arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   5 +
 .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi |   1 +
 drivers/base/platform.c                       |   2 +-
 drivers/bcma/main.c                           |   2 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c               |   2 +-
 drivers/dma/qcom/hidma_mgmt.c                 |   2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c         |   2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c         |   2 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c         |   2 +-
 drivers/gpu/drm/xen/xen_drm_front.c           |   2 +-
 drivers/gpu/host1x/bus.c                      |   4 +-
 drivers/media/platform/qcom/venus/firmware.c  |   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc.c      |   2 +-
 drivers/of/address.c                          | 136 +++++++++---------
 drivers/of/base.c                             |  69 +++++++--
 drivers/of/device.c                           |  59 +++++++-
 drivers/of/of_private.h                       |   5 +
 drivers/pci/pci-driver.c                      |   3 +-
 drivers/xen/gntdev.c                          |   2 +-
 include/linux/of_address.h                    |   8 +-
 include/linux/of_device.h                     |  23 ++-
 22 files changed, 223 insertions(+), 113 deletions(-)

-- 
2.23.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: robh+dt@kernel.org, devicetree@vger.kernel.org,
	frowand.list@gmail.com, linux-arm-kernel@lists.infradead.org,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, dmaengine@vger.kernel.org,
	etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	xen-devel@lists.xenproject.org, linux-tegra@vger.kernel.org,
	linux-media@vger.kernel.org, linux-pci@vger.kernel.org
Cc: f.fainelli@gmail.com, freedreno@lists.freedesktop.org,
	mbrugger@suse.com, wahrenst@gmx.net, james.quinlan@broadcom.com,
	Dan Williams <dan.j.williams@intel.com>,
	robin.murphy@arm.com,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Subject: [Xen-devel] [PATCH 00/11] of: Fix DMA configuration for non-DT masters
Date: Tue, 24 Sep 2019 20:12:31 +0200	[thread overview]
Message-ID: <20190924181244.7159-1-nsaenzjulienne@suse.de> (raw)

Hi All,
this series tries to address one of the issues blocking us from
upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that
devices not represented in DT which sit behind a PCI bus fail to get the
bus' DMA addressing constraints.

This is due to the fact that of_dma_configure() assumes it's receiving a
DT node representing the device being configured, as opposed to the PCIe
bridge node we currently pass. This causes the code to directly jump
into PCI's parent node when checking for 'dma-ranges' and misses
whatever was set there.

To address this I create a new API in OF - inspired from Robin Murphys
original proposal[2] - which accepts a bus DT node as it's input in
order to configure a device's DMA constraints. The changes go deep into
of/address.c's implementation, as a device being having a DT node
assumption was pretty strong.

On top of this work, I also cleaned up of_dma_configure() removing its
redundant arguments and creating an alternative function for the special cases
not applicable to either the above case or the default usage.

IMO the resulting functions are more explicit. They will probably
surface some hacky usages that can be properly fixed as I show with the
DT fixes on the Layerscape platform.

This was also tested on a Raspberry Pi 4 with a custom PCIe driver and
on a Seattle AMD board.

Regards,
Nicolas

[1] https://patchwork.kernel.org/patch/9650345/#20294961
[2] https://patchwork.kernel.org/patch/9650345/

---

Nicolas Saenz Julienne (11):
  of: address: clean-up unused variable in of_dma_get_range()
  of: base: introduce __of_n_*_cells_parent()
  of: address: use parent DT node in bus->count_cells()
  of: address: introduce of_translate_dma_address_parent()
  of: expose __of_get_dma_parent() to OF subsystem
  of: address: use parent OF node in of_dma_get_range()
  dts: arm64: layerscape: add dma-ranges property to qoric-mc node
  dts: arm64: layerscape: add dma-ranges property to pcie nodes
  of: device: remove comment in of_dma_configure()
  of: device: introduce of_dma_configure_parent()
  of: simplify of_dma_config()'s arguments

 .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi |   1 +
 .../arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   5 +
 .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi |   1 +
 drivers/base/platform.c                       |   2 +-
 drivers/bcma/main.c                           |   2 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c               |   2 +-
 drivers/dma/qcom/hidma_mgmt.c                 |   2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c         |   2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c         |   2 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c         |   2 +-
 drivers/gpu/drm/xen/xen_drm_front.c           |   2 +-
 drivers/gpu/host1x/bus.c                      |   4 +-
 drivers/media/platform/qcom/venus/firmware.c  |   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc.c      |   2 +-
 drivers/of/address.c                          | 136 +++++++++---------
 drivers/of/base.c                             |  69 +++++++--
 drivers/of/device.c                           |  59 +++++++-
 drivers/of/of_private.h                       |   5 +
 drivers/pci/pci-driver.c                      |   3 +-
 drivers/xen/gntdev.c                          |   2 +-
 include/linux/of_address.h                    |   8 +-
 include/linux/of_device.h                     |  23 ++-
 22 files changed, 223 insertions(+), 113 deletions(-)

-- 
2.23.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

             reply	other threads:[~2019-09-24 18:12 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 18:12 Nicolas Saenz Julienne [this message]
2019-09-24 18:12 ` [Xen-devel] [PATCH 00/11] of: Fix DMA configuration for non-DT masters Nicolas Saenz Julienne
2019-09-24 18:12 ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 01/11] of: address: clean-up unused variable in of_dma_get_range() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 02/11] of: base: introduce __of_n_*_cells_parent() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 03/11] of: address: use parent DT node in bus->count_cells() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 04/11] of: address: introduce of_translate_dma_address_parent() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 05/11] of: expose __of_get_dma_parent() to OF subsystem Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 06/11] of: address: use parent OF node in of_dma_get_range() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 07/11] dts: arm64: layerscape: add dma-ranges property to qoric-mc node Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-10-14  8:28   ` Shawn Guo
2019-10-14  8:28     ` [Xen-devel] " Shawn Guo
2019-10-14  8:28     ` Shawn Guo
2019-10-14 10:00     ` Nicolas Saenz Julienne
2019-10-14 10:00       ` [Xen-devel] " Nicolas Saenz Julienne
2019-10-14 10:00       ` Nicolas Saenz Julienne
2019-10-14 11:09       ` Shawn Guo
2019-10-14 11:09         ` [Xen-devel] " Shawn Guo
2019-10-14 11:09         ` Shawn Guo
2019-10-14 11:09         ` Shawn Guo
2019-09-24 18:12 ` [PATCH 08/11] dts: arm64: layerscape: add dma-ranges property to pcie nodes Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-10-14  8:29   ` Shawn Guo
2019-10-14  8:29     ` [Xen-devel] " Shawn Guo
2019-10-14  8:29     ` Shawn Guo
2019-09-24 18:12 ` [PATCH 09/11] of: device: remove comment in of_dma_configure() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 10/11] of: device: introduce of_dma_configure_parent() Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12 ` [PATCH 11/11] of: simplify of_dma_config()'s arguments Nicolas Saenz Julienne
2019-09-24 18:12   ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 18:12   ` Nicolas Saenz Julienne
2019-09-24 21:59 ` [PATCH 00/11] of: Fix DMA configuration for non-DT masters Rob Herring
2019-09-24 21:59   ` [Xen-devel] " Rob Herring
2019-09-24 21:59   ` Rob Herring
2019-09-24 21:59   ` Rob Herring
2019-09-25 14:52   ` Nicolas Saenz Julienne
2019-09-25 14:52     ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-25 14:52     ` Nicolas Saenz Julienne
2019-09-25 14:52     ` Nicolas Saenz Julienne
2019-09-25 15:09     ` Robin Murphy
2019-09-25 15:09       ` [Xen-devel] " Robin Murphy
2019-09-25 15:09       ` Robin Murphy
2019-09-25 15:09       ` Robin Murphy
2019-09-25 15:30       ` Nicolas Saenz Julienne
2019-09-25 15:30         ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-25 15:30         ` Nicolas Saenz Julienne
2019-09-25 15:30         ` Nicolas Saenz Julienne
2019-09-25 16:16         ` Rob Herring
2019-09-25 16:16           ` [Xen-devel] " Rob Herring
2019-09-25 16:16           ` Rob Herring
2019-09-25 16:16           ` Rob Herring
2019-09-25 16:52           ` Robin Murphy
2019-09-25 16:52             ` [Xen-devel] " Robin Murphy
2019-09-25 16:52             ` Robin Murphy
2019-09-25 16:52             ` Robin Murphy
2019-09-25 21:33             ` Rob Herring
2019-09-25 21:33               ` [Xen-devel] " Rob Herring
2019-09-25 21:33               ` Rob Herring
2019-09-25 21:33               ` Rob Herring
2019-09-26 10:44               ` Nicolas Saenz Julienne
2019-09-26 10:44                 ` [Xen-devel] " Nicolas Saenz Julienne
2019-09-26 10:44                 ` Nicolas Saenz Julienne
2019-09-26 10:44                 ` Nicolas Saenz Julienne
2019-09-26 11:20                 ` Robin Murphy
2019-09-26 11:20                   ` [Xen-devel] " Robin Murphy
2019-09-26 11:20                   ` Robin Murphy
2019-09-26 11:20                   ` Robin Murphy
2019-10-02 18:28                   ` Florian Fainelli
2019-10-02 18:28                     ` [Xen-devel] " Florian Fainelli
2019-10-02 18:28                     ` Florian Fainelli
2019-10-02 18:28                     ` Florian Fainelli
2019-09-25 16:07     ` Rob Herring
2019-09-25 16:07       ` [Xen-devel] " Rob Herring
2019-09-25 16:07       ` Rob Herring
2019-09-25 16:07       ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190924181244.7159-1-nsaenzjulienne@suse.de \
    --to=nsaenzjulienne@suse.de \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=f.fainelli@gmail.com \
    --cc=freedreno@lists.freedesktop.org \
    --cc=frowand.list@gmail.com \
    --cc=james.quinlan@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mbrugger@suse.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=wahrenst@gmx.net \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.