Re: [PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support

2015-01-23 Thread Paul Walmsley 
Hi Tony 

thought about this some more overnight...

On Fri, 23 Jan 2015, Paul Walmsley wrote:

 On Tue, 20 Jan 2015, Tony Lindgren wrote:

  +/* L3 Interconnect entries */
  +static struct omap_hwmod dm816x_l3_s_hwmod = {
  +   .name   = l3_s,
 
 Would suggest naming this l3_slow
 
  +   .clkdm_name = alwon_l3s_clkdm,
  +   .class  = l3_hwmod_class,
  +   .flags  = HWMOD_NO_IDLEST,
  +};
  +
  +static struct omap_hwmod __used dm816x_l3_med_hwmod = {
 
 Hmm, why __used for this -- maybe just add it to the hwmod list at the 
 bottom?
 
  +   .name   = l3_med,
  +   .clkdm_name = alwon_l3_med_clkdm,
  +   .class  = l3_hwmod_class,
  +   .flags  = HWMOD_NO_IDLEST,
  +};
  +
  +static struct omap_hwmod __used dm816x_l3_fast_hwmod = {
 
 Same __used comment as above.

Looking at the TRM CLKSTCTRL registers for the various L3 buses, it 
occurred to me that if we wanted to portray this accurately, we'd 
probably need separate hwmods for the ALWON and DEFAULT branches of the L3 
as well.  So there would be six in total: 
{alwon,default}_l3_{slow,med,fast}.  

It looks like it's possible to roughly figure out which targets are 
associated with which variant of the L3 by looking at the CLKACTIVITY 
bits.  So for example, it looks like most of the L3 Slow targets are on 
ALWON_L3_SLOW according to Table 18-136 CM_ALWON_L3_SLOW_CLKSTCTRL 
Register Field descriptions, with the exception of USB, which appears to 
be on DEFAULT_L3_SLOW according to Table 18-80 
CM_DEFAULT_L3_SLOW_CLKSTCTRL Register Field Descriptions.

Anyway, I'm sorry to put you through this, reverse-engineering this stuff 
isn't very pleasant :-(  After reflecting on the matter, I would be OK to 
ack the merge of the original L3-related hwmod data that you proposed, 
with two changes:

- dropping the __used and adding the two hwmods to the list at the bottom, 
assuming that the system still boots in that configuration (i.e., if it 
doesn't cause problems with the clockdomain programming, since it might 
appear that there are no devices/clocks active in those clockdomains)

- adding a comment noting that there probably should be six L3 hwmods as 
described above, but that this is left for future work

It would still be cool if you could doublecheck the SYSC/SYSS data for the 
other IP blocks that are listed below.

  +   .name   = l3_fast,
  +   .clkdm_name = alwon_l3_fast_clkdm,
  +   .class  = l3_hwmod_class,
  +   .flags  = HWMOD_NO_IDLEST,
  +};

See below, I screwed up the review comment ordering here...

  +
  +/*
  + * L4 standard peripherals, see TRM table 1-12 for devices using this.
  + * Devices using this have 125MHz SYSCLK5 clock.
  + */
  +static struct omap_hwmod dm816x_l4_ls_hwmod = {
  +   .name   = l4_ls,
  +   .clkdm_name = alwon_l3s_clkdm,
  +   .class  = l4_hwmod_class,
  +   .flags  = HWMOD_NO_IDLEST,
 
 Section 18.7.17.46 CM_ALWON_L3_CLKCTRL Register lists an IDLEST bitfield 
 for this.

Well I meant for this comment to be attached to the l3_fast hwmod.  But 
thinking about it further, I think this IDLEST is actually associated with 
the L3 configuration *register target*, rather than the L3 itself.  This 
appears to be located at 0x4400, according to the memory map in 
Section 1.5.1.  Register targets are usually what the IDLEST bits are 
intended to protect.  So I think it's OK to keep HWMOD_NO_IDLEST for the 
l3_fast hwmod, and then later to add a separate hwmod for the L3 config 
space.

What I meant to write was:

Section 18.7.17.48 CM_ALWON_L4LS_CLKCTRL Register lists an IDLEST   
bitfield for this.

  +};
  +
  +/*
  + * L4 high-speed peripherals. For devices using this, please see the TRM
  + * Table 1-13. L4 High-Speed Peripheral Memory Map. On dm816x, only
  + * EMAC, MDIO and SATA use this.
  + */
  +static struct omap_hwmod dm816x_l4_hs_hwmod = {
  +   .name   = l4_hs,
  +   .clkdm_name = alwon_l3_med_clkdm,
  +   .class  = l4_hwmod_class,
  +   .flags  = HWMOD_NO_IDLEST,
 
 Section 18.7.17.47 CM_ALWON_L4HS_CLKCTRL Register lists an IDLEST 
 bitfield for this.
 

[ ... ]

 The 816x TRM is pretty crappy when it comes to integration documentation, 
 so it's not so easy to figure out what IP blocks are connected to which 
 initiators.  (Maybe it doesn't even matter that much in the long run; I 
 doubt anyone is going to spend much time on PM or DMA path hacking for 
 these DM816x chips.)  Anyway, I think it's pretty safe to assume that any 
 IP block with a 128-bit or 64-bit initiator port onto the interconnect 
 probably isn't connected to the L3 Slow interconnect.  So looking at 
 Figure 1-75 L3 Interconnect Block Diagram and Section 1.11.2.2 L3 Port 
 Mapping this includes the MPU L3 port, HDVICP2-{0,1,2} initiator ports, 
 IOMMU, DSP, TPTC, TPCC, VPSS M0/M1 ports, SGX, Media Controller, expansion 
 slot 0 initiator, EMIF0/1, and PCIe.Similarly I'd assume that anything

Re: [PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support

2015-01-23 Thread Tony Lindgren 
* Paul Walmsley p...@pwsan.com [150123 10:24]:
 Hi Tony 
 
 thought about this some more overnight...
 
 On Fri, 23 Jan 2015, Paul Walmsley wrote:
 
  On Tue, 20 Jan 2015, Tony Lindgren wrote:
 
   +/* L3 Interconnect entries */
   +static struct omap_hwmod dm816x_l3_s_hwmod = {
   + .name   = l3_s,
  
  Would suggest naming this l3_slow
  
   + .clkdm_name = alwon_l3s_clkdm,
   + .class  = l3_hwmod_class,
   + .flags  = HWMOD_NO_IDLEST,
   +};
   +
   +static struct omap_hwmod __used dm816x_l3_med_hwmod = {
  
  Hmm, why __used for this -- maybe just add it to the hwmod list at the 
  bottom?
  
   + .name   = l3_med,
   + .clkdm_name = alwon_l3_med_clkdm,
   + .class  = l3_hwmod_class,
   + .flags  = HWMOD_NO_IDLEST,
   +};
   +
   +static struct omap_hwmod __used dm816x_l3_fast_hwmod = {
  
  Same __used comment as above.

Yes good point I've added them now.
 
 Looking at the TRM CLKSTCTRL registers for the various L3 buses, it 
 occurred to me that if we wanted to portray this accurately, we'd 
 probably need separate hwmods for the ALWON and DEFAULT branches of the L3 
 as well.  So there would be six in total: 
 {alwon,default}_l3_{slow,med,fast}.  
 
 It looks like it's possible to roughly figure out which targets are 
 associated with which variant of the L3 by looking at the CLKACTIVITY 
 bits.  So for example, it looks like most of the L3 Slow targets are on 
 ALWON_L3_SLOW according to Table 18-136 CM_ALWON_L3_SLOW_CLKSTCTRL 
 Register Field descriptions, with the exception of USB, which appears to 
 be on DEFAULT_L3_SLOW according to Table 18-80 
 CM_DEFAULT_L3_SLOW_CLKSTCTRL Register Field Descriptions.

OK I think I got that done too now.
 
 Anyway, I'm sorry to put you through this, reverse-engineering this stuff 
 isn't very pleasant :-(  After reflecting on the matter, I would be OK to 
 ack the merge of the original L3-related hwmod data that you proposed, 
 with two changes:
 
 - dropping the __used and adding the two hwmods to the list at the bottom, 
 assuming that the system still boots in that configuration (i.e., if it 
 doesn't cause problems with the clockdomain programming, since it might 
 appear that there are no devices/clocks active in those clockdomains)
 
 - adding a comment noting that there probably should be six L3 hwmods as 
 described above, but that this is left for future work

Oh we're so close to the merge window that we're cutting special deals? :)

I think I got all that done now, except I did not add the missing domains
for the devices that are not yet listed.
 
 It would still be cool if you could doublecheck the SYSC/SYSS data for the 
 other IP blocks that are listed below.
 
   + .name   = l3_fast,
   + .clkdm_name = alwon_l3_fast_clkdm,
   + .class  = l3_hwmod_class,
   + .flags  = HWMOD_NO_IDLEST,
   +};
 
 See below, I screwed up the review comment ordering here...
 
   +
   +/*
   + * L4 standard peripherals, see TRM table 1-12 for devices using this.
   + * Devices using this have 125MHz SYSCLK5 clock.
   + */
   +static struct omap_hwmod dm816x_l4_ls_hwmod = {
   + .name   = l4_ls,
   + .clkdm_name = alwon_l3s_clkdm,
   + .class  = l4_hwmod_class,
   + .flags  = HWMOD_NO_IDLEST,
  
  Section 18.7.17.46 CM_ALWON_L3_CLKCTRL Register lists an IDLEST bitfield 
  for this.
 
 Well I meant for this comment to be attached to the l3_fast hwmod.  But 
 thinking about it further, I think this IDLEST is actually associated with 
 the L3 configuration *register target*, rather than the L3 itself.  This 
 appears to be located at 0x4400, according to the memory map in 
 Section 1.5.1.  Register targets are usually what the IDLEST bits are 
 intended to protect.  So I think it's OK to keep HWMOD_NO_IDLEST for the 
 l3_fast hwmod, and then later to add a separate hwmod for the L3 config 
 space.
 
 What I meant to write was:
 
 Section 18.7.17.48 CM_ALWON_L4LS_CLKCTRL Register lists an IDLEST   
 bitfield for this.
 
   +};
   +
   +/*
   + * L4 high-speed peripherals. For devices using this, please see the TRM
   + * Table 1-13. L4 High-Speed Peripheral Memory Map. On dm816x, only
   + * EMAC, MDIO and SATA use this.
   + */
   +static struct omap_hwmod dm816x_l4_hs_hwmod = {
   + .name   = l4_hs,
   + .clkdm_name = alwon_l3_med_clkdm,
   + .class  = l4_hwmod_class,
   + .flags  = HWMOD_NO_IDLEST,
  
  Section 18.7.17.47 CM_ALWON_L4HS_CLKCTRL Register lists an IDLEST 
  bitfield for this.

Hmm so I've kept them for dm816x_*_l3_*_hwmod but removed them for the
dm816x_l4_*_hwmod. Can you please check if that's now to your liking?

 [ ... ]
 
  The 816x TRM is pretty crappy when it comes to integration documentation, 
  so it's not so easy to figure out what IP blocks are connected to which 
  initiators.  (Maybe it doesn't even matter that much in the long run; I 
  doubt anyone is going to spend much time on PM or DMA path

Re: [PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support

2015-01-23 Thread Paul Walmsley 
Hi Tony

just a few brief comments

On Tue, 20 Jan 2015, Tony Lindgren wrote:

 * Tony Lindgren t...@atomide.com [150117 08:38]:
  
  And the sysc and syss offsets for mcspi1 need 0x100 added to them for
  it to work, like on am33xx. Updated patch below.
 
 Here's this one updated with the alwon_l3s_clkdm naming changes
 Paul commented in the related clockdomain patch.
 
 Regards,
 
 Tony
 
 8 
 From: Tony Lindgren t...@atomide.com
 Date: Tue, 20 Jan 2015 18:24:47 -0800
 Subject: [PATCH] ARM: OMAP2+: Add dm816x hwmod support
 
 Add minimal hwmod support that works at least on dm8168. This
 is based on the code in the earlier TI CDP tree, and an earlier
 patch by Aida Mynzhasova aida.mynzhas...@skitlab.ru.
 
 I've set up things to work pretty much the same way as for
 am33xx. We are basically using cm33xx.c with a different set
 of clocks and clockdomains.
 
 This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches
 published at:
 
 http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
 
 Cc: Aida Mynzhasova aida.mynzhas...@skitlab.ru
 Cc: Brian Hutchinson b.hutch...@gmail.com
 Cc: Paul Walmsley p...@pwsan.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -121,6 +121,7 @@ obj-$(CONFIG_ARCH_OMAP4)  += 
 $(omap-prcm-4-5-common)
  obj-$(CONFIG_SOC_OMAP5)  += $(omap-prcm-4-5-common)
  obj-$(CONFIG_SOC_DRA7XX) += $(omap-prcm-4-5-common)
  am33xx-43xx-prcm-common  += prm33xx.o cm33xx.o
 +obj-$(CONFIG_SOC_TI81XX) += $(am33xx-43xx-prcm-common)
  obj-$(CONFIG_SOC_AM33XX) += $(am33xx-43xx-prcm-common)
  obj-$(CONFIG_SOC_AM43XX) += $(omap-prcm-4-5-common) \
  $(am33xx-43xx-prcm-common)
 @@ -225,6 +226,7 @@ obj-$(CONFIG_SOC_AM33XX)  += 
 omap_hwmod_33xx_43xx_ipblock_data.o
  obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_43xx_data.o
  obj-$(CONFIG_SOC_AM43XX) += 
 omap_hwmod_33xx_43xx_interconnect_data.o
  obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_ipblock_data.o
 +obj-$(CONFIG_SOC_TI81XX) += omap_hwmod_81xx_data.o
  obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
  obj-$(CONFIG_SOC_OMAP5)  += omap_hwmod_54xx_data.o
  obj-$(CONFIG_SOC_DRA7XX) += omap_hwmod_7xx_data.o
 diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
 index ed3e6e8f..e60780f 100644
 --- a/arch/arm/mach-omap2/io.c
 +++ b/arch/arm/mach-omap2/io.c
 @@ -545,10 +545,12 @@ void __init ti814x_init_early(void)
   omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL);
   omap3xxx_check_revision();
   ti81xx_check_features();
 + am33xx_prm_init();
 + am33xx_cm_init();
   omap3xxx_voltagedomains_init();
   omap3xxx_powerdomains_init();
   ti81xx_clockdomains_init();
 - omap3xxx_hwmod_init();
 + ti81xx_hwmod_init();
   omap_hwmod_init_postsetup();
   if (of_have_populated_dt())
   omap_clk_soc_init = ti81xx_dt_clk_init;
 @@ -564,10 +566,12 @@ void __init ti816x_init_early(void)
   omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL);
   omap3xxx_check_revision();
   ti81xx_check_features();
 + am33xx_prm_init();
 + am33xx_cm_init();
   omap3xxx_voltagedomains_init();
   omap3xxx_powerdomains_init();
   ti81xx_clockdomains_init();
 - omap3xxx_hwmod_init();
 + ti81xx_hwmod_init();
   omap_hwmod_init_postsetup();
   if (of_have_populated_dt())
   omap_clk_soc_init = ti81xx_dt_clk_init;
 diff --git a/arch/arm/mach-omap2/omap_hwmod.c 
 b/arch/arm/mach-omap2/omap_hwmod.c
 index 1c0cb48..be50454 100644
 --- a/arch/arm/mach-omap2/omap_hwmod.c
 +++ b/arch/arm/mach-omap2/omap_hwmod.c
 @@ -3916,7 +3916,7 @@ void __init omap_hwmod_init(void)
   soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
   soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
   soc_ops.init_clkdm = _init_clkdm;
 - } else if (soc_is_am33xx()) {
 + } else if (cpu_is_ti816x() || soc_is_am33xx()) {
   soc_ops.enable_module = _omap4_enable_module;
   soc_ops.disable_module = _omap4_disable_module;
   soc_ops.wait_target_ready = _omap4_wait_target_ready;
 --- a/arch/arm/mach-omap2/omap_hwmod.h
 +++ b/arch/arm/mach-omap2/omap_hwmod.h
 @@ -748,6 +748,7 @@ extern int omap3xxx_hwmod_init(void);
  extern int omap44xx_hwmod_init(void);
  extern int omap54xx_hwmod_init(void);
  extern int am33xx_hwmod_init(void);
 +extern int ti81xx_hwmod_init(void);
  extern int dra7xx_hwmod_init(void);
  int am43xx_hwmod_init(void);
  
 --- /dev/null
 +++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
 @@ -0,0 +1,1025 @@
 +/*
 + * DM81xx hwmod data.
 + *
 + * Copyright (C) 2010 Texas Instruments, Inc. -

Re: [PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support

2015-01-20 Thread Tony Lindgren 
* Tony Lindgren t...@atomide.com [150117 08:38]:
 
 And the sysc and syss offsets for mcspi1 need 0x100 added to them for
 it to work, like on am33xx. Updated patch below.

Here's this one updated with the alwon_l3s_clkdm naming changes
Paul commented in the related clockdomain patch.

Regards,

Tony

8 
From: Tony Lindgren t...@atomide.com
Date: Tue, 20 Jan 2015 18:24:47 -0800
Subject: [PATCH] ARM: OMAP2+: Add dm816x hwmod support

Add minimal hwmod support that works at least on dm8168. This
is based on the code in the earlier TI CDP tree, and an earlier
patch by Aida Mynzhasova aida.mynzhas...@skitlab.ru.

I've set up things to work pretty much the same way as for
am33xx. We are basically using cm33xx.c with a different set
of clocks and clockdomains.

This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches
published at:

http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html

Cc: Aida Mynzhasova aida.mynzhas...@skitlab.ru
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -121,6 +121,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= 
$(omap-prcm-4-5-common)
 obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common)
 obj-$(CONFIG_SOC_DRA7XX)   += $(omap-prcm-4-5-common)
 am33xx-43xx-prcm-common+= prm33xx.o cm33xx.o
+obj-$(CONFIG_SOC_TI81XX)   += $(am33xx-43xx-prcm-common)
 obj-$(CONFIG_SOC_AM33XX)   += $(am33xx-43xx-prcm-common)
 obj-$(CONFIG_SOC_AM43XX)   += $(omap-prcm-4-5-common) \
   $(am33xx-43xx-prcm-common)
@@ -225,6 +226,7 @@ obj-$(CONFIG_SOC_AM33XX)+= 
omap_hwmod_33xx_43xx_ipblock_data.o
 obj-$(CONFIG_SOC_AM43XX)   += omap_hwmod_43xx_data.o
 obj-$(CONFIG_SOC_AM43XX)   += 
omap_hwmod_33xx_43xx_interconnect_data.o
 obj-$(CONFIG_SOC_AM43XX)   += omap_hwmod_33xx_43xx_ipblock_data.o
+obj-$(CONFIG_SOC_TI81XX)   += omap_hwmod_81xx_data.o
 obj-$(CONFIG_ARCH_OMAP4)   += omap_hwmod_44xx_data.o
 obj-$(CONFIG_SOC_OMAP5)+= omap_hwmod_54xx_data.o
 obj-$(CONFIG_SOC_DRA7XX)   += omap_hwmod_7xx_data.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index ed3e6e8f..e60780f 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -545,10 +545,12 @@ void __init ti814x_init_early(void)
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
ti81xx_check_features();
+   am33xx_prm_init();
+   am33xx_cm_init();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
ti81xx_clockdomains_init();
-   omap3xxx_hwmod_init();
+   ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
omap_clk_soc_init = ti81xx_dt_clk_init;
@@ -564,10 +566,12 @@ void __init ti816x_init_early(void)
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
ti81xx_check_features();
+   am33xx_prm_init();
+   am33xx_cm_init();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
ti81xx_clockdomains_init();
-   omap3xxx_hwmod_init();
+   ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
omap_clk_soc_init = ti81xx_dt_clk_init;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 1c0cb48..be50454 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3916,7 +3916,7 @@ void __init omap_hwmod_init(void)
soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
soc_ops.init_clkdm = _init_clkdm;
-   } else if (soc_is_am33xx()) {
+   } else if (cpu_is_ti816x() || soc_is_am33xx()) {
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
soc_ops.wait_target_ready = _omap4_wait_target_ready;
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -748,6 +748,7 @@ extern int omap3xxx_hwmod_init(void);
 extern int omap44xx_hwmod_init(void);
 extern int omap54xx_hwmod_init(void);
 extern int am33xx_hwmod_init(void);
+extern int ti81xx_hwmod_init(void);
 extern int dra7xx_hwmod_init(void);
 int am43xx_hwmod_init(void);
 
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -0,0 +1,1025 @@
+/*
+ * DM81xx hwmod data.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
+ * Copyright (C) 2013 SKTB SKiT, http://www.skitlab.ru/
+ *
+ * This program

Re: [PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support

2015-01-17 Thread Tony Lindgren 
* Tony Lindgren t...@atomide.com [150114 11:49]:
 * Tony Lindgren t...@atomide.com [150113 15:29]:
  Add minimal hwmod support that works at least on dm8168. This
  is based on the code in the earlier TI CDP tree, and an earlier
  patch by Aida Mynzhasova aida.mynzhas...@skitlab.ru.
  
  I've set up things to work pretty much the same way as for
  am33xx. We are basically using cm33xx.c with a different set
  of clocks and clockdomains.
  
  This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches
  published at:
  
  http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
  
  Cc: Aida Mynzhasova aida.mynzhas...@skitlab.ru
  Cc: Brian Hutchinson b.hutch...@gmail.com
  Cc: Paul Walmsley p...@pwsan.com
  Signed-off-by: Tony Lindgren t...@atomide.com
  ---
   arch/arm/mach-omap2/Makefile   |1 +
   arch/arm/mach-omap2/io.c   |8 +-
   arch/arm/mach-omap2/omap_hwmod.c   |2 +-
   arch/arm/mach-omap2/omap_hwmod.h   |1 +
   arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 1025 
  
   5 files changed, 1034 insertions(+), 3 deletions(-)
   create mode 100644 arch/arm/mach-omap2/omap_hwmod_81xx_data.c
  
  diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
  index 352873c..926bc39 100644
  --- a/arch/arm/mach-omap2/Makefile
  +++ b/arch/arm/mach-omap2/Makefile
  @@ -226,6 +226,7 @@ obj-$(CONFIG_SOC_AM33XX)+= 
  omap_hwmod_33xx_43xx_ipblock_data.o
   obj-$(CONFIG_SOC_AM43XX)   += omap_hwmod_43xx_data.o
   obj-$(CONFIG_SOC_AM43XX)   += 
  omap_hwmod_33xx_43xx_interconnect_data.o
   obj-$(CONFIG_SOC_AM43XX)   += omap_hwmod_33xx_43xx_ipblock_data.o
  +obj-$(CONFIG_SOC_TI81XX)   += omap_hwmod_81xx_data.o
   obj-$(CONFIG_ARCH_OMAP4)   += omap_hwmod_44xx_data.o
   obj-$(CONFIG_SOC_OMAP5)+= omap_hwmod_54xx_data.o
   obj-$(CONFIG_SOC_DRA7XX)   += omap_hwmod_7xx_data.o
 
 Looks like the Makefile needs the following addition for make randconfig
 builds to work properly.

And the sysc and syss offsets for mcspi1 need 0x100 added to them for
it to work, like on am33xx. Updated patch below.

Regards,

Tony

8 --
From: Tony Lindgren t...@atomide.com
Date: Wed, 14 Jan 2015 17:45:22 -0800
Subject: [PATCH] ARM: OMAP2+: Add dm816x hwmod support

Add minimal hwmod support that works at least on dm8168. This
is based on the code in the earlier TI CDP tree, and an earlier
patch by Aida Mynzhasova aida.mynzhas...@skitlab.ru.

I've set up things to work pretty much the same way as for
am33xx. We are basically using cm33xx.c with a different set
of clocks and clockdomains.

This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches
published at:

http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html

Cc: Aida Mynzhasova aida.mynzhas...@skitlab.ru
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -121,6 +121,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= 
$(omap-prcm-4-5-common)
 obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common)
 obj-$(CONFIG_SOC_DRA7XX)   += $(omap-prcm-4-5-common)
 am33xx-43xx-prcm-common+= prm33xx.o cm33xx.o
+obj-$(CONFIG_SOC_TI81XX)   += $(am33xx-43xx-prcm-common)
 obj-$(CONFIG_SOC_AM33XX)   += $(am33xx-43xx-prcm-common)
 obj-$(CONFIG_SOC_AM43XX)   += $(omap-prcm-4-5-common) \
   $(am33xx-43xx-prcm-common)
@@ -226,6 +227,7 @@ obj-$(CONFIG_SOC_AM33XX)+= 
omap_hwmod_33xx_43xx_ipblock_data.o
 obj-$(CONFIG_SOC_AM43XX)   += omap_hwmod_43xx_data.o
 obj-$(CONFIG_SOC_AM43XX)   += 
omap_hwmod_33xx_43xx_interconnect_data.o
 obj-$(CONFIG_SOC_AM43XX)   += omap_hwmod_33xx_43xx_ipblock_data.o
+obj-$(CONFIG_SOC_TI81XX)   += omap_hwmod_81xx_data.o
 obj-$(CONFIG_ARCH_OMAP4)   += omap_hwmod_44xx_data.o
 obj-$(CONFIG_SOC_OMAP5)+= omap_hwmod_54xx_data.o
 obj-$(CONFIG_SOC_DRA7XX)   += omap_hwmod_7xx_data.o
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -502,10 +502,12 @@ void __init ti814x_init_early(void)
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
ti81xx_check_features();
+   am33xx_prm_init();
+   am33xx_cm_init();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
ti81xx_clockdomains_init();
-   omap3xxx_hwmod_init();
+   ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
omap_clk_soc_init = ti81xx_dt_clk_init;
@@ -521,10 +523,12 @@ void __init ti816x_init_early(void)

Re: [PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support

2015-01-14 Thread Tony Lindgren 
* Tony Lindgren t...@atomide.com [150113 15:29]:
 Add minimal hwmod support that works at least on dm8168. This
 is based on the code in the earlier TI CDP tree, and an earlier
 patch by Aida Mynzhasova aida.mynzhas...@skitlab.ru.
 
 I've set up things to work pretty much the same way as for
 am33xx. We are basically using cm33xx.c with a different set
 of clocks and clockdomains.
 
 This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches
 published at:
 
 http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
 
 Cc: Aida Mynzhasova aida.mynzhas...@skitlab.ru
 Cc: Brian Hutchinson b.hutch...@gmail.com
 Cc: Paul Walmsley p...@pwsan.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap2/Makefile   |1 +
  arch/arm/mach-omap2/io.c   |8 +-
  arch/arm/mach-omap2/omap_hwmod.c   |2 +-
  arch/arm/mach-omap2/omap_hwmod.h   |1 +
  arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 1025 
 
  5 files changed, 1034 insertions(+), 3 deletions(-)
  create mode 100644 arch/arm/mach-omap2/omap_hwmod_81xx_data.c
 
 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
 index 352873c..926bc39 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -226,6 +226,7 @@ obj-$(CONFIG_SOC_AM33XX)  += 
 omap_hwmod_33xx_43xx_ipblock_data.o
  obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_43xx_data.o
  obj-$(CONFIG_SOC_AM43XX) += 
 omap_hwmod_33xx_43xx_interconnect_data.o
  obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_ipblock_data.o
 +obj-$(CONFIG_SOC_TI81XX) += omap_hwmod_81xx_data.o
  obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
  obj-$(CONFIG_SOC_OMAP5)  += omap_hwmod_54xx_data.o
  obj-$(CONFIG_SOC_DRA7XX) += omap_hwmod_7xx_data.o

Looks like the Makefile needs the following addition for make randconfig
builds to work properly.

Regards,

Tony

--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -121,6 +121,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= 
$(omap-prcm-4-5-common)
 obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common)
 obj-$(CONFIG_SOC_DRA7XX)   += $(omap-prcm-4-5-common)
 am33xx-43xx-prcm-common+= prm33xx.o cm33xx.o
+obj-$(CONFIG_SOC_TI81XX)   += $(am33xx-43xx-prcm-common)
 obj-$(CONFIG_SOC_AM33XX)   += $(am33xx-43xx-prcm-common)
 obj-$(CONFIG_SOC_AM43XX)   += $(omap-prcm-4-5-common) \
   $(am33xx-43xx-prcm-common)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support

2015-01-13 Thread Tony Lindgren 
Add minimal hwmod support that works at least on dm8168. This
is based on the code in the earlier TI CDP tree, and an earlier
patch by Aida Mynzhasova aida.mynzhas...@skitlab.ru.

I've set up things to work pretty much the same way as for
am33xx. We are basically using cm33xx.c with a different set
of clocks and clockdomains.

This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches
published at:

http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html

Cc: Aida Mynzhasova aida.mynzhas...@skitlab.ru
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/Makefile   |1 +
 arch/arm/mach-omap2/io.c   |8 +-
 arch/arm/mach-omap2/omap_hwmod.c   |2 +-
 arch/arm/mach-omap2/omap_hwmod.h   |1 +
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 1025 
 5 files changed, 1034 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/mach-omap2/omap_hwmod_81xx_data.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 352873c..926bc39 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -226,6 +226,7 @@ obj-$(CONFIG_SOC_AM33XX)+= 
omap_hwmod_33xx_43xx_ipblock_data.o
 obj-$(CONFIG_SOC_AM43XX)   += omap_hwmod_43xx_data.o
 obj-$(CONFIG_SOC_AM43XX)   += 
omap_hwmod_33xx_43xx_interconnect_data.o
 obj-$(CONFIG_SOC_AM43XX)   += omap_hwmod_33xx_43xx_ipblock_data.o
+obj-$(CONFIG_SOC_TI81XX)   += omap_hwmod_81xx_data.o
 obj-$(CONFIG_ARCH_OMAP4)   += omap_hwmod_44xx_data.o
 obj-$(CONFIG_SOC_OMAP5)+= omap_hwmod_54xx_data.o
 obj-$(CONFIG_SOC_DRA7XX)   += omap_hwmod_7xx_data.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index ccf238c..3ab0685 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -502,10 +502,12 @@ void __init ti814x_init_early(void)
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
ti81xx_check_features();
+   am33xx_prm_init();
+   am33xx_cm_init();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
ti81xx_clockdomains_init();
-   omap3xxx_hwmod_init();
+   ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
omap_clk_soc_init = ti81xx_dt_clk_init;
@@ -521,10 +523,12 @@ void __init ti816x_init_early(void)
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
ti81xx_check_features();
+   am33xx_prm_init();
+   am33xx_cm_init();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
ti81xx_clockdomains_init();
-   omap3xxx_hwmod_init();
+   ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
omap_clk_soc_init = ti81xx_dt_clk_init;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908d..d7e6d5c 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -4142,7 +4142,7 @@ void __init omap_hwmod_init(void)
soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
soc_ops.init_clkdm = _init_clkdm;
-   } else if (soc_is_am33xx()) {
+   } else if (cpu_is_ti816x() || soc_is_am33xx()) {
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
soc_ops.wait_target_ready = _omap4_wait_target_ready;
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 35ca6ef..4b070b4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -763,6 +763,7 @@ extern int omap3xxx_hwmod_init(void);
 extern int omap44xx_hwmod_init(void);
 extern int omap54xx_hwmod_init(void);
 extern int am33xx_hwmod_init(void);
+extern int ti81xx_hwmod_init(void);
 extern int dra7xx_hwmod_init(void);
 int am43xx_hwmod_init(void);
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
new file mode 100644
index 000..41d0e42
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -0,0 +1,1025 @@
+/*
+ * DM81xx hwmod data.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
+ * Copyright (C) 2013 SKTB SKiT, http://www.skitlab.ru/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether