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 : > > 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 wrote: >> On Thu, 24 Mar 2011 12:00:30 -0700 >> Tony Lindgren wrote: >> >>> * Belisko Marek [110324 08:18]: On Thu, Mar 24, 2011 at 4:18 PM, Tony Lindgren wrote: > * Belisko Marek [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 wrote: > Am 25.03.2011 08:53, schrieb Belisko Marek: >> On Fri, Mar 25, 2011 at 8:13 AM, Jarkko Nikula wrote: >>> On Thu, 24 Mar 2011 12:00:30 -0700 >>> Tony Lindgren wrote: >>> * Belisko Marek [110324 08:18]: > On Thu, Mar 24, 2011 at 4:18 PM, Tony Lindgren wrote: > >> * Belisko Marek [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 > wrote: >> Am 25.03.2011 08:53, schrieb Belisko Marek: >>> On Fri, Mar 25, 2011 at 8:13 AM, Jarkko Nikula wrote: On Thu, 24 Mar 2011 12:00:30 -0700 Tony Lindgren wrote: > * Belisko Marek [110324 08:18]: >> On Thu, Mar 24, 2011 at 4:18 PM, Tony Lindgren wrote: >> >>> * Belisko Marek [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 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 B&N Nook Color generic kernel support patches?
Hi everyone, I am working on porting B&N 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 B&N Nook Color generic kernel support patches?
Hello, Abimanyu Gottumukkala writes: > I am working on porting B&N 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 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 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 g
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 correc
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] [] (unwind_backtrace+0x0/0x17c) from [] (dump_stack+0x20/0x24) [ 103.821105] [] (dump_stack+0x20/0x24) from [] (panic+0x5c/0x130) [ 103.828918] [] (panic+0x5c/0x130) from [] (do_exit+0x5d4/0x6a4) [ 103.836669] [] (do_exit+0x5d4/0x6a4) from [] (do_group_exit+0x4c/0xbc) [ 103.845062] [] (do_group_exit+0x4c/0xbc) from [] (get_signal_to_deliver+0x208/0x3e8) [ 103.854644] [] (get_signal_to_deliver+0x208/0x3e8) from [] (do_signal+0x74/0x698) [ 103.863983] [] (do_signal+0x74/0x698) from [] (do_notify_resume+0x6c/0x78) [ 103.872680] [] (do_notify_resume+0x6c/0x78) from [] (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] [] (unwind_backtrace+0x0/0x17c) from
> [] (dump_stack+0x20/0x24)
> [ 103.821105] [] (dump_stack+0x20/0x24) from []
> (panic+0x5c/0x130)
> [ 103.828918] [] (panic+0x5c/0x130) from []
> (do_exit+0x5d4/0x6a4)
> [ 103.836669] [] (do_exit+0x5d4/0x6a4) from []
> (do_group_exit+0x4c/0xbc)
> [ 103.845062] [] (do_group_exit+0x4c/0xbc) from []
> (get_signal_to_deliver+0x208/0x3e8)
> [ 103.854644] [] (get_signal_to_deliver+0x208/0x3e8) from
> [] (do_signal+0x74/0x698)
> [ 103.863983] [] (do_signal+0x74/0x698) from []
> (do_notify_resume+0x6c/0x78)
> [ 103.872680] [] (do_notify_resume+0x6c/0x78) from
> [] (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
