mbox series

[v2,0/5] Introduce PRU remoteproc consumer API

Message ID 20201216165239.2744-1-grzegorz.jaszczyk@linaro.org (mailing list archive)
Headers show
Series Introduce PRU remoteproc consumer API | expand

Message

Grzegorz Jaszczyk Dec. 16, 2020, 4:52 p.m. UTC
Hi All,

The Programmable Real-Time Unit and Industrial Communication Subsystem
(PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
RISC cores (Programmable Real-Time Units, or PRUs) for program execution.

There are 3 foundation components for PRUSS subsystem: the PRUSS platform
driver, the PRUSS INTC driver and the PRUSS remoteproc driver. All were
already merged and can be found under:
1) drivers/soc/ti/pruss.c
   Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
2) drivers/irqchip/irq-pruss-intc.c
   Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
3) drivers/remoteproc/pru_rproc.c
   Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml

The programmable nature of the PRUs provide flexibility to implement custom
peripheral interfaces, fast real-time responses, or specialized data handling.
Example of a PRU consumer drivers will be:
  - Software UART over PRUSS
  - PRU-ICSS Ethernet EMAC

In order to make usage of common PRU resources and allow the consumer drivers to
configure the PRU hardware for specific usage the PRU API is introduced.

Patch #3 of this series depends on one not merged remteproc related patch [1].

Please see the individual patches for exact changes in each patch, following is
the only change from v1:
 - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
 which influences patch #1 and patch #2

[1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-anna@ti.com/

Best regards,
Grzegorz

Roger Quadros (1):
  remoteproc: pru: Add pru_rproc_set_ctable() function

Suman Anna (2):
  dt-bindings: remoteproc: Add PRU consumer bindings
  remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots

Tero Kristo (2):
  remoteproc: pru: Add APIs to get and put the PRU cores
  remoteproc: pru: Configure firmware based on client setup

 .../bindings/remoteproc/ti,pru-consumer.yaml  |  64 +++++
 drivers/remoteproc/pru_rproc.c                | 221 +++++++++++++++++-
 include/linux/pruss.h                         |  78 +++++++
 3 files changed, 360 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
 create mode 100644 include/linux/pruss.h

Comments

David Lechner Jan. 4, 2021, 8:11 p.m. UTC | #1
> Please see the individual patches for exact changes in each patch, following is
> the only change from v1:
>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
>  which influences patch #1 and patch #2

It looks like "soc: ti: pruss: Add pruss_{request, release}_mem_region() API"
was also dropped in v2. Was this intentional?
Suman Anna Jan. 6, 2021, 9:05 p.m. UTC | #2
Hi David,

On 1/4/21 2:11 PM, David Lechner wrote:
> 
>> Please see the individual patches for exact changes in each patch, following is
>> the only change from v1:
>>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
>>  which influences patch #1 and patch #2
> 
> It looks like "soc: ti: pruss: Add pruss_{request, release}_mem_region() API"
> was also dropped in v2. Was this intentional?

No, it is not dropped. That patch is part of a different similarly titled
"Introduce PRU platform consumer API" series [1], which is dependent on this
series and is against a different folder (maintainer): drivers/soc/ti.

regards
Suman

[1] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=400787
Mathieu Poirier Jan. 6, 2021, 11:27 p.m. UTC | #3
On Wed, Dec 16, 2020 at 05:52:34PM +0100, Grzegorz Jaszczyk wrote:
> Hi All,
> 
> The Programmable Real-Time Unit and Industrial Communication Subsystem
> (PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
> RISC cores (Programmable Real-Time Units, or PRUs) for program execution.
> 
> There are 3 foundation components for PRUSS subsystem: the PRUSS platform
> driver, the PRUSS INTC driver and the PRUSS remoteproc driver. All were
> already merged and can be found under:
> 1) drivers/soc/ti/pruss.c
>    Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
> 2) drivers/irqchip/irq-pruss-intc.c
>    Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
> 3) drivers/remoteproc/pru_rproc.c
>    Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
> 
> The programmable nature of the PRUs provide flexibility to implement custom
> peripheral interfaces, fast real-time responses, or specialized data handling.
> Example of a PRU consumer drivers will be:
>   - Software UART over PRUSS
>   - PRU-ICSS Ethernet EMAC
> 
> In order to make usage of common PRU resources and allow the consumer drivers to
> configure the PRU hardware for specific usage the PRU API is introduced.
> 
> Patch #3 of this series depends on one not merged remteproc related patch [1].
> 
> Please see the individual patches for exact changes in each patch, following is
> the only change from v1:
>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
>  which influences patch #1 and patch #2
> 
> [1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-anna@ti.com/
> 
> Best regards,
> Grzegorz
> 
> Roger Quadros (1):
>   remoteproc: pru: Add pru_rproc_set_ctable() function
> 
> Suman Anna (2):
>   dt-bindings: remoteproc: Add PRU consumer bindings
>   remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots
> 
> Tero Kristo (2):
>   remoteproc: pru: Add APIs to get and put the PRU cores
>   remoteproc: pru: Configure firmware based on client setup
> 
>  .../bindings/remoteproc/ti,pru-consumer.yaml  |  64 +++++
>  drivers/remoteproc/pru_rproc.c                | 221 +++++++++++++++++-
>  include/linux/pruss.h                         |  78 +++++++

This patchset is giving checkpatch.pl errors and as such will not go further
with this revision.

>  3 files changed, 360 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
>  create mode 100644 include/linux/pruss.h
> 
> -- 
> 2.29.0
>
Suman Anna Jan. 7, 2021, 12:03 a.m. UTC | #4
Hi Mathieu,

On 1/6/21 5:27 PM, Mathieu Poirier wrote:
> On Wed, Dec 16, 2020 at 05:52:34PM +0100, Grzegorz Jaszczyk wrote:
>> Hi All,
>>
>> The Programmable Real-Time Unit and Industrial Communication Subsystem
>> (PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
>> RISC cores (Programmable Real-Time Units, or PRUs) for program execution.
>>
>> There are 3 foundation components for PRUSS subsystem: the PRUSS platform
>> driver, the PRUSS INTC driver and the PRUSS remoteproc driver. All were
>> already merged and can be found under:
>> 1) drivers/soc/ti/pruss.c
>>    Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
>> 2) drivers/irqchip/irq-pruss-intc.c
>>    Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
>> 3) drivers/remoteproc/pru_rproc.c
>>    Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
>>
>> The programmable nature of the PRUs provide flexibility to implement custom
>> peripheral interfaces, fast real-time responses, or specialized data handling.
>> Example of a PRU consumer drivers will be:
>>   - Software UART over PRUSS
>>   - PRU-ICSS Ethernet EMAC
>>
>> In order to make usage of common PRU resources and allow the consumer drivers to
>> configure the PRU hardware for specific usage the PRU API is introduced.
>>
>> Patch #3 of this series depends on one not merged remteproc related patch [1].
>>
>> Please see the individual patches for exact changes in each patch, following is
>> the only change from v1:
>>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
>>  which influences patch #1 and patch #2
>>
>> [1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-anna@ti.com/
>>
>> Best regards,
>> Grzegorz
>>
>> Roger Quadros (1):
>>   remoteproc: pru: Add pru_rproc_set_ctable() function
>>
>> Suman Anna (2):
>>   dt-bindings: remoteproc: Add PRU consumer bindings
>>   remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots
>>
>> Tero Kristo (2):
>>   remoteproc: pru: Add APIs to get and put the PRU cores
>>   remoteproc: pru: Configure firmware based on client setup
>>
>>  .../bindings/remoteproc/ti,pru-consumer.yaml  |  64 +++++
>>  drivers/remoteproc/pru_rproc.c                | 221 +++++++++++++++++-
>>  include/linux/pruss.h                         |  78 +++++++
> 
> This patchset is giving checkpatch.pl errors and as such will not go further
> with this revision.

Yeah, I am aware of those. Greg has intentionally skipped the checkpatch
warnings around ENOTSUPP, based on some similar discussion on a different patch,
https://lkml.org/lkml/2020/11/10/764.

Let me know if you prefer that we change these to EOPNOTSUPP.

regards
Suman

> 
>>  3 files changed, 360 insertions(+), 3 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
>>  create mode 100644 include/linux/pruss.h
>>
>> -- 
>> 2.29.0
>>
Mathieu Poirier Jan. 7, 2021, 10:44 p.m. UTC | #5
On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
> Hi Mathieu,
> 
> On 1/6/21 5:27 PM, Mathieu Poirier wrote:
> > On Wed, Dec 16, 2020 at 05:52:34PM +0100, Grzegorz Jaszczyk wrote:
> >> Hi All,
> >>
> >> The Programmable Real-Time Unit and Industrial Communication Subsystem
> >> (PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
> >> RISC cores (Programmable Real-Time Units, or PRUs) for program execution.
> >>
> >> There are 3 foundation components for PRUSS subsystem: the PRUSS platform
> >> driver, the PRUSS INTC driver and the PRUSS remoteproc driver. All were
> >> already merged and can be found under:
> >> 1) drivers/soc/ti/pruss.c
> >>    Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
> >> 2) drivers/irqchip/irq-pruss-intc.c
> >>    Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
> >> 3) drivers/remoteproc/pru_rproc.c
> >>    Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
> >>
> >> The programmable nature of the PRUs provide flexibility to implement custom
> >> peripheral interfaces, fast real-time responses, or specialized data handling.
> >> Example of a PRU consumer drivers will be:
> >>   - Software UART over PRUSS
> >>   - PRU-ICSS Ethernet EMAC
> >>
> >> In order to make usage of common PRU resources and allow the consumer drivers to
> >> configure the PRU hardware for specific usage the PRU API is introduced.
> >>
> >> Patch #3 of this series depends on one not merged remteproc related patch [1].
> >>
> >> Please see the individual patches for exact changes in each patch, following is
> >> the only change from v1:
> >>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
> >>  which influences patch #1 and patch #2
> >>
> >> [1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-anna@ti.com/
> >>
> >> Best regards,
> >> Grzegorz
> >>
> >> Roger Quadros (1):
> >>   remoteproc: pru: Add pru_rproc_set_ctable() function
> >>
> >> Suman Anna (2):
> >>   dt-bindings: remoteproc: Add PRU consumer bindings
> >>   remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots
> >>
> >> Tero Kristo (2):
> >>   remoteproc: pru: Add APIs to get and put the PRU cores
> >>   remoteproc: pru: Configure firmware based on client setup
> >>
> >>  .../bindings/remoteproc/ti,pru-consumer.yaml  |  64 +++++
> >>  drivers/remoteproc/pru_rproc.c                | 221 +++++++++++++++++-
> >>  include/linux/pruss.h                         |  78 +++++++
> > 
> > This patchset is giving checkpatch.pl errors and as such will not go further
> > with this revision.
> 
> Yeah, I am aware of those. Greg has intentionally skipped the checkpatch
> warnings around ENOTSUPP, based on some similar discussion on a different patch,
> https://lkml.org/lkml/2020/11/10/764.

I only see input from Andy and Lars in the thread you point out, nothing from
Greg.  I have also taken a look at the patch [1] that made checkpatch complain
about ENOTSUPP.  From what I see in that commit log the goal is to prevent new
additions of ENOTSUPP to the kernel.

Please modify and resend, otherwise I'm sure someone will send another patch to
fix it before the end of the cycle.

Thanks,
Mathieu

[1]. 6b9ea5ff5abd checkpatch: warn about uses of ENOTSUPP
> 
> Let me know if you prefer that we change these to EOPNOTSUPP.
> 
> regards
> Suman
> 
> > 
> >>  3 files changed, 360 insertions(+), 3 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
> >>  create mode 100644 include/linux/pruss.h
> >>
> >> -- 
> >> 2.29.0
> >>
>
Suman Anna Jan. 7, 2021, 10:49 p.m. UTC | #6
On 1/7/21 4:44 PM, Mathieu Poirier wrote:
> On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
>> Hi Mathieu,
>>
>> On 1/6/21 5:27 PM, Mathieu Poirier wrote:
>>> On Wed, Dec 16, 2020 at 05:52:34PM +0100, Grzegorz Jaszczyk wrote:
>>>> Hi All,
>>>>
>>>> The Programmable Real-Time Unit and Industrial Communication Subsystem
>>>> (PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
>>>> RISC cores (Programmable Real-Time Units, or PRUs) for program execution.
>>>>
>>>> There are 3 foundation components for PRUSS subsystem: the PRUSS platform
>>>> driver, the PRUSS INTC driver and the PRUSS remoteproc driver. All were
>>>> already merged and can be found under:
>>>> 1) drivers/soc/ti/pruss.c
>>>>    Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
>>>> 2) drivers/irqchip/irq-pruss-intc.c
>>>>    Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
>>>> 3) drivers/remoteproc/pru_rproc.c
>>>>    Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml
>>>>
>>>> The programmable nature of the PRUs provide flexibility to implement custom
>>>> peripheral interfaces, fast real-time responses, or specialized data handling.
>>>> Example of a PRU consumer drivers will be:
>>>>   - Software UART over PRUSS
>>>>   - PRU-ICSS Ethernet EMAC
>>>>
>>>> In order to make usage of common PRU resources and allow the consumer drivers to
>>>> configure the PRU hardware for specific usage the PRU API is introduced.
>>>>
>>>> Patch #3 of this series depends on one not merged remteproc related patch [1].
>>>>
>>>> Please see the individual patches for exact changes in each patch, following is
>>>> the only change from v1:
>>>>  - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
>>>>  which influences patch #1 and patch #2
>>>>
>>>> [1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-anna@ti.com/
>>>>
>>>> Best regards,
>>>> Grzegorz
>>>>
>>>> Roger Quadros (1):
>>>>   remoteproc: pru: Add pru_rproc_set_ctable() function
>>>>
>>>> Suman Anna (2):
>>>>   dt-bindings: remoteproc: Add PRU consumer bindings
>>>>   remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots
>>>>
>>>> Tero Kristo (2):
>>>>   remoteproc: pru: Add APIs to get and put the PRU cores
>>>>   remoteproc: pru: Configure firmware based on client setup
>>>>
>>>>  .../bindings/remoteproc/ti,pru-consumer.yaml  |  64 +++++
>>>>  drivers/remoteproc/pru_rproc.c                | 221 +++++++++++++++++-
>>>>  include/linux/pruss.h                         |  78 +++++++
>>>
>>> This patchset is giving checkpatch.pl errors and as such will not go further
>>> with this revision.
>>
>> Yeah, I am aware of those. Greg has intentionally skipped the checkpatch
>> warnings around ENOTSUPP, based on some similar discussion on a different patch,
>> https://lkml.org/lkml/2020/11/10/764.
> 
> I only see input from Andy and Lars in the thread you point out, nothing from
> Greg.  I have also taken a look at the patch [1] that made checkpatch complain
> about ENOTSUPP.  From what I see in that commit log the goal is to prevent new
> additions of ENOTSUPP to the kernel.
> 
> Please modify and resend, otherwise I'm sure someone will send another patch to
> fix it before the end of the cycle.

Yeah ok. I will send out a v3.

regards
Suman

> 
> Thanks,
> Mathieu
> 
> [1]. 6b9ea5ff5abd checkpatch: warn about uses of ENOTSUPP
>>
>> Let me know if you prefer that we change these to EOPNOTSUPP.
>>
>> regards
>> Suman
>>
>>>
>>>>  3 files changed, 360 insertions(+), 3 deletions(-)
>>>>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml
>>>>  create mode 100644 include/linux/pruss.h
>>>>
>>>> -- 
>>>> 2.29.0
>>>>
>>
Santosh Shilimkar Jan. 25, 2021, 4:34 a.m. UTC | #7
Hi Suman, Mathieu,

On 1/7/21 2:49 PM, Suman Anna wrote:
> On 1/7/21 4:44 PM, Mathieu Poirier wrote:
>> On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
>>> Hi Mathieu,
>>>
[...]
>> I only see input from Andy and Lars in the thread you point out, nothing from
>> Greg.  I have also taken a look at the patch [1] that made checkpatch complain
>> about ENOTSUPP.  From what I see in that commit log the goal is to prevent new
>> additions of ENOTSUPP to the kernel.
>>
>> Please modify and resend, otherwise I'm sure someone will send another patch to
>> fix it before the end of the cycle.
> 
> Yeah ok. I will send out a v3.
> 
I haven't seen v3 of this series yet. Please post it
if you would like to include it for 5.12.

Regards,
Santosh
Suman Anna Jan. 25, 2021, 3:43 p.m. UTC | #8
Hi Santosh,

On 1/24/21 10:34 PM, santosh.shilimkar@oracle.com wrote:
> Hi Suman, Mathieu,
> 
> On 1/7/21 2:49 PM, Suman Anna wrote:
>> On 1/7/21 4:44 PM, Mathieu Poirier wrote:
>>> On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
>>>> Hi Mathieu,
>>>>
> [...]
>>> I only see input from Andy and Lars in the thread you point out, nothing from
>>> Greg.  I have also taken a look at the patch [1] that made checkpatch complain
>>> about ENOTSUPP.  From what I see in that commit log the goal is to prevent new
>>> additions of ENOTSUPP to the kernel.
>>>
>>> Please modify and resend, otherwise I'm sure someone will send another patch to
>>> fix it before the end of the cycle.
>>
>> Yeah ok. I will send out a v3.
>>
> I haven't seen v3 of this series yet. Please post it
> if you would like to include it for 5.12.

This series is dependent on couple of patches that would have to come through
the remoteproc tree first, and I need to post the next versions of those as
well. So, let me sort out those first. You can drop this from your queue for 5.12.

regards
Suman
Santosh Shilimkar Jan. 25, 2021, 3:56 p.m. UTC | #9
On Jan 25, 2021, at 7:43 AM, Suman Anna <s-anna@ti.com> wrote:
> 
> Hi Santosh,
> 
> On 1/24/21 10:34 PM, santosh.shilimkar@oracle.com wrote:
>> Hi Suman, Mathieu,
>> 
>> On 1/7/21 2:49 PM, Suman Anna wrote:
>>> On 1/7/21 4:44 PM, Mathieu Poirier wrote:
>>>> On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
>>>>> Hi Mathieu,
>>>>> 
>> [...]
>>>> I only see input from Andy and Lars in the thread you point out, nothing from
>>>> Greg.  I have also taken a look at the patch [1] that made checkpatch complain
>>>> about ENOTSUPP.  From what I see in that commit log the goal is to prevent new
>>>> additions of ENOTSUPP to the kernel.
>>>> 
>>>> Please modify and resend, otherwise I'm sure someone will send another patch to
>>>> fix it before the end of the cycle.
>>> 
>>> Yeah ok. I will send out a v3.
>>> 
>> I haven't seen v3 of this series yet. Please post it
>> if you would like to include it for 5.12.
> 
> This series is dependent on couple of patches that would have to come through
> the remoteproc tree first, and I need to post the next versions of those as
> well. So, let me sort out those first. You can drop this from your queue for 5.12.
> 
Sounds good.

Regards,
Santosh