mbox series

[0/8] soc: ti: Add OMAP PRM driver

Message ID 1565164139-21886-1-git-send-email-t-kristo@ti.com (mailing list archive)
Headers show
Series soc: ti: Add OMAP PRM driver | expand

Message

Tero Kristo Aug. 7, 2019, 7:48 a.m. UTC
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.

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

Comments

Suman Anna Aug. 19, 2019, 11:20 p.m. UTC | #1
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.

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
>
Tero Kristo Aug. 20, 2019, 7:54 a.m. UTC | #2
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.

-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
Suman Anna Aug. 20, 2019, 4:51 p.m. UTC | #3
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