On 8/20/19 2:54 AM, Tero Kristo wrote: > On 20.8.2019 2.20, Suman Anna wrote: >> Hi Tero, >> >> On 8/7/19 2:48 AM, Tero Kristo wrote: >>> Hi, >>> >>> This series adds OMAP PRM driver which initially supports only reset >>> handling. Later on, power domain support can be added to this to get >>> rid of the current OMAP power domain handling code which resides >>> under the mach-omap2 platform directory. Initially, reset data is >>> added for AM3, OMAP4 and DRA7 SoCs. >> >> Wakeup M3 remoteproc driver is fully upstream, so we should be able to >> test that driver as well if you can add the AM4 data. That will also >> unblock my PRUSS. >> >> If you can add the data to others as well, it will help in easier >> migration of the individual drivers, otherwise the ti-sysc interconnect, >> hwmod, and hwmod reset data combinations will all have to be supported >> in code. > > Ok, so you are saying you would need the PRM data for am4 in addition? I > can generate that one also. Yes, if you can include the data for AM4 and OMAP5 as well, then we can convert all the SoCs other than OMAP2/OMAP3 at the same time as per your comment on bindings. Almost all of the active remoteprocs will be covered by these. OMAP3 ISP driver is also fully upstream, so we would have to manage its legacy compatibility. regards Suman > > -Tero > >> >> regards >> Suman >> >>> >>> I've been testing the reset handling logic with OMAP remoteproc >>> driver which has been converted to use generic reset framework. This >>> part is a work in progress, so will be posting patches from that part >>> later on. >>> >>> -Tero >>> >>> -- >>> >> > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
