Re: OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
Hi Archit,
On 10/05/2012 11:46 AM, Archit Taneja wrote:
Hi,
On Friday 31 August 2012 01:58 PM, Archit Taneja wrote:
On Friday 31 August 2012 01:57 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 13:50 +0530, Archit Taneja wrote:
On Friday 31 August 2012 12:45 PM, Tomi Valkeinen wrote:
On Fri, 2012-08-31 at 11:53 +0530, Archit Taneja wrote:
The only little problem was that during bootup, when hwmods are
setup,
only the 'parent' hwmod was able to get reset properly, all the other
'child' hwmods don't have modulemode bits tied to them, and hence
weren't able to reset. So we got some error prints.
Once DSS driver kicks in, the driver ensures the parent is enabled
for
any child to be enabled, so we don't face the issue again.
So, if DSS driver is not built in, and if the bootloader left DSS
in a
bad state, the DSS clocks might remain messed up all the time since
hwmod fwk wasn't able to reset them.
I think this is why we didn't proceed with remove dss_fck as a
slave
clock. If this issue is minor, we could go ahead and remove it.
I wonder if we could handle this with a custom reset function. We
already have a reset func for dss core. If I remember right, the main
point for that is the fact that omap 4 doesn't have a softreset for dss
core, so we manually write the default values to registers.
For omap2/3 this would be simple: skip the resets for all other dss
submodules, and dss core's reset would enable all the clocks and set
the
softreset bit. This would reset all the submodules also.
Omap4 is more tricky. I guess we'd need to enable all the clocks,
clear
manually dss core's registers, and then set softreset bits in all the
submodules. So in this case dss core would need to have information
about the other submodules.
The is a good idea. I don't clearly understand your approach though.
Are
you saying we have a custom reset function for only dss core? And reset
the submodules in it manually?
Yes.
An alternative approach would be to implement custom reset functions
for
each submodule(or each hwmod), and in the beginning of every reset
function, add a hack to enable MODULEMODE bits(since we don't want
hwmod
fwk to touch MODULEMODE for the DSS submodules), and then set the soft
reset bits.
I thought about that also. We'd need reset functions for all of them,
and for omap2/3 we'd just reset the submodules again as they have
already been reset with the dss core reset.
The dss submodule resets are a bit linked. For omap2/3 the connection is
obvious as dss core reset resets also the submodules, and for omap4 we
have this requirement for the modulemode. That's why I though it'd be
perhaps cleaner to handle the reset of the DSS block as a whole, in one
place.
Your approach would ensure that we get a clean reset of DSS, but it
would still give the annoying prints when each of the submodule
tries to
reset itself.
The other submodules would not be reset by the hwmod framework at all,
so there wouldn't be prints. I think there's a flag for that.
Sorry for bringing up an old thread. I was working on cleaning up the
OMAP4 DSS related clock/pm issues, hence brought it up.
We were discussing here on how to setting up and reset the OMAP4 DSS
submodules correctly without tying the MODULEMODE bits to the
corresponding hwmods.
Tomi, your suggestion was to do soft resets for the submodules manually
in the dss_core hwmod's custom reset function itself, and use the flag
HWMOD_INIT_NO_RESET to prevent _reset() being called.
Yep, that's the right approach.
However, this won't still resolve the issue of the errors we see a
bootup. The function _setup_reset() looks like this:
static int _setup_reset(struct omap_hwmod *oh)
{
...
r = _enable(oh);
if (r) {
pr_warning(omap_hwmod: %s: cannot be enabled for
reset (%d)\n, oh-name, oh-_state);
return -EINVAL;
}
...
if (!(oh-flags HWMOD_INIT_NO_RESET))
r = _reset(oh);
...
}
So, even if we have ask hwmod not to reset the DSS submodules, it will
still try to enable them, and we can't enable them since MODULEMODE
isn't tied to them. I don't see how we can get a clean reset done for
the DSS submodules without making some changes in hwmod framework.
Yeah, I do agree. Some module cannot but enabled automatically in the fmwk due
to PM dependency.
This is the case as well for MCPDM, IPU, DSP, ISS, FDIF...
In that case the early setup should just be skipped and the DSS driver should
take care of that during probe / pm_runtime_enable.
I already have a WIP series that delay the setup until the driver probe the
device. It will allow the setup to work properly in the case of the DSS
assuming the DISPC and other sub IPs are setup in the context of DSS probe. At
that time the DSS will be enabled already and thus every sub IPs will be able
to get enabled.
It is done in the context of
Re: OMAP4 clock/pm fixes [was: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage
On 10/05/2012 03:20 PM, Archit Taneja wrote: On Friday 05 October 2012 06:07 PM, Rajendra Nayak wrote: On Friday 05 October 2012 05:59 PM, Archit Taneja wrote: The other not so good option to make DSS PM work would be to add OCPIF_SWSUP_IDLE flag to our l3_main_2__dss_* slave interfaces(which have the hack dss_fck as slave clock). I gave this approach a try, that too isn't working so well. When I disable DSS, I get CM_DSS_DSS_CLKCTRL.IDLEST as 0x1, and CM_DSS_CLKSTCTRL.CLKACTIVITY_DSS_L3_ICLK is set. I wonder why that's happening. I have seen DSS get stuck in transition, with just a clkdm state toggle (from say HWSUP to SWWKUP) while its optional clocks are not running. Thats probably whats happening now. Oh ok, I can notice that too. So in the _idle() path, the clocks are disabled first, and then we try to change the clkdm state. I guess that could be the reason why DSS doesn't sleep. But then, I don't understand why this problem isn't seen if I try the alternative option of removing the fake dss_fck slave clock, and tie modulemode to only the parent hwmod. There DSS IDLEST is 0x3 when I disable DSS. I think with this approach, the problem is with _disable_clocks(), in disable_clocks, main_clk is disabled first, and then the slave clocks. That translates to DSS_FCK opt clock getting disabled first, and then MODULEMODE bits. I think DSS doesn't transition to sleep with this disable sequence. Did you try keeping the modulemode enabled and see if it really gates DSS/system sleep. I remember testing with Teros CORE ret/off patches and I was always seeing DSS modulemode enabled but it wasn't gating sleep. If the clkdm is in HW_AUTO, I can get DSS in sleep(STBYST and IDLEST all set). Is this helpful? Can we just leave modulemode on all the time? That'll be the best :) Well, it is true that in the case of the DSS the modulemode is only managing the interface clock. And since the interface clock is doing autogating, it will not prevent clockdomain transition. But I will not recommend using that, it should not be useful assuming the clocks are properly managed by the DSS. I think we still have issue dur to the presence of that fake modulemode clock node. Regards, Benoit -- 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
Re: [PATCH 1/3] ARM: dts: Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi
Hi Lokesh,
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
Renaming elpida_ecb240abacn.dtsi file generic, so that the
same file can be reused for other parts from different vendors.
Could you elaborate a little bit?
Are these settings purely reflecting lpddr2 spec timings?
Regards,
Benoit
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/{elpida_ecb240abacn.dtsi = lpddr2_data.dtsi} |0
arch/arm/boot/dts/omap4-panda.dts |2 +-
arch/arm/boot/dts/omap4-sdp.dts |2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/boot/dts/{elpida_ecb240abacn.dtsi = lpddr2_data.dtsi} (100%)
diff --git a/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
b/arch/arm/boot/dts/lpddr2_data.dtsi
similarity index 100%
rename from arch/arm/boot/dts/elpida_ecb240abacn.dtsi
rename to arch/arm/boot/dts/lpddr2_data.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 20b966e..09d3a32 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -8,7 +8,7 @@
/dts-v1/;
/include/ omap4.dtsi
-/include/ elpida_ecb240abacn.dtsi
+/include/ lpddr2_data.dtsi
/ {
model = TI OMAP4 PandaBoard;
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 94a23b3..dd749fc 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -8,7 +8,7 @@
/dts-v1/;
/include/ omap4.dtsi
-/include/ elpida_ecb240abacn.dtsi
+/include/ lpddr2_data.dtsi
/ {
model = TI OMAP4 SDP board;
--
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
Re: [PATCH 3/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
Device tree data for the EMIF sdram controllers in OMAP5
and LPDDR2 memory devices attached to OMAP5 boards.
Nit: Could you make a sentence with a verb to explain what you are doing
in this patch.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/lpddr2_data.dtsi | 64
+++-
arch/arm/boot/dts/omap5-evm.dts| 11 +++
arch/arm/boot/dts/omap5.dtsi | 18 ++
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/lpddr2_data.dtsi
b/arch/arm/boot/dts/lpddr2_data.dtsi
index f97f70f..8e8c1bc 100644
--- a/arch/arm/boot/dts/lpddr2_data.dtsi
+++ b/arch/arm/boot/dts/lpddr2_data.dtsi
@@ -3,7 +3,7 @@
*/
/ {
- elpida_ECB240ABACN: lpddr2 {
+ elpida_ECB240ABACN: lpddr2@0 {
compatible = Elpida,ECB240ABACN,jedec,lpddr2-s4;
density = 2048;
io-width= 32;
@@ -64,4 +64,66 @@
tDQSCK-max-derated = 6000;
};
};
+
+ samsung_K3PE0E000B: lpddr2@1 {
I'm confused now, why are you reusing the same lpddr2_data.dtsi file?
You should create a file per memory. That will make the reuse much easier.
If the goal of your first patch was to do that, it is then the wrong
approach.
+ compatible = Samsung,K3PE0E000B,jedec,lpddr2-s4;
+ density = 4096;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_samsung_K3PE0E000B_533mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 5;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 5620;
+ };
+
+ timings_samsung_K3PE0E000B_266mhz: lpddr2-timings@1 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 2;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 6f87e1a..8a952f8 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap5.dtsi
+/include/ lpddr2_data.dtsi
/ {
model = TI OMAP5 EVM board;
@@ -82,3 +83,13 @@
0x020700d9;/* SEARCH */
linux,input-no-autorepeat;
};
+
+emif1 {
+ cs1-used;
+ device-handle = samsung_K3PE0E000B;
+};
+
+emif2 {
+ cs1-used;
+ device-handle = samsung_K3PE0E000B;
+};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5db33f4..40b41c2 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -319,5 +319,23 @@
ti,buffer-size = 128;
ti,hwmods = mcbsp3;
};
+
+ emif1: emif@0x4c00 {
+ compatible = ti,emif-4d5;
+ ti,hwmods =
Re: [PATCH 2/3] ARM: dts: Correcting size of memory defined for omap5
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
Memory present for omap5 is 2GB. But in dt file
omap5 - OMAP5
dt - dts
And this patch is about omap5-evm so you should be more specific in your
changelog and even in the subject:
ARM: dts: omap5-evm: Fix size of memory defined for EVM
it is specified as 1GB. Correcting the same
in this patch
No patch in the changelog, please add a dot at the end of a sentence
and make a correct sentence.
Regards,
Benoit
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 9c41a3f..6f87e1a 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -15,7 +15,7 @@
memory {
device_type = memory;
- reg = 0x8000 0x4000; /* 1 GB */
+ reg = 0x8000 0x8000; /* 2 GB */
};
vmmcsd_fixed: fixedregulator-mmcsd {
--
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
Re: [PATCH 0/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
You should CC devicetree-disc...@lists.ozlabs.org for any Device tree patches. This is applicable for the whole series. On 10/10/2012 02:05 PM, Lokesh Vutla wrote: Patch 1: Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi Patch 2: Correcting size of memory defined for omap5 Patch 3: EMIF and LPDDR2 device tree data for OMAP5 boards There is not point to list the patch subject in a cover letter. You should just introduce the series and ideally give details about the test like you have done below. The cover letter should mostly be written like an email. Benoit Testing: - Boot tested on omap5-sevm board - Built emif as a module Lokesh Vutla (3): ARM: dts: Renaming elpida_ecb240abacn.dts as lpddr2_data.dtsi ARM: dts: Correcting size of memory defined for omap5 ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 --- arch/arm/boot/dts/lpddr2_data.dtsi| 129 + arch/arm/boot/dts/omap4-panda.dts |2 +- arch/arm/boot/dts/omap4-sdp.dts |2 +- arch/arm/boot/dts/omap5-evm.dts | 13 ++- arch/arm/boot/dts/omap5.dtsi | 18 6 files changed, 161 insertions(+), 70 deletions(-) delete mode 100644 arch/arm/boot/dts/elpida_ecb240abacn.dtsi create mode 100644 arch/arm/boot/dts/lpddr2_data.dtsi -- 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
Re: [PATCH 3/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
Hi Lokesh,
On 10/11/2012 08:16 AM, Lokesh Vutla wrote:
+ devicetree-discuss
Hi Benoit,
On Wednesday 10 October 2012 08:31 PM, Benoit Cousson wrote:
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
Device tree data for the EMIF sdram controllers in OMAP5
and LPDDR2 memory devices attached to OMAP5 boards.
Nit: Could you make a sentence with a verb to explain what you are doing
in this patch.
I am really sorry about this.
I ll make sure that all patch descriptions will be clear in V2 of this
patch series.
In this patch I am adding device tree data for LPDDR2 memory devices
attached to omap5-sevm and also adding device tree data for EMIF sdram
controllers in OMAP5.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/lpddr2_data.dtsi | 64
+++-
arch/arm/boot/dts/omap5-evm.dts| 11 +++
arch/arm/boot/dts/omap5.dtsi | 18 ++
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/lpddr2_data.dtsi
b/arch/arm/boot/dts/lpddr2_data.dtsi
index f97f70f..8e8c1bc 100644
--- a/arch/arm/boot/dts/lpddr2_data.dtsi
+++ b/arch/arm/boot/dts/lpddr2_data.dtsi
@@ -3,7 +3,7 @@
*/
/ {
-elpida_ECB240ABACN: lpddr2 {
+elpida_ECB240ABACN: lpddr2@0 {
compatible= Elpida,ECB240ABACN,jedec,lpddr2-s4;
density= 2048;
io-width= 32;
@@ -64,4 +64,66 @@
tDQSCK-max-derated = 6000;
};
};
+
+samsung_K3PE0E000B: lpddr2@1 {
I'm confused now, why are you reusing the same lpddr2_data.dtsi file?
You should create a file per memory. That will make the reuse much
easier.
If the goal of your first patch was to do that, it is then the wrong
approach.
Yes, I wanted to group data for all lppdr2 devices in a single file than
creating separate file for each device.
May be a dumb question, Why can't we group data for all the lpddr2
devices in a single file?
Well, why should we do that? What will be the advantage?
That will increase the size of the DTS/DTB with data nobody will care if
only one type of memory is used on a given platform.
Going in the same direction you can consider adding every OMAP
description into a single DTS... Does that really make sense?
So clearly there is no point doing that, it will cluttered the OMAP4 DTB
with useless Samsung memory data. And the same issue for OMAP5 board
that will contain Elpida memory information. And it will get worst each
time someone will want to add a new memory in this file.
You should just include the data you need for a given board.
Regards,
Benoit
--
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
Re: [PATCH 1/3] ARM: dts: Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi
On 10/11/2012 08:16 AM, Lokesh Vutla wrote: + devicetree-discuss Hi Benoit, On Wednesday 10 October 2012 08:18 PM, Benoit Cousson wrote: Hi Lokesh, On 10/10/2012 02:05 PM, Lokesh Vutla wrote: Renaming elpida_ecb240abacn.dtsi file generic, so that the same file can be reused for other parts from different vendors. Could you elaborate a little bit? Are these settings purely reflecting lpddr2 spec timings? The basic idea is to group data for all the lpddr2 devices in a single file instead of creating separate file for each lpddr2 device. Right now the file elpida_ecb240abacn.dtsi contains only data for lpddr2-s4 2G parts from Elpida. I wanted to add data for lpddr2-s4 4G parts from Samsung. So I renamed the file elpida_ecb240abacn.dtsi as lpddr2_data.dtsi. Please let me know if more clarification is needed. Well, not anymore... as explained in the previous email, you should not do that. Keep the Elpida file and create another one for the Samsung part. Then each board will be able to select the proper one and include only the relevant data. Regards, Benoit -- 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
Re: [PATCH] ARM: OMAP4: hwmod data: Add McASP data port address space
Hi Ricardo,
On 10/09/2012 04:15 PM, Ricardo Neri wrote:
Hi Benoit,
Have you had a chance to look at this patch? Maybe you want me to submit
it differently or to a different list?
Sorry, I missed it. It looks fine and aligned with what I have done for
OMAP5. I just have few minors comments.
Thanks!
Ricardo
On 09/27/2012 11:33 AM, Ricardo Neri wrote:
McASP has a configuration port and a data port. This patch adds the
address
space entry for the data port as described in the OMAP4 TRM.
Also, add names to the address spaces.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f31f3bc..cb5b463 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4951,10 +4951,16 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_abe__mcasp = {
static struct omap_hwmod_addr_space omap44xx_mcasp_dma_addrs[] = {
{
+.name= cfg,
.pa_start= 0x49028000,
.pa_end= 0x490283ff,
.flags= ADDR_TYPE_RT
},
+{
+.name= dat,
+.pa_start= 0x4902A000,
You should use lower case for hex number.
+.pa_end= 0x4902Afff,
In the data I have, the end is 0x4012a3ff.
Do we need to extend it to fff?
Regards,
Benoit
--
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
Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
Hi Tony, On 10/12/2012 06:24 PM, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [121012 08:56]: For those who don't bother looking at my kautobuild boot tests on the OMAP boards I have, here's the errors which get spat out at boot time. Note that some of these I've reported in the past, and one of them is missing a newline character at the end of its string. Thanks, let's get those fixed ASAP. twd: can't register interrupt 45 (-22) twd_local_timer_register failed -22 Hmm I think this regression was caused by my sparse IRQ changes, looks like I have a typo using OMAP_INTC_START in stead of the GIC base. Will do a patch for this. omap_hwmod: mcpdm: cannot be enabled for reset (3) Paul, Benoit, care to take a look at this? Yeah, that one is a warning. The mcpdm is not accessible at boot time if the external clock (from twl6040) is not enabled. Paul introduced a HWMOD_EXT_OPT_MAIN_CLK flag to avoid the warning [1], but it looks like that code is not merged. I'll check where that patch is stuck. Regards, Benoit [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/103019.html -- 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
Re: [PATCH] ARM: OMAP4: hwmod data: gpmc main clk
Hi Afzal,
On 10/15/2012 07:47 AM, Afzal Mohammed wrote:
gpmc has been converted to a driver. It requests clock with
con-id fck, if not available, probe fails. Clock for gpmc
device with con-id fck is created (aliased) along with
hwmod device, and for that to happen, main_clk needs to be
specified in hwmod entry, add it for OMAP4.
Well, in this case, this is not the preferred way. The hwmod data are supposed
to reflect the real HW capabilities.
We'd better add the alias in the already existing dummy clock node.
Here is the patch to do that.
Thanks,
Benoit
---
From: Benoit Cousson b-cous...@ti.com
Date: Mon, 15 Oct 2012 11:41:42 +0200
Subject: [PATCH] ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck
The GPMC code has been converted to a driver by the following commit:
commit da496873970c57c4b31e186d967933da0ffa0d7c
Author: Afzal Mohammed af...@ti.com
Date: Sun Sep 23 17:28:25 2012 -0600
ARM: OMAP2+: gpmc: minimal driver support
It now requests a clock with con-id fck otherwise the probe will fails.
[0.342010] omap-gpmc omap-gpmc: error: clk_get
[0.346771] omap-gpmc: probe of omap-gpmc failed with error -2
Add the omap-gmpc dev-id and fck con-id to the already existing
gmpc-fck dummy clock.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index d661d13..6efc30c 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3294,7 +3294,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, auxclk5_src_ck, auxclk5_src_ck,
CK_443X),
CLK(NULL, auxclk5_ck, auxclk5_ck,
CK_443X),
CLK(NULL, auxclkreq5_ck,auxclkreq5_ck,
CK_443X),
- CLK(NULL, gpmc_ck, dummy_ck,
CK_443X),
+ CLK(omap-gpmc,fck, dummy_ck,
CK_443X),
CLK(omap_i2c.1, ick, dummy_ck,
CK_443X),
CLK(omap_i2c.2, ick, dummy_ck,
CK_443X),
CLK(omap_i2c.3, ick, dummy_ck,
CK_443X),
--
1.7.0.4
--
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] ARM: OMAP2+: hwmod data: Fix wrong lostcontext_mask for OMAP4 l4_abe
The following commit added the support for the lostcontext_mask
along with the usage of the flag for l4_abe.
commit ce80979aedfce937926a8dd40a1f92fd4bc2fd53
Author: Tero Kristo t-kri...@ti.com
Date: Sun Sep 23 17:28:19 2012 -0600
ARM: OMAP4: hwmod data: add support for lostcontext_mask
Unfortunately, the l4_abe does not contain this memory and thus
cannot contain that flag.
Remove the flag from the l4_abe hwmod.
Change as well the mask for omap44xx_aess_hwmod to avoid missing
the status in case LOSTMEM_AESSMEM is set. The AESS logic does
not support retention and thus only the memory state is useful.
It is even mandatory to avoid a crash in the case of the AESS
resume.
TBD: Ideally each hwmod should contain an extra entry for memory
context attached to it. The AESS does contain only one, but some
IP like the IVAHD does have three memories with dedicated status.
The granularity is never used, but at least one global information
for all the memory banks is useful.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..c820de2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -203,9 +203,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
- .context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
- .lostcontext_mask = OMAP4430_LOSTMEM_AESSMEM_MASK,
- .flags= HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+ .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
},
},
};
@@ -351,7 +349,7 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_AESS_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
- .lostcontext_mask = OMAP4430_LOSTCONTEXT_DFF_MASK,
+ .lostcontext_mask = OMAP4430_LOSTMEM_AESSMEM_MASK,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
1.7.0.4
--
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
Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
Hi Tony, On 10/16/2012 08:12 PM, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [121014 23:00]: Hi, On Fri, Oct 12, 2012 at 21:54:52, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [121012 08:56]: omap-gpmc omap-gpmc: error: clk_get omap-gpmc: probe of omap-gpmc failed with error -2 I think Afzal posted something about this already? Looks like this too could be sparse IRQ related regression.. Patch has been posted to resolve the issue, ARM: OMAP4: hwmod data: gpmc main clk. OK thanks I'll pick that up. In fact you should not pick that one, the one I sent superseded it: [PATCH] ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck BTW, I cannot find your omap-for-v3.7-rc1/fixes-part2 branch, did you already pushed it? Regards, Benoit -- 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
Re: [PATCH] ARM: dts: AM33XX: Add tsl2550 ambient light sensor DT data
Hi Anil,
On 10/18/2012 07:46 AM, AnilKumar, Chimata wrote:
On Fri, Sep 21, 2012 at 21:19:11, AnilKumar, Chimata wrote:
Add tsl2550 ambient light sensor DT data to am335x-evm.dts. In AM335x
EVM tsl2550 ambient light sensor is connected to I2C2 bus. So this patch
adds child node inside i2c2 node with i2c slave address.
TAOS tsl2550 sensor with two-wire SMBus serial interface. This patch
also reduces I2C2 clock frequency to 100KHz from 400KHz because the
maximum clock frequency of SMBus is 100KHz.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 3b1f313..d99aa0f 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -49,7 +49,7 @@
i2c2: i2c@4802a000 {
status = okay;
-clock-frequency = 40;
+clock-frequency = 10;
lis331dlh: lis331dlh@18 {
compatible = st,lis331dlh, st,lis3lv02d;
@@ -79,6 +79,11 @@
st,max-limit-z = 750;
};
+tsl2550: tsl2550@39 {
+compatible = taos,tsl2550;
+reg = 0x39;
+};
+
tmp275: tmp275@48 {
compatible = ti,tmp275;
reg = 0x48;
Hi Tony/Benoit,
If there are no comments in this patch could you please take this in?
Have you updated the binding documentation to list the device?
It should be in:
Documentation/devicetree/bindings/i2c/trivial-devices.txt
Please Cc as well the DT ml.
Regards,
Benoit
--
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
Re: [PATCH] ARM/dts: omap3: Fix mcbsp2/3 hwmods to be able to probe the drivers for audio
On 10/18/2012 11:25 AM, Peter Ujfalusi wrote:
Fixes the following errors:
[2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
[2.324432] omap-mcbsp 49024000.mcbsp: invalid rx DMA channel
Which is because we failed to link the sidetone hwmod for McBSP2/3. The
missing sidetone hwmod link will prevent omap_device_alloc() to append the
DMA resources since we - accidentally - end up having the same number of
resources provided from DT (IO/IRQ) as we have in hwmod for the McBSP ports
without the ST resources.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
Regards,
Benoit
---
Hi Tony, Benoit,
Can you please take this patch for 3.7 since if we boot with DT audio will not
work on BeagleBoard and on boards which uses McBSP2 or 3 for audio.
Thank you,
Peter
arch/arm/boot/dts/omap3.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f38ea87..696e929 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -257,7 +257,7 @@
interrupt-names = common, tx, rx, sidetone;
interrupt-parent = intc;
ti,buffer-size = 1280;
- ti,hwmods = mcbsp2;
+ ti,hwmods = mcbsp2, mcbsp2_sidetone;
};
mcbsp3: mcbsp@49024000 {
@@ -272,7 +272,7 @@
interrupt-names = common, tx, rx, sidetone;
interrupt-parent = intc;
ti,buffer-size = 128;
- ti,hwmods = mcbsp3;
+ ti,hwmods = mcbsp3, mcbsp3_sidetone;
};
mcbsp4: mcbsp@49026000 {
--
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] ARM: OMAP2+: clockdomain: Fix OMAP4 ISS clk domain to support only SWSUP
From: Miguel Vadillo vadi...@ti.com
Since CAM domain (ISS) has no module wake-up dependency
with any other clock domain of the device and the dynamic
dependency from L3_main_2 is always disabled, the domain
needs to be in force wakeup in order to be able to access
it for configure (sysconfig) it or use it.
Also since there is no clock in the domain managed automatically
by the hardware, there is no use to configure automatic
clock domain transition. SW should keep the SW_WKUP domain
transition as long as a module in the domain is required to
be functional.
Signed-off-by: Miguel Vadillo vadi...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
Hi Tony,
Here is a fix that Miguel sent me some time back and that I forgot until
I face the crash again while trying to enable the ISS for test.
Regards,
Benoit
arch/arm/mach-omap2/clockdomains44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index b56d06b..95192a0 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -359,7 +359,7 @@ static struct clockdomain iss_44xx_clkdm = {
.clkdm_offs = OMAP4430_CM2_CAM_CAM_CDOFFS,
.wkdep_srcs = iss_wkup_sleep_deps,
.sleepdep_srcs= iss_wkup_sleep_deps,
- .flags= CLKDM_CAN_HWSUP_SWSUP,
+ .flags= CLKDM_CAN_SWSUP,
};
static struct clockdomain l3_dss_44xx_clkdm = {
--
1.7.0.4
--
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
Re: [PATCH 1/2] ARM: dts: OMAP: Add counter-32k nodes
Hi Jon,
This looks good to me, I just have a minor nit comment.
On 10/17/2012 08:33 PM, Jon Hunter wrote:
Adds the counter-32k timers nodes present in OMAP2/3/4 devices and
device-tree binding documentation for OMAP counter-32k.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
.../devicetree/bindings/arm/omap/counter32k.txt| 15 +++
arch/arm/boot/dts/omap2420.dtsi|6 ++
arch/arm/boot/dts/omap2430.dtsi|6 ++
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4.dtsi |6 ++
5 files changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/counter32k.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/counter32k.txt
b/Documentation/devicetree/bindings/arm/omap/counter32k.txt
new file mode 100644
index 000..1983fae
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/counter32k.txt
@@ -0,0 +1,15 @@
+OMAP Counter-32K bindings
+
+Required properties:
+- compatible:Must be ti,omap-counter32k for OMAP controllers
+- reg: Contains timer register address range (base address and
length)
+- ti,hwmods: Name of the hwmod associated to the counter, which is typically
+ counter_32k
+
+Example:
+
+counter32k: counter32k@4a304000 {
+ compatible = ti,omap-counter32k;
+ reg = 0x4a304000 0x001f;
+ ti,hwmods = counter_32k;
+};
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 5f68a70..082193f 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -14,6 +14,12 @@
compatible = ti,omap2420, ti,omap2;
ocp {
+ counter32k: counter32k@48004000 {
I'd rather use counter as generic type to be consistent with the timer
type we are already using.
+ counter32k: counter@48004000 {
Regards,
Benoit
--
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
Re: [PATCH v2] arm/dts: AM33XX: Add SPI device tree data
Hi Avinash,
This look good to me except the: status = disabled.
The disabled should be reserved for variant that does not contain the IP.
Is it the case here?
Regards,
Benoit
On 09/18/2012 07:30 AM, Philip, Avinash wrote:
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Tested-by: Matt Porter mpor...@ti.com
---
Changes since v1:
- Corrected reg offset in reg DT entry.
:100644 100644 ff3badb... 065fd54... March/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index ff3badb..065fd54 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -219,5 +219,30 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ spi0: spi@4803 {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x4803 0x400;
+ interrupt-parent = intc;
+ interrupt = 65;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi0;
+ status = disabled;
+
+ };
+
+ spi1: spi@481a {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x481a 0x400;
+ interrupt-parent = intc;
+ interrupt = 125;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi1;
+ status = disabled;
+ };
};
};
--
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
Re: [PATCH v2] arm/dts: AM33XX: Add SPI device tree data
Hi Matt,
On 10/19/2012 01:30 PM, Matt Porter wrote:
On Fri, Oct 19, 2012 at 10:24:15AM +0200, Benoit Cousson wrote:
Hi Avinash,
This look good to me except the: status = disabled.
The disabled should be reserved for variant that does not contain the IP.
Is it the case here?
http://comments.gmane.org/gmane.linux.drivers.devicetree/18968 is what
I've been going by with the DTS support in the EDMA dmaengine series. It
does make the most sense to only enable what you need in the
board.dts.
Thanks, I missed that thread. That being said, there is no real rational
:-)
It seems to be a preference more than anything else.
I'm curious now, why powerpc was not really using that approach?
I'd rather explicitly disable an IP than assuming than it is disabled by
default and then enabling it in the board file. But again it is just a
different view point, since at the end it will have the same effect.
If we really want the disabled state to be the default state, why is it
not disabled in the DT fmwk by default?
Regards,
Benoit
-Matt
On 09/18/2012 07:30 AM, Philip, Avinash wrote:
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Tested-by: Matt Porter mpor...@ti.com
---
Changes since v1:
- Corrected reg offset in reg DT entry.
:100644 100644 ff3badb... 065fd54... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index ff3badb..065fd54 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -219,5 +219,30 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ spi0: spi@4803 {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x4803 0x400;
+ interrupt-parent = intc;
+ interrupt = 65;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi0;
+ status = disabled;
+
+ };
+
+ spi1: spi@481a {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x481a 0x400;
+ interrupt-parent = intc;
+ interrupt = 125;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi1;
+ status = disabled;
+ };
};
};
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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
Re: [PATCH] arm: dts: omap4-sdp: pinmux configuration for keypad
Hi Sourav,
On 10/22/2012 09:29 AM, Sourav Poddar wrote:
Currently, omap4 keypad mux settings are done in the board file.
Populate the mux settings in the dts file for the keypad to
work via dt.
Have you changed the driver to handle properly the dependency with the
pinctrl and thus return EPROBE_DEFER if this is not ready?
Seb Guiriec has just sent a patch to do that for the omap-i2c driver
([PATCH] i2c: omap: adopt pinctrl support).
Cc: Felipe Balbi ba...@ti.com
Tested on omap4430 sdp with 3.7-rc1.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 5b7e04f..5efb059 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -194,6 +194,27 @@
0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT
| MODE0 */
;
};
+
+ keypad_pins: pinmux_keypad_pins {
+ pinctrl-single,pins =
+ 0x24 0x4119 /* gpmc_a18.kpd_row6 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+ 0x26 0x4119 /* gpmc_a19.kpd_row6 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+ 0x2c 0x4001 /* gpmc_a22.kpd_col6 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+ 0x2e 0x4001 /* gpmc_a23.kpd_col7 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+ 0x13c 0x4001 /* kpd_col0.kpd_col0 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+ 0x13e 0x4001 /* kpd_col1.kpd_col1 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+ 0x140 0x4001 /* kpd_col2.kpd_col2 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+ 0x142 0x10F /* kpd_col3.kpd_col3 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
Alway use lower case for hexa value.
+ 0x144 0x4001 /* kpd_col4.kpd_col4 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+ 0x146 0x4001 /* kpd_col5.kpd_col5 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+ 0x148 0xc119 /* kpd_row0.kpd_row0 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+ 0x14a 0x4119 /* kpd_row1.kpd_row1 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+ 0x14c 0x4119 /* kpd_row2.kpd_row2 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+ 0x14e 0x4119 /* kpd_row3.kpd_row3 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+ 0x150 0x4119 /* kpd_row4.kpd_row4 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+ 0x152 0x4119 /* kpd_row5.kpd_row5 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+ ;
+ };
};
i2c1 {
@@ -406,3 +427,8 @@
mcbsp3 {
status = disabled;
};
+
+keypad {
+pinctrl-names = default;
+pinctrl-0 = keypad_pins;
+};
Otherwise that looks good.
Thanks,
Benoit
--
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
Re: [PATCH] arm: dts: omap4-sdp: pinmux configuration for keypad
On 10/22/2012 10:23 AM, Sourav wrote:
Hi Benoit,
On Monday 22 October 2012 01:15 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/22/2012 09:29 AM, Sourav Poddar wrote:
Currently, omap4 keypad mux settings are done in the board file.
Populate the mux settings in the dts file for the keypad to
work via dt.
Have you changed the driver to handle properly the dependency with the
pinctrl and thus return EPROBE_DEFER if this is not ready?
I have send a patch[1] to the mailing list on the driver changes.
http://www.spinics.net/lists/linux-omap/msg79985.html.
Yeah, sorry, I've just seen it :-(.
Though, I see I have missed the following EPROBE_DEFER check..
Yes, indeed.
+ if (PTR_ERR(dev-pins) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
Will add for the above patch.
Thanks,
Benoit
Seb Guiriec has just sent a patch to do that for the omap-i2c driver
([PATCH] i2c: omap: adopt pinctrl support).
Cc: Felipe Balbi ba...@ti.com
Tested on omap4430 sdp with 3.7-rc1.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts
b/arch/arm/boot/dts/omap4-sdp.dts
index 5b7e04f..5efb059 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -194,6 +194,27 @@
0xbc 0x100/* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT |
MODE0 */
;
};
+
+keypad_pins: pinmux_keypad_pins {
+pinctrl-single,pins =
+0x24 0x4119 /* gpmc_a18.kpd_row6 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+0x26 0x4119 /* gpmc_a19.kpd_row6 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+0x2c 0x4001 /* gpmc_a22.kpd_col6 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+0x2e 0x4001 /* gpmc_a23.kpd_col7 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+0x13c 0x4001 /* kpd_col0.kpd_col0 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+0x13e 0x4001 /* kpd_col1.kpd_col1 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+0x140 0x4001 /* kpd_col2.kpd_col2 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+0x142 0x10F /* kpd_col3.kpd_col3 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
Alway use lower case for hexa value.
Ok. Will fix and send a new version.
+0x144 0x4001 /* kpd_col4.kpd_col4 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+0x146 0x4001 /* kpd_col5.kpd_col5 OMAP_WAKEUP_EN |
OMAP_MUX_MODE1 */
+0x148 0xc119 /* kpd_row0.kpd_row0 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+0x14a 0x4119 /* kpd_row1.kpd_row1 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+0x14c 0x4119 /* kpd_row2.kpd_row2 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+0x14e 0x4119 /* kpd_row3.kpd_row3 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+0x150 0x4119 /* kpd_row4.kpd_row4 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+0x152 0x4119 /* kpd_row5.kpd_row5 OMAP_PULL_ENA |
OMAP_PULL_UP | OMAP_WAKEUP_EN | OMAP_MUX_MODE1 | OMAP_INPUT_EN */
+;
+};
};
i2c1 {
@@ -406,3 +427,8 @@
mcbsp3 {
status = disabled;
};
+
+keypad {
+pinctrl-names = default;
+pinctrl-0 = keypad_pins;
+};
Otherwise that looks good.
Thanks,
Benoit
Thanks,
Sourav
--
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
Re: [PATCH 3/4] ARM/dts: omap5: Update UART with address space and interrupts
Hi Sourav,
On 10/22/2012 01:16 PM, Sourav wrote:
Hi Sebastien,
On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree data for
Incomplete sentence!
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6c22e1b..413df94 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -237,36 +237,48 @@
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
+reg = 0x4806a000 0x100;
+interrupts = 0 72 0x4;
ti,hwmods = uart1;
clock-frequency = 4800;
};
uart2: serial@4806c000 {
compatible = ti,omap4-uart;
+reg = 0x4806c000 0x100;
+interrupts = 0 73 0x4;
ti,hwmods = uart2;
clock-frequency = 4800;
};
uart3: serial@4802 {
compatible = ti,omap4-uart;
+reg = 0x4802 0x100;
+interrupts = 0 74 0x4;
ti,hwmods = uart3;
clock-frequency = 4800;
};
uart4: serial@4806e000 {
compatible = ti,omap4-uart;
+reg = 0x4806e000 0x100;
+interrupts = 0 70 0x4;
ti,hwmods = uart4;
clock-frequency = 4800;
};
uart5: serial@48066000 {
-compatible = ti,omap5-uart;
+compatible = ti,omap4-uart;
+reg = 0x48066000 0x100;
+interrupts = 0 105 0x4;
In Omap5 TRM, the interrupt number mentioned for uart5 is 138. How is
105 coming?
It is from hwmod and thus from the HW spec. It looks like the TRM is
wrong... or the HW spec :-)
ti,hwmods = uart5;
clock-frequency = 4800;
};
uart6: serial@48068000 {
-compatible = ti,omap6-uart;
+compatible = ti,omap4-uart;
+reg = 0x48068000 0x100;
+interrupts = 0 106 0x4;
Same here, TRM shows this number to be 139 ?
Same source.
Regards,
Benoit
--
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
Re: [PATCH 3/4] ARM/dts: omap5: Update UART with address space and interrupts
On 10/22/2012 01:57 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/22/2012 01:16 PM, Sourav wrote:
Hi Sebastien,
On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree data for
Incomplete sentence!
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6c22e1b..413df94 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -237,36 +237,48 @@
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
+reg = 0x4806a000 0x100;
+interrupts = 0 72 0x4;
ti,hwmods = uart1;
clock-frequency = 4800;
};
uart2: serial@4806c000 {
compatible = ti,omap4-uart;
+reg = 0x4806c000 0x100;
+interrupts = 0 73 0x4;
ti,hwmods = uart2;
clock-frequency = 4800;
};
uart3: serial@4802 {
compatible = ti,omap4-uart;
+reg = 0x4802 0x100;
+interrupts = 0 74 0x4;
ti,hwmods = uart3;
clock-frequency = 4800;
};
uart4: serial@4806e000 {
compatible = ti,omap4-uart;
+reg = 0x4806e000 0x100;
+interrupts = 0 70 0x4;
ti,hwmods = uart4;
clock-frequency = 4800;
};
uart5: serial@48066000 {
-compatible = ti,omap5-uart;
+compatible = ti,omap4-uart;
+reg = 0x48066000 0x100;
+interrupts = 0 105 0x4;
In Omap5 TRM, the interrupt number mentioned for uart5 is 138. How is
105 coming?
It is from hwmod and thus from the HW spec. It looks like the TRM is
wrong... or the HW spec :-)
ti,hwmods = uart5;
clock-frequency = 4800;
};
uart6: serial@48068000 {
-compatible = ti,omap6-uart;
+compatible = ti,omap4-uart;
+reg = 0x48068000 0x100;
+interrupts = 0 106 0x4;
Same here, TRM shows this number to be 139 ?
In fact, even the TRM (ES1.0 NDA vM) is aligned with these data.
Where did you see 138 and 139?
Regards,
Benoit
--
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
Re: [PATCH 0/7] ARM: OMAP: second set of PRM/CM/CGRM cleanup patches for 3.8
Hi Paul, What is CGRM? Is it a typo? Regards, Benoit On 10/16/2012 03:32 AM, Paul Walmsley wrote: This series removes the omap_prcm_get_reset_sources() function. This was exported from arch/arm/mach-omap2/prcm.c for use by the OMAP watchdog driver to report the boot reason. This series reimplements this using a platform_data function pointer for the time being, but after the upcoming PRM/CM drivers are merged, the watchdog driver can be patched to use an exported function from the drivers. This series will also be used as a base for other PRM/CM cleanup during the 3.8 time frame, since it adds the prm_register() and prm_unregister() functions. These are called by SoC-specific PRM IP block drivers to register function pointers with the PRM subsystem. This series changes the format of the watchdog's boot reason data to conform with the watchdog subsystem standard (the WDIOF_* flags). If users need more detail than that interface provides, either the watchdog interface can be patched, or those users can get that information from the upcoming PRM drivers. - Paul --- prcm_cleanup_b_3.8 text data bss dec hex filename 7519295696796 5613996 13830087 d307c7 vmlinux.omap2plus_defconfig.orig 7520203696868 5613996 13831067 d30b9b vmlinux.omap2plus_defconfig Paul Walmsley (7): ARM: OMAP2+: PRM: prepare for use of prm_ll_data function pointers ARM: OMAP2+: CM: prepare for use of cm_ll_data function pointers ARM: OMAP1: create read_reset_sources() function (for initial use by watchdog) ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr ARM: OMAP2+: PRCM: remove omap_prcm_get_reset_sources() arch/arm/mach-omap1/common.h|2 + arch/arm/mach-omap1/devices.c | 21 ++- arch/arm/mach-omap1/reset.c | 39 + arch/arm/mach-omap2/Makefile|2 - arch/arm/mach-omap2/cm.h| 12 arch/arm/mach-omap2/cm_common.c | 71 +++ arch/arm/mach-omap2/devices.c | 26 arch/arm/mach-omap2/prcm.c | 12 arch/arm/mach-omap2/prm-regbits-24xx.h |4 + arch/arm/mach-omap2/prm-regbits-34xx.h | 10 +++ arch/arm/mach-omap2/prm.h | 53 + arch/arm/mach-omap2/prm2xxx.c | 68 ++ arch/arm/mach-omap2/prm2xxx.h |4 + arch/arm/mach-omap2/prm2xxx_3xxx.h |2 + arch/arm/mach-omap2/prm3xxx.c | 65 + arch/arm/mach-omap2/prm3xxx.h |2 + arch/arm/mach-omap2/prm44xx.c | 83 ++- arch/arm/mach-omap2/prm44xx.h |2 + arch/arm/mach-omap2/prm_common.c| 78 + arch/arm/mach-omap2/wd_timer.c | 33 +++ arch/arm/plat-omap/include/plat/prcm.h |1 drivers/watchdog/omap_wdt.c | 26 include/linux/platform_data/omap-wd-timer.h | 38 23 files changed, 594 insertions(+), 60 deletions(-) create mode 100644 arch/arm/mach-omap2/cm_common.c create mode 100644 include/linux/platform_data/omap-wd-timer.h -- 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 -- 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
Re: [PATCH 5/8] i2c: omap: introduce and use OMAP_I2C_IP_VERSION_3
Hi Felipe, On 10/22/2012 11:46 AM, Felipe Balbi wrote: on OMAP4+ we want to read IRQSTATUS_RAW register, instead of IRQSTATUS. The reason being that IRQSTATUS will only contain the bits which were enabled on IRQENABLE_SET and that will break when we need to poll for a certain bit which wasn't enabled as an IRQ source. One such case is after we finish converting to deferred stop bit, we will have to poll for ARDY bit before returning control for the client driver in order to prevent us from trying to start a transfer on a bus which is already busy. Note, however, that omap-i2c.c needs a big rework on register definition and register access. Such work will be done in a separate series of patches. Do you need OMAP_I2C_IP_VERSION_3 for OMAP4? OMAP_I2C_IP_VERSION_2 was already introduced to detect OMAP3630 vs omap4430 because they were sharing the same IP version.. /* I2C controller revisions present on specific hardware */ #define OMAP_I2C_REV_ON_24300x36 #define OMAP_I2C_REV_ON_3430_3530 0x3C #define OMAP_I2C_REV_ON_3630_4430 0x40 So in theory you should not need an extra version. Regards, Benoit -- 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
Re: [PATCH 3/4] ARM/dts: omap5: Update UART with address space and interrupts
On 10/22/2012 02:27 PM, Sourav wrote:
Hi Benoit,
On Monday 22 October 2012 05:37 PM, Benoit Cousson wrote:
On 10/22/2012 01:57 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/22/2012 01:16 PM, Sourav wrote:
Hi Sebastien,
On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree data for
Incomplete sentence!
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi
b/arch/arm/boot/dts/omap5.dtsi
index 6c22e1b..413df94 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -237,36 +237,48 @@
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
+reg = 0x4806a000 0x100;
+interrupts = 0 72 0x4;
ti,hwmods = uart1;
clock-frequency = 4800;
};
uart2: serial@4806c000 {
compatible = ti,omap4-uart;
+reg = 0x4806c000 0x100;
+interrupts = 0 73 0x4;
ti,hwmods = uart2;
clock-frequency = 4800;
};
uart3: serial@4802 {
compatible = ti,omap4-uart;
+reg = 0x4802 0x100;
+interrupts = 0 74 0x4;
ti,hwmods = uart3;
clock-frequency = 4800;
};
uart4: serial@4806e000 {
compatible = ti,omap4-uart;
+reg = 0x4806e000 0x100;
+interrupts = 0 70 0x4;
ti,hwmods = uart4;
clock-frequency = 4800;
};
uart5: serial@48066000 {
-compatible = ti,omap5-uart;
+compatible = ti,omap4-uart;
+reg = 0x48066000 0x100;
+interrupts = 0 105 0x4;
In Omap5 TRM, the interrupt number mentioned for uart5 is 138. How is
105 coming?
It is from hwmod and thus from the HW spec. It looks like the TRM is
wrong... or the HW spec :-)
ti,hwmods = uart5;
clock-frequency = 4800;
};
uart6: serial@48068000 {
-compatible = ti,omap6-uart;
+compatible = ti,omap4-uart;
+reg = 0x48068000 0x100;
+interrupts = 0 106 0x4;
Same here, TRM shows this number to be 139 ?
In fact, even the TRM (ES1.0 NDA vM) is aligned with these data.
Where did you see 138 and 139?
I looked at Page 6300 of the above TRM, Figure 24-60. Is this place not
correct to look
up for these data?
Nope. Well it should be accurate but since it is a diagram, it does not
necessarily reflect the latest integration data like IRQ line.
You'd better use the table that list all the IRQ per CPU:
18.3.2 Interrupt Requests to INTC_MPU
Regards,
Benoit
--
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
Re: [PATCH 5/8] i2c: omap: introduce and use OMAP_I2C_IP_VERSION_3
On 10/22/2012 02:28 PM, Felipe Balbi wrote:
Hi,
On Mon, Oct 22, 2012 at 02:27:20PM +0200, Benoit Cousson wrote:
Hi Felipe,
On 10/22/2012 11:46 AM, Felipe Balbi wrote:
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
will only contain the bits which were enabled on
IRQENABLE_SET and that will break when we need to
poll for a certain bit which wasn't enabled as an
IRQ source.
One such case is after we finish converting to
deferred stop bit, we will have to poll for ARDY
bit before returning control for the client driver
in order to prevent us from trying to start a
transfer on a bus which is already busy.
Note, however, that omap-i2c.c needs a big rework
on register definition and register access. Such
work will be done in a separate series of patches.
Do you need OMAP_I2C_IP_VERSION_3 for OMAP4?
OMAP_I2C_IP_VERSION_2 was already introduced to detect OMAP3630 vs
omap4430 because they were sharing the same IP version..
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_24300x36
#define OMAP_I2C_REV_ON_3430_3530 0x3C
#define OMAP_I2C_REV_ON_3630_4430 0x40
So in theory you should not need an extra version.
are you sure that's how they're used ? Looking at the code where we
choose reg_map_ip_v1 and reg_map_ip_v2:
1120 if (dev-dtrev == OMAP_I2C_IP_VERSION_2)
1121 dev-regs = (u8 *)reg_map_ip_v2;
1122 else
1123 dev-regs = (u8 *)reg_map_ip_v1;
And looking at reg_map_ip_v1:
218 static const u8 reg_map_ip_v1[] = {
219 [OMAP_I2C_REV_REG] = 0x00,
220 [OMAP_I2C_IE_REG] = 0x01,
221 [OMAP_I2C_STAT_REG] = 0x02,
222 [OMAP_I2C_IV_REG] = 0x03,
223 [OMAP_I2C_WE_REG] = 0x03,
224 [OMAP_I2C_SYSS_REG] = 0x04,
225 [OMAP_I2C_BUF_REG] = 0x05,
226 [OMAP_I2C_CNT_REG] = 0x06,
227 [OMAP_I2C_DATA_REG] = 0x07,
228 [OMAP_I2C_SYSC_REG] = 0x08,
229 [OMAP_I2C_CON_REG] = 0x09,
230 [OMAP_I2C_OA_REG] = 0x0a,
231 [OMAP_I2C_SA_REG] = 0x0b,
232 [OMAP_I2C_PSC_REG] = 0x0c,
233 [OMAP_I2C_SCLL_REG] = 0x0d,
234 [OMAP_I2C_SCLH_REG] = 0x0e,
235 [OMAP_I2C_SYSTEST_REG] = 0x0f,
236 [OMAP_I2C_BUFSTAT_REG] = 0x10,
237 };
that's really not the register map on OMAP3. That only looks valid for
OMAP1.
No that should be valid as well for OMAP23 thanks to the
OMAP_I2C_FLAG_BUS_SHIFT_2.
It was introduced during DT adaptation:
#ifdef CONFIG_OF
static struct omap_i2c_bus_platform_data omap3_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
.flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_i2c_bus_platform_data omap4_pdata = {
.rev = OMAP_I2C_IP_VERSION_2,
};
static const struct of_device_id omap_i2c_of_match[] = {
{
.compatible = ti,omap4-i2c,
.data = omap4_pdata,
},
{
.compatible = ti,omap3-i2c,
.data = omap3_pdata,
},
{ },
};
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
#endif
-ECONFUSED
Well, it is confusing...
Benoit
--
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
Re: [PATCH 0/4] ARM/dts: Update OMAP5 with address space and interrupts
Hi Seb, Good work. Thanks for that series. Just update it with all the acked-by you've got from the TI driver folks + the minor comment and I'll pull it in the for_3.8/dts branch. That's a detail but you should update the subject with ARM: dts: OMAP5: XXX prefix for consistency with the latest naming convention. Please, Cc the DT list as well. Regards, Benoit On 10/22/2012 12:22 PM, Sebastien Guiriec wrote: Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the address space and interrupt line description inside dtsi file for OMAP5. This serie is updating the current OMAP5 IP with missing entry. It has been tested on OMAP5 with 3.7-audio-display feature tree. - MMC is probing and functional - TWL6041 probing (GPIO/I2C) - booting (UART) Sebastien Guiriec (4): ARM/dts: omap5: Update GPIO with address space and interrupt ARM/dts: omap5: Update I2C with address space and interrupts ARM/dts: omap5: Update UART with address space and interrupts ARM/dts: omap5: Update MMC with address space and interrupts arch/arm/boot/dts/omap5.dtsi | 56 +++--- 1 file changed, 52 insertions(+), 4 deletions(-) -- 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
Re: [PATCH 0/7] ARM: OMAP: second set of PRM/CM/CGRM cleanup patches for 3.8
On 10/22/2012 07:06 PM, Paul Walmsley wrote: On Mon, 22 Oct 2012, Benoit Cousson wrote: What is CGRM? Is it a typo? That's the OMAP1 Clock Generation and Reset Module that contains the ARM_SYSST register: Outch, that's pretty old stuff. Thanks for the clarification. Regards, Benoit -- 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
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi Dimitry,
On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
Hi Sourav,
On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
Adapt keypad to use pinctrl framework.
Tested on omap4430 sdp with 3.7-rc1 kernel.
I do not see anything in the driver that would directly use pinctrl. Is
there a better place to select default pin configuration; maybe when
instantiating platform device?
Why?
The devm_pinctrl_get_select_default is using the pinctrl.
That's why it is named get_select_default and not get only.
This API ensure that the pin will be set to the default state, and this
is all we need to do during the probe.
There is no point to change the mux if the driver is not probed, because
potentially the pin can be use be another driver.
So probe is the right place to do that for my point of view. Moreover
with DT we don't have that board static config like we had before to do
that kind of pin mux init.
But, maybe I'm missing your point.
Regards,
Benoit
Thanks.
Cc: Felipe Balbi ba...@ti.com
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
v1-v2
- Added PROBE_DEFER check
drivers/input/keyboard/omap4-keypad.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index c05f98c..502b832 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -31,6 +31,7 @@
#include linux/input.h
#include linux/slab.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
#include linux/platform_data/omap4-keypad.h
@@ -76,6 +77,7 @@ enum {
struct omap4_keypad {
struct input_dev *input;
+struct pinctrl *pins;
void __iomem *base;
unsigned int irq;
@@ -298,6 +300,15 @@ static int __devinit omap4_keypad_probe(struct
platform_device *pdev)
goto err_release_mem;
}
+keypad_data-pins = devm_pinctrl_get_select_default(pdev-dev);
+if (IS_ERR(keypad_data-pins)) {
+if (PTR_ERR(keypad_data-pins) == -EPROBE_DEFER)
+return -EPROBE_DEFER;
+
+dev_warn(pdev-dev, did not get pins for keypad error: %li\n,
+PTR_ERR(keypad_data-pins));
+keypad_data-pins = NULL;
+}
/*
* Enable clocks for the keypad module so that we can read
--
1.7.1
--
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
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi Linus, On 10/23/2012 11:13 AM, Linus Walleij wrote: On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: Hi Sourav, On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote: Adapt keypad to use pinctrl framework. Tested on omap4430 sdp with 3.7-rc1 kernel. I do not see anything in the driver that would directly use pinctrl. Is there a better place to select default pin configuration; maybe when instantiating platform device? The option is to use pinctrl hogs. Then the pins will be taken, muxed and configured by the pin controller itself. Another option (not implemented) is to use bus notifiers. (I wrote about this in some other thread but can't find it now.) Each approach above come with its own set of problems. If the driver need to handle multiple states like default/idle/sleep it is IMO better to put the handling into the driver, so if that is what is going to happen also to this driver it could be a good idea to actually implement that code upfront and include in this submission so as to show that this driver is really going to exercise its pins. But it's also a question of conformity: if other drivers in the system is using different states and this is the only one using a single default state, then it doesn't make sense to have just one driver get its pins using hogs, it's just inconsistent. So Sourav, please tell us a bit about your plans for this and other drivers! Yeah, this idea is to handle pinctrl from all the drivers, and potentially change the mode during suspend when it is relevant. Regards, Benoit -- 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
Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
On 10/23/2012 04:49 PM, Jon Hunter wrote:
Hi Seb,
On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 42c78be..9e39f9f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -104,6 +104,8 @@
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
+reg = 0x4ae1 0x200;
+interrupts = 0 29 0x4;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
I am wondering if we should add the interrupt-parent property to add
nodes in the device-tree source. I know that today the interrupt-parent
is being defined globally, but when device-tree maps an interrupt for a
device it searches for the interrupt-parent starting the current device
node.
So in other words, for gpio1 it will search the gpio1 binding for
interrupt-parent and if not found move up a level and search again. It
will keep doing this until it finds the interrupt-parent.
Therefore, I believe it will improve search time and hence, boot time if
we have interrupt-parent defined in each node.
Mmm, I'm not that sure. it will increase the size of the blob, so
increase the time to load it and then to parse it. Where in the current
case, it is just going up to the parent node using the already
un-flatten tree in memory and thus that should not take that much time.
That being said, it might be interesting to benchmark that to see what
is the real impact.
Regards,
Benoit
--
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
Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
On 10/23/2012 05:59 PM, Jon Hunter wrote:
On 10/23/2012 10:09 AM, Benoit Cousson wrote:
On 10/23/2012 04:49 PM, Jon Hunter wrote:
Hi Seb,
On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 42c78be..9e39f9f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -104,6 +104,8 @@
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
+ reg = 0x4ae1 0x200;
+ interrupts = 0 29 0x4;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
I am wondering if we should add the interrupt-parent property to add
nodes in the device-tree source. I know that today the interrupt-parent
is being defined globally, but when device-tree maps an interrupt for a
device it searches for the interrupt-parent starting the current device
node.
So in other words, for gpio1 it will search the gpio1 binding for
interrupt-parent and if not found move up a level and search again. It
will keep doing this until it finds the interrupt-parent.
Therefore, I believe it will improve search time and hence, boot time if
we have interrupt-parent defined in each node.
Mmm, I'm not that sure. it will increase the size of the blob, so
increase the time to load it and then to parse it. Where in the current
case, it is just going up to the parent node using the already
un-flatten tree in memory and thus that should not take that much time.
Yes it will definitely increase the size, so that could slow things down.
That being said, it might be interesting to benchmark that to see what
is the real impact.
Right, I wonder what the key functions are we need to benchmark to get
an overall feel for what is best? Right now I am seeing some people add
the interrupt-parent for device nodes and others not. Ideally we should
be consistent, but at the same time it is probably something that we can
easily sort out later. So not a big deal either way.
For consistency, I'd rather not add it at all for the moment.
Later, when we will only support DT boot, people will start complaining
about the boot time increase and then we will start optimizing a little
bit :-)
Regards,
Benoit
--
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
Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
On 10/23/2012 06:15 PM, Sebastien Guiriec wrote:
Hi Benoit and John,
On 10/23/2012 06:07 PM, Benoit Cousson wrote:
On 10/23/2012 05:59 PM, Jon Hunter wrote:
On 10/23/2012 10:09 AM, Benoit Cousson wrote:
On 10/23/2012 04:49 PM, Jon Hunter wrote:
Hi Seb,
On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi
b/arch/arm/boot/dts/omap5.dtsi
index 42c78be..9e39f9f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -104,6 +104,8 @@
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
+reg = 0x4ae1 0x200;
+interrupts = 0 29 0x4;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
I am wondering if we should add the interrupt-parent property to add
nodes in the device-tree source. I know that today the
interrupt-parent
is being defined globally, but when device-tree maps an interrupt
for a
device it searches for the interrupt-parent starting the current
device
node.
So in other words, for gpio1 it will search the gpio1 binding for
interrupt-parent and if not found move up a level and search
again. It
will keep doing this until it finds the interrupt-parent.
Therefore, I believe it will improve search time and hence, boot
time if
we have interrupt-parent defined in each node.
Mmm, I'm not that sure. it will increase the size of the blob, so
increase the time to load it and then to parse it. Where in the current
case, it is just going up to the parent node using the already
un-flatten tree in memory and thus that should not take that much time.
Yes it will definitely increase the size, so that could slow things
down.
That being said, it might be interesting to benchmark that to see what
is the real impact.
Right, I wonder what the key functions are we need to benchmark to get
an overall feel for what is best? Right now I am seeing some people add
the interrupt-parent for device nodes and others not. Ideally we should
be consistent, but at the same time it is probably something that we can
easily sort out later. So not a big deal either way.
For consistency, I'd rather not add it at all for the moment.
Later, when we will only support DT boot, people will start complaining
about the boot time increase and then we will start optimizing a little
bit :-)
I just do it like that to be consistent with what is inside OMAP4 dtsi
for those IPs (GPIO/UART/MMC/I2C). Now after checking Peter already add
the interrupt-parent for all audio IPs (OMAP3/4/5). But here we need
also interrupts name. So here we should try to be consistent.
So I can send back the series for OMAP5 and update the OMAP4 with
interrupts-parent = gic
No, you should not, as explained previously. You'd better remove the one
already in audio IPs for consistency.
Regards,
Benoit
--
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
Re: [PATCH v3 0/4] ARM: dts: Update OMAP5 with address space and interrupts
Hi Seb, Sorry, I missed your previous email, your v2 was the right one. We do have a single INTC in every OMAP, there is no point to repeat the same data hundred times. The DTS are already big enough. On 10/24/2012 09:07 AM, Sebastien Guiriec wrote: Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the address space and interrupt line description inside dtsi file for OMAP5. This serie is updating the current OMAP5 IP with missing entry. It has been tested on OMAP5 with 3.7-audio-display feature tree. - MMC is probing and functional - TWL6041 probing (GPIO/I2C) - booting (UART) Update since v1: - Add Ack and review - Fix up commit messages. Update since v2: - Add interrupt-parent. I will take the previous one to avoid the duplication of attributes. On top of that I will remove the ones introduce in audio IPs for consistency on OMAP3/4/5 platforms. Regards, Benoit -- 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] ARM: dts: OMAP: Move interrupt-parent to the root node to avoid duplication
The interrupt-parent attribute does not have to be added in each
node since the DT framework will check for the parent as well to get it.
Create an interrupt-parent for OMAP2, OMAP3, AM33xx and remove the
attributes from every nodes that were using it.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: Sebastien Guiriec s-guir...@ti.com
---
This patch was triggered by the thread about Seb's patch [1].
So let's clean the current OMAP/AM stuff right now to be consistent.
The patch applies on top of the for_3.8/dts [2] branch.
Regards,
Benoit
[1] https://lkml.org/lkml/2012/10/24/85
[2] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
arch/arm/boot/dts/am33xx.dtsi | 17 +
arch/arm/boot/dts/omap2.dtsi|1 +
arch/arm/boot/dts/omap2420.dtsi |2 --
arch/arm/boot/dts/omap2430.dtsi |5 -
arch/arm/boot/dts/omap3.dtsi|6 +-
arch/arm/boot/dts/omap4.dtsi|6 --
arch/arm/boot/dts/omap5.dtsi|5 -
7 files changed, 3 insertions(+), 39 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 64c2efe..4709269 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -12,6 +12,7 @@
/ {
compatible = ti,am33xx;
+ interrupt-parent = intc;
aliases {
serial0 = uart1;
@@ -94,7 +95,6 @@
interrupt-controller;
#interrupt-cells = 1;
reg = 0x44e07000 0x1000;
- interrupt-parent = intc;
interrupts = 96;
};
@@ -106,7 +106,6 @@
interrupt-controller;
#interrupt-cells = 1;
reg = 0x4804c000 0x1000;
- interrupt-parent = intc;
interrupts = 98;
};
@@ -118,7 +117,6 @@
interrupt-controller;
#interrupt-cells = 1;
reg = 0x481ac000 0x1000;
- interrupt-parent = intc;
interrupts = 32;
};
@@ -130,7 +128,6 @@
interrupt-controller;
#interrupt-cells = 1;
reg = 0x481ae000 0x1000;
- interrupt-parent = intc;
interrupts = 62;
};
@@ -139,7 +136,6 @@
ti,hwmods = uart1;
clock-frequency = 4800;
reg = 0x44e09000 0x2000;
- interrupt-parent = intc;
interrupts = 72;
status = disabled;
};
@@ -149,7 +145,6 @@
ti,hwmods = uart2;
clock-frequency = 4800;
reg = 0x48022000 0x2000;
- interrupt-parent = intc;
interrupts = 73;
status = disabled;
};
@@ -159,7 +154,6 @@
ti,hwmods = uart3;
clock-frequency = 4800;
reg = 0x48024000 0x2000;
- interrupt-parent = intc;
interrupts = 74;
status = disabled;
};
@@ -169,7 +163,6 @@
ti,hwmods = uart4;
clock-frequency = 4800;
reg = 0x481a6000 0x2000;
- interrupt-parent = intc;
interrupts = 44;
status = disabled;
};
@@ -179,7 +172,6 @@
ti,hwmods = uart5;
clock-frequency = 4800;
reg = 0x481a8000 0x2000;
- interrupt-parent = intc;
interrupts = 45;
status = disabled;
};
@@ -189,7 +181,6 @@
ti,hwmods = uart6;
clock-frequency = 4800;
reg = 0x481aa000 0x2000;
- interrupt-parent = intc;
interrupts = 46;
status = disabled;
};
@@ -200,7 +191,6 @@
#size-cells = 0;
ti,hwmods = i2c1;
reg = 0x44e0b000 0x1000;
- interrupt-parent = intc;
interrupts = 70;
status = disabled;
};
@@ -211,7 +201,6 @@
#size-cells = 0;
ti,hwmods = i2c2;
reg = 0x4802a000 0x1000;
- interrupt-parent = intc;
interrupts = 71
Re: [PATCH v3 0/4] ARM: dts: Update OMAP5 with address space and interrupts
On 10/24/2012 11:27 AM, Sebastien Guiriec wrote: Hi Benoit, On 10/24/2012 11:15 AM, Benoit Cousson wrote: Hi Seb, Sorry, I missed your previous email, your v2 was the right one. We do have a single INTC in every OMAP, there is no point to repeat the same data hundred times. The DTS are already big enough. So in such case we should send a series for audio IP interrupt-parent removal for OMAP3/4/5 dtsi file in order to be coherent. Yes. AM33xx was as well using that in some other IPs. Do you want me to do it? Thanks, but I've just done the patch, I'll sent it in a couple of minutes. Benoit On 10/24/2012 09:07 AM, Sebastien Guiriec wrote: Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the address space and interrupt line description inside dtsi file for OMAP5. This serie is updating the current OMAP5 IP with missing entry. It has been tested on OMAP5 with 3.7-audio-display feature tree. - MMC is probing and functional - TWL6041 probing (GPIO/I2C) - booting (UART) Update since v1: - Add Ack and review - Fix up commit messages. Update since v2: - Add interrupt-parent. I will take the previous one to avoid the duplication of attributes. On top of that I will remove the ones introduce in audio IPs for consistency on OMAP3/4/5 platforms. Regards, Benoit -- 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] ARM: dts: OMAP: Rename pandaES and var_som for consistency
Rename the files to have consistent names across OMAP boards.
Update the Makefile to use the new names.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Uri Yosef ur...@variscite.com
---
arch/arm/boot/dts/Makefile |4 ++--
.../dts/{omap4-pandaES.dts = omap4-panda-es.dts} |0
.../dts/{omap4-var_som.dts = omap4-var-som.dts} |0
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/boot/dts/{omap4-pandaES.dts = omap4-panda-es.dts} (100%)
rename arch/arm/boot/dts/{omap4-var_som.dts = omap4-var-som.dts} (100%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e69c921..634bd42 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -68,8 +68,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
omap4-panda.dtb \
- omap4-pandaES.dtb \
- omap4-var_som.dtb \
+ omap4-panda-es.dtb \
+ omap4-var-som.dtb \
omap4-sdp.dtb \
omap5-evm.dtb \
am335x-evm.dtb \
diff --git a/arch/arm/boot/dts/omap4-pandaES.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
similarity index 100%
rename from arch/arm/boot/dts/omap4-pandaES.dts
rename to arch/arm/boot/dts/omap4-panda-es.dts
diff --git a/arch/arm/boot/dts/omap4-var_som.dts
b/arch/arm/boot/dts/omap4-var-som.dts
similarity index 100%
rename from arch/arm/boot/dts/omap4-var_som.dts
rename to arch/arm/boot/dts/omap4-var-som.dts
--
1.7.0.4
--
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
Re: [PATCH V4 1/5] ARM: dts: OMAP: Add timer nodes
Hi Jon,
On 10/19/2012 04:59 PM, Jon Hunter wrote:
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add the 7 GP timers nodes present in AM33xx.
Add documentation for timer properties specific to OMAP.
Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have
modified
Vaibhav's original nodes adding information on which timers support a PWM
output.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
I updated the patch to remove the interrupt-parent from the DTS nodes and the
documentation, as discussed on the list in the context of OMAP5 DTS for GPIO.
If you are OK with that version, I'll push it to Tony along with the others DTS
patches.
Regards,
Benoit
---
From 531cc8142ecd6da7929628772c4035dcf7996fef Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Fri, 19 Oct 2012 09:59:00 -0500
Subject: [PATCH] ARM: dts: OMAP: Add timer nodes
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add the 7 GP timers nodes present in AM33xx.
Add documentation for timer properties specific to OMAP.
Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified
Vaibhav's original nodes adding information on which timers support a PWM
output.
Signed-off-by: Jon Hunter jon-hun...@ti.com
[b-cous...@ti.com: Remove the interrupt-parent from nodes]
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
.../devicetree/bindings/arm/omap/timer.txt | 31 +++
arch/arm/boot/dts/am33xx.dtsi | 54 +++
arch/arm/boot/dts/omap2.dtsi | 85 +
arch/arm/boot/dts/omap2420.dtsi|8 ++
arch/arm/boot/dts/omap2430.dtsi|8 ++
arch/arm/boot/dts/omap3.dtsi | 95
arch/arm/boot/dts/omap4.dtsi | 86 ++
7 files changed, 367 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
b/Documentation/devicetree/bindings/arm/omap/timer.txt
new file mode 100644
index 000..b073d89
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -0,0 +1,31 @@
+OMAP Timer bindings
+
+Required properties:
+- compatible: Must be ti,omap2-timer for OMAP2+ controllers.
+- reg: Contains timer register address range (base address and
+ length).
+- interrupts: Contains the interrupt information for the timer. The
+ format is being dependent on which interrupt controller
+ the OMAP device uses.
+- ti,hwmods: Name of the hwmod associated to the timer, timerX,
+ where X is the instance number of the timer from the
+ HW spec.
+
+Optional properties:
+- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
+- ti,timer-dsp:Indicates the timer can interrupt the on-chip
DSP in
+ addition to the ARM CPU.
+- ti,timer-pwm:Indicates the timer can generate a PWM output.
+- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
+ and therefore cannot be used by the kernel.
+
+Example:
+
+timer12: timer@48304000 {
+ compatible = ti,omap2-timer;
+ reg = 0x48304000 0xfff;
+ interrupts = 95;
+ ti,hwmods = timer12
+ ti,timer-alwon;
+ ti,timer-secure;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4709269..7522e16 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -237,5 +237,59 @@
interrupts = 55;
status = disabled;
};
+
+ timer1: timer@44e31000 {
+ compatible = ti,omap2-timer;
+ reg = 0x44e31000 0x1000;
+ interrupts = 67;
+ ti,hwmods = timer1;
+ ti,timer-alwon;
+ };
+
+ timer2: timer@4804 {
+ compatible = ti,omap2-timer;
+ reg = 0x4804 0x1000;
+ interrupts = 68;
+ ti,hwmods = timer2;
+ };
+
+ timer3: timer@48042000 {
+ compatible = ti,omap2-timer;
+ reg = 0x48042000 0x1000;
+ interrupts = 69;
+ ti,hwmods = timer3;
+ };
+
+ timer4: timer@48044000 {
+ compatible = ti,omap2-timer;
+ reg = 0x48044000 0x1000
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi Dmitry, On 10/24/2012 06:14 PM, Dmitry Torokhov wrote: On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote: Hi, On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote: On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote: Hi Dimitry, On 10/22/2012 05:50 PM, Dmitry Torokhov wrote: Hi Sourav, On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote: Adapt keypad to use pinctrl framework. Tested on omap4430 sdp with 3.7-rc1 kernel. I do not see anything in the driver that would directly use pinctrl. Is there a better place to select default pin configuration; maybe when instantiating platform device? Why? The devm_pinctrl_get_select_default is using the pinctrl. No, I guess we ihave different understanding of what directly use means. This particular driver does directly use interrupts: it requests it and performs some actions when interrupt arrives. Same goes for IO memory - it gets requested, then we access it. With pinctrl we do not do anything - we just ask another layer to configure it and that is it. this is true for almost anything we do: - we ask another layer to allocate memory for us - we ask another layer to call our ISR once the IRQ line is asserted - we ask another layer to handle the input events we just received - we ask another layer to transfer data through DMA for us - we ask another layer to turn regulators on and off. But we are _directly_ _using_ all of these. You allocate memory and you (the driver) stuff data into that memory. You ask for DMA and you take the DMAed data and work with it. Not so with pinctrl in omap keypad and other drivers I have seen so far. That's not really true. You select a pin mode and thanks to that you get the signal from an external pin that goes to your IP. And thanks to that the IP is doing what your are expecting it to do. Without that your IP will not get any input signal, which will make it a little bit useless, isn't it? and so on. This is just how abstractions work, we group common parts in a framework so that users don't need to know the details, but still need to tell the framework when to fiddle with those resources. I have seen just in a few days 3 or 4 drivers having exactly the same change - call to devm_pinctrl_get_select_default(), and I guess I will receive the same patches for the rest of input drivers shortly. This suggests that the operation is done at the wrong level. Do the pin configuration as you parse DT data, the same way you set up i2c devices registers in of_i2c.c, and leave the individual drivers that do not care about specifics alone. Makes no sense to hide that from drivers. The idea here is that driver should know when it needs its pins to muxed correctly. The driver also needs memory controller to be initialized, gpio chip be ready and registered, DMA subsystem ready, input core reade, etc, etc, etc. You however do not have every driver explicitly initialize any of that; you expect certain working environment to be already operable. The driver does manage resources it controls, it has ultimate knowledge about, pin configuration is normally is not it. We just need to know that we wired/muxed properly, otherwise we won't work. So please let parent layers deal with it. 95% of the time it will be done during probe() but then again, so what ? doing that when parsing DT, or on bus notifiers is just plain wrong. Drivers should be required to handle all of their resources. All of _their_ resources, exactly. They do not own nor control pins so they should not be bothered with them either. Look, when you see that potentially _every_ driver in the system needs to set up the same object that it doe snot use otherwise you should realize that individual driver is not the proper place to do that. What your are missing as well in that case is the explicit dependency that this API is creating with the pinctrl driver that we are going to miss otherwise. Hence the following code. + if (PTR_ERR(keypad_data-pins) == -EPROBE_DEFER) + return -EPROBE_DEFER; If the pinctrl is not already there you defer the probe until it is there. Moreover, as already said, we are probably at some point going to handle as well the low power mode and thus change the pin mode upon idle/suspend. And again, selecting a pin mode during probe is doing something with the pins when and only when it is useful. It is not different than getting an IRQ or DMA request at probe time. You get it, use it for registration and that all you are doing with it. It is no different here. Doing that during device creation does not make sense, since that device might never be used. Is it like allocating the memory by default for every devices at boot time just in case a driver will probe it at some time or registering every IRQs at boot time just in case a driver will use it... That's just pointless. We are wasting resources
Re: [PATCH V4 1/5] ARM: dts: OMAP: Add timer nodes
Hi Vaibhav, On 10/25/2012 02:05 PM, Hiremath, Vaibhav wrote: On Wed, Oct 24, 2012 at 21:11:13, Cousson, Benoit wrote: Hi Jon, On 10/19/2012 04:59 PM, Jon Hunter wrote: Add the 12 GP timers nodes present in OMAP2. Add the 12 GP timers nodes present in OMAP3. Add the 11 GP timers nodes present in OMAP4. Add the 7 GP timers nodes present in AM33xx. Add documentation for timer properties specific to OMAP. Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified Vaibhav's original nodes adding information on which timers support a PWM output. Cc: Benoit Cousson b-cous...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com I updated the patch to remove the interrupt-parent from the DTS nodes and the documentation, as discussed on the list in the context of OMAP5 DTS for GPIO. If you are OK with that version, I'll push it to Tony along with the others DTS patches. Regards, Benoit --- From 531cc8142ecd6da7929628772c4035dcf7996fef Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Fri, 19 Oct 2012 09:59:00 -0500 Subject: [PATCH] ARM: dts: OMAP: Add timer nodes Add the 12 GP timers nodes present in OMAP2. Add the 12 GP timers nodes present in OMAP3. Add the 11 GP timers nodes present in OMAP4. Add the 7 GP timers nodes present in AM33xx. Add documentation for timer properties specific to OMAP. Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified Vaibhav's original nodes adding information on which timers support a PWM output. Signed-off-by: Jon Hunter jon-hun...@ti.com [b-cous...@ti.com: Remove the interrupt-parent from nodes] Signed-off-by: Benoit Cousson b-cous...@ti.com --- .../devicetree/bindings/arm/omap/timer.txt | 31 +++ arch/arm/boot/dts/am33xx.dtsi | 54 +++ arch/arm/boot/dts/omap2.dtsi | 85 + arch/arm/boot/dts/omap2420.dtsi|8 ++ arch/arm/boot/dts/omap2430.dtsi|8 ++ arch/arm/boot/dts/omap3.dtsi | 95 arch/arm/boot/dts/omap4.dtsi | 86 ++ 7 files changed, 367 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt Benoit, I have boot tested this on BeagleBone, so, Tested-By: Vaibhav Hiremath hvaib...@ti.com Excellent, thanks. Regards, Benoit -- 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
Re: [PATCH v4 6/7] usb: dwc3-omap: Minor fixes to get dt working
Hi Kishon,
On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote:
Includes few minor fixes in dwc3-omap like populating the compatible
string in a correct way, extracting the utmi-mode property properly and
changing the index of get_irq since irq of core is removed from hwmod
entry.
Also updated the documentation with dwc3-omap device tree binding
information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index b84ddf3..10aad46 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -318,11 +318,10 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
struct resource *res;
struct device *dev = pdev-dev;
- int size;
int ret = -ENOMEM;
int irq;
- const u32 *utmi_mode;
+ u32 utmi_mode;
u32 reg;
void __iomem*base;
@@ -336,13 +335,13 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, omap);
- irq = platform_get_irq(pdev, 1);
+ irq = platform_get_irq(pdev, 0);
Cannot you use the name of the resource to avoid that kind of trick?
This is for that reason that we added the resource name in DTS :-)
if (irq 0) {
dev_err(dev, missing IRQ resource\n);
return -EINVAL;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
Same here.
Regards,
Benoit
--
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
Re: [PATCH v4 2/7] usb: dwc3-omap: use of_platform API to create dwc3 core pdev
On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote:
Used of_platform_populate() to populate dwc3 core platform_device
from device tree data. Since now the allocation of unique device id is
handled by of_*, removed the call to dwc3_get_device_id.
Just for my understanding: How are these devices organized exactly?
Do we have : omap_wrapper - dwc3-omap - dwc3-core ?
The DT binding is mentioning some wrapper, but I'm not sure where it
should be located.
Maybe you should add more documentation on that. Or maybe you do have a
other series to add that part?
Regards,
Benoit
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 50
+-
1 file changed, 10 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index d51c69c..4aaeec4 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -47,6 +47,7 @@
#include linux/ioport.h
#include linux/io.h
#include linux/of.h
+#include linux/of_platform.h
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
@@ -133,7 +134,6 @@ struct dwc3_omap {
/* device lock */
spinlock_t lock;
- struct platform_device *dwc3;
struct platform_device *usb2_phy;
struct platform_device *usb3_phy;
struct device *dev;
@@ -276,12 +276,10 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
struct dwc3_omap_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
- struct platform_device *dwc3;
struct dwc3_omap*omap;
struct resource *res;
struct device *dev = pdev-dev;
- int devid;
int size;
int ret = -ENOMEM;
int irq;
@@ -324,34 +322,19 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
return ret;
}
- devid = dwc3_get_device_id();
- if (devid 0)
- return -ENODEV;
-
- dwc3 = platform_device_alloc(dwc3, devid);
- if (!dwc3) {
- dev_err(dev, couldn't allocate dwc3 device\n);
- goto err1;
- }
-
context = devm_kzalloc(dev, resource_size(res), GFP_KERNEL);
if (!context) {
dev_err(dev, couldn't allocate dwc3 context memory\n);
- goto err2;
+ return -ENOMEM;
}
spin_lock_init(omap-lock);
- dma_set_coherent_mask(dwc3-dev, dev-coherent_dma_mask);
- dwc3-dev.parent = dev;
- dwc3-dev.dma_mask = dev-dma_mask;
- dwc3-dev.dma_parms = dev-dma_parms;
omap-resource_size = resource_size(res);
omap-context = context;
omap-dev = dev;
omap-irq = irq;
omap-base = base;
- omap-dwc3 = dwc3;
reg = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
@@ -396,7 +379,7 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
if (ret) {
dev_err(dev, failed to request IRQ #%d -- %d\n,
omap-irq, ret);
- goto err2;
+ return ret;
}
/* enable all IRQs */
@@ -415,28 +398,16 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_SET_1, reg);
- ret = platform_device_add_resources(dwc3, pdev-resource,
- pdev-num_resources);
- if (ret) {
- dev_err(dev, couldn't add resources to dwc3 device\n);
- goto err2;
- }
-
- ret = platform_device_add(dwc3);
- if (ret) {
- dev_err(dev, failed to register dwc3 device\n);
- goto err2;
+ if (node) {
+ ret = of_platform_populate(node, NULL, NULL, dev);
+ if (ret) {
+ dev_err(pdev-dev,
+ failed to add create dwc3 core\n);
+ return ret;
+ }
}
return 0;
-
-err2:
- platform_device_put(dwc3);
-
-err1:
- dwc3_put_device_id(devid);
-
- return ret;
}
static int __devexit dwc3_omap_remove(struct platform_device *pdev)
@@ -446,7 +417,6 @@ static int __devexit dwc3_omap_remove(struct
platform_device *pdev)
platform_device_unregister(omap-usb2_phy);
platform_device_unregister(omap-usb3_phy);
- dwc3_put_device_id(omap-dwc3-id);
device_for_each_child(pdev-dev, NULL, dwc3_omap_remove_core);
return 0;
--
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
Re: [PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree
Hi Felipe,
On 10/26/2012 10:13 AM, Felipe Balbi wrote:
Hi,
On Thu, Oct 25, 2012 at 11:37:33AM +0530, Vivek Gautam wrote:
Hi,
On Tue, Oct 16, 2012 at 3:38 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Oct 16, 2012 at 03:36:43PM +0530, kishon wrote:
Hi,
On Tuesday 16 October 2012 03:23 PM, Felipe Balbi wrote:
On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
This patch adds support to parse probe data for
dwc3-exynos driver using device tree.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c
b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..d11ef49 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -21,6 +21,7 @@
#include linux/clk.h
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
+#include linux/of.h
#include core.h
@@ -87,6 +88,8 @@ err1:
return ret;
}
+static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
+
static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
{
struct dwc3_exynos_data *pdata = pdev-dev.platform_data;
@@ -103,6 +106,14 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
goto err0;
}
+ /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+* Once we move to full device tree support this will vanish off.
+*/
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = dwc3_exynos_dma_mask;
says who ?
$ git grep -e dma_mask drivers/of/
drivers/of/platform.c: dev-dev.dma_mask = dev-archdata.dma_mask;
drivers/of/platform.c: dev-archdata.dma_mask = 0xUL;
drivers/of/platform.c: dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
drivers/of/platform.c: dev-dev.coherent_dma_mask = ~0;
drivers/of/platform.c: dev-dma_mask = ~0;
-ECONFUSED
dma_mask is set under some ifdef except for dev-dma_mask = ~0;.
However I agree with you for coherent_dma_mask case.
indeed. Should we try to patch that instead ?
Rob, should we set dma_mask at the driver or do you have a nicer way to
handle it ??
Can i have suggestions here please ? :)
Benoit, can you answer here since nobody else does ?
Well, I wish I could, but honestly I don't have a clue :-(
Benoit
--
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
Re: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
Hi Roger, On 10/26/2012 05:16 PM, Roger Quadros wrote: Hi Kishon Benoit, On 09/24/2012 12:06 PM, Rabin Vincent wrote: 2012/9/24 ABRAHAM, KISHON VIJAY kis...@ti.com: On Sat, Sep 22, 2012 at 3:03 AM, Rabin Vincent ra...@rab.in wrote: USB doesn't work on pandaboard on linux-next, and bisection shows this patch. Unfortunately, I can't provide a dmesg log because USB is the only way I currently have to get one out(!), but presumably it's because this omap-usb2 device is never registered? Looks like this breaks non-dt USB on pandaboard; is that intended? Yes. omap-usb2 is *only* dt supported (New drivers shouldn't have the old non-dt support). Well, USB used to work fine on Pandaboard without DT before the introduction of omap-usb2, so one would expected it to continue working (until the board file is completely removed). Anyway, I've moved to DT now. Some patches are queued only for 3.7. In case you want to use MUSB please use these patches on linux-next.. [PATCH v2] arm: omap: hwmod: make *phy_48m* as the main_clk of ocp2scp [PATCH] ARM: OMAP2+: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entries (from Benoit) [PATCH 0/2] ARM: dts: Add subnode for ocp2scp (patch series) [PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB (patch series) I got these by merging in Benoit's for_3.7/dts_part2 on top of next-20120921. Thanks. -- 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 I still can't get musb to work on 3.7-rc2. Apparently it is still missing the patches from Benoit's for_3.7/dts_part2. Maybe I just need to wait for it to be merged? They are now in a for_3.8/dts. Unfortunately, one patch that was adding ctrl_module address in the USB data was rejected and thus I'm not sure it will work without that. I think Tony had an idea to map the ctrl_register to regulator fmwk or something like that. Till then, where can I get a tree where musb works on Panda? Benoit, FYI, I get merge conflicts when merging 3.7-rc2 on top of Linus's kernel HEAD. Am I missing something? Yeah, some more patches were merged outside our tree. I fixed that. Can you try with the updated branch? Regards, Benoit -- 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
Re: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
Hi Paul, On 10/26/2012 07:54 PM, Paul Walmsley wrote: On Fri, 26 Oct 2012, Benoit Cousson wrote: On 10/26/2012 05:16 PM, Roger Quadros wrote: I still can't get musb to work on 3.7-rc2. Apparently it is still missing the patches from Benoit's for_3.7/dts_part2. Maybe I just need to wait for it to be merged? They are now in a for_3.8/dts. Unfortunately, one patch that was adding ctrl_module address in the USB data was rejected and thus I'm not sure it will work without that. For v3.7-rc timeframe, looks like it's waiting on an ack from you: http://www.spinics.net/lists/arm-kernel/msg201028.html Oups, I missed that one. But I thought Roger was mentioning the DT patch and not that one. Anyway, I will answer to Tony. Thanks for the reminder Paul. Regards, Benoit -- 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
Re: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
On 10/26/2012 07:57 PM, Benoit Cousson wrote: Hi Paul, On 10/26/2012 07:54 PM, Paul Walmsley wrote: On Fri, 26 Oct 2012, Benoit Cousson wrote: On 10/26/2012 05:16 PM, Roger Quadros wrote: I still can't get musb to work on 3.7-rc2. Apparently it is still missing the patches from Benoit's for_3.7/dts_part2. Maybe I just need to wait for it to be merged? They are now in a for_3.8/dts. Unfortunately, one patch that was adding ctrl_module address in the USB data was rejected and thus I'm not sure it will work without that. For v3.7-rc timeframe, looks like it's waiting on an ack from you: http://www.spinics.net/lists/arm-kernel/msg201028.html Oups, I missed that one. But I thought Roger was mentioning the DT patch and not that one. Anyway, I will answer to Tony. Thanks for the reminder Paul. Well, in fact, I cannot even find the original email in my mailbox :-( I was banned again from linux-omap around that time, so that might be the reason. Tony, So please take that hacky patch if it prevents the regression. Thanks, Benoit -- 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
Re: [RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Tested on omap5430 evm with 3.7-rc1 kernel.
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Tested on omap5430 sdp with 3.7-rc1 kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 95
+++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..b812d6d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -140,3 +140,98 @@
mcbsp3 {
status = disabled;
};
+
+i2c5 {
+ clock-frequency = 40;
+
+ smsc@38 {
+ compatible = smscece1099;
+ reg = 0x38;
+ clock = 0x13;
What does that clock mean?
I cannot find that in the binding documentation. BTW, did you add that
documentation in the driver patch?
Regards,
Benoit
--
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
Re: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
Hi Avinash,
On 10/30/2012 10:41 AM, Philip, Avinash wrote:
On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
Adds AM33XX SPI support for am335x-bone and am335x-evm.
Matt,
Can you build SPI DT patch with DMA support on top of SPI DT patch
I submitted [1]. With the patch [1] SPI can work on PIO mode.
So we can have basic SPI support available in 3.8.
Benoit,
Can you accept the SPI DT patch [1]
Yes, I've just applied it in for_3.8/dts branch
In case if you want I will resubmit a patch with subject line modified.
No, that's fine.
Thanks,
Benoit
Current subject line
arm/dts: AM33XX: Add SPI device tree data
1. https://patchwork.kernel.org/patch/1470661/
Thanks
Avinash
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 17 +++
arch/arm/boot/dts/am335x-evm.dts |9
arch/arm/boot/dts/am33xx.dtsi | 43
+
3 files changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5510979..23edfd8 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,6 +18,17 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am3358_pinmux: pinmux@44e10800 {
+ spi1_pins: pinmux_spi1_pins {
+ pinctrl-single,pins =
+ 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
OUTPUT_PULLUP | MODE3 */
+ 0x194 0x33 /* mcasp0_fsx.spi1_d0,
INPUT_PULLUP | MODE3 */
+ 0x198 0x13 /* mcasp0_axr0.spi1_d1,
OUTPUT_PULLUP | MODE3 */
+ 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
OUTPUT_PULLUP | MODE3 */
+ ;
+ };
+ };
+
Change to am33xx_pinmux.
ocp {
uart1: serial@44e09000 {
status = okay;
@@ -84,3 +95,9 @@
mmc1 {
vmmc-supply = ldo3_reg;
};
+
+spi1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = spi1_pins;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index d63fce8..8d5f660 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -124,3 +124,12 @@
mmc1 {
vmmc-supply = vmmc_reg;
};
+
+spi0 {
+ status = okay;
+ spi-flash@0 {
+ compatible = spansion,s25fl064k, m25p80;
+ spi-max-frequency = 2400;
+ reg = 0;
+ };
+};
In AM335x-evm, SPI flash available in profile #2 (am335x evm specific
profiles).
So can you drop this changes as if I understood correctly, am335x-evm.dts
will be
populated for devices present only on profile #0.
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 26a6af7..063ecea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux@44e10800 {
+ compatible = pinctrl-single;
+ reg = 0x44e10800 0x0238;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x7f;
+ };
+
Pin ctrl support already submitted
http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=commitdiff;h=3e0603e905d9ba662e8c1885ecb1d28bc454e448
Thanks
Avinash
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex.Since
@@ -261,6 +270,40 @@
status = disabled;
};
+ spi0: spi@4803 {
+ compatible = ti,omap4-mcspi;
+ ti,hwmods = spi0;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x4803 0x400;
+ interrupt-parent = intc;
+ interrupt = 65;
+ dmas = edma 16
+ edma 17
+ edma 18
+ edma 19;
+ dma-names = tx0, rx0, tx1, rx1;
+ ti,spi-num-cs = 2;
+ status = disabled;
+ };
+
+ spi1: spi@481a {
+ compatible = ti,omap4-mcspi;
+ ti,hwmods = spi1;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x481a 0x400;
+ interrupt-parent = intc;
+ interrupt = 125;
+ dmas = edma 42
+ edma 43
+ edma 44
+ edma 45;
+ dma-names = tx0, rx0, tx1, rx1;
+ ti,spi-num-cs = 2;
+ status = disabled;
Re: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
On 10/31/2012 11:16 AM, Benoit Cousson wrote:
Hi Avinash,
On 10/30/2012 10:41 AM, Philip, Avinash wrote:
On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
Adds AM33XX SPI support for am335x-bone and am335x-evm.
Matt,
Can you build SPI DT patch with DMA support on top of SPI DT patch
I submitted [1]. With the patch [1] SPI can work on PIO mode.
So we can have basic SPI support available in 3.8.
Benoit,
Can you accept the SPI DT patch [1]
Yes, I've just applied it in for_3.8/dts branch
Well, in fact I did not, it does not apply :-(
Can you rebase on top of the for_3.8/dts branch? I've just applied the
RTC patch on top that was OK.
Thanks,
Benoit
In case if you want I will resubmit a patch with subject line modified.
No, that's fine.
Thanks,
Benoit
Current subject line
arm/dts: AM33XX: Add SPI device tree data
1. https://patchwork.kernel.org/patch/1470661/
Thanks
Avinash
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 17 +++
arch/arm/boot/dts/am335x-evm.dts |9
arch/arm/boot/dts/am33xx.dtsi | 43
+
3 files changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5510979..23edfd8 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,6 +18,17 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am3358_pinmux: pinmux@44e10800 {
+ spi1_pins: pinmux_spi1_pins {
+ pinctrl-single,pins =
+ 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
OUTPUT_PULLUP | MODE3 */
+ 0x194 0x33 /* mcasp0_fsx.spi1_d0,
INPUT_PULLUP | MODE3 */
+ 0x198 0x13 /* mcasp0_axr0.spi1_d1,
OUTPUT_PULLUP | MODE3 */
+ 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
OUTPUT_PULLUP | MODE3 */
+ ;
+ };
+ };
+
Change to am33xx_pinmux.
ocp {
uart1: serial@44e09000 {
status = okay;
@@ -84,3 +95,9 @@
mmc1 {
vmmc-supply = ldo3_reg;
};
+
+spi1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = spi1_pins;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index d63fce8..8d5f660 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -124,3 +124,12 @@
mmc1 {
vmmc-supply = vmmc_reg;
};
+
+spi0 {
+ status = okay;
+ spi-flash@0 {
+ compatible = spansion,s25fl064k, m25p80;
+ spi-max-frequency = 2400;
+ reg = 0;
+ };
+};
In AM335x-evm, SPI flash available in profile #2 (am335x evm specific
profiles).
So can you drop this changes as if I understood correctly, am335x-evm.dts
will be
populated for devices present only on profile #0.
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 26a6af7..063ecea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux@44e10800 {
+ compatible = pinctrl-single;
+ reg = 0x44e10800 0x0238;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x7f;
+ };
+
Pin ctrl support already submitted
http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=commitdiff;h=3e0603e905d9ba662e8c1885ecb1d28bc454e448
Thanks
Avinash
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex.Since
@@ -261,6 +270,40 @@
status = disabled;
};
+ spi0: spi@4803 {
+ compatible = ti,omap4-mcspi;
+ ti,hwmods = spi0;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x4803 0x400;
+ interrupt-parent = intc;
+ interrupt = 65;
+ dmas = edma 16
+ edma 17
+ edma 18
+ edma 19;
+ dma-names = tx0, rx0, tx1, rx1;
+ ti,spi-num-cs = 2;
+ status = disabled;
+ };
+
+ spi1: spi@481a {
+ compatible = ti,omap4-mcspi;
+ ti,hwmods = spi1;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x481a 0x400;
+ interrupt-parent = intc;
+ interrupt = 125;
+ dmas = edma 42
+ edma 43
+ edma 44
Re: [PATCH v3] ARM: dts: AM33xx: Add SPI node
On 10/31/2012 11:51 AM, Philip, Avinash wrote:
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Tested-by: Matt Porter mpor...@ti.com
---
Applied in for_3.8/dts
Thanks,
Benoit
Changes since v2:
- Commit message corrected.
- Rebase on top of for_3.8/dts
Changes since v1:
- Corrected reg offset in reg DT entry.
:100644 100644 97a7bd3... 6e04789... March/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 97a7bd3..6e04789 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -299,5 +299,29 @@
76;
ti,hwmods = rtc;
};
+
+ spi0: spi@4803 {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x4803 0x400;
+ interrupt-parent = intc;
+ interrupt = 65;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi0;
+ status = disabled;
+ };
+
+ spi1: spi@481a {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x481a 0x400;
+ interrupt-parent = intc;
+ interrupt = 125;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi1;
+ status = disabled;
+ };
};
};
--
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
Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
Hi,
On 10/29/2012 09:21 AM, Vaibhav Hiremath wrote:
From: Mugunthan V N mugunthan...@ti.com
Add CPSW and MDIO related device tree data for AM33XX.
Also enable them into board/evm dts files by providing
respective phy-id.
Is there any bindings documentation for that device?
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Richard Cochran richardcoch...@gmail.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |8 ++
arch/arm/boot/dts/am335x-evm.dts |8 ++
arch/arm/boot/dts/am33xx.dtsi | 50
+
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..e233cfa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
Why are you using that kind of interface? You seem to want a reference
to a device.
Cannot you have something less hard coded like:
phy_id = davinci_mdio, 0;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..415c3b3 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -118,3 +118,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..f6bea04 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,55 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ mac: ethernet@4A10 {
hexa data should be in lower case.
+ compatible = ti,cpsw;
+ ti,hwmods = cpgmac0;
+ cpdma_channels = 8;
+ host_port_no = 0;
+ cpdma_reg_ofs = 0x800;
+ cpdma_sram_ofs = 0xa00;
+ ale_reg_ofs = 0xd00;
+ ale_entries = 1024;
+ host_port_reg_ofs = 0x108;
+ hw_stats_reg_ofs = 0x900;
+ bd_ram_ofs = 0x2000;
+ bd_ram_size = 0x2000;
+ no_bd_ram = 0;
+ rx_descs = 64;
+ mac_control = 0x20;
Do you have to store all these data in the DTS? Cannot it be in the driver?
Do you expect to have several instance of the same IP with different
parameters here?
+ slaves = 2;
+ reg = 0x4a10 0x800
+ 0x4a101200 0x100
+ 0x4a101000 0x100;
Please align the address.
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = intc;
+ /* c0_rx_thresh_pend c0_rx_pend c0_tx_pend
c0_misc_pend*/
Please use a standard multi-line comment instead of trying to put
everything in one line.
+ interrupts = 40 41 42 43;
+ ranges;
You should add blank line here for readability.
+ cpsw_emac0: slave@0 {
Mmm, you are using some address later and here some relative number,
that does not looks very consistent.
+ slave_reg_ofs = 0x208;
Is it an offset from 4a10? Cannot you use the address for the slave
name?
Something like that: cpsw_emac0: slave@4a100208
+ sliver_reg_ofs = 0xd80;
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
You should add blank line here for readability.
+ cpsw_emac1: slave@1 {
+ slave_reg_ofs = 0x308;
+ sliver_reg_ofs = 0xdc0;
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ davinci_mdio: mdio@4a101000 {
+ compatible = ti,davinci_mdio;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = davinci_mdio;
+ bus_freq = 100;
+ reg = 0x4a101000 0x100;
+ };
+
Stray change.
Regards,
Benoit
--
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
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi Panto, On 10/31/2012 07:09 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 11:05]: Hi Tony, On Oct 31, 2012, at 7:52 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 10:26]: It is painless to move the adapter DT devices to arch/arm/mach-omap2 However I got bit by the __init at omap_build_device family functions. If you don't remove it, crashes every time you instantiate a device at runtime, or you load the cape driver as a module. Hmm I think you misunderstood me. You only need to create the platform_device under arch/arm/mach-omap2. The device creation happens only at __init, so omap_build_device can stay as __init. The driver itself should be under drivers. But is this bus on non-device-tree omaps? If not, just make it device tree only. I'm afraid that's not the case. The whole notion of capebus is that instantiation of the devices doesn't just happen early at the boot sequence. It is perfectly valid for a cape to be instantiated via loading a module, or by making an override by writing a sysfs file. When having the __init there, the function has been long removed and you get a crash by calling into the weeds. So the sequence is: early boot Register the adapter driver. OK this is always there for the hardware, and done during the __init and this one should have an omap_device.. user insmod bone-geiger-cape cape-is-matched call omap_build_device Please look into the capebus patches for the details. ..but it seems that the devices connected to capebus should not have anything to do with omap_device and hwmod? Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? Regards, Benoit -- 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
Re: [PATCH v3] ARM: dts: AM33xx: Add SPI node
Hi Avinash,
On 10/31/2012 11:51 AM, Philip, Avinash wrote:
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Tested-by: Matt Porter mpor...@ti.com
I've just realized the interrupt-parent was still there, so I removed both.
Please find below the updated version.
Regards,
Benoit
From 9fd3c748aac9418cd377249ca463050783d2198f Mon Sep 17 00:00:00 2001
From: Philip, Avinash avinashphi...@ti.com
Date: Wed, 31 Oct 2012 16:21:09 +0530
Subject: [PATCH] ARM: dts: AM33XX: Add SPI node
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Tested-by: Matt Porter mpor...@ti.com
[b-cous...@ti.com: Remove interrupt-parent]
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 97a7bd3..5dfd682 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -299,5 +299,27 @@
76;
ti,hwmods = rtc;
};
+
+ spi0: spi@4803 {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x4803 0x400;
+ interrupt = 65;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi0;
+ status = disabled;
+ };
+
+ spi1: spi@481a {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x481a 0x400;
+ interrupt = 125;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi1;
+ status = disabled;
+ };
};
};
--
1.7.0.4
--
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
Re: [PATCH 0/3] ARM: dts: OMAP4/5 device-tree timer updates
Hi Jon, On 11/01/2012 04:49 PM, Jon Hunter wrote: A few device tree timer updates for OMAP4/5 devices. This series adds ... 1. MPU private addresses for OMAP4 timers 2. Timer nodes for OMAP5 3. 32kHz counter node for OMAP5 Great, thanks for that update. Just in time before the pull request. This is based upon of Benoit Cousson's OMAP device-tree branch for v3.8. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.8/dts Jon Hunter (3): ARM: dts: Update OMAP4 timer addresses ARM: dts: Add OMAP5 timer nodes ARM: dts: Add OMAP5 counter node I've just updated slightly the subjects: 3b3132f ARM: dts: OMAP5: Add counter node df692a9 ARM: dts: OMAP5: Add timer nodes d03a93b ARM: dts: OMAP4: Update timer addresses There are now in my for_3.8/dts branch. Thanks, Benoit -- 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
[GIT PULL] ARM: OMAP: DTS for 3.8
Hi Tony,
Please pull some more OMAP5 and AM33xx data for 3.8.
The branch contains as well some cleanup and the omap3-beagle support since the
previous one was in fact a beagle-xm.
Thanks,
Benoit
The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
Linus Torvalds (1):
Linux 3.7-rc3
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.8/dts
Afzal Mohammed (1):
ARM: dts: AM33XX: Add rtc node
AnilKumar Ch (8):
ARM: dts: AM33XX: Add device tree OPP table
ARM: dts: AM33XX: Add basic pinctrl device tree data
ARM: dts: AM33XX: Add D_CAN device tree data
ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
ARM: dts: AM33XX: Add temperature sensor device tree data to am335x-evm
ARM: dts: AM33XX: Add tsl2550 ambient light sensor DT data
ARM: dts: Add am335x-evmsk.dts
Documentation: dt: i2c: Update trivial-devices list
Benoit Cousson (2):
ARM: dts: OMAP: Move interrupt-parent to the root node to avoid
duplication
ARM: dts: OMAP: Rename pandaES and var_som for consistency
Jon Hunter (6):
ARM: dts: Add omap3-beagle.dts
ARM: dts: OMAP: Add timer nodes
ARM: dts: OMAP: Add counter-32k nodes
ARM: dts: OMAP4: Update timer addresses
ARM: dts: OMAP5: Add timer nodes
ARM: dts: OMAP5: Add counter node
Kishon Vijay Abraham I (3):
ARM: dts: Add twl6030-usb data
ARM: dts: Add twl4030-usb data
ARM: dts: OMAP4: add *reg* property for ocp2scp
Philip, Avinash (1):
ARM: dts: AM33XX: Add SPI node
Sebastien Guiriec (4):
ARM: dts: omap5: Update GPIO with address space and interrupts
ARM: dts: omap5: Update I2C with address space and interrupts
ARM: dts: omap5: Update UART with address space and interrupts
ARM: dts: omap5: Update MMC with address space and interrupts
.../devicetree/bindings/arm/omap/counter.txt | 15 ++
.../devicetree/bindings/arm/omap/timer.txt | 31
.../devicetree/bindings/bus/omap-ocp2scp.txt | 18 ++
.../devicetree/bindings/i2c/trivial-devices.txt|2 +
arch/arm/boot/dts/Makefile |5 +-
arch/arm/boot/dts/am335x-bone.dts |6 +
arch/arm/boot/dts/am335x-evm.dts | 55 +++
arch/arm/boot/dts/am335x-evmsk.dts | 166
arch/arm/boot/dts/am33xx.dtsi | 139 +++--
arch/arm/boot/dts/omap2.dtsi | 86 ++
arch/arm/boot/dts/omap2420.dtsi| 16 ++-
arch/arm/boot/dts/omap2430.dtsi| 19 ++-
arch/arm/boot/dts/omap3-beagle-xm.dts |6 -
arch/arm/boot/dts/omap3-beagle.dts | 67
arch/arm/boot/dts/omap3.dtsi | 107 -
.../dts/{omap4-pandaES.dts = omap4-panda-es.dts} |0
arch/arm/boot/dts/omap4-panda.dts |4 +
arch/arm/boot/dts/omap4-sdp.dts|4 +
.../dts/{omap4-var_som.dts = omap4-var-som.dts} |0
arch/arm/boot/dts/omap4.dtsi | 105 -
arch/arm/boot/dts/omap5.dtsi | 156 +-
arch/arm/boot/dts/twl4030.dtsi | 27 +++
arch/arm/boot/dts/twl6030.dtsi |5 +
23 files changed, 989 insertions(+), 50 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/counter.txt
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
create mode 100644 arch/arm/boot/dts/am335x-evmsk.dts
create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
rename arch/arm/boot/dts/{omap4-pandaES.dts = omap4-panda-es.dts} (100%)
rename arch/arm/boot/dts/{omap4-var_som.dts = omap4-var-som.dts} (100%)
--
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
Re: [PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
Hi Lokesh, On 11/05/2012 06:58 AM, Lokesh Vutla wrote: Hi, On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote: This patch series adds Device tree data for the EMIF sdram controllers in OMAP5 and LPDDR2 memory devices in OMAP5-evm board. Testing: - Boot tested on OMAP5430 evm. - Built EMIF as a module. Changes from v1: * Created a seperate dtsi file for Samsung LPDDR2 memory device used in OMAP5-evm. * Passing reg and interrupt fields from dt for EMIF1 and EMIF2. Gentle ping on this series. Sorry, I missed it. It might be too late for 3.8, since Tony wanted us to push before -rc4. I'll pull the series anyway just in case. I have a least one comment. Regards, Benoit Thanks Lokesh Lokesh Vutla (3): ARM: dts: omap5-evm: Fix size of memory defined for EVM ARM: dts: omap5: EMIF device tree data for OMAP5 boards ARM: dts: omap5-evm: LPDDR2 memory device details for EVM arch/arm/boot/dts/omap5-evm.dts | 13 +- arch/arm/boot/dts/omap5.dtsi | 24 +++ arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 + 3 files changed, 103 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi -- 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
Re: [PATCH V2 2/3] ARM: dts: omap5: EMIF device tree data for OMAP5 boards
On 10/11/2012 02:47 PM, Lokesh Vutla wrote:
Adding EMIF device tree data for OMAP5 boards.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5db33f4..445aeea 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -319,5 +319,29 @@
ti,buffer-size = 128;
ti,hwmods = mcbsp3;
};
+
+ emif1: emif@0x4c00 {
+ compatible = ti,emif-4d5;
+ ti,hwmods = emif1;
+ phy-type= 2;
+ reg = 0x4c00 0x3ff;
Should 0x400. This parameter is the size, not the end address.
+ interrupts = 0 110 0x4;
+ interrupt-parent = gic;
Please remove the interrupt-parent. It is not needed since DT will use
the parent node to get it. It will avoid duplicating the entry for every
nodes.
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
+
+ emif2: emif@0x4d00 {
+ compatible = ti,emif-4d5;
+ ti,hwmods = emif2;
+ phy-type= 2;
Can you just add a comment to give more information. I know this is in
the binding documentation, but some more comment never hurt.
+ reg = 0x4d00 0x3ff;
0x400 as well.
+ interrupts = 0 111 0x4;
+ interrupt-parent = gic;
Ditto.
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
};
};
Regards,
Benoit
--
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
Re: [PATCH V2 3/3] ARM: dts: omap5-evm: LPDDR2 memory device details for EVM
On 10/11/2012 02:47 PM, Lokesh Vutla wrote:
Samsung's K3PE0E000B memory part is used in OMAP5-evm board.
Adding timings and geometry details for Samsung's memory part and
attaching the same to device-handle of EMIF1/2.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 11 +
arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67
+
2 files changed, 78 insertions(+)
create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 6f87e1a..ed1d1b5 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap5.dtsi
+/include/ samsung_k3pe0e000b.dtsi
/ {
model = TI OMAP5 EVM board;
@@ -82,3 +83,13 @@
0x020700d9;/* SEARCH */
linux,input-no-autorepeat;
};
+
+emif1 {
+ cs1-used;
+ device-handle = samsung_K3PE0E000B;
+};
+
+emif2 {
+ cs1-used;
+ device-handle = samsung_K3PE0E000B;
+};
diff --git a/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
new file mode 100644
index 000..b352d69
--- /dev/null
+++ b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Timings and Geometry for Samsung K3PE0E000B memory part
+ */
+
+/ {
+ samsung_K3PE0E000B: lpddr2 {
+ compatible = Samsung,K3PE0E000B,jedec,lpddr2-s4;
+ density = 4096;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_samsung_K3PE0E000B_533mhz: lpddr2-timings@0 {
Nit, but the official unit is: MHz [1].
Regards,
Benoit
[1] http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf
--
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
Re: [PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
On 11/05/2012 11:51 AM, Benoit Cousson wrote: Hi Lokesh, On 11/05/2012 06:58 AM, Lokesh Vutla wrote: Hi, On Thursday 11 October 2012 06:17 PM, Lokesh Vutla wrote: This patch series adds Device tree data for the EMIF sdram controllers in OMAP5 and LPDDR2 memory devices in OMAP5-evm board. Testing: - Boot tested on OMAP5430 evm. - Built EMIF as a module. Changes from v1: * Created a seperate dtsi file for Samsung LPDDR2 memory device used in OMAP5-evm. * Passing reg and interrupt fields from dt for EMIF1 and EMIF2. Gentle ping on this series. Sorry, I missed it. It might be too late for 3.8, since Tony wanted us to push before -rc4. I'll pull the series anyway just in case. I have a least one comment. Could you just rebase on top of the for_3.8 branch, fix the minor comments and repost ASAP. Thanks, Benoit -- 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
Re: [PATCH] ARM: dts: AM33XX: Add usbss node
+ Felipe
Hi Afzal,
On 11/05/2012 06:59 AM, Afzal Mohammed wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
Device tree node for usbss on AM33XX. There are two musb
controllers on am33xx platform so have port0-mode and
port1-mode data.
[af...@ti.com: reg interrupt property addition]
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi Benoit,
This is based on your for_3.8/dts branch.
This is made on top of usb: musb: am335x support
(http://marc.info/?l=linux-omapm=135187391904863w=2)
and has been tested on Beagle Bone.
That looks good to me, I just like to get an Ack from Felipe for the
accuracy of the data part.
Regards,
Benoit
Regards
Afzal
arch/arm/boot/dts/am33xx.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5dfd682..78340a5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -321,5 +321,22 @@
ti,hwmods = spi1;
status = disabled;
};
+
+ usb_otg_hs@4740 {
+ compatible = ti,musb-am33xx;
+ reg = 0x4740 0x1000/* usbss */
+0x47401000 0x800 /* musb instance 0 */
+0x47401800 0x800; /* musb instance 1 */
+ interrupts = 17/* usbss */
+ 18/* musb instance 0 */
+ 19; /* musb instance 1 */
+ multipoint = 1;
+ num-eps = 16;
+ ram-bits = 12;
+ port0-mode = 3;
+ port1-mode = 3;
+ power = 250;
+ ti,hwmods = usb_otg_hs;
+ };
};
};
--
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
Re: [PATCH v2 2/2] ARM: OMAP: omap_device: Correct resource handling for DT boot
Hi Kevin, On 11/03/2012 09:31 AM, Kevin Hilman wrote: On 10/30/2012 12:24 PM, Peter Ujfalusi wrote: When booting with DT the OF core can fill up the resources provided within the DT blob. The current way of handling the DT boot prevents us from removing hwmod data for platforms only suppose to boot with DT (OMAP5 for example) since we need to keep the whole hwmod database intact in order to have more resources in hwmod than in DT (to be able to append the DMA resource from hwmod). To fix this issue we just examine the OF provided resources: If we do not have resources we use hwmod to fill them. If we have resources we check if we already able to recive DMA resource, if no we only append the DMA resurce from hwmod to the OF provided ones. In this way we can start removing hwmod data for devices which have their resources correctly configured in DT without regressions. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.comke Acked-by: Kevin Hilman khil...@ti.com Benoit, feel free to take this one as well. Thanks, I'll do. Regards, Benoit -- 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
Re: [PATCH 00/10] ARM: dts: AM33XX: Add device tree data
Hi Anil, On 11/05/2012 02:46 PM, AnilKumar, Chimata wrote: On Mon, Nov 05, 2012 at 16:15:40, AnilKumar, Chimata wrote: Add device tree date for GPIO based various drivers matrix keypad, volume keys, push buttons and use leds accross three AM33XX devices viz EVM, BeagleBone and Starter Kit. To make it functional this series also adds pinctrl data for all the GPIOs used by various drivers. In this series only default state pinmux/conf settings are added because of sleep/idle state pinctrl values are not available. These patches are based on linux-omap-dt:for_3.8/dts tree and these My bad, small correction in this statement, these patches apply cleanly on linux-omap-dt:for_3.8/dts tree with the below two patches. http://www.spinics.net/lists/arm-kernel/msg204872.html http://www.spinics.net/lists/arm-kernel/msg204873.html Mmm, this 2 patches do have dependency on some driver changes that might not be accepted for 3.8. And in fact I do have some comment on the RTC one :-) Don't you prefer to change the order to allow me to pull these ones first? Thanks, Benoit -- 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
Re: [PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
Hi Anil / Colin,
On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Added while (1); after the above steps to make sure that no other
process acquire cpu. Otherwise we might see an unexpected behaviour
because we are shutting down all the power rails of SoC except RTC.
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 79
+++-
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
I don't know how it is connected at board level, but I'm not sure the
binding is the proper one.
It does not look super generic, and I'm wondering if we should not use
instead some regulator binding to reflect the connection of the RTC to a
regulator.
But without the board / soc spec it is hard to tell :-(
Regards,
Benoit
+
Example:
rtc@1c23000 {
@@ -14,4 +18,5 @@ rtc@1c23000 {
interrupts = 19
19;
interrupt-parent = intc;
+ ti,system-power-controller;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6009714..2d90170 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,14 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_ALARM2_SECONDS_REG 0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG 0x84
+#define OMAP_RTC_ALARM2_HOURS_REG0x88
+#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
+#define OMAP_RTC_ALARM2_YEARS_REG0x94
+#define OMAP_RTC_PMIC_REG0x98
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT (17)
#define OMAP_RTC_CTRL_DISABLE(16)
@@ -93,15 +101,24 @@
#define OMAP_RTC_STATUS_BUSY(10)
/* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (14)
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_PMIC_REG bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN (116)
+
/* OMAP_RTC_KICKER values */
#define KICK0_VALUE 0x83e70b13
#define KICK1_VALUE 0x95a4f1e0
#define OMAP_RTC_HAS_KICKER 0x1
+#define SHUTDOWN_TIME_SEC2
+#define SECS_IN_MIN 60
+#define WAIT_AFTER (SECS_IN_MIN - SHUTDOWN_TIME_SEC)
+#define WAIT_TIME_MS (SHUTDOWN_TIME_SEC * 1000)
+
static void __iomem *rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -290,6 +307,58 @@ static int omap_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alm)
return 0;
}
+/*
+ * rtc_power_off: Set the pmic power off sequence. The RTC generates
+ * pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
+ */
+static void rtc_power_off(void)
+{
+ u32 val;
+ struct rtc_time tm;
+ spinlock_t lock;
+ unsigned long flags;
+
+ spin_lock_init(lock);
+
+ /* Set PMIC power enable */
+ val = readl(rtc_base + OMAP_RTC_PMIC_REG);
+ writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base + OMAP_RTC_PMIC_REG);
+
+ /* Wait few seconds instead of rollover */
+ do {
+ omap_rtc_read_time(NULL, tm);
+ if (WAIT_AFTER = tm.tm_sec)
+ mdelay(WAIT_TIME_MS);
+ } while (WAIT_AFTER = tm.tm_sec);
+
+ /* Add shutdown time to the current value */
+ tm.tm_sec += SHUTDOWN_TIME_SEC;
+
+ if (tm2bcd(tm) 0)
+ return;
+
+ pr_info(System will go to power_off state in approx. %d secs\n,
+ SHUTDOWN_TIME_SEC);
+
+ /* Set the ALARM2 time */
+ rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
+ rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
+ rtc_write(tm.tm_hour,
Re: [PATCH 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
+ Mark
On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Set tps65217 PMIC status to OFF if power enable toggle is
supported. Also adds platform data flag, which should be
passed from board init data.
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move the additions to tps65217 MFD driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
.../devicetree/bindings/regulator/tps65217.txt |4
drivers/mfd/tps65217.c | 12
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
index d316fb8..4f05d20 100644
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
@@ -11,6 +11,9 @@ Required properties:
using the standard binding for regulators found at
Documentation/devicetree/bindings/regulator/regulator.txt.
+Optional properties:
+- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
That sounds like a generic functionality to me. Don't we have some more
generic way to handle that?
If not, that should probably not be a TI only attribute.
It looks like a GPIO like kind of interface at PMIC level.
Regards,
Benoit
+
The valid names for regulators are:
tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
@@ -20,6 +23,7 @@ Example:
tps: tps@24 {
compatible = ti,tps65217;
+ ti,pmic-shutdown-controller;
regulators {
dcdc1_reg: dcdc1 {
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index 3fb32e6..c7f17d8 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -160,6 +160,7 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
unsigned int version;
unsigned int chip_id = ids-driver_data;
const struct of_device_id *match;
+ bool status_off = false;
int ret;
if (client-dev.of_node) {
@@ -170,6 +171,8 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return -EINVAL;
}
chip_id = (unsigned int)match-data;
+ status_off = of_property_read_bool(client-dev.of_node,
+ ti,pmic-shutdown-controller);
}
if (!chip_id) {
@@ -207,6 +210,15 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return ret;
}
+ /* Set the PMIC to shutdown on PWR_EN toggle */
+ if (status_off) {
+ ret = tps65217_set_bits(tps, TPS65217_REG_STATUS,
+ TPS65217_STATUS_OFF, TPS65217_STATUS_OFF,
+ TPS65217_PROTECT_NONE);
+ if (ret)
+ dev_warn(tps-dev, unable to set the status OFF\n);
+ }
+
dev_info(tps-dev, TPS65217 ID %#x version 1.%d\n,
(version TPS65217_CHIPID_CHIP_MASK) 4,
version TPS65217_CHIPID_REV_MASK);
--
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
Re: [PATCH 1/6] ARM/dts: omap4-panda: Add pinmux configuration for HDMI
Hi Tomi,
On 11/05/2012 02:14 PM, Tomi Valkeinen wrote:
From: Ricardo Neri ricardo.n...@ti.com
Add the pinmux configuration for HDMI and TPD12S015A. Configure the
gpios for the TPD12S015A and SDA, SCL and CEC for HDMI.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-panda-a4.dts | 17 +
arch/arm/boot/dts/omap4-panda.dts| 18 ++
arch/arm/boot/dts/omap4-pandaES.dts |9 +
I've just renamed that file omap4-panda-es.dts for consistency, so you'd
better rebase this series on top on my for_3.8/dts branch that I've just
sent to Tony.
Otherwise, this looks good to me.
Regards,
Benoit
3 files changed, 44 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-panda-a4.dts
diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts
b/arch/arm/boot/dts/omap4-panda-a4.dts
new file mode 100644
index 000..75466d2
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-panda-a4.dts
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/include/ omap4-panda.dts
+
+/* Pandaboard Rev A4+ have external pullups on SCL SDA */
+dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
+ 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
+ ;
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index e8f927c..8060f5b 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -65,6 +65,8 @@
twl6040_pins
mcpdm_pins
mcbsp1_pins
+ dss_hdmi_pins
+ tpd12s015_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -92,6 +94,22 @@
0xc4 0x100 /* abe_mcbsp1_fsx.abe_mcbsp1_fsx INPUT
| MODE0 */
;
};
+
+ dss_hdmi_pins: pinmux_dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP |
MODE 0 */
+ 0x5c 0x118 /* hdmi_scl.hdmi_scl INPUT PULLUP |
MODE 0 */
+ 0x5e 0x118 /* hdmi_sda.hdmi_sda INPUT PULLUP |
MODE 0 */
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x22 0x3/* gpmc_a17.gpio_41 OUTPUT | MODE3 */
+ 0x48 0x3/* gpmc_nbe1.gpio_60 OUTPUT | MODE3 */
+ 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
+ ;
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap4-pandaES.dts
b/arch/arm/boot/dts/omap4-pandaES.dts
index d4ba43a..73bc1a6 100644
--- a/arch/arm/boot/dts/omap4-pandaES.dts
+++ b/arch/arm/boot/dts/omap4-pandaES.dts
@@ -22,3 +22,12 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* PandaboardES has external pullups on SCL SDA */
+dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a 0x118 /* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+ 0x5c 0x100 /* hdmi_scl.hdmi_scl INPUT | MODE 0 */
+ 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
+ ;
+};
--
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 0/3] ARM: OMAP: OMAP4 DTS updates
Hi Tony, Here is a small series I have done for 3.4 but never posted before. It adds GPIO node for twl4030 embedded gpio controller and some LEDs data to be able to get rid of the static init done in board file right now. It is based on arm-soc/omap/dt-missed-3.4 to get the previous patches not yet in linus/master. The patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.5/dts/all Regards, Benoit Benoit Cousson (3): arm/dts: twl4030: Add twl4030-gpio node arm/dts: omap4-sdp: Add LEDs support arm/dts: omap4-panda: Add LEDs support arch/arm/boot/dts/omap4-panda.dts | 15 + arch/arm/boot/dts/omap4-sdp.dts | 43 + arch/arm/boot/dts/twl4030.dtsi|8 +++ 3 files changed, 66 insertions(+), 0 deletions(-) -- 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/3] arm/dts: omap4-sdp: Add LEDs support
Add the debug LEDs nodes for an OMAP4 SDP/Blaze.
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 67b2e98..e5eeb6f 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -27,6 +27,49 @@
enable-active-high;
regulator-boot-on;
};
+
+ leds {
+ compatible = gpio-leds;
+ debug0 {
+ label = omap4:green:debug0;
+ gpios = gpio2 29 0; /* 61 */
+ };
+
+ debug1 {
+ label = omap4:green:debug1;
+ gpios = gpio1 30 0; /* 30 */
+ };
+
+ debug2 {
+ label = omap4:green:debug2;
+ gpios = gpio1 7 0; /* 7 */
+ };
+
+ debug3 {
+ label = omap4:green:debug3;
+ gpios = gpio1 8 0; /* 8 */
+ };
+
+ debug4 {
+ label = omap4:green:debug4;
+ gpios = gpio2 18 0; /* 50 */
+ };
+
+ user1 {
+ label = omap4:blue:user;
+ gpios = gpio6 9 0; /* 169 */
+ };
+
+ user2 {
+ label = omap4:red:user;
+ gpios = gpio6 10 0; /* 170 */
+ };
+
+ user3 {
+ label = omap4:green:user;
+ gpios = gpio5 11 0; /* 139 */
+ };
+ };
};
i2c1 {
--
1.7.0.4
--
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 1/3] arm/dts: twl4030: Add twl4030-gpio node
Add the twl-gpio node inside twl4030 definition.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/twl4030.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index a94654c..22f4d13 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -36,4 +36,12 @@
regulator-min-microvolt = 185;
regulator-max-microvolt = 315;
};
+
+ twl_gpio: gpio {
+ compatible = ti,twl4030-gpio;
+ gpio-controller;
+ #gpio-cells = 2;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ };
};
--
1.7.0.4
--
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 3/3] arm/dts: omap4-panda: Add LEDs support
Add the debug LEDs nodes for an OMAP4 PandaBoard.
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index ea6f5bb..e671361 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -17,6 +17,21 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = pandaboard::status1;
+ gpios = gpio1 7 0;
+ linux,default-trigger = heartbeat;
+ };
+
+ mmc {
+ label = pandaboard::status2;
+ gpios = gpio1 8 0;
+ linux,default-trigger = mmc0;
+ };
+ };
};
i2c1 {
--
1.7.0.4
--
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 0/2] ARM: OMAP2+: Fix errors in PRCM hwmods + wrong clkdm
Hi Paul,
Here is the serie to fix wrong clkdm for the PRCM hwmods.
I did revert as well the patch to make the cm_clkdm and prm_clkdm
common since it does not exist on OMAP4.
I do not thinks it exists in OMAP2 and 3 either, and thus that series should
probably be extended with the total removal of these fake clkdm.
I'd like to get your feedback first on this one to go further for OMAP2 3.
This series is based on 3.5-rc2 and should target -rc3.
Regards,
Benoit
Benoit Cousson (2):
ARM: OMAP2+: hwmod data: Fix the wrong clkdm assigned to PRCM modules
Revert ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common
arch/arm/mach-omap2/Makefile |1 -
arch/arm/mach-omap2/clockdomain44xx.c|6 ---
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 10
arch/arm/mach-omap2/clockdomains44xx_data.c |2 -
arch/arm/mach-omap2/clockdomains_common_data.c | 24 --
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 52 +++---
6 files changed, 36 insertions(+), 59 deletions(-)
delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
--
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 1/2] ARM: OMAP2+: hwmod data: Fix the wrong clkdm assigned to PRCM modules
The following commit (794b480a37e3d284d6ee7344d8a737ef60476ed5) was adding
the PRCM IPs data for PRCM, CM, PRCM_MPU and SCRM.
The clkdm entry are not the correct ones and does not exist in the system.
Replace them with the proper wkup, l4_ao and l4_cfg.
Fix as well the wrong OCP port used by the cm_core_aon. It uses the
l4_cfg interconnect and not the l4_wkup.
Re-order the entries by address value.
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 52 ++--
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..03fc705 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2529,27 +2529,6 @@ static struct omap_hwmod_class omap44xx_prcm_hwmod_class
= {
.name = prcm,
};
-/* prcm_mpu */
-static struct omap_hwmod omap44xx_prcm_mpu_hwmod = {
- .name = prcm_mpu,
- .class = omap44xx_prcm_hwmod_class,
- .clkdm_name = l4_wkup_clkdm,
-};
-
-/* cm_core_aon */
-static struct omap_hwmod omap44xx_cm_core_aon_hwmod = {
- .name = cm_core_aon,
- .class = omap44xx_prcm_hwmod_class,
- .clkdm_name = cm_clkdm,
-};
-
-/* cm_core */
-static struct omap_hwmod omap44xx_cm_core_hwmod = {
- .name = cm_core,
- .class = omap44xx_prcm_hwmod_class,
- .clkdm_name = cm_clkdm,
-};
-
/* prm */
static struct omap_hwmod_irq_info omap44xx_prm_irqs[] = {
{ .irq = 11 + OMAP44XX_IRQ_GIC_START },
@@ -2564,12 +2543,33 @@ static struct omap_hwmod_rst_info omap44xx_prm_resets[]
= {
static struct omap_hwmod omap44xx_prm_hwmod = {
.name = prm,
.class = omap44xx_prcm_hwmod_class,
- .clkdm_name = prm_clkdm,
+ .clkdm_name = l4_wkup_clkdm,
.mpu_irqs = omap44xx_prm_irqs,
.rst_lines = omap44xx_prm_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_prm_resets),
};
+/* cm_core */
+static struct omap_hwmod omap44xx_cm_core_hwmod = {
+ .name = cm_core,
+ .class = omap44xx_prcm_hwmod_class,
+ .clkdm_name = l4_cfg_clkdm,
+};
+
+/* cm_core_aon */
+static struct omap_hwmod omap44xx_cm_core_aon_hwmod = {
+ .name = cm_core_aon,
+ .class = omap44xx_prcm_hwmod_class,
+ .clkdm_name = l4_ao_clkdm,
+};
+
+/* prcm_mpu */
+static struct omap_hwmod omap44xx_prcm_mpu_hwmod = {
+ .name = prcm_mpu,
+ .class = omap44xx_prcm_hwmod_class,
+ .clkdm_name = l4_wkup_clkdm,
+};
+
/*
* 'scrm' class
* system clock and reset manager
@@ -5305,10 +5305,10 @@ static struct omap_hwmod_addr_space
omap44xx_cm_core_aon_addrs[] = {
};
/* l4_wkup - cm_core_aon */
-static struct omap_hwmod_ocp_if omap44xx_l4_wkup__cm_core_aon = {
- .master = omap44xx_l4_wkup_hwmod,
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__cm_core_aon = {
+ .master = omap44xx_l4_cfg_hwmod,
.slave = omap44xx_cm_core_aon_hwmod,
- .clk= l4_wkup_clk_mux_ck,
+ .clk= l4_div_ck,
.addr = omap44xx_cm_core_aon_addrs,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
@@ -6101,7 +6101,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[]
__initdata = {
omap44xx_l3_main_2__ocmc_ram,
omap44xx_l4_cfg__ocp2scp_usb_phy,
omap44xx_mpu_private__prcm_mpu,
- omap44xx_l4_wkup__cm_core_aon,
+ omap44xx_l4_cfg__cm_core_aon,
omap44xx_l4_cfg__cm_core,
omap44xx_l4_wkup__prm,
omap44xx_l4_wkup__scrm,
--
1.7.0.4
--
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] Revert ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common
This reverts commit 6ba5a69ee92c29c2ffc814dad6ac61c4cd49090c.
Conflicts:
arch/arm/mach-omap2/Makefile
Neither prm_clkdm nor cm_clkdm does exist on OMAP4.
Remove the common definition that does not make sense anymore
since it is not common for OMAP2+ platforms.
Please note that these clock domains are probably non existant
on OMAP 2 3 and thus should be removed in all the
clockdomain files.
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile |1 -
arch/arm/mach-omap2/clockdomain44xx.c|6 -
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 10 +
arch/arm/mach-omap2/clockdomains44xx_data.c |2 -
arch/arm/mach-omap2/clockdomains_common_data.c | 24 --
5 files changed, 10 insertions(+), 33 deletions(-)
delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fa742f3..bc7d239 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -116,7 +116,6 @@ obj-$(CONFIG_ARCH_OMAP4)+=
powerdomains44xx_data.o
# PRCM clockdomain control
clockdomain-common += clockdomain.o
-clockdomain-common += clockdomains_common_data.o
obj-$(CONFIG_ARCH_OMAP2) += $(clockdomain-common)
obj-$(CONFIG_ARCH_OMAP2) += clockdomain2xxx_3xxx.o
obj-$(CONFIG_ARCH_OMAP2) += clockdomains2xxx_3xxx_data.o
diff --git a/arch/arm/mach-omap2/clockdomain44xx.c
b/arch/arm/mach-omap2/clockdomain44xx.c
index 4f04dd1..935c7f0 100644
--- a/arch/arm/mach-omap2/clockdomain44xx.c
+++ b/arch/arm/mach-omap2/clockdomain44xx.c
@@ -51,9 +51,6 @@ static int omap4_clkdm_clear_all_wkup_sleep_deps(struct
clockdomain *clkdm)
struct clkdm_dep *cd;
u32 mask = 0;
- if (!clkdm-prcm_partition)
- return 0;
-
for (cd = clkdm-wkdep_srcs; cd cd-clkdm_name; cd++) {
if (!cd-clkdm)
continue; /* only happens if data is erroneous */
@@ -106,9 +103,6 @@ static int omap4_clkdm_clk_disable(struct clockdomain
*clkdm)
{
bool hwsup = false;
- if (!clkdm-prcm_partition)
- return 0;
-
hwsup = omap4_cminst_is_clkdm_in_hwsup(clkdm-prcm_partition,
clkdm-cm_inst, clkdm-clkdm_offs);
diff --git a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
index 839145e..0a6a048 100644
--- a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
@@ -89,3 +89,13 @@ struct clockdomain wkup_common_clkdm = {
.pwrdm = { .name = wkup_pwrdm },
.dep_bit= OMAP_EN_WKUP_SHIFT,
};
+
+struct clockdomain prm_common_clkdm = {
+ .name = prm_clkdm,
+ .pwrdm = { .name = wkup_pwrdm },
+};
+
+struct clockdomain cm_common_clkdm = {
+ .name = cm_clkdm,
+ .pwrdm = { .name = core_pwrdm },
+};
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index c534258..bd7ed13 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -430,8 +430,6 @@ static struct clockdomain *clockdomains_omap44xx[]
__initdata = {
l4_wkup_44xx_clkdm,
emu_sys_44xx_clkdm,
l3_dma_44xx_clkdm,
- prm_common_clkdm,
- cm_common_clkdm,
NULL
};
diff --git a/arch/arm/mach-omap2/clockdomains_common_data.c
b/arch/arm/mach-omap2/clockdomains_common_data.c
deleted file mode 100644
index 615b1f0..000
--- a/arch/arm/mach-omap2/clockdomains_common_data.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * OMAP2+-common clockdomain data
- *
- * Copyright (C) 2008-2012 Texas Instruments, Inc.
- * Copyright (C) 2008-2010 Nokia Corporation
- *
- * Paul Walmsley, Jouni Högander
- */
-
-#include linux/kernel.h
-#include linux/io.h
-
-#include clockdomain.h
-
-/* These are implicit clockdomains - they are never defined as such in TRM */
-struct clockdomain prm_common_clkdm = {
- .name = prm_clkdm,
- .pwrdm = { .name = wkup_pwrdm },
-};
-
-struct clockdomain cm_common_clkdm = {
- .name = cm_clkdm,
- .pwrdm = { .name = core_pwrdm },
-};
--
1.7.0.4
--
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
Re: [PATCH-V3 3/3] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
Hi Vaibhav, One small comment. On 06/28/2012 04:59 PM, Vaibhav Hiremath wrote: The function __omap2_set_globals() can be common across all platforms/architectures, even in case of omap4, internally it calls same set of functions as in __omap2_set_globals() function (except for sdrc). This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc, so that we can reuse same function across omap2/3/4... Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Changes from V1: - Added Makefile rule to build sdrc.c file for new option SOC_HAS_OMAP2_SDRC (as per Kevin's comment). --- arch/arm/mach-omap2/Kconfig |8 arch/arm/mach-omap2/Makefile |3 ++- arch/arm/mach-omap2/common.c |8 +--- arch/arm/mach-omap2/common.h |5 + 4 files changed, 16 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 208b950..82d9d18 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -21,12 +21,16 @@ config ARCH_OMAP2PLUS_TYPICAL help Compile a kernel suitable for booting most boards +config SOC_HAS_OMAP2_SDRC + bool OMAP2 SDRAM Controller support + config ARCH_OMAP2 bool TI OMAP2 depends on ARCH_OMAP2PLUS default y select CPU_V6 select MULTI_IRQ_HANDLER + select SOC_HAS_OMAP2_SDRC config ARCH_OMAP3 bool TI OMAP3 @@ -39,6 +43,7 @@ config ARCH_OMAP3 select PM_OPP if PM select ARM_CPU_SUSPEND if PM select MULTI_IRQ_HANDLER + select SOC_HAS_OMAP2_SDRC config ARCH_OMAP4 bool TI OMAP4 @@ -66,16 +71,19 @@ config SOC_OMAP2420 depends on ARCH_OMAP2 default y select OMAP_DM_TIMER + select SOC_HAS_OMAP2_SDRC OMAP4 does not have the SDRC but the EMIF like TI8XX. Regards, Benoit -- 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
Re: [PATCH-V3 3/3] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
On 06/28/2012 05:39 PM, Hiremath, Vaibhav wrote: On Thu, Jun 28, 2012 at 20:35:38, Cousson, Benoit wrote: Hi Vaibhav, One small comment. On 06/28/2012 04:59 PM, Vaibhav Hiremath wrote: The function __omap2_set_globals() can be common across all platforms/architectures, even in case of omap4, internally it calls same set of functions as in __omap2_set_globals() function (except for sdrc). This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc, so that we can reuse same function across omap2/3/4... Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Changes from V1: - Added Makefile rule to build sdrc.c file for new option SOC_HAS_OMAP2_SDRC (as per Kevin's comment). --- arch/arm/mach-omap2/Kconfig |8 arch/arm/mach-omap2/Makefile |3 ++- arch/arm/mach-omap2/common.c |8 +--- arch/arm/mach-omap2/common.h |5 + 4 files changed, 16 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 208b950..82d9d18 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -21,12 +21,16 @@ config ARCH_OMAP2PLUS_TYPICAL help Compile a kernel suitable for booting most boards +config SOC_HAS_OMAP2_SDRC + bool OMAP2 SDRAM Controller support + config ARCH_OMAP2 bool TI OMAP2 depends on ARCH_OMAP2PLUS default y select CPU_V6 select MULTI_IRQ_HANDLER + select SOC_HAS_OMAP2_SDRC config ARCH_OMAP3 bool TI OMAP3 @@ -39,6 +43,7 @@ config ARCH_OMAP3 select PM_OPP if PM select ARM_CPU_SUSPEND if PM select MULTI_IRQ_HANDLER + select SOC_HAS_OMAP2_SDRC config ARCH_OMAP4 bool TI OMAP4 @@ -66,16 +71,19 @@ config SOC_OMAP2420 depends on ARCH_OMAP2 default y select OMAP_DM_TIMER + select SOC_HAS_OMAP2_SDRC OMAP4 does not have the SDRC but the EMIF like TI8XX. Benoit, This selection is happening for SOC_OMAP2420 and not for OMAP4. Hehe, indeed, I missed the context and was fooled by the config ARCH_OMAP4. I don't have any comment then :-) Benoit -- 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
Re: [PATCH] OMAP4: Clock: Correct OTG clock to use otg_60m_gfclk.
On 06/29/2012 10:35 PM, Paul Walmsley wrote:
+ Benoît who is the maintainer of this file
+ the linux-arm-kernel mailing list, which should be cc'ed on all OMAP
patches
On Fri, 29 Jun 2012, Ruslan Bilovol wrote:
From: Wenbiao Wang ww...@ti.com
OTG clock usb_otg_hs_ick used a incorrect parent l3_div_ck.
Correct it to use the right colck otg_60m_gfclk as its
parent.
Mmm, that does not seems to be correct.
otg_60m_gfclk is an optional clock. The interface clock is the main
clock of that module. That's why this is the parent of the fake
MODULEMODE clock node.
Moreover you are changing as well the utmi_phy_clkout_ck. That's not
mentioned at all in the changelog.
I know that there are some non standard stuff in this clock scheme.
The main reason being the utmi_phy_clkout_ck source is generated from
the usb_phy module. Unfortunately the clock fmwk cannot handle module as
a clock node.
So, as of today, this only way to get the OTG_60M_FCLK clock available
is to ensure that the usb_phy module is enabled before the usb_otg_hs
module.
Regards,
Benoit
Signed-off-by: Wenbiao Wang ww...@ti.com
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index b825049..fd43214 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -199,12 +199,6 @@ static struct clk tie_low_clock_ck = {
.ops= clkops_null,
};
-static struct clk utmi_phy_clkout_ck = {
- .name = utmi_phy_clkout_ck,
- .rate = 6000,
- .ops= clkops_null,
-};
-
static struct clk xclk60mhsp1_ck = {
.name = xclk60mhsp1_ck,
.rate = 6000,
@@ -992,6 +986,13 @@ static struct clk dpll_usb_clkdcoldo_ck = {
.recalc = followparent_recalc,
};
+static struct clk utmi_phy_clkout_ck = {
+ .name = utmi_phy_clkout_ck,
+ .ops= clkops_null,
+ .parent = dpll_usb_clkdcoldo_ck,
+ .recalc = followparent_recalc,
+};
+
static const struct clksel dpll_usb_m2_div[] = {
{ .parent = dpll_usb_ck, .rates = div31_1to31_rates },
{ .parent = NULL },
@@ -2685,7 +2686,7 @@ static struct clk usb_otg_hs_ick = {
.enable_reg = OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
.clkdm_name = l3_init_clkdm,
- .parent = l3_div_ck,
+ .parent = otg_60m_gfclk,
.recalc = followparent_recalc,
};
Benoît should have a look at this one, I think.
- Paul
--
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 0/3] OMAP4: PRCM fixes
Hi Paul Rajendra, Here are a couple of fixes on PRCM header files and powerdomain data. The series is based on v3.0-rc4 and tested on OMAP4430 ES2.1 + SDP. The patches are available here: git://gitorious.org/omap-pm/linux.git for_3.0.1/1_prcm_files_fixes Regards, Benoit Benoit Cousson (3): OMAP4: pcrm: Fix errors in few defines name OMAP4: prm: Remove wrong clockdomain offsets OMAP4: powerdomain data: Fix core mem states and missing cefuse flag arch/arm/mach-omap2/cm1_44xx.h | 28 +++--- arch/arm/mach-omap2/cm2_44xx.h | 23 - arch/arm/mach-omap2/powerdomains44xx_data.c | 25 ++- arch/arm/mach-omap2/prm44xx.h | 34 -- 4 files changed, 49 insertions(+), 61 deletions(-) -- 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 1/3] OMAP4: pcrm: Fix errors in few defines name
A couple of macros were wrongly changed during the _MOD to _INST rename done in the following commit: OMAP4: PRCM: rename _MOD macros to _INST cdb54c4457d68994da7c2e16907adfbfc130060d Fix them to their original name. Some CM and PRM instances were not well aligned. Align them. Remove one blank line in cm2_44xx.h to align the output with the other (cm1_44xx.h, prm44xx.h) files. Replace one tab with space. Update header copyright date. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/cm1_44xx.h | 28 ++-- arch/arm/mach-omap2/cm2_44xx.h | 23 +++ arch/arm/mach-omap2/prm44xx.h | 22 +++--- 3 files changed, 36 insertions(+), 37 deletions(-) diff --git a/arch/arm/mach-omap2/cm1_44xx.h b/arch/arm/mach-omap2/cm1_44xx.h index e2d7a56..fc649f5 100644 --- a/arch/arm/mach-omap2/cm1_44xx.h +++ b/arch/arm/mach-omap2/cm1_44xx.h @@ -1,7 +1,7 @@ /* * OMAP44xx CM1 instance offset macros * - * Copyright (C) 2009-2010 Texas Instruments, Inc. + * Copyright (C) 2009-2011 Texas Instruments, Inc. * Copyright (C) 2009-2010 Nokia Corporation * * Paul Walmsley (p...@pwsan.com) @@ -41,9 +41,9 @@ #define OMAP4430_CM1_INSTR_INST0x0f00 /* CM1 clockdomain register offsets (from instance start) */ -#define OMAP4430_CM1_ABE_ABE_CDOFFS0x -#define OMAP4430_CM1_MPU_MPU_CDOFFS0x -#define OMAP4430_CM1_TESLA_TESLA_CDOFFS0x +#define OMAP4430_CM1_MPU_MPU_CDOFFS0x +#define OMAP4430_CM1_TESLA_TESLA_CDOFFS0x +#define OMAP4430_CM1_ABE_ABE_CDOFFS0x /* CM1 */ @@ -82,8 +82,8 @@ #define OMAP4430_CM_DIV_M7_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x0044) #define OMAP4_CM_SSC_DELTAMSTEP_DPLL_CORE_OFFSET 0x0048 #define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x0048) -#define OMAP4_CM_SSC_INSTFREQDIV_DPLL_CORE_OFFSET 0x004c -#define OMAP4430_CM_SSC_INSTFREQDIV_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x004c) +#define OMAP4_CM_SSC_MODFREQDIV_DPLL_CORE_OFFSET 0x004c +#define OMAP4430_CM_SSC_MODFREQDIV_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x004c) #define OMAP4_CM_EMU_OVERRIDE_DPLL_CORE_OFFSET 0x0050 #define OMAP4430_CM_EMU_OVERRIDE_DPLL_CORE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x0050) #define OMAP4_CM_CLKMODE_DPLL_MPU_OFFSET 0x0060 @@ -98,8 +98,8 @@ #define OMAP4430_CM_DIV_M2_DPLL_MPU OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x0070) #define OMAP4_CM_SSC_DELTAMSTEP_DPLL_MPU_OFFSET0x0088 #define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_MPU OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x0088) -#define OMAP4_CM_SSC_INSTFREQDIV_DPLL_MPU_OFFSET 0x008c -#define OMAP4430_CM_SSC_INSTFREQDIV_DPLL_MPU OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x008c) +#define OMAP4_CM_SSC_MODFREQDIV_DPLL_MPU_OFFSET0x008c +#define OMAP4430_CM_SSC_MODFREQDIV_DPLL_MPU OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x008c) #define OMAP4_CM_BYPCLK_DPLL_MPU_OFFSET0x009c #define OMAP4430_CM_BYPCLK_DPLL_MPU OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x009c) #define OMAP4_CM_CLKMODE_DPLL_IVA_OFFSET 0x00a0 @@ -116,8 +116,8 @@ #define OMAP4430_CM_DIV_M5_DPLL_IVA OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x00bc) #define OMAP4_CM_SSC_DELTAMSTEP_DPLL_IVA_OFFSET0x00c8 #define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_IVA OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x00c8) -#define OMAP4_CM_SSC_INSTFREQDIV_DPLL_IVA_OFFSET 0x00cc -#define OMAP4430_CM_SSC_INSTFREQDIV_DPLL_IVA OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x00cc) +#define OMAP4_CM_SSC_MODFREQDIV_DPLL_IVA_OFFSET0x00cc +#define OMAP4430_CM_SSC_MODFREQDIV_DPLL_IVA OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x00cc) #define OMAP4_CM_BYPCLK_DPLL_IVA_OFFSET0x00dc #define OMAP4430_CM_BYPCLK_DPLL_IVA OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x00dc) #define OMAP4_CM_CLKMODE_DPLL_ABE_OFFSET 0x00e0 @@ -134,8 +134,8 @@ #define OMAP4430_CM_DIV_M3_DPLL_ABE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x00f4) #define OMAP4_CM_SSC_DELTAMSTEP_DPLL_ABE_OFFSET0x0108 #define OMAP4430_CM_SSC_DELTAMSTEP_DPLL_ABE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x0108) -#define OMAP4_CM_SSC_INSTFREQDIV_DPLL_ABE_OFFSET 0x010c -#define OMAP4430_CM_SSC_INSTFREQDIV_DPLL_ABE OMAP44XX_CM1_REGADDR(OMAP4430_CM1_CKGEN_INST, 0x010c) +#define OMAP4_CM_SSC_MODFREQDIV_DPLL_ABE_OFFSET
[PATCH 2/3] OMAP4: prm: Remove wrong clockdomain offsets
The following commit introduced new macros to define an offset per clock domain in an instance. commit e4156ee52fe617c2c2d80b5db993ff4bf07d7c3c OMAP4: CM instances: add clockdomain register offsets The PRM contains only two clock controls management entities: EMU and WKUP. Remove the other ones. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/prm44xx.h | 12 1 files changed, 0 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h index 2aec8c8..6e53120 100644 --- a/arch/arm/mach-omap2/prm44xx.h +++ b/arch/arm/mach-omap2/prm44xx.h @@ -57,19 +57,7 @@ #define OMAP4430_PRM_INSTR_INST0x1f00 /* PRM clockdomain register offsets (from instance start) */ -#define OMAP4430_PRM_MPU_MPU_CDOFFS0x -#define OMAP4430_PRM_TESLA_TESLA_CDOFFS0x -#define OMAP4430_PRM_ABE_ABE_CDOFFS0x -#define OMAP4430_PRM_CORE_CORE_CDOFFS 0x -#define OMAP4430_PRM_IVAHD_IVAHD_CDOFFS0x -#define OMAP4430_PRM_CAM_CAM_CDOFFS0x -#define OMAP4430_PRM_DSS_DSS_CDOFFS0x -#define OMAP4430_PRM_GFX_GFX_CDOFFS0x -#define OMAP4430_PRM_L3INIT_L3INIT_CDOFFS 0x -#define OMAP4430_PRM_L4PER_L4PER_CDOFFS0x -#define OMAP4430_PRM_CEFUSE_CEFUSE_CDOFFS 0x #define OMAP4430_PRM_WKUP_CM_WKUP_CDOFFS 0x -#define OMAP4430_PRM_EMU_EMU_CDOFFS0x #define OMAP4430_PRM_EMU_CM_EMU_CDOFFS 0x /* OMAP4 specific register offsets */ -- 1.7.0.4 -- 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 3/3] OMAP4: powerdomain data: Fix core mem states and missing cefuse flag
Since ES2.0, the core ocmram does not support a different state
than the main power domain anymore during both ON and RET power
domain state.
Since PM is not supported at all in ES1.0, update the common
structure.
LOWPOWERSTATECHANGE is supported by the cefuse power domain but
the flag was missing.
Add the PWRDM_HAS_LOWPOWERSTATECHANGE in flags field.
Indent all previous flags to be aligned with other fields.
Update the TI copyright date to 2011.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/powerdomains44xx_data.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index c4222c7..8f46e7d 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -1,7 +1,7 @@
/*
* OMAP4 Power domains framework
*
- * Copyright (C) 2009-2010 Texas Instruments, Inc.
+ * Copyright (C) 2009-2011 Texas Instruments, Inc.
* Copyright (C) 2009-2011 Nokia Corporation
*
* Abhijit Pagare (abhijitpag...@ti.com)
@@ -41,19 +41,19 @@ static struct powerdomain core_44xx_pwrdm = {
.banks= 5,
.pwrsts_mem_ret = {
[0] = PWRSTS_OFF, /* core_nret_bank */
- [1] = PWRSTS_OFF_RET, /* core_ocmram */
+ [1] = PWRSTS_RET, /* core_ocmram */
[2] = PWRSTS_RET, /* core_other_bank */
[3] = PWRSTS_OFF_RET, /* ducati_l2ram */
[4] = PWRSTS_OFF_RET, /* ducati_unicache */
},
.pwrsts_mem_on = {
[0] = PWRSTS_ON,/* core_nret_bank */
- [1] = PWRSTS_OFF_RET, /* core_ocmram */
+ [1] = PWRSTS_ON,/* core_ocmram */
[2] = PWRSTS_ON,/* core_other_bank */
[3] = PWRSTS_ON,/* ducati_l2ram */
[4] = PWRSTS_ON,/* ducati_unicache */
},
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
};
/* gfx_44xx_pwrdm: 3D accelerator power domain */
@@ -70,7 +70,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
.pwrsts_mem_on = {
[0] = PWRSTS_ON,/* gfx_mem */
},
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
};
/* abe_44xx_pwrdm: Audio back end power domain */
@@ -90,7 +90,7 @@ static struct powerdomain abe_44xx_pwrdm = {
[0] = PWRSTS_ON,/* aessmem */
[1] = PWRSTS_ON,/* periphmem */
},
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
};
/* dss_44xx_pwrdm: Display subsystem power domain */
@@ -108,7 +108,7 @@ static struct powerdomain dss_44xx_pwrdm = {
.pwrsts_mem_on = {
[0] = PWRSTS_ON,/* dss_mem */
},
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
};
/* tesla_44xx_pwrdm: Tesla processor power domain */
@@ -130,7 +130,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
[1] = PWRSTS_ON,/* tesla_l1 */
[2] = PWRSTS_ON,/* tesla_l2 */
},
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
};
/* wkup_44xx_pwrdm: Wake-up power domain */
@@ -241,7 +241,7 @@ static struct powerdomain ivahd_44xx_pwrdm = {
[2] = PWRSTS_ON,/* tcm1_mem */
[3] = PWRSTS_ON,/* tcm2_mem */
},
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
};
/* cam_44xx_pwrdm: Camera subsystem power domain */
@@ -258,7 +258,7 @@ static struct powerdomain cam_44xx_pwrdm = {
.pwrsts_mem_on = {
[0] = PWRSTS_ON,/* cam_mem */
},
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
};
/* l3init_44xx_pwrdm: L3 initators pheripherals power domain */
@@ -276,7 +276,7 @@ static struct powerdomain l3init_44xx_pwrdm = {
.pwrsts_mem_on = {
[0] = PWRSTS_ON,/* l3init_bank1 */
},
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE,
+ .flags= PWRDM_HAS_LOWPOWERSTATECHANGE,
};
/* l4per_44xx_pwrdm: Target peripherals power domain */
@@ -296,7 +296,7 @@ static struct powerdomain l4per_44xx_pwrdm = {
[0] = PWRSTS_ON,/* nonretained_bank */
[1] = PWRSTS_ON,/* retained_bank */
},
- .flags = PWRDM_HAS_LOWPOWERSTATECHANGE
[PATCH 00/16] OMAP4: PRCM big spring (late) cleanup
Hi Paul, Here are a bunch of cleanups on almost every PRCM related files. Some of them are purely code moves, and will look like a lot of noise for nothing, but this is needed if we want to keep the files aligned with generator tool and thus ease the future migration to whatever format (common clock framework + DT). Moreover, the diffstat is negative:-) The series is based on for_3.0.1/1_prcm_files_fixes and tested on OMAP4430 ES2.1 + SDP. The patches are available here: git://gitorious.org/omap-pm/linux.git for_3.0.1/2_prcm_files_cleanup Regards, Benoit Benoit Cousson (12): OMAP4: cm: Remove RESTORE macros to avoid access from SW OMAP4: prcm_mpu: Fix indent in few macros OMAP4: clockdomain data: Fix data order and wrong name OMAP4: clock data: Add sddiv to USB DPLL OMAP4: clock data: Remove usb_host_fs clkdev with NULL dev OMAP4: clock data: Re-order some clock nodes and structure fields OMAP4: clock data: Fix max mult and div for USB DPLL OMAP4: prcm: Remove references to non-existant peripherals OMAP4: hwmod data: Fix L3 interconnect data order and alignement OMAP4: hwmod data: Remove un-needed parens OMAP4: hwmod data: Fix typo and alignement OMAP4: hwmod data: Replace CHIP_IS_OMAP4430 by OMAP44XX Jon Hunter (2): OMAP4: clock data: Remove McASP2, McASP3 and MMC6 clocks OMAP4: clock data: Remove UNIPRO clock nodes Rajendra Nayak (2): OMAP4: clock data: Rename clock flags from 443X to 44XX OMAP4: clock data: Add missing divider selection for auxclks arch/arm/mach-omap2/clock44xx.h |7 - arch/arm/mach-omap2/clock44xx_data.c | 1010 + arch/arm/mach-omap2/clockdomains44xx_data.c | 124 ++-- arch/arm/mach-omap2/cm-regbits-44xx.h | 702 +++--- arch/arm/mach-omap2/cm1_44xx.h| 36 - arch/arm/mach-omap2/cm2_44xx.h| 90 --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c| 244 +++--- arch/arm/mach-omap2/prcm_mpu44xx.h| 69 +- arch/arm/mach-omap2/prm-regbits-44xx.h| 178 + arch/arm/mach-omap2/prm44xx.h | 64 -- arch/arm/plat-omap/include/plat/clkdev_omap.h |2 + arch/arm/plat-omap/include/plat/clock.h |3 +- arch/arm/plat-omap/include/plat/cpu.h |2 + 13 files changed, 1068 insertions(+), 1463 deletions(-) -- 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 03/16] OMAP4: clockdomain data: Fix data order and wrong name
MPUSS was renamed MPU and L3_D2D D2D.
The rename will slightly change the order of the structure
and thus generate some structures moves.
Add a comment and remove a comma.
Update Copyright for TI and Nokia and add back Paul
in the author list.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clockdomains44xx_data.c | 124 ++-
1 files changed, 63 insertions(+), 61 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index a607ec1..66090f2 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -1,11 +1,12 @@
/*
* OMAP4 Clock domains framework
*
- * Copyright (C) 2009 Texas Instruments, Inc.
- * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009-2011 Texas Instruments, Inc.
+ * Copyright (C) 2009-2011 Nokia Corporation
*
* Abhijit Pagare (abhijitpag...@ti.com)
* Benoit Cousson (b-cous...@ti.com)
+ * Paul Walmsley (p...@pwsan.com)
*
* This file is automatically generated from the OMAP hardware databases.
* We respectfully ask that any modifications to this file be coordinated
@@ -32,7 +33,7 @@
/* Static Dependencies for OMAP4 Clock Domains */
-static struct clkdm_dep ducati_wkup_sleep_deps[] = {
+static struct clkdm_dep d2d_wkup_sleep_deps[] = {
{
.clkdm_name = abe_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
@@ -50,103 +51,103 @@ static struct clkdm_dep ducati_wkup_sleep_deps[] = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = l3_dss_clkdm,
+ .clkdm_name = l3_emif_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = l3_emif_clkdm,
+ .clkdm_name = l3_init_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = l3_gfx_clkdm,
+ .clkdm_name = l4_cfg_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = l3_init_clkdm,
+ .clkdm_name = l4_per_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
+ { NULL },
+};
+
+static struct clkdm_dep ducati_wkup_sleep_deps[] = {
{
- .clkdm_name = l4_cfg_clkdm,
+ .clkdm_name = abe_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = l4_per_clkdm,
+ .clkdm_name = ivahd_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = l4_secure_clkdm,
+ .clkdm_name = l3_1_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = l4_wkup_clkdm,
+ .clkdm_name = l3_2_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = tesla_clkdm,
+ .clkdm_name = l3_dss_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
- { NULL },
-};
-
-static struct clkdm_dep iss_wkup_sleep_deps[] = {
{
- .clkdm_name = ivahd_clkdm,
+ .clkdm_name = l3_emif_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = l3_1_clkdm,
+ .clkdm_name = l3_gfx_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = l3_emif_clkdm,
+ .clkdm_name = l3_init_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
- { NULL },
-};
-
-static struct clkdm_dep ivahd_wkup_sleep_deps[] = {
{
- .clkdm_name = l3_1_clkdm,
+ .clkdm_name = l4_cfg_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = l3_emif_clkdm,
+ .clkdm_name = l4_per_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
- { NULL },
-};
-
-static struct clkdm_dep l3_d2d_wkup_sleep_deps[] = {
{
- .clkdm_name = abe_clkdm,
+ .clkdm_name = l4_secure_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
},
{
- .clkdm_name = ivahd_clkdm,
+ .clkdm_name = l4_wkup_clkdm,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430
[PATCH 04/16] OMAP4: clock data: Add sddiv to USB DPLL
The USB DPLL is a J-Type DPLL with the sddiv extra parameter.
On the other hand, the UNIPRO is not a J-Type and thus does
not require this flag.
Add it in USB DPLL and remove it in UNIPRO DPLL.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 8c96567..227befb 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -949,7 +949,6 @@ static struct dpll_data dpll_unipro_dd = {
.enable_mask= OMAP4430_DPLL_EN_MASK,
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
- .sddiv_mask = OMAP4430_DPLL_SD_DIV_MASK,
.max_multiplier = OMAP4430_MAX_DPLL_MULT,
.max_divider= OMAP4430_MAX_DPLL_DIV,
.min_divider= 1,
@@ -1015,6 +1014,7 @@ static struct dpll_data dpll_usb_dd = {
.enable_mask= OMAP4430_DPLL_EN_MASK,
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
+ .sddiv_mask = OMAP4430_DPLL_SD_DIV_MASK,
.max_multiplier = OMAP4430_MAX_DPLL_MULT,
.max_divider= OMAP4430_MAX_DPLL_DIV,
.min_divider= 1,
--
1.7.0.4
--
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 06/16] OMAP4: clock data: Re-order some clock nodes and structure fields
A couple of fields were edited manually and thus do not stick
to the template used by the generator and by other structures.
Move them to the correct location.
Fix the wrong .ops for the dpll_unipro_x2_ck node.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock44xx_data.c | 66 +
1 files changed, 34 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 52f3e39..555044d 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -53,9 +53,9 @@ static struct clk extalt_clkin_ck = {
static struct clk pad_clks_ck = {
.name = pad_clks_ck,
.rate = 1200,
- .ops= clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_CLKSEL_ABE,
- .enable_bit = OMAP4430_PAD_CLKS_GATE_SHIFT,
+ .ops= clkops_omap2_dflt,
+ .enable_reg = OMAP4430_CM_CLKSEL_ABE,
+ .enable_bit = OMAP4430_PAD_CLKS_GATE_SHIFT,
};
static struct clk pad_slimbus_core_clks_ck = {
@@ -73,9 +73,9 @@ static struct clk secure_32k_clk_src_ck = {
static struct clk slimbus_clk = {
.name = slimbus_clk,
.rate = 1200,
- .ops= clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_CLKSEL_ABE,
- .enable_bit = OMAP4430_SLIMBUS_CLK_GATE_SHIFT,
+ .ops= clkops_omap2_dflt,
+ .enable_reg = OMAP4430_CM_CLKSEL_ABE,
+ .enable_bit = OMAP4430_SLIMBUS_CLK_GATE_SHIFT,
};
static struct clk sys_32k_ck = {
@@ -278,10 +278,10 @@ static struct clk dpll_abe_ck = {
static struct clk dpll_abe_x2_ck = {
.name = dpll_abe_x2_ck,
.parent = dpll_abe_ck,
+ .clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
.flags = CLOCK_CLKOUTX2,
.ops= clkops_omap4_dpllmx_ops,
.recalc = omap3_clkoutx2_recalc,
- .clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
};
static const struct clksel_rate div31_1to31_rates[] = {
@@ -622,11 +622,11 @@ static struct clk dpll_core_m3x2_ck = {
.clksel_reg = OMAP4430_CM_DIV_M3_DPLL_CORE,
.clksel_mask= OMAP4430_DPLL_CLKOUTHIF_DIV_MASK,
.ops= clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_DIV_M3_DPLL_CORE,
- .enable_bit = OMAP4430_DPLL_CLKOUTHIF_GATE_CTRL_SHIFT,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
.set_rate = omap2_clksel_set_rate,
+ .enable_reg = OMAP4430_CM_DIV_M3_DPLL_CORE,
+ .enable_bit = OMAP4430_DPLL_CLKOUTHIF_GATE_CTRL_SHIFT,
};
static struct clk dpll_core_m7x2_ck = {
@@ -850,10 +850,10 @@ static struct clk dpll_per_m2_ck = {
static struct clk dpll_per_x2_ck = {
.name = dpll_per_x2_ck,
.parent = dpll_per_ck,
+ .clksel_reg = OMAP4430_CM_DIV_M2_DPLL_PER,
.flags = CLOCK_CLKOUTX2,
.ops= clkops_omap4_dpllmx_ops,
.recalc = omap3_clkoutx2_recalc,
- .clksel_reg = OMAP4430_CM_DIV_M2_DPLL_PER,
};
static const struct clksel dpll_per_m2x2_div[] = {
@@ -880,11 +880,11 @@ static struct clk dpll_per_m3x2_ck = {
.clksel_reg = OMAP4430_CM_DIV_M3_DPLL_PER,
.clksel_mask= OMAP4430_DPLL_CLKOUTHIF_DIV_MASK,
.ops= clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_DIV_M3_DPLL_PER,
- .enable_bit = OMAP4430_DPLL_CLKOUTHIF_GATE_CTRL_SHIFT,
.recalc = omap2_clksel_recalc,
.round_rate = omap2_clksel_round_rate,
.set_rate = omap2_clksel_set_rate,
+ .enable_reg = OMAP4430_CM_DIV_M3_DPLL_PER,
+ .enable_bit = OMAP4430_DPLL_CLKOUTHIF_GATE_CTRL_SHIFT,
};
static struct clk dpll_per_m4x2_ck = {
@@ -969,8 +969,9 @@ static struct clk dpll_unipro_ck = {
static struct clk dpll_unipro_x2_ck = {
.name = dpll_unipro_x2_ck,
.parent = dpll_unipro_ck,
+ .clksel_reg = OMAP4430_CM_DIV_M2_DPLL_UNIPRO,
.flags = CLOCK_CLKOUTX2,
- .ops= clkops_null,
+ .ops= clkops_omap4_dpllmx_ops,
.recalc = omap3_clkoutx2_recalc,
};
@@ -1035,8 +1036,8 @@ static struct clk dpll_usb_ck = {
static struct clk dpll_usb_clkdcoldo_ck = {
.name = dpll_usb_clkdcoldo_ck,
.parent = dpll_usb_ck,
- .ops= clkops_omap4_dpllmx_ops,
.clksel_reg = OMAP4430_CM_CLKDCOLDO_DPLL_USB,
+ .ops= clkops_omap4_dpllmx_ops,
.recalc = followparent_recalc,
};
@@ -1846,8 +1847,8 @@ static struct clk l3_instr_ick = {
.ops= clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_L3INSTR_L3_INSTR_CLKCTRL,
.enable_bit
[PATCH 07/16] OMAP4: clock data: Fix max mult and div for USB DPLL
The DPLL USB can generate higher speed (x2) than the regular ones.
The max multiplication value is then twice the previous value.
Fix both max_mult and max_div with that correct values.
Change the max_div variable type to u16 to allow storing up to 256.
Replace as well the define with the value to avoid
unneeded indirection and provide a better readability.
Remove the defines that become useless.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx.h |7 ---
arch/arm/mach-omap2/clock44xx_data.c| 28 ++--
arch/arm/plat-omap/include/plat/clock.h |2 +-
3 files changed, 15 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx.h b/arch/arm/mach-omap2/clock44xx.h
index 6be1095..7ceb870 100644
--- a/arch/arm/mach-omap2/clock44xx.h
+++ b/arch/arm/mach-omap2/clock44xx.h
@@ -8,13 +8,6 @@
#ifndef __ARCH_ARM_MACH_OMAP2_CLOCK44XX_H
#define __ARCH_ARM_MACH_OMAP2_CLOCK44XX_H
-/*
- * XXX Missing values for the OMAP4 DPLL_USB
- * XXX Missing min_multiplier values for all OMAP4 DPLLs
- */
-#define OMAP4430_MAX_DPLL_MULT 2047
-#define OMAP4430_MAX_DPLL_DIV 128
-
int omap4xxx_clk_init(void);
#endif
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 555044d..8307c9e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -258,8 +258,8 @@ static struct dpll_data dpll_abe_dd = {
.enable_mask= OMAP4430_DPLL_EN_MASK,
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
- .max_multiplier = OMAP4430_MAX_DPLL_MULT,
- .max_divider= OMAP4430_MAX_DPLL_DIV,
+ .max_multiplier = 2047,
+ .max_divider= 128,
.min_divider= 1,
};
@@ -434,8 +434,8 @@ static struct dpll_data dpll_core_dd = {
.enable_mask= OMAP4430_DPLL_EN_MASK,
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
- .max_multiplier = OMAP4430_MAX_DPLL_MULT,
- .max_divider= OMAP4430_MAX_DPLL_DIV,
+ .max_multiplier = 2047,
+ .max_divider= 128,
.min_divider= 1,
};
@@ -672,8 +672,8 @@ static struct dpll_data dpll_iva_dd = {
.enable_mask= OMAP4430_DPLL_EN_MASK,
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
- .max_multiplier = OMAP4430_MAX_DPLL_MULT,
- .max_divider= OMAP4430_MAX_DPLL_DIV,
+ .max_multiplier = 2047,
+ .max_divider= 128,
.min_divider= 1,
};
@@ -740,8 +740,8 @@ static struct dpll_data dpll_mpu_dd = {
.enable_mask= OMAP4430_DPLL_EN_MASK,
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
- .max_multiplier = OMAP4430_MAX_DPLL_MULT,
- .max_divider= OMAP4430_MAX_DPLL_DIV,
+ .max_multiplier = 2047,
+ .max_divider= 128,
.min_divider= 1,
};
@@ -813,8 +813,8 @@ static struct dpll_data dpll_per_dd = {
.enable_mask= OMAP4430_DPLL_EN_MASK,
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
- .max_multiplier = OMAP4430_MAX_DPLL_MULT,
- .max_divider= OMAP4430_MAX_DPLL_DIV,
+ .max_multiplier = 2047,
+ .max_divider= 128,
.min_divider= 1,
};
@@ -949,8 +949,8 @@ static struct dpll_data dpll_unipro_dd = {
.enable_mask= OMAP4430_DPLL_EN_MASK,
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
- .max_multiplier = OMAP4430_MAX_DPLL_MULT,
- .max_divider= OMAP4430_MAX_DPLL_DIV,
+ .max_multiplier = 2047,
+ .max_divider= 128,
.min_divider= 1,
};
@@ -1016,8 +1016,8 @@ static struct dpll_data dpll_usb_dd = {
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
.sddiv_mask = OMAP4430_DPLL_SD_DIV_MASK,
- .max_multiplier = OMAP4430_MAX_DPLL_MULT,
- .max_divider= OMAP4430_MAX_DPLL_DIV,
+ .max_multiplier = 4095,
+ .max_divider= 256,
.min_divider= 1,
};
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 006e599..f57e064 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -152,7 +152,7 @@ struct dpll_data {
u16 max_multiplier;
u8 last_rounded_n;
u8 min_divider;
- u8 max_divider;
+ u16 max_divider;
u8 modes;
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4
[PATCH 08/16] OMAP4: clock data: Rename clock flags from 443X to 44XX
From: Rajendra Nayak rna...@ti.com
Rename current 4430 definitions to 44XX in oder to make this file
applicable for the next revision (OMAP4460).
Create new flags for 44XX. They will be extented when OMAP4460
will be introduced.
Fix as well the clkdev indentation that were previously broken.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock44xx_data.c | 651 -
arch/arm/plat-omap/include/plat/clkdev_omap.h |2 +
arch/arm/plat-omap/include/plat/clock.h |1 +
3 files changed, 328 insertions(+), 326 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 8307c9e..0854160 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Clock data
+ * OMAP44xx Clock data
*
- * Copyright (C) 2009-2010 Texas Instruments, Inc.
+ * Copyright (C) 2009-2011 Texas Instruments, Inc.
* Copyright (C) 2009-2010 Nokia Corporation
*
* Paul Walmsley (p...@pwsan.com)
@@ -127,42 +127,42 @@ static struct clk virt_3840_ck = {
};
static const struct clksel_rate div_1_0_rates[] = {
- { .div = 1, .val = 0, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 0, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_1_rates[] = {
- { .div = 1, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 1, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_2_rates[] = {
- { .div = 1, .val = 2, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 2, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_3_rates[] = {
- { .div = 1, .val = 3, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 3, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_4_rates[] = {
- { .div = 1, .val = 4, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 4, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_5_rates[] = {
- { .div = 1, .val = 5, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 5, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_6_rates[] = {
- { .div = 1, .val = 6, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 6, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_7_rates[] = {
- { .div = 1, .val = 7, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 7, .flags = RATE_IN_44XX },
{ .div = 0 },
};
@@ -285,37 +285,37 @@ static struct clk dpll_abe_x2_ck = {
};
static const struct clksel_rate div31_1to31_rates[] = {
- { .div = 1, .val = 1, .flags = RATE_IN_4430 },
- { .div = 2, .val = 2, .flags = RATE_IN_4430 },
- { .div = 3, .val = 3, .flags = RATE_IN_4430 },
- { .div = 4, .val = 4, .flags = RATE_IN_4430 },
- { .div = 5, .val = 5, .flags = RATE_IN_4430 },
- { .div = 6, .val = 6, .flags = RATE_IN_4430 },
- { .div = 7, .val = 7, .flags = RATE_IN_4430 },
- { .div = 8, .val = 8, .flags = RATE_IN_4430 },
- { .div = 9, .val = 9, .flags = RATE_IN_4430 },
- { .div = 10, .val = 10, .flags = RATE_IN_4430 },
- { .div = 11, .val = 11, .flags = RATE_IN_4430 },
- { .div = 12, .val = 12, .flags = RATE_IN_4430 },
- { .div = 13, .val = 13, .flags = RATE_IN_4430 },
- { .div = 14, .val = 14, .flags = RATE_IN_4430 },
- { .div = 15, .val = 15, .flags = RATE_IN_4430 },
- { .div = 16, .val = 16, .flags = RATE_IN_4430 },
- { .div = 17, .val = 17, .flags = RATE_IN_4430 },
- { .div = 18, .val = 18, .flags = RATE_IN_4430 },
- { .div = 19, .val = 19, .flags = RATE_IN_4430 },
- { .div = 20, .val = 20, .flags = RATE_IN_4430 },
- { .div = 21, .val = 21, .flags = RATE_IN_4430 },
- { .div = 22, .val = 22, .flags = RATE_IN_4430 },
- { .div = 23, .val = 23, .flags = RATE_IN_4430 },
- { .div = 24, .val = 24, .flags = RATE_IN_4430 },
- { .div = 25, .val = 25, .flags = RATE_IN_4430 },
- { .div = 26, .val = 26, .flags = RATE_IN_4430 },
- { .div = 27, .val = 27, .flags = RATE_IN_4430 },
- { .div = 28, .val = 28, .flags = RATE_IN_4430 },
- { .div = 29, .val = 29, .flags = RATE_IN_4430 },
- { .div = 30, .val = 30, .flags = RATE_IN_4430 },
- { .div = 31, .val = 31, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 1, .flags = RATE_IN_44XX },
+ { .div = 2, .val = 2, .flags = RATE_IN_44XX },
+ { .div = 3, .val = 3, .flags = RATE_IN_44XX },
+ { .div = 4, .val = 4, .flags = RATE_IN_44XX },
+ { .div = 5, .val = 5, .flags = RATE_IN_44XX },
+ { .div = 6, .val = 6, .flags = RATE_IN_44XX },
+ { .div = 7, .val = 7, .flags = RATE_IN_44XX
[PATCH 09/16] OMAP4: clock data: Remove McASP2, McASP3 and MMC6 clocks
From: Jon Hunter jon-hun...@ti.com
McASP2, 3 and MMC6 modules are not present in the OMAP4 family.
Remove the fclk and the clksel related to these nodes.
Rename the references that were potentially re-used in order nodes.
Remove related macros in prcm header files.
Update TI copyright date.
Signed-off-by: Jon Hunter jon-hun...@ti.com
[b-cous...@ti.com: Update the patch according to autogen output]
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 86 ++-
arch/arm/mach-omap2/cm-regbits-44xx.h | 49 ++--
arch/arm/mach-omap2/cm2_44xx.h |6 --
arch/arm/mach-omap2/prm-regbits-44xx.h | 100 ---
arch/arm/mach-omap2/prm44xx.h | 12
5 files changed, 74 insertions(+), 179 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 0854160..ad3e1cf 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1170,19 +1170,6 @@ static struct clk func_96m_fclk = {
.set_rate = omap2_clksel_set_rate,
};
-static const struct clksel hsmmc6_fclk_sel[] = {
- { .parent = func_64m_fclk, .rates = div_1_0_rates },
- { .parent = func_96m_fclk, .rates = div_1_1_rates },
- { .parent = NULL },
-};
-
-static struct clk hsmmc6_fclk = {
- .name = hsmmc6_fclk,
- .parent = func_64m_fclk,
- .ops= clkops_null,
- .recalc = followparent_recalc,
-};
-
static const struct clksel_rate div2_1to8_rates[] = {
{ .div = 1, .val = 0, .flags = RATE_IN_44XX },
{ .div = 8, .val = 1, .flags = RATE_IN_44XX },
@@ -1265,6 +1252,21 @@ static struct clk l4_wkup_clk_mux_ck = {
.recalc = omap2_clksel_recalc,
};
+static struct clk ocp_abe_iclk = {
+ .name = ocp_abe_iclk,
+ .parent = aess_fclk,
+ .ops= clkops_null,
+ .recalc = followparent_recalc,
+};
+
+static struct clk per_abe_24m_fclk = {
+ .name = per_abe_24m_fclk,
+ .parent = dpll_abe_m2_ck,
+ .ops= clkops_null,
+ .fixed_div = 4,
+ .recalc = omap_fixed_divisor_recalc,
+};
+
static const struct clksel per_abe_nc_fclk_div[] = {
{ .parent = dpll_abe_m2_ck, .rates = div2_1to2_rates },
{ .parent = NULL },
@@ -1282,41 +1284,6 @@ static struct clk per_abe_nc_fclk = {
.set_rate = omap2_clksel_set_rate,
};
-static const struct clksel mcasp2_fclk_sel[] = {
- { .parent = func_96m_fclk, .rates = div_1_0_rates },
- { .parent = per_abe_nc_fclk, .rates = div_1_1_rates },
- { .parent = NULL },
-};
-
-static struct clk mcasp2_fclk = {
- .name = mcasp2_fclk,
- .parent = func_96m_fclk,
- .ops= clkops_null,
- .recalc = followparent_recalc,
-};
-
-static struct clk mcasp3_fclk = {
- .name = mcasp3_fclk,
- .parent = func_96m_fclk,
- .ops= clkops_null,
- .recalc = followparent_recalc,
-};
-
-static struct clk ocp_abe_iclk = {
- .name = ocp_abe_iclk,
- .parent = aess_fclk,
- .ops= clkops_null,
- .recalc = followparent_recalc,
-};
-
-static struct clk per_abe_24m_fclk = {
- .name = per_abe_24m_fclk,
- .parent = dpll_abe_m2_ck,
- .ops= clkops_null,
- .fixed_div = 4,
- .recalc = omap_fixed_divisor_recalc,
-};
-
static const struct clksel pmd_stm_clock_mux_sel[] = {
{ .parent = sys_clkin_ck, .rates = div_1_0_rates },
{ .parent = dpll_core_m6x2_ck, .rates = div_1_1_rates },
@@ -1996,10 +1963,16 @@ static struct clk mcbsp3_fck = {
.clkdm_name = abe_clkdm,
};
+static const struct clksel mcbsp4_sync_mux_sel[] = {
+ { .parent = func_96m_fclk, .rates = div_1_0_rates },
+ { .parent = per_abe_nc_fclk, .rates = div_1_1_rates },
+ { .parent = NULL },
+};
+
static struct clk mcbsp4_sync_mux_ck = {
.name = mcbsp4_sync_mux_ck,
.parent = func_96m_fclk,
- .clksel = mcasp2_fclk_sel,
+ .clksel = mcbsp4_sync_mux_sel,
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP4430_CM_L4PER_MCBSP4_CLKCTRL,
.clksel_mask= OMAP4430_CLKSEL_INTERNAL_SOURCE_MASK,
@@ -2078,11 +2051,17 @@ static struct clk mcspi4_fck = {
.recalc = followparent_recalc,
};
+static const struct clksel hsmmc1_fclk_sel[] = {
+ { .parent = func_64m_fclk, .rates = div_1_0_rates },
+ { .parent = func_96m_fclk, .rates = div_1_1_rates },
+ { .parent = NULL },
+};
+
/* Merged hsmmc1_fclk into mmc1 */
static struct clk mmc1_fck = {
.name = mmc1_fck,
.parent = func_64m_fclk
[PATCH 11/16] OMAP4: clock data: Add missing divider selection for auxclks
From: Rajendra Nayak rna...@ti.com
On OMAP4 the auxclk nodes (part of SCRM) support both
divider as well as parent selection.
Supporting this requires splitting the existing nodes
(which support only parent selection) into two nodes,
one for parent and another for divider selection.
The nodes for parent selection are named auxclk*_src_ck
and the ones for divider selection as auxclk*_ck.
Signed-off-by: Rajendra Nayak rna...@ti.com
[b-cous...@ti.com: Rebase on top of clock cleanup
and autogen alignement]
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock44xx_data.c | 176 +-
1 files changed, 152 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index b6791cd..684ae8b 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2772,19 +2772,39 @@ static struct clk trace_clk_div_ck = {
/* SCRM aux clk nodes */
-static const struct clksel auxclk_sel[] = {
+static const struct clksel auxclk_src_sel[] = {
{ .parent = sys_clkin_ck, .rates = div_1_0_rates },
{ .parent = dpll_core_m3x2_ck, .rates = div_1_1_rates },
{ .parent = dpll_per_m3x2_ck, .rates = div_1_2_rates },
{ .parent = NULL },
};
-static struct clk auxclk0_ck = {
- .name = auxclk0_ck,
+static const struct clksel_rate div16_1to16_rates[] = {
+ { .div = 1, .val = 0, .flags = RATE_IN_44XX },
+ { .div = 2, .val = 1, .flags = RATE_IN_44XX },
+ { .div = 3, .val = 2, .flags = RATE_IN_44XX },
+ { .div = 4, .val = 3, .flags = RATE_IN_44XX },
+ { .div = 5, .val = 4, .flags = RATE_IN_44XX },
+ { .div = 6, .val = 5, .flags = RATE_IN_44XX },
+ { .div = 7, .val = 6, .flags = RATE_IN_44XX },
+ { .div = 8, .val = 7, .flags = RATE_IN_44XX },
+ { .div = 9, .val = 8, .flags = RATE_IN_44XX },
+ { .div = 10, .val = 9, .flags = RATE_IN_44XX },
+ { .div = 11, .val = 10, .flags = RATE_IN_44XX },
+ { .div = 12, .val = 11, .flags = RATE_IN_44XX },
+ { .div = 13, .val = 12, .flags = RATE_IN_44XX },
+ { .div = 14, .val = 13, .flags = RATE_IN_44XX },
+ { .div = 15, .val = 14, .flags = RATE_IN_44XX },
+ { .div = 16, .val = 15, .flags = RATE_IN_44XX },
+ { .div = 0 },
+};
+
+static struct clk auxclk0_src_ck = {
+ .name = auxclk0_src_ck,
.parent = sys_clkin_ck,
.init = omap2_init_clksel_parent,
.ops= clkops_omap2_dflt,
- .clksel = auxclk_sel,
+ .clksel = auxclk_src_sel,
.clksel_reg = OMAP4_SCRM_AUXCLK0,
.clksel_mask= OMAP4_SRCSELECT_MASK,
.recalc = omap2_clksel_recalc,
@@ -2792,12 +2812,29 @@ static struct clk auxclk0_ck = {
.enable_bit = OMAP4_ENABLE_SHIFT,
};
-static struct clk auxclk1_ck = {
- .name = auxclk1_ck,
+static const struct clksel auxclk0_sel[] = {
+ { .parent = auxclk0_src_ck, .rates = div16_1to16_rates },
+ { .parent = NULL },
+};
+
+static struct clk auxclk0_ck = {
+ .name = auxclk0_ck,
+ .parent = auxclk0_src_ck,
+ .clksel = auxclk0_sel,
+ .clksel_reg = OMAP4_SCRM_AUXCLK0,
+ .clksel_mask= OMAP4_CLKDIV_MASK,
+ .ops= clkops_null,
+ .recalc = omap2_clksel_recalc,
+ .round_rate = omap2_clksel_round_rate,
+ .set_rate = omap2_clksel_set_rate,
+};
+
+static struct clk auxclk1_src_ck = {
+ .name = auxclk1_src_ck,
.parent = sys_clkin_ck,
.init = omap2_init_clksel_parent,
.ops= clkops_omap2_dflt,
- .clksel = auxclk_sel,
+ .clksel = auxclk_src_sel,
.clksel_reg = OMAP4_SCRM_AUXCLK1,
.clksel_mask= OMAP4_SRCSELECT_MASK,
.recalc = omap2_clksel_recalc,
@@ -2805,12 +2842,29 @@ static struct clk auxclk1_ck = {
.enable_bit = OMAP4_ENABLE_SHIFT,
};
-static struct clk auxclk2_ck = {
- .name = auxclk2_ck,
+static const struct clksel auxclk1_sel[] = {
+ { .parent = auxclk1_src_ck, .rates = div16_1to16_rates },
+ { .parent = NULL },
+};
+
+static struct clk auxclk1_ck = {
+ .name = auxclk1_ck,
+ .parent = auxclk1_src_ck,
+ .clksel = auxclk1_sel,
+ .clksel_reg = OMAP4_SCRM_AUXCLK1,
+ .clksel_mask= OMAP4_CLKDIV_MASK,
+ .ops= clkops_null,
+ .recalc = omap2_clksel_recalc,
+ .round_rate = omap2_clksel_round_rate,
+ .set_rate = omap2_clksel_set_rate,
+};
+
+static struct clk auxclk2_src_ck = {
+ .name = auxclk2_src_ck,
.parent = sys_clkin_ck,
.init = omap2_init_clksel_parent,
.ops
[PATCH 10/16] OMAP4: clock data: Remove UNIPRO clock nodes
From: Jon Hunter jon-hun...@ti.com
UNIPRO was removed from OMAP4 devices from ES2.0 onwards.
Since this IP was anyway non-functional and not supported,
it is best to remove it completely.
Signed-off-by: Jon Hunter jon-hun...@ti.com
[b-cous...@ti.com: Update the changelog]
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock44xx_data.c | 60
arch/arm/mach-omap2/cm-regbits-44xx.h | 29 ++-
arch/arm/mach-omap2/cm2_44xx.h |2 -
arch/arm/mach-omap2/prm-regbits-44xx.h | 12 +-
arch/arm/mach-omap2/prm44xx.h |4 --
5 files changed, 14 insertions(+), 93 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index ad3e1cf..b6791cd 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -935,63 +935,6 @@ static struct clk dpll_per_m7x2_ck = {
.set_rate = omap2_clksel_set_rate,
};
-/* DPLL_UNIPRO */
-static struct dpll_data dpll_unipro_dd = {
- .mult_div1_reg = OMAP4430_CM_CLKSEL_DPLL_UNIPRO,
- .clk_bypass = sys_clkin_ck,
- .clk_ref= sys_clkin_ck,
- .control_reg= OMAP4430_CM_CLKMODE_DPLL_UNIPRO,
- .modes = (1 DPLL_LOW_POWER_BYPASS) | (1 DPLL_LOCKED),
- .autoidle_reg = OMAP4430_CM_AUTOIDLE_DPLL_UNIPRO,
- .idlest_reg = OMAP4430_CM_IDLEST_DPLL_UNIPRO,
- .mult_mask = OMAP4430_DPLL_MULT_MASK,
- .div1_mask = OMAP4430_DPLL_DIV_MASK,
- .enable_mask= OMAP4430_DPLL_EN_MASK,
- .autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
- .idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
- .max_multiplier = 2047,
- .max_divider= 128,
- .min_divider= 1,
-};
-
-
-static struct clk dpll_unipro_ck = {
- .name = dpll_unipro_ck,
- .parent = sys_clkin_ck,
- .dpll_data = dpll_unipro_dd,
- .init = omap2_init_dpll_parent,
- .ops= clkops_omap3_noncore_dpll_ops,
- .recalc = omap3_dpll_recalc,
- .round_rate = omap2_dpll_round_rate,
- .set_rate = omap3_noncore_dpll_set_rate,
-};
-
-static struct clk dpll_unipro_x2_ck = {
- .name = dpll_unipro_x2_ck,
- .parent = dpll_unipro_ck,
- .clksel_reg = OMAP4430_CM_DIV_M2_DPLL_UNIPRO,
- .flags = CLOCK_CLKOUTX2,
- .ops= clkops_omap4_dpllmx_ops,
- .recalc = omap3_clkoutx2_recalc,
-};
-
-static const struct clksel dpll_unipro_m2x2_div[] = {
- { .parent = dpll_unipro_x2_ck, .rates = div31_1to31_rates },
- { .parent = NULL },
-};
-
-static struct clk dpll_unipro_m2x2_ck = {
- .name = dpll_unipro_m2x2_ck,
- .parent = dpll_unipro_x2_ck,
- .clksel = dpll_unipro_m2x2_div,
- .clksel_reg = OMAP4430_CM_DIV_M2_DPLL_UNIPRO,
- .clksel_mask= OMAP4430_DPLL_CLKOUT_DIV_MASK,
- .ops= clkops_omap4_dpllmx_ops,
- .recalc = omap2_clksel_recalc,
- .round_rate = omap2_clksel_round_rate,
- .set_rate = omap2_clksel_set_rate,
-};
-
static struct clk usb_hs_clk_div_ck = {
.name = usb_hs_clk_div_ck,
.parent = dpll_abe_m3x2_ck,
@@ -3057,9 +3000,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, dpll_per_m5x2_ck, dpll_per_m5x2_ck,
CK_44XX),
CLK(NULL, dpll_per_m6x2_ck, dpll_per_m6x2_ck,
CK_44XX),
CLK(NULL, dpll_per_m7x2_ck, dpll_per_m7x2_ck,
CK_44XX),
- CLK(NULL, dpll_unipro_ck, dpll_unipro_ck,
CK_44XX),
- CLK(NULL, dpll_unipro_x2_ck,dpll_unipro_x2_ck,
CK_44XX),
- CLK(NULL, dpll_unipro_m2x2_ck, dpll_unipro_m2x2_ck,
CK_44XX),
CLK(NULL, usb_hs_clk_div_ck,usb_hs_clk_div_ck,
CK_44XX),
CLK(NULL, dpll_usb_ck, dpll_usb_ck,
CK_44XX),
CLK(NULL, dpll_usb_clkdcoldo_ck,dpll_usb_clkdcoldo_ck,
CK_44XX),
diff --git a/arch/arm/mach-omap2/cm-regbits-44xx.h
b/arch/arm/mach-omap2/cm-regbits-44xx.h
index 094758d..733f93e 100644
--- a/arch/arm/mach-omap2/cm-regbits-44xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-44xx.h
@@ -862,10 +862,10 @@
* CM_IVAHD_SL2_CLKCTRL, CM_L3INIT_CCPTX_CLKCTRL, CM_L3INIT_EMAC_CLKCTRL,
* CM_L3INIT_HSI_CLKCTRL, CM_L3INIT_MMC1_CLKCTRL, CM_L3INIT_MMC2_CLKCTRL,
* CM_L3INIT_P1500_CLKCTRL, CM_L3INIT_PCIESS_CLKCTRL, CM_L3INIT_SATA_CLKCTRL,
- * CM_L3INIT_TPPSS_CLKCTRL, CM_L3INIT_UNIPRO1_CLKCTRL,
- * CM_L3INIT_USBPHYOCP2SCP_CLKCTRL, CM_L3INIT_USB_HOST_CLKCTRL,
- * CM_L3INIT_USB_HOST_FS_CLKCTRL, CM_L3INIT_USB_OTG_CLKCTRL,
- * CM_L3INIT_USB_TLL_CLKCTRL, CM_L3INIT_XHPI_CLKCTRL, CM_L3INSTR_L3_3_CLKCTRL,
+ * CM_L3INIT_TPPSS_CLKCTRL
[PATCH 13/16] OMAP4: hwmod data: Fix L3 interconnect data order and alignement
Change the position of the ocp_if structure to match the template.
Remove unneeded comma at the end of address space flag field.
Remove USER_SDMA since this ocp link is only from the l3_main_1
path that is accessible only from the MPU in that case and not
the SDMA.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 27 +--
1 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e1c69ff..58843df 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -264,17 +264,11 @@ static struct omap_hwmod_ocp_if omap44xx_mmc2__l3_main_1
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* L3 target configuration and error log registers */
-static struct omap_hwmod_irq_info omap44xx_l3_targ_irqs[] = {
- { .irq = 9 + OMAP44XX_IRQ_GIC_START },
- { .irq = 10 + OMAP44XX_IRQ_GIC_START },
-};
-
static struct omap_hwmod_addr_space omap44xx_l3_main_1_addrs[] = {
{
.pa_start = 0x4400,
.pa_end = 0x44000fff,
- .flags = ADDR_TYPE_RT,
+ .flags = ADDR_TYPE_RT
},
};
@@ -285,7 +279,7 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__l3_main_1 = {
.clk= l3_div_ck,
.addr = omap44xx_l3_main_1_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_l3_main_1_addrs),
- .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .user = OCP_USER_MPU,
};
/* l3_main_1 slave ports */
@@ -299,13 +293,18 @@ static struct omap_hwmod_ocp_if
*omap44xx_l3_main_1_slaves[] = {
omap44xx_mpu__l3_main_1,
};
+static struct omap_hwmod_irq_info omap44xx_l3_main_1_irqs[] = {
+ { .name = dbg_err, .irq = 9 + OMAP44XX_IRQ_GIC_START },
+ { .name = app_err, .irq = 10 + OMAP44XX_IRQ_GIC_START },
+};
+
static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
.name = l3_main_1,
.class = omap44xx_l3_hwmod_class,
- .mpu_irqs = omap44xx_l3_targ_irqs,
- .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_l3_targ_irqs),
.slaves = omap44xx_l3_main_1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l3_main_1_slaves),
+ .mpu_irqs = omap44xx_l3_main_1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_l3_main_1_irqs),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
@@ -354,7 +353,7 @@ static struct omap_hwmod_addr_space
omap44xx_l3_main_2_addrs[] = {
{
.pa_start = 0x4480,
.pa_end = 0x44801fff,
- .flags = ADDR_TYPE_RT,
+ .flags = ADDR_TYPE_RT
},
};
@@ -365,7 +364,7 @@ static struct omap_hwmod_ocp_if
omap44xx_l3_main_1__l3_main_2 = {
.clk= l3_div_ck,
.addr = omap44xx_l3_main_2_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_l3_main_2_addrs),
- .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .user = OCP_USER_MPU,
};
/* l4_cfg - l3_main_2 */
@@ -409,7 +408,7 @@ static struct omap_hwmod_addr_space
omap44xx_l3_main_3_addrs[] = {
{
.pa_start = 0x4500,
.pa_end = 0x45000fff,
- .flags = ADDR_TYPE_RT,
+ .flags = ADDR_TYPE_RT
},
};
@@ -420,7 +419,7 @@ static struct omap_hwmod_ocp_if
omap44xx_l3_main_1__l3_main_3 = {
.clk= l3_div_ck,
.addr = omap44xx_l3_main_3_addrs,
.addr_cnt = ARRAY_SIZE(omap44xx_l3_main_3_addrs),
- .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .user = OCP_USER_MPU,
};
/* l3_main_2 - l3_main_3 */
--
1.7.0.4
--
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 15/16] OMAP4: hwmod data: Fix typo and alignement
Fix a typo in the mailbox description comment.
Fix .prcm alignement and usb_otg_hs class and hwmod structures.
Add a couple of more potential hwmods in the comment.
Remove hsi, since it is already included in the data.
Remove one blank line.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 49 ++-
1 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 199e689..1ba676b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -632,7 +632,9 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* gpmc
* gpu
* hdq1w
- * hsi
+ * mcasp
+ * mpu_c0
+ * mpu_c1
* ocmc_ram
* ocp2scp_usb_phy
* ocp_wp_noc
@@ -739,7 +741,7 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
.sdma_reqs = omap44xx_aess_sdma_reqs,
.sdma_reqs_cnt = ARRAY_SIZE(omap44xx_aess_sdma_reqs),
.main_clk = aess_fck,
- .prcm = {
+ .prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM1_ABE_AESS_CLKCTRL,
},
@@ -768,7 +770,7 @@ static struct omap_hwmod_opt_clk bandgap_opt_clks[] = {
static struct omap_hwmod omap44xx_bandgap_hwmod = {
.name = bandgap,
.class = omap44xx_bandgap_hwmod_class,
- .prcm = {
+ .prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
},
@@ -827,7 +829,7 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
.class = omap44xx_counter_hwmod_class,
.flags = HWMOD_SWSUP_SIDLE,
.main_clk = sys_32k_ck,
- .prcm = {
+ .prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_WKUP_SYNCTIMER_CLKCTRL,
},
@@ -1003,7 +1005,7 @@ static struct omap_hwmod omap44xx_dmic_hwmod = {
.sdma_reqs = omap44xx_dmic_sdma_reqs,
.sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dmic_sdma_reqs),
.main_clk = dmic_fck,
- .prcm = {
+ .prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM1_ABE_DMIC_CLKCTRL,
},
@@ -2093,7 +2095,7 @@ static struct omap_hwmod omap44xx_hsi_hwmod = {
.mpu_irqs = omap44xx_hsi_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_hsi_irqs),
.main_clk = hsi_fck,
- .prcm = {
+ .prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_L3INIT_HSI_CLKCTRL,
},
@@ -2389,7 +2391,7 @@ static struct omap_hwmod omap44xx_ipu_c0_hwmod = {
.flags = HWMOD_INIT_NO_RESET,
.rst_lines = omap44xx_ipu_c0_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_c0_resets),
- .prcm = {
+ .prcm = {
.omap4 = {
.rstctrl_reg = OMAP4430_RM_DUCATI_RSTCTRL,
},
@@ -2404,7 +2406,7 @@ static struct omap_hwmod omap44xx_ipu_c1_hwmod = {
.flags = HWMOD_INIT_NO_RESET,
.rst_lines = omap44xx_ipu_c1_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_c1_resets),
- .prcm = {
+ .prcm = {
.omap4 = {
.rstctrl_reg = OMAP4430_RM_DUCATI_RSTCTRL,
},
@@ -2420,7 +2422,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
.rst_lines = omap44xx_ipu_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_resets),
.main_clk = ipu_fck,
- .prcm = {
+ .prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_DUCATI_DUCATI_CLKCTRL,
.rstctrl_reg = OMAP4430_RM_DUCATI_RSTCTRL,
@@ -2506,7 +2508,7 @@ static struct omap_hwmod omap44xx_iss_hwmod = {
.sdma_reqs = omap44xx_iss_sdma_reqs,
.sdma_reqs_cnt = ARRAY_SIZE(omap44xx_iss_sdma_reqs),
.main_clk = iss_fck,
- .prcm = {
+ .prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_CAM_ISS_CLKCTRL,
},
@@ -2686,7 +2688,7 @@ static struct omap_hwmod omap44xx_kbd_hwmod = {
.mpu_irqs = omap44xx_kbd_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_kbd_irqs),
.main_clk = kbd_fck,
- .prcm = {
+ .prcm = {
.omap4 = {
.clkctrl_reg = OMAP4430_CM_WKUP_KEYBOARD_CLKCTRL,
},
@@ -2698,8 +2700,8 @@ static struct omap_hwmod omap44xx_kbd_hwmod = {
/*
* 'mailbox' class
- * mailbox module allowing communication between the on-chip processors using a
- * queued mailbox-interrupt mechanism.
+ * mailbox module allowing
[PATCH 14/16] OMAP4: hwmod data: Remove un-needed parens
A couple of parens were added around some flags.
Remove them, since they are not needed and not used
for any other hwmods.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 58843df..199e689 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3733,7 +3733,7 @@ static struct omap_hwmod_ocp_if *omap44xx_mpu_masters[] =
{
static struct omap_hwmod omap44xx_mpu_hwmod = {
.name = mpu,
.class = omap44xx_mpu_hwmod_class,
- .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_mpu_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_mpu_irqs),
.main_clk = dpll_mpu_m2_ck,
@@ -4744,7 +4744,7 @@ static struct omap_hwmod_ocp_if *omap44xx_uart3_slaves[]
= {
static struct omap_hwmod omap44xx_uart3_hwmod = {
.name = uart3,
.class = omap44xx_uart_hwmod_class,
- .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_uart3_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_uart3_irqs),
.sdma_reqs = omap44xx_uart3_sdma_reqs,
--
1.7.0.4
--
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 16/16] OMAP4: hwmod data: Replace CHIP_IS_OMAP4430 by OMAP44XX
In order to make hwmod data usable for all OMAP4430 variants,
rename chip macro CHIP_IS_OMAP44XX.
Create the macro as well in cpu.h
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 164 ++--
arch/arm/plat-omap/include/plat/cpu.h |2 +
2 files changed, 84 insertions(+), 82 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1ba676b..2def5f6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -124,7 +124,7 @@ static struct omap_hwmod omap44xx_dmm_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_dmm_slaves),
.mpu_irqs = omap44xx_dmm_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dmm_irqs),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/*
@@ -173,7 +173,7 @@ static struct omap_hwmod omap44xx_emif_fw_hwmod = {
.class = omap44xx_emif_fw_hwmod_class,
.slaves = omap44xx_emif_fw_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_emif_fw_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/*
@@ -212,7 +212,7 @@ static struct omap_hwmod omap44xx_l3_instr_hwmod = {
.class = omap44xx_l3_hwmod_class,
.slaves = omap44xx_l3_instr_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l3_instr_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l3_main_1 interface data */
@@ -305,7 +305,7 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_l3_main_1_slaves),
.mpu_irqs = omap44xx_l3_main_1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_l3_main_1_irqs),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l3_main_2 interface data */
@@ -400,7 +400,7 @@ static struct omap_hwmod omap44xx_l3_main_2_hwmod = {
.class = omap44xx_l3_hwmod_class,
.slaves = omap44xx_l3_main_2_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l3_main_2_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l3_main_3 interface data */
@@ -450,7 +450,7 @@ static struct omap_hwmod omap44xx_l3_main_3_hwmod = {
.class = omap44xx_l3_hwmod_class,
.slaves = omap44xx_l3_main_3_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l3_main_3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/*
@@ -507,7 +507,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.class = omap44xx_l4_hwmod_class,
.slaves = omap44xx_l4_abe_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l4_abe_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l4_cfg interface data */
@@ -529,7 +529,7 @@ static struct omap_hwmod omap44xx_l4_cfg_hwmod = {
.class = omap44xx_l4_hwmod_class,
.slaves = omap44xx_l4_cfg_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l4_cfg_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l4_per interface data */
@@ -551,7 +551,7 @@ static struct omap_hwmod omap44xx_l4_per_hwmod = {
.class = omap44xx_l4_hwmod_class,
.slaves = omap44xx_l4_per_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l4_per_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l4_wkup interface data */
@@ -573,7 +573,7 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
.class = omap44xx_l4_hwmod_class,
.slaves = omap44xx_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l4_wkup_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/*
@@ -603,7 +603,7 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
.class = omap44xx_mpu_bus_hwmod_class,
.slaves = omap44xx_mpu_private_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mpu_private_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/*
@@ -750,7 +750,7 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_aess_slaves
[PATCH 12/16] OMAP4: prcm: Remove references to non-existant peripherals
Based on a patch from Jon Hunter jon-hun...@ti.com, but extented to remove remaining references. The peripherals CCPTX, EMAC, MMC6, P1500, PCIESS, SATA, TPPSS, XHPI, MGATE, MSPROHG, EMIF_H1, EMIF_H2, HECC1, HECC2, ADC, MDMINTC, DEISS and RTC do not exist for the OMAP4 devices. Remove all references to these modules. Update TI copyright. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Jon Hunter jon-hun...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/cm-regbits-44xx.h | 115 ++-- arch/arm/mach-omap2/cm2_44xx.h | 32 - arch/arm/mach-omap2/prm-regbits-44xx.h | 108 + arch/arm/mach-omap2/prm44xx.h | 48 - 4 files changed, 84 insertions(+), 219 deletions(-) diff --git a/arch/arm/mach-omap2/cm-regbits-44xx.h b/arch/arm/mach-omap2/cm-regbits-44xx.h index 733f93e..5e96e7b 100644 --- a/arch/arm/mach-omap2/cm-regbits-44xx.h +++ b/arch/arm/mach-omap2/cm-regbits-44xx.h @@ -852,46 +852,40 @@ * CM1_ABE_MCASP_CLKCTRL, CM1_ABE_MCBSP1_CLKCTRL, CM1_ABE_MCBSP2_CLKCTRL, * CM1_ABE_MCBSP3_CLKCTRL, CM1_ABE_PDM_CLKCTRL, CM1_ABE_SLIMBUS_CLKCTRL, * CM1_ABE_TIMER5_CLKCTRL, CM1_ABE_TIMER6_CLKCTRL, CM1_ABE_TIMER7_CLKCTRL, - * CM1_ABE_TIMER8_CLKCTRL, CM1_ABE_WDT3_CLKCTRL, CM_ALWON_MDMINTC_CLKCTRL, - * CM_ALWON_SR_CORE_CLKCTRL, CM_ALWON_SR_IVA_CLKCTRL, CM_ALWON_SR_MPU_CLKCTRL, - * CM_CAM_FDIF_CLKCTRL, CM_CAM_ISS_CLKCTRL, CM_CEFUSE_CEFUSE_CLKCTRL, - * CM_CM1_PROFILING_CLKCTRL, CM_CM2_PROFILING_CLKCTRL, - * CM_D2D_MODEM_ICR_CLKCTRL, CM_D2D_SAD2D_CLKCTRL, CM_D2D_SAD2D_FW_CLKCTRL, - * CM_DSS_DEISS_CLKCTRL, CM_DSS_DSS_CLKCTRL, CM_DUCATI_DUCATI_CLKCTRL, + * CM1_ABE_TIMER8_CLKCTRL, CM1_ABE_WDT3_CLKCTRL, CM_ALWON_SR_CORE_CLKCTRL, + * CM_ALWON_SR_IVA_CLKCTRL, CM_ALWON_SR_MPU_CLKCTRL, CM_CAM_FDIF_CLKCTRL, + * CM_CAM_ISS_CLKCTRL, CM_CEFUSE_CEFUSE_CLKCTRL, CM_CM1_PROFILING_CLKCTRL, + * CM_CM2_PROFILING_CLKCTRL, CM_D2D_MODEM_ICR_CLKCTRL, CM_D2D_SAD2D_CLKCTRL, + * CM_D2D_SAD2D_FW_CLKCTRL, CM_DSS_DSS_CLKCTRL, CM_DUCATI_DUCATI_CLKCTRL, * CM_EMU_DEBUGSS_CLKCTRL, CM_GFX_GFX_CLKCTRL, CM_IVAHD_IVAHD_CLKCTRL, - * CM_IVAHD_SL2_CLKCTRL, CM_L3INIT_CCPTX_CLKCTRL, CM_L3INIT_EMAC_CLKCTRL, - * CM_L3INIT_HSI_CLKCTRL, CM_L3INIT_MMC1_CLKCTRL, CM_L3INIT_MMC2_CLKCTRL, - * CM_L3INIT_P1500_CLKCTRL, CM_L3INIT_PCIESS_CLKCTRL, CM_L3INIT_SATA_CLKCTRL, - * CM_L3INIT_TPPSS_CLKCTRL, CM_L3INIT_USBPHYOCP2SCP_CLKCTRL, + * CM_IVAHD_SL2_CLKCTRL, CM_L3INIT_HSI_CLKCTRL, CM_L3INIT_MMC1_CLKCTRL, + * CM_L3INIT_MMC2_CLKCTRL, CM_L3INIT_USBPHYOCP2SCP_CLKCTRL, * CM_L3INIT_USB_HOST_CLKCTRL, CM_L3INIT_USB_HOST_FS_CLKCTRL, * CM_L3INIT_USB_OTG_CLKCTRL, CM_L3INIT_USB_TLL_CLKCTRL, - * CM_L3INIT_XHPI_CLKCTRL, CM_L3INSTR_L3_3_CLKCTRL, - * CM_L3INSTR_L3_INSTR_CLKCTRL, CM_L3INSTR_OCP_WP1_CLKCTRL, - * CM_L3_1_L3_1_CLKCTRL, CM_L3_2_GPMC_CLKCTRL, CM_L3_2_L3_2_CLKCTRL, - * CM_L3_2_OCMC_RAM_CLKCTRL, CM_L4CFG_HW_SEM_CLKCTRL, CM_L4CFG_L4_CFG_CLKCTRL, - * CM_L4CFG_MAILBOX_CLKCTRL, CM_L4CFG_SAR_ROM_CLKCTRL, CM_L4PER_ADC_CLKCTRL, + * CM_L3INSTR_L3_3_CLKCTRL, CM_L3INSTR_L3_INSTR_CLKCTRL, + * CM_L3INSTR_OCP_WP1_CLKCTRL, CM_L3_1_L3_1_CLKCTRL, CM_L3_2_GPMC_CLKCTRL, + * CM_L3_2_L3_2_CLKCTRL, CM_L3_2_OCMC_RAM_CLKCTRL, CM_L4CFG_HW_SEM_CLKCTRL, + * CM_L4CFG_L4_CFG_CLKCTRL, CM_L4CFG_MAILBOX_CLKCTRL, CM_L4CFG_SAR_ROM_CLKCTRL, * CM_L4PER_DMTIMER10_CLKCTRL, CM_L4PER_DMTIMER11_CLKCTRL, * CM_L4PER_DMTIMER2_CLKCTRL, CM_L4PER_DMTIMER3_CLKCTRL, * CM_L4PER_DMTIMER4_CLKCTRL, CM_L4PER_DMTIMER9_CLKCTRL, CM_L4PER_ELM_CLKCTRL, * CM_L4PER_GPIO2_CLKCTRL, CM_L4PER_GPIO3_CLKCTRL, CM_L4PER_GPIO4_CLKCTRL, * CM_L4PER_GPIO5_CLKCTRL, CM_L4PER_GPIO6_CLKCTRL, CM_L4PER_HDQ1W_CLKCTRL, - * CM_L4PER_HECC1_CLKCTRL, CM_L4PER_HECC2_CLKCTRL, CM_L4PER_I2C1_CLKCTRL, - * CM_L4PER_I2C2_CLKCTRL, CM_L4PER_I2C3_CLKCTRL, CM_L4PER_I2C4_CLKCTRL, - * CM_L4PER_I2C5_CLKCTRL, CM_L4PER_L4PER_CLKCTRL, CM_L4PER_MCBSP4_CLKCTRL, - * CM_L4PER_MCSPI1_CLKCTRL, CM_L4PER_MCSPI2_CLKCTRL, CM_L4PER_MCSPI3_CLKCTRL, - * CM_L4PER_MCSPI4_CLKCTRL, CM_L4PER_MGATE_CLKCTRL, CM_L4PER_MMCSD3_CLKCTRL, - * CM_L4PER_MMCSD4_CLKCTRL, CM_L4PER_MMCSD5_CLKCTRL, CM_L4PER_MSPROHG_CLKCTRL, - * CM_L4PER_SLIMBUS2_CLKCTRL, CM_L4PER_UART1_CLKCTRL, CM_L4PER_UART2_CLKCTRL, - * CM_L4PER_UART3_CLKCTRL, CM_L4PER_UART4_CLKCTRL, CM_L4SEC_AES1_CLKCTRL, - * CM_L4SEC_AES2_CLKCTRL, CM_L4SEC_CRYPTODMA_CLKCTRL, CM_L4SEC_DES3DES_CLKCTRL, + * CM_L4PER_I2C1_CLKCTRL, CM_L4PER_I2C2_CLKCTRL, CM_L4PER_I2C3_CLKCTRL, + * CM_L4PER_I2C4_CLKCTRL, CM_L4PER_I2C5_CLKCTRL, CM_L4PER_L4PER_CLKCTRL, + * CM_L4PER_MCBSP4_CLKCTRL, CM_L4PER_MCSPI1_CLKCTRL, CM_L4PER_MCSPI2_CLKCTRL, + * CM_L4PER_MCSPI3_CLKCTRL, CM_L4PER_MCSPI4_CLKCTRL, CM_L4PER_MMCSD3_CLKCTRL, + * CM_L4PER_MMCSD4_CLKCTRL, CM_L4PER_MMCSD5_CLKCTRL, CM_L4PER_SLIMBUS2_CLKCTRL, + * CM_L4PER_UART1_CLKCTRL, CM_L4PER_UART2_CLKCTRL, CM_L4PER_UART3_CLKCTRL, + * CM_L4PER_UART4_CLKCTRL, CM_L4SEC_AES1_CLKCTRL, CM_L4SEC_AES2_CLKCTRL, + * CM_L4SEC_CRYPTODMA_CLKCTRL, CM_L4SEC_DES3DES_CLKCTRL, * CM_L4SEC_PKAEIP29_CLKCTRL
[PATCH 05/16] OMAP4: clock data: Remove usb_host_fs clkdev with NULL dev
usb_host_fs_fck does have a clkdev mapping with usbhs-omap.0
and fs_fck alias used by the driver.
The entry with NULL dev is thus not needed anymore.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 227befb..52f3e39 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3204,7 +3204,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, uart2_fck,uart2_fck,
CK_443X),
CLK(NULL, uart3_fck,uart3_fck,
CK_443X),
CLK(NULL, uart4_fck,uart4_fck,
CK_443X),
- CLK(NULL, usb_host_fs_fck, usb_host_fs_fck,
CK_443X),
CLK(usbhs-omap.0, fs_fck, usb_host_fs_fck,
CK_443X),
CLK(NULL, utmi_p1_gfclk,utmi_p1_gfclk,
CK_443X),
CLK(NULL, usb_host_hs_utmi_p1_clk,
usb_host_hs_utmi_p1_clk, CK_443X),
@@ -3216,7 +3215,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, usb_host_hs_hsic60m_p2_clk,
usb_host_hs_hsic60m_p2_clk,CK_443X),
CLK(NULL, usb_host_hs_hsic480m_p2_clk,
usb_host_hs_hsic480m_p2_clk, CK_443X),
CLK(NULL, usb_host_hs_func48mclk,
usb_host_hs_func48mclk,CK_443X),
- CLK(NULL, usb_host_hs_fck, usb_host_hs_fck,
CK_443X),
CLK(usbhs-omap.0, hs_fck, usb_host_hs_fck,
CK_443X),
CLK(usbhs-omap.0, usbhost_ick, dummy_ck,
CK_443X),
CLK(NULL, otg_60m_gfclk,otg_60m_gfclk,
CK_443X),
@@ -3226,7 +3224,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, usb_tll_hs_usb_ch2_clk,
usb_tll_hs_usb_ch2_clk,CK_443X),
CLK(NULL, usb_tll_hs_usb_ch0_clk,
usb_tll_hs_usb_ch0_clk,CK_443X),
CLK(NULL, usb_tll_hs_usb_ch1_clk,
usb_tll_hs_usb_ch1_clk,CK_443X),
- CLK(NULL, usb_tll_hs_ick, usb_tll_hs_ick,
CK_443X),
CLK(usbhs-omap.0, usbtll_ick, usb_tll_hs_ick,
CK_443X),
CLK(usbhs-omap.0, usbtll_fck, dummy_ck,
CK_443X),
CLK(NULL, usim_ck, usim_ck,
CK_443X),
--
1.7.0.4
--
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 02/16] OMAP4: prcm_mpu: Fix indent in few macros
Some macros were not well aligned. Re-align them. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/prcm_mpu44xx.h | 69 +-- 1 files changed, 34 insertions(+), 35 deletions(-) diff --git a/arch/arm/mach-omap2/prcm_mpu44xx.h b/arch/arm/mach-omap2/prcm_mpu44xx.h index d22d1b4..8a6e250 100644 --- a/arch/arm/mach-omap2/prcm_mpu44xx.h +++ b/arch/arm/mach-omap2/prcm_mpu44xx.h @@ -31,7 +31,6 @@ OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE + (inst) + (reg)) /* PRCM_MPU instances */ - #define OMAP4430_PRCM_MPU_OCP_SOCKET_PRCM_INST 0x #define OMAP4430_PRCM_MPU_DEVICE_PRM_INST 0x0200 #define OMAP4430_PRCM_MPU_CPU0_INST0x0400 @@ -52,46 +51,46 @@ */ /* PRCM_MPU.OCP_SOCKET_PRCM register offsets */ -#define OMAP4_REVISION_PRCM_OFFSET 0x -#define OMAP4430_REVISION_PRCM OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_OCP_SOCKET_PRCM_INST, 0x) +#define OMAP4_REVISION_PRCM_OFFSET 0x +#define OMAP4430_REVISION_PRCM OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_OCP_SOCKET_PRCM_INST, 0x) /* PRCM_MPU.DEVICE_PRM register offsets */ -#define OMAP4_PRCM_MPU_PRM_RSTST_OFFSET0x -#define OMAP4430_PRCM_MPU_PRM_RSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_DEVICE_PRM_INST, 0x) -#define OMAP4_PRCM_MPU_PRM_PSCON_COUNT_OFFSET 0x0004 -#define OMAP4430_PRCM_MPU_PRM_PSCON_COUNT OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_DEVICE_PRM_INST, 0x0004) +#define OMAP4_PRCM_MPU_PRM_RSTST_OFFSET0x +#define OMAP4430_PRCM_MPU_PRM_RSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_DEVICE_PRM_INST, 0x) +#define OMAP4_PRCM_MPU_PRM_PSCON_COUNT_OFFSET 0x0004 +#define OMAP4430_PRCM_MPU_PRM_PSCON_COUNT OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_DEVICE_PRM_INST, 0x0004) /* PRCM_MPU.CPU0 register offsets */ -#define OMAP4_PM_CPU0_PWRSTCTRL_OFFSET 0x -#define OMAP4430_PM_CPU0_PWRSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x) -#define OMAP4_PM_CPU0_PWRSTST_OFFSET 0x0004 -#define OMAP4430_PM_CPU0_PWRSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0004) -#define OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET 0x0008 -#define OMAP4430_RM_CPU0_CPU0_CONTEXT OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0008) -#define OMAP4_RM_CPU0_CPU0_RSTCTRL_OFFSET 0x000c -#define OMAP4430_RM_CPU0_CPU0_RSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x000c) -#define OMAP4_RM_CPU0_CPU0_RSTST_OFFSET0x0010 -#define OMAP4430_RM_CPU0_CPU0_RSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0010) -#define OMAP4_CM_CPU0_CPU0_CLKCTRL_OFFSET 0x0014 -#define OMAP4430_CM_CPU0_CPU0_CLKCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0014) -#define OMAP4_CM_CPU0_CLKSTCTRL_OFFSET 0x0018 -#define OMAP4430_CM_CPU0_CLKSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0018) +#define OMAP4_PM_CPU0_PWRSTCTRL_OFFSET 0x +#define OMAP4430_PM_CPU0_PWRSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x) +#define OMAP4_PM_CPU0_PWRSTST_OFFSET 0x0004 +#define OMAP4430_PM_CPU0_PWRSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0004) +#define OMAP4_RM_CPU0_CPU0_CONTEXT_OFFSET 0x0008 +#define OMAP4430_RM_CPU0_CPU0_CONTEXT OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0008) +#define OMAP4_RM_CPU0_CPU0_RSTCTRL_OFFSET 0x000c +#define OMAP4430_RM_CPU0_CPU0_RSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x000c) +#define OMAP4_RM_CPU0_CPU0_RSTST_OFFSET0x0010 +#define OMAP4430_RM_CPU0_CPU0_RSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0010) +#define OMAP4_CM_CPU0_CPU0_CLKCTRL_OFFSET 0x0014 +#define OMAP4430_CM_CPU0_CPU0_CLKCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0014) +#define OMAP4_CM_CPU0_CLKSTCTRL_OFFSET 0x0018 +#define OMAP4430_CM_CPU0_CLKSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU0_INST, 0x0018) /* PRCM_MPU.CPU1 register offsets */ -#define OMAP4_PM_CPU1_PWRSTCTRL_OFFSET 0x -#define OMAP4430_PM_CPU1_PWRSTCTRL OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU1_INST, 0x) -#define OMAP4_PM_CPU1_PWRSTST_OFFSET 0x0004 -#define OMAP4430_PM_CPU1_PWRSTST OMAP44XX_PRCM_MPU_REGADDR(OMAP4430_PRCM_MPU_CPU1_INST, 0x0004) -#define OMAP4_RM_CPU1_CPU1_CONTEXT_OFFSET 0x0008 -#define
[PATCH 0/6] OMAP2+: hwmod framework fixes
Hi Paul, Here are the latest bug fixes done on the hwmod framework. There are mainly around wakeup capability added in OMAP4. The series is based on for_3.0.1/2_prcm_files_cleanup and tested on OMAP4430 ES2.1 + SDP. The patches are available here: git://gitorious.org/omap-pm/linux.git for_3.0.1/3_hwmod_fixes Regards, Benoit Benoit Cousson (5): OMAP2+: hwmod: Fix smart-standby + wakeup support OMAP4: hwmod data: Add MSTANDBY_SMART_WKUP flag OMAP2+: hwmod: Do not write the enawakeup bit if SYSC_HAS_ENAWAKEUP is not set OMAP2+: hwmod: Remove _populate_mpu_rt_base warning OMAP2+: hwmod: Fix the HW reset management Miguel Vadillo (1): OMAP2+: hwmod: Enable module in shutdown to access sysconfig arch/arm/mach-omap2/omap_hwmod.c | 88 +++--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |9 ++- arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +- 3 files changed, 58 insertions(+), 41 deletions(-) -- 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 1/6] OMAP2+: hwmod: Fix smart-standby + wakeup support
The commit 86009eb326afde34ffdc5648cd344aa86b8d58d4 was adding
the wakeup support for new OMAP4 IPs. This support is incomplete for
busmaster IPs that need as well to use smart-standby with wakeup.
This new standbymode is suported on HSI and USB_HOST_FS for the moment.
Add the new MSTANDBY_SMART_WKUP flag to mark the IPs that support this
capability.
Enable this new mode when applicable in _enable_wakeup, _disable_wakeup,
_enable_sysc and _idle_sysc.
The omap_hwmod_44xx_data.c will have to be updated to add this new flag.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Djamil Elaidi d-ela...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 34 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +-
2 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 293fa6c..384d3c3 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -391,7 +391,8 @@ static int _enable_wakeup(struct omap_hwmod *oh, u32 *v)
if (!oh-class-sysc ||
!((oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP) ||
- (oh-class-sysc-idlemodes SIDLE_SMART_WKUP)))
+ (oh-class-sysc-idlemodes SIDLE_SMART_WKUP) ||
+ (oh-class-sysc-idlemodes MSTANDBY_SMART_WKUP)))
return -EINVAL;
if (!oh-class-sysc-sysc_fields) {
@@ -405,6 +406,8 @@ static int _enable_wakeup(struct omap_hwmod *oh, u32 *v)
if (oh-class-sysc-idlemodes SIDLE_SMART_WKUP)
_set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
+ if (oh-class-sysc-idlemodes MSTANDBY_SMART_WKUP)
+ _set_master_standbymode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
/* XXX test pwrdm_get_wken for this hwmod's subsystem */
@@ -426,7 +429,8 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
if (!oh-class-sysc ||
!((oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP) ||
- (oh-class-sysc-idlemodes SIDLE_SMART_WKUP)))
+ (oh-class-sysc-idlemodes SIDLE_SMART_WKUP) ||
+ (oh-class-sysc-idlemodes MSTANDBY_SMART_WKUP)))
return -EINVAL;
if (!oh-class-sysc-sysc_fields) {
@@ -440,6 +444,8 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
if (oh-class-sysc-idlemodes SIDLE_SMART_WKUP)
_set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART, v);
+ if (oh-class-sysc-idlemodes MSTANDBY_SMART_WKUP)
+ _set_master_standbymode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
/* XXX test pwrdm_get_wken for this hwmod's subsystem */
@@ -781,8 +787,16 @@ static void _enable_sysc(struct omap_hwmod *oh)
}
if (sf SYSC_HAS_MIDLEMODE) {
- idlemode = (oh-flags HWMOD_SWSUP_MSTANDBY) ?
- HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+ if (oh-flags HWMOD_SWSUP_MSTANDBY) {
+ idlemode = HWMOD_IDLEMODE_NO;
+ } else {
+ if (sf SYSC_HAS_ENAWAKEUP)
+ _enable_wakeup(oh, v);
+ if (oh-class-sysc-idlemodes MSTANDBY_SMART_WKUP)
+ idlemode = HWMOD_IDLEMODE_SMART_WKUP;
+ else
+ idlemode = HWMOD_IDLEMODE_SMART;
+ }
_set_master_standbymode(oh, idlemode, v);
}
@@ -840,8 +854,16 @@ static void _idle_sysc(struct omap_hwmod *oh)
}
if (sf SYSC_HAS_MIDLEMODE) {
- idlemode = (oh-flags HWMOD_SWSUP_MSTANDBY) ?
- HWMOD_IDLEMODE_FORCE : HWMOD_IDLEMODE_SMART;
+ if (oh-flags HWMOD_SWSUP_MSTANDBY) {
+ idlemode = HWMOD_IDLEMODE_FORCE;
+ } else {
+ if (sf SYSC_HAS_ENAWAKEUP)
+ _enable_wakeup(oh, v);
+ if (oh-class-sysc-idlemodes MSTANDBY_SMART_WKUP)
+ idlemode = HWMOD_IDLEMODE_SMART_WKUP;
+ else
+ idlemode = HWMOD_IDLEMODE_SMART;
+ }
_set_master_standbymode(oh, idlemode, v);
}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1adea9c..e93438c 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -77,7 +77,6 @@ extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type2;
#define HWMOD_IDLEMODE_FORCE (1 0)
#define HWMOD_IDLEMODE_NO (1 1)
#define HWMOD_IDLEMODE_SMART (1 2)
-/* Slave idle mode flag only */
#define HWMOD_IDLEMODE_SMART_WKUP (1 3)
/**
@@ -258,6 +257,7 @@ struct omap_hwmod_ocp_if {
#define MSTANDBY_FORCE (HWMOD_IDLEMODE_FORCE
[PATCH 4/6] OMAP2+: hwmod: Do not write the enawakeup bit if SYSC_HAS_ENAWAKEUP is not set
The Type 2 type of IPs will not have any enawakeup bit in their sysconfig.
Writing to that bit will instead trigger a softreset.
Check the flag to write this bit only if the module supports it.
Reported-by: Miguel Vadillo vadi...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cbc2a8a..3800084 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -387,8 +387,6 @@ static int _set_module_autoidle(struct omap_hwmod *oh, u8
autoidle,
*/
static int _enable_wakeup(struct omap_hwmod *oh, u32 *v)
{
- u32 wakeup_mask;
-
if (!oh-class-sysc ||
!((oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP) ||
(oh-class-sysc-idlemodes SIDLE_SMART_WKUP) ||
@@ -400,9 +398,8 @@ static int _enable_wakeup(struct omap_hwmod *oh, u32 *v)
return -EINVAL;
}
- wakeup_mask = (0x1 oh-class-sysc-sysc_fields-enwkup_shift);
-
- *v |= wakeup_mask;
+ if (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)
+ *v |= 0x1 oh-class-sysc-sysc_fields-enwkup_shift;
if (oh-class-sysc-idlemodes SIDLE_SMART_WKUP)
_set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART_WKUP, v);
@@ -425,8 +422,6 @@ static int _enable_wakeup(struct omap_hwmod *oh, u32 *v)
*/
static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
{
- u32 wakeup_mask;
-
if (!oh-class-sysc ||
!((oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP) ||
(oh-class-sysc-idlemodes SIDLE_SMART_WKUP) ||
@@ -438,9 +433,8 @@ static int _disable_wakeup(struct omap_hwmod *oh, u32 *v)
return -EINVAL;
}
- wakeup_mask = (0x1 oh-class-sysc-sysc_fields-enwkup_shift);
-
- *v = ~wakeup_mask;
+ if (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)
+ *v = ~(0x1 oh-class-sysc-sysc_fields-enwkup_shift);
if (oh-class-sysc-idlemodes SIDLE_SMART_WKUP)
_set_slave_idlemode(oh, HWMOD_IDLEMODE_SMART, v);
--
1.7.0.4
--
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 5/6] OMAP2+: hwmod: Remove _populate_mpu_rt_base warning
It is perfectly valid for some hwmod to not have any register target address for sysconfig. This is especially true for interconnect hwmods. Remove the warning. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap_hwmod.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 3800084..f401417 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -1704,9 +1704,6 @@ static int __init _populate_mpu_rt_base(struct omap_hwmod *oh, void *data) return 0; oh-_mpu_rt_va = _find_mpu_rt_base(oh, oh-_mpu_port_index); - if (!oh-_mpu_rt_va) - pr_warning(omap_hwmod: %s found no _mpu_rt_va for %s\n, - __func__, oh-name); return 0; } -- 1.7.0.4 -- 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
