Message ID | 5cfc0d85-a3f7-b96a-7bc6-c7b0250ed54c@ti.com |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] firmware: ti-sci: changes for v5.3 | expand |
On 6/11/19 10:42 AM, Tero Kristo wrote: > Hi Santosh, > > Here's the collection of the TI SCI firmware changes for 5.3. > > This is based on the keystone clock driver pull request [1], which you > may want to wait until Stephen has picked it up. > This is really going to be problem since both subsystem can go differently. Does the compilation breaks with clock patches ? As long as arm-soc tree doesn't break I don't want to have this clock tree dep. Can you please clarify ? if there is dependency like that then I will need an immutable branch from clock tree which I can pull in and then apply soc patches. If above is not possible, but am afraid, these patches have to wait till the clock patches are available in Linus's tree. Let me know. Regards, Santosh
On 12/06/2019 07:57, santosh.shilimkar@oracle.com wrote: > On 6/11/19 10:42 AM, Tero Kristo wrote: >> Hi Santosh, >> >> Here's the collection of the TI SCI firmware changes for 5.3. >> >> This is based on the keystone clock driver pull request [1], which you >> may want to wait until Stephen has picked it up. >> > This is really going to be problem since both subsystem can go differently. > Does the compilation breaks with clock patches ? As long as arm-soc tree > doesn't break I don't want to have this clock tree dep. > > Can you please clarify ? if there is dependency like that then I will need > an immutable branch from clock tree which I can pull in and then apply > soc patches. With clock patches, it is fine. If you only apply drivers/firmware side changes, the sci-clock driver fails to compile due to the API changes involved. The clock pull-req itself can be considered immutable? > If above is not possible, but am afraid, these patches have to wait till > the clock patches are available in Linus's tree. Looking at the dependencies between the patches, I can actually split the pull-requests slightly differently... If I apply the sci-clk dependant firmware patch via the clock pull-req, rest of the patches don't have dependency and can be pulled independently... It seems there are no merge conflicts either if it is done this way. I think that is probably best, so please ignore this pull-request, I will send an updated one shortly. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki