This UIO driver was used to control the PRU processors found on various
TI SoCs. It was created before the Remoteproc framework, but now with
that we have a standard way to program and manage the PRU processors.
The proper PRU Remoteproc driver should be used instead of this driver.
Mark this driver deprecated.
The userspace tools to use this are no longer available, so also remove
those dead links from the Kconfig description.
Signed-off-by: Andrew Davis <[email protected]>
---
drivers/uio/Kconfig | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 2e16c5338e5b1..358dc2d19b885 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -126,19 +126,13 @@ config UIO_FSL_ELBC_GPCM_NETX5152
http://www.hilscher.com/netx
config UIO_PRUSS
- tristate "Texas Instruments PRUSS driver"
+ tristate "Texas Instruments PRUSS driver (DEPRECATED)"
select GENERIC_ALLOCATOR
depends on HAS_IOMEM && HAS_DMA
help
PRUSS driver for OMAPL138/DA850/AM18XX devices
- PRUSS driver requires user space components, examples and user space
- driver is available from below SVN repo - you may use anonymous login
- https://gforge.ti.com/gf/project/pru_sw/
-
- More info on API is available at below wiki
-
- http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader
+ This driver is deprecated, replaced by PRU_REMOTEPROC.
To compile this driver as a module, choose M here: the module
will be called uio_pruss.
--
2.39.2
On Mon, Mar 25, 2024 at 04:00:45PM -0500, Andrew Davis wrote:
> This UIO driver was used to control the PRU processors found on various
> TI SoCs. It was created before the Remoteproc framework, but now with
> that we have a standard way to program and manage the PRU processors.
> The proper PRU Remoteproc driver should be used instead of this driver.
> Mark this driver deprecated.
>
> The userspace tools to use this are no longer available, so also remove
> those dead links from the Kconfig description.
>
> Signed-off-by: Andrew Davis <[email protected]>
> ---
> drivers/uio/Kconfig | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 2e16c5338e5b1..358dc2d19b885 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -126,19 +126,13 @@ config UIO_FSL_ELBC_GPCM_NETX5152
> http://www.hilscher.com/netx
>
> config UIO_PRUSS
> - tristate "Texas Instruments PRUSS driver"
> + tristate "Texas Instruments PRUSS driver (DEPRECATED)"
This isn't going to do much, why not just delete the driver entirely if
no one uses it?
thanks,
greg k-h
On Tue, Mar 26, 2024 at 12:41 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Mon, Mar 25, 2024 at 04:00:45PM -0500, Andrew Davis wrote:
> > This UIO driver was used to control the PRU processors found on various
> > TI SoCs. It was created before the Remoteproc framework, but now with
> > that we have a standard way to program and manage the PRU processors.
> > The proper PRU Remoteproc driver should be used instead of this driver.
> > Mark this driver deprecated.
> >
> > The userspace tools to use this are no longer available, so also remove
> > those dead links from the Kconfig description.
> >
> > Signed-off-by: Andrew Davis <[email protected]>
> > ---
> > drivers/uio/Kconfig | 10 ++--------
> > 1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> > index 2e16c5338e5b1..358dc2d19b885 100644
> > --- a/drivers/uio/Kconfig
> > +++ b/drivers/uio/Kconfig
> > @@ -126,19 +126,13 @@ config UIO_FSL_ELBC_GPCM_NETX5152
> > http://www.hilscher.com/netx
> >
> > config UIO_PRUSS
> > - tristate "Texas Instruments PRUSS driver"
> > + tristate "Texas Instruments PRUSS driver (DEPRECATED)"
>
> This isn't going to do much, why not just delete the driver entirely if
> no one uses it?
CC'ing Matthijs one of our BeagleBoard community members who utilizes
and supports UIO on a number of community projects.
We know TI and Mainline in general do not like this UIO driver as it's
very open-ended.
While the remoteproc_pruss driver is now mainline (it has taken a long
time, since 3.14.x i I think TI first started this..)
There is a large user base of UIO examples that have been running
since 3.8.x and as a community we have made sure ( mostly Matthijs )
that these continue to operate on this driver in
v5.x/v6.x/lts/mainline branches.
We can always revert/etc.. But I'm hoping Matthijs will chime-in..
Regards,
--
Robert Nelson
https://rcn-ee.com/
On 3/26/24 11:19 AM, Robert Nelson wrote:
> On Tue, Mar 26, 2024 at 12:41 AM Greg Kroah-Hartman
> <[email protected]> wrote:
>>
>> On Mon, Mar 25, 2024 at 04:00:45PM -0500, Andrew Davis wrote:
>>> This UIO driver was used to control the PRU processors found on various
>>> TI SoCs. It was created before the Remoteproc framework, but now with
>>> that we have a standard way to program and manage the PRU processors.
>>> The proper PRU Remoteproc driver should be used instead of this driver.
>>> Mark this driver deprecated.
>>>
>>> The userspace tools to use this are no longer available, so also remove
>>> those dead links from the Kconfig description.
>>>
>>> Signed-off-by: Andrew Davis <[email protected]>
>>> ---
>>> drivers/uio/Kconfig | 10 ++--------
>>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
>>> index 2e16c5338e5b1..358dc2d19b885 100644
>>> --- a/drivers/uio/Kconfig
>>> +++ b/drivers/uio/Kconfig
>>> @@ -126,19 +126,13 @@ config UIO_FSL_ELBC_GPCM_NETX5152
>>> http://www.hilscher.com/netx
>>>
>>> config UIO_PRUSS
>>> - tristate "Texas Instruments PRUSS driver"
>>> + tristate "Texas Instruments PRUSS driver (DEPRECATED)"
>>
>> This isn't going to do much, why not just delete the driver entirely if
>> no one uses it?
>
> CC'ing Matthijs one of our BeagleBoard community members who utilizes
> and supports UIO on a number of community projects.
>
> We know TI and Mainline in general do not like this UIO driver as it's
> very open-ended.
>
> While the remoteproc_pruss driver is now mainline (it has taken a long
> time, since 3.14.x i I think TI first started this..)
>
> There is a large user base of UIO examples that have been running
> since 3.8.x and as a community we have made sure ( mostly Matthijs )
> that these continue to operate on this driver in
> v5.x/v6.x/lts/mainline branches.
>
These users rely on out-of-tree patches to make this driver usable[0].
In its current state upstream, this driver is not used/usable. Since you
have to make update patches anyway, why not simply carry the whole driver
as an out-of-tree patch?
That is why I was thinking of just marking it deprecated for a cycle
or two, just to give one last hint that it will be going away soon
(or you cancarry the driver out-of-tree for however long you want).
Andrew
[0] https://github.com/beagleboard/linux/commit/d5a2815173b26095fa469e6f428ff55990f51138
> We can always revert/etc.. But I'm hoping Matthijs will chime-in..
>
> Regards,
>
On Tue, Mar 26, 2024 at 12:02:09PM -0500, Andrew Davis wrote:
> On 3/26/24 11:19 AM, Robert Nelson wrote:
> > On Tue, Mar 26, 2024 at 12:41 AM Greg Kroah-Hartman
> > <[email protected]> wrote:
> > >
> > > On Mon, Mar 25, 2024 at 04:00:45PM -0500, Andrew Davis wrote:
> > > > This UIO driver was used to control the PRU processors found on various
> > > > TI SoCs. It was created before the Remoteproc framework, but now with
> > > > that we have a standard way to program and manage the PRU processors.
> > > > The proper PRU Remoteproc driver should be used instead of this driver.
> > > > Mark this driver deprecated.
> > > >
> > > > The userspace tools to use this are no longer available, so also remove
> > > > those dead links from the Kconfig description.
> > > >
> > > > Signed-off-by: Andrew Davis <[email protected]>
> > > > ---
> > > > drivers/uio/Kconfig | 10 ++--------
> > > > 1 file changed, 2 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> > > > index 2e16c5338e5b1..358dc2d19b885 100644
> > > > --- a/drivers/uio/Kconfig
> > > > +++ b/drivers/uio/Kconfig
> > > > @@ -126,19 +126,13 @@ config UIO_FSL_ELBC_GPCM_NETX5152
> > > > http://www.hilscher.com/netx
> > > >
> > > > config UIO_PRUSS
> > > > - tristate "Texas Instruments PRUSS driver"
> > > > + tristate "Texas Instruments PRUSS driver (DEPRECATED)"
> > >
> > > This isn't going to do much, why not just delete the driver entirely if
> > > no one uses it?
> >
> > CC'ing Matthijs one of our BeagleBoard community members who utilizes
> > and supports UIO on a number of community projects.
> >
> > We know TI and Mainline in general do not like this UIO driver as it's
> > very open-ended.
> >
> > While the remoteproc_pruss driver is now mainline (it has taken a long
> > time, since 3.14.x i I think TI first started this..)
> >
> > There is a large user base of UIO examples that have been running
> > since 3.8.x and as a community we have made sure ( mostly Matthijs )
> > that these continue to operate on this driver in
> > v5.x/v6.x/lts/mainline branches.
> >
>
> These users rely on out-of-tree patches to make this driver usable[0].
> In its current state upstream, this driver is not used/usable. Since you
> have to make update patches anyway, why not simply carry the whole driver
> as an out-of-tree patch?
>
> That is why I was thinking of just marking it deprecated for a cycle
> or two, just to give one last hint that it will be going away soon
> (or you cancarry the driver out-of-tree for however long you want).
No one notices "deprecated" stuff, they only notice if the code is
removed. So removing it is the only way to pay attention.
But why are out-of-tree changes needed? If they are needed, why are
they not submitted for us to take so that it is usable by everyone? Or
is the out-of-tree patches also not supposed to be used?
thanks,
greg k-h
I'll write a more in-depth reply when I have a moment, but right now I'd
like to point out that the uio-pruss driver in mainline linux is for the
pru subsystem on the freon/primus family of ARM9-based SoCs (OMAP-L1xx /
AM17xx / AM18xx / TMS320C674x / DA8xx), which is not currently supported
by remoteproc-pru.
--
Matthijs van Duin
> > These users rely on out-of-tree patches to make this driver usable[0].
> > In its current state upstream, this driver is not used/usable. Since you
> > have to make update patches anyway, why not simply carry the whole driver
> > as an out-of-tree patch?
> >
> > That is why I was thinking of just marking it deprecated for a cycle
> > or two, just to give one last hint that it will be going away soon
> > (or you cancarry the driver out-of-tree for however long you want).
>
> No one notices "deprecated" stuff, they only notice if the code is
> removed. So removing it is the only way to pay attention.
>
> But why are out-of-tree changes needed? If they are needed, why are
> they not submitted for us to take so that it is usable by everyone? Or
> is the out-of-tree patches also not supposed to be used?
I saw Matthijs, did chime in, I'll wait for his full reply, we've been
utilizing his knowledge on the pru subsystem to keep the uio driver
alive with our out of tree patches. (and extending it to even newer
TI am57xx devices, which TI didn't want us to do..)
Looking at lore, Matt Porter originally had am335x support in the
initial drop of uio when adding it to the DA850 family.
https://lore.kernel.org/lkml/20121003150058.GB11180@beef/
I'll dig for his v3 to find the real reason on why it was later dropped.
But at some point the remoteproc framework became the preferred
method, so uio patches were not allowed.. (one IP block, two drivers..
Community vs TI/Mainline)
Regards,
--
Robert Nelson
https://rcn-ee.com/
On Tue, Mar 26, 2024 at 12:02:09PM -0500, Andrew Davis wrote:
> These users rely on out-of-tree patches to make this driver usable[0].
> In its current state upstream, this driver is not used/usable.
These patches are to add support for newer PRU-ICSS(G) found on AM335x
and later SoCs. Presumably the mainline driver still works fine as-is
for the original PRUSS for which it was written.
--
Matthijs van Duin
On 3/26/24 12:24 PM, Matthijs van Duin wrote:
> I'll write a more in-depth reply when I have a moment, but right now I'd
> like to point out that the uio-pruss driver in mainline linux is for the
> pru subsystem on the freon/primus family of ARM9-based SoCs (OMAP-L1xx /
> AM17xx / AM18xx / TMS320C674x / DA8xx), which is not currently supported
> by remoteproc-pru.
>
I'll wait for your full reply, but a quick note, for those devices listed
this driver isn't usable either after they all moved to DT. As this driver
never got a DT port and relies on platform data (which is gone for those
couple devices).
Andrew
On 3/26/24 12:12 PM, Greg Kroah-Hartman wrote:
> On Tue, Mar 26, 2024 at 12:02:09PM -0500, Andrew Davis wrote:
>> On 3/26/24 11:19 AM, Robert Nelson wrote:
>>> On Tue, Mar 26, 2024 at 12:41 AM Greg Kroah-Hartman
>>> <[email protected]> wrote:
>>>>
>>>> On Mon, Mar 25, 2024 at 04:00:45PM -0500, Andrew Davis wrote:
>>>>> This UIO driver was used to control the PRU processors found on various
>>>>> TI SoCs. It was created before the Remoteproc framework, but now with
>>>>> that we have a standard way to program and manage the PRU processors.
>>>>> The proper PRU Remoteproc driver should be used instead of this driver.
>>>>> Mark this driver deprecated.
>>>>>
>>>>> The userspace tools to use this are no longer available, so also remove
>>>>> those dead links from the Kconfig description.
>>>>>
>>>>> Signed-off-by: Andrew Davis <[email protected]>
>>>>> ---
>>>>> drivers/uio/Kconfig | 10 ++--------
>>>>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
>>>>> index 2e16c5338e5b1..358dc2d19b885 100644
>>>>> --- a/drivers/uio/Kconfig
>>>>> +++ b/drivers/uio/Kconfig
>>>>> @@ -126,19 +126,13 @@ config UIO_FSL_ELBC_GPCM_NETX5152
>>>>> http://www.hilscher.com/netx
>>>>>
>>>>> config UIO_PRUSS
>>>>> - tristate "Texas Instruments PRUSS driver"
>>>>> + tristate "Texas Instruments PRUSS driver (DEPRECATED)"
>>>>
>>>> This isn't going to do much, why not just delete the driver entirely if
>>>> no one uses it?
>>>
>>> CC'ing Matthijs one of our BeagleBoard community members who utilizes
>>> and supports UIO on a number of community projects.
>>>
>>> We know TI and Mainline in general do not like this UIO driver as it's
>>> very open-ended.
>>>
>>> While the remoteproc_pruss driver is now mainline (it has taken a long
>>> time, since 3.14.x i I think TI first started this..)
>>>
>>> There is a large user base of UIO examples that have been running
>>> since 3.8.x and as a community we have made sure ( mostly Matthijs )
>>> that these continue to operate on this driver in
>>> v5.x/v6.x/lts/mainline branches.
>>>
>>
>> These users rely on out-of-tree patches to make this driver usable[0].
>> In its current state upstream, this driver is not used/usable. Since you
>> have to make update patches anyway, why not simply carry the whole driver
>> as an out-of-tree patch?
>>
>> That is why I was thinking of just marking it deprecated for a cycle
>> or two, just to give one last hint that it will be going away soon
>> (or you cancarry the driver out-of-tree for however long you want).
>
> No one notices "deprecated" stuff, they only notice if the code is
> removed. So removing it is the only way to pay attention.
>
Easy enough, will remove completely for v2.
> But why are out-of-tree changes needed? If they are needed, why are
> they not submitted for us to take so that it is usable by everyone? Or
> is the out-of-tree patches also not supposed to be used?
>
The out-of-tree patches should not be used and are only for backwards
compatibility with folks who have not updated to using the proper
remoteproc/rpmsg driver for PRU. Removing this driver would normally
be a userspace break (which we should obviously avoid), but since
the ability to actually use this driver never made it fully upstream
I see no issue.
And we shouldn't try to now upstream the full usable support for this
UIO driver at this point as we have a proper kernel driver for this hardware
upstream now.
(I'd argue most of UIO should not be used as it ends up just being a
hacky way to avoid writing proper kernel drivers for hardware, but that
is a different topic :))
Andrew
> thanks,
>
> greg k-h
On Tue, 26 Mar 2024 at 19:02, Andrew Davis <[email protected]> wrote:
>
> On 3/26/24 12:24 PM, Matthijs van Duin wrote:
> > I'll write a more in-depth reply when I have a moment, but right now I'd
> > like to point out that the uio-pruss driver in mainline linux is for the
> > pru subsystem on the freon/primus family of ARM9-based SoCs (OMAP-L1xx /
> > AM17xx / AM18xx / TMS320C674x / DA8xx), which is not currently supported
> > by remoteproc-pru.
> >
>
> I'll wait for your full reply, but a quick note, for those devices listed
> this driver isn't usable either after they all moved to DT. As this driver
> never got a DT port and relies on platform data (which is gone for those
> couple devices).
Ah I wasn't aware of that. But then the reasoning for removal is "we
broke this driver a long time and nobody seems to care enough to fix
it" rather than saying they should use remoteproc, which does not
support these devices.
Matthijs
On Tue, Mar 26, 2024 at 12:36 PM Andrew Davis <[email protected]> wrote:
>
> On 3/26/24 12:24 PM, Matthijs van Duin wrote:
> > I'll write a more in-depth reply when I have a moment, but right now I'd
> > like to point out that the uio-pruss driver in mainline linux is for the
> > pru subsystem on the freon/primus family of ARM9-based SoCs (OMAP-L1xx /
> > AM17xx / AM18xx / TMS320C674x / DA8xx), which is not currently supported
> > by remoteproc-pru.
> >
>
> I'll wait for your full reply, but a quick note, for those devices listed
> this driver isn't usable either after they all moved to DT. As this driver
> never got a DT port and relies on platform data (which is gone for those
> couple devices).
>
> Andrew
Andrew, I think we are okay with nuking the whole uio driver in
mainline, I'll ack it..
I figured we'd have more community response.. We gave them a chance..
The only issue I personally have with supporting remoteproc-pruss
We have a few users on 4.19.x-ti, 5.10.x-ti (remoteproc_pruss) can we
please make sure this project:
https://git.ti.com/gitweb?p=pru-software-support-package/pru-software-support-package.git;a=summary
actually works on mainline remoteproc_pruss ?
Watching the shortlog, it must break on every single TI LTS release:
https://git.ti.com/gitweb?p=pru-software-support-package/pru-software-support-package.git;a=shortlog
Whereas uio... well same firmware from 3.8.x ;)
(i will keep our uio fork alive, but we just use an overlay to switch
to between remoteproc_pruss and uio)
Regards,
--
Robert Nelson
https://rcn-ee.com/
On 4/5/24 10:39 AM, Robert Nelson wrote:
> On Tue, Mar 26, 2024 at 12:36 PM Andrew Davis <[email protected]> wrote:
>>
>> On 3/26/24 12:24 PM, Matthijs van Duin wrote:
>>> I'll write a more in-depth reply when I have a moment, but right now I'd
>>> like to point out that the uio-pruss driver in mainline linux is for the
>>> pru subsystem on the freon/primus family of ARM9-based SoCs (OMAP-L1xx /
>>> AM17xx / AM18xx / TMS320C674x / DA8xx), which is not currently supported
>>> by remoteproc-pru.
>>>
>>
>> I'll wait for your full reply, but a quick note, for those devices listed
>> this driver isn't usable either after they all moved to DT. As this driver
>> never got a DT port and relies on platform data (which is gone for those
>> couple devices).
>>
>> Andrew
>
> Andrew, I think we are okay with nuking the whole uio driver in
> mainline, I'll ack it..
>
Okay, will send that patch.
> I figured we'd have more community response.. We gave them a chance..
>
> The only issue I personally have with supporting remoteproc-pruss
>
> We have a few users on 4.19.x-ti, 5.10.x-ti (remoteproc_pruss) can we
> please make sure this project:
>
> https://git.ti.com/gitweb?p=pru-software-support-package/pru-software-support-package.git;a=summary
>
> actually works on mainline remoteproc_pruss ?
>
> Watching the shortlog, it must break on every single TI LTS release:
>
Yeah, before we got the remoteproc driver upstream we managed
to break it just about every LTS, it *should* be a bit more
stable now that it is upstream..
> https://git.ti.com/gitweb?p=pru-software-support-package/pru-software-support-package.git;a=shortlog
>
> Whereas uio... well same firmware from 3.8.x ;)
>
That is one benefit of the microkernel style "just expose raw memory
to userspace as a driver", it sure looks simple :)
Andrew
> (i will keep our uio fork alive, but we just use an overlay to switch
> to between remoteproc_pruss and uio)
>
> Regards,
>