devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* (unknown), 
@ 2012-04-25  6:57 jobhunts02
  0 siblings, 0 replies; 71+ messages in thread
From: jobhunts02 @ 2012-04-25  6:57 UTC (permalink / raw)
  To: gdb-thread.msg00270, gdb-thread.00270, raytaliaferro2,
	devicetree-discuss, gdb-thread.271, netfilter,
	wireshark-users-request, jordan_hargrave, linux-mtd

http://www.jagsxc.com/templates/beez/easyJob12.html

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

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

* (unknown)
@ 2012-10-05  7:15 Robert Schwebel
  0 siblings, 0 replies; 71+ messages in thread
From: Robert Schwebel @ 2012-10-05  7:15 UTC (permalink / raw)
  To: Guennadi Liakhovetski
  Cc: Steffen Trumtrar, devicetree-discuss, Rob Herring, linux-fbdev,
	dri-devel, Laurent Pinchart, linux-media, TomiValkeinen

<tomi.valkeinen@ti.com>, pza
Bcc:
Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings
Reply-To:
In-Reply-To: <Pine.LNX.4.64.1210042307300.3744@axis700.grange>
X-Sent-From: Pengutronix Hildesheim
X-URL: http://www.pengutronix.de/
X-IRC: #ptxdist @freenode
X-Accept-Language: de,en
X-Accept-Content-Type: text/plain
X-Uptime: 09:13:09 up 103 days, 22:24, 36 users,  load average: 0,57, 0,60,
 0,61

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
> > +optional properties:
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
>
> For the above two we also considered using bool properties but eventually
> settled down with integer ones:
>
> - hsync-active = <1>
>
> for active-high and 0 for active low. This has the added advantage of
> being able to omit this property in the .dts, which then doesn't mean,
> that the polarity is active low, but rather, that the hsync line is not
> used on this hardware. So, maybe it would be good to use the same binding
> here too?

Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

* (unknown), 
@ 2013-11-01  7:04 Xiubo Li
  0 siblings, 0 replies; 71+ messages in thread
From: Xiubo Li @ 2013-11-01  7:04 UTC (permalink / raw)
  To: r65073, timur, lgirdwood, broonie
  Cc: r64188, rob.herring, pawel.moll, mark.rutland, swarren,
	ian.campbell, rob, linux, perex, tiwai, grant.likely,
	fabio.estevam, LW, oskar, shawn.guo, b42378, b18965, devicetree,
	linux-doc, linux-kernel, linux-arm-kernel, alsa-devel,
	linuxppc-dev


Hello,

This patch series is mostly Freescale's SAI SoC Digital Audio Interface driver implementation. And the implementation is only compatible with device tree definition.

This patch series is based on linux-next and has been tested on Vybrid VF610 Tower board using device tree.

Changed in v2:
- Use default settings for the generic dmaengine PCM driver.
- Separate receive and transmit setting in most functions, but some couldn't for the HW limitation.
- Drop some not reduntant code.
- Use devm_snd_soc_register_component() instead of snd_soc_register_component().
- Use devm_snd_soc_register_card() instead of devm_snd_soc_register_card().
- Adjust the code sentences sequence.
- Make the namespacing consistent.
- Rename CONFIG_SND_SOC_FSL_SGTL5000 to CONFIG_SND_SOC_FSL_SGTL5000_VF610.
- Drop some meaningless lines.
- Rename the binding document file.

Added in v1:
- Add SAI SoC Digital Audio Interface driver.
- Add Freescale SAI ALSA SoC Digital Audio Interface node for VF610.
- Enables SAI ALSA SoC DAI device for Vybrid VF610 TOWER board.
- Add device tree bindings for Freescale SAI.
- Revise the bugs about the sgt15000 codec.
- Add SGT15000 based audio machine driver.
- Enable SGT15000 codec based audio driver node for VF610.
- Add device tree bindings for Freescale VF610 sound.





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

* (unknown)
@ 2013-11-08 20:28 Dave & Angela Dawes
  0 siblings, 0 replies; 71+ messages in thread
From: Dave & Angela Dawes @ 2013-11-08 20:28 UTC (permalink / raw)


This is Dave and Angela, My wife and I won the biggest Euro Millions, we
just commenced a Charity Donation by giving out to five (5) individuals;
we listed you as a recipient of our cash donation. get back to us for more
info and proof.

--
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] 71+ messages in thread

* (unknown), 
@ 2013-11-21  5:53 Management
  0 siblings, 0 replies; 71+ messages in thread
From: Management @ 2013-11-21  5:53 UTC (permalink / raw)


This is an automatic message by the system to let you know that you have
to confirm your account information. An Attempt has been made to login
from a new computer. For the security of your account.

Your Email account will be frozen temporary after 48 hours in order to
protect it.

The account will continue to be frozen until it is confirmed.Once you have
updated your account records, your information will be confirmed and your
account will start to work as normal once again. The process does not take
more than 5 minutes To proceed to confirm your account information Click
on this link or copy and paste in your browser tab:
http://666-17-79187.webs.com/

--
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] 71+ messages in thread

* (unknown), 
@ 2013-12-05  7:01 Jagan Teki
  0 siblings, 0 replies; 71+ messages in thread
From: Jagan Teki @ 2013-12-05  7:01 UTC (permalink / raw)
  To: devicetree-u79uwXL29TY76Z2rM5mHXA

-- 
Thanks,
Jagan.
--------
Jagannadha Sutradharudu Teki,
E: jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
--
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] 71+ messages in thread

* (unknown), 
@ 2013-12-12  7:30 Loc Ho
  0 siblings, 0 replies; 71+ messages in thread
From: Loc Ho @ 2013-12-12  7:30 UTC (permalink / raw)
  To: olof, tj, arnd
  Cc: linux-scsi, linux-ide, devicetree, linux-arm-kernel, jcm, patches,
	Loc Ho, Tuan Phan, Suman Tripathi

This patch adds support for APM X-Gene SoC 15Gbps Multi-purpose PHY. This
is the physical layer interface for the corresponding host controller. This
driver uses the new PHY generic framework posted by Kishon Vijay Abrahm.
In addition, the new PHY generic framework is patched to provide an
function to set the speed of the PHY.

v4
* Update documentation with 'apm,' instead 'apm-'
* Change DTS override parameter to have 'apm,'
* Add select GENERIC_PHY to Kconfig PHY_XGENE
* Make override parameters to be pair of three values instead one
* Some minor comment and indentation changes
* Remove error register addition offset
* Add ULL to constants
* Use module_init instead subsys_initcall
* Make DTS node based on first register address
* Update override setting values

v3
* Major re-write of the code based on various review comments
* Support external clock only at the moment
* Support SATA mode only at the moment
* No UEFI support at the moment

v2
* Remove port knowledge from functions
* Make all functions static
* Remove ID completely
* Make resource requirement based on compatible type
* Rename override PHY parameters with more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation

v1
* Initial version

Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
  PHY: Add function set_speed to generic PHY framework
  Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
    binding documentation
  PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
  arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

 .../devicetree/bindings/ata/apm-xgene-phy.txt      |   89 +
 arch/arm64/boot/dts/apm-storm.dtsi                 |   31 +
 drivers/phy/Kconfig                                |    7 +
 drivers/phy/Makefile                               |    2 +
 drivers/phy/phy-core.c                             |   21 +
 drivers/phy/phy-xgene.c                            | 1854 ++++++++++++++++++++
 include/linux/phy/phy.h                            |    8 +
 7 files changed, 2012 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene-phy.txt
 create mode 100644 drivers/phy/phy-xgene.c


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

* (unknown)
@ 2014-01-11  0:37 klightspeed-aslSrjg9ejhWX4hkXwHRhw
  0 siblings, 0 replies; 71+ messages in thread
From: klightspeed-aslSrjg9ejhWX4hkXwHRhw @ 2014-01-11  0:37 UTC (permalink / raw)


>From f3b6db2e9607c22d1a7e16de9c4872539f4d786c Mon Sep 17 00:00:00 2001
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org
Date: Sat, 11 Jan 2014 10:03:58 +1000
Subject: [PATCH] ARM: parameter initrd must override FDT initrd

The initrd_start and initrd_end as set by FDT was overriding
the phys_initrd_start and phys_initrd_size set by the initrd=
kernel parameter.  This patch will ignore the initrd_start
and initrd_end set earlier if phys_initrd_start and
phys_initrd_size (as set by the initrd= parameter) are set.

Signed-off-by: Ben Peddell <klightspeed-aslSrjg9ejhWX4hkXwHRhw@public.gmane.org>
---
 arch/arm/mm/init.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 1f7b19a..819c539 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -345,10 +345,11 @@ void __init arm_memblock_init(struct meminfo *mi,
 #endif
 #ifdef CONFIG_BLK_DEV_INITRD
 	/* FDT scan will populate initrd_start */
-	if (initrd_start) {
+	if (initrd_start && !phys_initrd_size) {
 		phys_initrd_start = __virt_to_phys(initrd_start);
 		phys_initrd_size = initrd_end - initrd_start;
 	}
+	initrd_start = initrd_end = 0;
 	if (phys_initrd_size &&
 	    !memblock_is_region_memory(phys_initrd_start, phys_initrd_size)) {
 		pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - disabling initrd\n",
-- 
1.8.3.2

--
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] 71+ messages in thread

* (unknown), 
@ 2014-01-13 10:29 Lothar Waßmann
  0 siblings, 0 replies; 71+ messages in thread
From: Lothar Waßmann @ 2014-01-13 10:29 UTC (permalink / raw)
  To: linux-arm-kernel, Shawn Guo, Sascha Hauer, Rob Herring,
	Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
	Thierry Reding, devicetree, linux-kernel, linux-pwm

This patchset adds support for inverting the PWM output in hardware by
setting the POUTC bit in the PWMCR register. This feature is
controlled via the standard DT flas for PWMs.

The first patch does a minor source cleanup without any functional
change.

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

* (unknown), 
@ 2014-01-13 10:32 Lothar Waßmann
  0 siblings, 0 replies; 71+ messages in thread
From: Lothar Waßmann @ 2014-01-13 10:32 UTC (permalink / raw)
  To: linux-arm-kernel, Rob Herring, Pawel Moll, Mark Rutland,
	Ian Campbell, Kumar Gala, Russell King, Shawn Guo, Sascha Hauer,
	devicetree, linux-kernel

This patchset adds support for the Ka-Ro electronics i.MX53 based
modules.
The first patch adds a new pingroup for NAND pads that is used by the
modules.

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

* (unknown), 
@ 2014-01-16 16:09 Loc Ho
  0 siblings, 0 replies; 71+ messages in thread
From: Loc Ho @ 2014-01-16 16:09 UTC (permalink / raw)
  To: olof, tj, arnd
  Cc: linux-scsi, linux-ide, devicetree, linux-arm-kernel, dmilburn,
	jcm, patches, Loc Ho, Tuan Phan, Suman Tripathi

This patch adds support for APM X-Gene SoC 15Gbps Multi-purpose PHY. This
is the physical layer interface for the corresponding host controller. This
driver uses the new PHY generic framework posted by Kishon Vijay Abrahm.
In addition, the new PHY generic framework is patched to provide an
function to set the speed of the PHY.

v8
* Update binding documentation
* Remove XGENE_PHY_DTS and XGENE_PHY_EXT_DTS defines
* Remove support for internal clock
* Remove support for external reference CMU
* Remove the need for external reference resource DTS entry and its related
  code

v7
* Add/Update PHY CMU/lane parameters and its default values
* Rename variable enable_manual_cal to preA3Chip
* Remove function phy_rd, phy_wr, and phy_wr_flush
* Change function cmu_wr, cmu_rd, cmu_toggle1to0, cmu_clrbits, cmu_setbits,
  serdes_wr, serdes_rd, serdes_clrbits, and serdes_setbits to take context
  instead void *
* Remove function serdes_toggle1to0
* Decrease the polling time from 10ms to 1ms on CMU calibration complete
  detection
* Move all SATA specify code in function xgene_phy_hw_initialize into
  function xgene_phy_hw_init_sata
* Add usleep_range after starting summer/latch calibrations
* Add usleep_range between receiver reset (function xgene_phy_reset_rxd)
* Save and restore PHY register 31 instead writing 0 in function
  xgene_phy_gen_avg_val
* Update function xgene_phy_sata_force_gen programming sequences
* Add support to reset the receiver lane in function xgene_phy_set_speed
  if speed is 0
* Update PHY parameters in DTS per controller
* Some minor code clean up

v6
* Move PHY document to Documentation/devicetree/binding/phy
* Remove _ADDR from all register defines
* Update clock-names property for sataphy1clk, sataphy2clk, and sataphy3clk

v5
* Update DTS binding documentation
* Remove direct clock access and use clock interface instead
* Change override parameters to decimal instead hex values
* Change apm,tx-amplitude, apm,tx-pre-cursor1, apm,tx-pre-cursor2,
  apm,tx-post-cursor to be unit of uV

v4
* Update documentation with 'apm,' instead 'apm-'
* Change DTS override parameter to have 'apm,'
* Add select GENERIC_PHY to Kconfig PHY_XGENE
* Make override parameters to be pair of three values instead one
* Some minor comment and indentation changes
* Remove error register addition offset
* Add ULL to constants
* Use module_init instead subsys_initcall
* Make DTS node based on first register address
* Update override setting values

v3
* Major re-write of the code based on various review comments
* Support external clock only at the moment
* Support SATA mode only at the moment
* No UEFI support at the moment

v2
* Remove port knowledge from functions
* Make all functions static
* Remove ID completely
* Make resource requirement based on compatible type
* Rename override PHY parameters with more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation

v1
* Initial version

Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
  PHY: Add function set_speed to generic PHY framework
  Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
    binding documentation
  PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
  arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

 .../devicetree/bindings/phy/apm-xgene-phy.txt      |   79 +
 arch/arm64/boot/dts/apm-storm.dtsi                 |   75 +
 drivers/phy/Kconfig                                |    7 +
 drivers/phy/Makefile                               |    2 +
 drivers/phy/phy-core.c                             |   21 +
 drivers/phy/phy-xgene.c                            | 1793 ++++++++++++++++++++
 include/linux/phy/phy.h                            |    8 +
 7 files changed, 1985 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
 create mode 100644 drivers/phy/phy-xgene.c


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

* (unknown), 
@ 2014-01-16 16:11 Loc Ho
  0 siblings, 0 replies; 71+ messages in thread
From: Loc Ho @ 2014-01-16 16:11 UTC (permalink / raw)
  To: olof, tj, arnd
  Cc: linux-scsi, linux-ide, devicetree, linux-arm-kernel, dmilburn,
	jcm, patches, Loc Ho, Tuan Phan, Suman Tripathi

This patch adds support for the APM X-Gene SoC SATA host controller. In
order for the host controller to work, the corresponding PHY driver
musts also be available.

v10:
 * Update binding documentation

v9:
 * Remove ACPI/EFI include files
 * Remove the IO flush support, interrupt routine, and DTS resources
 * Remove function xgene_rd, xgene_wr, and xgene_wr_flush
 * Remove PMP support (function xgene_ahci_qc_issue, xgene_ahci_qc_prep,
   xgene_ahci_qc_fill_rtf, xgene_ahci_softreset, and xgene_ahci_do_softreset)
 * Rename function xgene_ahci_enable_phy to xgene_ahci_force_phy_rdy
 * Clean up hardreset functions
 * Require v7 of the PHY driver

v8:
 * Remove _ADDR from defines
 * Remove define MSTAWAUX_COHERENT_BYPASS_SET and
   STARAUX_COHERENT_BYPASS_SET and use direct coding
 * Remove the un-necessary check for DTS boot with built in ACPI table
 * Switch to use dma_set_mask_and_coherent for setting DMA mask
 * Remove ACPI table matching code
 * Update clock-names for sata01clk, sata23clk, and sata45clk

v7:
 * Update the clock code by toggle the clock
 * Update the DTS clock mask values due to the clock spilt between host and
   v5 of the PHY drivers

v6:
 * Update binding documentation
 * Change select PHY_XGENE_SATA to PHY_XGENE
 * Add ULL to constants
 * Change indentation and comments
 * Clean up the probe functions a bit more
 * Remove xgene_ahci_remove function
 * Add the flush register to DTS
 * Remove the interrupt-parent from DTS

v5:
 * Sync up to v3 of the PHY driver
 * Remove MSLIM wrapper functions
 * Change the memory shutdown loop to use usleep_range
 * Use devm_ioremap_resource instead devm_ioremap
 * Remove suspend/resume functions as not needed

v4:
 * Remove the ID property in DT
 * Remove the temporary PHY direct function call and use PHY function
 * Change printk to pr_debug
 * Move the IOB flush addresses into the DT
 * Remove the parameters retrieval function as no longer needed
 * Remove the header file as no longer needed
 * Require v2 patch of the SATA PHY driver. Require slightly modification
   in the Kconfig as it is moved to folder driver/phy and use Kconfig
   PHY_XGENE_SATA instead SATA_XGENE_PHY.

v3:
 * Move out the SATA PHY to another driver
 * Remove the clock-cells entry from DTS
 * Remove debug wrapper
 * Remove delay functions wrapper
 * Clean up resource and IRQ query
 * Remove query clock name
 * Switch to use dma_set_mask/dma_coherent_mask
 * Remove un-necessary devm_kfree
 * Update GPL license header to v2
 * Spilt up function xgene_ahci_hardreset
 * Spilt up function xgene_ahci_probe
 * Remove all reference of CONFIG_ARCH_MSLIM
 * Clean up chip revision code

v2:
 * Clean up file sata_xgene.c with Lindent and etc
 * Clean up file sata_xgene_serdes.c with Lindent and etc
 * Add description to each patch

v1:
 * inital version

Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Tuan Phan <tphan@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
---
Loc Ho (4):
  ata: Export required functions by APM X-Gene SATA driver
  Documentation: Add documentation for APM X-Gene SoC SATA host
    controller DTS binding
  ata: Add APM X-Gene SoC SATA host controller driver
  arm64: Add APM X-Gene SoC SATA host controller DTS entries

 .../devicetree/bindings/ata/apm-xgene.txt          |   70 +++
 arch/arm64/boot/dts/apm-storm.dtsi                 |   75 +++
 drivers/ata/Kconfig                                |    8 +
 drivers/ata/Makefile                               |    1 +
 drivers/ata/ahci.h                                 |    9 +
 drivers/ata/libahci.c                              |   16 +-
 drivers/ata/sata_xgene.c                           |  630 ++++++++++++++++++++
 7 files changed, 803 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene.txt
 create mode 100644 drivers/ata/sata_xgene.c


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

* (unknown), 
@ 2014-02-02 18:31 Davor Joja
  0 siblings, 0 replies; 71+ messages in thread
From: Davor Joja @ 2014-02-02 18:31 UTC (permalink / raw)
  To: mark.rutland-5wv7dgnIgG8; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA

Hi,

I would like to ask for comments on these patches.

Their purpose is to show how I did binding for Xylon logiCVC IP core within
DRM driver.
First goal is to get comments on logiCVC binding so that I can use it in
community approved form in DRM and FB drivers and then send drivers to review.
Second goal is to get "xylon" prefix in vendor-prefixes.

Thanks,
Davor

--
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] 71+ messages in thread

* (unknown), 
@ 2014-02-16 11:35 Eleazar Molina Molina
  0 siblings, 0 replies; 71+ messages in thread
From: Eleazar Molina Molina @ 2014-02-16 11:35 UTC (permalink / raw)




Good day. I am Mark Reyes Guus, I not work with Abn Amro Bank as an auditor. I have a proposition to discuss with you. Should you be interested, Please e-mail back to me.

Private Email: markreyesguus@abnmrob.co.uk OR markguus.reyes01 @ yahoo.nl

Yours Sincerely,
Guus Mark Reyes.

________________________________

La información de este correo así como la contenida en los documentos que se adjuntan, pueden ser objeto de solicitudes de acceso a la información. Visítanos: http://www.ipn.mx

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

* (unknown), 
@ 2014-02-22 15:53 Hans de Goede
  0 siblings, 0 replies; 71+ messages in thread
From: Hans de Goede @ 2014-02-22 15:53 UTC (permalink / raw)
  To: Tejun Heo, Maxime Ripard
  Cc: Oliver Schinagl, Richard Zhu, Roger Quadros, Lee Jones,
	linux-ide-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw

Hi all,

Here is v7 of my patchset for adding ahci-sunxi support. This is hopefully
the final final version of this set :)

Note I'm going on vacation for a week starting Monday, so if I'm not responding
that is why. Tejun if you feel some small cleanups are still necessary and
you don't want to wait for me to get back feel free to squash in any cleanups
you deem necessary.

This has been tested with Allwinner A10, Allwinner A20 and Freeware imx6x SoCs,
including suspend / resume. Note that the ahci_imx driver now also has imx53
sata support, it would be good if someone could test that with this series.


History:

v1, by Olliver Schinagl:
This was using the approach of having a platform device which probe method
creates a new child platform device which gets driven by ahci_platform.c,
as done by ahci_imx.c .

v2, by Hans de Goede:
Stand-alone platform driver based on Olliver's work

v3, by Hans de Goede:
patch-series, with 4 different parts
a) Make ahci_platform.c more generic, handle more then 1 clk, target pwr
   regulator
b) New ahci-sunxi code only populating ahci_platform_data, passed to
   ahci_platform.c to of_device_id matching.
c) Refactor ahci-imx code to work the same as the new ahci-sunxi code, this
   is the reason why v3 is an RFC, I'm waiting for the wandboard I ordered to
   arrive so that I can actually test this.
d) dts bindings for the sunxi ahci parts

v4, by Hans de Goede:
patch-series, with 5 different parts:
a) Make ahci_platform.c more generic, handle more then 1 clk, target pwr
   regulator
b) Turn parts of ahci_platform.c into a library for use by other drivers
c) New ahci-sunxi driver using the ahci_platform.c library functionality
d) Refactor ahci-imx code to work the same as the new ahci-sunxi code
e) dts bindings for the sunxi ahci parts

v5:
v4 + the following changes:
1) fsl,imx6q driver is now tested
2) fixed suspend / resume on fsl,imx6q
3) Modifed devicetree node naming to match dt spec
4) Reworked the busy waiting code in the sunxi-phy handling as suggested by
   Russell King

v6:
v5 rebased on top of 3.14-rc3 + the following changes
1) Added Roger Quadros' generic phy support series
2) Added a "ARM: sun4i: dt: Remove grouping + simple-bus for regulators" dts
   patch

v7:
v6 + the following changes:
1) Addressed all Tejun's review remarks:
  * Added function header comments to all exported ahci_platform functions
  * Added comments in some other places
  * Removed use of 2 empty lines to separate functions in some cases
  * Use devres to automatically call ahci_platform_put_resources on
    get_resource failure, probe failure and regular device remove
2) Dropped patches to move ahci_host_priv struct declaration to include/linux,
  this was a left-over from v3 and is no longer necessary
3) Updated Roger's "ata: ahci_platform: Manage SATA PHY" patch:
  * Update function header comments for the changes this makes
  * Drop the Kconfig PHY requires hack, my patch for the phy-core to always be
    built-in has been queued in Greg KH's tree, so this is no longer necessary.
4) Dropped Roger's "ata: ahci_platform: Add 'struct device' argument to ahci_platform_put_resources()"
  patch, ahci_platform_put_resources already has a device argument as result
  of it being changed into a devres release function

Tejun, can you please add patches 1-12 to your ata tree for 3.15 ?

Maxime, can you please add patch 13-15 to your dts tree for 3.15 ?

Thanks & Regards,

Hans

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

* (unknown), 
@ 2014-03-11  3:29 Christian Organization
  0 siblings, 0 replies; 71+ messages in thread
From: Christian Organization @ 2014-03-11  3:29 UTC (permalink / raw)



Good day,

We are Christian organization, we give out loan to those that have given
there lives to Christ, contact us via email marieloanlenders-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Regard

Mrs Marie



--
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] 71+ messages in thread

* (unknown), 
@ 2014-05-24  1:21 Loc Ho
  0 siblings, 0 replies; 71+ messages in thread
From: Loc Ho @ 2014-05-24  1:21 UTC (permalink / raw)
  To: dougthompson-aS9lmoZGLiVWk0Htik3J/w, bp-Gina5bIWoIWzQB+pC5nmwQ,
	m.chehab-Sze3O3UU22JBDgjK7y7TUQ
  Cc: linux-edac-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	jcm-H+wXaHxf7aLQT0dZR+AlfA, patches-qTEPVZfXA3Y, Loc Ho

This patch adds support for the APM X-Gene SoC EDAC driver.

v2:
* Add EDAC entry in MAINTAINERS for APM EDAC driver
* Remove the MC scrub patch
* Remove the word 'Caches' from Kconfig
* Change all MASK defines to use BIT(x)
* Update comment or remove them
* Wrap error injection code around CONFIG_EDAC_DEBUG
* Change function name xgene_edac_mc_hw_init to xgene_edac_mc_irq_ctl
* Change all function XXX_hw_init to XXX_hw_ctl
* Fix typo 'activie'
* Move calling function edac_mc_alloc after resource retrieval
* Check for NULL on platform_get_resource return if reference directly
* Add documentation for struct xgene_edac_pmd_ctx
* Move L1 and L2 check out of function xgene_edac_pmd_check to its own
  functions
* Use for loop for configure each CPU of an PMD
* Replace /2 by >> 1
* Remove unnecessary comment on edac_device_add_device failure
* Make mem_err_ip static const
* Unwind EDAC register correctly if failed
---
Loc Ho (4):
  MAINTAINERS: Add entry for APM X-Gene SoC EDAC driver
  Documentation: Add documentation for the APM X-Gene SoC EDAC DTS
    binding
  edac: Add APM X-Gene SoC EDAC driver
  arm64: Add APM X-Gene SoC EDAC DTS entries

 .../devicetree/bindings/edac/apm-xgene-edac.txt    |   70 +
 MAINTAINERS                                        |    8 +
 arch/arm64/boot/dts/apm-storm.dtsi                 |   89 +
 drivers/edac/Kconfig                               |    9 +-
 drivers/edac/Makefile                              |    3 +
 drivers/edac/xgene_edac.c                          | 1993 ++++++++++++++++++++
 6 files changed, 2171 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
 create mode 100644 drivers/edac/xgene_edac.c

--
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] 71+ messages in thread

* (unknown), 
@ 2014-09-20 23:12 M.K-YIN
  0 siblings, 0 replies; 71+ messages in thread
From: M.K-YIN @ 2014-09-20 23:12 UTC (permalink / raw)





--
I have a portfolio project for you.

Regards,
M.K-YIN
--

--
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] 71+ messages in thread

* (unknown), 
@ 2014-09-22  7:45 Jingchang Lu
  0 siblings, 0 replies; 71+ messages in thread
From: Jingchang Lu @ 2014-09-22  7:45 UTC (permalink / raw)
  To: shawn.guo-KZfg59tc24xl57MIdRCFDg
  Cc: arnd-r2nGTMty4D4, mark.rutland-5wv7dgnIgG8,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA

This series contain the support for Freescale LS1021A CPU and LS1021A-QDS
and LS1021A-TWR board.

The LS1021A SoC combines two ARM Cortex-A7 cores that have been optimized
for high reliability and pack the highest level of integration available
for sub-3W embedded communications processors and with a comprehensive
enablement model focused on ease of programmability.

The LS1021A SoC shares IPs with i.MX family, Vybrid family and Freescale
PowerPC platform. 

For the detail information about LS1021A SoC, please refer to the RM doc.

---
changes in v4:
add "syscon" compatible to device tree scfg and dcfg node, and 
remove uncompleted dcsr related node.
remove mxc_restart reference in DT_MACHINE_START.
remove dma_zone_size defination in DT_MACHINE_START.

changes in v3:
rewrite scfg and dcfg binding doc description.
remove sai related node leaving to the driver support.

changes in v2:
remove unused nodes.
wakeup the secondary core by IPI call to u-boot standby procedure. 
add dt-bindings for LS1021A SoC and platform gerenal configuration nodes.

----------------------------------------------------------------
Jingchang Lu (6):
	ARM: dts: Add SoC level device tree support for LS1021A
	ARM: dts: Add initial LS1021A QDS board dts support
	ARM: dts: Add initial LS1021A TWR board dts support
	dt-bindings: arm: add Freescale LS1021A SoC device tree binding
	ARM: imx: Add initial support for Freescale LS1021A
	ARM: imx: Add Freescale LS1021A SMP support

 Documentation/devicetree/bindings/arm/fsl.txt |  38 ++++
 arch/arm/boot/dts/Makefile                    |   2 +
 arch/arm/boot/dts/ls1021a-qds.dts             | 285 ++++++++++++++++++++++++++
 arch/arm/boot/dts/ls1021a-twr.dts             | 117 +++++++++++
 arch/arm/boot/dts/ls1021a.dtsi                | 539 ++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/Kconfig                     |  14 ++
 arch/arm/mach-imx/Makefile                    |   4 +-
 arch/arm/mach-imx/common.h                    |   1 +
 arch/arm/mach-imx/mach-ls1021a.c              |  22 +++
 arch/arm/mach-imx/platsmp.c                   |  32 +++
 10 files changed, 1053 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/ls1021a-qds.dts
 create mode 100755 arch/arm/boot/dts/ls1021a-twr.dts
 create mode 100644 arch/arm/boot/dts/ls1021a.dtsi
 create mode 100644 arch/arm/mach-imx/mach-ls1021a.c

--
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] 71+ messages in thread

* (unknown), 
@ 2014-09-29  3:16 Shengchao Guo
  0 siblings, 0 replies; 71+ messages in thread
From: Shengchao Guo @ 2014-09-29  3:16 UTC (permalink / raw)
  To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org


unsubscribe devicetree
--
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] 71+ messages in thread

* (unknown), 
@ 2014-10-06  6:56 Suman Tripathi
  0 siblings, 0 replies; 71+ messages in thread
From: Suman Tripathi @ 2014-10-06  6:56 UTC (permalink / raw)
  To: olof, tj, arnd
  Cc: linux-scsi, linux-ide, devicetree, linux-arm-kernel, ddutile, jcm,
	patches, Suman Tripathi, Loc Ho, Ben Hutchings,
	Greg Kroah-Hartman

commit 72f79f9e35bd3f78ee8853f2fcacaa197d23ebac upstream.
Subject: [PATCH 3.16 350/357] ahci_xgene: Removing NCQ support from the APM X-Gene SoC AHCI SATA Host Controller driver.

This patch removes the NCQ support from the APM X-Gene SoC AHCI
Host Controller driver as it doesn't support it.

Signed-off-by: Loc Ho <lho@apm.com>
Signed-off-by: Suman Tripathi <stripathi@apm.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
[bwh: Backported to 3.16: host flags are passed to ahci_platform_init_host()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Suman Tripathi <stripathi@apm.com>

---
 drivers/ata/ahci_xgene.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -337,7 +337,7 @@ static struct ata_port_operations xgene_
 };
 
 static const struct ata_port_info xgene_ahci_port_info = {
-	.flags = AHCI_FLAG_COMMON | ATA_FLAG_NCQ,
+	.flags = AHCI_FLAG_COMMON,
 	.pio_mask = ATA_PIO4,
 	.udma_mask = ATA_UDMA6,
 	.port_ops = &xgene_ahci_ops,
@@ -484,7 +484,7 @@ static int xgene_ahci_probe(struct platf
 		goto disable_resources;
 	}
 
-	hflags = AHCI_HFLAG_NO_PMP | AHCI_HFLAG_YES_NCQ;
+	hflags = AHCI_HFLAG_NO_PMP | AHCI_HFLAG_NO_NCQ;
 
 	rc = ahci_platform_init_host(pdev, hpriv, &xgene_ahci_port_info,
 				     hflags, 0, 0);

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

* (unknown), 
@ 2014-10-06 19:57 Omar Hashim
  0 siblings, 0 replies; 71+ messages in thread
From: Omar Hashim @ 2014-10-06 19:57 UTC (permalink / raw)





--
I have a lucrative business proposal of 
mutual interest to share with you, 
contact me if you are interested.
--

--
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] 71+ messages in thread

* (unknown)
       [not found]                                                                                                     ` <1488091663.147175.1414957674639.JavaMail.yahoo-pZijWUW3o9/uQS8rMknbopOW+3bF1jUfVpNB7YpNyf8@public.gmane.org>
@ 2014-11-02 19:48                                                                                                       ` MRS GRACE MANDA
  0 siblings, 0 replies; 71+ messages in thread
From: MRS GRACE MANDA @ 2014-11-02 19:48 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 140 bytes --]









This is Mrs Grace Manda (  Please I need your Help is Urgent).






This is Mrs Grace Manda (  Please I need your Help is Urgent). 

[-- Attachment #2: Mrs Grace Manda.rtf --]
[-- Type: application/rtf, Size: 35796 bytes --]

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

* (unknown), 
@ 2015-02-18 16:14 Lee Jones
  0 siblings, 0 replies; 71+ messages in thread
From: Lee Jones @ 2015-02-18 16:14 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel
  Cc: lee.jones, kernel, mturquette, sboyd, devicetree

Subject: [PATCH v2 0/4] clk: st: New clock domain

v1 => v2:
  - Turned the ST specific driver into a generic one 

Hardware can have a bunch of clocks which must not be turned off.
If drivers a) fail to obtain a reference to any of these or b) give
up a previously obtained reference during suspend, the common clk
framework will attempt to turn them off and the hardware will
subsequently die.  The only way to recover from this failure is to
restart.
 
To avoid either of these two scenarios from catastrophically
disabling the running system we have implemented a clock domain
where clocks are consumed and references are taken, thus preventing
them from being shut down by the framework.

Lee Jones (4):
  ARM: sti: stih407-family: Supply defines for CLOCKGEN A0
  ARM: sti: stih407-family: Provide Clock Domain information
  clk: Provide an always-on clock domain framework
  clk: dt: Introduce always-on clock domain documentation

 .../devicetree/bindings/clock/clk-domain.txt       | 35 ++++++++++++
 arch/arm/boot/dts/stih407-family.dtsi              | 13 +++++
 drivers/clk/Makefile                               |  1 +
 drivers/clk/clkdomain.c                            | 63 ++++++++++++++++++++++
 include/dt-bindings/clock/stih407-clks.h           |  4 ++
 5 files changed, 116 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/clk-domain.txt
 create mode 100644 drivers/clk/clkdomain.c

-- 
1.9.1

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

* (unknown), 
@ 2015-03-07 15:29 Mr John Wong
  0 siblings, 0 replies; 71+ messages in thread
From: Mr John Wong @ 2015-03-07 15:29 UTC (permalink / raw)
  To: Recipients

Seeking Your Assistance In A Business Proposal get back to me if interested via email:mrjohn.wong-/E1597aS9LQAvxtiuMwx3w@public.gmane.org

------------------------
This email was scanned by BitDefender.
--
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] 71+ messages in thread

* (unknown), 
@ 2015-03-25 20:46 Robert Smigielski
  0 siblings, 0 replies; 71+ messages in thread
From: Robert Smigielski @ 2015-03-25 20:46 UTC (permalink / raw)
  To: devicetree-u79uwXL29TY76Z2rM5mHXA

subscribe
--
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] 71+ messages in thread

* (unknown), 
@ 2015-05-05  6:23 Alanoud AlFayeza
  0 siblings, 0 replies; 71+ messages in thread
From: Alanoud AlFayeza @ 2015-05-05  6:23 UTC (permalink / raw)




I have a business proposal of a mutual benefit for you, contact for more information

--
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] 71+ messages in thread

* (unknown), 
@ 2015-05-18 20:00 raghu MG
  0 siblings, 0 replies; 71+ messages in thread
From: raghu MG @ 2015-05-18 20:00 UTC (permalink / raw)
  To: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

Hi,
This mail is regarding Linux smp boot on ARMADA-XP MV2860
.

CPU-1 doesnt boot/go through the boot sequence & it fails to come
online & dumps this message

CPU1:failed to come online .

The CPU-1 boot register is programmed with physical address of
-->armada_xp_secondary_startup function & then cpu-0 deasserts the CPU-1.

I am using armada-xp-gp.dts with armada-xp-mv78260.dts included in it.

Any help would be appreciated.
Regards
--
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] 71+ messages in thread

* (unknown), 
@ 2015-07-06 15:57 Maria McCumiskey
  0 siblings, 0 replies; 71+ messages in thread
From: Maria McCumiskey @ 2015-07-06 15:57 UTC (permalink / raw)


I and my wife violet donated $500,000.00 USD as our personal donation to you this year 2015.Contact us:
allenlarge0452-1ViLX0X+lBJBDgjK7y7TUQ@public.gmane.org
--
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] 71+ messages in thread

* (unknown), 
@ 2015-07-22 14:05 Chunfeng Yun
  0 siblings, 0 replies; 71+ messages in thread
From: Chunfeng Yun @ 2015-07-22 14:05 UTC (permalink / raw)
  To: Mathias Nyman
  Cc: Rob Herring, Mark Rutland, Matthias Brugger, Felipe Balbi,
	Chunfeng Yun, Sascha Hauer, devicetree, linux-kernel,
	linux-arm-kernel, Roger Quadros, linux-usb, linux-mediatek,
	John Crispin, Daniel Kurtz

>From ac1e8724bfa47494223bad0af450c1a63cd2fe0c Mon Sep 17 00:00:00 2001
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date: Wed, 22 Jul 2015 21:15:15 +0800
Subject: [PATCH 0/5] *** SUBJECT HERE ***

The patch supports MediaTek's xHCI controller.

There are some differences from xHCI spec:
1. The interval is specified in 250 * 8ns increments for Interrupt Moderation
Interval(IMODI) of the Interrupter Moderation(IMOD) register, it is 8 times as
much as that defined in xHCI spec.

2. For the value of TD Size in Normal TRB, MTK's xHCI controller defines a
number of packets that remain to be transferred for a TD after processing all
Max packets in all previous TRBs,that means don't include the current TRB's,
but in xHCI spec it includes the current ones.

3. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK
architecture defines some extra SW scheduling parameters for HW. According to
these parameters provided by SW, the xHC can easily decide whether a
synchronous endpoint should be scheduled in a specific uFrame. The extra SW
scheduling parameters are put into reserved DWs in Slot and Endpoint Context.
And a bandwidth scheduler algorithm is added to support such feature.

A usb3.0 phy driver is also added which used by mt65xx SoCs platform, it
supports two usb2.0 ports and one usb3.0 port.

Change in v3:
1. implement generic phy
2. move opperations for IPPC and wakeup from phy driver to xHCI driver
3. seperate quirk functions into a single C file to fix up dependence issue

Chunfeng Yun (5):
  dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
  dt-bindings: Add a binding for Mediatek xHCI host controller
  usb: phy: add usb3.0 phy driver for mt65xx SoCs
  xhci: mediatek: support MTK xHCI host controller
  arm64: dts: mediatek: add xHCI & usb phy for mt8173

 .../devicetree/bindings/phy/phy-mt65xx-u3.txt      |  21 +
 .../devicetree/bindings/usb/mt8173-xhci.txt        |  50 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts        |  15 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |  31 +
 drivers/phy/Kconfig                                |   9 +
 drivers/phy/Makefile                               |   1 +
 drivers/phy/phy-mt65xx-usb3.c                      | 426 +++++++++++
 drivers/usb/host/Kconfig                           |   9 +
 drivers/usb/host/Makefile                          |   4 +
 drivers/usb/host/xhci-mtk-sch.c                    | 436 +++++++++++
 drivers/usb/host/xhci-mtk.c                        | 836 +++++++++++++++++++++
 drivers/usb/host/xhci-mtk.h                        | 135 ++++
 drivers/usb/host/xhci-ring.c                       |  35 +-
 drivers/usb/host/xhci.c                            |  19 +-
 drivers/usb/host/xhci.h                            |   1 +
 15 files changed, 2021 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-u3.txt
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
 create mode 100644 drivers/phy/phy-mt65xx-usb3.c
 create mode 100644 drivers/usb/host/xhci-mtk-sch.c
 create mode 100644 drivers/usb/host/xhci-mtk.c
 create mode 100644 drivers/usb/host/xhci-mtk.h

--
1.8.1.1.dirty

In-Reply-To: 

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

* (unknown), 
@ 2015-07-31 11:22 Mrs Christy Walton
  0 siblings, 0 replies; 71+ messages in thread
From: Mrs Christy Walton @ 2015-07-31 11:22 UTC (permalink / raw)
  To: peter.u2011-PkbjNfxxIARBDgjK7y7TUQ


Greetings,

This is an official request for Professional/consultants who will stand as our regional representative to run logistics on behalf of zheng Group.We are looking for a payment collection agent in USA, Canada, Mexico and Europe. Salary is 10% of every payment you receive from our customers. Get back to us for more details if interested.

NOTE!!! it have no effect on your present job.


(1)Your Full names:
(2)Your Complete Address:
a. City:
b. State:
c. Zip code:
d. Country:
(3)Tele/cell numbers:
(4)Occupation:
(5)Gender:
(6)Age:
(7)Email:

Respectfully
Mr Tadashi Itoh (Human Resources)
zheng Group


--
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] 71+ messages in thread

* (unknown), 
@ 2015-08-04 15:37 Mark Salter
  0 siblings, 0 replies; 71+ messages in thread
From: Mark Salter @ 2015-08-04 15:37 UTC (permalink / raw)
  To: devicetree-u79uwXL29TY76Z2rM5mHXA

unsubscribe devicetree

--
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] 71+ messages in thread

* (unknown), 
@ 2015-08-29  1:09 Zheng Group
  0 siblings, 0 replies; 71+ messages in thread
From: Zheng Group @ 2015-08-29  1:09 UTC (permalink / raw)





Greetings,

This is an official request for Professional/consultants who will stand 
as our regional representative to run logistics on behalf of zheng 
Group.We are looking for a payment collection agent in USA, Canada, 
Mexico and Europe. Salary is 10% of every payment you receive from our 
customers. Get back to us for more details if interested. contact us for more details.
 

NOTE!!! it have no effect on your present job.


Respectfully
Mr Tadashi Itoh (Human Resources)
zheng Group


--
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] 71+ messages in thread

* (unknown), 
@ 2015-09-18 14:57 Asia Heritage Foundation
  0 siblings, 0 replies; 71+ messages in thread
From: Asia Heritage Foundation @ 2015-09-18 14:57 UTC (permalink / raw)




ATTENTION

This is to inform you that you have been selected for this year fund donation please contact our online officer via email: asiaheritagefoundations-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 

for more information of claims.

From
Mr.Rehan Omar.
Secretary
Asia Heritage Foundation (AHF)
Italy Chapter
--
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] 71+ messages in thread

* (unknown)
@ 2016-01-11  6:54 wangwyy-hl91/bYNON7k1uMJSBkQmQ
  0 siblings, 0 replies; 71+ messages in thread
From: wangwyy-hl91/bYNON7k1uMJSBkQmQ @ 2016-01-11  6:54 UTC (permalink / raw)
  To: dfengsteel-Mj/0Miq2reM, dfdqyb-/E1597aS9LRv1O+Z8WTAqQ,
	dfdhcjs-/E1597aS9LRv1O+Z8WTAqQ,
	devilliang2003-/E1597aS9LRv1O+Z8WTAqQ,
	dfcmwhb-/E1597aS9LRv1O+Z8WTAqQ, dfcb203719-/E1597aS9LRv1O+Z8WTAqQ,
	dfertl-/E1597aS9LT0CCvOHzKKcA, dengjw2006-/E1597aS9LQAvxtiuMwx3w,
	devpandey007-/E1597aS9LQAvxtiuMwx3w,
	dfdpep-/E1597aS9LQAvxtiuMwx3w, dfdok-/E1597aS9LQAvxtiuMwx3w,
	devananthangovindasamy-/E1597aS9LQAvxtiuMwx3w,
	dezhimu-/E1597aS9LQAvxtiuMwx3w, dfevdong-dbdLmdGazhY,
	dfdichi-dbdLmdGazhY, dfd3fdf31-dbdLmdGazhY,
	dezheng5918-dbdLmdGazhY, deyeni-dbdLmdGazhY,
	devon199-icHrzHC44DVdHVCsmzoppAC/G2K4zDHf,
	dfdai-yKZSRQ1cFl8nDS1+zs4M5A,
	dfd.com.yahoomail.com.com.com.qmail-3K/ljU4b5cRWj0EZb7rXcA,
	dfermine-39ZsbGIQGT5GWvitb5QawA, deyuelou-uB8bxKUEBrdWk0Htik3J/w,
	devil2012-OlFFNeSka43QT0dZR+AlfA, dfcnyh-Q4arlSNMIUZBDgjK7y7TUQ,
	dfcgx-Q4arlSNMIUYnDS1+zs4M5A, den-GveOkT2v/s5BDgjK7y7TUQ,
	dfczyj-GveOkT2v/s5BDgjK7y7TUQ, dfcar-GveOkT2v/s5BDgjK7y7TUQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	devin_kao-53PKxisUrC1Wk0Htik3J/w,
	dfcm-N6yXg7DiKdn/Op/ZHr5HmtBPR1lH4CV8, dennisqiu-WVlzvzqoTvw,
	dfe2221a-WVlzvzqoTvw, devil.lucifer-WVlzvzqoTvw,
	dfdfd-WVlzvzqoTvw


nd of smlast
--
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] 71+ messages in thread

* (unknown), 
@ 2016-05-18 16:26 Warner Losh
  0 siblings, 0 replies; 71+ messages in thread
From: Warner Losh @ 2016-05-18 16:26 UTC (permalink / raw)
  To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org

Greetings,

I was looking at the draft link posted here
https://github.com/devicetree-org/devicetree-specification-released/blob/master/prerelease/devicetree-specification-v0.1-pre1-20160429.pdf
a while ago. I hope this is the right place to ask about it.

It raised a bit of a question. There's nothing in it talking about the
current
practice of using CPP to pre-process the .dts/.dtsi files before passing
them
into dtc to compile them into dtb.

Normally, I see such things outside the scope of standardization. However,
many of the .dts files that are in the wild today use a number of #define
constants to make things more readable (having GPIO_ACTIVE_HIGH
instead of '0' makes the .dts files easier to read). However, there's a
small
issue that I've had. The files that contain those definitions are currently
in the Linux kernel and have a wide variety of licenses (including none
at all).

So before even getting to the notion of licenses and such (which past
expereince suggests may be the worst place to start a discussion), I'm
wondering where that will be defined, and if these #defines will become
part of the standard for each of the bindings that are defined.

I'm also wondering where the larger issue of using cpp to process the dts
files will be discussed, since FreeBSD's BSDL dtc suffers interoperability
due to this issue. Having the formal spec will also be helpful for its care and
feeding since many fine points have had to be decided based on .dts
files in the wild rather than a clear spec.

Thanks again for spear-heading the effort to get a new version out now
that ePAPR has fallen on hard times.

Warner

P.S. I'm mostly a FreeBSD guy, but just spent some time digging into this
issue for another of the BSDs that's considering adopting DTS files.
--
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] 71+ messages in thread

* (unknown), 
@ 2016-07-28 17:49 Ryan
  0 siblings, 0 replies; 71+ messages in thread
From: Ryan @ 2016-07-28 17:49 UTC (permalink / raw)
  To: devicetree-u79uwXL29TY76Z2rM5mHXA

 auth 74e10dbf subscribe devicetree ryanphilips19-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org
--
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] 71+ messages in thread

* (unknown), 
@ 2016-09-30 14:37 Maxime Ripard
  0 siblings, 0 replies; 71+ messages in thread
From: Maxime Ripard @ 2016-09-30 14:37 UTC (permalink / raw)
  To: Rob Herring, Daniel Vetter, David Airlie, Archit Taneja
  Cc: devicetree, dri-devel, Chen-Yu Tsai, Maxime Ripard,
	linux-arm-kernel

Subject: [PATCH v5 0/5] drm: Add Support for Passive RGB to VGA bridges

Hi,

This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.

Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the screen if available (and if not,
fall back on XGA standards), set up the display pipeline to output on
the RGB bus with the proper timings, and you're done.

This serie also fixes a bunch of bugs uncovered when trying to
increase the resolution, and hence the pixel clock, of our
pipeline. It also fixes a few bugs in the DRM driver itself that went
unnoticed before.

Let me know what you think,
Maxime

Changes from v4:
  - Removed unused functions

Changes from v3:
  - Depends on OF in Kconfig
  - Fixed typos in the driver comments
  - Removed the mention of a "passive" bridge in the bindings doc
  - Made the strcuture const
  - Removed the nops and best_encoders implementations
  - Removed the call to drm_bridge_enable in the sun4i driver

Changes from v2:
  - Changed the compatible as suggested
  - Rebased on top 4.8

Changes from v1:
  - Switch to using a vga-connector
  - Use drm_encoder bridge pointer instead of doing our own
  - Report the connector status as unknown instead of connected by
    default, and as connected only if we can retrieve the EDID.
  - Switch to of_i2c_get_adapter by node, and put the reference when done
  - Rebased on linux-next	      

Maxime Ripard (5):
  drm/sun4i: rgb: Remove the bridge enable/disable functions
  drm/bridge: Add RGB to VGA bridge support
  ARM: sun5i: a13-olinuxino: Enable VGA bridge
  ARM: multi_v7: enable VGA bridge
  ARM: sunxi: Enable VGA bridge

 .../bindings/display/bridge/rgb-to-vga-bridge.txt  |  48 +++++
 arch/arm/boot/dts/sun5i-a13-olinuxino.dts          |  54 +++++
 arch/arm/configs/multi_v7_defconfig                |   1 +
 arch/arm/configs/sunxi_defconfig                   |   1 +
 drivers/gpu/drm/bridge/Kconfig                     |   7 +
 drivers/gpu/drm/bridge/Makefile                    |   1 +
 drivers/gpu/drm/bridge/rgb-to-vga.c                | 229 +++++++++++++++++++++
 drivers/gpu/drm/sun4i/sun4i_rgb.c                  |   6 -
 8 files changed, 341 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
 create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c

-- 
2.9.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* (unknown), 
@ 2016-11-20 22:16 Mr Friedrich Mayrhofer
  0 siblings, 0 replies; 71+ messages in thread
From: Mr Friedrich Mayrhofer @ 2016-11-20 22:16 UTC (permalink / raw)





Good Day,

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.

Regards.
Friedrich Mayrhofer






--
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] 71+ messages in thread

* (unknown), 
@ 2016-11-28  9:58 Mr Friedrich Mayrhofer
  0 siblings, 0 replies; 71+ messages in thread
From: Mr Friedrich Mayrhofer @ 2016-11-28  9:58 UTC (permalink / raw)





Good Day,

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for
more details.

Regards.
Friedrich Mayrhofer






--
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] 71+ messages in thread

* (unknown), 
@ 2016-12-14  2:45 Mr Friedrich Mayrhofer
  0 siblings, 0 replies; 71+ messages in thread
From: Mr Friedrich Mayrhofer @ 2016-12-14  2:45 UTC (permalink / raw)



Good Day,

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.

Regards.
Friedrich Mayrhofer






--
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] 71+ messages in thread

* (unknown), 
@ 2017-02-16 21:01 Qin's Yanjun
  0 siblings, 0 replies; 71+ messages in thread
From: Qin's Yanjun @ 2017-02-16 21:01 UTC (permalink / raw)



How are you today and your family? I'm Qin Yanjun, Tak-lam, SBS, JP, and
Chief Executive of (HKMA). I have a concealed business suggestion for you,
It require your attention and honest co-operation.

Regards,
Mr. Qin Yanjun


______________________________

Sky Silk, http://aknet.kz

--
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] 71+ messages in thread

* (unknown), 
@ 2017-03-14 17:14 nkosuta-f+iqBESB6gc
  0 siblings, 0 replies; 71+ messages in thread
From: nkosuta-f+iqBESB6gc @ 2017-03-14 17:14 UTC (permalink / raw)
  To: devicetree

[-- Attachment #1: EMAIL_05109557_devicetree.zip --]
[-- Type: application/zip, Size: 4727 bytes --]

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

* (unknown), 
@ 2017-03-20 19:40 janepatrick00-VmEwxm1hRrAnxqbYAscKCQ
  0 siblings, 0 replies; 71+ messages in thread
From: janepatrick00-VmEwxm1hRrAnxqbYAscKCQ @ 2017-03-20 19:40 UTC (permalink / raw)
  To: Recipients

Hello,
My name is Jane from UK, I came across you email address online, I will like to know more about you , I have a very important reason of contacting you which, I'll tell you in my next mail.
I wait for your reply
--
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] 71+ messages in thread

* (unknown), 
@ 2017-04-03  6:14 Adrian Gillian Bayford
  0 siblings, 0 replies; 71+ messages in thread
From: Adrian Gillian Bayford @ 2017-04-03  6:14 UTC (permalink / raw)
  To: Recipients

£1.5 Million Has Been Granted To You As A Donation Visit www.bbc.co.uk/news/uk-england-19254228 Sendname Address Phone for more info
--
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] 71+ messages in thread

* (unknown), 
@ 2017-04-17  4:06 nkosuta-f+iqBESB6gc
  0 siblings, 0 replies; 71+ messages in thread
From: nkosuta-f+iqBESB6gc @ 2017-04-17  4:06 UTC (permalink / raw)
  To: devicetree

[-- Attachment #1: $MONEY-52123352603-devicetree.zip --]
[-- Type: application/zip, Size: 2171 bytes --]

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

* (unknown), 
@ 2017-06-10  7:07 Youichi Kanno
  0 siblings, 0 replies; 71+ messages in thread
From: Youichi Kanno @ 2017-06-10  7:07 UTC (permalink / raw)





Sir/Madam

I am sorry to encroach into your privacy in this manner, I found you  
listed in the Trade Center Chambers of Commerce directory here in  
Japan, My name is Youichi Kanno and I work in Audit & credit  
Supervisory role at The Norinchukin Bank, I need your assistance to  
process the fund claims oF $18,100,000.00 (Eighteen Million, One  
Hundred Thousand, USD) of a deceased client Mr. Grigor Kassan, And i  
need your assistance to process the fund claims, I only pray at this  
time that your address is still valid. I want to solicit your  
attention to receive this money on my behalf. The purpose of my  
contacting you is because my status would not permit me to do this  
alone.

I hope to hear from you soon so we can discuss the logistic of moving  
the funds to a safe offshore bank.

Yours sincerely,
Youichi Kanno
Phone Number: +81345400962





--
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] 71+ messages in thread

* (unknown), 
@ 2017-06-23  4:50 nkosuta-f+iqBESB6gc
  0 siblings, 0 replies; 71+ messages in thread
From: nkosuta-f+iqBESB6gc @ 2017-06-23  4:50 UTC (permalink / raw)
  To: devicetree-u79uwXL29TY76Z2rM5mHXA

[-- Attachment #1: 39579.zip --]
[-- Type: application/zip, Size: 3602 bytes --]

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

* (unknown), 
       [not found] ` <1504117946-3958-1-git-send-email-larturus2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2017-09-24 15:50   ` Artur Lorincz
  2017-10-06 19:31   ` (unknown), Artur Lorincz
  2017-10-08 16:28   ` (unknown), Artur Lorincz
  2 siblings, 0 replies; 71+ messages in thread
From: Artur Lorincz @ 2017-09-24 15:50 UTC (permalink / raw)
  To: frowand.list-Re5JQEeQqe8AvxtiuMwx3w
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	larturus-/E1597aS9LQAvxtiuMwx3w

Hello,

Could you please send me an update about this patch?

Thanks,
Artur
--
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] 71+ messages in thread

* (unknown), 
       [not found] ` <1504117946-3958-1-git-send-email-larturus2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  2017-09-24 15:50   ` (unknown), Artur Lorincz
@ 2017-10-06 19:31   ` Artur Lorincz
  2017-10-08 16:28   ` (unknown), Artur Lorincz
  2 siblings, 0 replies; 71+ messages in thread
From: Artur Lorincz @ 2017-10-06 19:31 UTC (permalink / raw)
  To: robh-DgEjT+Ai2ygdnm+yROfE0A
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	larturus-/E1597aS9LQAvxtiuMwx3w

Hello,

When you get to it, could you please send me an update about this patch?

I believe the attached (trivial) patch should take less time to review then reading this message.
 
Thanks,
Artur
--
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] 71+ messages in thread

* (unknown), 
       [not found] ` <1504117946-3958-1-git-send-email-larturus2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  2017-09-24 15:50   ` (unknown), Artur Lorincz
  2017-10-06 19:31   ` (unknown), Artur Lorincz
@ 2017-10-08 16:28   ` Artur Lorincz
  2 siblings, 0 replies; 71+ messages in thread
From: Artur Lorincz @ 2017-10-08 16:28 UTC (permalink / raw)
  To: robh-DgEjT+Ai2ygdnm+yROfE0A
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	larturus-/E1597aS9LQAvxtiuMwx3w

Hello,

Thanks for checking the patch.

I missed the #else part of he CONFIG_OF #ifdef previously.

I made the code properly depend on CONFIG_OF now.

I am not familiar with this code base. When time allows I would like to contribute by  refactoring code in this area.

Let me know if you have specific ideas about what should change and how the code should be refactored.

Artur
--
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] 71+ messages in thread

* (unknown), 
@ 2018-02-12  1:39 Alfred Cheuk Chow
  0 siblings, 0 replies; 71+ messages in thread
From: Alfred Cheuk Chow @ 2018-02-12  1:39 UTC (permalink / raw)



Good Day,

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong
Hing Bank, Hong Kong, Chong Hing Bank Center, 24 Des Voeux Road Central,
Hong Kong. I have a business proposal of $ 38,980,369.00.

All confirmable documents to back up the claims will be made available
to you prior to your acceptance and as soon as I receive your return
mail.

Best Regards,
Alfred Chow.






--
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] 71+ messages in thread

* (unknown), 
@ 2018-06-23 21:08 David Lechner
  2018-06-23 21:08 ` [PATCH 1/8] remoteproc: add map parameter to da_to_va David Lechner
                   ` (8 more replies)
  0 siblings, 9 replies; 71+ messages in thread
From: David Lechner @ 2018-06-23 21:08 UTC (permalink / raw)
  To: linux-remoteproc, devicetree, linux-omap, linux-arm-kernel
  Cc: David Lechner, Ohad Ben-Cohen, Bjorn Andersson, Rob Herring,
	Mark Rutland, Benoît Cousson, Tony Lindgren, Sekhar Nori,
	Kevin Hilman, linux-kernel


Date: Sat, 23 Jun 2018 15:43:59 -0500
Subject: [PATCH 0/8] New remoteproc driver for TI PRU

This series adds a new remoteproc driver for the TI Programmable Runtime Unit
(PRU) that is present in some TI Sitara processors. This code has been tested
working on AM1808 (LEGO MINDSTORMS EV3) and AM3358 (BeagleBone Green).

There are a couple of quirks that had to be worked around in order to get this
working. The PRU units have multiple memory maps. Notably, both the instruction
RAM and data RAM are at address 0x0. This caused the da_to_va callback to not
work because the same address could refer to two different locations. To work
around this, the first two patches add a "map" parameter to the da_to_va
callbacks so that we have an extra bit of information to make this distinction.

Also, on AM38xx we have to use pdata for accessing a reset since there is not
a reset controller. There are several other devices doing this, so the seems
the best way for now.

For anyone else who would like to test, I used the rpmsg-client-sample driver.
Just enable it in your kernel config. Then grab the appropriate firmware[1]
and put in in /lib/firmware/. Use sysfs to start and stop the PRU:

        echo start > /sys/class/remoteproc<n>/state
        echo stop > /sys/class/remoteproc<n>/state

[1]: firmware downloads:

AM18XX: https://github.com/ev3dev/ev3dev-pru-firmware/releases/download/mainline-kernel-testing/AM18xx-PRU-rpmsg-client-sample.zip
AM335X: https://github.com/ev3dev/ev3dev-pru-firmware/releases/download/mainline-kernel-testing/AM335x-PRU-rpmsg-client-sample.zip

David Lechner (8):
  remoteproc: add map parameter to da_to_va
  remoteproc: add page lookup for TI PRU to ELF loader
  ARM: OMAP2+: add pdata quirks for PRUSS reset
  dt-bindings: add bindings for TI PRU as remoteproc
  remoteproc: new driver for TI PRU
  ARM: davinci_all_defconfig: enable PRU remoteproc module
  ARM: dts: da850: add node for PRUSS
  ARM: dts: am33xx: add node for PRU remoteproc

 .../bindings/remoteproc/ti_pru_rproc.txt      |  51 ++
 MAINTAINERS                                   |   5 +
 arch/arm/boot/dts/am33xx.dtsi                 |   9 +
 arch/arm/boot/dts/da850.dtsi                  |   8 +
 arch/arm/configs/davinci_all_defconfig        |   2 +
 arch/arm/mach-omap2/pdata-quirks.c            |   9 +
 drivers/remoteproc/Kconfig                    |   7 +
 drivers/remoteproc/Makefile                   |   1 +
 drivers/remoteproc/imx_rproc.c                |   2 +-
 drivers/remoteproc/keystone_remoteproc.c      |   3 +-
 drivers/remoteproc/qcom_adsp_pil.c            |   2 +-
 drivers/remoteproc/qcom_q6v5_pil.c            |   2 +-
 drivers/remoteproc/qcom_wcnss.c               |   2 +-
 drivers/remoteproc/remoteproc_core.c          |  10 +-
 drivers/remoteproc/remoteproc_elf_loader.c    | 117 +++-
 drivers/remoteproc/remoteproc_internal.h      |   2 +-
 drivers/remoteproc/st_slim_rproc.c            |   2 +-
 drivers/remoteproc/ti_pru_rproc.c             | 660 ++++++++++++++++++
 drivers/remoteproc/wkup_m3_rproc.c            |   3 +-
 include/linux/platform_data/ti-pruss.h        |  18 +
 include/linux/remoteproc.h                    |   2 +-
 include/uapi/linux/elf-em.h                   |   1 +
 22 files changed, 899 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
 create mode 100644 drivers/remoteproc/ti_pru_rproc.c
 create mode 100644 include/linux/platform_data/ti-pruss.h

-- 
2.17.1

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

* [PATCH 1/8] remoteproc: add map parameter to da_to_va
  2018-06-23 21:08 (unknown), David Lechner
@ 2018-06-23 21:08 ` David Lechner
  2018-06-23 21:08 ` [PATCH 2/8] remoteproc: add page lookup for TI PRU to ELF loader David Lechner
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 71+ messages in thread
From: David Lechner @ 2018-06-23 21:08 UTC (permalink / raw)
  To: linux-remoteproc, devicetree, linux-omap, linux-arm-kernel
  Cc: David Lechner, Ohad Ben-Cohen, Bjorn Andersson, Rob Herring,
	Mark Rutland, Benoît Cousson, Tony Lindgren, Sekhar Nori,
	Kevin Hilman, linux-kernel

This adds a new map parameter to the da_to_va callback for remoteproc
devices. This parameter will be used by devices that have more than
one memory map, such as the PRU found in TI Sitara SoCs.

On these devices, the same physical memory address can refer to two
different locations, i.e. instruction memory or data memory both start
at 0x0. So, an extra bit of information is needed in the da_to_va
callback to tell these apart.

Devices that only have a single memory map will just pass 0 for this
parameter. For now we are using 0 everywhere, but later patches will
modify this value.

Signed-off-by: David Lechner <david@lechnology.com>
---
 drivers/remoteproc/imx_rproc.c             |  2 +-
 drivers/remoteproc/keystone_remoteproc.c   |  3 ++-
 drivers/remoteproc/qcom_adsp_pil.c         |  2 +-
 drivers/remoteproc/qcom_q6v5_pil.c         |  2 +-
 drivers/remoteproc/qcom_wcnss.c            |  2 +-
 drivers/remoteproc/remoteproc_core.c       | 10 ++++++----
 drivers/remoteproc/remoteproc_elf_loader.c |  4 ++--
 drivers/remoteproc/remoteproc_internal.h   |  2 +-
 drivers/remoteproc/st_slim_rproc.c         |  2 +-
 drivers/remoteproc/wkup_m3_rproc.c         |  3 ++-
 include/linux/remoteproc.h                 |  2 +-
 11 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 54c07fd3f204..78c3502fea36 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -211,7 +211,7 @@ static int imx_rproc_da_to_sys(struct imx_rproc *priv, u64 da,
 	return -ENOENT;
 }
 
-static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, int len, int map)
 {
 	struct imx_rproc *priv = rproc->priv;
 	void *va = NULL;
diff --git a/drivers/remoteproc/keystone_remoteproc.c b/drivers/remoteproc/keystone_remoteproc.c
index aaac31134e39..0f87cf95ae4f 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -254,7 +254,8 @@ static void keystone_rproc_kick(struct rproc *rproc, int vqid)
  * can be used either by the remoteproc core for loading (when using kernel
  * remoteproc loader), or by any rpmsg bus drivers.
  */
-static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, int len,
+				     int map)
 {
 	struct keystone_rproc *ksproc = rproc->priv;
 	void __iomem *va = NULL;
diff --git a/drivers/remoteproc/qcom_adsp_pil.c b/drivers/remoteproc/qcom_adsp_pil.c
index 89a86ce07f99..25a174a06985 100644
--- a/drivers/remoteproc/qcom_adsp_pil.c
+++ b/drivers/remoteproc/qcom_adsp_pil.c
@@ -167,7 +167,7 @@ static int adsp_stop(struct rproc *rproc)
 	return ret;
 }
 
-static void *adsp_da_to_va(struct rproc *rproc, u64 da, int len)
+static void *adsp_da_to_va(struct rproc *rproc, u64 da, int len, int map)
 {
 	struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
 	int offset;
diff --git a/drivers/remoteproc/qcom_q6v5_pil.c b/drivers/remoteproc/qcom_q6v5_pil.c
index 2bf8e7c49f2a..58ba7349b311 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -995,7 +995,7 @@ static int q6v5_stop(struct rproc *rproc)
 	return 0;
 }
 
-static void *q6v5_da_to_va(struct rproc *rproc, u64 da, int len)
+static void *q6v5_da_to_va(struct rproc *rproc, u64 da, int len, int map)
 {
 	struct q6v5 *qproc = rproc->priv;
 	int offset;
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index b0e07e9f42d5..92b05fb10557 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -295,7 +295,7 @@ static int wcnss_stop(struct rproc *rproc)
 	return ret;
 }
 
-static void *wcnss_da_to_va(struct rproc *rproc, u64 da, int len)
+static void *wcnss_da_to_va(struct rproc *rproc, u64 da, int len, int map)
 {
 	struct qcom_wcnss *wcnss = (struct qcom_wcnss *)rproc->priv;
 	int offset;
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index a9609d971f7f..fb9ae85a0bee 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -145,6 +145,8 @@ static void rproc_disable_iommu(struct rproc *rproc)
  * @rproc: handle of a remote processor
  * @da: remoteproc device address to translate
  * @len: length of the memory region @da is pointing to
+ * @map: indicates which memory map to use for devices with more than one
+ *       memory map or 0 for devices that only have a single memory map
  *
  * Some remote processors will ask us to allocate them physically contiguous
  * memory regions (which we call "carveouts"), and map them to specific
@@ -169,13 +171,13 @@ static void rproc_disable_iommu(struct rproc *rproc)
  * here the output of the DMA API for the carveouts, which should be more
  * correct.
  */
-void *rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+void *rproc_da_to_va(struct rproc *rproc, u64 da, int len, int map)
 {
 	struct rproc_mem_entry *carveout;
 	void *ptr = NULL;
 
 	if (rproc->ops->da_to_va) {
-		ptr = rproc->ops->da_to_va(rproc, da, len);
+		ptr = rproc->ops->da_to_va(rproc, da, len, map);
 		if (ptr)
 			goto out;
 	}
@@ -468,7 +470,7 @@ static int rproc_handle_trace(struct rproc *rproc, struct fw_rsc_trace *rsc,
 	}
 
 	/* what's the kernel address of this resource ? */
-	ptr = rproc_da_to_va(rproc, rsc->da, rsc->len);
+	ptr = rproc_da_to_va(rproc, rsc->da, rsc->len, 0);
 	if (!ptr) {
 		dev_err(dev, "erroneous trace resource entry\n");
 		return -EINVAL;
@@ -1124,7 +1126,7 @@ static void rproc_coredump(struct rproc *rproc)
 		phdr->p_flags = PF_R | PF_W | PF_X;
 		phdr->p_align = 0;
 
-		ptr = rproc_da_to_va(rproc, segment->da, segment->size);
+		ptr = rproc_da_to_va(rproc, segment->da, segment->size, 0);
 		if (!ptr) {
 			dev_err(&rproc->dev,
 				"invalid coredump segment (%pad, %zu)\n",
diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c
index b17d72ec8603..8888d39e1b13 100644
--- a/drivers/remoteproc/remoteproc_elf_loader.c
+++ b/drivers/remoteproc/remoteproc_elf_loader.c
@@ -182,7 +182,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
 		}
 
 		/* grab the kernel address for this device address */
-		ptr = rproc_da_to_va(rproc, da, memsz);
+		ptr = rproc_da_to_va(rproc, da, memsz, 0);
 		if (!ptr) {
 			dev_err(dev, "bad phdr da 0x%x mem 0x%x\n", da, memsz);
 			ret = -EINVAL;
@@ -333,6 +333,6 @@ struct resource_table *rproc_elf_find_loaded_rsc_table(struct rproc *rproc,
 	if (!shdr)
 		return NULL;
 
-	return rproc_da_to_va(rproc, shdr->sh_addr, shdr->sh_size);
+	return rproc_da_to_va(rproc, shdr->sh_addr, shdr->sh_size, 0);
 }
 EXPORT_SYMBOL(rproc_elf_find_loaded_rsc_table);
diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
index 7570beb035b5..92968a341f86 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -51,7 +51,7 @@ void rproc_exit_sysfs(void);
 void rproc_free_vring(struct rproc_vring *rvring);
 int rproc_alloc_vring(struct rproc_vdev *rvdev, int i);
 
-void *rproc_da_to_va(struct rproc *rproc, u64 da, int len);
+void *rproc_da_to_va(struct rproc *rproc, u64 da, int len, int map);
 int rproc_trigger_recovery(struct rproc *rproc);
 
 int rproc_elf_sanity_check(struct rproc *rproc, const struct firmware *fw);
diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
index 1ffb1f0c43d6..146badc9f061 100644
--- a/drivers/remoteproc/st_slim_rproc.c
+++ b/drivers/remoteproc/st_slim_rproc.c
@@ -178,7 +178,7 @@ static int slim_rproc_stop(struct rproc *rproc)
 	return 0;
 }
 
-static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len, int map)
 {
 	struct st_slim_rproc *slim_rproc = rproc->priv;
 	void *va = NULL;
diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
index 1ada0e51fef6..12cb26ebf35b 100644
--- a/drivers/remoteproc/wkup_m3_rproc.c
+++ b/drivers/remoteproc/wkup_m3_rproc.c
@@ -88,7 +88,8 @@ static int wkup_m3_rproc_stop(struct rproc *rproc)
 	return 0;
 }
 
-static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
+static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, int len,
+				    int map)
 {
 	struct wkup_m3_rproc *wkupm3 = rproc->priv;
 	void *va = NULL;
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index dfdaede9139e..2d88e394fc99 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -343,7 +343,7 @@ struct rproc_ops {
 	int (*start)(struct rproc *rproc);
 	int (*stop)(struct rproc *rproc);
 	void (*kick)(struct rproc *rproc, int vqid);
-	void * (*da_to_va)(struct rproc *rproc, u64 da, int len);
+	void * (*da_to_va)(struct rproc *rproc, u64 da, int len, int map);
 	int (*parse_fw)(struct rproc *rproc, const struct firmware *fw);
 	struct resource_table *(*find_loaded_rsc_table)(
 				struct rproc *rproc, const struct firmware *fw);
-- 
2.17.1

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

* [PATCH 2/8] remoteproc: add page lookup for TI PRU to ELF loader
  2018-06-23 21:08 (unknown), David Lechner
  2018-06-23 21:08 ` [PATCH 1/8] remoteproc: add map parameter to da_to_va David Lechner
@ 2018-06-23 21:08 ` David Lechner
  2018-06-23 21:08 ` [PATCH 3/8] ARM: OMAP2+: add pdata quirks for PRUSS reset David Lechner
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 71+ messages in thread
From: David Lechner @ 2018-06-23 21:08 UTC (permalink / raw)
  To: linux-remoteproc, devicetree, linux-omap, linux-arm-kernel
  Cc: Ohad Ben-Cohen, Mark Rutland, David Lechner, Kevin Hilman,
	Tony Lindgren, Sekhar Nori, linux-kernel, Bjorn Andersson,
	Rob Herring, Benoît Cousson

This adds a special handler to the default remoteproc ELF firmware
loader that looks up the memory map on TI PRU firmware files.

These processors have multiple memory maps that share the same address
space, so we need to know the page in addition to the physical address
in order to translate the address to a local CPU address.

Signed-off-by: David Lechner <david@lechnology.com>
---
 drivers/remoteproc/remoteproc_elf_loader.c | 117 +++++++++++++++++++--
 include/uapi/linux/elf-em.h                |   1 +
 2 files changed, 112 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_elf_loader.c b/drivers/remoteproc/remoteproc_elf_loader.c
index 8888d39e1b13..f041b6fb798f 100644
--- a/drivers/remoteproc/remoteproc_elf_loader.c
+++ b/drivers/remoteproc/remoteproc_elf_loader.c
@@ -32,6 +32,103 @@
 
 #include "remoteproc_internal.h"
 
+#define SHT_TI_PHATTRS 0x7F000004
+#define SHT_TI_SH_PAGE 0x7F000007
+
+typedef struct {
+	Elf32_Half pha_seg_id; /* Segment id */
+	Elf32_Half pha_tag_id; /* Attribute kind id */
+	union {
+		Elf32_Off pha_offset; /* byte offset within the section */
+		Elf32_Word pha_value; /* Constant tag value */
+	} pha_un;
+} Elf32_TI_PHAttrs;
+
+/* this struct is reverse engineered, so not sure what most of the values are */
+struct ti_section_page {
+	u32 unk0;
+	u32 unk1;
+	u32 unk2;
+	u32 unk3;
+	u32 unk4;
+	u16 size;
+	u16 unk5;
+	u16 unk6;
+	u8 data[0]; /* array of size */
+};
+
+/**
+ * rproc_elf_segment_to_map() - Gets memory map for segment
+ * @id: segment id
+ * @elf_data: pointer to ELF file data
+ *
+ * Returns the memory map for the segment.
+ */
+static int rproc_elf_segment_to_map(u32 id, const u8 *elf_data)
+{
+	struct elf32_hdr *ehdr;
+	struct elf32_shdr *shdr;
+	Elf32_TI_PHAttrs *attrs = NULL;
+	int i;
+
+	ehdr = (struct elf32_hdr *)elf_data;
+	shdr = (struct elf32_shdr *)(elf_data + ehdr->e_shoff);
+
+	if (ehdr->e_machine != EM_TI_PRU)
+		return 0;
+
+	for (i = 0; i < ehdr->e_shnum; i++, shdr++) {
+		if (shdr->sh_type == SHT_TI_PHATTRS) {
+			attrs = (Elf32_TI_PHAttrs *)(elf_data + shdr->sh_offset);
+			break;
+		}
+	}
+
+	if (!attrs)
+		return 0;
+
+	/* list is terminated by tag id == 0 (PHA_NULL) */
+	for (; attrs->pha_tag_id; attrs++) {
+		if (attrs->pha_tag_id == 3 && attrs->pha_seg_id == id)
+			return attrs->pha_un.pha_value;
+	}
+
+	return 0;
+}
+
+/**
+ * rproc_elf_section_to_map() - Gets memory map for section
+ * @id: segment id
+ * @elf_data: pointer to ELF file data
+ *
+ * Returns the memory map for the section.
+ */
+static int rproc_elf_section_to_map(u32 id, const u8 *elf_data)
+{
+	struct elf32_hdr *ehdr;
+	struct elf32_shdr *shdr;
+	struct ti_section_page *map = NULL;
+	int i;
+
+	ehdr = (struct elf32_hdr *)elf_data;
+	shdr = (struct elf32_shdr *)(elf_data + ehdr->e_shoff);
+
+	if (ehdr->e_machine != EM_TI_PRU)
+		return 0;
+
+	for (i = 0; i < ehdr->e_shnum; i++, shdr++) {
+		if (shdr->sh_type == SHT_TI_SH_PAGE) {
+			map = (struct ti_section_page *)(elf_data + shdr->sh_offset);
+			break;
+		}
+	}
+
+	if (!map || id >= map->size)
+		return 0;
+
+	return map->data[id];
+}
+
 /**
  * rproc_elf_sanity_check() - Sanity Check ELF firmware image
  * @rproc: the remote processor handle
@@ -147,7 +244,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
 	struct device *dev = &rproc->dev;
 	struct elf32_hdr *ehdr;
 	struct elf32_phdr *phdr;
-	int i, ret = 0;
+	int i, map, ret = 0;
 	const u8 *elf_data = fw->data;
 
 	ehdr = (struct elf32_hdr *)elf_data;
@@ -181,8 +278,10 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
 			break;
 		}
 
+		map = rproc_elf_segment_to_map(i, elf_data);
+
 		/* grab the kernel address for this device address */
-		ptr = rproc_da_to_va(rproc, da, memsz, 0);
+		ptr = rproc_da_to_va(rproc, da, memsz, map);
 		if (!ptr) {
 			dev_err(dev, "bad phdr da 0x%x mem 0x%x\n", da, memsz);
 			ret = -EINVAL;
@@ -209,7 +308,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const struct firmware *fw)
 EXPORT_SYMBOL(rproc_elf_load_segments);
 
 static struct elf32_shdr *
-find_table(struct device *dev, struct elf32_hdr *ehdr, size_t fw_size)
+find_table(struct device *dev, struct elf32_hdr *ehdr, size_t fw_size, int *id)
 {
 	struct elf32_shdr *shdr;
 	int i;
@@ -261,6 +360,9 @@ find_table(struct device *dev, struct elf32_hdr *ehdr, size_t fw_size)
 			return NULL;
 		}
 
+		if (id)
+			*id = i;
+
 		return shdr;
 	}
 
@@ -288,7 +390,7 @@ int rproc_elf_load_rsc_table(struct rproc *rproc, const struct firmware *fw)
 
 	ehdr = (struct elf32_hdr *)elf_data;
 
-	shdr = find_table(dev, ehdr, fw->size);
+	shdr = find_table(dev, ehdr, fw->size, NULL);
 	if (!shdr)
 		return -EINVAL;
 
@@ -328,11 +430,14 @@ struct resource_table *rproc_elf_find_loaded_rsc_table(struct rproc *rproc,
 {
 	struct elf32_hdr *ehdr = (struct elf32_hdr *)fw->data;
 	struct elf32_shdr *shdr;
+	int id, map;
 
-	shdr = find_table(&rproc->dev, ehdr, fw->size);
+	shdr = find_table(&rproc->dev, ehdr, fw->size, &id);
 	if (!shdr)
 		return NULL;
 
-	return rproc_da_to_va(rproc, shdr->sh_addr, shdr->sh_size, 0);
+	map = rproc_elf_section_to_map(id, fw->data);
+
+	return rproc_da_to_va(rproc, shdr->sh_addr, shdr->sh_size, map);
 }
 EXPORT_SYMBOL(rproc_elf_find_loaded_rsc_table);
diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h
index 31aa10178335..ce114abc7a50 100644
--- a/include/uapi/linux/elf-em.h
+++ b/include/uapi/linux/elf-em.h
@@ -37,6 +37,7 @@
 #define EM_BLACKFIN     106     /* ADI Blackfin Processor */
 #define EM_ALTERA_NIOS2	113	/* Altera Nios II soft-core processor */
 #define EM_TI_C6000	140	/* TI C6X DSPs */
+#define EM_TI_PRU	144	/* TI Programmable Realtime Unit */
 #define EM_AARCH64	183	/* ARM 64 bit */
 #define EM_TILEPRO	188	/* Tilera TILEPro */
 #define EM_MICROBLAZE	189	/* Xilinx MicroBlaze */
-- 
2.17.1

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

* [PATCH 3/8] ARM: OMAP2+: add pdata quirks for PRUSS reset
  2018-06-23 21:08 (unknown), David Lechner
  2018-06-23 21:08 ` [PATCH 1/8] remoteproc: add map parameter to da_to_va David Lechner
  2018-06-23 21:08 ` [PATCH 2/8] remoteproc: add page lookup for TI PRU to ELF loader David Lechner
@ 2018-06-23 21:08 ` David Lechner
  2018-06-23 21:08 ` [PATCH 4/8] dt-bindings: add bindings for TI PRU as remoteproc David Lechner
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 71+ messages in thread
From: David Lechner @ 2018-06-23 21:08 UTC (permalink / raw)
  To: linux-remoteproc, devicetree, linux-omap, linux-arm-kernel
  Cc: David Lechner, Ohad Ben-Cohen, Bjorn Andersson, Rob Herring,
	Mark Rutland, Benoît Cousson, Tony Lindgren, Sekhar Nori,
	Kevin Hilman, linux-kernel

This adds platform data for the PRUSS reset on OMAP2+. This is following
the pattern used by several other platform devices on these SoCs since
there is not a proper reset controller.

Signed-off-by: David Lechner <david@lechnology.com>
---
 arch/arm/mach-omap2/pdata-quirks.c     |  9 +++++++++
 include/linux/platform_data/ti-pruss.h | 18 ++++++++++++++++++
 2 files changed, 27 insertions(+)
 create mode 100644 include/linux/platform_data/ti-pruss.h

diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 7f02743edbe4..8ea35d6cded5 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -25,6 +25,7 @@
 #include <linux/platform_data/hsmmc-omap.h>
 #include <linux/platform_data/iommu-omap.h>
 #include <linux/platform_data/ti-sysc.h>
+#include <linux/platform_data/ti-pruss.h>
 #include <linux/platform_data/wkup_m3.h>
 #include <linux/platform_data/asoc-ti-mcbsp.h>
 
@@ -424,6 +425,12 @@ static struct wkup_m3_platform_data wkup_m3_data = {
 	.assert_reset = omap_device_assert_hardreset,
 	.deassert_reset = omap_device_deassert_hardreset,
 };
+
+static struct ti_pruss_platform_data pruss_data = {
+	.reset_name = "pruss",
+	.assert_reset = omap_device_assert_hardreset,
+	.deassert_reset = omap_device_deassert_hardreset,
+};
 #endif
 
 #ifdef CONFIG_SOC_OMAP5
@@ -568,6 +575,8 @@ static struct of_dev_auxdata omap_auxdata_lookup[] = {
 #ifdef CONFIG_SOC_AM33XX
 	OF_DEV_AUXDATA("ti,am3352-wkup-m3", 0x44d00000, "44d00000.wkup_m3",
 		       &wkup_m3_data),
+	OF_DEV_AUXDATA("ti,am3352-pru-rproc", 0x4a300000, "4a300000.cpu",
+		       &pruss_data),
 #endif
 #ifdef CONFIG_SOC_AM43XX
 	OF_DEV_AUXDATA("ti,am4372-wkup-m3", 0x44d00000, "44d00000.wkup_m3",
diff --git a/include/linux/platform_data/ti-pruss.h b/include/linux/platform_data/ti-pruss.h
new file mode 100644
index 000000000000..e401e621ebdf
--- /dev/null
+++ b/include/linux/platform_data/ti-pruss.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * TI PRU remote processor platform data
+ */
+
+#ifndef _LINUX_PLATFORM_DATA_TI_PRU_H
+#define _LINUX_PLATFORM_DATA_TI_PRU_H
+
+struct platform_device;
+
+struct ti_pruss_platform_data {
+	const char *reset_name;
+
+	int (*assert_reset)(struct platform_device *pdev, const char *name);
+	int (*deassert_reset)(struct platform_device *pdev, const char *name);
+};
+
+#endif /* _LINUX_PLATFORM_DATA_TI_PRU_H */
-- 
2.17.1

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

* [PATCH 4/8] dt-bindings: add bindings for TI PRU as remoteproc
  2018-06-23 21:08 (unknown), David Lechner
                   ` (2 preceding siblings ...)
  2018-06-23 21:08 ` [PATCH 3/8] ARM: OMAP2+: add pdata quirks for PRUSS reset David Lechner
@ 2018-06-23 21:08 ` David Lechner
  2018-07-03 20:59   ` Rob Herring
  2018-06-23 21:08 ` [PATCH 5/8] remoteproc: new driver for TI PRU David Lechner
                   ` (4 subsequent siblings)
  8 siblings, 1 reply; 71+ messages in thread
From: David Lechner @ 2018-06-23 21:08 UTC (permalink / raw)
  To: linux-remoteproc, devicetree, linux-omap, linux-arm-kernel
  Cc: David Lechner, Ohad Ben-Cohen, Bjorn Andersson, Rob Herring,
	Mark Rutland, Benoît Cousson, Tony Lindgren, Sekhar Nori,
	Kevin Hilman, linux-kernel

This adds a new binding for the TI Programmable Runtime Unit (PRU)
as a remoteproc device.

Signed-off-by: David Lechner <david@lechnology.com>
---
 .../bindings/remoteproc/ti_pru_rproc.txt      | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt b/Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
new file mode 100644
index 000000000000..0e80a8db46d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
@@ -0,0 +1,51 @@
+TI Programmable Realtime Unit (PRU)
+===================================
+
+Some TI Sitara SoCs contain a Programmable Realtime Unit subsystem with two
+processor cores that can be used for hard-realtime tasks.
+
+
+Required properties:
+--------------------
+The following are the mandatory properties:
+
+- compatible:		Should be one of the following,
+			    "ti,da850-pru-rproc" for AM18xx/OMAPL138 SoCs
+			    "ti,am3352-pru-rproc" for AM355x SoCs
+
+- reg:			Should contain the memory region for the PRUSS
+
+- interrupts: 		Should contain the interrupt number used to receive the
+			virtualqueue kick interrupts from the PRU (i.e.
+			PRU_EVTOUT0 and PRU_EVTOUT1)
+
+- interrupt-names	Should contain "pru0-vq", "pru1-vq"
+
+Optional properties:
+--------------------
+
+- power-domains:	A phandle to the power domain that powers the PRUSS
+
+- ti,hwmods:		Name of the hwmod associated to the PRUSS, which is
+			typically "pruss"
+
+Example:
+--------
+
+	// AM18xx
+	pru_rproc: cpu@30000 {
+		compatible = "ti,da850-pru-rproc";
+		reg = <0x30000 0x10000>;
+		interrupts = <3>, <4>;
+		interrupt-names = "pru0-vq", "pru1-vq";
+		power-domains = <&psc0 13>;
+	};
+
+	// AM335x
+	pru_rproc: cpu@4a300000 {
+		compatible = "ti,am3352-pru-rproc";
+		reg = <0x4a300000 0x80000>;
+		interrupts = <20>, <21>;
+		interrupt-names = "pru0-vq", "pru1-vq";
+		ti,hwmods = "pruss";
+	};
-- 
2.17.1

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

* [PATCH 5/8] remoteproc: new driver for TI PRU
  2018-06-23 21:08 (unknown), David Lechner
                   ` (3 preceding siblings ...)
  2018-06-23 21:08 ` [PATCH 4/8] dt-bindings: add bindings for TI PRU as remoteproc David Lechner
@ 2018-06-23 21:08 ` David Lechner
  2018-06-29 10:14   ` Roger Quadros
  2018-06-23 21:08 ` [PATCH 6/8] ARM: davinci_all_defconfig: enable PRU remoteproc module David Lechner
                   ` (3 subsequent siblings)
  8 siblings, 1 reply; 71+ messages in thread
From: David Lechner @ 2018-06-23 21:08 UTC (permalink / raw)
  To: linux-remoteproc, devicetree, linux-omap, linux-arm-kernel
  Cc: David Lechner, Ohad Ben-Cohen, Bjorn Andersson, Rob Herring,
	Mark Rutland, Benoît Cousson, Tony Lindgren, Sekhar Nori,
	Kevin Hilman, linux-kernel

This adds a new remoteproc driver for TI Programmable Realtime Units
(PRUs).

This has been tested working on AM1808 (LEGO MINDSTORMS EV3) using the
sample rpmsg client driver.

Signed-off-by: David Lechner <david@lechnology.com>
---
 MAINTAINERS                       |   5 +
 drivers/remoteproc/Kconfig        |   7 +
 drivers/remoteproc/Makefile       |   1 +
 drivers/remoteproc/ti_pru_rproc.c | 660 ++++++++++++++++++++++++++++++
 4 files changed, 673 insertions(+)
 create mode 100644 drivers/remoteproc/ti_pru_rproc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index edf3cf5ea691..06dea089d9ae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14288,6 +14288,11 @@ L:	netdev@vger.kernel.org
 S:	Maintained
 F:	drivers/net/ethernet/ti/netcp*
 
+TI PRU REMOTEPROC DRIVER
+R:	David Lechner <david@lechnology.com>
+F:	Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
+F:	drivers/remoteproc/ti_pru_rproc.c
+
 TI TAS571X FAMILY ASoC CODEC DRIVER
 M:	Kevin Cernekee <cernekee@chromium.org>
 L:	alsa-devel@alsa-project.org (moderated for non-subscribers)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index cd1c168fd188..ae6e725e1755 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -158,6 +158,13 @@ config ST_REMOTEPROC
 config ST_SLIM_REMOTEPROC
 	tristate
 
+config TI_PRU_REMOTEPROC
+	tristate "TI Programmable Realtime Unit"
+	depends on ARCH_DAVINCI_DA8XX || SOC_AM33XX
+	help
+	  Say y here to support TI Programmable Runtime Units (PRUs) via the
+	  remote processor framework.
+
 endif # REMOTEPROC
 
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 02627ede8d4a..451efee5c8d3 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -23,3 +23,4 @@ qcom_wcnss_pil-y			+= qcom_wcnss.o
 qcom_wcnss_pil-y			+= qcom_wcnss_iris.o
 obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
 obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
+obj-$(CONFIG_TI_PRU_REMOTEPROC)		+= ti_pru_rproc.o
diff --git a/drivers/remoteproc/ti_pru_rproc.c b/drivers/remoteproc/ti_pru_rproc.c
new file mode 100644
index 000000000000..cd8302c318c9
--- /dev/null
+++ b/drivers/remoteproc/ti_pru_rproc.c
@@ -0,0 +1,660 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 David Lechner <david@lechnology.com>
+ *
+ * Remoteproc driver for TI Programmable Realtime Unit
+ */
+
+#include <linux/bitops.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_data/ti-pruss.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/remoteproc.h>
+#include <linux/regmap.h>
+#include <linux/sizes.h>
+#include <linux/types.h>
+
+#include "remoteproc_internal.h"
+
+#define SZ_12K 0x3000
+
+/* control/status registers */
+#define TI_PRU_CS_CONTROL	0x0
+#define TI_PRU_CS_STATUS	0x4
+#define TI_PRU_CS_WAKEUP	0x8
+#define TI_PRU_CS_CYCLECNT	0xc
+
+/* control register bits */
+#define TI_PRU_CONTROL_PCRESETVAL	GENMASK(31, 16)
+#define TI_PRU_CONTROL_RUNSTATE		BIT(15)
+#define TI_PRU_CONTROL_SINGLESTEP	BIT(8)
+#define TI_PRU_CONTROL_COUNTENABLE	BIT(3)
+#define TI_PRU_CONTROL_SLEEPING		BIT(2)
+#define TI_PRU_CONTROL_ENABLE		BIT(1)
+#define TI_PRU_CONTROL_SOFTRESET	BIT(0)
+
+/* status bits */
+#define TI_PRU_STATUS_PCOUNTER		GENMASK(15, 0)
+
+/* interrupt controller registers */
+#define TI_PRU_INTC_GLBLEN		0x10
+#define TI_PRU_INTC_STATIDXSET		0x20
+#define TI_PRU_INTC_STATIDXCLR		0x24
+#define TI_PRU_INTC_ENIDXSET		0x28
+#define TI_PRU_INTC_HSTINTENIDXSET	0x34
+#define TI_PRU_INTC_CHANMAP0		0x400
+#define TI_PRU_INTC_POLARITY0		0xd00
+#define TI_PRU_INTC_TYPE0		0xd80
+#define TI_PRU_INTC_HOSTMAP0		0x800
+
+/* config registers */
+#define TI_PRU_CFG_SYSCFG		0x4
+
+/* syscfg bits */
+#define TI_PRU_SYSCFG_SUB_MWAIT			BIT(5)
+#define TI_PRU_SYSCFG_STANDBY_INIT		BIT(4)
+#define TI_PRU_SYSCFG_STANDBY_MODE_MASK		GENMASK(3, 2)
+#define TI_PRU_SYSCFG_STANDBY_MODE_SMART	(2 << 2)
+#define TI_PRU_SYSCFG_IDLE_MODE_MASK		GENMASK(1, 0)
+#define TI_PRU_SYSCFG_IDLE_MODE_SMART		(2 << 0)
+
+enum ti_pru {
+	TI_PRU0,
+	TI_PRU1,
+	NUM_TI_PRU
+};
+
+enum ti_pru_type {
+	TI_PRU_TYPE_AM18XX,
+	TI_PRU_TYPE_AM335X,
+	NUM_TI_PRU_TYPE
+};
+
+enum ti_pru_evtout {
+	TI_PRU_EVTOUT0,
+	TI_PRU_EVTOUT1,
+	TI_PRU_EVTOUT2,
+	TI_PRU_EVTOUT3,
+	TI_PRU_EVTOUT4,
+	TI_PRU_EVTOUT5,
+	TI_PRU_EVTOUT6,
+	TI_PRU_EVTOUT7,
+	NUM_TI_PRU_EVTOUT
+};
+
+struct ti_pru_mem_region {
+	off_t offset;
+	size_t size;
+};
+
+/**
+ * ti_pru_shared_info - common init info for the PRUSS
+ * @ram: shared RAM, if present
+ * @intc: interrupt controller
+ * @cfg: configuration registers, if present
+ */
+struct ti_pru_shared_info {
+	struct ti_pru_mem_region ram;
+	struct ti_pru_mem_region intc;
+	struct ti_pru_mem_region cfg;
+};
+
+/**
+ * ti_pru_info - init info each individual PRU
+ * @ram: PRU RAM
+ * @ctrl: PRU control/status registers
+ * @dbg: PRU dbg registers
+ * @inst: instruction RAM
+ * @vq_arm_to_pru_event: The index of the PRU system event interrupt used
+ *                       used by the ARM for kicking the PRU
+ * @vq_pru_to_arm_event: The index of the PRU system event interrupt used
+ *                       used by the PRU for kicking the ARM
+ */
+struct ti_pru_info {
+	struct ti_pru_mem_region ram;
+	struct ti_pru_mem_region ctrl;
+	struct ti_pru_mem_region dbg;
+	struct ti_pru_mem_region inst;
+	int vq_arm_to_pru_event;
+	int vq_pru_to_arm_event;
+};
+
+struct ti_pru_device_info {
+	struct ti_pru_shared_info shared;
+	struct ti_pru_info pru[NUM_TI_PRU];
+};
+
+static const struct ti_pru_device_info ti_pru_devices[NUM_TI_PRU_TYPE] = {
+	[TI_PRU_TYPE_AM18XX] = {
+		.shared = {
+			.intc	= { .offset = 0x4000,	.size = SZ_12K,	},
+		},
+		.pru[TI_PRU0] = {
+			.ram	= { .offset = 0x0000,	.size = SZ_512,	},
+			.ctrl	= { .offset = 0x7000,	.size = SZ_1K,	},
+			.dbg	= { .offset = 0x7400,	.size = SZ_1K,	},
+			.inst	= { .offset = 0x8000,	.size = SZ_4K,	},
+			.vq_arm_to_pru_event = 32,
+			.vq_pru_to_arm_event = 33,
+		},
+		.pru[TI_PRU1] = {
+			.ram	= { .offset = 0x2000,	.size = SZ_512,	},
+			.ctrl	= { .offset = 0x7800,	.size = SZ_1K,	},
+			.dbg	= { .offset = 0x7c00,	.size = SZ_1K,	},
+			.inst	= { .offset = 0xc000,	.size = SZ_4K,	},
+			.vq_arm_to_pru_event = 34,
+			.vq_pru_to_arm_event = 35,
+		},
+	},
+	[TI_PRU_TYPE_AM335X] = {
+		.shared = {
+			.ram	= { .offset = 0x10000,	.size = SZ_12K,	},
+			.intc	= { .offset = 0x20000,	.size = SZ_8K,	},
+			.cfg	= { .offset = 0x26000,	.size = SZ_8K,	},
+		},
+		.pru[TI_PRU0] = {
+			.ram	= { .offset = 0x00000,	.size = SZ_8K,	},
+			.ctrl	= { .offset = 0x22000,	.size = SZ_1K,	},
+			.dbg	= { .offset = 0x22400,	.size = SZ_1K,	},
+			.inst	= { .offset = 0x34000,	.size = SZ_8K,	},
+			.vq_arm_to_pru_event = 16,
+			.vq_pru_to_arm_event = 17,
+		},
+		.pru[TI_PRU1] = {
+			.ram	= { .offset = 0x02000,	.size = SZ_8K,	},
+			.ctrl	= { .offset = 0x24000,	.size = SZ_1K,	},
+			.dbg	= { .offset = 0x24400,	.size = SZ_1K,	},
+			.inst	= { .offset = 0x38000,	.size = SZ_8K,	},
+			.vq_arm_to_pru_event = 18,
+			.vq_pru_to_arm_event = 19,
+		},
+	},
+};
+
+/**
+ * ti_pru_shared_data - private platform driver data
+ * @info: init info common to both PRU cores
+ * @dev: the platform device
+ * @base: the mapped memory region of the PRUSS
+ * @intc: regmap of the interrupt controller
+ * @cfg: regmap of configuration registers
+ * @pru: per-PRU core data
+ */
+struct ti_pru_shared_data {
+	const struct ti_pru_shared_info *info;
+	struct device *dev;
+	void __iomem *base;
+	struct regmap *intc;
+	struct regmap *cfg;
+	struct rproc *pru[NUM_TI_PRU];
+};
+
+/**
+ * ti_pru_data - private data for each PRU core
+ * @info: static init info
+ * @shared: pointer to the shared data struct
+ * @ctrl: regmap of the PRU control/status register
+ * @vq_irq: interrupt used for rpmsg
+ */
+struct ti_pru_data {
+	const struct ti_pru_info *info;
+	struct ti_pru_shared_data *shared;
+	struct regmap *ctrl;
+	int vq_irq;
+};
+
+static int ti_pru_rproc_start(struct rproc *rproc)
+{
+	struct ti_pru_data *pru = rproc->priv;
+	u32 val;
+
+	val = (rproc->bootaddr >> 2) << (ffs(TI_PRU_CONTROL_PCRESETVAL) - 1);
+	val |= TI_PRU_CONTROL_ENABLE;
+
+	return regmap_write(pru->ctrl, TI_PRU_CS_CONTROL, val);
+}
+
+static int ti_pru_rproc_stop(struct rproc *rproc)
+{
+	struct ti_pru_data *pru = rproc->priv;
+	u32 mask;
+
+	mask = TI_PRU_CONTROL_ENABLE;
+
+	return regmap_write_bits(pru->ctrl, TI_PRU_CS_CONTROL, mask, 0);
+}
+
+static void ti_pru_rproc_kick(struct rproc *rproc, int vqid)
+{
+	struct ti_pru_data *pru = rproc->priv;
+	struct ti_pru_shared_data *shared = pru->shared;
+	u32 val;
+
+	val = pru->info->vq_arm_to_pru_event;
+
+	regmap_write(shared->intc, TI_PRU_INTC_STATIDXSET, val);
+}
+
+static void *ti_pru_rproc_da_to_va(struct rproc *rproc, u64 da, int len, int map)
+{
+	struct ti_pru_data *pru = rproc->priv;
+	struct ti_pru_shared_data *shared = pru->shared;
+
+	if (map == 0) {
+		if (da + len > pru->info->inst.size)
+			return ERR_PTR(-EINVAL);
+
+		return shared->base + pru->info->inst.offset + da;
+	}
+
+	if (map == 1) {
+		if (da + len > pru->info->ram.size)
+			return ERR_PTR(-EINVAL);
+
+		return shared->base + pru->info->ram.offset + da;
+	}
+
+	return ERR_PTR(-EINVAL);
+}
+
+static const struct rproc_ops ti_pru_rproc_ops = {
+	.start = ti_pru_rproc_start,
+	.stop = ti_pru_rproc_stop,
+	.kick = ti_pru_rproc_kick,
+	.da_to_va = ti_pru_rproc_da_to_va,
+};
+
+static struct regmap_config ti_pru_ctrl_regmap_config = {
+	.reg_bits = 32,
+	.val_bits = 32,
+	.reg_stride = 4,
+	.max_register = 0x2c,
+};
+
+static struct regmap_config ti_pru_intc_regmap_config = {
+	.reg_bits = 32,
+	.val_bits = 32,
+	.reg_stride = 4,
+	.max_register = 0x1500,
+};
+
+static struct regmap_config ti_pru_cfg_regmap_config = {
+	.reg_bits = 32,
+	.val_bits = 32,
+	.reg_stride = 4,
+	.max_register = 0x40,
+};
+
+static const struct of_device_id ti_pru_rproc_of_match[] = {
+	{
+		.compatible = "ti,da850-pru-rproc",
+		.data = &ti_pru_devices[TI_PRU_TYPE_AM18XX]
+	},
+	{
+		.compatible = "ti,am3352-pru-rproc",
+		.data = &ti_pru_devices[TI_PRU_TYPE_AM335X]
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, ti_pru_rproc_of_match);
+
+static irqreturn_t ti_pru_handle_vq_irq(int irq, void *p)
+{
+	struct rproc *rproc = p;
+	struct ti_pru_data *pru = rproc->priv;
+
+	regmap_write(pru->shared->intc, TI_PRU_INTC_STATIDXCLR,
+		     pru->info->vq_pru_to_arm_event);
+
+	return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t ti_pru_vq_irq_thread(int irq, void *p)
+{
+	struct rproc *rproc = p;
+
+	rproc_vq_interrupt(rproc, 0);
+	rproc_vq_interrupt(rproc, 1);
+
+	return IRQ_HANDLED;
+}
+
+static void ti_pru_free_rproc(void *data)
+{
+	struct rproc *rproc = data;
+
+	rproc_free(rproc);
+}
+
+static struct rproc *ti_pru_init_one_rproc(struct ti_pru_shared_data *shared,
+					   const struct ti_pru_info *info,
+					   enum ti_pru id)
+{
+	struct device *dev = shared->dev;
+	struct platform_device *pdev = to_platform_device(dev);
+	const char *name;
+	char irq_name[16];
+	struct rproc *rproc;
+	struct ti_pru_data *pru;
+	int err;
+
+	name = devm_kasprintf(dev, GFP_KERNEL, "pru%u", id);
+	if (!name)
+		return ERR_PTR(-ENOMEM);
+
+	rproc = rproc_alloc(dev, name, &ti_pru_rproc_ops, NULL, sizeof(*pru));
+	if (!rproc)
+		return ERR_PTR(-ENOMEM);
+
+	devm_add_action(dev, ti_pru_free_rproc, rproc);
+
+	/* don't auto-boot for now - bad firmware can lock up the system */
+	rproc->auto_boot = false;
+
+	pru = rproc->priv;
+	pru->info = info;
+	pru->shared = shared;
+
+	snprintf(irq_name, 16, "%s-vq", name);
+
+	pru->vq_irq = platform_get_irq_byname(pdev, irq_name);
+	if (pru->vq_irq < 0) {
+		dev_err(&rproc->dev, "failed to get vq IRQ\n");
+		return ERR_PTR(pru->vq_irq);
+	}
+
+	err = devm_request_threaded_irq(&rproc->dev, pru->vq_irq,
+					ti_pru_handle_vq_irq,
+					ti_pru_vq_irq_thread, 0, name, rproc);
+	if (err < 0) {
+		dev_err(&rproc->dev, "failed to request vq IRQ\n");
+		return ERR_PTR(err);
+	}
+
+	pru->ctrl = devm_regmap_init_mmio(&rproc->dev,
+					  shared->base + info->ctrl.offset,
+					  &ti_pru_ctrl_regmap_config);
+	if (IS_ERR(pru->ctrl)) {
+		dev_err(&rproc->dev, "failed to init ctrl regmap\n");
+		return ERR_CAST(pru->ctrl);
+	}
+
+	return rproc;
+}
+
+/**
+ * ti_pru_init_intc_polarity - configure polarity interrupt event
+ * @intc: the interrtup controller regmap
+ * @event: the source event
+ */
+static void ti_pru_init_intc_polarity(struct regmap *intc, int event)
+{
+	int offset, shift, mask;
+
+	/* 32 events per register */
+	offset = event / 32 * 4;
+	shift = event % 32;
+	mask = 1 << shift;
+
+	/* polarity is always high (1) */
+	regmap_write_bits(intc, TI_PRU_INTC_POLARITY0 + offset, mask, ~0);
+}
+
+/**
+ * ti_pru_init_intc_type - configure type of interrupt event
+ * @intc: the interrtup controller regmap
+ * @event: the source event
+ */
+static void ti_pru_init_intc_type(struct regmap *intc, int event)
+{
+	int offset, shift, mask;
+
+	/* 32 events per register */
+	offset = event / 32 * 4;
+	shift = event % 32;
+	mask = 1 << shift;
+
+	/* type is always pulse (0) */
+	regmap_write_bits(intc, TI_PRU_INTC_TYPE0 + offset, mask, 0);
+}
+
+/**
+ * ti_pru_init_intc_channel_map - configure interrupt event to channel mapping
+ * @intc: the interrtup controller regmap
+ * @event: the source event
+ * @ch: the channel to be assigned to the event
+ */
+static void ti_pru_init_intc_channel_map(struct regmap *intc, int event, int ch)
+{
+	int offset, shift, mask, val;
+
+	/* 4 channels per 32-bit register */
+	offset = event / 4 * 4;
+	shift = event % 4 * 8;
+	mask = 0xff << shift;
+	val = ch << shift;
+
+	regmap_write_bits(intc, TI_PRU_INTC_CHANMAP0 + offset, mask, val);
+}
+
+/**
+ * ti_pru_init_intc_host_map - configure interrupt channel to host mapping
+ * @intc: the interrtup controller regmap
+ * @ch: the source channel
+ * @host: the host interrupt to be assigned to the channel
+ */
+static void ti_pru_init_intc_host_map(struct regmap *intc, int ch, int host)
+{
+	int offset, shift, mask, val;
+
+	/* 4 hosts per 32-bit register */
+	offset = ch / 4 * 4;
+	shift = ch % 4 * 8;
+	mask = 0xff << shift;
+	val = host << shift;
+
+	regmap_write_bits(intc, TI_PRU_INTC_HOSTMAP0 + offset, mask, val);
+}
+
+static void ti_pru_init_intc(struct regmap *intc,
+			     const struct ti_pru_device_info *info)
+{
+	int arm_to_pru0 = info->pru[TI_PRU0].vq_arm_to_pru_event;
+	int arm_to_pru1 = info->pru[TI_PRU1].vq_arm_to_pru_event;
+	int pru0_to_arm = info->pru[TI_PRU0].vq_pru_to_arm_event;
+	int pru1_to_arm = info->pru[TI_PRU1].vq_pru_to_arm_event;
+
+	/* set polarity of system events */
+	ti_pru_init_intc_polarity(intc, arm_to_pru0);
+	ti_pru_init_intc_polarity(intc, arm_to_pru1);
+	ti_pru_init_intc_polarity(intc, pru0_to_arm);
+	ti_pru_init_intc_polarity(intc, pru1_to_arm);
+
+	/* set type of system events */
+	ti_pru_init_intc_type(intc, arm_to_pru0);
+	ti_pru_init_intc_type(intc, arm_to_pru1);
+	ti_pru_init_intc_type(intc, pru0_to_arm);
+	ti_pru_init_intc_type(intc, pru1_to_arm);
+
+	/* map system events to channels */
+	ti_pru_init_intc_channel_map(intc, arm_to_pru0, 0);
+	ti_pru_init_intc_channel_map(intc, arm_to_pru1, 1);
+	ti_pru_init_intc_channel_map(intc, pru0_to_arm, 2);
+	ti_pru_init_intc_channel_map(intc, pru1_to_arm, 3);
+
+	/* map channels to host interrupts */
+	ti_pru_init_intc_host_map(intc, 0, 0); /* ARM to PRU0 */
+	ti_pru_init_intc_host_map(intc, 1, 1); /* ARM to PRU1 */
+	ti_pru_init_intc_host_map(intc, 2, 2); /* PRU0 to ARM */
+	ti_pru_init_intc_host_map(intc, 3, 3); /* PRU1 to ARM */
+
+	/* clear system interrupts */
+	regmap_write(intc, TI_PRU_INTC_STATIDXCLR, arm_to_pru0);
+	regmap_write(intc, TI_PRU_INTC_STATIDXCLR, arm_to_pru1);
+	regmap_write(intc, TI_PRU_INTC_STATIDXCLR, pru0_to_arm);
+	regmap_write(intc, TI_PRU_INTC_STATIDXCLR, pru1_to_arm);
+
+	/* enable host interrupts for kicking */
+	regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 0); /* ARM to PRU0 */
+	regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 1); /* ARM to PRU1 */
+	regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 2); /* PRU0 to ARM */
+	regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 3); /* PRU1 to ARM */
+
+	/* enable system events for kicking */
+	regmap_write(intc, TI_PRU_INTC_ENIDXSET, arm_to_pru0);
+	regmap_write(intc, TI_PRU_INTC_ENIDXSET, arm_to_pru1);
+	regmap_write(intc, TI_PRU_INTC_ENIDXSET, pru0_to_arm);
+	regmap_write(intc, TI_PRU_INTC_ENIDXSET, pru1_to_arm);
+
+	/* enable all interrupts */
+	regmap_write_bits(intc, TI_PRU_INTC_GLBLEN, 1, 1);
+}
+
+static int ti_pru_rproc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct ti_pruss_platform_data *pdata = dev_get_platdata(dev);
+	const struct of_device_id *of_id;
+	const struct ti_pru_device_info *info;
+	struct ti_pru_shared_data *shared;
+	struct resource *res;
+	int err;
+
+	of_id = of_match_device(ti_pru_rproc_of_match, dev);
+	if (!of_id || !of_id->data)
+		return -EINVAL;
+
+	info = of_id->data;
+
+	shared = devm_kzalloc(dev, sizeof(*shared), GFP_KERNEL);
+
+	platform_set_drvdata(pdev, shared);
+
+	shared->info = &info->shared;
+	shared->dev = dev;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	shared->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(shared->base)) {
+		dev_err(dev, "failed to ioremap resource\n");
+		return PTR_ERR(shared->base);
+	}
+
+	shared->intc = devm_regmap_init_mmio(dev,
+				shared->base + shared->info->intc.offset,
+				&ti_pru_intc_regmap_config);
+	if (IS_ERR(shared->intc)) {
+		dev_err(dev, "failed to init intc regmap\n");
+		return PTR_ERR(shared->intc);
+	}
+
+	if (shared->info->cfg.size) {
+		shared->cfg = devm_regmap_init_mmio(dev,
+			shared->base + shared->info->cfg.offset,
+			&ti_pru_cfg_regmap_config);
+		if (IS_ERR(shared->cfg)) {
+			dev_err(dev, "failed to init cfg regmap\n");
+			return PTR_ERR(shared->cfg);
+		}
+	}
+
+	shared->pru[TI_PRU0] = ti_pru_init_one_rproc(shared, &info->pru[TI_PRU0],
+						     TI_PRU0);
+	if (IS_ERR(shared->pru[TI_PRU0]))
+		return PTR_ERR(shared->pru[TI_PRU0]);
+
+	shared->pru[TI_PRU1] = ti_pru_init_one_rproc(shared, &info->pru[TI_PRU1],
+						     TI_PRU1);
+	if (IS_ERR(shared->pru[TI_PRU1]))
+		return PTR_ERR(shared->pru[TI_PRU1]);
+
+	pm_runtime_enable(dev);
+
+	err = pm_runtime_get_sync(dev);
+	if (err < 0)
+		goto err_pm_runtime_disable;
+
+	if (pdata) {
+		err = pdata->deassert_reset(pdev, pdata->reset_name);
+		if (err < 0) {
+			dev_err(dev, "Failed to reset pruss\n");
+			goto err_pm_runtime_put;
+		}
+	}
+
+	if (shared->cfg) {
+		int mask, val;
+
+		mask = TI_PRU_SYSCFG_IDLE_MODE_MASK | TI_PRU_SYSCFG_STANDBY_MODE_MASK;
+		val = TI_PRU_SYSCFG_IDLE_MODE_SMART | TI_PRU_SYSCFG_STANDBY_MODE_SMART;
+		regmap_write_bits(shared->cfg, TI_PRU_CFG_SYSCFG, mask, val);
+
+		mask = TI_PRU_SYSCFG_STANDBY_INIT;
+		val = 0;
+		regmap_write_bits(shared->cfg, TI_PRU_CFG_SYSCFG, mask, val);
+
+		err = regmap_read_poll_timeout(shared->cfg, TI_PRU_CFG_SYSCFG,
+				val, !(val & TI_PRU_SYSCFG_SUB_MWAIT), 5, 50);
+		if (err < 0) {
+			dev_err(dev, "timeout while enabling pruss\n");
+			goto err_pm_runtime_put;
+		}
+	}
+
+	ti_pru_init_intc(shared->intc, info);
+
+	err = rproc_add(shared->pru[TI_PRU0]);
+	if (err < 0)
+		goto err_assert_reset;
+
+	err = rproc_add(shared->pru[TI_PRU1]);
+	if (err < 0)
+		goto err_del_pru0;
+
+	return 0;
+
+err_del_pru0:
+	rproc_del(shared->pru[TI_PRU0]);
+err_assert_reset:
+	if (pdata)
+		pdata->assert_reset(pdev, pdata->reset_name);
+err_pm_runtime_put:
+	pm_runtime_put(dev);
+err_pm_runtime_disable:
+	pm_runtime_disable(dev);
+
+	return err;
+}
+
+static int ti_pru_rproc_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct ti_pruss_platform_data *pdata = dev_get_platdata(dev);
+	struct ti_pru_shared_data *shared = platform_get_drvdata(pdev);
+
+	rproc_del(shared->pru[TI_PRU1]);
+	rproc_del(shared->pru[TI_PRU0]);
+	if (pdata)
+		pdata->assert_reset(pdev, pdata->reset_name);
+	pm_runtime_put(dev);
+	pm_runtime_disable(dev);
+
+	return 0;
+}
+
+static struct platform_driver ti_pru_rproc_driver = {
+	.probe	= ti_pru_rproc_probe,
+	.remove	= ti_pru_rproc_remove,
+	.driver	= {
+		.name = "ti-pru-rproc",
+		.of_match_table = ti_pru_rproc_of_match,
+	},
+};
+module_platform_driver(ti_pru_rproc_driver);
+
+MODULE_AUTHOR("David Lechner <david@lechnology.com>");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Remoteproc driver for TI PRU");
-- 
2.17.1

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

* [PATCH 6/8] ARM: davinci_all_defconfig: enable PRU remoteproc module
  2018-06-23 21:08 (unknown), David Lechner
                   ` (4 preceding siblings ...)
  2018-06-23 21:08 ` [PATCH 5/8] remoteproc: new driver for TI PRU David Lechner
@ 2018-06-23 21:08 ` David Lechner
  2018-06-23 21:08 ` [PATCH 7/8] ARM: dts: da850: add node for PRUSS David Lechner
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 71+ messages in thread
From: David Lechner @ 2018-06-23 21:08 UTC (permalink / raw)
  To: linux-remoteproc, devicetree, linux-omap, linux-arm-kernel
  Cc: David Lechner, Ohad Ben-Cohen, Bjorn Andersson, Rob Herring,
	Mark Rutland, Benoît Cousson, Tony Lindgren, Sekhar Nori,
	Kevin Hilman, linux-kernel

This enabled the remoteproc module for the PRU on DA8xx-type devices.

Signed-off-by: David Lechner <david@lechnology.com>
---
 arch/arm/configs/davinci_all_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index a1b6e106b867..1bcc7c6a03ee 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -214,6 +214,8 @@ CONFIG_DMADEVICES=y
 CONFIG_TI_EDMA=y
 CONFIG_REMOTEPROC=m
 CONFIG_DA8XX_REMOTEPROC=m
+CONFIG_TI_PRU_REMOTEPROC=m
+CONFIG_RPMSG_VIRTIO=m
 CONFIG_MEMORY=y
 CONFIG_TI_AEMIF=m
 CONFIG_DA8XX_DDRCTL=y
-- 
2.17.1

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

* [PATCH 7/8] ARM: dts: da850: add node for PRUSS
  2018-06-23 21:08 (unknown), David Lechner
                   ` (5 preceding siblings ...)
  2018-06-23 21:08 ` [PATCH 6/8] ARM: davinci_all_defconfig: enable PRU remoteproc module David Lechner
@ 2018-06-23 21:08 ` David Lechner
  2018-06-23 21:08 ` [PATCH 8/8] ARM: dts: am33xx: add node for PRU remoteproc David Lechner
  2018-06-29  9:58 ` New remoteproc driver for TI PRU Roger Quadros
  8 siblings, 0 replies; 71+ messages in thread
From: David Lechner @ 2018-06-23 21:08 UTC (permalink / raw)
  To: linux-remoteproc, devicetree, linux-omap, linux-arm-kernel
  Cc: David Lechner, Ohad Ben-Cohen, Bjorn Andersson, Rob Herring,
	Mark Rutland, Benoît Cousson, Tony Lindgren, Sekhar Nori,
	Kevin Hilman, linux-kernel

This adds a new remoteproc node to the da850 device tree for the PRUSS.

Signed-off-by: David Lechner <david@lechnology.com>
---

Note: this requires the recent common-clk patches for power-domains

 arch/arm/boot/dts/da850.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 3fc8b8fd816e..8b052e96fb53 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -540,6 +540,14 @@
 			clocks = <&pll0_auxclk>;
 			status = "disabled";
 		};
+		pru_rproc: cpu@30000 {
+			compatible = "ti,da850-pru-rproc";
+			reg = <0x30000 0x10000>;
+			interrupts = <3>, <4>;
+			interrupt-names = "pru0-vq", "pru1-vq";
+			power-domains = <&psc0 13>;
+			status = "disabled";
+		};
 		mmc0: mmc@40000 {
 			compatible = "ti,da830-mmc";
 			reg = <0x40000 0x1000>;
-- 
2.17.1

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

* [PATCH 8/8] ARM: dts: am33xx: add node for PRU remoteproc
  2018-06-23 21:08 (unknown), David Lechner
                   ` (6 preceding siblings ...)
  2018-06-23 21:08 ` [PATCH 7/8] ARM: dts: da850: add node for PRUSS David Lechner
@ 2018-06-23 21:08 ` David Lechner
  2018-06-29  9:58 ` New remoteproc driver for TI PRU Roger Quadros
  8 siblings, 0 replies; 71+ messages in thread
From: David Lechner @ 2018-06-23 21:08 UTC (permalink / raw)
  To: linux-remoteproc, devicetree, linux-omap, linux-arm-kernel
  Cc: David Lechner, Ohad Ben-Cohen, Bjorn Andersson, Rob Herring,
	Mark Rutland, Benoît Cousson, Tony Lindgren, Sekhar Nori,
	Kevin Hilman, linux-kernel

This adds a new node to am33xx.dtsi for binding the PRUSS as a
remoteproc device.

Signed-off-by: David Lechner <david@lechnology.com>
---
 arch/arm/boot/dts/am33xx.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9cd62bc2ca35..1e7837af4689 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -924,6 +924,15 @@
 			};
 		};
 
+		pru_rproc: cpu@4a300000 {
+			compatible = "ti,am3352-pru-rproc";
+			reg = <0x4a300000 0x80000>;
+			interrupts = <20>, <21>;
+			interrupt-names = "pru0-vq", "pru1-vq";
+			ti,hwmods = "pruss";
+			status = "disabled";
+		};
+
 		elm: elm@48080000 {
 			compatible = "ti,am3352-elm";
 			reg = <0x48080000 0x2000>;
-- 
2.17.1

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

* New remoteproc driver for TI PRU
  2018-06-23 21:08 (unknown), David Lechner
                   ` (7 preceding siblings ...)
  2018-06-23 21:08 ` [PATCH 8/8] ARM: dts: am33xx: add node for PRU remoteproc David Lechner
@ 2018-06-29  9:58 ` Roger Quadros
  2018-06-29 17:44   ` David Lechner
  8 siblings, 1 reply; 71+ messages in thread
From: Roger Quadros @ 2018-06-29  9:58 UTC (permalink / raw)
  To: David Lechner, linux-remoteproc, devicetree, linux-omap,
	linux-arm-kernel
  Cc: Ohad Ben-Cohen, Bjorn Andersson, Rob Herring, Mark Rutland,
	Benoît Cousson, Tony Lindgren, Sekhar Nori, Kevin Hilman,
	linux-kernel, Anna, Suman, Tero Kristo

+Suman & Tero

Hi David,

On 24/06/18 00:08, David Lechner wrote:
> 
> Date: Sat, 23 Jun 2018 15:43:59 -0500
> Subject: [PATCH 0/8] New remoteproc driver for TI PRU
> 
> This series adds a new remoteproc driver for the TI Programmable Runtime Unit
> (PRU) that is present in some TI Sitara processors. This code has been tested
> working on AM1808 (LEGO MINDSTORMS EV3) and AM3358 (BeagleBone Green).

This is great. We have been working on something similar and I think it would
be great if we can collaborate to get all our needs addressed.

Our primary requirement is that it should be possible for a user (e.g. kernel driver) to
- request a specific PRU core load a specific firmware blob and boot/stop the PRU.
- configure INTC interrupt mapping based on either resource table or DT
- use request_irq to request and use an interrupt.
- request access to DRAM/SRAM
- configure gpimode/miirt/xfr (CFG space)

The work is published here

PRUSS platform bus driver (platform resets & quirks)
https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/drivers/remoteproc/pruss_soc_bus.c

PRUSS core driver (resource management e.g. SRAM/DRAM for clients)
https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/drivers/remoteproc/pruss.c

PRU Rproc driver (PRU remoteproc driver)
https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/drivers/remoteproc/pru_rproc.c

INTC driver (irqchip support for INTC)
https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/drivers/remoteproc/pruss_intc.c

Please have a look at it. I think it addresses most if not all of what your series addresses.
Maybe Suman and you can decide which driver to start with and get the missing pieces addressed.

An example of a client driver
https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/drivers/net/ethernet/ti/prueth.c
and DT node for that
https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/arch/arm/boot/dts/am335x-icev2-prueth.dts#line25

> 
> There are a couple of quirks that had to be worked around in order to get this
> working. The PRU units have multiple memory maps. Notably, both the instruction
> RAM and data RAM are at address 0x0. This caused the da_to_va callback to not
> work because the same address could refer to two different locations. To work
> around this, the first two patches add a "map" parameter to the da_to_va
> callbacks so that we have an extra bit of information to make this distinction.
> 
> Also, on AM38xx we have to use pdata for accessing a reset since there is not
> a reset controller. There are several other devices doing this, so the seems
> the best way for now.
> 
> For anyone else who would like to test, I used the rpmsg-client-sample driver.
> Just enable it in your kernel config. Then grab the appropriate firmware[1]
> and put in in /lib/firmware/. Use sysfs to start and stop the PRU:
> 
>         echo start > /sys/class/remoteproc<n>/state
>         echo stop > /sys/class/remoteproc<n>/state
> 
> [1]: firmware downloads:
> 
> AM18XX: https://github.com/ev3dev/ev3dev-pru-firmware/releases/download/mainline-kernel-testing/AM18xx-PRU-rpmsg-client-sample.zip
> AM335X: https://github.com/ev3dev/ev3dev-pru-firmware/releases/download/mainline-kernel-testing/AM335x-PRU-rpmsg-client-sample.zip
> 
> David Lechner (8):
>   remoteproc: add map parameter to da_to_va
>   remoteproc: add page lookup for TI PRU to ELF loader
>   ARM: OMAP2+: add pdata quirks for PRUSS reset
>   dt-bindings: add bindings for TI PRU as remoteproc
>   remoteproc: new driver for TI PRU
>   ARM: davinci_all_defconfig: enable PRU remoteproc module
>   ARM: dts: da850: add node for PRUSS
>   ARM: dts: am33xx: add node for PRU remoteproc
> 
>  .../bindings/remoteproc/ti_pru_rproc.txt      |  51 ++
>  MAINTAINERS                                   |   5 +
>  arch/arm/boot/dts/am33xx.dtsi                 |   9 +
>  arch/arm/boot/dts/da850.dtsi                  |   8 +
>  arch/arm/configs/davinci_all_defconfig        |   2 +
>  arch/arm/mach-omap2/pdata-quirks.c            |   9 +
>  drivers/remoteproc/Kconfig                    |   7 +
>  drivers/remoteproc/Makefile                   |   1 +
>  drivers/remoteproc/imx_rproc.c                |   2 +-
>  drivers/remoteproc/keystone_remoteproc.c      |   3 +-
>  drivers/remoteproc/qcom_adsp_pil.c            |   2 +-
>  drivers/remoteproc/qcom_q6v5_pil.c            |   2 +-
>  drivers/remoteproc/qcom_wcnss.c               |   2 +-
>  drivers/remoteproc/remoteproc_core.c          |  10 +-
>  drivers/remoteproc/remoteproc_elf_loader.c    | 117 +++-
>  drivers/remoteproc/remoteproc_internal.h      |   2 +-
>  drivers/remoteproc/st_slim_rproc.c            |   2 +-
>  drivers/remoteproc/ti_pru_rproc.c             | 660 ++++++++++++++++++
>  drivers/remoteproc/wkup_m3_rproc.c            |   3 +-
>  include/linux/platform_data/ti-pruss.h        |  18 +
>  include/linux/remoteproc.h                    |   2 +-
>  include/uapi/linux/elf-em.h                   |   1 +
>  22 files changed, 899 insertions(+), 19 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
>  create mode 100644 drivers/remoteproc/ti_pru_rproc.c
>  create mode 100644 include/linux/platform_data/ti-pruss.h
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

* Re: [PATCH 5/8] remoteproc: new driver for TI PRU
  2018-06-23 21:08 ` [PATCH 5/8] remoteproc: new driver for TI PRU David Lechner
@ 2018-06-29 10:14   ` Roger Quadros
  2018-06-30 19:02     ` Derald Woods
  0 siblings, 1 reply; 71+ messages in thread
From: Roger Quadros @ 2018-06-29 10:14 UTC (permalink / raw)
  To: David Lechner, linux-remoteproc, devicetree, linux-omap,
	linux-arm-kernel
  Cc: Ohad Ben-Cohen, Bjorn Andersson, Rob Herring, Mark Rutland,
	Benoît Cousson, Tony Lindgren, Sekhar Nori, Kevin Hilman,
	linux-kernel, Anna, Suman, Tero Kristo



On 24/06/18 00:08, David Lechner wrote:
> This adds a new remoteproc driver for TI Programmable Realtime Units
> (PRUs).
> 
> This has been tested working on AM1808 (LEGO MINDSTORMS EV3) using the
> sample rpmsg client driver.
> 
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>  MAINTAINERS                       |   5 +
>  drivers/remoteproc/Kconfig        |   7 +
>  drivers/remoteproc/Makefile       |   1 +
>  drivers/remoteproc/ti_pru_rproc.c | 660 ++++++++++++++++++++++++++++++
>  4 files changed, 673 insertions(+)
>  create mode 100644 drivers/remoteproc/ti_pru_rproc.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index edf3cf5ea691..06dea089d9ae 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14288,6 +14288,11 @@ L:	netdev@vger.kernel.org
>  S:	Maintained
>  F:	drivers/net/ethernet/ti/netcp*
>  
> +TI PRU REMOTEPROC DRIVER
> +R:	David Lechner <david@lechnology.com>
> +F:	Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
> +F:	drivers/remoteproc/ti_pru_rproc.c
> +
>  TI TAS571X FAMILY ASoC CODEC DRIVER
>  M:	Kevin Cernekee <cernekee@chromium.org>
>  L:	alsa-devel@alsa-project.org (moderated for non-subscribers)
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index cd1c168fd188..ae6e725e1755 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -158,6 +158,13 @@ config ST_REMOTEPROC
>  config ST_SLIM_REMOTEPROC
>  	tristate
>  
> +config TI_PRU_REMOTEPROC
> +	tristate "TI Programmable Realtime Unit"
> +	depends on ARCH_DAVINCI_DA8XX || SOC_AM33XX
> +	help
> +	  Say y here to support TI Programmable Runtime Units (PRUs) via the
> +	  remote processor framework.
> +
>  endif # REMOTEPROC
>  
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 02627ede8d4a..451efee5c8d3 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -23,3 +23,4 @@ qcom_wcnss_pil-y			+= qcom_wcnss.o
>  qcom_wcnss_pil-y			+= qcom_wcnss_iris.o
>  obj-$(CONFIG_ST_REMOTEPROC)		+= st_remoteproc.o
>  obj-$(CONFIG_ST_SLIM_REMOTEPROC)	+= st_slim_rproc.o
> +obj-$(CONFIG_TI_PRU_REMOTEPROC)		+= ti_pru_rproc.o
> diff --git a/drivers/remoteproc/ti_pru_rproc.c b/drivers/remoteproc/ti_pru_rproc.c
> new file mode 100644
> index 000000000000..cd8302c318c9
> --- /dev/null
> +++ b/drivers/remoteproc/ti_pru_rproc.c
> @@ -0,0 +1,660 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 David Lechner <david@lechnology.com>
> + *
> + * Remoteproc driver for TI Programmable Realtime Unit
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_data/ti-pruss.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/remoteproc.h>
> +#include <linux/regmap.h>
> +#include <linux/sizes.h>
> +#include <linux/types.h>
> +
> +#include "remoteproc_internal.h"
> +
> +#define SZ_12K 0x3000
> +
> +/* control/status registers */
> +#define TI_PRU_CS_CONTROL	0x0
> +#define TI_PRU_CS_STATUS	0x4
> +#define TI_PRU_CS_WAKEUP	0x8
> +#define TI_PRU_CS_CYCLECNT	0xc
> +
> +/* control register bits */
> +#define TI_PRU_CONTROL_PCRESETVAL	GENMASK(31, 16)
> +#define TI_PRU_CONTROL_RUNSTATE		BIT(15)
> +#define TI_PRU_CONTROL_SINGLESTEP	BIT(8)
> +#define TI_PRU_CONTROL_COUNTENABLE	BIT(3)
> +#define TI_PRU_CONTROL_SLEEPING		BIT(2)
> +#define TI_PRU_CONTROL_ENABLE		BIT(1)
> +#define TI_PRU_CONTROL_SOFTRESET	BIT(0)
> +
> +/* status bits */
> +#define TI_PRU_STATUS_PCOUNTER		GENMASK(15, 0)
> +
> +/* interrupt controller registers */
> +#define TI_PRU_INTC_GLBLEN		0x10
> +#define TI_PRU_INTC_STATIDXSET		0x20
> +#define TI_PRU_INTC_STATIDXCLR		0x24
> +#define TI_PRU_INTC_ENIDXSET		0x28
> +#define TI_PRU_INTC_HSTINTENIDXSET	0x34
> +#define TI_PRU_INTC_CHANMAP0		0x400
> +#define TI_PRU_INTC_POLARITY0		0xd00
> +#define TI_PRU_INTC_TYPE0		0xd80
> +#define TI_PRU_INTC_HOSTMAP0		0x800
> +
> +/* config registers */
> +#define TI_PRU_CFG_SYSCFG		0x4
> +
> +/* syscfg bits */
> +#define TI_PRU_SYSCFG_SUB_MWAIT			BIT(5)
> +#define TI_PRU_SYSCFG_STANDBY_INIT		BIT(4)
> +#define TI_PRU_SYSCFG_STANDBY_MODE_MASK		GENMASK(3, 2)
> +#define TI_PRU_SYSCFG_STANDBY_MODE_SMART	(2 << 2)
> +#define TI_PRU_SYSCFG_IDLE_MODE_MASK		GENMASK(1, 0)
> +#define TI_PRU_SYSCFG_IDLE_MODE_SMART		(2 << 0)
> +
> +enum ti_pru {
> +	TI_PRU0,
> +	TI_PRU1,
> +	NUM_TI_PRU
> +};
> +
> +enum ti_pru_type {
> +	TI_PRU_TYPE_AM18XX,
> +	TI_PRU_TYPE_AM335X,
> +	NUM_TI_PRU_TYPE
> +};
> +
> +enum ti_pru_evtout {
> +	TI_PRU_EVTOUT0,
> +	TI_PRU_EVTOUT1,
> +	TI_PRU_EVTOUT2,
> +	TI_PRU_EVTOUT3,
> +	TI_PRU_EVTOUT4,
> +	TI_PRU_EVTOUT5,
> +	TI_PRU_EVTOUT6,
> +	TI_PRU_EVTOUT7,
> +	NUM_TI_PRU_EVTOUT
> +};
> +
> +struct ti_pru_mem_region {
> +	off_t offset;
> +	size_t size;
> +};
> +
> +/**
> + * ti_pru_shared_info - common init info for the PRUSS
> + * @ram: shared RAM, if present
> + * @intc: interrupt controller
> + * @cfg: configuration registers, if present
> + */
> +struct ti_pru_shared_info {
> +	struct ti_pru_mem_region ram;
> +	struct ti_pru_mem_region intc;
> +	struct ti_pru_mem_region cfg;
> +};
> +
> +/**
> + * ti_pru_info - init info each individual PRU
> + * @ram: PRU RAM
> + * @ctrl: PRU control/status registers
> + * @dbg: PRU dbg registers
> + * @inst: instruction RAM
> + * @vq_arm_to_pru_event: The index of the PRU system event interrupt used
> + *                       used by the ARM for kicking the PRU
> + * @vq_pru_to_arm_event: The index of the PRU system event interrupt used
> + *                       used by the PRU for kicking the ARM
> + */
> +struct ti_pru_info {
> +	struct ti_pru_mem_region ram;
> +	struct ti_pru_mem_region ctrl;
> +	struct ti_pru_mem_region dbg;
> +	struct ti_pru_mem_region inst;
> +	int vq_arm_to_pru_event;
> +	int vq_pru_to_arm_event;
> +};
> +
> +struct ti_pru_device_info {
> +	struct ti_pru_shared_info shared;
> +	struct ti_pru_info pru[NUM_TI_PRU];
> +};
> +
> +static const struct ti_pru_device_info ti_pru_devices[NUM_TI_PRU_TYPE] = {
> +	[TI_PRU_TYPE_AM18XX] = {
> +		.shared = {
> +			.intc	= { .offset = 0x4000,	.size = SZ_12K,	},
> +		},
> +		.pru[TI_PRU0] = {
> +			.ram	= { .offset = 0x0000,	.size = SZ_512,	},
> +			.ctrl	= { .offset = 0x7000,	.size = SZ_1K,	},
> +			.dbg	= { .offset = 0x7400,	.size = SZ_1K,	},
> +			.inst	= { .offset = 0x8000,	.size = SZ_4K,	},
> +			.vq_arm_to_pru_event = 32,
> +			.vq_pru_to_arm_event = 33,
> +		},
> +		.pru[TI_PRU1] = {
> +			.ram	= { .offset = 0x2000,	.size = SZ_512,	},
> +			.ctrl	= { .offset = 0x7800,	.size = SZ_1K,	},
> +			.dbg	= { .offset = 0x7c00,	.size = SZ_1K,	},
> +			.inst	= { .offset = 0xc000,	.size = SZ_4K,	},
> +			.vq_arm_to_pru_event = 34,
> +			.vq_pru_to_arm_event = 35,
> +		},
> +	},
> +	[TI_PRU_TYPE_AM335X] = {
> +		.shared = {
> +			.ram	= { .offset = 0x10000,	.size = SZ_12K,	},
> +			.intc	= { .offset = 0x20000,	.size = SZ_8K,	},
> +			.cfg	= { .offset = 0x26000,	.size = SZ_8K,	},
> +		},
> +		.pru[TI_PRU0] = {
> +			.ram	= { .offset = 0x00000,	.size = SZ_8K,	},
> +			.ctrl	= { .offset = 0x22000,	.size = SZ_1K,	},
> +			.dbg	= { .offset = 0x22400,	.size = SZ_1K,	},
> +			.inst	= { .offset = 0x34000,	.size = SZ_8K,	},
> +			.vq_arm_to_pru_event = 16,
> +			.vq_pru_to_arm_event = 17,
> +		},
> +		.pru[TI_PRU1] = {
> +			.ram	= { .offset = 0x02000,	.size = SZ_8K,	},
> +			.ctrl	= { .offset = 0x24000,	.size = SZ_1K,	},
> +			.dbg	= { .offset = 0x24400,	.size = SZ_1K,	},
> +			.inst	= { .offset = 0x38000,	.size = SZ_8K,	},
> +			.vq_arm_to_pru_event = 18,
> +			.vq_pru_to_arm_event = 19,
> +		},
> +	},

All this information should really come from the DT.

> +};
> +
> +/**
> + * ti_pru_shared_data - private platform driver data
> + * @info: init info common to both PRU cores
> + * @dev: the platform device
> + * @base: the mapped memory region of the PRUSS
> + * @intc: regmap of the interrupt controller
> + * @cfg: regmap of configuration registers
> + * @pru: per-PRU core data
> + */
> +struct ti_pru_shared_data {
> +	const struct ti_pru_shared_info *info;
> +	struct device *dev;
> +	void __iomem *base;
> +	struct regmap *intc;
> +	struct regmap *cfg;
> +	struct rproc *pru[NUM_TI_PRU];
> +};
> +
> +/**
> + * ti_pru_data - private data for each PRU core
> + * @info: static init info
> + * @shared: pointer to the shared data struct
> + * @ctrl: regmap of the PRU control/status register
> + * @vq_irq: interrupt used for rpmsg
> + */
> +struct ti_pru_data {
> +	const struct ti_pru_info *info;
> +	struct ti_pru_shared_data *shared;
> +	struct regmap *ctrl;
> +	int vq_irq;
> +};
> +
> +static int ti_pru_rproc_start(struct rproc *rproc)
> +{
> +	struct ti_pru_data *pru = rproc->priv;
> +	u32 val;
> +
> +	val = (rproc->bootaddr >> 2) << (ffs(TI_PRU_CONTROL_PCRESETVAL) - 1);
> +	val |= TI_PRU_CONTROL_ENABLE;
> +
> +	return regmap_write(pru->ctrl, TI_PRU_CS_CONTROL, val);
> +}
> +
> +static int ti_pru_rproc_stop(struct rproc *rproc)
> +{
> +	struct ti_pru_data *pru = rproc->priv;
> +	u32 mask;
> +
> +	mask = TI_PRU_CONTROL_ENABLE;
> +
> +	return regmap_write_bits(pru->ctrl, TI_PRU_CS_CONTROL, mask, 0);
> +}
> +
> +static void ti_pru_rproc_kick(struct rproc *rproc, int vqid)
> +{
> +	struct ti_pru_data *pru = rproc->priv;
> +	struct ti_pru_shared_data *shared = pru->shared;
> +	u32 val;
> +
> +	val = pru->info->vq_arm_to_pru_event;
> +
> +	regmap_write(shared->intc, TI_PRU_INTC_STATIDXSET, val);
> +}
> +
> +static void *ti_pru_rproc_da_to_va(struct rproc *rproc, u64 da, int len, int map)
> +{
> +	struct ti_pru_data *pru = rproc->priv;
> +	struct ti_pru_shared_data *shared = pru->shared;
> +
> +	if (map == 0) {
> +		if (da + len > pru->info->inst.size)
> +			return ERR_PTR(-EINVAL);
> +
> +		return shared->base + pru->info->inst.offset + da;
> +	}
> +
> +	if (map == 1) {
> +		if (da + len > pru->info->ram.size)
> +			return ERR_PTR(-EINVAL);
> +
> +		return shared->base + pru->info->ram.offset + da;
> +	}
> +
> +	return ERR_PTR(-EINVAL);
> +}
> +
> +static const struct rproc_ops ti_pru_rproc_ops = {
> +	.start = ti_pru_rproc_start,
> +	.stop = ti_pru_rproc_stop,
> +	.kick = ti_pru_rproc_kick,
> +	.da_to_va = ti_pru_rproc_da_to_va,
> +};
> +
> +static struct regmap_config ti_pru_ctrl_regmap_config = {
> +	.reg_bits = 32,
> +	.val_bits = 32,
> +	.reg_stride = 4,
> +	.max_register = 0x2c,
> +};
> +
> +static struct regmap_config ti_pru_intc_regmap_config = {
> +	.reg_bits = 32,
> +	.val_bits = 32,
> +	.reg_stride = 4,
> +	.max_register = 0x1500,
> +};
> +
> +static struct regmap_config ti_pru_cfg_regmap_config = {
> +	.reg_bits = 32,
> +	.val_bits = 32,
> +	.reg_stride = 4,
> +	.max_register = 0x40,
> +};
> +
> +static const struct of_device_id ti_pru_rproc_of_match[] = {
> +	{
> +		.compatible = "ti,da850-pru-rproc",
> +		.data = &ti_pru_devices[TI_PRU_TYPE_AM18XX]
> +	},
> +	{
> +		.compatible = "ti,am3352-pru-rproc",
> +		.data = &ti_pru_devices[TI_PRU_TYPE_AM335X]
> +	},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, ti_pru_rproc_of_match);
> +
> +static irqreturn_t ti_pru_handle_vq_irq(int irq, void *p)
> +{
> +	struct rproc *rproc = p;
> +	struct ti_pru_data *pru = rproc->priv;
> +
> +	regmap_write(pru->shared->intc, TI_PRU_INTC_STATIDXCLR,
> +		     pru->info->vq_pru_to_arm_event);
> +
> +	return IRQ_WAKE_THREAD;
> +}
> +
> +static irqreturn_t ti_pru_vq_irq_thread(int irq, void *p)
> +{
> +	struct rproc *rproc = p;
> +
> +	rproc_vq_interrupt(rproc, 0);
> +	rproc_vq_interrupt(rproc, 1);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static void ti_pru_free_rproc(void *data)
> +{
> +	struct rproc *rproc = data;
> +
> +	rproc_free(rproc);
> +}
> +
> +static struct rproc *ti_pru_init_one_rproc(struct ti_pru_shared_data *shared,
> +					   const struct ti_pru_info *info,
> +					   enum ti_pru id)
> +{
> +	struct device *dev = shared->dev;
> +	struct platform_device *pdev = to_platform_device(dev);
> +	const char *name;
> +	char irq_name[16];
> +	struct rproc *rproc;
> +	struct ti_pru_data *pru;
> +	int err;
> +
> +	name = devm_kasprintf(dev, GFP_KERNEL, "pru%u", id);
> +	if (!name)
> +		return ERR_PTR(-ENOMEM);
> +
> +	rproc = rproc_alloc(dev, name, &ti_pru_rproc_ops, NULL, sizeof(*pru));
> +	if (!rproc)
> +		return ERR_PTR(-ENOMEM);
> +
> +	devm_add_action(dev, ti_pru_free_rproc, rproc);
> +
> +	/* don't auto-boot for now - bad firmware can lock up the system */
> +	rproc->auto_boot = false;
> +
> +	pru = rproc->priv;
> +	pru->info = info;
> +	pru->shared = shared;
> +
> +	snprintf(irq_name, 16, "%s-vq", name);
> +
> +	pru->vq_irq = platform_get_irq_byname(pdev, irq_name);
> +	if (pru->vq_irq < 0) {
> +		dev_err(&rproc->dev, "failed to get vq IRQ\n");
> +		return ERR_PTR(pru->vq_irq);
> +	}
> +
> +	err = devm_request_threaded_irq(&rproc->dev, pru->vq_irq,
> +					ti_pru_handle_vq_irq,
> +					ti_pru_vq_irq_thread, 0, name, rproc);
> +	if (err < 0) {
> +		dev_err(&rproc->dev, "failed to request vq IRQ\n");
> +		return ERR_PTR(err);
> +	}
> +
> +	pru->ctrl = devm_regmap_init_mmio(&rproc->dev,
> +					  shared->base + info->ctrl.offset,
> +					  &ti_pru_ctrl_regmap_config);
> +	if (IS_ERR(pru->ctrl)) {
> +		dev_err(&rproc->dev, "failed to init ctrl regmap\n");
> +		return ERR_CAST(pru->ctrl);
> +	}
> +
> +	return rproc;
> +}
> +
> +/**
> + * ti_pru_init_intc_polarity - configure polarity interrupt event
> + * @intc: the interrtup controller regmap
> + * @event: the source event
> + */
> +static void ti_pru_init_intc_polarity(struct regmap *intc, int event)
> +{
> +	int offset, shift, mask;
> +
> +	/* 32 events per register */
> +	offset = event / 32 * 4;
> +	shift = event % 32;
> +	mask = 1 << shift;
> +
> +	/* polarity is always high (1) */
> +	regmap_write_bits(intc, TI_PRU_INTC_POLARITY0 + offset, mask, ~0);
> +}
> +
> +/**
> + * ti_pru_init_intc_type - configure type of interrupt event
> + * @intc: the interrtup controller regmap
> + * @event: the source event
> + */
> +static void ti_pru_init_intc_type(struct regmap *intc, int event)
> +{
> +	int offset, shift, mask;
> +
> +	/* 32 events per register */
> +	offset = event / 32 * 4;
> +	shift = event % 32;
> +	mask = 1 << shift;
> +
> +	/* type is always pulse (0) */
> +	regmap_write_bits(intc, TI_PRU_INTC_TYPE0 + offset, mask, 0);
> +}
> +
> +/**
> + * ti_pru_init_intc_channel_map - configure interrupt event to channel mapping
> + * @intc: the interrtup controller regmap
> + * @event: the source event
> + * @ch: the channel to be assigned to the event
> + */
> +static void ti_pru_init_intc_channel_map(struct regmap *intc, int event, int ch)
> +{
> +	int offset, shift, mask, val;
> +
> +	/* 4 channels per 32-bit register */
> +	offset = event / 4 * 4;
> +	shift = event % 4 * 8;
> +	mask = 0xff << shift;
> +	val = ch << shift;
> +
> +	regmap_write_bits(intc, TI_PRU_INTC_CHANMAP0 + offset, mask, val);
> +}
> +
> +/**
> + * ti_pru_init_intc_host_map - configure interrupt channel to host mapping
> + * @intc: the interrtup controller regmap
> + * @ch: the source channel
> + * @host: the host interrupt to be assigned to the channel
> + */
> +static void ti_pru_init_intc_host_map(struct regmap *intc, int ch, int host)
> +{
> +	int offset, shift, mask, val;
> +
> +	/* 4 hosts per 32-bit register */
> +	offset = ch / 4 * 4;
> +	shift = ch % 4 * 8;
> +	mask = 0xff << shift;
> +	val = host << shift;
> +
> +	regmap_write_bits(intc, TI_PRU_INTC_HOSTMAP0 + offset, mask, val);
> +}
> +
> +static void ti_pru_init_intc(struct regmap *intc,
> +			     const struct ti_pru_device_info *info)
> +{
> +	int arm_to_pru0 = info->pru[TI_PRU0].vq_arm_to_pru_event;
> +	int arm_to_pru1 = info->pru[TI_PRU1].vq_arm_to_pru_event;
> +	int pru0_to_arm = info->pru[TI_PRU0].vq_pru_to_arm_event;
> +	int pru1_to_arm = info->pru[TI_PRU1].vq_pru_to_arm_event;
> +
> +	/* set polarity of system events */
> +	ti_pru_init_intc_polarity(intc, arm_to_pru0);
> +	ti_pru_init_intc_polarity(intc, arm_to_pru1);
> +	ti_pru_init_intc_polarity(intc, pru0_to_arm);
> +	ti_pru_init_intc_polarity(intc, pru1_to_arm);
> +
> +	/* set type of system events */
> +	ti_pru_init_intc_type(intc, arm_to_pru0);
> +	ti_pru_init_intc_type(intc, arm_to_pru1);
> +	ti_pru_init_intc_type(intc, pru0_to_arm);
> +	ti_pru_init_intc_type(intc, pru1_to_arm);
> +
> +	/* map system events to channels */
> +	ti_pru_init_intc_channel_map(intc, arm_to_pru0, 0);
> +	ti_pru_init_intc_channel_map(intc, arm_to_pru1, 1);
> +	ti_pru_init_intc_channel_map(intc, pru0_to_arm, 2);
> +	ti_pru_init_intc_channel_map(intc, pru1_to_arm, 3);
> +
> +	/* map channels to host interrupts */
> +	ti_pru_init_intc_host_map(intc, 0, 0); /* ARM to PRU0 */
> +	ti_pru_init_intc_host_map(intc, 1, 1); /* ARM to PRU1 */
> +	ti_pru_init_intc_host_map(intc, 2, 2); /* PRU0 to ARM */
> +	ti_pru_init_intc_host_map(intc, 3, 3); /* PRU1 to ARM */
> +
> +	/* clear system interrupts */
> +	regmap_write(intc, TI_PRU_INTC_STATIDXCLR, arm_to_pru0);
> +	regmap_write(intc, TI_PRU_INTC_STATIDXCLR, arm_to_pru1);
> +	regmap_write(intc, TI_PRU_INTC_STATIDXCLR, pru0_to_arm);
> +	regmap_write(intc, TI_PRU_INTC_STATIDXCLR, pru1_to_arm);
> +
> +	/* enable host interrupts for kicking */
> +	regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 0); /* ARM to PRU0 */
> +	regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 1); /* ARM to PRU1 */
> +	regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 2); /* PRU0 to ARM */
> +	regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 3); /* PRU1 to ARM */
> +
> +	/* enable system events for kicking */
> +	regmap_write(intc, TI_PRU_INTC_ENIDXSET, arm_to_pru0);
> +	regmap_write(intc, TI_PRU_INTC_ENIDXSET, arm_to_pru1);
> +	regmap_write(intc, TI_PRU_INTC_ENIDXSET, pru0_to_arm);
> +	regmap_write(intc, TI_PRU_INTC_ENIDXSET, pru1_to_arm);
> +
> +	/* enable all interrupts */
> +	regmap_write_bits(intc, TI_PRU_INTC_GLBLEN, 1, 1);
> +}

We already have a working irq_chip implementation for INTC.
https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/drivers/remoteproc/pruss_intc.c

I think we can leverage directly from that.

This way pru_rproc or client device nodes can easily specify a pruss_intc interrupt parent and the
SYSEVENT number as the irq. Then device drivers can simply use request_irq().

example usage here
https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/arch/arm/boot/dts/am33xx.dtsi#line986
https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/drivers/remoteproc/pru_rproc.c#line670


> +
> +static int ti_pru_rproc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct ti_pruss_platform_data *pdata = dev_get_platdata(dev);
> +	const struct of_device_id *of_id;
> +	const struct ti_pru_device_info *info;
> +	struct ti_pru_shared_data *shared;
> +	struct resource *res;
> +	int err;
> +
> +	of_id = of_match_device(ti_pru_rproc_of_match, dev);
> +	if (!of_id || !of_id->data)
> +		return -EINVAL;
> +
> +	info = of_id->data;
> +
> +	shared = devm_kzalloc(dev, sizeof(*shared), GFP_KERNEL);
> +
> +	platform_set_drvdata(pdev, shared);
> +
> +	shared->info = &info->shared;
> +	shared->dev = dev;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	shared->base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(shared->base)) {
> +		dev_err(dev, "failed to ioremap resource\n");
> +		return PTR_ERR(shared->base);
> +	}
> +
> +	shared->intc = devm_regmap_init_mmio(dev,
> +				shared->base + shared->info->intc.offset,
> +				&ti_pru_intc_regmap_config);
> +	if (IS_ERR(shared->intc)) {
> +		dev_err(dev, "failed to init intc regmap\n");
> +		return PTR_ERR(shared->intc);
> +	}
> +
> +	if (shared->info->cfg.size) {
> +		shared->cfg = devm_regmap_init_mmio(dev,
> +			shared->base + shared->info->cfg.offset,
> +			&ti_pru_cfg_regmap_config);
> +		if (IS_ERR(shared->cfg)) {
> +			dev_err(dev, "failed to init cfg regmap\n");
> +			return PTR_ERR(shared->cfg);
> +		}
> +	}
> +
> +	shared->pru[TI_PRU0] = ti_pru_init_one_rproc(shared, &info->pru[TI_PRU0],
> +						     TI_PRU0);
> +	if (IS_ERR(shared->pru[TI_PRU0]))
> +		return PTR_ERR(shared->pru[TI_PRU0]);
> +
> +	shared->pru[TI_PRU1] = ti_pru_init_one_rproc(shared, &info->pru[TI_PRU1],
> +						     TI_PRU1);
> +	if (IS_ERR(shared->pru[TI_PRU1]))
> +		return PTR_ERR(shared->pru[TI_PRU1]);
> +
> +	pm_runtime_enable(dev);
> +
> +	err = pm_runtime_get_sync(dev);
> +	if (err < 0)
> +		goto err_pm_runtime_disable;
> +
> +	if (pdata) {
> +		err = pdata->deassert_reset(pdev, pdata->reset_name);
> +		if (err < 0) {
> +			dev_err(dev, "Failed to reset pruss\n");
> +			goto err_pm_runtime_put;
> +		}
> +	}
> +
> +	if (shared->cfg) {
> +		int mask, val;
> +
> +		mask = TI_PRU_SYSCFG_IDLE_MODE_MASK | TI_PRU_SYSCFG_STANDBY_MODE_MASK;
> +		val = TI_PRU_SYSCFG_IDLE_MODE_SMART | TI_PRU_SYSCFG_STANDBY_MODE_SMART;
> +		regmap_write_bits(shared->cfg, TI_PRU_CFG_SYSCFG, mask, val);
> +
> +		mask = TI_PRU_SYSCFG_STANDBY_INIT;
> +		val = 0;
> +		regmap_write_bits(shared->cfg, TI_PRU_CFG_SYSCFG, mask, val);
> +
> +		err = regmap_read_poll_timeout(shared->cfg, TI_PRU_CFG_SYSCFG,
> +				val, !(val & TI_PRU_SYSCFG_SUB_MWAIT), 5, 50);
> +		if (err < 0) {
> +			dev_err(dev, "timeout while enabling pruss\n");
> +			goto err_pm_runtime_put;
> +		}
> +	}
> +
> +	ti_pru_init_intc(shared->intc, info);

This is using a static INTC map right?
This limits our possibility to use application based INTC mapping.
There needs to be a way to specify the INTC mapping in the DT and/or resource table.

> +
> +	err = rproc_add(shared->pru[TI_PRU0]);
> +	if (err < 0)
> +		goto err_assert_reset;
> +
> +	err = rproc_add(shared->pru[TI_PRU1]);
> +	if (err < 0)
> +		goto err_del_pru0;
> +
> +	return 0;
> +
> +err_del_pru0:
> +	rproc_del(shared->pru[TI_PRU0]);
> +err_assert_reset:
> +	if (pdata)
> +		pdata->assert_reset(pdev, pdata->reset_name);
> +err_pm_runtime_put:
> +	pm_runtime_put(dev);
> +err_pm_runtime_disable:
> +	pm_runtime_disable(dev);
> +
> +	return err;
> +}
> +
> +static int ti_pru_rproc_remove(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct ti_pruss_platform_data *pdata = dev_get_platdata(dev);
> +	struct ti_pru_shared_data *shared = platform_get_drvdata(pdev);
> +
> +	rproc_del(shared->pru[TI_PRU1]);
> +	rproc_del(shared->pru[TI_PRU0]);
> +	if (pdata)
> +		pdata->assert_reset(pdev, pdata->reset_name);
> +	pm_runtime_put(dev);
> +	pm_runtime_disable(dev);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver ti_pru_rproc_driver = {
> +	.probe	= ti_pru_rproc_probe,
> +	.remove	= ti_pru_rproc_remove,
> +	.driver	= {
> +		.name = "ti-pru-rproc",
> +		.of_match_table = ti_pru_rproc_of_match,
> +	},
> +};
> +module_platform_driver(ti_pru_rproc_driver);
> +
> +MODULE_AUTHOR("David Lechner <david@lechnology.com>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Remoteproc driver for TI PRU");
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

* Re: New remoteproc driver for TI PRU
  2018-06-29  9:58 ` New remoteproc driver for TI PRU Roger Quadros
@ 2018-06-29 17:44   ` David Lechner
  2018-06-30  0:17     ` Suman Anna
  2018-07-02  8:17     ` Roger Quadros
  0 siblings, 2 replies; 71+ messages in thread
From: David Lechner @ 2018-06-29 17:44 UTC (permalink / raw)
  To: Roger Quadros, linux-remoteproc, devicetree, linux-omap,
	linux-arm-kernel
  Cc: Ohad Ben-Cohen, Bjorn Andersson, Rob Herring, Mark Rutland,
	Benoît Cousson, Tony Lindgren, Sekhar Nori, Kevin Hilman,
	linux-kernel, Anna, Suman, Tero Kristo

On 06/29/2018 04:58 AM, Roger Quadros wrote:
> +Suman & Tero
> 
> Hi David,
> 
> On 24/06/18 00:08, David Lechner wrote:
>>
>> Date: Sat, 23 Jun 2018 15:43:59 -0500
>> Subject: [PATCH 0/8] New remoteproc driver for TI PRU
>>
>> This series adds a new remoteproc driver for the TI Programmable Runtime Unit
>> (PRU) that is present in some TI Sitara processors. This code has been tested
>> working on AM1808 (LEGO MINDSTORMS EV3) and AM3358 (BeagleBone Green).
> 
> This is great. We have been working on something similar and I think it would
> be great if we can collaborate to get all our needs addressed.

Yes, I have used the PRU with the TI kernel on BeagleBone so I've seen the TI
implementation. My primary interest is in the AM1808, which has a far simpler
PRU than other SoCs. So, I was hoping I could get away with just implementing
the basic stuff that I need and let TI add the more complex stuff later.

> 
> Our primary requirement is that it should be possible for a user (e.g. kernel driver) to
> - request a specific PRU core load a specific firmware blob and boot/stop the PRU.

For this, I was thinking of suggesting a generic remoteproc provider/consumer
binding that is similar to other subsystems. For example:

Provider node has:

	#remoteproc-cells = <1>;

And consumer has:

	remoteprocs = <&pruss 0>, <&pruss 1>;
	remoteproc-names = "pru0", "pru1";

The consumer device would be responsible for determining the firmware file
and for calling the rproc boot function.


> - configure INTC interrupt mapping based on either resource table or DT
> - use request_irq to request and use an interrupt.

I didn't consider creating a new interrupt controller in device tree, but
that makes sense. I will have to look into it some more.


> - request access to DRAM/SRAM

Can the existing device tree bindings for reserved-memory be used for this?
I would expect the consumer nodes to use this and not the PRUSS provider node.


> - configure gpimode/miirt/xfr (CFG space)

I have no idea what this stuff is. :-)

(This is what I was referring to when I said I was hoping that someone
else could add more later).

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

* Re: New remoteproc driver for TI PRU
  2018-06-29 17:44   ` David Lechner
@ 2018-06-30  0:17     ` Suman Anna
  2018-08-06 16:32       ` David Lechner
  2018-07-02  8:17     ` Roger Quadros
  1 sibling, 1 reply; 71+ messages in thread
From: Suman Anna @ 2018-06-30  0:17 UTC (permalink / raw)
  To: David Lechner, Roger Quadros, linux-remoteproc, devicetree,
	linux-omap, linux-arm-kernel
  Cc: Ohad Ben-Cohen, Mark Rutland, Kevin Hilman, Tony Lindgren,
	Sekhar Nori, linux-kernel, Bjorn Andersson, Tero Kristo,
	Rob Herring, Benoît Cousson

Hi David,

On 06/29/2018 12:44 PM, David Lechner wrote:
> On 06/29/2018 04:58 AM, Roger Quadros wrote:
>> +Suman & Tero
>>
>> Hi David,
>>
>> On 24/06/18 00:08, David Lechner wrote:
>>>
>>> Date: Sat, 23 Jun 2018 15:43:59 -0500
>>> Subject: [PATCH 0/8] New remoteproc driver for TI PRU
>>>
>>> This series adds a new remoteproc driver for the TI Programmable
>>> Runtime Unit
>>> (PRU) that is present in some TI Sitara processors. This code has
>>> been tested
>>> working on AM1808 (LEGO MINDSTORMS EV3) and AM3358 (BeagleBone Green).
>>
>> This is great. We have been working on something similar and I think
>> it would
>> be great if we can collaborate to get all our needs addressed.
> 
> Yes, I have used the PRU with the TI kernel on BeagleBone so I've seen
> the TI
> implementation. My primary interest is in the AM1808, which has a far
> simpler
> PRU than other SoCs. So, I was hoping I could get away with just
> implementing
> the basic stuff that I need and let TI add the more complex stuff later.

Thanks for the series. PRUSS is present on many SoCs now, and each with
their own integration quirks, both in terms of SoC connections as well
as internal sub-modules within the subsystem. We currently support
AM335x, AM437x, AM57xx, Keystone 2 based 66AK2G and a newer generation
AM65x as well. It should be relatively straight-forward to scale this
for AM1808/OMAP-L138 as well. The move to the standard Common Clock and
Reset frameworks for clocks with the Davinci chips should make it
relatively straight-forward for the architecture pieces.

I will take a look at your series in detail sometime next week, and
mostly post our series to the upstream lists as well within the next
couple of weeks so that it is easier for discussion on the upstream lists.

> 
>>
>> Our primary requirement is that it should be possible for a user (e.g.
>> kernel driver) to
>> - request a specific PRU core load a specific firmware blob and
>> boot/stop the PRU.
> 
> For this, I was thinking of suggesting a generic remoteproc
> provider/consumer
> binding that is similar to other subsystems. For example:
> 
> Provider node has:
> 
>     #remoteproc-cells = <1>;
> 
> And consumer has:
> 
>     remoteprocs = <&pruss 0>, <&pruss 1>;
>     remoteproc-names = "pru0", "pru1";

We do have an existing API in remoteproc core today,
rproc_get_by_phandle() for this, though it is not as sophisticated or
designed in a standard way that we see on some other sub-systems. One
thing that's currently missing from this is a sense of exclusive access,
as we do want to restrict access to a PRU to a single client at a time.
> 
> The consumer device would be responsible for determining the firmware file
> and for calling the rproc boot function.
> 
> 
>> - configure INTC interrupt mapping based on either resource table or DT
>> - use request_irq to request and use an interrupt.
> 
> I didn't consider creating a new interrupt controller in device tree, but
> that makes sense. I will have to look into it some more.
> 

Couple of iterations on our vendor tree all but resulted in representing
various sub-modules as child nodes - this allows to reuse different
drivers to deal with specific functionality like MDIO, UART etc. The
number of registers across all PRUSS sub-modules and SoCs are too huge
to support through a single driver.

> 
>> - request access to DRAM/SRAM
> 
> Can the existing device tree bindings for reserved-memory be used for this?

Typically, reserved-memory is used for reserving regions in DDR, not
mmio spaces. There is the SRAM driver in general to deal with on-chip
memories.

> I would expect the consumer nodes to use this and not the PRUSS provider
> node.

We will need access from both, as the remoteproc core does the loading
in general leveraging specific rproc ops from a remoteproc
implementation driver.

> 
> 
>> - configure gpimode/miirt/xfr (CFG space)
> 
> I have no idea what this stuff is. :-)

There are all the different sub-modules/register spaces dealing
specifically with internal pinmuxes, some serial/parallel GPIO pin
operations etc.

regards
Suman

> 
> (This is what I was referring to when I said I was hoping that someone
> else could add more later).
> 

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

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

* Re: [PATCH 5/8] remoteproc: new driver for TI PRU
  2018-06-29 10:14   ` Roger Quadros
@ 2018-06-30 19:02     ` Derald Woods
  2018-07-02  8:05       ` Roger Quadros
  0 siblings, 1 reply; 71+ messages in thread
From: Derald Woods @ 2018-06-30 19:02 UTC (permalink / raw)
  To: Roger Quadros
  Cc: David Lechner, linux-remoteproc, devicetree, linux-omap,
	linux-arm-kernel, Ohad Ben-Cohen, Bjorn Andersson, Rob Herring,
	Mark Rutland, Benoît Cousson, Tony Lindgren, Sekhar Nori,
	Kevin Hilman, linux-kernel, Anna, Suman, Tero Kristo

[-- Attachment #1: Type: text/plain, Size: 28845 bytes --]

On Fri, Jun 29, 2018 at 5:14 AM, Roger Quadros <rogerq@ti.com> wrote:

>
>
> On 24/06/18 00:08, David Lechner wrote:
> > This adds a new remoteproc driver for TI Programmable Realtime Units
> > (PRUs).
> >
> > This has been tested working on AM1808 (LEGO MINDSTORMS EV3) using the
> > sample rpmsg client driver.
> >
> > Signed-off-by: David Lechner <david@lechnology.com>
> > ---
> >  MAINTAINERS                       |   5 +
> >  drivers/remoteproc/Kconfig        |   7 +
> >  drivers/remoteproc/Makefile       |   1 +
> >  drivers/remoteproc/ti_pru_rproc.c | 660 ++++++++++++++++++++++++++++++
> >  4 files changed, 673 insertions(+)
> >  create mode 100644 drivers/remoteproc/ti_pru_rproc.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index edf3cf5ea691..06dea089d9ae 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -14288,6 +14288,11 @@ L:   netdev@vger.kernel.org
> >  S:   Maintained
> >  F:   drivers/net/ethernet/ti/netcp*
> >
> > +TI PRU REMOTEPROC DRIVER
> > +R:   David Lechner <david@lechnology.com>
> > +F:   Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
> > +F:   drivers/remoteproc/ti_pru_rproc.c
> > +
> >  TI TAS571X FAMILY ASoC CODEC DRIVER
> >  M:   Kevin Cernekee <cernekee@chromium.org>
> >  L:   alsa-devel@alsa-project.org (moderated for non-subscribers)
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index cd1c168fd188..ae6e725e1755 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -158,6 +158,13 @@ config ST_REMOTEPROC
> >  config ST_SLIM_REMOTEPROC
> >       tristate
> >
> > +config TI_PRU_REMOTEPROC
> > +     tristate "TI Programmable Realtime Unit"
> > +     depends on ARCH_DAVINCI_DA8XX || SOC_AM33XX
> > +     help
> > +       Say y here to support TI Programmable Runtime Units (PRUs) via
> the
> > +       remote processor framework.
> > +
> >  endif # REMOTEPROC
> >
> >  endmenu
> > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > index 02627ede8d4a..451efee5c8d3 100644
> > --- a/drivers/remoteproc/Makefile
> > +++ b/drivers/remoteproc/Makefile
> > @@ -23,3 +23,4 @@ qcom_wcnss_pil-y                    += qcom_wcnss.o
> >  qcom_wcnss_pil-y                     += qcom_wcnss_iris.o
> >  obj-$(CONFIG_ST_REMOTEPROC)          += st_remoteproc.o
> >  obj-$(CONFIG_ST_SLIM_REMOTEPROC)     += st_slim_rproc.o
> > +obj-$(CONFIG_TI_PRU_REMOTEPROC)              += ti_pru_rproc.o
> > diff --git a/drivers/remoteproc/ti_pru_rproc.c
> b/drivers/remoteproc/ti_pru_rproc.c
> > new file mode 100644
> > index 000000000000..cd8302c318c9
> > --- /dev/null
> > +++ b/drivers/remoteproc/ti_pru_rproc.c
> > @@ -0,0 +1,660 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018 David Lechner <david@lechnology.com>
> > + *
> > + * Remoteproc driver for TI Programmable Realtime Unit
> > + */
> > +
> > +#include <linux/bitops.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_data/ti-pruss.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/pm_runtime.h>
> > +#include <linux/remoteproc.h>
> > +#include <linux/regmap.h>
> > +#include <linux/sizes.h>
> > +#include <linux/types.h>
> > +
> > +#include "remoteproc_internal.h"
> > +
> > +#define SZ_12K 0x3000
> > +
> > +/* control/status registers */
> > +#define TI_PRU_CS_CONTROL    0x0
> > +#define TI_PRU_CS_STATUS     0x4
> > +#define TI_PRU_CS_WAKEUP     0x8
> > +#define TI_PRU_CS_CYCLECNT   0xc
> > +
> > +/* control register bits */
> > +#define TI_PRU_CONTROL_PCRESETVAL    GENMASK(31, 16)
> > +#define TI_PRU_CONTROL_RUNSTATE              BIT(15)
> > +#define TI_PRU_CONTROL_SINGLESTEP    BIT(8)
> > +#define TI_PRU_CONTROL_COUNTENABLE   BIT(3)
> > +#define TI_PRU_CONTROL_SLEEPING              BIT(2)
> > +#define TI_PRU_CONTROL_ENABLE                BIT(1)
> > +#define TI_PRU_CONTROL_SOFTRESET     BIT(0)
> > +
> > +/* status bits */
> > +#define TI_PRU_STATUS_PCOUNTER               GENMASK(15, 0)
> > +
> > +/* interrupt controller registers */
> > +#define TI_PRU_INTC_GLBLEN           0x10
> > +#define TI_PRU_INTC_STATIDXSET               0x20
> > +#define TI_PRU_INTC_STATIDXCLR               0x24
> > +#define TI_PRU_INTC_ENIDXSET         0x28
> > +#define TI_PRU_INTC_HSTINTENIDXSET   0x34
> > +#define TI_PRU_INTC_CHANMAP0         0x400
> > +#define TI_PRU_INTC_POLARITY0                0xd00
> > +#define TI_PRU_INTC_TYPE0            0xd80
> > +#define TI_PRU_INTC_HOSTMAP0         0x800
> > +
> > +/* config registers */
> > +#define TI_PRU_CFG_SYSCFG            0x4
> > +
> > +/* syscfg bits */
> > +#define TI_PRU_SYSCFG_SUB_MWAIT                      BIT(5)
> > +#define TI_PRU_SYSCFG_STANDBY_INIT           BIT(4)
> > +#define TI_PRU_SYSCFG_STANDBY_MODE_MASK              GENMASK(3, 2)
> > +#define TI_PRU_SYSCFG_STANDBY_MODE_SMART     (2 << 2)
> > +#define TI_PRU_SYSCFG_IDLE_MODE_MASK         GENMASK(1, 0)
> > +#define TI_PRU_SYSCFG_IDLE_MODE_SMART                (2 << 0)
> > +
> > +enum ti_pru {
> > +     TI_PRU0,
> > +     TI_PRU1,
> > +     NUM_TI_PRU
> > +};
> > +
> > +enum ti_pru_type {
> > +     TI_PRU_TYPE_AM18XX,
> > +     TI_PRU_TYPE_AM335X,
> > +     NUM_TI_PRU_TYPE
> > +};
> > +
> > +enum ti_pru_evtout {
> > +     TI_PRU_EVTOUT0,
> > +     TI_PRU_EVTOUT1,
> > +     TI_PRU_EVTOUT2,
> > +     TI_PRU_EVTOUT3,
> > +     TI_PRU_EVTOUT4,
> > +     TI_PRU_EVTOUT5,
> > +     TI_PRU_EVTOUT6,
> > +     TI_PRU_EVTOUT7,
> > +     NUM_TI_PRU_EVTOUT
> > +};
> > +
> > +struct ti_pru_mem_region {
> > +     off_t offset;
> > +     size_t size;
> > +};
> > +
> > +/**
> > + * ti_pru_shared_info - common init info for the PRUSS
> > + * @ram: shared RAM, if present
> > + * @intc: interrupt controller
> > + * @cfg: configuration registers, if present
> > + */
> > +struct ti_pru_shared_info {
> > +     struct ti_pru_mem_region ram;
> > +     struct ti_pru_mem_region intc;
> > +     struct ti_pru_mem_region cfg;
> > +};
> > +
> > +/**
> > + * ti_pru_info - init info each individual PRU
> > + * @ram: PRU RAM
> > + * @ctrl: PRU control/status registers
> > + * @dbg: PRU dbg registers
> > + * @inst: instruction RAM
> > + * @vq_arm_to_pru_event: The index of the PRU system event interrupt
> used
> > + *                       used by the ARM for kicking the PRU
> > + * @vq_pru_to_arm_event: The index of the PRU system event interrupt
> used
> > + *                       used by the PRU for kicking the ARM
> > + */
> > +struct ti_pru_info {
> > +     struct ti_pru_mem_region ram;
> > +     struct ti_pru_mem_region ctrl;
> > +     struct ti_pru_mem_region dbg;
> > +     struct ti_pru_mem_region inst;
> > +     int vq_arm_to_pru_event;
> > +     int vq_pru_to_arm_event;
> > +};
> > +
> > +struct ti_pru_device_info {
> > +     struct ti_pru_shared_info shared;
> > +     struct ti_pru_info pru[NUM_TI_PRU];
> > +};
> > +
> > +static const struct ti_pru_device_info ti_pru_devices[NUM_TI_PRU_TYPE]
> = {
> > +     [TI_PRU_TYPE_AM18XX] = {
> > +             .shared = {
> > +                     .intc   = { .offset = 0x4000,   .size = SZ_12K, },
> > +             },
> > +             .pru[TI_PRU0] = {
> > +                     .ram    = { .offset = 0x0000,   .size = SZ_512, },
> > +                     .ctrl   = { .offset = 0x7000,   .size = SZ_1K,  },
> > +                     .dbg    = { .offset = 0x7400,   .size = SZ_1K,  },
> > +                     .inst   = { .offset = 0x8000,   .size = SZ_4K,  },
> > +                     .vq_arm_to_pru_event = 32,
> > +                     .vq_pru_to_arm_event = 33,
> > +             },
> > +             .pru[TI_PRU1] = {
> > +                     .ram    = { .offset = 0x2000,   .size = SZ_512, },
> > +                     .ctrl   = { .offset = 0x7800,   .size = SZ_1K,  },
> > +                     .dbg    = { .offset = 0x7c00,   .size = SZ_1K,  },
> > +                     .inst   = { .offset = 0xc000,   .size = SZ_4K,  },
> > +                     .vq_arm_to_pru_event = 34,
> > +                     .vq_pru_to_arm_event = 35,
> > +             },
> > +     },
> > +     [TI_PRU_TYPE_AM335X] = {
> > +             .shared = {
> > +                     .ram    = { .offset = 0x10000,  .size = SZ_12K, },
> > +                     .intc   = { .offset = 0x20000,  .size = SZ_8K,  },
> > +                     .cfg    = { .offset = 0x26000,  .size = SZ_8K,  },
> > +             },
> > +             .pru[TI_PRU0] = {
> > +                     .ram    = { .offset = 0x00000,  .size = SZ_8K,  },
> > +                     .ctrl   = { .offset = 0x22000,  .size = SZ_1K,  },
> > +                     .dbg    = { .offset = 0x22400,  .size = SZ_1K,  },
> > +                     .inst   = { .offset = 0x34000,  .size = SZ_8K,  },
> > +                     .vq_arm_to_pru_event = 16,
> > +                     .vq_pru_to_arm_event = 17,
> > +             },
> > +             .pru[TI_PRU1] = {
> > +                     .ram    = { .offset = 0x02000,  .size = SZ_8K,  },
> > +                     .ctrl   = { .offset = 0x24000,  .size = SZ_1K,  },
> > +                     .dbg    = { .offset = 0x24400,  .size = SZ_1K,  },
> > +                     .inst   = { .offset = 0x38000,  .size = SZ_8K,  },
> > +                     .vq_arm_to_pru_event = 18,
> > +                     .vq_pru_to_arm_event = 19,
> > +             },
> > +     },
>
> All this information should really come from the DT.
>
> > +};
> > +
> > +/**
> > + * ti_pru_shared_data - private platform driver data
> > + * @info: init info common to both PRU cores
> > + * @dev: the platform device
> > + * @base: the mapped memory region of the PRUSS
> > + * @intc: regmap of the interrupt controller
> > + * @cfg: regmap of configuration registers
> > + * @pru: per-PRU core data
> > + */
> > +struct ti_pru_shared_data {
> > +     const struct ti_pru_shared_info *info;
> > +     struct device *dev;
> > +     void __iomem *base;
> > +     struct regmap *intc;
> > +     struct regmap *cfg;
> > +     struct rproc *pru[NUM_TI_PRU];
> > +};
> > +
> > +/**
> > + * ti_pru_data - private data for each PRU core
> > + * @info: static init info
> > + * @shared: pointer to the shared data struct
> > + * @ctrl: regmap of the PRU control/status register
> > + * @vq_irq: interrupt used for rpmsg
> > + */
> > +struct ti_pru_data {
> > +     const struct ti_pru_info *info;
> > +     struct ti_pru_shared_data *shared;
> > +     struct regmap *ctrl;
> > +     int vq_irq;
> > +};
> > +
> > +static int ti_pru_rproc_start(struct rproc *rproc)
> > +{
> > +     struct ti_pru_data *pru = rproc->priv;
> > +     u32 val;
> > +
> > +     val = (rproc->bootaddr >> 2) << (ffs(TI_PRU_CONTROL_PCRESETVAL) -
> 1);
> > +     val |= TI_PRU_CONTROL_ENABLE;
> > +
> > +     return regmap_write(pru->ctrl, TI_PRU_CS_CONTROL, val);
> > +}
> > +
> > +static int ti_pru_rproc_stop(struct rproc *rproc)
> > +{
> > +     struct ti_pru_data *pru = rproc->priv;
> > +     u32 mask;
> > +
> > +     mask = TI_PRU_CONTROL_ENABLE;
> > +
> > +     return regmap_write_bits(pru->ctrl, TI_PRU_CS_CONTROL, mask, 0);
> > +}
> > +
> > +static void ti_pru_rproc_kick(struct rproc *rproc, int vqid)
> > +{
> > +     struct ti_pru_data *pru = rproc->priv;
> > +     struct ti_pru_shared_data *shared = pru->shared;
> > +     u32 val;
> > +
> > +     val = pru->info->vq_arm_to_pru_event;
> > +
> > +     regmap_write(shared->intc, TI_PRU_INTC_STATIDXSET, val);
> > +}
> > +
> > +static void *ti_pru_rproc_da_to_va(struct rproc *rproc, u64 da, int
> len, int map)
> > +{
> > +     struct ti_pru_data *pru = rproc->priv;
> > +     struct ti_pru_shared_data *shared = pru->shared;
> > +
> > +     if (map == 0) {
> > +             if (da + len > pru->info->inst.size)
> > +                     return ERR_PTR(-EINVAL);
> > +
> > +             return shared->base + pru->info->inst.offset + da;
> > +     }
> > +
> > +     if (map == 1) {
> > +             if (da + len > pru->info->ram.size)
> > +                     return ERR_PTR(-EINVAL);
> > +
> > +             return shared->base + pru->info->ram.offset + da;
> > +     }
> > +
> > +     return ERR_PTR(-EINVAL);
> > +}
> > +
> > +static const struct rproc_ops ti_pru_rproc_ops = {
> > +     .start = ti_pru_rproc_start,
> > +     .stop = ti_pru_rproc_stop,
> > +     .kick = ti_pru_rproc_kick,
> > +     .da_to_va = ti_pru_rproc_da_to_va,
> > +};
> > +
> > +static struct regmap_config ti_pru_ctrl_regmap_config = {
> > +     .reg_bits = 32,
> > +     .val_bits = 32,
> > +     .reg_stride = 4,
> > +     .max_register = 0x2c,
> > +};
> > +
> > +static struct regmap_config ti_pru_intc_regmap_config = {
> > +     .reg_bits = 32,
> > +     .val_bits = 32,
> > +     .reg_stride = 4,
> > +     .max_register = 0x1500,
> > +};
> > +
> > +static struct regmap_config ti_pru_cfg_regmap_config = {
> > +     .reg_bits = 32,
> > +     .val_bits = 32,
> > +     .reg_stride = 4,
> > +     .max_register = 0x40,
> > +};
> > +
> > +static const struct of_device_id ti_pru_rproc_of_match[] = {
> > +     {
> > +             .compatible = "ti,da850-pru-rproc",
> > +             .data = &ti_pru_devices[TI_PRU_TYPE_AM18XX]
> > +     },
> > +     {
> > +             .compatible = "ti,am3352-pru-rproc",
> > +             .data = &ti_pru_devices[TI_PRU_TYPE_AM335X]
> > +     },
> > +     { },
> > +};
> > +MODULE_DEVICE_TABLE(of, ti_pru_rproc_of_match);
> > +
> > +static irqreturn_t ti_pru_handle_vq_irq(int irq, void *p)
> > +{
> > +     struct rproc *rproc = p;
> > +     struct ti_pru_data *pru = rproc->priv;
> > +
> > +     regmap_write(pru->shared->intc, TI_PRU_INTC_STATIDXCLR,
> > +                  pru->info->vq_pru_to_arm_event);
> > +
> > +     return IRQ_WAKE_THREAD;
> > +}
> > +
> > +static irqreturn_t ti_pru_vq_irq_thread(int irq, void *p)
> > +{
> > +     struct rproc *rproc = p;
> > +
> > +     rproc_vq_interrupt(rproc, 0);
> > +     rproc_vq_interrupt(rproc, 1);
> > +
> > +     return IRQ_HANDLED;
> > +}
> > +
> > +static void ti_pru_free_rproc(void *data)
> > +{
> > +     struct rproc *rproc = data;
> > +
> > +     rproc_free(rproc);
> > +}
> > +
> > +static struct rproc *ti_pru_init_one_rproc(struct ti_pru_shared_data
> *shared,
> > +                                        const struct ti_pru_info *info,
> > +                                        enum ti_pru id)
> > +{
> > +     struct device *dev = shared->dev;
> > +     struct platform_device *pdev = to_platform_device(dev);
> > +     const char *name;
> > +     char irq_name[16];
> > +     struct rproc *rproc;
> > +     struct ti_pru_data *pru;
> > +     int err;
> > +
> > +     name = devm_kasprintf(dev, GFP_KERNEL, "pru%u", id);
> > +     if (!name)
> > +             return ERR_PTR(-ENOMEM);
> > +
> > +     rproc = rproc_alloc(dev, name, &ti_pru_rproc_ops, NULL,
> sizeof(*pru));
> > +     if (!rproc)
> > +             return ERR_PTR(-ENOMEM);
> > +
> > +     devm_add_action(dev, ti_pru_free_rproc, rproc);
> > +
> > +     /* don't auto-boot for now - bad firmware can lock up the system */
> > +     rproc->auto_boot = false;
> > +
> > +     pru = rproc->priv;
> > +     pru->info = info;
> > +     pru->shared = shared;
> > +
> > +     snprintf(irq_name, 16, "%s-vq", name);
> > +
> > +     pru->vq_irq = platform_get_irq_byname(pdev, irq_name);
> > +     if (pru->vq_irq < 0) {
> > +             dev_err(&rproc->dev, "failed to get vq IRQ\n");
> > +             return ERR_PTR(pru->vq_irq);
> > +     }
> > +
> > +     err = devm_request_threaded_irq(&rproc->dev, pru->vq_irq,
> > +                                     ti_pru_handle_vq_irq,
> > +                                     ti_pru_vq_irq_thread, 0, name,
> rproc);
> > +     if (err < 0) {
> > +             dev_err(&rproc->dev, "failed to request vq IRQ\n");
> > +             return ERR_PTR(err);
> > +     }
> > +
> > +     pru->ctrl = devm_regmap_init_mmio(&rproc->dev,
> > +                                       shared->base + info->ctrl.offset,
> > +                                       &ti_pru_ctrl_regmap_config);
> > +     if (IS_ERR(pru->ctrl)) {
> > +             dev_err(&rproc->dev, "failed to init ctrl regmap\n");
> > +             return ERR_CAST(pru->ctrl);
> > +     }
> > +
> > +     return rproc;
> > +}
> > +
> > +/**
> > + * ti_pru_init_intc_polarity - configure polarity interrupt event
> > + * @intc: the interrtup controller regmap
> > + * @event: the source event
> > + */
> > +static void ti_pru_init_intc_polarity(struct regmap *intc, int event)
> > +{
> > +     int offset, shift, mask;
> > +
> > +     /* 32 events per register */
> > +     offset = event / 32 * 4;
> > +     shift = event % 32;
> > +     mask = 1 << shift;
> > +
> > +     /* polarity is always high (1) */
> > +     regmap_write_bits(intc, TI_PRU_INTC_POLARITY0 + offset, mask, ~0);
> > +}
> > +
> > +/**
> > + * ti_pru_init_intc_type - configure type of interrupt event
> > + * @intc: the interrtup controller regmap
> > + * @event: the source event
> > + */
> > +static void ti_pru_init_intc_type(struct regmap *intc, int event)
> > +{
> > +     int offset, shift, mask;
> > +
> > +     /* 32 events per register */
> > +     offset = event / 32 * 4;
> > +     shift = event % 32;
> > +     mask = 1 << shift;
> > +
> > +     /* type is always pulse (0) */
> > +     regmap_write_bits(intc, TI_PRU_INTC_TYPE0 + offset, mask, 0);
> > +}
> > +
> > +/**
> > + * ti_pru_init_intc_channel_map - configure interrupt event to channel
> mapping
> > + * @intc: the interrtup controller regmap
> > + * @event: the source event
> > + * @ch: the channel to be assigned to the event
> > + */
> > +static void ti_pru_init_intc_channel_map(struct regmap *intc, int
> event, int ch)
> > +{
> > +     int offset, shift, mask, val;
> > +
> > +     /* 4 channels per 32-bit register */
> > +     offset = event / 4 * 4;
> > +     shift = event % 4 * 8;
> > +     mask = 0xff << shift;
> > +     val = ch << shift;
> > +
> > +     regmap_write_bits(intc, TI_PRU_INTC_CHANMAP0 + offset, mask, val);
> > +}
> > +
> > +/**
> > + * ti_pru_init_intc_host_map - configure interrupt channel to host
> mapping
> > + * @intc: the interrtup controller regmap
> > + * @ch: the source channel
> > + * @host: the host interrupt to be assigned to the channel
> > + */
> > +static void ti_pru_init_intc_host_map(struct regmap *intc, int ch, int
> host)
> > +{
> > +     int offset, shift, mask, val;
> > +
> > +     /* 4 hosts per 32-bit register */
> > +     offset = ch / 4 * 4;
> > +     shift = ch % 4 * 8;
> > +     mask = 0xff << shift;
> > +     val = host << shift;
> > +
> > +     regmap_write_bits(intc, TI_PRU_INTC_HOSTMAP0 + offset, mask, val);
> > +}
> > +
> > +static void ti_pru_init_intc(struct regmap *intc,
> > +                          const struct ti_pru_device_info *info)
> > +{
> > +     int arm_to_pru0 = info->pru[TI_PRU0].vq_arm_to_pru_event;
> > +     int arm_to_pru1 = info->pru[TI_PRU1].vq_arm_to_pru_event;
> > +     int pru0_to_arm = info->pru[TI_PRU0].vq_pru_to_arm_event;
> > +     int pru1_to_arm = info->pru[TI_PRU1].vq_pru_to_arm_event;
> > +
> > +     /* set polarity of system events */
> > +     ti_pru_init_intc_polarity(intc, arm_to_pru0);
> > +     ti_pru_init_intc_polarity(intc, arm_to_pru1);
> > +     ti_pru_init_intc_polarity(intc, pru0_to_arm);
> > +     ti_pru_init_intc_polarity(intc, pru1_to_arm);
> > +
> > +     /* set type of system events */
> > +     ti_pru_init_intc_type(intc, arm_to_pru0);
> > +     ti_pru_init_intc_type(intc, arm_to_pru1);
> > +     ti_pru_init_intc_type(intc, pru0_to_arm);
> > +     ti_pru_init_intc_type(intc, pru1_to_arm);
> > +
> > +     /* map system events to channels */
> > +     ti_pru_init_intc_channel_map(intc, arm_to_pru0, 0);
> > +     ti_pru_init_intc_channel_map(intc, arm_to_pru1, 1);
> > +     ti_pru_init_intc_channel_map(intc, pru0_to_arm, 2);
> > +     ti_pru_init_intc_channel_map(intc, pru1_to_arm, 3);
> > +
> > +     /* map channels to host interrupts */
> > +     ti_pru_init_intc_host_map(intc, 0, 0); /* ARM to PRU0 */
> > +     ti_pru_init_intc_host_map(intc, 1, 1); /* ARM to PRU1 */
> > +     ti_pru_init_intc_host_map(intc, 2, 2); /* PRU0 to ARM */
> > +     ti_pru_init_intc_host_map(intc, 3, 3); /* PRU1 to ARM */
> > +
> > +     /* clear system interrupts */
> > +     regmap_write(intc, TI_PRU_INTC_STATIDXCLR, arm_to_pru0);
> > +     regmap_write(intc, TI_PRU_INTC_STATIDXCLR, arm_to_pru1);
> > +     regmap_write(intc, TI_PRU_INTC_STATIDXCLR, pru0_to_arm);
> > +     regmap_write(intc, TI_PRU_INTC_STATIDXCLR, pru1_to_arm);
> > +
> > +     /* enable host interrupts for kicking */
> > +     regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 0); /* ARM to PRU0
> */
> > +     regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 1); /* ARM to PRU1
> */
> > +     regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 2); /* PRU0 to ARM
> */
> > +     regmap_write(intc, TI_PRU_INTC_HSTINTENIDXSET, 3); /* PRU1 to ARM
> */
> > +
> > +     /* enable system events for kicking */
> > +     regmap_write(intc, TI_PRU_INTC_ENIDXSET, arm_to_pru0);
> > +     regmap_write(intc, TI_PRU_INTC_ENIDXSET, arm_to_pru1);
> > +     regmap_write(intc, TI_PRU_INTC_ENIDXSET, pru0_to_arm);
> > +     regmap_write(intc, TI_PRU_INTC_ENIDXSET, pru1_to_arm);
> > +
> > +     /* enable all interrupts */
> > +     regmap_write_bits(intc, TI_PRU_INTC_GLBLEN, 1, 1);
> > +}
>
> We already have a working irq_chip implementation for INTC.
> https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/
> ti-linux-4.14.y/drivers/remoteproc/pruss_intc.c
>
> I think we can leverage directly from that.
>
> This way pru_rproc or client device nodes can easily specify a pruss_intc
> interrupt parent and the
> SYSEVENT number as the irq. Then device drivers can simply use
> request_irq().
>
> example usage here
> https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/
> ti-linux-4.14.y/arch/arm/boot/dts/am33xx.dtsi#line986
> https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/
> ti-linux-4.14.y/drivers/remoteproc/pru_rproc.c#line670




​Is this PRU code on a path to be added to the mainline kernel?​ There is
an increase in the number of available systems which would benefit from
consistent PRU interfaces. If code is not mainlined, or on a mainline path,
some may think it is not usable or ready for production. Is this a
permanent "out-of-tree" and/or "TI-tree" development. Just wondering.

Derald




>
>
>
> > +
> > +static int ti_pru_rproc_probe(struct platform_device *pdev)
> > +{
> > +     struct device *dev = &pdev->dev;
> > +     struct ti_pruss_platform_data *pdata = dev_get_platdata(dev);
> > +     const struct of_device_id *of_id;
> > +     const struct ti_pru_device_info *info;
> > +     struct ti_pru_shared_data *shared;
> > +     struct resource *res;
> > +     int err;
> > +
> > +     of_id = of_match_device(ti_pru_rproc_of_match, dev);
> > +     if (!of_id || !of_id->data)
> > +             return -EINVAL;
> > +
> > +     info = of_id->data;
> > +
> > +     shared = devm_kzalloc(dev, sizeof(*shared), GFP_KERNEL);
> > +
> > +     platform_set_drvdata(pdev, shared);
> > +
> > +     shared->info = &info->shared;
> > +     shared->dev = dev;
> > +
> > +     res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +     shared->base = devm_ioremap_resource(dev, res);
> > +     if (IS_ERR(shared->base)) {
> > +             dev_err(dev, "failed to ioremap resource\n");
> > +             return PTR_ERR(shared->base);
> > +     }
> > +
> > +     shared->intc = devm_regmap_init_mmio(dev,
> > +                             shared->base + shared->info->intc.offset,
> > +                             &ti_pru_intc_regmap_config);
> > +     if (IS_ERR(shared->intc)) {
> > +             dev_err(dev, "failed to init intc regmap\n");
> > +             return PTR_ERR(shared->intc);
> > +     }
> > +
> > +     if (shared->info->cfg.size) {
> > +             shared->cfg = devm_regmap_init_mmio(dev,
> > +                     shared->base + shared->info->cfg.offset,
> > +                     &ti_pru_cfg_regmap_config);
> > +             if (IS_ERR(shared->cfg)) {
> > +                     dev_err(dev, "failed to init cfg regmap\n");
> > +                     return PTR_ERR(shared->cfg);
> > +             }
> > +     }
> > +
> > +     shared->pru[TI_PRU0] = ti_pru_init_one_rproc(shared,
> &info->pru[TI_PRU0],
> > +                                                  TI_PRU0);
> > +     if (IS_ERR(shared->pru[TI_PRU0]))
> > +             return PTR_ERR(shared->pru[TI_PRU0]);
> > +
> > +     shared->pru[TI_PRU1] = ti_pru_init_one_rproc(shared,
> &info->pru[TI_PRU1],
> > +                                                  TI_PRU1);
> > +     if (IS_ERR(shared->pru[TI_PRU1]))
> > +             return PTR_ERR(shared->pru[TI_PRU1]);
> > +
> > +     pm_runtime_enable(dev);
> > +
> > +     err = pm_runtime_get_sync(dev);
> > +     if (err < 0)
> > +             goto err_pm_runtime_disable;
> > +
> > +     if (pdata) {
> > +             err = pdata->deassert_reset(pdev, pdata->reset_name);
> > +             if (err < 0) {
> > +                     dev_err(dev, "Failed to reset pruss\n");
> > +                     goto err_pm_runtime_put;
> > +             }
> > +     }
> > +
> > +     if (shared->cfg) {
> > +             int mask, val;
> > +
> > +             mask = TI_PRU_SYSCFG_IDLE_MODE_MASK |
> TI_PRU_SYSCFG_STANDBY_MODE_MASK;
> > +             val = TI_PRU_SYSCFG_IDLE_MODE_SMART |
> TI_PRU_SYSCFG_STANDBY_MODE_SMART;
> > +             regmap_write_bits(shared->cfg, TI_PRU_CFG_SYSCFG, mask,
> val);
> > +
> > +             mask = TI_PRU_SYSCFG_STANDBY_INIT;
> > +             val = 0;
> > +             regmap_write_bits(shared->cfg, TI_PRU_CFG_SYSCFG, mask,
> val);
> > +
> > +             err = regmap_read_poll_timeout(shared->cfg,
> TI_PRU_CFG_SYSCFG,
> > +                             val, !(val & TI_PRU_SYSCFG_SUB_MWAIT), 5,
> 50);
> > +             if (err < 0) {
> > +                     dev_err(dev, "timeout while enabling pruss\n");
> > +                     goto err_pm_runtime_put;
> > +             }
> > +     }
> > +
> > +     ti_pru_init_intc(shared->intc, info);
>
> This is using a static INTC map right?
> This limits our possibility to use application based INTC mapping.
> There needs to be a way to specify the INTC mapping in the DT and/or
> resource table.
>
> > +
> > +     err = rproc_add(shared->pru[TI_PRU0]);
> > +     if (err < 0)
> > +             goto err_assert_reset;
> > +
> > +     err = rproc_add(shared->pru[TI_PRU1]);
> > +     if (err < 0)
> > +             goto err_del_pru0;
> > +
> > +     return 0;
> > +
> > +err_del_pru0:
> > +     rproc_del(shared->pru[TI_PRU0]);
> > +err_assert_reset:
> > +     if (pdata)
> > +             pdata->assert_reset(pdev, pdata->reset_name);
> > +err_pm_runtime_put:
> > +     pm_runtime_put(dev);
> > +err_pm_runtime_disable:
> > +     pm_runtime_disable(dev);
> > +
> > +     return err;
> > +}
> > +
> > +static int ti_pru_rproc_remove(struct platform_device *pdev)
> > +{
> > +     struct device *dev = &pdev->dev;
> > +     struct ti_pruss_platform_data *pdata = dev_get_platdata(dev);
> > +     struct ti_pru_shared_data *shared = platform_get_drvdata(pdev);
> > +
> > +     rproc_del(shared->pru[TI_PRU1]);
> > +     rproc_del(shared->pru[TI_PRU0]);
> > +     if (pdata)
> > +             pdata->assert_reset(pdev, pdata->reset_name);
> > +     pm_runtime_put(dev);
> > +     pm_runtime_disable(dev);
> > +
> > +     return 0;
> > +}
> > +
> > +static struct platform_driver ti_pru_rproc_driver = {
> > +     .probe  = ti_pru_rproc_probe,
> > +     .remove = ti_pru_rproc_remove,
> > +     .driver = {
> > +             .name = "ti-pru-rproc",
> > +             .of_match_table = ti_pru_rproc_of_match,
> > +     },
> > +};
> > +module_platform_driver(ti_pru_rproc_driver);
> > +
> > +MODULE_AUTHOR("David Lechner <david@lechnology.com>");
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_DESCRIPTION("Remoteproc driver for TI PRU");
> >
>
> --
> cheers,
> -roger
>
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>

[-- Attachment #2: Type: text/html, Size: 37449 bytes --]

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

* Re: [PATCH 5/8] remoteproc: new driver for TI PRU
  2018-06-30 19:02     ` Derald Woods
@ 2018-07-02  8:05       ` Roger Quadros
  0 siblings, 0 replies; 71+ messages in thread
From: Roger Quadros @ 2018-07-02  8:05 UTC (permalink / raw)
  To: Derald Woods
  Cc: David Lechner, linux-remoteproc, devicetree, linux-omap,
	linux-arm-kernel, Ohad Ben-Cohen, Bjorn Andersson, Rob Herring,
	Mark Rutland, Benoît Cousson, Tony Lindgren, Sekhar Nori,
	Kevin Hilman, linux-kernel, Anna, Suman, Tero Kristo

Derald,

On 30/06/18 22:02, Derald Woods wrote:
> 
> 
> On Fri, Jun 29, 2018 at 5:14 AM, Roger Quadros <rogerq@ti.com <mailto:rogerq@ti.com>> wrote:
> 
> 
> 
>     On 24/06/18 00:08, David Lechner wrote:
>     > This adds a new remoteproc driver for TI Programmable Realtime Units
>     > (PRUs).
>     >
>     > This has been tested working on AM1808 (LEGO MINDSTORMS EV3) using the
>     > sample rpmsg client driver.
>     >
>     > Signed-off-by: David Lechner <david@lechnology.com <mailto:david@lechnology.com>>
>     > ---
>     >  MAINTAINERS                       |   5 +
>     >  drivers/remoteproc/Kconfig        |   7 +
>     >  drivers/remoteproc/Makefile       |   1 +
>     >  drivers/remoteproc/ti_pru_rproc.c | 660 ++++++++++++++++++++++++++++++
>     >  4 files changed, 673 insertions(+)
>     >  create mode 100644 drivers/remoteproc/ti_pru_rproc.c

<snip>

> 
>     We already have a working irq_chip implementation for INTC.
>     https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/drivers/remoteproc/pruss_intc.c <https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/drivers/remoteproc/pruss_intc.c>
> 
>     I think we can leverage directly from that.
> 
>     This way pru_rproc or client device nodes can easily specify a pruss_intc interrupt parent and the
>     SYSEVENT number as the irq. Then device drivers can simply use request_irq().
> 
>     example usage here
>     https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/arch/arm/boot/dts/am33xx.dtsi#line986 <https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/arch/arm/boot/dts/am33xx.dtsi#line986>
>     https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/drivers/remoteproc/pru_rproc.c#line670 <https://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-linux-4.14.y/drivers/remoteproc/pru_rproc.c#line670>
> 
> 
> 
> 
> ​Is this PRU code on a path to be added to the mainline kernel?​ There is an increase in the number of available systems which would benefit from consistent PRU interfaces. If code is not mainlined, or on a mainline path, some may think it is not usable or ready for production. Is this a permanent "out-of-tree" and/or "TI-tree" development. Just wondering.
> 

Yes, we constantly upstream our work. We are currently working to get the PRU support upstream.

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

* Re: New remoteproc driver for TI PRU
  2018-06-29 17:44   ` David Lechner
  2018-06-30  0:17     ` Suman Anna
@ 2018-07-02  8:17     ` Roger Quadros
  1 sibling, 0 replies; 71+ messages in thread
From: Roger Quadros @ 2018-07-02  8:17 UTC (permalink / raw)
  To: David Lechner, linux-remoteproc, devicetree, linux-omap,
	linux-arm-kernel
  Cc: Ohad Ben-Cohen, Bjorn Andersson, Rob Herring, Mark Rutland,
	Benoît Cousson, Tony Lindgren, Sekhar Nori, Kevin Hilman,
	linux-kernel, Anna, Suman, Tero Kristo

On 29/06/18 20:44, David Lechner wrote:
> On 06/29/2018 04:58 AM, Roger Quadros wrote:
>> +Suman & Tero
>>
>> Hi David,
>>
>> On 24/06/18 00:08, David Lechner wrote:
>>>
>>> Date: Sat, 23 Jun 2018 15:43:59 -0500
>>> Subject: [PATCH 0/8] New remoteproc driver for TI PRU
>>>
>>> This series adds a new remoteproc driver for the TI Programmable Runtime Unit
>>> (PRU) that is present in some TI Sitara processors. This code has been tested
>>> working on AM1808 (LEGO MINDSTORMS EV3) and AM3358 (BeagleBone Green).
>>
>> This is great. We have been working on something similar and I think it would
>> be great if we can collaborate to get all our needs addressed.
> 
> Yes, I have used the PRU with the TI kernel on BeagleBone so I've seen the TI
> implementation. My primary interest is in the AM1808, which has a far simpler
> PRU than other SoCs. So, I was hoping I could get away with just implementing
> the basic stuff that I need and let TI add the more complex stuff later.
> 

The PRUSS core is essentially the same thing on most of our SoCs. They might
be varying in amount of RAM and integrated modules though. So PRUSS core support
should be scalable across all SoCs.

It is perfectly fine to get basic support in first and add the rest as we go along.

>>
>> Our primary requirement is that it should be possible for a user (e.g. kernel driver) to
>> - request a specific PRU core load a specific firmware blob and boot/stop the PRU.
> 
> For this, I was thinking of suggesting a generic remoteproc provider/consumer
> binding that is similar to other subsystems. For example:
> 
> Provider node has:
> 
>     #remoteproc-cells = <1>;
> 
> And consumer has:
> 
>     remoteprocs = <&pruss 0>, <&pruss 1>;
>     remoteproc-names = "pru0", "pru1";
> 
> The consumer device would be responsible for determining the firmware file
> and for calling the rproc boot function.
> 
> 
>> - configure INTC interrupt mapping based on either resource table or DT
>> - use request_irq to request and use an interrupt.
> 
> I didn't consider creating a new interrupt controller in device tree, but
> that makes sense. I will have to look into it some more.
> 
> 
>> - request access to DRAM/SRAM
> 
> Can the existing device tree bindings for reserved-memory be used for this?
> I would expect the consumer nodes to use this and not the PRUSS provider node.
> 
> 
>> - configure gpimode/miirt/xfr (CFG space)
> 
> I have no idea what this stuff is. :-)
> 
> (This is what I was referring to when I said I was hoping that someone
> else could add more later).
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

* Re: [PATCH 4/8] dt-bindings: add bindings for TI PRU as remoteproc
  2018-06-23 21:08 ` [PATCH 4/8] dt-bindings: add bindings for TI PRU as remoteproc David Lechner
@ 2018-07-03 20:59   ` Rob Herring
  0 siblings, 0 replies; 71+ messages in thread
From: Rob Herring @ 2018-07-03 20:59 UTC (permalink / raw)
  To: David Lechner
  Cc: linux-remoteproc, devicetree, linux-omap, linux-arm-kernel,
	Ohad Ben-Cohen, Bjorn Andersson, Mark Rutland,
	Benoît Cousson, Tony Lindgren, Sekhar Nori, Kevin Hilman,
	linux-kernel

On Sat, Jun 23, 2018 at 04:08:06PM -0500, David Lechner wrote:
> This adds a new binding for the TI Programmable Runtime Unit (PRU)
> as a remoteproc device.
> 
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>  .../bindings/remoteproc/ti_pru_rproc.txt      | 51 +++++++++++++++++++
>  1 file changed, 51 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt b/Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
> new file mode 100644
> index 000000000000..0e80a8db46d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/ti_pru_rproc.txt
> @@ -0,0 +1,51 @@
> +TI Programmable Realtime Unit (PRU)
> +===================================
> +
> +Some TI Sitara SoCs contain a Programmable Realtime Unit subsystem with two
> +processor cores that can be used for hard-realtime tasks.
> +
> +
> +Required properties:
> +--------------------
> +The following are the mandatory properties:
> +
> +- compatible:		Should be one of the following,
> +			    "ti,da850-pru-rproc" for AM18xx/OMAPL138 SoCs
> +			    "ti,am3352-pru-rproc" for AM355x SoCs
> +
> +- reg:			Should contain the memory region for the PRUSS
> +
> +- interrupts: 		Should contain the interrupt number used to receive the
> +			virtualqueue kick interrupts from the PRU (i.e.
> +			PRU_EVTOUT0 and PRU_EVTOUT1)
> +
> +- interrupt-names	Should contain "pru0-vq", "pru1-vq"
> +
> +Optional properties:
> +--------------------
> +
> +- power-domains:	A phandle to the power domain that powers the PRUSS

Only for da850?

> +
> +- ti,hwmods:		Name of the hwmod associated to the PRUSS, which is
> +			typically "pruss"

Only for am3352?

typically? You should enumerate possible values.

> +
> +Example:
> +--------
> +
> +	// AM18xx
> +	pru_rproc: cpu@30000 {

cpu is reserved for cpu nodes.

> +		compatible = "ti,da850-pru-rproc";
> +		reg = <0x30000 0x10000>;
> +		interrupts = <3>, <4>;
> +		interrupt-names = "pru0-vq", "pru1-vq";
> +		power-domains = <&psc0 13>;
> +	};
> +
> +	// AM335x
> +	pru_rproc: cpu@4a300000 {
> +		compatible = "ti,am3352-pru-rproc";
> +		reg = <0x4a300000 0x80000>;
> +		interrupts = <20>, <21>;
> +		interrupt-names = "pru0-vq", "pru1-vq";
> +		ti,hwmods = "pruss";
> +	};

Really need 2 examples?

> -- 
> 2.17.1
> 

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

* Re: New remoteproc driver for TI PRU
  2018-06-30  0:17     ` Suman Anna
@ 2018-08-06 16:32       ` David Lechner
  2018-08-07  1:39         ` Suman Anna
  0 siblings, 1 reply; 71+ messages in thread
From: David Lechner @ 2018-08-06 16:32 UTC (permalink / raw)
  To: Suman Anna, Roger Quadros, linux-remoteproc, devicetree,
	linux-omap, linux-arm-kernel
  Cc: Ohad Ben-Cohen, Bjorn Andersson, Rob Herring, Mark Rutland,
	Benoît Cousson, Tony Lindgren, Sekhar Nori, Kevin Hilman,
	linux-kernel, Tero Kristo

On 06/29/2018 07:17 PM, Suman Anna wrote:
> Hi David,
> 
> On 06/29/2018 12:44 PM, David Lechner wrote:
>> On 06/29/2018 04:58 AM, Roger Quadros wrote:
>>> +Suman & Tero
>>>
>>> Hi David,
>>>
>>> On 24/06/18 00:08, David Lechner wrote:
>>>>
>>>> Date: Sat, 23 Jun 2018 15:43:59 -0500
>>>> Subject: [PATCH 0/8] New remoteproc driver for TI PRU
>>>>
>>>> This series adds a new remoteproc driver for the TI Programmable
>>>> Runtime Unit
>>>> (PRU) that is present in some TI Sitara processors. This code has
>>>> been tested
>>>> working on AM1808 (LEGO MINDSTORMS EV3) and AM3358 (BeagleBone Green).
>>>
>>> This is great. We have been working on something similar and I think
>>> it would
>>> be great if we can collaborate to get all our needs addressed.
>>
>> Yes, I have used the PRU with the TI kernel on BeagleBone so I've seen
>> the TI
>> implementation. My primary interest is in the AM1808, which has a far
>> simpler
>> PRU than other SoCs. So, I was hoping I could get away with just
>> implementing
>> the basic stuff that I need and let TI add the more complex stuff later.
> 
> Thanks for the series. PRUSS is present on many SoCs now, and each with
> their own integration quirks, both in terms of SoC connections as well
> as internal sub-modules within the subsystem. We currently support
> AM335x, AM437x, AM57xx, Keystone 2 based 66AK2G and a newer generation
> AM65x as well. It should be relatively straight-forward to scale this
> for AM1808/OMAP-L138 as well. The move to the standard Common Clock and
> Reset frameworks for clocks with the Davinci chips should make it
> relatively straight-forward for the architecture pieces.
> 
> I will take a look at your series in detail sometime next week, and
> mostly post our series to the upstream lists as well within the next
> couple of weeks so that it is easier for discussion on the upstream lists.
> 

Have you had time to look at this yet? If you are too busy, I can submit
a v2 with the interrupt controller broken out into a separate driver.

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

* Re: New remoteproc driver for TI PRU
  2018-08-06 16:32       ` David Lechner
@ 2018-08-07  1:39         ` Suman Anna
  0 siblings, 0 replies; 71+ messages in thread
From: Suman Anna @ 2018-08-07  1:39 UTC (permalink / raw)
  To: David Lechner, Roger Quadros, linux-remoteproc, devicetree,
	linux-omap, linux-arm-kernel
  Cc: Ohad Ben-Cohen, Mark Rutland, Kevin Hilman, Tony Lindgren,
	Sekhar Nori, linux-kernel, Bjorn Andersson, Tero Kristo,
	Rob Herring, Benoît Cousson

Hi David,

On 08/06/2018 11:32 AM, David Lechner wrote:
> On 06/29/2018 07:17 PM, Suman Anna wrote:
>> Hi David,
>>
>> On 06/29/2018 12:44 PM, David Lechner wrote:
>>> On 06/29/2018 04:58 AM, Roger Quadros wrote:
>>>> +Suman & Tero
>>>>
>>>> Hi David,
>>>>
>>>> On 24/06/18 00:08, David Lechner wrote:
>>>>>
>>>>> Date: Sat, 23 Jun 2018 15:43:59 -0500
>>>>> Subject: [PATCH 0/8] New remoteproc driver for TI PRU
>>>>>
>>>>> This series adds a new remoteproc driver for the TI Programmable
>>>>> Runtime Unit
>>>>> (PRU) that is present in some TI Sitara processors. This code has
>>>>> been tested
>>>>> working on AM1808 (LEGO MINDSTORMS EV3) and AM3358 (BeagleBone Green).
>>>>
>>>> This is great. We have been working on something similar and I think
>>>> it would
>>>> be great if we can collaborate to get all our needs addressed.
>>>
>>> Yes, I have used the PRU with the TI kernel on BeagleBone so I've seen
>>> the TI
>>> implementation. My primary interest is in the AM1808, which has a far
>>> simpler
>>> PRU than other SoCs. So, I was hoping I could get away with just
>>> implementing
>>> the basic stuff that I need and let TI add the more complex stuff later.
>>
>> Thanks for the series. PRUSS is present on many SoCs now, and each with
>> their own integration quirks, both in terms of SoC connections as well
>> as internal sub-modules within the subsystem. We currently support
>> AM335x, AM437x, AM57xx, Keystone 2 based 66AK2G and a newer generation
>> AM65x as well. It should be relatively straight-forward to scale this
>> for AM1808/OMAP-L138 as well. The move to the standard Common Clock and
>> Reset frameworks for clocks with the Davinci chips should make it
>> relatively straight-forward for the architecture pieces.
>>
>> I will take a look at your series in detail sometime next week, and
>> mostly post our series to the upstream lists as well within the next
>> couple of weeks so that it is easier for discussion on the upstream
>> lists.
>>
> 
> Have you had time to look at this yet? If you are too busy, I can submit
> a v2 with the interrupt controller broken out into a separate driver.

Yeah, I worked on it a bit around -rc4 time, but didn't get a chance to
complete the cleanup & testing before I had to shift to some other
tasks. If you are interested, I can share my branch. I will mostly get
back to this towards the latter half of next week. Anyway, I am
expecting 4.19-rc1 to be in a better shape w.r.t Davinci platform as the
genpd and CCF stuff comes in, and the pm_runtime usage for clocking in
my PRUSS drivers will fit well with those available.

regards
Suman

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

end of thread, other threads:[~2018-08-07  1:39 UTC | newest]

Thread overview: 71+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-23 21:08 (unknown), David Lechner
2018-06-23 21:08 ` [PATCH 1/8] remoteproc: add map parameter to da_to_va David Lechner
2018-06-23 21:08 ` [PATCH 2/8] remoteproc: add page lookup for TI PRU to ELF loader David Lechner
2018-06-23 21:08 ` [PATCH 3/8] ARM: OMAP2+: add pdata quirks for PRUSS reset David Lechner
2018-06-23 21:08 ` [PATCH 4/8] dt-bindings: add bindings for TI PRU as remoteproc David Lechner
2018-07-03 20:59   ` Rob Herring
2018-06-23 21:08 ` [PATCH 5/8] remoteproc: new driver for TI PRU David Lechner
2018-06-29 10:14   ` Roger Quadros
2018-06-30 19:02     ` Derald Woods
2018-07-02  8:05       ` Roger Quadros
2018-06-23 21:08 ` [PATCH 6/8] ARM: davinci_all_defconfig: enable PRU remoteproc module David Lechner
2018-06-23 21:08 ` [PATCH 7/8] ARM: dts: da850: add node for PRUSS David Lechner
2018-06-23 21:08 ` [PATCH 8/8] ARM: dts: am33xx: add node for PRU remoteproc David Lechner
2018-06-29  9:58 ` New remoteproc driver for TI PRU Roger Quadros
2018-06-29 17:44   ` David Lechner
2018-06-30  0:17     ` Suman Anna
2018-08-06 16:32       ` David Lechner
2018-08-07  1:39         ` Suman Anna
2018-07-02  8:17     ` Roger Quadros
  -- strict thread matches above, loose matches on Subject: below --
2018-02-12  1:39 (unknown), Alfred Cheuk Chow
2017-08-30 18:32 [PATCH] default implementation for of_find_all_nodes(...) Artur Lorincz
     [not found] ` <1504117946-3958-1-git-send-email-larturus2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-09-24 15:50   ` (unknown), Artur Lorincz
2017-10-06 19:31   ` (unknown), Artur Lorincz
2017-10-08 16:28   ` (unknown), Artur Lorincz
2017-06-23  4:50 (unknown), nkosuta-f+iqBESB6gc
2017-06-10  7:07 (unknown), Youichi Kanno
2017-04-17  4:06 (unknown), nkosuta-f+iqBESB6gc
2017-04-03  6:14 (unknown), Adrian Gillian Bayford
2017-03-20 19:40 (unknown), janepatrick00-VmEwxm1hRrAnxqbYAscKCQ
2017-03-14 17:14 (unknown), nkosuta-f+iqBESB6gc
2017-02-16 21:01 (unknown), Qin's Yanjun
2016-12-14  2:45 (unknown), Mr Friedrich Mayrhofer
2016-11-28  9:58 (unknown), Mr Friedrich Mayrhofer
2016-11-20 22:16 (unknown), Mr Friedrich Mayrhofer
2016-09-30 14:37 (unknown), Maxime Ripard
2016-07-28 17:49 (unknown), Ryan
2016-05-18 16:26 (unknown), Warner Losh
2016-01-11  6:54 (unknown) wangwyy-hl91/bYNON7k1uMJSBkQmQ
2015-09-18 14:57 (unknown), Asia Heritage Foundation
2015-08-29  1:09 (unknown), Zheng Group
2015-08-04 15:37 (unknown), Mark Salter
2015-07-31 11:22 (unknown), Mrs Christy Walton
2015-07-22 14:05 (unknown), Chunfeng Yun
2015-07-06 15:57 (unknown), Maria McCumiskey
2015-05-18 20:00 (unknown), raghu MG
2015-05-05  6:23 (unknown), Alanoud AlFayeza
2015-03-25 20:46 (unknown), Robert Smigielski
2015-03-07 15:29 (unknown), Mr John Wong
2015-02-18 16:14 (unknown), Lee Jones
     [not found] <1570038211.167595.1414613146892.JavaMail.yahoo@jws10056.mail.ne1.yahoo.com>
     [not found] ` <1835234304.171617.1414613165674.JavaMail.yahoo@jws10089.mail.ne1.yahoo.com>
     [not found]   ` <1938862685.172387.1414613200459.JavaMail.yahoo@jws100180.mail.ne1.yahoo.com>
     [not found]     ` <705402329.170339.1414613213653.JavaMail.yahoo@jws10087.mail.ne1.yahoo.com>
     [not found]       ` <760168749.169371.1414613227586.JavaMail.yahoo@jws10082.mail.ne1.yahoo.com>
     [not found]         ` <1233923671.167957.1414613439879.JavaMail.yahoo@jws10091.mail.ne1.yahoo.com>
     [not found]           ` <925985882.172122.1414613520734.JavaMail.yahoo@jws100207.mail.ne1.yahoo.com>
     [not found]             ` <1216694778.172990.1414613570775.JavaMail.yahoo@jws100152.mail.ne1.yahoo.com>
     [not found]               ` <1213035306.169838.1414613612716.JavaMail.yahoo@jws10097.mail.ne1.yahoo.com>
     [not found]                 ` <2058591563.172973.1414613668636.JavaMail.yahoo@jws10089.mail.ne1.yahoo.com>
     [not found]                   ` <1202030640.175493 .1414613712352.JavaMail.yahoo@jws10036.mail.ne1.yahoo.com>
     [not found]                     ` <1111049042.175610.1414613739099.JavaMail.yahoo@jws100165.mail.ne1.yahoo.com>
     [not found]                       ` <574125160.175950.1414613784216.JavaMail.yahoo@jws100158.mail.ne1.yahoo.com>
     [not found]                         ` <1726966600.175552.1414613846198.JavaMail.yahoo@jws100190.mail.ne1.yahoo.com>
     [not found]                           ` <976499752.219775.1414613888129.JavaMail.yahoo@jws100101.mail.ne1.yahoo.com>
     [not found]                             ` <1400960529.171566.1414613936238.JavaMail.yahoo@jws10059.mail.ne1.yahoo.com>
     [not found]                               ` <1333619289.175040.1414613999304.JavaMail.yahoo@jws100196.mail.ne1.yahoo.com>
     [not found]                                 ` <1038759122.176173.1414614054070.JavaMail.yahoo@jws100138.mail.ne1.yahoo.com>
     [not found]                                   ` <1109995533.176150.1414614101940.JavaMail.yahoo@jws100140.mail.ne1.yahoo.com>
     [not found]                                     ` <809474730.174920.1414614143971.JavaMail.yahoo@jws100154.mail.ne1.yahoo.com>
     [not found]                                       ` <1234226428.170349.1414614189490.JavaMail .yahoo@jws10056.mail.ne1.yahoo.com>
     [not found]                                         ` <1122464611.177103.1414614228916.JavaMail.yahoo@jws100161.mail.ne1.yahoo.com>
     [not found]                                           ` <1350859260.174219.1414614279095.JavaMail.yahoo@jws100176.mail.ne1.yahoo.com>
     [not found]                                             ` <1730751880.171557.1414614322033.JavaMail.yahoo@jws10060.mail.ne1.yahoo.com>
     [not found]                                               ` <642429550.177328.1414614367628.JavaMail.yahoo@jws100165.mail.ne1.yahoo.com>
     [not found]                                                 ` <1400780243.20511.1414614418178.JavaMail.yahoo@jws100162.mail.ne1.yahoo.com>
     [not found]                                                   ` <2025652090.173204.1414614462119.JavaMail.yahoo@jws10087.mail.ne1.yahoo.com>
     [not found]                                                     ` <859211720.180077.1414614521867.JavaMail.yahoo@jws100147.mail.ne1.yahoo.com>
     [not found]                                                       ` <258705675.173585.1414614563057.JavaMail.yahoo@jws10078.mail.ne1.yahoo.com>
     [not found]                                                         ` <1773234186.173687.1414614613736.JavaMail.yahoo@jws10078.mail.ne1.yahoo.com>
     [not found]                                                           ` <1132079010.173033.1414614645153.JavaMail.yahoo@jws10066.mail.ne1.ya hoo.com>
     [not found]                                                             ` <1972302405.176488.1414614708676.JavaMail.yahoo@jws100166.mail.ne1.yahoo.com>
     [not found]                                                               ` <1713123000.176308.1414614771694.JavaMail.yahoo@jws10045.mail.ne1.yahoo.com>
     [not found]                                                                 ` <299800233.173413.1414614817575.JavaMail.yahoo@jws10066.mail.ne1.yahoo.com>
     [not found]                                                                   ` <494469968.179875.1414614903152.JavaMail.yahoo@jws100144.mail.ne1.yahoo.com>
     [not found]                                                                     ` <2136945987.171995.1414614942776.JavaMail.yahoo@jws10091.mail.ne1.yahoo.com>
     [not found]                                                                       ` <257674219.177708.1414615022592.JavaMail.yahoo@jws100181.mail.ne1.yahoo.com>
     [not found]                                                                         ` <716927833.181664.1414615075308.JavaMail.yahoo@jws100145.mail.ne1.yahoo.com>
     [not found]                                                                           ` <874940984.178797.1414615132802.JavaMail.yahoo@jws100157.mail.ne1.yahoo.com>
     [not found]                                                                             ` <1283488887.176736.1414615187657.JavaMail.yahoo@jws100183.mail.ne1.yahoo.com>
     [not found]                                                                               ` <777665713.175887.1414615236293.JavaMail.yahoo@jws10083.mail.ne1.yahoo.com>
     [not found]                                                                                 ` <585395776.176325.1 414615298260.JavaMail.yahoo@jws10033.mail.ne1.yahoo.com>
     [not found]                                                                                   ` <178352191.221832.1414615355071.JavaMail.yahoo@jws100104.mail.ne1.yahoo.com>
     [not found]                                                                                     ` <108454213.176606.1414615522058.JavaMail.yahoo@jws10053.mail.ne1.yahoo.com>
     [not found]                                                                                       ` <1617229176.177502.1414615563724.JavaMail.yahoo@jws10030.mail.ne1.yahoo.com>
     [not found]                                                                                         ` <324334617.178254.1414615625247.JavaMail.yahoo@jws10089.mail.ne1.yahoo.com>
     [not found]                                                                                           ` <567135865.82376.1414615664442.JavaMail.yahoo@jws100136.mail.ne1.yahoo.com>
     [not found]                                                                                             ` <764758300.179669.1414615711821.JavaMail.yahoo@jws100107.mail.ne1.yahoo.com>
     [not found]                                                                                               ` <1072855470.183388.1414615775798.JavaMail.yahoo@jws100147.mail.ne1.yahoo.com>
     [not found]                                                                                                 ` <2134283632.173314.1414615831322.JavaMail.yahoo@jws10094.mail.ne1.yahoo.com>
     [not found]                                                                                                   ` <1454491902.178612.1414615875076.JavaMail.yahoo@jws100209.mail.ne1.yahoo.com>
     [not found]                                                                                                     ` <1488091663.147175.1414957674639.JavaMail.yahoo-pZijWUW3o9/uQS8rMknbopOW+3bF1jUfVpNB7YpNyf8@public.gmane.org>
2014-11-02 19:48                                                                                                       ` (unknown) MRS GRACE MANDA
2014-10-06 19:57 (unknown), Omar Hashim
2014-10-06  6:56 (unknown), Suman Tripathi
2014-09-29  3:16 (unknown), Shengchao Guo
2014-09-22  7:45 (unknown), Jingchang Lu
2014-09-20 23:12 (unknown), M.K-YIN
2014-05-24  1:21 (unknown), Loc Ho
2014-03-11  3:29 (unknown), Christian Organization
2014-02-22 15:53 (unknown), Hans de Goede
2014-02-16 11:35 (unknown), Eleazar Molina Molina
2014-02-02 18:31 (unknown), Davor Joja
2014-01-16 16:11 (unknown), Loc Ho
2014-01-16 16:09 (unknown), Loc Ho
2014-01-13 10:32 (unknown), Lothar Waßmann
2014-01-13 10:29 (unknown), Lothar Waßmann
2014-01-11  0:37 (unknown) klightspeed-aslSrjg9ejhWX4hkXwHRhw
2013-12-12  7:30 (unknown), Loc Ho
2013-12-05  7:01 (unknown), Jagan Teki
2013-11-21  5:53 (unknown), Management
2013-11-08 20:28 (unknown) Dave & Angela Dawes
2013-11-01  7:04 (unknown), Xiubo Li
2012-10-05  7:15 (unknown) Robert Schwebel
2012-04-25  6:57 (unknown), jobhunts02

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).