From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suman Anna Subject: Re: New remoteproc driver for TI PRU Date: Fri, 29 Jun 2018 19:17:36 -0500 Message-ID: <536d28bd-bcdd-1665-e1c8-828572051cfb@ti.com> References: <20180623210810.21232-1-david@lechnology.com> <8fc18d40-72f5-9215-26f0-1492e3a6c0e7@lechnology.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <8fc18d40-72f5-9215-26f0-1492e3a6c0e7@lechnology.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: David Lechner , Roger Quadros , linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Ohad Ben-Cohen , Mark Rutland , Kevin Hilman , Tony Lindgren , Sekhar Nori , linux-kernel@vger.kernel.org, Bjorn Andersson , Tero Kristo , Rob Herring , =?UTF-8?Q?Beno=c3=aet_Cousson?= List-Id: linux-omap@vger.kernel.org SGkgRGF2aWQsCgpPbiAwNi8yOS8yMDE4IDEyOjQ0IFBNLCBEYXZpZCBMZWNobmVyIHdyb3RlOgo+ IE9uIDA2LzI5LzIwMTggMDQ6NTggQU0sIFJvZ2VyIFF1YWRyb3Mgd3JvdGU6Cj4+ICtTdW1hbiAm IFRlcm8KPj4KPj4gSGkgRGF2aWQsCj4+Cj4+IE9uIDI0LzA2LzE4IDAwOjA4LCBEYXZpZCBMZWNo bmVyIHdyb3RlOgo+Pj4KPj4+IERhdGU6IFNhdCwgMjMgSnVuIDIwMTggMTU6NDM6NTkgLTA1MDAK Pj4+IFN1YmplY3Q6IFtQQVRDSCAwLzhdIE5ldyByZW1vdGVwcm9jIGRyaXZlciBmb3IgVEkgUFJV Cj4+Pgo+Pj4gVGhpcyBzZXJpZXMgYWRkcyBhIG5ldyByZW1vdGVwcm9jIGRyaXZlciBmb3IgdGhl IFRJIFByb2dyYW1tYWJsZQo+Pj4gUnVudGltZSBVbml0Cj4+PiAoUFJVKSB0aGF0IGlzIHByZXNl bnQgaW4gc29tZSBUSSBTaXRhcmEgcHJvY2Vzc29ycy4gVGhpcyBjb2RlIGhhcwo+Pj4gYmVlbiB0 ZXN0ZWQKPj4+IHdvcmtpbmcgb24gQU0xODA4IChMRUdPIE1JTkRTVE9STVMgRVYzKSBhbmQgQU0z MzU4IChCZWFnbGVCb25lIEdyZWVuKS4KPj4KPj4gVGhpcyBpcyBncmVhdC4gV2UgaGF2ZSBiZWVu IHdvcmtpbmcgb24gc29tZXRoaW5nIHNpbWlsYXIgYW5kIEkgdGhpbmsKPj4gaXQgd291bGQKPj4g YmUgZ3JlYXQgaWYgd2UgY2FuIGNvbGxhYm9yYXRlIHRvIGdldCBhbGwgb3VyIG5lZWRzIGFkZHJl c3NlZC4KPiAKPiBZZXMsIEkgaGF2ZSB1c2VkIHRoZSBQUlUgd2l0aCB0aGUgVEkga2VybmVsIG9u IEJlYWdsZUJvbmUgc28gSSd2ZSBzZWVuCj4gdGhlIFRJCj4gaW1wbGVtZW50YXRpb24uIE15IHBy aW1hcnkgaW50ZXJlc3QgaXMgaW4gdGhlIEFNMTgwOCwgd2hpY2ggaGFzIGEgZmFyCj4gc2ltcGxl cgo+IFBSVSB0aGFuIG90aGVyIFNvQ3MuIFNvLCBJIHdhcyBob3BpbmcgSSBjb3VsZCBnZXQgYXdh eSB3aXRoIGp1c3QKPiBpbXBsZW1lbnRpbmcKPiB0aGUgYmFzaWMgc3R1ZmYgdGhhdCBJIG5lZWQg YW5kIGxldCBUSSBhZGQgdGhlIG1vcmUgY29tcGxleCBzdHVmZiBsYXRlci4KClRoYW5rcyBmb3Ig dGhlIHNlcmllcy4gUFJVU1MgaXMgcHJlc2VudCBvbiBtYW55IFNvQ3Mgbm93LCBhbmQgZWFjaCB3 aXRoCnRoZWlyIG93biBpbnRlZ3JhdGlvbiBxdWlya3MsIGJvdGggaW4gdGVybXMgb2YgU29DIGNv bm5lY3Rpb25zIGFzIHdlbGwKYXMgaW50ZXJuYWwgc3ViLW1vZHVsZXMgd2l0aGluIHRoZSBzdWJz eXN0ZW0uIFdlIGN1cnJlbnRseSBzdXBwb3J0CkFNMzM1eCwgQU00Mzd4LCBBTTU3eHgsIEtleXN0 b25lIDIgYmFzZWQgNjZBSzJHIGFuZCBhIG5ld2VyIGdlbmVyYXRpb24KQU02NXggYXMgd2VsbC4g SXQgc2hvdWxkIGJlIHJlbGF0aXZlbHkgc3RyYWlnaHQtZm9yd2FyZCB0byBzY2FsZSB0aGlzCmZv ciBBTTE4MDgvT01BUC1MMTM4IGFzIHdlbGwuIFRoZSBtb3ZlIHRvIHRoZSBzdGFuZGFyZCBDb21t b24gQ2xvY2sgYW5kClJlc2V0IGZyYW1ld29ya3MgZm9yIGNsb2NrcyB3aXRoIHRoZSBEYXZpbmNp IGNoaXBzIHNob3VsZCBtYWtlIGl0CnJlbGF0aXZlbHkgc3RyYWlnaHQtZm9yd2FyZCBmb3IgdGhl IGFyY2hpdGVjdHVyZSBwaWVjZXMuCgpJIHdpbGwgdGFrZSBhIGxvb2sgYXQgeW91ciBzZXJpZXMg aW4gZGV0YWlsIHNvbWV0aW1lIG5leHQgd2VlaywgYW5kCm1vc3RseSBwb3N0IG91ciBzZXJpZXMg dG8gdGhlIHVwc3RyZWFtIGxpc3RzIGFzIHdlbGwgd2l0aGluIHRoZSBuZXh0CmNvdXBsZSBvZiB3 ZWVrcyBzbyB0aGF0IGl0IGlzIGVhc2llciBmb3IgZGlzY3Vzc2lvbiBvbiB0aGUgdXBzdHJlYW0g bGlzdHMuCgo+IAo+Pgo+PiBPdXIgcHJpbWFyeSByZXF1aXJlbWVudCBpcyB0aGF0IGl0IHNob3Vs ZCBiZSBwb3NzaWJsZSBmb3IgYSB1c2VyIChlLmcuCj4+IGtlcm5lbCBkcml2ZXIpIHRvCj4+IC0g cmVxdWVzdCBhIHNwZWNpZmljIFBSVSBjb3JlIGxvYWQgYSBzcGVjaWZpYyBmaXJtd2FyZSBibG9i IGFuZAo+PiBib290L3N0b3AgdGhlIFBSVS4KPiAKPiBGb3IgdGhpcywgSSB3YXMgdGhpbmtpbmcg b2Ygc3VnZ2VzdGluZyBhIGdlbmVyaWMgcmVtb3RlcHJvYwo+IHByb3ZpZGVyL2NvbnN1bWVyCj4g YmluZGluZyB0aGF0IGlzIHNpbWlsYXIgdG8gb3RoZXIgc3Vic3lzdGVtcy4gRm9yIGV4YW1wbGU6 Cj4gCj4gUHJvdmlkZXIgbm9kZSBoYXM6Cj4gCj4gwqDCoMKgwqAjcmVtb3RlcHJvYy1jZWxscyA9 IDwxPjsKPiAKPiBBbmQgY29uc3VtZXIgaGFzOgo+IAo+IMKgwqDCoMKgcmVtb3RlcHJvY3MgPSA8 JnBydXNzIDA+LCA8JnBydXNzIDE+Owo+IMKgwqDCoMKgcmVtb3RlcHJvYy1uYW1lcyA9ICJwcnUw IiwgInBydTEiOwoKV2UgZG8gaGF2ZSBhbiBleGlzdGluZyBBUEkgaW4gcmVtb3RlcHJvYyBjb3Jl IHRvZGF5LApycHJvY19nZXRfYnlfcGhhbmRsZSgpIGZvciB0aGlzLCB0aG91Z2ggaXQgaXMgbm90 IGFzIHNvcGhpc3RpY2F0ZWQgb3IKZGVzaWduZWQgaW4gYSBzdGFuZGFyZCB3YXkgdGhhdCB3ZSBz ZWUgb24gc29tZSBvdGhlciBzdWItc3lzdGVtcy4gT25lCnRoaW5nIHRoYXQncyBjdXJyZW50bHkg bWlzc2luZyBmcm9tIHRoaXMgaXMgYSBzZW5zZSBvZiBleGNsdXNpdmUgYWNjZXNzLAphcyB3ZSBk byB3YW50IHRvIHJlc3RyaWN0IGFjY2VzcyB0byBhIFBSVSB0byBhIHNpbmdsZSBjbGllbnQgYXQg YSB0aW1lLgo+IAo+IFRoZSBjb25zdW1lciBkZXZpY2Ugd291bGQgYmUgcmVzcG9uc2libGUgZm9y IGRldGVybWluaW5nIHRoZSBmaXJtd2FyZSBmaWxlCj4gYW5kIGZvciBjYWxsaW5nIHRoZSBycHJv YyBib290IGZ1bmN0aW9uLgo+IAo+IAo+PiAtIGNvbmZpZ3VyZSBJTlRDIGludGVycnVwdCBtYXBw aW5nIGJhc2VkIG9uIGVpdGhlciByZXNvdXJjZSB0YWJsZSBvciBEVAo+PiAtIHVzZSByZXF1ZXN0 X2lycSB0byByZXF1ZXN0IGFuZCB1c2UgYW4gaW50ZXJydXB0Lgo+IAo+IEkgZGlkbid0IGNvbnNp ZGVyIGNyZWF0aW5nIGEgbmV3IGludGVycnVwdCBjb250cm9sbGVyIGluIGRldmljZSB0cmVlLCBi dXQKPiB0aGF0IG1ha2VzIHNlbnNlLiBJIHdpbGwgaGF2ZSB0byBsb29rIGludG8gaXQgc29tZSBt b3JlLgo+IAoKQ291cGxlIG9mIGl0ZXJhdGlvbnMgb24gb3VyIHZlbmRvciB0cmVlIGFsbCBidXQg cmVzdWx0ZWQgaW4gcmVwcmVzZW50aW5nCnZhcmlvdXMgc3ViLW1vZHVsZXMgYXMgY2hpbGQgbm9k ZXMgLSB0aGlzIGFsbG93cyB0byByZXVzZSBkaWZmZXJlbnQKZHJpdmVycyB0byBkZWFsIHdpdGgg c3BlY2lmaWMgZnVuY3Rpb25hbGl0eSBsaWtlIE1ESU8sIFVBUlQgZXRjLiBUaGUKbnVtYmVyIG9m IHJlZ2lzdGVycyBhY3Jvc3MgYWxsIFBSVVNTIHN1Yi1tb2R1bGVzIGFuZCBTb0NzIGFyZSB0b28g aHVnZQp0byBzdXBwb3J0IHRocm91Z2ggYSBzaW5nbGUgZHJpdmVyLgoKPiAKPj4gLSByZXF1ZXN0 IGFjY2VzcyB0byBEUkFNL1NSQU0KPiAKPiBDYW4gdGhlIGV4aXN0aW5nIGRldmljZSB0cmVlIGJp bmRpbmdzIGZvciByZXNlcnZlZC1tZW1vcnkgYmUgdXNlZCBmb3IgdGhpcz8KClR5cGljYWxseSwg cmVzZXJ2ZWQtbWVtb3J5IGlzIHVzZWQgZm9yIHJlc2VydmluZyByZWdpb25zIGluIEREUiwgbm90 Cm1taW8gc3BhY2VzLiBUaGVyZSBpcyB0aGUgU1JBTSBkcml2ZXIgaW4gZ2VuZXJhbCB0byBkZWFs IHdpdGggb24tY2hpcAptZW1vcmllcy4KCj4gSSB3b3VsZCBleHBlY3QgdGhlIGNvbnN1bWVyIG5v ZGVzIHRvIHVzZSB0aGlzIGFuZCBub3QgdGhlIFBSVVNTIHByb3ZpZGVyCj4gbm9kZS4KCldlIHdp bGwgbmVlZCBhY2Nlc3MgZnJvbSBib3RoLCBhcyB0aGUgcmVtb3RlcHJvYyBjb3JlIGRvZXMgdGhl IGxvYWRpbmcKaW4gZ2VuZXJhbCBsZXZlcmFnaW5nIHNwZWNpZmljIHJwcm9jIG9wcyBmcm9tIGEg cmVtb3RlcHJvYwppbXBsZW1lbnRhdGlvbiBkcml2ZXIuCgo+IAo+IAo+PiAtIGNvbmZpZ3VyZSBn cGltb2RlL21paXJ0L3hmciAoQ0ZHIHNwYWNlKQo+IAo+IEkgaGF2ZSBubyBpZGVhIHdoYXQgdGhp cyBzdHVmZiBpcy4gOi0pCgpUaGVyZSBhcmUgYWxsIHRoZSBkaWZmZXJlbnQgc3ViLW1vZHVsZXMv cmVnaXN0ZXIgc3BhY2VzIGRlYWxpbmcKc3BlY2lmaWNhbGx5IHdpdGggaW50ZXJuYWwgcGlubXV4 ZXMsIHNvbWUgc2VyaWFsL3BhcmFsbGVsIEdQSU8gcGluCm9wZXJhdGlvbnMgZXRjLgoKcmVnYXJk cwpTdW1hbgoKPiAKPiAoVGhpcyBpcyB3aGF0IEkgd2FzIHJlZmVycmluZyB0byB3aGVuIEkgc2Fp ZCBJIHdhcyBob3BpbmcgdGhhdCBzb21lb25lCj4gZWxzZSBjb3VsZCBhZGQgbW9yZSBsYXRlciku Cj4gCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51 eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVh ZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1h cm0ta2VybmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: New remoteproc driver for TI PRU References: <20180623210810.21232-1-david@lechnology.com> <8fc18d40-72f5-9215-26f0-1492e3a6c0e7@lechnology.com> From: Suman Anna Message-ID: <536d28bd-bcdd-1665-e1c8-828572051cfb@ti.com> Date: Fri, 29 Jun 2018 19:17:36 -0500 MIME-Version: 1.0 In-Reply-To: <8fc18d40-72f5-9215-26f0-1492e3a6c0e7@lechnology.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit To: David Lechner , Roger Quadros , linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Ohad Ben-Cohen , Bjorn Andersson , Rob Herring , Mark Rutland , =?UTF-8?Q?Beno=c3=aet_Cousson?= , Tony Lindgren , Sekhar Nori , Kevin Hilman , linux-kernel@vger.kernel.org, Tero Kristo List-ID: 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). > From mboxrd@z Thu Jan 1 00:00:00 1970 From: s-anna@ti.com (Suman Anna) Date: Fri, 29 Jun 2018 19:17:36 -0500 Subject: New remoteproc driver for TI PRU In-Reply-To: <8fc18d40-72f5-9215-26f0-1492e3a6c0e7@lechnology.com> References: <20180623210810.21232-1-david@lechnology.com> <8fc18d40-72f5-9215-26f0-1492e3a6c0e7@lechnology.com> Message-ID: <536d28bd-bcdd-1665-e1c8-828572051cfb@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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). >