diff mbox

[v2,3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra

Message ID 1375183546-12758-4-git-send-email-rnayak@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Rajendra Nayak July 30, 2013, 11:25 a.m. UTC 
From: R Sricharan <r.sricharan@ti.com>

The PRCM and MPUSS parts of DRA7 devices are quite identical
to OMAP5 so as to reuse all the existing infrastructure around it.
Makefile updates to do just that.

Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/Makefile |    8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Nishanth Menon July 30, 2013, 12:26 p.m. UTC | #1 
On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
> From: R Sricharan <r.sricharan@ti.com>
[...]
>   # Clock framework
>   obj-$(CONFIG_ARCH_OMAP2)		+= $(clock-common) clock2xxx.o
> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)		+= $(clock-common) dpll3xxx.o
>   obj-$(CONFIG_SOC_AM33XX)		+= cclock33xx_data.o
>   obj-$(CONFIG_SOC_OMAP5)			+= $(clock-common)
>   obj-$(CONFIG_SOC_OMAP5)			+= dpll3xxx.o dpll44xx.o
> +obj-$(CONFIG_SOC_DRA7XX)		+= $(clock-common)
> +obj-$(CONFIG_SOC_DRA7XX)		+= dpll3xxx.o dpll44xx.o
>

are these in sync with DRA7 support being introduced for clock data in [1]?


[1] http://marc.info/?l=linux-omap&m=137456411706971&w=2
Rajendra Nayak July 30, 2013, 12:38 p.m. UTC | #2 
On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote:
> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>> From: R Sricharan <r.sricharan@ti.com>
> [...]
>>   # Clock framework
>>   obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o
>> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
>>   obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
>>   obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
>>   obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
>> +obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
>> +obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
>>
> 
> are these in sync with DRA7 support being introduced for clock data in [1]?

I don't want to have a dependency on those patches since I am not sure of them
making it into 3.12.

> 
> 
> [1] http://marc.info/?l=linux-omap&m=137456411706971&w=2
>
Nishanth Menon July 30, 2013, 12:41 p.m. UTC | #3 
On 07/30/2013 07:38 AM, Rajendra Nayak wrote:
> On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote:
>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>> From: R Sricharan <r.sricharan@ti.com>
>> [...]
>>>    # Clock framework
>>>    obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o
>>> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
>>>    obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
>>>    obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
>>>    obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
>>> +obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
>>> +obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
>>>
>>
>> are these in sync with DRA7 support being introduced for clock data in [1]?
>
> I don't want to have a dependency on those patches since I am not sure of them
> making it into 3.12.

Then we have to undo these changes again in clock data support. the chip 
wont bootup anyways without clock data information, so why not try and 
keep the changes that Tero is doing independent of these changes?

>
>>
>>
>> [1] http://marc.info/?l=linux-omap&m=137456411706971&w=2
>>
>
Rajendra Nayak July 30, 2013, 12:48 p.m. UTC | #4 
On Tuesday 30 July 2013 06:11 PM, Nishanth Menon wrote:
> On 07/30/2013 07:38 AM, Rajendra Nayak wrote:
>> On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote:
>>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>>> From: R Sricharan <r.sricharan@ti.com>
>>> [...]
>>>>    # Clock framework
>>>>    obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o
>>>> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
>>>>    obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
>>>>    obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
>>>>    obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
>>>> +obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
>>>> +obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
>>>>
>>>
>>> are these in sync with DRA7 support being introduced for clock data in [1]?
>>
>> I don't want to have a dependency on those patches since I am not sure of them
>> making it into 3.12.
> 
> Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes?

I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out.
Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the
dpll files for DRA7? Is that what you are worried we might have to revert?

> 
>>
>>>
>>>
>>> [1] http://marc.info/?l=linux-omap&m=137456411706971&w=2
>>>
>>
> 
>
Nishanth Menon July 30, 2013, 12:57 p.m. UTC | #5 
On 07/30/2013 07:48 AM, Rajendra Nayak wrote:
> On Tuesday 30 July 2013 06:11 PM, Nishanth Menon wrote:
>> On 07/30/2013 07:38 AM, Rajendra Nayak wrote:
>>> On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote:
>>>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>>>> From: R Sricharan <r.sricharan@ti.com>
>>>> [...]
>>>>>     # Clock framework
>>>>>     obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o
>>>>> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
>>>>>     obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
>>>>>     obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
>>>>>     obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
>>>>> +obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
>>>>> +obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
>>>>>
>>>>
>>>> are these in sync with DRA7 support being introduced for clock data in [1]?
>>>
>>> I don't want to have a dependency on those patches since I am not sure of them
>>> making it into 3.12.
>>
>> Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes?
>
> I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out.
> Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the
> dpll files for DRA7? Is that what you are worried we might have to revert?

yes - lets just drop that change. that allows what ever alignment we 
have for clock data/driver to handle it appropriately. IMHO, could also 
keeps your series independent from Tero's series.

>>
>>>
>>>>
>>>>
>>>> [1] http://marc.info/?l=linux-omap&m=137456411706971&w=2
>>>>
>>>
>>
>>
>
Rajendra Nayak July 30, 2013, 12:59 p.m. UTC | #6 
On Tuesday 30 July 2013 06:27 PM, Nishanth Menon wrote:
> On 07/30/2013 07:48 AM, Rajendra Nayak wrote:
>> On Tuesday 30 July 2013 06:11 PM, Nishanth Menon wrote:
>>> On 07/30/2013 07:38 AM, Rajendra Nayak wrote:
>>>> On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote:
>>>>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>>>>> From: R Sricharan <r.sricharan@ti.com>
>>>>> [...]
>>>>>>     # Clock framework
>>>>>>     obj-$(CONFIG_ARCH_OMAP2)        += $(clock-common) clock2xxx.o
>>>>>> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)        += $(clock-common) dpll3xxx.o
>>>>>>     obj-$(CONFIG_SOC_AM33XX)        += cclock33xx_data.o
>>>>>>     obj-$(CONFIG_SOC_OMAP5)            += $(clock-common)
>>>>>>     obj-$(CONFIG_SOC_OMAP5)            += dpll3xxx.o dpll44xx.o
>>>>>> +obj-$(CONFIG_SOC_DRA7XX)        += $(clock-common)
>>>>>> +obj-$(CONFIG_SOC_DRA7XX)        += dpll3xxx.o dpll44xx.o
>>>>>>
>>>>>
>>>>> are these in sync with DRA7 support being introduced for clock data in [1]?
>>>>
>>>> I don't want to have a dependency on those patches since I am not sure of them
>>>> making it into 3.12.
>>>
>>> Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes?
>>
>> I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out.
>> Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the
>> dpll files for DRA7? Is that what you are worried we might have to revert?
> 
> yes - lets just drop that change. that allows what ever alignment we have for clock data/driver to handle it appropriately. IMHO, could also keeps your series independent from Tero's series.

I can drop those. no issues.

> 
>>>
>>>>
>>>>>
>>>>>
>>>>> [1] http://marc.info/?l=linux-omap&m=137456411706971&w=2
>>>>>
>>>>
>>>
>>>
>>
> 
>
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d4f6715..17fb8b7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -23,6 +23,7 @@  obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common)
 obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common)
 obj-$(CONFIG_SOC_OMAP5)	 += prm44xx.o $(hwmod-common) $(secure-common)
 obj-$(CONFIG_SOC_AM43XX) += $(hwmod-common) $(secure-common)
+obj-$(CONFIG_SOC_DRA7XX) += prm44xx.o $(hwmod-common) $(secure-common)
 
 ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),)
 obj-y += mcbsp.o
@@ -39,6 +40,7 @@  omap-4-5-common				=  omap4-common.o omap-wakeupgen.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(omap-4-5-common) $(smp-y) sleep44xx.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(omap-4-5-common) $(smp-y) sleep44xx.o
 obj-$(CONFIG_SOC_AM43XX)		+= $(omap-4-5-common)
+obj-$(CONFIG_SOC_DRA7XX)		+= $(omap-4-5-common) $(smp-y)
 
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_omap-headsmp.o			:=-Wa,-march=armv7-a$(plus_sec)
@@ -87,6 +89,7 @@  obj-$(CONFIG_ARCH_OMAP2)		+= sleep24xx.o
 obj-$(CONFIG_ARCH_OMAP3)		+= pm34xx.o sleep34xx.o
 obj-$(CONFIG_ARCH_OMAP4)		+= pm44xx.o omap-mpuss-lowpower.o
 obj-$(CONFIG_SOC_OMAP5)			+= omap-mpuss-lowpower.o
+obj-$(CONFIG_SOC_DRA7XX)		+= omap-mpuss-lowpower.o
 obj-$(CONFIG_PM_DEBUG)			+= pm-debug.o
 
 obj-$(CONFIG_POWER_AVS_OMAP)		+= sr_device.o
@@ -114,6 +117,7 @@  omap-prcm-4-5-common			=  cminst44xx.o cm44xx.o prm44xx.o \
 					   vc44xx_data.o vp44xx_data.o
 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)
 
 # OMAP voltage domains
 voltagedomain-common			:= voltage.o vc.o vp.o
@@ -143,6 +147,7 @@  obj-$(CONFIG_SOC_AM33XX)		+= powerdomains33xx_data.o
 obj-$(CONFIG_SOC_AM43XX)		+= $(powerdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(powerdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= powerdomains54xx_data.o
+obj-$(CONFIG_SOC_DRA7XX)		+= $(powerdomain-common)
 
 # PRCM clockdomain control
 clockdomain-common			+= clockdomain.o
@@ -160,6 +165,7 @@  obj-$(CONFIG_SOC_AM33XX)		+= clockdomains33xx_data.o
 obj-$(CONFIG_SOC_AM43XX)		+= $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= $(clockdomain-common)
 obj-$(CONFIG_SOC_OMAP5)			+= clockdomains54xx_data.o
+obj-$(CONFIG_SOC_DRA7XX)		+= $(clockdomain-common)
 
 # Clock framework
 obj-$(CONFIG_ARCH_OMAP2)		+= $(clock-common) clock2xxx.o
@@ -181,6 +187,8 @@  obj-$(CONFIG_SOC_AM33XX)		+= $(clock-common) dpll3xxx.o
 obj-$(CONFIG_SOC_AM33XX)		+= cclock33xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(clock-common)
 obj-$(CONFIG_SOC_OMAP5)			+= dpll3xxx.o dpll44xx.o
+obj-$(CONFIG_SOC_DRA7XX)		+= $(clock-common)
+obj-$(CONFIG_SOC_DRA7XX)		+= dpll3xxx.o dpll44xx.o
 
 # OMAP2 clock rate set data (old "OPP" data)
 obj-$(CONFIG_SOC_OMAP2420)		+= opp2420_data.o