Dave Gerlach <d-gerlach@xxxxxx> writes: > On 08/09/2013 12:11 AM, Tony Lindgren wrote: >> * Dave Gerlach <d-gerlach@xxxxxx> [130808 09:23]: >>> On 08/08/2013 08:44 AM, Santosh Shilimkar wrote: >>>> Lets address the above better. I don't see a need of 8 functions >>>> exported doing one or 2 register writes. >>>> >>>> Look M3 based handling is going to be there on future SOCs >>>> as well and this kind of handling of IPC is very short cited. >>>> >>> >>> The idea here was to move all control module register accesses into >>> one file in planning of implementing a driver for the control module >>> itself in the future. >>> >>>> Probably we should have a separate driver for M3 in linux which >>>> can have all this local code instead of all these exports. >>> >>> The wkup_m3 code has been moved to a small driver found in patch 8 >>> of this series, would it better to move this code there rather than >>> with the rest of the control module code? >> >> Please make everything you can into regular device drivers. >> >> We still have some dependencies to mach-omap2 code for PRCM >> for example, but we're trying to get all that to live in >> drivers. >> >> So for new pieces, let's not add further dependencies to >> complicate moving things to drivers. >> >> Regards, >> >> Tony >> > > Ok I will go ahead and pull the control module code that handles IPC > into the wkup_m3 driver. Any control module register access still needs to stay in control.c. > The wkup_m3.c file is still present in mach-omap2 as the right > location for it wasn't decided in the last RFC. Any thoughts on a good > location for it? I raised this also in earlier reviews, but don't remember the if it was answered... Why can't we handle the wkup_m3 using remoteproc/rpmsg instead of creating another little driver that duplicates communication with the M3. Note also that the firmware load part would also be provided by remoteproc/rpmsg. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
