[<prev] [next>] [day] [month] [year] [list]
Message-ID: <d331a7dc-9fb0-aa05-36e6-3e1373b6fd16@ti.com>
Date: Mon, 2 Jul 2018 11:05:04 +0300
From: Roger Quadros <rogerq@...com>
To: Derald Woods <woods.technical@...il.com>
CC: David Lechner <david@...hnology.com>,
<linux-remoteproc@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-omap@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
Ohad Ben-Cohen <ohad@...ery.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Benoît Cousson <bcousson@...libre.com>,
Tony Lindgren <tony@...mide.com>, Sekhar Nori <nsekhar@...com>,
Kevin Hilman <khilman@...nel.org>,
<linux-kernel@...r.kernel.org>, "Anna, Suman" <s-anna@...com>,
Tero Kristo <t-kristo@...com>
Subject: Re: [PATCH 5/8] remoteproc: new driver for TI PRU
Derald,
On 30/06/18 22:02, Derald Woods wrote:
>
>
> On Fri, Jun 29, 2018 at 5:14 AM, Roger Quadros <rogerq@...com <mailto:rogerq@...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@...hnology.com <mailto:david@...hnology.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
Powered by blists - more mailing lists