Re: [PATCH 00/13] uio_pruss: add support for devicetree and am33xx

2014-07-09 Thread Hans J. Koch
On Mon, Jul 07, 2014 at 05:50:09PM +, Paul Walmsley wrote:
 On Mon, 7 Jul 2014, Andre Heider wrote:
 
  On Sun, Jun 29, 2014 at 06:21:34PM +0200, Andre Heider wrote:
   
   this series adds PRUv2 support to uio_pruss through devicetree, makes the
   device usable on am33xx and enables it on beaglebone black.
   Inspired by old patches from Matt Porter found in a downstream tree.
   
   To archieve that this series:
   * adds a flag to omap_hwmod.c to get PRUSS out of hardreset (patch 5 and 
   6)
 
 ...
 
   * is the hardreset thing I did there the right thing to do? I think the
 proper way would be a reset controller (which apparently doesn't yet 
   exist
 for this SoC?) and let the driver deassert/assert on probe/remove?
   * the platform device path has a clk_enable() / clk_put() calls. Are those
 now redundant with the introduced pm_runtime_enable() 
   pm_runtime_disable()
 calls?
 
 Probably you only need pm_runtime_{get,put}_*() calls, unless you're 
 changing clock parents or rates in your driver code.
 
  @OMAP guys: any comments? The series depends on patch 5 and 6; both touch
  common hwmod code.
 
 I'd suggest splitting the series into three independent pieces if 
 possible:
 
 1. UIO code, for the UIO maintainer(s)
 2. DT pieces for Tony
 3. hwmod pieces for me
 
 That way they can be cleanly merged by the respective maintainers.

I second that. At first sight, the UIO parts look OK to me, but please
make it a new patch series.

Thanks,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/13] uio_pruss: add support for devicetree and am33xx

2014-07-09 Thread Andre Heider
On Mon, Jul 07, 2014 at 05:50:09PM +, Paul Walmsley wrote:
 On Mon, 7 Jul 2014, Andre Heider wrote:
 
  On Sun, Jun 29, 2014 at 06:21:34PM +0200, Andre Heider wrote:
   
   this series adds PRUv2 support to uio_pruss through devicetree, makes the
   device usable on am33xx and enables it on beaglebone black.
   Inspired by old patches from Matt Porter found in a downstream tree.
   
   To archieve that this series:
   * adds a flag to omap_hwmod.c to get PRUSS out of hardreset (patch 5 and 
   6)
 
 ...
 
   * is the hardreset thing I did there the right thing to do? I think the
 proper way would be a reset controller (which apparently doesn't yet 
   exist
 for this SoC?) and let the driver deassert/assert on probe/remove?
   * the platform device path has a clk_enable() / clk_put() calls. Are those
 now redundant with the introduced pm_runtime_enable() 
   pm_runtime_disable()
 calls?
 
 Probably you only need pm_runtime_{get,put}_*() calls, unless you're 
 changing clock parents or rates in your driver code.

No, the driver doesn't do that. So I can clean that up, nice.

 
  @OMAP guys: any comments? The series depends on patch 5 and 6; both touch
  common hwmod code.
 
 I'd suggest splitting the series into three independent pieces if 
 possible:
 
 1. UIO code, for the UIO maintainer(s)
 2. DT pieces for Tony
 3. hwmod pieces for me
 
 That way they can be cleanly merged by the respective maintainers.
 
 As far as the hwmod piece goes, I'd be willing to merge your code as a 
 temporary workaround for the issue, and marking it as such; but I'd be 
 concerned about power management-related interactions (i.e., does the 
 PRUSS need to be reset upon return from deep idle states, etc.)

Alright, thanks Paul.

About the deep idle states... I'm not sure, I couldn't find any explicit
wording about it in the am335x technical reference manual nor in in the
boneblack system reference manual.

According to the TRM the PRUSS lies in the PD_PER power domain, which is
powered down for the Deepsleep0 power mode. So I *guess* the PRUSS also
needs to be taken out of hard reset when waking up from such a state.

But there's no upstream support for these power modes on am33xx anyway,
and I'd assume that HWMOD_INIT_DEASSERT_HARD_RESET gets removed or
replaced once that lands. Which is probably what you meant by temporary.
FWIW, I'd be willing to look into that when the time comes and PRUSS gets
left behind.

Thanks,
Andre
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/13] uio_pruss: add support for devicetree and am33xx

2014-07-07 Thread Andre Heider
On Sun, Jun 29, 2014 at 06:21:34PM +0200, Andre Heider wrote:
 Hi,
 
 this series adds PRUv2 support to uio_pruss through devicetree, makes the
 device usable on am33xx and enables it on beaglebone black.
 Inspired by old patches from Matt Porter found in a downstream tree.
 
 To archieve that this series:
 * adds a flag to omap_hwmod.c to get PRUSS out of hardreset (patch 5 and 6)
 * adds devicetree support to uio_pruss (patch 7 and 9)
 * adds the device to the am33xx dtsi and boneblack dts (patch 12 and 13)
 
 Bits and pieces:
 * some cleanup (patch 1-4)
 * take care of a fact that SRAM on am33xx is not exposed through UIO (patch 8)
 * add runtime pm support to enable clocks (patch 10)
 * allow the driver to be compiled on SOC_AM33XX (patch 11)
 
 This is only tested on beaglebone black (as that's the only hardware of the
 PRUSS enabled families I have) with some basic GPIO and IRQ tests.
 
 Notes:
 * I just got this hardware and I don't know if this UIO PRUSS business is
   desired. Looking at the userspace driver I'd guess not so much ;), but this
   interface is there for older generations anyway, and this small series lets
   me use the device.
 * is the hardreset thing I did there the right thing to do? I think the
   proper way would be a reset controller (which apparently doesn't yet exist
   for this SoC?) and let the driver deassert/assert on probe/remove?
 * the platform device path has a clk_enable() / clk_put() calls. Are those
   now redundant with the introduced pm_runtime_enable() pm_runtime_disable()
   calls?

@OMAP guys: any comments? The series depends on patch 5 and 6; both touch
common hwmod code.

I noticed that AM437x now comes with 4 PRUSS cores, maybe you had something
different in mind on how to expose these?

Thanks in advance,
Andre
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/13] uio_pruss: add support for devicetree and am33xx

2014-07-07 Thread Paul Walmsley
On Mon, 7 Jul 2014, Andre Heider wrote:

 On Sun, Jun 29, 2014 at 06:21:34PM +0200, Andre Heider wrote:
  
  this series adds PRUv2 support to uio_pruss through devicetree, makes the
  device usable on am33xx and enables it on beaglebone black.
  Inspired by old patches from Matt Porter found in a downstream tree.
  
  To archieve that this series:
  * adds a flag to omap_hwmod.c to get PRUSS out of hardreset (patch 5 and 6)

...

  * is the hardreset thing I did there the right thing to do? I think the
proper way would be a reset controller (which apparently doesn't yet exist
for this SoC?) and let the driver deassert/assert on probe/remove?
  * the platform device path has a clk_enable() / clk_put() calls. Are those
now redundant with the introduced pm_runtime_enable() pm_runtime_disable()
calls?

Probably you only need pm_runtime_{get,put}_*() calls, unless you're 
changing clock parents or rates in your driver code.

 @OMAP guys: any comments? The series depends on patch 5 and 6; both touch
 common hwmod code.

I'd suggest splitting the series into three independent pieces if 
possible:

1. UIO code, for the UIO maintainer(s)
2. DT pieces for Tony
3. hwmod pieces for me

That way they can be cleanly merged by the respective maintainers.

As far as the hwmod piece goes, I'd be willing to merge your code as a 
temporary workaround for the issue, and marking it as such; but I'd be 
concerned about power management-related interactions (i.e., does the 
PRUSS need to be reset upon return from deep idle states, etc.)


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 00/13] uio_pruss: add support for devicetree and am33xx

2014-06-29 Thread Andre Heider
Hi,

this series adds PRUv2 support to uio_pruss through devicetree, makes the
device usable on am33xx and enables it on beaglebone black.
Inspired by old patches from Matt Porter found in a downstream tree.

To archieve that this series:
* adds a flag to omap_hwmod.c to get PRUSS out of hardreset (patch 5 and 6)
* adds devicetree support to uio_pruss (patch 7 and 9)
* adds the device to the am33xx dtsi and boneblack dts (patch 12 and 13)

Bits and pieces:
* some cleanup (patch 1-4)
* take care of a fact that SRAM on am33xx is not exposed through UIO (patch 8)
* add runtime pm support to enable clocks (patch 10)
* allow the driver to be compiled on SOC_AM33XX (patch 11)

This is only tested on beaglebone black (as that's the only hardware of the
PRUSS enabled families I have) with some basic GPIO and IRQ tests.

Notes:
* I just got this hardware and I don't know if this UIO PRUSS business is
  desired. Looking at the userspace driver I'd guess not so much ;), but this
  interface is there for older generations anyway, and this small series lets
  me use the device.
* is the hardreset thing I did there the right thing to do? I think the
  proper way would be a reset controller (which apparently doesn't yet exist
  for this SoC?) and let the driver deassert/assert on probe/remove?
* the platform device path has a clk_enable() / clk_put() calls. Are those
  now redundant with the introduced pm_runtime_enable() pm_runtime_disable()
  calls?

Thanks,
Andre

Andre Heider (13):
  uio: uio_pruss: use struct device
  uio: uio_pruss: use devm_kzalloc()
  uio: uio_pruss: use devm_ioremap_resource()
  uio: uio_pruss: use dmam_alloc_coherent()
  ARM: OMAP2+: hwmod: Introduce a flag to deassert the HW reset line
  ARM: AM33XX: hwmod: deassert PRUSS' hardreset lines
  Documentation: devicetree: add bindings for TI PRUSS
  uio: uio_pruss: make the UIO SRAM memory region optional
  uio: uio_pruss: add devicetree support
  uio: uio_pruss: add runtime pm support
  uio: uio_pruss: enable the driver for am33xx SoCs
  ARM: dts: am33xx: add the PRUSSv2 device
  ARM: dts: am335x-boneblack: enable the PRUSSv2 device

 .../devicetree/bindings/misc/ti,pruss.txt  |  19 +++
 arch/arm/boot/dts/am335x-boneblack.dts |   4 +
 arch/arm/boot/dts/am33xx.dtsi  |   9 ++
 arch/arm/mach-omap2/omap_hwmod.c   |   2 +
 arch/arm/mach-omap2/omap_hwmod.h   |   2 +
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |   1 +
 drivers/uio/Kconfig|   4 +-
 drivers/uio/uio_pruss.c| 144 -
 8 files changed, 123 insertions(+), 62 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/ti,pruss.txt

-- 
2.0.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html