mbox series

[GIT,PULL] firmware: ti-sci: changes for v5.3

Message ID 5cfc0d85-a3f7-b96a-7bc6-c7b0250ed54c@ti.com
State New
Headers show
Series [GIT,PULL] firmware: ti-sci: changes for v5.3 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux

Message

Tero Kristo June 11, 2019, 5:42 p.m. UTC
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.

-Tero

[1]: https://www.spinics.net/lists/arm-kernel/msg733157.html

---

The following changes since commit 3f1f22d8009035a641a359a09239bcc6ffac7bb9:

   clk: keystone: sci-clk: extend clock IDs to 32 bits (2019-06-07 
12:11:41 +0300)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux 
tags/ti-sci-for-5.3

for you to fetch changes up to f9ff858a26cf36c01d16a1ea560280164465c7cd:

   firmware: ti_sci: Parse all resource ranges even if some is not 
available (2019-06-11 15:47:42 +0300)

----------------------------------------------------------------
Firmware - TI SCI changes for 5.3.

- Couple of fixes to handle resource ranges and requesting response
   always from firmware; these are only critical for upcoming j721e and
   DMA support
- Add processor control
- Add support APIs for DMA
- Add support for 32bit clock identifiers

----------------------------------------------------------------
Andrew F. Davis (1):
       firmware: ti_sci: Always request response from firmware

Peter Ujfalusi (2):
       firmware: ti_sci: Add resource management APIs for ringacc, psi-l 
and udma
       firmware: ti_sci: Parse all resource ranges even if some is not 
available

Suman Anna (1):
       firmware: ti_sci: Add support for processor control

Tero Kristo (1):
       firmware: ti_sci: extend clock identifiers from u8 to u32

  drivers/firmware/ti_sci.c              | 1228 
+++++++++++++++++++++++++++-----
  drivers/firmware/ti_sci.h              |  873 ++++++++++++++++++++++-
  include/linux/soc/ti/ti_sci_protocol.h |  274 ++++++-
  3 files changed, 2185 insertions(+), 190 deletions(-)
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Comments

Santosh Shilimkar June 12, 2019, 4:57 a.m. UTC | #1
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
Tero Kristo June 12, 2019, 11:39 a.m. UTC | #2
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