mbox series

[0/8] Add hwmod data for IPU & DSP processors/MMUs

Message ID 20170821234818.4755-1-s-anna@ti.com
Headers show
Series Add hwmod data for IPU & DSP processors/MMUs | expand

Message

Suman Anna Aug. 21, 2017, 11:48 p.m. UTC 
Hi Tony,

The following series adds the hwmod data and the corresponding
pdata quirks for the various MMUs associated with the IPU and DSP
processors on DRA7xx/AM57xx SoCs. This is part 1 of the patches
for enabling the MMUs on DRA7 SoCs (OMAP4 and OMAP5 are already
supported on mainline) and providing a baseline for adding the
OMAP remoteproc driver. The hwmod data for the consumers of these
MMUs - IPU and DSP processors is also added on OMAP5 and DRA7 SoCs,
with an update to the OMAP4 ones.

Patches are baselined on your current for-next branch with commit
a70cb93b6c2f ("Merge branch 'omap-for-v4.14/dt-v3' into for-next").

I have tested the patches on current TI DRA7xx/AM57xx boards (DRA7,
DRA72, DRA71, DRA76 EVMs, AM571x & AM572x IDKs and AM57xx BeagleBoard-X15)
as well as the OMAP4 Panda and OMAP5 uEVM.

regards
Suman

Suman Anna (8):
  ARM: DRA7: hwmod data: Add MMU data for IPUs
  ARM: DRA7: hwmod data: Add MMU data for DSPs
  ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs
  ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 DSPs
  ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods
  ARM: OMAP5: hwmod_data: Add data for IPU & DSP processors
  ARM: DRA7: hwmod_data: Add data for IPUs
  ARM: DRA7: hwmod_data: Add data for DSPs

 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   2 -
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  79 +++++++
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 322 +++++++++++++++++++++++++++++
 arch/arm/mach-omap2/pdata-quirks.c         |  11 +-
 4 files changed, 411 insertions(+), 3 deletions(-)

-- 
2.13.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Suman Anna Sept. 22, 2017, 5:18 p.m. UTC | #1 
Tony,

On 08/21/2017 06:48 PM, Suman Anna wrote:
> Hi Tony,

> 

> The following series adds the hwmod data and the corresponding

> pdata quirks for the various MMUs associated with the IPU and DSP

> processors on DRA7xx/AM57xx SoCs. This is part 1 of the patches

> for enabling the MMUs on DRA7 SoCs (OMAP4 and OMAP5 are already

> supported on mainline) and providing a baseline for adding the

> OMAP remoteproc driver. The hwmod data for the consumers of these

> MMUs - IPU and DSP processors is also added on OMAP5 and DRA7 SoCs,

> with an update to the OMAP4 ones.

> 

> Patches are baselined on your current for-next branch with commit

> a70cb93b6c2f ("Merge branch 'omap-for-v4.14/dt-v3' into for-next").

> 

> I have tested the patches on current TI DRA7xx/AM57xx boards (DRA7,

> DRA72, DRA71, DRA76 EVMs, AM571x & AM572x IDKs and AM57xx BeagleBoard-X15)

> as well as the OMAP4 Panda and OMAP5 uEVM.


Ping on this series. Tero's clkctrl series changes are orthogonal to
these changes.

regards
Suman

> 

> regards

> Suman

> 

> Suman Anna (8):

>   ARM: DRA7: hwmod data: Add MMU data for IPUs

>   ARM: DRA7: hwmod data: Add MMU data for DSPs

>   ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs

>   ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 DSPs

>   ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods

>   ARM: OMAP5: hwmod_data: Add data for IPU & DSP processors

>   ARM: DRA7: hwmod_data: Add data for IPUs

>   ARM: DRA7: hwmod_data: Add data for DSPs

> 

>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   2 -

>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c |  79 +++++++

>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 322 +++++++++++++++++++++++++++++

>  arch/arm/mach-omap2/pdata-quirks.c         |  11 +-

>  4 files changed, 411 insertions(+), 3 deletions(-)

> 


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren Sept. 22, 2017, 5:51 p.m. UTC | #2 
* Suman Anna <s-anna@ti.com> [170922 10:19]:
> Ping on this series. Tero's clkctrl series changes are orthogonal to

> these changes.


With patch 5/8 you said earlier "It will still be a shared set
between the MMU and remoteproc drivers, but let me look into
how these get integrated." So was there any conclusion there?

Also, what's the deal with these omap4 changes that I commented
on in 5/8?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Suman Anna Sept. 22, 2017, 9:07 p.m. UTC | #3 
On 09/22/2017 12:51 PM, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [170922 10:19]:

>> Ping on this series. Tero's clkctrl series changes are orthogonal to

>> these changes.

> 

> With patch 5/8 you said earlier "It will still be a shared set

> between the MMU and remoteproc drivers, but let me look into

> how these get integrated." So was there any conclusion there?

> 

> Also, what's the deal with these omap4 changes that I commented

> on in 5/8?


Tony,
So, looking at code, removing modulemode on hwmod does change the
semantics as that will not plug in the clkctrl clk (_omap4_xlate_clkctrl
will return 0) into the hwmod and will fall back. So, this should make
it compatible to the existing code before adding the clkctrl dt nodes,
and Patch 5 will be good to avoid the crash when disabling the processor
nodes. That said, now that the modulemode is controlled by the
ti-clkctrl code, I would expect to get the refcounting for free due to
clk_enable() semantics if the same clkctrl clk is plugged under two
nodes (MMU and processor) and I may not need to remove the modulemode.
One of the main reasons for removing the modulemode is the lack of
refcounting on modulemode in the original code.

In anycase, I need to retest this with all of required patches from Tero
(current mainline does not yet have the clkctrl dt nodes).

Tero,
Do you have these patches rebased onto 4.14-rc1 (preferable if it is
rebased onto Tony's omap-for-v4.15/soc branch. I tried cherry-picking
from your github test branch (based on 4.13-rc3), but am running into
some L3Noc errors once I add the clkctrl dts node patch on Panda4 using NFS.

regards
Suman
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren Sept. 22, 2017, 9:19 p.m. UTC | #4 
* Suman Anna <s-anna@ti.com> [170922 14:08]:
> On 09/22/2017 12:51 PM, Tony Lindgren wrote:

> > * Suman Anna <s-anna@ti.com> [170922 10:19]:

> >> Ping on this series. Tero's clkctrl series changes are orthogonal to

> >> these changes.

> > 

> > With patch 5/8 you said earlier "It will still be a shared set

> > between the MMU and remoteproc drivers, but let me look into

> > how these get integrated." So was there any conclusion there?

> > 

> > Also, what's the deal with these omap4 changes that I commented

> > on in 5/8?

> 

> Tony,

> So, looking at code, removing modulemode on hwmod does change the

> semantics as that will not plug in the clkctrl clk (_omap4_xlate_clkctrl

> will return 0) into the hwmod and will fall back. So, this should make

> it compatible to the existing code before adding the clkctrl dt nodes,

> and Patch 5 will be good to avoid the crash when disabling the processor

> nodes. That said, now that the modulemode is controlled by the

> ti-clkctrl code, I would expect to get the refcounting for free due to

> clk_enable() semantics if the same clkctrl clk is plugged under two

> nodes (MMU and processor) and I may not need to remove the modulemode.

> One of the main reasons for removing the modulemode is the lack of

> refcounting on modulemode in the original code.


OK. Sounds like you can get the refcounting for free just by modifying
the dts as done for example for musb on omap4 in "[PATCH 10/10] ARM:
dts: Use ti-sysc module driver for omap4 musb" in that series. You
will need also the rest of the patches from that series naturally :)

That is as long as MMU and processor are both child devices in the
same interconnect target module.

> In anycase, I need to retest this with all of required patches from Tero

> (current mainline does not yet have the clkctrl dt nodes).


OK

> Tero,

> Do you have these patches rebased onto 4.14-rc1 (preferable if it is

> rebased onto Tony's omap-for-v4.15/soc branch. I tried cherry-picking

> from your github test branch (based on 4.13-rc3), but am running into

> some L3Noc errors once I add the clkctrl dts node patch on Panda4 using NFS.


Yeah I noticed that and emailed Tero about it. It seems to trigger
with built-in musb and DEBUG_KERNEL disabled, not sure what triggers
it. Only happens after the clkctrl nodes are added.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tero Kristo Oct. 12, 2017, 5:50 a.m. UTC | #5 

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

On 23/09/17 00:19, Tony Lindgren wrote:
> * Suman Anna <s-anna@ti.com> [170922 14:08]:

>> On 09/22/2017 12:51 PM, Tony Lindgren wrote:

>>> * Suman Anna <s-anna@ti.com> [170922 10:19]:

>>>> Ping on this series. Tero's clkctrl series changes are orthogonal to

>>>> these changes.

>>>

>>> With patch 5/8 you said earlier "It will still be a shared set

>>> between the MMU and remoteproc drivers, but let me look into

>>> how these get integrated." So was there any conclusion there?

>>>

>>> Also, what's the deal with these omap4 changes that I commented

>>> on in 5/8?

>>

>> Tony,

>> So, looking at code, removing modulemode on hwmod does change the

>> semantics as that will not plug in the clkctrl clk (_omap4_xlate_clkctrl

>> will return 0) into the hwmod and will fall back. So, this should make

>> it compatible to the existing code before adding the clkctrl dt nodes,

>> and Patch 5 will be good to avoid the crash when disabling the processor

>> nodes. That said, now that the modulemode is controlled by the

>> ti-clkctrl code, I would expect to get the refcounting for free due to

>> clk_enable() semantics if the same clkctrl clk is plugged under two

>> nodes (MMU and processor) and I may not need to remove the modulemode.

>> One of the main reasons for removing the modulemode is the lack of

>> refcounting on modulemode in the original code.

> 

> OK. Sounds like you can get the refcounting for free just by modifying

> the dts as done for example for musb on omap4 in "[PATCH 10/10] ARM:

> dts: Use ti-sysc module driver for omap4 musb" in that series. You

> will need also the rest of the patches from that series naturally :)

> 

> That is as long as MMU and processor are both child devices in the

> same interconnect target module.

> 

>> In anycase, I need to retest this with all of required patches from Tero

>> (current mainline does not yet have the clkctrl dt nodes).

> 

> OK

> 

>> Tero,

>> Do you have these patches rebased onto 4.14-rc1 (preferable if it is

>> rebased onto Tony's omap-for-v4.15/soc branch. I tried cherry-picking

>> from your github test branch (based on 4.13-rc3), but am running into

>> some L3Noc errors once I add the clkctrl dts node patch on Panda4 using NFS.

> 

> Yeah I noticed that and emailed Tero about it. It seems to trigger

> with built-in musb and DEBUG_KERNEL disabled, not sure what triggers

> it. Only happens after the clkctrl nodes are added.


In my tree, you can find 4.14-rc1-clkctrl-cleanup branch. It can still 
be considered WIP, as I haven't posted it publicly and am working with 
some late quirks on it.

-Tero

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html