All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-05 13:16 ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization

Hi Vinod, Bjorn, Patrice,

This patchset adds support for the Flexible Direct Memory Access (FDMA) core
found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU
with a dedicated firmware. It is a general purpose DMA controller supporting
16 independent channels and data can be moved from memory to memory or between
memory and paced latency critical real time targets.

After quite a few review rounds, I'm hoping this series can get taken for v4.9.

After some discussion with the DT maintainers I've removed the firmware
name from DT, and now generate the name based on the compatible string.

I've also dropped the dma xbar support for the moment, as I believe it should be
re-worked based on some of the xbar API's that TI recently added.

V3 also included some updates to the ASoC st,sti-asoc-card.txt DT documentation
to make the doc align with the driver code. These patches have already been applied
and are now dropped from this series. Other changes included enabling the ASoC drivers
in multi_v7 defconfig and adding DT patches for Patrices STi DT tree to enable ASoC
on STiH407/10 based platforms using the fdma driver.

v4 includes a new slim core rproc driver for loading the slim elf firmware. This
enables us to use the generic rproc elf loading code. This has deliberately not
been implemented as a platform_driver, to avoid having to have double mappings of
I/O memory from two device drivers, and also to ensure that the DT node reflects
the actual hardware rather than Linux subsystems. The slim core is the basis
for various pieces of IP in STi chipsets and the intention is that other drivers
(e.g. demux) can also be migrated over to using the slim rproc for their
elf firmware loading and start/stop control.

v5 includes various updates from Bjorn related to the slim rproc implementation.
It also includes a patch to make rsc_table optional in remoteproc_core and various
other cleanups and review feedback from Vinod to do with the actual fdma
implementation. It also fixes a regression introduced in v4 when all drivers are
built-in spotted by Aranud.

v6 goes back to having a dummy rsc_table and fixes some kbuild warnings. However
a change is still required in rproc core when all drivers are built-in as the initial
async firmware resource table parsing can fail when built-in, which causes subsequent calls
to rproc_boot() to also fail. V6 changes this behaviour to retry rproc_fw_config_virtio()
from rproc_boot(), in cases where it previously failed, as at this point we know the
irmwaref has been successfully obtained.

v7 removes all remoteproc core changes required to get -EPROBE_DEFER working properly
when firmware resides on a rootfs and compiling as built-in. The fdma driver now relies on
the firmware being available in the initramfs when building fdma as built-in. This has
been tested and works well. If remoteproc subsystem implements a new mechanism for
firmware on late mounted root filesystems, we can migrate this driver over to use it
at that point.

v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
slim_rproc driver. The series has also been rebased on v4.8-rc3.

v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
was found during testing now that the platform boots without clk_ignore_unused parameter
whereby the clocks would not be enabled properly before firmware loading was attempted.

regards,

Peter.

Changes since v8:
 - Add MODULE_ALIAS (Vinod)
 - devm_kzalloc to devm_kcalloc (Vinod)
 - quisce tasklet initialised by vchan_init() (Vinod)
 - Don't make SLIM rproc user selectable (Bjorn)
 - slim_rproc: Ensure clocks enabled before firmware load (Peter)
 - Various code style nits / commit message change (Lee)
 - Separate patch for '\n' kconfig removal (Vinod)

Changes since v7:
 - Rebase on v4.8-rc3 (Peter)
 - Double check that len is <= mem[i].size (Bjorn)
 - Remove if (!fw) checks (Bjorn)
 - Omit reference from fw_ops struct (Bjorn)
 - Call rproc_del() before rproc_put() (Bjorn)
 - Fix some odd line breaks (Bjorn)
 - Rename SLIM_* and slim_* with st prefix (Bjorn)

Changes since v6:
 - Fix recursive Kconfig warning (Patrice)
 - Fix various Intel zero day compiler warnings
 - Remove all changes related to late firmware load (now relies on initramfs) (Peter)

Changes since v5:
 - Remove optional rsc table and go back to dummy resource table (Bjorn)
 - Retry rproc_fw_config_virtio() from rproc_boot() if previously failed (Peter)
 - Fixup some kbuild warnings
 - rebase on v4.7-rc5
 - Remove some patches which were merged via ASoC tree

Changes since v4:
 - Make rsc table optional in remoteproc (Peter)
 - Various fixups to STi audio DT nodes (Arnaud)
 - Bulk rename of xp70 to slim (Peter)
 - Update my email to @linaro.org (Lee)
 - rebase on v4.7-rc2 (Peter)
 - Don't make ST_SLIM_REMOTEPROC user selectable (Bjorn)
 - -EPROBE_DEFER if rproc_boot fails when allocating DMA channel (Arnaud / Peter)
 - Drop some unnecessary headers (Vinod / Bjorn)
 - Change to writel now we have several mappings (Bjorn)
 - Remove io_res, rproc, and some unused structure fields / #define (Bjorn)
 - put clks in error path, also put clks before rproc_put() (Bjorn)
 - Make enum less generic (Bjorn)
 - Make slim_rproc_alloc() return a st_slim_rproc reference (Bjorn)
 - Alphabetical naming in Kconfig & Makefile (Vinod)
 - Add FDMA prefix to REQ_CTRL* (Vinod)
 - Print ret on some error paths (Vinod)
 - Add some acked-by (Peter)

Changes since v3:
 - Remove elf loading code from fdma driver (Vinod)
 - Remove fdma_ prefix for clock names (Arnd)
 - Make _xlate use dma_get_any_channel rather than request_channel (Arnd)
 - Make a common function for _prep_ routines (Vinod)
 - Make driver depend on COMPILE_TEST (Arnd)
 - Remove unnecessary st_fdma_filter_fn (Arnd)
 - Enable FDMA as a module (Arnd)
 - Drop fdma_ clock prefix (Arnd)
 - Fix description as well as example for st, prefix (Arnd)
 - Remove string concatenation from fdma register macros to ease grep'ability (Arnd)
 - Add a XP70 rproc driver for ELF firmware loading and start/stop control (Peter)
 - Add myself as a author of the driver (Peter)

Changes since v2:
 - Change to dma-controller (Arnd)
 - Remove platform data header file and simplifiy code (Arnd)
 - Remove FW_LOADER_USER_HELPER_FALLBACK and rework firmware loading to device config (Vinod)
 - Use SET_RUNTIME_PM_OPS helpers (Vinod)
 - Remove fdma-id dt prop and use compatibles to generate different fdma firmware names (Arnd / Lee)
 - Add sti-asoc-card DT nodes and pinmux config for uniperif player & reader (Peter)
 - Update sti-asoc-card DT binding documentation (Peter)
 - Enable STi audio drivers in multi_v7_defconfig (Peter)

Changes since v1:
 - split into smaller patches for easier / faster review (Vinod)
 - new fill_hw_mode() with common code (Vinod)
 - new config_reqctrl() called from *_prep() instead of device_config cb (Vinod)
 - fdma-xbar support removed (Peter)
 - rework firmware name mechanism so fwname isn't in DT (Peter / Lee)
 - st_fdma_seg_to_mem can be static (Paul)
 - EXPORT_SYMBOL st_fdma_filter_fn not required (Paul)
 - s/channel/channels (vinod)
 - better describe "Must be <3>" (vinod)
 - sizeof(*ehdr) (vinod)
 - print values on error debug (vinod)
 - empty line (Vinod)
 - Update to -EIO (Vinod)
 - Make st_fdma tristate (Paul)
 - Remove __exit tag from .remove (Maxime)
 - Update MAINTAINERS rule to fdma* (Lee)
 - Unit address should match reg property (Lee)

Peter Griffin (19):
  remoteproc: st_slim_rproc: add a slimcore rproc driver
  MAINTAINERS: Add st slim core rproc driver to STi section.
  dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding
    documentation
  dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file
  dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
  ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
  MAINTAINERS: Add FDMA driver files to STi section.
  ARM: multi_v7_defconfig: Enable STi FDMA driver
  ARM: multi_v7_defconfig: Enable STi and simple-card drivers.
  ARM: DT: STiH407: Add i2s_out pinctrl configuration
  ARM: DT: STiH407: Add i2s_in pinctrl configuration
  ARM: DT: STiH407: Add spdif_out pinctrl config
  ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
  ARM: STi: DT: STiH407: Add uniperif player dt nodes
  ARM: STi: DT: STiH407: Add uniperif reader dt nodes
  ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
  drm/virtio: kconfig: Fix recursive dependency issue.
  drm/virtio: kconfig: Fixup white space.
  dmaengine: kconfig: Remove superfluous '\n'

 Documentation/devicetree/bindings/dma/st_fdma.txt |  87 +++
 MAINTAINERS                                       |   3 +
 arch/arm/boot/dts/stih407-family.dtsi             | 167 ++++
 arch/arm/boot/dts/stih407-pinctrl.dtsi            |  55 ++
 arch/arm/boot/dts/stihxxx-b2120.dtsi              |  45 ++
 arch/arm/configs/multi_v7_defconfig               |   4 +
 drivers/dma/Kconfig                               |  14 +-
 drivers/dma/Makefile                              |   1 +
 drivers/dma/st_fdma.c                             | 899 ++++++++++++++++++++++
 drivers/dma/st_fdma.h                             | 249 ++++++
 drivers/gpu/drm/virtio/Kconfig                    |   9 +-
 drivers/remoteproc/Kconfig                        |   4 +
 drivers/remoteproc/Makefile                       |   1 +
 drivers/remoteproc/st_slim_rproc.c                | 364 +++++++++
 include/linux/remoteproc/st_slim_rproc.h          |  58 ++
 15 files changed, 1955 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt
 create mode 100644 drivers/dma/st_fdma.c
 create mode 100644 drivers/dma/st_fdma.h
 create mode 100644 drivers/remoteproc/st_slim_rproc.c
 create mode 100644 include/linux/remoteproc/st_slim_rproc.h

-- 
1.9.1

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-05 13:16 ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones

Hi Vinod, Bjorn, Patrice,

This patchset adds support for the Flexible Direct Memory Access (FDMA) core
found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU
with a dedicated firmware. It is a general purpose DMA controller supporting
16 independent channels and data can be moved from memory to memory or between
memory and paced latency critical real time targets.

After quite a few review rounds, I'm hoping this series can get taken for v4.9.

After some discussion with the DT maintainers I've removed the firmware
name from DT, and now generate the name based on the compatible string.

I've also dropped the dma xbar support for the moment, as I believe it should be
re-worked based on some of the xbar API's that TI recently added.

V3 also included some updates to the ASoC st,sti-asoc-card.txt DT documentation
to make the doc align with the driver code. These patches have already been applied
and are now dropped from this series. Other changes included enabling the ASoC drivers
in multi_v7 defconfig and adding DT patches for Patrices STi DT tree to enable ASoC
on STiH407/10 based platforms using the fdma driver.

v4 includes a new slim core rproc driver for loading the slim elf firmware. This
enables us to use the generic rproc elf loading code. This has deliberately not
been implemented as a platform_driver, to avoid having to have double mappings of
I/O memory from two device drivers, and also to ensure that the DT node reflects
the actual hardware rather than Linux subsystems. The slim core is the basis
for various pieces of IP in STi chipsets and the intention is that other drivers
(e.g. demux) can also be migrated over to using the slim rproc for their
elf firmware loading and start/stop control.

v5 includes various updates from Bjorn related to the slim rproc implementation.
It also includes a patch to make rsc_table optional in remoteproc_core and various
other cleanups and review feedback from Vinod to do with the actual fdma
implementation. It also fixes a regression introduced in v4 when all drivers are
built-in spotted by Aranud.

v6 goes back to having a dummy rsc_table and fixes some kbuild warnings. However
a change is still required in rproc core when all drivers are built-in as the initial
async firmware resource table parsing can fail when built-in, which causes subsequent calls
to rproc_boot() to also fail. V6 changes this behaviour to retry rproc_fw_config_virtio()
from rproc_boot(), in cases where it previously failed, as at this point we know the
irmwaref has been successfully obtained.

v7 removes all remoteproc core changes required to get -EPROBE_DEFER working properly
when firmware resides on a rootfs and compiling as built-in. The fdma driver now relies on
the firmware being available in the initramfs when building fdma as built-in. This has
been tested and works well. If remoteproc subsystem implements a new mechanism for
firmware on late mounted root filesystems, we can migrate this driver over to use it
at that point.

v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
slim_rproc driver. The series has also been rebased on v4.8-rc3.

v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
was found during testing now that the platform boots without clk_ignore_unused parameter
whereby the clocks would not be enabled properly before firmware loading was attempted.

regards,

Peter.

Changes since v8:
 - Add MODULE_ALIAS (Vinod)
 - devm_kzalloc to devm_kcalloc (Vinod)
 - quisce tasklet initialised by vchan_init() (Vinod)
 - Don't make SLIM rproc user selectable (Bjorn)
 - slim_rproc: Ensure clocks enabled before firmware load (Peter)
 - Various code style nits / commit message change (Lee)
 - Separate patch for '\n' kconfig removal (Vinod)

Changes since v7:
 - Rebase on v4.8-rc3 (Peter)
 - Double check that len is <= mem[i].size (Bjorn)
 - Remove if (!fw) checks (Bjorn)
 - Omit reference from fw_ops struct (Bjorn)
 - Call rproc_del() before rproc_put() (Bjorn)
 - Fix some odd line breaks (Bjorn)
 - Rename SLIM_* and slim_* with st prefix (Bjorn)

Changes since v6:
 - Fix recursive Kconfig warning (Patrice)
 - Fix various Intel zero day compiler warnings
 - Remove all changes related to late firmware load (now relies on initramfs) (Peter)

Changes since v5:
 - Remove optional rsc table and go back to dummy resource table (Bjorn)
 - Retry rproc_fw_config_virtio() from rproc_boot() if previously failed (Peter)
 - Fixup some kbuild warnings
 - rebase on v4.7-rc5
 - Remove some patches which were merged via ASoC tree

Changes since v4:
 - Make rsc table optional in remoteproc (Peter)
 - Various fixups to STi audio DT nodes (Arnaud)
 - Bulk rename of xp70 to slim (Peter)
 - Update my email to @linaro.org (Lee)
 - rebase on v4.7-rc2 (Peter)
 - Don't make ST_SLIM_REMOTEPROC user selectable (Bjorn)
 - -EPROBE_DEFER if rproc_boot fails when allocating DMA channel (Arnaud / Peter)
 - Drop some unnecessary headers (Vinod / Bjorn)
 - Change to writel now we have several mappings (Bjorn)
 - Remove io_res, rproc, and some unused structure fields / #define (Bjorn)
 - put clks in error path, also put clks before rproc_put() (Bjorn)
 - Make enum less generic (Bjorn)
 - Make slim_rproc_alloc() return a st_slim_rproc reference (Bjorn)
 - Alphabetical naming in Kconfig & Makefile (Vinod)
 - Add FDMA prefix to REQ_CTRL* (Vinod)
 - Print ret on some error paths (Vinod)
 - Add some acked-by (Peter)

Changes since v3:
 - Remove elf loading code from fdma driver (Vinod)
 - Remove fdma_ prefix for clock names (Arnd)
 - Make _xlate use dma_get_any_channel rather than request_channel (Arnd)
 - Make a common function for _prep_ routines (Vinod)
 - Make driver depend on COMPILE_TEST (Arnd)
 - Remove unnecessary st_fdma_filter_fn (Arnd)
 - Enable FDMA as a module (Arnd)
 - Drop fdma_ clock prefix (Arnd)
 - Fix description as well as example for st, prefix (Arnd)
 - Remove string concatenation from fdma register macros to ease grep'ability (Arnd)
 - Add a XP70 rproc driver for ELF firmware loading and start/stop control (Peter)
 - Add myself as a author of the driver (Peter)

Changes since v2:
 - Change to dma-controller (Arnd)
 - Remove platform data header file and simplifiy code (Arnd)
 - Remove FW_LOADER_USER_HELPER_FALLBACK and rework firmware loading to device config (Vinod)
 - Use SET_RUNTIME_PM_OPS helpers (Vinod)
 - Remove fdma-id dt prop and use compatibles to generate different fdma firmware names (Arnd / Lee)
 - Add sti-asoc-card DT nodes and pinmux config for uniperif player & reader (Peter)
 - Update sti-asoc-card DT binding documentation (Peter)
 - Enable STi audio drivers in multi_v7_defconfig (Peter)

Changes since v1:
 - split into smaller patches for easier / faster review (Vinod)
 - new fill_hw_mode() with common code (Vinod)
 - new config_reqctrl() called from *_prep() instead of device_config cb (Vinod)
 - fdma-xbar support removed (Peter)
 - rework firmware name mechanism so fwname isn't in DT (Peter / Lee)
 - st_fdma_seg_to_mem can be static (Paul)
 - EXPORT_SYMBOL st_fdma_filter_fn not required (Paul)
 - s/channel/channels (vinod)
 - better describe "Must be <3>" (vinod)
 - sizeof(*ehdr) (vinod)
 - print values on error debug (vinod)
 - empty line (Vinod)
 - Update to -EIO (Vinod)
 - Make st_fdma tristate (Paul)
 - Remove __exit tag from .remove (Maxime)
 - Update MAINTAINERS rule to fdma* (Lee)
 - Unit address should match reg property (Lee)

Peter Griffin (19):
  remoteproc: st_slim_rproc: add a slimcore rproc driver
  MAINTAINERS: Add st slim core rproc driver to STi section.
  dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding
    documentation
  dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file
  dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
  ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
  MAINTAINERS: Add FDMA driver files to STi section.
  ARM: multi_v7_defconfig: Enable STi FDMA driver
  ARM: multi_v7_defconfig: Enable STi and simple-card drivers.
  ARM: DT: STiH407: Add i2s_out pinctrl configuration
  ARM: DT: STiH407: Add i2s_in pinctrl configuration
  ARM: DT: STiH407: Add spdif_out pinctrl config
  ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
  ARM: STi: DT: STiH407: Add uniperif player dt nodes
  ARM: STi: DT: STiH407: Add uniperif reader dt nodes
  ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
  drm/virtio: kconfig: Fix recursive dependency issue.
  drm/virtio: kconfig: Fixup white space.
  dmaengine: kconfig: Remove superfluous '\n'

 Documentation/devicetree/bindings/dma/st_fdma.txt |  87 +++
 MAINTAINERS                                       |   3 +
 arch/arm/boot/dts/stih407-family.dtsi             | 167 ++++
 arch/arm/boot/dts/stih407-pinctrl.dtsi            |  55 ++
 arch/arm/boot/dts/stihxxx-b2120.dtsi              |  45 ++
 arch/arm/configs/multi_v7_defconfig               |   4 +
 drivers/dma/Kconfig                               |  14 +-
 drivers/dma/Makefile                              |   1 +
 drivers/dma/st_fdma.c                             | 899 ++++++++++++++++++++++
 drivers/dma/st_fdma.h                             | 249 ++++++
 drivers/gpu/drm/virtio/Kconfig                    |   9 +-
 drivers/remoteproc/Kconfig                        |   4 +
 drivers/remoteproc/Makefile                       |   1 +
 drivers/remoteproc/st_slim_rproc.c                | 364 +++++++++
 include/linux/remoteproc/st_slim_rproc.h          |  58 ++
 15 files changed, 1955 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt
 create mode 100644 drivers/dma/st_fdma.c
 create mode 100644 drivers/dma/st_fdma.h
 create mode 100644 drivers/remoteproc/st_slim_rproc.c
 create mode 100644 include/linux/remoteproc/st_slim_rproc.h

-- 
1.9.1

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-05 13:16 ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Vinod, Bjorn, Patrice,

This patchset adds support for the Flexible Direct Memory Access (FDMA) core
found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU
with a dedicated firmware. It is a general purpose DMA controller supporting
16 independent channels and data can be moved from memory to memory or between
memory and paced latency critical real time targets.

After quite a few review rounds, I'm hoping this series can get taken for v4.9.

After some discussion with the DT maintainers I've removed the firmware
name from DT, and now generate the name based on the compatible string.

I've also dropped the dma xbar support for the moment, as I believe it should be
re-worked based on some of the xbar API's that TI recently added.

V3 also included some updates to the ASoC st,sti-asoc-card.txt DT documentation
to make the doc align with the driver code. These patches have already been applied
and are now dropped from this series. Other changes included enabling the ASoC drivers
in multi_v7 defconfig and adding DT patches for Patrices STi DT tree to enable ASoC
on STiH407/10 based platforms using the fdma driver.

v4 includes a new slim core rproc driver for loading the slim elf firmware. This
enables us to use the generic rproc elf loading code. This has deliberately not
been implemented as a platform_driver, to avoid having to have double mappings of
I/O memory from two device drivers, and also to ensure that the DT node reflects
the actual hardware rather than Linux subsystems. The slim core is the basis
for various pieces of IP in STi chipsets and the intention is that other drivers
(e.g. demux) can also be migrated over to using the slim rproc for their
elf firmware loading and start/stop control.

v5 includes various updates from Bjorn related to the slim rproc implementation.
It also includes a patch to make rsc_table optional in remoteproc_core and various
other cleanups and review feedback from Vinod to do with the actual fdma
implementation. It also fixes a regression introduced in v4 when all drivers are
built-in spotted by Aranud.

v6 goes back to having a dummy rsc_table and fixes some kbuild warnings. However
a change is still required in rproc core when all drivers are built-in as the initial
async firmware resource table parsing can fail when built-in, which causes subsequent calls
to rproc_boot() to also fail. V6 changes this behaviour to retry rproc_fw_config_virtio()
from rproc_boot(), in cases where it previously failed, as at this point we know the
irmwaref has been successfully obtained.

v7 removes all remoteproc core changes required to get -EPROBE_DEFER working properly
when firmware resides on a rootfs and compiling as built-in. The fdma driver now relies on
the firmware being available in the initramfs when building fdma as built-in. This has
been tested and works well. If remoteproc subsystem implements a new mechanism for
firmware on late mounted root filesystems, we can migrate this driver over to use it
at that point.

v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
slim_rproc driver. The series has also been rebased on v4.8-rc3.

v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
was found during testing now that the platform boots without clk_ignore_unused parameter
whereby the clocks would not be enabled properly before firmware loading was attempted.

regards,

Peter.

Changes since v8:
 - Add MODULE_ALIAS (Vinod)
 - devm_kzalloc to devm_kcalloc (Vinod)
 - quisce tasklet initialised by vchan_init() (Vinod)
 - Don't make SLIM rproc user selectable (Bjorn)
 - slim_rproc: Ensure clocks enabled before firmware load (Peter)
 - Various code style nits / commit message change (Lee)
 - Separate patch for '\n' kconfig removal (Vinod)

Changes since v7:
 - Rebase on v4.8-rc3 (Peter)
 - Double check that len is <= mem[i].size (Bjorn)
 - Remove if (!fw) checks (Bjorn)
 - Omit reference from fw_ops struct (Bjorn)
 - Call rproc_del() before rproc_put() (Bjorn)
 - Fix some odd line breaks (Bjorn)
 - Rename SLIM_* and slim_* with st prefix (Bjorn)

Changes since v6:
 - Fix recursive Kconfig warning (Patrice)
 - Fix various Intel zero day compiler warnings
 - Remove all changes related to late firmware load (now relies on initramfs) (Peter)

Changes since v5:
 - Remove optional rsc table and go back to dummy resource table (Bjorn)
 - Retry rproc_fw_config_virtio() from rproc_boot() if previously failed (Peter)
 - Fixup some kbuild warnings
 - rebase on v4.7-rc5
 - Remove some patches which were merged via ASoC tree

Changes since v4:
 - Make rsc table optional in remoteproc (Peter)
 - Various fixups to STi audio DT nodes (Arnaud)
 - Bulk rename of xp70 to slim (Peter)
 - Update my email to @linaro.org (Lee)
 - rebase on v4.7-rc2 (Peter)
 - Don't make ST_SLIM_REMOTEPROC user selectable (Bjorn)
 - -EPROBE_DEFER if rproc_boot fails when allocating DMA channel (Arnaud / Peter)
 - Drop some unnecessary headers (Vinod / Bjorn)
 - Change to writel now we have several mappings (Bjorn)
 - Remove io_res, rproc, and some unused structure fields / #define (Bjorn)
 - put clks in error path, also put clks before rproc_put() (Bjorn)
 - Make enum less generic (Bjorn)
 - Make slim_rproc_alloc() return a st_slim_rproc reference (Bjorn)
 - Alphabetical naming in Kconfig & Makefile (Vinod)
 - Add FDMA prefix to REQ_CTRL* (Vinod)
 - Print ret on some error paths (Vinod)
 - Add some acked-by (Peter)

Changes since v3:
 - Remove elf loading code from fdma driver (Vinod)
 - Remove fdma_ prefix for clock names (Arnd)
 - Make _xlate use dma_get_any_channel rather than request_channel (Arnd)
 - Make a common function for _prep_ routines (Vinod)
 - Make driver depend on COMPILE_TEST (Arnd)
 - Remove unnecessary st_fdma_filter_fn (Arnd)
 - Enable FDMA as a module (Arnd)
 - Drop fdma_ clock prefix (Arnd)
 - Fix description as well as example for st, prefix (Arnd)
 - Remove string concatenation from fdma register macros to ease grep'ability (Arnd)
 - Add a XP70 rproc driver for ELF firmware loading and start/stop control (Peter)
 - Add myself as a author of the driver (Peter)

Changes since v2:
 - Change to dma-controller (Arnd)
 - Remove platform data header file and simplifiy code (Arnd)
 - Remove FW_LOADER_USER_HELPER_FALLBACK and rework firmware loading to device config (Vinod)
 - Use SET_RUNTIME_PM_OPS helpers (Vinod)
 - Remove fdma-id dt prop and use compatibles to generate different fdma firmware names (Arnd / Lee)
 - Add sti-asoc-card DT nodes and pinmux config for uniperif player & reader (Peter)
 - Update sti-asoc-card DT binding documentation (Peter)
 - Enable STi audio drivers in multi_v7_defconfig (Peter)

Changes since v1:
 - split into smaller patches for easier / faster review (Vinod)
 - new fill_hw_mode() with common code (Vinod)
 - new config_reqctrl() called from *_prep() instead of device_config cb (Vinod)
 - fdma-xbar support removed (Peter)
 - rework firmware name mechanism so fwname isn't in DT (Peter / Lee)
 - st_fdma_seg_to_mem can be static (Paul)
 - EXPORT_SYMBOL st_fdma_filter_fn not required (Paul)
 - s/channel/channels (vinod)
 - better describe "Must be <3>" (vinod)
 - sizeof(*ehdr) (vinod)
 - print values on error debug (vinod)
 - empty line (Vinod)
 - Update to -EIO (Vinod)
 - Make st_fdma tristate (Paul)
 - Remove __exit tag from .remove (Maxime)
 - Update MAINTAINERS rule to fdma* (Lee)
 - Unit address should match reg property (Lee)

Peter Griffin (19):
  remoteproc: st_slim_rproc: add a slimcore rproc driver
  MAINTAINERS: Add st slim core rproc driver to STi section.
  dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding
    documentation
  dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file
  dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
  ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
  MAINTAINERS: Add FDMA driver files to STi section.
  ARM: multi_v7_defconfig: Enable STi FDMA driver
  ARM: multi_v7_defconfig: Enable STi and simple-card drivers.
  ARM: DT: STiH407: Add i2s_out pinctrl configuration
  ARM: DT: STiH407: Add i2s_in pinctrl configuration
  ARM: DT: STiH407: Add spdif_out pinctrl config
  ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
  ARM: STi: DT: STiH407: Add uniperif player dt nodes
  ARM: STi: DT: STiH407: Add uniperif reader dt nodes
  ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
  drm/virtio: kconfig: Fix recursive dependency issue.
  drm/virtio: kconfig: Fixup white space.
  dmaengine: kconfig: Remove superfluous '\n'

 Documentation/devicetree/bindings/dma/st_fdma.txt |  87 +++
 MAINTAINERS                                       |   3 +
 arch/arm/boot/dts/stih407-family.dtsi             | 167 ++++
 arch/arm/boot/dts/stih407-pinctrl.dtsi            |  55 ++
 arch/arm/boot/dts/stihxxx-b2120.dtsi              |  45 ++
 arch/arm/configs/multi_v7_defconfig               |   4 +
 drivers/dma/Kconfig                               |  14 +-
 drivers/dma/Makefile                              |   1 +
 drivers/dma/st_fdma.c                             | 899 ++++++++++++++++++++++
 drivers/dma/st_fdma.h                             | 249 ++++++
 drivers/gpu/drm/virtio/Kconfig                    |   9 +-
 drivers/remoteproc/Kconfig                        |   4 +
 drivers/remoteproc/Makefile                       |   1 +
 drivers/remoteproc/st_slim_rproc.c                | 364 +++++++++
 include/linux/remoteproc/st_slim_rproc.h          |  58 ++
 15 files changed, 1955 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt
 create mode 100644 drivers/dma/st_fdma.c
 create mode 100644 drivers/dma/st_fdma.h
 create mode 100644 drivers/remoteproc/st_slim_rproc.c
 create mode 100644 include/linux/remoteproc/st_slim_rproc.h

-- 
1.9.1

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver
  2016-09-05 13:16 ` Peter Griffin
  (?)
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization

slim core is used as a basis for many IPs in the STi
chipsets such as fdma and demux. To avoid duplicating
the elf loading code in each device driver a slim
rproc driver has been created.

This driver is designed to be used by other device drivers
such as fdma, or demux whose IP is based around a slim core.
The device driver can call slim_rproc_alloc() to allocate
a slim rproc and slim_rproc_put() when finished.

This driver takes care of ioremapping the slim
registers (dmem, imem, slimcore, peripherals), whose offsets
and sizes can change between IP's. It also obtains and enables
any clocks used by the device. This approach avoids having
a double mapping of the registers as slim_rproc does not register
its own platform device. It also maps well to device tree
abstraction as it allows us to have one dt node for the whole
device.

All of the generic rproc elf loading code can be reused, and
we provide start() stop() hooks to start and stop the slim
core once the firmware has been loaded. This has been tested
successfully with fdma driver.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/remoteproc/Kconfig               |   4 +
 drivers/remoteproc/Makefile              |   1 +
 drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
 include/linux/remoteproc/st_slim_rproc.h |  58 +++++
 4 files changed, 427 insertions(+)
 create mode 100644 drivers/remoteproc/st_slim_rproc.c
 create mode 100644 include/linux/remoteproc/st_slim_rproc.h

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 1a8bf76a..a7bedc6 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -100,4 +100,8 @@ config ST_REMOTEPROC
 	  processor framework.
 	  This can be either built-in or a loadable module.
 
+config ST_SLIM_REMOTEPROC
+	tristate
+	select REMOTEPROC
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 92d3758..db1dae7 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
 obj-$(CONFIG_QCOM_MDT_LOADER)		+= qcom_mdt_loader.o
 obj-$(CONFIG_QCOM_Q6V5_PIL)		+= qcom_q6v5_pil.o
 obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
+obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
new file mode 100644
index 0000000..1484e97
--- /dev/null
+++ b/drivers/remoteproc/st_slim_rproc.c
@@ -0,0 +1,364 @@
+/*
+ * SLIM core rproc driver
+ *
+ * Copyright (C) 2016 STMicroelectronics
+ *
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc.h>
+#include <linux/remoteproc/st_slim_rproc.h>
+#include "remoteproc_internal.h"
+
+/* SLIM core registers */
+#define SLIM_ID_OFST		0x0
+#define SLIM_VER_OFST		0x4
+
+#define SLIM_EN_OFST		0x8
+#define SLIM_EN_RUN			BIT(0)
+
+#define SLIM_CLK_GATE_OFST	0xC
+#define SLIM_CLK_GATE_DIS		BIT(0)
+#define SLIM_CLK_GATE_RESET		BIT(2)
+
+#define SLIM_SLIM_PC_OFST	0x20
+
+/* DMEM registers */
+#define SLIM_REV_ID_OFST	0x0
+#define SLIM_REV_ID_MIN_MASK		GENMASK(15, 8)
+#define SLIM_REV_ID_MIN(id)		((id & SLIM_REV_ID_MIN_MASK) >> 8)
+#define SLIM_REV_ID_MAJ_MASK		GENMASK(23, 16)
+#define SLIM_REV_ID_MAJ(id)		((id & SLIM_REV_ID_MAJ_MASK) >> 16)
+
+
+/* peripherals registers */
+#define SLIM_STBUS_SYNC_OFST	0xF88
+#define SLIM_STBUS_SYNC_DIS		BIT(0)
+
+#define SLIM_INT_SET_OFST	0xFD4
+#define SLIM_INT_CLR_OFST	0xFD8
+#define SLIM_INT_MASK_OFST	0xFDC
+
+#define SLIM_CMD_CLR_OFST	0xFC8
+#define SLIM_CMD_MASK_OFST	0xFCC
+
+static const char *mem_names[ST_SLIM_MEM_MAX] = {
+	[ST_SLIM_DMEM]	= "dmem",
+	[ST_SLIM_IMEM]	= "imem",
+};
+
+static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
+{
+	int clk, err;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
+		slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
+		if (IS_ERR(slim_rproc->clks[clk])) {
+			err = PTR_ERR(slim_rproc->clks[clk]);
+			if (err == -EPROBE_DEFER)
+				goto err_put_clks;
+			slim_rproc->clks[clk] = NULL;
+			break;
+		}
+	}
+
+	return 0;
+
+err_put_clks:
+	while (--clk >= 0)
+		clk_put(slim_rproc->clks[clk]);
+
+	return err;
+}
+
+static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
+{
+	int clk;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
+		clk_disable_unprepare(slim_rproc->clks[clk]);
+}
+
+static int slim_clk_enable(struct st_slim_rproc *slim_rproc)
+{
+	int clk, ret;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++) {
+		ret = clk_prepare_enable(slim_rproc->clks[clk]);
+		if (ret)
+			goto err_disable_clks;
+	}
+
+	return 0;
+
+err_disable_clks:
+	while (--clk >= 0)
+		clk_disable_unprepare(slim_rproc->clks[clk]);
+
+	return ret;
+}
+
+/*
+ * Remoteproc slim specific device handlers
+ */
+static int slim_rproc_start(struct rproc *rproc)
+{
+	struct device *dev = &rproc->dev;
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	unsigned long hw_id, hw_ver, fw_rev;
+	u32 val;
+
+	/* disable CPU pipeline clock & reset CPU pipeline */
+	val = SLIM_CLK_GATE_DIS | SLIM_CLK_GATE_RESET;
+	writel(val, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	/* disable SLIM core STBus sync */
+	writel(SLIM_STBUS_SYNC_DIS, slim_rproc->peri + SLIM_STBUS_SYNC_OFST);
+
+	/* enable cpu pipeline clock */
+	writel(!SLIM_CLK_GATE_DIS,
+		slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	/* clear int & cmd mailbox */
+	writel(~0U, slim_rproc->peri + SLIM_INT_CLR_OFST);
+	writel(~0U, slim_rproc->peri + SLIM_CMD_CLR_OFST);
+
+	/* enable all channels cmd & int */
+	writel(~0U, slim_rproc->peri + SLIM_INT_MASK_OFST);
+	writel(~0U, slim_rproc->peri + SLIM_CMD_MASK_OFST);
+
+	/* enable cpu */
+	writel(SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
+
+	hw_id = readl_relaxed(slim_rproc->slimcore + SLIM_ID_OFST);
+	hw_ver = readl_relaxed(slim_rproc->slimcore + SLIM_VER_OFST);
+
+	fw_rev = readl(slim_rproc->mem[ST_SLIM_DMEM].cpu_addr +
+			SLIM_REV_ID_OFST);
+
+	dev_info(dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
+		 SLIM_REV_ID_MAJ(fw_rev), SLIM_REV_ID_MIN(fw_rev),
+		 hw_id, hw_ver);
+
+	return 0;
+}
+
+static int slim_rproc_stop(struct rproc *rproc)
+{
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	u32 val;
+
+	/* mask all (cmd & int) channels */
+	writel(0UL, slim_rproc->peri + SLIM_INT_MASK_OFST);
+	writel(0UL, slim_rproc->peri + SLIM_CMD_MASK_OFST);
+
+	/* disable cpu pipeline clock */
+	writel(SLIM_CLK_GATE_DIS, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	writel(!SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
+
+	val = readl(slim_rproc->slimcore + SLIM_EN_OFST);
+	if (val & SLIM_EN_RUN)
+		dev_warn(&rproc->dev, "Failed to disable SLIM");
+
+	dev_dbg(&rproc->dev, "slim stopped\n");
+
+	return 0;
+}
+
+static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+{
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	void *va = NULL;
+	int i;
+
+	for (i = 0; i < ST_SLIM_MEM_MAX; i++) {
+		if (da != slim_rproc->mem[i].bus_addr)
+			continue;
+
+		if (len <= slim_rproc->mem[i].size) {
+			/* __force to make sparse happy with type conversion */
+			va = (__force void *)slim_rproc->mem[i].cpu_addr;
+			break;
+		}
+	}
+
+	dev_dbg(&rproc->dev, "da = 0x%llx len = 0x%x va = 0x%p\n", da, len, va);
+
+	return va;
+}
+
+static struct rproc_ops slim_rproc_ops = {
+	.start		= slim_rproc_start,
+	.stop		= slim_rproc_stop,
+	.da_to_va       = slim_rproc_da_to_va,
+};
+
+/*
+ * Firmware handler operations: sanity, boot address, load ...
+ */
+
+static struct resource_table empty_rsc_tbl = {
+	.ver = 1,
+	.num = 0,
+};
+
+static struct resource_table *slim_rproc_find_rsc_table(struct rproc *rproc,
+					       const struct firmware *fw,
+					       int *tablesz)
+{
+	*tablesz = sizeof(empty_rsc_tbl);
+	return &empty_rsc_tbl;
+}
+
+static struct rproc_fw_ops slim_rproc_fw_ops = {
+	.find_rsc_table = slim_rproc_find_rsc_table,
+};
+
+/**
+ * st_slim_rproc_alloc() - allocate and initialise slim rproc
+ * @pdev: Pointer to the platform_device struct
+ * @fw_name: Name of firmware for rproc to use
+ *
+ * Function for allocating and initialising a slim rproc for use by
+ * device drivers whose IP is based around the SLIM core. It
+ * obtains and enables any clocks required by the SLIM core and also
+ * ioremaps the various IO.
+ *
+ * Returns st_slim_rproc pointer or PTR_ERR() on error.
+ */
+
+struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
+				char *fw_name)
+{
+	struct device *dev = &pdev->dev;
+	struct st_slim_rproc *slim_rproc;
+	struct device_node *np = dev->of_node;
+	struct rproc *rproc;
+	struct resource *res;
+	int err, i;
+	const struct rproc_fw_ops *elf_ops;
+
+	if (!fw_name)
+		return ERR_PTR(-EINVAL);
+
+	if (!of_device_is_compatible(np, "st,slim-rproc"))
+		return ERR_PTR(-EINVAL);
+
+	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
+			fw_name, sizeof(*slim_rproc));
+	if (!rproc)
+		return ERR_PTR(-ENOMEM);
+
+	rproc->has_iommu = false;
+
+	slim_rproc = rproc->priv;
+	slim_rproc->rproc = rproc;
+
+	elf_ops = rproc->fw_ops;
+	/* Use some generic elf ops */
+	slim_rproc_fw_ops.load = elf_ops->load;
+	slim_rproc_fw_ops.sanity_check = elf_ops->sanity_check;
+
+	rproc->fw_ops = &slim_rproc_fw_ops;
+
+	/* get imem and dmem */
+	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
+		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+						mem_names[i]);
+
+		slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
+		if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
+			dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
+			err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
+			goto err;
+		}
+		slim_rproc->mem[i].bus_addr = res->start;
+		slim_rproc->mem[i].size = resource_size(res);
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
+	slim_rproc->slimcore = devm_ioremap_resource(dev, res);
+	if (IS_ERR(slim_rproc->slimcore)) {
+		dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
+		err = PTR_ERR(slim_rproc->slimcore);
+		goto err;
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
+	slim_rproc->peri = devm_ioremap_resource(dev, res);
+	if (IS_ERR(slim_rproc->peri)) {
+		dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
+		err = PTR_ERR(slim_rproc->peri);
+		goto err;
+	}
+
+	err = slim_clk_get(slim_rproc, dev);
+	if (err)
+		goto err;
+
+	err = slim_clk_enable(slim_rproc);
+	if (err) {
+		dev_err(dev, "Failed to enable clocks\n");
+		goto err_clk_put;
+	}
+
+	/* Register as a remoteproc device */
+	err = rproc_add(rproc);
+	if (err) {
+		dev_err(dev, "registration of slim remoteproc failed\n");
+		goto err_clk_dis;
+	}
+
+	return slim_rproc;
+
+err_clk_dis:
+	slim_clk_disable(slim_rproc);
+err_clk_put:
+	for (i = 0; i < ST_SLIM_MAX_CLK && slim_rproc->clks[i]; i++)
+		clk_put(slim_rproc->clks[i]);
+err:
+	rproc_put(rproc);
+	return ERR_PTR(err);
+}
+EXPORT_SYMBOL(st_slim_rproc_alloc);
+
+/**
+  * st_slim_rproc_put() - put slim rproc resources
+  * @slim_rproc: Pointer to the st_slim_rproc struct
+  *
+  * Function for calling respective _put() functions on slim_rproc resources.
+  *
+  */
+void st_slim_rproc_put(struct st_slim_rproc *slim_rproc)
+{
+	int clk;
+
+	if (!slim_rproc)
+		return;
+
+	slim_clk_disable(slim_rproc);
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
+		clk_put(slim_rproc->clks[clk]);
+
+	rproc_del(slim_rproc->rproc);
+	rproc_put(slim_rproc->rproc);
+}
+EXPORT_SYMBOL(st_slim_rproc_put);
+
+MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
+MODULE_DESCRIPTION("STMicroelectronics SLIM core rproc driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/remoteproc/st_slim_rproc.h b/include/linux/remoteproc/st_slim_rproc.h
new file mode 100644
index 0000000..4155556
--- /dev/null
+++ b/include/linux/remoteproc/st_slim_rproc.h
@@ -0,0 +1,58 @@
+/*
+ * SLIM core rproc driver header
+ *
+ * Copyright (C) 2016 STMicroelectronics
+ *
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef _ST_REMOTEPROC_SLIM_H
+#define _ST_REMOTEPROC_SLIM_H
+
+#define ST_SLIM_MEM_MAX 2
+#define ST_SLIM_MAX_CLK 4
+
+enum {
+	ST_SLIM_DMEM,
+	ST_SLIM_IMEM,
+};
+
+/**
+ * struct st_slim_mem - slim internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @size: Size of the memory region
+ */
+struct st_slim_mem {
+	void __iomem *cpu_addr;
+	phys_addr_t bus_addr;
+	size_t size;
+};
+
+/**
+ * struct st_slim_rproc - SLIM slim core
+ * @rproc: rproc handle
+ * @mem: slim memory information
+ * @slimcore: slim slimcore regs
+ * @peri: slim peripheral regs
+ * @clks: slim clocks
+ */
+struct st_slim_rproc {
+	struct rproc *rproc;
+	struct st_slim_mem mem[ST_SLIM_MEM_MAX];
+	void __iomem *slimcore;
+	void __iomem *peri;
+
+	/* st_slim_rproc private */
+	struct clk *clks[ST_SLIM_MAX_CLK];
+};
+
+struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
+					char *fw_name);
+void st_slim_rproc_put(struct st_slim_rproc *slim_rproc);
+
+#endif
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones

slim core is used as a basis for many IPs in the STi
chipsets such as fdma and demux. To avoid duplicating
the elf loading code in each device driver a slim
rproc driver has been created.

This driver is designed to be used by other device drivers
such as fdma, or demux whose IP is based around a slim core.
The device driver can call slim_rproc_alloc() to allocate
a slim rproc and slim_rproc_put() when finished.

This driver takes care of ioremapping the slim
registers (dmem, imem, slimcore, peripherals), whose offsets
and sizes can change between IP's. It also obtains and enables
any clocks used by the device. This approach avoids having
a double mapping of the registers as slim_rproc does not register
its own platform device. It also maps well to device tree
abstraction as it allows us to have one dt node for the whole
device.

All of the generic rproc elf loading code can be reused, and
we provide start() stop() hooks to start and stop the slim
core once the firmware has been loaded. This has been tested
successfully with fdma driver.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/remoteproc/Kconfig               |   4 +
 drivers/remoteproc/Makefile              |   1 +
 drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
 include/linux/remoteproc/st_slim_rproc.h |  58 +++++
 4 files changed, 427 insertions(+)
 create mode 100644 drivers/remoteproc/st_slim_rproc.c
 create mode 100644 include/linux/remoteproc/st_slim_rproc.h

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 1a8bf76a..a7bedc6 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -100,4 +100,8 @@ config ST_REMOTEPROC
 	  processor framework.
 	  This can be either built-in or a loadable module.
 
+config ST_SLIM_REMOTEPROC
+	tristate
+	select REMOTEPROC
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 92d3758..db1dae7 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
 obj-$(CONFIG_QCOM_MDT_LOADER)		+= qcom_mdt_loader.o
 obj-$(CONFIG_QCOM_Q6V5_PIL)		+= qcom_q6v5_pil.o
 obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
+obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
new file mode 100644
index 0000000..1484e97
--- /dev/null
+++ b/drivers/remoteproc/st_slim_rproc.c
@@ -0,0 +1,364 @@
+/*
+ * SLIM core rproc driver
+ *
+ * Copyright (C) 2016 STMicroelectronics
+ *
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc.h>
+#include <linux/remoteproc/st_slim_rproc.h>
+#include "remoteproc_internal.h"
+
+/* SLIM core registers */
+#define SLIM_ID_OFST		0x0
+#define SLIM_VER_OFST		0x4
+
+#define SLIM_EN_OFST		0x8
+#define SLIM_EN_RUN			BIT(0)
+
+#define SLIM_CLK_GATE_OFST	0xC
+#define SLIM_CLK_GATE_DIS		BIT(0)
+#define SLIM_CLK_GATE_RESET		BIT(2)
+
+#define SLIM_SLIM_PC_OFST	0x20
+
+/* DMEM registers */
+#define SLIM_REV_ID_OFST	0x0
+#define SLIM_REV_ID_MIN_MASK		GENMASK(15, 8)
+#define SLIM_REV_ID_MIN(id)		((id & SLIM_REV_ID_MIN_MASK) >> 8)
+#define SLIM_REV_ID_MAJ_MASK		GENMASK(23, 16)
+#define SLIM_REV_ID_MAJ(id)		((id & SLIM_REV_ID_MAJ_MASK) >> 16)
+
+
+/* peripherals registers */
+#define SLIM_STBUS_SYNC_OFST	0xF88
+#define SLIM_STBUS_SYNC_DIS		BIT(0)
+
+#define SLIM_INT_SET_OFST	0xFD4
+#define SLIM_INT_CLR_OFST	0xFD8
+#define SLIM_INT_MASK_OFST	0xFDC
+
+#define SLIM_CMD_CLR_OFST	0xFC8
+#define SLIM_CMD_MASK_OFST	0xFCC
+
+static const char *mem_names[ST_SLIM_MEM_MAX] = {
+	[ST_SLIM_DMEM]	= "dmem",
+	[ST_SLIM_IMEM]	= "imem",
+};
+
+static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
+{
+	int clk, err;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
+		slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
+		if (IS_ERR(slim_rproc->clks[clk])) {
+			err = PTR_ERR(slim_rproc->clks[clk]);
+			if (err == -EPROBE_DEFER)
+				goto err_put_clks;
+			slim_rproc->clks[clk] = NULL;
+			break;
+		}
+	}
+
+	return 0;
+
+err_put_clks:
+	while (--clk >= 0)
+		clk_put(slim_rproc->clks[clk]);
+
+	return err;
+}
+
+static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
+{
+	int clk;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
+		clk_disable_unprepare(slim_rproc->clks[clk]);
+}
+
+static int slim_clk_enable(struct st_slim_rproc *slim_rproc)
+{
+	int clk, ret;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++) {
+		ret = clk_prepare_enable(slim_rproc->clks[clk]);
+		if (ret)
+			goto err_disable_clks;
+	}
+
+	return 0;
+
+err_disable_clks:
+	while (--clk >= 0)
+		clk_disable_unprepare(slim_rproc->clks[clk]);
+
+	return ret;
+}
+
+/*
+ * Remoteproc slim specific device handlers
+ */
+static int slim_rproc_start(struct rproc *rproc)
+{
+	struct device *dev = &rproc->dev;
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	unsigned long hw_id, hw_ver, fw_rev;
+	u32 val;
+
+	/* disable CPU pipeline clock & reset CPU pipeline */
+	val = SLIM_CLK_GATE_DIS | SLIM_CLK_GATE_RESET;
+	writel(val, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	/* disable SLIM core STBus sync */
+	writel(SLIM_STBUS_SYNC_DIS, slim_rproc->peri + SLIM_STBUS_SYNC_OFST);
+
+	/* enable cpu pipeline clock */
+	writel(!SLIM_CLK_GATE_DIS,
+		slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	/* clear int & cmd mailbox */
+	writel(~0U, slim_rproc->peri + SLIM_INT_CLR_OFST);
+	writel(~0U, slim_rproc->peri + SLIM_CMD_CLR_OFST);
+
+	/* enable all channels cmd & int */
+	writel(~0U, slim_rproc->peri + SLIM_INT_MASK_OFST);
+	writel(~0U, slim_rproc->peri + SLIM_CMD_MASK_OFST);
+
+	/* enable cpu */
+	writel(SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
+
+	hw_id = readl_relaxed(slim_rproc->slimcore + SLIM_ID_OFST);
+	hw_ver = readl_relaxed(slim_rproc->slimcore + SLIM_VER_OFST);
+
+	fw_rev = readl(slim_rproc->mem[ST_SLIM_DMEM].cpu_addr +
+			SLIM_REV_ID_OFST);
+
+	dev_info(dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
+		 SLIM_REV_ID_MAJ(fw_rev), SLIM_REV_ID_MIN(fw_rev),
+		 hw_id, hw_ver);
+
+	return 0;
+}
+
+static int slim_rproc_stop(struct rproc *rproc)
+{
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	u32 val;
+
+	/* mask all (cmd & int) channels */
+	writel(0UL, slim_rproc->peri + SLIM_INT_MASK_OFST);
+	writel(0UL, slim_rproc->peri + SLIM_CMD_MASK_OFST);
+
+	/* disable cpu pipeline clock */
+	writel(SLIM_CLK_GATE_DIS, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	writel(!SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
+
+	val = readl(slim_rproc->slimcore + SLIM_EN_OFST);
+	if (val & SLIM_EN_RUN)
+		dev_warn(&rproc->dev, "Failed to disable SLIM");
+
+	dev_dbg(&rproc->dev, "slim stopped\n");
+
+	return 0;
+}
+
+static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+{
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	void *va = NULL;
+	int i;
+
+	for (i = 0; i < ST_SLIM_MEM_MAX; i++) {
+		if (da != slim_rproc->mem[i].bus_addr)
+			continue;
+
+		if (len <= slim_rproc->mem[i].size) {
+			/* __force to make sparse happy with type conversion */
+			va = (__force void *)slim_rproc->mem[i].cpu_addr;
+			break;
+		}
+	}
+
+	dev_dbg(&rproc->dev, "da = 0x%llx len = 0x%x va = 0x%p\n", da, len, va);
+
+	return va;
+}
+
+static struct rproc_ops slim_rproc_ops = {
+	.start		= slim_rproc_start,
+	.stop		= slim_rproc_stop,
+	.da_to_va       = slim_rproc_da_to_va,
+};
+
+/*
+ * Firmware handler operations: sanity, boot address, load ...
+ */
+
+static struct resource_table empty_rsc_tbl = {
+	.ver = 1,
+	.num = 0,
+};
+
+static struct resource_table *slim_rproc_find_rsc_table(struct rproc *rproc,
+					       const struct firmware *fw,
+					       int *tablesz)
+{
+	*tablesz = sizeof(empty_rsc_tbl);
+	return &empty_rsc_tbl;
+}
+
+static struct rproc_fw_ops slim_rproc_fw_ops = {
+	.find_rsc_table = slim_rproc_find_rsc_table,
+};
+
+/**
+ * st_slim_rproc_alloc() - allocate and initialise slim rproc
+ * @pdev: Pointer to the platform_device struct
+ * @fw_name: Name of firmware for rproc to use
+ *
+ * Function for allocating and initialising a slim rproc for use by
+ * device drivers whose IP is based around the SLIM core. It
+ * obtains and enables any clocks required by the SLIM core and also
+ * ioremaps the various IO.
+ *
+ * Returns st_slim_rproc pointer or PTR_ERR() on error.
+ */
+
+struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
+				char *fw_name)
+{
+	struct device *dev = &pdev->dev;
+	struct st_slim_rproc *slim_rproc;
+	struct device_node *np = dev->of_node;
+	struct rproc *rproc;
+	struct resource *res;
+	int err, i;
+	const struct rproc_fw_ops *elf_ops;
+
+	if (!fw_name)
+		return ERR_PTR(-EINVAL);
+
+	if (!of_device_is_compatible(np, "st,slim-rproc"))
+		return ERR_PTR(-EINVAL);
+
+	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
+			fw_name, sizeof(*slim_rproc));
+	if (!rproc)
+		return ERR_PTR(-ENOMEM);
+
+	rproc->has_iommu = false;
+
+	slim_rproc = rproc->priv;
+	slim_rproc->rproc = rproc;
+
+	elf_ops = rproc->fw_ops;
+	/* Use some generic elf ops */
+	slim_rproc_fw_ops.load = elf_ops->load;
+	slim_rproc_fw_ops.sanity_check = elf_ops->sanity_check;
+
+	rproc->fw_ops = &slim_rproc_fw_ops;
+
+	/* get imem and dmem */
+	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
+		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+						mem_names[i]);
+
+		slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
+		if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
+			dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
+			err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
+			goto err;
+		}
+		slim_rproc->mem[i].bus_addr = res->start;
+		slim_rproc->mem[i].size = resource_size(res);
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
+	slim_rproc->slimcore = devm_ioremap_resource(dev, res);
+	if (IS_ERR(slim_rproc->slimcore)) {
+		dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
+		err = PTR_ERR(slim_rproc->slimcore);
+		goto err;
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
+	slim_rproc->peri = devm_ioremap_resource(dev, res);
+	if (IS_ERR(slim_rproc->peri)) {
+		dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
+		err = PTR_ERR(slim_rproc->peri);
+		goto err;
+	}
+
+	err = slim_clk_get(slim_rproc, dev);
+	if (err)
+		goto err;
+
+	err = slim_clk_enable(slim_rproc);
+	if (err) {
+		dev_err(dev, "Failed to enable clocks\n");
+		goto err_clk_put;
+	}
+
+	/* Register as a remoteproc device */
+	err = rproc_add(rproc);
+	if (err) {
+		dev_err(dev, "registration of slim remoteproc failed\n");
+		goto err_clk_dis;
+	}
+
+	return slim_rproc;
+
+err_clk_dis:
+	slim_clk_disable(slim_rproc);
+err_clk_put:
+	for (i = 0; i < ST_SLIM_MAX_CLK && slim_rproc->clks[i]; i++)
+		clk_put(slim_rproc->clks[i]);
+err:
+	rproc_put(rproc);
+	return ERR_PTR(err);
+}
+EXPORT_SYMBOL(st_slim_rproc_alloc);
+
+/**
+  * st_slim_rproc_put() - put slim rproc resources
+  * @slim_rproc: Pointer to the st_slim_rproc struct
+  *
+  * Function for calling respective _put() functions on slim_rproc resources.
+  *
+  */
+void st_slim_rproc_put(struct st_slim_rproc *slim_rproc)
+{
+	int clk;
+
+	if (!slim_rproc)
+		return;
+
+	slim_clk_disable(slim_rproc);
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
+		clk_put(slim_rproc->clks[clk]);
+
+	rproc_del(slim_rproc->rproc);
+	rproc_put(slim_rproc->rproc);
+}
+EXPORT_SYMBOL(st_slim_rproc_put);
+
+MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
+MODULE_DESCRIPTION("STMicroelectronics SLIM core rproc driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/remoteproc/st_slim_rproc.h b/include/linux/remoteproc/st_slim_rproc.h
new file mode 100644
index 0000000..4155556
--- /dev/null
+++ b/include/linux/remoteproc/st_slim_rproc.h
@@ -0,0 +1,58 @@
+/*
+ * SLIM core rproc driver header
+ *
+ * Copyright (C) 2016 STMicroelectronics
+ *
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef _ST_REMOTEPROC_SLIM_H
+#define _ST_REMOTEPROC_SLIM_H
+
+#define ST_SLIM_MEM_MAX 2
+#define ST_SLIM_MAX_CLK 4
+
+enum {
+	ST_SLIM_DMEM,
+	ST_SLIM_IMEM,
+};
+
+/**
+ * struct st_slim_mem - slim internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @size: Size of the memory region
+ */
+struct st_slim_mem {
+	void __iomem *cpu_addr;
+	phys_addr_t bus_addr;
+	size_t size;
+};
+
+/**
+ * struct st_slim_rproc - SLIM slim core
+ * @rproc: rproc handle
+ * @mem: slim memory information
+ * @slimcore: slim slimcore regs
+ * @peri: slim peripheral regs
+ * @clks: slim clocks
+ */
+struct st_slim_rproc {
+	struct rproc *rproc;
+	struct st_slim_mem mem[ST_SLIM_MEM_MAX];
+	void __iomem *slimcore;
+	void __iomem *peri;
+
+	/* st_slim_rproc private */
+	struct clk *clks[ST_SLIM_MAX_CLK];
+};
+
+struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
+					char *fw_name);
+void st_slim_rproc_put(struct st_slim_rproc *slim_rproc);
+
+#endif
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

slim core is used as a basis for many IPs in the STi
chipsets such as fdma and demux. To avoid duplicating
the elf loading code in each device driver a slim
rproc driver has been created.

This driver is designed to be used by other device drivers
such as fdma, or demux whose IP is based around a slim core.
The device driver can call slim_rproc_alloc() to allocate
a slim rproc and slim_rproc_put() when finished.

This driver takes care of ioremapping the slim
registers (dmem, imem, slimcore, peripherals), whose offsets
and sizes can change between IP's. It also obtains and enables
any clocks used by the device. This approach avoids having
a double mapping of the registers as slim_rproc does not register
its own platform device. It also maps well to device tree
abstraction as it allows us to have one dt node for the whole
device.

All of the generic rproc elf loading code can be reused, and
we provide start() stop() hooks to start and stop the slim
core once the firmware has been loaded. This has been tested
successfully with fdma driver.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/remoteproc/Kconfig               |   4 +
 drivers/remoteproc/Makefile              |   1 +
 drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
 include/linux/remoteproc/st_slim_rproc.h |  58 +++++
 4 files changed, 427 insertions(+)
 create mode 100644 drivers/remoteproc/st_slim_rproc.c
 create mode 100644 include/linux/remoteproc/st_slim_rproc.h

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 1a8bf76a..a7bedc6 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -100,4 +100,8 @@ config ST_REMOTEPROC
 	  processor framework.
 	  This can be either built-in or a loadable module.
 
+config ST_SLIM_REMOTEPROC
+	tristate
+	select REMOTEPROC
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 92d3758..db1dae7 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
 obj-$(CONFIG_QCOM_MDT_LOADER)		+= qcom_mdt_loader.o
 obj-$(CONFIG_QCOM_Q6V5_PIL)		+= qcom_q6v5_pil.o
 obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
+obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
new file mode 100644
index 0000000..1484e97
--- /dev/null
+++ b/drivers/remoteproc/st_slim_rproc.c
@@ -0,0 +1,364 @@
+/*
+ * SLIM core rproc driver
+ *
+ * Copyright (C) 2016 STMicroelectronics
+ *
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/remoteproc.h>
+#include <linux/remoteproc/st_slim_rproc.h>
+#include "remoteproc_internal.h"
+
+/* SLIM core registers */
+#define SLIM_ID_OFST		0x0
+#define SLIM_VER_OFST		0x4
+
+#define SLIM_EN_OFST		0x8
+#define SLIM_EN_RUN			BIT(0)
+
+#define SLIM_CLK_GATE_OFST	0xC
+#define SLIM_CLK_GATE_DIS		BIT(0)
+#define SLIM_CLK_GATE_RESET		BIT(2)
+
+#define SLIM_SLIM_PC_OFST	0x20
+
+/* DMEM registers */
+#define SLIM_REV_ID_OFST	0x0
+#define SLIM_REV_ID_MIN_MASK		GENMASK(15, 8)
+#define SLIM_REV_ID_MIN(id)		((id & SLIM_REV_ID_MIN_MASK) >> 8)
+#define SLIM_REV_ID_MAJ_MASK		GENMASK(23, 16)
+#define SLIM_REV_ID_MAJ(id)		((id & SLIM_REV_ID_MAJ_MASK) >> 16)
+
+
+/* peripherals registers */
+#define SLIM_STBUS_SYNC_OFST	0xF88
+#define SLIM_STBUS_SYNC_DIS		BIT(0)
+
+#define SLIM_INT_SET_OFST	0xFD4
+#define SLIM_INT_CLR_OFST	0xFD8
+#define SLIM_INT_MASK_OFST	0xFDC
+
+#define SLIM_CMD_CLR_OFST	0xFC8
+#define SLIM_CMD_MASK_OFST	0xFCC
+
+static const char *mem_names[ST_SLIM_MEM_MAX] = {
+	[ST_SLIM_DMEM]	= "dmem",
+	[ST_SLIM_IMEM]	= "imem",
+};
+
+static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
+{
+	int clk, err;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
+		slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
+		if (IS_ERR(slim_rproc->clks[clk])) {
+			err = PTR_ERR(slim_rproc->clks[clk]);
+			if (err == -EPROBE_DEFER)
+				goto err_put_clks;
+			slim_rproc->clks[clk] = NULL;
+			break;
+		}
+	}
+
+	return 0;
+
+err_put_clks:
+	while (--clk >= 0)
+		clk_put(slim_rproc->clks[clk]);
+
+	return err;
+}
+
+static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
+{
+	int clk;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
+		clk_disable_unprepare(slim_rproc->clks[clk]);
+}
+
+static int slim_clk_enable(struct st_slim_rproc *slim_rproc)
+{
+	int clk, ret;
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++) {
+		ret = clk_prepare_enable(slim_rproc->clks[clk]);
+		if (ret)
+			goto err_disable_clks;
+	}
+
+	return 0;
+
+err_disable_clks:
+	while (--clk >= 0)
+		clk_disable_unprepare(slim_rproc->clks[clk]);
+
+	return ret;
+}
+
+/*
+ * Remoteproc slim specific device handlers
+ */
+static int slim_rproc_start(struct rproc *rproc)
+{
+	struct device *dev = &rproc->dev;
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	unsigned long hw_id, hw_ver, fw_rev;
+	u32 val;
+
+	/* disable CPU pipeline clock & reset CPU pipeline */
+	val = SLIM_CLK_GATE_DIS | SLIM_CLK_GATE_RESET;
+	writel(val, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	/* disable SLIM core STBus sync */
+	writel(SLIM_STBUS_SYNC_DIS, slim_rproc->peri + SLIM_STBUS_SYNC_OFST);
+
+	/* enable cpu pipeline clock */
+	writel(!SLIM_CLK_GATE_DIS,
+		slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	/* clear int & cmd mailbox */
+	writel(~0U, slim_rproc->peri + SLIM_INT_CLR_OFST);
+	writel(~0U, slim_rproc->peri + SLIM_CMD_CLR_OFST);
+
+	/* enable all channels cmd & int */
+	writel(~0U, slim_rproc->peri + SLIM_INT_MASK_OFST);
+	writel(~0U, slim_rproc->peri + SLIM_CMD_MASK_OFST);
+
+	/* enable cpu */
+	writel(SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
+
+	hw_id = readl_relaxed(slim_rproc->slimcore + SLIM_ID_OFST);
+	hw_ver = readl_relaxed(slim_rproc->slimcore + SLIM_VER_OFST);
+
+	fw_rev = readl(slim_rproc->mem[ST_SLIM_DMEM].cpu_addr +
+			SLIM_REV_ID_OFST);
+
+	dev_info(dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
+		 SLIM_REV_ID_MAJ(fw_rev), SLIM_REV_ID_MIN(fw_rev),
+		 hw_id, hw_ver);
+
+	return 0;
+}
+
+static int slim_rproc_stop(struct rproc *rproc)
+{
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	u32 val;
+
+	/* mask all (cmd & int) channels */
+	writel(0UL, slim_rproc->peri + SLIM_INT_MASK_OFST);
+	writel(0UL, slim_rproc->peri + SLIM_CMD_MASK_OFST);
+
+	/* disable cpu pipeline clock */
+	writel(SLIM_CLK_GATE_DIS, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
+
+	writel(!SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
+
+	val = readl(slim_rproc->slimcore + SLIM_EN_OFST);
+	if (val & SLIM_EN_RUN)
+		dev_warn(&rproc->dev, "Failed to disable SLIM");
+
+	dev_dbg(&rproc->dev, "slim stopped\n");
+
+	return 0;
+}
+
+static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+{
+	struct st_slim_rproc *slim_rproc = rproc->priv;
+	void *va = NULL;
+	int i;
+
+	for (i = 0; i < ST_SLIM_MEM_MAX; i++) {
+		if (da != slim_rproc->mem[i].bus_addr)
+			continue;
+
+		if (len <= slim_rproc->mem[i].size) {
+			/* __force to make sparse happy with type conversion */
+			va = (__force void *)slim_rproc->mem[i].cpu_addr;
+			break;
+		}
+	}
+
+	dev_dbg(&rproc->dev, "da = 0x%llx len = 0x%x va = 0x%p\n", da, len, va);
+
+	return va;
+}
+
+static struct rproc_ops slim_rproc_ops = {
+	.start		= slim_rproc_start,
+	.stop		= slim_rproc_stop,
+	.da_to_va       = slim_rproc_da_to_va,
+};
+
+/*
+ * Firmware handler operations: sanity, boot address, load ...
+ */
+
+static struct resource_table empty_rsc_tbl = {
+	.ver = 1,
+	.num = 0,
+};
+
+static struct resource_table *slim_rproc_find_rsc_table(struct rproc *rproc,
+					       const struct firmware *fw,
+					       int *tablesz)
+{
+	*tablesz = sizeof(empty_rsc_tbl);
+	return &empty_rsc_tbl;
+}
+
+static struct rproc_fw_ops slim_rproc_fw_ops = {
+	.find_rsc_table = slim_rproc_find_rsc_table,
+};
+
+/**
+ * st_slim_rproc_alloc() - allocate and initialise slim rproc
+ * @pdev: Pointer to the platform_device struct
+ * @fw_name: Name of firmware for rproc to use
+ *
+ * Function for allocating and initialising a slim rproc for use by
+ * device drivers whose IP is based around the SLIM core. It
+ * obtains and enables any clocks required by the SLIM core and also
+ * ioremaps the various IO.
+ *
+ * Returns st_slim_rproc pointer or PTR_ERR() on error.
+ */
+
+struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
+				char *fw_name)
+{
+	struct device *dev = &pdev->dev;
+	struct st_slim_rproc *slim_rproc;
+	struct device_node *np = dev->of_node;
+	struct rproc *rproc;
+	struct resource *res;
+	int err, i;
+	const struct rproc_fw_ops *elf_ops;
+
+	if (!fw_name)
+		return ERR_PTR(-EINVAL);
+
+	if (!of_device_is_compatible(np, "st,slim-rproc"))
+		return ERR_PTR(-EINVAL);
+
+	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
+			fw_name, sizeof(*slim_rproc));
+	if (!rproc)
+		return ERR_PTR(-ENOMEM);
+
+	rproc->has_iommu = false;
+
+	slim_rproc = rproc->priv;
+	slim_rproc->rproc = rproc;
+
+	elf_ops = rproc->fw_ops;
+	/* Use some generic elf ops */
+	slim_rproc_fw_ops.load = elf_ops->load;
+	slim_rproc_fw_ops.sanity_check = elf_ops->sanity_check;
+
+	rproc->fw_ops = &slim_rproc_fw_ops;
+
+	/* get imem and dmem */
+	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
+		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+						mem_names[i]);
+
+		slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
+		if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
+			dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
+			err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
+			goto err;
+		}
+		slim_rproc->mem[i].bus_addr = res->start;
+		slim_rproc->mem[i].size = resource_size(res);
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
+	slim_rproc->slimcore = devm_ioremap_resource(dev, res);
+	if (IS_ERR(slim_rproc->slimcore)) {
+		dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
+		err = PTR_ERR(slim_rproc->slimcore);
+		goto err;
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
+	slim_rproc->peri = devm_ioremap_resource(dev, res);
+	if (IS_ERR(slim_rproc->peri)) {
+		dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
+		err = PTR_ERR(slim_rproc->peri);
+		goto err;
+	}
+
+	err = slim_clk_get(slim_rproc, dev);
+	if (err)
+		goto err;
+
+	err = slim_clk_enable(slim_rproc);
+	if (err) {
+		dev_err(dev, "Failed to enable clocks\n");
+		goto err_clk_put;
+	}
+
+	/* Register as a remoteproc device */
+	err = rproc_add(rproc);
+	if (err) {
+		dev_err(dev, "registration of slim remoteproc failed\n");
+		goto err_clk_dis;
+	}
+
+	return slim_rproc;
+
+err_clk_dis:
+	slim_clk_disable(slim_rproc);
+err_clk_put:
+	for (i = 0; i < ST_SLIM_MAX_CLK && slim_rproc->clks[i]; i++)
+		clk_put(slim_rproc->clks[i]);
+err:
+	rproc_put(rproc);
+	return ERR_PTR(err);
+}
+EXPORT_SYMBOL(st_slim_rproc_alloc);
+
+/**
+  * st_slim_rproc_put() - put slim rproc resources
+  * @slim_rproc: Pointer to the st_slim_rproc struct
+  *
+  * Function for calling respective _put() functions on slim_rproc resources.
+  *
+  */
+void st_slim_rproc_put(struct st_slim_rproc *slim_rproc)
+{
+	int clk;
+
+	if (!slim_rproc)
+		return;
+
+	slim_clk_disable(slim_rproc);
+
+	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
+		clk_put(slim_rproc->clks[clk]);
+
+	rproc_del(slim_rproc->rproc);
+	rproc_put(slim_rproc->rproc);
+}
+EXPORT_SYMBOL(st_slim_rproc_put);
+
+MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
+MODULE_DESCRIPTION("STMicroelectronics SLIM core rproc driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/remoteproc/st_slim_rproc.h b/include/linux/remoteproc/st_slim_rproc.h
new file mode 100644
index 0000000..4155556
--- /dev/null
+++ b/include/linux/remoteproc/st_slim_rproc.h
@@ -0,0 +1,58 @@
+/*
+ * SLIM core rproc driver header
+ *
+ * Copyright (C) 2016 STMicroelectronics
+ *
+ * Author: Peter Griffin <peter.griffin@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef _ST_REMOTEPROC_SLIM_H
+#define _ST_REMOTEPROC_SLIM_H
+
+#define ST_SLIM_MEM_MAX 2
+#define ST_SLIM_MAX_CLK 4
+
+enum {
+	ST_SLIM_DMEM,
+	ST_SLIM_IMEM,
+};
+
+/**
+ * struct st_slim_mem - slim internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @size: Size of the memory region
+ */
+struct st_slim_mem {
+	void __iomem *cpu_addr;
+	phys_addr_t bus_addr;
+	size_t size;
+};
+
+/**
+ * struct st_slim_rproc - SLIM slim core
+ * @rproc: rproc handle
+ * @mem: slim memory information
+ * @slimcore: slim slimcore regs
+ * @peri: slim peripheral regs
+ * @clks: slim clocks
+ */
+struct st_slim_rproc {
+	struct rproc *rproc;
+	struct st_slim_mem mem[ST_SLIM_MEM_MAX];
+	void __iomem *slimcore;
+	void __iomem *peri;
+
+	/* st_slim_rproc private */
+	struct clk *clks[ST_SLIM_MAX_CLK];
+};
+
+struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
+					char *fw_name);
+void st_slim_rproc_put(struct st_slim_rproc *slim_rproc);
+
+#endif
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 02/19] MAINTAINERS: Add st slim core rproc driver to STi section.
  2016-09-05 13:16 ` Peter Griffin
  (?)
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization

This patch adds the slim core rproc driver to the STi section
of the MAINTAINERS file.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0bbe4b1..5dd3b24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1749,6 +1749,7 @@ F:	drivers/phy/phy-stih407-usb.c
 F:	drivers/phy/phy-stih41x-usb.c
 F:	drivers/pinctrl/pinctrl-st.c
 F:	drivers/remoteproc/st_remoteproc.c
+F:	drivers/remoteproc/st_slim_rproc.c
 F:	drivers/reset/sti/
 F:	drivers/rtc/rtc-st-lpc.c
 F:	drivers/tty/serial/st-asc.c
@@ -1757,6 +1758,7 @@ F:	drivers/usb/host/ehci-st.c
 F:	drivers/usb/host/ohci-st.c
 F:	drivers/watchdog/st_lpc_wdt.c
 F:	drivers/ata/ahci_st.c
+F:	include/linux/remoteproc/st_slim_rproc.h
 
 ARM/STM32 ARCHITECTURE
 M:	Maxime Coquelin <mcoquelin.stm32@gmail.com>
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 02/19] MAINTAINERS: Add st slim core rproc driver to STi section.
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones

This patch adds the slim core rproc driver to the STi section
of the MAINTAINERS file.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0bbe4b1..5dd3b24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1749,6 +1749,7 @@ F:	drivers/phy/phy-stih407-usb.c
 F:	drivers/phy/phy-stih41x-usb.c
 F:	drivers/pinctrl/pinctrl-st.c
 F:	drivers/remoteproc/st_remoteproc.c
+F:	drivers/remoteproc/st_slim_rproc.c
 F:	drivers/reset/sti/
 F:	drivers/rtc/rtc-st-lpc.c
 F:	drivers/tty/serial/st-asc.c
@@ -1757,6 +1758,7 @@ F:	drivers/usb/host/ehci-st.c
 F:	drivers/usb/host/ohci-st.c
 F:	drivers/watchdog/st_lpc_wdt.c
 F:	drivers/ata/ahci_st.c
+F:	include/linux/remoteproc/st_slim_rproc.h
 
 ARM/STM32 ARCHITECTURE
 M:	Maxime Coquelin <mcoquelin.stm32@gmail.com>
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 02/19] MAINTAINERS: Add st slim core rproc driver to STi section.
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds the slim core rproc driver to the STi section
of the MAINTAINERS file.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0bbe4b1..5dd3b24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1749,6 +1749,7 @@ F:	drivers/phy/phy-stih407-usb.c
 F:	drivers/phy/phy-stih41x-usb.c
 F:	drivers/pinctrl/pinctrl-st.c
 F:	drivers/remoteproc/st_remoteproc.c
+F:	drivers/remoteproc/st_slim_rproc.c
 F:	drivers/reset/sti/
 F:	drivers/rtc/rtc-st-lpc.c
 F:	drivers/tty/serial/st-asc.c
@@ -1757,6 +1758,7 @@ F:	drivers/usb/host/ehci-st.c
 F:	drivers/usb/host/ohci-st.c
 F:	drivers/watchdog/st_lpc_wdt.c
 F:	drivers/ata/ahci_st.c
+F:	include/linux/remoteproc/st_slim_rproc.h
 
 ARM/STM32 ARCHITECTURE
 M:	Maxime Coquelin <mcoquelin.stm32@gmail.com>
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 03/19] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation
  2016-09-05 13:16 ` Peter Griffin
  (?)
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization, Ludovic Barre

This patch adds the DT binding documentation for the FDMA constroller
found on STi based chipsets from STMicroelectronics.

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/dma/st_fdma.txt | 87 +++++++++++++++++++++++
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt

diff --git a/Documentation/devicetree/bindings/dma/st_fdma.txt b/Documentation/devicetree/bindings/dma/st_fdma.txt
new file mode 100644
index 0000000..495d853
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/st_fdma.txt
@@ -0,0 +1,87 @@
+* STMicroelectronics Flexible Direct Memory Access Device Tree bindings
+
+The FDMA is a general-purpose direct memory access controller capable of
+supporting 16 independent DMA channels. It accepts up to 32 DMA requests.
+The FDMA is based on a Slim processor which requires a firmware.
+
+* FDMA Controller
+
+Required properties:
+- compatible	: Should be one of
+		 - st,stih407-fdma-mpe31-11, "st,slim-rproc";
+		 - st,stih407-fdma-mpe31-12, "st,slim-rproc";
+		 - st,stih407-fdma-mpe31-13, "st,slim-rproc";
+- reg		: Should contain an entry for each name in reg-names
+- reg-names	: Must contain "slimcore", "dmem", "peripherals", "imem" entries
+- interrupts	: Should contain one interrupt shared by all channels
+- dma-channels	: Number of channels supported by the controller
+- #dma-cells	: Must be <3>. See DMA client section below
+- clocks	: Must contain an entry for each clock
+See: Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+
+Example:
+
+	fdma0: dma-controller@8e20000 {
+		compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
+		reg = <0x8e20000 0x8000>,
+		      <0x8e30000 0x3000>,
+		      <0x8e37000 0x1000>,
+		      <0x8e38000 0x8000>;
+		reg-names = "slimcore", "dmem", "peripherals", "imem";
+		clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+			 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+			 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+			 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
+		dma-channels = <16>;
+		#dma-cells = <3>;
+	};
+
+* DMA client
+
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+1. A phandle pointing to the FDMA controller
+2. The request line number
+3. A 32bit mask specifying (see include/linux/platform_data/dma-st-fdma.h)
+ -bit 2-0: Holdoff value, dreq will be masked for
+	0x0: 0-0.5us
+	0x1: 0.5-1us
+	0x2: 1-1.5us
+ -bit 17: data swap
+	0x0: disabled
+	0x1: enabled
+ -bit 21: Increment Address
+	0x0: no address increment between transfers
+	0x1: increment address between transfers
+ -bit 22: 2 STBus Initiator Coprocessor interface
+	0x0: high priority port
+	0x1: low priority port
+4. transfers type
+ 0 free running
+ 1 paced
+
+Example:
+
+	sti_uni_player2: sti-uni-player@2 {
+		compatible = "st,sti-uni-player";
+		status = "disabled";
+		#sound-dai-cells = <0>;
+		st,syscfg = <&syscfg_core>;
+		clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+		assigned-clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+		assigned-clock-parents = <&clk_s_d0_quadfs 2>;
+		assigned-clock-rates = <50000000>;
+		reg = <0x8D82000 0x158>;
+		interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
+		dmas = <&fdma0 4 0 1>;
+		dai-name = "Uni Player #1 (DAC)";
+		dma-names = "tx";
+		st,uniperiph-id = <2>;
+		st,version = <5>;
+		st,mode = "PCM";
+	};
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 03/19] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones, Ludovic Barre

This patch adds the DT binding documentation for the FDMA constroller
found on STi based chipsets from STMicroelectronics.

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/dma/st_fdma.txt | 87 +++++++++++++++++++++++
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt

diff --git a/Documentation/devicetree/bindings/dma/st_fdma.txt b/Documentation/devicetree/bindings/dma/st_fdma.txt
new file mode 100644
index 0000000..495d853
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/st_fdma.txt
@@ -0,0 +1,87 @@
+* STMicroelectronics Flexible Direct Memory Access Device Tree bindings
+
+The FDMA is a general-purpose direct memory access controller capable of
+supporting 16 independent DMA channels. It accepts up to 32 DMA requests.
+The FDMA is based on a Slim processor which requires a firmware.
+
+* FDMA Controller
+
+Required properties:
+- compatible	: Should be one of
+		 - st,stih407-fdma-mpe31-11, "st,slim-rproc";
+		 - st,stih407-fdma-mpe31-12, "st,slim-rproc";
+		 - st,stih407-fdma-mpe31-13, "st,slim-rproc";
+- reg		: Should contain an entry for each name in reg-names
+- reg-names	: Must contain "slimcore", "dmem", "peripherals", "imem" entries
+- interrupts	: Should contain one interrupt shared by all channels
+- dma-channels	: Number of channels supported by the controller
+- #dma-cells	: Must be <3>. See DMA client section below
+- clocks	: Must contain an entry for each clock
+See: Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+
+Example:
+
+	fdma0: dma-controller@8e20000 {
+		compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
+		reg = <0x8e20000 0x8000>,
+		      <0x8e30000 0x3000>,
+		      <0x8e37000 0x1000>,
+		      <0x8e38000 0x8000>;
+		reg-names = "slimcore", "dmem", "peripherals", "imem";
+		clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+			 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+			 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+			 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
+		dma-channels = <16>;
+		#dma-cells = <3>;
+	};
+
+* DMA client
+
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+1. A phandle pointing to the FDMA controller
+2. The request line number
+3. A 32bit mask specifying (see include/linux/platform_data/dma-st-fdma.h)
+ -bit 2-0: Holdoff value, dreq will be masked for
+	0x0: 0-0.5us
+	0x1: 0.5-1us
+	0x2: 1-1.5us
+ -bit 17: data swap
+	0x0: disabled
+	0x1: enabled
+ -bit 21: Increment Address
+	0x0: no address increment between transfers
+	0x1: increment address between transfers
+ -bit 22: 2 STBus Initiator Coprocessor interface
+	0x0: high priority port
+	0x1: low priority port
+4. transfers type
+ 0 free running
+ 1 paced
+
+Example:
+
+	sti_uni_player2: sti-uni-player@2 {
+		compatible = "st,sti-uni-player";
+		status = "disabled";
+		#sound-dai-cells = <0>;
+		st,syscfg = <&syscfg_core>;
+		clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+		assigned-clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+		assigned-clock-parents = <&clk_s_d0_quadfs 2>;
+		assigned-clock-rates = <50000000>;
+		reg = <0x8D82000 0x158>;
+		interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
+		dmas = <&fdma0 4 0 1>;
+		dai-name = "Uni Player #1 (DAC)";
+		dma-names = "tx";
+		st,uniperiph-id = <2>;
+		st,version = <5>;
+		st,mode = "PCM";
+	};
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 03/19] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds the DT binding documentation for the FDMA constroller
found on STi based chipsets from STMicroelectronics.

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/dma/st_fdma.txt | 87 +++++++++++++++++++++++
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt

diff --git a/Documentation/devicetree/bindings/dma/st_fdma.txt b/Documentation/devicetree/bindings/dma/st_fdma.txt
new file mode 100644
index 0000000..495d853
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/st_fdma.txt
@@ -0,0 +1,87 @@
+* STMicroelectronics Flexible Direct Memory Access Device Tree bindings
+
+The FDMA is a general-purpose direct memory access controller capable of
+supporting 16 independent DMA channels. It accepts up to 32 DMA requests.
+The FDMA is based on a Slim processor which requires a firmware.
+
+* FDMA Controller
+
+Required properties:
+- compatible	: Should be one of
+		 - st,stih407-fdma-mpe31-11, "st,slim-rproc";
+		 - st,stih407-fdma-mpe31-12, "st,slim-rproc";
+		 - st,stih407-fdma-mpe31-13, "st,slim-rproc";
+- reg		: Should contain an entry for each name in reg-names
+- reg-names	: Must contain "slimcore", "dmem", "peripherals", "imem" entries
+- interrupts	: Should contain one interrupt shared by all channels
+- dma-channels	: Number of channels supported by the controller
+- #dma-cells	: Must be <3>. See DMA client section below
+- clocks	: Must contain an entry for each clock
+See: Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+
+Example:
+
+	fdma0: dma-controller at 8e20000 {
+		compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
+		reg = <0x8e20000 0x8000>,
+		      <0x8e30000 0x3000>,
+		      <0x8e37000 0x1000>,
+		      <0x8e38000 0x8000>;
+		reg-names = "slimcore", "dmem", "peripherals", "imem";
+		clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+			 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+			 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+			 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
+		dma-channels = <16>;
+		#dma-cells = <3>;
+	};
+
+* DMA client
+
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+1. A phandle pointing to the FDMA controller
+2. The request line number
+3. A 32bit mask specifying (see include/linux/platform_data/dma-st-fdma.h)
+ -bit 2-0: Holdoff value, dreq will be masked for
+	0x0: 0-0.5us
+	0x1: 0.5-1us
+	0x2: 1-1.5us
+ -bit 17: data swap
+	0x0: disabled
+	0x1: enabled
+ -bit 21: Increment Address
+	0x0: no address increment between transfers
+	0x1: increment address between transfers
+ -bit 22: 2 STBus Initiator Coprocessor interface
+	0x0: high priority port
+	0x1: low priority port
+4. transfers type
+ 0 free running
+ 1 paced
+
+Example:
+
+	sti_uni_player2: sti-uni-player at 2 {
+		compatible = "st,sti-uni-player";
+		status = "disabled";
+		#sound-dai-cells = <0>;
+		st,syscfg = <&syscfg_core>;
+		clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+		assigned-clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+		assigned-clock-parents = <&clk_s_d0_quadfs 2>;
+		assigned-clock-rates = <50000000>;
+		reg = <0x8D82000 0x158>;
+		interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
+		dmas = <&fdma0 4 0 1>;
+		dai-name = "Uni Player #1 (DAC)";
+		dma-names = "tx";
+		st,uniperiph-id = <2>;
+		st,version = <5>;
+		st,mode = "PCM";
+	};
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 04/19] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file
  2016-09-05 13:16 ` Peter Griffin
  (?)
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization, Ludovic Barre

This header file will also be used by the dma xbar driver in the
future.

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/dma/st_fdma.h | 249 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 249 insertions(+)
 create mode 100644 drivers/dma/st_fdma.h

diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
new file mode 100644
index 0000000..c58e00d
--- /dev/null
+++ b/drivers/dma/st_fdma.h
@@ -0,0 +1,249 @@
+/*
+ * DMA driver header for STMicroelectronics STi FDMA controller
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * Author: Ludovic Barre <Ludovic.barre@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef __DMA_ST_FDMA_H
+#define __DMA_ST_FDMA_H
+
+#include <linux/dmaengine.h>
+#include <linux/dmapool.h>
+#include <linux/io.h>
+#include <linux/remoteproc/st_slim_rproc.h>
+#include "virt-dma.h"
+
+#define ST_FDMA_NR_DREQS 32
+#define FW_NAME_SIZE 30
+#define DRIVER_NAME "st-fdma"
+
+/**
+ * struct st_fdma_generic_node - Free running/paced generic node
+ *
+ * @length: Length in bytes of a line in a 2D mem to mem
+ * @sstride: Stride, in bytes, between source lines in a 2D data move
+ * @dstride: Stride, in bytes, between destination lines in a 2D data move
+ */
+struct st_fdma_generic_node {
+	u32 length;
+	u32 sstride;
+	u32 dstride;
+};
+
+/**
+ * struct st_fdma_hw_node - Node structure used by fdma hw
+ *
+ * @next: Pointer to next node
+ * @control: Transfer Control Parameters
+ * @nbytes: Number of Bytes to read
+ * @saddr: Source address
+ * @daddr: Destination address
+ *
+ * @generic: generic node for free running/paced transfert type
+ * 2 others transfert type are possible, but not yet implemented
+ *
+ * The NODE structures must be aligned to a 32 byte boundary
+ */
+struct st_fdma_hw_node {
+	u32 next;
+	u32 control;
+	u32 nbytes;
+	u32 saddr;
+	u32 daddr;
+	union {
+		struct st_fdma_generic_node generic;
+	};
+} __aligned(32);
+
+/*
+ * node control parameters
+ */
+#define FDMA_NODE_CTRL_REQ_MAP_MASK	GENMASK(4, 0)
+#define FDMA_NODE_CTRL_REQ_MAP_FREE_RUN	0x0
+#define FDMA_NODE_CTRL_REQ_MAP_DREQ(n)	((n)&FDMA_NODE_CTRL_REQ_MAP_MASK)
+#define FDMA_NODE_CTRL_REQ_MAP_EXT		FDMA_NODE_CTRL_REQ_MAP_MASK
+#define FDMA_NODE_CTRL_SRC_MASK		GENMASK(6, 5)
+#define FDMA_NODE_CTRL_SRC_STATIC	BIT(5)
+#define FDMA_NODE_CTRL_SRC_INCR		BIT(6)
+#define FDMA_NODE_CTRL_DST_MASK		GENMASK(8, 7)
+#define FDMA_NODE_CTRL_DST_STATIC	BIT(7)
+#define FDMA_NODE_CTRL_DST_INCR		BIT(8)
+#define FDMA_NODE_CTRL_SECURE		BIT(15)
+#define FDMA_NODE_CTRL_PAUSE_EON	BIT(30)
+#define FDMA_NODE_CTRL_INT_EON		BIT(31)
+
+/**
+ * struct st_fdma_sw_node - descriptor structure for link list
+ *
+ * @pdesc: Physical address of desc
+ * @node: link used for putting this into a channel queue
+ */
+struct st_fdma_sw_node {
+	dma_addr_t pdesc;
+	struct st_fdma_hw_node *desc;
+};
+
+#define NAME_SZ 10
+
+struct st_fdma_driverdata {
+	u32 id;
+	char name[NAME_SZ];
+};
+
+struct st_fdma_desc {
+	struct virt_dma_desc vdesc;
+	struct st_fdma_chan *fchan;
+	bool iscyclic;
+	unsigned int n_nodes;
+	struct st_fdma_sw_node node[];
+};
+
+enum st_fdma_type {
+	ST_FDMA_TYPE_FREE_RUN,
+	ST_FDMA_TYPE_PACED,
+};
+
+struct st_fdma_cfg {
+	struct device_node *of_node;
+	enum st_fdma_type type;
+	dma_addr_t dev_addr;
+	enum dma_transfer_direction dir;
+	int req_line; /* request line */
+	long req_ctrl; /* Request control */
+};
+
+struct st_fdma_chan {
+	struct st_fdma_dev *fdev;
+	struct dma_pool *node_pool;
+	struct dma_slave_config scfg;
+	struct st_fdma_cfg cfg;
+
+	int dreq_line;
+
+	struct virt_dma_chan vchan;
+	struct st_fdma_desc *fdesc;
+	enum dma_status	status;
+};
+
+struct st_fdma_dev {
+	struct device *dev;
+	const struct st_fdma_driverdata *drvdata;
+	struct dma_device dma_device;
+
+	struct st_slim_rproc *slim_rproc;
+
+	int irq;
+
+	struct st_fdma_chan *chans;
+
+	spinlock_t dreq_lock;
+	unsigned long dreq_mask;
+
+	u32 nr_channels;
+	char fw_name[FW_NAME_SIZE];
+};
+
+/* Peripheral Registers*/
+
+#define FDMA_CMD_STA_OFST	0xFC0
+#define FDMA_CMD_SET_OFST	0xFC4
+#define FDMA_CMD_CLR_OFST	0xFC8
+#define FDMA_CMD_MASK_OFST	0xFCC
+#define FDMA_CMD_START(ch)		(0x1 << (ch << 1))
+#define FDMA_CMD_PAUSE(ch)		(0x2 << (ch << 1))
+#define FDMA_CMD_FLUSH(ch)		(0x3 << (ch << 1))
+
+#define FDMA_INT_STA_OFST	0xFD0
+#define FDMA_INT_STA_CH			0x1
+#define FDMA_INT_STA_ERR		0x2
+
+#define FDMA_INT_SET_OFST	0xFD4
+#define FDMA_INT_CLR_OFST	0xFD8
+#define FDMA_INT_MASK_OFST	0xFDC
+
+#define fdma_read(fdev, name) \
+	readl((fdev)->slim_rproc->peri + name)
+
+#define fdma_write(fdev, val, name) \
+	writel((val), (fdev)->slim_rproc->peri + name)
+
+/* fchan interface (dmem) */
+#define FDMA_CH_CMD_OFST	0x200
+#define FDMA_CH_CMD_STA_MASK		GENMASK(1, 0)
+#define FDMA_CH_CMD_STA_IDLE		(0x0)
+#define FDMA_CH_CMD_STA_START		(0x1)
+#define FDMA_CH_CMD_STA_RUNNING		(0x2)
+#define FDMA_CH_CMD_STA_PAUSED		(0x3)
+#define FDMA_CH_CMD_ERR_MASK		GENMASK(4, 2)
+#define FDMA_CH_CMD_ERR_INT		(0x0 << 2)
+#define FDMA_CH_CMD_ERR_NAND		(0x1 << 2)
+#define FDMA_CH_CMD_ERR_MCHI		(0x2 << 2)
+#define FDMA_CH_CMD_DATA_MASK		GENMASK(31, 5)
+#define fchan_read(fchan, name) \
+	readl((fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * 0x4 \
+			+ name)
+
+#define fchan_write(fchan, val, name) \
+	writel((val), (fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * 0x4 \
+			+ name)
+
+/* req interface */
+#define FDMA_REQ_CTRL_OFST	0x240
+#define dreq_write(fchan, val, name) \
+	writel((val), (fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ fchan->dreq_line * 0x04 \
+			+ name)
+/* node interface */
+#define FDMA_NODE_SZ 128
+#define FDMA_PTRN_OFST		0x800
+#define FDMA_CNTN_OFST		0x808
+#define FDMA_SADDRN_OFST	0x80c
+#define FDMA_DADDRN_OFST	0x810
+#define fnode_read(fchan, name) \
+	readl((fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * FDMA_NODE_SZ \
+			+ name)
+
+#define fnode_write(fchan, val, name) \
+	writel((val), (fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * FDMA_NODE_SZ \
+			+ name)
+
+/*
+ * request control bits
+ */
+#define FDMA_REQ_CTRL_NUM_OPS_MASK	GENMASK(31, 24)
+#define FDMA_REQ_CTRL_NUM_OPS(n)	(FDMA_REQ_CTRL_NUM_OPS_MASK & \
+					((n) << 24))
+#define FDMA_REQ_CTRL_INITIATOR_MASK	BIT(22)
+#define FDMA_REQ_CTRL_INIT0		(0x0 << 22)
+#define FDMA_REQ_CTRL_INIT1		(0x1 << 22)
+#define FDMA_REQ_CTRL_INC_ADDR_ON	BIT(21)
+#define FDMA_REQ_CTRL_DATA_SWAP_ON	BIT(17)
+#define FDMA_REQ_CTRL_WNR		BIT(14)
+#define FDMA_REQ_CTRL_OPCODE_MASK	GENMASK(7, 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST1	(0x0 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST2	(0x1 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST4	(0x2 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST8	(0x3 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST16	(0x4 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST32	(0x5 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST64	(0x6 << 4)
+#define FDMA_REQ_CTRL_HOLDOFF_MASK	GENMASK(2, 0)
+#define FDMA_REQ_CTRL_HOLDOFF(n)	((n) & FDMA_REQ_CTRL_HOLDOFF_MASK)
+
+/* bits used by client to configure request control */
+#define FDMA_REQ_CTRL_CFG_MASK (FDMA_REQ_CTRL_HOLDOFF_MASK | \
+				FDMA_REQ_CTRL_DATA_SWAP_ON | \
+				FDMA_REQ_CTRL_INC_ADDR_ON | \
+				FDMA_REQ_CTRL_INITIATOR_MASK)
+
+#endif	/* __DMA_ST_FDMA_H */
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 04/19] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones, Ludovic Barre

This header file will also be used by the dma xbar driver in the
future.

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/dma/st_fdma.h | 249 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 249 insertions(+)
 create mode 100644 drivers/dma/st_fdma.h

diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
new file mode 100644
index 0000000..c58e00d
--- /dev/null
+++ b/drivers/dma/st_fdma.h
@@ -0,0 +1,249 @@
+/*
+ * DMA driver header for STMicroelectronics STi FDMA controller
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * Author: Ludovic Barre <Ludovic.barre@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef __DMA_ST_FDMA_H
+#define __DMA_ST_FDMA_H
+
+#include <linux/dmaengine.h>
+#include <linux/dmapool.h>
+#include <linux/io.h>
+#include <linux/remoteproc/st_slim_rproc.h>
+#include "virt-dma.h"
+
+#define ST_FDMA_NR_DREQS 32
+#define FW_NAME_SIZE 30
+#define DRIVER_NAME "st-fdma"
+
+/**
+ * struct st_fdma_generic_node - Free running/paced generic node
+ *
+ * @length: Length in bytes of a line in a 2D mem to mem
+ * @sstride: Stride, in bytes, between source lines in a 2D data move
+ * @dstride: Stride, in bytes, between destination lines in a 2D data move
+ */
+struct st_fdma_generic_node {
+	u32 length;
+	u32 sstride;
+	u32 dstride;
+};
+
+/**
+ * struct st_fdma_hw_node - Node structure used by fdma hw
+ *
+ * @next: Pointer to next node
+ * @control: Transfer Control Parameters
+ * @nbytes: Number of Bytes to read
+ * @saddr: Source address
+ * @daddr: Destination address
+ *
+ * @generic: generic node for free running/paced transfert type
+ * 2 others transfert type are possible, but not yet implemented
+ *
+ * The NODE structures must be aligned to a 32 byte boundary
+ */
+struct st_fdma_hw_node {
+	u32 next;
+	u32 control;
+	u32 nbytes;
+	u32 saddr;
+	u32 daddr;
+	union {
+		struct st_fdma_generic_node generic;
+	};
+} __aligned(32);
+
+/*
+ * node control parameters
+ */
+#define FDMA_NODE_CTRL_REQ_MAP_MASK	GENMASK(4, 0)
+#define FDMA_NODE_CTRL_REQ_MAP_FREE_RUN	0x0
+#define FDMA_NODE_CTRL_REQ_MAP_DREQ(n)	((n)&FDMA_NODE_CTRL_REQ_MAP_MASK)
+#define FDMA_NODE_CTRL_REQ_MAP_EXT		FDMA_NODE_CTRL_REQ_MAP_MASK
+#define FDMA_NODE_CTRL_SRC_MASK		GENMASK(6, 5)
+#define FDMA_NODE_CTRL_SRC_STATIC	BIT(5)
+#define FDMA_NODE_CTRL_SRC_INCR		BIT(6)
+#define FDMA_NODE_CTRL_DST_MASK		GENMASK(8, 7)
+#define FDMA_NODE_CTRL_DST_STATIC	BIT(7)
+#define FDMA_NODE_CTRL_DST_INCR		BIT(8)
+#define FDMA_NODE_CTRL_SECURE		BIT(15)
+#define FDMA_NODE_CTRL_PAUSE_EON	BIT(30)
+#define FDMA_NODE_CTRL_INT_EON		BIT(31)
+
+/**
+ * struct st_fdma_sw_node - descriptor structure for link list
+ *
+ * @pdesc: Physical address of desc
+ * @node: link used for putting this into a channel queue
+ */
+struct st_fdma_sw_node {
+	dma_addr_t pdesc;
+	struct st_fdma_hw_node *desc;
+};
+
+#define NAME_SZ 10
+
+struct st_fdma_driverdata {
+	u32 id;
+	char name[NAME_SZ];
+};
+
+struct st_fdma_desc {
+	struct virt_dma_desc vdesc;
+	struct st_fdma_chan *fchan;
+	bool iscyclic;
+	unsigned int n_nodes;
+	struct st_fdma_sw_node node[];
+};
+
+enum st_fdma_type {
+	ST_FDMA_TYPE_FREE_RUN,
+	ST_FDMA_TYPE_PACED,
+};
+
+struct st_fdma_cfg {
+	struct device_node *of_node;
+	enum st_fdma_type type;
+	dma_addr_t dev_addr;
+	enum dma_transfer_direction dir;
+	int req_line; /* request line */
+	long req_ctrl; /* Request control */
+};
+
+struct st_fdma_chan {
+	struct st_fdma_dev *fdev;
+	struct dma_pool *node_pool;
+	struct dma_slave_config scfg;
+	struct st_fdma_cfg cfg;
+
+	int dreq_line;
+
+	struct virt_dma_chan vchan;
+	struct st_fdma_desc *fdesc;
+	enum dma_status	status;
+};
+
+struct st_fdma_dev {
+	struct device *dev;
+	const struct st_fdma_driverdata *drvdata;
+	struct dma_device dma_device;
+
+	struct st_slim_rproc *slim_rproc;
+
+	int irq;
+
+	struct st_fdma_chan *chans;
+
+	spinlock_t dreq_lock;
+	unsigned long dreq_mask;
+
+	u32 nr_channels;
+	char fw_name[FW_NAME_SIZE];
+};
+
+/* Peripheral Registers*/
+
+#define FDMA_CMD_STA_OFST	0xFC0
+#define FDMA_CMD_SET_OFST	0xFC4
+#define FDMA_CMD_CLR_OFST	0xFC8
+#define FDMA_CMD_MASK_OFST	0xFCC
+#define FDMA_CMD_START(ch)		(0x1 << (ch << 1))
+#define FDMA_CMD_PAUSE(ch)		(0x2 << (ch << 1))
+#define FDMA_CMD_FLUSH(ch)		(0x3 << (ch << 1))
+
+#define FDMA_INT_STA_OFST	0xFD0
+#define FDMA_INT_STA_CH			0x1
+#define FDMA_INT_STA_ERR		0x2
+
+#define FDMA_INT_SET_OFST	0xFD4
+#define FDMA_INT_CLR_OFST	0xFD8
+#define FDMA_INT_MASK_OFST	0xFDC
+
+#define fdma_read(fdev, name) \
+	readl((fdev)->slim_rproc->peri + name)
+
+#define fdma_write(fdev, val, name) \
+	writel((val), (fdev)->slim_rproc->peri + name)
+
+/* fchan interface (dmem) */
+#define FDMA_CH_CMD_OFST	0x200
+#define FDMA_CH_CMD_STA_MASK		GENMASK(1, 0)
+#define FDMA_CH_CMD_STA_IDLE		(0x0)
+#define FDMA_CH_CMD_STA_START		(0x1)
+#define FDMA_CH_CMD_STA_RUNNING		(0x2)
+#define FDMA_CH_CMD_STA_PAUSED		(0x3)
+#define FDMA_CH_CMD_ERR_MASK		GENMASK(4, 2)
+#define FDMA_CH_CMD_ERR_INT		(0x0 << 2)
+#define FDMA_CH_CMD_ERR_NAND		(0x1 << 2)
+#define FDMA_CH_CMD_ERR_MCHI		(0x2 << 2)
+#define FDMA_CH_CMD_DATA_MASK		GENMASK(31, 5)
+#define fchan_read(fchan, name) \
+	readl((fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * 0x4 \
+			+ name)
+
+#define fchan_write(fchan, val, name) \
+	writel((val), (fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * 0x4 \
+			+ name)
+
+/* req interface */
+#define FDMA_REQ_CTRL_OFST	0x240
+#define dreq_write(fchan, val, name) \
+	writel((val), (fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ fchan->dreq_line * 0x04 \
+			+ name)
+/* node interface */
+#define FDMA_NODE_SZ 128
+#define FDMA_PTRN_OFST		0x800
+#define FDMA_CNTN_OFST		0x808
+#define FDMA_SADDRN_OFST	0x80c
+#define FDMA_DADDRN_OFST	0x810
+#define fnode_read(fchan, name) \
+	readl((fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * FDMA_NODE_SZ \
+			+ name)
+
+#define fnode_write(fchan, val, name) \
+	writel((val), (fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * FDMA_NODE_SZ \
+			+ name)
+
+/*
+ * request control bits
+ */
+#define FDMA_REQ_CTRL_NUM_OPS_MASK	GENMASK(31, 24)
+#define FDMA_REQ_CTRL_NUM_OPS(n)	(FDMA_REQ_CTRL_NUM_OPS_MASK & \
+					((n) << 24))
+#define FDMA_REQ_CTRL_INITIATOR_MASK	BIT(22)
+#define FDMA_REQ_CTRL_INIT0		(0x0 << 22)
+#define FDMA_REQ_CTRL_INIT1		(0x1 << 22)
+#define FDMA_REQ_CTRL_INC_ADDR_ON	BIT(21)
+#define FDMA_REQ_CTRL_DATA_SWAP_ON	BIT(17)
+#define FDMA_REQ_CTRL_WNR		BIT(14)
+#define FDMA_REQ_CTRL_OPCODE_MASK	GENMASK(7, 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST1	(0x0 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST2	(0x1 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST4	(0x2 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST8	(0x3 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST16	(0x4 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST32	(0x5 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST64	(0x6 << 4)
+#define FDMA_REQ_CTRL_HOLDOFF_MASK	GENMASK(2, 0)
+#define FDMA_REQ_CTRL_HOLDOFF(n)	((n) & FDMA_REQ_CTRL_HOLDOFF_MASK)
+
+/* bits used by client to configure request control */
+#define FDMA_REQ_CTRL_CFG_MASK (FDMA_REQ_CTRL_HOLDOFF_MASK | \
+				FDMA_REQ_CTRL_DATA_SWAP_ON | \
+				FDMA_REQ_CTRL_INC_ADDR_ON | \
+				FDMA_REQ_CTRL_INITIATOR_MASK)
+
+#endif	/* __DMA_ST_FDMA_H */
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 04/19] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This header file will also be used by the dma xbar driver in the
future.

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/dma/st_fdma.h | 249 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 249 insertions(+)
 create mode 100644 drivers/dma/st_fdma.h

diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
new file mode 100644
index 0000000..c58e00d
--- /dev/null
+++ b/drivers/dma/st_fdma.h
@@ -0,0 +1,249 @@
+/*
+ * DMA driver header for STMicroelectronics STi FDMA controller
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * Author: Ludovic Barre <Ludovic.barre@st.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef __DMA_ST_FDMA_H
+#define __DMA_ST_FDMA_H
+
+#include <linux/dmaengine.h>
+#include <linux/dmapool.h>
+#include <linux/io.h>
+#include <linux/remoteproc/st_slim_rproc.h>
+#include "virt-dma.h"
+
+#define ST_FDMA_NR_DREQS 32
+#define FW_NAME_SIZE 30
+#define DRIVER_NAME "st-fdma"
+
+/**
+ * struct st_fdma_generic_node - Free running/paced generic node
+ *
+ * @length: Length in bytes of a line in a 2D mem to mem
+ * @sstride: Stride, in bytes, between source lines in a 2D data move
+ * @dstride: Stride, in bytes, between destination lines in a 2D data move
+ */
+struct st_fdma_generic_node {
+	u32 length;
+	u32 sstride;
+	u32 dstride;
+};
+
+/**
+ * struct st_fdma_hw_node - Node structure used by fdma hw
+ *
+ * @next: Pointer to next node
+ * @control: Transfer Control Parameters
+ * @nbytes: Number of Bytes to read
+ * @saddr: Source address
+ * @daddr: Destination address
+ *
+ * @generic: generic node for free running/paced transfert type
+ * 2 others transfert type are possible, but not yet implemented
+ *
+ * The NODE structures must be aligned to a 32 byte boundary
+ */
+struct st_fdma_hw_node {
+	u32 next;
+	u32 control;
+	u32 nbytes;
+	u32 saddr;
+	u32 daddr;
+	union {
+		struct st_fdma_generic_node generic;
+	};
+} __aligned(32);
+
+/*
+ * node control parameters
+ */
+#define FDMA_NODE_CTRL_REQ_MAP_MASK	GENMASK(4, 0)
+#define FDMA_NODE_CTRL_REQ_MAP_FREE_RUN	0x0
+#define FDMA_NODE_CTRL_REQ_MAP_DREQ(n)	((n)&FDMA_NODE_CTRL_REQ_MAP_MASK)
+#define FDMA_NODE_CTRL_REQ_MAP_EXT		FDMA_NODE_CTRL_REQ_MAP_MASK
+#define FDMA_NODE_CTRL_SRC_MASK		GENMASK(6, 5)
+#define FDMA_NODE_CTRL_SRC_STATIC	BIT(5)
+#define FDMA_NODE_CTRL_SRC_INCR		BIT(6)
+#define FDMA_NODE_CTRL_DST_MASK		GENMASK(8, 7)
+#define FDMA_NODE_CTRL_DST_STATIC	BIT(7)
+#define FDMA_NODE_CTRL_DST_INCR		BIT(8)
+#define FDMA_NODE_CTRL_SECURE		BIT(15)
+#define FDMA_NODE_CTRL_PAUSE_EON	BIT(30)
+#define FDMA_NODE_CTRL_INT_EON		BIT(31)
+
+/**
+ * struct st_fdma_sw_node - descriptor structure for link list
+ *
+ * @pdesc: Physical address of desc
+ * @node: link used for putting this into a channel queue
+ */
+struct st_fdma_sw_node {
+	dma_addr_t pdesc;
+	struct st_fdma_hw_node *desc;
+};
+
+#define NAME_SZ 10
+
+struct st_fdma_driverdata {
+	u32 id;
+	char name[NAME_SZ];
+};
+
+struct st_fdma_desc {
+	struct virt_dma_desc vdesc;
+	struct st_fdma_chan *fchan;
+	bool iscyclic;
+	unsigned int n_nodes;
+	struct st_fdma_sw_node node[];
+};
+
+enum st_fdma_type {
+	ST_FDMA_TYPE_FREE_RUN,
+	ST_FDMA_TYPE_PACED,
+};
+
+struct st_fdma_cfg {
+	struct device_node *of_node;
+	enum st_fdma_type type;
+	dma_addr_t dev_addr;
+	enum dma_transfer_direction dir;
+	int req_line; /* request line */
+	long req_ctrl; /* Request control */
+};
+
+struct st_fdma_chan {
+	struct st_fdma_dev *fdev;
+	struct dma_pool *node_pool;
+	struct dma_slave_config scfg;
+	struct st_fdma_cfg cfg;
+
+	int dreq_line;
+
+	struct virt_dma_chan vchan;
+	struct st_fdma_desc *fdesc;
+	enum dma_status	status;
+};
+
+struct st_fdma_dev {
+	struct device *dev;
+	const struct st_fdma_driverdata *drvdata;
+	struct dma_device dma_device;
+
+	struct st_slim_rproc *slim_rproc;
+
+	int irq;
+
+	struct st_fdma_chan *chans;
+
+	spinlock_t dreq_lock;
+	unsigned long dreq_mask;
+
+	u32 nr_channels;
+	char fw_name[FW_NAME_SIZE];
+};
+
+/* Peripheral Registers*/
+
+#define FDMA_CMD_STA_OFST	0xFC0
+#define FDMA_CMD_SET_OFST	0xFC4
+#define FDMA_CMD_CLR_OFST	0xFC8
+#define FDMA_CMD_MASK_OFST	0xFCC
+#define FDMA_CMD_START(ch)		(0x1 << (ch << 1))
+#define FDMA_CMD_PAUSE(ch)		(0x2 << (ch << 1))
+#define FDMA_CMD_FLUSH(ch)		(0x3 << (ch << 1))
+
+#define FDMA_INT_STA_OFST	0xFD0
+#define FDMA_INT_STA_CH			0x1
+#define FDMA_INT_STA_ERR		0x2
+
+#define FDMA_INT_SET_OFST	0xFD4
+#define FDMA_INT_CLR_OFST	0xFD8
+#define FDMA_INT_MASK_OFST	0xFDC
+
+#define fdma_read(fdev, name) \
+	readl((fdev)->slim_rproc->peri + name)
+
+#define fdma_write(fdev, val, name) \
+	writel((val), (fdev)->slim_rproc->peri + name)
+
+/* fchan interface (dmem) */
+#define FDMA_CH_CMD_OFST	0x200
+#define FDMA_CH_CMD_STA_MASK		GENMASK(1, 0)
+#define FDMA_CH_CMD_STA_IDLE		(0x0)
+#define FDMA_CH_CMD_STA_START		(0x1)
+#define FDMA_CH_CMD_STA_RUNNING		(0x2)
+#define FDMA_CH_CMD_STA_PAUSED		(0x3)
+#define FDMA_CH_CMD_ERR_MASK		GENMASK(4, 2)
+#define FDMA_CH_CMD_ERR_INT		(0x0 << 2)
+#define FDMA_CH_CMD_ERR_NAND		(0x1 << 2)
+#define FDMA_CH_CMD_ERR_MCHI		(0x2 << 2)
+#define FDMA_CH_CMD_DATA_MASK		GENMASK(31, 5)
+#define fchan_read(fchan, name) \
+	readl((fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * 0x4 \
+			+ name)
+
+#define fchan_write(fchan, val, name) \
+	writel((val), (fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * 0x4 \
+			+ name)
+
+/* req interface */
+#define FDMA_REQ_CTRL_OFST	0x240
+#define dreq_write(fchan, val, name) \
+	writel((val), (fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ fchan->dreq_line * 0x04 \
+			+ name)
+/* node interface */
+#define FDMA_NODE_SZ 128
+#define FDMA_PTRN_OFST		0x800
+#define FDMA_CNTN_OFST		0x808
+#define FDMA_SADDRN_OFST	0x80c
+#define FDMA_DADDRN_OFST	0x810
+#define fnode_read(fchan, name) \
+	readl((fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * FDMA_NODE_SZ \
+			+ name)
+
+#define fnode_write(fchan, val, name) \
+	writel((val), (fchan)->fdev->slim_rproc->mem[ST_SLIM_DMEM].cpu_addr \
+			+ (fchan)->vchan.chan.chan_id * FDMA_NODE_SZ \
+			+ name)
+
+/*
+ * request control bits
+ */
+#define FDMA_REQ_CTRL_NUM_OPS_MASK	GENMASK(31, 24)
+#define FDMA_REQ_CTRL_NUM_OPS(n)	(FDMA_REQ_CTRL_NUM_OPS_MASK & \
+					((n) << 24))
+#define FDMA_REQ_CTRL_INITIATOR_MASK	BIT(22)
+#define FDMA_REQ_CTRL_INIT0		(0x0 << 22)
+#define FDMA_REQ_CTRL_INIT1		(0x1 << 22)
+#define FDMA_REQ_CTRL_INC_ADDR_ON	BIT(21)
+#define FDMA_REQ_CTRL_DATA_SWAP_ON	BIT(17)
+#define FDMA_REQ_CTRL_WNR		BIT(14)
+#define FDMA_REQ_CTRL_OPCODE_MASK	GENMASK(7, 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST1	(0x0 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST2	(0x1 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST4	(0x2 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST8	(0x3 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST16	(0x4 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST32	(0x5 << 4)
+#define FDMA_REQ_CTRL_OPCODE_LD_ST64	(0x6 << 4)
+#define FDMA_REQ_CTRL_HOLDOFF_MASK	GENMASK(2, 0)
+#define FDMA_REQ_CTRL_HOLDOFF(n)	((n) & FDMA_REQ_CTRL_HOLDOFF_MASK)
+
+/* bits used by client to configure request control */
+#define FDMA_REQ_CTRL_CFG_MASK (FDMA_REQ_CTRL_HOLDOFF_MASK | \
+				FDMA_REQ_CTRL_DATA_SWAP_ON | \
+				FDMA_REQ_CTRL_INC_ADDR_ON | \
+				FDMA_REQ_CTRL_INITIATOR_MASK)
+
+#endif	/* __DMA_ST_FDMA_H */
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 05/19] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
  2016-09-05 13:16 ` Peter Griffin
  (?)
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization, Ludovic Barre

This patch adds support for the Flexible Direct Memory Access (FDMA) core
driver. The FDMA is a slim core CPU with a dedicated firmware.
It is a general purpose DMA controller capable of supporting 16
independent DMA channels. Data moves maybe from memory to memory
or between memory and paced latency critical real time targets and it
is found on al STi based chipsets.

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/dma/Kconfig   |  15 +-
 drivers/dma/Makefile  |   1 +
 drivers/dma/st_fdma.c | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 914 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma/st_fdma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 739f797..7c5d946 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -437,6 +437,19 @@ config STE_DMA40
 	help
 	  Support for ST-Ericsson DMA40 controller
 
+config ST_FDMA
+	tristate "ST FDMA dmaengine support"
+	depends on ARCH_STI
+	select ST_SLIM_REMOTEPROC
+	select DMA_ENGINE
+	select DMA_VIRTUAL_CHANNELS
+	help
+	  Enable support for ST FDMA controller.
+	  It supports 16 independent DMA channels, accepts up to 32 DMA requests
+
+	  Say Y here if you have such a chipset.
+	  If unsure, say N.
+
 config STM32_DMA
 	bool "STMicroelectronics STM32 DMA support"
 	depends on ARCH_STM32
@@ -449,6 +462,7 @@ config STM32_DMA
 	  If you have a board based on such a MCU and wish to use DMA say Y or M
 	  here.
 
+
 config S3C24XX_DMAC
 	bool "Samsung S3C24XX DMA support"
 	depends on ARCH_S3C24XX
@@ -567,7 +581,6 @@ config ZX_DMA
 	help
 	  Support the DMA engine for ZTE ZX296702 platform devices.
 
-
 # driver files
 source "drivers/dma/bestcomm/Kconfig"
 
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index e4dc9ca..a4fa336 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
 obj-$(CONFIG_TI_EDMA) += edma.o
 obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-$(CONFIG_ST_FDMA) += st_fdma.o
 
 obj-y += qcom/
 obj-y += xilinx/
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
new file mode 100644
index 0000000..515e1d4
--- /dev/null
+++ b/drivers/dma/st_fdma.c
@@ -0,0 +1,899 @@
+/*
+ * DMA driver for STMicroelectronics STi FDMA controller
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * Author: Ludovic Barre <Ludovic.barre@st.com>
+ *	   Peter Griffin <peter.griffin@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_dma.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/remoteproc.h>
+
+#include "st_fdma.h"
+
+static inline struct st_fdma_chan *to_st_fdma_chan(struct dma_chan *c)
+{
+	return container_of(c, struct st_fdma_chan, vchan.chan);
+}
+
+static struct st_fdma_desc *to_st_fdma_desc(struct virt_dma_desc *vd)
+{
+	return container_of(vd, struct st_fdma_desc, vdesc);
+}
+
+static int st_fdma_dreq_get(struct st_fdma_chan *fchan)
+{
+	struct st_fdma_dev *fdev = fchan->fdev;
+	u32 req_line_cfg = fchan->cfg.req_line;
+	u32 dreq_line;
+	int try = 0;
+
+	/*
+	 * dreq_mask is shared for n channels of fdma, so all accesses must be
+	 * atomic. if the dreq_mask is changed between ffz and set_bit,
+	 * we retry
+	 */
+	do {
+		if (fdev->dreq_mask == ~0L) {
+			dev_err(fdev->dev, "No req lines available\n");
+			return -EINVAL;
+		}
+
+		if (try || req_line_cfg >= ST_FDMA_NR_DREQS) {
+			dev_err(fdev->dev, "Invalid or used req line\n");
+			return -EINVAL;
+		} else {
+			dreq_line = req_line_cfg;
+		}
+
+		try++;
+	} while (test_and_set_bit(dreq_line, &fdev->dreq_mask));
+
+	dev_dbg(fdev->dev, "get dreq_line:%d mask:%#lx\n",
+		dreq_line, fdev->dreq_mask);
+
+	return dreq_line;
+}
+
+static void st_fdma_dreq_put(struct st_fdma_chan *fchan)
+{
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	dev_dbg(fdev->dev, "put dreq_line:%#x\n", fchan->dreq_line);
+	clear_bit(fchan->dreq_line, &fdev->dreq_mask);
+}
+
+static void st_fdma_xfer_desc(struct st_fdma_chan *fchan)
+{
+	struct virt_dma_desc *vdesc;
+	unsigned long nbytes, ch_cmd, cmd;
+
+	vdesc = vchan_next_desc(&fchan->vchan);
+	if (!vdesc)
+		return;
+
+	fchan->fdesc = to_st_fdma_desc(vdesc);
+	nbytes = fchan->fdesc->node[0].desc->nbytes;
+	cmd = FDMA_CMD_START(fchan->vchan.chan.chan_id);
+	ch_cmd = fchan->fdesc->node[0].pdesc | FDMA_CH_CMD_STA_START;
+
+	/* start the channel for the descriptor */
+	fnode_write(fchan, nbytes, FDMA_CNTN_OFST);
+	fchan_write(fchan, ch_cmd, FDMA_CH_CMD_OFST);
+	writel(cmd,
+		fchan->fdev->slim_rproc->peri + FDMA_CMD_SET_OFST);
+
+	dev_dbg(fchan->fdev->dev, "start chan:%d\n", fchan->vchan.chan.chan_id);
+}
+
+static void st_fdma_ch_sta_update(struct st_fdma_chan *fchan,
+				  unsigned long int_sta)
+{
+	unsigned long ch_sta, ch_err;
+	int ch_id = fchan->vchan.chan.chan_id;
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	ch_sta = fchan_read(fchan, FDMA_CH_CMD_OFST);
+	ch_err = ch_sta & FDMA_CH_CMD_ERR_MASK;
+	ch_sta &= FDMA_CH_CMD_STA_MASK;
+
+	if (int_sta & FDMA_INT_STA_ERR) {
+		dev_warn(fdev->dev, "chan:%d, error:%ld\n", ch_id, ch_err);
+		fchan->status = DMA_ERROR;
+		return;
+	}
+
+	switch (ch_sta) {
+	case FDMA_CH_CMD_STA_PAUSED:
+		fchan->status = DMA_PAUSED;
+		break;
+
+	case FDMA_CH_CMD_STA_RUNNING:
+		fchan->status = DMA_IN_PROGRESS;
+		break;
+	}
+}
+
+static irqreturn_t st_fdma_irq_handler(int irq, void *dev_id)
+{
+	struct st_fdma_dev *fdev = dev_id;
+	irqreturn_t ret = IRQ_NONE;
+	struct st_fdma_chan *fchan = &fdev->chans[0];
+	unsigned long int_sta, clr;
+
+	int_sta = fdma_read(fdev, FDMA_INT_STA_OFST);
+	clr = int_sta;
+
+	for (; int_sta != 0 ; int_sta >>= 2, fchan++) {
+		if (!(int_sta & (FDMA_INT_STA_CH | FDMA_INT_STA_ERR)))
+			continue;
+
+		spin_lock(&fchan->vchan.lock);
+		st_fdma_ch_sta_update(fchan, int_sta);
+
+		if (fchan->fdesc) {
+			if (!fchan->fdesc->iscyclic) {
+				list_del(&fchan->fdesc->vdesc.node);
+				vchan_cookie_complete(&fchan->fdesc->vdesc);
+				fchan->fdesc = NULL;
+				fchan->status = DMA_COMPLETE;
+			} else {
+				vchan_cyclic_callback(&fchan->fdesc->vdesc);
+			}
+
+			/* Start the next descriptor (if available) */
+			if (!fchan->fdesc)
+				st_fdma_xfer_desc(fchan);
+		}
+
+		spin_unlock(&fchan->vchan.lock);
+		ret = IRQ_HANDLED;
+	}
+
+	fdma_write(fdev, clr, FDMA_INT_CLR_OFST);
+
+	return ret;
+}
+
+static struct dma_chan *st_fdma_of_xlate(struct of_phandle_args *dma_spec,
+					 struct of_dma *ofdma)
+{
+	struct st_fdma_dev *fdev = ofdma->of_dma_data;
+	struct dma_chan *chan;
+	struct st_fdma_chan *fchan;
+	int ret;
+
+	if (dma_spec->args_count < 1)
+		return ERR_PTR(-EINVAL);
+
+	if (fdev->dma_device.dev->of_node != dma_spec->np)
+		return ERR_PTR(-EINVAL);
+
+	ret = rproc_boot(fdev->slim_rproc->rproc);
+	if (ret == -ENOENT)
+		return ERR_PTR(-EPROBE_DEFER);
+	else if (ret)
+		return ERR_PTR(ret);
+
+	chan = dma_get_any_slave_channel(&fdev->dma_device);
+	if (!chan)
+		goto err_chan;
+
+	fchan = to_st_fdma_chan(chan);
+
+	fchan->cfg.of_node = dma_spec->np;
+	fchan->cfg.req_line = dma_spec->args[0];
+	fchan->cfg.req_ctrl = 0;
+	fchan->cfg.type = ST_FDMA_TYPE_FREE_RUN;
+
+	if (dma_spec->args_count > 1)
+		fchan->cfg.req_ctrl = dma_spec->args[1]
+			& FDMA_REQ_CTRL_CFG_MASK;
+
+	if (dma_spec->args_count > 2)
+		fchan->cfg.type = dma_spec->args[2];
+
+	if (fchan->cfg.type == ST_FDMA_TYPE_FREE_RUN) {
+		fchan->dreq_line = 0;
+	} else {
+		fchan->dreq_line = st_fdma_dreq_get(fchan);
+		if (IS_ERR_VALUE(fchan->dreq_line)) {
+			chan = ERR_PTR(fchan->dreq_line);
+			goto err_chan;
+		}
+	}
+
+	dev_dbg(fdev->dev, "xlate req_line:%d type:%d req_ctrl:%#lx\n",
+		fchan->cfg.req_line, fchan->cfg.type, fchan->cfg.req_ctrl);
+
+	return chan;
+
+err_chan:
+	rproc_shutdown(fdev->slim_rproc->rproc);
+	return chan;
+
+}
+
+static void st_fdma_free_desc(struct virt_dma_desc *vdesc)
+{
+	struct st_fdma_desc *fdesc;
+	int i;
+
+	fdesc = to_st_fdma_desc(vdesc);
+	for (i = 0; i < fdesc->n_nodes; i++)
+		dma_pool_free(fdesc->fchan->node_pool, fdesc->node[i].desc,
+			      fdesc->node[i].pdesc);
+	kfree(fdesc);
+}
+
+static struct st_fdma_desc *st_fdma_alloc_desc(struct st_fdma_chan *fchan,
+					       int sg_len)
+{
+	struct st_fdma_desc *fdesc;
+	int i;
+
+	fdesc = kzalloc(sizeof(*fdesc) +
+			sizeof(struct st_fdma_sw_node) * sg_len, GFP_NOWAIT);
+	if (!fdesc)
+		return NULL;
+
+	fdesc->fchan = fchan;
+	fdesc->n_nodes = sg_len;
+	for (i = 0; i < sg_len; i++) {
+		fdesc->node[i].desc = dma_pool_alloc(fchan->node_pool,
+				GFP_NOWAIT, &fdesc->node[i].pdesc);
+		if (!fdesc->node[i].desc)
+			goto err;
+	}
+	return fdesc;
+
+err:
+	while (--i >= 0)
+		dma_pool_free(fchan->node_pool, fdesc->node[i].desc,
+			      fdesc->node[i].pdesc);
+	kfree(fdesc);
+	return NULL;
+}
+
+static int st_fdma_alloc_chan_res(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+
+	/* Create the dma pool for descriptor allocation */
+	fchan->node_pool = dma_pool_create(dev_name(&chan->dev->device),
+					    fchan->fdev->dev,
+					    sizeof(struct st_fdma_hw_node),
+					    __alignof__(struct st_fdma_hw_node),
+					    0);
+
+	if (!fchan->node_pool) {
+		dev_err(fchan->fdev->dev, "unable to allocate desc pool\n");
+		return -ENOMEM;
+	}
+
+	dev_dbg(fchan->fdev->dev, "alloc ch_id:%d type:%d\n",
+		fchan->vchan.chan.chan_id, fchan->cfg.type);
+
+	return 0;
+}
+
+static void st_fdma_free_chan_res(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	struct rproc *rproc = fchan->fdev->slim_rproc->rproc;
+	unsigned long flags;
+
+	LIST_HEAD(head);
+
+	dev_dbg(fchan->fdev->dev, "%s: freeing chan:%d\n",
+		__func__, fchan->vchan.chan.chan_id);
+
+	if (fchan->cfg.type != ST_FDMA_TYPE_FREE_RUN)
+		st_fdma_dreq_put(fchan);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	fchan->fdesc = NULL;
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	dma_pool_destroy(fchan->node_pool);
+	fchan->node_pool = NULL;
+	memset(&fchan->cfg, 0, sizeof(struct st_fdma_cfg));
+
+	rproc_shutdown(rproc);
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_dma_memcpy(
+	struct dma_chan *chan,	dma_addr_t dst, dma_addr_t src,
+	size_t len, unsigned long flags)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	struct st_fdma_hw_node *hw_node;
+
+	if (!len)
+		return NULL;
+
+	fchan = to_st_fdma_chan(chan);
+
+	/* We only require a single descriptor */
+	fdesc = st_fdma_alloc_desc(fchan, 1);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	hw_node = fdesc->node[0].desc;
+	hw_node->next = 0;
+	hw_node->control = FDMA_NODE_CTRL_REQ_MAP_FREE_RUN;
+	hw_node->control |= FDMA_NODE_CTRL_SRC_INCR;
+	hw_node->control |= FDMA_NODE_CTRL_DST_INCR;
+	hw_node->control |= FDMA_NODE_CTRL_INT_EON;
+	hw_node->nbytes = len;
+	hw_node->saddr = src;
+	hw_node->daddr = dst;
+	hw_node->generic.length = len;
+	hw_node->generic.sstride = 0;
+	hw_node->generic.dstride = 0;
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static int config_reqctrl(struct st_fdma_chan *fchan,
+			  enum dma_transfer_direction direction)
+{
+	u32 maxburst = 0, addr = 0;
+	enum dma_slave_buswidth width;
+	int ch_id = fchan->vchan.chan.chan_id;
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	switch (direction) {
+
+	case DMA_DEV_TO_MEM:
+		fchan->cfg.req_ctrl &= ~FDMA_REQ_CTRL_WNR;
+		maxburst = fchan->scfg.src_maxburst;
+		width = fchan->scfg.src_addr_width;
+		addr = fchan->scfg.src_addr;
+		break;
+
+	case DMA_MEM_TO_DEV:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_WNR;
+		maxburst = fchan->scfg.dst_maxburst;
+		width = fchan->scfg.dst_addr_width;
+		addr = fchan->scfg.dst_addr;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	fchan->cfg.req_ctrl &= ~FDMA_REQ_CTRL_OPCODE_MASK;
+
+	switch (width) {
+
+	case DMA_SLAVE_BUSWIDTH_1_BYTE:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST1;
+		break;
+
+	case DMA_SLAVE_BUSWIDTH_2_BYTES:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST2;
+		break;
+
+	case DMA_SLAVE_BUSWIDTH_4_BYTES:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST4;
+		break;
+
+	case DMA_SLAVE_BUSWIDTH_8_BYTES:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST8;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	fchan->cfg.req_ctrl &= ~FDMA_REQ_CTRL_NUM_OPS_MASK;
+	fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_NUM_OPS(maxburst-1);
+	dreq_write(fchan, fchan->cfg.req_ctrl, FDMA_REQ_CTRL_OFST);
+
+	fchan->cfg.dev_addr = addr;
+	fchan->cfg.dir = direction;
+
+	dev_dbg(fdev->dev, "chan:%d config_reqctrl:%#x req_ctrl:%#lx\n",
+		ch_id, addr, fchan->cfg.req_ctrl);
+
+	return 0;
+}
+
+static void fill_hw_node(struct st_fdma_hw_node *hw_node,
+			struct st_fdma_chan *fchan,
+			enum dma_transfer_direction direction)
+{
+	if (direction == DMA_MEM_TO_DEV) {
+		hw_node->control |= FDMA_NODE_CTRL_SRC_INCR;
+		hw_node->control |= FDMA_NODE_CTRL_DST_STATIC;
+		hw_node->daddr = fchan->cfg.dev_addr;
+	} else {
+		hw_node->control |= FDMA_NODE_CTRL_SRC_STATIC;
+		hw_node->control |= FDMA_NODE_CTRL_DST_INCR;
+		hw_node->saddr = fchan->cfg.dev_addr;
+	}
+
+	hw_node->generic.sstride = 0;
+	hw_node->generic.dstride = 0;
+}
+
+static inline struct st_fdma_chan *st_fdma_prep_common(struct dma_chan *chan,
+		size_t len, enum dma_transfer_direction direction)
+{
+	struct st_fdma_chan *fchan;
+
+	if (!chan || !len)
+		return NULL;
+
+	fchan = to_st_fdma_chan(chan);
+
+	if (!is_slave_direction(direction)) {
+		dev_err(fchan->fdev->dev, "bad direction?\n");
+		return NULL;
+	}
+
+	return fchan;
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_dma_cyclic(
+		struct dma_chan *chan, dma_addr_t buf_addr, size_t len,
+		size_t period_len, enum dma_transfer_direction direction,
+		unsigned long flags)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	int sg_len, i;
+
+	fchan = st_fdma_prep_common(chan, len, direction);
+	if (!fchan)
+		return NULL;
+
+	if (!period_len)
+		return NULL;
+
+	if (config_reqctrl(fchan, direction)) {
+		dev_err(fchan->fdev->dev, "bad width or direction\n");
+		return NULL;
+	}
+
+	/* the buffer length must be a multiple of period_len */
+	if (len % period_len != 0) {
+		dev_err(fchan->fdev->dev, "len is not multiple of period\n");
+		return NULL;
+	}
+
+	sg_len = len / period_len;
+	fdesc = st_fdma_alloc_desc(fchan, sg_len);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	fdesc->iscyclic = true;
+
+	for (i = 0; i < sg_len; i++) {
+		struct st_fdma_hw_node *hw_node = fdesc->node[i].desc;
+
+		hw_node->next = fdesc->node[(i + 1) % sg_len].pdesc;
+
+		hw_node->control =
+			FDMA_NODE_CTRL_REQ_MAP_DREQ(fchan->dreq_line);
+		hw_node->control |= FDMA_NODE_CTRL_INT_EON;
+
+		fill_hw_node(hw_node, fchan, direction);
+
+		if (direction == DMA_MEM_TO_DEV)
+			hw_node->saddr = buf_addr + (i * period_len);
+		else
+			hw_node->daddr = buf_addr + (i * period_len);
+
+		hw_node->nbytes = period_len;
+		hw_node->generic.length = period_len;
+	}
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_slave_sg(
+		struct dma_chan *chan, struct scatterlist *sgl,
+		unsigned int sg_len, enum dma_transfer_direction direction,
+		unsigned long flags, void *context)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	struct st_fdma_hw_node *hw_node;
+	struct scatterlist *sg;
+	int i;
+
+	fchan = st_fdma_prep_common(chan, sg_len, direction);
+	if (!fchan)
+		return NULL;
+
+	if (!sgl)
+		return NULL;
+
+	fdesc = st_fdma_alloc_desc(fchan, sg_len);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	fdesc->iscyclic = false;
+
+	for_each_sg(sgl, sg, sg_len, i) {
+		hw_node = fdesc->node[i].desc;
+
+		hw_node->next = fdesc->node[(i + 1) % sg_len].pdesc;
+		hw_node->control = FDMA_NODE_CTRL_REQ_MAP_DREQ(fchan->dreq_line);
+
+		fill_hw_node(hw_node, fchan, direction);
+
+		if (direction == DMA_MEM_TO_DEV)
+			hw_node->saddr = sg_dma_address(sg);
+		else
+			hw_node->daddr = sg_dma_address(sg);
+
+		hw_node->nbytes = sg_dma_len(sg);
+		hw_node->generic.length = sg_dma_len(sg);
+	}
+
+	/* interrupt at end of last node */
+	hw_node->control |= FDMA_NODE_CTRL_INT_EON;
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static size_t st_fdma_desc_residue(struct st_fdma_chan *fchan,
+				   struct virt_dma_desc *vdesc,
+				   bool in_progress)
+{
+	struct st_fdma_desc *fdesc = fchan->fdesc;
+	size_t residue = 0;
+	dma_addr_t cur_addr = 0;
+	int i;
+
+	if (in_progress) {
+		cur_addr = fchan_read(fchan, FDMA_CH_CMD_OFST);
+		cur_addr &= FDMA_CH_CMD_DATA_MASK;
+	}
+
+	for (i = fchan->fdesc->n_nodes - 1 ; i >= 0; i--) {
+		if (cur_addr == fdesc->node[i].pdesc) {
+			residue += fnode_read(fchan, FDMA_CNTN_OFST);
+			break;
+		}
+		residue += fdesc->node[i].desc->nbytes;
+	}
+
+	return residue;
+}
+
+static enum dma_status st_fdma_tx_status(struct dma_chan *chan,
+					 dma_cookie_t cookie,
+					 struct dma_tx_state *txstate)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	struct virt_dma_desc *vd;
+	enum dma_status ret;
+	unsigned long flags;
+
+	ret = dma_cookie_status(chan, cookie, txstate);
+	if (ret == DMA_COMPLETE || !txstate)
+		return ret;
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	vd = vchan_find_desc(&fchan->vchan, cookie);
+	if (fchan->fdesc && cookie == fchan->fdesc->vdesc.tx.cookie)
+		txstate->residue = st_fdma_desc_residue(fchan, vd, true);
+	else if (vd)
+		txstate->residue = st_fdma_desc_residue(fchan, vd, false);
+	else
+		txstate->residue = 0;
+
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return ret;
+}
+
+static void st_fdma_issue_pending(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	unsigned long flags;
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+
+	if (vchan_issue_pending(&fchan->vchan) && !fchan->fdesc)
+		st_fdma_xfer_desc(fchan);
+
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+}
+
+static int st_fdma_pause(struct dma_chan *chan)
+{
+	unsigned long flags;
+	LIST_HEAD(head);
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+	unsigned long cmd = FDMA_CMD_PAUSE(ch_id);
+
+	dev_dbg(fchan->fdev->dev, "pause chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	if (fchan->fdesc)
+		fdma_write(fchan->fdev, cmd, FDMA_CMD_SET_OFST);
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return 0;
+}
+
+static int st_fdma_resume(struct dma_chan *chan)
+{
+	unsigned long flags;
+	unsigned long val;
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+
+	dev_dbg(fchan->fdev->dev, "resume chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	if (fchan->fdesc) {
+		val = fchan_read(fchan, FDMA_CH_CMD_OFST);
+		val &= FDMA_CH_CMD_DATA_MASK;
+		fchan_write(fchan, val, FDMA_CH_CMD_OFST);
+	}
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return 0;
+}
+
+static int st_fdma_terminate_all(struct dma_chan *chan)
+{
+	unsigned long flags;
+	LIST_HEAD(head);
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+	unsigned long cmd = FDMA_CMD_PAUSE(ch_id);
+
+	dev_dbg(fchan->fdev->dev, "terminate chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	fdma_write(fchan->fdev, cmd, FDMA_CMD_SET_OFST);
+	fchan->fdesc = NULL;
+	vchan_get_all_descriptors(&fchan->vchan, &head);
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+	vchan_dma_desc_free_list(&fchan->vchan, &head);
+
+	return 0;
+}
+
+static int st_fdma_slave_config(struct dma_chan *chan,
+				struct dma_slave_config *slave_cfg)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+
+	memcpy(&fchan->scfg, slave_cfg, sizeof(fchan->scfg));
+	return 0;
+}
+
+static const struct st_fdma_driverdata fdma_mpe31_stih407_11 = {
+	.name = "STiH407",
+	.id = 0,
+};
+
+static const struct st_fdma_driverdata fdma_mpe31_stih407_12 = {
+	.name = "STiH407",
+	.id = 1,
+};
+
+static const struct st_fdma_driverdata fdma_mpe31_stih407_13 = {
+	.name = "STiH407",
+	.id = 2,
+};
+
+static const struct of_device_id st_fdma_match[] = {
+	{ .compatible = "st,stih407-fdma-mpe31-11"
+	  , .data = &fdma_mpe31_stih407_11 },
+	{ .compatible = "st,stih407-fdma-mpe31-12"
+	  , .data = &fdma_mpe31_stih407_12 },
+	{ .compatible = "st,stih407-fdma-mpe31-13"
+	  , .data = &fdma_mpe31_stih407_13 },
+	{},
+};
+MODULE_DEVICE_TABLE(of, st_fdma_match);
+
+static int st_fdma_parse_dt(struct platform_device *pdev,
+			const struct st_fdma_driverdata *drvdata,
+			struct st_fdma_dev *fdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int ret;
+
+	if (!np)
+		goto err;
+
+	ret = of_property_read_u32(np, "dma-channels", &fdev->nr_channels);
+	if (ret)
+		goto err;
+
+	snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
+		drvdata->name, drvdata->id);
+
+err:
+	return ret;
+}
+#define FDMA_DMA_BUSWIDTHS	(BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static void st_fdma_free(struct st_fdma_dev *fdev)
+{
+	struct st_fdma_chan *fchan;
+	int i;
+
+	for (i = 0; i < fdev->nr_channels; i++) {
+		fchan = &fdev->chans[i];
+		list_del(&fchan->vchan.chan.device_node);
+		tasklet_kill(&fchan->vchan.task);
+	}
+}
+
+static int st_fdma_probe(struct platform_device *pdev)
+{
+	struct st_fdma_dev *fdev;
+	const struct of_device_id *match;
+	struct device_node *np = pdev->dev.of_node;
+	const struct st_fdma_driverdata *drvdata;
+	int ret, i;
+
+	match = of_match_device((st_fdma_match), &pdev->dev);
+	if (!match || !match->data) {
+		dev_err(&pdev->dev, "No device match found\n");
+		return -ENODEV;
+	}
+
+	drvdata = match->data;
+
+	fdev = devm_kzalloc(&pdev->dev, sizeof(*fdev), GFP_KERNEL);
+	if (!fdev)
+		return -ENOMEM;
+
+	ret = st_fdma_parse_dt(pdev, drvdata, fdev);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to find platform data\n");
+		goto err;
+	}
+
+	fdev->chans = devm_kcalloc(&pdev->dev, fdev->nr_channels,
+				   sizeof(struct st_fdma_chan), GFP_KERNEL);
+	if (!fdev->chans)
+		return -ENOMEM;
+
+	fdev->dev = &pdev->dev;
+	fdev->drvdata = drvdata;
+	platform_set_drvdata(pdev, fdev);
+
+	fdev->irq = platform_get_irq(pdev, 0);
+	if (fdev->irq < 0) {
+		dev_err(&pdev->dev, "Failed to get irq resource\n");
+		return -EINVAL;
+	}
+
+	ret = devm_request_irq(&pdev->dev, fdev->irq, st_fdma_irq_handler, 0,
+			       dev_name(&pdev->dev), fdev);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to request irq (%d)\n", ret);
+		goto err;
+	}
+
+	fdev->slim_rproc = st_slim_rproc_alloc(pdev, fdev->fw_name);
+	if (!fdev->slim_rproc) {
+		ret = PTR_ERR(fdev->slim_rproc);
+		dev_err(&pdev->dev, "slim_rproc_alloc failed (%d)\n", ret);
+		goto err;
+	}
+
+	/* Initialise list of FDMA channels */
+	INIT_LIST_HEAD(&fdev->dma_device.channels);
+	for (i = 0; i < fdev->nr_channels; i++) {
+		struct st_fdma_chan *fchan = &fdev->chans[i];
+
+		fchan->fdev = fdev;
+		fchan->vchan.desc_free = st_fdma_free_desc;
+		vchan_init(&fchan->vchan, &fdev->dma_device);
+	}
+
+	/* Initialise the FDMA dreq (reserve 0 & 31 for FDMA use) */
+	fdev->dreq_mask = BIT(0) | BIT(31);
+
+	dma_cap_set(DMA_SLAVE, fdev->dma_device.cap_mask);
+	dma_cap_set(DMA_CYCLIC, fdev->dma_device.cap_mask);
+	dma_cap_set(DMA_MEMCPY, fdev->dma_device.cap_mask);
+
+	fdev->dma_device.dev = &pdev->dev;
+	fdev->dma_device.device_alloc_chan_resources = st_fdma_alloc_chan_res;
+	fdev->dma_device.device_free_chan_resources = st_fdma_free_chan_res;
+	fdev->dma_device.device_prep_dma_cyclic	= st_fdma_prep_dma_cyclic;
+	fdev->dma_device.device_prep_slave_sg = st_fdma_prep_slave_sg;
+	fdev->dma_device.device_prep_dma_memcpy = st_fdma_prep_dma_memcpy;
+	fdev->dma_device.device_tx_status = st_fdma_tx_status;
+	fdev->dma_device.device_issue_pending = st_fdma_issue_pending;
+	fdev->dma_device.device_terminate_all = st_fdma_terminate_all;
+	fdev->dma_device.device_config = st_fdma_slave_config;
+	fdev->dma_device.device_pause = st_fdma_pause;
+	fdev->dma_device.device_resume = st_fdma_resume;
+
+	fdev->dma_device.src_addr_widths = FDMA_DMA_BUSWIDTHS;
+	fdev->dma_device.dst_addr_widths = FDMA_DMA_BUSWIDTHS;
+	fdev->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+	fdev->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+
+	ret = dma_async_device_register(&fdev->dma_device);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"Failed to register DMA device (%d)\n", ret);
+		goto err_rproc;
+	}
+
+	ret = of_dma_controller_register(np, st_fdma_of_xlate, fdev);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"Failed to register controller (%d)\n", ret);
+		goto err_dma_dev;
+	}
+
+	dev_info(&pdev->dev, "ST FDMA engine driver, irq:%d\n", fdev->irq);
+
+	return 0;
+
+err_dma_dev:
+	dma_async_device_unregister(&fdev->dma_device);
+err_rproc:
+	st_fdma_free(fdev);
+	st_slim_rproc_put(fdev->slim_rproc);
+err:
+	return ret;
+}
+
+static int st_fdma_remove(struct platform_device *pdev)
+{
+	struct st_fdma_dev *fdev = platform_get_drvdata(pdev);
+
+	devm_free_irq(&pdev->dev, fdev->irq, fdev);
+	st_slim_rproc_put(fdev->slim_rproc);
+	of_dma_controller_free(pdev->dev.of_node);
+	dma_async_device_unregister(&fdev->dma_device);
+
+	return 0;
+}
+
+static struct platform_driver st_fdma_platform_driver = {
+	.driver = {
+		.name = DRIVER_NAME,
+		.of_match_table = st_fdma_match,
+	},
+	.probe = st_fdma_probe,
+	.remove = st_fdma_remove,
+};
+module_platform_driver(st_fdma_platform_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("STMicroelectronics FDMA engine driver");
+MODULE_AUTHOR("Ludovic.barre <Ludovic.barre@st.com>");
+MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
+MODULE_ALIAS("platform: " DRIVER_NAME);
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 05/19] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones, Ludovic Barre

This patch adds support for the Flexible Direct Memory Access (FDMA) core
driver. The FDMA is a slim core CPU with a dedicated firmware.
It is a general purpose DMA controller capable of supporting 16
independent DMA channels. Data moves maybe from memory to memory
or between memory and paced latency critical real time targets and it
is found on al STi based chipsets.

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/dma/Kconfig   |  15 +-
 drivers/dma/Makefile  |   1 +
 drivers/dma/st_fdma.c | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 914 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma/st_fdma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 739f797..7c5d946 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -437,6 +437,19 @@ config STE_DMA40
 	help
 	  Support for ST-Ericsson DMA40 controller
 
+config ST_FDMA
+	tristate "ST FDMA dmaengine support"
+	depends on ARCH_STI
+	select ST_SLIM_REMOTEPROC
+	select DMA_ENGINE
+	select DMA_VIRTUAL_CHANNELS
+	help
+	  Enable support for ST FDMA controller.
+	  It supports 16 independent DMA channels, accepts up to 32 DMA requests
+
+	  Say Y here if you have such a chipset.
+	  If unsure, say N.
+
 config STM32_DMA
 	bool "STMicroelectronics STM32 DMA support"
 	depends on ARCH_STM32
@@ -449,6 +462,7 @@ config STM32_DMA
 	  If you have a board based on such a MCU and wish to use DMA say Y or M
 	  here.
 
+
 config S3C24XX_DMAC
 	bool "Samsung S3C24XX DMA support"
 	depends on ARCH_S3C24XX
@@ -567,7 +581,6 @@ config ZX_DMA
 	help
 	  Support the DMA engine for ZTE ZX296702 platform devices.
 
-
 # driver files
 source "drivers/dma/bestcomm/Kconfig"
 
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index e4dc9ca..a4fa336 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
 obj-$(CONFIG_TI_EDMA) += edma.o
 obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-$(CONFIG_ST_FDMA) += st_fdma.o
 
 obj-y += qcom/
 obj-y += xilinx/
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
new file mode 100644
index 0000000..515e1d4
--- /dev/null
+++ b/drivers/dma/st_fdma.c
@@ -0,0 +1,899 @@
+/*
+ * DMA driver for STMicroelectronics STi FDMA controller
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * Author: Ludovic Barre <Ludovic.barre@st.com>
+ *	   Peter Griffin <peter.griffin@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_dma.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/remoteproc.h>
+
+#include "st_fdma.h"
+
+static inline struct st_fdma_chan *to_st_fdma_chan(struct dma_chan *c)
+{
+	return container_of(c, struct st_fdma_chan, vchan.chan);
+}
+
+static struct st_fdma_desc *to_st_fdma_desc(struct virt_dma_desc *vd)
+{
+	return container_of(vd, struct st_fdma_desc, vdesc);
+}
+
+static int st_fdma_dreq_get(struct st_fdma_chan *fchan)
+{
+	struct st_fdma_dev *fdev = fchan->fdev;
+	u32 req_line_cfg = fchan->cfg.req_line;
+	u32 dreq_line;
+	int try = 0;
+
+	/*
+	 * dreq_mask is shared for n channels of fdma, so all accesses must be
+	 * atomic. if the dreq_mask is changed between ffz and set_bit,
+	 * we retry
+	 */
+	do {
+		if (fdev->dreq_mask == ~0L) {
+			dev_err(fdev->dev, "No req lines available\n");
+			return -EINVAL;
+		}
+
+		if (try || req_line_cfg >= ST_FDMA_NR_DREQS) {
+			dev_err(fdev->dev, "Invalid or used req line\n");
+			return -EINVAL;
+		} else {
+			dreq_line = req_line_cfg;
+		}
+
+		try++;
+	} while (test_and_set_bit(dreq_line, &fdev->dreq_mask));
+
+	dev_dbg(fdev->dev, "get dreq_line:%d mask:%#lx\n",
+		dreq_line, fdev->dreq_mask);
+
+	return dreq_line;
+}
+
+static void st_fdma_dreq_put(struct st_fdma_chan *fchan)
+{
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	dev_dbg(fdev->dev, "put dreq_line:%#x\n", fchan->dreq_line);
+	clear_bit(fchan->dreq_line, &fdev->dreq_mask);
+}
+
+static void st_fdma_xfer_desc(struct st_fdma_chan *fchan)
+{
+	struct virt_dma_desc *vdesc;
+	unsigned long nbytes, ch_cmd, cmd;
+
+	vdesc = vchan_next_desc(&fchan->vchan);
+	if (!vdesc)
+		return;
+
+	fchan->fdesc = to_st_fdma_desc(vdesc);
+	nbytes = fchan->fdesc->node[0].desc->nbytes;
+	cmd = FDMA_CMD_START(fchan->vchan.chan.chan_id);
+	ch_cmd = fchan->fdesc->node[0].pdesc | FDMA_CH_CMD_STA_START;
+
+	/* start the channel for the descriptor */
+	fnode_write(fchan, nbytes, FDMA_CNTN_OFST);
+	fchan_write(fchan, ch_cmd, FDMA_CH_CMD_OFST);
+	writel(cmd,
+		fchan->fdev->slim_rproc->peri + FDMA_CMD_SET_OFST);
+
+	dev_dbg(fchan->fdev->dev, "start chan:%d\n", fchan->vchan.chan.chan_id);
+}
+
+static void st_fdma_ch_sta_update(struct st_fdma_chan *fchan,
+				  unsigned long int_sta)
+{
+	unsigned long ch_sta, ch_err;
+	int ch_id = fchan->vchan.chan.chan_id;
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	ch_sta = fchan_read(fchan, FDMA_CH_CMD_OFST);
+	ch_err = ch_sta & FDMA_CH_CMD_ERR_MASK;
+	ch_sta &= FDMA_CH_CMD_STA_MASK;
+
+	if (int_sta & FDMA_INT_STA_ERR) {
+		dev_warn(fdev->dev, "chan:%d, error:%ld\n", ch_id, ch_err);
+		fchan->status = DMA_ERROR;
+		return;
+	}
+
+	switch (ch_sta) {
+	case FDMA_CH_CMD_STA_PAUSED:
+		fchan->status = DMA_PAUSED;
+		break;
+
+	case FDMA_CH_CMD_STA_RUNNING:
+		fchan->status = DMA_IN_PROGRESS;
+		break;
+	}
+}
+
+static irqreturn_t st_fdma_irq_handler(int irq, void *dev_id)
+{
+	struct st_fdma_dev *fdev = dev_id;
+	irqreturn_t ret = IRQ_NONE;
+	struct st_fdma_chan *fchan = &fdev->chans[0];
+	unsigned long int_sta, clr;
+
+	int_sta = fdma_read(fdev, FDMA_INT_STA_OFST);
+	clr = int_sta;
+
+	for (; int_sta != 0 ; int_sta >>= 2, fchan++) {
+		if (!(int_sta & (FDMA_INT_STA_CH | FDMA_INT_STA_ERR)))
+			continue;
+
+		spin_lock(&fchan->vchan.lock);
+		st_fdma_ch_sta_update(fchan, int_sta);
+
+		if (fchan->fdesc) {
+			if (!fchan->fdesc->iscyclic) {
+				list_del(&fchan->fdesc->vdesc.node);
+				vchan_cookie_complete(&fchan->fdesc->vdesc);
+				fchan->fdesc = NULL;
+				fchan->status = DMA_COMPLETE;
+			} else {
+				vchan_cyclic_callback(&fchan->fdesc->vdesc);
+			}
+
+			/* Start the next descriptor (if available) */
+			if (!fchan->fdesc)
+				st_fdma_xfer_desc(fchan);
+		}
+
+		spin_unlock(&fchan->vchan.lock);
+		ret = IRQ_HANDLED;
+	}
+
+	fdma_write(fdev, clr, FDMA_INT_CLR_OFST);
+
+	return ret;
+}
+
+static struct dma_chan *st_fdma_of_xlate(struct of_phandle_args *dma_spec,
+					 struct of_dma *ofdma)
+{
+	struct st_fdma_dev *fdev = ofdma->of_dma_data;
+	struct dma_chan *chan;
+	struct st_fdma_chan *fchan;
+	int ret;
+
+	if (dma_spec->args_count < 1)
+		return ERR_PTR(-EINVAL);
+
+	if (fdev->dma_device.dev->of_node != dma_spec->np)
+		return ERR_PTR(-EINVAL);
+
+	ret = rproc_boot(fdev->slim_rproc->rproc);
+	if (ret == -ENOENT)
+		return ERR_PTR(-EPROBE_DEFER);
+	else if (ret)
+		return ERR_PTR(ret);
+
+	chan = dma_get_any_slave_channel(&fdev->dma_device);
+	if (!chan)
+		goto err_chan;
+
+	fchan = to_st_fdma_chan(chan);
+
+	fchan->cfg.of_node = dma_spec->np;
+	fchan->cfg.req_line = dma_spec->args[0];
+	fchan->cfg.req_ctrl = 0;
+	fchan->cfg.type = ST_FDMA_TYPE_FREE_RUN;
+
+	if (dma_spec->args_count > 1)
+		fchan->cfg.req_ctrl = dma_spec->args[1]
+			& FDMA_REQ_CTRL_CFG_MASK;
+
+	if (dma_spec->args_count > 2)
+		fchan->cfg.type = dma_spec->args[2];
+
+	if (fchan->cfg.type == ST_FDMA_TYPE_FREE_RUN) {
+		fchan->dreq_line = 0;
+	} else {
+		fchan->dreq_line = st_fdma_dreq_get(fchan);
+		if (IS_ERR_VALUE(fchan->dreq_line)) {
+			chan = ERR_PTR(fchan->dreq_line);
+			goto err_chan;
+		}
+	}
+
+	dev_dbg(fdev->dev, "xlate req_line:%d type:%d req_ctrl:%#lx\n",
+		fchan->cfg.req_line, fchan->cfg.type, fchan->cfg.req_ctrl);
+
+	return chan;
+
+err_chan:
+	rproc_shutdown(fdev->slim_rproc->rproc);
+	return chan;
+
+}
+
+static void st_fdma_free_desc(struct virt_dma_desc *vdesc)
+{
+	struct st_fdma_desc *fdesc;
+	int i;
+
+	fdesc = to_st_fdma_desc(vdesc);
+	for (i = 0; i < fdesc->n_nodes; i++)
+		dma_pool_free(fdesc->fchan->node_pool, fdesc->node[i].desc,
+			      fdesc->node[i].pdesc);
+	kfree(fdesc);
+}
+
+static struct st_fdma_desc *st_fdma_alloc_desc(struct st_fdma_chan *fchan,
+					       int sg_len)
+{
+	struct st_fdma_desc *fdesc;
+	int i;
+
+	fdesc = kzalloc(sizeof(*fdesc) +
+			sizeof(struct st_fdma_sw_node) * sg_len, GFP_NOWAIT);
+	if (!fdesc)
+		return NULL;
+
+	fdesc->fchan = fchan;
+	fdesc->n_nodes = sg_len;
+	for (i = 0; i < sg_len; i++) {
+		fdesc->node[i].desc = dma_pool_alloc(fchan->node_pool,
+				GFP_NOWAIT, &fdesc->node[i].pdesc);
+		if (!fdesc->node[i].desc)
+			goto err;
+	}
+	return fdesc;
+
+err:
+	while (--i >= 0)
+		dma_pool_free(fchan->node_pool, fdesc->node[i].desc,
+			      fdesc->node[i].pdesc);
+	kfree(fdesc);
+	return NULL;
+}
+
+static int st_fdma_alloc_chan_res(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+
+	/* Create the dma pool for descriptor allocation */
+	fchan->node_pool = dma_pool_create(dev_name(&chan->dev->device),
+					    fchan->fdev->dev,
+					    sizeof(struct st_fdma_hw_node),
+					    __alignof__(struct st_fdma_hw_node),
+					    0);
+
+	if (!fchan->node_pool) {
+		dev_err(fchan->fdev->dev, "unable to allocate desc pool\n");
+		return -ENOMEM;
+	}
+
+	dev_dbg(fchan->fdev->dev, "alloc ch_id:%d type:%d\n",
+		fchan->vchan.chan.chan_id, fchan->cfg.type);
+
+	return 0;
+}
+
+static void st_fdma_free_chan_res(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	struct rproc *rproc = fchan->fdev->slim_rproc->rproc;
+	unsigned long flags;
+
+	LIST_HEAD(head);
+
+	dev_dbg(fchan->fdev->dev, "%s: freeing chan:%d\n",
+		__func__, fchan->vchan.chan.chan_id);
+
+	if (fchan->cfg.type != ST_FDMA_TYPE_FREE_RUN)
+		st_fdma_dreq_put(fchan);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	fchan->fdesc = NULL;
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	dma_pool_destroy(fchan->node_pool);
+	fchan->node_pool = NULL;
+	memset(&fchan->cfg, 0, sizeof(struct st_fdma_cfg));
+
+	rproc_shutdown(rproc);
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_dma_memcpy(
+	struct dma_chan *chan,	dma_addr_t dst, dma_addr_t src,
+	size_t len, unsigned long flags)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	struct st_fdma_hw_node *hw_node;
+
+	if (!len)
+		return NULL;
+
+	fchan = to_st_fdma_chan(chan);
+
+	/* We only require a single descriptor */
+	fdesc = st_fdma_alloc_desc(fchan, 1);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	hw_node = fdesc->node[0].desc;
+	hw_node->next = 0;
+	hw_node->control = FDMA_NODE_CTRL_REQ_MAP_FREE_RUN;
+	hw_node->control |= FDMA_NODE_CTRL_SRC_INCR;
+	hw_node->control |= FDMA_NODE_CTRL_DST_INCR;
+	hw_node->control |= FDMA_NODE_CTRL_INT_EON;
+	hw_node->nbytes = len;
+	hw_node->saddr = src;
+	hw_node->daddr = dst;
+	hw_node->generic.length = len;
+	hw_node->generic.sstride = 0;
+	hw_node->generic.dstride = 0;
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static int config_reqctrl(struct st_fdma_chan *fchan,
+			  enum dma_transfer_direction direction)
+{
+	u32 maxburst = 0, addr = 0;
+	enum dma_slave_buswidth width;
+	int ch_id = fchan->vchan.chan.chan_id;
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	switch (direction) {
+
+	case DMA_DEV_TO_MEM:
+		fchan->cfg.req_ctrl &= ~FDMA_REQ_CTRL_WNR;
+		maxburst = fchan->scfg.src_maxburst;
+		width = fchan->scfg.src_addr_width;
+		addr = fchan->scfg.src_addr;
+		break;
+
+	case DMA_MEM_TO_DEV:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_WNR;
+		maxburst = fchan->scfg.dst_maxburst;
+		width = fchan->scfg.dst_addr_width;
+		addr = fchan->scfg.dst_addr;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	fchan->cfg.req_ctrl &= ~FDMA_REQ_CTRL_OPCODE_MASK;
+
+	switch (width) {
+
+	case DMA_SLAVE_BUSWIDTH_1_BYTE:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST1;
+		break;
+
+	case DMA_SLAVE_BUSWIDTH_2_BYTES:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST2;
+		break;
+
+	case DMA_SLAVE_BUSWIDTH_4_BYTES:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST4;
+		break;
+
+	case DMA_SLAVE_BUSWIDTH_8_BYTES:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST8;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	fchan->cfg.req_ctrl &= ~FDMA_REQ_CTRL_NUM_OPS_MASK;
+	fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_NUM_OPS(maxburst-1);
+	dreq_write(fchan, fchan->cfg.req_ctrl, FDMA_REQ_CTRL_OFST);
+
+	fchan->cfg.dev_addr = addr;
+	fchan->cfg.dir = direction;
+
+	dev_dbg(fdev->dev, "chan:%d config_reqctrl:%#x req_ctrl:%#lx\n",
+		ch_id, addr, fchan->cfg.req_ctrl);
+
+	return 0;
+}
+
+static void fill_hw_node(struct st_fdma_hw_node *hw_node,
+			struct st_fdma_chan *fchan,
+			enum dma_transfer_direction direction)
+{
+	if (direction == DMA_MEM_TO_DEV) {
+		hw_node->control |= FDMA_NODE_CTRL_SRC_INCR;
+		hw_node->control |= FDMA_NODE_CTRL_DST_STATIC;
+		hw_node->daddr = fchan->cfg.dev_addr;
+	} else {
+		hw_node->control |= FDMA_NODE_CTRL_SRC_STATIC;
+		hw_node->control |= FDMA_NODE_CTRL_DST_INCR;
+		hw_node->saddr = fchan->cfg.dev_addr;
+	}
+
+	hw_node->generic.sstride = 0;
+	hw_node->generic.dstride = 0;
+}
+
+static inline struct st_fdma_chan *st_fdma_prep_common(struct dma_chan *chan,
+		size_t len, enum dma_transfer_direction direction)
+{
+	struct st_fdma_chan *fchan;
+
+	if (!chan || !len)
+		return NULL;
+
+	fchan = to_st_fdma_chan(chan);
+
+	if (!is_slave_direction(direction)) {
+		dev_err(fchan->fdev->dev, "bad direction?\n");
+		return NULL;
+	}
+
+	return fchan;
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_dma_cyclic(
+		struct dma_chan *chan, dma_addr_t buf_addr, size_t len,
+		size_t period_len, enum dma_transfer_direction direction,
+		unsigned long flags)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	int sg_len, i;
+
+	fchan = st_fdma_prep_common(chan, len, direction);
+	if (!fchan)
+		return NULL;
+
+	if (!period_len)
+		return NULL;
+
+	if (config_reqctrl(fchan, direction)) {
+		dev_err(fchan->fdev->dev, "bad width or direction\n");
+		return NULL;
+	}
+
+	/* the buffer length must be a multiple of period_len */
+	if (len % period_len != 0) {
+		dev_err(fchan->fdev->dev, "len is not multiple of period\n");
+		return NULL;
+	}
+
+	sg_len = len / period_len;
+	fdesc = st_fdma_alloc_desc(fchan, sg_len);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	fdesc->iscyclic = true;
+
+	for (i = 0; i < sg_len; i++) {
+		struct st_fdma_hw_node *hw_node = fdesc->node[i].desc;
+
+		hw_node->next = fdesc->node[(i + 1) % sg_len].pdesc;
+
+		hw_node->control =
+			FDMA_NODE_CTRL_REQ_MAP_DREQ(fchan->dreq_line);
+		hw_node->control |= FDMA_NODE_CTRL_INT_EON;
+
+		fill_hw_node(hw_node, fchan, direction);
+
+		if (direction == DMA_MEM_TO_DEV)
+			hw_node->saddr = buf_addr + (i * period_len);
+		else
+			hw_node->daddr = buf_addr + (i * period_len);
+
+		hw_node->nbytes = period_len;
+		hw_node->generic.length = period_len;
+	}
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_slave_sg(
+		struct dma_chan *chan, struct scatterlist *sgl,
+		unsigned int sg_len, enum dma_transfer_direction direction,
+		unsigned long flags, void *context)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	struct st_fdma_hw_node *hw_node;
+	struct scatterlist *sg;
+	int i;
+
+	fchan = st_fdma_prep_common(chan, sg_len, direction);
+	if (!fchan)
+		return NULL;
+
+	if (!sgl)
+		return NULL;
+
+	fdesc = st_fdma_alloc_desc(fchan, sg_len);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	fdesc->iscyclic = false;
+
+	for_each_sg(sgl, sg, sg_len, i) {
+		hw_node = fdesc->node[i].desc;
+
+		hw_node->next = fdesc->node[(i + 1) % sg_len].pdesc;
+		hw_node->control = FDMA_NODE_CTRL_REQ_MAP_DREQ(fchan->dreq_line);
+
+		fill_hw_node(hw_node, fchan, direction);
+
+		if (direction == DMA_MEM_TO_DEV)
+			hw_node->saddr = sg_dma_address(sg);
+		else
+			hw_node->daddr = sg_dma_address(sg);
+
+		hw_node->nbytes = sg_dma_len(sg);
+		hw_node->generic.length = sg_dma_len(sg);
+	}
+
+	/* interrupt at end of last node */
+	hw_node->control |= FDMA_NODE_CTRL_INT_EON;
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static size_t st_fdma_desc_residue(struct st_fdma_chan *fchan,
+				   struct virt_dma_desc *vdesc,
+				   bool in_progress)
+{
+	struct st_fdma_desc *fdesc = fchan->fdesc;
+	size_t residue = 0;
+	dma_addr_t cur_addr = 0;
+	int i;
+
+	if (in_progress) {
+		cur_addr = fchan_read(fchan, FDMA_CH_CMD_OFST);
+		cur_addr &= FDMA_CH_CMD_DATA_MASK;
+	}
+
+	for (i = fchan->fdesc->n_nodes - 1 ; i >= 0; i--) {
+		if (cur_addr == fdesc->node[i].pdesc) {
+			residue += fnode_read(fchan, FDMA_CNTN_OFST);
+			break;
+		}
+		residue += fdesc->node[i].desc->nbytes;
+	}
+
+	return residue;
+}
+
+static enum dma_status st_fdma_tx_status(struct dma_chan *chan,
+					 dma_cookie_t cookie,
+					 struct dma_tx_state *txstate)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	struct virt_dma_desc *vd;
+	enum dma_status ret;
+	unsigned long flags;
+
+	ret = dma_cookie_status(chan, cookie, txstate);
+	if (ret == DMA_COMPLETE || !txstate)
+		return ret;
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	vd = vchan_find_desc(&fchan->vchan, cookie);
+	if (fchan->fdesc && cookie == fchan->fdesc->vdesc.tx.cookie)
+		txstate->residue = st_fdma_desc_residue(fchan, vd, true);
+	else if (vd)
+		txstate->residue = st_fdma_desc_residue(fchan, vd, false);
+	else
+		txstate->residue = 0;
+
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return ret;
+}
+
+static void st_fdma_issue_pending(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	unsigned long flags;
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+
+	if (vchan_issue_pending(&fchan->vchan) && !fchan->fdesc)
+		st_fdma_xfer_desc(fchan);
+
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+}
+
+static int st_fdma_pause(struct dma_chan *chan)
+{
+	unsigned long flags;
+	LIST_HEAD(head);
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+	unsigned long cmd = FDMA_CMD_PAUSE(ch_id);
+
+	dev_dbg(fchan->fdev->dev, "pause chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	if (fchan->fdesc)
+		fdma_write(fchan->fdev, cmd, FDMA_CMD_SET_OFST);
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return 0;
+}
+
+static int st_fdma_resume(struct dma_chan *chan)
+{
+	unsigned long flags;
+	unsigned long val;
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+
+	dev_dbg(fchan->fdev->dev, "resume chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	if (fchan->fdesc) {
+		val = fchan_read(fchan, FDMA_CH_CMD_OFST);
+		val &= FDMA_CH_CMD_DATA_MASK;
+		fchan_write(fchan, val, FDMA_CH_CMD_OFST);
+	}
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return 0;
+}
+
+static int st_fdma_terminate_all(struct dma_chan *chan)
+{
+	unsigned long flags;
+	LIST_HEAD(head);
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+	unsigned long cmd = FDMA_CMD_PAUSE(ch_id);
+
+	dev_dbg(fchan->fdev->dev, "terminate chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	fdma_write(fchan->fdev, cmd, FDMA_CMD_SET_OFST);
+	fchan->fdesc = NULL;
+	vchan_get_all_descriptors(&fchan->vchan, &head);
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+	vchan_dma_desc_free_list(&fchan->vchan, &head);
+
+	return 0;
+}
+
+static int st_fdma_slave_config(struct dma_chan *chan,
+				struct dma_slave_config *slave_cfg)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+
+	memcpy(&fchan->scfg, slave_cfg, sizeof(fchan->scfg));
+	return 0;
+}
+
+static const struct st_fdma_driverdata fdma_mpe31_stih407_11 = {
+	.name = "STiH407",
+	.id = 0,
+};
+
+static const struct st_fdma_driverdata fdma_mpe31_stih407_12 = {
+	.name = "STiH407",
+	.id = 1,
+};
+
+static const struct st_fdma_driverdata fdma_mpe31_stih407_13 = {
+	.name = "STiH407",
+	.id = 2,
+};
+
+static const struct of_device_id st_fdma_match[] = {
+	{ .compatible = "st,stih407-fdma-mpe31-11"
+	  , .data = &fdma_mpe31_stih407_11 },
+	{ .compatible = "st,stih407-fdma-mpe31-12"
+	  , .data = &fdma_mpe31_stih407_12 },
+	{ .compatible = "st,stih407-fdma-mpe31-13"
+	  , .data = &fdma_mpe31_stih407_13 },
+	{},
+};
+MODULE_DEVICE_TABLE(of, st_fdma_match);
+
+static int st_fdma_parse_dt(struct platform_device *pdev,
+			const struct st_fdma_driverdata *drvdata,
+			struct st_fdma_dev *fdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int ret;
+
+	if (!np)
+		goto err;
+
+	ret = of_property_read_u32(np, "dma-channels", &fdev->nr_channels);
+	if (ret)
+		goto err;
+
+	snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
+		drvdata->name, drvdata->id);
+
+err:
+	return ret;
+}
+#define FDMA_DMA_BUSWIDTHS	(BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static void st_fdma_free(struct st_fdma_dev *fdev)
+{
+	struct st_fdma_chan *fchan;
+	int i;
+
+	for (i = 0; i < fdev->nr_channels; i++) {
+		fchan = &fdev->chans[i];
+		list_del(&fchan->vchan.chan.device_node);
+		tasklet_kill(&fchan->vchan.task);
+	}
+}
+
+static int st_fdma_probe(struct platform_device *pdev)
+{
+	struct st_fdma_dev *fdev;
+	const struct of_device_id *match;
+	struct device_node *np = pdev->dev.of_node;
+	const struct st_fdma_driverdata *drvdata;
+	int ret, i;
+
+	match = of_match_device((st_fdma_match), &pdev->dev);
+	if (!match || !match->data) {
+		dev_err(&pdev->dev, "No device match found\n");
+		return -ENODEV;
+	}
+
+	drvdata = match->data;
+
+	fdev = devm_kzalloc(&pdev->dev, sizeof(*fdev), GFP_KERNEL);
+	if (!fdev)
+		return -ENOMEM;
+
+	ret = st_fdma_parse_dt(pdev, drvdata, fdev);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to find platform data\n");
+		goto err;
+	}
+
+	fdev->chans = devm_kcalloc(&pdev->dev, fdev->nr_channels,
+				   sizeof(struct st_fdma_chan), GFP_KERNEL);
+	if (!fdev->chans)
+		return -ENOMEM;
+
+	fdev->dev = &pdev->dev;
+	fdev->drvdata = drvdata;
+	platform_set_drvdata(pdev, fdev);
+
+	fdev->irq = platform_get_irq(pdev, 0);
+	if (fdev->irq < 0) {
+		dev_err(&pdev->dev, "Failed to get irq resource\n");
+		return -EINVAL;
+	}
+
+	ret = devm_request_irq(&pdev->dev, fdev->irq, st_fdma_irq_handler, 0,
+			       dev_name(&pdev->dev), fdev);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to request irq (%d)\n", ret);
+		goto err;
+	}
+
+	fdev->slim_rproc = st_slim_rproc_alloc(pdev, fdev->fw_name);
+	if (!fdev->slim_rproc) {
+		ret = PTR_ERR(fdev->slim_rproc);
+		dev_err(&pdev->dev, "slim_rproc_alloc failed (%d)\n", ret);
+		goto err;
+	}
+
+	/* Initialise list of FDMA channels */
+	INIT_LIST_HEAD(&fdev->dma_device.channels);
+	for (i = 0; i < fdev->nr_channels; i++) {
+		struct st_fdma_chan *fchan = &fdev->chans[i];
+
+		fchan->fdev = fdev;
+		fchan->vchan.desc_free = st_fdma_free_desc;
+		vchan_init(&fchan->vchan, &fdev->dma_device);
+	}
+
+	/* Initialise the FDMA dreq (reserve 0 & 31 for FDMA use) */
+	fdev->dreq_mask = BIT(0) | BIT(31);
+
+	dma_cap_set(DMA_SLAVE, fdev->dma_device.cap_mask);
+	dma_cap_set(DMA_CYCLIC, fdev->dma_device.cap_mask);
+	dma_cap_set(DMA_MEMCPY, fdev->dma_device.cap_mask);
+
+	fdev->dma_device.dev = &pdev->dev;
+	fdev->dma_device.device_alloc_chan_resources = st_fdma_alloc_chan_res;
+	fdev->dma_device.device_free_chan_resources = st_fdma_free_chan_res;
+	fdev->dma_device.device_prep_dma_cyclic	= st_fdma_prep_dma_cyclic;
+	fdev->dma_device.device_prep_slave_sg = st_fdma_prep_slave_sg;
+	fdev->dma_device.device_prep_dma_memcpy = st_fdma_prep_dma_memcpy;
+	fdev->dma_device.device_tx_status = st_fdma_tx_status;
+	fdev->dma_device.device_issue_pending = st_fdma_issue_pending;
+	fdev->dma_device.device_terminate_all = st_fdma_terminate_all;
+	fdev->dma_device.device_config = st_fdma_slave_config;
+	fdev->dma_device.device_pause = st_fdma_pause;
+	fdev->dma_device.device_resume = st_fdma_resume;
+
+	fdev->dma_device.src_addr_widths = FDMA_DMA_BUSWIDTHS;
+	fdev->dma_device.dst_addr_widths = FDMA_DMA_BUSWIDTHS;
+	fdev->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+	fdev->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+
+	ret = dma_async_device_register(&fdev->dma_device);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"Failed to register DMA device (%d)\n", ret);
+		goto err_rproc;
+	}
+
+	ret = of_dma_controller_register(np, st_fdma_of_xlate, fdev);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"Failed to register controller (%d)\n", ret);
+		goto err_dma_dev;
+	}
+
+	dev_info(&pdev->dev, "ST FDMA engine driver, irq:%d\n", fdev->irq);
+
+	return 0;
+
+err_dma_dev:
+	dma_async_device_unregister(&fdev->dma_device);
+err_rproc:
+	st_fdma_free(fdev);
+	st_slim_rproc_put(fdev->slim_rproc);
+err:
+	return ret;
+}
+
+static int st_fdma_remove(struct platform_device *pdev)
+{
+	struct st_fdma_dev *fdev = platform_get_drvdata(pdev);
+
+	devm_free_irq(&pdev->dev, fdev->irq, fdev);
+	st_slim_rproc_put(fdev->slim_rproc);
+	of_dma_controller_free(pdev->dev.of_node);
+	dma_async_device_unregister(&fdev->dma_device);
+
+	return 0;
+}
+
+static struct platform_driver st_fdma_platform_driver = {
+	.driver = {
+		.name = DRIVER_NAME,
+		.of_match_table = st_fdma_match,
+	},
+	.probe = st_fdma_probe,
+	.remove = st_fdma_remove,
+};
+module_platform_driver(st_fdma_platform_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("STMicroelectronics FDMA engine driver");
+MODULE_AUTHOR("Ludovic.barre <Ludovic.barre@st.com>");
+MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
+MODULE_ALIAS("platform: " DRIVER_NAME);
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 05/19] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds support for the Flexible Direct Memory Access (FDMA) core
driver. The FDMA is a slim core CPU with a dedicated firmware.
It is a general purpose DMA controller capable of supporting 16
independent DMA channels. Data moves maybe from memory to memory
or between memory and paced latency critical real time targets and it
is found on al STi based chipsets.

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/dma/Kconfig   |  15 +-
 drivers/dma/Makefile  |   1 +
 drivers/dma/st_fdma.c | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 914 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma/st_fdma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 739f797..7c5d946 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -437,6 +437,19 @@ config STE_DMA40
 	help
 	  Support for ST-Ericsson DMA40 controller
 
+config ST_FDMA
+	tristate "ST FDMA dmaengine support"
+	depends on ARCH_STI
+	select ST_SLIM_REMOTEPROC
+	select DMA_ENGINE
+	select DMA_VIRTUAL_CHANNELS
+	help
+	  Enable support for ST FDMA controller.
+	  It supports 16 independent DMA channels, accepts up to 32 DMA requests
+
+	  Say Y here if you have such a chipset.
+	  If unsure, say N.
+
 config STM32_DMA
 	bool "STMicroelectronics STM32 DMA support"
 	depends on ARCH_STM32
@@ -449,6 +462,7 @@ config STM32_DMA
 	  If you have a board based on such a MCU and wish to use DMA say Y or M
 	  here.
 
+
 config S3C24XX_DMAC
 	bool "Samsung S3C24XX DMA support"
 	depends on ARCH_S3C24XX
@@ -567,7 +581,6 @@ config ZX_DMA
 	help
 	  Support the DMA engine for ZTE ZX296702 platform devices.
 
-
 # driver files
 source "drivers/dma/bestcomm/Kconfig"
 
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index e4dc9ca..a4fa336 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
 obj-$(CONFIG_TI_EDMA) += edma.o
 obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-$(CONFIG_ST_FDMA) += st_fdma.o
 
 obj-y += qcom/
 obj-y += xilinx/
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
new file mode 100644
index 0000000..515e1d4
--- /dev/null
+++ b/drivers/dma/st_fdma.c
@@ -0,0 +1,899 @@
+/*
+ * DMA driver for STMicroelectronics STi FDMA controller
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * Author: Ludovic Barre <Ludovic.barre@st.com>
+ *	   Peter Griffin <peter.griffin@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_dma.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/remoteproc.h>
+
+#include "st_fdma.h"
+
+static inline struct st_fdma_chan *to_st_fdma_chan(struct dma_chan *c)
+{
+	return container_of(c, struct st_fdma_chan, vchan.chan);
+}
+
+static struct st_fdma_desc *to_st_fdma_desc(struct virt_dma_desc *vd)
+{
+	return container_of(vd, struct st_fdma_desc, vdesc);
+}
+
+static int st_fdma_dreq_get(struct st_fdma_chan *fchan)
+{
+	struct st_fdma_dev *fdev = fchan->fdev;
+	u32 req_line_cfg = fchan->cfg.req_line;
+	u32 dreq_line;
+	int try = 0;
+
+	/*
+	 * dreq_mask is shared for n channels of fdma, so all accesses must be
+	 * atomic. if the dreq_mask is changed between ffz and set_bit,
+	 * we retry
+	 */
+	do {
+		if (fdev->dreq_mask == ~0L) {
+			dev_err(fdev->dev, "No req lines available\n");
+			return -EINVAL;
+		}
+
+		if (try || req_line_cfg >= ST_FDMA_NR_DREQS) {
+			dev_err(fdev->dev, "Invalid or used req line\n");
+			return -EINVAL;
+		} else {
+			dreq_line = req_line_cfg;
+		}
+
+		try++;
+	} while (test_and_set_bit(dreq_line, &fdev->dreq_mask));
+
+	dev_dbg(fdev->dev, "get dreq_line:%d mask:%#lx\n",
+		dreq_line, fdev->dreq_mask);
+
+	return dreq_line;
+}
+
+static void st_fdma_dreq_put(struct st_fdma_chan *fchan)
+{
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	dev_dbg(fdev->dev, "put dreq_line:%#x\n", fchan->dreq_line);
+	clear_bit(fchan->dreq_line, &fdev->dreq_mask);
+}
+
+static void st_fdma_xfer_desc(struct st_fdma_chan *fchan)
+{
+	struct virt_dma_desc *vdesc;
+	unsigned long nbytes, ch_cmd, cmd;
+
+	vdesc = vchan_next_desc(&fchan->vchan);
+	if (!vdesc)
+		return;
+
+	fchan->fdesc = to_st_fdma_desc(vdesc);
+	nbytes = fchan->fdesc->node[0].desc->nbytes;
+	cmd = FDMA_CMD_START(fchan->vchan.chan.chan_id);
+	ch_cmd = fchan->fdesc->node[0].pdesc | FDMA_CH_CMD_STA_START;
+
+	/* start the channel for the descriptor */
+	fnode_write(fchan, nbytes, FDMA_CNTN_OFST);
+	fchan_write(fchan, ch_cmd, FDMA_CH_CMD_OFST);
+	writel(cmd,
+		fchan->fdev->slim_rproc->peri + FDMA_CMD_SET_OFST);
+
+	dev_dbg(fchan->fdev->dev, "start chan:%d\n", fchan->vchan.chan.chan_id);
+}
+
+static void st_fdma_ch_sta_update(struct st_fdma_chan *fchan,
+				  unsigned long int_sta)
+{
+	unsigned long ch_sta, ch_err;
+	int ch_id = fchan->vchan.chan.chan_id;
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	ch_sta = fchan_read(fchan, FDMA_CH_CMD_OFST);
+	ch_err = ch_sta & FDMA_CH_CMD_ERR_MASK;
+	ch_sta &= FDMA_CH_CMD_STA_MASK;
+
+	if (int_sta & FDMA_INT_STA_ERR) {
+		dev_warn(fdev->dev, "chan:%d, error:%ld\n", ch_id, ch_err);
+		fchan->status = DMA_ERROR;
+		return;
+	}
+
+	switch (ch_sta) {
+	case FDMA_CH_CMD_STA_PAUSED:
+		fchan->status = DMA_PAUSED;
+		break;
+
+	case FDMA_CH_CMD_STA_RUNNING:
+		fchan->status = DMA_IN_PROGRESS;
+		break;
+	}
+}
+
+static irqreturn_t st_fdma_irq_handler(int irq, void *dev_id)
+{
+	struct st_fdma_dev *fdev = dev_id;
+	irqreturn_t ret = IRQ_NONE;
+	struct st_fdma_chan *fchan = &fdev->chans[0];
+	unsigned long int_sta, clr;
+
+	int_sta = fdma_read(fdev, FDMA_INT_STA_OFST);
+	clr = int_sta;
+
+	for (; int_sta != 0 ; int_sta >>= 2, fchan++) {
+		if (!(int_sta & (FDMA_INT_STA_CH | FDMA_INT_STA_ERR)))
+			continue;
+
+		spin_lock(&fchan->vchan.lock);
+		st_fdma_ch_sta_update(fchan, int_sta);
+
+		if (fchan->fdesc) {
+			if (!fchan->fdesc->iscyclic) {
+				list_del(&fchan->fdesc->vdesc.node);
+				vchan_cookie_complete(&fchan->fdesc->vdesc);
+				fchan->fdesc = NULL;
+				fchan->status = DMA_COMPLETE;
+			} else {
+				vchan_cyclic_callback(&fchan->fdesc->vdesc);
+			}
+
+			/* Start the next descriptor (if available) */
+			if (!fchan->fdesc)
+				st_fdma_xfer_desc(fchan);
+		}
+
+		spin_unlock(&fchan->vchan.lock);
+		ret = IRQ_HANDLED;
+	}
+
+	fdma_write(fdev, clr, FDMA_INT_CLR_OFST);
+
+	return ret;
+}
+
+static struct dma_chan *st_fdma_of_xlate(struct of_phandle_args *dma_spec,
+					 struct of_dma *ofdma)
+{
+	struct st_fdma_dev *fdev = ofdma->of_dma_data;
+	struct dma_chan *chan;
+	struct st_fdma_chan *fchan;
+	int ret;
+
+	if (dma_spec->args_count < 1)
+		return ERR_PTR(-EINVAL);
+
+	if (fdev->dma_device.dev->of_node != dma_spec->np)
+		return ERR_PTR(-EINVAL);
+
+	ret = rproc_boot(fdev->slim_rproc->rproc);
+	if (ret == -ENOENT)
+		return ERR_PTR(-EPROBE_DEFER);
+	else if (ret)
+		return ERR_PTR(ret);
+
+	chan = dma_get_any_slave_channel(&fdev->dma_device);
+	if (!chan)
+		goto err_chan;
+
+	fchan = to_st_fdma_chan(chan);
+
+	fchan->cfg.of_node = dma_spec->np;
+	fchan->cfg.req_line = dma_spec->args[0];
+	fchan->cfg.req_ctrl = 0;
+	fchan->cfg.type = ST_FDMA_TYPE_FREE_RUN;
+
+	if (dma_spec->args_count > 1)
+		fchan->cfg.req_ctrl = dma_spec->args[1]
+			& FDMA_REQ_CTRL_CFG_MASK;
+
+	if (dma_spec->args_count > 2)
+		fchan->cfg.type = dma_spec->args[2];
+
+	if (fchan->cfg.type == ST_FDMA_TYPE_FREE_RUN) {
+		fchan->dreq_line = 0;
+	} else {
+		fchan->dreq_line = st_fdma_dreq_get(fchan);
+		if (IS_ERR_VALUE(fchan->dreq_line)) {
+			chan = ERR_PTR(fchan->dreq_line);
+			goto err_chan;
+		}
+	}
+
+	dev_dbg(fdev->dev, "xlate req_line:%d type:%d req_ctrl:%#lx\n",
+		fchan->cfg.req_line, fchan->cfg.type, fchan->cfg.req_ctrl);
+
+	return chan;
+
+err_chan:
+	rproc_shutdown(fdev->slim_rproc->rproc);
+	return chan;
+
+}
+
+static void st_fdma_free_desc(struct virt_dma_desc *vdesc)
+{
+	struct st_fdma_desc *fdesc;
+	int i;
+
+	fdesc = to_st_fdma_desc(vdesc);
+	for (i = 0; i < fdesc->n_nodes; i++)
+		dma_pool_free(fdesc->fchan->node_pool, fdesc->node[i].desc,
+			      fdesc->node[i].pdesc);
+	kfree(fdesc);
+}
+
+static struct st_fdma_desc *st_fdma_alloc_desc(struct st_fdma_chan *fchan,
+					       int sg_len)
+{
+	struct st_fdma_desc *fdesc;
+	int i;
+
+	fdesc = kzalloc(sizeof(*fdesc) +
+			sizeof(struct st_fdma_sw_node) * sg_len, GFP_NOWAIT);
+	if (!fdesc)
+		return NULL;
+
+	fdesc->fchan = fchan;
+	fdesc->n_nodes = sg_len;
+	for (i = 0; i < sg_len; i++) {
+		fdesc->node[i].desc = dma_pool_alloc(fchan->node_pool,
+				GFP_NOWAIT, &fdesc->node[i].pdesc);
+		if (!fdesc->node[i].desc)
+			goto err;
+	}
+	return fdesc;
+
+err:
+	while (--i >= 0)
+		dma_pool_free(fchan->node_pool, fdesc->node[i].desc,
+			      fdesc->node[i].pdesc);
+	kfree(fdesc);
+	return NULL;
+}
+
+static int st_fdma_alloc_chan_res(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+
+	/* Create the dma pool for descriptor allocation */
+	fchan->node_pool = dma_pool_create(dev_name(&chan->dev->device),
+					    fchan->fdev->dev,
+					    sizeof(struct st_fdma_hw_node),
+					    __alignof__(struct st_fdma_hw_node),
+					    0);
+
+	if (!fchan->node_pool) {
+		dev_err(fchan->fdev->dev, "unable to allocate desc pool\n");
+		return -ENOMEM;
+	}
+
+	dev_dbg(fchan->fdev->dev, "alloc ch_id:%d type:%d\n",
+		fchan->vchan.chan.chan_id, fchan->cfg.type);
+
+	return 0;
+}
+
+static void st_fdma_free_chan_res(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	struct rproc *rproc = fchan->fdev->slim_rproc->rproc;
+	unsigned long flags;
+
+	LIST_HEAD(head);
+
+	dev_dbg(fchan->fdev->dev, "%s: freeing chan:%d\n",
+		__func__, fchan->vchan.chan.chan_id);
+
+	if (fchan->cfg.type != ST_FDMA_TYPE_FREE_RUN)
+		st_fdma_dreq_put(fchan);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	fchan->fdesc = NULL;
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	dma_pool_destroy(fchan->node_pool);
+	fchan->node_pool = NULL;
+	memset(&fchan->cfg, 0, sizeof(struct st_fdma_cfg));
+
+	rproc_shutdown(rproc);
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_dma_memcpy(
+	struct dma_chan *chan,	dma_addr_t dst, dma_addr_t src,
+	size_t len, unsigned long flags)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	struct st_fdma_hw_node *hw_node;
+
+	if (!len)
+		return NULL;
+
+	fchan = to_st_fdma_chan(chan);
+
+	/* We only require a single descriptor */
+	fdesc = st_fdma_alloc_desc(fchan, 1);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	hw_node = fdesc->node[0].desc;
+	hw_node->next = 0;
+	hw_node->control = FDMA_NODE_CTRL_REQ_MAP_FREE_RUN;
+	hw_node->control |= FDMA_NODE_CTRL_SRC_INCR;
+	hw_node->control |= FDMA_NODE_CTRL_DST_INCR;
+	hw_node->control |= FDMA_NODE_CTRL_INT_EON;
+	hw_node->nbytes = len;
+	hw_node->saddr = src;
+	hw_node->daddr = dst;
+	hw_node->generic.length = len;
+	hw_node->generic.sstride = 0;
+	hw_node->generic.dstride = 0;
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static int config_reqctrl(struct st_fdma_chan *fchan,
+			  enum dma_transfer_direction direction)
+{
+	u32 maxburst = 0, addr = 0;
+	enum dma_slave_buswidth width;
+	int ch_id = fchan->vchan.chan.chan_id;
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	switch (direction) {
+
+	case DMA_DEV_TO_MEM:
+		fchan->cfg.req_ctrl &= ~FDMA_REQ_CTRL_WNR;
+		maxburst = fchan->scfg.src_maxburst;
+		width = fchan->scfg.src_addr_width;
+		addr = fchan->scfg.src_addr;
+		break;
+
+	case DMA_MEM_TO_DEV:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_WNR;
+		maxburst = fchan->scfg.dst_maxburst;
+		width = fchan->scfg.dst_addr_width;
+		addr = fchan->scfg.dst_addr;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	fchan->cfg.req_ctrl &= ~FDMA_REQ_CTRL_OPCODE_MASK;
+
+	switch (width) {
+
+	case DMA_SLAVE_BUSWIDTH_1_BYTE:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST1;
+		break;
+
+	case DMA_SLAVE_BUSWIDTH_2_BYTES:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST2;
+		break;
+
+	case DMA_SLAVE_BUSWIDTH_4_BYTES:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST4;
+		break;
+
+	case DMA_SLAVE_BUSWIDTH_8_BYTES:
+		fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_OPCODE_LD_ST8;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	fchan->cfg.req_ctrl &= ~FDMA_REQ_CTRL_NUM_OPS_MASK;
+	fchan->cfg.req_ctrl |= FDMA_REQ_CTRL_NUM_OPS(maxburst-1);
+	dreq_write(fchan, fchan->cfg.req_ctrl, FDMA_REQ_CTRL_OFST);
+
+	fchan->cfg.dev_addr = addr;
+	fchan->cfg.dir = direction;
+
+	dev_dbg(fdev->dev, "chan:%d config_reqctrl:%#x req_ctrl:%#lx\n",
+		ch_id, addr, fchan->cfg.req_ctrl);
+
+	return 0;
+}
+
+static void fill_hw_node(struct st_fdma_hw_node *hw_node,
+			struct st_fdma_chan *fchan,
+			enum dma_transfer_direction direction)
+{
+	if (direction == DMA_MEM_TO_DEV) {
+		hw_node->control |= FDMA_NODE_CTRL_SRC_INCR;
+		hw_node->control |= FDMA_NODE_CTRL_DST_STATIC;
+		hw_node->daddr = fchan->cfg.dev_addr;
+	} else {
+		hw_node->control |= FDMA_NODE_CTRL_SRC_STATIC;
+		hw_node->control |= FDMA_NODE_CTRL_DST_INCR;
+		hw_node->saddr = fchan->cfg.dev_addr;
+	}
+
+	hw_node->generic.sstride = 0;
+	hw_node->generic.dstride = 0;
+}
+
+static inline struct st_fdma_chan *st_fdma_prep_common(struct dma_chan *chan,
+		size_t len, enum dma_transfer_direction direction)
+{
+	struct st_fdma_chan *fchan;
+
+	if (!chan || !len)
+		return NULL;
+
+	fchan = to_st_fdma_chan(chan);
+
+	if (!is_slave_direction(direction)) {
+		dev_err(fchan->fdev->dev, "bad direction?\n");
+		return NULL;
+	}
+
+	return fchan;
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_dma_cyclic(
+		struct dma_chan *chan, dma_addr_t buf_addr, size_t len,
+		size_t period_len, enum dma_transfer_direction direction,
+		unsigned long flags)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	int sg_len, i;
+
+	fchan = st_fdma_prep_common(chan, len, direction);
+	if (!fchan)
+		return NULL;
+
+	if (!period_len)
+		return NULL;
+
+	if (config_reqctrl(fchan, direction)) {
+		dev_err(fchan->fdev->dev, "bad width or direction\n");
+		return NULL;
+	}
+
+	/* the buffer length must be a multiple of period_len */
+	if (len % period_len != 0) {
+		dev_err(fchan->fdev->dev, "len is not multiple of period\n");
+		return NULL;
+	}
+
+	sg_len = len / period_len;
+	fdesc = st_fdma_alloc_desc(fchan, sg_len);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	fdesc->iscyclic = true;
+
+	for (i = 0; i < sg_len; i++) {
+		struct st_fdma_hw_node *hw_node = fdesc->node[i].desc;
+
+		hw_node->next = fdesc->node[(i + 1) % sg_len].pdesc;
+
+		hw_node->control =
+			FDMA_NODE_CTRL_REQ_MAP_DREQ(fchan->dreq_line);
+		hw_node->control |= FDMA_NODE_CTRL_INT_EON;
+
+		fill_hw_node(hw_node, fchan, direction);
+
+		if (direction == DMA_MEM_TO_DEV)
+			hw_node->saddr = buf_addr + (i * period_len);
+		else
+			hw_node->daddr = buf_addr + (i * period_len);
+
+		hw_node->nbytes = period_len;
+		hw_node->generic.length = period_len;
+	}
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_slave_sg(
+		struct dma_chan *chan, struct scatterlist *sgl,
+		unsigned int sg_len, enum dma_transfer_direction direction,
+		unsigned long flags, void *context)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	struct st_fdma_hw_node *hw_node;
+	struct scatterlist *sg;
+	int i;
+
+	fchan = st_fdma_prep_common(chan, sg_len, direction);
+	if (!fchan)
+		return NULL;
+
+	if (!sgl)
+		return NULL;
+
+	fdesc = st_fdma_alloc_desc(fchan, sg_len);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	fdesc->iscyclic = false;
+
+	for_each_sg(sgl, sg, sg_len, i) {
+		hw_node = fdesc->node[i].desc;
+
+		hw_node->next = fdesc->node[(i + 1) % sg_len].pdesc;
+		hw_node->control = FDMA_NODE_CTRL_REQ_MAP_DREQ(fchan->dreq_line);
+
+		fill_hw_node(hw_node, fchan, direction);
+
+		if (direction == DMA_MEM_TO_DEV)
+			hw_node->saddr = sg_dma_address(sg);
+		else
+			hw_node->daddr = sg_dma_address(sg);
+
+		hw_node->nbytes = sg_dma_len(sg);
+		hw_node->generic.length = sg_dma_len(sg);
+	}
+
+	/* interrupt at end of last node */
+	hw_node->control |= FDMA_NODE_CTRL_INT_EON;
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static size_t st_fdma_desc_residue(struct st_fdma_chan *fchan,
+				   struct virt_dma_desc *vdesc,
+				   bool in_progress)
+{
+	struct st_fdma_desc *fdesc = fchan->fdesc;
+	size_t residue = 0;
+	dma_addr_t cur_addr = 0;
+	int i;
+
+	if (in_progress) {
+		cur_addr = fchan_read(fchan, FDMA_CH_CMD_OFST);
+		cur_addr &= FDMA_CH_CMD_DATA_MASK;
+	}
+
+	for (i = fchan->fdesc->n_nodes - 1 ; i >= 0; i--) {
+		if (cur_addr == fdesc->node[i].pdesc) {
+			residue += fnode_read(fchan, FDMA_CNTN_OFST);
+			break;
+		}
+		residue += fdesc->node[i].desc->nbytes;
+	}
+
+	return residue;
+}
+
+static enum dma_status st_fdma_tx_status(struct dma_chan *chan,
+					 dma_cookie_t cookie,
+					 struct dma_tx_state *txstate)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	struct virt_dma_desc *vd;
+	enum dma_status ret;
+	unsigned long flags;
+
+	ret = dma_cookie_status(chan, cookie, txstate);
+	if (ret == DMA_COMPLETE || !txstate)
+		return ret;
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	vd = vchan_find_desc(&fchan->vchan, cookie);
+	if (fchan->fdesc && cookie == fchan->fdesc->vdesc.tx.cookie)
+		txstate->residue = st_fdma_desc_residue(fchan, vd, true);
+	else if (vd)
+		txstate->residue = st_fdma_desc_residue(fchan, vd, false);
+	else
+		txstate->residue = 0;
+
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return ret;
+}
+
+static void st_fdma_issue_pending(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	unsigned long flags;
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+
+	if (vchan_issue_pending(&fchan->vchan) && !fchan->fdesc)
+		st_fdma_xfer_desc(fchan);
+
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+}
+
+static int st_fdma_pause(struct dma_chan *chan)
+{
+	unsigned long flags;
+	LIST_HEAD(head);
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+	unsigned long cmd = FDMA_CMD_PAUSE(ch_id);
+
+	dev_dbg(fchan->fdev->dev, "pause chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	if (fchan->fdesc)
+		fdma_write(fchan->fdev, cmd, FDMA_CMD_SET_OFST);
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return 0;
+}
+
+static int st_fdma_resume(struct dma_chan *chan)
+{
+	unsigned long flags;
+	unsigned long val;
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+
+	dev_dbg(fchan->fdev->dev, "resume chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	if (fchan->fdesc) {
+		val = fchan_read(fchan, FDMA_CH_CMD_OFST);
+		val &= FDMA_CH_CMD_DATA_MASK;
+		fchan_write(fchan, val, FDMA_CH_CMD_OFST);
+	}
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return 0;
+}
+
+static int st_fdma_terminate_all(struct dma_chan *chan)
+{
+	unsigned long flags;
+	LIST_HEAD(head);
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+	unsigned long cmd = FDMA_CMD_PAUSE(ch_id);
+
+	dev_dbg(fchan->fdev->dev, "terminate chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	fdma_write(fchan->fdev, cmd, FDMA_CMD_SET_OFST);
+	fchan->fdesc = NULL;
+	vchan_get_all_descriptors(&fchan->vchan, &head);
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+	vchan_dma_desc_free_list(&fchan->vchan, &head);
+
+	return 0;
+}
+
+static int st_fdma_slave_config(struct dma_chan *chan,
+				struct dma_slave_config *slave_cfg)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+
+	memcpy(&fchan->scfg, slave_cfg, sizeof(fchan->scfg));
+	return 0;
+}
+
+static const struct st_fdma_driverdata fdma_mpe31_stih407_11 = {
+	.name = "STiH407",
+	.id = 0,
+};
+
+static const struct st_fdma_driverdata fdma_mpe31_stih407_12 = {
+	.name = "STiH407",
+	.id = 1,
+};
+
+static const struct st_fdma_driverdata fdma_mpe31_stih407_13 = {
+	.name = "STiH407",
+	.id = 2,
+};
+
+static const struct of_device_id st_fdma_match[] = {
+	{ .compatible = "st,stih407-fdma-mpe31-11"
+	  , .data = &fdma_mpe31_stih407_11 },
+	{ .compatible = "st,stih407-fdma-mpe31-12"
+	  , .data = &fdma_mpe31_stih407_12 },
+	{ .compatible = "st,stih407-fdma-mpe31-13"
+	  , .data = &fdma_mpe31_stih407_13 },
+	{},
+};
+MODULE_DEVICE_TABLE(of, st_fdma_match);
+
+static int st_fdma_parse_dt(struct platform_device *pdev,
+			const struct st_fdma_driverdata *drvdata,
+			struct st_fdma_dev *fdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int ret;
+
+	if (!np)
+		goto err;
+
+	ret = of_property_read_u32(np, "dma-channels", &fdev->nr_channels);
+	if (ret)
+		goto err;
+
+	snprintf(fdev->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
+		drvdata->name, drvdata->id);
+
+err:
+	return ret;
+}
+#define FDMA_DMA_BUSWIDTHS	(BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static void st_fdma_free(struct st_fdma_dev *fdev)
+{
+	struct st_fdma_chan *fchan;
+	int i;
+
+	for (i = 0; i < fdev->nr_channels; i++) {
+		fchan = &fdev->chans[i];
+		list_del(&fchan->vchan.chan.device_node);
+		tasklet_kill(&fchan->vchan.task);
+	}
+}
+
+static int st_fdma_probe(struct platform_device *pdev)
+{
+	struct st_fdma_dev *fdev;
+	const struct of_device_id *match;
+	struct device_node *np = pdev->dev.of_node;
+	const struct st_fdma_driverdata *drvdata;
+	int ret, i;
+
+	match = of_match_device((st_fdma_match), &pdev->dev);
+	if (!match || !match->data) {
+		dev_err(&pdev->dev, "No device match found\n");
+		return -ENODEV;
+	}
+
+	drvdata = match->data;
+
+	fdev = devm_kzalloc(&pdev->dev, sizeof(*fdev), GFP_KERNEL);
+	if (!fdev)
+		return -ENOMEM;
+
+	ret = st_fdma_parse_dt(pdev, drvdata, fdev);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to find platform data\n");
+		goto err;
+	}
+
+	fdev->chans = devm_kcalloc(&pdev->dev, fdev->nr_channels,
+				   sizeof(struct st_fdma_chan), GFP_KERNEL);
+	if (!fdev->chans)
+		return -ENOMEM;
+
+	fdev->dev = &pdev->dev;
+	fdev->drvdata = drvdata;
+	platform_set_drvdata(pdev, fdev);
+
+	fdev->irq = platform_get_irq(pdev, 0);
+	if (fdev->irq < 0) {
+		dev_err(&pdev->dev, "Failed to get irq resource\n");
+		return -EINVAL;
+	}
+
+	ret = devm_request_irq(&pdev->dev, fdev->irq, st_fdma_irq_handler, 0,
+			       dev_name(&pdev->dev), fdev);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to request irq (%d)\n", ret);
+		goto err;
+	}
+
+	fdev->slim_rproc = st_slim_rproc_alloc(pdev, fdev->fw_name);
+	if (!fdev->slim_rproc) {
+		ret = PTR_ERR(fdev->slim_rproc);
+		dev_err(&pdev->dev, "slim_rproc_alloc failed (%d)\n", ret);
+		goto err;
+	}
+
+	/* Initialise list of FDMA channels */
+	INIT_LIST_HEAD(&fdev->dma_device.channels);
+	for (i = 0; i < fdev->nr_channels; i++) {
+		struct st_fdma_chan *fchan = &fdev->chans[i];
+
+		fchan->fdev = fdev;
+		fchan->vchan.desc_free = st_fdma_free_desc;
+		vchan_init(&fchan->vchan, &fdev->dma_device);
+	}
+
+	/* Initialise the FDMA dreq (reserve 0 & 31 for FDMA use) */
+	fdev->dreq_mask = BIT(0) | BIT(31);
+
+	dma_cap_set(DMA_SLAVE, fdev->dma_device.cap_mask);
+	dma_cap_set(DMA_CYCLIC, fdev->dma_device.cap_mask);
+	dma_cap_set(DMA_MEMCPY, fdev->dma_device.cap_mask);
+
+	fdev->dma_device.dev = &pdev->dev;
+	fdev->dma_device.device_alloc_chan_resources = st_fdma_alloc_chan_res;
+	fdev->dma_device.device_free_chan_resources = st_fdma_free_chan_res;
+	fdev->dma_device.device_prep_dma_cyclic	= st_fdma_prep_dma_cyclic;
+	fdev->dma_device.device_prep_slave_sg = st_fdma_prep_slave_sg;
+	fdev->dma_device.device_prep_dma_memcpy = st_fdma_prep_dma_memcpy;
+	fdev->dma_device.device_tx_status = st_fdma_tx_status;
+	fdev->dma_device.device_issue_pending = st_fdma_issue_pending;
+	fdev->dma_device.device_terminate_all = st_fdma_terminate_all;
+	fdev->dma_device.device_config = st_fdma_slave_config;
+	fdev->dma_device.device_pause = st_fdma_pause;
+	fdev->dma_device.device_resume = st_fdma_resume;
+
+	fdev->dma_device.src_addr_widths = FDMA_DMA_BUSWIDTHS;
+	fdev->dma_device.dst_addr_widths = FDMA_DMA_BUSWIDTHS;
+	fdev->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+	fdev->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+
+	ret = dma_async_device_register(&fdev->dma_device);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"Failed to register DMA device (%d)\n", ret);
+		goto err_rproc;
+	}
+
+	ret = of_dma_controller_register(np, st_fdma_of_xlate, fdev);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"Failed to register controller (%d)\n", ret);
+		goto err_dma_dev;
+	}
+
+	dev_info(&pdev->dev, "ST FDMA engine driver, irq:%d\n", fdev->irq);
+
+	return 0;
+
+err_dma_dev:
+	dma_async_device_unregister(&fdev->dma_device);
+err_rproc:
+	st_fdma_free(fdev);
+	st_slim_rproc_put(fdev->slim_rproc);
+err:
+	return ret;
+}
+
+static int st_fdma_remove(struct platform_device *pdev)
+{
+	struct st_fdma_dev *fdev = platform_get_drvdata(pdev);
+
+	devm_free_irq(&pdev->dev, fdev->irq, fdev);
+	st_slim_rproc_put(fdev->slim_rproc);
+	of_dma_controller_free(pdev->dev.of_node);
+	dma_async_device_unregister(&fdev->dma_device);
+
+	return 0;
+}
+
+static struct platform_driver st_fdma_platform_driver = {
+	.driver = {
+		.name = DRIVER_NAME,
+		.of_match_table = st_fdma_match,
+	},
+	.probe = st_fdma_probe,
+	.remove = st_fdma_remove,
+};
+module_platform_driver(st_fdma_platform_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("STMicroelectronics FDMA engine driver");
+MODULE_AUTHOR("Ludovic.barre <Ludovic.barre@st.com>");
+MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
+MODULE_ALIAS("platform: " DRIVER_NAME);
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
  2016-09-05 13:16 ` Peter Griffin
  (?)
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization

These nodes are required to get the fdma driver working
on STiH407 based silicon.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 52 +++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index d294e82..45cab30 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -821,5 +821,57 @@
 			clock-frequency	= <600000000>;
 			st,syscfg	= <&syscfg_core 0x224>;
 		};
+
+		/* fdma audio */
+		fdma0: dma-controller@8e20000 {
+			compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
+			reg = <0x8e20000 0x8000>,
+			      <0x8e30000 0x3000>,
+			      <0x8e37000 0x1000>,
+			      <0x8e38000 0x8000>;
+			reg-names = "slimcore", "dmem", "peripherals", "imem";
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+		};
+
+		/* fdma app */
+		fdma1: dma-controller@8e40000 {
+			compatible = "st,stih407-fdma-mpe31-12", "st,slim-rproc";
+			reg = <0x8e40000 0x8000>,
+			      <0x8e50000 0x3000>,
+			      <0x8e57000 0x1000>,
+			      <0x8e58000 0x8000>;
+			reg-names = "slimcore", "dmem", "peripherals", "imem";
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+
+			interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+		};
+
+		/* fdma free running */
+		fdma2: dma-controller@8e60000 {
+			compatible = "st,stih407-fdma-mpe31-13", "st,slim-rproc";
+			reg = <0x8e60000 0x8000>,
+			      <0x8e70000 0x3000>,
+			      <0x8e77000 0x1000>,
+			      <0x8e78000 0x8000>;
+			reg-names = "slimcore", "dmem", "peripherals", "imem";
+			interrupts = <GIC_SPI 9 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				<&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
+				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones

These nodes are required to get the fdma driver working
on STiH407 based silicon.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 52 +++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index d294e82..45cab30 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -821,5 +821,57 @@
 			clock-frequency	= <600000000>;
 			st,syscfg	= <&syscfg_core 0x224>;
 		};
+
+		/* fdma audio */
+		fdma0: dma-controller@8e20000 {
+			compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
+			reg = <0x8e20000 0x8000>,
+			      <0x8e30000 0x3000>,
+			      <0x8e37000 0x1000>,
+			      <0x8e38000 0x8000>;
+			reg-names = "slimcore", "dmem", "peripherals", "imem";
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+		};
+
+		/* fdma app */
+		fdma1: dma-controller@8e40000 {
+			compatible = "st,stih407-fdma-mpe31-12", "st,slim-rproc";
+			reg = <0x8e40000 0x8000>,
+			      <0x8e50000 0x3000>,
+			      <0x8e57000 0x1000>,
+			      <0x8e58000 0x8000>;
+			reg-names = "slimcore", "dmem", "peripherals", "imem";
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+
+			interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+		};
+
+		/* fdma free running */
+		fdma2: dma-controller@8e60000 {
+			compatible = "st,stih407-fdma-mpe31-13", "st,slim-rproc";
+			reg = <0x8e60000 0x8000>,
+			      <0x8e70000 0x3000>,
+			      <0x8e77000 0x1000>,
+			      <0x8e78000 0x8000>;
+			reg-names = "slimcore", "dmem", "peripherals", "imem";
+			interrupts = <GIC_SPI 9 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				<&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
+				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

These nodes are required to get the fdma driver working
on STiH407 based silicon.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 52 +++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index d294e82..45cab30 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -821,5 +821,57 @@
 			clock-frequency	= <600000000>;
 			st,syscfg	= <&syscfg_core 0x224>;
 		};
+
+		/* fdma audio */
+		fdma0: dma-controller at 8e20000 {
+			compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
+			reg = <0x8e20000 0x8000>,
+			      <0x8e30000 0x3000>,
+			      <0x8e37000 0x1000>,
+			      <0x8e38000 0x8000>;
+			reg-names = "slimcore", "dmem", "peripherals", "imem";
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+		};
+
+		/* fdma app */
+		fdma1: dma-controller at 8e40000 {
+			compatible = "st,stih407-fdma-mpe31-12", "st,slim-rproc";
+			reg = <0x8e40000 0x8000>,
+			      <0x8e50000 0x3000>,
+			      <0x8e57000 0x1000>,
+			      <0x8e58000 0x8000>;
+			reg-names = "slimcore", "dmem", "peripherals", "imem";
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+
+			interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+		};
+
+		/* fdma free running */
+		fdma2: dma-controller at 8e60000 {
+			compatible = "st,stih407-fdma-mpe31-13", "st,slim-rproc";
+			reg = <0x8e60000 0x8000>,
+			      <0x8e70000 0x3000>,
+			      <0x8e77000 0x1000>,
+			      <0x8e78000 0x8000>;
+			reg-names = "slimcore", "dmem", "peripherals", "imem";
+			interrupts = <GIC_SPI 9 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				<&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
+				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 07/19] MAINTAINERS: Add FDMA driver files to STi section.
  2016-09-05 13:16 ` Peter Griffin
  (?)
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization

This patch adds the FDMA driver files to the STi
section of the maintainers file.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5dd3b24..d21a7b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1739,6 +1739,7 @@ F:	drivers/char/hw_random/st-rng.c
 F:	drivers/clocksource/arm_global_timer.c
 F:	drivers/clocksource/clksrc_st_lpc.c
 F:	drivers/cpufreq/sti-cpufreq.c
+F:	drivers/dma/st_fdma*
 F:	drivers/i2c/busses/i2c-st.c
 F:	drivers/media/rc/st_rc.c
 F:	drivers/media/platform/sti/c8sectpfe/
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 07/19] MAINTAINERS: Add FDMA driver files to STi section.
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones

This patch adds the FDMA driver files to the STi
section of the maintainers file.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5dd3b24..d21a7b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1739,6 +1739,7 @@ F:	drivers/char/hw_random/st-rng.c
 F:	drivers/clocksource/arm_global_timer.c
 F:	drivers/clocksource/clksrc_st_lpc.c
 F:	drivers/cpufreq/sti-cpufreq.c
+F:	drivers/dma/st_fdma*
 F:	drivers/i2c/busses/i2c-st.c
 F:	drivers/media/rc/st_rc.c
 F:	drivers/media/platform/sti/c8sectpfe/
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 07/19] MAINTAINERS: Add FDMA driver files to STi section.
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds the FDMA driver files to the STi
section of the maintainers file.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5dd3b24..d21a7b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1739,6 +1739,7 @@ F:	drivers/char/hw_random/st-rng.c
 F:	drivers/clocksource/arm_global_timer.c
 F:	drivers/clocksource/clksrc_st_lpc.c
 F:	drivers/cpufreq/sti-cpufreq.c
+F:	drivers/dma/st_fdma*
 F:	drivers/i2c/busses/i2c-st.c
 F:	drivers/media/rc/st_rc.c
 F:	drivers/media/platform/sti/c8sectpfe/
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 08/19] ARM: multi_v7_defconfig: Enable STi FDMA driver
  2016-09-05 13:16 ` Peter Griffin
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization

This DMA controller is found on all STi chipsets.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index ea23250..998578a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -784,6 +784,7 @@ CONFIG_DMA_OMAP=y
 CONFIG_QCOM_BAM_DMA=y
 CONFIG_XILINX_VDMA=y
 CONFIG_DMA_SUN6I=y
+CONFIG_ST_FDMA=m
 CONFIG_STAGING=y
 CONFIG_SENSORS_ISL29018=y
 CONFIG_SENSORS_ISL29028=y
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 08/19] ARM: multi_v7_defconfig: Enable STi FDMA driver
  2016-09-05 13:16 ` Peter Griffin
                   ` (8 preceding siblings ...)
  (?)
@ 2016-09-05 13:16 ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones

This DMA controller is found on all STi chipsets.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index ea23250..998578a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -784,6 +784,7 @@ CONFIG_DMA_OMAP=y
 CONFIG_QCOM_BAM_DMA=y
 CONFIG_XILINX_VDMA=y
 CONFIG_DMA_SUN6I=y
+CONFIG_ST_FDMA=m
 CONFIG_STAGING=y
 CONFIG_SENSORS_ISL29018=y
 CONFIG_SENSORS_ISL29028=y
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 08/19] ARM: multi_v7_defconfig: Enable STi FDMA driver
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This DMA controller is found on all STi chipsets.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index ea23250..998578a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -784,6 +784,7 @@ CONFIG_DMA_OMAP=y
 CONFIG_QCOM_BAM_DMA=y
 CONFIG_XILINX_VDMA=y
 CONFIG_DMA_SUN6I=y
+CONFIG_ST_FDMA=m
 CONFIG_STAGING=y
 CONFIG_SENSORS_ISL29018=y
 CONFIG_SENSORS_ISL29028=y
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 09/19] ARM: multi_v7_defconfig: Enable STi and simple-card drivers.
  2016-09-05 13:16 ` Peter Griffin
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization, arnaud.pouliquen, broonie

This patch enables the STi ALSA drivers found on STi platforms
as well as the simple-card driver which is a dependency to have
working sound.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Cc: arnaud.pouliquen@st.com
Cc: broonie@kernel.org
---
 arch/arm/configs/multi_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 998578a..51a38b1 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -644,6 +644,9 @@ CONFIG_SND_SOC_AK4642=m
 CONFIG_SND_SOC_SGTL5000=m
 CONFIG_SND_SOC_SPDIF=m
 CONFIG_SND_SOC_WM8978=m
+CONFIG_SND_SOC_STI=m
+CONFIG_SND_SOC_STI_SAS=m
+CONFIG_SND_SIMPLE_CARD=m
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_MVEBU=y
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 09/19] ARM: multi_v7_defconfig: Enable STi and simple-card drivers.
  2016-09-05 13:16 ` Peter Griffin
                   ` (10 preceding siblings ...)
  (?)
@ 2016-09-05 13:16 ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, arnaud.pouliquen, linux-remoteproc, dri-devel,
	virtualization, peter.griffin, broonie, dmaengine, lee.jones

This patch enables the STi ALSA drivers found on STi platforms
as well as the simple-card driver which is a dependency to have
working sound.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Cc: arnaud.pouliquen@st.com
Cc: broonie@kernel.org
---
 arch/arm/configs/multi_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 998578a..51a38b1 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -644,6 +644,9 @@ CONFIG_SND_SOC_AK4642=m
 CONFIG_SND_SOC_SGTL5000=m
 CONFIG_SND_SOC_SPDIF=m
 CONFIG_SND_SOC_WM8978=m
+CONFIG_SND_SOC_STI=m
+CONFIG_SND_SOC_STI_SAS=m
+CONFIG_SND_SIMPLE_CARD=m
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_MVEBU=y
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 09/19] ARM: multi_v7_defconfig: Enable STi and simple-card drivers.
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch enables the STi ALSA drivers found on STi platforms
as well as the simple-card driver which is a dependency to have
working sound.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Cc: arnaud.pouliquen at st.com
Cc: broonie at kernel.org
---
 arch/arm/configs/multi_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 998578a..51a38b1 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -644,6 +644,9 @@ CONFIG_SND_SOC_AK4642=m
 CONFIG_SND_SOC_SGTL5000=m
 CONFIG_SND_SOC_SPDIF=m
 CONFIG_SND_SOC_WM8978=m
+CONFIG_SND_SOC_STI=m
+CONFIG_SND_SOC_STI_SAS=m
+CONFIG_SND_SIMPLE_CARD=m
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_MVEBU=y
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 10/19] ARM: DT: STiH407: Add i2s_out pinctrl configuration
  2016-09-05 13:16 ` Peter Griffin
  (?)
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization, Arnaud Pouliquen

This patch adds the pinctrl config for the i2s_out pins
used by the uniperif player IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index a538ae5..0fb5c8a 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1067,6 +1067,29 @@
 				};
 			};
 
+			i2s_out {
+				pinctrl_i2s_8ch_out: i2s_8ch_out{
+					st,pins {
+						mclk = <&pio33 5 ALT1 OUT>;
+						lrclk = <&pio33 7 ALT1 OUT>;
+						sclk = <&pio33 6 ALT1 OUT>;
+						data0 = <&pio33 4 ALT1 OUT>;
+						data1 = <&pio34 0 ALT1 OUT>;
+						data2 = <&pio34 1 ALT1 OUT>;
+						data3 = <&pio34 2 ALT1 OUT>;
+					};
+				};
+
+				pinctrl_i2s_2ch_out: i2s_2ch_out{
+					st,pins {
+						mclk = <&pio33 5 ALT1 OUT>;
+						lrclk = <&pio33 7 ALT1 OUT>;
+						sclk = <&pio33 6 ALT1 OUT>;
+						data0 = <&pio33 4 ALT1 OUT>;
+					};
+				};
+			};
+
 			serial3 {
 				pinctrl_serial3: serial3-0 {
 					st,pins {
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 10/19] ARM: DT: STiH407: Add i2s_out pinctrl configuration
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, peter.griffin, dmaengine, lee.jones

This patch adds the pinctrl config for the i2s_out pins
used by the uniperif player IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index a538ae5..0fb5c8a 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1067,6 +1067,29 @@
 				};
 			};
 
+			i2s_out {
+				pinctrl_i2s_8ch_out: i2s_8ch_out{
+					st,pins {
+						mclk = <&pio33 5 ALT1 OUT>;
+						lrclk = <&pio33 7 ALT1 OUT>;
+						sclk = <&pio33 6 ALT1 OUT>;
+						data0 = <&pio33 4 ALT1 OUT>;
+						data1 = <&pio34 0 ALT1 OUT>;
+						data2 = <&pio34 1 ALT1 OUT>;
+						data3 = <&pio34 2 ALT1 OUT>;
+					};
+				};
+
+				pinctrl_i2s_2ch_out: i2s_2ch_out{
+					st,pins {
+						mclk = <&pio33 5 ALT1 OUT>;
+						lrclk = <&pio33 7 ALT1 OUT>;
+						sclk = <&pio33 6 ALT1 OUT>;
+						data0 = <&pio33 4 ALT1 OUT>;
+					};
+				};
+			};
+
 			serial3 {
 				pinctrl_serial3: serial3-0 {
 					st,pins {
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 10/19] ARM: DT: STiH407: Add i2s_out pinctrl configuration
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds the pinctrl config for the i2s_out pins
used by the uniperif player IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index a538ae5..0fb5c8a 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1067,6 +1067,29 @@
 				};
 			};
 
+			i2s_out {
+				pinctrl_i2s_8ch_out: i2s_8ch_out{
+					st,pins {
+						mclk = <&pio33 5 ALT1 OUT>;
+						lrclk = <&pio33 7 ALT1 OUT>;
+						sclk = <&pio33 6 ALT1 OUT>;
+						data0 = <&pio33 4 ALT1 OUT>;
+						data1 = <&pio34 0 ALT1 OUT>;
+						data2 = <&pio34 1 ALT1 OUT>;
+						data3 = <&pio34 2 ALT1 OUT>;
+					};
+				};
+
+				pinctrl_i2s_2ch_out: i2s_2ch_out{
+					st,pins {
+						mclk = <&pio33 5 ALT1 OUT>;
+						lrclk = <&pio33 7 ALT1 OUT>;
+						sclk = <&pio33 6 ALT1 OUT>;
+						data0 = <&pio33 4 ALT1 OUT>;
+					};
+				};
+			};
+
 			serial3 {
 				pinctrl_serial3: serial3-0 {
 					st,pins {
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in pinctrl configuration
  2016-09-05 13:16 ` Peter Griffin
  (?)
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization, Arnaud Pouliquen

This patch adds the pinctrl config for the i2s_in pins
used by the uniperif reader IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 0fb5c8a..537db7e 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1090,6 +1090,30 @@
 				};
 			};
 
+			i2s_in {
+				pinctrl_i2s_8ch_in: i2s_8ch_in{
+					st,pins {
+						mclk = <&pio32 5 ALT1 IN>;
+						lrclk = <&pio32 7 ALT1 IN>;
+						sclk = <&pio32 6 ALT1 IN>;
+						data0 = <&pio32 4 ALT1 IN>;
+						data1 = <&pio33 0 ALT1 IN>;
+						data2 = <&pio33 1 ALT1 IN>;
+						data3 = <&pio33 2 ALT1 IN>;
+						data4 = <&pio33 3 ALT1 IN>;
+					};
+				};
+
+				pinctrl_i2s_2ch_in: i2s_2ch_in{
+					st,pins {
+						mclk = <&pio32 5 ALT1 IN>;
+						lrclk = <&pio32 7 ALT1 IN>;
+						sclk = <&pio32 6 ALT1 IN>;
+						data0 = <&pio32 4 ALT1 IN>;
+					};
+				};
+			};
+
 			serial3 {
 				pinctrl_serial3: serial3-0 {
 					st,pins {
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in pinctrl configuration
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, peter.griffin, dmaengine, lee.jones

This patch adds the pinctrl config for the i2s_in pins
used by the uniperif reader IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 0fb5c8a..537db7e 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1090,6 +1090,30 @@
 				};
 			};
 
+			i2s_in {
+				pinctrl_i2s_8ch_in: i2s_8ch_in{
+					st,pins {
+						mclk = <&pio32 5 ALT1 IN>;
+						lrclk = <&pio32 7 ALT1 IN>;
+						sclk = <&pio32 6 ALT1 IN>;
+						data0 = <&pio32 4 ALT1 IN>;
+						data1 = <&pio33 0 ALT1 IN>;
+						data2 = <&pio33 1 ALT1 IN>;
+						data3 = <&pio33 2 ALT1 IN>;
+						data4 = <&pio33 3 ALT1 IN>;
+					};
+				};
+
+				pinctrl_i2s_2ch_in: i2s_2ch_in{
+					st,pins {
+						mclk = <&pio32 5 ALT1 IN>;
+						lrclk = <&pio32 7 ALT1 IN>;
+						sclk = <&pio32 6 ALT1 IN>;
+						data0 = <&pio32 4 ALT1 IN>;
+					};
+				};
+			};
+
 			serial3 {
 				pinctrl_serial3: serial3-0 {
 					st,pins {
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in pinctrl configuration
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds the pinctrl config for the i2s_in pins
used by the uniperif reader IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 0fb5c8a..537db7e 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1090,6 +1090,30 @@
 				};
 			};
 
+			i2s_in {
+				pinctrl_i2s_8ch_in: i2s_8ch_in{
+					st,pins {
+						mclk = <&pio32 5 ALT1 IN>;
+						lrclk = <&pio32 7 ALT1 IN>;
+						sclk = <&pio32 6 ALT1 IN>;
+						data0 = <&pio32 4 ALT1 IN>;
+						data1 = <&pio33 0 ALT1 IN>;
+						data2 = <&pio33 1 ALT1 IN>;
+						data3 = <&pio33 2 ALT1 IN>;
+						data4 = <&pio33 3 ALT1 IN>;
+					};
+				};
+
+				pinctrl_i2s_2ch_in: i2s_2ch_in{
+					st,pins {
+						mclk = <&pio32 5 ALT1 IN>;
+						lrclk = <&pio32 7 ALT1 IN>;
+						sclk = <&pio32 6 ALT1 IN>;
+						data0 = <&pio32 4 ALT1 IN>;
+					};
+				};
+			};
+
 			serial3 {
 				pinctrl_serial3: serial3-0 {
 					st,pins {
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization, Arnaud Pouliquen

This patch adds the pinctrl config for the spidf out
pins used by the sasg codec IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 537db7e..598dbab 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1114,6 +1114,14 @@
 				};
 			};
 
+			spdif_out {
+				pinctrl_spdif_out: spdif_out{
+					st,pins {
+						spdif_out = <&pio34 7 ALT1 OUT>;
+					};
+				};
+			};
+
 			serial3 {
 				pinctrl_serial3: serial3-0 {
 					st,pins {
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	patrice.chotard-qxv4g6HH51o,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, airlied-cv59FeDIM0c,
	kraxel-H+wXaHxf7aLQT0dZR+AlfA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
	bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A
  Cc: peter.griffin-QSEj5FYQhm4dnm+yROfE0A,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	Arnaud Pouliquen

This patch adds the pinctrl config for the spidf out
pins used by the sasg codec IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 537db7e..598dbab 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1114,6 +1114,14 @@
 				};
 			};
 
+			spdif_out {
+				pinctrl_spdif_out: spdif_out{
+					st,pins {
+						spdif_out = <&pio34 7 ALT1 OUT>;
+					};
+				};
+			};
+
 			serial3 {
 				pinctrl_serial3: serial3-0 {
 					st,pins {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config
  2016-09-05 13:16 ` Peter Griffin
                   ` (15 preceding siblings ...)
  (?)
@ 2016-09-05 13:16 ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, peter.griffin, dmaengine, lee.jones

This patch adds the pinctrl config for the spidf out
pins used by the sasg codec IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 537db7e..598dbab 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1114,6 +1114,14 @@
 				};
 			};
 
+			spdif_out {
+				pinctrl_spdif_out: spdif_out{
+					st,pins {
+						spdif_out = <&pio34 7 ALT1 OUT>;
+					};
+				};
+			};
+
 			serial3 {
 				pinctrl_serial3: serial3-0 {
 					st,pins {
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds the pinctrl config for the spidf out
pins used by the sasg codec IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index 537db7e..598dbab 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -1114,6 +1114,14 @@
 				};
 			};
 
+			spdif_out {
+				pinctrl_spdif_out: spdif_out{
+					st,pins {
+						spdif_out = <&pio34 7 ALT1 OUT>;
+					};
+				};
+			};
+
 			serial3 {
 				pinctrl_serial3: serial3-0 {
 					st,pins {
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 13/19] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
  2016-09-05 13:16 ` Peter Griffin
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization, Arnaud Pouliquen

This patch adds the dt node for the internal audio
codec IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 45cab30..d1258d5 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -873,5 +873,12 @@
 				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
 				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
 		};
+
+		sti_sasg_codec: sti-sasg-codec {
+			compatible = "st,stih407-sas-codec";
+			#sound-dai-cells = <1>;
+			status = "disabled";
+			st,syscfg = <&syscfg_core>;
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 13/19] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
  2016-09-05 13:16 ` Peter Griffin
                   ` (16 preceding siblings ...)
  (?)
@ 2016-09-05 13:16 ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, peter.griffin, dmaengine, lee.jones

This patch adds the dt node for the internal audio
codec IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 45cab30..d1258d5 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -873,5 +873,12 @@
 				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
 				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
 		};
+
+		sti_sasg_codec: sti-sasg-codec {
+			compatible = "st,stih407-sas-codec";
+			#sound-dai-cells = <1>;
+			status = "disabled";
+			st,syscfg = <&syscfg_core>;
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 13/19] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds the dt node for the internal audio
codec IP.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 45cab30..d1258d5 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -873,5 +873,12 @@
 				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
 				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
 		};
+
+		sti_sasg_codec: sti-sasg-codec {
+			compatible = "st,stih407-sas-codec";
+			#sound-dai-cells = <1>;
+			status = "disabled";
+			st,syscfg = <&syscfg_core>;
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 14/19] ARM: STi: DT: STiH407: Add uniperif player dt nodes
  2016-09-05 13:16 ` Peter Griffin
  (?)
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization, Arnaud Pouliquen

This patch adds the DT nodes for the uniperif player
IP blocks found on STiH407 family silicon.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 80 +++++++++++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index d1258d5..1edc36c 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -880,5 +880,85 @@
 			status = "disabled";
 			st,syscfg = <&syscfg_core>;
 		};
+
+		sti_uni_player0: sti-uni-player@8d80000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_PCM_0>;
+			assigned-clocks = <&clk_s_d0_quadfs 0>, <&clk_s_d0_flexgen CLK_PCM_0>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 0>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d80000 0x158>;
+			interrupts = <GIC_SPI 84 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 2 0 1>;
+			dai-name = "Uni Player #0 (HDMI)";
+			dma-names = "tx";
+			st,uniperiph-id = <0>;
+			st,version = <5>;
+			st,mode = "HDMI";
+
+			status		= "disabled";
+		};
+
+		sti_uni_player1: sti-uni-player@8d81000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_PCM_1>;
+			assigned-clocks = <&clk_s_d0_quadfs 1>, <&clk_s_d0_flexgen CLK_PCM_1>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 1>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d81000 0x158>;
+			interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 3 0 1>;
+			dai-name = "Uni Player #1 (PIO)";
+			dma-names = "tx";
+			st,uniperiph-id = <1>;
+			st,version = <5>;
+			st,mode = "PCM";
+
+			status = "disabled";
+		};
+
+		sti_uni_player2: sti-uni-player@8d82000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+			assigned-clocks = <&clk_s_d0_quadfs 2>, <&clk_s_d0_flexgen CLK_PCM_2>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 2>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d82000 0x158>;
+			interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 4 0 1>;
+			dai-name = "Uni Player #1 (DAC)";
+			dma-names = "tx";
+			st,uniperiph-id = <2>;
+			st,version = <5>;
+			st,mode = "PCM";
+
+			status = "disabled";
+		};
+
+		sti_uni_player3: sti-uni-player@8d85000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_SPDIFF>;
+			assigned-clocks = <&clk_s_d0_quadfs 3>, <&clk_s_d0_flexgen CLK_SPDIFF>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 3>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d85000 0x158>;
+			interrupts = <GIC_SPI 89 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 7 0 1>;
+			dma-names = "tx";
+			dai-name = "Uni Player #1 (PIO)";
+			st,uniperiph-id = <3>;
+			st,version = <5>;
+			st,mode = "SPDIF";
+
+			status = "disabled";
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 14/19] ARM: STi: DT: STiH407: Add uniperif player dt nodes
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, peter.griffin, dmaengine, lee.jones

This patch adds the DT nodes for the uniperif player
IP blocks found on STiH407 family silicon.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 80 +++++++++++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index d1258d5..1edc36c 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -880,5 +880,85 @@
 			status = "disabled";
 			st,syscfg = <&syscfg_core>;
 		};
+
+		sti_uni_player0: sti-uni-player@8d80000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_PCM_0>;
+			assigned-clocks = <&clk_s_d0_quadfs 0>, <&clk_s_d0_flexgen CLK_PCM_0>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 0>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d80000 0x158>;
+			interrupts = <GIC_SPI 84 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 2 0 1>;
+			dai-name = "Uni Player #0 (HDMI)";
+			dma-names = "tx";
+			st,uniperiph-id = <0>;
+			st,version = <5>;
+			st,mode = "HDMI";
+
+			status		= "disabled";
+		};
+
+		sti_uni_player1: sti-uni-player@8d81000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_PCM_1>;
+			assigned-clocks = <&clk_s_d0_quadfs 1>, <&clk_s_d0_flexgen CLK_PCM_1>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 1>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d81000 0x158>;
+			interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 3 0 1>;
+			dai-name = "Uni Player #1 (PIO)";
+			dma-names = "tx";
+			st,uniperiph-id = <1>;
+			st,version = <5>;
+			st,mode = "PCM";
+
+			status = "disabled";
+		};
+
+		sti_uni_player2: sti-uni-player@8d82000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+			assigned-clocks = <&clk_s_d0_quadfs 2>, <&clk_s_d0_flexgen CLK_PCM_2>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 2>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d82000 0x158>;
+			interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 4 0 1>;
+			dai-name = "Uni Player #1 (DAC)";
+			dma-names = "tx";
+			st,uniperiph-id = <2>;
+			st,version = <5>;
+			st,mode = "PCM";
+
+			status = "disabled";
+		};
+
+		sti_uni_player3: sti-uni-player@8d85000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_SPDIFF>;
+			assigned-clocks = <&clk_s_d0_quadfs 3>, <&clk_s_d0_flexgen CLK_SPDIFF>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 3>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d85000 0x158>;
+			interrupts = <GIC_SPI 89 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 7 0 1>;
+			dma-names = "tx";
+			dai-name = "Uni Player #1 (PIO)";
+			st,uniperiph-id = <3>;
+			st,version = <5>;
+			st,mode = "SPDIF";
+
+			status = "disabled";
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 14/19] ARM: STi: DT: STiH407: Add uniperif player dt nodes
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds the DT nodes for the uniperif player
IP blocks found on STiH407 family silicon.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 80 +++++++++++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index d1258d5..1edc36c 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -880,5 +880,85 @@
 			status = "disabled";
 			st,syscfg = <&syscfg_core>;
 		};
+
+		sti_uni_player0: sti-uni-player at 8d80000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_PCM_0>;
+			assigned-clocks = <&clk_s_d0_quadfs 0>, <&clk_s_d0_flexgen CLK_PCM_0>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 0>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d80000 0x158>;
+			interrupts = <GIC_SPI 84 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 2 0 1>;
+			dai-name = "Uni Player #0 (HDMI)";
+			dma-names = "tx";
+			st,uniperiph-id = <0>;
+			st,version = <5>;
+			st,mode = "HDMI";
+
+			status		= "disabled";
+		};
+
+		sti_uni_player1: sti-uni-player at 8d81000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_PCM_1>;
+			assigned-clocks = <&clk_s_d0_quadfs 1>, <&clk_s_d0_flexgen CLK_PCM_1>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 1>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d81000 0x158>;
+			interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 3 0 1>;
+			dai-name = "Uni Player #1 (PIO)";
+			dma-names = "tx";
+			st,uniperiph-id = <1>;
+			st,version = <5>;
+			st,mode = "PCM";
+
+			status = "disabled";
+		};
+
+		sti_uni_player2: sti-uni-player at 8d82000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
+			assigned-clocks = <&clk_s_d0_quadfs 2>, <&clk_s_d0_flexgen CLK_PCM_2>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 2>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d82000 0x158>;
+			interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 4 0 1>;
+			dai-name = "Uni Player #1 (DAC)";
+			dma-names = "tx";
+			st,uniperiph-id = <2>;
+			st,version = <5>;
+			st,mode = "PCM";
+
+			status = "disabled";
+		};
+
+		sti_uni_player3: sti-uni-player at 8d85000 {
+			compatible = "st,sti-uni-player";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			clocks = <&clk_s_d0_flexgen CLK_SPDIFF>;
+			assigned-clocks = <&clk_s_d0_quadfs 3>, <&clk_s_d0_flexgen CLK_SPDIFF>;
+			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 3>;
+			assigned-clock-rates = <50000000>;
+			reg = <0x8d85000 0x158>;
+			interrupts = <GIC_SPI 89 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 7 0 1>;
+			dma-names = "tx";
+			dai-name = "Uni Player #1 (PIO)";
+			st,uniperiph-id = <3>;
+			st,version = <5>;
+			st,mode = "SPDIF";
+
+			status = "disabled";
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader dt nodes
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization, Arnaud Pouliquen

This patch adds the DT node for the uniperif reader
IP block found on STiH407 family silicon.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 1edc36c..883019a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -960,5 +960,33 @@
 
 			status = "disabled";
 		};
+
+		sti_uni_reader0: sti-uni-reader@8d83000 {
+			compatible = "st,sti-uni-reader";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			reg = <0x8d83000 0x158>;
+			interrupts = <GIC_SPI 87 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 5 0 1>;
+			dma-names = "rx";
+			dai-name = "Uni Reader #0 (PCM IN)";
+			st,version = <3>;
+
+			status = "disabled";
+		};
+
+		sti_uni_reader1: sti-uni-reader@8d84000 {
+			compatible = "st,sti-uni-reader";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			reg = <0x8d84000 0x158>;
+			interrupts = <GIC_SPI 88 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 6 0 1>;
+			dma-names = "rx";
+			dai-name = "Uni Reader #1 (HDMI RX)";
+			st,version = <3>;
+
+			status = "disabled";
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader dt nodes
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	patrice.chotard-qxv4g6HH51o,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, airlied-cv59FeDIM0c,
	kraxel-H+wXaHxf7aLQT0dZR+AlfA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
	bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A
  Cc: peter.griffin-QSEj5FYQhm4dnm+yROfE0A,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	Arnaud Pouliquen

This patch adds the DT node for the uniperif reader
IP block found on STiH407 family silicon.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 1edc36c..883019a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -960,5 +960,33 @@
 
 			status = "disabled";
 		};
+
+		sti_uni_reader0: sti-uni-reader@8d83000 {
+			compatible = "st,sti-uni-reader";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			reg = <0x8d83000 0x158>;
+			interrupts = <GIC_SPI 87 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 5 0 1>;
+			dma-names = "rx";
+			dai-name = "Uni Reader #0 (PCM IN)";
+			st,version = <3>;
+
+			status = "disabled";
+		};
+
+		sti_uni_reader1: sti-uni-reader@8d84000 {
+			compatible = "st,sti-uni-reader";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			reg = <0x8d84000 0x158>;
+			interrupts = <GIC_SPI 88 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 6 0 1>;
+			dma-names = "rx";
+			dai-name = "Uni Reader #1 (HDMI RX)";
+			st,version = <3>;
+
+			status = "disabled";
+		};
 	};
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader dt nodes
  2016-09-05 13:16 ` Peter Griffin
                   ` (19 preceding siblings ...)
  (?)
@ 2016-09-05 13:16 ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, peter.griffin, dmaengine, lee.jones

This patch adds the DT node for the uniperif reader
IP block found on STiH407 family silicon.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 1edc36c..883019a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -960,5 +960,33 @@
 
 			status = "disabled";
 		};
+
+		sti_uni_reader0: sti-uni-reader@8d83000 {
+			compatible = "st,sti-uni-reader";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			reg = <0x8d83000 0x158>;
+			interrupts = <GIC_SPI 87 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 5 0 1>;
+			dma-names = "rx";
+			dai-name = "Uni Reader #0 (PCM IN)";
+			st,version = <3>;
+
+			status = "disabled";
+		};
+
+		sti_uni_reader1: sti-uni-reader@8d84000 {
+			compatible = "st,sti-uni-reader";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			reg = <0x8d84000 0x158>;
+			interrupts = <GIC_SPI 88 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 6 0 1>;
+			dma-names = "rx";
+			dai-name = "Uni Reader #1 (HDMI RX)";
+			st,version = <3>;
+
+			status = "disabled";
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader dt nodes
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds the DT node for the uniperif reader
IP block found on STiH407 family silicon.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 1edc36c..883019a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -960,5 +960,33 @@
 
 			status = "disabled";
 		};
+
+		sti_uni_reader0: sti-uni-reader at 8d83000 {
+			compatible = "st,sti-uni-reader";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			reg = <0x8d83000 0x158>;
+			interrupts = <GIC_SPI 87 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 5 0 1>;
+			dma-names = "rx";
+			dai-name = "Uni Reader #0 (PCM IN)";
+			st,version = <3>;
+
+			status = "disabled";
+		};
+
+		sti_uni_reader1: sti-uni-reader at 8d84000 {
+			compatible = "st,sti-uni-reader";
+			#sound-dai-cells = <0>;
+			st,syscfg = <&syscfg_core>;
+			reg = <0x8d84000 0x158>;
+			interrupts = <GIC_SPI 88 IRQ_TYPE_NONE>;
+			dmas = <&fdma0 6 0 1>;
+			dma-names = "rx";
+			dai-name = "Uni Reader #1 (HDMI RX)";
+			st,version = <3>;
+
+			status = "disabled";
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 16/19] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
  2016-09-05 13:16 ` Peter Griffin
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization, Arnaud Pouliquen

This patch enables the uniperif players 2 & 3 for b2120 boards
and also adds the "simple-audio-card" device node to interconnect
the SoC sound device and the codec.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stihxxx-b2120.dtsi | 45 ++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index 722c63f..4939501 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -131,5 +131,50 @@
 				dvb-card	= <STV0367_TDA18212_NIMA_1>;
 			};
 		};
+
+		sti_uni_player2: sti-uni-player@8d82000 {
+			status = "okay";
+		};
+
+		sti_uni_player3: sti-uni-player@8d85000 {
+			status = "okay";
+		};
+
+		sti_sasg_codec: sti-sasg-codec {
+			status = "okay";
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_spdif_out>;
+		};
+
+		sound {
+			compatible = "simple-audio-card";
+			simple-audio-card,name = "sti audio card";
+			status = "okay";
+
+			simple-audio-card,dai-link@0 {
+				/* DAC */
+				format = "i2s";
+				mclk-fs = <256>;
+				cpu {
+					sound-dai = <&sti_uni_player2>;
+				};
+
+				codec {
+					sound-dai = <&sti_sasg_codec 1>;
+				};
+			};
+			simple-audio-card,dai-link@1 {
+				/* SPDIF */
+				format = "left_j";
+				mclk-fs = <128>;
+				cpu {
+					sound-dai = <&sti_uni_player3>;
+				};
+
+				codec {
+					sound-dai = <&sti_sasg_codec 0>;
+				};
+			};
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 16/19] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
  2016-09-05 13:16 ` Peter Griffin
                   ` (22 preceding siblings ...)
  (?)
@ 2016-09-05 13:16 ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, peter.griffin, dmaengine, lee.jones

This patch enables the uniperif players 2 & 3 for b2120 boards
and also adds the "simple-audio-card" device node to interconnect
the SoC sound device and the codec.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stihxxx-b2120.dtsi | 45 ++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index 722c63f..4939501 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -131,5 +131,50 @@
 				dvb-card	= <STV0367_TDA18212_NIMA_1>;
 			};
 		};
+
+		sti_uni_player2: sti-uni-player@8d82000 {
+			status = "okay";
+		};
+
+		sti_uni_player3: sti-uni-player@8d85000 {
+			status = "okay";
+		};
+
+		sti_sasg_codec: sti-sasg-codec {
+			status = "okay";
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_spdif_out>;
+		};
+
+		sound {
+			compatible = "simple-audio-card";
+			simple-audio-card,name = "sti audio card";
+			status = "okay";
+
+			simple-audio-card,dai-link@0 {
+				/* DAC */
+				format = "i2s";
+				mclk-fs = <256>;
+				cpu {
+					sound-dai = <&sti_uni_player2>;
+				};
+
+				codec {
+					sound-dai = <&sti_sasg_codec 1>;
+				};
+			};
+			simple-audio-card,dai-link@1 {
+				/* SPDIF */
+				format = "left_j";
+				mclk-fs = <128>;
+				cpu {
+					sound-dai = <&sti_uni_player3>;
+				};
+
+				codec {
+					sound-dai = <&sti_sasg_codec 0>;
+				};
+			};
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 16/19] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch enables the uniperif players 2 & 3 for b2120 boards
and also adds the "simple-audio-card" device node to interconnect
the SoC sound device and the codec.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stihxxx-b2120.dtsi | 45 ++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index 722c63f..4939501 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -131,5 +131,50 @@
 				dvb-card	= <STV0367_TDA18212_NIMA_1>;
 			};
 		};
+
+		sti_uni_player2: sti-uni-player at 8d82000 {
+			status = "okay";
+		};
+
+		sti_uni_player3: sti-uni-player at 8d85000 {
+			status = "okay";
+		};
+
+		sti_sasg_codec: sti-sasg-codec {
+			status = "okay";
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_spdif_out>;
+		};
+
+		sound {
+			compatible = "simple-audio-card";
+			simple-audio-card,name = "sti audio card";
+			status = "okay";
+
+			simple-audio-card,dai-link at 0 {
+				/* DAC */
+				format = "i2s";
+				mclk-fs = <256>;
+				cpu {
+					sound-dai = <&sti_uni_player2>;
+				};
+
+				codec {
+					sound-dai = <&sti_sasg_codec 1>;
+				};
+			};
+			simple-audio-card,dai-link at 1 {
+				/* SPDIF */
+				format = "left_j";
+				mclk-fs = <128>;
+				cpu {
+					sound-dai = <&sti_uni_player3>;
+				};
+
+				codec {
+					sound-dai = <&sti_sasg_codec 0>;
+				};
+			};
+		};
 	};
 };
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-05 13:16 ` Peter Griffin
@ 2016-09-05 13:16   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization

ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
recursive dependency.

[..]
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5:	symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:42:	symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:36:	symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/virtio/Kconfig:1:	symbol DRM_VIRTIO_GPU depends on VIRTIO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/virtio/Kconfig:1:	symbol VIRTIO is selected by REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:4:	symbol REMOTEPROC is selected by ST_SLIM_REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:103:	symbol ST_SLIM_REMOTEPROC is selected by ST_FDMA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:440:	symbol ST_FDMA depends on DMADEVICES
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:5:	symbol DMADEVICES is selected by SND_SOC_SH4_SIU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:29:	symbol SND_SOC_SH4_SIU is selected by SND_SIU_MIGOR
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:64:	symbol SND_SIU_MIGOR depends on I2C
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/i2c/Kconfig:7:	symbol I2C is selected by FB_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:63:	symbol FB_DDC is selected by FB_CYBER2000_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:378:	symbol FB_CYBER2000_DDC depends on FB_CYBER2000
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:366:	symbol FB_CYBER2000 depends on FB

which is due to drivers/gpu/drm/virtio/Kconfig depending on VIRTIO.

Fix by dropping depend and switching to select VIRTIO.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/gpu/drm/virtio/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index e1afc3d..90357d9 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -1,6 +1,7 @@
 config DRM_VIRTIO_GPU
 	tristate "Virtio GPU driver"
-	depends on DRM && VIRTIO
+	depends on DRM
+	select VIRTIO
         select DRM_KMS_HELPER
         select DRM_TTM
 	help
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-05 13:16 ` Peter Griffin
                   ` (23 preceding siblings ...)
  (?)
@ 2016-09-05 13:16 ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones

ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
recursive dependency.

[..]
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5:	symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:42:	symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:36:	symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/virtio/Kconfig:1:	symbol DRM_VIRTIO_GPU depends on VIRTIO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/virtio/Kconfig:1:	symbol VIRTIO is selected by REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:4:	symbol REMOTEPROC is selected by ST_SLIM_REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:103:	symbol ST_SLIM_REMOTEPROC is selected by ST_FDMA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:440:	symbol ST_FDMA depends on DMADEVICES
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:5:	symbol DMADEVICES is selected by SND_SOC_SH4_SIU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:29:	symbol SND_SOC_SH4_SIU is selected by SND_SIU_MIGOR
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:64:	symbol SND_SIU_MIGOR depends on I2C
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/i2c/Kconfig:7:	symbol I2C is selected by FB_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:63:	symbol FB_DDC is selected by FB_CYBER2000_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:378:	symbol FB_CYBER2000_DDC depends on FB_CYBER2000
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:366:	symbol FB_CYBER2000 depends on FB

which is due to drivers/gpu/drm/virtio/Kconfig depending on VIRTIO.

Fix by dropping depend and switching to select VIRTIO.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/gpu/drm/virtio/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index e1afc3d..90357d9 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -1,6 +1,7 @@
 config DRM_VIRTIO_GPU
 	tristate "Virtio GPU driver"
-	depends on DRM && VIRTIO
+	depends on DRM
+	select VIRTIO
         select DRM_KMS_HELPER
         select DRM_TTM
 	help
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-05 13:16   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:16 UTC (permalink / raw)
  To: linux-arm-kernel

ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
recursive dependency.

[..]
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5:	symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:42:	symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:36:	symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/virtio/Kconfig:1:	symbol DRM_VIRTIO_GPU depends on VIRTIO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/virtio/Kconfig:1:	symbol VIRTIO is selected by REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:4:	symbol REMOTEPROC is selected by ST_SLIM_REMOTEPROC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/remoteproc/Kconfig:103:	symbol ST_SLIM_REMOTEPROC is selected by ST_FDMA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:440:	symbol ST_FDMA depends on DMADEVICES
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:5:	symbol DMADEVICES is selected by SND_SOC_SH4_SIU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:29:	symbol SND_SOC_SH4_SIU is selected by SND_SIU_MIGOR
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:64:	symbol SND_SIU_MIGOR depends on I2C
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/i2c/Kconfig:7:	symbol I2C is selected by FB_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:63:	symbol FB_DDC is selected by FB_CYBER2000_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:378:	symbol FB_CYBER2000_DDC depends on FB_CYBER2000
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:366:	symbol FB_CYBER2000 depends on FB

which is due to drivers/gpu/drm/virtio/Kconfig depending on VIRTIO.

Fix by dropping depend and switching to select VIRTIO.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/gpu/drm/virtio/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index e1afc3d..90357d9 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -1,6 +1,7 @@
 config DRM_VIRTIO_GPU
 	tristate "Virtio GPU driver"
-	depends on DRM && VIRTIO
+	depends on DRM
+	select VIRTIO
         select DRM_KMS_HELPER
         select DRM_TTM
 	help
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 18/19] drm/virtio: kconfig: Fixup white space.
  2016-09-05 13:16 ` Peter Griffin
@ 2016-09-05 13:17   ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:17 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization

Use tabs instead of spaces.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/gpu/drm/virtio/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index 90357d9..2d83932 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -2,10 +2,10 @@ config DRM_VIRTIO_GPU
 	tristate "Virtio GPU driver"
 	depends on DRM
 	select VIRTIO
-        select DRM_KMS_HELPER
-        select DRM_TTM
+	select DRM_KMS_HELPER
+	select DRM_TTM
 	help
 	   This is the virtual GPU driver for virtio.  It can be used with
-           QEMU based VMMs (like KVM or Xen).
+	   QEMU based VMMs (like KVM or Xen).
 
 	   If unsure say M.
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 18/19] drm/virtio: kconfig: Fixup white space.
  2016-09-05 13:16 ` Peter Griffin
                   ` (26 preceding siblings ...)
  (?)
@ 2016-09-05 13:17 ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:17 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones

Use tabs instead of spaces.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/gpu/drm/virtio/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index 90357d9..2d83932 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -2,10 +2,10 @@ config DRM_VIRTIO_GPU
 	tristate "Virtio GPU driver"
 	depends on DRM
 	select VIRTIO
-        select DRM_KMS_HELPER
-        select DRM_TTM
+	select DRM_KMS_HELPER
+	select DRM_TTM
 	help
 	   This is the virtual GPU driver for virtio.  It can be used with
-           QEMU based VMMs (like KVM or Xen).
+	   QEMU based VMMs (like KVM or Xen).
 
 	   If unsure say M.
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 18/19] drm/virtio: kconfig: Fixup white space.
@ 2016-09-05 13:17   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:17 UTC (permalink / raw)
  To: linux-arm-kernel

Use tabs instead of spaces.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/gpu/drm/virtio/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index 90357d9..2d83932 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -2,10 +2,10 @@ config DRM_VIRTIO_GPU
 	tristate "Virtio GPU driver"
 	depends on DRM
 	select VIRTIO
-        select DRM_KMS_HELPER
-        select DRM_TTM
+	select DRM_KMS_HELPER
+	select DRM_TTM
 	help
 	   This is the virtual GPU driver for virtio.  It can be used with
-           QEMU based VMMs (like KVM or Xen).
+	   QEMU based VMMs (like KVM or Xen).
 
 	   If unsure say M.
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 19/19] dmaengine: kconfig: Remove superfluous '\n'
@ 2016-09-05 13:17   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:17 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: peter.griffin, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization

Remove the extra '\n' between kconfig entries.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/dma/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 7c5d946..5b5a341 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -462,7 +462,6 @@ config STM32_DMA
 	  If you have a board based on such a MCU and wish to use DMA say Y or M
 	  here.
 
-
 config S3C24XX_DMAC
 	bool "Samsung S3C24XX DMA support"
 	depends on ARCH_S3C24XX
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 19/19] dmaengine: kconfig: Remove superfluous '\n'
@ 2016-09-05 13:17   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:17 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	patrice.chotard-qxv4g6HH51o,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, airlied-cv59FeDIM0c,
	kraxel-H+wXaHxf7aLQT0dZR+AlfA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
	bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A
  Cc: peter.griffin-QSEj5FYQhm4dnm+yROfE0A,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA

Remove the extra '\n' between kconfig entries.

Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/dma/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 7c5d946..5b5a341 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -462,7 +462,6 @@ config STM32_DMA
 	  If you have a board based on such a MCU and wish to use DMA say Y or M
 	  here.
 
-
 config S3C24XX_DMAC
 	bool "Samsung S3C24XX DMA support"
 	depends on ARCH_S3C24XX
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 19/19] dmaengine: kconfig: Remove superfluous '\n'
  2016-09-05 13:16 ` Peter Griffin
                   ` (28 preceding siblings ...)
  (?)
@ 2016-09-05 13:17 ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:17 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	peter.griffin, dmaengine, lee.jones

Remove the extra '\n' between kconfig entries.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/dma/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 7c5d946..5b5a341 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -462,7 +462,6 @@ config STM32_DMA
 	  If you have a board based on such a MCU and wish to use DMA say Y or M
 	  here.
 
-
 config S3C24XX_DMAC
 	bool "Samsung S3C24XX DMA support"
 	depends on ARCH_S3C24XX
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* [PATCH v9 19/19] dmaengine: kconfig: Remove superfluous '\n'
@ 2016-09-05 13:17   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-05 13:17 UTC (permalink / raw)
  To: linux-arm-kernel

Remove the extra '\n' between kconfig entries.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/dma/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 7c5d946..5b5a341 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -462,7 +462,6 @@ config STM32_DMA
 	  If you have a board based on such a MCU and wish to use DMA say Y or M
 	  here.
 
-
 config S3C24XX_DMAC
 	bool "Samsung S3C24XX DMA support"
 	depends on ARCH_S3C24XX
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-13  9:31   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-13  9:31 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization

Hi Vinod & Bjorn,

[..]

On Mon, 05 Sep 2016, Peter Griffin wrote:

> v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
> a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
> slim_rproc driver. The series has also been rebased on v4.8-rc3.
> 
> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
> was found during testing now that the platform boots without clk_ignore_unused parameter
> whereby the clocks would not be enabled properly before firmware loading was attempted.
> 
> regards,
> 
> Peter.
> 
> Changes since v8:
>  - Add MODULE_ALIAS (Vinod)
>  - devm_kzalloc to devm_kcalloc (Vinod)
>  - quisce tasklet initialised by vchan_init() (Vinod)
>  - Don't make SLIM rproc user selectable (Bjorn)
>  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
>  - Various code style nits / commit message change (Lee)
>  - Separate patch for '\n' kconfig removal (Vinod)

I hate to send a ping, but do you think we can merge this fdma series? It has gone
through quite a few review rounds now.

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-13  9:31   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-13  9:31 UTC (permalink / raw)
  To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	patrice.chotard-qxv4g6HH51o,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, airlied-cv59FeDIM0c,
	kraxel-H+wXaHxf7aLQT0dZR+AlfA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
	bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A
  Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA

Hi Vinod & Bjorn,

[..]

On Mon, 05 Sep 2016, Peter Griffin wrote:

> v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
> a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
> slim_rproc driver. The series has also been rebased on v4.8-rc3.
> 
> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
> was found during testing now that the platform boots without clk_ignore_unused parameter
> whereby the clocks would not be enabled properly before firmware loading was attempted.
> 
> regards,
> 
> Peter.
> 
> Changes since v8:
>  - Add MODULE_ALIAS (Vinod)
>  - devm_kzalloc to devm_kcalloc (Vinod)
>  - quisce tasklet initialised by vchan_init() (Vinod)
>  - Don't make SLIM rproc user selectable (Bjorn)
>  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
>  - Various code style nits / commit message change (Lee)
>  - Separate patch for '\n' kconfig removal (Vinod)

I hate to send a ping, but do you think we can merge this fdma series? It has gone
through quite a few review rounds now.

regards,

Peter.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
  2016-09-05 13:16 ` Peter Griffin
                   ` (29 preceding siblings ...)
  (?)
@ 2016-09-13  9:31 ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-13  9:31 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	dmaengine, lee.jones

Hi Vinod & Bjorn,

[..]

On Mon, 05 Sep 2016, Peter Griffin wrote:

> v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
> a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
> slim_rproc driver. The series has also been rebased on v4.8-rc3.
> 
> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
> was found during testing now that the platform boots without clk_ignore_unused parameter
> whereby the clocks would not be enabled properly before firmware loading was attempted.
> 
> regards,
> 
> Peter.
> 
> Changes since v8:
>  - Add MODULE_ALIAS (Vinod)
>  - devm_kzalloc to devm_kcalloc (Vinod)
>  - quisce tasklet initialised by vchan_init() (Vinod)
>  - Don't make SLIM rproc user selectable (Bjorn)
>  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
>  - Various code style nits / commit message change (Lee)
>  - Separate patch for '\n' kconfig removal (Vinod)

I hate to send a ping, but do you think we can merge this fdma series? It has gone
through quite a few review rounds now.

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-13  9:31   ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-13  9:31 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Vinod & Bjorn,

[..]

On Mon, 05 Sep 2016, Peter Griffin wrote:

> v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
> a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
> slim_rproc driver. The series has also been rebased on v4.8-rc3.
> 
> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
> was found during testing now that the platform boots without clk_ignore_unused parameter
> whereby the clocks would not be enabled properly before firmware loading was attempted.
> 
> regards,
> 
> Peter.
> 
> Changes since v8:
>  - Add MODULE_ALIAS (Vinod)
>  - devm_kzalloc to devm_kcalloc (Vinod)
>  - quisce tasklet initialised by vchan_init() (Vinod)
>  - Don't make SLIM rproc user selectable (Bjorn)
>  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
>  - Various code style nits / commit message change (Lee)
>  - Separate patch for '\n' kconfig removal (Vinod)

I hate to send a ping, but do you think we can merge this fdma series? It has gone
through quite a few review rounds now.

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver
  2016-09-05 13:16   ` Peter Griffin
  (?)
@ 2016-09-13 17:56     ` Bjorn Andersson
  -1 siblings, 0 replies; 174+ messages in thread
From: Bjorn Andersson @ 2016-09-13 17:56 UTC (permalink / raw)
  To: Peter Griffin
  Cc: linux-arm-kernel, linux-kernel, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization

On Mon 05 Sep 06:16 PDT 2016, Peter Griffin wrote:

> slim core is used as a basis for many IPs in the STi
> chipsets such as fdma and demux. To avoid duplicating
> the elf loading code in each device driver a slim
> rproc driver has been created.
> 
> This driver is designed to be used by other device drivers
> such as fdma, or demux whose IP is based around a slim core.
> The device driver can call slim_rproc_alloc() to allocate
> a slim rproc and slim_rproc_put() when finished.
> 
> This driver takes care of ioremapping the slim
> registers (dmem, imem, slimcore, peripherals), whose offsets
> and sizes can change between IP's. It also obtains and enables
> any clocks used by the device. This approach avoids having
> a double mapping of the registers as slim_rproc does not register
> its own platform device. It also maps well to device tree
> abstraction as it allows us to have one dt node for the whole
> device.
> 
> All of the generic rproc elf loading code can be reused, and
> we provide start() stop() hooks to start and stop the slim
> core once the firmware has been loaded. This has been tested
> successfully with fdma driver.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>

Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> ---
>  drivers/remoteproc/Kconfig               |   4 +
>  drivers/remoteproc/Makefile              |   1 +
>  drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
>  include/linux/remoteproc/st_slim_rproc.h |  58 +++++
>  4 files changed, 427 insertions(+)
>  create mode 100644 drivers/remoteproc/st_slim_rproc.c
>  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 1a8bf76a..a7bedc6 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -100,4 +100,8 @@ config ST_REMOTEPROC
>  	  processor framework.
>  	  This can be either built-in or a loadable module.
>  
> +config ST_SLIM_REMOTEPROC
> +	tristate
> +	select REMOTEPROC
> +
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 92d3758..db1dae7 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
>  obj-$(CONFIG_QCOM_MDT_LOADER)		+= qcom_mdt_loader.o
>  obj-$(CONFIG_QCOM_Q6V5_PIL)		+= qcom_q6v5_pil.o
>  obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
> +obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
> diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> new file mode 100644
> index 0000000..1484e97
> --- /dev/null
> +++ b/drivers/remoteproc/st_slim_rproc.c
> @@ -0,0 +1,364 @@
> +/*
> + * SLIM core rproc driver
> + *
> + * Copyright (C) 2016 STMicroelectronics
> + *
> + * Author: Peter Griffin <peter.griffin@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/remoteproc.h>
> +#include <linux/remoteproc/st_slim_rproc.h>
> +#include "remoteproc_internal.h"
> +
> +/* SLIM core registers */
> +#define SLIM_ID_OFST		0x0
> +#define SLIM_VER_OFST		0x4
> +
> +#define SLIM_EN_OFST		0x8
> +#define SLIM_EN_RUN			BIT(0)
> +
> +#define SLIM_CLK_GATE_OFST	0xC
> +#define SLIM_CLK_GATE_DIS		BIT(0)
> +#define SLIM_CLK_GATE_RESET		BIT(2)
> +
> +#define SLIM_SLIM_PC_OFST	0x20
> +
> +/* DMEM registers */
> +#define SLIM_REV_ID_OFST	0x0
> +#define SLIM_REV_ID_MIN_MASK		GENMASK(15, 8)
> +#define SLIM_REV_ID_MIN(id)		((id & SLIM_REV_ID_MIN_MASK) >> 8)
> +#define SLIM_REV_ID_MAJ_MASK		GENMASK(23, 16)
> +#define SLIM_REV_ID_MAJ(id)		((id & SLIM_REV_ID_MAJ_MASK) >> 16)
> +
> +
> +/* peripherals registers */
> +#define SLIM_STBUS_SYNC_OFST	0xF88
> +#define SLIM_STBUS_SYNC_DIS		BIT(0)
> +
> +#define SLIM_INT_SET_OFST	0xFD4
> +#define SLIM_INT_CLR_OFST	0xFD8
> +#define SLIM_INT_MASK_OFST	0xFDC
> +
> +#define SLIM_CMD_CLR_OFST	0xFC8
> +#define SLIM_CMD_MASK_OFST	0xFCC
> +
> +static const char *mem_names[ST_SLIM_MEM_MAX] = {
> +	[ST_SLIM_DMEM]	= "dmem",
> +	[ST_SLIM_IMEM]	= "imem",
> +};
> +
> +static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
> +{
> +	int clk, err;
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
> +		slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
> +		if (IS_ERR(slim_rproc->clks[clk])) {
> +			err = PTR_ERR(slim_rproc->clks[clk]);
> +			if (err == -EPROBE_DEFER)
> +				goto err_put_clks;
> +			slim_rproc->clks[clk] = NULL;
> +			break;
> +		}
> +	}
> +
> +	return 0;
> +
> +err_put_clks:
> +	while (--clk >= 0)
> +		clk_put(slim_rproc->clks[clk]);
> +
> +	return err;
> +}
> +
> +static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
> +{
> +	int clk;
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> +		clk_disable_unprepare(slim_rproc->clks[clk]);
> +}
> +
> +static int slim_clk_enable(struct st_slim_rproc *slim_rproc)
> +{
> +	int clk, ret;
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++) {
> +		ret = clk_prepare_enable(slim_rproc->clks[clk]);
> +		if (ret)
> +			goto err_disable_clks;
> +	}
> +
> +	return 0;
> +
> +err_disable_clks:
> +	while (--clk >= 0)
> +		clk_disable_unprepare(slim_rproc->clks[clk]);
> +
> +	return ret;
> +}
> +
> +/*
> + * Remoteproc slim specific device handlers
> + */
> +static int slim_rproc_start(struct rproc *rproc)
> +{
> +	struct device *dev = &rproc->dev;
> +	struct st_slim_rproc *slim_rproc = rproc->priv;
> +	unsigned long hw_id, hw_ver, fw_rev;
> +	u32 val;
> +
> +	/* disable CPU pipeline clock & reset CPU pipeline */
> +	val = SLIM_CLK_GATE_DIS | SLIM_CLK_GATE_RESET;
> +	writel(val, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> +
> +	/* disable SLIM core STBus sync */
> +	writel(SLIM_STBUS_SYNC_DIS, slim_rproc->peri + SLIM_STBUS_SYNC_OFST);
> +
> +	/* enable cpu pipeline clock */
> +	writel(!SLIM_CLK_GATE_DIS,
> +		slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> +
> +	/* clear int & cmd mailbox */
> +	writel(~0U, slim_rproc->peri + SLIM_INT_CLR_OFST);
> +	writel(~0U, slim_rproc->peri + SLIM_CMD_CLR_OFST);
> +
> +	/* enable all channels cmd & int */
> +	writel(~0U, slim_rproc->peri + SLIM_INT_MASK_OFST);
> +	writel(~0U, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> +
> +	/* enable cpu */
> +	writel(SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> +
> +	hw_id = readl_relaxed(slim_rproc->slimcore + SLIM_ID_OFST);
> +	hw_ver = readl_relaxed(slim_rproc->slimcore + SLIM_VER_OFST);
> +
> +	fw_rev = readl(slim_rproc->mem[ST_SLIM_DMEM].cpu_addr +
> +			SLIM_REV_ID_OFST);
> +
> +	dev_info(dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
> +		 SLIM_REV_ID_MAJ(fw_rev), SLIM_REV_ID_MIN(fw_rev),
> +		 hw_id, hw_ver);
> +
> +	return 0;
> +}
> +
> +static int slim_rproc_stop(struct rproc *rproc)
> +{
> +	struct st_slim_rproc *slim_rproc = rproc->priv;
> +	u32 val;
> +
> +	/* mask all (cmd & int) channels */
> +	writel(0UL, slim_rproc->peri + SLIM_INT_MASK_OFST);
> +	writel(0UL, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> +
> +	/* disable cpu pipeline clock */
> +	writel(SLIM_CLK_GATE_DIS, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> +
> +	writel(!SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> +
> +	val = readl(slim_rproc->slimcore + SLIM_EN_OFST);
> +	if (val & SLIM_EN_RUN)
> +		dev_warn(&rproc->dev, "Failed to disable SLIM");
> +
> +	dev_dbg(&rproc->dev, "slim stopped\n");
> +
> +	return 0;
> +}
> +
> +static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> +{
> +	struct st_slim_rproc *slim_rproc = rproc->priv;
> +	void *va = NULL;
> +	int i;
> +
> +	for (i = 0; i < ST_SLIM_MEM_MAX; i++) {
> +		if (da != slim_rproc->mem[i].bus_addr)
> +			continue;
> +
> +		if (len <= slim_rproc->mem[i].size) {
> +			/* __force to make sparse happy with type conversion */
> +			va = (__force void *)slim_rproc->mem[i].cpu_addr;
> +			break;
> +		}
> +	}
> +
> +	dev_dbg(&rproc->dev, "da = 0x%llx len = 0x%x va = 0x%p\n", da, len, va);
> +
> +	return va;
> +}
> +
> +static struct rproc_ops slim_rproc_ops = {
> +	.start		= slim_rproc_start,
> +	.stop		= slim_rproc_stop,
> +	.da_to_va       = slim_rproc_da_to_va,
> +};
> +
> +/*
> + * Firmware handler operations: sanity, boot address, load ...
> + */
> +
> +static struct resource_table empty_rsc_tbl = {
> +	.ver = 1,
> +	.num = 0,
> +};
> +
> +static struct resource_table *slim_rproc_find_rsc_table(struct rproc *rproc,
> +					       const struct firmware *fw,
> +					       int *tablesz)
> +{
> +	*tablesz = sizeof(empty_rsc_tbl);
> +	return &empty_rsc_tbl;
> +}
> +
> +static struct rproc_fw_ops slim_rproc_fw_ops = {
> +	.find_rsc_table = slim_rproc_find_rsc_table,
> +};
> +
> +/**
> + * st_slim_rproc_alloc() - allocate and initialise slim rproc
> + * @pdev: Pointer to the platform_device struct
> + * @fw_name: Name of firmware for rproc to use
> + *
> + * Function for allocating and initialising a slim rproc for use by
> + * device drivers whose IP is based around the SLIM core. It
> + * obtains and enables any clocks required by the SLIM core and also
> + * ioremaps the various IO.
> + *
> + * Returns st_slim_rproc pointer or PTR_ERR() on error.
> + */
> +
> +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> +				char *fw_name)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct st_slim_rproc *slim_rproc;
> +	struct device_node *np = dev->of_node;
> +	struct rproc *rproc;
> +	struct resource *res;
> +	int err, i;
> +	const struct rproc_fw_ops *elf_ops;
> +
> +	if (!fw_name)
> +		return ERR_PTR(-EINVAL);
> +
> +	if (!of_device_is_compatible(np, "st,slim-rproc"))
> +		return ERR_PTR(-EINVAL);
> +
> +	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> +			fw_name, sizeof(*slim_rproc));
> +	if (!rproc)
> +		return ERR_PTR(-ENOMEM);
> +
> +	rproc->has_iommu = false;
> +
> +	slim_rproc = rproc->priv;
> +	slim_rproc->rproc = rproc;
> +
> +	elf_ops = rproc->fw_ops;
> +	/* Use some generic elf ops */
> +	slim_rproc_fw_ops.load = elf_ops->load;
> +	slim_rproc_fw_ops.sanity_check = elf_ops->sanity_check;
> +
> +	rproc->fw_ops = &slim_rproc_fw_ops;
> +
> +	/* get imem and dmem */
> +	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
> +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> +						mem_names[i]);
> +
> +		slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
> +		if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
> +			dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
> +			err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
> +			goto err;
> +		}
> +		slim_rproc->mem[i].bus_addr = res->start;
> +		slim_rproc->mem[i].size = resource_size(res);
> +	}
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
> +	slim_rproc->slimcore = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(slim_rproc->slimcore)) {
> +		dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
> +		err = PTR_ERR(slim_rproc->slimcore);
> +		goto err;
> +	}
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
> +	slim_rproc->peri = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(slim_rproc->peri)) {
> +		dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
> +		err = PTR_ERR(slim_rproc->peri);
> +		goto err;
> +	}
> +
> +	err = slim_clk_get(slim_rproc, dev);
> +	if (err)
> +		goto err;
> +
> +	err = slim_clk_enable(slim_rproc);
> +	if (err) {
> +		dev_err(dev, "Failed to enable clocks\n");
> +		goto err_clk_put;
> +	}
> +
> +	/* Register as a remoteproc device */
> +	err = rproc_add(rproc);
> +	if (err) {
> +		dev_err(dev, "registration of slim remoteproc failed\n");
> +		goto err_clk_dis;
> +	}
> +
> +	return slim_rproc;
> +
> +err_clk_dis:
> +	slim_clk_disable(slim_rproc);
> +err_clk_put:
> +	for (i = 0; i < ST_SLIM_MAX_CLK && slim_rproc->clks[i]; i++)
> +		clk_put(slim_rproc->clks[i]);
> +err:
> +	rproc_put(rproc);
> +	return ERR_PTR(err);
> +}
> +EXPORT_SYMBOL(st_slim_rproc_alloc);
> +
> +/**
> +  * st_slim_rproc_put() - put slim rproc resources
> +  * @slim_rproc: Pointer to the st_slim_rproc struct
> +  *
> +  * Function for calling respective _put() functions on slim_rproc resources.
> +  *
> +  */
> +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc)
> +{
> +	int clk;
> +
> +	if (!slim_rproc)
> +		return;
> +
> +	slim_clk_disable(slim_rproc);
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> +		clk_put(slim_rproc->clks[clk]);
> +
> +	rproc_del(slim_rproc->rproc);
> +	rproc_put(slim_rproc->rproc);
> +}
> +EXPORT_SYMBOL(st_slim_rproc_put);
> +
> +MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
> +MODULE_DESCRIPTION("STMicroelectronics SLIM core rproc driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/remoteproc/st_slim_rproc.h b/include/linux/remoteproc/st_slim_rproc.h
> new file mode 100644
> index 0000000..4155556
> --- /dev/null
> +++ b/include/linux/remoteproc/st_slim_rproc.h
> @@ -0,0 +1,58 @@
> +/*
> + * SLIM core rproc driver header
> + *
> + * Copyright (C) 2016 STMicroelectronics
> + *
> + * Author: Peter Griffin <peter.griffin@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#ifndef _ST_REMOTEPROC_SLIM_H
> +#define _ST_REMOTEPROC_SLIM_H
> +
> +#define ST_SLIM_MEM_MAX 2
> +#define ST_SLIM_MAX_CLK 4
> +
> +enum {
> +	ST_SLIM_DMEM,
> +	ST_SLIM_IMEM,
> +};
> +
> +/**
> + * struct st_slim_mem - slim internal memory structure
> + * @cpu_addr: MPU virtual address of the memory region
> + * @bus_addr: Bus address used to access the memory region
> + * @size: Size of the memory region
> + */
> +struct st_slim_mem {
> +	void __iomem *cpu_addr;
> +	phys_addr_t bus_addr;
> +	size_t size;
> +};
> +
> +/**
> + * struct st_slim_rproc - SLIM slim core
> + * @rproc: rproc handle
> + * @mem: slim memory information
> + * @slimcore: slim slimcore regs
> + * @peri: slim peripheral regs
> + * @clks: slim clocks
> + */
> +struct st_slim_rproc {
> +	struct rproc *rproc;
> +	struct st_slim_mem mem[ST_SLIM_MEM_MAX];
> +	void __iomem *slimcore;
> +	void __iomem *peri;
> +
> +	/* st_slim_rproc private */
> +	struct clk *clks[ST_SLIM_MAX_CLK];
> +};
> +
> +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> +					char *fw_name);
> +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc);
> +
> +#endif
> -- 
> 1.9.1
> 

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver
@ 2016-09-13 17:56     ` Bjorn Andersson
  0 siblings, 0 replies; 174+ messages in thread
From: Bjorn Andersson @ 2016-09-13 17:56 UTC (permalink / raw)
  To: Peter Griffin
  Cc: devicetree, kernel, vinod.koul, linux-remoteproc,
	patrice.chotard, dri-devel, linux-kernel, airlied, dmaengine,
	dan.j.williams, virtualization, lee.jones, linux-arm-kernel

On Mon 05 Sep 06:16 PDT 2016, Peter Griffin wrote:

> slim core is used as a basis for many IPs in the STi
> chipsets such as fdma and demux. To avoid duplicating
> the elf loading code in each device driver a slim
> rproc driver has been created.
> 
> This driver is designed to be used by other device drivers
> such as fdma, or demux whose IP is based around a slim core.
> The device driver can call slim_rproc_alloc() to allocate
> a slim rproc and slim_rproc_put() when finished.
> 
> This driver takes care of ioremapping the slim
> registers (dmem, imem, slimcore, peripherals), whose offsets
> and sizes can change between IP's. It also obtains and enables
> any clocks used by the device. This approach avoids having
> a double mapping of the registers as slim_rproc does not register
> its own platform device. It also maps well to device tree
> abstraction as it allows us to have one dt node for the whole
> device.
> 
> All of the generic rproc elf loading code can be reused, and
> we provide start() stop() hooks to start and stop the slim
> core once the firmware has been loaded. This has been tested
> successfully with fdma driver.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>

Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> ---
>  drivers/remoteproc/Kconfig               |   4 +
>  drivers/remoteproc/Makefile              |   1 +
>  drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
>  include/linux/remoteproc/st_slim_rproc.h |  58 +++++
>  4 files changed, 427 insertions(+)
>  create mode 100644 drivers/remoteproc/st_slim_rproc.c
>  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 1a8bf76a..a7bedc6 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -100,4 +100,8 @@ config ST_REMOTEPROC
>  	  processor framework.
>  	  This can be either built-in or a loadable module.
>  
> +config ST_SLIM_REMOTEPROC
> +	tristate
> +	select REMOTEPROC
> +
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 92d3758..db1dae7 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
>  obj-$(CONFIG_QCOM_MDT_LOADER)		+= qcom_mdt_loader.o
>  obj-$(CONFIG_QCOM_Q6V5_PIL)		+= qcom_q6v5_pil.o
>  obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
> +obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
> diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> new file mode 100644
> index 0000000..1484e97
> --- /dev/null
> +++ b/drivers/remoteproc/st_slim_rproc.c
> @@ -0,0 +1,364 @@
> +/*
> + * SLIM core rproc driver
> + *
> + * Copyright (C) 2016 STMicroelectronics
> + *
> + * Author: Peter Griffin <peter.griffin@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/remoteproc.h>
> +#include <linux/remoteproc/st_slim_rproc.h>
> +#include "remoteproc_internal.h"
> +
> +/* SLIM core registers */
> +#define SLIM_ID_OFST		0x0
> +#define SLIM_VER_OFST		0x4
> +
> +#define SLIM_EN_OFST		0x8
> +#define SLIM_EN_RUN			BIT(0)
> +
> +#define SLIM_CLK_GATE_OFST	0xC
> +#define SLIM_CLK_GATE_DIS		BIT(0)
> +#define SLIM_CLK_GATE_RESET		BIT(2)
> +
> +#define SLIM_SLIM_PC_OFST	0x20
> +
> +/* DMEM registers */
> +#define SLIM_REV_ID_OFST	0x0
> +#define SLIM_REV_ID_MIN_MASK		GENMASK(15, 8)
> +#define SLIM_REV_ID_MIN(id)		((id & SLIM_REV_ID_MIN_MASK) >> 8)
> +#define SLIM_REV_ID_MAJ_MASK		GENMASK(23, 16)
> +#define SLIM_REV_ID_MAJ(id)		((id & SLIM_REV_ID_MAJ_MASK) >> 16)
> +
> +
> +/* peripherals registers */
> +#define SLIM_STBUS_SYNC_OFST	0xF88
> +#define SLIM_STBUS_SYNC_DIS		BIT(0)
> +
> +#define SLIM_INT_SET_OFST	0xFD4
> +#define SLIM_INT_CLR_OFST	0xFD8
> +#define SLIM_INT_MASK_OFST	0xFDC
> +
> +#define SLIM_CMD_CLR_OFST	0xFC8
> +#define SLIM_CMD_MASK_OFST	0xFCC
> +
> +static const char *mem_names[ST_SLIM_MEM_MAX] = {
> +	[ST_SLIM_DMEM]	= "dmem",
> +	[ST_SLIM_IMEM]	= "imem",
> +};
> +
> +static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
> +{
> +	int clk, err;
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
> +		slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
> +		if (IS_ERR(slim_rproc->clks[clk])) {
> +			err = PTR_ERR(slim_rproc->clks[clk]);
> +			if (err == -EPROBE_DEFER)
> +				goto err_put_clks;
> +			slim_rproc->clks[clk] = NULL;
> +			break;
> +		}
> +	}
> +
> +	return 0;
> +
> +err_put_clks:
> +	while (--clk >= 0)
> +		clk_put(slim_rproc->clks[clk]);
> +
> +	return err;
> +}
> +
> +static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
> +{
> +	int clk;
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> +		clk_disable_unprepare(slim_rproc->clks[clk]);
> +}
> +
> +static int slim_clk_enable(struct st_slim_rproc *slim_rproc)
> +{
> +	int clk, ret;
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++) {
> +		ret = clk_prepare_enable(slim_rproc->clks[clk]);
> +		if (ret)
> +			goto err_disable_clks;
> +	}
> +
> +	return 0;
> +
> +err_disable_clks:
> +	while (--clk >= 0)
> +		clk_disable_unprepare(slim_rproc->clks[clk]);
> +
> +	return ret;
> +}
> +
> +/*
> + * Remoteproc slim specific device handlers
> + */
> +static int slim_rproc_start(struct rproc *rproc)
> +{
> +	struct device *dev = &rproc->dev;
> +	struct st_slim_rproc *slim_rproc = rproc->priv;
> +	unsigned long hw_id, hw_ver, fw_rev;
> +	u32 val;
> +
> +	/* disable CPU pipeline clock & reset CPU pipeline */
> +	val = SLIM_CLK_GATE_DIS | SLIM_CLK_GATE_RESET;
> +	writel(val, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> +
> +	/* disable SLIM core STBus sync */
> +	writel(SLIM_STBUS_SYNC_DIS, slim_rproc->peri + SLIM_STBUS_SYNC_OFST);
> +
> +	/* enable cpu pipeline clock */
> +	writel(!SLIM_CLK_GATE_DIS,
> +		slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> +
> +	/* clear int & cmd mailbox */
> +	writel(~0U, slim_rproc->peri + SLIM_INT_CLR_OFST);
> +	writel(~0U, slim_rproc->peri + SLIM_CMD_CLR_OFST);
> +
> +	/* enable all channels cmd & int */
> +	writel(~0U, slim_rproc->peri + SLIM_INT_MASK_OFST);
> +	writel(~0U, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> +
> +	/* enable cpu */
> +	writel(SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> +
> +	hw_id = readl_relaxed(slim_rproc->slimcore + SLIM_ID_OFST);
> +	hw_ver = readl_relaxed(slim_rproc->slimcore + SLIM_VER_OFST);
> +
> +	fw_rev = readl(slim_rproc->mem[ST_SLIM_DMEM].cpu_addr +
> +			SLIM_REV_ID_OFST);
> +
> +	dev_info(dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
> +		 SLIM_REV_ID_MAJ(fw_rev), SLIM_REV_ID_MIN(fw_rev),
> +		 hw_id, hw_ver);
> +
> +	return 0;
> +}
> +
> +static int slim_rproc_stop(struct rproc *rproc)
> +{
> +	struct st_slim_rproc *slim_rproc = rproc->priv;
> +	u32 val;
> +
> +	/* mask all (cmd & int) channels */
> +	writel(0UL, slim_rproc->peri + SLIM_INT_MASK_OFST);
> +	writel(0UL, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> +
> +	/* disable cpu pipeline clock */
> +	writel(SLIM_CLK_GATE_DIS, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> +
> +	writel(!SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> +
> +	val = readl(slim_rproc->slimcore + SLIM_EN_OFST);
> +	if (val & SLIM_EN_RUN)
> +		dev_warn(&rproc->dev, "Failed to disable SLIM");
> +
> +	dev_dbg(&rproc->dev, "slim stopped\n");
> +
> +	return 0;
> +}
> +
> +static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> +{
> +	struct st_slim_rproc *slim_rproc = rproc->priv;
> +	void *va = NULL;
> +	int i;
> +
> +	for (i = 0; i < ST_SLIM_MEM_MAX; i++) {
> +		if (da != slim_rproc->mem[i].bus_addr)
> +			continue;
> +
> +		if (len <= slim_rproc->mem[i].size) {
> +			/* __force to make sparse happy with type conversion */
> +			va = (__force void *)slim_rproc->mem[i].cpu_addr;
> +			break;
> +		}
> +	}
> +
> +	dev_dbg(&rproc->dev, "da = 0x%llx len = 0x%x va = 0x%p\n", da, len, va);
> +
> +	return va;
> +}
> +
> +static struct rproc_ops slim_rproc_ops = {
> +	.start		= slim_rproc_start,
> +	.stop		= slim_rproc_stop,
> +	.da_to_va       = slim_rproc_da_to_va,
> +};
> +
> +/*
> + * Firmware handler operations: sanity, boot address, load ...
> + */
> +
> +static struct resource_table empty_rsc_tbl = {
> +	.ver = 1,
> +	.num = 0,
> +};
> +
> +static struct resource_table *slim_rproc_find_rsc_table(struct rproc *rproc,
> +					       const struct firmware *fw,
> +					       int *tablesz)
> +{
> +	*tablesz = sizeof(empty_rsc_tbl);
> +	return &empty_rsc_tbl;
> +}
> +
> +static struct rproc_fw_ops slim_rproc_fw_ops = {
> +	.find_rsc_table = slim_rproc_find_rsc_table,
> +};
> +
> +/**
> + * st_slim_rproc_alloc() - allocate and initialise slim rproc
> + * @pdev: Pointer to the platform_device struct
> + * @fw_name: Name of firmware for rproc to use
> + *
> + * Function for allocating and initialising a slim rproc for use by
> + * device drivers whose IP is based around the SLIM core. It
> + * obtains and enables any clocks required by the SLIM core and also
> + * ioremaps the various IO.
> + *
> + * Returns st_slim_rproc pointer or PTR_ERR() on error.
> + */
> +
> +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> +				char *fw_name)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct st_slim_rproc *slim_rproc;
> +	struct device_node *np = dev->of_node;
> +	struct rproc *rproc;
> +	struct resource *res;
> +	int err, i;
> +	const struct rproc_fw_ops *elf_ops;
> +
> +	if (!fw_name)
> +		return ERR_PTR(-EINVAL);
> +
> +	if (!of_device_is_compatible(np, "st,slim-rproc"))
> +		return ERR_PTR(-EINVAL);
> +
> +	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> +			fw_name, sizeof(*slim_rproc));
> +	if (!rproc)
> +		return ERR_PTR(-ENOMEM);
> +
> +	rproc->has_iommu = false;
> +
> +	slim_rproc = rproc->priv;
> +	slim_rproc->rproc = rproc;
> +
> +	elf_ops = rproc->fw_ops;
> +	/* Use some generic elf ops */
> +	slim_rproc_fw_ops.load = elf_ops->load;
> +	slim_rproc_fw_ops.sanity_check = elf_ops->sanity_check;
> +
> +	rproc->fw_ops = &slim_rproc_fw_ops;
> +
> +	/* get imem and dmem */
> +	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
> +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> +						mem_names[i]);
> +
> +		slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
> +		if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
> +			dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
> +			err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
> +			goto err;
> +		}
> +		slim_rproc->mem[i].bus_addr = res->start;
> +		slim_rproc->mem[i].size = resource_size(res);
> +	}
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
> +	slim_rproc->slimcore = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(slim_rproc->slimcore)) {
> +		dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
> +		err = PTR_ERR(slim_rproc->slimcore);
> +		goto err;
> +	}
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
> +	slim_rproc->peri = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(slim_rproc->peri)) {
> +		dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
> +		err = PTR_ERR(slim_rproc->peri);
> +		goto err;
> +	}
> +
> +	err = slim_clk_get(slim_rproc, dev);
> +	if (err)
> +		goto err;
> +
> +	err = slim_clk_enable(slim_rproc);
> +	if (err) {
> +		dev_err(dev, "Failed to enable clocks\n");
> +		goto err_clk_put;
> +	}
> +
> +	/* Register as a remoteproc device */
> +	err = rproc_add(rproc);
> +	if (err) {
> +		dev_err(dev, "registration of slim remoteproc failed\n");
> +		goto err_clk_dis;
> +	}
> +
> +	return slim_rproc;
> +
> +err_clk_dis:
> +	slim_clk_disable(slim_rproc);
> +err_clk_put:
> +	for (i = 0; i < ST_SLIM_MAX_CLK && slim_rproc->clks[i]; i++)
> +		clk_put(slim_rproc->clks[i]);
> +err:
> +	rproc_put(rproc);
> +	return ERR_PTR(err);
> +}
> +EXPORT_SYMBOL(st_slim_rproc_alloc);
> +
> +/**
> +  * st_slim_rproc_put() - put slim rproc resources
> +  * @slim_rproc: Pointer to the st_slim_rproc struct
> +  *
> +  * Function for calling respective _put() functions on slim_rproc resources.
> +  *
> +  */
> +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc)
> +{
> +	int clk;
> +
> +	if (!slim_rproc)
> +		return;
> +
> +	slim_clk_disable(slim_rproc);
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> +		clk_put(slim_rproc->clks[clk]);
> +
> +	rproc_del(slim_rproc->rproc);
> +	rproc_put(slim_rproc->rproc);
> +}
> +EXPORT_SYMBOL(st_slim_rproc_put);
> +
> +MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
> +MODULE_DESCRIPTION("STMicroelectronics SLIM core rproc driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/remoteproc/st_slim_rproc.h b/include/linux/remoteproc/st_slim_rproc.h
> new file mode 100644
> index 0000000..4155556
> --- /dev/null
> +++ b/include/linux/remoteproc/st_slim_rproc.h
> @@ -0,0 +1,58 @@
> +/*
> + * SLIM core rproc driver header
> + *
> + * Copyright (C) 2016 STMicroelectronics
> + *
> + * Author: Peter Griffin <peter.griffin@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#ifndef _ST_REMOTEPROC_SLIM_H
> +#define _ST_REMOTEPROC_SLIM_H
> +
> +#define ST_SLIM_MEM_MAX 2
> +#define ST_SLIM_MAX_CLK 4
> +
> +enum {
> +	ST_SLIM_DMEM,
> +	ST_SLIM_IMEM,
> +};
> +
> +/**
> + * struct st_slim_mem - slim internal memory structure
> + * @cpu_addr: MPU virtual address of the memory region
> + * @bus_addr: Bus address used to access the memory region
> + * @size: Size of the memory region
> + */
> +struct st_slim_mem {
> +	void __iomem *cpu_addr;
> +	phys_addr_t bus_addr;
> +	size_t size;
> +};
> +
> +/**
> + * struct st_slim_rproc - SLIM slim core
> + * @rproc: rproc handle
> + * @mem: slim memory information
> + * @slimcore: slim slimcore regs
> + * @peri: slim peripheral regs
> + * @clks: slim clocks
> + */
> +struct st_slim_rproc {
> +	struct rproc *rproc;
> +	struct st_slim_mem mem[ST_SLIM_MEM_MAX];
> +	void __iomem *slimcore;
> +	void __iomem *peri;
> +
> +	/* st_slim_rproc private */
> +	struct clk *clks[ST_SLIM_MAX_CLK];
> +};
> +
> +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> +					char *fw_name);
> +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc);
> +
> +#endif
> -- 
> 1.9.1
> 

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver
@ 2016-09-13 17:56     ` Bjorn Andersson
  0 siblings, 0 replies; 174+ messages in thread
From: Bjorn Andersson @ 2016-09-13 17:56 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon 05 Sep 06:16 PDT 2016, Peter Griffin wrote:

> slim core is used as a basis for many IPs in the STi
> chipsets such as fdma and demux. To avoid duplicating
> the elf loading code in each device driver a slim
> rproc driver has been created.
> 
> This driver is designed to be used by other device drivers
> such as fdma, or demux whose IP is based around a slim core.
> The device driver can call slim_rproc_alloc() to allocate
> a slim rproc and slim_rproc_put() when finished.
> 
> This driver takes care of ioremapping the slim
> registers (dmem, imem, slimcore, peripherals), whose offsets
> and sizes can change between IP's. It also obtains and enables
> any clocks used by the device. This approach avoids having
> a double mapping of the registers as slim_rproc does not register
> its own platform device. It also maps well to device tree
> abstraction as it allows us to have one dt node for the whole
> device.
> 
> All of the generic rproc elf loading code can be reused, and
> we provide start() stop() hooks to start and stop the slim
> core once the firmware has been loaded. This has been tested
> successfully with fdma driver.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>

Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> ---
>  drivers/remoteproc/Kconfig               |   4 +
>  drivers/remoteproc/Makefile              |   1 +
>  drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
>  include/linux/remoteproc/st_slim_rproc.h |  58 +++++
>  4 files changed, 427 insertions(+)
>  create mode 100644 drivers/remoteproc/st_slim_rproc.c
>  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 1a8bf76a..a7bedc6 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -100,4 +100,8 @@ config ST_REMOTEPROC
>  	  processor framework.
>  	  This can be either built-in or a loadable module.
>  
> +config ST_SLIM_REMOTEPROC
> +	tristate
> +	select REMOTEPROC
> +
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 92d3758..db1dae7 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
>  obj-$(CONFIG_QCOM_MDT_LOADER)		+= qcom_mdt_loader.o
>  obj-$(CONFIG_QCOM_Q6V5_PIL)		+= qcom_q6v5_pil.o
>  obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
> +obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
> diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> new file mode 100644
> index 0000000..1484e97
> --- /dev/null
> +++ b/drivers/remoteproc/st_slim_rproc.c
> @@ -0,0 +1,364 @@
> +/*
> + * SLIM core rproc driver
> + *
> + * Copyright (C) 2016 STMicroelectronics
> + *
> + * Author: Peter Griffin <peter.griffin@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/remoteproc.h>
> +#include <linux/remoteproc/st_slim_rproc.h>
> +#include "remoteproc_internal.h"
> +
> +/* SLIM core registers */
> +#define SLIM_ID_OFST		0x0
> +#define SLIM_VER_OFST		0x4
> +
> +#define SLIM_EN_OFST		0x8
> +#define SLIM_EN_RUN			BIT(0)
> +
> +#define SLIM_CLK_GATE_OFST	0xC
> +#define SLIM_CLK_GATE_DIS		BIT(0)
> +#define SLIM_CLK_GATE_RESET		BIT(2)
> +
> +#define SLIM_SLIM_PC_OFST	0x20
> +
> +/* DMEM registers */
> +#define SLIM_REV_ID_OFST	0x0
> +#define SLIM_REV_ID_MIN_MASK		GENMASK(15, 8)
> +#define SLIM_REV_ID_MIN(id)		((id & SLIM_REV_ID_MIN_MASK) >> 8)
> +#define SLIM_REV_ID_MAJ_MASK		GENMASK(23, 16)
> +#define SLIM_REV_ID_MAJ(id)		((id & SLIM_REV_ID_MAJ_MASK) >> 16)
> +
> +
> +/* peripherals registers */
> +#define SLIM_STBUS_SYNC_OFST	0xF88
> +#define SLIM_STBUS_SYNC_DIS		BIT(0)
> +
> +#define SLIM_INT_SET_OFST	0xFD4
> +#define SLIM_INT_CLR_OFST	0xFD8
> +#define SLIM_INT_MASK_OFST	0xFDC
> +
> +#define SLIM_CMD_CLR_OFST	0xFC8
> +#define SLIM_CMD_MASK_OFST	0xFCC
> +
> +static const char *mem_names[ST_SLIM_MEM_MAX] = {
> +	[ST_SLIM_DMEM]	= "dmem",
> +	[ST_SLIM_IMEM]	= "imem",
> +};
> +
> +static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
> +{
> +	int clk, err;
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
> +		slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
> +		if (IS_ERR(slim_rproc->clks[clk])) {
> +			err = PTR_ERR(slim_rproc->clks[clk]);
> +			if (err == -EPROBE_DEFER)
> +				goto err_put_clks;
> +			slim_rproc->clks[clk] = NULL;
> +			break;
> +		}
> +	}
> +
> +	return 0;
> +
> +err_put_clks:
> +	while (--clk >= 0)
> +		clk_put(slim_rproc->clks[clk]);
> +
> +	return err;
> +}
> +
> +static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
> +{
> +	int clk;
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> +		clk_disable_unprepare(slim_rproc->clks[clk]);
> +}
> +
> +static int slim_clk_enable(struct st_slim_rproc *slim_rproc)
> +{
> +	int clk, ret;
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++) {
> +		ret = clk_prepare_enable(slim_rproc->clks[clk]);
> +		if (ret)
> +			goto err_disable_clks;
> +	}
> +
> +	return 0;
> +
> +err_disable_clks:
> +	while (--clk >= 0)
> +		clk_disable_unprepare(slim_rproc->clks[clk]);
> +
> +	return ret;
> +}
> +
> +/*
> + * Remoteproc slim specific device handlers
> + */
> +static int slim_rproc_start(struct rproc *rproc)
> +{
> +	struct device *dev = &rproc->dev;
> +	struct st_slim_rproc *slim_rproc = rproc->priv;
> +	unsigned long hw_id, hw_ver, fw_rev;
> +	u32 val;
> +
> +	/* disable CPU pipeline clock & reset CPU pipeline */
> +	val = SLIM_CLK_GATE_DIS | SLIM_CLK_GATE_RESET;
> +	writel(val, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> +
> +	/* disable SLIM core STBus sync */
> +	writel(SLIM_STBUS_SYNC_DIS, slim_rproc->peri + SLIM_STBUS_SYNC_OFST);
> +
> +	/* enable cpu pipeline clock */
> +	writel(!SLIM_CLK_GATE_DIS,
> +		slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> +
> +	/* clear int & cmd mailbox */
> +	writel(~0U, slim_rproc->peri + SLIM_INT_CLR_OFST);
> +	writel(~0U, slim_rproc->peri + SLIM_CMD_CLR_OFST);
> +
> +	/* enable all channels cmd & int */
> +	writel(~0U, slim_rproc->peri + SLIM_INT_MASK_OFST);
> +	writel(~0U, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> +
> +	/* enable cpu */
> +	writel(SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> +
> +	hw_id = readl_relaxed(slim_rproc->slimcore + SLIM_ID_OFST);
> +	hw_ver = readl_relaxed(slim_rproc->slimcore + SLIM_VER_OFST);
> +
> +	fw_rev = readl(slim_rproc->mem[ST_SLIM_DMEM].cpu_addr +
> +			SLIM_REV_ID_OFST);
> +
> +	dev_info(dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
> +		 SLIM_REV_ID_MAJ(fw_rev), SLIM_REV_ID_MIN(fw_rev),
> +		 hw_id, hw_ver);
> +
> +	return 0;
> +}
> +
> +static int slim_rproc_stop(struct rproc *rproc)
> +{
> +	struct st_slim_rproc *slim_rproc = rproc->priv;
> +	u32 val;
> +
> +	/* mask all (cmd & int) channels */
> +	writel(0UL, slim_rproc->peri + SLIM_INT_MASK_OFST);
> +	writel(0UL, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> +
> +	/* disable cpu pipeline clock */
> +	writel(SLIM_CLK_GATE_DIS, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> +
> +	writel(!SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> +
> +	val = readl(slim_rproc->slimcore + SLIM_EN_OFST);
> +	if (val & SLIM_EN_RUN)
> +		dev_warn(&rproc->dev, "Failed to disable SLIM");
> +
> +	dev_dbg(&rproc->dev, "slim stopped\n");
> +
> +	return 0;
> +}
> +
> +static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> +{
> +	struct st_slim_rproc *slim_rproc = rproc->priv;
> +	void *va = NULL;
> +	int i;
> +
> +	for (i = 0; i < ST_SLIM_MEM_MAX; i++) {
> +		if (da != slim_rproc->mem[i].bus_addr)
> +			continue;
> +
> +		if (len <= slim_rproc->mem[i].size) {
> +			/* __force to make sparse happy with type conversion */
> +			va = (__force void *)slim_rproc->mem[i].cpu_addr;
> +			break;
> +		}
> +	}
> +
> +	dev_dbg(&rproc->dev, "da = 0x%llx len = 0x%x va = 0x%p\n", da, len, va);
> +
> +	return va;
> +}
> +
> +static struct rproc_ops slim_rproc_ops = {
> +	.start		= slim_rproc_start,
> +	.stop		= slim_rproc_stop,
> +	.da_to_va       = slim_rproc_da_to_va,
> +};
> +
> +/*
> + * Firmware handler operations: sanity, boot address, load ...
> + */
> +
> +static struct resource_table empty_rsc_tbl = {
> +	.ver = 1,
> +	.num = 0,
> +};
> +
> +static struct resource_table *slim_rproc_find_rsc_table(struct rproc *rproc,
> +					       const struct firmware *fw,
> +					       int *tablesz)
> +{
> +	*tablesz = sizeof(empty_rsc_tbl);
> +	return &empty_rsc_tbl;
> +}
> +
> +static struct rproc_fw_ops slim_rproc_fw_ops = {
> +	.find_rsc_table = slim_rproc_find_rsc_table,
> +};
> +
> +/**
> + * st_slim_rproc_alloc() - allocate and initialise slim rproc
> + * @pdev: Pointer to the platform_device struct
> + * @fw_name: Name of firmware for rproc to use
> + *
> + * Function for allocating and initialising a slim rproc for use by
> + * device drivers whose IP is based around the SLIM core. It
> + * obtains and enables any clocks required by the SLIM core and also
> + * ioremaps the various IO.
> + *
> + * Returns st_slim_rproc pointer or PTR_ERR() on error.
> + */
> +
> +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> +				char *fw_name)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct st_slim_rproc *slim_rproc;
> +	struct device_node *np = dev->of_node;
> +	struct rproc *rproc;
> +	struct resource *res;
> +	int err, i;
> +	const struct rproc_fw_ops *elf_ops;
> +
> +	if (!fw_name)
> +		return ERR_PTR(-EINVAL);
> +
> +	if (!of_device_is_compatible(np, "st,slim-rproc"))
> +		return ERR_PTR(-EINVAL);
> +
> +	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> +			fw_name, sizeof(*slim_rproc));
> +	if (!rproc)
> +		return ERR_PTR(-ENOMEM);
> +
> +	rproc->has_iommu = false;
> +
> +	slim_rproc = rproc->priv;
> +	slim_rproc->rproc = rproc;
> +
> +	elf_ops = rproc->fw_ops;
> +	/* Use some generic elf ops */
> +	slim_rproc_fw_ops.load = elf_ops->load;
> +	slim_rproc_fw_ops.sanity_check = elf_ops->sanity_check;
> +
> +	rproc->fw_ops = &slim_rproc_fw_ops;
> +
> +	/* get imem and dmem */
> +	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
> +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> +						mem_names[i]);
> +
> +		slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
> +		if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
> +			dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
> +			err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
> +			goto err;
> +		}
> +		slim_rproc->mem[i].bus_addr = res->start;
> +		slim_rproc->mem[i].size = resource_size(res);
> +	}
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
> +	slim_rproc->slimcore = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(slim_rproc->slimcore)) {
> +		dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
> +		err = PTR_ERR(slim_rproc->slimcore);
> +		goto err;
> +	}
> +
> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
> +	slim_rproc->peri = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(slim_rproc->peri)) {
> +		dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
> +		err = PTR_ERR(slim_rproc->peri);
> +		goto err;
> +	}
> +
> +	err = slim_clk_get(slim_rproc, dev);
> +	if (err)
> +		goto err;
> +
> +	err = slim_clk_enable(slim_rproc);
> +	if (err) {
> +		dev_err(dev, "Failed to enable clocks\n");
> +		goto err_clk_put;
> +	}
> +
> +	/* Register as a remoteproc device */
> +	err = rproc_add(rproc);
> +	if (err) {
> +		dev_err(dev, "registration of slim remoteproc failed\n");
> +		goto err_clk_dis;
> +	}
> +
> +	return slim_rproc;
> +
> +err_clk_dis:
> +	slim_clk_disable(slim_rproc);
> +err_clk_put:
> +	for (i = 0; i < ST_SLIM_MAX_CLK && slim_rproc->clks[i]; i++)
> +		clk_put(slim_rproc->clks[i]);
> +err:
> +	rproc_put(rproc);
> +	return ERR_PTR(err);
> +}
> +EXPORT_SYMBOL(st_slim_rproc_alloc);
> +
> +/**
> +  * st_slim_rproc_put() - put slim rproc resources
> +  * @slim_rproc: Pointer to the st_slim_rproc struct
> +  *
> +  * Function for calling respective _put() functions on slim_rproc resources.
> +  *
> +  */
> +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc)
> +{
> +	int clk;
> +
> +	if (!slim_rproc)
> +		return;
> +
> +	slim_clk_disable(slim_rproc);
> +
> +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> +		clk_put(slim_rproc->clks[clk]);
> +
> +	rproc_del(slim_rproc->rproc);
> +	rproc_put(slim_rproc->rproc);
> +}
> +EXPORT_SYMBOL(st_slim_rproc_put);
> +
> +MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
> +MODULE_DESCRIPTION("STMicroelectronics SLIM core rproc driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/remoteproc/st_slim_rproc.h b/include/linux/remoteproc/st_slim_rproc.h
> new file mode 100644
> index 0000000..4155556
> --- /dev/null
> +++ b/include/linux/remoteproc/st_slim_rproc.h
> @@ -0,0 +1,58 @@
> +/*
> + * SLIM core rproc driver header
> + *
> + * Copyright (C) 2016 STMicroelectronics
> + *
> + * Author: Peter Griffin <peter.griffin@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#ifndef _ST_REMOTEPROC_SLIM_H
> +#define _ST_REMOTEPROC_SLIM_H
> +
> +#define ST_SLIM_MEM_MAX 2
> +#define ST_SLIM_MAX_CLK 4
> +
> +enum {
> +	ST_SLIM_DMEM,
> +	ST_SLIM_IMEM,
> +};
> +
> +/**
> + * struct st_slim_mem - slim internal memory structure
> + * @cpu_addr: MPU virtual address of the memory region
> + * @bus_addr: Bus address used to access the memory region
> + * @size: Size of the memory region
> + */
> +struct st_slim_mem {
> +	void __iomem *cpu_addr;
> +	phys_addr_t bus_addr;
> +	size_t size;
> +};
> +
> +/**
> + * struct st_slim_rproc - SLIM slim core
> + * @rproc: rproc handle
> + * @mem: slim memory information
> + * @slimcore: slim slimcore regs
> + * @peri: slim peripheral regs
> + * @clks: slim clocks
> + */
> +struct st_slim_rproc {
> +	struct rproc *rproc;
> +	struct st_slim_mem mem[ST_SLIM_MEM_MAX];
> +	void __iomem *slimcore;
> +	void __iomem *peri;
> +
> +	/* st_slim_rproc private */
> +	struct clk *clks[ST_SLIM_MAX_CLK];
> +};
> +
> +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> +					char *fw_name);
> +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc);
> +
> +#endif
> -- 
> 1.9.1
> 

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
  2016-09-13  9:31   ` Peter Griffin
  (?)
@ 2016-09-13 18:06     ` Bjorn Andersson
  -1 siblings, 0 replies; 174+ messages in thread
From: Bjorn Andersson @ 2016-09-13 18:06 UTC (permalink / raw)
  To: Peter Griffin, vinod.koul
  Cc: linux-arm-kernel, linux-kernel, kernel, patrice.chotard,
	dan.j.williams, airlied, kraxel, ohad, lee.jones, dmaengine,
	devicetree, dri-devel, linux-remoteproc, virtualization

On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:

> Hi Vinod & Bjorn,
> 
> [..]
> 
> On Mon, 05 Sep 2016, Peter Griffin wrote:
> 
> > v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
> > a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
> > slim_rproc driver. The series has also been rebased on v4.8-rc3.
> > 
> > v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
> > was found during testing now that the platform boots without clk_ignore_unused parameter
> > whereby the clocks would not be enabled properly before firmware loading was attempted.
> > 
> > regards,
> > 
> > Peter.
> > 
> > Changes since v8:
> >  - Add MODULE_ALIAS (Vinod)
> >  - devm_kzalloc to devm_kcalloc (Vinod)
> >  - quisce tasklet initialised by vchan_init() (Vinod)
> >  - Don't make SLIM rproc user selectable (Bjorn)
> >  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
> >  - Various code style nits / commit message change (Lee)
> >  - Separate patch for '\n' kconfig removal (Vinod)
> 
> I hate to send a ping,

Sorry about that.

> but do you think we can merge this fdma series? It has gone
> through quite a few review rounds now.
> 

I think the remoteproc part looks good.

Vinod, I don't have any changes queued in remoteproc that should cause
merge issues. If you want to you could take the remoteproc patch
through your tree.


I do however think that the dts patches should go through arm-soc.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-13 18:06     ` Bjorn Andersson
  0 siblings, 0 replies; 174+ messages in thread
From: Bjorn Andersson @ 2016-09-13 18:06 UTC (permalink / raw)
  To: Peter Griffin, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ, patrice.chotard-qxv4g6HH51o,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, airlied-cv59FeDIM0c,
	kraxel-H+wXaHxf7aLQT0dZR+AlfA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA

On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:

> Hi Vinod & Bjorn,
> 
> [..]
> 
> On Mon, 05 Sep 2016, Peter Griffin wrote:
> 
> > v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
> > a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
> > slim_rproc driver. The series has also been rebased on v4.8-rc3.
> > 
> > v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
> > was found during testing now that the platform boots without clk_ignore_unused parameter
> > whereby the clocks would not be enabled properly before firmware loading was attempted.
> > 
> > regards,
> > 
> > Peter.
> > 
> > Changes since v8:
> >  - Add MODULE_ALIAS (Vinod)
> >  - devm_kzalloc to devm_kcalloc (Vinod)
> >  - quisce tasklet initialised by vchan_init() (Vinod)
> >  - Don't make SLIM rproc user selectable (Bjorn)
> >  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
> >  - Various code style nits / commit message change (Lee)
> >  - Separate patch for '\n' kconfig removal (Vinod)
> 
> I hate to send a ping,

Sorry about that.

> but do you think we can merge this fdma series? It has gone
> through quite a few review rounds now.
> 

I think the remoteproc part looks good.

Vinod, I don't have any changes queued in remoteproc that should cause
merge issues. If you want to you could take the remoteproc patch
through your tree.


I do however think that the dts patches should go through arm-soc.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
  2016-09-13  9:31   ` Peter Griffin
  (?)
  (?)
@ 2016-09-13 18:06   ` Bjorn Andersson
  -1 siblings, 0 replies; 174+ messages in thread
From: Bjorn Andersson @ 2016-09-13 18:06 UTC (permalink / raw)
  To: Peter Griffin, vinod.koul
  Cc: devicetree, kernel, airlied, linux-remoteproc, patrice.chotard,
	dri-devel, linux-kernel, dmaengine, dan.j.williams,
	virtualization, lee.jones, linux-arm-kernel

On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:

> Hi Vinod & Bjorn,
> 
> [..]
> 
> On Mon, 05 Sep 2016, Peter Griffin wrote:
> 
> > v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
> > a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
> > slim_rproc driver. The series has also been rebased on v4.8-rc3.
> > 
> > v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
> > was found during testing now that the platform boots without clk_ignore_unused parameter
> > whereby the clocks would not be enabled properly before firmware loading was attempted.
> > 
> > regards,
> > 
> > Peter.
> > 
> > Changes since v8:
> >  - Add MODULE_ALIAS (Vinod)
> >  - devm_kzalloc to devm_kcalloc (Vinod)
> >  - quisce tasklet initialised by vchan_init() (Vinod)
> >  - Don't make SLIM rproc user selectable (Bjorn)
> >  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
> >  - Various code style nits / commit message change (Lee)
> >  - Separate patch for '\n' kconfig removal (Vinod)
> 
> I hate to send a ping,

Sorry about that.

> but do you think we can merge this fdma series? It has gone
> through quite a few review rounds now.
> 

I think the remoteproc part looks good.

Vinod, I don't have any changes queued in remoteproc that should cause
merge issues. If you want to you could take the remoteproc patch
through your tree.


I do however think that the dts patches should go through arm-soc.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-13 18:06     ` Bjorn Andersson
  0 siblings, 0 replies; 174+ messages in thread
From: Bjorn Andersson @ 2016-09-13 18:06 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:

> Hi Vinod & Bjorn,
> 
> [..]
> 
> On Mon, 05 Sep 2016, Peter Griffin wrote:
> 
> > v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
> > a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
> > slim_rproc driver. The series has also been rebased on v4.8-rc3.
> > 
> > v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
> > was found during testing now that the platform boots without clk_ignore_unused parameter
> > whereby the clocks would not be enabled properly before firmware loading was attempted.
> > 
> > regards,
> > 
> > Peter.
> > 
> > Changes since v8:
> >  - Add MODULE_ALIAS (Vinod)
> >  - devm_kzalloc to devm_kcalloc (Vinod)
> >  - quisce tasklet initialised by vchan_init() (Vinod)
> >  - Don't make SLIM rproc user selectable (Bjorn)
> >  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
> >  - Various code style nits / commit message change (Lee)
> >  - Separate patch for '\n' kconfig removal (Vinod)
> 
> I hate to send a ping,

Sorry about that.

> but do you think we can merge this fdma series? It has gone
> through quite a few review rounds now.
> 

I think the remoteproc part looks good.

Vinod, I don't have any changes queued in remoteproc that should cause
merge issues. If you want to you could take the remoteproc patch
through your tree.


I do however think that the dts patches should go through arm-soc.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
  2016-09-13 18:06     ` Bjorn Andersson
  (?)
  (?)
@ 2016-09-14  6:59       ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14  6:59 UTC (permalink / raw)
  To: Bjorn Andersson, Peter Griffin, vinod.koul
  Cc: linux-arm-kernel, linux-kernel, kernel, dan.j.williams, airlied,
	kraxel, ohad, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization

Hi Bjorn

On 09/13/2016 08:06 PM, Bjorn Andersson wrote:
> On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:
> 
>> Hi Vinod & Bjorn,
>>
>> [..]
>>
>> On Mon, 05 Sep 2016, Peter Griffin wrote:
>>
>>> v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
>>> a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
>>> slim_rproc driver. The series has also been rebased on v4.8-rc3.
>>>
>>> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
>>> was found during testing now that the platform boots without clk_ignore_unused parameter
>>> whereby the clocks would not be enabled properly before firmware loading was attempted.
>>>
>>> regards,
>>>
>>> Peter.
>>>
>>> Changes since v8:
>>>  - Add MODULE_ALIAS (Vinod)
>>>  - devm_kzalloc to devm_kcalloc (Vinod)
>>>  - quisce tasklet initialised by vchan_init() (Vinod)
>>>  - Don't make SLIM rproc user selectable (Bjorn)
>>>  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
>>>  - Various code style nits / commit message change (Lee)
>>>  - Separate patch for '\n' kconfig removal (Vinod)
>>
>> I hate to send a ping,
> 
> Sorry about that.
> 
>> but do you think we can merge this fdma series? It has gone
>> through quite a few review rounds now.
>>
> 
> I think the remoteproc part looks good.
> 
> Vinod, I don't have any changes queued in remoteproc that should cause
> merge issues. If you want to you could take the remoteproc patch
> through your tree.
> 
> 
> I do however think that the dts patches should go through arm-soc.

I will take care about dts patches by adding them in the next STi DT pull request

Thanks
Patrice

> 
> Regards,
> Bjorn
> 

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-14  6:59       ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14  6:59 UTC (permalink / raw)
  To: Bjorn Andersson, Peter Griffin, vinod.koul
  Cc: linux-arm-kernel, linux-kernel, kernel, dan.j.williams, airlied,
	kraxel, ohad, lee.jones, dmaengine, devicetree, dri-devel,
	linux-remoteproc, virtualization

Hi Bjorn

On 09/13/2016 08:06 PM, Bjorn Andersson wrote:
> On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:
> 
>> Hi Vinod & Bjorn,
>>
>> [..]
>>
>> On Mon, 05 Sep 2016, Peter Griffin wrote:
>>
>>> v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
>>> a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
>>> slim_rproc driver. The series has also been rebased on v4.8-rc3.
>>>
>>> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
>>> was found during testing now that the platform boots without clk_ignore_unused parameter
>>> whereby the clocks would not be enabled properly before firmware loading was attempted.
>>>
>>> regards,
>>>
>>> Peter.
>>>
>>> Changes since v8:
>>>  - Add MODULE_ALIAS (Vinod)
>>>  - devm_kzalloc to devm_kcalloc (Vinod)
>>>  - quisce tasklet initialised by vchan_init() (Vinod)
>>>  - Don't make SLIM rproc user selectable (Bjorn)
>>>  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
>>>  - Various code style nits / commit message change (Lee)
>>>  - Separate patch for '\n' kconfig removal (Vinod)
>>
>> I hate to send a ping,
> 
> Sorry about that.
> 
>> but do you think we can merge this fdma series? It has gone
>> through quite a few review rounds now.
>>
> 
> I think the remoteproc part looks good.
> 
> Vinod, I don't have any changes queued in remoteproc that should cause
> merge issues. If you want to you could take the remoteproc patch
> through your tree.
> 
> 
> I do however think that the dts patches should go through arm-soc.

I will take care about dts patches by adding them in the next STi DT pull request

Thanks
Patrice

> 
> Regards,
> Bjorn
> 

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-14  6:59       ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14  6:59 UTC (permalink / raw)
  To: Bjorn Andersson, Peter Griffin, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, airlied-cv59FeDIM0c,
	kraxel-H+wXaHxf7aLQT0dZR+AlfA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA

Hi Bjorn

On 09/13/2016 08:06 PM, Bjorn Andersson wrote:
> On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:
> 
>> Hi Vinod & Bjorn,
>>
>> [..]
>>
>> On Mon, 05 Sep 2016, Peter Griffin wrote:
>>
>>> v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
>>> a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
>>> slim_rproc driver. The series has also been rebased on v4.8-rc3.
>>>
>>> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
>>> was found during testing now that the platform boots without clk_ignore_unused parameter
>>> whereby the clocks would not be enabled properly before firmware loading was attempted.
>>>
>>> regards,
>>>
>>> Peter.
>>>
>>> Changes since v8:
>>>  - Add MODULE_ALIAS (Vinod)
>>>  - devm_kzalloc to devm_kcalloc (Vinod)
>>>  - quisce tasklet initialised by vchan_init() (Vinod)
>>>  - Don't make SLIM rproc user selectable (Bjorn)
>>>  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
>>>  - Various code style nits / commit message change (Lee)
>>>  - Separate patch for '\n' kconfig removal (Vinod)
>>
>> I hate to send a ping,
> 
> Sorry about that.
> 
>> but do you think we can merge this fdma series? It has gone
>> through quite a few review rounds now.
>>
> 
> I think the remoteproc part looks good.
> 
> Vinod, I don't have any changes queued in remoteproc that should cause
> merge issues. If you want to you could take the remoteproc patch
> through your tree.
> 
> 
> I do however think that the dts patches should go through arm-soc.

I will take care about dts patches by adding them in the next STi DT pull request

Thanks
Patrice

> 
> Regards,
> Bjorn
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
  2016-09-13 18:06     ` Bjorn Andersson
                       ` (2 preceding siblings ...)
  (?)
@ 2016-09-14  6:59     ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14  6:59 UTC (permalink / raw)
  To: Bjorn Andersson, Peter Griffin, vinod.koul
  Cc: devicetree, kernel, airlied, linux-remoteproc, linux-kernel,
	dri-devel, virtualization, dmaengine, dan.j.williams, lee.jones,
	linux-arm-kernel

Hi Bjorn

On 09/13/2016 08:06 PM, Bjorn Andersson wrote:
> On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:
> 
>> Hi Vinod & Bjorn,
>>
>> [..]
>>
>> On Mon, 05 Sep 2016, Peter Griffin wrote:
>>
>>> v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
>>> a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
>>> slim_rproc driver. The series has also been rebased on v4.8-rc3.
>>>
>>> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
>>> was found during testing now that the platform boots without clk_ignore_unused parameter
>>> whereby the clocks would not be enabled properly before firmware loading was attempted.
>>>
>>> regards,
>>>
>>> Peter.
>>>
>>> Changes since v8:
>>>  - Add MODULE_ALIAS (Vinod)
>>>  - devm_kzalloc to devm_kcalloc (Vinod)
>>>  - quisce tasklet initialised by vchan_init() (Vinod)
>>>  - Don't make SLIM rproc user selectable (Bjorn)
>>>  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
>>>  - Various code style nits / commit message change (Lee)
>>>  - Separate patch for '\n' kconfig removal (Vinod)
>>
>> I hate to send a ping,
> 
> Sorry about that.
> 
>> but do you think we can merge this fdma series? It has gone
>> through quite a few review rounds now.
>>
> 
> I think the remoteproc part looks good.
> 
> Vinod, I don't have any changes queued in remoteproc that should cause
> merge issues. If you want to you could take the remoteproc patch
> through your tree.
> 
> 
> I do however think that the dts patches should go through arm-soc.

I will take care about dts patches by adding them in the next STi DT pull request

Thanks
Patrice

> 
> Regards,
> Bjorn
> 

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-14  6:59       ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14  6:59 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Bjorn

On 09/13/2016 08:06 PM, Bjorn Andersson wrote:
> On Tue 13 Sep 02:31 PDT 2016, Peter Griffin wrote:
> 
>> Hi Vinod & Bjorn,
>>
>> [..]
>>
>> On Mon, 05 Sep 2016, Peter Griffin wrote:
>>
>>> v8 actions some review feedback from Bjorn to the slim rproc driver, and also includes
>>> a patch which fixes a recursive Kconfig error which is triggered when st_fdma selects
>>> slim_rproc driver. The series has also been rebased on v4.8-rc3.
>>>
>>> v9 actions some review feedback from Bjorn, Lee and Vinod. See below. Importantly a bug
>>> was found during testing now that the platform boots without clk_ignore_unused parameter
>>> whereby the clocks would not be enabled properly before firmware loading was attempted.
>>>
>>> regards,
>>>
>>> Peter.
>>>
>>> Changes since v8:
>>>  - Add MODULE_ALIAS (Vinod)
>>>  - devm_kzalloc to devm_kcalloc (Vinod)
>>>  - quisce tasklet initialised by vchan_init() (Vinod)
>>>  - Don't make SLIM rproc user selectable (Bjorn)
>>>  - slim_rproc: Ensure clocks enabled before firmware load (Peter)
>>>  - Various code style nits / commit message change (Lee)
>>>  - Separate patch for '\n' kconfig removal (Vinod)
>>
>> I hate to send a ping,
> 
> Sorry about that.
> 
>> but do you think we can merge this fdma series? It has gone
>> through quite a few review rounds now.
>>
> 
> I think the remoteproc part looks good.
> 
> Vinod, I don't have any changes queued in remoteproc that should cause
> merge issues. If you want to you could take the remoteproc patch
> through your tree.
> 
> 
> I do however think that the dts patches should go through arm-soc.

I will take care about dts patches by adding them in the next STi DT pull request

Thanks
Patrice

> 
> Regards,
> Bjorn
> 

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver
  2016-09-13 17:56     ` Bjorn Andersson
  (?)
@ 2016-09-14  8:30       ` Lee Jones
  -1 siblings, 0 replies; 174+ messages in thread
From: Lee Jones @ 2016-09-14  8:30 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, patrice.chotard, dan.j.williams, airlied, kraxel,
	ohad, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization

On Tue, 13 Sep 2016, Bjorn Andersson wrote:

> On Mon 05 Sep 06:16 PDT 2016, Peter Griffin wrote:
> 
> > slim core is used as a basis for many IPs in the STi
> > chipsets such as fdma and demux. To avoid duplicating
> > the elf loading code in each device driver a slim
> > rproc driver has been created.
> > 
> > This driver is designed to be used by other device drivers
> > such as fdma, or demux whose IP is based around a slim core.
> > The device driver can call slim_rproc_alloc() to allocate
> > a slim rproc and slim_rproc_put() when finished.
> > 
> > This driver takes care of ioremapping the slim
> > registers (dmem, imem, slimcore, peripherals), whose offsets
> > and sizes can change between IP's. It also obtains and enables
> > any clocks used by the device. This approach avoids having
> > a double mapping of the registers as slim_rproc does not register
> > its own platform device. It also maps well to device tree
> > abstraction as it allows us to have one dt node for the whole
> > device.
> > 
> > All of the generic rproc elf loading code can be reused, and
> > we provide start() stop() hooks to start and stop the slim
> > core once the firmware has been loaded. This has been tested
> > successfully with fdma driver.
> > 
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> 
> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>

What's preventing this from being applied right away?

> > ---
> >  drivers/remoteproc/Kconfig               |   4 +
> >  drivers/remoteproc/Makefile              |   1 +
> >  drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
> >  include/linux/remoteproc/st_slim_rproc.h |  58 +++++
> >  4 files changed, 427 insertions(+)
> >  create mode 100644 drivers/remoteproc/st_slim_rproc.c
> >  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> > 
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index 1a8bf76a..a7bedc6 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -100,4 +100,8 @@ config ST_REMOTEPROC
> >  	  processor framework.
> >  	  This can be either built-in or a loadable module.
> >  
> > +config ST_SLIM_REMOTEPROC
> > +	tristate
> > +	select REMOTEPROC
> > +
> >  endmenu
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 92d3758..db1dae7 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
> >  obj-$(CONFIG_QCOM_MDT_LOADER)		+= qcom_mdt_loader.o
> >  obj-$(CONFIG_QCOM_Q6V5_PIL)		+= qcom_q6v5_pil.o
> >  obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
> > +obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
> > diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> > new file mode 100644
> > index 0000000..1484e97
> > --- /dev/null
> > +++ b/drivers/remoteproc/st_slim_rproc.c
> > @@ -0,0 +1,364 @@
> > +/*
> > + * SLIM core rproc driver
> > + *
> > + * Copyright (C) 2016 STMicroelectronics
> > + *
> > + * Author: Peter Griffin <peter.griffin@linaro.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/err.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/remoteproc.h>
> > +#include <linux/remoteproc/st_slim_rproc.h>
> > +#include "remoteproc_internal.h"
> > +
> > +/* SLIM core registers */
> > +#define SLIM_ID_OFST		0x0
> > +#define SLIM_VER_OFST		0x4
> > +
> > +#define SLIM_EN_OFST		0x8
> > +#define SLIM_EN_RUN			BIT(0)
> > +
> > +#define SLIM_CLK_GATE_OFST	0xC
> > +#define SLIM_CLK_GATE_DIS		BIT(0)
> > +#define SLIM_CLK_GATE_RESET		BIT(2)
> > +
> > +#define SLIM_SLIM_PC_OFST	0x20
> > +
> > +/* DMEM registers */
> > +#define SLIM_REV_ID_OFST	0x0
> > +#define SLIM_REV_ID_MIN_MASK		GENMASK(15, 8)
> > +#define SLIM_REV_ID_MIN(id)		((id & SLIM_REV_ID_MIN_MASK) >> 8)
> > +#define SLIM_REV_ID_MAJ_MASK		GENMASK(23, 16)
> > +#define SLIM_REV_ID_MAJ(id)		((id & SLIM_REV_ID_MAJ_MASK) >> 16)
> > +
> > +
> > +/* peripherals registers */
> > +#define SLIM_STBUS_SYNC_OFST	0xF88
> > +#define SLIM_STBUS_SYNC_DIS		BIT(0)
> > +
> > +#define SLIM_INT_SET_OFST	0xFD4
> > +#define SLIM_INT_CLR_OFST	0xFD8
> > +#define SLIM_INT_MASK_OFST	0xFDC
> > +
> > +#define SLIM_CMD_CLR_OFST	0xFC8
> > +#define SLIM_CMD_MASK_OFST	0xFCC
> > +
> > +static const char *mem_names[ST_SLIM_MEM_MAX] = {
> > +	[ST_SLIM_DMEM]	= "dmem",
> > +	[ST_SLIM_IMEM]	= "imem",
> > +};
> > +
> > +static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
> > +{
> > +	int clk, err;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
> > +		slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
> > +		if (IS_ERR(slim_rproc->clks[clk])) {
> > +			err = PTR_ERR(slim_rproc->clks[clk]);
> > +			if (err == -EPROBE_DEFER)
> > +				goto err_put_clks;
> > +			slim_rproc->clks[clk] = NULL;
> > +			break;
> > +		}
> > +	}
> > +
> > +	return 0;
> > +
> > +err_put_clks:
> > +	while (--clk >= 0)
> > +		clk_put(slim_rproc->clks[clk]);
> > +
> > +	return err;
> > +}
> > +
> > +static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> > +		clk_disable_unprepare(slim_rproc->clks[clk]);
> > +}
> > +
> > +static int slim_clk_enable(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk, ret;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++) {
> > +		ret = clk_prepare_enable(slim_rproc->clks[clk]);
> > +		if (ret)
> > +			goto err_disable_clks;
> > +	}
> > +
> > +	return 0;
> > +
> > +err_disable_clks:
> > +	while (--clk >= 0)
> > +		clk_disable_unprepare(slim_rproc->clks[clk]);
> > +
> > +	return ret;
> > +}
> > +
> > +/*
> > + * Remoteproc slim specific device handlers
> > + */
> > +static int slim_rproc_start(struct rproc *rproc)
> > +{
> > +	struct device *dev = &rproc->dev;
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	unsigned long hw_id, hw_ver, fw_rev;
> > +	u32 val;
> > +
> > +	/* disable CPU pipeline clock & reset CPU pipeline */
> > +	val = SLIM_CLK_GATE_DIS | SLIM_CLK_GATE_RESET;
> > +	writel(val, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	/* disable SLIM core STBus sync */
> > +	writel(SLIM_STBUS_SYNC_DIS, slim_rproc->peri + SLIM_STBUS_SYNC_OFST);
> > +
> > +	/* enable cpu pipeline clock */
> > +	writel(!SLIM_CLK_GATE_DIS,
> > +		slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	/* clear int & cmd mailbox */
> > +	writel(~0U, slim_rproc->peri + SLIM_INT_CLR_OFST);
> > +	writel(~0U, slim_rproc->peri + SLIM_CMD_CLR_OFST);
> > +
> > +	/* enable all channels cmd & int */
> > +	writel(~0U, slim_rproc->peri + SLIM_INT_MASK_OFST);
> > +	writel(~0U, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> > +
> > +	/* enable cpu */
> > +	writel(SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> > +
> > +	hw_id = readl_relaxed(slim_rproc->slimcore + SLIM_ID_OFST);
> > +	hw_ver = readl_relaxed(slim_rproc->slimcore + SLIM_VER_OFST);
> > +
> > +	fw_rev = readl(slim_rproc->mem[ST_SLIM_DMEM].cpu_addr +
> > +			SLIM_REV_ID_OFST);
> > +
> > +	dev_info(dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
> > +		 SLIM_REV_ID_MAJ(fw_rev), SLIM_REV_ID_MIN(fw_rev),
> > +		 hw_id, hw_ver);
> > +
> > +	return 0;
> > +}
> > +
> > +static int slim_rproc_stop(struct rproc *rproc)
> > +{
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	u32 val;
> > +
> > +	/* mask all (cmd & int) channels */
> > +	writel(0UL, slim_rproc->peri + SLIM_INT_MASK_OFST);
> > +	writel(0UL, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> > +
> > +	/* disable cpu pipeline clock */
> > +	writel(SLIM_CLK_GATE_DIS, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	writel(!SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> > +
> > +	val = readl(slim_rproc->slimcore + SLIM_EN_OFST);
> > +	if (val & SLIM_EN_RUN)
> > +		dev_warn(&rproc->dev, "Failed to disable SLIM");
> > +
> > +	dev_dbg(&rproc->dev, "slim stopped\n");
> > +
> > +	return 0;
> > +}
> > +
> > +static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> > +{
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	void *va = NULL;
> > +	int i;
> > +
> > +	for (i = 0; i < ST_SLIM_MEM_MAX; i++) {
> > +		if (da != slim_rproc->mem[i].bus_addr)
> > +			continue;
> > +
> > +		if (len <= slim_rproc->mem[i].size) {
> > +			/* __force to make sparse happy with type conversion */
> > +			va = (__force void *)slim_rproc->mem[i].cpu_addr;
> > +			break;
> > +		}
> > +	}
> > +
> > +	dev_dbg(&rproc->dev, "da = 0x%llx len = 0x%x va = 0x%p\n", da, len, va);
> > +
> > +	return va;
> > +}
> > +
> > +static struct rproc_ops slim_rproc_ops = {
> > +	.start		= slim_rproc_start,
> > +	.stop		= slim_rproc_stop,
> > +	.da_to_va       = slim_rproc_da_to_va,
> > +};
> > +
> > +/*
> > + * Firmware handler operations: sanity, boot address, load ...
> > + */
> > +
> > +static struct resource_table empty_rsc_tbl = {
> > +	.ver = 1,
> > +	.num = 0,
> > +};
> > +
> > +static struct resource_table *slim_rproc_find_rsc_table(struct rproc *rproc,
> > +					       const struct firmware *fw,
> > +					       int *tablesz)
> > +{
> > +	*tablesz = sizeof(empty_rsc_tbl);
> > +	return &empty_rsc_tbl;
> > +}
> > +
> > +static struct rproc_fw_ops slim_rproc_fw_ops = {
> > +	.find_rsc_table = slim_rproc_find_rsc_table,
> > +};
> > +
> > +/**
> > + * st_slim_rproc_alloc() - allocate and initialise slim rproc
> > + * @pdev: Pointer to the platform_device struct
> > + * @fw_name: Name of firmware for rproc to use
> > + *
> > + * Function for allocating and initialising a slim rproc for use by
> > + * device drivers whose IP is based around the SLIM core. It
> > + * obtains and enables any clocks required by the SLIM core and also
> > + * ioremaps the various IO.
> > + *
> > + * Returns st_slim_rproc pointer or PTR_ERR() on error.
> > + */
> > +
> > +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> > +				char *fw_name)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct st_slim_rproc *slim_rproc;
> > +	struct device_node *np = dev->of_node;
> > +	struct rproc *rproc;
> > +	struct resource *res;
> > +	int err, i;
> > +	const struct rproc_fw_ops *elf_ops;
> > +
> > +	if (!fw_name)
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	if (!of_device_is_compatible(np, "st,slim-rproc"))
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> > +			fw_name, sizeof(*slim_rproc));
> > +	if (!rproc)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	rproc->has_iommu = false;
> > +
> > +	slim_rproc = rproc->priv;
> > +	slim_rproc->rproc = rproc;
> > +
> > +	elf_ops = rproc->fw_ops;
> > +	/* Use some generic elf ops */
> > +	slim_rproc_fw_ops.load = elf_ops->load;
> > +	slim_rproc_fw_ops.sanity_check = elf_ops->sanity_check;
> > +
> > +	rproc->fw_ops = &slim_rproc_fw_ops;
> > +
> > +	/* get imem and dmem */
> > +	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
> > +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +						mem_names[i]);
> > +
> > +		slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
> > +		if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
> > +			dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
> > +			err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
> > +			goto err;
> > +		}
> > +		slim_rproc->mem[i].bus_addr = res->start;
> > +		slim_rproc->mem[i].size = resource_size(res);
> > +	}
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
> > +	slim_rproc->slimcore = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(slim_rproc->slimcore)) {
> > +		dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
> > +		err = PTR_ERR(slim_rproc->slimcore);
> > +		goto err;
> > +	}
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
> > +	slim_rproc->peri = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(slim_rproc->peri)) {
> > +		dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
> > +		err = PTR_ERR(slim_rproc->peri);
> > +		goto err;
> > +	}
> > +
> > +	err = slim_clk_get(slim_rproc, dev);
> > +	if (err)
> > +		goto err;
> > +
> > +	err = slim_clk_enable(slim_rproc);
> > +	if (err) {
> > +		dev_err(dev, "Failed to enable clocks\n");
> > +		goto err_clk_put;
> > +	}
> > +
> > +	/* Register as a remoteproc device */
> > +	err = rproc_add(rproc);
> > +	if (err) {
> > +		dev_err(dev, "registration of slim remoteproc failed\n");
> > +		goto err_clk_dis;
> > +	}
> > +
> > +	return slim_rproc;
> > +
> > +err_clk_dis:
> > +	slim_clk_disable(slim_rproc);
> > +err_clk_put:
> > +	for (i = 0; i < ST_SLIM_MAX_CLK && slim_rproc->clks[i]; i++)
> > +		clk_put(slim_rproc->clks[i]);
> > +err:
> > +	rproc_put(rproc);
> > +	return ERR_PTR(err);
> > +}
> > +EXPORT_SYMBOL(st_slim_rproc_alloc);
> > +
> > +/**
> > +  * st_slim_rproc_put() - put slim rproc resources
> > +  * @slim_rproc: Pointer to the st_slim_rproc struct
> > +  *
> > +  * Function for calling respective _put() functions on slim_rproc resources.
> > +  *
> > +  */
> > +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk;
> > +
> > +	if (!slim_rproc)
> > +		return;
> > +
> > +	slim_clk_disable(slim_rproc);
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> > +		clk_put(slim_rproc->clks[clk]);
> > +
> > +	rproc_del(slim_rproc->rproc);
> > +	rproc_put(slim_rproc->rproc);
> > +}
> > +EXPORT_SYMBOL(st_slim_rproc_put);
> > +
> > +MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
> > +MODULE_DESCRIPTION("STMicroelectronics SLIM core rproc driver");
> > +MODULE_LICENSE("GPL v2");
> > diff --git a/include/linux/remoteproc/st_slim_rproc.h b/include/linux/remoteproc/st_slim_rproc.h
> > new file mode 100644
> > index 0000000..4155556
> > --- /dev/null
> > +++ b/include/linux/remoteproc/st_slim_rproc.h
> > @@ -0,0 +1,58 @@
> > +/*
> > + * SLIM core rproc driver header
> > + *
> > + * Copyright (C) 2016 STMicroelectronics
> > + *
> > + * Author: Peter Griffin <peter.griffin@linaro.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +#ifndef _ST_REMOTEPROC_SLIM_H
> > +#define _ST_REMOTEPROC_SLIM_H
> > +
> > +#define ST_SLIM_MEM_MAX 2
> > +#define ST_SLIM_MAX_CLK 4
> > +
> > +enum {
> > +	ST_SLIM_DMEM,
> > +	ST_SLIM_IMEM,
> > +};
> > +
> > +/**
> > + * struct st_slim_mem - slim internal memory structure
> > + * @cpu_addr: MPU virtual address of the memory region
> > + * @bus_addr: Bus address used to access the memory region
> > + * @size: Size of the memory region
> > + */
> > +struct st_slim_mem {
> > +	void __iomem *cpu_addr;
> > +	phys_addr_t bus_addr;
> > +	size_t size;
> > +};
> > +
> > +/**
> > + * struct st_slim_rproc - SLIM slim core
> > + * @rproc: rproc handle
> > + * @mem: slim memory information
> > + * @slimcore: slim slimcore regs
> > + * @peri: slim peripheral regs
> > + * @clks: slim clocks
> > + */
> > +struct st_slim_rproc {
> > +	struct rproc *rproc;
> > +	struct st_slim_mem mem[ST_SLIM_MEM_MAX];
> > +	void __iomem *slimcore;
> > +	void __iomem *peri;
> > +
> > +	/* st_slim_rproc private */
> > +	struct clk *clks[ST_SLIM_MAX_CLK];
> > +};
> > +
> > +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> > +					char *fw_name);
> > +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc);
> > +
> > +#endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver
@ 2016-09-14  8:30       ` Lee Jones
  0 siblings, 0 replies; 174+ messages in thread
From: Lee Jones @ 2016-09-14  8:30 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: ohad, devicetree, kernel, vinod.koul, linux-remoteproc,
	patrice.chotard, dri-devel, linux-kernel, Peter Griffin, kraxel,
	dmaengine, dan.j.williams, virtualization, linux-arm-kernel

On Tue, 13 Sep 2016, Bjorn Andersson wrote:

> On Mon 05 Sep 06:16 PDT 2016, Peter Griffin wrote:
> 
> > slim core is used as a basis for many IPs in the STi
> > chipsets such as fdma and demux. To avoid duplicating
> > the elf loading code in each device driver a slim
> > rproc driver has been created.
> > 
> > This driver is designed to be used by other device drivers
> > such as fdma, or demux whose IP is based around a slim core.
> > The device driver can call slim_rproc_alloc() to allocate
> > a slim rproc and slim_rproc_put() when finished.
> > 
> > This driver takes care of ioremapping the slim
> > registers (dmem, imem, slimcore, peripherals), whose offsets
> > and sizes can change between IP's. It also obtains and enables
> > any clocks used by the device. This approach avoids having
> > a double mapping of the registers as slim_rproc does not register
> > its own platform device. It also maps well to device tree
> > abstraction as it allows us to have one dt node for the whole
> > device.
> > 
> > All of the generic rproc elf loading code can be reused, and
> > we provide start() stop() hooks to start and stop the slim
> > core once the firmware has been loaded. This has been tested
> > successfully with fdma driver.
> > 
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> 
> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>

What's preventing this from being applied right away?

> > ---
> >  drivers/remoteproc/Kconfig               |   4 +
> >  drivers/remoteproc/Makefile              |   1 +
> >  drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
> >  include/linux/remoteproc/st_slim_rproc.h |  58 +++++
> >  4 files changed, 427 insertions(+)
> >  create mode 100644 drivers/remoteproc/st_slim_rproc.c
> >  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> > 
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index 1a8bf76a..a7bedc6 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -100,4 +100,8 @@ config ST_REMOTEPROC
> >  	  processor framework.
> >  	  This can be either built-in or a loadable module.
> >  
> > +config ST_SLIM_REMOTEPROC
> > +	tristate
> > +	select REMOTEPROC
> > +
> >  endmenu
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 92d3758..db1dae7 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
> >  obj-$(CONFIG_QCOM_MDT_LOADER)		+= qcom_mdt_loader.o
> >  obj-$(CONFIG_QCOM_Q6V5_PIL)		+= qcom_q6v5_pil.o
> >  obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
> > +obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
> > diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> > new file mode 100644
> > index 0000000..1484e97
> > --- /dev/null
> > +++ b/drivers/remoteproc/st_slim_rproc.c
> > @@ -0,0 +1,364 @@
> > +/*
> > + * SLIM core rproc driver
> > + *
> > + * Copyright (C) 2016 STMicroelectronics
> > + *
> > + * Author: Peter Griffin <peter.griffin@linaro.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/err.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/remoteproc.h>
> > +#include <linux/remoteproc/st_slim_rproc.h>
> > +#include "remoteproc_internal.h"
> > +
> > +/* SLIM core registers */
> > +#define SLIM_ID_OFST		0x0
> > +#define SLIM_VER_OFST		0x4
> > +
> > +#define SLIM_EN_OFST		0x8
> > +#define SLIM_EN_RUN			BIT(0)
> > +
> > +#define SLIM_CLK_GATE_OFST	0xC
> > +#define SLIM_CLK_GATE_DIS		BIT(0)
> > +#define SLIM_CLK_GATE_RESET		BIT(2)
> > +
> > +#define SLIM_SLIM_PC_OFST	0x20
> > +
> > +/* DMEM registers */
> > +#define SLIM_REV_ID_OFST	0x0
> > +#define SLIM_REV_ID_MIN_MASK		GENMASK(15, 8)
> > +#define SLIM_REV_ID_MIN(id)		((id & SLIM_REV_ID_MIN_MASK) >> 8)
> > +#define SLIM_REV_ID_MAJ_MASK		GENMASK(23, 16)
> > +#define SLIM_REV_ID_MAJ(id)		((id & SLIM_REV_ID_MAJ_MASK) >> 16)
> > +
> > +
> > +/* peripherals registers */
> > +#define SLIM_STBUS_SYNC_OFST	0xF88
> > +#define SLIM_STBUS_SYNC_DIS		BIT(0)
> > +
> > +#define SLIM_INT_SET_OFST	0xFD4
> > +#define SLIM_INT_CLR_OFST	0xFD8
> > +#define SLIM_INT_MASK_OFST	0xFDC
> > +
> > +#define SLIM_CMD_CLR_OFST	0xFC8
> > +#define SLIM_CMD_MASK_OFST	0xFCC
> > +
> > +static const char *mem_names[ST_SLIM_MEM_MAX] = {
> > +	[ST_SLIM_DMEM]	= "dmem",
> > +	[ST_SLIM_IMEM]	= "imem",
> > +};
> > +
> > +static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
> > +{
> > +	int clk, err;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
> > +		slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
> > +		if (IS_ERR(slim_rproc->clks[clk])) {
> > +			err = PTR_ERR(slim_rproc->clks[clk]);
> > +			if (err == -EPROBE_DEFER)
> > +				goto err_put_clks;
> > +			slim_rproc->clks[clk] = NULL;
> > +			break;
> > +		}
> > +	}
> > +
> > +	return 0;
> > +
> > +err_put_clks:
> > +	while (--clk >= 0)
> > +		clk_put(slim_rproc->clks[clk]);
> > +
> > +	return err;
> > +}
> > +
> > +static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> > +		clk_disable_unprepare(slim_rproc->clks[clk]);
> > +}
> > +
> > +static int slim_clk_enable(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk, ret;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++) {
> > +		ret = clk_prepare_enable(slim_rproc->clks[clk]);
> > +		if (ret)
> > +			goto err_disable_clks;
> > +	}
> > +
> > +	return 0;
> > +
> > +err_disable_clks:
> > +	while (--clk >= 0)
> > +		clk_disable_unprepare(slim_rproc->clks[clk]);
> > +
> > +	return ret;
> > +}
> > +
> > +/*
> > + * Remoteproc slim specific device handlers
> > + */
> > +static int slim_rproc_start(struct rproc *rproc)
> > +{
> > +	struct device *dev = &rproc->dev;
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	unsigned long hw_id, hw_ver, fw_rev;
> > +	u32 val;
> > +
> > +	/* disable CPU pipeline clock & reset CPU pipeline */
> > +	val = SLIM_CLK_GATE_DIS | SLIM_CLK_GATE_RESET;
> > +	writel(val, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	/* disable SLIM core STBus sync */
> > +	writel(SLIM_STBUS_SYNC_DIS, slim_rproc->peri + SLIM_STBUS_SYNC_OFST);
> > +
> > +	/* enable cpu pipeline clock */
> > +	writel(!SLIM_CLK_GATE_DIS,
> > +		slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	/* clear int & cmd mailbox */
> > +	writel(~0U, slim_rproc->peri + SLIM_INT_CLR_OFST);
> > +	writel(~0U, slim_rproc->peri + SLIM_CMD_CLR_OFST);
> > +
> > +	/* enable all channels cmd & int */
> > +	writel(~0U, slim_rproc->peri + SLIM_INT_MASK_OFST);
> > +	writel(~0U, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> > +
> > +	/* enable cpu */
> > +	writel(SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> > +
> > +	hw_id = readl_relaxed(slim_rproc->slimcore + SLIM_ID_OFST);
> > +	hw_ver = readl_relaxed(slim_rproc->slimcore + SLIM_VER_OFST);
> > +
> > +	fw_rev = readl(slim_rproc->mem[ST_SLIM_DMEM].cpu_addr +
> > +			SLIM_REV_ID_OFST);
> > +
> > +	dev_info(dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
> > +		 SLIM_REV_ID_MAJ(fw_rev), SLIM_REV_ID_MIN(fw_rev),
> > +		 hw_id, hw_ver);
> > +
> > +	return 0;
> > +}
> > +
> > +static int slim_rproc_stop(struct rproc *rproc)
> > +{
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	u32 val;
> > +
> > +	/* mask all (cmd & int) channels */
> > +	writel(0UL, slim_rproc->peri + SLIM_INT_MASK_OFST);
> > +	writel(0UL, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> > +
> > +	/* disable cpu pipeline clock */
> > +	writel(SLIM_CLK_GATE_DIS, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	writel(!SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> > +
> > +	val = readl(slim_rproc->slimcore + SLIM_EN_OFST);
> > +	if (val & SLIM_EN_RUN)
> > +		dev_warn(&rproc->dev, "Failed to disable SLIM");
> > +
> > +	dev_dbg(&rproc->dev, "slim stopped\n");
> > +
> > +	return 0;
> > +}
> > +
> > +static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> > +{
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	void *va = NULL;
> > +	int i;
> > +
> > +	for (i = 0; i < ST_SLIM_MEM_MAX; i++) {
> > +		if (da != slim_rproc->mem[i].bus_addr)
> > +			continue;
> > +
> > +		if (len <= slim_rproc->mem[i].size) {
> > +			/* __force to make sparse happy with type conversion */
> > +			va = (__force void *)slim_rproc->mem[i].cpu_addr;
> > +			break;
> > +		}
> > +	}
> > +
> > +	dev_dbg(&rproc->dev, "da = 0x%llx len = 0x%x va = 0x%p\n", da, len, va);
> > +
> > +	return va;
> > +}
> > +
> > +static struct rproc_ops slim_rproc_ops = {
> > +	.start		= slim_rproc_start,
> > +	.stop		= slim_rproc_stop,
> > +	.da_to_va       = slim_rproc_da_to_va,
> > +};
> > +
> > +/*
> > + * Firmware handler operations: sanity, boot address, load ...
> > + */
> > +
> > +static struct resource_table empty_rsc_tbl = {
> > +	.ver = 1,
> > +	.num = 0,
> > +};
> > +
> > +static struct resource_table *slim_rproc_find_rsc_table(struct rproc *rproc,
> > +					       const struct firmware *fw,
> > +					       int *tablesz)
> > +{
> > +	*tablesz = sizeof(empty_rsc_tbl);
> > +	return &empty_rsc_tbl;
> > +}
> > +
> > +static struct rproc_fw_ops slim_rproc_fw_ops = {
> > +	.find_rsc_table = slim_rproc_find_rsc_table,
> > +};
> > +
> > +/**
> > + * st_slim_rproc_alloc() - allocate and initialise slim rproc
> > + * @pdev: Pointer to the platform_device struct
> > + * @fw_name: Name of firmware for rproc to use
> > + *
> > + * Function for allocating and initialising a slim rproc for use by
> > + * device drivers whose IP is based around the SLIM core. It
> > + * obtains and enables any clocks required by the SLIM core and also
> > + * ioremaps the various IO.
> > + *
> > + * Returns st_slim_rproc pointer or PTR_ERR() on error.
> > + */
> > +
> > +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> > +				char *fw_name)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct st_slim_rproc *slim_rproc;
> > +	struct device_node *np = dev->of_node;
> > +	struct rproc *rproc;
> > +	struct resource *res;
> > +	int err, i;
> > +	const struct rproc_fw_ops *elf_ops;
> > +
> > +	if (!fw_name)
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	if (!of_device_is_compatible(np, "st,slim-rproc"))
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> > +			fw_name, sizeof(*slim_rproc));
> > +	if (!rproc)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	rproc->has_iommu = false;
> > +
> > +	slim_rproc = rproc->priv;
> > +	slim_rproc->rproc = rproc;
> > +
> > +	elf_ops = rproc->fw_ops;
> > +	/* Use some generic elf ops */
> > +	slim_rproc_fw_ops.load = elf_ops->load;
> > +	slim_rproc_fw_ops.sanity_check = elf_ops->sanity_check;
> > +
> > +	rproc->fw_ops = &slim_rproc_fw_ops;
> > +
> > +	/* get imem and dmem */
> > +	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
> > +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +						mem_names[i]);
> > +
> > +		slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
> > +		if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
> > +			dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
> > +			err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
> > +			goto err;
> > +		}
> > +		slim_rproc->mem[i].bus_addr = res->start;
> > +		slim_rproc->mem[i].size = resource_size(res);
> > +	}
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
> > +	slim_rproc->slimcore = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(slim_rproc->slimcore)) {
> > +		dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
> > +		err = PTR_ERR(slim_rproc->slimcore);
> > +		goto err;
> > +	}
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
> > +	slim_rproc->peri = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(slim_rproc->peri)) {
> > +		dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
> > +		err = PTR_ERR(slim_rproc->peri);
> > +		goto err;
> > +	}
> > +
> > +	err = slim_clk_get(slim_rproc, dev);
> > +	if (err)
> > +		goto err;
> > +
> > +	err = slim_clk_enable(slim_rproc);
> > +	if (err) {
> > +		dev_err(dev, "Failed to enable clocks\n");
> > +		goto err_clk_put;
> > +	}
> > +
> > +	/* Register as a remoteproc device */
> > +	err = rproc_add(rproc);
> > +	if (err) {
> > +		dev_err(dev, "registration of slim remoteproc failed\n");
> > +		goto err_clk_dis;
> > +	}
> > +
> > +	return slim_rproc;
> > +
> > +err_clk_dis:
> > +	slim_clk_disable(slim_rproc);
> > +err_clk_put:
> > +	for (i = 0; i < ST_SLIM_MAX_CLK && slim_rproc->clks[i]; i++)
> > +		clk_put(slim_rproc->clks[i]);
> > +err:
> > +	rproc_put(rproc);
> > +	return ERR_PTR(err);
> > +}
> > +EXPORT_SYMBOL(st_slim_rproc_alloc);
> > +
> > +/**
> > +  * st_slim_rproc_put() - put slim rproc resources
> > +  * @slim_rproc: Pointer to the st_slim_rproc struct
> > +  *
> > +  * Function for calling respective _put() functions on slim_rproc resources.
> > +  *
> > +  */
> > +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk;
> > +
> > +	if (!slim_rproc)
> > +		return;
> > +
> > +	slim_clk_disable(slim_rproc);
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> > +		clk_put(slim_rproc->clks[clk]);
> > +
> > +	rproc_del(slim_rproc->rproc);
> > +	rproc_put(slim_rproc->rproc);
> > +}
> > +EXPORT_SYMBOL(st_slim_rproc_put);
> > +
> > +MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
> > +MODULE_DESCRIPTION("STMicroelectronics SLIM core rproc driver");
> > +MODULE_LICENSE("GPL v2");
> > diff --git a/include/linux/remoteproc/st_slim_rproc.h b/include/linux/remoteproc/st_slim_rproc.h
> > new file mode 100644
> > index 0000000..4155556
> > --- /dev/null
> > +++ b/include/linux/remoteproc/st_slim_rproc.h
> > @@ -0,0 +1,58 @@
> > +/*
> > + * SLIM core rproc driver header
> > + *
> > + * Copyright (C) 2016 STMicroelectronics
> > + *
> > + * Author: Peter Griffin <peter.griffin@linaro.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +#ifndef _ST_REMOTEPROC_SLIM_H
> > +#define _ST_REMOTEPROC_SLIM_H
> > +
> > +#define ST_SLIM_MEM_MAX 2
> > +#define ST_SLIM_MAX_CLK 4
> > +
> > +enum {
> > +	ST_SLIM_DMEM,
> > +	ST_SLIM_IMEM,
> > +};
> > +
> > +/**
> > + * struct st_slim_mem - slim internal memory structure
> > + * @cpu_addr: MPU virtual address of the memory region
> > + * @bus_addr: Bus address used to access the memory region
> > + * @size: Size of the memory region
> > + */
> > +struct st_slim_mem {
> > +	void __iomem *cpu_addr;
> > +	phys_addr_t bus_addr;
> > +	size_t size;
> > +};
> > +
> > +/**
> > + * struct st_slim_rproc - SLIM slim core
> > + * @rproc: rproc handle
> > + * @mem: slim memory information
> > + * @slimcore: slim slimcore regs
> > + * @peri: slim peripheral regs
> > + * @clks: slim clocks
> > + */
> > +struct st_slim_rproc {
> > +	struct rproc *rproc;
> > +	struct st_slim_mem mem[ST_SLIM_MEM_MAX];
> > +	void __iomem *slimcore;
> > +	void __iomem *peri;
> > +
> > +	/* st_slim_rproc private */
> > +	struct clk *clks[ST_SLIM_MAX_CLK];
> > +};
> > +
> > +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> > +					char *fw_name);
> > +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc);
> > +
> > +#endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver
  2016-09-13 17:56     ` Bjorn Andersson
  (?)
  (?)
@ 2016-09-14  8:30     ` Lee Jones
  -1 siblings, 0 replies; 174+ messages in thread
From: Lee Jones @ 2016-09-14  8:30 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: devicetree, kernel, vinod.koul, linux-remoteproc,
	patrice.chotard, dri-devel, linux-kernel, Peter Griffin, airlied,
	dmaengine, dan.j.williams, virtualization, linux-arm-kernel

On Tue, 13 Sep 2016, Bjorn Andersson wrote:

> On Mon 05 Sep 06:16 PDT 2016, Peter Griffin wrote:
> 
> > slim core is used as a basis for many IPs in the STi
> > chipsets such as fdma and demux. To avoid duplicating
> > the elf loading code in each device driver a slim
> > rproc driver has been created.
> > 
> > This driver is designed to be used by other device drivers
> > such as fdma, or demux whose IP is based around a slim core.
> > The device driver can call slim_rproc_alloc() to allocate
> > a slim rproc and slim_rproc_put() when finished.
> > 
> > This driver takes care of ioremapping the slim
> > registers (dmem, imem, slimcore, peripherals), whose offsets
> > and sizes can change between IP's. It also obtains and enables
> > any clocks used by the device. This approach avoids having
> > a double mapping of the registers as slim_rproc does not register
> > its own platform device. It also maps well to device tree
> > abstraction as it allows us to have one dt node for the whole
> > device.
> > 
> > All of the generic rproc elf loading code can be reused, and
> > we provide start() stop() hooks to start and stop the slim
> > core once the firmware has been loaded. This has been tested
> > successfully with fdma driver.
> > 
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> 
> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>

What's preventing this from being applied right away?

> > ---
> >  drivers/remoteproc/Kconfig               |   4 +
> >  drivers/remoteproc/Makefile              |   1 +
> >  drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
> >  include/linux/remoteproc/st_slim_rproc.h |  58 +++++
> >  4 files changed, 427 insertions(+)
> >  create mode 100644 drivers/remoteproc/st_slim_rproc.c
> >  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> > 
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index 1a8bf76a..a7bedc6 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -100,4 +100,8 @@ config ST_REMOTEPROC
> >  	  processor framework.
> >  	  This can be either built-in or a loadable module.
> >  
> > +config ST_SLIM_REMOTEPROC
> > +	tristate
> > +	select REMOTEPROC
> > +
> >  endmenu
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 92d3758..db1dae7 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
> >  obj-$(CONFIG_QCOM_MDT_LOADER)		+= qcom_mdt_loader.o
> >  obj-$(CONFIG_QCOM_Q6V5_PIL)		+= qcom_q6v5_pil.o
> >  obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
> > +obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
> > diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> > new file mode 100644
> > index 0000000..1484e97
> > --- /dev/null
> > +++ b/drivers/remoteproc/st_slim_rproc.c
> > @@ -0,0 +1,364 @@
> > +/*
> > + * SLIM core rproc driver
> > + *
> > + * Copyright (C) 2016 STMicroelectronics
> > + *
> > + * Author: Peter Griffin <peter.griffin@linaro.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/err.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/remoteproc.h>
> > +#include <linux/remoteproc/st_slim_rproc.h>
> > +#include "remoteproc_internal.h"
> > +
> > +/* SLIM core registers */
> > +#define SLIM_ID_OFST		0x0
> > +#define SLIM_VER_OFST		0x4
> > +
> > +#define SLIM_EN_OFST		0x8
> > +#define SLIM_EN_RUN			BIT(0)
> > +
> > +#define SLIM_CLK_GATE_OFST	0xC
> > +#define SLIM_CLK_GATE_DIS		BIT(0)
> > +#define SLIM_CLK_GATE_RESET		BIT(2)
> > +
> > +#define SLIM_SLIM_PC_OFST	0x20
> > +
> > +/* DMEM registers */
> > +#define SLIM_REV_ID_OFST	0x0
> > +#define SLIM_REV_ID_MIN_MASK		GENMASK(15, 8)
> > +#define SLIM_REV_ID_MIN(id)		((id & SLIM_REV_ID_MIN_MASK) >> 8)
> > +#define SLIM_REV_ID_MAJ_MASK		GENMASK(23, 16)
> > +#define SLIM_REV_ID_MAJ(id)		((id & SLIM_REV_ID_MAJ_MASK) >> 16)
> > +
> > +
> > +/* peripherals registers */
> > +#define SLIM_STBUS_SYNC_OFST	0xF88
> > +#define SLIM_STBUS_SYNC_DIS		BIT(0)
> > +
> > +#define SLIM_INT_SET_OFST	0xFD4
> > +#define SLIM_INT_CLR_OFST	0xFD8
> > +#define SLIM_INT_MASK_OFST	0xFDC
> > +
> > +#define SLIM_CMD_CLR_OFST	0xFC8
> > +#define SLIM_CMD_MASK_OFST	0xFCC
> > +
> > +static const char *mem_names[ST_SLIM_MEM_MAX] = {
> > +	[ST_SLIM_DMEM]	= "dmem",
> > +	[ST_SLIM_IMEM]	= "imem",
> > +};
> > +
> > +static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
> > +{
> > +	int clk, err;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
> > +		slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
> > +		if (IS_ERR(slim_rproc->clks[clk])) {
> > +			err = PTR_ERR(slim_rproc->clks[clk]);
> > +			if (err == -EPROBE_DEFER)
> > +				goto err_put_clks;
> > +			slim_rproc->clks[clk] = NULL;
> > +			break;
> > +		}
> > +	}
> > +
> > +	return 0;
> > +
> > +err_put_clks:
> > +	while (--clk >= 0)
> > +		clk_put(slim_rproc->clks[clk]);
> > +
> > +	return err;
> > +}
> > +
> > +static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> > +		clk_disable_unprepare(slim_rproc->clks[clk]);
> > +}
> > +
> > +static int slim_clk_enable(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk, ret;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++) {
> > +		ret = clk_prepare_enable(slim_rproc->clks[clk]);
> > +		if (ret)
> > +			goto err_disable_clks;
> > +	}
> > +
> > +	return 0;
> > +
> > +err_disable_clks:
> > +	while (--clk >= 0)
> > +		clk_disable_unprepare(slim_rproc->clks[clk]);
> > +
> > +	return ret;
> > +}
> > +
> > +/*
> > + * Remoteproc slim specific device handlers
> > + */
> > +static int slim_rproc_start(struct rproc *rproc)
> > +{
> > +	struct device *dev = &rproc->dev;
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	unsigned long hw_id, hw_ver, fw_rev;
> > +	u32 val;
> > +
> > +	/* disable CPU pipeline clock & reset CPU pipeline */
> > +	val = SLIM_CLK_GATE_DIS | SLIM_CLK_GATE_RESET;
> > +	writel(val, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	/* disable SLIM core STBus sync */
> > +	writel(SLIM_STBUS_SYNC_DIS, slim_rproc->peri + SLIM_STBUS_SYNC_OFST);
> > +
> > +	/* enable cpu pipeline clock */
> > +	writel(!SLIM_CLK_GATE_DIS,
> > +		slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	/* clear int & cmd mailbox */
> > +	writel(~0U, slim_rproc->peri + SLIM_INT_CLR_OFST);
> > +	writel(~0U, slim_rproc->peri + SLIM_CMD_CLR_OFST);
> > +
> > +	/* enable all channels cmd & int */
> > +	writel(~0U, slim_rproc->peri + SLIM_INT_MASK_OFST);
> > +	writel(~0U, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> > +
> > +	/* enable cpu */
> > +	writel(SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> > +
> > +	hw_id = readl_relaxed(slim_rproc->slimcore + SLIM_ID_OFST);
> > +	hw_ver = readl_relaxed(slim_rproc->slimcore + SLIM_VER_OFST);
> > +
> > +	fw_rev = readl(slim_rproc->mem[ST_SLIM_DMEM].cpu_addr +
> > +			SLIM_REV_ID_OFST);
> > +
> > +	dev_info(dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
> > +		 SLIM_REV_ID_MAJ(fw_rev), SLIM_REV_ID_MIN(fw_rev),
> > +		 hw_id, hw_ver);
> > +
> > +	return 0;
> > +}
> > +
> > +static int slim_rproc_stop(struct rproc *rproc)
> > +{
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	u32 val;
> > +
> > +	/* mask all (cmd & int) channels */
> > +	writel(0UL, slim_rproc->peri + SLIM_INT_MASK_OFST);
> > +	writel(0UL, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> > +
> > +	/* disable cpu pipeline clock */
> > +	writel(SLIM_CLK_GATE_DIS, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	writel(!SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> > +
> > +	val = readl(slim_rproc->slimcore + SLIM_EN_OFST);
> > +	if (val & SLIM_EN_RUN)
> > +		dev_warn(&rproc->dev, "Failed to disable SLIM");
> > +
> > +	dev_dbg(&rproc->dev, "slim stopped\n");
> > +
> > +	return 0;
> > +}
> > +
> > +static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> > +{
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	void *va = NULL;
> > +	int i;
> > +
> > +	for (i = 0; i < ST_SLIM_MEM_MAX; i++) {
> > +		if (da != slim_rproc->mem[i].bus_addr)
> > +			continue;
> > +
> > +		if (len <= slim_rproc->mem[i].size) {
> > +			/* __force to make sparse happy with type conversion */
> > +			va = (__force void *)slim_rproc->mem[i].cpu_addr;
> > +			break;
> > +		}
> > +	}
> > +
> > +	dev_dbg(&rproc->dev, "da = 0x%llx len = 0x%x va = 0x%p\n", da, len, va);
> > +
> > +	return va;
> > +}
> > +
> > +static struct rproc_ops slim_rproc_ops = {
> > +	.start		= slim_rproc_start,
> > +	.stop		= slim_rproc_stop,
> > +	.da_to_va       = slim_rproc_da_to_va,
> > +};
> > +
> > +/*
> > + * Firmware handler operations: sanity, boot address, load ...
> > + */
> > +
> > +static struct resource_table empty_rsc_tbl = {
> > +	.ver = 1,
> > +	.num = 0,
> > +};
> > +
> > +static struct resource_table *slim_rproc_find_rsc_table(struct rproc *rproc,
> > +					       const struct firmware *fw,
> > +					       int *tablesz)
> > +{
> > +	*tablesz = sizeof(empty_rsc_tbl);
> > +	return &empty_rsc_tbl;
> > +}
> > +
> > +static struct rproc_fw_ops slim_rproc_fw_ops = {
> > +	.find_rsc_table = slim_rproc_find_rsc_table,
> > +};
> > +
> > +/**
> > + * st_slim_rproc_alloc() - allocate and initialise slim rproc
> > + * @pdev: Pointer to the platform_device struct
> > + * @fw_name: Name of firmware for rproc to use
> > + *
> > + * Function for allocating and initialising a slim rproc for use by
> > + * device drivers whose IP is based around the SLIM core. It
> > + * obtains and enables any clocks required by the SLIM core and also
> > + * ioremaps the various IO.
> > + *
> > + * Returns st_slim_rproc pointer or PTR_ERR() on error.
> > + */
> > +
> > +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> > +				char *fw_name)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct st_slim_rproc *slim_rproc;
> > +	struct device_node *np = dev->of_node;
> > +	struct rproc *rproc;
> > +	struct resource *res;
> > +	int err, i;
> > +	const struct rproc_fw_ops *elf_ops;
> > +
> > +	if (!fw_name)
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	if (!of_device_is_compatible(np, "st,slim-rproc"))
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> > +			fw_name, sizeof(*slim_rproc));
> > +	if (!rproc)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	rproc->has_iommu = false;
> > +
> > +	slim_rproc = rproc->priv;
> > +	slim_rproc->rproc = rproc;
> > +
> > +	elf_ops = rproc->fw_ops;
> > +	/* Use some generic elf ops */
> > +	slim_rproc_fw_ops.load = elf_ops->load;
> > +	slim_rproc_fw_ops.sanity_check = elf_ops->sanity_check;
> > +
> > +	rproc->fw_ops = &slim_rproc_fw_ops;
> > +
> > +	/* get imem and dmem */
> > +	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
> > +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +						mem_names[i]);
> > +
> > +		slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
> > +		if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
> > +			dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
> > +			err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
> > +			goto err;
> > +		}
> > +		slim_rproc->mem[i].bus_addr = res->start;
> > +		slim_rproc->mem[i].size = resource_size(res);
> > +	}
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
> > +	slim_rproc->slimcore = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(slim_rproc->slimcore)) {
> > +		dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
> > +		err = PTR_ERR(slim_rproc->slimcore);
> > +		goto err;
> > +	}
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
> > +	slim_rproc->peri = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(slim_rproc->peri)) {
> > +		dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
> > +		err = PTR_ERR(slim_rproc->peri);
> > +		goto err;
> > +	}
> > +
> > +	err = slim_clk_get(slim_rproc, dev);
> > +	if (err)
> > +		goto err;
> > +
> > +	err = slim_clk_enable(slim_rproc);
> > +	if (err) {
> > +		dev_err(dev, "Failed to enable clocks\n");
> > +		goto err_clk_put;
> > +	}
> > +
> > +	/* Register as a remoteproc device */
> > +	err = rproc_add(rproc);
> > +	if (err) {
> > +		dev_err(dev, "registration of slim remoteproc failed\n");
> > +		goto err_clk_dis;
> > +	}
> > +
> > +	return slim_rproc;
> > +
> > +err_clk_dis:
> > +	slim_clk_disable(slim_rproc);
> > +err_clk_put:
> > +	for (i = 0; i < ST_SLIM_MAX_CLK && slim_rproc->clks[i]; i++)
> > +		clk_put(slim_rproc->clks[i]);
> > +err:
> > +	rproc_put(rproc);
> > +	return ERR_PTR(err);
> > +}
> > +EXPORT_SYMBOL(st_slim_rproc_alloc);
> > +
> > +/**
> > +  * st_slim_rproc_put() - put slim rproc resources
> > +  * @slim_rproc: Pointer to the st_slim_rproc struct
> > +  *
> > +  * Function for calling respective _put() functions on slim_rproc resources.
> > +  *
> > +  */
> > +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk;
> > +
> > +	if (!slim_rproc)
> > +		return;
> > +
> > +	slim_clk_disable(slim_rproc);
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> > +		clk_put(slim_rproc->clks[clk]);
> > +
> > +	rproc_del(slim_rproc->rproc);
> > +	rproc_put(slim_rproc->rproc);
> > +}
> > +EXPORT_SYMBOL(st_slim_rproc_put);
> > +
> > +MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
> > +MODULE_DESCRIPTION("STMicroelectronics SLIM core rproc driver");
> > +MODULE_LICENSE("GPL v2");
> > diff --git a/include/linux/remoteproc/st_slim_rproc.h b/include/linux/remoteproc/st_slim_rproc.h
> > new file mode 100644
> > index 0000000..4155556
> > --- /dev/null
> > +++ b/include/linux/remoteproc/st_slim_rproc.h
> > @@ -0,0 +1,58 @@
> > +/*
> > + * SLIM core rproc driver header
> > + *
> > + * Copyright (C) 2016 STMicroelectronics
> > + *
> > + * Author: Peter Griffin <peter.griffin@linaro.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +#ifndef _ST_REMOTEPROC_SLIM_H
> > +#define _ST_REMOTEPROC_SLIM_H
> > +
> > +#define ST_SLIM_MEM_MAX 2
> > +#define ST_SLIM_MAX_CLK 4
> > +
> > +enum {
> > +	ST_SLIM_DMEM,
> > +	ST_SLIM_IMEM,
> > +};
> > +
> > +/**
> > + * struct st_slim_mem - slim internal memory structure
> > + * @cpu_addr: MPU virtual address of the memory region
> > + * @bus_addr: Bus address used to access the memory region
> > + * @size: Size of the memory region
> > + */
> > +struct st_slim_mem {
> > +	void __iomem *cpu_addr;
> > +	phys_addr_t bus_addr;
> > +	size_t size;
> > +};
> > +
> > +/**
> > + * struct st_slim_rproc - SLIM slim core
> > + * @rproc: rproc handle
> > + * @mem: slim memory information
> > + * @slimcore: slim slimcore regs
> > + * @peri: slim peripheral regs
> > + * @clks: slim clocks
> > + */
> > +struct st_slim_rproc {
> > +	struct rproc *rproc;
> > +	struct st_slim_mem mem[ST_SLIM_MEM_MAX];
> > +	void __iomem *slimcore;
> > +	void __iomem *peri;
> > +
> > +	/* st_slim_rproc private */
> > +	struct clk *clks[ST_SLIM_MAX_CLK];
> > +};
> > +
> > +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> > +					char *fw_name);
> > +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc);
> > +
> > +#endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver
@ 2016-09-14  8:30       ` Lee Jones
  0 siblings, 0 replies; 174+ messages in thread
From: Lee Jones @ 2016-09-14  8:30 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 13 Sep 2016, Bjorn Andersson wrote:

> On Mon 05 Sep 06:16 PDT 2016, Peter Griffin wrote:
> 
> > slim core is used as a basis for many IPs in the STi
> > chipsets such as fdma and demux. To avoid duplicating
> > the elf loading code in each device driver a slim
> > rproc driver has been created.
> > 
> > This driver is designed to be used by other device drivers
> > such as fdma, or demux whose IP is based around a slim core.
> > The device driver can call slim_rproc_alloc() to allocate
> > a slim rproc and slim_rproc_put() when finished.
> > 
> > This driver takes care of ioremapping the slim
> > registers (dmem, imem, slimcore, peripherals), whose offsets
> > and sizes can change between IP's. It also obtains and enables
> > any clocks used by the device. This approach avoids having
> > a double mapping of the registers as slim_rproc does not register
> > its own platform device. It also maps well to device tree
> > abstraction as it allows us to have one dt node for the whole
> > device.
> > 
> > All of the generic rproc elf loading code can be reused, and
> > we provide start() stop() hooks to start and stop the slim
> > core once the firmware has been loaded. This has been tested
> > successfully with fdma driver.
> > 
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> 
> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>

What's preventing this from being applied right away?

> > ---
> >  drivers/remoteproc/Kconfig               |   4 +
> >  drivers/remoteproc/Makefile              |   1 +
> >  drivers/remoteproc/st_slim_rproc.c       | 364 +++++++++++++++++++++++++++++++
> >  include/linux/remoteproc/st_slim_rproc.h |  58 +++++
> >  4 files changed, 427 insertions(+)
> >  create mode 100644 drivers/remoteproc/st_slim_rproc.c
> >  create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> > 
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index 1a8bf76a..a7bedc6 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -100,4 +100,8 @@ config ST_REMOTEPROC
> >  	  processor framework.
> >  	  This can be either built-in or a loadable module.
> >  
> > +config ST_SLIM_REMOTEPROC
> > +	tristate
> > +	select REMOTEPROC
> > +
> >  endmenu
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 92d3758..db1dae7 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -14,3 +14,4 @@ obj-$(CONFIG_DA8XX_REMOTEPROC)		+= da8xx_remoteproc.o
> >  obj-$(CONFIG_QCOM_MDT_LOADER)		+= qcom_mdt_loader.o
> >  obj-$(CONFIG_QCOM_Q6V5_PIL)		+= qcom_q6v5_pil.o
> >  obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
> > +obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
> > diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> > new file mode 100644
> > index 0000000..1484e97
> > --- /dev/null
> > +++ b/drivers/remoteproc/st_slim_rproc.c
> > @@ -0,0 +1,364 @@
> > +/*
> > + * SLIM core rproc driver
> > + *
> > + * Copyright (C) 2016 STMicroelectronics
> > + *
> > + * Author: Peter Griffin <peter.griffin@linaro.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/err.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/remoteproc.h>
> > +#include <linux/remoteproc/st_slim_rproc.h>
> > +#include "remoteproc_internal.h"
> > +
> > +/* SLIM core registers */
> > +#define SLIM_ID_OFST		0x0
> > +#define SLIM_VER_OFST		0x4
> > +
> > +#define SLIM_EN_OFST		0x8
> > +#define SLIM_EN_RUN			BIT(0)
> > +
> > +#define SLIM_CLK_GATE_OFST	0xC
> > +#define SLIM_CLK_GATE_DIS		BIT(0)
> > +#define SLIM_CLK_GATE_RESET		BIT(2)
> > +
> > +#define SLIM_SLIM_PC_OFST	0x20
> > +
> > +/* DMEM registers */
> > +#define SLIM_REV_ID_OFST	0x0
> > +#define SLIM_REV_ID_MIN_MASK		GENMASK(15, 8)
> > +#define SLIM_REV_ID_MIN(id)		((id & SLIM_REV_ID_MIN_MASK) >> 8)
> > +#define SLIM_REV_ID_MAJ_MASK		GENMASK(23, 16)
> > +#define SLIM_REV_ID_MAJ(id)		((id & SLIM_REV_ID_MAJ_MASK) >> 16)
> > +
> > +
> > +/* peripherals registers */
> > +#define SLIM_STBUS_SYNC_OFST	0xF88
> > +#define SLIM_STBUS_SYNC_DIS		BIT(0)
> > +
> > +#define SLIM_INT_SET_OFST	0xFD4
> > +#define SLIM_INT_CLR_OFST	0xFD8
> > +#define SLIM_INT_MASK_OFST	0xFDC
> > +
> > +#define SLIM_CMD_CLR_OFST	0xFC8
> > +#define SLIM_CMD_MASK_OFST	0xFCC
> > +
> > +static const char *mem_names[ST_SLIM_MEM_MAX] = {
> > +	[ST_SLIM_DMEM]	= "dmem",
> > +	[ST_SLIM_IMEM]	= "imem",
> > +};
> > +
> > +static int slim_clk_get(struct st_slim_rproc *slim_rproc, struct device *dev)
> > +{
> > +	int clk, err;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK; clk++) {
> > +		slim_rproc->clks[clk] = of_clk_get(dev->of_node, clk);
> > +		if (IS_ERR(slim_rproc->clks[clk])) {
> > +			err = PTR_ERR(slim_rproc->clks[clk]);
> > +			if (err == -EPROBE_DEFER)
> > +				goto err_put_clks;
> > +			slim_rproc->clks[clk] = NULL;
> > +			break;
> > +		}
> > +	}
> > +
> > +	return 0;
> > +
> > +err_put_clks:
> > +	while (--clk >= 0)
> > +		clk_put(slim_rproc->clks[clk]);
> > +
> > +	return err;
> > +}
> > +
> > +static void slim_clk_disable(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> > +		clk_disable_unprepare(slim_rproc->clks[clk]);
> > +}
> > +
> > +static int slim_clk_enable(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk, ret;
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++) {
> > +		ret = clk_prepare_enable(slim_rproc->clks[clk]);
> > +		if (ret)
> > +			goto err_disable_clks;
> > +	}
> > +
> > +	return 0;
> > +
> > +err_disable_clks:
> > +	while (--clk >= 0)
> > +		clk_disable_unprepare(slim_rproc->clks[clk]);
> > +
> > +	return ret;
> > +}
> > +
> > +/*
> > + * Remoteproc slim specific device handlers
> > + */
> > +static int slim_rproc_start(struct rproc *rproc)
> > +{
> > +	struct device *dev = &rproc->dev;
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	unsigned long hw_id, hw_ver, fw_rev;
> > +	u32 val;
> > +
> > +	/* disable CPU pipeline clock & reset CPU pipeline */
> > +	val = SLIM_CLK_GATE_DIS | SLIM_CLK_GATE_RESET;
> > +	writel(val, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	/* disable SLIM core STBus sync */
> > +	writel(SLIM_STBUS_SYNC_DIS, slim_rproc->peri + SLIM_STBUS_SYNC_OFST);
> > +
> > +	/* enable cpu pipeline clock */
> > +	writel(!SLIM_CLK_GATE_DIS,
> > +		slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	/* clear int & cmd mailbox */
> > +	writel(~0U, slim_rproc->peri + SLIM_INT_CLR_OFST);
> > +	writel(~0U, slim_rproc->peri + SLIM_CMD_CLR_OFST);
> > +
> > +	/* enable all channels cmd & int */
> > +	writel(~0U, slim_rproc->peri + SLIM_INT_MASK_OFST);
> > +	writel(~0U, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> > +
> > +	/* enable cpu */
> > +	writel(SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> > +
> > +	hw_id = readl_relaxed(slim_rproc->slimcore + SLIM_ID_OFST);
> > +	hw_ver = readl_relaxed(slim_rproc->slimcore + SLIM_VER_OFST);
> > +
> > +	fw_rev = readl(slim_rproc->mem[ST_SLIM_DMEM].cpu_addr +
> > +			SLIM_REV_ID_OFST);
> > +
> > +	dev_info(dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
> > +		 SLIM_REV_ID_MAJ(fw_rev), SLIM_REV_ID_MIN(fw_rev),
> > +		 hw_id, hw_ver);
> > +
> > +	return 0;
> > +}
> > +
> > +static int slim_rproc_stop(struct rproc *rproc)
> > +{
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	u32 val;
> > +
> > +	/* mask all (cmd & int) channels */
> > +	writel(0UL, slim_rproc->peri + SLIM_INT_MASK_OFST);
> > +	writel(0UL, slim_rproc->peri + SLIM_CMD_MASK_OFST);
> > +
> > +	/* disable cpu pipeline clock */
> > +	writel(SLIM_CLK_GATE_DIS, slim_rproc->slimcore + SLIM_CLK_GATE_OFST);
> > +
> > +	writel(!SLIM_EN_RUN, slim_rproc->slimcore + SLIM_EN_OFST);
> > +
> > +	val = readl(slim_rproc->slimcore + SLIM_EN_OFST);
> > +	if (val & SLIM_EN_RUN)
> > +		dev_warn(&rproc->dev, "Failed to disable SLIM");
> > +
> > +	dev_dbg(&rproc->dev, "slim stopped\n");
> > +
> > +	return 0;
> > +}
> > +
> > +static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
> > +{
> > +	struct st_slim_rproc *slim_rproc = rproc->priv;
> > +	void *va = NULL;
> > +	int i;
> > +
> > +	for (i = 0; i < ST_SLIM_MEM_MAX; i++) {
> > +		if (da != slim_rproc->mem[i].bus_addr)
> > +			continue;
> > +
> > +		if (len <= slim_rproc->mem[i].size) {
> > +			/* __force to make sparse happy with type conversion */
> > +			va = (__force void *)slim_rproc->mem[i].cpu_addr;
> > +			break;
> > +		}
> > +	}
> > +
> > +	dev_dbg(&rproc->dev, "da = 0x%llx len = 0x%x va = 0x%p\n", da, len, va);
> > +
> > +	return va;
> > +}
> > +
> > +static struct rproc_ops slim_rproc_ops = {
> > +	.start		= slim_rproc_start,
> > +	.stop		= slim_rproc_stop,
> > +	.da_to_va       = slim_rproc_da_to_va,
> > +};
> > +
> > +/*
> > + * Firmware handler operations: sanity, boot address, load ...
> > + */
> > +
> > +static struct resource_table empty_rsc_tbl = {
> > +	.ver = 1,
> > +	.num = 0,
> > +};
> > +
> > +static struct resource_table *slim_rproc_find_rsc_table(struct rproc *rproc,
> > +					       const struct firmware *fw,
> > +					       int *tablesz)
> > +{
> > +	*tablesz = sizeof(empty_rsc_tbl);
> > +	return &empty_rsc_tbl;
> > +}
> > +
> > +static struct rproc_fw_ops slim_rproc_fw_ops = {
> > +	.find_rsc_table = slim_rproc_find_rsc_table,
> > +};
> > +
> > +/**
> > + * st_slim_rproc_alloc() - allocate and initialise slim rproc
> > + * @pdev: Pointer to the platform_device struct
> > + * @fw_name: Name of firmware for rproc to use
> > + *
> > + * Function for allocating and initialising a slim rproc for use by
> > + * device drivers whose IP is based around the SLIM core. It
> > + * obtains and enables any clocks required by the SLIM core and also
> > + * ioremaps the various IO.
> > + *
> > + * Returns st_slim_rproc pointer or PTR_ERR() on error.
> > + */
> > +
> > +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> > +				char *fw_name)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct st_slim_rproc *slim_rproc;
> > +	struct device_node *np = dev->of_node;
> > +	struct rproc *rproc;
> > +	struct resource *res;
> > +	int err, i;
> > +	const struct rproc_fw_ops *elf_ops;
> > +
> > +	if (!fw_name)
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	if (!of_device_is_compatible(np, "st,slim-rproc"))
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> > +			fw_name, sizeof(*slim_rproc));
> > +	if (!rproc)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	rproc->has_iommu = false;
> > +
> > +	slim_rproc = rproc->priv;
> > +	slim_rproc->rproc = rproc;
> > +
> > +	elf_ops = rproc->fw_ops;
> > +	/* Use some generic elf ops */
> > +	slim_rproc_fw_ops.load = elf_ops->load;
> > +	slim_rproc_fw_ops.sanity_check = elf_ops->sanity_check;
> > +
> > +	rproc->fw_ops = &slim_rproc_fw_ops;
> > +
> > +	/* get imem and dmem */
> > +	for (i = 0; i < ARRAY_SIZE(mem_names); i++) {
> > +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > +						mem_names[i]);
> > +
> > +		slim_rproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
> > +		if (IS_ERR(slim_rproc->mem[i].cpu_addr)) {
> > +			dev_err(&pdev->dev, "devm_ioremap_resource failed\n");
> > +			err = PTR_ERR(slim_rproc->mem[i].cpu_addr);
> > +			goto err;
> > +		}
> > +		slim_rproc->mem[i].bus_addr = res->start;
> > +		slim_rproc->mem[i].size = resource_size(res);
> > +	}
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "slimcore");
> > +	slim_rproc->slimcore = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(slim_rproc->slimcore)) {
> > +		dev_err(&pdev->dev, "failed to ioremap slimcore IO\n");
> > +		err = PTR_ERR(slim_rproc->slimcore);
> > +		goto err;
> > +	}
> > +
> > +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "peripherals");
> > +	slim_rproc->peri = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(slim_rproc->peri)) {
> > +		dev_err(&pdev->dev, "failed to ioremap peripherals IO\n");
> > +		err = PTR_ERR(slim_rproc->peri);
> > +		goto err;
> > +	}
> > +
> > +	err = slim_clk_get(slim_rproc, dev);
> > +	if (err)
> > +		goto err;
> > +
> > +	err = slim_clk_enable(slim_rproc);
> > +	if (err) {
> > +		dev_err(dev, "Failed to enable clocks\n");
> > +		goto err_clk_put;
> > +	}
> > +
> > +	/* Register as a remoteproc device */
> > +	err = rproc_add(rproc);
> > +	if (err) {
> > +		dev_err(dev, "registration of slim remoteproc failed\n");
> > +		goto err_clk_dis;
> > +	}
> > +
> > +	return slim_rproc;
> > +
> > +err_clk_dis:
> > +	slim_clk_disable(slim_rproc);
> > +err_clk_put:
> > +	for (i = 0; i < ST_SLIM_MAX_CLK && slim_rproc->clks[i]; i++)
> > +		clk_put(slim_rproc->clks[i]);
> > +err:
> > +	rproc_put(rproc);
> > +	return ERR_PTR(err);
> > +}
> > +EXPORT_SYMBOL(st_slim_rproc_alloc);
> > +
> > +/**
> > +  * st_slim_rproc_put() - put slim rproc resources
> > +  * @slim_rproc: Pointer to the st_slim_rproc struct
> > +  *
> > +  * Function for calling respective _put() functions on slim_rproc resources.
> > +  *
> > +  */
> > +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc)
> > +{
> > +	int clk;
> > +
> > +	if (!slim_rproc)
> > +		return;
> > +
> > +	slim_clk_disable(slim_rproc);
> > +
> > +	for (clk = 0; clk < ST_SLIM_MAX_CLK && slim_rproc->clks[clk]; clk++)
> > +		clk_put(slim_rproc->clks[clk]);
> > +
> > +	rproc_del(slim_rproc->rproc);
> > +	rproc_put(slim_rproc->rproc);
> > +}
> > +EXPORT_SYMBOL(st_slim_rproc_put);
> > +
> > +MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
> > +MODULE_DESCRIPTION("STMicroelectronics SLIM core rproc driver");
> > +MODULE_LICENSE("GPL v2");
> > diff --git a/include/linux/remoteproc/st_slim_rproc.h b/include/linux/remoteproc/st_slim_rproc.h
> > new file mode 100644
> > index 0000000..4155556
> > --- /dev/null
> > +++ b/include/linux/remoteproc/st_slim_rproc.h
> > @@ -0,0 +1,58 @@
> > +/*
> > + * SLIM core rproc driver header
> > + *
> > + * Copyright (C) 2016 STMicroelectronics
> > + *
> > + * Author: Peter Griffin <peter.griffin@linaro.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +#ifndef _ST_REMOTEPROC_SLIM_H
> > +#define _ST_REMOTEPROC_SLIM_H
> > +
> > +#define ST_SLIM_MEM_MAX 2
> > +#define ST_SLIM_MAX_CLK 4
> > +
> > +enum {
> > +	ST_SLIM_DMEM,
> > +	ST_SLIM_IMEM,
> > +};
> > +
> > +/**
> > + * struct st_slim_mem - slim internal memory structure
> > + * @cpu_addr: MPU virtual address of the memory region
> > + * @bus_addr: Bus address used to access the memory region
> > + * @size: Size of the memory region
> > + */
> > +struct st_slim_mem {
> > +	void __iomem *cpu_addr;
> > +	phys_addr_t bus_addr;
> > +	size_t size;
> > +};
> > +
> > +/**
> > + * struct st_slim_rproc - SLIM slim core
> > + * @rproc: rproc handle
> > + * @mem: slim memory information
> > + * @slimcore: slim slimcore regs
> > + * @peri: slim peripheral regs
> > + * @clks: slim clocks
> > + */
> > +struct st_slim_rproc {
> > +	struct rproc *rproc;
> > +	struct st_slim_mem mem[ST_SLIM_MEM_MAX];
> > +	void __iomem *slimcore;
> > +	void __iomem *peri;
> > +
> > +	/* st_slim_rproc private */
> > +	struct clk *clks[ST_SLIM_MAX_CLK];
> > +};
> > +
> > +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> > +					char *fw_name);
> > +void st_slim_rproc_put(struct st_slim_rproc *slim_rproc);
> > +
> > +#endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
  2016-09-05 13:16   ` Peter Griffin
  (?)
  (?)
@ 2016-09-14 11:59     ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 11:59 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> These nodes are required to get the fdma driver working
> on STiH407 based silicon.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 52 +++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index d294e82..45cab30 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -821,5 +821,57 @@
>  			clock-frequency	= <600000000>;
>  			st,syscfg	= <&syscfg_core 0x224>;
>  		};
> +
> +		/* fdma audio */
> +		fdma0: dma-controller@8e20000 {
> +			compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
> +			reg = <0x8e20000 0x8000>,
> +			      <0x8e30000 0x3000>,
> +			      <0x8e37000 0x1000>,
> +			      <0x8e38000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +		};
> +
> +		/* fdma app */
> +		fdma1: dma-controller@8e40000 {
> +			compatible = "st,stih407-fdma-mpe31-12", "st,slim-rproc";
> +			reg = <0x8e40000 0x8000>,
> +			      <0x8e50000 0x3000>,
> +			      <0x8e57000 0x1000>,
> +			      <0x8e58000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +
> +			interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +		};
> +
> +		/* fdma free running */
> +		fdma2: dma-controller@8e60000 {
> +			compatible = "st,stih407-fdma-mpe31-13", "st,slim-rproc";
> +			reg = <0x8e60000 0x8000>,
> +			      <0x8e70000 0x3000>,
> +			      <0x8e77000 0x1000>,
> +			      <0x8e78000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			interrupts = <GIC_SPI 9 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +		};
>  	};
>  };
> 

Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
@ 2016-09-14 11:59     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 11:59 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> These nodes are required to get the fdma driver working
> on STiH407 based silicon.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 52 +++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index d294e82..45cab30 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -821,5 +821,57 @@
>  			clock-frequency	= <600000000>;
>  			st,syscfg	= <&syscfg_core 0x224>;
>  		};
> +
> +		/* fdma audio */
> +		fdma0: dma-controller@8e20000 {
> +			compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
> +			reg = <0x8e20000 0x8000>,
> +			      <0x8e30000 0x3000>,
> +			      <0x8e37000 0x1000>,
> +			      <0x8e38000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +		};
> +
> +		/* fdma app */
> +		fdma1: dma-controller@8e40000 {
> +			compatible = "st,stih407-fdma-mpe31-12", "st,slim-rproc";
> +			reg = <0x8e40000 0x8000>,
> +			      <0x8e50000 0x3000>,
> +			      <0x8e57000 0x1000>,
> +			      <0x8e58000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +
> +			interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +		};
> +
> +		/* fdma free running */
> +		fdma2: dma-controller@8e60000 {
> +			compatible = "st,stih407-fdma-mpe31-13", "st,slim-rproc";
> +			reg = <0x8e60000 0x8000>,
> +			      <0x8e70000 0x3000>,
> +			      <0x8e77000 0x1000>,
> +			      <0x8e78000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			interrupts = <GIC_SPI 9 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +		};
>  	};
>  };
> 

Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
@ 2016-09-14 11:59     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 11:59 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, airlied-cv59FeDIM0c,
	kraxel-H+wXaHxf7aLQT0dZR+AlfA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
	bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A
  Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> These nodes are required to get the fdma driver working
> on STiH407 based silicon.
> 
> Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 52 +++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index d294e82..45cab30 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -821,5 +821,57 @@
>  			clock-frequency	= <600000000>;
>  			st,syscfg	= <&syscfg_core 0x224>;
>  		};
> +
> +		/* fdma audio */
> +		fdma0: dma-controller@8e20000 {
> +			compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
> +			reg = <0x8e20000 0x8000>,
> +			      <0x8e30000 0x3000>,
> +			      <0x8e37000 0x1000>,
> +			      <0x8e38000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +		};
> +
> +		/* fdma app */
> +		fdma1: dma-controller@8e40000 {
> +			compatible = "st,stih407-fdma-mpe31-12", "st,slim-rproc";
> +			reg = <0x8e40000 0x8000>,
> +			      <0x8e50000 0x3000>,
> +			      <0x8e57000 0x1000>,
> +			      <0x8e58000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +
> +			interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +		};
> +
> +		/* fdma free running */
> +		fdma2: dma-controller@8e60000 {
> +			compatible = "st,stih407-fdma-mpe31-13", "st,slim-rproc";
> +			reg = <0x8e60000 0x8000>,
> +			      <0x8e70000 0x3000>,
> +			      <0x8e77000 0x1000>,
> +			      <0x8e78000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			interrupts = <GIC_SPI 9 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +		};
>  	};
>  };
> 

Applied for STi next

Thanks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
  2016-09-05 13:16   ` Peter Griffin
                     ` (2 preceding siblings ...)
  (?)
@ 2016-09-14 11:59   ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 11:59 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, linux-remoteproc, dri-devel, virtualization,
	dmaengine, lee.jones

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> These nodes are required to get the fdma driver working
> on STiH407 based silicon.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 52 +++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index d294e82..45cab30 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -821,5 +821,57 @@
>  			clock-frequency	= <600000000>;
>  			st,syscfg	= <&syscfg_core 0x224>;
>  		};
> +
> +		/* fdma audio */
> +		fdma0: dma-controller@8e20000 {
> +			compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
> +			reg = <0x8e20000 0x8000>,
> +			      <0x8e30000 0x3000>,
> +			      <0x8e37000 0x1000>,
> +			      <0x8e38000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +		};
> +
> +		/* fdma app */
> +		fdma1: dma-controller@8e40000 {
> +			compatible = "st,stih407-fdma-mpe31-12", "st,slim-rproc";
> +			reg = <0x8e40000 0x8000>,
> +			      <0x8e50000 0x3000>,
> +			      <0x8e57000 0x1000>,
> +			      <0x8e58000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +
> +			interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +		};
> +
> +		/* fdma free running */
> +		fdma2: dma-controller@8e60000 {
> +			compatible = "st,stih407-fdma-mpe31-13", "st,slim-rproc";
> +			reg = <0x8e60000 0x8000>,
> +			      <0x8e70000 0x3000>,
> +			      <0x8e77000 0x1000>,
> +			      <0x8e78000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			interrupts = <GIC_SPI 9 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +		};
>  	};
>  };
> 

Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
@ 2016-09-14 11:59     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 11:59 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> These nodes are required to get the fdma driver working
> on STiH407 based silicon.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 52 +++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index d294e82..45cab30 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -821,5 +821,57 @@
>  			clock-frequency	= <600000000>;
>  			st,syscfg	= <&syscfg_core 0x224>;
>  		};
> +
> +		/* fdma audio */
> +		fdma0: dma-controller at 8e20000 {
> +			compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
> +			reg = <0x8e20000 0x8000>,
> +			      <0x8e30000 0x3000>,
> +			      <0x8e37000 0x1000>,
> +			      <0x8e38000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +		};
> +
> +		/* fdma app */
> +		fdma1: dma-controller at 8e40000 {
> +			compatible = "st,stih407-fdma-mpe31-12", "st,slim-rproc";
> +			reg = <0x8e40000 0x8000>,
> +			      <0x8e50000 0x3000>,
> +			      <0x8e57000 0x1000>,
> +			      <0x8e58000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +
> +			interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +		};
> +
> +		/* fdma free running */
> +		fdma2: dma-controller at 8e60000 {
> +			compatible = "st,stih407-fdma-mpe31-13", "st,slim-rproc";
> +			reg = <0x8e60000 0x8000>,
> +			      <0x8e70000 0x3000>,
> +			      <0x8e77000 0x1000>,
> +			      <0x8e78000 0x8000>;
> +			reg-names = "slimcore", "dmem", "peripherals", "imem";
> +			interrupts = <GIC_SPI 9 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
> +				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +		};
>  	};
>  };
> 

Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 10/19] ARM: DT: STiH407: Add i2s_out pinctrl configuration
  2016-09-05 13:16   ` Peter Griffin
  (?)
@ 2016-09-14 12:00     ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_out pins
> used by the uniperif player IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index a538ae5..0fb5c8a 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1067,6 +1067,29 @@
>  				};
>  			};
>  
> +			i2s_out {
> +				pinctrl_i2s_8ch_out: i2s_8ch_out{
> +					st,pins {
> +						mclk = <&pio33 5 ALT1 OUT>;
> +						lrclk = <&pio33 7 ALT1 OUT>;
> +						sclk = <&pio33 6 ALT1 OUT>;
> +						data0 = <&pio33 4 ALT1 OUT>;
> +						data1 = <&pio34 0 ALT1 OUT>;
> +						data2 = <&pio34 1 ALT1 OUT>;
> +						data3 = <&pio34 2 ALT1 OUT>;
> +					};
> +				};
> +
> +				pinctrl_i2s_2ch_out: i2s_2ch_out{
> +					st,pins {
> +						mclk = <&pio33 5 ALT1 OUT>;
> +						lrclk = <&pio33 7 ALT1 OUT>;
> +						sclk = <&pio33 6 ALT1 OUT>;
> +						data0 = <&pio33 4 ALT1 OUT>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 10/19] ARM: DT: STiH407: Add i2s_out pinctrl configuration
@ 2016-09-14 12:00     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_out pins
> used by the uniperif player IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index a538ae5..0fb5c8a 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1067,6 +1067,29 @@
>  				};
>  			};
>  
> +			i2s_out {
> +				pinctrl_i2s_8ch_out: i2s_8ch_out{
> +					st,pins {
> +						mclk = <&pio33 5 ALT1 OUT>;
> +						lrclk = <&pio33 7 ALT1 OUT>;
> +						sclk = <&pio33 6 ALT1 OUT>;
> +						data0 = <&pio33 4 ALT1 OUT>;
> +						data1 = <&pio34 0 ALT1 OUT>;
> +						data2 = <&pio34 1 ALT1 OUT>;
> +						data3 = <&pio34 2 ALT1 OUT>;
> +					};
> +				};
> +
> +				pinctrl_i2s_2ch_out: i2s_2ch_out{
> +					st,pins {
> +						mclk = <&pio33 5 ALT1 OUT>;
> +						lrclk = <&pio33 7 ALT1 OUT>;
> +						sclk = <&pio33 6 ALT1 OUT>;
> +						data0 = <&pio33 4 ALT1 OUT>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 10/19] ARM: DT: STiH407: Add i2s_out pinctrl configuration
  2016-09-05 13:16   ` Peter Griffin
  (?)
  (?)
@ 2016-09-14 12:00   ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, dmaengine, lee.jones

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_out pins
> used by the uniperif player IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index a538ae5..0fb5c8a 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1067,6 +1067,29 @@
>  				};
>  			};
>  
> +			i2s_out {
> +				pinctrl_i2s_8ch_out: i2s_8ch_out{
> +					st,pins {
> +						mclk = <&pio33 5 ALT1 OUT>;
> +						lrclk = <&pio33 7 ALT1 OUT>;
> +						sclk = <&pio33 6 ALT1 OUT>;
> +						data0 = <&pio33 4 ALT1 OUT>;
> +						data1 = <&pio34 0 ALT1 OUT>;
> +						data2 = <&pio34 1 ALT1 OUT>;
> +						data3 = <&pio34 2 ALT1 OUT>;
> +					};
> +				};
> +
> +				pinctrl_i2s_2ch_out: i2s_2ch_out{
> +					st,pins {
> +						mclk = <&pio33 5 ALT1 OUT>;
> +						lrclk = <&pio33 7 ALT1 OUT>;
> +						sclk = <&pio33 6 ALT1 OUT>;
> +						data0 = <&pio33 4 ALT1 OUT>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 10/19] ARM: DT: STiH407: Add i2s_out pinctrl configuration
@ 2016-09-14 12:00     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_out pins
> used by the uniperif player IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index a538ae5..0fb5c8a 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1067,6 +1067,29 @@
>  				};
>  			};
>  
> +			i2s_out {
> +				pinctrl_i2s_8ch_out: i2s_8ch_out{
> +					st,pins {
> +						mclk = <&pio33 5 ALT1 OUT>;
> +						lrclk = <&pio33 7 ALT1 OUT>;
> +						sclk = <&pio33 6 ALT1 OUT>;
> +						data0 = <&pio33 4 ALT1 OUT>;
> +						data1 = <&pio34 0 ALT1 OUT>;
> +						data2 = <&pio34 1 ALT1 OUT>;
> +						data3 = <&pio34 2 ALT1 OUT>;
> +					};
> +				};
> +
> +				pinctrl_i2s_2ch_out: i2s_2ch_out{
> +					st,pins {
> +						mclk = <&pio33 5 ALT1 OUT>;
> +						lrclk = <&pio33 7 ALT1 OUT>;
> +						sclk = <&pio33 6 ALT1 OUT>;
> +						data0 = <&pio33 4 ALT1 OUT>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in pinctrl configuration
  2016-09-05 13:16   ` Peter Griffin
  (?)
  (?)
@ 2016-09-14 12:00     ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_in pins
> used by the uniperif reader IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 0fb5c8a..537db7e 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1090,6 +1090,30 @@
>  				};
>  			};
>  
> +			i2s_in {
> +				pinctrl_i2s_8ch_in: i2s_8ch_in{
> +					st,pins {
> +						mclk = <&pio32 5 ALT1 IN>;
> +						lrclk = <&pio32 7 ALT1 IN>;
> +						sclk = <&pio32 6 ALT1 IN>;
> +						data0 = <&pio32 4 ALT1 IN>;
> +						data1 = <&pio33 0 ALT1 IN>;
> +						data2 = <&pio33 1 ALT1 IN>;
> +						data3 = <&pio33 2 ALT1 IN>;
> +						data4 = <&pio33 3 ALT1 IN>;
> +					};
> +				};
> +
> +				pinctrl_i2s_2ch_in: i2s_2ch_in{
> +					st,pins {
> +						mclk = <&pio32 5 ALT1 IN>;
> +						lrclk = <&pio32 7 ALT1 IN>;
> +						sclk = <&pio32 6 ALT1 IN>;
> +						data0 = <&pio32 4 ALT1 IN>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in pinctrl configuration
@ 2016-09-14 12:00     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_in pins
> used by the uniperif reader IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 0fb5c8a..537db7e 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1090,6 +1090,30 @@
>  				};
>  			};
>  
> +			i2s_in {
> +				pinctrl_i2s_8ch_in: i2s_8ch_in{
> +					st,pins {
> +						mclk = <&pio32 5 ALT1 IN>;
> +						lrclk = <&pio32 7 ALT1 IN>;
> +						sclk = <&pio32 6 ALT1 IN>;
> +						data0 = <&pio32 4 ALT1 IN>;
> +						data1 = <&pio33 0 ALT1 IN>;
> +						data2 = <&pio33 1 ALT1 IN>;
> +						data3 = <&pio33 2 ALT1 IN>;
> +						data4 = <&pio33 3 ALT1 IN>;
> +					};
> +				};
> +
> +				pinctrl_i2s_2ch_in: i2s_2ch_in{
> +					st,pins {
> +						mclk = <&pio32 5 ALT1 IN>;
> +						lrclk = <&pio32 7 ALT1 IN>;
> +						sclk = <&pio32 6 ALT1 IN>;
> +						data0 = <&pio32 4 ALT1 IN>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in pinctrl configuration
@ 2016-09-14 12:00     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, airlied-cv59FeDIM0c,
	kraxel-H+wXaHxf7aLQT0dZR+AlfA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
	bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A
  Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_in pins
> used by the uniperif reader IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
> Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 0fb5c8a..537db7e 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1090,6 +1090,30 @@
>  				};
>  			};
>  
> +			i2s_in {
> +				pinctrl_i2s_8ch_in: i2s_8ch_in{
> +					st,pins {
> +						mclk = <&pio32 5 ALT1 IN>;
> +						lrclk = <&pio32 7 ALT1 IN>;
> +						sclk = <&pio32 6 ALT1 IN>;
> +						data0 = <&pio32 4 ALT1 IN>;
> +						data1 = <&pio33 0 ALT1 IN>;
> +						data2 = <&pio33 1 ALT1 IN>;
> +						data3 = <&pio33 2 ALT1 IN>;
> +						data4 = <&pio33 3 ALT1 IN>;
> +					};
> +				};
> +
> +				pinctrl_i2s_2ch_in: i2s_2ch_in{
> +					st,pins {
> +						mclk = <&pio32 5 ALT1 IN>;
> +						lrclk = <&pio32 7 ALT1 IN>;
> +						sclk = <&pio32 6 ALT1 IN>;
> +						data0 = <&pio32 4 ALT1 IN>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 



Applied for STi next

Thanks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in pinctrl configuration
  2016-09-05 13:16   ` Peter Griffin
  (?)
  (?)
@ 2016-09-14 12:00   ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, dmaengine, lee.jones

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_in pins
> used by the uniperif reader IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 0fb5c8a..537db7e 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1090,6 +1090,30 @@
>  				};
>  			};
>  
> +			i2s_in {
> +				pinctrl_i2s_8ch_in: i2s_8ch_in{
> +					st,pins {
> +						mclk = <&pio32 5 ALT1 IN>;
> +						lrclk = <&pio32 7 ALT1 IN>;
> +						sclk = <&pio32 6 ALT1 IN>;
> +						data0 = <&pio32 4 ALT1 IN>;
> +						data1 = <&pio33 0 ALT1 IN>;
> +						data2 = <&pio33 1 ALT1 IN>;
> +						data3 = <&pio33 2 ALT1 IN>;
> +						data4 = <&pio33 3 ALT1 IN>;
> +					};
> +				};
> +
> +				pinctrl_i2s_2ch_in: i2s_2ch_in{
> +					st,pins {
> +						mclk = <&pio32 5 ALT1 IN>;
> +						lrclk = <&pio32 7 ALT1 IN>;
> +						sclk = <&pio32 6 ALT1 IN>;
> +						data0 = <&pio32 4 ALT1 IN>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in pinctrl configuration
@ 2016-09-14 12:00     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the i2s_in pins
> used by the uniperif reader IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 0fb5c8a..537db7e 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1090,6 +1090,30 @@
>  				};
>  			};
>  
> +			i2s_in {
> +				pinctrl_i2s_8ch_in: i2s_8ch_in{
> +					st,pins {
> +						mclk = <&pio32 5 ALT1 IN>;
> +						lrclk = <&pio32 7 ALT1 IN>;
> +						sclk = <&pio32 6 ALT1 IN>;
> +						data0 = <&pio32 4 ALT1 IN>;
> +						data1 = <&pio33 0 ALT1 IN>;
> +						data2 = <&pio33 1 ALT1 IN>;
> +						data3 = <&pio33 2 ALT1 IN>;
> +						data4 = <&pio33 3 ALT1 IN>;
> +					};
> +				};
> +
> +				pinctrl_i2s_2ch_in: i2s_2ch_in{
> +					st,pins {
> +						mclk = <&pio32 5 ALT1 IN>;
> +						lrclk = <&pio32 7 ALT1 IN>;
> +						sclk = <&pio32 6 ALT1 IN>;
> +						data0 = <&pio32 4 ALT1 IN>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config
  2016-09-05 13:16   ` Peter Griffin
  (?)
@ 2016-09-14 12:00     ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the spidf out
> pins used by the sasg codec IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 537db7e..598dbab 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1114,6 +1114,14 @@
>  				};
>  			};
>  
> +			spdif_out {
> +				pinctrl_spdif_out: spdif_out{
> +					st,pins {
> +						spdif_out = <&pio34 7 ALT1 OUT>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config
@ 2016-09-14 12:00     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the spidf out
> pins used by the sasg codec IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 537db7e..598dbab 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1114,6 +1114,14 @@
>  				};
>  			};
>  
> +			spdif_out {
> +				pinctrl_spdif_out: spdif_out{
> +					st,pins {
> +						spdif_out = <&pio34 7 ALT1 OUT>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config
  2016-09-05 13:16   ` Peter Griffin
                     ` (2 preceding siblings ...)
  (?)
@ 2016-09-14 12:00   ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, dmaengine, lee.jones

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the spidf out
> pins used by the sasg codec IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 537db7e..598dbab 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1114,6 +1114,14 @@
>  				};
>  			};
>  
> +			spdif_out {
> +				pinctrl_spdif_out: spdif_out{
> +					st,pins {
> +						spdif_out = <&pio34 7 ALT1 OUT>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config
@ 2016-09-14 12:00     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:00 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the pinctrl config for the spidf out
> pins used by the sasg codec IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-pinctrl.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index 537db7e..598dbab 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -1114,6 +1114,14 @@
>  				};
>  			};
>  
> +			spdif_out {
> +				pinctrl_spdif_out: spdif_out{
> +					st,pins {
> +						spdif_out = <&pio34 7 ALT1 OUT>;
> +					};
> +				};
> +			};
> +
>  			serial3 {
>  				pinctrl_serial3: serial3-0 {
>  					st,pins {
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 13/19] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
  2016-09-05 13:16   ` Peter Griffin
  (?)
@ 2016-09-14 12:01     ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the dt node for the internal audio
> codec IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 45cab30..d1258d5 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -873,5 +873,12 @@
>  				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
>  				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
>  		};
> +
> +		sti_sasg_codec: sti-sasg-codec {
> +			compatible = "st,stih407-sas-codec";
> +			#sound-dai-cells = <1>;
> +			status = "disabled";
> +			st,syscfg = <&syscfg_core>;
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 13/19] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
@ 2016-09-14 12:01     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the dt node for the internal audio
> codec IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 45cab30..d1258d5 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -873,5 +873,12 @@
>  				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
>  				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
>  		};
> +
> +		sti_sasg_codec: sti-sasg-codec {
> +			compatible = "st,stih407-sas-codec";
> +			#sound-dai-cells = <1>;
> +			status = "disabled";
> +			st,syscfg = <&syscfg_core>;
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 13/19] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
  2016-09-05 13:16   ` Peter Griffin
  (?)
@ 2016-09-14 12:01   ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, dmaengine, lee.jones

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the dt node for the internal audio
> codec IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 45cab30..d1258d5 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -873,5 +873,12 @@
>  				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
>  				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
>  		};
> +
> +		sti_sasg_codec: sti-sasg-codec {
> +			compatible = "st,stih407-sas-codec";
> +			#sound-dai-cells = <1>;
> +			status = "disabled";
> +			st,syscfg = <&syscfg_core>;
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 13/19] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node
@ 2016-09-14 12:01     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the dt node for the internal audio
> codec IP.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 45cab30..d1258d5 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -873,5 +873,12 @@
>  				<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
>  				<&clk_s_c0_flexgen CLK_EXT2F_A9>;
>  		};
> +
> +		sti_sasg_codec: sti-sasg-codec {
> +			compatible = "st,stih407-sas-codec";
> +			#sound-dai-cells = <1>;
> +			status = "disabled";
> +			st,syscfg = <&syscfg_core>;
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 14/19] ARM: STi: DT: STiH407: Add uniperif player dt nodes
  2016-09-05 13:16   ` Peter Griffin
  (?)
@ 2016-09-14 12:01     ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT nodes for the uniperif player
> IP blocks found on STiH407 family silicon.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 80 +++++++++++++++++++++++++++++++++++
>  1 file changed, 80 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index d1258d5..1edc36c 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -880,5 +880,85 @@
>  			status = "disabled";
>  			st,syscfg = <&syscfg_core>;
>  		};
> +
> +		sti_uni_player0: sti-uni-player@8d80000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_0>;
> +			assigned-clocks = <&clk_s_d0_quadfs 0>, <&clk_s_d0_flexgen CLK_PCM_0>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 0>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d80000 0x158>;
> +			interrupts = <GIC_SPI 84 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 2 0 1>;
> +			dai-name = "Uni Player #0 (HDMI)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <0>;
> +			st,version = <5>;
> +			st,mode = "HDMI";
> +
> +			status		= "disabled";
> +		};
> +
> +		sti_uni_player1: sti-uni-player@8d81000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_1>;
> +			assigned-clocks = <&clk_s_d0_quadfs 1>, <&clk_s_d0_flexgen CLK_PCM_1>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 1>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d81000 0x158>;
> +			interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 3 0 1>;
> +			dai-name = "Uni Player #1 (PIO)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <1>;
> +			st,version = <5>;
> +			st,mode = "PCM";
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_player2: sti-uni-player@8d82000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
> +			assigned-clocks = <&clk_s_d0_quadfs 2>, <&clk_s_d0_flexgen CLK_PCM_2>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 2>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d82000 0x158>;
> +			interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 4 0 1>;
> +			dai-name = "Uni Player #1 (DAC)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <2>;
> +			st,version = <5>;
> +			st,mode = "PCM";
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_player3: sti-uni-player@8d85000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_SPDIFF>;
> +			assigned-clocks = <&clk_s_d0_quadfs 3>, <&clk_s_d0_flexgen CLK_SPDIFF>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 3>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d85000 0x158>;
> +			interrupts = <GIC_SPI 89 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 7 0 1>;
> +			dma-names = "tx";
> +			dai-name = "Uni Player #1 (PIO)";
> +			st,uniperiph-id = <3>;
> +			st,version = <5>;
> +			st,mode = "SPDIF";
> +
> +			status = "disabled";
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 14/19] ARM: STi: DT: STiH407: Add uniperif player dt nodes
@ 2016-09-14 12:01     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT nodes for the uniperif player
> IP blocks found on STiH407 family silicon.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 80 +++++++++++++++++++++++++++++++++++
>  1 file changed, 80 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index d1258d5..1edc36c 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -880,5 +880,85 @@
>  			status = "disabled";
>  			st,syscfg = <&syscfg_core>;
>  		};
> +
> +		sti_uni_player0: sti-uni-player@8d80000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_0>;
> +			assigned-clocks = <&clk_s_d0_quadfs 0>, <&clk_s_d0_flexgen CLK_PCM_0>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 0>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d80000 0x158>;
> +			interrupts = <GIC_SPI 84 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 2 0 1>;
> +			dai-name = "Uni Player #0 (HDMI)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <0>;
> +			st,version = <5>;
> +			st,mode = "HDMI";
> +
> +			status		= "disabled";
> +		};
> +
> +		sti_uni_player1: sti-uni-player@8d81000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_1>;
> +			assigned-clocks = <&clk_s_d0_quadfs 1>, <&clk_s_d0_flexgen CLK_PCM_1>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 1>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d81000 0x158>;
> +			interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 3 0 1>;
> +			dai-name = "Uni Player #1 (PIO)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <1>;
> +			st,version = <5>;
> +			st,mode = "PCM";
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_player2: sti-uni-player@8d82000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
> +			assigned-clocks = <&clk_s_d0_quadfs 2>, <&clk_s_d0_flexgen CLK_PCM_2>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 2>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d82000 0x158>;
> +			interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 4 0 1>;
> +			dai-name = "Uni Player #1 (DAC)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <2>;
> +			st,version = <5>;
> +			st,mode = "PCM";
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_player3: sti-uni-player@8d85000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_SPDIFF>;
> +			assigned-clocks = <&clk_s_d0_quadfs 3>, <&clk_s_d0_flexgen CLK_SPDIFF>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 3>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d85000 0x158>;
> +			interrupts = <GIC_SPI 89 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 7 0 1>;
> +			dma-names = "tx";
> +			dai-name = "Uni Player #1 (PIO)";
> +			st,uniperiph-id = <3>;
> +			st,version = <5>;
> +			st,mode = "SPDIF";
> +
> +			status = "disabled";
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 14/19] ARM: STi: DT: STiH407: Add uniperif player dt nodes
  2016-09-05 13:16   ` Peter Griffin
  (?)
  (?)
@ 2016-09-14 12:01   ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, dmaengine, lee.jones

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT nodes for the uniperif player
> IP blocks found on STiH407 family silicon.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 80 +++++++++++++++++++++++++++++++++++
>  1 file changed, 80 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index d1258d5..1edc36c 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -880,5 +880,85 @@
>  			status = "disabled";
>  			st,syscfg = <&syscfg_core>;
>  		};
> +
> +		sti_uni_player0: sti-uni-player@8d80000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_0>;
> +			assigned-clocks = <&clk_s_d0_quadfs 0>, <&clk_s_d0_flexgen CLK_PCM_0>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 0>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d80000 0x158>;
> +			interrupts = <GIC_SPI 84 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 2 0 1>;
> +			dai-name = "Uni Player #0 (HDMI)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <0>;
> +			st,version = <5>;
> +			st,mode = "HDMI";
> +
> +			status		= "disabled";
> +		};
> +
> +		sti_uni_player1: sti-uni-player@8d81000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_1>;
> +			assigned-clocks = <&clk_s_d0_quadfs 1>, <&clk_s_d0_flexgen CLK_PCM_1>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 1>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d81000 0x158>;
> +			interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 3 0 1>;
> +			dai-name = "Uni Player #1 (PIO)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <1>;
> +			st,version = <5>;
> +			st,mode = "PCM";
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_player2: sti-uni-player@8d82000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
> +			assigned-clocks = <&clk_s_d0_quadfs 2>, <&clk_s_d0_flexgen CLK_PCM_2>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 2>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d82000 0x158>;
> +			interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 4 0 1>;
> +			dai-name = "Uni Player #1 (DAC)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <2>;
> +			st,version = <5>;
> +			st,mode = "PCM";
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_player3: sti-uni-player@8d85000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_SPDIFF>;
> +			assigned-clocks = <&clk_s_d0_quadfs 3>, <&clk_s_d0_flexgen CLK_SPDIFF>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 3>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d85000 0x158>;
> +			interrupts = <GIC_SPI 89 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 7 0 1>;
> +			dma-names = "tx";
> +			dai-name = "Uni Player #1 (PIO)";
> +			st,uniperiph-id = <3>;
> +			st,version = <5>;
> +			st,mode = "SPDIF";
> +
> +			status = "disabled";
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 14/19] ARM: STi: DT: STiH407: Add uniperif player dt nodes
@ 2016-09-14 12:01     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT nodes for the uniperif player
> IP blocks found on STiH407 family silicon.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 80 +++++++++++++++++++++++++++++++++++
>  1 file changed, 80 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index d1258d5..1edc36c 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -880,5 +880,85 @@
>  			status = "disabled";
>  			st,syscfg = <&syscfg_core>;
>  		};
> +
> +		sti_uni_player0: sti-uni-player at 8d80000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_0>;
> +			assigned-clocks = <&clk_s_d0_quadfs 0>, <&clk_s_d0_flexgen CLK_PCM_0>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 0>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d80000 0x158>;
> +			interrupts = <GIC_SPI 84 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 2 0 1>;
> +			dai-name = "Uni Player #0 (HDMI)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <0>;
> +			st,version = <5>;
> +			st,mode = "HDMI";
> +
> +			status		= "disabled";
> +		};
> +
> +		sti_uni_player1: sti-uni-player at 8d81000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_1>;
> +			assigned-clocks = <&clk_s_d0_quadfs 1>, <&clk_s_d0_flexgen CLK_PCM_1>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 1>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d81000 0x158>;
> +			interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 3 0 1>;
> +			dai-name = "Uni Player #1 (PIO)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <1>;
> +			st,version = <5>;
> +			st,mode = "PCM";
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_player2: sti-uni-player at 8d82000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
> +			assigned-clocks = <&clk_s_d0_quadfs 2>, <&clk_s_d0_flexgen CLK_PCM_2>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 2>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d82000 0x158>;
> +			interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 4 0 1>;
> +			dai-name = "Uni Player #1 (DAC)";
> +			dma-names = "tx";
> +			st,uniperiph-id = <2>;
> +			st,version = <5>;
> +			st,mode = "PCM";
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_player3: sti-uni-player at 8d85000 {
> +			compatible = "st,sti-uni-player";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			clocks = <&clk_s_d0_flexgen CLK_SPDIFF>;
> +			assigned-clocks = <&clk_s_d0_quadfs 3>, <&clk_s_d0_flexgen CLK_SPDIFF>;
> +			assigned-clock-parents = <0>, <&clk_s_d0_quadfs 3>;
> +			assigned-clock-rates = <50000000>;
> +			reg = <0x8d85000 0x158>;
> +			interrupts = <GIC_SPI 89 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 7 0 1>;
> +			dma-names = "tx";
> +			dai-name = "Uni Player #1 (PIO)";
> +			st,uniperiph-id = <3>;
> +			st,version = <5>;
> +			st,mode = "SPDIF";
> +
> +			status = "disabled";
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader dt nodes
  2016-09-05 13:16   ` Peter Griffin
  (?)
@ 2016-09-14 12:01     ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT node for the uniperif reader
> IP block found on STiH407 family silicon.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 1edc36c..883019a 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -960,5 +960,33 @@
>  
>  			status = "disabled";
>  		};
> +
> +		sti_uni_reader0: sti-uni-reader@8d83000 {
> +			compatible = "st,sti-uni-reader";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			reg = <0x8d83000 0x158>;
> +			interrupts = <GIC_SPI 87 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 5 0 1>;
> +			dma-names = "rx";
> +			dai-name = "Uni Reader #0 (PCM IN)";
> +			st,version = <3>;
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_reader1: sti-uni-reader@8d84000 {
> +			compatible = "st,sti-uni-reader";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			reg = <0x8d84000 0x158>;
> +			interrupts = <GIC_SPI 88 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 6 0 1>;
> +			dma-names = "rx";
> +			dai-name = "Uni Reader #1 (HDMI RX)";
> +			st,version = <3>;
> +
> +			status = "disabled";
> +		};
>  	};
>  };
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader dt nodes
@ 2016-09-14 12:01     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT node for the uniperif reader
> IP block found on STiH407 family silicon.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 1edc36c..883019a 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -960,5 +960,33 @@
>  
>  			status = "disabled";
>  		};
> +
> +		sti_uni_reader0: sti-uni-reader@8d83000 {
> +			compatible = "st,sti-uni-reader";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			reg = <0x8d83000 0x158>;
> +			interrupts = <GIC_SPI 87 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 5 0 1>;
> +			dma-names = "rx";
> +			dai-name = "Uni Reader #0 (PCM IN)";
> +			st,version = <3>;
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_reader1: sti-uni-reader@8d84000 {
> +			compatible = "st,sti-uni-reader";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			reg = <0x8d84000 0x158>;
> +			interrupts = <GIC_SPI 88 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 6 0 1>;
> +			dma-names = "rx";
> +			dai-name = "Uni Reader #1 (HDMI RX)";
> +			st,version = <3>;
> +
> +			status = "disabled";
> +		};
>  	};
>  };
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader dt nodes
  2016-09-05 13:16   ` Peter Griffin
  (?)
  (?)
@ 2016-09-14 12:01   ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, dmaengine, lee.jones

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT node for the uniperif reader
> IP block found on STiH407 family silicon.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 1edc36c..883019a 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -960,5 +960,33 @@
>  
>  			status = "disabled";
>  		};
> +
> +		sti_uni_reader0: sti-uni-reader@8d83000 {
> +			compatible = "st,sti-uni-reader";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			reg = <0x8d83000 0x158>;
> +			interrupts = <GIC_SPI 87 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 5 0 1>;
> +			dma-names = "rx";
> +			dai-name = "Uni Reader #0 (PCM IN)";
> +			st,version = <3>;
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_reader1: sti-uni-reader@8d84000 {
> +			compatible = "st,sti-uni-reader";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			reg = <0x8d84000 0x158>;
> +			interrupts = <GIC_SPI 88 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 6 0 1>;
> +			dma-names = "rx";
> +			dai-name = "Uni Reader #1 (HDMI RX)";
> +			st,version = <3>;
> +
> +			status = "disabled";
> +		};
>  	};
>  };
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader dt nodes
@ 2016-09-14 12:01     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch adds the DT node for the uniperif reader
> IP block found on STiH407 family silicon.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 1edc36c..883019a 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -960,5 +960,33 @@
>  
>  			status = "disabled";
>  		};
> +
> +		sti_uni_reader0: sti-uni-reader at 8d83000 {
> +			compatible = "st,sti-uni-reader";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			reg = <0x8d83000 0x158>;
> +			interrupts = <GIC_SPI 87 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 5 0 1>;
> +			dma-names = "rx";
> +			dai-name = "Uni Reader #0 (PCM IN)";
> +			st,version = <3>;
> +
> +			status = "disabled";
> +		};
> +
> +		sti_uni_reader1: sti-uni-reader at 8d84000 {
> +			compatible = "st,sti-uni-reader";
> +			#sound-dai-cells = <0>;
> +			st,syscfg = <&syscfg_core>;
> +			reg = <0x8d84000 0x158>;
> +			interrupts = <GIC_SPI 88 IRQ_TYPE_NONE>;
> +			dmas = <&fdma0 6 0 1>;
> +			dma-names = "rx";
> +			dai-name = "Uni Reader #1 (HDMI RX)";
> +			st,version = <3>;
> +
> +			status = "disabled";
> +		};
>  	};
>  };
> 



Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 16/19] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
  2016-09-05 13:16   ` Peter Griffin
  (?)
@ 2016-09-14 12:01     ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch enables the uniperif players 2 & 3 for b2120 boards
> and also adds the "simple-audio-card" device node to interconnect
> the SoC sound device and the codec.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stihxxx-b2120.dtsi | 45 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> index 722c63f..4939501 100644
> --- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
> +++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> @@ -131,5 +131,50 @@
>  				dvb-card	= <STV0367_TDA18212_NIMA_1>;
>  			};
>  		};
> +
> +		sti_uni_player2: sti-uni-player@8d82000 {
> +			status = "okay";
> +		};
> +
> +		sti_uni_player3: sti-uni-player@8d85000 {
> +			status = "okay";
> +		};
> +
> +		sti_sasg_codec: sti-sasg-codec {
> +			status = "okay";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_spdif_out>;
> +		};
> +
> +		sound {
> +			compatible = "simple-audio-card";
> +			simple-audio-card,name = "sti audio card";
> +			status = "okay";
> +
> +			simple-audio-card,dai-link@0 {
> +				/* DAC */
> +				format = "i2s";
> +				mclk-fs = <256>;
> +				cpu {
> +					sound-dai = <&sti_uni_player2>;
> +				};
> +
> +				codec {
> +					sound-dai = <&sti_sasg_codec 1>;
> +				};
> +			};
> +			simple-audio-card,dai-link@1 {
> +				/* SPDIF */
> +				format = "left_j";
> +				mclk-fs = <128>;
> +				cpu {
> +					sound-dai = <&sti_uni_player3>;
> +				};
> +
> +				codec {
> +					sound-dai = <&sti_sasg_codec 0>;
> +				};
> +			};
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 16/19] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
@ 2016-09-14 12:01     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization, Arnaud Pouliquen

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch enables the uniperif players 2 & 3 for b2120 boards
> and also adds the "simple-audio-card" device node to interconnect
> the SoC sound device and the codec.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stihxxx-b2120.dtsi | 45 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> index 722c63f..4939501 100644
> --- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
> +++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> @@ -131,5 +131,50 @@
>  				dvb-card	= <STV0367_TDA18212_NIMA_1>;
>  			};
>  		};
> +
> +		sti_uni_player2: sti-uni-player@8d82000 {
> +			status = "okay";
> +		};
> +
> +		sti_uni_player3: sti-uni-player@8d85000 {
> +			status = "okay";
> +		};
> +
> +		sti_sasg_codec: sti-sasg-codec {
> +			status = "okay";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_spdif_out>;
> +		};
> +
> +		sound {
> +			compatible = "simple-audio-card";
> +			simple-audio-card,name = "sti audio card";
> +			status = "okay";
> +
> +			simple-audio-card,dai-link@0 {
> +				/* DAC */
> +				format = "i2s";
> +				mclk-fs = <256>;
> +				cpu {
> +					sound-dai = <&sti_uni_player2>;
> +				};
> +
> +				codec {
> +					sound-dai = <&sti_sasg_codec 1>;
> +				};
> +			};
> +			simple-audio-card,dai-link@1 {
> +				/* SPDIF */
> +				format = "left_j";
> +				mclk-fs = <128>;
> +				cpu {
> +					sound-dai = <&sti_uni_player3>;
> +				};
> +
> +				codec {
> +					sound-dai = <&sti_sasg_codec 0>;
> +				};
> +			};
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 16/19] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
  2016-09-05 13:16   ` Peter Griffin
  (?)
  (?)
@ 2016-09-14 12:01   ` Patrice Chotard
  -1 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	vinod.koul, dan.j.williams, airlied, kraxel, ohad,
	bjorn.andersson
  Cc: devicetree, Arnaud Pouliquen, linux-remoteproc, dri-devel,
	virtualization, dmaengine, lee.jones

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch enables the uniperif players 2 & 3 for b2120 boards
> and also adds the "simple-audio-card" device node to interconnect
> the SoC sound device and the codec.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stihxxx-b2120.dtsi | 45 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> index 722c63f..4939501 100644
> --- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
> +++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> @@ -131,5 +131,50 @@
>  				dvb-card	= <STV0367_TDA18212_NIMA_1>;
>  			};
>  		};
> +
> +		sti_uni_player2: sti-uni-player@8d82000 {
> +			status = "okay";
> +		};
> +
> +		sti_uni_player3: sti-uni-player@8d85000 {
> +			status = "okay";
> +		};
> +
> +		sti_sasg_codec: sti-sasg-codec {
> +			status = "okay";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_spdif_out>;
> +		};
> +
> +		sound {
> +			compatible = "simple-audio-card";
> +			simple-audio-card,name = "sti audio card";
> +			status = "okay";
> +
> +			simple-audio-card,dai-link@0 {
> +				/* DAC */
> +				format = "i2s";
> +				mclk-fs = <256>;
> +				cpu {
> +					sound-dai = <&sti_uni_player2>;
> +				};
> +
> +				codec {
> +					sound-dai = <&sti_sasg_codec 1>;
> +				};
> +			};
> +			simple-audio-card,dai-link@1 {
> +				/* SPDIF */
> +				format = "left_j";
> +				mclk-fs = <128>;
> +				cpu {
> +					sound-dai = <&sti_uni_player3>;
> +				};
> +
> +				codec {
> +					sound-dai = <&sti_sasg_codec 0>;
> +				};
> +			};
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 16/19] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card
@ 2016-09-14 12:01     ` Patrice Chotard
  0 siblings, 0 replies; 174+ messages in thread
From: Patrice Chotard @ 2016-09-14 12:01 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Peter

On 09/05/2016 03:16 PM, Peter Griffin wrote:
> This patch enables the uniperif players 2 & 3 for b2120 boards
> and also adds the "simple-audio-card" device node to interconnect
> the SoC sound device and the codec.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stihxxx-b2120.dtsi | 45 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> index 722c63f..4939501 100644
> --- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
> +++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
> @@ -131,5 +131,50 @@
>  				dvb-card	= <STV0367_TDA18212_NIMA_1>;
>  			};
>  		};
> +
> +		sti_uni_player2: sti-uni-player at 8d82000 {
> +			status = "okay";
> +		};
> +
> +		sti_uni_player3: sti-uni-player at 8d85000 {
> +			status = "okay";
> +		};
> +
> +		sti_sasg_codec: sti-sasg-codec {
> +			status = "okay";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_spdif_out>;
> +		};
> +
> +		sound {
> +			compatible = "simple-audio-card";
> +			simple-audio-card,name = "sti audio card";
> +			status = "okay";
> +
> +			simple-audio-card,dai-link at 0 {
> +				/* DAC */
> +				format = "i2s";
> +				mclk-fs = <256>;
> +				cpu {
> +					sound-dai = <&sti_uni_player2>;
> +				};
> +
> +				codec {
> +					sound-dai = <&sti_sasg_codec 1>;
> +				};
> +			};
> +			simple-audio-card,dai-link at 1 {
> +				/* SPDIF */
> +				format = "left_j";
> +				mclk-fs = <128>;
> +				cpu {
> +					sound-dai = <&sti_uni_player3>;
> +				};
> +
> +				codec {
> +					sound-dai = <&sti_sasg_codec 0>;
> +				};
> +			};
> +		};
>  	};
>  };
> 


Applied for STi next

Thanks

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
  2016-09-13 18:06     ` Bjorn Andersson
  (?)
@ 2016-09-14 13:07       ` Vinod Koul
  -1 siblings, 0 replies; 174+ messages in thread
From: Vinod Koul @ 2016-09-14 13:07 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization

On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > I hate to send a ping,
> 
> Sorry about that.
> 
> > but do you think we can merge this fdma series? It has gone
> > through quite a few review rounds now.
> > 
> 
> I think the remoteproc part looks good.

yeah I was waiting for ack on other patches. But looks like at least
remoteproc ones have it


> Vinod, I don't have any changes queued in remoteproc that should cause
> merge issues. If you want to you could take the remoteproc patch
> through your tree.

I rechecked the dma part, they look good to me, so I should be able to apply
these. I will wait a day for ack/nacks. It is the time to speak up :)

-- 
~Vinod

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-14 13:07       ` Vinod Koul
  0 siblings, 0 replies; 174+ messages in thread
From: Vinod Koul @ 2016-09-14 13:07 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Peter Griffin, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ, patrice.chotard-qxv4g6HH51o,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, airlied-cv59FeDIM0c,
	kraxel-H+wXaHxf7aLQT0dZR+AlfA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA

On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > I hate to send a ping,
> 
> Sorry about that.
> 
> > but do you think we can merge this fdma series? It has gone
> > through quite a few review rounds now.
> > 
> 
> I think the remoteproc part looks good.

yeah I was waiting for ack on other patches. But looks like at least
remoteproc ones have it


> Vinod, I don't have any changes queued in remoteproc that should cause
> merge issues. If you want to you could take the remoteproc patch
> through your tree.

I rechecked the dma part, they look good to me, so I should be able to apply
these. I will wait a day for ack/nacks. It is the time to speak up :)

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
  2016-09-13 18:06     ` Bjorn Andersson
                       ` (4 preceding siblings ...)
  (?)
@ 2016-09-14 13:07     ` Vinod Koul
  -1 siblings, 0 replies; 174+ messages in thread
From: Vinod Koul @ 2016-09-14 13:07 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: devicetree, kernel, airlied, linux-remoteproc, patrice.chotard,
	dri-devel, linux-kernel, Peter Griffin, dmaengine,
	dan.j.williams, virtualization, lee.jones, linux-arm-kernel

On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > I hate to send a ping,
> 
> Sorry about that.
> 
> > but do you think we can merge this fdma series? It has gone
> > through quite a few review rounds now.
> > 
> 
> I think the remoteproc part looks good.

yeah I was waiting for ack on other patches. But looks like at least
remoteproc ones have it


> Vinod, I don't have any changes queued in remoteproc that should cause
> merge issues. If you want to you could take the remoteproc patch
> through your tree.

I rechecked the dma part, they look good to me, so I should be able to apply
these. I will wait a day for ack/nacks. It is the time to speak up :)

-- 
~Vinod

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-14 13:07       ` Vinod Koul
  0 siblings, 0 replies; 174+ messages in thread
From: Vinod Koul @ 2016-09-14 13:07 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > I hate to send a ping,
> 
> Sorry about that.
> 
> > but do you think we can merge this fdma series? It has gone
> > through quite a few review rounds now.
> > 
> 
> I think the remoteproc part looks good.

yeah I was waiting for ack on other patches. But looks like at least
remoteproc ones have it


> Vinod, I don't have any changes queued in remoteproc that should cause
> merge issues. If you want to you could take the remoteproc patch
> through your tree.

I rechecked the dma part, they look good to me, so I should be able to apply
these. I will wait a day for ack/nacks. It is the time to speak up :)

-- 
~Vinod

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
  2016-09-14 13:07       ` Vinod Koul
  (?)
@ 2016-09-15 16:20         ` Vinod Koul
  -1 siblings, 0 replies; 174+ messages in thread
From: Vinod Koul @ 2016-09-15 16:20 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Peter Griffin, linux-arm-kernel, linux-kernel, kernel,
	patrice.chotard, dan.j.williams, airlied, kraxel, ohad,
	lee.jones, dmaengine, devicetree, dri-devel, linux-remoteproc,
	virtualization

On Wed, Sep 14, 2016 at 06:37:40PM +0530, Vinod Koul wrote:
> On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > > I hate to send a ping,
> > 
> > Sorry about that.
> > 
> > > but do you think we can merge this fdma series? It has gone
> > > through quite a few review rounds now.
> > > 
> > 
> > I think the remoteproc part looks good.
> 
> yeah I was waiting for ack on other patches. But looks like at least
> remoteproc ones have it
> 
> 
> > Vinod, I don't have any changes queued in remoteproc that should cause
> > merge issues. If you want to you could take the remoteproc patch
> > through your tree.
> 
> I rechecked the dma part, they look good to me, so I should be able to apply
> these. I will wait a day for ack/nacks. It is the time to speak up :)

And I have applied thru 9th patch. Others are applied by Patrice.

Btw you should send drm ones to drm folks separately and not in this
series..

Thanks
-- 
~Vinod

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-15 16:20         ` Vinod Koul
  0 siblings, 0 replies; 174+ messages in thread
From: Vinod Koul @ 2016-09-15 16:20 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Peter Griffin, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ, patrice.chotard-qxv4g6HH51o,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, airlied-cv59FeDIM0c,
	kraxel-H+wXaHxf7aLQT0dZR+AlfA, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA

On Wed, Sep 14, 2016 at 06:37:40PM +0530, Vinod Koul wrote:
> On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > > I hate to send a ping,
> > 
> > Sorry about that.
> > 
> > > but do you think we can merge this fdma series? It has gone
> > > through quite a few review rounds now.
> > > 
> > 
> > I think the remoteproc part looks good.
> 
> yeah I was waiting for ack on other patches. But looks like at least
> remoteproc ones have it
> 
> 
> > Vinod, I don't have any changes queued in remoteproc that should cause
> > merge issues. If you want to you could take the remoteproc patch
> > through your tree.
> 
> I rechecked the dma part, they look good to me, so I should be able to apply
> these. I will wait a day for ack/nacks. It is the time to speak up :)

And I have applied thru 9th patch. Others are applied by Patrice.

Btw you should send drm ones to drm folks separately and not in this
series..

Thanks
-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
  2016-09-14 13:07       ` Vinod Koul
  (?)
  (?)
@ 2016-09-15 16:20       ` Vinod Koul
  -1 siblings, 0 replies; 174+ messages in thread
From: Vinod Koul @ 2016-09-15 16:20 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: devicetree, kernel, airlied, linux-remoteproc, patrice.chotard,
	dri-devel, linux-kernel, Peter Griffin, dmaengine,
	dan.j.williams, virtualization, lee.jones, linux-arm-kernel

On Wed, Sep 14, 2016 at 06:37:40PM +0530, Vinod Koul wrote:
> On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > > I hate to send a ping,
> > 
> > Sorry about that.
> > 
> > > but do you think we can merge this fdma series? It has gone
> > > through quite a few review rounds now.
> > > 
> > 
> > I think the remoteproc part looks good.
> 
> yeah I was waiting for ack on other patches. But looks like at least
> remoteproc ones have it
> 
> 
> > Vinod, I don't have any changes queued in remoteproc that should cause
> > merge issues. If you want to you could take the remoteproc patch
> > through your tree.
> 
> I rechecked the dma part, they look good to me, so I should be able to apply
> these. I will wait a day for ack/nacks. It is the time to speak up :)

And I have applied thru 9th patch. Others are applied by Patrice.

Btw you should send drm ones to drm folks separately and not in this
series..

Thanks
-- 
~Vinod

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
@ 2016-09-15 16:20         ` Vinod Koul
  0 siblings, 0 replies; 174+ messages in thread
From: Vinod Koul @ 2016-09-15 16:20 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Sep 14, 2016 at 06:37:40PM +0530, Vinod Koul wrote:
> On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > > I hate to send a ping,
> > 
> > Sorry about that.
> > 
> > > but do you think we can merge this fdma series? It has gone
> > > through quite a few review rounds now.
> > > 
> > 
> > I think the remoteproc part looks good.
> 
> yeah I was waiting for ack on other patches. But looks like at least
> remoteproc ones have it
> 
> 
> > Vinod, I don't have any changes queued in remoteproc that should cause
> > merge issues. If you want to you could take the remoteproc patch
> > through your tree.
> 
> I rechecked the dma part, they look good to me, so I should be able to apply
> these. I will wait a day for ack/nacks. It is the time to speak up :)

And I have applied thru 9th patch. Others are applied by Patrice.

Btw you should send drm ones to drm folks separately and not in this
series..

Thanks
-- 
~Vinod

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-05 13:16   ` Peter Griffin
                       ` (2 preceding siblings ...)
  (?)
@ 2016-09-19 23:18     ` Emil Velikov
  -1 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-09-19 23:18 UTC (permalink / raw)
  To: Peter Griffin
  Cc: LAKML, Linux-Kernel@Vger. Kernel. Org, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, David Airlie, Gerd Hoffmann,
	ohad, bjorn.andersson, devicetree, linux-remoteproc,
	ML dri-devel, open list:VIRTIO GPU DRIVER, dmaengine, lee.jones

On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
>From a humble skim through remoteproc, drm and a few other subsystems
I think the above is wrong. All the drivers (outside of remoteproc),
that I've seen, depend on the core component, they don't select it.

Furthermore most places explicitly hide the drivers from the menu if
the core component isn't enabled.

Is there something that requires such a different/unusual behaviour in
remoteproc ?

Regards,
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-19 23:18     ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-09-19 23:18 UTC (permalink / raw)
  To: Peter Griffin
  Cc: LAKML, Linux-Kernel@Vger. Kernel. Org, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, David Airlie, Gerd Hoffmann,
	ohad, bjorn.andersson, devicetree, linux-remoteproc,
	ML dri-devel, open list:VIRTIO GPU DRIVER, dmaengine, lee.jones

On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
>From a humble skim through remoteproc, drm and a few other subsystems
I think the above is wrong. All the drivers (outside of remoteproc),
that I've seen, depend on the core component, they don't select it.

Furthermore most places explicitly hide the drivers from the menu if
the core component isn't enabled.

Is there something that requires such a different/unusual behaviour in
remoteproc ?

Regards,
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-19 23:18     ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-09-19 23:18 UTC (permalink / raw)
  To: Peter Griffin
  Cc: devicetree, kernel, vinod.koul, lee.jones, linux-remoteproc,
	patrice.chotard, ML dri-devel, Linux-Kernel@Vger. Kernel. Org,
	David Airlie, dmaengine, dan.j.williams, bjorn.andersson,
	open list:VIRTIO GPU DRIVER, LAKML

On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
>From a humble skim through remoteproc, drm and a few other subsystems
I think the above is wrong. All the drivers (outside of remoteproc),
that I've seen, depend on the core component, they don't select it.

Furthermore most places explicitly hide the drivers from the menu if
the core component isn't enabled.

Is there something that requires such a different/unusual behaviour in
remoteproc ?

Regards,
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-19 23:18     ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-09-19 23:18 UTC (permalink / raw)
  To: Peter Griffin
  Cc: devicetree, kernel, vinod.koul, lee.jones, linux-remoteproc,
	patrice.chotard, ML dri-devel, Linux-Kernel@Vger. Kernel. Org,
	David Airlie, dmaengine, dan.j.williams, bjorn.andersson,
	open list:VIRTIO GPU DRIVER, LAKML

On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
From a humble skim through remoteproc, drm and a few other subsystems
I think the above is wrong. All the drivers (outside of remoteproc),
that I've seen, depend on the core component, they don't select it.

Furthermore most places explicitly hide the drivers from the menu if
the core component isn't enabled.

Is there something that requires such a different/unusual behaviour in
remoteproc ?

Regards,
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-19 23:18     ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-09-19 23:18 UTC (permalink / raw)
  To: linux-arm-kernel

On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
>From a humble skim through remoteproc, drm and a few other subsystems
I think the above is wrong. All the drivers (outside of remoteproc),
that I've seen, depend on the core component, they don't select it.

Furthermore most places explicitly hide the drivers from the menu if
the core component isn't enabled.

Is there something that requires such a different/unusual behaviour in
remoteproc ?

Regards,
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-19 23:18     ` Emil Velikov
  (?)
  (?)
@ 2016-09-20  8:32       ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-20  8:32 UTC (permalink / raw)
  To: Emil Velikov, Arnd Bergmann
  Cc: LAKML, Linux-Kernel@Vger. Kernel. Org, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, David Airlie, Gerd Hoffmann,
	ohad, bjorn.andersson, devicetree, linux-remoteproc,
	ML dri-devel, open list:VIRTIO GPU DRIVER, dmaengine, lee.jones

Hi Emil,

On Tue, 20 Sep 2016, Emil Velikov wrote:

> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> > recursive dependency.


> >
> From a humble skim through remoteproc, drm and a few other subsystems
> I think the above is wrong. All the drivers (outside of remoteproc),
> that I've seen, depend on the core component, they don't select it.

I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
why it is like it is.

For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
the other drivers in the remoteproc subsystem which has exposed this recursive
dependency issue.

For this particular kconfig symbol a quick grep reveals more drivers in
the kernel using 'select', than 'depend on'

git grep "select VIRTIO" | wc -l
14

git grep "depends on VIRTIO" | wc -l
10


> Furthermore most places explicitly hide the drivers from the menu if
> the core component isn't enabled.

Remoteproc subsystem takes a different approach, the core code is only enabled
if a driver which relies on it is enabled. This IMHO makes sense, as
remoteproc is not widely used (only a few particular ARM SoC's).

It is true that for subsystems which rely on the core component being
explicitly enabled, they often tend to hide drivers which depend on it
from the menu unless it is. This also makes sense.

> 
> Is there something that requires such a different/unusual behaviour in
> remoteproc ?
> 

I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
mfd subsystem, client drivers select MFD_CORE.

I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
recently, maybe he has some thoughts on whether this is the correct fix or not?

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-20  8:32       ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-20  8:32 UTC (permalink / raw)
  To: Emil Velikov, Arnd Bergmann
  Cc: LAKML, Linux-Kernel@Vger. Kernel. Org, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, David Airlie, Gerd Hoffmann,
	ohad, bjorn.andersson, devicetree, linux-remoteproc,
	ML dri-devel, open list:VIRTIO GPU DRIVER, dmaengine, lee.jones

Hi Emil,

On Tue, 20 Sep 2016, Emil Velikov wrote:

> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> > recursive dependency.


> >
> From a humble skim through remoteproc, drm and a few other subsystems
> I think the above is wrong. All the drivers (outside of remoteproc),
> that I've seen, depend on the core component, they don't select it.

I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
why it is like it is.

For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
the other drivers in the remoteproc subsystem which has exposed this recursive
dependency issue.

For this particular kconfig symbol a quick grep reveals more drivers in
the kernel using 'select', than 'depend on'

git grep "select VIRTIO" | wc -l
14

git grep "depends on VIRTIO" | wc -l
10


> Furthermore most places explicitly hide the drivers from the menu if
> the core component isn't enabled.

Remoteproc subsystem takes a different approach, the core code is only enabled
if a driver which relies on it is enabled. This IMHO makes sense, as
remoteproc is not widely used (only a few particular ARM SoC's).

It is true that for subsystems which rely on the core component being
explicitly enabled, they often tend to hide drivers which depend on it
from the menu unless it is. This also makes sense.

> 
> Is there something that requires such a different/unusual behaviour in
> remoteproc ?
> 

I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
mfd subsystem, client drivers select MFD_CORE.

I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
recently, maybe he has some thoughts on whether this is the correct fix or not?

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-20  8:32       ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-20  8:32 UTC (permalink / raw)
  To: Emil Velikov, Arnd Bergmann
  Cc: devicetree, kernel, vinod.koul, lee.jones, linux-remoteproc,
	patrice.chotard, ML dri-devel, Linux-Kernel@Vger. Kernel. Org,
	David Airlie, dmaengine, dan.j.williams, bjorn.andersson,
	open list:VIRTIO GPU DRIVER, LAKML

Hi Emil,

On Tue, 20 Sep 2016, Emil Velikov wrote:

> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> > recursive dependency.


> >
> From a humble skim through remoteproc, drm and a few other subsystems
> I think the above is wrong. All the drivers (outside of remoteproc),
> that I've seen, depend on the core component, they don't select it.

I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
why it is like it is.

For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
the other drivers in the remoteproc subsystem which has exposed this recursive
dependency issue.

For this particular kconfig symbol a quick grep reveals more drivers in
the kernel using 'select', than 'depend on'

git grep "select VIRTIO" | wc -l
14

git grep "depends on VIRTIO" | wc -l
10


> Furthermore most places explicitly hide the drivers from the menu if
> the core component isn't enabled.

Remoteproc subsystem takes a different approach, the core code is only enabled
if a driver which relies on it is enabled. This IMHO makes sense, as
remoteproc is not widely used (only a few particular ARM SoC's).

It is true that for subsystems which rely on the core component being
explicitly enabled, they often tend to hide drivers which depend on it
from the menu unless it is. This also makes sense.

> 
> Is there something that requires such a different/unusual behaviour in
> remoteproc ?
> 

I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
mfd subsystem, client drivers select MFD_CORE.

I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
recently, maybe he has some thoughts on whether this is the correct fix or not?

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-20  8:32       ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-09-20  8:32 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Emil,

On Tue, 20 Sep 2016, Emil Velikov wrote:

> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> > recursive dependency.


> >
> From a humble skim through remoteproc, drm and a few other subsystems
> I think the above is wrong. All the drivers (outside of remoteproc),
> that I've seen, depend on the core component, they don't select it.

I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
why it is like it is.

For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
the other drivers in the remoteproc subsystem which has exposed this recursive
dependency issue.

For this particular kconfig symbol a quick grep reveals more drivers in
the kernel using 'select', than 'depend on'

git grep "select VIRTIO" | wc -l
14

git grep "depends on VIRTIO" | wc -l
10


> Furthermore most places explicitly hide the drivers from the menu if
> the core component isn't enabled.

Remoteproc subsystem takes a different approach, the core code is only enabled
if a driver which relies on it is enabled. This IMHO makes sense, as
remoteproc is not widely used (only a few particular ARM SoC's).

It is true that for subsystems which rely on the core component being
explicitly enabled, they often tend to hide drivers which depend on it
from the menu unless it is. This also makes sense.

> 
> Is there something that requires such a different/unusual behaviour in
> remoteproc ?
> 

I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
mfd subsystem, client drivers select MFD_CORE.

I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
recently, maybe he has some thoughts on whether this is the correct fix or not?

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-20  8:32       ` Peter Griffin
  (?)
  (?)
@ 2016-09-20  9:33         ` Jani Nikula
  -1 siblings, 0 replies; 174+ messages in thread
From: Jani Nikula @ 2016-09-20  9:33 UTC (permalink / raw)
  To: Peter Griffin, Emil Velikov, Arnd Bergmann
  Cc: ohad, devicetree, kernel, vinod.koul, lee.jones,
	linux-remoteproc, patrice.chotard, ML dri-devel,
	Linux-Kernel@Vger. Kernel. Org, Gerd Hoffmann, dmaengine,
	dan.j.williams, bjorn.andersson, open list:VIRTIO GPU DRIVER,
	LAKML

On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>> 
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>> 
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?


Documentation/kbuild/kconfig-language.txt:

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)

Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-20  9:33         ` Jani Nikula
  0 siblings, 0 replies; 174+ messages in thread
From: Jani Nikula @ 2016-09-20  9:33 UTC (permalink / raw)
  To: Peter Griffin, Emil Velikov, Arnd Bergmann
  Cc: ohad, devicetree, kernel, vinod.koul, lee.jones,
	linux-remoteproc, patrice.chotard, ML dri-devel,
	Linux-Kernel@Vger. Kernel. Org, Gerd Hoffmann, dmaengine,
	dan.j.williams, bjorn.andersson, open list:VIRTIO GPU DRIVER,
	LAKML

On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>> 
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>> 
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?


Documentation/kbuild/kconfig-language.txt:

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)

Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-20  9:33         ` Jani Nikula
  0 siblings, 0 replies; 174+ messages in thread
From: Jani Nikula @ 2016-09-20  9:33 UTC (permalink / raw)
  To: Peter Griffin, Emil Velikov, Arnd Bergmann
  Cc: ohad-Ix1uc/W3ht7QT0dZR+AlfA, devicetree,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	lee.jones-QSEj5FYQhm4dnm+yROfE0A,
	linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	patrice.chotard-qxv4g6HH51o, ML dri-devel,
	Linux-Kernel@Vger. Kernel. Org, Gerd Hoffmann,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
	bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
	open list:VIRTIO GPU DRIVER, LAKML

On Tue, 20 Sep 2016, Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>> 
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>> 
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?


Documentation/kbuild/kconfig-language.txt:

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)

Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-20  8:32       ` Peter Griffin
                         ` (2 preceding siblings ...)
  (?)
@ 2016-09-20  9:33       ` Jani Nikula
  -1 siblings, 0 replies; 174+ messages in thread
From: Jani Nikula @ 2016-09-20  9:33 UTC (permalink / raw)
  To: Peter Griffin, Emil Velikov, Arnd Bergmann
  Cc: devicetree, kernel, vinod.koul, linux-remoteproc,
	patrice.chotard, ML dri-devel, Linux-Kernel@Vger. Kernel. Org,
	dmaengine, dan.j.williams, bjorn.andersson, lee.jones,
	open list:VIRTIO GPU DRIVER, LAKML

On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>> 
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>> 
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?


Documentation/kbuild/kconfig-language.txt:

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)

Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-20  9:33         ` Jani Nikula
  0 siblings, 0 replies; 174+ messages in thread
From: Jani Nikula @ 2016-09-20  9:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>> 
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>> 
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?


Documentation/kbuild/kconfig-language.txt:

  Note:
	select should be used with care. select will force
	a symbol to a value without visiting the dependencies.
	By abusing select you are able to select a symbol FOO even
	if FOO depends on BAR that is not set.
	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

People tend to abuse select because it's "convenient". If you depend,
but some of your dependencies aren't met, you're in for some digging
through Kconfig to find the missing deps. Just to make the option you
want visible in menuconfig. If you instead select something with
dependencies, it'll be right most of the time, and it's "convenient",
until it breaks. (And hey, it usually breaks for someone else with some
other config, so it's still convenient for you.)

Perhaps kconfig should complain about selecting visible symbols and
symbols with dependencies.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-20  8:32       ` Peter Griffin
  (?)
@ 2016-09-21 12:09         ` Emil Velikov
  -1 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-09-21 12:09 UTC (permalink / raw)
  To: Peter Griffin
  Cc: Arnd Bergmann, LAKML, Linux-Kernel@Vger. Kernel. Org, kernel,
	vinod.koul, patrice.chotard, dan.j.williams, David Airlie,
	Gerd Hoffmann, ohad, bjorn.andersson, devicetree,
	linux-remoteproc, ML dri-devel, open list:VIRTIO GPU DRIVER,
	dmaengine, lee.jones

On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
Might be worth taking a closer look into these at some point.

>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>>
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>>
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
On the USB case I'm not sure what the reasoning behind the USB vs
USB_COMMON split. In seems that one could just fold them, but that's
another topic. On the MFD side... it follows the select {,mis,ab}use.
With one (the only one?) MFD driver not using/selecting MFD_CORE doing
it's own version of mfd_add_devices... which could be reworked,
possibly.

> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?
>
Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
reasonable, but it'll be great to hear others as well.

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-21 12:09         ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-09-21 12:09 UTC (permalink / raw)
  To: Peter Griffin
  Cc: Arnd Bergmann, LAKML, Linux-Kernel@Vger. Kernel. Org, kernel,
	vinod.koul, patrice.chotard, dan.j.williams, David Airlie,
	Gerd Hoffmann, ohad, bjorn.andersson, devicetree,
	linux-remoteproc, ML dri-devel, open list:VIRTIO GPU DRIVER,
	dmaengine, lee.jones

On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
Might be worth taking a closer look into these at some point.

>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>>
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>>
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
On the USB case I'm not sure what the reasoning behind the USB vs
USB_COMMON split. In seems that one could just fold them, but that's
another topic. On the MFD side... it follows the select {,mis,ab}use.
With one (the only one?) MFD driver not using/selecting MFD_CORE doing
it's own version of mfd_add_devices... which could be reworked,
possibly.

> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?
>
Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
reasonable, but it'll be great to hear others as well.

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-20  8:32       ` Peter Griffin
                         ` (4 preceding siblings ...)
  (?)
@ 2016-09-21 12:09       ` Emil Velikov
  -1 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-09-21 12:09 UTC (permalink / raw)
  To: Peter Griffin
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, lee.jones,
	linux-remoteproc, patrice.chotard, ML dri-devel,
	Linux-Kernel@Vger. Kernel. Org, David Airlie, dmaengine,
	dan.j.williams, bjorn.andersson, open list:VIRTIO GPU DRIVER,
	LAKML

On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
Might be worth taking a closer look into these at some point.

>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>>
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>>
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
On the USB case I'm not sure what the reasoning behind the USB vs
USB_COMMON split. In seems that one could just fold them, but that's
another topic. On the MFD side... it follows the select {,mis,ab}use.
With one (the only one?) MFD driver not using/selecting MFD_CORE doing
it's own version of mfd_add_devices... which could be reworked,
possibly.

> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?
>
Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
reasonable, but it'll be great to hear others as well.

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-21 12:09         ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-09-21 12:09 UTC (permalink / raw)
  To: linux-arm-kernel

On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble skim through remoteproc, drm and a few other subsystems
>> I think the above is wrong. All the drivers (outside of remoteproc),
>> that I've seen, depend on the core component, they don't select it.
>
> I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> why it is like it is.
>
> For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> the other drivers in the remoteproc subsystem which has exposed this recursive
> dependency issue.
>
> For this particular kconfig symbol a quick grep reveals more drivers in
> the kernel using 'select', than 'depend on'
>
> git grep "select VIRTIO" | wc -l
> 14
>
> git grep "depends on VIRTIO" | wc -l
> 10
>
Might be worth taking a closer look into these at some point.

>
>> Furthermore most places explicitly hide the drivers from the menu if
>> the core component isn't enabled.
>
> Remoteproc subsystem takes a different approach, the core code is only enabled
> if a driver which relies on it is enabled. This IMHO makes sense, as
> remoteproc is not widely used (only a few particular ARM SoC's).
>
> It is true that for subsystems which rely on the core component being
> explicitly enabled, they often tend to hide drivers which depend on it
> from the menu unless it is. This also makes sense.
>
>>
>> Is there something that requires such a different/unusual behaviour in
>> remoteproc ?
>>
>
> I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> mfd subsystem, client drivers select MFD_CORE.
>
On the USB case I'm not sure what the reasoning behind the USB vs
USB_COMMON split. In seems that one could just fold them, but that's
another topic. On the MFD side... it follows the select {,mis,ab}use.
With one (the only one?) MFD driver not using/selecting MFD_CORE doing
it's own version of mfd_add_devices... which could be reworked,
possibly.

> I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> recently, maybe he has some thoughts on whether this is the correct fix or not?
>
Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
reasonable, but it'll be great to hear others as well.

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-21 12:09         ` Emil Velikov
  (?)
  (?)
@ 2016-09-27 17:01           ` Bjorn Andersson
  -1 siblings, 0 replies; 174+ messages in thread
From: Bjorn Andersson @ 2016-09-27 17:01 UTC (permalink / raw)
  To: Emil Velikov
  Cc: Peter Griffin, Arnd Bergmann, LAKML,
	Linux-Kernel@Vger. Kernel. Org, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, David Airlie, Gerd Hoffmann,
	ohad, devicetree, linux-remoteproc, ML dri-devel,
	open list:VIRTIO GPU DRIVER, dmaengine, lee.jones

On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:

> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> Might be worth taking a closer look into these at some point.
> 

The general idea here is that VIRTIO provides the "framework" and as
such drivers implementing VIRTIO do select and drivers using virtio use
depends.

This is found in several places around the kernel.

> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >>
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >>

There's nothing unusual in remoteproc that forces us to stay with this
model; however the parts related to the REMOTEPROC config is useless by
themselves.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-27 17:01           ` Bjorn Andersson
  0 siblings, 0 replies; 174+ messages in thread
From: Bjorn Andersson @ 2016-09-27 17:01 UTC (permalink / raw)
  To: Emil Velikov
  Cc: Peter Griffin, Arnd Bergmann, LAKML,
	Linux-Kernel@Vger. Kernel. Org, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, David Airlie, Gerd Hoffmann,
	ohad, devicetree, linux-remoteproc, ML dri-devel,
	open list:VIRTIO GPU DRIVER, dmaengine, lee.jones

On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:

> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> Might be worth taking a closer look into these at some point.
> 

The general idea here is that VIRTIO provides the "framework" and as
such drivers implementing VIRTIO do select and drivers using virtio use
depends.

This is found in several places around the kernel.

> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >>
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >>

There's nothing unusual in remoteproc that forces us to stay with this
model; however the parts related to the REMOTEPROC config is useless by
themselves.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-27 17:01           ` Bjorn Andersson
  0 siblings, 0 replies; 174+ messages in thread
From: Bjorn Andersson @ 2016-09-27 17:01 UTC (permalink / raw)
  To: Emil Velikov
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
	Linux-Kernel@Vger. Kernel. Org, ML dri-devel, patrice.chotard,
	Peter Griffin, David Airlie, dmaengine, dan.j.williams,
	open list:VIRTIO GPU DRIVER, lee.jones, LAKML

On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:

> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> Might be worth taking a closer look into these at some point.
> 

The general idea here is that VIRTIO provides the "framework" and as
such drivers implementing VIRTIO do select and drivers using virtio use
depends.

This is found in several places around the kernel.

> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >>
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >>

There's nothing unusual in remoteproc that forces us to stay with this
model; however the parts related to the REMOTEPROC config is useless by
themselves.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-09-27 17:01           ` Bjorn Andersson
  0 siblings, 0 replies; 174+ messages in thread
From: Bjorn Andersson @ 2016-09-27 17:01 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:

> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> Might be worth taking a closer look into these at some point.
> 

The general idea here is that VIRTIO provides the "framework" and as
such drivers implementing VIRTIO do select and drivers using virtio use
depends.

This is found in several places around the kernel.

> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >>
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >>

There's nothing unusual in remoteproc that forces us to stay with this
model; however the parts related to the REMOTEPROC config is useless by
themselves.

Regards,
Bjorn

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-20  9:33         ` Jani Nikula
  (?)
  (?)
@ 2016-10-06  9:37           ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-06  9:37 UTC (permalink / raw)
  To: Jani Nikula
  Cc: Emil Velikov, Arnd Bergmann, ohad, devicetree, kernel,
	vinod.koul, lee.jones, linux-remoteproc, patrice.chotard,
	ML dri-devel, Linux-Kernel@Vger. Kernel. Org, Gerd Hoffmann,
	dmaengine, dan.j.williams, bjorn.andersson,
	open list:VIRTIO GPU DRIVER, LAKML

Hi Jani,

Sorry for the delay, I've been travelling last week.

On Tue, 20 Sep 2016, Jani Nikula wrote:

> On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >> 
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >> 
> >
> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> > mfd subsystem, client drivers select MFD_CORE.
> >
> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> > recently, maybe he has some thoughts on whether this is the correct fix or not?
> 
> 
> Documentation/kbuild/kconfig-language.txt:
> 
>   Note:
> 	select should be used with care. select will force
> 	a symbol to a value without visiting the dependencies.
> 	By abusing select you are able to select a symbol FOO even
> 	if FOO depends on BAR that is not set.
> 	In general use select only for non-visible symbols
> 	(no prompts anywhere) and for symbols with no dependencies.
> 	That will limit the usefulness but on the other hand avoid
> 	the illegal configurations all over.

Thanks for the documentation link. I believe this proves this patch is an
appropriate fix as VIRTIO is a non-visible symbol, and has no dependencies.

In fact the help text for VIRTIO even states this option should be selected
by any driver which implements virtio.

> 
> People tend to abuse select because it's "convenient". If you depend,
> but some of your dependencies aren't met, you're in for some digging
> through Kconfig to find the missing deps. Just to make the option you
> want visible in menuconfig. If you instead select something with
> dependencies, it'll be right most of the time, and it's "convenient",
> until it breaks. (And hey, it usually breaks for someone else with some
> other config, so it's still convenient for you.)

I'm sure they do but in this case it is actually the use of 'depends on'
which has caused the breakage and inconvenience for somebody else and sadly this
inconvienice is still on-going due to this patch not being applied or getting an
acked-by from the appropriate maintainers.

> 
> Perhaps kconfig should complain about selecting visible symbols and
> symbols with dependencies.

That sounds like it would be a useful addition.

Is it possible to get this patch applied or an acked-by to avoid further delay
to the fdma series?

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06  9:37           ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-06  9:37 UTC (permalink / raw)
  To: Jani Nikula
  Cc: Emil Velikov, Arnd Bergmann, ohad, devicetree, kernel,
	vinod.koul, lee.jones, linux-remoteproc, patrice.chotard,
	ML dri-devel, Linux-Kernel@Vger. Kernel. Org, Gerd Hoffmann,
	dmaengine, dan.j.williams, bjorn.andersson,
	open list:VIRTIO GPU DRIVER, LAKML

Hi Jani,

Sorry for the delay, I've been travelling last week.

On Tue, 20 Sep 2016, Jani Nikula wrote:

> On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >> 
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >> 
> >
> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> > mfd subsystem, client drivers select MFD_CORE.
> >
> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> > recently, maybe he has some thoughts on whether this is the correct fix or not?
> 
> 
> Documentation/kbuild/kconfig-language.txt:
> 
>   Note:
> 	select should be used with care. select will force
> 	a symbol to a value without visiting the dependencies.
> 	By abusing select you are able to select a symbol FOO even
> 	if FOO depends on BAR that is not set.
> 	In general use select only for non-visible symbols
> 	(no prompts anywhere) and for symbols with no dependencies.
> 	That will limit the usefulness but on the other hand avoid
> 	the illegal configurations all over.

Thanks for the documentation link. I believe this proves this patch is an
appropriate fix as VIRTIO is a non-visible symbol, and has no dependencies.

In fact the help text for VIRTIO even states this option should be selected
by any driver which implements virtio.

> 
> People tend to abuse select because it's "convenient". If you depend,
> but some of your dependencies aren't met, you're in for some digging
> through Kconfig to find the missing deps. Just to make the option you
> want visible in menuconfig. If you instead select something with
> dependencies, it'll be right most of the time, and it's "convenient",
> until it breaks. (And hey, it usually breaks for someone else with some
> other config, so it's still convenient for you.)

I'm sure they do but in this case it is actually the use of 'depends on'
which has caused the breakage and inconvenience for somebody else and sadly this
inconvienice is still on-going due to this patch not being applied or getting an
acked-by from the appropriate maintainers.

> 
> Perhaps kconfig should complain about selecting visible symbols and
> symbols with dependencies.

That sounds like it would be a useful addition.

Is it possible to get this patch applied or an acked-by to avoid further delay
to the fdma series?

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06  9:37           ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-06  9:37 UTC (permalink / raw)
  To: Jani Nikula
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
	Emil Velikov, patrice.chotard, ML dri-devel,
	Linux-Kernel@Vger. Kernel. Org, dmaengine, dan.j.williams,
	bjorn.andersson, lee.jones, open list:VIRTIO GPU DRIVER, LAKML

Hi Jani,

Sorry for the delay, I've been travelling last week.

On Tue, 20 Sep 2016, Jani Nikula wrote:

> On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >> 
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >> 
> >
> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> > mfd subsystem, client drivers select MFD_CORE.
> >
> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> > recently, maybe he has some thoughts on whether this is the correct fix or not?
> 
> 
> Documentation/kbuild/kconfig-language.txt:
> 
>   Note:
> 	select should be used with care. select will force
> 	a symbol to a value without visiting the dependencies.
> 	By abusing select you are able to select a symbol FOO even
> 	if FOO depends on BAR that is not set.
> 	In general use select only for non-visible symbols
> 	(no prompts anywhere) and for symbols with no dependencies.
> 	That will limit the usefulness but on the other hand avoid
> 	the illegal configurations all over.

Thanks for the documentation link. I believe this proves this patch is an
appropriate fix as VIRTIO is a non-visible symbol, and has no dependencies.

In fact the help text for VIRTIO even states this option should be selected
by any driver which implements virtio.

> 
> People tend to abuse select because it's "convenient". If you depend,
> but some of your dependencies aren't met, you're in for some digging
> through Kconfig to find the missing deps. Just to make the option you
> want visible in menuconfig. If you instead select something with
> dependencies, it'll be right most of the time, and it's "convenient",
> until it breaks. (And hey, it usually breaks for someone else with some
> other config, so it's still convenient for you.)

I'm sure they do but in this case it is actually the use of 'depends on'
which has caused the breakage and inconvenience for somebody else and sadly this
inconvienice is still on-going due to this patch not being applied or getting an
acked-by from the appropriate maintainers.

> 
> Perhaps kconfig should complain about selecting visible symbols and
> symbols with dependencies.

That sounds like it would be a useful addition.

Is it possible to get this patch applied or an acked-by to avoid further delay
to the fdma series?

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06  9:37           ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-06  9:37 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Jani,

Sorry for the delay, I've been travelling last week.

On Tue, 20 Sep 2016, Jani Nikula wrote:

> On Tue, 20 Sep 2016, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >> 
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >> 
> >
> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> > mfd subsystem, client drivers select MFD_CORE.
> >
> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> > recently, maybe he has some thoughts on whether this is the correct fix or not?
> 
> 
> Documentation/kbuild/kconfig-language.txt:
> 
>   Note:
> 	select should be used with care. select will force
> 	a symbol to a value without visiting the dependencies.
> 	By abusing select you are able to select a symbol FOO even
> 	if FOO depends on BAR that is not set.
> 	In general use select only for non-visible symbols
> 	(no prompts anywhere) and for symbols with no dependencies.
> 	That will limit the usefulness but on the other hand avoid
> 	the illegal configurations all over.

Thanks for the documentation link. I believe this proves this patch is an
appropriate fix as VIRTIO is a non-visible symbol, and has no dependencies.

In fact the help text for VIRTIO even states this option should be selected
by any driver which implements virtio.

> 
> People tend to abuse select because it's "convenient". If you depend,
> but some of your dependencies aren't met, you're in for some digging
> through Kconfig to find the missing deps. Just to make the option you
> want visible in menuconfig. If you instead select something with
> dependencies, it'll be right most of the time, and it's "convenient",
> until it breaks. (And hey, it usually breaks for someone else with some
> other config, so it's still convenient for you.)

I'm sure they do but in this case it is actually the use of 'depends on'
which has caused the breakage and inconvenience for somebody else and sadly this
inconvienice is still on-going due to this patch not being applied or getting an
acked-by from the appropriate maintainers.

> 
> Perhaps kconfig should complain about selecting visible symbols and
> symbols with dependencies.

That sounds like it would be a useful addition.

Is it possible to get this patch applied or an acked-by to avoid further delay
to the fdma series?

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-27 17:01           ` Bjorn Andersson
  (?)
@ 2016-10-06 10:10             ` Emil Velikov
  -1 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 10:10 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Peter Griffin, Arnd Bergmann, LAKML,
	Linux-Kernel@Vger. Kernel. Org, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, David Airlie, Gerd Hoffmann,
	Ohad Ben-Cohen, devicetree, linux-remoteproc, ML dri-devel,
	open list:VIRTIO GPU DRIVER, dmaengine, Lee Jones

Hi Bjorn,

On 27 September 2016 at 18:01, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> >> > recursive dependency.
>> >
>> >
>> >> >
>> >> From a humble skim through remoteproc, drm and a few other subsystems
>> >> I think the above is wrong. All the drivers (outside of remoteproc),
>> >> that I've seen, depend on the core component, they don't select it.
>> >
>> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
>> > why it is like it is.
>> >
>> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
>> > the other drivers in the remoteproc subsystem which has exposed this recursive
>> > dependency issue.
>> >
>> > For this particular kconfig symbol a quick grep reveals more drivers in
>> > the kernel using 'select', than 'depend on'
>> >
>> > git grep "select VIRTIO" | wc -l
>> > 14
>> >
>> > git grep "depends on VIRTIO" | wc -l
>> > 10
>> >
>> Might be worth taking a closer look into these at some point.
>>
>
> The general idea here is that VIRTIO provides the "framework" and as
> such drivers implementing VIRTIO do select and drivers using virtio use
> depends.
>
> This is found in several places around the kernel.
>
>> >
>> >> Furthermore most places explicitly hide the drivers from the menu if
>> >> the core component isn't enabled.
>> >
>> > Remoteproc subsystem takes a different approach, the core code is only enabled
>> > if a driver which relies on it is enabled. This IMHO makes sense, as
>> > remoteproc is not widely used (only a few particular ARM SoC's).
>> >
>> > It is true that for subsystems which rely on the core component being
>> > explicitly enabled, they often tend to hide drivers which depend on it
>> > from the menu unless it is. This also makes sense.
>> >
>> >>
>> >> Is there something that requires such a different/unusual behaviour in
>> >> remoteproc ?
>> >>
>
> There's nothing unusual in remoteproc that forces us to stay with this
> model; however the parts related to the REMOTEPROC config is useless by
> themselves.
>
I'm afraid that the "supporting" arguments you're using are generic
and not specific to remoteproc. Although as Jani mentioned and pointed
to the documentation, remoteproc is {mis,ab}using 'select' leading to
issues elsewhere.

In the long term we might want to switch to 'select' and attribute
kconfig like Jani suggested.  But in the short term we want to avoid
select-ing things just for our "convenience".

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06 10:10             ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 10:10 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Peter Griffin, Arnd Bergmann, LAKML,
	Linux-Kernel@Vger. Kernel. Org, kernel, vinod.koul,
	patrice.chotard, dan.j.williams, David Airlie, Gerd Hoffmann,
	Ohad Ben-Cohen, devicetree, linux-remoteproc, ML dri-devel,
	open list:VIRTIO GPU DRIVER, dmaengine, Lee Jones

Hi Bjorn,

On 27 September 2016 at 18:01, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> >> > recursive dependency.
>> >
>> >
>> >> >
>> >> From a humble skim through remoteproc, drm and a few other subsystems
>> >> I think the above is wrong. All the drivers (outside of remoteproc),
>> >> that I've seen, depend on the core component, they don't select it.
>> >
>> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
>> > why it is like it is.
>> >
>> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
>> > the other drivers in the remoteproc subsystem which has exposed this recursive
>> > dependency issue.
>> >
>> > For this particular kconfig symbol a quick grep reveals more drivers in
>> > the kernel using 'select', than 'depend on'
>> >
>> > git grep "select VIRTIO" | wc -l
>> > 14
>> >
>> > git grep "depends on VIRTIO" | wc -l
>> > 10
>> >
>> Might be worth taking a closer look into these at some point.
>>
>
> The general idea here is that VIRTIO provides the "framework" and as
> such drivers implementing VIRTIO do select and drivers using virtio use
> depends.
>
> This is found in several places around the kernel.
>
>> >
>> >> Furthermore most places explicitly hide the drivers from the menu if
>> >> the core component isn't enabled.
>> >
>> > Remoteproc subsystem takes a different approach, the core code is only enabled
>> > if a driver which relies on it is enabled. This IMHO makes sense, as
>> > remoteproc is not widely used (only a few particular ARM SoC's).
>> >
>> > It is true that for subsystems which rely on the core component being
>> > explicitly enabled, they often tend to hide drivers which depend on it
>> > from the menu unless it is. This also makes sense.
>> >
>> >>
>> >> Is there something that requires such a different/unusual behaviour in
>> >> remoteproc ?
>> >>
>
> There's nothing unusual in remoteproc that forces us to stay with this
> model; however the parts related to the REMOTEPROC config is useless by
> themselves.
>
I'm afraid that the "supporting" arguments you're using are generic
and not specific to remoteproc. Although as Jani mentioned and pointed
to the documentation, remoteproc is {mis,ab}using 'select' leading to
issues elsewhere.

In the long term we might want to switch to 'select' and attribute
kconfig like Jani suggested.  But in the short term we want to avoid
select-ing things just for our "convenience".

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-27 17:01           ` Bjorn Andersson
                             ` (2 preceding siblings ...)
  (?)
@ 2016-10-06 10:10           ` Emil Velikov
  -1 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 10:10 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
	Linux-Kernel@Vger. Kernel. Org, ML dri-devel, patrice.chotard,
	Peter Griffin, David Airlie, dmaengine, dan.j.williams,
	open list:VIRTIO GPU DRIVER, Lee Jones, LAKML

Hi Bjorn,

On 27 September 2016 at 18:01, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> >> > recursive dependency.
>> >
>> >
>> >> >
>> >> From a humble skim through remoteproc, drm and a few other subsystems
>> >> I think the above is wrong. All the drivers (outside of remoteproc),
>> >> that I've seen, depend on the core component, they don't select it.
>> >
>> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
>> > why it is like it is.
>> >
>> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
>> > the other drivers in the remoteproc subsystem which has exposed this recursive
>> > dependency issue.
>> >
>> > For this particular kconfig symbol a quick grep reveals more drivers in
>> > the kernel using 'select', than 'depend on'
>> >
>> > git grep "select VIRTIO" | wc -l
>> > 14
>> >
>> > git grep "depends on VIRTIO" | wc -l
>> > 10
>> >
>> Might be worth taking a closer look into these at some point.
>>
>
> The general idea here is that VIRTIO provides the "framework" and as
> such drivers implementing VIRTIO do select and drivers using virtio use
> depends.
>
> This is found in several places around the kernel.
>
>> >
>> >> Furthermore most places explicitly hide the drivers from the menu if
>> >> the core component isn't enabled.
>> >
>> > Remoteproc subsystem takes a different approach, the core code is only enabled
>> > if a driver which relies on it is enabled. This IMHO makes sense, as
>> > remoteproc is not widely used (only a few particular ARM SoC's).
>> >
>> > It is true that for subsystems which rely on the core component being
>> > explicitly enabled, they often tend to hide drivers which depend on it
>> > from the menu unless it is. This also makes sense.
>> >
>> >>
>> >> Is there something that requires such a different/unusual behaviour in
>> >> remoteproc ?
>> >>
>
> There's nothing unusual in remoteproc that forces us to stay with this
> model; however the parts related to the REMOTEPROC config is useless by
> themselves.
>
I'm afraid that the "supporting" arguments you're using are generic
and not specific to remoteproc. Although as Jani mentioned and pointed
to the documentation, remoteproc is {mis,ab}using 'select' leading to
issues elsewhere.

In the long term we might want to switch to 'select' and attribute
kconfig like Jani suggested.  But in the short term we want to avoid
select-ing things just for our "convenience".

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06 10:10             ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 10:10 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Bjorn,

On 27 September 2016 at 18:01, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> >> > recursive dependency.
>> >
>> >
>> >> >
>> >> From a humble skim through remoteproc, drm and a few other subsystems
>> >> I think the above is wrong. All the drivers (outside of remoteproc),
>> >> that I've seen, depend on the core component, they don't select it.
>> >
>> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
>> > why it is like it is.
>> >
>> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
>> > the other drivers in the remoteproc subsystem which has exposed this recursive
>> > dependency issue.
>> >
>> > For this particular kconfig symbol a quick grep reveals more drivers in
>> > the kernel using 'select', than 'depend on'
>> >
>> > git grep "select VIRTIO" | wc -l
>> > 14
>> >
>> > git grep "depends on VIRTIO" | wc -l
>> > 10
>> >
>> Might be worth taking a closer look into these at some point.
>>
>
> The general idea here is that VIRTIO provides the "framework" and as
> such drivers implementing VIRTIO do select and drivers using virtio use
> depends.
>
> This is found in several places around the kernel.
>
>> >
>> >> Furthermore most places explicitly hide the drivers from the menu if
>> >> the core component isn't enabled.
>> >
>> > Remoteproc subsystem takes a different approach, the core code is only enabled
>> > if a driver which relies on it is enabled. This IMHO makes sense, as
>> > remoteproc is not widely used (only a few particular ARM SoC's).
>> >
>> > It is true that for subsystems which rely on the core component being
>> > explicitly enabled, they often tend to hide drivers which depend on it
>> > from the menu unless it is. This also makes sense.
>> >
>> >>
>> >> Is there something that requires such a different/unusual behaviour in
>> >> remoteproc ?
>> >>
>
> There's nothing unusual in remoteproc that forces us to stay with this
> model; however the parts related to the REMOTEPROC config is useless by
> themselves.
>
I'm afraid that the "supporting" arguments you're using are generic
and not specific to remoteproc. Although as Jani mentioned and pointed
to the documentation, remoteproc is {mis,ab}using 'select' leading to
issues elsewhere.

In the long term we might want to switch to 'select' and attribute
kconfig like Jani suggested.  But in the short term we want to avoid
select-ing things just for our "convenience".

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-10-06  9:37           ` Peter Griffin
  (?)
  (?)
@ 2016-10-06 10:45             ` Emil Velikov
  -1 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 10:45 UTC (permalink / raw)
  To: Peter Griffin
  Cc: Jani Nikula, Arnd Bergmann, Ohad Ben-Cohen, devicetree, kernel,
	vinod.koul, Lee Jones, linux-remoteproc, patrice.chotard,
	ML dri-devel, Linux-Kernel@Vger. Kernel. Org, Gerd Hoffmann,
	dmaengine, dan.j.williams, Bjorn Andersson,
	open list:VIRTIO GPU DRIVER, LAKML

On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:

> In fact the help text for VIRTIO even states this option should be selected
> by any driver which implements virtio.
>
Almost but not quite. It says:

"This option is selected by any driver which implements the virtio _bus_"

REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
the latter should _not_ select, be that explicitly or implicitly via
REMOTEPROC, the symbol.

>>
>> People tend to abuse select because it's "convenient". If you depend,
>> but some of your dependencies aren't met, you're in for some digging
>> through Kconfig to find the missing deps. Just to make the option you
>> want visible in menuconfig. If you instead select something with
>> dependencies, it'll be right most of the time, and it's "convenient",
>> until it breaks. (And hey, it usually breaks for someone else with some
>> other config, so it's still convenient for you.)
>
> I'm sure they do but in this case it is actually the use of 'depends on'
> which has caused the breakage and inconvenience for somebody else and sadly this
> inconvienice is still on-going due to this patch not being applied or getting an
> acked-by from the appropriate maintainers.
>
Surely you're not saying that pre-existing driver following the
documentation, is 'causing breakage' for a new driver {ab,mis}using a
feature ?

This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t
mean there is anything wrong with your feet."
You seem to be suggesting the opposite ?

>>
>> Perhaps kconfig should complain about selecting visible symbols and
>> symbols with dependencies.
>
> That sounds like it would be a useful addition.
>
> Is it possible to get this patch applied or an acked-by to avoid further delay
> to the fdma series?
>
Please don't apply duct tape, especially where it's _not_ needed.

$ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig

... will resolve things in the right place. The alternative will lead
to random issues in other subsystems.

Regards,
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06 10:45             ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 10:45 UTC (permalink / raw)
  To: Peter Griffin
  Cc: Jani Nikula, Arnd Bergmann, Ohad Ben-Cohen, devicetree, kernel,
	vinod.koul, Lee Jones, linux-remoteproc, patrice.chotard,
	ML dri-devel, Linux-Kernel@Vger. Kernel. Org, Gerd Hoffmann,
	dmaengine, dan.j.williams, Bjorn Andersson,
	open list:VIRTIO GPU DRIVER, LAKML

On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:

> In fact the help text for VIRTIO even states this option should be selected
> by any driver which implements virtio.
>
Almost but not quite. It says:

"This option is selected by any driver which implements the virtio _bus_"

REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
the latter should _not_ select, be that explicitly or implicitly via
REMOTEPROC, the symbol.

>>
>> People tend to abuse select because it's "convenient". If you depend,
>> but some of your dependencies aren't met, you're in for some digging
>> through Kconfig to find the missing deps. Just to make the option you
>> want visible in menuconfig. If you instead select something with
>> dependencies, it'll be right most of the time, and it's "convenient",
>> until it breaks. (And hey, it usually breaks for someone else with some
>> other config, so it's still convenient for you.)
>
> I'm sure they do but in this case it is actually the use of 'depends on'
> which has caused the breakage and inconvenience for somebody else and sadly this
> inconvienice is still on-going due to this patch not being applied or getting an
> acked-by from the appropriate maintainers.
>
Surely you're not saying that pre-existing driver following the
documentation, is 'causing breakage' for a new driver {ab,mis}using a
feature ?

This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t
mean there is anything wrong with your feet."
You seem to be suggesting the opposite ?

>>
>> Perhaps kconfig should complain about selecting visible symbols and
>> symbols with dependencies.
>
> That sounds like it would be a useful addition.
>
> Is it possible to get this patch applied or an acked-by to avoid further delay
> to the fdma series?
>
Please don't apply duct tape, especially where it's _not_ needed.

$ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig

... will resolve things in the right place. The alternative will lead
to random issues in other subsystems.

Regards,
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06 10:45             ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 10:45 UTC (permalink / raw)
  To: Peter Griffin
  Cc: Jani Nikula, Arnd Bergmann, Ohad Ben-Cohen, devicetree,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	Lee Jones, linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
	patrice.chotard-qxv4g6HH51o, ML dri-devel,
	Linux-Kernel@Vger. Kernel. Org, Gerd Hoffmann,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w, Bjorn Andersson,
	open list:VIRTIO GPU DRIVER, LAKML

On 6 October 2016 at 10:37, Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

> In fact the help text for VIRTIO even states this option should be selected
> by any driver which implements virtio.
>
Almost but not quite. It says:

"This option is selected by any driver which implements the virtio _bus_"

REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
the latter should _not_ select, be that explicitly or implicitly via
REMOTEPROC, the symbol.

>>
>> People tend to abuse select because it's "convenient". If you depend,
>> but some of your dependencies aren't met, you're in for some digging
>> through Kconfig to find the missing deps. Just to make the option you
>> want visible in menuconfig. If you instead select something with
>> dependencies, it'll be right most of the time, and it's "convenient",
>> until it breaks. (And hey, it usually breaks for someone else with some
>> other config, so it's still convenient for you.)
>
> I'm sure they do but in this case it is actually the use of 'depends on'
> which has caused the breakage and inconvenience for somebody else and sadly this
> inconvienice is still on-going due to this patch not being applied or getting an
> acked-by from the appropriate maintainers.
>
Surely you're not saying that pre-existing driver following the
documentation, is 'causing breakage' for a new driver {ab,mis}using a
feature ?

This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t
mean there is anything wrong with your feet."
You seem to be suggesting the opposite ?

>>
>> Perhaps kconfig should complain about selecting visible symbols and
>> symbols with dependencies.
>
> That sounds like it would be a useful addition.
>
> Is it possible to get this patch applied or an acked-by to avoid further delay
> to the fdma series?
>
Please don't apply duct tape, especially where it's _not_ needed.

$ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig

... will resolve things in the right place. The alternative will lead
to random issues in other subsystems.

Regards,
Emil
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-10-06  9:37           ` Peter Griffin
                             ` (2 preceding siblings ...)
  (?)
@ 2016-10-06 10:45           ` Emil Velikov
  -1 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 10:45 UTC (permalink / raw)
  To: Peter Griffin
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
	patrice.chotard, Jani Nikula, Linux-Kernel@Vger. Kernel. Org,
	ML dri-devel, dmaengine, LAKML, dan.j.williams, Bjorn Andersson,
	Lee Jones, open list:VIRTIO GPU DRIVER

On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:

> In fact the help text for VIRTIO even states this option should be selected
> by any driver which implements virtio.
>
Almost but not quite. It says:

"This option is selected by any driver which implements the virtio _bus_"

REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
the latter should _not_ select, be that explicitly or implicitly via
REMOTEPROC, the symbol.

>>
>> People tend to abuse select because it's "convenient". If you depend,
>> but some of your dependencies aren't met, you're in for some digging
>> through Kconfig to find the missing deps. Just to make the option you
>> want visible in menuconfig. If you instead select something with
>> dependencies, it'll be right most of the time, and it's "convenient",
>> until it breaks. (And hey, it usually breaks for someone else with some
>> other config, so it's still convenient for you.)
>
> I'm sure they do but in this case it is actually the use of 'depends on'
> which has caused the breakage and inconvenience for somebody else and sadly this
> inconvienice is still on-going due to this patch not being applied or getting an
> acked-by from the appropriate maintainers.
>
Surely you're not saying that pre-existing driver following the
documentation, is 'causing breakage' for a new driver {ab,mis}using a
feature ?

This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t
mean there is anything wrong with your feet."
You seem to be suggesting the opposite ?

>>
>> Perhaps kconfig should complain about selecting visible symbols and
>> symbols with dependencies.
>
> That sounds like it would be a useful addition.
>
> Is it possible to get this patch applied or an acked-by to avoid further delay
> to the fdma series?
>
Please don't apply duct tape, especially where it's _not_ needed.

$ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig

... will resolve things in the right place. The alternative will lead
to random issues in other subsystems.

Regards,
Emil
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06 10:45             ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 10:45 UTC (permalink / raw)
  To: linux-arm-kernel

On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:

> In fact the help text for VIRTIO even states this option should be selected
> by any driver which implements virtio.
>
Almost but not quite. It says:

"This option is selected by any driver which implements the virtio _bus_"

REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
the latter should _not_ select, be that explicitly or implicitly via
REMOTEPROC, the symbol.

>>
>> People tend to abuse select because it's "convenient". If you depend,
>> but some of your dependencies aren't met, you're in for some digging
>> through Kconfig to find the missing deps. Just to make the option you
>> want visible in menuconfig. If you instead select something with
>> dependencies, it'll be right most of the time, and it's "convenient",
>> until it breaks. (And hey, it usually breaks for someone else with some
>> other config, so it's still convenient for you.)
>
> I'm sure they do but in this case it is actually the use of 'depends on'
> which has caused the breakage and inconvenience for somebody else and sadly this
> inconvienice is still on-going due to this patch not being applied or getting an
> acked-by from the appropriate maintainers.
>
Surely you're not saying that pre-existing driver following the
documentation, is 'causing breakage' for a new driver {ab,mis}using a
feature ?

This reminds me an old saying: "If the shoe doesn?t fit, it doesn?t
mean there is anything wrong with your feet."
You seem to be suggesting the opposite ?

>>
>> Perhaps kconfig should complain about selecting visible symbols and
>> symbols with dependencies.
>
> That sounds like it would be a useful addition.
>
> Is it possible to get this patch applied or an acked-by to avoid further delay
> to the fdma series?
>
Please don't apply duct tape, especially where it's _not_ needed.

$ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig

... will resolve things in the right place. The alternative will lead
to random issues in other subsystems.

Regards,
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-21 12:09         ` Emil Velikov
  (?)
  (?)
@ 2016-10-06 10:48           ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-06 10:48 UTC (permalink / raw)
  To: Emil Velikov
  Cc: Arnd Bergmann, LAKML, Linux-Kernel@Vger. Kernel. Org, kernel,
	vinod.koul, patrice.chotard, dan.j.williams, David Airlie,
	Gerd Hoffmann, ohad, bjorn.andersson, devicetree,
	linux-remoteproc, ML dri-devel, open list:VIRTIO GPU DRIVER,
	dmaengine, lee.jones

Hi Emil,

On Wed, 21 Sep 2016, Emil Velikov wrote:

> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> Might be worth taking a closer look into these at some point.

VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
mentions that drivers should select it.

> 
> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >>
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >>
> >
> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> > mfd subsystem, client drivers select MFD_CORE.
> >
> On the USB case I'm not sure what the reasoning behind the USB vs
> USB_COMMON split. In seems that one could just fold them, but that's
> another topic. On the MFD side... it follows the select {,mis,ab}use.
> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
> it's own version of mfd_add_devices... which could be reworked,
> possibly.

Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
with no dependencies so it matches the documentation Jani referenced.

I personally think the approach taken makes sense, as why would you want to have
a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
which uses it also enabled in your kernel?

It seems to me a good solution to make the client drivers select the core
component so that it only gets enabled if at least one driver requires it.
This avoids having useless core code which will never be used compiled into the
kernel and in the end a smaller kernel size for a given kernel configuration (better
cache use etc etc).

> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> > recently, maybe he has some thoughts on whether this is the correct fix or not?
> >
> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
> reasonable, but it'll be great to hear others as well.

Yes me to. However I don't think anything in this patch is at odds with the
documentation Jani has referenced. 

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06 10:48           ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-06 10:48 UTC (permalink / raw)
  To: Emil Velikov
  Cc: Arnd Bergmann, LAKML, Linux-Kernel@Vger. Kernel. Org, kernel,
	vinod.koul, patrice.chotard, dan.j.williams, David Airlie,
	Gerd Hoffmann, ohad, bjorn.andersson, devicetree,
	linux-remoteproc, ML dri-devel, open list:VIRTIO GPU DRIVER,
	dmaengine, lee.jones

Hi Emil,

On Wed, 21 Sep 2016, Emil Velikov wrote:

> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> Might be worth taking a closer look into these at some point.

VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
mentions that drivers should select it.

> 
> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >>
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >>
> >
> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> > mfd subsystem, client drivers select MFD_CORE.
> >
> On the USB case I'm not sure what the reasoning behind the USB vs
> USB_COMMON split. In seems that one could just fold them, but that's
> another topic. On the MFD side... it follows the select {,mis,ab}use.
> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
> it's own version of mfd_add_devices... which could be reworked,
> possibly.

Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
with no dependencies so it matches the documentation Jani referenced.

I personally think the approach taken makes sense, as why would you want to have
a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
which uses it also enabled in your kernel?

It seems to me a good solution to make the client drivers select the core
component so that it only gets enabled if at least one driver requires it.
This avoids having useless core code which will never be used compiled into the
kernel and in the end a smaller kernel size for a given kernel configuration (better
cache use etc etc).

> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> > recently, maybe he has some thoughts on whether this is the correct fix or not?
> >
> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
> reasonable, but it'll be great to hear others as well.

Yes me to. However I don't think anything in this patch is at odds with the
documentation Jani has referenced. 

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06 10:48           ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-06 10:48 UTC (permalink / raw)
  To: Emil Velikov
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, lee.jones,
	linux-remoteproc, patrice.chotard, ML dri-devel,
	Linux-Kernel@Vger. Kernel. Org, David Airlie, dmaengine,
	dan.j.williams, bjorn.andersson, open list:VIRTIO GPU DRIVER,
	LAKML

Hi Emil,

On Wed, 21 Sep 2016, Emil Velikov wrote:

> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> Might be worth taking a closer look into these at some point.

VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
mentions that drivers should select it.

> 
> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >>
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >>
> >
> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> > mfd subsystem, client drivers select MFD_CORE.
> >
> On the USB case I'm not sure what the reasoning behind the USB vs
> USB_COMMON split. In seems that one could just fold them, but that's
> another topic. On the MFD side... it follows the select {,mis,ab}use.
> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
> it's own version of mfd_add_devices... which could be reworked,
> possibly.

Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
with no dependencies so it matches the documentation Jani referenced.

I personally think the approach taken makes sense, as why would you want to have
a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
which uses it also enabled in your kernel?

It seems to me a good solution to make the client drivers select the core
component so that it only gets enabled if at least one driver requires it.
This avoids having useless core code which will never be used compiled into the
kernel and in the end a smaller kernel size for a given kernel configuration (better
cache use etc etc).

> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> > recently, maybe he has some thoughts on whether this is the correct fix or not?
> >
> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
> reasonable, but it'll be great to hear others as well.

Yes me to. However I don't think anything in this patch is at odds with the
documentation Jani has referenced. 

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06 10:48           ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-06 10:48 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Emil,

On Wed, 21 Sep 2016, Emil Velikov wrote:

> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other subsystems
> >> I think the above is wrong. All the drivers (outside of remoteproc),
> >> that I've seen, depend on the core component, they don't select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
> > the other drivers in the remoteproc subsystem which has exposed this recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> Might be worth taking a closer look into these at some point.

VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
mentions that drivers should select it.

> 
> >
> >> Furthermore most places explicitly hide the drivers from the menu if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >>
> >> Is there something that requires such a different/unusual behaviour in
> >> remoteproc ?
> >>
> >
> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
> > mfd subsystem, client drivers select MFD_CORE.
> >
> On the USB case I'm not sure what the reasoning behind the USB vs
> USB_COMMON split. In seems that one could just fold them, but that's
> another topic. On the MFD side... it follows the select {,mis,ab}use.
> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
> it's own version of mfd_add_devices... which could be reworked,
> possibly.

Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
with no dependencies so it matches the documentation Jani referenced.

I personally think the approach taken makes sense, as why would you want to have
a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
which uses it also enabled in your kernel?

It seems to me a good solution to make the client drivers select the core
component so that it only gets enabled if at least one driver requires it.
This avoids having useless core code which will never be used compiled into the
kernel and in the end a smaller kernel size for a given kernel configuration (better
cache use etc etc).

> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
> > recently, maybe he has some thoughts on whether this is the correct fix or not?
> >
> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
> reasonable, but it'll be great to hear others as well.

Yes me to. However I don't think anything in this patch is at odds with the
documentation Jani has referenced. 

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-10-06 10:48           ` Peter Griffin
  (?)
@ 2016-10-06 11:31             ` Emil Velikov
  -1 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 11:31 UTC (permalink / raw)
  To: Peter Griffin
  Cc: Arnd Bergmann, LAKML, Linux-Kernel@Vger. Kernel. Org, kernel,
	vinod.koul, patrice.chotard, dan.j.williams, David Airlie,
	Gerd Hoffmann, Ohad Ben-Cohen, Bjorn Andersson, devicetree,
	linux-remoteproc, ML dri-devel, open list:VIRTIO GPU DRIVER,
	dmaengine, Lee Jones

Hi Peter,

On 6 October 2016 at 11:48, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Wed, 21 Sep 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> >> > recursive dependency.
>> >
>> >
>> >> >
>> >> From a humble skim through remoteproc, drm and a few other subsystems
>> >> I think the above is wrong. All the drivers (outside of remoteproc),
>> >> that I've seen, depend on the core component, they don't select it.
>> >
>> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
>> > why it is like it is.
>> >
>> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
>> > the other drivers in the remoteproc subsystem which has exposed this recursive
>> > dependency issue.
>> >
>> > For this particular kconfig symbol a quick grep reveals more drivers in
>> > the kernel using 'select', than 'depend on'
>> >
>> > git grep "select VIRTIO" | wc -l
>> > 14
>> >
>> > git grep "depends on VIRTIO" | wc -l
>> > 10
>> >
>> Might be worth taking a closer look into these at some point.
>
> VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
> mentions that drivers should select it.
>
This is a (un)fortunate detail cannot/should not overrule the other
arguments I've mentioned, should it ?

>>
>> >
>> >> Furthermore most places explicitly hide the drivers from the menu if
>> >> the core component isn't enabled.
>> >
>> > Remoteproc subsystem takes a different approach, the core code is only enabled
>> > if a driver which relies on it is enabled. This IMHO makes sense, as
>> > remoteproc is not widely used (only a few particular ARM SoC's).
>> >
>> > It is true that for subsystems which rely on the core component being
>> > explicitly enabled, they often tend to hide drivers which depend on it
>> > from the menu unless it is. This also makes sense.
>> >
>> >>
>> >> Is there something that requires such a different/unusual behaviour in
>> >> remoteproc ?
>> >>
>> >
>> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
>> > mfd subsystem, client drivers select MFD_CORE.
>> >
>> On the USB case I'm not sure what the reasoning behind the USB vs
>> USB_COMMON split. In seems that one could just fold them, but that's
>> another topic. On the MFD side... it follows the select {,mis,ab}use.
>> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
>> it's own version of mfd_add_devices... which could be reworked,
>> possibly.
>
> Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
> with no dependencies so it matches the documentation Jani referenced.
>
> I personally think the approach taken makes sense, as why would you want to have
> a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
> which uses it also enabled in your kernel?
>
> It seems to me a good solution to make the client drivers select the core
> component so that it only gets enabled if at least one driver requires it.
> This avoids having useless core code which will never be used compiled into the
> kernel and in the end a smaller kernel size for a given kernel configuration (better
> cache use etc etc).
>
>> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
>> > recently, maybe he has some thoughts on whether this is the correct fix or not?
>> >
>> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
>> reasonable, but it'll be great to hear others as well.
>
> Yes me to. However I don't think anything in this patch is at odds with the
> documentation Jani has referenced.
>
It case it's not clear, let me elaborate:

Yes, using depend might not be the most user-friendly thing to do and
in the long term we might want to move to select.
Yes, I agree with the argument about symbol visibility but that is not
the only contributing factor.

If one wants to pick on specific users which opt for $driver select
$core they must do the same for $driver depends on $core. Check the
number 'in favour" of each case and draw their conclusions ;-)

In particular: both MFD_CORE and USB_COMMON, are _optional_ as only
some drivers depends on them. Thus giving them as an example is
wrong/irrelevant, I'm afraid.

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06 11:31             ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 11:31 UTC (permalink / raw)
  To: Peter Griffin
  Cc: Arnd Bergmann, LAKML, Linux-Kernel@Vger. Kernel. Org, kernel,
	vinod.koul, patrice.chotard, dan.j.williams, David Airlie,
	Gerd Hoffmann, Ohad Ben-Cohen, Bjorn Andersson, devicetree,
	linux-remoteproc, ML dri-devel, open list:VIRTIO GPU DRIVER,
	dmaengine, Lee Jones

Hi Peter,

On 6 October 2016 at 11:48, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Wed, 21 Sep 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> >> > recursive dependency.
>> >
>> >
>> >> >
>> >> From a humble skim through remoteproc, drm and a few other subsystems
>> >> I think the above is wrong. All the drivers (outside of remoteproc),
>> >> that I've seen, depend on the core component, they don't select it.
>> >
>> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
>> > why it is like it is.
>> >
>> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
>> > the other drivers in the remoteproc subsystem which has exposed this recursive
>> > dependency issue.
>> >
>> > For this particular kconfig symbol a quick grep reveals more drivers in
>> > the kernel using 'select', than 'depend on'
>> >
>> > git grep "select VIRTIO" | wc -l
>> > 14
>> >
>> > git grep "depends on VIRTIO" | wc -l
>> > 10
>> >
>> Might be worth taking a closer look into these at some point.
>
> VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
> mentions that drivers should select it.
>
This is a (un)fortunate detail cannot/should not overrule the other
arguments I've mentioned, should it ?

>>
>> >
>> >> Furthermore most places explicitly hide the drivers from the menu if
>> >> the core component isn't enabled.
>> >
>> > Remoteproc subsystem takes a different approach, the core code is only enabled
>> > if a driver which relies on it is enabled. This IMHO makes sense, as
>> > remoteproc is not widely used (only a few particular ARM SoC's).
>> >
>> > It is true that for subsystems which rely on the core component being
>> > explicitly enabled, they often tend to hide drivers which depend on it
>> > from the menu unless it is. This also makes sense.
>> >
>> >>
>> >> Is there something that requires such a different/unusual behaviour in
>> >> remoteproc ?
>> >>
>> >
>> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
>> > mfd subsystem, client drivers select MFD_CORE.
>> >
>> On the USB case I'm not sure what the reasoning behind the USB vs
>> USB_COMMON split. In seems that one could just fold them, but that's
>> another topic. On the MFD side... it follows the select {,mis,ab}use.
>> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
>> it's own version of mfd_add_devices... which could be reworked,
>> possibly.
>
> Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
> with no dependencies so it matches the documentation Jani referenced.
>
> I personally think the approach taken makes sense, as why would you want to have
> a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
> which uses it also enabled in your kernel?
>
> It seems to me a good solution to make the client drivers select the core
> component so that it only gets enabled if at least one driver requires it.
> This avoids having useless core code which will never be used compiled into the
> kernel and in the end a smaller kernel size for a given kernel configuration (better
> cache use etc etc).
>
>> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
>> > recently, maybe he has some thoughts on whether this is the correct fix or not?
>> >
>> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
>> reasonable, but it'll be great to hear others as well.
>
> Yes me to. However I don't think anything in this patch is at odds with the
> documentation Jani has referenced.
>
It case it's not clear, let me elaborate:

Yes, using depend might not be the most user-friendly thing to do and
in the long term we might want to move to select.
Yes, I agree with the argument about symbol visibility but that is not
the only contributing factor.

If one wants to pick on specific users which opt for $driver select
$core they must do the same for $driver depends on $core. Check the
number 'in favour" of each case and draw their conclusions ;-)

In particular: both MFD_CORE and USB_COMMON, are _optional_ as only
some drivers depends on them. Thus giving them as an example is
wrong/irrelevant, I'm afraid.

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-10-06 10:48           ` Peter Griffin
                             ` (3 preceding siblings ...)
  (?)
@ 2016-10-06 11:31           ` Emil Velikov
  -1 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 11:31 UTC (permalink / raw)
  To: Peter Griffin
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, Lee Jones,
	linux-remoteproc, patrice.chotard, ML dri-devel,
	Linux-Kernel@Vger. Kernel. Org, David Airlie, dmaengine,
	dan.j.williams, Bjorn Andersson, open list:VIRTIO GPU DRIVER,
	LAKML

Hi Peter,

On 6 October 2016 at 11:48, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Wed, 21 Sep 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> >> > recursive dependency.
>> >
>> >
>> >> >
>> >> From a humble skim through remoteproc, drm and a few other subsystems
>> >> I think the above is wrong. All the drivers (outside of remoteproc),
>> >> that I've seen, depend on the core component, they don't select it.
>> >
>> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
>> > why it is like it is.
>> >
>> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
>> > the other drivers in the remoteproc subsystem which has exposed this recursive
>> > dependency issue.
>> >
>> > For this particular kconfig symbol a quick grep reveals more drivers in
>> > the kernel using 'select', than 'depend on'
>> >
>> > git grep "select VIRTIO" | wc -l
>> > 14
>> >
>> > git grep "depends on VIRTIO" | wc -l
>> > 10
>> >
>> Might be worth taking a closer look into these at some point.
>
> VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
> mentions that drivers should select it.
>
This is a (un)fortunate detail cannot/should not overrule the other
arguments I've mentioned, should it ?

>>
>> >
>> >> Furthermore most places explicitly hide the drivers from the menu if
>> >> the core component isn't enabled.
>> >
>> > Remoteproc subsystem takes a different approach, the core code is only enabled
>> > if a driver which relies on it is enabled. This IMHO makes sense, as
>> > remoteproc is not widely used (only a few particular ARM SoC's).
>> >
>> > It is true that for subsystems which rely on the core component being
>> > explicitly enabled, they often tend to hide drivers which depend on it
>> > from the menu unless it is. This also makes sense.
>> >
>> >>
>> >> Is there something that requires such a different/unusual behaviour in
>> >> remoteproc ?
>> >>
>> >
>> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
>> > mfd subsystem, client drivers select MFD_CORE.
>> >
>> On the USB case I'm not sure what the reasoning behind the USB vs
>> USB_COMMON split. In seems that one could just fold them, but that's
>> another topic. On the MFD side... it follows the select {,mis,ab}use.
>> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
>> it's own version of mfd_add_devices... which could be reworked,
>> possibly.
>
> Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
> with no dependencies so it matches the documentation Jani referenced.
>
> I personally think the approach taken makes sense, as why would you want to have
> a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
> which uses it also enabled in your kernel?
>
> It seems to me a good solution to make the client drivers select the core
> component so that it only gets enabled if at least one driver requires it.
> This avoids having useless core code which will never be used compiled into the
> kernel and in the end a smaller kernel size for a given kernel configuration (better
> cache use etc etc).
>
>> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
>> > recently, maybe he has some thoughts on whether this is the correct fix or not?
>> >
>> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
>> reasonable, but it'll be great to hear others as well.
>
> Yes me to. However I don't think anything in this patch is at odds with the
> documentation Jani has referenced.
>
It case it's not clear, let me elaborate:

Yes, using depend might not be the most user-friendly thing to do and
in the long term we might want to move to select.
Yes, I agree with the argument about symbol visibility but that is not
the only contributing factor.

If one wants to pick on specific users which opt for $driver select
$core they must do the same for $driver depends on $core. Check the
number 'in favour" of each case and draw their conclusions ;-)

In particular: both MFD_CORE and USB_COMMON, are _optional_ as only
some drivers depends on them. Thus giving them as an example is
wrong/irrelevant, I'm afraid.

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-06 11:31             ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-10-06 11:31 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Peter,

On 6 October 2016 at 11:48, Peter Griffin <peter.griffin@linaro.org> wrote:
> Hi Emil,
>
> On Wed, 21 Sep 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin <peter.griffin@linaro.org> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>> >
>> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
>> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> >> > recursive dependency.
>> >
>> >
>> >> >
>> >> From a humble skim through remoteproc, drm and a few other subsystems
>> >> I think the above is wrong. All the drivers (outside of remoteproc),
>> >> that I've seen, depend on the core component, they don't select it.
>> >
>> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and
>> > why it is like it is.
>> >
>> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all
>> > the other drivers in the remoteproc subsystem which has exposed this recursive
>> > dependency issue.
>> >
>> > For this particular kconfig symbol a quick grep reveals more drivers in
>> > the kernel using 'select', than 'depend on'
>> >
>> > git grep "select VIRTIO" | wc -l
>> > 14
>> >
>> > git grep "depends on VIRTIO" | wc -l
>> > 10
>> >
>> Might be worth taking a closer look into these at some point.
>
> VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also
> mentions that drivers should select it.
>
This is a (un)fortunate detail cannot/should not overrule the other
arguments I've mentioned, should it ?

>>
>> >
>> >> Furthermore most places explicitly hide the drivers from the menu if
>> >> the core component isn't enabled.
>> >
>> > Remoteproc subsystem takes a different approach, the core code is only enabled
>> > if a driver which relies on it is enabled. This IMHO makes sense, as
>> > remoteproc is not widely used (only a few particular ARM SoC's).
>> >
>> > It is true that for subsystems which rely on the core component being
>> > explicitly enabled, they often tend to hide drivers which depend on it
>> > from the menu unless it is. This also makes sense.
>> >
>> >>
>> >> Is there something that requires such a different/unusual behaviour in
>> >> remoteproc ?
>> >>
>> >
>> > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in
>> > mfd subsystem, client drivers select MFD_CORE.
>> >
>> On the USB case I'm not sure what the reasoning behind the USB vs
>> USB_COMMON split. In seems that one could just fold them, but that's
>> another topic. On the MFD side... it follows the select {,mis,ab}use.
>> With one (the only one?) MFD driver not using/selecting MFD_CORE doing
>> it's own version of mfd_add_devices... which could be reworked,
>> possibly.
>
> Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol
> with no dependencies so it matches the documentation Jani referenced.
>
> I personally think the approach taken makes sense, as why would you want to have
> a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device
> which uses it also enabled in your kernel?
>
> It seems to me a good solution to make the client drivers select the core
> component so that it only gets enabled if at least one driver requires it.
> This avoids having useless core code which will never be used compiled into the
> kernel and in the end a smaller kernel size for a given kernel configuration (better
> cache use etc etc).
>
>> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him
>> > recently, maybe he has some thoughts on whether this is the correct fix or not?
>> >
>> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty
>> reasonable, but it'll be great to hear others as well.
>
> Yes me to. However I don't think anything in this patch is at odds with the
> documentation Jani has referenced.
>
It case it's not clear, let me elaborate:

Yes, using depend might not be the most user-friendly thing to do and
in the long term we might want to move to select.
Yes, I agree with the argument about symbol visibility but that is not
the only contributing factor.

If one wants to pick on specific users which opt for $driver select
$core they must do the same for $driver depends on $core. Check the
number 'in favour" of each case and draw their conclusions ;-)

In particular: both MFD_CORE and USB_COMMON, are _optional_ as only
some drivers depends on them. Thus giving them as an example is
wrong/irrelevant, I'm afraid.

Thanks
Emil

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-10-06 10:45             ` Emil Velikov
  (?)
  (?)
@ 2016-10-07 17:44               ` Peter Griffin
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-07 17:44 UTC (permalink / raw)
  To: Emil Velikov
  Cc: Jani Nikula, Arnd Bergmann, Ohad Ben-Cohen, devicetree, kernel,
	vinod.koul, Lee Jones, linux-remoteproc, patrice.chotard,
	ML dri-devel, Linux-Kernel@Vger. Kernel. Org, Gerd Hoffmann,
	dmaengine, dan.j.williams, Bjorn Andersson,
	open list:VIRTIO GPU DRIVER, LAKML

Hi Emil,

On Thu, 06 Oct 2016, Emil Velikov wrote:

> On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:
> 
> > In fact the help text for VIRTIO even states this option should be selected
> > by any driver which implements virtio.
> >
> Almost but not quite. It says:
> 
> "This option is selected by any driver which implements the virtio _bus_"
> 

Ah I thought DRM_VIRTIO_GPU was implementing a virtio bus, bus it seems that it 
uses pci. Which does raise the question of why it is depending on VIRTIO at all
and not VIRTIO_PCI.

> REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
> the latter should _not_ select, be that explicitly or implicitly via
> REMOTEPROC, the symbol.

Yep OK.

> 
> >>
> >> People tend to abuse select because it's "convenient". If you depend,
> >> but some of your dependencies aren't met, you're in for some digging
> >> through Kconfig to find the missing deps. Just to make the option you
> >> want visible in menuconfig. If you instead select something with
> >> dependencies, it'll be right most of the time, and it's "convenient",
> >> until it breaks. (And hey, it usually breaks for someone else with some
> >> other config, so it's still convenient for you.)
> >
> > I'm sure they do but in this case it is actually the use of 'depends on'
> > which has caused the breakage and inconvenience for somebody else and sadly this
> > inconvienice is still on-going due to this patch not being applied or getting an
> > acked-by from the appropriate maintainers.
> >
> Surely you're not saying that pre-existing driver following the
> documentation, is 'causing breakage' for a new driver {ab,mis}using a
> feature ?

Your right I wasn't saying that :)

My point was that this patch wasn't 'wrong' when referring to the Kconfig
documentation Jani referenced as VIRTIO has no dependencies.

Also I thought DRM_VIRTIO_GPU driver implemented a VIRTIO bus which re-enforced
the view that it should be selecting VIRTIO. 

> 
> This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t
> mean there is anything wrong with your feet."

If the shoe doesn't fit, chop off the leg :)

> You seem to be suggesting the opposite ?
> 
> >>
> >> Perhaps kconfig should complain about selecting visible symbols and
> >> symbols with dependencies.
> >
> > That sounds like it would be a useful addition.
> >
> > Is it possible to get this patch applied or an acked-by to avoid further delay
> > to the fdma series?
> >
> Please don't apply duct tape, especially where it's _not_ needed.
> 
> $ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig
> 
> ... will resolve things in the right place. The alternative will lead
> to random issues in other subsystems.
> 

If Bjorn is OK with it, then it is fine with me.

I will update remoteproc Kconfig setup in fdma v10, this will drop the
requirement for this patch in drm subsystem.

I can then send the whitespace cleanup patch separately to DRM ML.

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-07 17:44               ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-07 17:44 UTC (permalink / raw)
  To: Emil Velikov
  Cc: Jani Nikula, Arnd Bergmann, Ohad Ben-Cohen, devicetree, kernel,
	vinod.koul, Lee Jones, linux-remoteproc, patrice.chotard,
	ML dri-devel, Linux-Kernel@Vger. Kernel. Org, Gerd Hoffmann,
	dmaengine, dan.j.williams, Bjorn Andersson,
	open list:VIRTIO GPU DRIVER, LAKML

Hi Emil,

On Thu, 06 Oct 2016, Emil Velikov wrote:

> On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:
> 
> > In fact the help text for VIRTIO even states this option should be selected
> > by any driver which implements virtio.
> >
> Almost but not quite. It says:
> 
> "This option is selected by any driver which implements the virtio _bus_"
> 

Ah I thought DRM_VIRTIO_GPU was implementing a virtio bus, bus it seems that it 
uses pci. Which does raise the question of why it is depending on VIRTIO at all
and not VIRTIO_PCI.

> REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
> the latter should _not_ select, be that explicitly or implicitly via
> REMOTEPROC, the symbol.

Yep OK.

> 
> >>
> >> People tend to abuse select because it's "convenient". If you depend,
> >> but some of your dependencies aren't met, you're in for some digging
> >> through Kconfig to find the missing deps. Just to make the option you
> >> want visible in menuconfig. If you instead select something with
> >> dependencies, it'll be right most of the time, and it's "convenient",
> >> until it breaks. (And hey, it usually breaks for someone else with some
> >> other config, so it's still convenient for you.)
> >
> > I'm sure they do but in this case it is actually the use of 'depends on'
> > which has caused the breakage and inconvenience for somebody else and sadly this
> > inconvienice is still on-going due to this patch not being applied or getting an
> > acked-by from the appropriate maintainers.
> >
> Surely you're not saying that pre-existing driver following the
> documentation, is 'causing breakage' for a new driver {ab,mis}using a
> feature ?

Your right I wasn't saying that :)

My point was that this patch wasn't 'wrong' when referring to the Kconfig
documentation Jani referenced as VIRTIO has no dependencies.

Also I thought DRM_VIRTIO_GPU driver implemented a VIRTIO bus which re-enforced
the view that it should be selecting VIRTIO. 

> 
> This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t
> mean there is anything wrong with your feet."

If the shoe doesn't fit, chop off the leg :)

> You seem to be suggesting the opposite ?
> 
> >>
> >> Perhaps kconfig should complain about selecting visible symbols and
> >> symbols with dependencies.
> >
> > That sounds like it would be a useful addition.
> >
> > Is it possible to get this patch applied or an acked-by to avoid further delay
> > to the fdma series?
> >
> Please don't apply duct tape, especially where it's _not_ needed.
> 
> $ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig
> 
> ... will resolve things in the right place. The alternative will lead
> to random issues in other subsystems.
> 

If Bjorn is OK with it, then it is fine with me.

I will update remoteproc Kconfig setup in fdma v10, this will drop the
requirement for this patch in drm subsystem.

I can then send the whitespace cleanup patch separately to DRM ML.

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-07 17:44               ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-07 17:44 UTC (permalink / raw)
  To: Emil Velikov
  Cc: devicetree, kernel, Arnd Bergmann, vinod.koul, linux-remoteproc,
	patrice.chotard, Jani Nikula, Linux-Kernel@Vger. Kernel. Org,
	ML dri-devel, dmaengine, LAKML, dan.j.williams, Bjorn Andersson,
	Lee Jones, open list:VIRTIO GPU DRIVER

Hi Emil,

On Thu, 06 Oct 2016, Emil Velikov wrote:

> On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:
> 
> > In fact the help text for VIRTIO even states this option should be selected
> > by any driver which implements virtio.
> >
> Almost but not quite. It says:
> 
> "This option is selected by any driver which implements the virtio _bus_"
> 

Ah I thought DRM_VIRTIO_GPU was implementing a virtio bus, bus it seems that it 
uses pci. Which does raise the question of why it is depending on VIRTIO at all
and not VIRTIO_PCI.

> REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
> the latter should _not_ select, be that explicitly or implicitly via
> REMOTEPROC, the symbol.

Yep OK.

> 
> >>
> >> People tend to abuse select because it's "convenient". If you depend,
> >> but some of your dependencies aren't met, you're in for some digging
> >> through Kconfig to find the missing deps. Just to make the option you
> >> want visible in menuconfig. If you instead select something with
> >> dependencies, it'll be right most of the time, and it's "convenient",
> >> until it breaks. (And hey, it usually breaks for someone else with some
> >> other config, so it's still convenient for you.)
> >
> > I'm sure they do but in this case it is actually the use of 'depends on'
> > which has caused the breakage and inconvenience for somebody else and sadly this
> > inconvienice is still on-going due to this patch not being applied or getting an
> > acked-by from the appropriate maintainers.
> >
> Surely you're not saying that pre-existing driver following the
> documentation, is 'causing breakage' for a new driver {ab,mis}using a
> feature ?

Your right I wasn't saying that :)

My point was that this patch wasn't 'wrong' when referring to the Kconfig
documentation Jani referenced as VIRTIO has no dependencies.

Also I thought DRM_VIRTIO_GPU driver implemented a VIRTIO bus which re-enforced
the view that it should be selecting VIRTIO. 

> 
> This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t
> mean there is anything wrong with your feet."

If the shoe doesn't fit, chop off the leg :)

> You seem to be suggesting the opposite ?
> 
> >>
> >> Perhaps kconfig should complain about selecting visible symbols and
> >> symbols with dependencies.
> >
> > That sounds like it would be a useful addition.
> >
> > Is it possible to get this patch applied or an acked-by to avoid further delay
> > to the fdma series?
> >
> Please don't apply duct tape, especially where it's _not_ needed.
> 
> $ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig
> 
> ... will resolve things in the right place. The alternative will lead
> to random issues in other subsystems.
> 

If Bjorn is OK with it, then it is fine with me.

I will update remoteproc Kconfig setup in fdma v10, this will drop the
requirement for this patch in drm subsystem.

I can then send the whitespace cleanup patch separately to DRM ML.

regards,

Peter.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 174+ messages in thread

* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
@ 2016-10-07 17:44               ` Peter Griffin
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Griffin @ 2016-10-07 17:44 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Emil,

On Thu, 06 Oct 2016, Emil Velikov wrote:

> On 6 October 2016 at 10:37, Peter Griffin <peter.griffin@linaro.org> wrote:
> 
> > In fact the help text for VIRTIO even states this option should be selected
> > by any driver which implements virtio.
> >
> Almost but not quite. It says:
> 
> "This option is selected by any driver which implements the virtio _bus_"
> 

Ah I thought DRM_VIRTIO_GPU was implementing a virtio bus, bus it seems that it 
uses pci. Which does raise the question of why it is depending on VIRTIO at all
and not VIRTIO_PCI.

> REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
> the latter should _not_ select, be that explicitly or implicitly via
> REMOTEPROC, the symbol.

Yep OK.

> 
> >>
> >> People tend to abuse select because it's "convenient". If you depend,
> >> but some of your dependencies aren't met, you're in for some digging
> >> through Kconfig to find the missing deps. Just to make the option you
> >> want visible in menuconfig. If you instead select something with
> >> dependencies, it'll be right most of the time, and it's "convenient",
> >> until it breaks. (And hey, it usually breaks for someone else with some
> >> other config, so it's still convenient for you.)
> >
> > I'm sure they do but in this case it is actually the use of 'depends on'
> > which has caused the breakage and inconvenience for somebody else and sadly this
> > inconvienice is still on-going due to this patch not being applied or getting an
> > acked-by from the appropriate maintainers.
> >
> Surely you're not saying that pre-existing driver following the
> documentation, is 'causing breakage' for a new driver {ab,mis}using a
> feature ?

Your right I wasn't saying that :)

My point was that this patch wasn't 'wrong' when referring to the Kconfig
documentation Jani referenced as VIRTIO has no dependencies.

Also I thought DRM_VIRTIO_GPU driver implemented a VIRTIO bus which re-enforced
the view that it should be selecting VIRTIO. 

> 
> This reminds me an old saying: "If the shoe doesn?t fit, it doesn?t
> mean there is anything wrong with your feet."

If the shoe doesn't fit, chop off the leg :)

> You seem to be suggesting the opposite ?
> 
> >>
> >> Perhaps kconfig should complain about selecting visible symbols and
> >> symbols with dependencies.
> >
> > That sounds like it would be a useful addition.
> >
> > Is it possible to get this patch applied or an acked-by to avoid further delay
> > to the fdma series?
> >
> Please don't apply duct tape, especially where it's _not_ needed.
> 
> $ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig
> 
> ... will resolve things in the right place. The alternative will lead
> to random issues in other subsystems.
> 

If Bjorn is OK with it, then it is fine with me.

I will update remoteproc Kconfig setup in fdma v10, this will drop the
requirement for this patch in drm subsystem.

I can then send the whitespace cleanup patch separately to DRM ML.

regards,

Peter.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-20  7:20   ` [PATCH v9 17/19] " Emil Velikov
@ 2016-09-20  7:24     ` Emil Velikov
  0 siblings, 0 replies; 174+ messages in thread
From: Emil Velikov @ 2016-09-20  7:24 UTC (permalink / raw)
  To: Peter Griffin
  Cc: sfr, kernel, airlied, linux-kernel, dri-devel, bjorn.andersson,
	vinod.koul, virtualization, lee.jones, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 206 bytes --]

On Tuesday, 20 September 2016, Emil Velikov <emil.l.velikov@gmail.com>
wrote:


>  Did you miss my earlier question/suggestion that mentions that ?
>
Please scratch that. Just noticed the timestamps.

Emil

[-- Attachment #1.2: Type: text/html, Size: 426 bytes --]

[-- Attachment #2: Type: text/plain, Size: 183 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
  2016-09-19  9:34 ` [PATCH 1/2] drm/virtio: kconfig: Fix recursive dependency issue Peter Griffin
@ 2016-09-20  7:20   ` Emil Velikov
  2016-09-20  7:24     ` Emil Velikov
  0 siblings, 1 reply; 174+ messages in thread
From: Emil Velikov @ 2016-09-20  7:20 UTC (permalink / raw)
  To: Peter Griffin
  Cc: sfr, kernel, airlied, linux-kernel, dri-devel, bjorn.andersson,
	vinod.koul, virtualization, lee.jones, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 296 bytes --]

On Monday, 19 September 2016, Peter Griffin <peter.griffin@linaro.org>
wrote:

> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
> It must not select, it must depend? Did you miss my earlier
question/suggestion that mentions that ?

Regards,
Emil

[-- Attachment #1.2: Type: text/html, Size: 517 bytes --]

[-- Attachment #2: Type: text/plain, Size: 183 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 174+ messages in thread

end of thread, other threads:[~2016-10-07 17:44 UTC | newest]

Thread overview: 174+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-05 13:16 [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 01/19] remoteproc: st_slim_rproc: add a slimcore rproc driver Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-13 17:56   ` Bjorn Andersson
2016-09-13 17:56     ` Bjorn Andersson
2016-09-13 17:56     ` Bjorn Andersson
2016-09-14  8:30     ` Lee Jones
2016-09-14  8:30     ` Lee Jones
2016-09-14  8:30       ` Lee Jones
2016-09-14  8:30       ` Lee Jones
2016-09-05 13:16 ` [PATCH v9 02/19] MAINTAINERS: Add st slim core rproc driver to STi section Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 03/19] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 04/19] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 05/19] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 06/19] ARM: STi: DT: STiH407: Add FDMA driver dt nodes Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 11:59   ` Patrice Chotard
2016-09-14 11:59     ` Patrice Chotard
2016-09-14 11:59     ` Patrice Chotard
2016-09-14 11:59     ` Patrice Chotard
2016-09-14 11:59   ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 07/19] MAINTAINERS: Add FDMA driver files to STi section Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 08/19] ARM: multi_v7_defconfig: Enable STi FDMA driver Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 09/19] ARM: multi_v7_defconfig: Enable STi and simple-card drivers Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 10/19] ARM: DT: STiH407: Add i2s_out pinctrl configuration Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:00   ` Patrice Chotard
2016-09-14 12:00   ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 11/19] ARM: DT: STiH407: Add i2s_in " Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:00   ` Patrice Chotard
2016-09-14 12:00   ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 12/19] ARM: DT: STiH407: Add spdif_out pinctrl config Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:00   ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-14 12:00     ` Patrice Chotard
2016-09-14 12:00   ` Patrice Chotard
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 13/19] ARM: STi: DT: STiH407: Add sti-sasg-codec dt node Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 14/19] ARM: STi: DT: STiH407: Add uniperif player dt nodes Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 15/19] ARM: STi: DT: STiH407: Add uniperif reader " Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-05 13:16 ` [PATCH v9 16/19] ARM: DT: STi: stihxxx-b2120: Add DT nodes for STi audio card Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-14 12:01   ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-14 12:01     ` Patrice Chotard
2016-09-14 12:01   ` Patrice Chotard
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16 ` [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue Peter Griffin
2016-09-05 13:16 ` Peter Griffin
2016-09-05 13:16   ` Peter Griffin
2016-09-19 23:18   ` Emil Velikov
2016-09-19 23:18     ` Emil Velikov
2016-09-19 23:18     ` Emil Velikov
2016-09-19 23:18     ` Emil Velikov
2016-09-19 23:18     ` Emil Velikov
2016-09-20  8:32     ` Peter Griffin
2016-09-20  8:32       ` Peter Griffin
2016-09-20  8:32       ` Peter Griffin
2016-09-20  8:32       ` Peter Griffin
2016-09-20  9:33       ` Jani Nikula
2016-09-20  9:33       ` Jani Nikula
2016-09-20  9:33         ` Jani Nikula
2016-09-20  9:33         ` Jani Nikula
2016-09-20  9:33         ` Jani Nikula
2016-10-06  9:37         ` Peter Griffin
2016-10-06  9:37           ` Peter Griffin
2016-10-06  9:37           ` Peter Griffin
2016-10-06  9:37           ` Peter Griffin
2016-10-06 10:45           ` Emil Velikov
2016-10-06 10:45           ` Emil Velikov
2016-10-06 10:45             ` Emil Velikov
2016-10-06 10:45             ` Emil Velikov
2016-10-06 10:45             ` Emil Velikov
2016-10-07 17:44             ` Peter Griffin
2016-10-07 17:44               ` Peter Griffin
2016-10-07 17:44               ` Peter Griffin
2016-10-07 17:44               ` Peter Griffin
2016-09-21 12:09       ` Emil Velikov
2016-09-21 12:09       ` Emil Velikov
2016-09-21 12:09         ` Emil Velikov
2016-09-21 12:09         ` Emil Velikov
2016-09-27 17:01         ` Bjorn Andersson
2016-09-27 17:01           ` Bjorn Andersson
2016-09-27 17:01           ` Bjorn Andersson
2016-09-27 17:01           ` Bjorn Andersson
2016-10-06 10:10           ` Emil Velikov
2016-10-06 10:10           ` Emil Velikov
2016-10-06 10:10             ` Emil Velikov
2016-10-06 10:10             ` Emil Velikov
2016-10-06 10:48         ` Peter Griffin
2016-10-06 10:48           ` Peter Griffin
2016-10-06 10:48           ` Peter Griffin
2016-10-06 10:48           ` Peter Griffin
2016-10-06 11:31           ` Emil Velikov
2016-10-06 11:31             ` Emil Velikov
2016-10-06 11:31             ` Emil Velikov
2016-10-06 11:31           ` Emil Velikov
2016-09-05 13:17 ` [PATCH v9 18/19] drm/virtio: kconfig: Fixup white space Peter Griffin
2016-09-05 13:17   ` Peter Griffin
2016-09-05 13:17 ` Peter Griffin
2016-09-05 13:17 ` [PATCH v9 19/19] dmaengine: kconfig: Remove superfluous '\n' Peter Griffin
2016-09-05 13:17   ` Peter Griffin
2016-09-05 13:17   ` Peter Griffin
2016-09-05 13:17 ` Peter Griffin
2016-09-13  9:31 ` [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets Peter Griffin
2016-09-13  9:31 ` Peter Griffin
2016-09-13  9:31   ` Peter Griffin
2016-09-13  9:31   ` Peter Griffin
2016-09-13 18:06   ` Bjorn Andersson
2016-09-13 18:06   ` Bjorn Andersson
2016-09-13 18:06     ` Bjorn Andersson
2016-09-13 18:06     ` Bjorn Andersson
2016-09-14  6:59     ` Patrice Chotard
2016-09-14  6:59       ` Patrice Chotard
2016-09-14  6:59       ` Patrice Chotard
2016-09-14  6:59       ` Patrice Chotard
2016-09-14  6:59     ` Patrice Chotard
2016-09-14 13:07     ` Vinod Koul
2016-09-14 13:07       ` Vinod Koul
2016-09-14 13:07       ` Vinod Koul
2016-09-15 16:20       ` Vinod Koul
2016-09-15 16:20       ` Vinod Koul
2016-09-15 16:20         ` Vinod Koul
2016-09-15 16:20         ` Vinod Koul
2016-09-14 13:07     ` Vinod Koul
2016-09-19  9:34 [PATCH 0/2] Fix recursive Kconfig depedency issue Peter Griffin
2016-09-19  9:34 ` [PATCH 1/2] drm/virtio: kconfig: Fix recursive dependency issue Peter Griffin
2016-09-20  7:20   ` [PATCH v9 17/19] " Emil Velikov
2016-09-20  7:24     ` Emil Velikov

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.