mbox series

[PATCHv3,00/10] clk: ti: remoteproc / iommu support patches

Message ID 20190912132613.28093-1-t-kristo@ti.com (mailing list archive)
Headers show
Series clk: ti: remoteproc / iommu support patches | expand

Message

Tero Kristo Sept. 12, 2019, 1:26 p.m. UTC
Hi,

V3 of this series sort of reverted back to pretty much V1 which expects
strict sequencing of events from the bus driver. This one doesn't have
any dependency towards the reset driver either, and the controversial
reset handling APIs have been removed.

-Tero


--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Comments

Tero Kristo Oct. 10, 2019, 8:34 a.m. UTC | #1
On 12/09/2019 16:26, Tero Kristo wrote:
> Hi,
> 
> V3 of this series sort of reverted back to pretty much V1 which expects
> strict sequencing of events from the bus driver. This one doesn't have
> any dependency towards the reset driver either, and the controversial
> reset handling APIs have been removed.
> 
> -Tero

Stephen, any comments on this one or shall I just craft a pull-request 
for this and rest of the TI clock driver changes towards 5.5? There 
seems to be a pile of them coming this time over...

-Tero

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Tony Lindgren Oct. 10, 2019, 2:35 p.m. UTC | #2
* Tero Kristo <t-kristo@ti.com> [191010 08:34]:
> On 12/09/2019 16:26, Tero Kristo wrote:
> > Hi,
> > 
> > V3 of this series sort of reverted back to pretty much V1 which expects
> > strict sequencing of events from the bus driver. This one doesn't have
> > any dependency towards the reset driver either, and the controversial
> > reset handling APIs have been removed.
> > 
> > -Tero
> 
> Stephen, any comments on this one or shall I just craft a pull-request for
> this and rest of the TI clock driver changes towards 5.5? There seems to be
> a pile of them coming this time over...

Sounds like we need an immutable branch for the clkctrl related
changes against v5.4-rc1 that I can also merge into omap-for-v5.5/prm
branch in addition to the immutable prm reset driver branch.

Otherwise I can't apply any of the consumer device related dts
changes into that branch AFAIK.

Regards,

Tony
Tero Kristo Oct. 10, 2019, 3:32 p.m. UTC | #3
On 10/10/2019 17:35, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [191010 08:34]:
>> On 12/09/2019 16:26, Tero Kristo wrote:
>>> Hi,
>>>
>>> V3 of this series sort of reverted back to pretty much V1 which expects
>>> strict sequencing of events from the bus driver. This one doesn't have
>>> any dependency towards the reset driver either, and the controversial
>>> reset handling APIs have been removed.
>>>
>>> -Tero
>>
>> Stephen, any comments on this one or shall I just craft a pull-request for
>> this and rest of the TI clock driver changes towards 5.5? There seems to be
>> a pile of them coming this time over...
> 
> Sounds like we need an immutable branch for the clkctrl related
> changes against v5.4-rc1 that I can also merge into omap-for-v5.5/prm
> branch in addition to the immutable prm reset driver branch.
> 
> Otherwise I can't apply any of the consumer device related dts
> changes into that branch AFAIK.

Well, the sgx patch you can probably merge, as it will fail silently and 
only cause issues if you actually try to enable the device.

However, yes I agree, we should probably setup an immutable branch here.

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Tero Kristo Oct. 24, 2019, 12:28 p.m. UTC | #4
On 10/10/2019 18:32, Tero Kristo wrote:
> On 10/10/2019 17:35, Tony Lindgren wrote:
>> * Tero Kristo <t-kristo@ti.com> [191010 08:34]:
>>> On 12/09/2019 16:26, Tero Kristo wrote:
>>>> Hi,
>>>>
>>>> V3 of this series sort of reverted back to pretty much V1 which expects
>>>> strict sequencing of events from the bus driver. This one doesn't have
>>>> any dependency towards the reset driver either, and the controversial
>>>> reset handling APIs have been removed.
>>>>
>>>> -Tero
>>>
>>> Stephen, any comments on this one or shall I just craft a 
>>> pull-request for
>>> this and rest of the TI clock driver changes towards 5.5? There seems 
>>> to be
>>> a pile of them coming this time over...
>>
>> Sounds like we need an immutable branch for the clkctrl related
>> changes against v5.4-rc1 that I can also merge into omap-for-v5.5/prm
>> branch in addition to the immutable prm reset driver branch.
>>
>> Otherwise I can't apply any of the consumer device related dts
>> changes into that branch AFAIK.
> 
> Well, the sgx patch you can probably merge, as it will fail silently and 
> only cause issues if you actually try to enable the device.
> 
> However, yes I agree, we should probably setup an immutable branch here.

Queued this series towards 5.5, thanks.

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Stephen Boyd Oct. 28, 2019, 2:43 p.m. UTC | #5
Quoting Tero Kristo (2019-10-24 05:28:23)
> On 10/10/2019 18:32, Tero Kristo wrote:
> > On 10/10/2019 17:35, Tony Lindgren wrote:
> >> * Tero Kristo <t-kristo@ti.com> [191010 08:34]:
> >>> Stephen, any comments on this one or shall I just craft a 
> >>> pull-request for
> >>> this and rest of the TI clock driver changes towards 5.5? There seems 
> >>> to be
> >>> a pile of them coming this time over...
> >>
> >> Sounds like we need an immutable branch for the clkctrl related
> >> changes against v5.4-rc1 that I can also merge into omap-for-v5.5/prm
> >> branch in addition to the immutable prm reset driver branch.
> >>
> >> Otherwise I can't apply any of the consumer device related dts
> >> changes into that branch AFAIK.
> > 
> > Well, the sgx patch you can probably merge, as it will fail silently and 
> > only cause issues if you actually try to enable the device.
> > 
> > However, yes I agree, we should probably setup an immutable branch here.
> 
> Queued this series towards 5.5, thanks.
> 

One minor comment. Otherwise looks fine. Thanks.