| Message ID | 20240325210045.153827-1-afd@ti.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | uio: pruss: Deprecate use of this driver | expand |
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 <afd@ti.com> > --- > 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 <gregkh@linuxfoundation.org> 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 <afd@ti.com> > > --- > > 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,
On 3/26/24 11:19 AM, Robert Nelson wrote: > On Tue, Mar 26, 2024 at 12:41 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> 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 <afd@ti.com> >>> --- >>> 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 > > <gregkh@linuxfoundation.org> 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 <afd@ti.com> > > > > --- > > > > 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.
> > 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 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 >>> <gregkh@linuxfoundation.org> 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 <afd@ti.com> >>>>> --- >>>>> 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, 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.
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 Tue, 26 Mar 2024 at 19:02, Andrew Davis <afd@ti.com> 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 <afd@ti.com> 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,
On 4/5/24 10:39 AM, Robert Nelson wrote: > On Tue, Mar 26, 2024 at 12:36 PM Andrew Davis <afd@ti.com> 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, >
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.
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 <afd@ti.com> --- drivers/uio/Kconfig | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)