[PATCH V2] OMAP2+: SR Layer Cleanup.
As a part of Voltage Layer Cleanup Patches,
submitted by Kevin Hilman, Voltage domain
Information is removed from hwmod,
So the patch removes 'vdd_name' info from omap_hwmod
and adds that info into dev_attr as SR code uses vdd_name
to get voltagedomain sructure info.
Tested on OMAP3630 SDP and OMAP4430 SDP Board
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
V2:
Rebased on latest 'pm-wip/voltdm_a' branch.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ---
arch/arm/mach-omap2/smartreflex.h| 10 ++
arch/arm/mach-omap2/sr_device.c | 11 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 -
5 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3cd91ac..6a704bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -29,6 +29,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include prm-regbits-34xx.h
#include cm-regbits-34xx.h
#include wd_timer.h
@@ -2904,6 +2905,10 @@ static struct omap_hwmod_class
omap36xx_smartreflex_hwmod_class = {
};
/* SR1 */
+static struct omap_sr_dev_attr sr1_dev_attr = {
+ .voltdm_name = mpu_iva,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
omap3_l4_core__sr1,
};
@@ -2912,7 +2917,6 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
.name = sr1_hwmod,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2924,6 +2928,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr = sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2934,7 +2939,6 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
.name = sr1_hwmod,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2946,10 +2950,15 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr = sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
/* SR2 */
+static struct omap_sr_dev_attr sr2_dev_attr = {
+ .voltdm_name= core,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
omap3_l4_core__sr2,
};
@@ -2958,7 +2967,6 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
.name = sr2_hwmod,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2970,6 +2978,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr = sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2980,7 +2989,6 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.name = sr2_hwmod,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2992,6 +3000,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr = sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3e88dd3..1331b39 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,6 +30,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include cm1_44xx.h
#include cm2_44xx.h
#include prm44xx.h
@@ -3775,6 +3776,10 @@ static struct omap_hwmod_class
omap44xx_smartreflex_hwmod_class = {
};
/* smartreflex_core */
+static struct omap_sr_dev_attr sr_core_dev_attr = {
+ .voltdm_name = core,
+};
+
static
Re: omap: USB host disconnects connecting a device through USB HUB
On Thu, Apr 07, 2011 at 11:03:38PM +0200, Enric Balletbò i Serra wrote: Hi, 2011/4/7 Alan Stern st...@rowland.harvard.edu: On Thu, 7 Apr 2011, Enric Balletbò i Serra wrote: Hi all, I'm experimenting some issues with USB on IGEP v2 board, in certain cases I've an USB disconnect when I plug a device. For me it fails with kernel 2.6.35 but I think it also affect newer kernel, the issue is easy to reproduce following these steps: 1. Power up the board (without any device connected ) 2. When kernel is up, connect a powered USB HUB 2.0 to the USB host port, kernel shows, usb 1-1: new high speed USB device using ehci-omap and address 2 usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1.4: new high speed USB device using ehci-omap and address 3 usb 1-1.4: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1.4: Product: USB2.0 Hub hub 1-1.4:1.0: USB hub found hub 1-1.4:1.0: 4 ports detected 3. Then if I connect a device (for example a pendrive) to the HUB I get USB disconnect message usb 1-1: USB disconnect, address 2 usb 1-1.4: USB disconnect, address 3 OTOH, it works without problem 1. if power up the board with the USB HUB connected to the USB Host port and the device connected to the USB hub. 2. if after kernel is up, connect the USB HUB + device to the USB Host port Anyone is experimenting something like this with other OMAP3-based boards ? At first glance, it looks like a power-related issue. Current inrush when the device is plugged in, or something like that. What happens if you attach the hub and pendrive to a standard PC? With standard PC works as expected, would be possible a problem with omap-ehci driver ? Maybe Felipe can give some light ? Maybe PM is kicking in and turning off the clocks. Donno. What if you use function tracer so we know the last called function before the problem ? Just filter the call to *hci*. -- balbi -- 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: 2.6.38 not booting on sbc8100 (aka devkit8000)
Am 25.03.2011 08:53, schrieb Belisko Marek: On Fri, Mar 25, 2011 at 8:13 AM, Jarkko Nikula jhnik...@gmail.com wrote: On Thu, 24 Mar 2011 12:00:30 -0700 Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [110324 08:18]: On Thu, Mar 24, 2011 at 4:18 PM, Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [110324 02:50]: Hi, Try to run 2.6.38 on my sbc8100 (use mach-type for devkit8000 because boards are similar) board but when u-boot load it to ram I see just: ... Can you enable DEBUG_LL and EARLY_PRINTK in your .config and add earlyprintk to your cmdline? Then you should see what goes wrong. Forgot to mention. I already test this options but result is same like I report in first email. Maybe add some printk statements to start_kernel function in init/main.c and see if you get any output? For earlyprintk worth to check also arch/arm/plat-omap/include/plat/uncompress.h that there is entry for sbc8100 (double check with devkit8000 as there is entry for it and if you are re-using the mach-type). Thanks for hint. It was missing there so I add line: DEBUG_LL_OMAP3(3, devkit8000); (I'm convince linux to use mach-type for devkit8000) But still same result. Bytes transferred = 2898680 (2c3af8 hex) ## Booting kernel from Legacy Image at 8030 ... Image Name: Linux-2.6.37-1-g88870c9-dirt Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2898616 Bytes = 2.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Anybody with devkit8000 have success to run 2.6.37 kernel on board? -- Jarkko regards, marek Hello Marek, yes, it is running. But your mach-type is wrong. Thats not the mach-type from devkit8000, it is spark. What version of u-boot are you running? Thomas -- 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: 2.6.38 not booting on sbc8100 (aka devkit8000)
On Fri, Apr 8, 2011 at 9:00 AM, Thomas Weber thomas.weber.li...@googlemail.com wrote: Am 25.03.2011 08:53, schrieb Belisko Marek: On Fri, Mar 25, 2011 at 8:13 AM, Jarkko Nikula jhnik...@gmail.com wrote: On Thu, 24 Mar 2011 12:00:30 -0700 Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [110324 08:18]: On Thu, Mar 24, 2011 at 4:18 PM, Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [110324 02:50]: Hi, Try to run 2.6.38 on my sbc8100 (use mach-type for devkit8000 because boards are similar) board but when u-boot load it to ram I see just: ... Can you enable DEBUG_LL and EARLY_PRINTK in your .config and add earlyprintk to your cmdline? Then you should see what goes wrong. Forgot to mention. I already test this options but result is same like I report in first email. Maybe add some printk statements to start_kernel function in init/main.c and see if you get any output? For earlyprintk worth to check also arch/arm/plat-omap/include/plat/uncompress.h that there is entry for sbc8100 (double check with devkit8000 as there is entry for it and if you are re-using the mach-type). Thanks for hint. It was missing there so I add line: DEBUG_LL_OMAP3(3, devkit8000); (I'm convince linux to use mach-type for devkit8000) But still same result. Bytes transferred = 2898680 (2c3af8 hex) ## Booting kernel from Legacy Image at 8030 ... Image Name: Linux-2.6.37-1-g88870c9-dirt Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2898616 Bytes = 2.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Anybody with devkit8000 have success to run 2.6.37 kernel on board? -- Jarkko regards, marek Hello Marek, yes, it is running. But your mach-type is wrong. Thats not the mach-type from devkit8000, it is spark. What version of u-boot are you running? Well my u-boot return different mach-type but I always override it when kernel start (in arch/arm/kernel/head.S ldr r1,=0x.. mach-type). But still no luck. Thomas thanks, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite icq: 290551086 web: http://open-nandra.com -- 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: 2.6.38 not booting on sbc8100 (aka devkit8000)
Am 08.04.2011 10:03, schrieb Belisko Marek: On Fri, Apr 8, 2011 at 9:00 AM, Thomas Weber thomas.weber.li...@googlemail.com wrote: Am 25.03.2011 08:53, schrieb Belisko Marek: On Fri, Mar 25, 2011 at 8:13 AM, Jarkko Nikula jhnik...@gmail.com wrote: On Thu, 24 Mar 2011 12:00:30 -0700 Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [110324 08:18]: On Thu, Mar 24, 2011 at 4:18 PM, Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [110324 02:50]: Hi, Try to run 2.6.38 on my sbc8100 (use mach-type for devkit8000 because boards are similar) board but when u-boot load it to ram I see just: ... Can you enable DEBUG_LL and EARLY_PRINTK in your .config and add earlyprintk to your cmdline? Then you should see what goes wrong. Forgot to mention. I already test this options but result is same like I report in first email. Maybe add some printk statements to start_kernel function in init/main.c and see if you get any output? For earlyprintk worth to check also arch/arm/plat-omap/include/plat/uncompress.h that there is entry for sbc8100 (double check with devkit8000 as there is entry for it and if you are re-using the mach-type). Thanks for hint. It was missing there so I add line: DEBUG_LL_OMAP3(3, devkit8000); (I'm convince linux to use mach-type for devkit8000) But still same result. Bytes transferred = 2898680 (2c3af8 hex) ## Booting kernel from Legacy Image at 8030 ... Image Name: Linux-2.6.37-1-g88870c9-dirt Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2898616 Bytes = 2.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Anybody with devkit8000 have success to run 2.6.37 kernel on board? I run actually 2.6.38. / # uname -a Linux 192.168.250.2 2.6.38-09676-ge63e9ed #8 Tue Mar 22 13:07:44 CET 2011 armv7l GNU/Linux -- Jarkko regards, marek Hello Marek, yes, it is running. But your mach-type is wrong. Thats not the mach-type from devkit8000, it is spark. What version of u-boot are you running? Well my u-boot return different mach-type but I always override it when kernel start (in arch/arm/kernel/head.S ldr r1,=0x.. mach-type). But still no luck. What machine-id are you passing in? devkit8000 is 2330 Thomas Thomas thanks, marek -- 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: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
On Fri, 8 Apr 2011, Li Li wrote: Dears, I cannot understand how TLS EMU ensure it's SMP safe, because get_tls helper (at 0x0fe0) just read the value from 0x0ff0. But all SMP cores should have the exact same mapping to the vectors page (at 0x). So various threads running on different SMP cores at the same time would get the same emulated TLS value (instead of thread specific value set via set_tls). Could anybody explain this a little bit? On SMP the hardware TLS register is always available, therefore the TLS value is not stored at 0x0ff0. The code actually installed at 0x0fe0 is modified at boot time by kuser_get_tls_init to select either the ldr or the mrc instruction to retrieve the TLS value. Nicolas -- 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: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
Nicolas, Thanks for the explanation. :) I noticed what you mentioned. Actually, Kconfig says TLS EMU might be used in some old (e.g. pre-armv6) SMP platforms without TLS register. In such a case, could we still ensure it's SMP safe by a single ldr? Thanks, Lea On Fri, Apr 8, 2011 at 9:19 PM, Nicolas Pitre n...@fluxnic.net wrote: On Fri, 8 Apr 2011, Li Li wrote: Dears, I cannot understand how TLS EMU ensure it's SMP safe, because get_tls helper (at 0x0fe0) just read the value from 0x0ff0. But all SMP cores should have the exact same mapping to the vectors page (at 0x). So various threads running on different SMP cores at the same time would get the same emulated TLS value (instead of thread specific value set via set_tls). Could anybody explain this a little bit? On SMP the hardware TLS register is always available, therefore the TLS value is not stored at 0x0ff0. The code actually installed at 0x0fe0 is modified at boot time by kuser_get_tls_init to select either the ldr or the mrc instruction to retrieve the TLS value. Nicolas -- 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
Can i submit BN Nook Color generic kernel support patches?
Hi everyone, I am working on porting BN Nook color source to generic kernel (non Android). Can i submit my ported code to omap-linux git? 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
Re: OMAP4 DSS clock setup
Hi Paul, On 4/7/2011 9:27 PM, Paul Walmsley wrote: Hello Tomi, Benoît, On Mon, 4 Apr 2011, Tomi Valkeinen wrote: On Fri, 2011-04-01 at 20:12 -0600, Paul Walmsley wrote: Based on the E-mail thread so far, I'd say that changing the clock aliases is the way to go for right now. The clock aliases are not hardware data; they just control how the clock hardware is mapped to the drivers. I'd very much prefer this option. Below is a patch for this. If Benoit doesn't complain too much about this, I'd like to get this merged as soon as possible, as OMAP4 DSS is currently crashing in the mainline kernel. I will queue your clock aliases patch and attempt to merge it upstream for the -rc series. I am not happy to be disagreeing with Benoît here, but this is the rationale that I am using. (Benoît, Tomi, please feel free to correct if there is something blatantly false below.) That's quite good that you were disagreeing with me, because I think that you are indeed right:-) 1. The integration of the DSS module is an unusual case. The MODULEMODE bits for the DSS bits do not control the DSS main functional clock (the clock that is needed to access device registers); instead, they only control the DSS interface clock. (This is because the DSS can use a functional clock that is not provided by the OMAP core.) So calling the DSS MODULEMODE struct clk dss_fck is not really correct, since it is really controlling the interface clock. I've just got the confirmation from a PRCM designer that this is indeed what is happening. In the case of the DSS the optional functional clocks are provided by the PRCM and thus managed by the PRCM. The only difference is that since two different functional clocks are available, the PRCM cannot chose automatically the proper one. Hence the term optional fck, meaning that the SW has to explicitly enable them. The PRCM will not do it when modulemode will be enabled. So in that case enabling the modulemode will effectively enable the module for the PRCM point of view and just request the iclk if not already available. The only point that we need to take care of is the sequence. The PRCM spec clearly specify that one of the optional clock must be active before the modulemode is enabled. That does not seems to be the case in the current DSS code. 2. This patch does not create a precedent for hacking around general driver clocking problems in the clock or clock data. This is only needed because the MODULEMODE bits don't control the module functional clock in this case. As I understand it, the only other device that this problem could occur with is McBSP, due to mcbsp_clks. In that case this is slightly different because even the PRCM does not control these external clocks. Whereas in the case of the dss_fck, if the DPLL is not locked when you request it, it will be enabled automatically. Assuming that auto mode are enabled. 3. The existing DSS2 driver clock design apparently works fine when this change is implemented[1], so no driver changes will be needed. Yeah, but my point was that driver changes will be needed anyway, hence my preference to hack the driver instead of hacking the clock data. 4. The proposed DSS driver patch to work around this uses a nasty hack that really should be NACK'ed[2]. All this said, we may not be able to merge this change upstream, due to the recent unhappiness about the clock data changes. If Linus rejects it, you'll need a Plan B. That's was my #2 concern as well. See you soon at ELC. 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: Can i submit BN Nook Color generic kernel support patches?
Hello, Abimanyu Gottumukkala m...@abimanyu.in writes: I am working on porting BN Nook color source to generic kernel (non Android). Can i submit my ported code to omap-linux git? Absolutely! Support for new platforms is always welcome. This platform is based on the OMAP36xx (3621 I think), so you might look at other 36xx-based platforms (like Zoom3) as a starting point for your platform support. It will also be good to be familiar with the differences between a 3621 and a 3630 and use OMAP features so any differences in the parts can be determined at runtime (see omap_has_* in plat/cpu.h for example.) Thanks, Kevin -- 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: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
Ah, I see. That's why I saw abnormal behavior when I enabled TLS EMU on an ARMv7 SMP SOC. Many thanks! :) On Fri, Apr 8, 2011 at 10:35 PM, Jamie Lokier ja...@shareable.org wrote: Li Li wrote: Nicolas, Thanks for the explanation. :) I noticed what you mentioned. Actually, Kconfig says TLS EMU might be used in some old (e.g. pre-armv6) SMP platforms without TLS register. In such a case, could we still ensure it's SMP safe by a single ldr? In that case, the hardware TLS 'mcr' is used, which traps and is emulated by the undefined instruction handler. It's not fast but presumably those platforms don't really matter. See CONFIG_TLS_REG_EMUL in arch/arm/kernel/traps.c, and 'tls_emu'. 'tls_emu' is a constant, so if a kernel built for TLS emulation is run on something which has the TLS register, it will not work properly. -- JAmie -- 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: OMAP4 DSS clock setup
Hi On Fri, 8 Apr 2011, Tomi Valkeinen wrote: On Thu, 2011-04-07 at 13:27 -0600, Paul Walmsley wrote: On Mon, 4 Apr 2011, Tomi Valkeinen wrote: On Fri, 2011-04-01 at 20:12 -0600, Paul Walmsley wrote: Based on the E-mail thread so far, I'd say that changing the clock aliases is the way to go for right now. The clock aliases are not hardware data; they just control how the clock hardware is mapped to the drivers. I'd very much prefer this option. Below is a patch for this. If Benoit doesn't complain too much about this, I'd like to get this merged as soon as possible, as OMAP4 DSS is currently crashing in the mainline kernel. I will queue your clock aliases patch and attempt to merge it upstream for the -rc series. I am not happy to be disagreeing with Benoît here, but this is the rationale that I am using. (Benoît, Tomi, please feel free to correct if there is something blatantly false below.) 1. The integration of the DSS module is an unusual case. The MODULEMODE bits for the DSS bits do not control the DSS main functional clock (the clock that is needed to access device registers); instead, they only control the DSS interface clock. (This is because the DSS can use a functional clock that is not provided by the OMAP core.) So calling the DSS MODULEMODE struct clk dss_fck is not really correct, since it is really controlling the interface clock. If we don't apply the patch, I think the clock aliases are still broken. Let's forget the ick/fck thing for a second, and just think the clock from PRCM which is used as the source clock for pixel clock. That is currently called fck on OMAP2/3, but dss_dss_clk on OMAP4. This cannot be right, can it? From DSS's point of view that is the same clock, it should clearly have the same alias on all platforms. I don't care what the name is as long as it's consistent on all platforms. Yes, I agree. That is another good point. And I have to say I still don't quite get it what is the problem with fck name. After the hwmod/PM runtime conversion, there shouldn't be any clock aliases left that are simply called fck, because it is almost a meaningless name. Or is that meant to be a clock which enables the registers on the module, After the hwmod/PM runtime conversion, that should have an alias name of main that is automatically added by the omap_device code. (Note that it does not appear to do so now; that is a bug that needs be fixed.) and not the clock used for the pixel clock? If so, I'm fine with having fck to be what it is currently, but then we need a new name for the clock used for pixel clock, which is consistent on all platforms. If there is a separate PRCM-provided clock used only for the pixel clock, then that clock should have an alias name of system_pixel_ck or something similar that is meaningful to the DSS driver. I think the problem in this case is that dss_dss_clk is (optionally) used for two purposes: optionally as a main PRCM-provided functional clock and optionally as a system-provided pixel clock. I'll reply to the rest of your mail in a separate E-mail... - Paul
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
Li Li wrote: Nicolas, Thanks for the explanation. :) I noticed what you mentioned. Actually, Kconfig says TLS EMU might be used in some old (e.g. pre-armv6) SMP platforms without TLS register. In such a case, could we still ensure it's SMP safe by a single ldr? In that case, the hardware TLS 'mcr' is used, which traps and is emulated by the undefined instruction handler. It's not fast but presumably those platforms don't really matter. See CONFIG_TLS_REG_EMUL in arch/arm/kernel/traps.c, and 'tls_emu'. 'tls_emu' is a constant, so if a kernel built for TLS emulation is run on something which has the TLS register, it will not work properly. -- JAmie -- 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: OMAP4 DSS clock setup
Hi Tomi, On 4/8/2011 7:51 AM, Valkeinen, Tomi wrote: Hi Paul, On Thu, 2011-04-07 at 13:27 -0600, Paul Walmsley wrote: Hello Tomi, Benoît, On Mon, 4 Apr 2011, Tomi Valkeinen wrote: On Fri, 2011-04-01 at 20:12 -0600, Paul Walmsley wrote: Based on the E-mail thread so far, I'd say that changing the clock aliases is the way to go for right now. The clock aliases are not hardware data; they just control how the clock hardware is mapped to the drivers. I'd very much prefer this option. Below is a patch for this. If Benoit doesn't complain too much about this, I'd like to get this merged as soon as possible, as OMAP4 DSS is currently crashing in the mainline kernel. I will queue your clock aliases patch and attempt to merge it upstream for the -rc series. I am not happy to be disagreeing with Benoît here, but this is the rationale that I am using. (Benoît, Tomi, please feel free to correct if there is something blatantly false below.) 1. The integration of the DSS module is an unusual case. The MODULEMODE bits for the DSS bits do not control the DSS main functional clock (the clock that is needed to access device registers); instead, they only control the DSS interface clock. (This is because the DSS can use a functional clock that is not provided by the OMAP core.) So calling the DSS MODULEMODE struct clk dss_fck is not really correct, since it is really controlling the interface clock. If we don't apply the patch, I think the clock aliases are still broken. Let's forget the ick/fck thing for a second, and just think the clock from PRCM which is used as the source clock for pixel clock. That is currently called fck on OMAP2/3, but dss_dss_clk on OMAP4. This cannot be right, can it? From DSS's point of view that is the same clock, it should clearly have the same alias on all platforms. I don't care what the name is as long as it's consistent on all platforms. And I have to say I still don't quite get it what is the problem with fck name. Or is that meant to be a clock which enables the registers on the module, and not the clock used for the pixel clock? If so, I'm fine with having fck to be what it is currently, but then we need a new name for the clock used for pixel clock, which is consistent on all platforms. Both can be used for the system clock (sys_clk - DSI DPLL or dss_dss_clk). In fact after multiple discussions with DSS and PRCM folks, I realized that OMAP3 and 4 are using exactly the same clock scheme :-( The confusion in my mind came from change in naming convention in both the PRCM and the DSS at the same time between OMAP3 and 4. OMAP3 - OMAP4 dss1_alwon_fck - dss_dss_clk (from dpll per output in both cases) dss2_alwon_fck - dss_sys_clk dss_ick- dss_fck (- modulemode) that name really needs to be changed to avoid further confusion. So in fact the OMAP4 aliased should be: CLK(omapdss_dss, fck, dss_dss_clk, CK_443X), CLK(omapdss_dss, sys_clk, dss_sys_clk, CK_443X), CLK(omapdss_dss, ick, dss_fck, CK_443X), That will map perfectly what we have on OMAP3: CLK(omapdss_dss, fck, dss1_alwon_fck_3430es2, ...), CLK(omapdss_dss, sys_clk, dss2_alwon_fck, ...), CLK(omapdss_dss, ick, dss_ick_3430es2, ...), 2. This patch does not create a precedent for hacking around general driver clocking problems in the clock or clock data. This is only needed because the MODULEMODE bits don't control the module functional clock in this case. As I understand it, the only other device that this problem could occur with is McBSP, due to mcbsp_clks. 3. The existing DSS2 driver clock design apparently works fine when this change is implemented[1], so no driver changes will be needed. 4. The proposed DSS driver patch to work around this uses a nasty hack that really should be NACK'ed[2]. All this said, we may not be able to merge this change upstream, due to the recent unhappiness about the clock data changes. If Linus rejects it, you'll need a Plan B. ... Also, I hope you and the other DSS hackers can finish the PM runtime conversion of the DSS driver soon. Ideally before any new DSS features are added. We really need to be able to separate the OMAP integration details from the drivers, and right now, hwmod and PM runtime are the best way we have to do that. I also started to look at the PM runtime, but it doesn't fix the issue with the inconsistent clock name I described above. No indeed. I also have some questions regarding PM runtime, perhaps I'll just put them here as they are slightly related: - Should every DSS module handle their clocks independently, i.e. should VENC get its own clocks and DSI should get its own? If so, we need a bunch of new clock aliases so the devices can get their clocks. For dedicated clock like tv_clk, it probably makes sense, because
Re: OMAP4 DSS clock setup
Hi Tomi,
On Fri, 8 Apr 2011, Tomi Valkeinen wrote:
Also, I hope you and the other DSS hackers can finish the PM runtime
conversion of the DSS driver soon. Ideally before any new DSS
features are added. We really need to be able to separate the OMAP
integration details from the drivers, and right now, hwmod and PM
runtime are the best way we have to do that.
I also started to look at the PM runtime, but it doesn't fix the issue
with the inconsistent clock name I described above.
After the hwmod/PM runtime conversion, I don't think any of the clock
aliases currently in clock*_data.c should be used by the DSS driver (or by
anything else on the system, for that matter). That's because the
omap_device code should set up the main alias for the DSS main
functional clock[*], as well as the aliases in the optional clock data in
the OMAP hwmod data files:
static struct omap_hwmod_opt_clk dss_opt_clks[] = {
{ .role = sys_clk, .clk = dss_sys_clk },
{ .role = tv_clk, .clk = dss_tv_clk },
{ .role = dss_clk, .clk = dss_dss_clk },
{ .role = video_clk, .clk = dss_48mhz_clk },
};
It might be that some of these role names aren't quite accurate and need
to be changed. Those are intended to be meaningful to the driver, so
comments there are definitely welcome.
[*]. The main alias should be defined by the omap_device code
automatically, similarly to how _add_optional_clock_clkdev() does it. It
does not do so currently. This needs to be fixed in the omap_device.c
code.
I also have some questions regarding PM runtime, perhaps I'll just put
them here as they are slightly related:
- Should every DSS module handle their clocks independently, i.e. should
VENC get its own clocks and DSI should get its own? If so, we need a
bunch of new clock aliases so the devices can get their clocks.
If all that driver code needs to do is to enable its main functional clock
when it is active and disable that clock when the driver is inactive,
then, no, the drivers shouldn't need their own clock aliases. Same if the
driver only needs to get the rate or set the rate on that main functional
clock, since that alias should be set up automatically.
But if the driver for that submodule needs to control PRCM-provided
optional clocks, then it will need to have struct omap_hwmod_opt_clk
entries defined in the hwmod data.
- Should every DSS module have their own PM runtime handling? (actually
related to the question above)
Yes, I think so. From the integration perspective, we are trying to get
to the point where each omap_device maps to only one hwmod.
- If the modules are handled separately, how should the dependencies be
handled? For example, dss_core's reset will reset all the other modules
also, and most of the submodules need functions from dss_core and
dss_dispc. So should, say, dss_dsi then call functions in core and dispc
to get them, i.e. increase their pm runtime use count?
Probably not.
Here is how I would suggest structuring the code. This is only a naïve
suggestion; you and your team almost certainly know better than I.
I'd suggest that you separate low-level register access into .c files
that are targeted specifically for the IP block. So in the DSS case,
you'd have dss.c, dispc.c, dsi.c, hdmi.c, rfbi.c, venc.c. Each one should
be a separate platform_device and would export symbols. Hopefully, there
should be no cross-dependencies between these low-level files.
Then you'd have higher-level code that might need to read/write from
multiple DSS submodules to complete some higher-level operation. That
would be at least one separate driver -- say, dss2 or something -- with
dependencies on the low-level drivers. So, for example, when that
higher-level driver is modprobe'd, Linux would also load the drivers for
the underlying hardware blocks that it uses.
- There seems to be some child/parent relationships in PM runtime.
Should dss_core be the parent for the rest of the DSS modules? This
would at least solve the reset issue easily, I guess.
Yes, I think that's more accurate, anyway. Something isn't right with the
DSS hwmod data. According to the OMAP4 Public TRM Rev O Table 10-3 DSS
Integration, there's a Sonics LX bus lurking in there. All of the DSS
submodules should have slave sockets with that Sonics LX bus as their
master. And the hwmod associated with the SLX should have an address
range that covers all of the DSS submodules. I assume that the logical
hwmod to associate the SLX with is dss_core, as you write.
Also, I notice the CAUTION boxes in Section 10.1.3 DSS Register
Manual, 10.2.7 Display Controller Register Manual, etc. etc., that say
that the DSS and submodules should be accessed through the L3 address
space. But all of the DSS hwmod register targets are listed as the L4_PER
variants. So the hwmod data also doesn't appear to be correct there. The
correct approach would be to have both address
Re: OMAP4 DSS clock setup
On Fri, 2011-04-08 at 17:36 +0200, Cousson, Benoit wrote: Hi Tomi, On 4/8/2011 7:51 AM, Valkeinen, Tomi wrote: - If the modules are handled separately, how should the dependencies be handled? For example, dss_core's reset will reset all the other modules also, and most of the submodules need functions from dss_core and dss_dispc. So should, say, dss_dsi then call functions in core and dispc to get them, i.e. increase their pm runtime use count? Are you sure about that? The dss_core does not have any reset in the sysonfig (only a status), but the dispc does have one and the dsi as well. Ah, I might be speaking only of OMAP2/3. I remember somebody saying that the DSS reset bit on OMAP4 is marked as reserved. But for OMAP3 (and I think for OMAP2 also) the DSS_SYSCONFIG reset bit will reset also the rest of the DSS. Tomi -- 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: OMAP4 DSS clock setup
Hi Tomi,
On Mon, 4 Apr 2011, Tomi Valkeinen wrote:
On Fri, 2011-04-01 at 20:12 -0600, Paul Walmsley wrote:
Of course, at some point soon, those clock aliases are going to go away.
But hopefully you all will have converted the driver over to PM runtime at
that point.
Once that happens, there's another problem: omap_hwmod_enable() is defined
that the hardware registers should be accessible by the MPU after it
completes. So by that definition, the hwmod code should be
enabling/disabling that dss_clk clock too when it enables/idles/shuts down
the hwmod. Probably we'd need to mark that struct omap_hwmod_opt_clk with
some flag. Then we'd need some kind of way for the DSS to tell the hwmod
code whether it is or isn't reliant on the PRCM-provided functional clock
for its internal functional clock. Maybe something like
omap_hwmod_{release,require}_system_fclk()?
Hmm, right. I guess no other HW module has clock setups like this?
I think McBSP can have an optional main functional clock. So something
like that should be usable for that case too. (In the McBSP case, the
optional clock isn't controlled by the PRCM, it's controlled by the SCM,
but that doesn't really matter to the hwmod code.)
Currently DSS can use clk_enable/disable() for the system fclk when its
using DSI PLL for the fclk. So omap_hwmod_{release,require}_system_fclk
sounds like a simple solution to this.
OK. The only problem with those functions (actually
omap_device_{release,require}_system_fclk()) is that they will need to be
called through platform_data function pointers for now. Maybe it is
possible to handle something like this simply with the clock framework
also.
Not directly related, but something I've been wondering about is how to
abstract the DSI/HDMI PLLs in DSS. What do you think, would it be
possible/worth it to create struct clks for the clocks coming out of
those PLLs? These would, of course, be DSS internal clks. I'm not very
familiar with the clock framework, so I don't really have any idea what
this would require and what would be the pros and cons.
Yes, I think it would be good to try to implement the entire DSS clock
tree in the clock framework. One change to the clock code that we know
we'll need is to put a hwmod pointer in the struct clk which tells the
clock code that the hwmod needs to be enabled in order to access the
clock's registers. Right now, the clock code assumes that all of the
clock registers are accessible, all of the time.
- 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
Kernel panic on run_init_process(execute command)
Hello, I am working with a custom OMAP3530 board. I am using rowboat 2.6.32, codesourcery 2010q1, X-loader and U-boot, all uniquely customized for this board. I am using the 3 partition microSD card for this board, modeled after the TI-DevKit version 2.2, with rootfs as a partition at /dev/mmcblk0p2. On kernel boot, after mounting the root filesystem (/dev/mmcblk0p2) when attempting to start init (bootargs are init=/init), in main.c, run_init_process(execute_command) with execute_command set to /init, I get a kernel panic: [ 103.806274] Kernel panic - not syncing: Attempted to kill init! The backtrace identifies: [ 103.812377] [c0048320] (unwind_backtrace+0x0/0x17c) from [c0489d34] (dump_stack+0x20/0x24) [ 103.821105] [c0489d34] (dump_stack+0x20/0x24) from [c0489d94] (panic+0x5c/0x130) [ 103.828918] [c0489d94] (panic+0x5c/0x130) from [c007cc18] (do_exit+0x5d4/0x6a4) [ 103.836669] [c007cc18] (do_exit+0x5d4/0x6a4) from [c007cd34] (do_group_exit+0x4c/0xbc) [ 103.845062] [c007cd34] (do_group_exit+0x4c/0xbc) from [c008dee8] (get_signal_to_deliver+0x208/0x3e8) [ 103.854644] [c008dee8] (get_signal_to_deliver+0x208/0x3e8) from [c0042de0] (do_signal+0x74/0x698) [ 103.863983] [c0042de0] (do_signal+0x74/0x698) from [c0043470] (do_notify_resume+0x6c/0x78) [ 103.872680] [c0043470] (do_notify_resume+0x6c/0x78) from [c003fb4c] (work_pending+0x1c/0x20) I am not sure what is exactly causing this error. I am using RealView ICE and RVD, with source code debugging. Can anybody assist? 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
Re: Kernel panic on run_init_process(execute command)
Hi,
On Apr 8, 2011, at 11:22 PM, Boswell, Patrick wrote:
I am working with a custom OMAP3530 board. I am using rowboat 2.6.32,
codesourcery 2010q1, X-loader and U-boot, all uniquely customized for
this board.
I am using the 3 partition microSD card for this board, modeled after
the TI-DevKit version 2.2, with rootfs as a partition at /dev/mmcblk0p2.
Try to use just 2 partitions first, a 40MB FAT32 partition, and a 512MB
ext3 partition.
On the FAT boot partition, you should first copy MLO, u-boot.bin and uImage.
While creating the bootable rootfs partition (disk-1), you can merge the
outputs of the
android root and system folders as follows:
# su
# cd /media/disk-1
# rm -Rf *
# cp -a /tool/android-rowboat-2.2/out/target/product/beagleboard/root/* .
# cp -a /tool/android-rowboat-2.2/out/target/product/beagleboard/system/*
system/
# chown -R root.root *
# chmod -R 777 data system
You should also check your init.rc file, to ensure that you comment out the
sections relating to mounting the nand partitions.
##mount rootfs rootfs / ro remount
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a
checkpoint
##mount yaffs2 mtd@system /system
##mount yaffs2 mtd@system /system ro remount
# We chown/chmod /data again so because mount is run as root + defaults
##mount yaffs2 mtd@userdata /data nosuid nodev
chown system system /data
chmod 0771 /data
Also check your bootargs. The ones that I use are as follows:
# printenv
# setenv defaultdisplay lcd43
# setenv dvimode 480x272MR-16@60
# setenv vram 12M
# setenv mmcargs setenv bootargs console=${console} vram=${vram}
omapfb.vram=0:4M omapfb.mode=dvi:${dvimode} omapfb.debug=y
omapdss.def_disp=${defaultdisplay} root=/dev/mmcblk0p2 rw rootfstype=ext3
rootwait
# saveenv
# boot
On kernel boot, after mounting the root filesystem (/dev/mmcblk0p2) when
attempting to start init (bootargs are init=/init), in main.c,
run_init_process(execute_command) with execute_command set to /init, I
get a kernel panic:
[ 103.806274] Kernel panic - not syncing: Attempted to kill init!
Are you able to boot a standard linux omap console image, with the TI DevKit
2.2 kernel
without specifying the init=/init boot args?
This is to try to narrow the issue to being either with the x-load, u-boot,
kernel combination
with standard rootfs (which should boot properly first), versus trying to load
the android
root file system.
Which version of android are you using?
The backtrace identifies:
[ 103.812377] [c0048320] (unwind_backtrace+0x0/0x17c) from
[c0489d34] (dump_stack+0x20/0x24)
[ 103.821105] [c0489d34] (dump_stack+0x20/0x24) from [c0489d94]
(panic+0x5c/0x130)
[ 103.828918] [c0489d94] (panic+0x5c/0x130) from [c007cc18]
(do_exit+0x5d4/0x6a4)
[ 103.836669] [c007cc18] (do_exit+0x5d4/0x6a4) from [c007cd34]
(do_group_exit+0x4c/0xbc)
[ 103.845062] [c007cd34] (do_group_exit+0x4c/0xbc) from [c008dee8]
(get_signal_to_deliver+0x208/0x3e8)
[ 103.854644] [c008dee8] (get_signal_to_deliver+0x208/0x3e8) from
[c0042de0] (do_signal+0x74/0x698)
[ 103.863983] [c0042de0] (do_signal+0x74/0x698) from [c0043470]
(do_notify_resume+0x6c/0x78)
[ 103.872680] [c0043470] (do_notify_resume+0x6c/0x78) from
[c003fb4c] (work_pending+0x1c/0x20)
Could you paste the output of the entire boot process, leading upto the panic?
Elvis Dowson
--
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
[no subject]
Subscribe -- 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
