PRUSS MFD staging driver: status update

PRUSS MFD staging driver: status update

[Philippe Proulx]

Hi Greg.

I am interested in continuing the work of Subhasish Ghosh regarding
TI PRUSS drivers integration on the kernel side. The last LKML reply
I'm aware of is yours, 2 years ago, here:
<https://lkml.org/lkml/2011/7/5/548>, and then there was silence.

Just a quick reminder: PRUSS (Programmable Realtime Unit SubSystem) is a
subsystem on various TI DSPs/SoCs that contains two independent RISC
cores. Each PRU has its own data/instruction RAM. See
<http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem>.

My main objective is to eventually have a soft UART (which relies on a
PRU) integrated into the mainline. Since this would depend on common
routines shared by other drivers using PRUSS (enable/disable the PRUSS
clock, load a firmware, start/stop a specific PRU, configure interrupts,
etc.), common exported PRUSS functions need to be available.

I believe that's what Subhasish Ghosh was trying to do with his PRUSS
MFD staging driver.

Now, what is the status of this? Would you still accept a valid patch
for this "MFD" driver in staging? My idea, however, is more about a set
of common functions that could be used by other "real" drivers. This
means nothing exported to user space, no sysfs, etc., since only kernel
drivers would use them (I don't intend user space drivers to rely on
this; they already have drivers/uio/uio_pruss for this).

Also, at least today, PRUSS is not only part of the DA850 devices, but
also included into OMAP-L1x8/OMAP-L1x7, C674n, AM18xx/AM17XX and
AM335x devices, so I wouldn't mention "DA8XX" in the Kconfig.

Please Cc me in any answer/comment regarding this message.

Thank you if you have any time to look into this,
Phil

Re: PRUSS MFD staging driver: status update

[Greg Kroah-Hartman]

On Tue, Jul 30, 2013 at 02:17:40PM -0400, Philippe Proulx wrote:
> Hi Greg.
> 
> I am interested in continuing the work of Subhasish Ghosh regarding
> TI PRUSS drivers integration on the kernel side. The last LKML reply
> I'm aware of is yours, 2 years ago, here:
> <https://lkml.org/lkml/2011/7/5/548>, and then there was silence.

Then please follow what I suggested there and resend the code, or send
whatever you are proposing.  It's hard to judge vague statements without
seeing the code as to what you wish to have integrated, don't you agree?

thanks,

greg k-h