Re: Please help in adding ams-delta support to ASoC
On Tue, 16 Jun 2009 16:43:53 +0200 Janusz Krzysztofik wrote: > >>> - original patch ported to the last l-o commit supporting > >>> omap-alsa: > >>> - playback: works as before, > >>> - capture: both >>> but DMA interrupts still work. > I can confirm that the old driver can set up mcbsp in a way that > keeps it shifting the contents of its input register, loaded with a > pattern using omap_mcbsp_pollwrite() as Peter suggested, even if I > break dma by commenting out all omap_start_dma() invocations. I have > verified this by detecting averaged voltage level changes on the > codec input pin with a simple multimeter (I still have not get access > to a scope back). > Heh, clever and adequate enough test at the moment until we'll get bit running over the interface :-) > Using the new driver, I am not able to detect similiar voltage > changes, whatever I do to get the mcbsp sending data to the codec > over its serial output. I have modified omap-mcbsp code with a hacked > in probe hook that initializes mcbsp at boot time exactly as the old > driver does it - no results. > Hmm, recall, did you try hacking the ASoC driver at the same commit d8376cc482b241701f7606c81ad578b90853e175 where older driver still exists and works? There has been ASoC OMAP fixes and changes since then but nothing which can explain why it doesn't work now for 1510. There we would know that clock framework, register access etc. works for McBSP on 1510. -- Jarkko -- 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] SDRC: Remove SDRC_POWER register configuration from SDRC init.
Hi,
Perhaps someone from TI could comment that. I'm not sure if I can share
errata information for public discussion.
Br,
Samu
>-Original Message-
>From: ext Paul Walmsley [mailto:p...@pwsan.com]
>Sent: 17 June, 2009 19:25
>To: Onkalo Samu.P (Nokia-D/Tampere); Bityutskiy Artem
>(Nokia-D/Helsinki)
>Cc: linux-omap@vger.kernel.org; Tony Lindgren
>Subject: Re: [PATCH] SDRC: Remove SDRC_POWER register
>configuration from SDRC init.
>
>Hello Samu, Artem,
>
>On Wed, 17 Jun 2009, Artem Bityutskiy wrote:
>
>> From: Samu Onkalo
>>
>> Bootloader must configure proper settings for SDRC before starting
>> kernel from SDRAM. Furthermore, removed lines violated omap3430 and
>> omap2420 SDRC errata (see errata 1.150)
>
>The 2420 and 3430 errata data here seems to be old; neither
>one contains 1.150. While I wait for a new version to arrive,
>can you provide some more context on this errata? Does it
>imply any restrictions on programming SDRC_POWER from SRAM,
>e.g., the CORE DVFS code?
>
>
>- Paul
>
>>
>> Signed-off-by: Samu Onkalo
>> ---
>> arch/arm/mach-omap2/sdrc.c | 10 ++
>> 1 files changed, 2 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
>> index 2045441..0874687 100644
>> --- a/arch/arm/mach-omap2/sdrc.c
>> +++ b/arch/arm/mach-omap2/sdrc.c
>> @@ -86,8 +86,8 @@ void __init omap2_set_globals_sdrc(struct
>omap_globals *omap2_globals)
>> * @sp: pointer to a null-terminated list of struct omap_sdrc_params
>> *
>> * Turn on smart idle modes for SDRAM scheduler and controller.
>> - * Program a known-good configuration for the SDRC to deal
>with buggy
>> - * bootloaders.
>> + * Bootloaders should make proper configuration for SDRC
>since kernel
>> + * is running from SDRAM.
>> */
>> void __init omap2_sdrc_init(struct omap_sdrc_params *sp) { @@
>> -104,10 +104,4 @@ void __init omap2_sdrc_init(struct
>omap_sdrc_params *sp)
>> sdrc_write_reg(l, SDRC_SYSCONFIG);
>>
>> sdrc_init_params = sp;
>> -
>> -/* XXX Enable SRFRONIDLEREQ here also? */
>> -l = (1 << SDRC_POWER_EXTCLKDIS_SHIFT) |
>> -(1 << SDRC_POWER_PWDENA_SHIFT) |
>> -(1 << SDRC_POWER_PAGEPOLICY_SHIFT);
>> -sdrc_write_reg(l, SDRC_POWER);
>> }
>> --
>> 1.6.0.6
>>
>> --
>> 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
>>
>
>
>- 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] DSPBRIDGE: change offset of RSTCTRL and RSTST register to the correct value.
>From 35acd0141fdaeb9a7b3214de34442a4948275ffb Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo Date: Mon, 15 Jun 2009 16:14:23 -0500 Subject: [PATCH] DSPBRIDGE: change offset of RSTCTRL and RSTST register to the correct value. This patch changes the defines of the offset for RM_RSTCTRL_IVA2 and RM_RSTCTRL_IVA2 to the value according with the TRM. Signed-off-by: Fernando Guzman Lugo --- drivers/dsp/bridge/hw/PRCMAccInt.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dsp/bridge/hw/PRCMAccInt.h b/drivers/dsp/bridge/hw/PRCMAccInt.h index 42baa68..5a11f01 100644 --- a/drivers/dsp/bridge/hw/PRCMAccInt.h +++ b/drivers/dsp/bridge/hw/PRCMAccInt.h @@ -117,8 +117,8 @@ #define PRCM_CM_AUTOIDLE_DSP_OFFSET (u32)(0x830) #define PRCM_CM_CLKSEL_DSP_OFFSET(u32)(0x840) #define PRCM_CM_CLKSTCTRL_DSP_OFFSET (u32)(0x848) -#define PRCM_RM_RSTCTRL_DSP_OFFSET (u32)(0x850) -#define PRCM_RM_RSTST_DSP_OFFSET (u32)(0x858) +#define PRCM_RM_RSTCTRL_DSP_OFFSET (u32)(0x050) +#define PRCM_RM_RSTST_DSP_OFFSET (u32)(0x058) #define PRCM_PM_PWSTCTRL_DSP_OFFSET (u32)(0x8e0) #define PRCM_PM_PWSTST_DSP_OFFSET(u32)(0x8e4) #define PRCM_PM_PWSTST_IVA2_OFFSET(u32)(0xE4) -- 1.5.6.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] OMAP3: MMC: Add mux for pins
Pandita, Vikram wrote: The ball/pad numbers may change due to the package, but the registers used to configure the pin muxing and the pin muxing options will not change. So from a software standpoint it is the same. The OMAP3530 is available in 3 packages, namely CBB, CBC and CUS according to the data manual [1]. The OMAP3430 is only available in the CBB package. What this means is that the name "N28_3430_MMC1_CLK", which associates ball N28 with signal MMC1_CLK, is appliable to the OMAP3430 and OMAP3530 CBB package, but not applicable to the OMAP3530 CBC and CUS packages as this ball number does not exist on these packages. This is simply a difference in naming of the balls between the packages but does not impact the pin muxing options. So looks like I should keep the MMC mux under cpu_is_omap3430() And not include 3530 as CBC and CUS may not be valid cases for this mux. Actually, the mux configuration is still valid for the CBC and CUS packages. The only difference is the balls have different names. Sorry if this is not clear. For example, on the OMAP3530 CBB package if you look at ball N28 you will find: mux-mode0 --> mmc1_clk mux-mode4 --> gpio120 mux-mode7 --> safe mode For the OMAP3530 CBC package you will find the same options on N19 and for the CUS package the same options on ball M23. I have been doing a bit more looking at this and we do need to becareful here. I think that we really need to view the OMAP3430 as a superset of the OMAP3530. One example being, with the OMAP3530 I don't see support for peripherals such as DSI, CSI, and MS. Hence, muxing options for the signals corresponding to these peripherals are not shown in the OMAP3530 data manual. This just means that there are less muxing options on some of the balls for the OMAP3530, but the good news is that there will not be any conflicts between the OMAP3430 and OMAP3530 as far as muxing goes. OK, good. Thanks for the clarification. Tony and I were thinking a few weeks back that we should drop the ball names from these mux options anyways as they don't really add any value, and seem to add more confusion. Sounds like it's the right thing to do in this context. I was thinking this too. For different applications different packages make sense. So this is fairly common to see. So dropping the ball name would make this easier. I guess the only benefit is knowing the actual ball that you are using for hardware purposes. However, on OMAP2/3 the register names imply what is mux-mode0 and so it fairly easy to figure out the ball number from the data manual. Cheers Jon -- 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 -pm 1/2] SDRC: check for stuck DLL state machine and kick
Hi Paul, Hm, seems my mailing is out to lunch today... I'll be worse than normal in protocol and top post. I've seen this issue on a couple custom boards. In these instances I've not had access to boot loaders. I would expect this issue would show up in the wild in some devices. It might be ok to move to at least init. Having it at deadlock spot is a bit more conservative. I've only seen the condition along side of very aggressive SDRC_POWER settings. Its my guess beagle doesn't enable all those features yet. Unless you have a bunch of beagle accessories attached, I'm not sure how good a reference beagle is for system DVFS validation. I've not taken stat's to see how much it happens. The alternate to the latency spike is a dead lock which is clealry not wanted. Net-Net I see this as more a plus than a minus in current form. If you have some time you might expirment with beagle and see if you can trigger the condition. Regards, Richard W. -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, June 17, 2009 3:04 AM So, what is different about your setup? The usual suite of questions: - What chip revisions/boards does this affect? - Is this specific to certain bootloaders? - Has anyone else out there seen this problem? Rather than working around an occasional DLL failure to lock, is it possible to reset the DLL earlier in the boot process, as Richard's commit message suggests? That would be preferable to this approach. A back-of-the-envelope assessment suggests that this patch could cause unpredictable, additional 1.5 millisecond latency spikes whenever the workaround triggers (since OCM RAM is marked uncacheable). -- 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/2] adding back some features
writes:
>
>
>>-Original Message-
>>From: ext Tony Lindgren [mailto:t...@atomide.com]
>>Sent: 17 June, 2009 12:58
>>To: Paul Walmsley
>>Cc: Kristo Tero (Nokia-D/Tampere); Kevin Hilman;
>>linux-omap@vger.kernel.org
>>Subject: Re: [PATCH 0/2] adding back some features
>>
>>* Paul Walmsley [090617 01:35]:
>>> code comment below:
>>>
>>> On Wed, 17 Jun 2009, Tony Lindgren wrote:
>>>
>>> > * Kevin Hilman [090615 09:05]:
>>> > > Kevin Hilman writes:
>>> > >
>>> > > > Tony Lindgren writes:
>>> > > >
>>> > > >> Hi,
>>> > > >>
>>> > > >> * Kevin Hilman [090612 15:13]:
>>> > > >>> Here's a couple patches to add-back some feature dropped in
>>> > > >>> the mainline sync. These are needed for the PM
>>branch among other things.
>>> > > >>>
>>> > > >>> Applies to linux-omap master.
>>> > > >>>
>>> > > >>> Kevin Hilman (1):
>>> > > >>> OMAP2/3: SoC IDs: add omap_type() for determining GP/EMU/HS
>>> > > >>
>>> > > >> Is there any reason to get this one into mainline early?
>>> > > >
>>> > > > Well, the PM branch has a dependency, but also the recenetly
>>> > > > submitted qwatchdog driver has a dependency.
>>> > > >
>>> > > >> If not, I suggest you keep this in your pm branch for next
>>> > > >> merge window that I can keep merging to l-o master as needed.
>>> > > >>
>>> > > >> However, if omap_type() is by other queues earlier,
>>then I can
>>> > > >> add it into my upstream queue. If this blocks several queues
>>> > > >> from being rebased against mainline kernel, that alone might
>>> > > >> already be a good enough reason to get it in early.
>>> > > >
>>> > > > I think it should go via your upstream queue. I
>>imagine some of
>>> > > > the other upcoming driver submissions from TI will have a
>>> > > > dependency as well since there is still some missing
>>EMU/HS support ind drivers.
>>> > >
>>> > > Also, I'm carrying this SRAM patch below for HS/EMU that
>>could go
>>> > > into Paul's SRAM/SDRC queue if this omap_type() gets
>>merged sooner
>>> > > rather than later.
>>> >
>>> > Hmm, the HS omap sram.c patch below for sure justifies
>>fixing it as
>>> > incorrect SRAM size can cause nasty bugs.
>>> >
>>> > Will add both omap_type and the sram.c patch below to omap-fixes.
>>> >
>>> > Regards,
>>> >
>>> > Tony
>>> >
>>> > > Kevin
>>> > >
>>> > > commit 106588e30f070d9a8d5906d409e0b9aad89edc9e
>>> > > Author: Tero Kristo
>>> > > Date: Thu Oct 9 17:47:02 2008 +0300
>>> > >
>>> > > OMAP3: SRAM size fix for HS/EMU devices
>>> > >
>>> > > Signed-off-by: Tero Kristo
>>> > > Signed-off-by: Kevin Hilman
>>> > >
>>> > > diff --git a/arch/arm/plat-omap/sram.c
>>b/arch/arm/plat-omap/sram.c
>>> > > old mode 100644 new mode 100755 index 65006df..f40bd2d
>>> > > --- a/arch/arm/plat-omap/sram.c
>>> > > +++ b/arch/arm/plat-omap/sram.c
>>> > > @@ -131,9 +131,15 @@ void __init omap_detect_sram(void)
>>> > > if (cpu_class_is_omap2()) {
>>> > > if (is_sram_locked()) {
>>> > > if (cpu_is_omap34xx()) {
>>> > > - omap_sram_base =
>>OMAP3_SRAM_PUB_VA;
>>> > > - omap_sram_start =
>>OMAP3_SRAM_PUB_PA;
>>> > > - omap_sram_size =
>>0x8000; /* 32K */
>>> > > + if (omap_type() ==
>>OMAP2_DEVICE_TYPE_GP) {
>>> > > + omap_sram_base
>>= OMAP3_SRAM_PUB_VA;
>>> > > + omap_sram_start
>>= OMAP3_SRAM_PUB_PA;
>>> > > + omap_sram_size
>>= 0x8000; /* 32K */
>>> > > + } else {
>>>
>>> This would be better if it specifically tested for HS and
>>EMU devices.
>>> There are at least two other omap_type() possibilities here, "TEST"
>>> and "BAD"
>>
>>Tero, can you please repost? I will hold on sending out the
>>omap-fixes for that, and refresh omap-fixes with the updated patch.
>
> I'll try to look at this tomorrow if I happen to have time, I am currently
> quite busy fixing some bugs in our code base. However, if you need it right
> now and if someone wants to re-write this to check against TEST and BAD, I am
> of course okay with that (rather simple fix actually.) :)
>
OK, I've sent an updated patch to the list, along with a revert of the
original so it's easier to sned upstream.
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
[PATCH 2/2] OMAP3: SRAM size fix for HS/EMU devices
From: Tero Kristo
SRAM size fix for HS/EMU devices
Signed-off-by: Tero Kristo
Signed-off-by: Kevin Hilman
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/sram.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
mode change 100644 => 100755 arch/arm/plat-omap/sram.c
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
old mode 100644
new mode 100755
index 65006df..80bf3b1
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -133,7 +133,11 @@ void __init omap_detect_sram(void)
if (cpu_is_omap34xx()) {
omap_sram_base = OMAP3_SRAM_PUB_VA;
omap_sram_start = OMAP3_SRAM_PUB_PA;
- omap_sram_size = 0x8000; /* 32K */
+ if ((omap_type() == OMAP2_DEVICE_TYPE_EMU) ||
+ (omap_type() == OMAP2_DEVICE_TYPE_SEC)) {
+ omap_sram_size = 0x7000; /* 28K */
+ else
+ omap_sram_size = 0x8000; /* 32K */
} else {
omap_sram_base = OMAP2_SRAM_PUB_VA;
omap_sram_start = OMAP2_SRAM_PUB_PA;
--
1.6.3.2
--
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] Revert "OMAP3: SRAM size fix for HS/EMU devices"
This reverts commit bea1418bd09e30961e36f96f97979a3603f1da9b.
---
arch/arm/plat-omap/sram.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
mode change 100755 => 100644 arch/arm/plat-omap/sram.c
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
old mode 100755
new mode 100644
index f40bd2d..65006df
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -131,15 +131,9 @@ void __init omap_detect_sram(void)
if (cpu_class_is_omap2()) {
if (is_sram_locked()) {
if (cpu_is_omap34xx()) {
- if (omap_type() == OMAP2_DEVICE_TYPE_GP) {
- omap_sram_base = OMAP3_SRAM_PUB_VA;
- omap_sram_start = OMAP3_SRAM_PUB_PA;
- omap_sram_size = 0x8000; /* 32K */
- } else {
- omap_sram_base = OMAP3_SRAM_PUB_VA;
- omap_sram_start = OMAP3_SRAM_PUB_PA;
- omap_sram_size = 0x7000; /* 28K */
- }
+ omap_sram_base = OMAP3_SRAM_PUB_VA;
+ omap_sram_start = OMAP3_SRAM_PUB_PA;
+ omap_sram_size = 0x8000; /* 32K */
} else {
omap_sram_base = OMAP2_SRAM_PUB_VA;
omap_sram_start = OMAP2_SRAM_PUB_PA;
--
1.6.3.2
--
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
new 2.6.30-based PM branch
Hello, Now that 2.6.30 is out, the PM branch has been rebased onto current linux-omap master which is 2.6.30 based. The previous, 2.6.29-based PM branch will continue to exist and be renamed to pm-2.6.29. I will continue to accept bugfixes against pm-2.6.29, but all new work should be done on the new pm branch. Both branches are available in my linux-omap-pm tree[1], but only the 2.6.30-based one (named 'pm') will be sync'd daily to Tony's linux-omap repo. This new PM branch has had basic testing on the following OMAP3 platforms - 3430SDP (initramfs, NFS) - OMAP3 EVM (initramfs, NFS) - Beagle (MMC rootfs) - RX51 (OneNAND rootfs) - Zoom2 (initramfs, ** problems w/NFS, see below) And is able to do full-chip retention and off in idle and suspend on all of these platforms. Rather than try to manage multiple defconfigs for these boards, there is a now a new all-in-one defconfig that will work on all these boards. Well, almost. omap3_pm_defconfig will work out of the box on SDP and EVM, and will boot on Beagle, Zoom2 and RX51 simply by changing System Type-->TI OMAP implementations-->Low-level debug console UART from UART1 to UART3 (the LL_DEBUG support is still a little dumb and needs some fixing, but that's for another day.) Known problems: - Zoom2 network doesn't work, not yet debugged - ES3.0-based SDPs have problems with UART1 coming back from off-while-idle UART 3 works fine. Kevin [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git -- 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] OMAP3: MMC: Add mux for pins
>-Original Message- >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: Wednesday, June 17, 2009 5:58 PM >To: Hunter, Jon >Cc: Pandita, Vikram; Tony Lindgren; Hugo Vincent; linux-omap@vger.kernel.org; >Chikkature Rajashekar, >Madhusudhan >Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins > >Jon Hunter writes: > >> Kevin Hilman wrote: >>> "Pandita, Vikram" writes: >>> > -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > >>> If some pins are always needed, and don't have alternative pinouts, then >>> the common pins could be muxed in devices.c. >> This is the algo we can use for MMC pin muxing in that case: >> >> MMC1: No pin has mux clash >> Mux all 10 pins in devices.c > Is this common across 34xx and 35xx? Yes this is common. Both are same OMAP3 marketed differently. >>> >>> Yes, but they are in different packages, so I was curious if the pin >>> muxing is identical across the different packages. >> >> The ball/pad numbers may change due to the package, but the registers >> used to configure the pin muxing and the pin muxing options will not >> change. So from a software standpoint it is the same. >> >> The OMAP3530 is available in 3 packages, namely CBB, CBC and CUS >> according to the data manual [1]. The OMAP3430 is only available in >> the CBB package. >> >> What this means is that the name "N28_3430_MMC1_CLK", which associates >> ball N28 with signal MMC1_CLK, is appliable to the OMAP3430 and >> OMAP3530 CBB package, but not applicable to the OMAP3530 CBC and CUS >> packages >> as this ball number does not exist on these packages. This is simply a >> difference in naming of the balls between the packages but does not >> impact the pin muxing options. So looks like I should keep the MMC mux under cpu_is_omap3430() And not include 3530 as CBC and CUS may not be valid cases for this mux. > >OK, good. Thanks for the clarification. > >Tony and I were thinking a few weeks back that we should drop the ball >names from these mux options anyways as they don't really add any >value, and seem to add more confusion. Sounds like it's the right >thing to do in this context. > >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] OMAP3: MMC: Add mux for pins
Jon Hunter writes: > Kevin Hilman wrote: >> "Pandita, Vikram" writes: >> -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> If some pins are always needed, and don't have alternative pinouts, then >> the common pins could be muxed in devices.c. > This is the algo we can use for MMC pin muxing in that case: > > MMC1: No pin has mux clash > Mux all 10 pins in devices.c Is this common across 34xx and 35xx? >>> Yes this is common. >>> Both are same OMAP3 marketed differently. >> >> Yes, but they are in different packages, so I was curious if the pin >> muxing is identical across the different packages. > > The ball/pad numbers may change due to the package, but the registers > used to configure the pin muxing and the pin muxing options will not > change. So from a software standpoint it is the same. > > The OMAP3530 is available in 3 packages, namely CBB, CBC and CUS > according to the data manual [1]. The OMAP3430 is only available in > the CBB package. > > What this means is that the name "N28_3430_MMC1_CLK", which associates > ball N28 with signal MMC1_CLK, is appliable to the OMAP3430 and > OMAP3530 CBB package, but not applicable to the OMAP3530 CBC and CUS > packages > as this ball number does not exist on these packages. This is simply a > difference in naming of the balls between the packages but does not > impact the pin muxing options. OK, good. Thanks for the clarification. Tony and I were thinking a few weeks back that we should drop the ball names from these mux options anyways as they don't really add any value, and seem to add more confusion. Sounds like it's the right thing to do in this context. 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] OMAP3: MMC: Add mux for pins
Kevin Hilman wrote: "Pandita, Vikram" writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] If some pins are always needed, and don't have alternative pinouts, then the common pins could be muxed in devices.c. This is the algo we can use for MMC pin muxing in that case: MMC1: No pin has mux clash Mux all 10 pins in devices.c Is this common across 34xx and 35xx? Yes this is common. Both are same OMAP3 marketed differently. Yes, but they are in different packages, so I was curious if the pin muxing is identical across the different packages. The ball/pad numbers may change due to the package, but the registers used to configure the pin muxing and the pin muxing options will not change. So from a software standpoint it is the same. The OMAP3530 is available in 3 packages, namely CBB, CBC and CUS according to the data manual [1]. The OMAP3430 is only available in the CBB package. What this means is that the name "N28_3430_MMC1_CLK", which associates ball N28 with signal MMC1_CLK, is appliable to the OMAP3430 and OMAP3530 CBB package, but not applicable to the OMAP3530 CBC and CUS packages as this ball number does not exist on these packages. This is simply a difference in naming of the balls between the packages but does not impact the pin muxing options. Cheers Jon [1] OMAP3530 Data Manual http://www.ti.com/lit/gpn/omap3530 -- 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: OMAP34XXCAM: Micron mt9d111 sensor support?
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Zach LeRoy > Sent: Wednesday, June 17, 2009 5:06 PM > To: linux-omap; linux-me...@vger.kernel.org > Subject: OMAP34XXCAM: Micron mt9d111 sensor support? > > I am working on adding support for a micron 2 MP sensor: mt9d111 on a > gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to > use the omap34xxcam driver to interface with this sensor. I am wondering > if there are currently any distributions which already include support for > this sensor through the omap34xxcam driver, or if anyone else is > interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) Regards, Sergio > > Cheers, > > Zach LeRoy > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" 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
OMAP34XXCAM: Micron mt9d111 sensor support?
I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Cheers, Zach LeRoy -- 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] OMAP3: MMC: Add mux for pins
"Pandita, Vikram" writes: >>-Original Message- >>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> If some pins are always needed, and don't have alternative pinouts, then the common pins could be muxed in devices.c. >>> >>> This is the algo we can use for MMC pin muxing in that case: >>> >>> MMC1: No pin has mux clash >>> Mux all 10 pins in devices.c >> >>Is this common across 34xx and 35xx? > > Yes this is common. > Both are same OMAP3 marketed differently. Yes, but they are in different packages, so I was curious if the pin muxing is identical across the different packages. 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
[PATCH - V3] TVP514x: Migration to sub-device framework
From: Muralidharan Karicheri
This patch converts TVP514x driver to sub-device framework
from V4L2-int framework.
NOTE: Please note that this patch was tested on DM355 and DM6446
and not tested on OMAP platform
Changes from v2 based on review comments (Taken over this work from
Vaibhav)
- removed __exit for tvp514x_remove
- removed v4l2_i2c_driver_data and use new model similar to ths7303
- changed state to streaming
TODO:
- Add support for some basic video/core functionality like,
.g_chip_ident
.reset
.g_input_status
- Migration of OMAP master driver to validate this driver
- validate on OMAP boards
Reviewed by :Hans Verkuil
Signed-off-by: Brijesh Jadav
Signed-off-by: Hardik Shah
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Murali Karicheri
---
Applies to v4l-dvb repository
drivers/media/video/tvp514x.c | 875 ++--
drivers/media/video/tvp514x_regs.h | 10 -
include/media/tvp514x.h|4 -
3 files changed, 349 insertions(+), 540 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 3750f7f..6063b57 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -31,7 +31,10 @@
#include
#include
#include
-#include
+
+#include
+#include
+#include
#include
#include "tvp514x_regs.h"
@@ -49,13 +52,11 @@ static int debug;
module_param(debug, bool, 0644);
MODULE_PARM_DESC(debug, "Debug level (0-1)");
-#define dump_reg(client, reg, val) \
- do {\
- val = tvp514x_read_reg(client, reg);\
- v4l_info(client, "Reg(0x%.2X): 0x%.2X\n", reg, val); \
- } while (0)
+MODULE_AUTHOR("Texas Instruments");
+MODULE_DESCRIPTION("TVP514X linux decoder driver");
+MODULE_LICENSE("GPL");
-/**
+/*
* enum tvp514x_std - enum for supported standards
*/
enum tvp514x_std {
@@ -64,15 +65,7 @@ enum tvp514x_std {
STD_INVALID
};
-/**
- * enum tvp514x_state - enum for different decoder states
- */
-enum tvp514x_state {
- STATE_NOT_DETECTED,
- STATE_DETECTED
-};
-
-/**
+/*
* struct tvp514x_std_info - Structure to store standard informations
* @width: Line width in pixels
* @height:Number of active lines
@@ -87,35 +80,29 @@ struct tvp514x_std_info {
};
static struct tvp514x_reg tvp514x_reg_list_default[0x40];
-/**
+/*
* struct tvp514x_decoder - TVP5146/47 decoder object
- * @v4l2_int_device: Slave handle
- * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
+ * @sd: Subdevice Slave handle
* @tvp514x_regs: copy of hw's regs with preset values.
* @pdata: Board specific
- * @client: I2C client data
- * @id: Entry from I2C table
* @ver: Chip version
- * @state: TVP5146/47 decoder state - detected or not-detected
+ * @streaming: TVP5146/47 decoder streaming - enabled or disabled.
* @pix: Current pixel format
* @num_fmts: Number of formats
* @fmt_list: Format list
* @current_std: Current standard
* @num_stds: Number of standards
* @std_list: Standards list
- * @route: input and output routing at chip level
+ * @input: Input routing at chip level
+ * @output: Output routing at chip level
*/
struct tvp514x_decoder {
- struct v4l2_int_device v4l2_int_device;
- struct v4l2_int_slave tvp514x_slave;
+ struct v4l2_subdev sd;
struct tvp514x_reg tvp514x_regs[ARRAY_SIZE(tvp514x_reg_list_default)];
const struct tvp514x_platform_data *pdata;
- struct i2c_client *client;
-
- struct i2c_device_id *id;
int ver;
- enum tvp514x_state state;
+ int streaming;
struct v4l2_pix_format pix;
int num_fmts;
@@ -124,8 +111,11 @@ struct tvp514x_decoder {
enum tvp514x_std current_std;
int num_stds;
struct tvp514x_std_info *std_list;
-
- struct v4l2_routing route;
+ /*
+* Input and Output Routing parameters
+*/
+ u32 input;
+ u32 output;
};
/* TVP514x default register values */
@@ -191,7 +181,8 @@ static struct tvp514x_reg tvp514x_reg_list_default[] = {
{TOK_TERM, 0, 0},
};
-/* List of image formats supported by TVP5146/47 decoder
+/*
+ * List of image formats supported by TVP5146/47 decoder
* Currently we are using 8 bit mode only, but can be
* extended to 10/20 bit mode.
*/
@@ -240,35 +231,29 @@ static struct tvp514x_std_info tvp514x_std_list[] = {
},
/* Standard: need to add for additional standard */
};
-/*
- * Control structure for Auto Gain
- * This is temporary data, will get replaced once
- * v4l2_ctrl_query_fill supports it.
- */
-static const struct v4l2_queryctrl tvp514x_autogain_ctrl = {
- .id = V4L2_CID_AUTOGAIN,
- .name = "Gain, Automatic",
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .minimum = 0,
- .maximum = 1,
- .step
[PATCH v4 0/2] watchdog:OMAP3:Add support for IVA2, SECURE WDTs
This patch series enables support for IVA2 and SECURE WDTs, available on omap34xx. The WDTs will be accessible (when present on device) through: MPU:/dev/watchdog SECURE: /dev/watchdog_secure IVA2: /dev/watchdog_iva2 Tested on Zoom1 OMAP3 platform Signed-off-by: Ulrik Bech Hald --- This patch set has a dependency on: runtime: [PATCH 1/1] watchdog: OMAP fixes: enable clock in probe, trigger timer reload arch/arm/mach-omap1/clock.c |6 +- arch/arm/mach-omap2/clock24xx.c |4 - arch/arm/mach-omap2/clock34xx.c | 12 ++--- arch/arm/plat-omap/devices.c| 91 drivers/watchdog/omap_wdt.c | 34 +++--- 5 files changed, 112 insertions(+), 35 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 v4 1/2] watchdog:OMAP3:Register IVA and SECURE WDT, make clks accessible
Enabling registration of IVA and SECURE WDT devices. Making
ick and fck for IVA and SECURE WDTs accessible.
Tested on Zoom1 OMAP3 platform
Signed-off-by: Ulrik Bech Hald
---
arch/arm/mach-omap1/clock.c |6 +-
arch/arm/mach-omap2/clock24xx.c |4 +-
arch/arm/mach-omap2/clock34xx.c | 12 +++---
arch/arm/plat-omap/devices.c| 91 ---
4 files changed, 86 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 436eed2..c0b5849 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -85,9 +85,9 @@ static struct omap_clk omap_clks[] = {
CLK(NULL, "arm_gpio_ck", &arm_gpio_ck, CK_1510 | CK_310),
CLK(NULL, "armxor_ck",&armxor_ck.clk, CK_16XX | CK_1510 |
CK_310),
CLK(NULL, "armtim_ck",&armtim_ck.clk, CK_16XX | CK_1510 |
CK_310),
- CLK("omap_wdt", "fck", &armwdt_ck.clk, CK_16XX | CK_1510 |
CK_310),
- CLK("omap_wdt", "ick", &armper_ck.clk, CK_16XX),
- CLK("omap_wdt", "ick", &dummy_ck, CK_1510 | CK_310),
+ CLK("omap_wdt.2", "fck",&armwdt_ck.clk, CK_16XX | CK_1510 |
CK_310),
+ CLK("omap_wdt.2", "ick",&armper_ck.clk, CK_16XX),
+ CLK("omap_wdt.2", "ick",&dummy_ck, CK_1510 | CK_310),
CLK(NULL, "arminth_ck", &arminth_ck1510, CK_1510 | CK_310),
CLK(NULL, "arminth_ck", &arminth_ck16xx, CK_16XX),
/* CK_GEN2 clocks */
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 44de027..4fe3def
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -165,8 +165,8 @@ static struct omap_clk omap24xx_clks[] = {
CLK(NULL, "uart3_fck",&uart3_fck, CK_243X | CK_242X),
CLK(NULL, "gpios_ick",&gpios_ick, CK_243X | CK_242X),
CLK(NULL, "gpios_fck",&gpios_fck, CK_243X | CK_242X),
- CLK("omap_wdt", "ick", &mpu_wdt_ick, CK_243X | CK_242X),
- CLK("omap_wdt", "fck", &mpu_wdt_fck, CK_243X | CK_242X),
+ CLK("omap_wdt.2", "ick",&mpu_wdt_ick, CK_243X | CK_242X),
+ CLK("omap_wdt.2", "fck",&mpu_wdt_fck, CK_243X | CK_242X),
CLK(NULL, "sync_32k_ick", &sync_32k_ick, CK_243X | CK_242X),
CLK(NULL, "wdt1_ick", &wdt1_ick, CK_243X | CK_242X),
CLK(NULL, "omapctrl_ick", &omapctrl_ick, CK_243X | CK_242X),
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 045da92..a4613e5 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -215,11 +215,11 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, "gpt1_fck", &gpt1_fck, CK_343X),
CLK(NULL, "wkup_32k_fck", &wkup_32k_fck, CK_343X),
CLK(NULL, "gpio1_dbck", &gpio1_dbck,CK_343X),
- CLK("omap_wdt", "fck", &wdt2_fck, CK_343X),
+ CLK("omap_wdt.2", "fck",&wdt2_fck, CK_343X),
CLK(NULL, "wkup_l4_ick", &wkup_l4_ick, CK_343X),
CLK(NULL, "usim_ick", &usim_ick, CK_3430ES2),
- CLK("omap_wdt", "ick", &wdt2_ick, CK_343X),
- CLK(NULL, "wdt1_ick", &wdt1_ick, CK_343X),
+ CLK("omap_wdt.2", "ick",&wdt2_ick, CK_343X),
+ CLK("omap_wdt.1", "ick",&wdt1_ick, CK_343X),
CLK(NULL, "gpio1_ick",&gpio1_ick, CK_343X),
CLK(NULL, "omap_32ksync_ick", &omap_32ksync_ick, CK_343X),
CLK(NULL, "gpt12_ick",&gpt12_ick, CK_343X),
@@ -241,14 +241,14 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, "gpio4_dbck", &gpio4_dbck,CK_343X),
CLK(NULL, "gpio3_dbck", &gpio3_dbck,CK_343X),
CLK(NULL, "gpio2_dbck", &gpio2_dbck,CK_343X),
- CLK(NULL, "wdt3_fck", &wdt3_fck, CK_343X),
+ CLK("omap_wdt.3", "fck",&wdt3_fck, CK_343X),
CLK(NULL, "per_l4_ick", &per_l4_ick,CK_343X),
CLK(NULL, "gpio6_ick",&gpio6_ick, CK_343X),
CLK(NULL, "gpio5_ick",&gpio5_ick, CK_343X),
CLK(NULL, "gpio4_ick",&gpio4_ick, CK_343X),
CLK(NULL, "gpio3_ick",&gpio3_ick, CK_343X),
CLK(NULL, "gpio2_ick",&gpio2_ick, CK_343X),
- CLK(NULL, "wdt3_ick", &wdt3_ick, CK_343X),
+ CLK("omap_wdt.3", "ick",&wdt3_ick, CK_343X),
CLK(NULL, "uart3_ick",&uart3_ick, CK_343X),
CLK(NULL, "gpt9_ick", &gpt9_ick, CK_343X),
CLK(NULL, "gpt8_ick", &gpt8_ick, CK_343X),
@@ -275,7 +275,7 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, "sr_l4_ick",&sr_l4_ick, CK_343X),
CLK(NULL,
[PATCH v4 2/2] watchdog:OMAP3:Enable support for IVA2 and SECURE
This patch adds support for IVA2 and SECURE WDTs in the omap_wdt
driver for omap34xx family. SECURE will be available as
/dev/watchdog_secure on HS/EMU devices and IVA2 will be available
as /dev/watchdog_iva2. MPU will still be available as /dev/watchdog
Tested on Zoom1 OMAP3 platform
Signed-off-by: Ulrik Bech Hald
---
runtime: [PATCH 1/1] watchdog: OMAP fixes: enable clock in probe, trigger timer
reload
drivers/watchdog/omap_wdt.c | 34 ++
1 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index f271385..ab9bd88
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -47,7 +47,9 @@
#include "omap_wdt.h"
-static struct platform_device *omap_wdt_dev;
+#define NUM_WDTS 3
+
+static struct platform_device *omap_wdt_dev[NUM_WDTS];
static unsigned timer_margin;
module_param(timer_margin, uint, 0);
@@ -139,8 +141,23 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
*/
static int omap_wdt_open(struct inode *inode, struct file *file)
{
- struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
- void __iomem *base = wdev->base;
+ struct omap_wdt_dev *wdev = NULL;
+ void __iomem *base;
+
+ /* Find match between device node and wdt device */
+ int i;
+ for (i = 0; i < NUM_WDTS; i++) {
+ if (omap_wdt_dev[i]) {
+ wdev = platform_get_drvdata(omap_wdt_dev[i]);
+ if (iminor(inode) == wdev->omap_wdt_miscdev.minor)
+ break;
+ }
+ }
+
+ if (!wdev)
+ return -ENODEV;
+
+ base = wdev->base;
if (test_and_set_bit(1, (unsigned long *)&(wdev->omap_wdt_users)))
return -EBUSY;
@@ -271,7 +288,7 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
goto err_get_resource;
}
- if (omap_wdt_dev) {
+ if (omap_wdt_dev[pdev->id-1]) {
ret = -EBUSY;
goto err_busy;
}
@@ -317,9 +334,9 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
omap_wdt_adjust_timeout(timer_margin);
wdev->omap_wdt_miscdev.parent = &pdev->dev;
- wdev->omap_wdt_miscdev.minor = WATCHDOG_MINOR;
- wdev->omap_wdt_miscdev.name = "watchdog";
+ wdev->omap_wdt_miscdev.minor = MISC_DYNAMIC_MINOR;
wdev->omap_wdt_miscdev.fops = &omap_wdt_fops;
+ wdev->omap_wdt_miscdev.name = (char *) pdev->dev.platform_data;
ret = misc_register(&(wdev->omap_wdt_miscdev));
if (ret)
@@ -332,7 +349,8 @@ static int __devinit omap_wdt_probe(struct platform_device
*pdev)
/* autogate OCP interface clock */
__raw_writel(0x01, wdev->base + OMAP_WATCHDOG_SYS_CONFIG);
- omap_wdt_dev = pdev;
+ /* keep track of the wdt platform devices in local device array */
+ omap_wdt_dev[pdev->id - 1] = pdev;
return 0;
@@ -384,7 +402,7 @@ static int __devexit omap_wdt_remove(struct platform_device
*pdev)
iounmap(wdev->base);
kfree(wdev);
- omap_wdt_dev = NULL;
+ omap_wdt_dev[pdev->id-1] = NULL;
return 0;
}
--
1.5.4.3
--
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] OMAP3: MMC: Add mux for pins
>-Original Message- >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > >>>If some pins are always needed, and don't have alternative pinouts, then >>>the common pins could be muxed in devices.c. >> >> This is the algo we can use for MMC pin muxing in that case: >> >> MMC1: No pin has mux clash >> Mux all 10 pins in devices.c > >Is this common across 34xx and 35xx? Yes this is common. Both are same OMAP3 marketed differently. > >> MMC2: MUX CLK,CMD,D0-D3 in devices.c: D4-D7 have mux clash >> In case board needs 8 bit support, >> then in devices.c print KERN_WARNING "Configure MMC2:D4-D7 mux in board >> file" > >I don't think you need a KERN_WARNING, what if the board code does this >later? Probably a comment in the code would suffice. Given this split of common MMC mux in devices.c and non-common MMC mux in board file, for someone starting new, a warning message helps a lot... The idea is to warn only MMC2-8bit and MMC3 user to setup the mux. If already done in uboot/board file, purpose is solved... > >> MMC3: All pins have mux clash: No mux done in devices.c >> In case board specifies MMC3 usage, >> then in devices.c print KERN_WARNING "Configure MMC3 mux in board file" >> >> Let me know if this is final and I can submit a patch. > >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] OMAP3: MMC: Add mux for pins
"Pandita, Vikram" writes: >> >>If some pins are always needed, and don't have alternative pinouts, then >>the common pins could be muxed in devices.c. > > This is the algo we can use for MMC pin muxing in that case: > > MMC1: No pin has mux clash > Mux all 10 pins in devices.c Is this common across 34xx and 35xx? > MMC2: MUX CLK,CMD,D0-D3 in devices.c: D4-D7 have mux clash > In case board needs 8 bit support, > then in devices.c print KERN_WARNING "Configure MMC2:D4-D7 mux in board > file" I don't think you need a KERN_WARNING, what if the board code does this later? Probably a comment in the code would suffice. > MMC3: All pins have mux clash: No mux done in devices.c > In case board specifies MMC3 usage, > then in devices.c print KERN_WARNING "Configure MMC3 mux in board file" > > Let me know if this is final and I can submit a patch. 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] OMAP3: MMC: Add mux for pins
>-Original Message- >From: Tony Lindgren [mailto:t...@atomide.com] > >* Pandita, Vikram [090616 09:50]: >> >> >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >> > >> >"Pandita, Vikram" writes: >> > >> >>>-Original Message- >> >>>From: Tony Lindgren [mailto:t...@atomide.com] >> >>>Sent: Monday, June 15, 2009 6:05 AM >> >>>To: Hugo Vincent >> >>>Cc: Pandita, Vikram; linux-omap@vger.kernel.org; Chikkature Rajashekar, >> >>>Madhusudhan >> >>>Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins >> >>> >> >>>* Hugo Vincent [090615 03:44]: >> >> On 15/06/2009, at 8:12 PM, Tony Lindgren wrote: >> >> > * Vikram Pandita [090612 15:43]: >> >> For OMAP3 add MMC1 MMC2 and MMC3 pin mux >> >> >> >> Signed-off-by: Chikkature Rajashekar >> >> Signed-off-by: Vikram Pandita >> >> --- >> >> arch/arm/mach-omap2/devices.c | 33 ++ >> >> arch/arm/mach-omap2/mux.c | 49 +++ >> >> ++ >> >> arch/arm/plat-omap/include/mach/mux.h | 28 +++ >> > >> > Great, just one issue: All data pins may not be connected, so you >> > need to look at wires in struct omap_mmc_slot_data to see how many >> > data pins to mux. >> >> There is another issue: different mux-outs are possible for different >> board layouts; for example, I'm using AE10_3430_MMC3_CMD instead of >> AC3_3430_MMC3_CMD. I'm not sure what the best way of handling this is, >> but at a minimum, perhaps make mux setting optional, e.g. add no_mux to >> struct omap_mmc_slot_data. >> >>> >> >>>Hmm, yeah that's right. I guess only the common pins should be muxed >> >>>in devices.c, and any optional pins should be muxed in the board-*.c >> >>>files. >> >> >> >> Please check this patch set: >> >> [PATCH 1/2] OMAP3: MMC: Pass pin muxing control flag >> >> >> >> I used the nomux flag to do this distinction. >> >> >> > >> >This still doesn't address the problem that when you do mux, you mux >> >all OMAP3 platforms the same way, and that is not correct. >> >> The patch tries to address this exact concern. >> >> Using nomux flag, the board file decides if the default mux for each MMC(n) >> controller is good for >it or not. >> >> In case default is good, then MMC(n).nomux=0 >> In case default mux for any one MMC controller is not good, then for that >> MMC(n).nomux=1 >> >> And the board file specifies the mux for that MMC(n) only. >> >> I do not see any advantage to control mux at ball level for each mmc >> controller instance. > >To me it seems cleanest just to do the muxing in board-*.c files and not even >attempt to do it in a generic way. As we also support doing the muxing in >the bootloader only, adding a flag for nomux can easily create hard to >track bugs. Ok. > >If some pins are always needed, and don't have alternative pinouts, then >the common pins could be muxed in devices.c. This is the algo we can use for MMC pin muxing in that case: MMC1: No pin has mux clash Mux all 10 pins in devices.c MMC2: MUX CLK,CMD,D0-D3 in devices.c: D4-D7 have mux clash In case board needs 8 bit support, then in devices.c print KERN_WARNING "Configure MMC2:D4-D7 mux in board file" MMC3: All pins have mux clash: No mux done in devices.c In case board specifies MMC3 usage, then in devices.c print KERN_WARNING "Configure MMC3 mux in board file" Let me know if this is final and I can submit a patch. > >Regards, > >Tony -- 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 4/7] DSPBRIDGE: Shared memory size increased to 5MB
Increase the shared memory size to 5MB, bridge initialization should reserve 5MB of shared memory by default. Signed-off-by: Omar Ramirez Luna --- drivers/dsp/bridge/rmgr/drv_interface.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c b/drivers/dsp/bridge/rmgr/drv_interface.c index f41e153..eaac89d 100644 --- a/drivers/dsp/bridge/rmgr/drv_interface.c +++ b/drivers/dsp/bridge/rmgr/drv_interface.c @@ -129,7 +129,7 @@ static s32 driver_minor = DRIVER_MINOR; static char *base_img; char *iva_img; static char *num_procs = "C55=1"; -static s32 shm_size = 0x40;/* 4 MB */ +static s32 shm_size = 0x50;/* 5 MB */ static u32 phys_mempool_base; static u32 phys_mempool_size; static int tc_wordswapon; /* Default value is always false */ -- 1.6.2.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/7] DSPBRIDGE: Handle properly user space pointers
From: Hari Kanigeri
This patch fixes bridge crash in UUID_UuidToString function. This
error was due to user pointers not handled properly.
Signed-off-by: Hari Kanigeri
---
drivers/dsp/bridge/pmgr/wcd.c | 147 ++---
1 files changed, 109 insertions(+), 38 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index cd84e4e..995a833 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -519,15 +519,38 @@ u32 MGRWRAP_EnumProc_Info(union Trapped_Args *args)
u32 MGRWRAP_RegisterObject(union Trapped_Args *args)
{
u32 retVal;
+ struct DSP_UUID pUuid;
+ u32 pathSize = 0;
+ char *pszPathName = NULL;
+ DSP_STATUS status = DSP_SOK;
+
+ cp_fm_usr(&pUuid, args->ARGS_MGR_REGISTEROBJECT.pUuid, status, 1);
+ if (DSP_FAILED(status))
+ goto func_end;
+ pathSize = strlen_user((char *)
+ args->ARGS_MGR_REGISTEROBJECT.pszPathName);
+ pszPathName = MEM_Alloc(pathSize, MEM_NONPAGED);
+ if (!pszPathName)
+ goto func_end;
+ retVal = strncpy_from_user(pszPathName,
+ (char *)args->ARGS_MGR_REGISTEROBJECT.pszPathName,
+ pathSize);
+ if (!retVal) {
+ status = DSP_EPOINTER;
+ goto func_end;
+ }
+ pszPathName[pathSize] = '\0';
GT_1trace(WCD_debugMask, GT_ENTER,
"MGRWRAP_RegisterObject: entered pg2hMsg "
"0x%x\n", args->ARGS_MGR_REGISTEROBJECT.pUuid);
- retVal = DCD_RegisterObject(WRAP_MAP2CALLER
- (args->ARGS_MGR_REGISTEROBJECT.pUuid),
- args->ARGS_MGR_REGISTEROBJECT.objType,
- WRAP_MAP2CALLER(args->ARGS_MGR_REGISTEROBJECT.pszPathName));
- return retVal;
+ status = DCD_RegisterObject(&pUuid,
+ args->ARGS_MGR_REGISTEROBJECT.objType,
+ (char *)pszPathName);
+func_end:
+ if (pszPathName)
+ MEM_Free(pszPathName);
+ return status;
}
/*
@@ -535,16 +558,21 @@ u32 MGRWRAP_RegisterObject(union Trapped_Args *args)
*/
u32 MGRWRAP_UnregisterObject(union Trapped_Args *args)
{
- u32 retVal;
+ DSP_STATUS status = DSP_SOK;
+ struct DSP_UUID pUuid;
+
+ cp_fm_usr(&pUuid, args->ARGS_MGR_REGISTEROBJECT.pUuid, status, 1);
+ if (DSP_FAILED(status))
+ goto func_end;
GT_1trace(WCD_debugMask, GT_ENTER,
"MGRWRAP_UnregisterObject: entered pg2hMsg"
" 0x%x\n", args->ARGS_MGR_UNREGISTEROBJECT.pUuid);
- retVal = DCD_UnregisterObject(WRAP_MAP2CALLER
- (args->ARGS_MGR_UNREGISTEROBJECT.pUuid),
+ status = DCD_UnregisterObject(&pUuid,
args->ARGS_MGR_UNREGISTEROBJECT.objType);
+func_end:
+ return status;
- return retVal;
}
/*
@@ -628,11 +656,15 @@ u32 PROCWRAP_Attach(union Trapped_Args *args)
cp_fm_usr(&attrIn, args->ARGS_PROC_ATTACH.pAttrIn, status, 1);
if (DSP_SUCCEEDED(status))
pAttrIn = &attrIn;
+ else
+ goto func_end;
+
}
status = PROC_Attach(args->ARGS_PROC_ATTACH.uProcessor, pAttrIn,
&processor);
cp_to_usr(args->ARGS_PROC_ATTACH.phProcessor, &processor, status, 1);
+func_end:
return status;
}
@@ -653,16 +685,20 @@ u32 PROCWRAP_Ctrl(union Trapped_Args *args)
args->ARGS_PROC_CTRL.dwCmd,
args->ARGS_PROC_CTRL.pArgs);
if (pSize) {
- if (get_user(cbDataSize, pSize))
+ if (get_user(cbDataSize, pSize)) {
status = DSP_EFAIL;
-
+ goto func_end;
+ }
cbDataSize += sizeof(u32);
if (DSP_SUCCEEDED(status)) {
pArgs = MEM_Alloc(cbDataSize, MEM_NONPAGED);
- if (pArgs == NULL)
+ if (pArgs == NULL) {
status = DSP_EMEMORY;
+ goto func_end;
+ }
+ } else
+ goto func_end;
- }
cp_fm_usr(pArgs, args->ARGS_PROC_CTRL.pArgs, status,
cbDataSize);
}
@@ -675,7 +711,7 @@ u32 PROCWRAP_Ctrl(union Trapped_Args *args)
/* cp_to_usr(args->ARGS_PROC_CTRL.pArgs, pArgs, status, 1);*/
if (pArgs)
MEM_Free(pArgs);
-
+func_end:
return status;
}
@@ -767,7 +803,11 @@ u32 PROCWRAP_InvalidateMemory(union Trapped_Args *args)
*/
u32 PROCWRAP_EnumResources(union Trapped_Args *args)
{
- u32 retVal;
+ DSP_STATUS status = DSP_SOK;
+ struct DSP_RESOURCEINFO pResourceInfo;
+
+ if (DSP_FAILED(status))
+
[PATCH 7/7] DSPBRIDGE: Reset MMU and DSP on board stop
From: Fernando Guzman Lugo This patch resets MMU and DSP by writintg into those registers, this will solve MMU faults occured when the processor is stopped. Signed-off-by: Omar Ramirez Luna Signed-off-by: Fernando Guzman --- drivers/dsp/bridge/wmd/tiomap3430.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c b/drivers/dsp/bridge/wmd/tiomap3430.c index 4919314..b317015 100644 --- a/drivers/dsp/bridge/wmd/tiomap3430.c +++ b/drivers/dsp/bridge/wmd/tiomap3430.c @@ -849,6 +849,9 @@ static DSP_STATUS WMD_BRD_Stop(struct WMD_DEV_CONTEXT *hDevContext) (pPtAttrs->L2NumPages * sizeof(struct PageInfo))); } DBG_Trace(DBG_LEVEL6, "WMD_BRD_Stop - End ** \n"); + HW_RST_Reset(resources.dwPrmBase, HW_RST1_IVA2); + HW_RST_Reset(resources.dwPrmBase, HW_RST2_IVA2); + return status; } @@ -911,7 +914,7 @@ static DSP_STATUS WMD_BRD_Delete(struct WMD_DEV_CONTEXT *hDevContext) memset((u8 *)pPtAttrs->pgInfo, 0x00, (pPtAttrs->L2NumPages * sizeof(struct PageInfo))); } - DBG_Trace(DBG_LEVEL6, "WMD_BRD_Stop - End ** \n"); + DBG_Trace(DBG_LEVEL6, "WMD_BRD_Delete - End ** \n"); HW_RST_Reset(resources.dwPrmBase, HW_RST1_IVA2); HW_RST_Reset(resources.dwPrmBase, HW_RST2_IVA2); -- 1.6.2.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 6/7] DSPBRIDGE: Keep DMM resources for other nodes on PROC_Detach
From: Hari Kanigeri
Removed resource cleanup for DMM on PROC_Detach due to LCML
detaching the processor when it deletes each node, therefore
resource cleanup was freeing DMM resources of other nodes that
might be still in use, this would cause unexpected behavior,
possibly MMU fault.
Signed-of-by: Hari Kanigeri
---
drivers/dsp/bridge/rmgr/proc.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index 43f2d29..f6045bb 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -658,10 +658,8 @@ DSP_STATUS PROC_Detach(DSP_HPROCESSOR hProcessor)
DRV_GetProcContext(hProcess,
(struct DRV_OBJECT *)hDRVObject, &pPctxt,
NULL, 0);
- if (pPctxt != NULL) {
- DRV_ProcFreeDMMRes(pPctxt);
+ if (pPctxt != NULL)
pPctxt->hProcessor = NULL;
- }
}
#endif
/* Notify the Client */
--
1.6.2.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/7] DSPBRIDGE: Removing UTIL module
This module was deprecated, removing its source files.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/util.h | 122 ---
drivers/dsp/bridge/pmgr/cmm.c |2 +-
drivers/dsp/bridge/pmgr/dev.c |1 -
drivers/dsp/bridge/pmgr/wcd.c |1 -
drivers/dsp/bridge/services/clk.c |2 -
drivers/dsp/bridge/services/services.c | 15 +---
drivers/dsp/bridge/wmd/tiomap3430.c |1 -
drivers/dsp/bridge/wmd/tiomap3430_pwr.c |1 -
drivers/dsp/bridge/wmd/tiomap_io.c |1 -
9 files changed, 5 insertions(+), 141 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/dspbridge/util.h
diff --git a/arch/arm/plat-omap/include/dspbridge/util.h
b/arch/arm/plat-omap/include/dspbridge/util.h
deleted file mode 100644
index e6815ca..000
--- a/arch/arm/plat-omap/include/dspbridge/util.h
+++ /dev/null
@@ -1,122 +0,0 @@
-/*
- * util.h
- *
- * DSP-BIOS Bridge driver support functions for TI OMAP processors.
- *
- * Copyright (C) 2005-2006 Texas Instruments, Inc.
- *
- * This package 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.
- *
- * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
- * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- */
-
-
-/*
- * util.h
- * Purpose:
- * Provide general purpose utility functions.
- *
- * Public Functions:
- * UTIL_CDTestDll
- * UTIL_CmdLineToArgs
- * UTIL_Exit
- * UTIL_GetSysInfo
- * UTIL_Init
- */
-
-#ifndef _UTIL_H
-#define _UTIL_H
-
-#include
-#include
-
-#include
-
-/*
- * UTIL_CDTestDll
- * Purpose:
- * Provides test entry point in class driver context.
- * Parameters:
- * cArgc: test module command line input count.
- * ppArgv: test module command line args.
- * Returns:
- * 0 if successful, a negative value otherwise.
- * Requires:
- * UTIL initialized.
- * Ensures:
- */
- extern u32 UTIL_CDTestDll(IN s32 cArgc, IN char **ppArgv);
-
-/*
- * UTIL_CmdLineToArgs
- * Purpose:
- * This function re-creates C-style cmd line argc & argv from WinMain()
- * cmd line args.
- * Parameters:
- * s8 *pszProgName - The name of the program currently being executed.
- * s8 *argv[]- The argument vector.
- * s8 *pCmdLine - The pointer to the command line.
- * bool fHasProgName - Indicats whether a program name is supplied.
- * Returns:
- * Returns the number of arguments found.
- * Requires:
- * UTIL initialized.
- * Ensures:
- */
- extern s32 UTIL_CmdLineToArgs(IN char *pszProgName,
- IN char *argv[UTIL_MAXARGVS],
- IN char *pCmdLine, IN bool fHasProgName);
-
-/*
- * UTIL_Exit
- * Purpose:
- * Discontinue usage of module; free resources when reference count
- * reaches 0.
- * Parameters:
- * Returns:
- * Requires:
- * UTIL initialized.
- * Ensures:
- * Resources used by module are freed when cRef reaches zero.
- */
- extern inline void UTIL_Exit(void)
- {
- }
-/*
- * UTIL_GetSysInfo
- * Purpose:
- * This function return platform specific system information.
- *
- * Parameters:
- * pSysInfo - address to store the system information.
- * Returns:
- * DSP_SOK
- * S_FAIL
- * Requires:
- * UTIL initialized.
- * pSysInfo != NULL
- * Ensures:
- */
- extern DSP_STATUS UTIL_GetSysInfo(OUT struct UTIL_SYSINFO *pSysInfo);
-
-/*
- * UTIL_Init
- * Purpose:
- * Initializes private state of UTIL module.
- * Parameters:
- * Returns:
- * TRUE if success, else FALSE.
- * Requires:
- * Ensures:
- * UTIL initialized.
- */
- extern inline bool UTIL_Init(void)
- {
- return true;
- }
-
-#endif /* _UTIL_H */
diff --git a/drivers/dsp/bridge/pmgr/cmm.c b/drivers/dsp/bridge/pmgr/cmm.c
index 99a2432..9b19be2 100644
--- a/drivers/dsp/bridge/pmgr/cmm.c
+++ b/drivers/dsp/bridge/pmgr/cmm.c
@@ -107,7 +107,7 @@
#include
#include
#include
-#include
+#include
/* --- Platform Manager */
#include
diff --git a/drivers/dsp/bridge/pmgr/dev.c b/drivers/dsp/bridge/pmgr/dev.c
index 1c2f7d5..5e4e30b 100644
--- a/drivers/dsp/bridge/pmgr/dev.c
+++ b/drivers/dsp/bridge/pmgr/dev.c
@@ -130,7 +130,6 @@
#include
#include
#include
-#include
/* --- Platform Manager */
#include
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 859043d..cd84e4e 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++
[PATCH 2/7] DSPBRIDGE: Allow separate load/run addresses for Dynamic Loader
From: Fernando Guzman Lugo
Allow separate load/run addresses for Dynamic Loader.
Signed-off-by: Fernando Guzman Lugo
Signed-off-by: Omar Ramirez Luna
---
drivers/dsp/bridge/pmgr/dbll.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/dbll.c b/drivers/dsp/bridge/pmgr/dbll.c
index 82430a3..5e58e80 100644
--- a/drivers/dsp/bridge/pmgr/dbll.c
+++ b/drivers/dsp/bridge/pmgr/dbll.c
@@ -1313,6 +1313,7 @@ static int rmmAlloc(struct Dynamic_Loader_Allocate *this,
s32 req = -1;
s32 count = 0;
u32 allocSize = 0;
+ u32 runAddrFlag = 0;
DBC_Require(this != NULL);
lib = pAlloc->lib;
@@ -1357,10 +1358,9 @@ static int rmmAlloc(struct Dynamic_Loader_Allocate *this,
if (strcmp(szSecLastToken, "DYN_SARAM") == 0) {
segId = 1;
} else {
- if (strcmp(szSecLastToken,
- "DYN_EXTERNAL") == 0) {
+ if (strcmp(szSecLastToken,
+ "DYN_EXTERNAL") == 0)
segId = 2;
- }
}
}
if (segId != -1) {
@@ -1381,6 +1381,11 @@ func_cont:
allocSize = info->size + GEM_L1P_PREFETCH_SIZE;
else
allocSize = info->size;
+ GT_2trace(DBLL_debugMask, GT_5CLASS,
+"Beg info->run_addr = 0x%x, info->load_addr= 0x%x\n",
+info->run_addr, info->load_addr);
+ if (info->load_addr != info->run_addr)
+ runAddrFlag = 1;
/* TODO - ideally, we can pass the alignment requirement also
* from here */
if (lib != NULL) {
@@ -1393,12 +1398,16 @@ func_cont:
} else {
/* RMM gives word address. Need to convert to byte address */
info->load_addr = rmmAddr.addr * DSPWORDSIZE;
- info->run_addr = info->load_addr;
+ if (!runAddrFlag)
+ info->run_addr = info->load_addr;
info->context = (u32)rmmAddr.segid;
GT_3trace(DBLL_debugMask, GT_5CLASS,
"Remote alloc: %s base = 0x%lx len"
"= 0x%lx\n", info->name, info->load_addr / DSPWORDSIZE,
info->size / DSPWORDSIZE);
+ GT_2trace(DBLL_debugMask, GT_5CLASS,
+"info->run_addr = 0x%x, info->load_addr= 0x%x\n",
+info->run_addr, info->load_addr);
}
return retVal;
}
--
1.6.2.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/7] DSPBRIDGE: latest set of patches
These are the latest set of patches for d.o-z dspbridge. Fernando Guzman Lugo (2): DSPBRIDGE: Allow separate load/run addresses for Dynamic Loader DSPBRIDGE: Reset MMU and DSP on board stop Hari Kanigeri (3): DSPBRIDGE: Handle properly user space pointers DSPBRIDGE: Increased DMM size to 256MB DSPBRIDGE: Keep DMM resources for other nodes on PROC_Detach Omar Ramirez Luna (2): DSPBRIDGE: Removing UTIL module DSPBRIDGE: Shared memory size increased to 5MB arch/arm/plat-omap/include/dspbridge/dmm.h |2 +- arch/arm/plat-omap/include/dspbridge/util.h | 122 -- drivers/dsp/bridge/pmgr/cmm.c |2 +- drivers/dsp/bridge/pmgr/dbll.c | 17 +++- drivers/dsp/bridge/pmgr/dev.c |1 - drivers/dsp/bridge/pmgr/dmm.c |8 +- drivers/dsp/bridge/pmgr/wcd.c | 148 --- drivers/dsp/bridge/rmgr/drv_interface.c |2 +- drivers/dsp/bridge/rmgr/proc.c |4 +- drivers/dsp/bridge/services/clk.c |2 - drivers/dsp/bridge/services/services.c | 15 +-- drivers/dsp/bridge/wmd/tiomap3430.c |6 +- drivers/dsp/bridge/wmd/tiomap3430_pwr.c |1 - drivers/dsp/bridge/wmd/tiomap_io.c |1 - 14 files changed, 138 insertions(+), 193 deletions(-) delete mode 100644 arch/arm/plat-omap/include/dspbridge/util.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
[PATCH 5/7] DSPBRIDGE: Increased DMM size to 256MB
From: Hari Kanigeri
This patch increases the DMM from 64MB to 256MB.
Signed-off-by: Hari Kanigeri
Signed-off-by: Omar Ramirez Luna
---
arch/arm/plat-omap/include/dspbridge/dmm.h |2 +-
drivers/dsp/bridge/pmgr/dmm.c |8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dmm.h
b/arch/arm/plat-omap/include/dspbridge/dmm.h
index ef37668..37f272f 100644
--- a/arch/arm/plat-omap/include/dspbridge/dmm.h
+++ b/arch/arm/plat-omap/include/dspbridge/dmm.h
@@ -41,7 +41,7 @@
u32 reserved;
} ;
-#define DMMPOOLSIZE 0x400
+#define DMMPOOLSIZE 0x1000
/*
* DMM_GetHandle
diff --git a/drivers/dsp/bridge/pmgr/dmm.c b/drivers/dsp/bridge/pmgr/dmm.c
index 803de93..19b8f29 100644
--- a/drivers/dsp/bridge/pmgr/dmm.c
+++ b/drivers/dsp/bridge/pmgr/dmm.c
@@ -103,10 +103,10 @@ static struct GT_Mask DMM_debugMask = { NULL, NULL };
/* GT trace variable */
static u32 cRefs; /* module reference count */
struct MapPage {
- u32 RegionSize:15;
- u32 MappedSize:15;
- u32 bReserved:1;
- u32 bMapped:1;
+ u64 RegionSize:31;
+ u64 MappedSize:31;
+ u64 bReserved:1;
+ u64 bMapped:1;
};
/* Create the free list */
--
1.6.2.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 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously
Hi Kevin, Setting auto voltage scaling with C-states is good idea. AUTO_SLEEP is when you idle with power state set to "ON" - otherwise known as INACTIVE. Sorry for the confusion on the table. I did not show all combinations. You will get 0V in OFF mode with just AUTO_OFF set, the other 2 (AUTO_RET and AUTO_SLEEP don't have to be set but do not hurt if they are set). My point was to show that when MPU and CORE do not have the same power state settings then you need to pay attention to the AUTO voltage settings otherwise you may not get voltage scaling. If MPU and CORE have the same power state then you are OK setting all three (AUTO_OFF, AUTO_RET and AUTO_SLEEP). Regards, David -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, June 16, 2009 12:28 PM To: Derrick, David Cc: Nayak, Rajendra; Högander Jouni; linux-omap@vger.kernel.org; Woodruff, Richard Subject: Re: [PATCH 02/04] OMAP3: PM: Prevent AUTO_RET and AUTO_OFF being enabled simultaneously Hi David, Thanks for the extra clarifications. Is this Table you sent in the TRM somewhere? I don't find it in my ES3.1 NDA TRM ver. P. For the various C-states in CPUidle, we do indeed have various combinations of MPU and CORE state, from cpuidle34xx.c: /* omap3_init_power_states - Initialises the OMAP3 specific C states. * * Below is the desciption of each C state. * C1 . MPU WFI + Core active * C2 . MPU WFI + Core inactive * C3 . MPU CSWR + Core inactive * C4 . MPU OFF + Core inactive * C5 . MPU CSWR + Core CSWR * C6 . MPU OFF + Core CSWR * C7 . MPU OFF + Core OFF */ Maybe the right solution is to have the PRM_VOLTCTRL value associated with the C-state so we minimize the amount of conditional logic we have to do in idle loop itself. Otherwise tracking all these combinations in the idle loop could get ugly. We also don't currently do anything with AUTO_SLEEP, and it looks like we should. But, getting back to the original patch, based on the table you sent, the description in the original patch makes even less sense to me. It says basically that AUTO_RET and AUTO_OFF are mutually exclusive. The table suggests otherwise, and shows that you'll never hit 0V unless both are set. So I still think the original patch description needs an update. Kevin "Derrick, David" writes: > Kevin, > > > > Not sure this change has been done yet. But basically when you have > mis-matched > power states between the MPU and CORE, you may run into a situation where the > voltage does not scale. As long as both MPU and CORE go into the same power > state then there is not a problem. See the following table to better > understand: > > > > > > Table 1. AUTO Voltage Scaling > > ++ > |MPU Power |CORE Power State |AUTO_OFF|AUTO_RETENTION|AUTO_SLEEP >|VDD1|VDD2 | > |State | || | >|| | > |---+-++--+--++--| > | OFF | OFF | 0 |1 | 1 >| 1.0V | 0.9V | > |---+-++--+--++--| > | OFF | OFF | 0 |1 | 0 >| 0.9V | 0.9V | > |---+-++--+--++--| > | OFF | OFF | 1 |1 | 1 >|0V/0.6V*|0V/0.6mV* | > |---+-++--+--++--| > | OFF | OSWR or CSWR | 0 |1 | 1 >| 1.0V | 0.9V | > |---+-++--+--++--| > | OFF | OSWR or CSWR | 0 |1 | 0 >| 0.9V | 0.9V | > |---+-++--+--++--| > | OFF | OSWR or CSWR | 1 |1 | 1 >| 1.2V | 1.15V | > |---+-++--+--++--| > | CSWR | ON (INACTIVE) | 0 |1 | 0 >| 0.9V | 1.15V | > |---+-++--+--++--| > | CSWR | ON (INACTIVE) | 0 |1 | 1 >| 0.9V | 1.0V | > |---+-++--+--
RE: [APPLIED] [PATCH 2/2] OMAP: Zoom2: Fix file system loading issue
>-Original Message- >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: Wednesday, June 17, 2009 10:55 AM >To: Tony Lindgren; Pandita, Vikram >Cc: linux-omap@vger.kernel.org >Subject: Re: [APPLIED] [PATCH 2/2] OMAP: Zoom2: Fix file system loading issue > >Tony Lindgren writes: > >> This patch has been applied to the linux-omap >> by youw fwiendly patch wobot. >> >> Branch in linux-omap: omap-fixes >> >> Initial commit ID (Likely to change): >> f84eca35d44fd64cdde542f12d08eb04ca534954 >> >> PatchWorks >> http://patchwork.kernel.org/patch/29668/ >> >> Git (Likely to change, and takes a while to get mirrored) >> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- >2.6.git;a=commit;h=f84eca35d44fd64cdde542f12d08eb04ca534954 > >Sorry, I didn't get to this beforethe merge, but $SUBJECT for this >patch is wrong and not terribly helpful. It refers to the symptom, bu >tnot the root cause. > >It should be something like: > >OMAP3: Zoom2: pass IRQ triggering flags for serial driver Yes that should have been the subject and is put that way for the 8250 driver: http://lists.arm.linux.org.uk/lurker/attach/1...@20090612.173251.776f9eda.attach It's learning for next time. > >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] SDRC: Remove SDRC_POWER register configuration from SDRC init.
Hello Samu, Artem,
On Wed, 17 Jun 2009, Artem Bityutskiy wrote:
> From: Samu Onkalo
>
> Bootloader must configure proper settings for SDRC before starting
> kernel from SDRAM. Furthermore, removed lines violated omap3430 and
> omap2420 SDRC errata (see errata 1.150)
The 2420 and 3430 errata data here seems to be old; neither one contains
1.150. While I wait for a new version to arrive, can you provide some
more context on this errata? Does it imply any restrictions on
programming SDRC_POWER from SRAM, e.g., the CORE DVFS code?
- Paul
>
> Signed-off-by: Samu Onkalo
> ---
> arch/arm/mach-omap2/sdrc.c | 10 ++
> 1 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
> index 2045441..0874687 100644
> --- a/arch/arm/mach-omap2/sdrc.c
> +++ b/arch/arm/mach-omap2/sdrc.c
> @@ -86,8 +86,8 @@ void __init omap2_set_globals_sdrc(struct omap_globals
> *omap2_globals)
> * @sp: pointer to a null-terminated list of struct omap_sdrc_params
> *
> * Turn on smart idle modes for SDRAM scheduler and controller.
> - * Program a known-good configuration for the SDRC to deal with buggy
> - * bootloaders.
> + * Bootloaders should make proper configuration for SDRC since kernel
> + * is running from SDRAM.
> */
> void __init omap2_sdrc_init(struct omap_sdrc_params *sp)
> {
> @@ -104,10 +104,4 @@ void __init omap2_sdrc_init(struct omap_sdrc_params *sp)
> sdrc_write_reg(l, SDRC_SYSCONFIG);
>
> sdrc_init_params = sp;
> -
> - /* XXX Enable SRFRONIDLEREQ here also? */
> - l = (1 << SDRC_POWER_EXTCLKDIS_SHIFT) |
> - (1 << SDRC_POWER_PWDENA_SHIFT) |
> - (1 << SDRC_POWER_PAGEPOLICY_SHIFT);
> - sdrc_write_reg(l, SDRC_POWER);
> }
> --
> 1.6.0.6
>
> --
> 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
>
- 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
Re: [APPLIED] [PATCH 2/2] OMAP: Zoom2: Fix file system loading issue
Tony Lindgren writes: > This patch has been applied to the linux-omap > by youw fwiendly patch wobot. > > Branch in linux-omap: omap-fixes > > Initial commit ID (Likely to change): f84eca35d44fd64cdde542f12d08eb04ca534954 > > PatchWorks > http://patchwork.kernel.org/patch/29668/ > > Git (Likely to change, and takes a while to get mirrored) > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=f84eca35d44fd64cdde542f12d08eb04ca534954 Sorry, I didn't get to this beforethe merge, but $SUBJECT for this patch is wrong and not terribly helpful. It refers to the symptom, bu tnot the root cause. It should be something like: OMAP3: Zoom2: pass IRQ triggering flags for serial driver 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: [APPLIED] [PATCH 2/2] OMAP: Zoom2: Fix file system loading issue
"Pandita, Vikram" writes: >>This patch has been applied to the linux-omap >>by youw fwiendly patch wobot. >> >>Branch in linux-omap: omap-fixes >> >>Initial commit ID (Likely to change): f84eca35d44fd64cdde542f12d08eb04ca534954 >> >>PatchWorks >>http://patchwork.kernel.org/patch/29668/ > > This patch breaks the zoom2 build. > ... > arch/arm/mach-omap2/board-zoom-debugboard.c:87: error: > 'UPF_IRQ_TRIG_HIGH' undeclared here (not in a function) > make[1]: *** [arch/arm/mach-omap2/board-zoom-debugboard.o] Error 1 > make: *** [arch/arm/mach-omap2] Error 2 > ... > > There is a dependency on 8250 patch: > http://lists.arm.linux.org.uk/lurker/attach/1...@20090612.173251.776f9eda.attach > > > how do you want to address this issue? > Tony, IMO, We should probably stage the 8250 UPF_* change in l-o as well while we wait for the linux-serial lag. 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: [APPLIED] [PATCH 2/2] OMAP: Zoom2: Fix file system loading issue
Tony >-Original Message- >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony >Lindgren >Sent: Wednesday, June 17, 2009 8:57 AM >To: linux-omap@vger.kernel.org >Subject: [APPLIED] [PATCH 2/2] OMAP: Zoom2: Fix file system loading issue > >This patch has been applied to the linux-omap >by youw fwiendly patch wobot. > >Branch in linux-omap: omap-fixes > >Initial commit ID (Likely to change): f84eca35d44fd64cdde542f12d08eb04ca534954 > >PatchWorks >http://patchwork.kernel.org/patch/29668/ This patch breaks the zoom2 build. ... arch/arm/mach-omap2/board-zoom-debugboard.c:87: error: 'UPF_IRQ_TRIG_HIGH' undeclared here (not in a function) make[1]: *** [arch/arm/mach-omap2/board-zoom-debugboard.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 ... There is a dependency on 8250 patch: http://lists.arm.linux.org.uk/lurker/attach/1...@20090612.173251.776f9eda.attach how do you want to address this issue? > >Git (Likely to change, and takes a while to get mirrored) >http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- >2.6.git;a=commit;h=f84eca35d44fd64cdde542f12d08eb04ca534954 > > >-- >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: OMAP3 PM: off-mode during idle, problem with UART1 console
"Woodruff, Richard" writes: > Can you ping the system via network during on time? Yes. > - generate some activity on uart to be awake then try. Yes, ping works before, after and during off-while-idle. > Why not fire up a second tty/shell on UART3 or just try with uart 3 > on SDP. Bootargs change is easy enough. - this can say if you have > uart specific issue or maybe core vs per Indeed, using UART3 on SDP works as expected, only UART 1 has the problem. > Did you hook up your emulator and connect during awake time of uart timer? > It should really tell a lot. Will give that a try. Thanks, Kevin > >> -Original Message- >> From: Nayak, Rajendra >> Sent: Wednesday, June 17, 2009 1:12 AM >> To: Kevin Hilman; Woodruff, Richard >> Cc: linux-omap@vger.kernel.org >> Subject: RE: OMAP3 PM: off-mode during idle, problem with UART1 console >> >> Kevin, >> >> What Silicon Rev does your SDP have? I currently am using an ES3.1 based SDP >> and I havent seen any of these issues you have reported with off-while-idle. >> >> Infact I have kept the board running overnight a couple times in the last >> week >> with off-while-idle and voltage scaling to 0v enabled, mainly to test the >> recent >> patch set (disabling Auto idle for PER in scratchpad memory) for stability. >> >> I will see if I can get hold of an ES3 and ES2.1 based SDP's and see if I >> reproduce >> the issue. Besides I use nfs and I am not sure if that's got something to do >> with it. >> Will try a ramdisk also. >> >> Does it take you a while to reproduce this, or is it seen after the very >> first >> UART >> inactivity? >> >> regards, >> Rajendra >> >> >-Original Message- >> >From: linux-omap-ow...@vger.kernel.org >> >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman >> >Sent: Wednesday, June 17, 2009 2:35 AM >> >To: Nayak, Rajendra; Woodruff, Richard >> >Cc: linux-omap@vger.kernel.org >> >Subject: OMAP3 PM: off-mode during idle, problem with UART1 console >> > >> >Rajendra, Richard, >> > >> >Hoping you can shed some light, or give me some direction on where to >> >debug this further... >> > >> >With the latest PM branch, I've notice that off-while idle isn't >> >working on the SDP, but the same kernel works fine on the RX51. >> >RET-while-idle works fine on both. This is with CPUidle disabled, so >> >just using the default idle where MPU and CORE are changed together. >> > >> >More specifically, it seems to be the UART1 (CORE) console that never >> >comes back from off-while-idle, but the UART3 (PER) console on RX51 >> >works. >> > >> >On SDP, if I >> > >> ># echo 1 > /sys/power/enable_off_mode >> ># echo 1 > /sys/power/voltage_off_while_idle >> ># echo 1 > /sys/power/sleep_while_idle >> > >> >After the UART inactivty timeout of 5 seconds, I start to see the >> >sys_off_mode LED toggling between red and green with system timer >> >wakeups. >> > >> >If I then push a key on the UART1 console, the LED goes green, stays >> >for the 5 second UART inactivity and then goes back to toggling >> >red/green again. However, I never get my console back and never see >> >the characters on my console. >> > >> >If I keep typing, I keep the system from going back off (based on >> >sys_off_mode LED) and as soon as I stop typing long enough for the >> >inactivity timer to expiere (5 seconds) it goes back into off. >> > >> >Any ideas what's going on here? >> > >> >On RX51, the same thing works using UART3. >> > >> >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 >> > >> > -- 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: OMAP3 PM: off-mode during idle, problem with UART1 console
"Nayak, Rajendra" writes: > What Silicon Rev does your SDP have? I currently am using an ES3.1 based SDP > and I havent seen any of these issues you have reported with off-while-idle. I have and ES3.0 SDP. > Infact I have kept the board running overnight a couple times in the last > week > with off-while-idle and voltage scaling to 0v enabled, mainly to test the > recent > patch set (disabling Auto idle for PER in scratchpad memory) for stability. Ah, great. That is really good to know. Are you using omap_3430sdp_pm_defconfig? I see the same problems with and without your patches. > I will see if I can get hold of an ES3 and ES2.1 based SDP's and see if I > reproduce > the issue. Besides I use nfs and I am not sure if that's got something to do > with it. > Will try a ramdisk also. I'm using a ramdisk. > Does it take you a while to reproduce this, or is it seen after the very > first UART > inactivity? It happens on the first try. Could you try my uImage which has my initramfs rootfs built-in on your ES3.1 SDP? http://userweb.kernel.org/~khilman/tmp/rajendra/uImage.pm-vanilla Immediately after booting, I do # echo 1 > /sys/power/enable_off_mode # echo 1 > /sys/power/voltage_off_while_idle # echo 1 > /sys/power/sleep_while_idle and after UART inactivity, I start to see sys_off_mode LED blinking. Kevin >>-Original Message- >>From: linux-omap-ow...@vger.kernel.org >>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman >>Sent: Wednesday, June 17, 2009 2:35 AM >>To: Nayak, Rajendra; Woodruff, Richard >>Cc: linux-omap@vger.kernel.org >>Subject: OMAP3 PM: off-mode during idle, problem with UART1 console >> >>Rajendra, Richard, >> >>Hoping you can shed some light, or give me some direction on where to >>debug this further... >> >>With the latest PM branch, I've notice that off-while idle isn't >>working on the SDP, but the same kernel works fine on the RX51. >>RET-while-idle works fine on both. This is with CPUidle disabled, so >>just using the default idle where MPU and CORE are changed together. >> >>More specifically, it seems to be the UART1 (CORE) console that never >>comes back from off-while-idle, but the UART3 (PER) console on RX51 >>works. >> >>On SDP, if I >> >># echo 1 > /sys/power/enable_off_mode >># echo 1 > /sys/power/voltage_off_while_idle >># echo 1 > /sys/power/sleep_while_idle >> >>After the UART inactivty timeout of 5 seconds, I start to see the >>sys_off_mode LED toggling between red and green with system timer >>wakeups. >> >>If I then push a key on the UART1 console, the LED goes green, stays >>for the 5 second UART inactivity and then goes back to toggling >>red/green again. However, I never get my console back and never see >>the characters on my console. >> >>If I keep typing, I keep the system from going back off (based on >>sys_off_mode LED) and as soon as I stop typing long enough for the >>inactivity timer to expiere (5 seconds) it goes back into off. >> >>Any ideas what's going on here? >> >>On RX51, the same thing works using UART3. >> >>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 >> >> -- 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: Linux OMAP 2.6.30 kernel not booting
>-Original Message- >From: Tony Lindgren [mailto:t...@atomide.com] > >* Pandita, Vikram [090616 15:56]: >> >> >-Original Message- >> >From: Gunasekera, Nipuna >> > >> >Thanks Vikram. I'm able to move further in the booting process using >> >arm-2008q3-72. However, I'm >> >still getting a kernel panic and I'm not sure why. If you or some others >> >have experienced this >> >please let me know. >> >> There are some pending patches that are still under review and not merged >> that are needed for the >zoom2 to work of Linux-omap master. >> >> Linux-Omap pending patches in patchworks: >> MMC mux fix: >> http://patchwork.kernel.org/patch/30445/ >> http://patchwork.kernel.org/patch/30446/ >> Zoom2 T2 enabling: >> http://patchwork.kernel.org/patch/30001/ >> http://patchwork.kernel.org/patch/30002/ >> File system loading issue: >> http://patchwork.kernel.org/patch/29668/ >> >> >> Serial driver pending patch: >> http://lists.arm.linux.org.uk/lurker/attach/1...@20090612.173251.776f9eda.attach >> >> >> I hope all these dependencies will make it soon to their respective trees. > >Also, please check that your .config has CONFIG_REGULATOR enabled and the >associated twl4030 regulator. That is done as part of patches already submitted and waiting for your merge. Zoom2 T2 enabling: http://patchwork.kernel.org/patch/30001/ http://patchwork.kernel.org/patch/30002/ > >Tony -- 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] TWL4030: Reset header file to mainline
On Wed, Jun 17, 2009 at 06:20:24PM +0400, Eugeny S. Mints wrote: > Tony Lindgren wrote: >> Anything touching arch/arm/*omap*. > I'm not sure how many non-omap based boards out there are using twl4030 > chip and if a separate mfd mail list exists. > But until any of the above is true I personally feel that twl4030 > related discussions naturally fall into omap mail list. While the overwhelming majority of TWL4030 specifics will only actually be seen on OMAP systems (so CCing the OMAP list makes sense) the code also exists in the context of the rest of the kernel. It needs review by subsystem maintainers and people working on non-OMAP systems may have useful input based on their general experience of working on simiar parts - in general Linux terms the fact that you've got, for example, a keyboard controller is at least as relevant as the fact that it's likely to be used on an OMAP system. Many subsystems don't have a separate list and just use linux-kernel. -- 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 1/2] watchdog:OMAP3:Register IVA and SECURE WDT, make clks accessible
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Hald, Ulrik Bech
> Sent: Wednesday, June 17, 2009 9:52 AM
> To: Tony Lindgren
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH v3 1/2] watchdog:OMAP3:Register IVA and SECURE WDT,
> make clks accessible
>
> > -Original Message-
> > From: Tony Lindgren [mailto:t...@atomide.com]
> > Sent: Wednesday, June 17, 2009 8:48 AM
> > To: Hald, Ulrik Bech
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: [PATCH v3 1/2] watchdog:OMAP3:Register IVA and SECURE WDT,
> > make clks accessible
> >
> > Hi,
> >
> > * Ulrik Bech Hald [090616 07:20]:
> > > Enabling registration of IVA and SECURE WDT devices. Making
> > > ick and fck for IVA and SECURE WDTs accessible.
> > >
> > > Tested on Zoom1 OMAP3 platform
> > > Signed-off-by: Ulrik Bech Hald
> > > ---
> > > This patch has a dependency on:
> > > compilation: PATCH 1/2] OMAP2/3: SoC IDs: add omap_type() for
> > determining GP/EMU/HS
> > >
> > > arch/arm/mach-omap2/clock34xx.c | 12 +++---
> > > arch/arm/plat-omap/devices.c| 81
> +++-
> > ---
> > > 2 files changed, 71 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
> > omap2/clock34xx.c
> > > index 9e43fe5..933ae9e 100644
> > > --- a/arch/arm/mach-omap2/clock34xx.c
> > > +++ b/arch/arm/mach-omap2/clock34xx.c
> > > @@ -215,11 +215,11 @@ static struct omap_clk omap34xx_clks[] = {
> > > CLK(NULL, "gpt1_fck", &gpt1_fck, CK_343X),
> > > CLK(NULL, "wkup_32k_fck", &wkup_32k_fck, CK_343X),
> > > CLK(NULL, "gpio1_dbck", &gpio1_dbck,CK_343X),
> > > - CLK("omap_wdt", "fck", &wdt2_fck, CK_343X),
> > > + CLK("omap_wdt.2", "fck",&wdt2_fck, CK_343X),
> > > CLK(NULL, "wkup_l4_ick", &wkup_l4_ick, CK_343X),
> > > CLK(NULL, "usim_ick", &usim_ick, CK_3430ES2),
> > > - CLK("omap_wdt", "ick", &wdt2_ick, CK_343X),
> > > - CLK(NULL, "wdt1_ick", &wdt1_ick, CK_343X),
> > > + CLK("omap_wdt.2", "ick",&wdt2_ick, CK_343X),
> > > + CLK("omap_wdt.1", "ick",&wdt1_ick, CK_343X),
> > > CLK(NULL, "gpio1_ick",&gpio1_ick, CK_343X),
> > > CLK(NULL, "omap_32ksync_ick", &omap_32ksync_ick, CK_343X),
> > > CLK(NULL, "gpt12_ick",&gpt12_ick, CK_343X),
> > > @@ -241,14 +241,14 @@ static struct omap_clk omap34xx_clks[] = {
> > > CLK(NULL, "gpio4_dbck", &gpio4_dbck,CK_343X),
> > > CLK(NULL, "gpio3_dbck", &gpio3_dbck,CK_343X),
> > > CLK(NULL, "gpio2_dbck", &gpio2_dbck,CK_343X),
> > > - CLK(NULL, "wdt3_fck", &wdt3_fck, CK_343X),
> > > + CLK("omap_wdt.3", "fck",&wdt3_fck, CK_343X),
> > > CLK(NULL, "per_l4_ick", &per_l4_ick,CK_343X),
> > > CLK(NULL, "gpio6_ick",&gpio6_ick, CK_343X),
> > > CLK(NULL, "gpio5_ick",&gpio5_ick, CK_343X),
> > > CLK(NULL, "gpio4_ick",&gpio4_ick, CK_343X),
> > > CLK(NULL, "gpio3_ick",&gpio3_ick, CK_343X),
> > > CLK(NULL, "gpio2_ick",&gpio2_ick, CK_343X),
> > > - CLK(NULL, "wdt3_ick", &wdt3_ick, CK_343X),
> > > + CLK("omap_wdt.3", "ick",&wdt3_ick, CK_343X),
> > > CLK(NULL, "uart3_ick",&uart3_ick, CK_343X),
> > > CLK(NULL, "gpt9_ick", &gpt9_ick, CK_343X),
> > > CLK(NULL, "gpt8_ick", &gpt8_ick, CK_343X),
> > > @@ -275,7 +275,7 @@ static struct omap_clk omap34xx_clks[] = {
> > > CLK(NULL, "sr_l4_ick",&sr_l4_ick, CK_343X),
> > > CLK(NULL, "secure_32k_fck", &secure_32k_fck, CK_343X),
> > > CLK(NULL, "gpt12_fck",&gpt12_fck, CK_343X),
> > > - CLK(NULL, "wdt1_fck", &wdt1_fck, CK_343X),
> > > + CLK("omap_wdt.1", "fck",&wdt1_fck, CK_343X),
> > > };
> > >
> > > /* CM_AUTOIDLE_PLL*.AUTO_* bit values */
> >
> > To me it looks like you need to make the omap_wdt clock alias rename
> > change also for mach-omap1/clock.c.
> >
> > Regards,
> >
> > Tony
> >
>
> You're right, and it also looks like mach-omap2/clock24xx.c needs the
> alias rename to omap_wdt.1 as well.
And by omap_wdt.1 I really mean omap_wdt.2 (mpu) :)
>
> Thanks for looking at it Tony.
>
> /Ulrik
> >
> > > diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-
> omap/devices.c
> > > old mode 100644
> > > new mode 100755
> > > index a64b692..de5182c
> > > --- a/arch/arm/plat-omap/devices.c
> > > +++ b/arch/arm/plat-omap/devices.c
> > > @@ -288,42 +288,91 @@ static inline void omap_init_uwire(void) {}
> > >
> > > #if defined(CONFIG_OMAP_WATCHDOG) ||
> > defined(CONFIG_OMAP_WATCHDOG_MODULE)
> > >
> > > -static struct resource wdt_resources[] = {
> > > +#define OMAP34XX_WDT1_BASE 0x4830c000
> > > +#define OMAP34XX_WDT2_BASE 0x48314000
> > > +#define
RE: [PATCH v3 1/2] watchdog:OMAP3:Register IVA and SECURE WDT, make clks accessible
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Wednesday, June 17, 2009 8:48 AM
> To: Hald, Ulrik Bech
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH v3 1/2] watchdog:OMAP3:Register IVA and SECURE WDT,
> make clks accessible
>
> Hi,
>
> * Ulrik Bech Hald [090616 07:20]:
> > Enabling registration of IVA and SECURE WDT devices. Making
> > ick and fck for IVA and SECURE WDTs accessible.
> >
> > Tested on Zoom1 OMAP3 platform
> > Signed-off-by: Ulrik Bech Hald
> > ---
> > This patch has a dependency on:
> > compilation: PATCH 1/2] OMAP2/3: SoC IDs: add omap_type() for
> determining GP/EMU/HS
> >
> > arch/arm/mach-omap2/clock34xx.c | 12 +++---
> > arch/arm/plat-omap/devices.c| 81 +++-
> ---
> > 2 files changed, 71 insertions(+), 22 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
> omap2/clock34xx.c
> > index 9e43fe5..933ae9e 100644
> > --- a/arch/arm/mach-omap2/clock34xx.c
> > +++ b/arch/arm/mach-omap2/clock34xx.c
> > @@ -215,11 +215,11 @@ static struct omap_clk omap34xx_clks[] = {
> > CLK(NULL, "gpt1_fck", &gpt1_fck, CK_343X),
> > CLK(NULL, "wkup_32k_fck", &wkup_32k_fck, CK_343X),
> > CLK(NULL, "gpio1_dbck", &gpio1_dbck,CK_343X),
> > - CLK("omap_wdt", "fck", &wdt2_fck, CK_343X),
> > + CLK("omap_wdt.2", "fck",&wdt2_fck, CK_343X),
> > CLK(NULL, "wkup_l4_ick", &wkup_l4_ick, CK_343X),
> > CLK(NULL, "usim_ick", &usim_ick, CK_3430ES2),
> > - CLK("omap_wdt", "ick", &wdt2_ick, CK_343X),
> > - CLK(NULL, "wdt1_ick", &wdt1_ick, CK_343X),
> > + CLK("omap_wdt.2", "ick",&wdt2_ick, CK_343X),
> > + CLK("omap_wdt.1", "ick",&wdt1_ick, CK_343X),
> > CLK(NULL, "gpio1_ick",&gpio1_ick, CK_343X),
> > CLK(NULL, "omap_32ksync_ick", &omap_32ksync_ick, CK_343X),
> > CLK(NULL, "gpt12_ick",&gpt12_ick, CK_343X),
> > @@ -241,14 +241,14 @@ static struct omap_clk omap34xx_clks[] = {
> > CLK(NULL, "gpio4_dbck", &gpio4_dbck,CK_343X),
> > CLK(NULL, "gpio3_dbck", &gpio3_dbck,CK_343X),
> > CLK(NULL, "gpio2_dbck", &gpio2_dbck,CK_343X),
> > - CLK(NULL, "wdt3_fck", &wdt3_fck, CK_343X),
> > + CLK("omap_wdt.3", "fck",&wdt3_fck, CK_343X),
> > CLK(NULL, "per_l4_ick", &per_l4_ick,CK_343X),
> > CLK(NULL, "gpio6_ick",&gpio6_ick, CK_343X),
> > CLK(NULL, "gpio5_ick",&gpio5_ick, CK_343X),
> > CLK(NULL, "gpio4_ick",&gpio4_ick, CK_343X),
> > CLK(NULL, "gpio3_ick",&gpio3_ick, CK_343X),
> > CLK(NULL, "gpio2_ick",&gpio2_ick, CK_343X),
> > - CLK(NULL, "wdt3_ick", &wdt3_ick, CK_343X),
> > + CLK("omap_wdt.3", "ick",&wdt3_ick, CK_343X),
> > CLK(NULL, "uart3_ick",&uart3_ick, CK_343X),
> > CLK(NULL, "gpt9_ick", &gpt9_ick, CK_343X),
> > CLK(NULL, "gpt8_ick", &gpt8_ick, CK_343X),
> > @@ -275,7 +275,7 @@ static struct omap_clk omap34xx_clks[] = {
> > CLK(NULL, "sr_l4_ick",&sr_l4_ick, CK_343X),
> > CLK(NULL, "secure_32k_fck", &secure_32k_fck, CK_343X),
> > CLK(NULL, "gpt12_fck",&gpt12_fck, CK_343X),
> > - CLK(NULL, "wdt1_fck", &wdt1_fck, CK_343X),
> > + CLK("omap_wdt.1", "fck",&wdt1_fck, CK_343X),
> > };
> >
> > /* CM_AUTOIDLE_PLL*.AUTO_* bit values */
>
> To me it looks like you need to make the omap_wdt clock alias rename
> change also for mach-omap1/clock.c.
>
> Regards,
>
> Tony
>
You're right, and it also looks like mach-omap2/clock24xx.c needs the alias
rename to omap_wdt.1 as well.
Thanks for looking at it Tony.
/Ulrik
>
> > diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
> > old mode 100644
> > new mode 100755
> > index a64b692..de5182c
> > --- a/arch/arm/plat-omap/devices.c
> > +++ b/arch/arm/plat-omap/devices.c
> > @@ -288,42 +288,91 @@ static inline void omap_init_uwire(void) {}
> >
> > #ifdefined(CONFIG_OMAP_WATCHDOG) ||
> defined(CONFIG_OMAP_WATCHDOG_MODULE)
> >
> > -static struct resource wdt_resources[] = {
> > +#defineOMAP34XX_WDT1_BASE 0x4830c000
> > +#defineOMAP34XX_WDT2_BASE 0x48314000
> > +#defineOMAP34XX_WDT3_BASE 0x4903
> > +#defineOMAP2430_WDT_BASE 0x49016000
> > +#defineOMAP2420_WDT_BASE 0x48022000
> > +#defineOMAP16XX_WDT_BASE 0xfffeb000
> > +
> > +static struct resource wdt1_resources[] = {
> > {
> > - .flags = IORESOURCE_MEM,
> > + .flags = IORESOURCE_MEM,
> > },
> > };
> >
> > -static struct platform_device omap_wdt_device = {
> > - .name = "omap_wdt",
> > - .id = -1,
> > - .num_resources = ARRAY_SIZ
RE: OMAP3 PM: off-mode during idle, problem with UART1 console
Kevin, Can you ping the system via network during on time? - generate some activity on uart to be awake then try. Why not fire up a second tty/shell on UART3 or just try with uart 3 on SDP. Bootargs change is easy enough. - this can say if you have uart specific issue or maybe core vs per Did you hook up your emulator and connect during awake time of uart timer? It should really tell a lot. Regards, Richard W. > -Original Message- > From: Nayak, Rajendra > Sent: Wednesday, June 17, 2009 1:12 AM > To: Kevin Hilman; Woodruff, Richard > Cc: linux-omap@vger.kernel.org > Subject: RE: OMAP3 PM: off-mode during idle, problem with UART1 console > > Kevin, > > What Silicon Rev does your SDP have? I currently am using an ES3.1 based SDP > and I havent seen any of these issues you have reported with off-while-idle. > > Infact I have kept the board running overnight a couple times in the last week > with off-while-idle and voltage scaling to 0v enabled, mainly to test the > recent > patch set (disabling Auto idle for PER in scratchpad memory) for stability. > > I will see if I can get hold of an ES3 and ES2.1 based SDP's and see if I > reproduce > the issue. Besides I use nfs and I am not sure if that's got something to do > with it. > Will try a ramdisk also. > > Does it take you a while to reproduce this, or is it seen after the very first > UART > inactivity? > > regards, > Rajendra > > >-Original Message- > >From: linux-omap-ow...@vger.kernel.org > >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman > >Sent: Wednesday, June 17, 2009 2:35 AM > >To: Nayak, Rajendra; Woodruff, Richard > >Cc: linux-omap@vger.kernel.org > >Subject: OMAP3 PM: off-mode during idle, problem with UART1 console > > > >Rajendra, Richard, > > > >Hoping you can shed some light, or give me some direction on where to > >debug this further... > > > >With the latest PM branch, I've notice that off-while idle isn't > >working on the SDP, but the same kernel works fine on the RX51. > >RET-while-idle works fine on both. This is with CPUidle disabled, so > >just using the default idle where MPU and CORE are changed together. > > > >More specifically, it seems to be the UART1 (CORE) console that never > >comes back from off-while-idle, but the UART3 (PER) console on RX51 > >works. > > > >On SDP, if I > > > ># echo 1 > /sys/power/enable_off_mode > ># echo 1 > /sys/power/voltage_off_while_idle > ># echo 1 > /sys/power/sleep_while_idle > > > >After the UART inactivty timeout of 5 seconds, I start to see the > >sys_off_mode LED toggling between red and green with system timer > >wakeups. > > > >If I then push a key on the UART1 console, the LED goes green, stays > >for the 5 second UART inactivity and then goes back to toggling > >red/green again. However, I never get my console back and never see > >the characters on my console. > > > >If I keep typing, I keep the system from going back off (based on > >sys_off_mode LED) and as soon as I stop typing long enough for the > >inactivity timer to expiere (5 seconds) it goes back into off. > > > >Any ideas what's going on here? > > > >On RX51, the same thing works using UART3. > > > >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 > > > > -- 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/2] watchdog:OMAP3:Enable support for IVA2 and SECURE
"Hald, Ulrik Bech" writes:
[...]
>>
>> Drop this and just use the inode match.
>>
> Was considering that, but ended up defaulting value instead of error checking
> later. I'll change the above.
>
>> > + /* Find match between device node and wdt device */
>> > + int i;
>> > + for (i = 0; i < NUM_WDTS; i++) {
>> > + if (omap_wdt_dev[i]) {
>> > + wdev = platform_get_drvdata(omap_wdt_dev[i]);
>> > + if (iminor(inode) == wdev->omap_wdt_miscdev.minor)
>> > + break;
>> > + }
>> > + }
>>
>> You should check for a valid match here.
>>
> The sanity check I would choose here is
>
> struct omap_wdt_dev *wdev = NULL;
> ...
>
> ...
> if(!wdev)
> return -ENODEV;
>
Looks fine.
[...]
>>
>> The more think about this, the more I don't like this pdev->id
>> switching in the driver. The only thing it is needed for
>> is to set the name of the node.
>>
>> Instead, why not set the name in devices.c and pass it in
>> using platform_data.
>>
>> Then you can drop the enum and the pdev->id switching.
>>
>
> That does simplify things a bit. Had overlooked that way of sharing info
> between device and driver.
> So, devices.c would have something like:
>
> static struct platform_device omap_secure_wdt_device = {
> .name = "omap_wdt",
> .id = 1,
> .num_resources = ARRAY_SIZE(secure_wdt_resources),
> .resource = secure_wdt_resources,
> .dev = {
> .platform_data = "watchdog_secure",
> },
> };
>
> And omap_wdt.c would have in probe():
>
> wdev->omap_wdt_miscdev.name = (char *) pdev->dev.platform_data;
>
> Is that more like what you had in mind?
>
Exactly.
This is typically done with a platform_data struct, and a pointer to
the struct is passed as the platform_data, but in this case since the
struct would only have one field for the name pointer, this should be
fine.
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] TWL4030: Reset header file to mainline
* Amit Kucheria [090617 07:19]: > On 09 Jun 17, Eugeny S. Mints wrote: > > Amit Kucheria wrote: > >> Reset twl4030.h to what is upstream. Patches to restore twl4030_power > >> functionality will follow directly to lkml. > >> > >> > > development against upstream is great. But what will be left for > > this mail list if we send all patches directly to lkml? > > I think the idea is that (and Tony should correct me here if I'm wrong) > core OMAP code is handled here while peripheral drivers will all go > directly to their respective susbsystem maintainers upstream. Yeah, so for the twl4030 patches that's mostly drivers/mfd. If we pile up things to linux-omap, that code never goes anywhere and keeps piling up! And now for the first time ever, we have pretty much all we need working in the mainline kernel! So that should be the stable base for any distros or prodcuts starting with 2.6.31. Tony -- 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] TWL4030: Reset header file to mainline
Tony Lindgren wrote: * Eugeny S. Mints [090617 06:46]: Amit Kucheria wrote: Reset twl4030.h to what is upstream. Patches to restore twl4030_power functionality will follow directly to lkml. development against upstream is great. But what will be left for this mail list if we send all patches directly to lkml? Anything touching arch/arm/*omap*. I'm not sure how many non-omap based boards out there are using twl4030 chip and if a separate mfd mail list exists. But until any of the above is true I personally feel that twl4030 related discussions naturally fall into omap mail list. Also, while waiting things to get to mainline, we can merge in various topic branches, such as PM, DSS2. So basically linux-omap master branch will shortly be just a queue of things going to the mainline tree while waiting for the next merge window. ok Regards, Tony -- 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] TWL4030: Reset header file to mainline
On 09 Jun 17, Eugeny S. Mints wrote: > Amit Kucheria wrote: >> Reset twl4030.h to what is upstream. Patches to restore twl4030_power >> functionality will follow directly to lkml. >> >> > development against upstream is great. But what will be left for > this mail list if we send all patches directly to lkml? I think the idea is that (and Tony should correct me here if I'm wrong) core OMAP code is handled here while peripheral drivers will all go directly to their respective susbsystem maintainers upstream. -- - Amit Kucheria, Kernel Developer, Verdurent - -- 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/2] watchdog:OMAP3:Enable support for IVA2 and SECURE
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Tuesday, June 16, 2009 10:27 AM
> To: Hald, Ulrik Bech
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH 2/2] watchdog:OMAP3:Enable support for IVA2 and SECURE
>
> Ulrik Bech Hald writes:
>
> > This patch enables the IVA2 and SECURE WDTs in the omap_wdt
> > driver for omap34xx family. SECURE will be available as
> > /dev/watchdog_secure on HS/EMU devices and IVA2 will be available
> > as /dev/watchdog_iva2. MPU will still be available as /dev/watchdog
> >
> > Signed-off-by: Ulrik Bech Hald
> > ---
> > This patch has a dependency on:
> > [PATCH 1/1] watchdog: OMAP fixes: enable clock in probe, trigger timer
> reload
> >
> > drivers/watchdog/omap_wdt.c | 51
> --
> > 1 files changed, 43 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> > index f271385..85a92de 100644
> > --- a/drivers/watchdog/omap_wdt.c
> > +++ b/drivers/watchdog/omap_wdt.c
> > @@ -47,7 +47,15 @@
> >
> > #include "omap_wdt.h"
> >
> > -static struct platform_device *omap_wdt_dev;
> > +#define NUM_WDTS 3
> > +
> > +enum {
> > + SECURE_WDT = 1,
> > + MPU_WDT,
> > + IVA2_WDT,
> > +};
> > +
> > +static struct platform_device *omap_wdt_dev[NUM_WDTS];
>
> If you're going to have shared numbers here, they should be shared and
> also used by the SoC init code. IOW, the id's you're using in the
> devices.c file affects the numbering here.
>
> Also, why not use zero-based numbering here and in devices.c, then
> you can avoide the 'pdev->id - 1' below.
>
> > static unsigned timer_margin;
> > module_param(timer_margin, uint, 0);
> > @@ -139,8 +147,23 @@ static void omap_wdt_set_timeout(struct
> omap_wdt_dev *wdev)
> > */
> > static int omap_wdt_open(struct inode *inode, struct file *file)
> > {
> > - struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
> > - void __iomem *base = wdev->base;
> > + struct omap_wdt_dev *wdev;
> > + void __iomem *base;
> > +
> > + /* by default MPU wdt is present across omap family */
> > + wdev = platform_get_drvdata(omap_wdt_dev[1]);
>
> Drop this and just use the inode match.
>
Was considering that, but ended up defaulting value instead of error checking
later. I'll change the above.
> > + /* Find match between device node and wdt device */
> > + int i;
> > + for (i = 0; i < NUM_WDTS; i++) {
> > + if (omap_wdt_dev[i]) {
> > + wdev = platform_get_drvdata(omap_wdt_dev[i]);
> > + if (iminor(inode) == wdev->omap_wdt_miscdev.minor)
> > + break;
> > + }
> > + }
>
> You should check for a valid match here.
>
The sanity check I would choose here is
struct omap_wdt_dev *wdev = NULL;
...
...
if(!wdev)
return -ENODEV;
> > + base = wdev->base;
> >
> > if (test_and_set_bit(1, (unsigned long *)&(wdev->omap_wdt_users)))
> > return -EBUSY;
> > @@ -271,7 +294,7 @@ static int __devinit omap_wdt_probe(struct
> platform_device *pdev)
> > goto err_get_resource;
> > }
> >
> > - if (omap_wdt_dev) {
> > + if (omap_wdt_dev[pdev->id-1]) {
>
> With zero-based numbering, you can drop the -1.
>
> > ret = -EBUSY;
> > goto err_busy;
> > }
> > @@ -317,10 +340,21 @@ static int __devinit omap_wdt_probe(struct
> platform_device *pdev)
> > omap_wdt_adjust_timeout(timer_margin);
> >
> > wdev->omap_wdt_miscdev.parent = &pdev->dev;
> > - wdev->omap_wdt_miscdev.minor = WATCHDOG_MINOR;
> > - wdev->omap_wdt_miscdev.name = "watchdog";
> > + wdev->omap_wdt_miscdev.minor = MISC_DYNAMIC_MINOR;
> > wdev->omap_wdt_miscdev.fops = &omap_wdt_fops;
> >
> > + switch (pdev->id) {
> > + case SECURE_WDT:
> > + wdev->omap_wdt_miscdev.name = "watchdog_secure";
> > + break;
> > + case IVA2_WDT:
> > + wdev->omap_wdt_miscdev.name = "watchdog_iva2";
> > + break;
> > + case MPU_WDT:
> > + default:
> > + wdev->omap_wdt_miscdev.name = "watchdog";
> > + }
> > +
>
> The more think about this, the more I don't like this pdev->id
> switching in the driver. The only thing it is needed for
> is to set the name of the node.
>
> Instead, why not set the name in devices.c and pass it in
> using platform_data.
>
> Then you can drop the enum and the pdev->id switching.
>
That does simplify things a bit. Had overlooked that way of sharing info
between device and driver.
So, devices.c would have something like:
static struct platform_device omap_secure_wdt_device = {
.name = "omap_wdt",
.id = 1,
.num_resources = ARRAY_SIZE(secure_wdt_resources),
.resource = secure_wdt_resources,
.dev = {
.platform_data = "watchdog_secure",
},
};
And omap_wdt.c would have in probe():
wdev->omap_wdt_miscdev.name = (char *) pdev->dev.platform_data;
Progress in adding ams-delta support to ASoC?
Janusz Krzysztofik wrote: After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason. I finally did what I should have already done before: learned about dynamic debugging, turned it on and probably got the answer from omap_msbsp_dump_reg(): all mcbsp1 register read operations returned 0x. So it looks like I simply get no acccess to mcbsp1 at all. Now I wonder if I can close this thread with a conclusion that mcbsp1 on opam15xx is simply not yet supported by the mainline kernel that I have based my work on. Thanks, Janusz -- 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] TWL4030: Reset header file to mainline
* Eugeny S. Mints [090617 06:46]: > Amit Kucheria wrote: >> Reset twl4030.h to what is upstream. Patches to restore twl4030_power >> functionality will follow directly to lkml. >> >> > development against upstream is great. But what will be left for > this mail list if we send all patches directly to lkml? Anything touching arch/arm/*omap*. Also, while waiting things to get to mainline, we can merge in various topic branches, such as PM, DSS2. So basically linux-omap master branch will shortly be just a queue of things going to the mainline tree while waiting for the next merge window. Regards, Tony -- 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/2] adding back some features
writes: >>> >>> This would be better if it specifically tested for HS and EMU >>> devices. There are at least two other omap_type() possibilities >>> here, "TEST" and "BAD" >> >>Tero, can you please repost? I will hold on sending out the >>omap-fixes for that, and refresh omap-fixes with the updated patch. > > I'll try to look at this tomorrow if I happen to have time, I am > currently quite busy fixing some bugs in our code base. However, if > you need it right now and if someone wants to re-write this to check > against TEST and BAD, I am of course okay with that (rather simple > fix actually.) :) I'll fix this up and resubmit. 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
[APPLIED] [PATCH 2/2] OMAP: Zoom2: Fix file system loading issue
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): f84eca35d44fd64cdde542f12d08eb04ca534954 PatchWorks http://patchwork.kernel.org/patch/29668/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=f84eca35d44fd64cdde542f12d08eb04ca534954 -- 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/2] adding back some features
>-Original Message-
>From: ext Tony Lindgren [mailto:t...@atomide.com]
>Sent: 17 June, 2009 12:58
>To: Paul Walmsley
>Cc: Kristo Tero (Nokia-D/Tampere); Kevin Hilman;
>linux-omap@vger.kernel.org
>Subject: Re: [PATCH 0/2] adding back some features
>
>* Paul Walmsley [090617 01:35]:
>> code comment below:
>>
>> On Wed, 17 Jun 2009, Tony Lindgren wrote:
>>
>> > * Kevin Hilman [090615 09:05]:
>> > > Kevin Hilman writes:
>> > >
>> > > > Tony Lindgren writes:
>> > > >
>> > > >> Hi,
>> > > >>
>> > > >> * Kevin Hilman [090612 15:13]:
>> > > >>> Here's a couple patches to add-back some feature dropped in
>> > > >>> the mainline sync. These are needed for the PM
>branch among other things.
>> > > >>>
>> > > >>> Applies to linux-omap master.
>> > > >>>
>> > > >>> Kevin Hilman (1):
>> > > >>> OMAP2/3: SoC IDs: add omap_type() for determining GP/EMU/HS
>> > > >>
>> > > >> Is there any reason to get this one into mainline early?
>> > > >
>> > > > Well, the PM branch has a dependency, but also the recenetly
>> > > > submitted qwatchdog driver has a dependency.
>> > > >
>> > > >> If not, I suggest you keep this in your pm branch for next
>> > > >> merge window that I can keep merging to l-o master as needed.
>> > > >>
>> > > >> However, if omap_type() is by other queues earlier,
>then I can
>> > > >> add it into my upstream queue. If this blocks several queues
>> > > >> from being rebased against mainline kernel, that alone might
>> > > >> already be a good enough reason to get it in early.
>> > > >
>> > > > I think it should go via your upstream queue. I
>imagine some of
>> > > > the other upcoming driver submissions from TI will have a
>> > > > dependency as well since there is still some missing
>EMU/HS support ind drivers.
>> > >
>> > > Also, I'm carrying this SRAM patch below for HS/EMU that
>could go
>> > > into Paul's SRAM/SDRC queue if this omap_type() gets
>merged sooner
>> > > rather than later.
>> >
>> > Hmm, the HS omap sram.c patch below for sure justifies
>fixing it as
>> > incorrect SRAM size can cause nasty bugs.
>> >
>> > Will add both omap_type and the sram.c patch below to omap-fixes.
>> >
>> > Regards,
>> >
>> > Tony
>> >
>> > > Kevin
>> > >
>> > > commit 106588e30f070d9a8d5906d409e0b9aad89edc9e
>> > > Author: Tero Kristo
>> > > Date: Thu Oct 9 17:47:02 2008 +0300
>> > >
>> > > OMAP3: SRAM size fix for HS/EMU devices
>> > >
>> > > Signed-off-by: Tero Kristo
>> > > Signed-off-by: Kevin Hilman
>> > >
>> > > diff --git a/arch/arm/plat-omap/sram.c
>b/arch/arm/plat-omap/sram.c
>> > > old mode 100644 new mode 100755 index 65006df..f40bd2d
>> > > --- a/arch/arm/plat-omap/sram.c
>> > > +++ b/arch/arm/plat-omap/sram.c
>> > > @@ -131,9 +131,15 @@ void __init omap_detect_sram(void)
>> > > if (cpu_class_is_omap2()) {
>> > > if (is_sram_locked()) {
>> > > if (cpu_is_omap34xx()) {
>> > > -omap_sram_base =
>OMAP3_SRAM_PUB_VA;
>> > > -omap_sram_start =
>OMAP3_SRAM_PUB_PA;
>> > > -omap_sram_size =
>0x8000; /* 32K */
>> > > +if (omap_type() ==
>OMAP2_DEVICE_TYPE_GP) {
>> > > +omap_sram_base
>= OMAP3_SRAM_PUB_VA;
>> > > +omap_sram_start
>= OMAP3_SRAM_PUB_PA;
>> > > +omap_sram_size
>= 0x8000; /* 32K */
>> > > +} else {
>>
>> This would be better if it specifically tested for HS and
>EMU devices.
>> There are at least two other omap_type() possibilities here, "TEST"
>> and "BAD"
>
>Tero, can you please repost? I will hold on sending out the
>omap-fixes for that, and refresh omap-fixes with the updated patch.
I'll try to look at this tomorrow if I happen to have time, I am currently
quite busy fixing some bugs in our code base. However, if you need it right now
and if someone wants to re-write this to check against TEST and BAD, I am of
course okay with that (rather simple fix actually.) :)
-Tero
>
>Tony
>
>
>> > > +omap_sram_base
>= OMAP3_SRAM_PUB_VA;
>> > > +omap_sram_start
>= OMAP3_SRAM_PUB_PA;
>> > > +omap_sram_size
>= 0x7000; /* 28K */
>> > > +}
>> > > } else {
>> > > omap_sram_base =
>OMAP2_SRAM_PUB_VA;
>> > > omap_sram_start =
>OMAP2_SRAM_PUB_PA;
>> > --
>> > 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
>> >
>>
>>
>> - Paul
>--
To unsubscribe from this list: send the line "unsubscribe linux-oma
Re: [PATCH v3 1/2] watchdog:OMAP3:Register IVA and SECURE WDT, make clks accessible
Hi,
* Ulrik Bech Hald [090616 07:20]:
> Enabling registration of IVA and SECURE WDT devices. Making
> ick and fck for IVA and SECURE WDTs accessible.
>
> Tested on Zoom1 OMAP3 platform
> Signed-off-by: Ulrik Bech Hald
> ---
> This patch has a dependency on:
> compilation: PATCH 1/2] OMAP2/3: SoC IDs: add omap_type() for determining
> GP/EMU/HS
>
> arch/arm/mach-omap2/clock34xx.c | 12 +++---
> arch/arm/plat-omap/devices.c| 81
> +++
> 2 files changed, 71 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
> index 9e43fe5..933ae9e 100644
> --- a/arch/arm/mach-omap2/clock34xx.c
> +++ b/arch/arm/mach-omap2/clock34xx.c
> @@ -215,11 +215,11 @@ static struct omap_clk omap34xx_clks[] = {
> CLK(NULL, "gpt1_fck", &gpt1_fck, CK_343X),
> CLK(NULL, "wkup_32k_fck", &wkup_32k_fck, CK_343X),
> CLK(NULL, "gpio1_dbck", &gpio1_dbck,CK_343X),
> - CLK("omap_wdt", "fck", &wdt2_fck, CK_343X),
> + CLK("omap_wdt.2", "fck",&wdt2_fck, CK_343X),
> CLK(NULL, "wkup_l4_ick", &wkup_l4_ick, CK_343X),
> CLK(NULL, "usim_ick", &usim_ick, CK_3430ES2),
> - CLK("omap_wdt", "ick", &wdt2_ick, CK_343X),
> - CLK(NULL, "wdt1_ick", &wdt1_ick, CK_343X),
> + CLK("omap_wdt.2", "ick",&wdt2_ick, CK_343X),
> + CLK("omap_wdt.1", "ick",&wdt1_ick, CK_343X),
> CLK(NULL, "gpio1_ick",&gpio1_ick, CK_343X),
> CLK(NULL, "omap_32ksync_ick", &omap_32ksync_ick, CK_343X),
> CLK(NULL, "gpt12_ick",&gpt12_ick, CK_343X),
> @@ -241,14 +241,14 @@ static struct omap_clk omap34xx_clks[] = {
> CLK(NULL, "gpio4_dbck", &gpio4_dbck,CK_343X),
> CLK(NULL, "gpio3_dbck", &gpio3_dbck,CK_343X),
> CLK(NULL, "gpio2_dbck", &gpio2_dbck,CK_343X),
> - CLK(NULL, "wdt3_fck", &wdt3_fck, CK_343X),
> + CLK("omap_wdt.3", "fck",&wdt3_fck, CK_343X),
> CLK(NULL, "per_l4_ick", &per_l4_ick,CK_343X),
> CLK(NULL, "gpio6_ick",&gpio6_ick, CK_343X),
> CLK(NULL, "gpio5_ick",&gpio5_ick, CK_343X),
> CLK(NULL, "gpio4_ick",&gpio4_ick, CK_343X),
> CLK(NULL, "gpio3_ick",&gpio3_ick, CK_343X),
> CLK(NULL, "gpio2_ick",&gpio2_ick, CK_343X),
> - CLK(NULL, "wdt3_ick", &wdt3_ick, CK_343X),
> + CLK("omap_wdt.3", "ick",&wdt3_ick, CK_343X),
> CLK(NULL, "uart3_ick",&uart3_ick, CK_343X),
> CLK(NULL, "gpt9_ick", &gpt9_ick, CK_343X),
> CLK(NULL, "gpt8_ick", &gpt8_ick, CK_343X),
> @@ -275,7 +275,7 @@ static struct omap_clk omap34xx_clks[] = {
> CLK(NULL, "sr_l4_ick",&sr_l4_ick, CK_343X),
> CLK(NULL, "secure_32k_fck", &secure_32k_fck, CK_343X),
> CLK(NULL, "gpt12_fck",&gpt12_fck, CK_343X),
> - CLK(NULL, "wdt1_fck", &wdt1_fck, CK_343X),
> + CLK("omap_wdt.1", "fck",&wdt1_fck, CK_343X),
> };
>
> /* CM_AUTOIDLE_PLL*.AUTO_* bit values */
To me it looks like you need to make the omap_wdt clock alias rename
change also for mach-omap1/clock.c.
Regards,
Tony
> diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
> old mode 100644
> new mode 100755
> index a64b692..de5182c
> --- a/arch/arm/plat-omap/devices.c
> +++ b/arch/arm/plat-omap/devices.c
> @@ -288,42 +288,91 @@ static inline void omap_init_uwire(void) {}
>
> #if defined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
>
> -static struct resource wdt_resources[] = {
> +#define OMAP34XX_WDT1_BASE 0x4830c000
> +#define OMAP34XX_WDT2_BASE 0x48314000
> +#define OMAP34XX_WDT3_BASE 0x4903
> +#define OMAP2430_WDT_BASE 0x49016000
> +#define OMAP2420_WDT_BASE 0x48022000
> +#define OMAP16XX_WDT_BASE 0xfffeb000
> +
> +static struct resource wdt1_resources[] = {
> {
> - .flags = IORESOURCE_MEM,
> + .flags = IORESOURCE_MEM,
> },
> };
>
> -static struct platform_device omap_wdt_device = {
> - .name = "omap_wdt",
> - .id = -1,
> - .num_resources = ARRAY_SIZE(wdt_resources),
> - .resource = wdt_resources,
> +static struct resource wdt2_resources[] = {
> + {
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +static struct resource wdt3_resources[] = {
> + {
> + .flags = IORESOURCE_MEM,
> + },
> +};
> +
> +/* SECURE WDT */
> +static struct platform_device omap_wdt1_device = {
> + .name = "omap_wdt",
> + .id = 1,
> + .num_resources = ARRAY_SIZE(wdt1_resources),
> + .resource = wdt1_resources,
> +};
> +
> +/* MPU
Re: [PATCH] TWL4030: Reset header file to mainline
Amit Kucheria wrote: Reset twl4030.h to what is upstream. Patches to restore twl4030_power functionality will follow directly to lkml. development against upstream is great. But what will be left for this mail list if we send all patches directly to lkml? Eugeny -- 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] OMAP3: drop SmartReflex base addresses mistakenly added by EHCI patch
* Kevin Hilman [090615 10:12]: > From: Kevin Hilman > > Drop them for now. They will be re-added with the SmartReflex > patches coming from the PM branch, and will use the > L4_34XX_BASE + approach. Felipe, can you please update your ehci-omap branch accordingly? Also, please remove the addition of omap3evm_flash_init() call for board-omap3evm.c in your branch. Thanks, Tony > Signed-off-by: Kevin Hilman > --- > arch/arm/plat-omap/include/mach/omap34xx.h |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/plat-omap/include/mach/omap34xx.h > b/arch/arm/plat-omap/include/mach/omap34xx.h > index 4655707..6a58f3d 100644 > --- a/arch/arm/plat-omap/include/mach/omap34xx.h > +++ b/arch/arm/plat-omap/include/mach/omap34xx.h > @@ -78,8 +78,6 @@ > #define OMAP34XX_UHH_CONFIG_BASE (L4_34XX_BASE + 0x64000) > #define OMAP34XX_OHCI_BASE (L4_34XX_BASE + 0x64400) > #define OMAP34XX_EHCI_BASE (L4_34XX_BASE + 0x64800) > -#define OMAP34XX_SR1_BASE0x480C9000 > -#define OMAP34XX_SR2_BASE0x480CB000 > > #define OMAP34XX_MAILBOX_BASE(L4_34XX_BASE + 0x94000) > > -- > 1.6.2.2 > > -- > 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
[APPLIED] [PATCH] OMAP3: drop SmartReflex base addresses mistakenly added by
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: master Initial commit ID (Likely to change): b380e36df8b03a2c89dfefda8f862aa871b1047a PatchWorks http://patchwork.kernel.org/patch/30380/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b380e36df8b03a2c89dfefda8f862aa871b1047a -- 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] SDRC: Remove SDRC_POWER register configuration from SDRC init.
From: Samu Onkalo
Bootloader must configure proper settings for SDRC before starting
kernel from SDRAM. Furthermore, removed lines violated omap3430 and
omap2420 SDRC errata (see errata 1.150)
Signed-off-by: Samu Onkalo
---
arch/arm/mach-omap2/sdrc.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index 2045441..0874687 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -86,8 +86,8 @@ void __init omap2_set_globals_sdrc(struct omap_globals
*omap2_globals)
* @sp: pointer to a null-terminated list of struct omap_sdrc_params
*
* Turn on smart idle modes for SDRAM scheduler and controller.
- * Program a known-good configuration for the SDRC to deal with buggy
- * bootloaders.
+ * Bootloaders should make proper configuration for SDRC since kernel
+ * is running from SDRAM.
*/
void __init omap2_sdrc_init(struct omap_sdrc_params *sp)
{
@@ -104,10 +104,4 @@ void __init omap2_sdrc_init(struct omap_sdrc_params *sp)
sdrc_write_reg(l, SDRC_SYSCONFIG);
sdrc_init_params = sp;
-
- /* XXX Enable SRFRONIDLEREQ here also? */
- l = (1 << SDRC_POWER_EXTCLKDIS_SHIFT) |
- (1 << SDRC_POWER_PWDENA_SHIFT) |
- (1 << SDRC_POWER_PAGEPOLICY_SHIFT);
- sdrc_write_reg(l, SDRC_POWER);
}
--
1.6.0.6
--
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 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
>-Original Message- >From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com] >Sent: Wednesday, June 17, 2009 6:18 PM >To: Nayak, Rajendra >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard >Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle >before OFF, reduces OFF latency by 20ms > >On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote: >> >> >-Original Message- >> >From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com] >> >Sent: Wednesday, June 17, 2009 3:56 PM >> >To: Nayak, Rajendra >> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard >> >Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle >> >before OFF, reduces OFF latency by 20ms >> > >> >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote: >> >> >-Original Message- >> >> >From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com] >> >> >Sent: Wednesday, June 17, 2009 1:17 PM >> >> >To: Nayak, Rajendra >> >> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard >> >> >Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle >> >> >before OFF, reduces OFF latency by 20ms >> >> > >> >> >Hi Rajendra, >> >> > >> >> >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote: >> >> >> If autoidle for DPLL4 is enabled in the stored scratchpad >> >> >> value of CM_AUTOIDLE_PLL then there is an added delay by >> >> >> the boot ROM when coming out of OFF mode. >> >> >> The patch disables this bitfield in the stored >scratchpad value. >> >> >> >> >> >> This should significantly reduce CORE OFF latency and also >> >> >> bring down the threshold for CORE OFF, making OFF affordable >> >> >> even with smaller sleep times. >> >> > >> >> >I did some measurements on RX-51 with this patch, and it >> >seems it does >> >> >not reduce latency, it increases it by few hundred us. >> >> > >> >> >Servicing an empty timer interrupt from off mode >(measured from VDD1 >> >> >ramp up to start of VDD1 ramp down): >> >> > >> >> >with dpll4 patch : ~14100us >> >> >without patch: ~13600us >> >> > >> >> >I attached pictures of both situations. >> >> > >> >> >My kernel had only C7 state enabled. >> >> > >> >> >Have you measured the latency effects on SDP or some other board? >> >> >> >> I haven't done the latency measurements on SDP yet, but >> >David had done it >> >> sometime back, using a different codebase though. >> > >> >OK, I also used our internal code base. Though the PM >functionality is >> >pretty much the same as in l-o:pm branch. >> > >> >> >> >> Can you explain more on how you are measuring the latency >> >here, I am a bit >> >> confused. This is supposed to bring down the OFF wakeup >> >latency, the sleep latency >> >> remains the same. >> > >> >I'm doing a timer interrupt periodically. Servicing that timer >> >interrupt >> >takes the same amount of time every time. What varies (with >the patch) >> >is the transition times from off to active and back to off. >> > >> >In the pictures the top graph shows current and bottom >graph shows the >> >VDD1 and VDD2 voltages. I zoomed from the pictures the interval from >> >when VDD1 goes up, to the point when it starts to go down again. >> > >> >So I measured: wakeup latency + interrupt service + sleep latency. >> >> Is the boot ROM different on the OMAP devices on nokia h/w or is it >> the same as that on the SDP? > >I have heard that our ROM version would be somehow older version, but I >really don't have any facts on that matter. Oh.. it turns out that when the scratchpad save routine is called, the autoidle for PER is not even set. Its only set some place later. So the 20ms or so advantage was always there on l-o pm branch even without this patch :) > >- Kalle > >> >> > >> >- Kalle >> > >> >> >> >> > >> >> >- Kalle >> >> > >> >> > >> >> >> This patch however does not optimize the C state threshold for >> >> >> CORE OFF states based on the new latency. >> >> >> >> >> >> Signed-off-by: Rajendra Nayak >> >> >> --- >> >> >> arch/arm/mach-omap2/control.c |7 +++ >> >> >> 1 files changed, 7 insertions(+), 0 deletions(-) >> >> >> >> >> >> diff --git a/arch/arm/mach-omap2/control.c >> >> >b/arch/arm/mach-omap2/control.c >> >> >> index c9407c0..a7159a9 100644 >> >> >> --- a/arch/arm/mach-omap2/control.c >> >> >> +++ b/arch/arm/mach-omap2/control.c >> >> >> @@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void) >> >> >>cm_read_mod_reg(PLL_MOD, CM_CLKEN); >> >> >>prcm_block_contents.cm_autoidle_pll = >> >> >>cm_read_mod_reg(PLL_MOD, >> >> >OMAP3430_CM_AUTOIDLE_PLL); >> >> >> + /* >> >> >> + * ROM restore takes 20mS longer if PER idle is enabled >> >> >before OFF. >> >> >> + * Clear feature before sleep. The origional >idle state is >> >> >> + * restored by software as part of wake procedure. >> >> >> + */ >> >> >> + prcm_block_contents.cm_autoidle_pll &= >> >> >~OMAP3430_AUTO_PERIPH_DPLL_MASK; >>
RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
On Wed, 2009-06-17 at 15:38 +0300, Nayak, Rajendra wrote: > > >-Original Message- > >From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com] > >Sent: Wednesday, June 17, 2009 3:56 PM > >To: Nayak, Rajendra > >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard > >Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle > >before OFF, reduces OFF latency by 20ms > > > >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote: > >> >-Original Message- > >> >From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com] > >> >Sent: Wednesday, June 17, 2009 1:17 PM > >> >To: Nayak, Rajendra > >> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard > >> >Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle > >> >before OFF, reduces OFF latency by 20ms > >> > > >> >Hi Rajendra, > >> > > >> >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote: > >> >> If autoidle for DPLL4 is enabled in the stored scratchpad > >> >> value of CM_AUTOIDLE_PLL then there is an added delay by > >> >> the boot ROM when coming out of OFF mode. > >> >> The patch disables this bitfield in the stored scratchpad value. > >> >> > >> >> This should significantly reduce CORE OFF latency and also > >> >> bring down the threshold for CORE OFF, making OFF affordable > >> >> even with smaller sleep times. > >> > > >> >I did some measurements on RX-51 with this patch, and it > >seems it does > >> >not reduce latency, it increases it by few hundred us. > >> > > >> >Servicing an empty timer interrupt from off mode (measured from VDD1 > >> >ramp up to start of VDD1 ramp down): > >> > > >> >with dpll4 patch : ~14100us > >> >without patch: ~13600us > >> > > >> >I attached pictures of both situations. > >> > > >> >My kernel had only C7 state enabled. > >> > > >> >Have you measured the latency effects on SDP or some other board? > >> > >> I haven't done the latency measurements on SDP yet, but > >David had done it > >> sometime back, using a different codebase though. > > > >OK, I also used our internal code base. Though the PM functionality is > >pretty much the same as in l-o:pm branch. > > > >> > >> Can you explain more on how you are measuring the latency > >here, I am a bit > >> confused. This is supposed to bring down the OFF wakeup > >latency, the sleep latency > >> remains the same. > > > >I'm doing a timer interrupt periodically. Servicing that timer > >interrupt > >takes the same amount of time every time. What varies (with the patch) > >is the transition times from off to active and back to off. > > > >In the pictures the top graph shows current and bottom graph shows the > >VDD1 and VDD2 voltages. I zoomed from the pictures the interval from > >when VDD1 goes up, to the point when it starts to go down again. > > > >So I measured: wakeup latency + interrupt service + sleep latency. > > Is the boot ROM different on the OMAP devices on nokia h/w or is it > the same as that on the SDP? I have heard that our ROM version would be somehow older version, but I really don't have any facts on that matter. - Kalle > > > > >- Kalle > > > >> > >> > > >> >- Kalle > >> > > >> > > >> >> This patch however does not optimize the C state threshold for > >> >> CORE OFF states based on the new latency. > >> >> > >> >> Signed-off-by: Rajendra Nayak > >> >> --- > >> >> arch/arm/mach-omap2/control.c |7 +++ > >> >> 1 files changed, 7 insertions(+), 0 deletions(-) > >> >> > >> >> diff --git a/arch/arm/mach-omap2/control.c > >> >b/arch/arm/mach-omap2/control.c > >> >> index c9407c0..a7159a9 100644 > >> >> --- a/arch/arm/mach-omap2/control.c > >> >> +++ b/arch/arm/mach-omap2/control.c > >> >> @@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void) > >> >> cm_read_mod_reg(PLL_MOD, CM_CLKEN); > >> >> prcm_block_contents.cm_autoidle_pll = > >> >> cm_read_mod_reg(PLL_MOD, > >> >OMAP3430_CM_AUTOIDLE_PLL); > >> >> + /* > >> >> +* ROM restore takes 20mS longer if PER idle is enabled > >> >before OFF. > >> >> +* Clear feature before sleep. The origional idle state is > >> >> +* restored by software as part of wake procedure. > >> >> +*/ > >> >> + prcm_block_contents.cm_autoidle_pll &= > >> >~OMAP3430_AUTO_PERIPH_DPLL_MASK; > >> >> + > >> >> prcm_block_contents.cm_clksel1_pll = > >> >> cm_read_mod_reg(PLL_MOD, > >> >OMAP3430_CM_CLKSEL1_PLL); > >> >> prcm_block_contents.cm_clksel2_pll = > >> > > > > > > > -- 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 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
>-Original Message- >From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com] >Sent: Wednesday, June 17, 2009 3:56 PM >To: Nayak, Rajendra >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard >Subject: RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle >before OFF, reduces OFF latency by 20ms > >On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote: >> >-Original Message- >> >From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com] >> >Sent: Wednesday, June 17, 2009 1:17 PM >> >To: Nayak, Rajendra >> >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard >> >Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle >> >before OFF, reduces OFF latency by 20ms >> > >> >Hi Rajendra, >> > >> >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote: >> >> If autoidle for DPLL4 is enabled in the stored scratchpad >> >> value of CM_AUTOIDLE_PLL then there is an added delay by >> >> the boot ROM when coming out of OFF mode. >> >> The patch disables this bitfield in the stored scratchpad value. >> >> >> >> This should significantly reduce CORE OFF latency and also >> >> bring down the threshold for CORE OFF, making OFF affordable >> >> even with smaller sleep times. >> > >> >I did some measurements on RX-51 with this patch, and it >seems it does >> >not reduce latency, it increases it by few hundred us. >> > >> >Servicing an empty timer interrupt from off mode (measured from VDD1 >> >ramp up to start of VDD1 ramp down): >> > >> >with dpll4 patch : ~14100us >> >without patch: ~13600us >> > >> >I attached pictures of both situations. >> > >> >My kernel had only C7 state enabled. >> > >> >Have you measured the latency effects on SDP or some other board? >> >> I haven't done the latency measurements on SDP yet, but >David had done it >> sometime back, using a different codebase though. > >OK, I also used our internal code base. Though the PM functionality is >pretty much the same as in l-o:pm branch. > >> >> Can you explain more on how you are measuring the latency >here, I am a bit >> confused. This is supposed to bring down the OFF wakeup >latency, the sleep latency >> remains the same. > >I'm doing a timer interrupt periodically. Servicing that timer >interrupt >takes the same amount of time every time. What varies (with the patch) >is the transition times from off to active and back to off. > >In the pictures the top graph shows current and bottom graph shows the >VDD1 and VDD2 voltages. I zoomed from the pictures the interval from >when VDD1 goes up, to the point when it starts to go down again. > >So I measured: wakeup latency + interrupt service + sleep latency. Is the boot ROM different on the OMAP devices on nokia h/w or is it the same as that on the SDP? > >- Kalle > >> >> > >> >- Kalle >> > >> > >> >> This patch however does not optimize the C state threshold for >> >> CORE OFF states based on the new latency. >> >> >> >> Signed-off-by: Rajendra Nayak >> >> --- >> >> arch/arm/mach-omap2/control.c |7 +++ >> >> 1 files changed, 7 insertions(+), 0 deletions(-) >> >> >> >> diff --git a/arch/arm/mach-omap2/control.c >> >b/arch/arm/mach-omap2/control.c >> >> index c9407c0..a7159a9 100644 >> >> --- a/arch/arm/mach-omap2/control.c >> >> +++ b/arch/arm/mach-omap2/control.c >> >> @@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void) >> >> cm_read_mod_reg(PLL_MOD, CM_CLKEN); >> >> prcm_block_contents.cm_autoidle_pll = >> >> cm_read_mod_reg(PLL_MOD, >> >OMAP3430_CM_AUTOIDLE_PLL); >> >> + /* >> >> + * ROM restore takes 20mS longer if PER idle is enabled >> >before OFF. >> >> + * Clear feature before sleep. The origional idle state is >> >> + * restored by software as part of wake procedure. >> >> + */ >> >> + prcm_block_contents.cm_autoidle_pll &= >> >~OMAP3430_AUTO_PERIPH_DPLL_MASK; >> >> + >> >> prcm_block_contents.cm_clksel1_pll = >> >> cm_read_mod_reg(PLL_MOD, >> >OMAP3430_CM_CLKSEL1_PLL); >> >> prcm_block_contents.cm_clksel2_pll = >> > > > >-- 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] TWL4030: Reset header file to mainline
* Felipe Balbi [090617 04:43]: > > on subject put REMOVE_OMAP_LEGACY_CODE like all the other related > patches so it's easier to track down which features we're loosing :-p I actually have similar patches here already for all the I2C stuff and the remaining twl4030 stuff.. Will push today. Tony -- 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] TWL4030: Reset header file to mainline
on subject put REMOVE_OMAP_LEGACY_CODE like all the other related patches so it's easier to track down which features we're loosing :-p -- 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
[PATCH] TWL4030: Reset header file to mainline
Reset twl4030.h to what is upstream. Patches to restore twl4030_power
functionality will follow directly to lkml.
Compile-tested only.
Signed-off-by: Amit Kucheria
---
include/linux/i2c/twl4030.h | 78 +++---
1 files changed, 6 insertions(+), 72 deletions(-)
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index 87accda..0dc80ef 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -243,37 +243,6 @@ int twl4030_i2c_read(u8 mod_no, u8 *value, u8 reg,
unsigned num_bytes);
#define RES_STATE_SLEEP0x8
#define RES_STATE_OFF 0x0
-/* Power resources */
-
-#define RES_VAUX1 1
-#define RES_VAUX2 2
-#define RES_VAUX3 3
-#define RES_VAUX4 4
-#define RES_VMMC1 5
-#define RES_VMMC2 6
-#define RES_VPLL1 7
-#define RES_VPLL2 8
-#define RES_VSIM9
-#define RES_VDAC10
-#define RES_VINTANA111
-#define RES_VINTANA212
-#define RES_VINTDIG 13
-#define RES_VIO 14
-#define RES_VDD115
-#define RES_VDD216
-#define RES_VUSB_1V517
-#define RES_VUSB_1V818
-#define RES_VUSB_3V119
-#define RES_VUSBCP 20
-#define RES_REGEN 21
-#define RES_NRES_PWRON 22
-#define RES_CLKEN 23
-#define RES_SYSEN 24
-#define RES_HFCLKOUT25
-#define RES_32KCLKOUT 26
-#define RES_RESET 27
-#define RES_Main_Ref28
-
/*
* Power Bus Message Format ... these can be sent individually by Linux,
* but are usually part of downloaded scripts that are run when various
@@ -333,19 +302,12 @@ struct twl4030_madc_platform_data {
int irq_line;
};
-/* Boards have uniqe mappings of {col, row} --> keycode.
- * Column and row are 4 bits, but range only from 0..7;
- * a PERSISTENT_KEY is "always on" and never reported.
- */
-#define KEY_PERSISTENT 0x0080
-#define KEY(col, row, keycode) (((col) << 28) | ((row) << 24) | (keycode))
-#define PERSISTENT_KEY(c, r) KEY(c, r, KEY_PERSISTENT)
-
struct twl4030_keypad_data {
- unsigned rows;
- unsigned cols;
- unsigned *keymap;
- unsigned short keymapsize;
+ int rows;
+ int cols;
+ int *keymap;
+ int irq;
+ unsigned int keymapsize;
unsigned int rep:1;
};
@@ -358,34 +320,6 @@ struct twl4030_usb_data {
enum twl4030_usb_mode usb_mode;
};
-struct twl4030_ins {
- u16 pmb_message;
- u8 delay;
-};
-
-struct twl4030_script {
- struct twl4030_ins *script;
- unsigned size;
- u8 flags;
-#define TRITON_WRST_SCRIPT (1<<0)
-#define TRITON_WAKEUP12_SCRIPT (1<<1)
-#define TRITON_WAKEUP3_SCRIPT (1<<2)
-#define TRITON_SLEEP_SCRIPT(1<<3)
-};
-
-struct twl4030_resconfig {
- u8 resource;
- u8 devgroup;
- u8 type;
- u8 type2;
-};
-
-struct twl4030_power_data {
- struct twl4030_script **scripts;
- unsigned size;
- const struct twl4030_resconfig *resource_config;
-};
-
struct twl4030_platform_data {
unsignedirq_base, irq_end;
struct twl4030_bci_platform_data*bci;
@@ -393,7 +327,6 @@ struct twl4030_platform_data {
struct twl4030_madc_platform_data *madc;
struct twl4030_keypad_data *keypad;
struct twl4030_usb_data *usb;
- struct twl4030_power_data *power;
/* LDO regulators */
struct regulator_init_data *vdac;
@@ -424,6 +357,7 @@ int twl4030_sih_setup(int module);
#define TWL4030_VAUX3_DEV_GRP 0x1F
#define TWL4030_VAUX3_DEDICATED0x22
+
#if defined(CONFIG_TWL4030_BCI_BATTERY) || \
defined(CONFIG_TWL4030_BCI_BATTERY_MODULE)
extern int twl4030charger_usb_en(int enable);
--
1.6.3.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: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
On Wed, 2009-06-17 at 12:50 +0300, Nayak, Rajendra wrote: > >-Original Message- > >From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com] > >Sent: Wednesday, June 17, 2009 1:17 PM > >To: Nayak, Rajendra > >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard > >Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle > >before OFF, reduces OFF latency by 20ms > > > >Hi Rajendra, > > > >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote: > >> If autoidle for DPLL4 is enabled in the stored scratchpad > >> value of CM_AUTOIDLE_PLL then there is an added delay by > >> the boot ROM when coming out of OFF mode. > >> The patch disables this bitfield in the stored scratchpad value. > >> > >> This should significantly reduce CORE OFF latency and also > >> bring down the threshold for CORE OFF, making OFF affordable > >> even with smaller sleep times. > > > >I did some measurements on RX-51 with this patch, and it seems it does > >not reduce latency, it increases it by few hundred us. > > > >Servicing an empty timer interrupt from off mode (measured from VDD1 > >ramp up to start of VDD1 ramp down): > > > >with dpll4 patch : ~14100us > >without patch: ~13600us > > > >I attached pictures of both situations. > > > >My kernel had only C7 state enabled. > > > >Have you measured the latency effects on SDP or some other board? > > I haven't done the latency measurements on SDP yet, but David had done it > sometime back, using a different codebase though. OK, I also used our internal code base. Though the PM functionality is pretty much the same as in l-o:pm branch. > > Can you explain more on how you are measuring the latency here, I am a bit > confused. This is supposed to bring down the OFF wakeup latency, the sleep > latency > remains the same. I'm doing a timer interrupt periodically. Servicing that timer interrupt takes the same amount of time every time. What varies (with the patch) is the transition times from off to active and back to off. In the pictures the top graph shows current and bottom graph shows the VDD1 and VDD2 voltages. I zoomed from the pictures the interval from when VDD1 goes up, to the point when it starts to go down again. So I measured: wakeup latency + interrupt service + sleep latency. - Kalle > > > > >- Kalle > > > > > >> This patch however does not optimize the C state threshold for > >> CORE OFF states based on the new latency. > >> > >> Signed-off-by: Rajendra Nayak > >> --- > >> arch/arm/mach-omap2/control.c |7 +++ > >> 1 files changed, 7 insertions(+), 0 deletions(-) > >> > >> diff --git a/arch/arm/mach-omap2/control.c > >b/arch/arm/mach-omap2/control.c > >> index c9407c0..a7159a9 100644 > >> --- a/arch/arm/mach-omap2/control.c > >> +++ b/arch/arm/mach-omap2/control.c > >> @@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void) > >>cm_read_mod_reg(PLL_MOD, CM_CLKEN); > >>prcm_block_contents.cm_autoidle_pll = > >>cm_read_mod_reg(PLL_MOD, > >OMAP3430_CM_AUTOIDLE_PLL); > >> + /* > >> + * ROM restore takes 20mS longer if PER idle is enabled > >before OFF. > >> + * Clear feature before sleep. The origional idle state is > >> + * restored by software as part of wake procedure. > >> + */ > >> + prcm_block_contents.cm_autoidle_pll &= > >~OMAP3430_AUTO_PERIPH_DPLL_MASK; > >> + > >>prcm_block_contents.cm_clksel1_pll = > >>cm_read_mod_reg(PLL_MOD, > >OMAP3430_CM_CLKSEL1_PLL); > >>prcm_block_contents.cm_clksel2_pll = > > -- 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: [PULL REQUEST] omapfb: Add support for new LCDs / misc fixes
On Tue, Jun 16, 2009 at 06:58:25PM +0200, ext Krzysztof Helt wrote: > On Thu, 11 Jun 2009 15:02:06 +0300 > Imre Deak wrote: > > > Hi, > > > > the following pull request is for the patchset updated based on your > > comments: > > > > The following changes since commit 07a2039b8eb0af4ff464efd3dfd95de5c02648c6: > > Linus Torvalds (1): > > Linux 2.6.30 > > > > are available in the git repository at: > > > > git://koowaldah.org/people/imre/linux-2.6-fb master > > > > Daniel Stone (1): > > omapfb: dispc: Allow multiple external IRQ handlers > > > > Hunyue Yau (1): > > omapfb: Add support for the 2430SDP LCD > > > > Imre Deak (5): > > omapfb: Add support for MIPI-DCS compatible LCDs > > N770: Enable LCD MIPI-DCS in Kconfig > > omapfb: dispc: Various typo fixes > > omapfb: Add FB manual update option to Kconfig > > omapfb: HWA742: fix pointer to be const > > > > Jonathan McDowell (1): > > omapfb: Add support for the Amstrad Delta LCD > > > > Jouni Hogander (2): > > omapfb: dispc: Disable iface clocks along with func clocks > > omapfb: dispc: Enable wake up capability > > > > Jouni Högander (1): > > omapfb: suspend/resume only if FB device is already initialized > > > > Kevin Hilman (1): > > omapfb: Add support for the 3430SDP LCD > > > > Koen Kooi (1): > > omapfb: Add support for the OMAP3 Beagle DVI output > > > > Kyungmin Park (1): > > omapfb: Add support for the Apollon LCD > > > > Rodrigo Vivi (1): > > omapfb: Add support for rotation on the Blizzard LCD ctrl > > > > Stanley.Miao (1): > > omapfb: Add support for the ZOOM MDK LCD > > > > Steve Sakoman (2): > > omapfb: Add support for the OMAP3 EVM LCD > > omapfb: Add support for the Gumstix Overo LCD > > > > arun c (2): > > omapfb: Add support for the OMAP2EVM LCD > > omapfb: Fix coding style / remove dead line > > > > arch/arm/configs/n770_defconfig |2 +- > > arch/arm/configs/omap3_beagle_defconfig | 47 ++- > > arch/arm/configs/omap_3430sdp_defconfig | 39 ++- > > arch/arm/configs/omap_ldp_defconfig | 54 +++- > > arch/arm/plat-omap/include/mach/lcd_mipid.h |5 + > > arch/arm/plat-omap/include/mach/omapfb.h|4 +- > > drivers/video/omap/Kconfig | 82 +++- > > drivers/video/omap/Makefile | 12 + > > drivers/video/omap/blizzard.c | 91 - > > drivers/video/omap/dispc.c | 130 --- > > drivers/video/omap/dispc.h |7 +- > > drivers/video/omap/hwa742.c |2 +- > > drivers/video/omap/lcd_2430sdp.c| 200 + > > drivers/video/omap/lcd_ams_delta.c | 137 ++ > > drivers/video/omap/lcd_apollon.c| 138 ++ > > drivers/video/omap/lcd_ldp.c| 200 + > > drivers/video/omap/lcd_mipid.c | 625 > > +++ > > drivers/video/omap/lcd_omap2evm.c | 189 > > drivers/video/omap/lcd_omap3beagle.c| 133 ++ > > drivers/video/omap/lcd_omap3evm.c | 191 > > drivers/video/omap/lcd_overo.c | 179 > > drivers/video/omap/omapfb_main.c| 64 ++- > > drivers/video/omap/rfbi.c |7 +- > > 23 files changed, 2424 insertions(+), 114 deletions(-) > > create mode 100644 drivers/video/omap/lcd_2430sdp.c > > create mode 100644 drivers/video/omap/lcd_ams_delta.c > > create mode 100644 drivers/video/omap/lcd_apollon.c > > create mode 100644 drivers/video/omap/lcd_ldp.c > > create mode 100644 drivers/video/omap/lcd_mipid.c > > create mode 100644 drivers/video/omap/lcd_omap2evm.c > > create mode 100644 drivers/video/omap/lcd_omap3beagle.c > > create mode 100644 drivers/video/omap/lcd_omap3evm.c > > create mode 100644 drivers/video/omap/lcd_overo.c > > > > I assume you introduced small changes after my review. > > For the whole patchset: > > Acked-by: Krzysztof Helt Yes, I've updated the patchset based on our discussion. I've also added your acked-by line. --Imre -- 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] i2c-omap: Fix build breaking typo cpu_is_omap_2430
Hi Ben, Can you please queue this fix? Thanks, Tony >From ffe2b2cdf6283770b70a197e3748c6b40a1006be Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Wed, 17 Jun 2009 13:14:23 +0300 Subject: [PATCH] i2c-omap: Fix build breaking typo in cpu_is_omap_2430 Commit 84bf2c86 introduced a typo, it should be cpu_is_omap2430 instead. The typo was probably caused by a mismerge. Without this patch all omaps fail to build with: error: implicit declaration of function 'cpu_is_omap_2430' Signed-off-by: Tony Lindgren diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index b606db8..ad8d201 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -339,7 +339,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) * to get longer filter period for better noise suppression. * The filter is iclk (fclk for HS) period. */ - if (dev->speed > 400 || cpu_is_omap_2430()) + if (dev->speed > 400 || cpu_is_omap2430()) internal_clk = 19200; else if (dev->speed > 100) internal_clk = 9600;
Re: [PATCH 0/2] adding back some features
* Paul Walmsley [090617 01:35]:
> code comment below:
>
> On Wed, 17 Jun 2009, Tony Lindgren wrote:
>
> > * Kevin Hilman [090615 09:05]:
> > > Kevin Hilman writes:
> > >
> > > > Tony Lindgren writes:
> > > >
> > > >> Hi,
> > > >>
> > > >> * Kevin Hilman [090612 15:13]:
> > > >>> Here's a couple patches to add-back some feature dropped in the
> > > >>> mainline sync. These are needed for the PM branch among other things.
> > > >>>
> > > >>> Applies to linux-omap master.
> > > >>>
> > > >>> Kevin Hilman (1):
> > > >>> OMAP2/3: SoC IDs: add omap_type() for determining GP/EMU/HS
> > > >>
> > > >> Is there any reason to get this one into mainline early?
> > > >
> > > > Well, the PM branch has a dependency, but also the recenetly submitted
> > > > qwatchdog driver has a dependency.
> > > >
> > > >> If not, I suggest you keep this in your pm branch for next merge
> > > >> window that I can keep merging to l-o master as needed.
> > > >>
> > > >> However, if omap_type() is by other queues earlier, then I can
> > > >> add it into my upstream queue. If this blocks several queues
> > > >> from being rebased against mainline kernel, that alone might
> > > >> already be a good enough reason to get it in early.
> > > >
> > > > I think it should go via your upstream queue. I imagine some of the
> > > > other upcoming driver submissions from TI will have a dependency as
> > > > well since there is still some missing EMU/HS support ind drivers.
> > >
> > > Also, I'm carrying this SRAM patch below for HS/EMU that could go into
> > > Paul's SRAM/SDRC queue if this omap_type() gets merged sooner rather
> > > than later.
> >
> > Hmm, the HS omap sram.c patch below for sure justifies fixing it as
> > incorrect SRAM size can cause nasty bugs.
> >
> > Will add both omap_type and the sram.c patch below to omap-fixes.
> >
> > Regards,
> >
> > Tony
> >
> > > Kevin
> > >
> > > commit 106588e30f070d9a8d5906d409e0b9aad89edc9e
> > > Author: Tero Kristo
> > > Date: Thu Oct 9 17:47:02 2008 +0300
> > >
> > > OMAP3: SRAM size fix for HS/EMU devices
> > >
> > > Signed-off-by: Tero Kristo
> > > Signed-off-by: Kevin Hilman
> > >
> > > diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> > > old mode 100644
> > > new mode 100755
> > > index 65006df..f40bd2d
> > > --- a/arch/arm/plat-omap/sram.c
> > > +++ b/arch/arm/plat-omap/sram.c
> > > @@ -131,9 +131,15 @@ void __init omap_detect_sram(void)
> > > if (cpu_class_is_omap2()) {
> > > if (is_sram_locked()) {
> > > if (cpu_is_omap34xx()) {
> > > - omap_sram_base = OMAP3_SRAM_PUB_VA;
> > > - omap_sram_start = OMAP3_SRAM_PUB_PA;
> > > - omap_sram_size = 0x8000; /* 32K */
> > > + if (omap_type() == OMAP2_DEVICE_TYPE_GP) {
> > > + omap_sram_base = OMAP3_SRAM_PUB_VA;
> > > + omap_sram_start = OMAP3_SRAM_PUB_PA;
> > > + omap_sram_size = 0x8000; /* 32K */
> > > + } else {
>
> This would be better if it specifically tested for HS and EMU devices.
> There are at least two other omap_type() possibilities here, "TEST" and
> "BAD"
Tero, can you please repost? I will hold on sending out the omap-fixes
for that, and refresh omap-fixes with the updated patch.
Tony
> > > + omap_sram_base = OMAP3_SRAM_PUB_VA;
> > > + omap_sram_start = OMAP3_SRAM_PUB_PA;
> > > + omap_sram_size = 0x7000; /* 28K */
> > > + }
> > > } else {
> > > omap_sram_base = OMAP2_SRAM_PUB_VA;
> > > omap_sram_start = OMAP2_SRAM_PUB_PA;
> > --
> > 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
> >
>
>
> - 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
RE: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
>-Original Message- >From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com] >Sent: Wednesday, June 17, 2009 1:17 PM >To: Nayak, Rajendra >Cc: linux-omap@vger.kernel.org; Derrick, David; Woodruff, Richard >Subject: Re: [PATCH 01/04] OMAP3: PM: Disable PER DPLL idle >before OFF, reduces OFF latency by 20ms > >Hi Rajendra, > >On Tue, 2009-06-16 at 14:52 +0300, Rajendra Nayak wrote: >> If autoidle for DPLL4 is enabled in the stored scratchpad >> value of CM_AUTOIDLE_PLL then there is an added delay by >> the boot ROM when coming out of OFF mode. >> The patch disables this bitfield in the stored scratchpad value. >> >> This should significantly reduce CORE OFF latency and also >> bring down the threshold for CORE OFF, making OFF affordable >> even with smaller sleep times. > >I did some measurements on RX-51 with this patch, and it seems it does >not reduce latency, it increases it by few hundred us. > >Servicing an empty timer interrupt from off mode (measured from VDD1 >ramp up to start of VDD1 ramp down): > >with dpll4 patch : ~14100us >without patch: ~13600us > >I attached pictures of both situations. > >My kernel had only C7 state enabled. > >Have you measured the latency effects on SDP or some other board? I haven't done the latency measurements on SDP yet, but David had done it sometime back, using a different codebase though. Can you explain more on how you are measuring the latency here, I am a bit confused. This is supposed to bring down the OFF wakeup latency, the sleep latency remains the same. > >- Kalle > > >> This patch however does not optimize the C state threshold for >> CORE OFF states based on the new latency. >> >> Signed-off-by: Rajendra Nayak >> --- >> arch/arm/mach-omap2/control.c |7 +++ >> 1 files changed, 7 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/control.c >b/arch/arm/mach-omap2/control.c >> index c9407c0..a7159a9 100644 >> --- a/arch/arm/mach-omap2/control.c >> +++ b/arch/arm/mach-omap2/control.c >> @@ -238,6 +238,13 @@ void omap3_save_scratchpad_contents(void) >> cm_read_mod_reg(PLL_MOD, CM_CLKEN); >> prcm_block_contents.cm_autoidle_pll = >> cm_read_mod_reg(PLL_MOD, >OMAP3430_CM_AUTOIDLE_PLL); >> +/* >> + * ROM restore takes 20mS longer if PER idle is enabled >before OFF. >> + * Clear feature before sleep. The origional idle state is >> + * restored by software as part of wake procedure. >> + */ >> +prcm_block_contents.cm_autoidle_pll &= >~OMAP3430_AUTO_PERIPH_DPLL_MASK; >> + >> prcm_block_contents.cm_clksel1_pll = >> cm_read_mod_reg(PLL_MOD, >OMAP3430_CM_CLKSEL1_PLL); >> prcm_block_contents.cm_clksel2_pll = >-- 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
[APPLIED] [PATCH 1/1] IOMMU: function flush_iotlb_page is not flushing
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): aef217b87726a17282c975e9281e9f698ff2b8e6 PatchWorks http://patchwork.kernel.org/patch/30288/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=aef217b87726a17282c975e9281e9f698ff2b8e6 -- 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
[APPLIED] [PATCH 1/1] omap mailbox: platform_get_irq() error ignored
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 20514e5b5c3e86d58fb1825c8f89e18c3bcc61a7 PatchWorks http://patchwork.kernel.org/patch/30287/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=20514e5b5c3e86d58fb1825c8f89e18c3bcc61a7 -- 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
[APPLIED] [PATCH 3/4] ARM: OMAP1: remove duplicated #include
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 93bfbbdfcbe2ad9758eb78ddc3da1d46c7c5597a PatchWorks http://patchwork.kernel.org/patch/30575/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=93bfbbdfcbe2ad9758eb78ddc3da1d46c7c5597a -- 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] Remove duplicate definitions
* Tony Lindgren [090617 01:52]:
> * Sanjeev Premi [090616 04:15]:
> > Fixes the duplicate definitions of KEY and PERSISTENT_KEY
> > leading to these compile-time warnings:
> >
> > In file included from arch/arm/mach-omap2/board-omap3evm.c:39:
> > arch/arm/plat-omap/include/mach/keypad.h:38:1: warning: "KEY" redefined
> > In file included from arch/arm/mach-omap2/board-omap3evm.c:27:
> > include/linux/i2c/twl4030.h:341:1: warning: this is the location of the
> > previous definition
> > In file included from arch/arm/mach-omap2/board-omap3evm.c:39:
> > arch/arm/plat-omap/include/mach/keypad.h:39:1: warning: "PERSISTENT_KEY"
> > redefined
> > In file included from arch/arm/mach-omap2/board-omap3evm.c:27:
> > include/linux/i2c/twl4030.h:342:1: warning: this is the location of the
> > previous definition
>
> Hmm, I think we should rather remove these from keypad.h. Will queue
> a patch into omap-fixes for that.
Sorry, you're right, looks like we have still non-standard headers
for I2C. Will reset those in linux-omap tree.
> Tony
>
> > Signed-off-by: Sanjeev Premi
> > ---
> > include/linux/i2c/twl4030.h |8
> > 1 files changed, 0 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
> > index 87accda..21e65bf 100644
> > --- a/include/linux/i2c/twl4030.h
> > +++ b/include/linux/i2c/twl4030.h
> > @@ -333,14 +333,6 @@ struct twl4030_madc_platform_data {
> > int irq_line;
> > };
> >
> > -/* Boards have uniqe mappings of {col, row} --> keycode.
> > - * Column and row are 4 bits, but range only from 0..7;
> > - * a PERSISTENT_KEY is "always on" and never reported.
> > - */
> > -#define KEY_PERSISTENT 0x0080
> > -#define KEY(col, row, keycode) (((col) << 28) | ((row) << 24) |
> > (keycode))
> > -#define PERSISTENT_KEY(c, r) KEY(c, r, KEY_PERSISTENT)
> > -
> > struct twl4030_keypad_data {
> > unsigned rows;
> > unsigned cols;
> > --
> > 1.6.2.2
> >
> > --
> > 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
--
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] Remove duplicate definitions
* Sanjeev Premi [090616 04:15]:
> Fixes the duplicate definitions of KEY and PERSISTENT_KEY
> leading to these compile-time warnings:
>
> In file included from arch/arm/mach-omap2/board-omap3evm.c:39:
> arch/arm/plat-omap/include/mach/keypad.h:38:1: warning: "KEY" redefined
> In file included from arch/arm/mach-omap2/board-omap3evm.c:27:
> include/linux/i2c/twl4030.h:341:1: warning: this is the location of the
> previous definition
> In file included from arch/arm/mach-omap2/board-omap3evm.c:39:
> arch/arm/plat-omap/include/mach/keypad.h:39:1: warning: "PERSISTENT_KEY"
> redefined
> In file included from arch/arm/mach-omap2/board-omap3evm.c:27:
> include/linux/i2c/twl4030.h:342:1: warning: this is the location of the
> previous definition
Hmm, I think we should rather remove these from keypad.h. Will queue
a patch into omap-fixes for that.
Tony
> Signed-off-by: Sanjeev Premi
> ---
> include/linux/i2c/twl4030.h |8
> 1 files changed, 0 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
> index 87accda..21e65bf 100644
> --- a/include/linux/i2c/twl4030.h
> +++ b/include/linux/i2c/twl4030.h
> @@ -333,14 +333,6 @@ struct twl4030_madc_platform_data {
> int irq_line;
> };
>
> -/* Boards have uniqe mappings of {col, row} --> keycode.
> - * Column and row are 4 bits, but range only from 0..7;
> - * a PERSISTENT_KEY is "always on" and never reported.
> - */
> -#define KEY_PERSISTENT 0x0080
> -#define KEY(col, row, keycode) (((col) << 28) | ((row) << 24) |
> (keycode))
> -#define PERSISTENT_KEY(c, r) KEY(c, r, KEY_PERSISTENT)
> -
> struct twl4030_keypad_data {
> unsigned rows;
> unsigned cols;
> --
> 1.6.2.2
>
> --
> 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
[APPLIED] [PATCH 0/2] adding back some features
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 97b83891f45c229ef5898b86dfe969e23d3b32b8 PatchWorks http://patchwork.kernel.org/patch/30370/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=97b83891f45c229ef5898b86dfe969e23d3b32b8 -- 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/2] adding back some features
code comment below:
On Wed, 17 Jun 2009, Tony Lindgren wrote:
> * Kevin Hilman [090615 09:05]:
> > Kevin Hilman writes:
> >
> > > Tony Lindgren writes:
> > >
> > >> Hi,
> > >>
> > >> * Kevin Hilman [090612 15:13]:
> > >>> Here's a couple patches to add-back some feature dropped in the
> > >>> mainline sync. These are needed for the PM branch among other things.
> > >>>
> > >>> Applies to linux-omap master.
> > >>>
> > >>> Kevin Hilman (1):
> > >>> OMAP2/3: SoC IDs: add omap_type() for determining GP/EMU/HS
> > >>
> > >> Is there any reason to get this one into mainline early?
> > >
> > > Well, the PM branch has a dependency, but also the recenetly submitted
> > > qwatchdog driver has a dependency.
> > >
> > >> If not, I suggest you keep this in your pm branch for next merge
> > >> window that I can keep merging to l-o master as needed.
> > >>
> > >> However, if omap_type() is by other queues earlier, then I can
> > >> add it into my upstream queue. If this blocks several queues
> > >> from being rebased against mainline kernel, that alone might
> > >> already be a good enough reason to get it in early.
> > >
> > > I think it should go via your upstream queue. I imagine some of the
> > > other upcoming driver submissions from TI will have a dependency as
> > > well since there is still some missing EMU/HS support ind drivers.
> >
> > Also, I'm carrying this SRAM patch below for HS/EMU that could go into
> > Paul's SRAM/SDRC queue if this omap_type() gets merged sooner rather
> > than later.
>
> Hmm, the HS omap sram.c patch below for sure justifies fixing it as
> incorrect SRAM size can cause nasty bugs.
>
> Will add both omap_type and the sram.c patch below to omap-fixes.
>
> Regards,
>
> Tony
>
> > Kevin
> >
> > commit 106588e30f070d9a8d5906d409e0b9aad89edc9e
> > Author: Tero Kristo
> > Date: Thu Oct 9 17:47:02 2008 +0300
> >
> > OMAP3: SRAM size fix for HS/EMU devices
> >
> > Signed-off-by: Tero Kristo
> > Signed-off-by: Kevin Hilman
> >
> > diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> > old mode 100644
> > new mode 100755
> > index 65006df..f40bd2d
> > --- a/arch/arm/plat-omap/sram.c
> > +++ b/arch/arm/plat-omap/sram.c
> > @@ -131,9 +131,15 @@ void __init omap_detect_sram(void)
> > if (cpu_class_is_omap2()) {
> > if (is_sram_locked()) {
> > if (cpu_is_omap34xx()) {
> > - omap_sram_base = OMAP3_SRAM_PUB_VA;
> > - omap_sram_start = OMAP3_SRAM_PUB_PA;
> > - omap_sram_size = 0x8000; /* 32K */
> > + if (omap_type() == OMAP2_DEVICE_TYPE_GP) {
> > + omap_sram_base = OMAP3_SRAM_PUB_VA;
> > + omap_sram_start = OMAP3_SRAM_PUB_PA;
> > + omap_sram_size = 0x8000; /* 32K */
> > + } else {
This would be better if it specifically tested for HS and EMU devices.
There are at least two other omap_type() possibilities here, "TEST" and
"BAD"
> > + omap_sram_base = OMAP3_SRAM_PUB_VA;
> > + omap_sram_start = OMAP3_SRAM_PUB_PA;
> > + omap_sram_size = 0x7000; /* 28K */
> > + }
> > } else {
> > omap_sram_base = OMAP2_SRAM_PUB_VA;
> > omap_sram_start = OMAP2_SRAM_PUB_PA;
> --
> 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
>
- 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
[APPLIED] [PATCH 1/2] OMAP2/3: SoC IDs: add omap_type() for determining
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 3c195a1bd36ab83b248b9174412ee81a35a41e87 PatchWorks http://patchwork.kernel.org/patch/29974/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=3c195a1bd36ab83b248b9174412ee81a35a41e87 -- 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 01/04] OMAP3: PM: Disable PER DPLL idle before OFF, reduces OFF latency by 20ms
Hello David, On Tue, 16 Jun 2009, Derrick, David wrote: > Note that we have seen some instability with this change so use with caution. Could you please expand on this? Presumably we should not merge this if it will cause instability, no? - 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
Re: [PATCH 0/2] adding back some features
* Kevin Hilman [090615 09:05]:
> Kevin Hilman writes:
>
> > Tony Lindgren writes:
> >
> >> Hi,
> >>
> >> * Kevin Hilman [090612 15:13]:
> >>> Here's a couple patches to add-back some feature dropped in the
> >>> mainline sync. These are needed for the PM branch among other things.
> >>>
> >>> Applies to linux-omap master.
> >>>
> >>> Kevin Hilman (1):
> >>> OMAP2/3: SoC IDs: add omap_type() for determining GP/EMU/HS
> >>
> >> Is there any reason to get this one into mainline early?
> >
> > Well, the PM branch has a dependency, but also the recenetly submitted
> > qwatchdog driver has a dependency.
> >
> >> If not, I suggest you keep this in your pm branch for next merge
> >> window that I can keep merging to l-o master as needed.
> >>
> >> However, if omap_type() is by other queues earlier, then I can
> >> add it into my upstream queue. If this blocks several queues
> >> from being rebased against mainline kernel, that alone might
> >> already be a good enough reason to get it in early.
> >
> > I think it should go via your upstream queue. I imagine some of the
> > other upcoming driver submissions from TI will have a dependency as
> > well since there is still some missing EMU/HS support ind drivers.
>
> Also, I'm carrying this SRAM patch below for HS/EMU that could go into
> Paul's SRAM/SDRC queue if this omap_type() gets merged sooner rather
> than later.
Hmm, the HS omap sram.c patch below for sure justifies fixing it as
incorrect SRAM size can cause nasty bugs.
Will add both omap_type and the sram.c patch below to omap-fixes.
Regards,
Tony
> Kevin
>
> commit 106588e30f070d9a8d5906d409e0b9aad89edc9e
> Author: Tero Kristo
> Date: Thu Oct 9 17:47:02 2008 +0300
>
> OMAP3: SRAM size fix for HS/EMU devices
>
> Signed-off-by: Tero Kristo
> Signed-off-by: Kevin Hilman
>
> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> old mode 100644
> new mode 100755
> index 65006df..f40bd2d
> --- a/arch/arm/plat-omap/sram.c
> +++ b/arch/arm/plat-omap/sram.c
> @@ -131,9 +131,15 @@ void __init omap_detect_sram(void)
> if (cpu_class_is_omap2()) {
> if (is_sram_locked()) {
> if (cpu_is_omap34xx()) {
> - omap_sram_base = OMAP3_SRAM_PUB_VA;
> - omap_sram_start = OMAP3_SRAM_PUB_PA;
> - omap_sram_size = 0x8000; /* 32K */
> + if (omap_type() == OMAP2_DEVICE_TYPE_GP) {
> + omap_sram_base = OMAP3_SRAM_PUB_VA;
> + omap_sram_start = OMAP3_SRAM_PUB_PA;
> + omap_sram_size = 0x8000; /* 32K */
> + } else {
> + omap_sram_base = OMAP3_SRAM_PUB_VA;
> + omap_sram_start = OMAP3_SRAM_PUB_PA;
> + omap_sram_size = 0x7000; /* 28K */
> + }
> } else {
> omap_sram_base = OMAP2_SRAM_PUB_VA;
> omap_sram_start = OMAP2_SRAM_PUB_PA;
--
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] OMAP3: MMC: Add mux for pins
* Pandita, Vikram [090616 09:50]: > > >From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > > > >"Pandita, Vikram" writes: > > > >>>-Original Message- > >>>From: Tony Lindgren [mailto:t...@atomide.com] > >>>Sent: Monday, June 15, 2009 6:05 AM > >>>To: Hugo Vincent > >>>Cc: Pandita, Vikram; linux-omap@vger.kernel.org; Chikkature Rajashekar, > >>>Madhusudhan > >>>Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins > >>> > >>>* Hugo Vincent [090615 03:44]: > > On 15/06/2009, at 8:12 PM, Tony Lindgren wrote: > > > * Vikram Pandita [090612 15:43]: > >> For OMAP3 add MMC1 MMC2 and MMC3 pin mux > >> > >> Signed-off-by: Chikkature Rajashekar > >> Signed-off-by: Vikram Pandita > >> --- > >> arch/arm/mach-omap2/devices.c | 33 ++ > >> arch/arm/mach-omap2/mux.c | 49 +++ > >> ++ > >> arch/arm/plat-omap/include/mach/mux.h | 28 +++ > > > > Great, just one issue: All data pins may not be connected, so you > > need to look at wires in struct omap_mmc_slot_data to see how many > > data pins to mux. > > There is another issue: different mux-outs are possible for different > board layouts; for example, I'm using AE10_3430_MMC3_CMD instead of > AC3_3430_MMC3_CMD. I'm not sure what the best way of handling this is, > but at a minimum, perhaps make mux setting optional, e.g. add no_mux to > struct omap_mmc_slot_data. > >>> > >>>Hmm, yeah that's right. I guess only the common pins should be muxed > >>>in devices.c, and any optional pins should be muxed in the board-*.c > >>>files. > >> > >> Please check this patch set: > >> [PATCH 1/2] OMAP3: MMC: Pass pin muxing control flag > >> > >> I used the nomux flag to do this distinction. > >> > > > >This still doesn't address the problem that when you do mux, you mux > >all OMAP3 platforms the same way, and that is not correct. > > The patch tries to address this exact concern. > > Using nomux flag, the board file decides if the default mux for each MMC(n) > controller is good for it or not. > > In case default is good, then MMC(n).nomux=0 > In case default mux for any one MMC controller is not good, then for that > MMC(n).nomux=1 > > And the board file specifies the mux for that MMC(n) only. > > I do not see any advantage to control mux at ball level for each mmc > controller instance. To me it seems cleanest just to do the muxing in board-*.c files and not even attempt to do it in a generic way. As we also support doing the muxing in the bootloader only, adding a flag for nomux can easily create hard to track bugs. If some pins are always needed, and don't have alternative pinouts, then the common pins could be muxed in devices.c. Regards, Tony -- 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 -pm 1/2] SDRC: check for stuck DLL state machine and kick
Hi, a few questions for Mike and Richard: On Mon, 15 Jun 2009, Kevin Hilman wrote: > From: Richard Woodruff > > I'm thinking DLL state is an exceptional condition which happens based > on some wrong early programming when initially setting DLL up. Some > kind of race between idle features and lock happens early on. This > patch recognizes the issue and moves state machine into locked state. > > Its my guess the kick case won't be executed that often. As long as > DLL is not on you can mess with idle state. When its on to mess with > DDR control you need to be in self-refresh and not making > accesses... like in dvfs code. > > Tested-by: Mike Chan The last time I torture-tested CORE DVFS, which admittedly was some time ago, the boards tested were stable across the entire overnight run, doing nothing but CORE DVFS switching. This was on a Beagle and a 3430SDP. So, what is different about your setup? The usual suite of questions: - What chip revisions/boards does this affect? - Is this specific to certain bootloaders? - Has anyone else out there seen this problem? Rather than working around an occasional DLL failure to lock, is it possible to reset the DLL earlier in the boot process, as Richard's commit message suggests? That would be preferable to this approach. A back-of-the-envelope assessment suggests that this patch could cause unpredictable, additional 1.5 millisecond latency spikes whenever the workaround triggers (since OCM RAM is marked uncacheable). - Paul > --- > arch/arm/mach-omap2/sleep34xx.S | 22 -- > 1 files changed, 20 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S > index aedcf94..c469bbe 100644 > --- a/arch/arm/mach-omap2/sleep34xx.S > +++ b/arch/arm/mach-omap2/sleep34xx.S > @@ -595,20 +595,38 @@ wait_sdrc_ok: > ldr r5, [r4] > bic r5, r5, #0x40 > str r5, [r4] > -wait_dll_lock: > -/* Is dll in lock mode? */ > +is_dll_in_lock_mode: > ldr r4, sdrc_dlla_ctrl > ldr r5, [r4] > tst r5, #0x4 > bxnelr > /* wait till dll locks */ > +wait_dll_lock_timed: > ldr r4, sdrc_dlla_status > +mov r6, #0x2000 > +wait_dll_lock: > +subsr6, r6, #0x1 > +beq kick_dll > ldr r5, [r4] > and r5, r5, #0x4 > cmp r5, #0x4 > bne wait_dll_lock > bx lr > > +/* Kick DLL state machine if lock not started */ > +kick_dll: > + ldr r4, sdrc_dlla_ctrl /* get dlla addr */ > + ldr r5, [r4]/* grab value */ > + mov r6, r5 /* save value */ > + orr r6, r6, #0x10 /* dllidle on */ > + str r6, [r4] > + dsb > + bic r6, #0x10 /* dllidle off */ > + str r6, [r4] > + dsb > + str r6, [r4]/* restore old value */ > + b wait_dll_lock_timed > + > cm_idlest1_core: > .word CM_IDLEST1_CORE_V > sdrc_dlla_status: > -- > 1.6.3.2 > > -- > 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 > - 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
