RE: [PATCH] PM: Disable usb host HW save and restore
On Thu, 2009-05-14 at 20:40 +0300, Woodruff, Richard wrote: > > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > > Sent: Thursday, May 14, 2009 12:10 PM > > To: Kalle Jokiniemi > > > Kalle Jokiniemi writes: > > > > > The hardware SAVEANDRESTORE mechanism seems to leave > > > USB HOST power domain permanently into active state > > > after one transition from off to active state. > > > Disabling for now. > > Some are is needed around USB host domain handling. There are a > couple errata impacting different chip revs. > > Today in the older TI reference code this condition of a stuck on > power domain does not happen. However, we are using a software > supervised method to disable the power domain. May be this code has a > bug or the hardware does around auto use for this domain. Yes, usb-host autoidle was enabled when I was digging this issue. > > You will want TLL or host SAR activated to minimally work around a > possible false cold reset issue. There is a window coming back from > OFF where a reset will be thrown. Enabling SAR conclusively moves the > internal window so there is no danger. The error is fairly easily > seen so if you start taking resets know this is likely the root cause. > > What Rev of CPU is the issue occurring on? I think the usb-host problem was on ES3.1 at least. > > The USBTLL SAR in 3.0 and before silicon will case a deadlock on 2nd > sleep attempt. On 3.1 and after its fixed. So ES3.0 devices are exposed to the cold reset issue (since USBTLL SAR is only enabled in ES3.1). Would you suspect that we can enable USB host SAR, if the AUTOIDLE is turned off? Then we would not need this patch. - Kalle > > Regards, > Richard W. -- 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: PM: timeout waiting for write of PM_WKEN_WKUP.EN_IO_CHAIN
On Thu, 2009-05-14 at 18:57 +0300, Kevin Hilman wrote: > Kalle, > > In your "Enable IO-CHAIN wakeup" patch[1], you set a timout based on > 1000 tries of reading back from PM_WKST_WKUP. > > Just curious how you came up with that value. I tested it around a few times, and the loop seemed to run 2 iterations max. 1000 is just a random (big enough) number that I think should work if everything is ok. > > On ES3.1 3430SDP, some TI folks are seeing that timeout warning > every time hitting idle. Then there is something wrong and the io-chain enable is not working. Please try removing the timeout and see if it hangs completely. I don't have a SDP to test on. - Kalle > > Kevin > > [1] http://marc.info/?l=linux-omap&m=123807750921423&w=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
RE: [PATCH 7/8] ARM: OMAP3: Fix number of GPIO lines for 34xx
> > From: Tony Lindgren Typo? > > As per 3430 TRM, there are 6 banks [0 to 191] > > Signed-off-by: Tom Rix > Signed-off-by: Vikram Pandita > Signed-off-by: Tony Lindgren > --- > arch/arm/plat-omap/gpio.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c > index 17d7afe..ee0b21f 100644 > --- a/arch/arm/plat-omap/gpio.c > +++ b/arch/arm/plat-omap/gpio.c > @@ -307,7 +307,7 @@ static inline int gpio_valid(int gpio) > return 0; > if (cpu_is_omap24xx() && gpio < 128) > return 0; > - if (cpu_is_omap34xx() && gpio < 160) > + if (cpu_is_omap34xx() && gpio < 192) > return 0; > return -1; > } >
Re: Patch "REMOVE OMAP LEGACY CODE: Reset mach-omap1/board-*.c files to mainline" breaks nokia770
* Andrew de Quincey [090514 16:37]:
> Quoting Tony Lindgren :
>
>> * Andrew de Quincey [090514 16:19]:
>>> Quoting Tony Lindgren :
>>>
* Felipe Balbi [090514 01:15]:
> On Thu, May 14, 2009 at 03:44:14AM +0200, ext Tony Lindgren wrote:
> > * Felipe Balbi [090513 17:33]:
> > > On Thu, May 14, 2009 at 01:46:51AM +0200, ext Andrew de Quincey wrote:
> > > > Hi, I've just discovered that the patch at:
> > > >
> > > >
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=3eae3ea7c443fc4330574dffea65b6f2f53a2574
> > > >
> > > > Breaks the nokia770's framebuffer as it removes the
> platform data for
> > > > the HWA742 LCD controller.
> > > >
> > > > As the patch says "Patches against the mainline tree are welcome to
> > > > add back the missing functionality if needed!", I'm happy
> to do this.
> > > >
> > > > However, since I'm fairly new to the linux-omap project, is simply
> > > > extracting the removed nokia770 code and generating a patch against
> > > > the mainline kernel sufficient? or is there a newer style
> of some sort
> > > > that should be adopted for this?
> > >
> > > You can start by generating the new patch against mainline and running
> > > scripts/checkpatch.pl, then you should probably find out if there are
> > > any API changes and stuff like that. Then send the patch to lkml ccing
> > > linux-omap and let's see what comments do you get from those guys :-)
> >
> > Please change the code to pass the struct clock to
> drivers/video/omap/hwa742.c
> > in hwa742_platform_data. The hw742.c can just do standard
> clk_enable/disable
> > there. Otherwise we won't be able to get this missing part to
> the mainline
> > kernel.
>
> how about clkdev then ? are we gonna support that for omap1 still ?
Yeah the clkdev is there, but in the case of the LCD the clock can be
any clock, so we cannot set just one "fck" for all the omap1 LCD panels.
In this case the "bclk" is used for the LCD, but "bclk" could be used
for other devices as well, not just LCD.
>>>
>>> Hi, is the attached patch the sort of thing you had in mind? This is
>>> against linux-omap-2.6, latest git.
>>
>> Hey, that's pretty cool! Just one comment below.
>>
>>> Unfortunately, both mainline linux-2.6 and linux-omap-2.6 gits lock up
>>> on bootup before the LCD is initialised. However, the linux-omap 2.6.29
>>> that is compiled by openembedded still boots ok, and with the attached
>>> patch applied, the LCD works again!
>>
>> OK, good to hear. Need to debug that then.
>>
>>> I guess my next task is to figure out why the mainline kernels freeze;
>>> I've seen that before, and it seemed to be something to do with changes
>>> to the mcbsp support.
>>
>> OK
>>
>>> Reinstate HWA742 platform data for nokia 770 platform.
>>>
>>> Signed-off-by: Andrew de Quincey
>>>
>>> diff --git a/arch/arm/mach-omap1/board-nokia770.c
>>> b/arch/arm/mach-omap1/board-nokia770.c
>>> index 8780ca6..df5f38b 100644
>>> --- a/arch/arm/mach-omap1/board-nokia770.c
>>> +++ b/arch/arm/mach-omap1/board-nokia770.c
>>> @@ -33,6 +33,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -163,6 +164,26 @@ static struct spi_board_info
>>> nokia770_spi_board_info[] __initdata = {
>>> },
>>> };
>>>
>>> +static struct hwa742_platform_data nokia770_hwa742_platform_data = {
>>> + .sys_ck = NULL,
>>> + .te_connected = 1,
>>> +};
>>> +
>>> +static int hwa742_get_clocks(void)
>>> +{
>>> + nokia770_hwa742_platform_data.sys_ck = clk_get(NULL, "bclk");
>>> + if (IS_ERR(nokia770_hwa742_platform_data.sys_ck)) {
>>> + printk(KERN_ERR "can't get HWA742 clock\n");
>>> + return PTR_ERR(nokia770_hwa742_platform_data.sys_ck);
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +static void hwa742_dev_init(void)
>>> +{
>>> + hwa742_get_clocks();
>>> + omapfb_set_ctrl_platform_data(&nokia770_hwa742_platform_data);
>>> +}
>>
>> You can now get rid of the hwa742_get_clocks(), and move that code
>> to hwa742_dev_init() instead.
>
> [snip]
>
> Done! v2 attached.
Looks good to me.
Acked-by: Tony Lindgren
Imre, want to update your git branch for fbdev list with this one?
Regards,
Tony
> Reinstate HWA742 platform data for nokia 770 platform.
>
> Signed-off-by: Andrew de Quincey
>
> diff --git a/arch/arm/mach-omap1/board-nokia770.c
> b/arch/arm/mach-omap1/board-nokia770.c
> index 8780ca6..2c4785e 100644
> --- a/arch/arm/mach-omap1/board-nokia770.c
> +++ b/arch/arm/mach-omap1/board-nokia770.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -163,6 +164,20 @@ static struct spi_board_info nokia770_spi_board_info[]
> __initdata = {
> },
> };
>
> +static struct hwa742_platform_data nokia770_hwa
Re: OMAP3: PM: Add the wakeup source driver, v4
Kevin Hilman writes: Kim Kyuwon writes: Hi Kevin, Could you please review this fourth version of OMAP wakeup source driver? Yes. I'm working through my backlog of PM branch submissions this week. I've been focusing on getting some of the PM branch reworked and rebased so I can start submitting upstream. I apologize for the delays, but the upstream work is currently higher priority than adding large new features to the PM branch. I agree. Thank you for your works about OMAP tree and OMAP PM brach! -- 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 OMAP LEGACY CODE: Reset mach-omap1/board-*.c files to mainline" breaks nokia770
Quoting Tony Lindgren :
* Andrew de Quincey [090514 16:19]:
Quoting Tony Lindgren :
* Felipe Balbi [090514 01:15]:
On Thu, May 14, 2009 at 03:44:14AM +0200, ext Tony Lindgren wrote:
> * Felipe Balbi [090513 17:33]:
> > On Thu, May 14, 2009 at 01:46:51AM +0200, ext Andrew de Quincey wrote:
> > > Hi, I've just discovered that the patch at:
> > >
> > >
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=3eae3ea7c443fc4330574dffea65b6f2f53a2574
> > >
> > > Breaks the nokia770's framebuffer as it removes the
platform data for
> > > the HWA742 LCD controller.
> > >
> > > As the patch says "Patches against the mainline tree are welcome to
> > > add back the missing functionality if needed!", I'm happy
to do this.
> > >
> > > However, since I'm fairly new to the linux-omap project, is simply
> > > extracting the removed nokia770 code and generating a patch against
> > > the mainline kernel sufficient? or is there a newer style
of some sort
> > > that should be adopted for this?
> >
> > You can start by generating the new patch against mainline and running
> > scripts/checkpatch.pl, then you should probably find out if there are
> > any API changes and stuff like that. Then send the patch to lkml ccing
> > linux-omap and let's see what comments do you get from those guys :-)
>
> Please change the code to pass the struct clock to
drivers/video/omap/hwa742.c
> in hwa742_platform_data. The hw742.c can just do standard
clk_enable/disable
> there. Otherwise we won't be able to get this missing part to
the mainline
> kernel.
how about clkdev then ? are we gonna support that for omap1 still ?
Yeah the clkdev is there, but in the case of the LCD the clock can be
any clock, so we cannot set just one "fck" for all the omap1 LCD panels.
In this case the "bclk" is used for the LCD, but "bclk" could be used
for other devices as well, not just LCD.
Hi, is the attached patch the sort of thing you had in mind? This is
against linux-omap-2.6, latest git.
Hey, that's pretty cool! Just one comment below.
Unfortunately, both mainline linux-2.6 and linux-omap-2.6 gits lock up
on bootup before the LCD is initialised. However, the linux-omap 2.6.29
that is compiled by openembedded still boots ok, and with the attached
patch applied, the LCD works again!
OK, good to hear. Need to debug that then.
I guess my next task is to figure out why the mainline kernels freeze;
I've seen that before, and it seemed to be something to do with changes
to the mcbsp support.
OK
Reinstate HWA742 platform data for nokia 770 platform.
Signed-off-by: Andrew de Quincey
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index 8780ca6..df5f38b 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -163,6 +164,26 @@ static struct spi_board_info
nokia770_spi_board_info[] __initdata = {
},
};
+static struct hwa742_platform_data nokia770_hwa742_platform_data = {
+ .sys_ck = NULL,
+ .te_connected = 1,
+};
+
+static int hwa742_get_clocks(void)
+{
+ nokia770_hwa742_platform_data.sys_ck = clk_get(NULL, "bclk");
+ if (IS_ERR(nokia770_hwa742_platform_data.sys_ck)) {
+ printk(KERN_ERR "can't get HWA742 clock\n");
+ return PTR_ERR(nokia770_hwa742_platform_data.sys_ck);
+ }
+ return 0;
+}
+
+static void hwa742_dev_init(void)
+{
+ hwa742_get_clocks();
+ omapfb_set_ctrl_platform_data(&nokia770_hwa742_platform_data);
+}
You can now get rid of the hwa742_get_clocks(), and move that code
to hwa742_dev_init() instead.
[snip]
Done! v2 attached.
Reinstate HWA742 platform data for nokia 770 platform.
Signed-off-by: Andrew de Quincey
diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
index 8780ca6..2c4785e 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -163,6 +164,20 @@ static struct spi_board_info nokia770_spi_board_info[] __initdata = {
},
};
+static struct hwa742_platform_data nokia770_hwa742_platform_data = {
+ .sys_ck = NULL,
+ .te_connected = 1,
+};
+
+static void hwa742_dev_init(void)
+{
+ nokia770_hwa742_platform_data.sys_ck = clk_get(NULL, "bclk");
+ if (IS_ERR(nokia770_hwa742_platform_data.sys_ck)) {
+ printk(KERN_ERR "can't get HWA742 clock\n");
+ } else {
+ omapfb_set_ctrl_platform_data(&nokia770_hwa742_platform_data);
+ }
+}
/* assume no Mini-AB port */
@@ -371,6 +386,7 @@ static void __init omap_nokia770_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
omap_dsp_init();
+ hwa742_dev_init();
ads7846_dev_init();
mipid_dev_init();
omap_usb_init(&nokia770_usb_config);
diff --git a/a
[PATCH 5/5] ARM: OMAP2/3: Remove OMAP_CM_REGADDR
Processor specific macros should be used instead. Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/clock24xx.h|2 ++ arch/arm/mach-omap2/clock34xx.h|2 ++ arch/arm/mach-omap2/cm.h |5 - arch/arm/plat-omap/include/mach/omap24xx.h | 10 -- arch/arm/plat-omap/include/mach/omap34xx.h |6 -- 5 files changed, 4 insertions(+), 21 deletions(-) diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h index f0e4480..458f00c 100644 --- a/arch/arm/mach-omap2/clock24xx.h +++ b/arch/arm/mach-omap2/clock24xx.h @@ -26,9 +26,11 @@ /* REVISIT: These should be set dynamically for CONFIG_MULTI_OMAP2 */ #ifdef CONFIG_ARCH_OMAP2420 +#define OMAP_CM_REGADDROMAP2420_CM_REGADDR #define OMAP24XX_PRCM_CLKOUT_CTRL OMAP2420_PRCM_CLKOUT_CTRL #define OMAP24XX_PRCM_CLKEMUL_CTRL OMAP2420_PRCM_CLKEMUL_CTRL #else +#define OMAP_CM_REGADDROMAP2430_CM_REGADDR #define OMAP24XX_PRCM_CLKOUT_CTRL OMAP2430_PRCM_CLKOUT_CTRL #define OMAP24XX_PRCM_CLKEMUL_CTRL OMAP2430_PRCM_CLKEMUL_CTRL #endif diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h index 017a30e..496f0e9 100644 --- a/arch/arm/mach-omap2/clock34xx.h +++ b/arch/arm/mach-omap2/clock34xx.h @@ -27,6 +27,8 @@ #include "prm.h" #include "prm-regbits-34xx.h" +#define OMAP_CM_REGADDROMAP34XX_CM_REGADDR + static unsigned long omap3_dpll_recalc(struct clk *clk); static unsigned long omap3_clkoutx2_recalc(struct clk *clk); static void omap3_dpll_allow_idle(struct clk *clk); diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index efc082a..1d3c93b 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -16,17 +16,12 @@ #include "prcm-common.h" -#ifndef __ASSEMBLER__ -#define OMAP_CM_REGADDR(module, reg) \ - IO_ADDRESS(OMAP2_CM_BASE + (module) + (reg)) -#else #define OMAP2420_CM_REGADDR(module, reg) \ IO_ADDRESS(OMAP2420_CM_BASE + (module) + (reg)) #define OMAP2430_CM_REGADDR(module, reg) \ IO_ADDRESS(OMAP2430_CM_BASE + (module) + (reg)) #define OMAP34XX_CM_REGADDR(module, reg) \ IO_ADDRESS(OMAP3430_CM_BASE + (module) + (reg)) -#endif /* * Architecture-specific global CM registers diff --git a/arch/arm/plat-omap/include/mach/omap24xx.h b/arch/arm/plat-omap/include/mach/omap24xx.h index 60f8324..696edfc 100644 --- a/arch/arm/plat-omap/include/mach/omap24xx.h +++ b/arch/arm/plat-omap/include/mach/omap24xx.h @@ -85,15 +85,5 @@ #define OMAP24XX_SEC_AES_BASE (OMAP24XX_SEC_BASE + 0x6000) #define OMAP24XX_SEC_PKA_BASE (OMAP24XX_SEC_BASE + 0x8000) -#if defined(CONFIG_ARCH_OMAP2420) - -#define OMAP2_CM_BASE OMAP2420_CM_BASE - -#elif defined(CONFIG_ARCH_OMAP2430) - -#define OMAP2_CM_BASE OMAP2430_CM_BASE - -#endif - #endif /* __ASM_ARCH_OMAP24XX_H */ diff --git a/arch/arm/plat-omap/include/mach/omap34xx.h b/arch/arm/plat-omap/include/mach/omap34xx.h index 36c99ca..cc25733 100644 --- a/arch/arm/plat-omap/include/mach/omap34xx.h +++ b/arch/arm/plat-omap/include/mach/omap34xx.h @@ -83,12 +83,6 @@ #define OMAP34XX_MAILBOX_BASE (L4_34XX_BASE + 0x94000) -#if defined(CONFIG_ARCH_OMAP3430) - -#define OMAP2_CM_BASE OMAP3430_CM_BASE - -#endif - #define OMAP34XX_DSP_BASE 0x5800 #define OMAP34XX_DSP_MEM_BASE (OMAP34XX_DSP_BASE + 0x0) #define OMAP34XX_DSP_IPI_BASE (OMAP34XX_DSP_BASE + 0x100) -- 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 OMAP LEGACY CODE: Reset mach-omap1/board-*.c files to mainline" breaks nokia770
* Andrew de Quincey [090514 16:19]:
> Quoting Tony Lindgren :
>
>> * Felipe Balbi [090514 01:15]:
>>> On Thu, May 14, 2009 at 03:44:14AM +0200, ext Tony Lindgren wrote:
>>> > * Felipe Balbi [090513 17:33]:
>>> > > On Thu, May 14, 2009 at 01:46:51AM +0200, ext Andrew de Quincey wrote:
>>> > > > Hi, I've just discovered that the patch at:
>>> > > >
>>> > > >
>>> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=3eae3ea7c443fc4330574dffea65b6f2f53a2574
>>> > > >
>>> > > > Breaks the nokia770's framebuffer as it removes the platform data for
>>> > > > the HWA742 LCD controller.
>>> > > >
>>> > > > As the patch says "Patches against the mainline tree are welcome to
>>> > > > add back the missing functionality if needed!", I'm happy to do this.
>>> > > >
>>> > > > However, since I'm fairly new to the linux-omap project, is simply
>>> > > > extracting the removed nokia770 code and generating a patch against
>>> > > > the mainline kernel sufficient? or is there a newer style of some sort
>>> > > > that should be adopted for this?
>>> > >
>>> > > You can start by generating the new patch against mainline and running
>>> > > scripts/checkpatch.pl, then you should probably find out if there are
>>> > > any API changes and stuff like that. Then send the patch to lkml ccing
>>> > > linux-omap and let's see what comments do you get from those guys :-)
>>> >
>>> > Please change the code to pass the struct clock to
>>> drivers/video/omap/hwa742.c
>>> > in hwa742_platform_data. The hw742.c can just do standard
>>> clk_enable/disable
>>> > there. Otherwise we won't be able to get this missing part to the mainline
>>> > kernel.
>>>
>>> how about clkdev then ? are we gonna support that for omap1 still ?
>>
>> Yeah the clkdev is there, but in the case of the LCD the clock can be
>> any clock, so we cannot set just one "fck" for all the omap1 LCD panels.
>>
>> In this case the "bclk" is used for the LCD, but "bclk" could be used
>> for other devices as well, not just LCD.
>
> Hi, is the attached patch the sort of thing you had in mind? This is
> against linux-omap-2.6, latest git.
Hey, that's pretty cool! Just one comment below.
> Unfortunately, both mainline linux-2.6 and linux-omap-2.6 gits lock up
> on bootup before the LCD is initialised. However, the linux-omap 2.6.29
> that is compiled by openembedded still boots ok, and with the attached
> patch applied, the LCD works again!
OK, good to hear. Need to debug that then.
> I guess my next task is to figure out why the mainline kernels freeze;
> I've seen that before, and it seemed to be something to do with changes
> to the mcbsp support.
OK
> Reinstate HWA742 platform data for nokia 770 platform.
>
> Signed-off-by: Andrew de Quincey
>
> diff --git a/arch/arm/mach-omap1/board-nokia770.c
> b/arch/arm/mach-omap1/board-nokia770.c
> index 8780ca6..df5f38b 100644
> --- a/arch/arm/mach-omap1/board-nokia770.c
> +++ b/arch/arm/mach-omap1/board-nokia770.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -163,6 +164,26 @@ static struct spi_board_info nokia770_spi_board_info[]
> __initdata = {
> },
> };
>
> +static struct hwa742_platform_data nokia770_hwa742_platform_data = {
> + .sys_ck = NULL,
> + .te_connected = 1,
> +};
> +
> +static int hwa742_get_clocks(void)
> +{
> + nokia770_hwa742_platform_data.sys_ck = clk_get(NULL, "bclk");
> + if (IS_ERR(nokia770_hwa742_platform_data.sys_ck)) {
> + printk(KERN_ERR "can't get HWA742 clock\n");
> + return PTR_ERR(nokia770_hwa742_platform_data.sys_ck);
> + }
> + return 0;
> +}
> +
> +static void hwa742_dev_init(void)
> +{
> + hwa742_get_clocks();
> + omapfb_set_ctrl_platform_data(&nokia770_hwa742_platform_data);
> +}
You can now get rid of the hwa742_get_clocks(), and move that code
to hwa742_dev_init() instead.
Regards,
Tony
> /* assume no Mini-AB port */
>
> @@ -371,6 +392,7 @@ static void __init omap_nokia770_init(void)
> omap_serial_init();
> omap_register_i2c_bus(1, 100, NULL, 0);
> omap_dsp_init();
> + hwa742_dev_init();
> ads7846_dev_init();
> mipid_dev_init();
> omap_usb_init(&nokia770_usb_config);
> diff --git a/arch/arm/plat-omap/include/mach/hwa742.h
> b/arch/arm/plat-omap/include/mach/hwa742.h
> index 577f492..c00e05d 100644
> --- a/arch/arm/plat-omap/include/mach/hwa742.h
> +++ b/arch/arm/plat-omap/include/mach/hwa742.h
> @@ -2,10 +2,7 @@
> #define _HWA742_H
>
> struct hwa742_platform_data {
> - void(*power_up)(struct device *dev);
> - void(*power_down)(struct device *dev);
> - unsigned long (*get_clock_rate)(struct device *dev);
> -
> + struct clk *sys_ck;
> unsignedte_connected:1;
> };
>
> diff --git a/drivers/video/omap/hwa742.c b/drivers/video/omap/hwa742.c
> index 8aa6e47..1230476 100644
> ---
[PATCH 4/5] ARM: OMAP2/3: Remove OMAP2_PRCM_BASE
It's currently unused, and processor specific defines should be used instead. Signed-off-by: Tony Lindgren --- arch/arm/plat-omap/include/mach/omap24xx.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/omap24xx.h b/arch/arm/plat-omap/include/mach/omap24xx.h index 4ce9b6a..60f8324 100644 --- a/arch/arm/plat-omap/include/mach/omap24xx.h +++ b/arch/arm/plat-omap/include/mach/omap24xx.h @@ -87,12 +87,10 @@ #if defined(CONFIG_ARCH_OMAP2420) -#define OMAP2_PRCM_BASEOMAP2420_PRCM_BASE #define OMAP2_CM_BASE OMAP2420_CM_BASE #elif defined(CONFIG_ARCH_OMAP2430) -#define OMAP2_PRCM_BASEOMAP2430_PRCM_BASE #define OMAP2_CM_BASE OMAP2430_CM_BASE #endif -- 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/5] ARM: OMAP2/3: Move define of OMAP2_VA_IC_BASE to be local to entry-macro.S
Move define of OMAP2_VA_IC_BASE to be local to entry-macro.S Signed-off-by: Tony Lindgren --- arch/arm/plat-omap/include/mach/entry-macro.S |9 ++--- arch/arm/plat-omap/include/mach/omap24xx.h|2 -- arch/arm/plat-omap/include/mach/omap34xx.h|1 - 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/entry-macro.S b/arch/arm/plat-omap/include/mach/entry-macro.S index 2276f89..33256a0 100644 --- a/arch/arm/plat-omap/include/mach/entry-macro.S +++ b/arch/arm/plat-omap/include/mach/entry-macro.S @@ -58,11 +58,14 @@ #endif #if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX) -#if defined(CONFIG_ARCH_OMAP24XX) #include -#endif -#if defined(CONFIG_ARCH_OMAP34XX) #include + +/* REVISIT: This should be set dynamically if CONFIG_MULTI_OMAP2 is selected */ +#if defined(CONFIG_ARCH_OMAP2420) || defined(CONFIG_ARCH_OMAP2430) +#define OMAP2_VA_IC_BASE IO_ADDRESS(OMAP24XX_IC_BASE) +#elif defined(CONFIG_ARCH_OMAP34XX) +#define OMAP2_VA_IC_BASE IO_ADDRESS(OMAP34XX_IC_BASE) #endif #define INTCPS_SIR_IRQ_OFFSET 0x0040 /* Active interrupt offset */ diff --git a/arch/arm/plat-omap/include/mach/omap24xx.h b/arch/arm/plat-omap/include/mach/omap24xx.h index 10a6413..4ce9b6a 100644 --- a/arch/arm/plat-omap/include/mach/omap24xx.h +++ b/arch/arm/plat-omap/include/mach/omap24xx.h @@ -89,13 +89,11 @@ #define OMAP2_PRCM_BASEOMAP2420_PRCM_BASE #define OMAP2_CM_BASE OMAP2420_CM_BASE -#define OMAP2_VA_IC_BASE IO_ADDRESS(OMAP24XX_IC_BASE) #elif defined(CONFIG_ARCH_OMAP2430) #define OMAP2_PRCM_BASEOMAP2430_PRCM_BASE #define OMAP2_CM_BASE OMAP2430_CM_BASE -#define OMAP2_VA_IC_BASE IO_ADDRESS(OMAP24XX_IC_BASE) #endif diff --git a/arch/arm/plat-omap/include/mach/omap34xx.h b/arch/arm/plat-omap/include/mach/omap34xx.h index 4233064..36c99ca 100644 --- a/arch/arm/plat-omap/include/mach/omap34xx.h +++ b/arch/arm/plat-omap/include/mach/omap34xx.h @@ -86,7 +86,6 @@ #if defined(CONFIG_ARCH_OMAP3430) #define OMAP2_CM_BASE OMAP3430_CM_BASE -#define OMAP2_VA_IC_BASE IO_ADDRESS(OMAP34XX_IC_BASE) #endif -- 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/5] ARM: OMAP2/3: Remove OMAP_PRM_REGADDR and OMAP2_PRM_BASE
Remove OMAP_PRM_REGADDR and use processor specific defines instead.
Also fold in a patch from Kevin Hilman to add _OFFSET #defines
for the PRCM registers to be used with the prm_[read|write]_* macros.
These are used extensively in the forthcoming OMAP PM support.
Also remove now unused OMAP2_PRM_BASE.
Signed-off-by: Kevin Hilman
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/clock.c|4 -
arch/arm/mach-omap2/clock24xx.c| 21 ++-
arch/arm/mach-omap2/clock24xx.h|9 +
arch/arm/mach-omap2/cm.h |1
arch/arm/mach-omap2/prm.h | 205 +---
arch/arm/mach-omap2/sdrc2xxx.c |5 +
arch/arm/mach-omap2/sram242x.S |6 -
arch/arm/mach-omap2/sram243x.S |6 -
arch/arm/plat-omap/include/mach/omap24xx.h |2
arch/arm/plat-omap/include/mach/omap34xx.h |1
10 files changed, 160 insertions(+), 100 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 4247a15..dd37483 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -91,9 +91,9 @@ static void _omap2xxx_clk_commit(struct clk *clk)
return;
prm_write_mod_reg(OMAP24XX_VALID_CONFIG, OMAP24XX_GR_MOD,
- OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET);
+ OMAP2_PRCM_CLKCFG_CTRL_OFFSET);
/* OCP barrier */
- prm_read_mod_reg(OMAP24XX_GR_MOD, OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET);
+ prm_read_mod_reg(OMAP24XX_GR_MOD, OMAP2_PRCM_CLKCFG_CTRL_OFFSET);
}
/*
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index e4cef33..c442fe9 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -233,6 +233,8 @@ static struct prcm_config *curr_prcm_set;
static struct clk *vclk;
static struct clk *sclk;
+static void __iomem *prcm_clksrc_ctrl;
+
/*-
* Omap24xx specific clock functions
*-*/
@@ -269,10 +271,9 @@ static int omap2_enable_osc_ck(struct clk *clk)
{
u32 pcc;
- pcc = __raw_readl(OMAP24XX_PRCM_CLKSRC_CTRL);
+ pcc = __raw_readl(prcm_clksrc_ctrl);
- __raw_writel(pcc & ~OMAP_AUTOEXTCLKMODE_MASK,
- OMAP24XX_PRCM_CLKSRC_CTRL);
+ __raw_writel(pcc & ~OMAP_AUTOEXTCLKMODE_MASK, prcm_clksrc_ctrl);
return 0;
}
@@ -281,10 +282,9 @@ static void omap2_disable_osc_ck(struct clk *clk)
{
u32 pcc;
- pcc = __raw_readl(OMAP24XX_PRCM_CLKSRC_CTRL);
+ pcc = __raw_readl(prcm_clksrc_ctrl);
- __raw_writel(pcc | OMAP_AUTOEXTCLKMODE_MASK,
- OMAP24XX_PRCM_CLKSRC_CTRL);
+ __raw_writel(pcc | OMAP_AUTOEXTCLKMODE_MASK, prcm_clksrc_ctrl);
}
static const struct clkops clkops_oscck = {
@@ -654,7 +654,7 @@ static u32 omap2_get_sysclkdiv(void)
{
u32 div;
- div = __raw_readl(OMAP24XX_PRCM_CLKSRC_CTRL);
+ div = __raw_readl(prcm_clksrc_ctrl);
div &= OMAP_SYSCLKDIV_MASK;
div >>= OMAP_SYSCLKDIV_SHIFT;
@@ -714,10 +714,13 @@ int __init omap2_clk_init(void)
struct omap_clk *c;
u32 clkrate;
- if (cpu_is_omap242x())
+ if (cpu_is_omap242x()) {
+ prcm_clksrc_ctrl = OMAP2420_PRCM_CLKSRC_CTRL;
cpu_mask = RATE_IN_242X;
- else if (cpu_is_omap2430())
+ } else if (cpu_is_omap2430()) {
+ prcm_clksrc_ctrl = OMAP2430_PRCM_CLKSRC_CTRL;
cpu_mask = RATE_IN_243X;
+ }
clk_init(&omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h
index 88c5acb..f0e4480 100644
--- a/arch/arm/mach-omap2/clock24xx.h
+++ b/arch/arm/mach-omap2/clock24xx.h
@@ -24,6 +24,15 @@
#include "cm-regbits-24xx.h"
#include "sdrc.h"
+/* REVISIT: These should be set dynamically for CONFIG_MULTI_OMAP2 */
+#ifdef CONFIG_ARCH_OMAP2420
+#define OMAP24XX_PRCM_CLKOUT_CTRL OMAP2420_PRCM_CLKOUT_CTRL
+#define OMAP24XX_PRCM_CLKEMUL_CTRL OMAP2420_PRCM_CLKEMUL_CTRL
+#else
+#define OMAP24XX_PRCM_CLKOUT_CTRL OMAP2430_PRCM_CLKOUT_CTRL
+#define OMAP24XX_PRCM_CLKEMUL_CTRL OMAP2430_PRCM_CLKEMUL_CTRL
+#endif
+
static unsigned long omap2_table_mpu_recalc(struct clk *clk);
static int omap2_select_table_rate(struct clk *clk, unsigned long rate);
static long omap2_round_to_table_rate(struct clk *clk, unsigned long rate);
diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h
index 65fdf78..efc082a 100644
--- a/arch/arm/mach-omap2/cm.h
+++ b/arch/arm/mach-omap2/cm.h
@@ -38,6 +38,7 @@
#define OMAP3430_CM_SYSCONFIG OMAP_CM_REGADDR(OCP_MOD, 0x0010)
#define OMAP3430_CM_POLCTRLOMAP_CM_REGADDR(OCP_MOD, 0x009c)
+#define OMAP3_CM_CLKOUT_CTRL_OFFSET0x0070
#define OMAP3430_CM_CLKOUT_CTRL
OMAP_CM_REGADDR(OMAP3430_C
[PATCH 1/5] ARM: OMAP2/3: Remove OMAP2_32KSYNCT_BASE
Use processor specific defines instead.
As an extra bonus, this patch fixes the problem of CONFIG_DEBUG_SPINLOCK
calling sched_clock before we have things initialized:
http://patchwork.kernel.org/patch/15810/
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/sram242x.S |4 +-
arch/arm/mach-omap2/sram243x.S |4 +-
arch/arm/plat-omap/common.c| 69
arch/arm/plat-omap/include/mach/omap24xx.h |2 -
arch/arm/plat-omap/include/mach/omap34xx.h |1
5 files changed, 62 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/sram242x.S b/arch/arm/mach-omap2/sram242x.S
index af4bd34..cbb8930 100644
--- a/arch/arm/mach-omap2/sram242x.S
+++ b/arch/arm/mach-omap2/sram242x.S
@@ -128,7 +128,7 @@ omap242x_sdi_prcm_voltctrl:
prcm_mask_val:
.word 0x3FFC
omap242x_sdi_timer_32ksynct_cr:
- .word IO_ADDRESS(OMAP2_32KSYNCT_BASE + 0x010)
+ .word IO_ADDRESS(OMAP2420_32KSYNCT_BASE + 0x010)
ENTRY(omap242x_sram_ddr_init_sz)
.word . - omap242x_sram_ddr_init
@@ -224,7 +224,7 @@ omap242x_srs_prcm_voltctrl:
ddr_prcm_mask_val:
.word 0x3FFC
omap242x_srs_timer_32ksynct:
- .word IO_ADDRESS(OMAP2_32KSYNCT_BASE + 0x010)
+ .word IO_ADDRESS(OMAP2420_32KSYNCT_BASE + 0x010)
ENTRY(omap242x_sram_reprogram_sdrc_sz)
.word . - omap242x_sram_reprogram_sdrc
diff --git a/arch/arm/mach-omap2/sram243x.S b/arch/arm/mach-omap2/sram243x.S
index 84363e2..054b0f3 100644
--- a/arch/arm/mach-omap2/sram243x.S
+++ b/arch/arm/mach-omap2/sram243x.S
@@ -128,7 +128,7 @@ omap243x_sdi_prcm_voltctrl:
prcm_mask_val:
.word 0x3FFC
omap243x_sdi_timer_32ksynct_cr:
- .word IO_ADDRESS(OMAP2_32KSYNCT_BASE + 0x010)
+ .word IO_ADDRESS(OMAP2430_32KSYNCT_BASE + 0x010)
ENTRY(omap243x_sram_ddr_init_sz)
.word . - omap243x_sram_ddr_init
@@ -224,7 +224,7 @@ omap243x_srs_prcm_voltctrl:
ddr_prcm_mask_val:
.word 0x3FFC
omap243x_srs_timer_32ksynct:
- .word IO_ADDRESS(OMAP2_32KSYNCT_BASE + 0x010)
+ .word IO_ADDRESS(OMAP2430_32KSYNCT_BASE + 0x010)
ENTRY(omap243x_sram_reprogram_sdrc_sz)
.word . - omap243x_sram_reprogram_sdrc
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 433021f..e1add78 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -175,25 +175,61 @@ console_initcall(omap_add_serial_console);
* but systems won't necessarily want to spend resources that way.
*/
-#if defined(CONFIG_ARCH_OMAP16XX)
-#define TIMER_32K_SYNCHRONIZED 0xfffbc410
-#elif defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
-#define TIMER_32K_SYNCHRONIZED (OMAP2_32KSYNCT_BASE + 0x10)
-#endif
+#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410
-#ifdef TIMER_32K_SYNCHRONIZED
+#if !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX))
#include
-static cycle_t omap_32k_read(struct clocksource *cs)
+#ifdef CONFIG_ARCH_OMAP16XX
+static cycle_t omap16xx_32k_read(struct clocksource *cs)
+{
+ return omap_readl(OMAP16XX_TIMER_32K_SYNCHRONIZED);
+}
+#else
+#define omap16xx_32k_read NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2420
+static cycle_t omap2420_32k_read(struct clocksource *cs)
+{
+ return omap_readl(OMAP2420_32KSYNCT_BASE + 0x10);
+}
+#else
+#define omap2420_32k_read NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2430
+static cycle_t omap2430_32k_read(struct clocksource *cs)
+{
+ return omap_readl(OMAP2430_32KSYNCT_BASE + 0x10);
+}
+#else
+#define omap2430_32k_read NULL
+#endif
+
+#ifdef CONFIG_ARCH_OMAP34XX
+static cycle_t omap34xx_32k_read(struct clocksource *cs)
{
- return omap_readl(TIMER_32K_SYNCHRONIZED);
+ return omap_readl(OMAP3430_32KSYNCT_BASE + 0x10);
+}
+#else
+#define omap34xx_32k_read NULL
+#endif
+
+/*
+ * Kernel assumes that sched_clock can be called early but may not have
+ * things ready yet.
+ */
+static cycle_t omap_32k_read_dummy(struct clocksource *cs)
+{
+ return 0;
}
static struct clocksource clocksource_32k = {
.name = "32k_counter",
.rating = 250,
- .read = omap_32k_read,
+ .read = omap_32k_read_dummy,
.mask = CLOCKSOURCE_MASK(32),
.shift = 10,
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
@@ -207,7 +243,7 @@ unsigned long long sched_clock(void)
{
unsigned long long ret;
- ret = (unsigned long long)omap_32k_read(&clocksource_32k);
+ ret = (unsigned long long)clocksource_32k.read(&clocksource_32k);
ret = (ret * clocksource_32k.mult_orig) >> clocksource_32k.shift;
return ret;
}
@@ -220,6 +256,17 @@ static int __init omap_init_clocksource_32k(void)
if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
struct clk *sync_32k_ick;
+ if (cpu_is_omap16xx())
+ clocksource_32k.read
[PATCH 0/5] More omap header clean-up for the merge window after 2.6.30
Hi, This series removes defines that are included from hardware.h via various processor specific headers. The series makes the defines processor specific where possible so they don't trigger recompile and cause blocks for multi-omap booting. After this series, pretty much the only remaining problem code is the clock24xx.h that should have clock registers set dynamically for 2420 and 2430. This series just makes the problem defines local to clock24xx.h. Regards, Tony --- Tony Lindgren (5): ARM: OMAP2/3: Remove OMAP_CM_REGADDR ARM: OMAP2/3: Remove OMAP2_PRCM_BASE ARM: OMAP2/3: Move define of OMAP2_VA_IC_BASE to be local to entry-macro.S ARM: OMAP2/3: Remove OMAP_PRM_REGADDR and OMAP2_PRM_BASE ARM: OMAP2/3: Remove OMAP2_32KSYNCT_BASE arch/arm/mach-omap2/clock.c |4 arch/arm/mach-omap2/clock24xx.c | 21 +-- arch/arm/mach-omap2/clock24xx.h | 11 + arch/arm/mach-omap2/clock34xx.h |2 arch/arm/mach-omap2/cm.h |6 - arch/arm/mach-omap2/prm.h | 205 +++-- arch/arm/mach-omap2/sdrc2xxx.c|5 - arch/arm/mach-omap2/sram242x.S| 10 + arch/arm/mach-omap2/sram243x.S| 10 + arch/arm/plat-omap/common.c | 69 +++- arch/arm/plat-omap/include/mach/entry-macro.S |9 + arch/arm/plat-omap/include/mach/omap24xx.h| 18 -- arch/arm/plat-omap/include/mach/omap34xx.h|9 - 13 files changed, 232 insertions(+), 147 deletions(-) -- Signature -- 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 OMAP LEGACY CODE: Reset mach-omap1/board-*.c files to mainline" breaks nokia770
Quoting Tony Lindgren :
* Felipe Balbi [090514 01:15]:
On Thu, May 14, 2009 at 03:44:14AM +0200, ext Tony Lindgren wrote:
> * Felipe Balbi [090513 17:33]:
> > On Thu, May 14, 2009 at 01:46:51AM +0200, ext Andrew de Quincey wrote:
> > > Hi, I've just discovered that the patch at:
> > >
> > >
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=3eae3ea7c443fc4330574dffea65b6f2f53a2574
> > >
> > > Breaks the nokia770's framebuffer as it removes the platform data for
> > > the HWA742 LCD controller.
> > >
> > > As the patch says "Patches against the mainline tree are welcome to
> > > add back the missing functionality if needed!", I'm happy to do this.
> > >
> > > However, since I'm fairly new to the linux-omap project, is simply
> > > extracting the removed nokia770 code and generating a patch against
> > > the mainline kernel sufficient? or is there a newer style of some sort
> > > that should be adopted for this?
> >
> > You can start by generating the new patch against mainline and running
> > scripts/checkpatch.pl, then you should probably find out if there are
> > any API changes and stuff like that. Then send the patch to lkml ccing
> > linux-omap and let's see what comments do you get from those guys :-)
>
> Please change the code to pass the struct clock to
drivers/video/omap/hwa742.c
> in hwa742_platform_data. The hw742.c can just do standard
clk_enable/disable
> there. Otherwise we won't be able to get this missing part to the mainline
> kernel.
how about clkdev then ? are we gonna support that for omap1 still ?
Yeah the clkdev is there, but in the case of the LCD the clock can be
any clock, so we cannot set just one "fck" for all the omap1 LCD panels.
In this case the "bclk" is used for the LCD, but "bclk" could be used
for other devices as well, not just LCD.
Hi, is the attached patch the sort of thing you had in mind? This is
against linux-omap-2.6, latest git.
Unfortunately, both mainline linux-2.6 and linux-omap-2.6 gits lock up
on bootup before the LCD is initialised. However, the linux-omap
2.6.29 that is compiled by openembedded still boots ok, and with the
attached patch applied, the LCD works again!
I guess my next task is to figure out why the mainline kernels freeze;
I've seen that before, and it seemed to be something to do with
changes to the mcbsp support.
Reinstate HWA742 platform data for nokia 770 platform.
Signed-off-by: Andrew de Quincey
diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
index 8780ca6..df5f38b 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -163,6 +164,26 @@ static struct spi_board_info nokia770_spi_board_info[] __initdata = {
},
};
+static struct hwa742_platform_data nokia770_hwa742_platform_data = {
+ .sys_ck = NULL,
+ .te_connected = 1,
+};
+
+static int hwa742_get_clocks(void)
+{
+ nokia770_hwa742_platform_data.sys_ck = clk_get(NULL, "bclk");
+ if (IS_ERR(nokia770_hwa742_platform_data.sys_ck)) {
+ printk(KERN_ERR "can't get HWA742 clock\n");
+ return PTR_ERR(nokia770_hwa742_platform_data.sys_ck);
+ }
+ return 0;
+}
+
+static void hwa742_dev_init(void)
+{
+ hwa742_get_clocks();
+ omapfb_set_ctrl_platform_data(&nokia770_hwa742_platform_data);
+}
/* assume no Mini-AB port */
@@ -371,6 +392,7 @@ static void __init omap_nokia770_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, NULL, 0);
omap_dsp_init();
+ hwa742_dev_init();
ads7846_dev_init();
mipid_dev_init();
omap_usb_init(&nokia770_usb_config);
diff --git a/arch/arm/plat-omap/include/mach/hwa742.h b/arch/arm/plat-omap/include/mach/hwa742.h
index 577f492..c00e05d 100644
--- a/arch/arm/plat-omap/include/mach/hwa742.h
+++ b/arch/arm/plat-omap/include/mach/hwa742.h
@@ -2,10 +2,7 @@
#define _HWA742_H
struct hwa742_platform_data {
- void (*power_up)(struct device *dev);
- void (*power_down)(struct device *dev);
- unsigned long (*get_clock_rate)(struct device *dev);
-
+ struct clk *sys_ck;
unsigned te_connected:1;
};
diff --git a/drivers/video/omap/hwa742.c b/drivers/video/omap/hwa742.c
index 8aa6e47..1230476 100644
--- a/drivers/video/omap/hwa742.c
+++ b/drivers/video/omap/hwa742.c
@@ -133,8 +133,7 @@ struct {
struct lcd_ctrl_extif *extif;
struct lcd_ctrl *int_ctrl;
- void (*power_up)(struct device *dev);
- void (*power_down)(struct device *dev);
+ struct clk *sys_ck;
} hwa742;
struct lcd_ctrl hwa742_ctrl;
@@ -915,14 +914,13 @@ static void hwa742_suspend(void)
hwa742_set_update_mode(OMAPFB_UPDATE_DISABLED);
/* Enable sleep mode */
hwa742_write_reg(HWA742_POWER_SAVE, 1 << 1);
- if (hwa742.power_down != NULL)
- hwa742.power_down(hwa742.fbdev->dev);
+ clk_disable(hwa742.sys_ck);
}
static void hwa742_resume(void)
{
- if (hwa742.power_up != NULL)
- hwa742.power_up(hwa742.fbdev->dev);
+ clk_enable(h
Re: [PATCH omap3-upstream] OMAP: PM: add PRCM register offsets
* Kevin Hilman [090514 15:36]: > Add _OFFSET #defines for the PRCM registers to be used with the > prm_[read|write]_* macros. These are used extensively in the > forthcoming OMAP PM support. Thanks, I've merged this into "Remove OMAP_PRM_REGADDR and OMAP2_PRM_BASE", will post the series with LAKML Cc'd for review. Tony > Signed-off-by: Kevin Hilman > --- > arch/arm/mach-omap2/clock.c|4 +- > arch/arm/mach-omap2/cm.h |1 + > arch/arm/mach-omap2/prm.h | 69 ++- > arch/arm/mach-omap2/sram242x.S |6 ++-- > arch/arm/mach-omap2/sram243x.S |6 ++-- > 5 files changed, 62 insertions(+), 24 deletions(-) > > diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c > index 4247a15..dd37483 100644 > --- a/arch/arm/mach-omap2/clock.c > +++ b/arch/arm/mach-omap2/clock.c > @@ -91,9 +91,9 @@ static void _omap2xxx_clk_commit(struct clk *clk) > return; > > prm_write_mod_reg(OMAP24XX_VALID_CONFIG, OMAP24XX_GR_MOD, > - OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET); > + OMAP2_PRCM_CLKCFG_CTRL_OFFSET); > /* OCP barrier */ > - prm_read_mod_reg(OMAP24XX_GR_MOD, OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET); > + prm_read_mod_reg(OMAP24XX_GR_MOD, OMAP2_PRCM_CLKCFG_CTRL_OFFSET); > } > > /* > diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h > index 04c5fc5..1d3c93b 100644 > --- a/arch/arm/mach-omap2/cm.h > +++ b/arch/arm/mach-omap2/cm.h > @@ -33,6 +33,7 @@ > #define OMAP3430_CM_SYSCONFIGOMAP_CM_REGADDR(OCP_MOD, 0x0010) > #define OMAP3430_CM_POLCTRL OMAP_CM_REGADDR(OCP_MOD, 0x009c) > > +#define OMAP3_CM_CLKOUT_CTRL_OFFSET 0x0070 > #define OMAP3430_CM_CLKOUT_CTRL > OMAP_CM_REGADDR(OMAP3430_CCR_MOD, 0x0070) > > /* > diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h > index 2eb8399..7c8e0c4 100644 > --- a/arch/arm/mach-omap2/prm.h > +++ b/arch/arm/mach-omap2/prm.h > @@ -33,36 +33,35 @@ > * > */ > > -/* Global 24xx registers in GR_MOD (Same as OCP_MOD for 24xx) */ > -#define OMAP24XX_PRCM_VOLTCTRL_OFFSET0x0050 > -#define OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET 0x0080 > - > -/* 242x GR_MOD registers, use these only for assembly code */ > -#define OMAP242X_PRCM_VOLTCTRL > OMAP2420_PRM_REGADDR(OMAP24XX_GR_MOD, \ > - OMAP24XX_PRCM_VOLTCTRL_OFFSET) > -#define OMAP242X_PRCM_CLKCFG_CTRLOMAP2420_PRM_REGADDR(OMAP24XX_GR_MOD, > \ > - > OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET) > - > -/* 243x GR_MOD registers, use these only for assembly code */ > -#define OMAP243X_PRCM_VOLTCTRL > OMAP2430_PRM_REGADDR(OMAP24XX_GR_MOD, \ > - OMAP24XX_PRCM_VOLTCTRL_OFFSET) > -#define OMAP243X_PRCM_CLKCFG_CTRLOMAP2430_PRM_REGADDR(OMAP24XX_GR_MOD, > \ > - > OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET) > - > +#define OMAP2_PRCM_REVISION_OFFSET 0x > #define OMAP2420_PRCM_REVISION OMAP2420_PRM_REGADDR(OCP_MOD, > 0x) > +#define OMAP2_PRCM_SYSCONFIG_OFFSET 0x0010 > #define OMAP2420_PRCM_SYSCONFIG OMAP2420_PRM_REGADDR(OCP_MOD, > 0x0010) > > +#define OMAP2_PRCM_IRQSTATUS_MPU_OFFSET 0x0018 > #define OMAP2420_PRCM_IRQSTATUS_MPU OMAP2420_PRM_REGADDR(OCP_MOD, 0x0018) > +#define OMAP2_PRCM_IRQENABLE_MPU_OFFSET 0x001c > #define OMAP2420_PRCM_IRQENABLE_MPU OMAP2420_PRM_REGADDR(OCP_MOD, 0x001c) > > +#define OMAP2_PRCM_VOLTCTRL_OFFSET 0x0050 > +#define OMAP2420_PRCM_VOLTCTRL OMAP2420_PRM_REGADDR(OCP_MOD, > 0x0050) > +#define OMAP2_PRCM_VOLTST_OFFSET 0x0054 > #define OMAP2420_PRCM_VOLTST OMAP2420_PRM_REGADDR(OCP_MOD, 0x0054) > +#define OMAP2_PRCM_CLKSRC_CTRL_OFFSET0x0060 > #define OMAP2420_PRCM_CLKSRC_CTRLOMAP2420_PRM_REGADDR(OCP_MOD, 0x0060) > +#define OMAP2_PRCM_CLKOUT_CTRL_OFFSET0x0070 > #define OMAP2420_PRCM_CLKOUT_CTRLOMAP2420_PRM_REGADDR(OCP_MOD, 0x0070) > +#define OMAP2_PRCM_CLKEMUL_CTRL_OFFSET 0x0078 > #define OMAP2420_PRCM_CLKEMUL_CTRL OMAP2420_PRM_REGADDR(OCP_MOD, 0x0078) > +#define OMAP2_PRCM_CLKCFG_CTRL_OFFSET0x0080 > #define OMAP2420_PRCM_CLKCFG_CTRLOMAP2420_PRM_REGADDR(OCP_MOD, 0x0080) > +#define OMAP2_PRCM_CLKCFG_STATUS_OFFSET 0x0084 > #define OMAP2420_PRCM_CLKCFG_STATUS OMAP2420_PRM_REGADDR(OCP_MOD, 0x0084) > +#define OMAP2_PRCM_VOLTSETUP_OFFSET 0x0090 > #define OMAP2420_PRCM_VOLTSETUP OMAP2420_PRM_REGADDR(OCP_MOD, > 0x0090) > +#define OMAP2_PRCM_CLKSSETUP_OFFSET 0x0094 > #define OMAP2420_PRCM_CLKSSETUP OMAP2420_PRM_REGADDR(OCP_MOD, > 0x0094) > +#define OMAP2_PRCM_POLCTRL_OFFSET0x0098 > #define OMAP2420_PRCM_POLCTRLOMAP2420_PRM_REGADDR(OCP_MOD, > 0x0098) > > #define OMAP2430_PRCM_REVISION OMAP2430_PRM_REGADDR(OCP_MOD, > 0x)
[PATCH omap3-upstream] OMAP: PM: add PRCM register offsets
Add _OFFSET #defines for the PRCM registers to be used with the prm_[read|write]_* macros. These are used extensively in the forthcoming OMAP PM support. Signed-off-by: Kevin Hilman --- arch/arm/mach-omap2/clock.c|4 +- arch/arm/mach-omap2/cm.h |1 + arch/arm/mach-omap2/prm.h | 69 ++- arch/arm/mach-omap2/sram242x.S |6 ++-- arch/arm/mach-omap2/sram243x.S |6 ++-- 5 files changed, 62 insertions(+), 24 deletions(-) diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c index 4247a15..dd37483 100644 --- a/arch/arm/mach-omap2/clock.c +++ b/arch/arm/mach-omap2/clock.c @@ -91,9 +91,9 @@ static void _omap2xxx_clk_commit(struct clk *clk) return; prm_write_mod_reg(OMAP24XX_VALID_CONFIG, OMAP24XX_GR_MOD, - OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET); + OMAP2_PRCM_CLKCFG_CTRL_OFFSET); /* OCP barrier */ - prm_read_mod_reg(OMAP24XX_GR_MOD, OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET); + prm_read_mod_reg(OMAP24XX_GR_MOD, OMAP2_PRCM_CLKCFG_CTRL_OFFSET); } /* diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index 04c5fc5..1d3c93b 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -33,6 +33,7 @@ #define OMAP3430_CM_SYSCONFIG OMAP_CM_REGADDR(OCP_MOD, 0x0010) #define OMAP3430_CM_POLCTRLOMAP_CM_REGADDR(OCP_MOD, 0x009c) +#define OMAP3_CM_CLKOUT_CTRL_OFFSET0x0070 #define OMAP3430_CM_CLKOUT_CTRL OMAP_CM_REGADDR(OMAP3430_CCR_MOD, 0x0070) /* diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h index 2eb8399..7c8e0c4 100644 --- a/arch/arm/mach-omap2/prm.h +++ b/arch/arm/mach-omap2/prm.h @@ -33,36 +33,35 @@ * */ -/* Global 24xx registers in GR_MOD (Same as OCP_MOD for 24xx) */ -#define OMAP24XX_PRCM_VOLTCTRL_OFFSET 0x0050 -#define OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET 0x0080 - -/* 242x GR_MOD registers, use these only for assembly code */ -#define OMAP242X_PRCM_VOLTCTRL OMAP2420_PRM_REGADDR(OMAP24XX_GR_MOD, \ - OMAP24XX_PRCM_VOLTCTRL_OFFSET) -#define OMAP242X_PRCM_CLKCFG_CTRL OMAP2420_PRM_REGADDR(OMAP24XX_GR_MOD, \ - OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET) - -/* 243x GR_MOD registers, use these only for assembly code */ -#define OMAP243X_PRCM_VOLTCTRL OMAP2430_PRM_REGADDR(OMAP24XX_GR_MOD, \ - OMAP24XX_PRCM_VOLTCTRL_OFFSET) -#define OMAP243X_PRCM_CLKCFG_CTRL OMAP2430_PRM_REGADDR(OMAP24XX_GR_MOD, \ - OMAP24XX_PRCM_CLKCFG_CTRL_OFFSET) - +#define OMAP2_PRCM_REVISION_OFFSET 0x #define OMAP2420_PRCM_REVISION OMAP2420_PRM_REGADDR(OCP_MOD, 0x) +#define OMAP2_PRCM_SYSCONFIG_OFFSET0x0010 #define OMAP2420_PRCM_SYSCONFIGOMAP2420_PRM_REGADDR(OCP_MOD, 0x0010) +#define OMAP2_PRCM_IRQSTATUS_MPU_OFFSET0x0018 #define OMAP2420_PRCM_IRQSTATUS_MPUOMAP2420_PRM_REGADDR(OCP_MOD, 0x0018) +#define OMAP2_PRCM_IRQENABLE_MPU_OFFSET0x001c #define OMAP2420_PRCM_IRQENABLE_MPUOMAP2420_PRM_REGADDR(OCP_MOD, 0x001c) +#define OMAP2_PRCM_VOLTCTRL_OFFSET 0x0050 +#define OMAP2420_PRCM_VOLTCTRL OMAP2420_PRM_REGADDR(OCP_MOD, 0x0050) +#define OMAP2_PRCM_VOLTST_OFFSET 0x0054 #define OMAP2420_PRCM_VOLTST OMAP2420_PRM_REGADDR(OCP_MOD, 0x0054) +#define OMAP2_PRCM_CLKSRC_CTRL_OFFSET 0x0060 #define OMAP2420_PRCM_CLKSRC_CTRL OMAP2420_PRM_REGADDR(OCP_MOD, 0x0060) +#define OMAP2_PRCM_CLKOUT_CTRL_OFFSET 0x0070 #define OMAP2420_PRCM_CLKOUT_CTRL OMAP2420_PRM_REGADDR(OCP_MOD, 0x0070) +#define OMAP2_PRCM_CLKEMUL_CTRL_OFFSET 0x0078 #define OMAP2420_PRCM_CLKEMUL_CTRL OMAP2420_PRM_REGADDR(OCP_MOD, 0x0078) +#define OMAP2_PRCM_CLKCFG_CTRL_OFFSET 0x0080 #define OMAP2420_PRCM_CLKCFG_CTRL OMAP2420_PRM_REGADDR(OCP_MOD, 0x0080) +#define OMAP2_PRCM_CLKCFG_STATUS_OFFSET0x0084 #define OMAP2420_PRCM_CLKCFG_STATUSOMAP2420_PRM_REGADDR(OCP_MOD, 0x0084) +#define OMAP2_PRCM_VOLTSETUP_OFFSET0x0090 #define OMAP2420_PRCM_VOLTSETUPOMAP2420_PRM_REGADDR(OCP_MOD, 0x0090) +#define OMAP2_PRCM_CLKSSETUP_OFFSET0x0094 #define OMAP2420_PRCM_CLKSSETUPOMAP2420_PRM_REGADDR(OCP_MOD, 0x0094) +#define OMAP2_PRCM_POLCTRL_OFFSET 0x0098 #define OMAP2420_PRCM_POLCTRL OMAP2420_PRM_REGADDR(OCP_MOD, 0x0098) #define OMAP2430_PRCM_REVISION OMAP2430_PRM_REGADDR(OCP_MOD, 0x) @@ -71,6 +70,7 @@ #define OMAP2430_PRCM_IRQSTATUS_MPUOMAP2430_PRM_REGADDR(OCP_MOD, 0x0018) #define OMAP2430_PRCM_IRQENABLE_MPUOMAP2430_PRM_REGADDR(OCP_MOD, 0x001c) +#define OMAP2430_PRCM_VOLTCTRL OMAP2430_PRM_REGADDR(OCP_MOD, 0x0050) #define OMAP2430_PRCM_VOLTST OMAP2430_PRM_REGADDR(OCP_MOD, 0x0054) #define OMAP2430_PRCM_CLKSRC_CTRL OMAP2430_PRM_
Re: [PATCH] ARM: OMAP: Fix path for omap-sha1-md5 import of irqs.h
* Mike Auty [090514 14:52]: > > Sorry for the delay.. I'll apply this to linux-omap tree. Do you want > > to take this driver and prepare a patch to the associated driver mailing > > list so we can get it integrated? > > Errr, I'm not sure what that entails? What would I have to do? It's > really such a trivial fix, I wasn't sure it needed a patch at all. I > can do something extra if that's necessary, but I was really just > reporting it since I thought someone should know... Well if you want to do some Linux stuff that's a good way to get started :) Just see who maintains the those kind of drivers and prepare the patch against mainline tree and send it to the maintainer with the right driver mailing list Cc'd and linux-omap list Cc'd. Then fix the comments if needed. That's all it takes. Be sure to read Documentation/Submit* files, and run your patch through checkpatch.pl first.. 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] ARM: OMAP: Fix path for omap-sha1-md5 import of irqs.h
> Sorry for the delay.. I'll apply this to linux-omap tree. Do you want > to take this driver and prepare a patch to the associated driver mailing > list so we can get it integrated? Errr, I'm not sure what that entails? What would I have to do? It's really such a trivial fix, I wasn't sure it needed a patch at all. I can do something extra if that's necessary, but I was really just reporting it since I thought someone should know... Mike 5:) -- 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] omap2: off by 1
On Wed, 25 Feb 2009, Roel Kluin wrote:
> with while (i++ < MAX_CLOCK_ENABLE_WAIT); i can reach MAX_CLOCK_ENABLE_WAIT +
> 1
> after the loop, so if (i == MAX_CLOCK_ENABLE_WAIT) that's still success.
Hi Roel
it's a worst-case bailout value that is significantly larger than it needs
to be, so being off by 1 doesn't matter here. But I'll take the patch on
pedantic grounds. Queued in the omap-clocks-upstream branch.
- Paul
> Signed-off-by: Roel Kluin
> ---
> arch/arm/mach-omap2/clock.c |2 +-
> arch/arm/mach-omap2/powerdomain.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index ce4d46a..da185ff 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -202,7 +202,7 @@ int omap2_wait_clock_ready(void __iomem *reg, u32 mask,
> const char *name)
> udelay(1);
> }
>
> - if (i < MAX_CLOCK_ENABLE_WAIT)
> + if (i <= MAX_CLOCK_ENABLE_WAIT)
> pr_debug("Clock %s stable after %d loops\n", name, i);
> else
> printk(KERN_ERR "Clock %s didn't enable in %d tries\n",
> diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> index 73e2971..983f1cb 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -1099,7 +1099,7 @@ int pwrdm_wait_transition(struct powerdomain *pwrdm)
> (c++ < PWRDM_TRANSITION_BAILOUT))
> udelay(1);
>
> - if (c >= PWRDM_TRANSITION_BAILOUT) {
> + if (c > PWRDM_TRANSITION_BAILOUT) {
> printk(KERN_ERR "powerdomain: waited too long for "
> "powerdomain %s to complete transition\n", pwrdm->name);
> return -EAGAIN;
> --
> 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 v2 0/2] PM: OMAP3 SDRC: fix some SDRAM settings for Qimonda parts
On Thu, 14 May 2009, Tony Lindgren wrote: > * Paul Walmsley [090514 12:52]: > > Hi, > > > > This series updates some SDRAM parameter settings for the Qimonda parts > > used on some 3430SDP boards. > > > > Drop the 133.3MHz/66.6MHz rates from the Qimonda SDRAM file - these were > > only > > used on some early Labrador boards with slower SDRAM parts. Thanks to > > Richard Woodruff for help with this patch. > > > > Finally some 3430SDP boards are using bootloaders with rounded DPLL3 rates > > (e.g., 16600 Hz rather than 165941176 Hz); update the Qimonda SDRAM > > parameters. This resolves -EINVALs during boot-time "Reprogramming SDRC" > > on 3430SDPs with updated bootloaders. Thanks to Kevin Hilman > > for reporting this issue and testing > > the patch. > > > > These patches will be queued up into the omap-clock-testing branch at the > > next opportunity. > > I've merged these two patches already into your older sdram patches > in the omap3-upstream queue. Sweet! Thanks! - 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 v2 0/2] PM: OMAP3 SDRC: fix some SDRAM settings for Qimonda parts
* Paul Walmsley [090514 12:52]: > Hi, > > This series updates some SDRAM parameter settings for the Qimonda parts > used on some 3430SDP boards. > > Drop the 133.3MHz/66.6MHz rates from the Qimonda SDRAM file - these were only > used on some early Labrador boards with slower SDRAM parts. Thanks to > Richard Woodruff for help with this patch. > > Finally some 3430SDP boards are using bootloaders with rounded DPLL3 rates > (e.g., 16600 Hz rather than 165941176 Hz); update the Qimonda SDRAM > parameters. This resolves -EINVALs during boot-time "Reprogramming SDRC" > on 3430SDPs with updated bootloaders. Thanks to Kevin Hilman > for reporting this issue and testing > the patch. > > These patches will be queued up into the omap-clock-testing branch at the > next opportunity. I've merged these two patches already into your older sdram patches in the omap3-upstream queue. 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
[APPLIED] [PATCH] RX51: Remove multiple definition of MACH_NOKIA_RX51 in
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): f6ea2bbc8d4346c3a263ed86a92435d67f652809 PatchWorks http://patchwork.kernel.org/patch/20615/ 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=f6ea2bbc8d4346c3a263ed86a92435d67f652809 -- 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] I2C:Moving Register Defines to Header File
* Jagadeesh Bhaskar Pakaravoor [090514 03:34]: > > IMO, The regs do not need to move to a separate header unless they will > > be used outside of i2c-omap.c. > > > Would it not be cleaner to move them to a separate header file, > especially considering the fact that we have some 19 registers for > OMAP3 I2C and when we redefine them for OMAP4, there would be 38 > (infact 40, including the two new registers) lines of just register > definitions at the top of the file? I agree with Kevin, unless the defines are used in other files there should not be need for having a separate header file. 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
[APPLIED] [PATCH v2 2/2] OMAP3 SDRC: Add rounded rates for devices using the
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): c82881eac1c6999abd768c548ad196c1973d3a55 PatchWorks http://patchwork.kernel.org/patch/23825/ 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=c82881eac1c6999abd768c548ad196c1973d3a55 -- 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 v2 1/2] OMAP3 SDRC: Drop 133.3MHz,
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): e0d613947b647e278de15e71fe57ab59eab3e82a PatchWorks http://patchwork.kernel.org/patch/23826/ 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=e0d613947b647e278de15e71fe57ab59eab3e82a -- 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 6/8] ARM: OMAP2/3: Change omapfb to use clkdev for dispc and rfbi
* Krzysztof Helt [090514 11:57]:
> On Thu, 14 May 2009 10:49:59 -0700
> Tony Lindgren wrote:
>
> > This makes the framebuffer work on omap3.
> >
> > Also fix the clk_get usage for checkpatch.pl
> > "ERROR: do not use assignment in if condition".
> >
> > Cc: Imre Deak
> > Cc: linux-fbdev-de...@lists.sourceforge.net
> > Signed-off-by: Tony Lindgren
> > ---
>
> Acked-by: Krzysztof Helt
Thanks for looking. Here's v2 of the patch with one line fixed below.
> > --- a/drivers/video/omap/dispc.c
> > +++ b/drivers/video/omap/dispc.c
> > @@ -880,23 +880,25 @@ static irqreturn_t omap_dispc_irq_handler(int irq,
> > void *dev)
> >
> > static int get_dss_clocks(void)
> > {
> > - if (IS_ERR((dispc.dss_ick = clk_get(dispc.fbdev->dev, "dss_ick" {
> > - dev_err(dispc.fbdev->dev, "can't get dss_ick\n");
> > + dispc.dss_ick = clk_get(dispc.fbdev->dev, "ick");
> > + if (IS_ERR(dispc.dss_ick)) {
> > + dev_err(dispc.fbdev->dev, "can't get ick\n");
> > return PTR_ERR(dispc.dss_ick);
> > }
> >
> > - if (IS_ERR((dispc.dss1_fck = clk_get(dispc.fbdev->dev, "dss1_fck" {
> > + dispc.dss1_fck = clk_get(dispc.fbdev->dev, "dss1_fck");
> > + if (IS_ERR(dispc.dss1_fck)) {
> > dev_err(dispc.fbdev->dev, "can't get dss1_fck\n");
> > clk_put(dispc.dss_ick);
> > return PTR_ERR(dispc.dss1_fck);
> > }
> >
> > - if (IS_ERR((dispc.dss_54m_fck =
> > - clk_get(dispc.fbdev->dev, "dss_54m_fck" {
> > - dev_err(dispc.fbdev->dev, "can't get dss_54m_fck\n");
> > + dispc.dss_54m_fck = clk_get(dispc.fbdev->dev, "tv_fck");
> > + if (IS_ERR(dispc.dss_54m_fck)) {
> > + dev_err(dispc.fbdev->dev, "can't get tv_fck\n");
> > clk_put(dispc.dss_ick);
> > clk_put(dispc.dss1_fck);
> > - return PTR_ERR(dispc.dss_54m_fck);
> > +
> > }
The return PTR_ERR(dispc.dss_54m_fck) should not be left out.
Regards,
Tony
commit 27db33cfadd3c47c9499def6e71aaf5d2fd51e60
Author: Tony Lindgren
Date: Tue May 12 11:20:03 2009 -0700
ARM: OMAP2/3: Change omapfb to use clkdev for dispc and rfbi, v2
This makes the framebuffer work on omap3.
Also fix the clk_get usage for checkpatch.pl
"ERROR: do not use assignment in if condition".
Cc: Imre Deak
Cc: linux-fbdev-de...@lists.sourceforge.net
Acked-by: Krzysztof Helt
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index ff9b4c0..e4cef33 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -103,10 +103,10 @@ static struct omap_clk omap24xx_clks[] = {
CLK(NULL, "mdm_ick", &mdm_ick, CK_243X),
CLK(NULL, "mdm_osc_ck", &mdm_osc_ck, CK_243X),
/* DSS domain clocks */
- CLK(NULL, "dss_ick", &dss_ick, CK_243X | CK_242X),
- CLK(NULL, "dss1_fck", &dss1_fck, CK_243X | CK_242X),
- CLK(NULL, "dss2_fck", &dss2_fck, CK_243X | CK_242X),
- CLK(NULL, "dss_54m_fck", &dss_54m_fck, CK_243X | CK_242X),
+ CLK("omapfb", "ick", &dss_ick, CK_243X | CK_242X),
+ CLK("omapfb", "dss1_fck", &dss1_fck, CK_243X | CK_242X),
+ CLK("omapfb", "dss2_fck", &dss2_fck, CK_243X | CK_242X),
+ CLK("omapfb", "tv_fck", &dss_54m_fck, CK_243X | CK_242X),
/* L3 domain clocks */
CLK(NULL, "core_l3_ck", &core_l3_ck, CK_243X | CK_242X),
CLK(NULL, "ssi_fck", &ssi_ssr_sst_fck, CK_243X | CK_242X),
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index a057539..ba05aa4 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -197,11 +197,11 @@ static struct omap_clk omap34xx_clks[] = {
CLK("omap_rng", "ick", &rng_ick, CK_343X),
CLK(NULL, "sha11_ick", &sha11_ick, CK_343X),
CLK(NULL, "des1_ick", &des1_ick, CK_343X),
- CLK(NULL, "dss1_alwon_fck", &dss1_alwon_fck, CK_343X),
- CLK(NULL, "dss_tv_fck", &dss_tv_fck, CK_343X),
- CLK(NULL, "dss_96m_fck", &dss_96m_fck, CK_343X),
- CLK(NULL, "dss2_alwon_fck", &dss2_alwon_fck, CK_343X),
- CLK(NULL, "dss_ick", &dss_ick, CK_343X),
+ CLK("omapfb", "dss1_fck", &dss1_alwon_fck, CK_343X),
+ CLK("omapfb", "tv_fck", &dss_tv_fck, CK_343X),
+ CLK("omapfb", "video_fck", &dss_96m_fck, CK_343X),
+ CLK("omapfb", "dss2_fck", &dss2_alwon_fck, CK_343X),
+ CLK("omapfb", "ick", &dss_ick, CK_343X),
CLK(NULL, "cam_mclk", &cam_mclk, CK_343X),
CLK(NULL, "cam_ick", &cam_ick, CK_343X),
CLK(NULL, "csi2_96m_fck", &csi2_96m_fck, CK_343X),
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index dfb72f5..148cbcc 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -880,20 +880,22 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void *dev)
static int get_dss_clocks(void)
{
- if (IS_ERR((dispc.dss_ick = clk_get(dispc.fbdev->dev, "dss_ick" {
- dev_err(dispc.fbdev->dev, "can't get dss_ick\n");
+ dispc.dss_ick = clk_get(dispc.fbdev->dev, "ick");
+ if (IS_ERR(dispc.dss_ick)) {
+ dev_err(dispc.fbdev->dev, "ca
[PATCH v2 1/2] OMAP3 SDRC: Drop 133.3MHz, 66.6MHz rates from Qimonda SDRAM params file
Boards that used 133.3MHz maximum rate SDRAM were never released to the
public and presumably used the OMAPZoom kernel; so, drop these unused
rates. Viz.:
http://marc.info/?l=linux-omap&m=124232922426311&w=2
This patch is a collaboration between Richard Woodruff
and Paul Walmsley .
Signed-off-by: Paul Walmsley
Cc: Richard Woodruff
---
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 21 +++-
1 files changed, 3 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
index 74a92c8..8b6f929 100644
--- a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
+++ b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
@@ -1,8 +1,8 @@
/*
* SDRC register values for the Qimonda HYB18M512160AF-6
*
- * Copyright (C) 2008 Texas Instruments, Inc.
- * Copyright (C) 2008 Nokia Corporation
+ * Copyright (C) 2008-2009 Texas Instruments, Inc.
+ * Copyright (C) 2008-2009 Nokia Corporation
*
* Paul Walmsley
*
@@ -17,7 +17,6 @@
#include
/* Qimonda HYB18M512160AF-6 */
-/* XXX Using ARE = 0x1 (no autorefresh burst) -- can this be changed? */
static struct omap_sdrc_params hyb18m512160af6_sdrc_params[] = {
[0] = {
.rate= 165941176,
@@ -27,27 +26,13 @@ static struct omap_sdrc_params
hyb18m512160af6_sdrc_params[] = {
.mr = 0x0032,
},
[1] = {
- .rate= 1,
- .actim_ctrla = 0x5219b485,
- .actim_ctrlb = 0x00012210,
- .rfr_ctrl= 0x0003de01,
- .mr = 0x0032,
- },
- [2] = {
.rate= 82970588,
.actim_ctrla = 0x31512283,
.actim_ctrlb = 0x0001220a,
.rfr_ctrl= 0x00025501,
.mr = 0x0022,
},
- [3] = {
- .rate= ,
- .actim_ctrla = 0x290d2243,
- .actim_ctrlb = 0x00012208,
- .rfr_ctrl= 0x0001d601,
- .mr = 0x0022,
- },
- [4] = {
+ [2] = {
.rate= 0
},
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] OMAP3 SDRC: Add rounded rates for devices using the Qimonda SDRAM
The 3430SDPs, many of which use Qimonda SDRAM, are finally using
bootloaders that program rounded rates for DPLL3. Since no SDRAM
memory timings are defined for the rounded rates, the initial SDRC
reprogram during init fails. Add in the correct timings here.
Problem reported by Kevin Hilman .
Signed-off-by: Paul Walmsley
Tested-by: Kevin Hilman
---
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
index 8b6f929..3751d29 100644
--- a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
+++ b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
@@ -19,20 +19,34 @@
/* Qimonda HYB18M512160AF-6 */
static struct omap_sdrc_params hyb18m512160af6_sdrc_params[] = {
[0] = {
- .rate= 165941176,
+ .rate= 16600,
.actim_ctrla = 0x629db4c6,
.actim_ctrlb = 0x00012214,
.rfr_ctrl= 0x0004dc01,
.mr = 0x0032,
},
[1] = {
+ .rate= 165941176,
+ .actim_ctrla = 0x629db4c6,
+ .actim_ctrlb = 0x00012214,
+ .rfr_ctrl= 0x0004dc01,
+ .mr = 0x0032,
+ },
+ [2] = {
+ .rate= 8300,
+ .actim_ctrla = 0x31512283,
+ .actim_ctrlb = 0x0001220a,
+ .rfr_ctrl= 0x00025501,
+ .mr = 0x0022,
+ },
+ [3] = {
.rate= 82970588,
.actim_ctrla = 0x31512283,
.actim_ctrlb = 0x0001220a,
.rfr_ctrl= 0x00025501,
.mr = 0x0022,
},
- [2] = {
+ [4] = {
.rate= 0
},
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] PM: OMAP3 SDRC: fix some SDRAM settings for Qimonda parts
Hi, This series updates some SDRAM parameter settings for the Qimonda parts used on some 3430SDP boards. Drop the 133.3MHz/66.6MHz rates from the Qimonda SDRAM file - these were only used on some early Labrador boards with slower SDRAM parts. Thanks to Richard Woodruff for help with this patch. Finally some 3430SDP boards are using bootloaders with rounded DPLL3 rates (e.g., 16600 Hz rather than 165941176 Hz); update the Qimonda SDRAM parameters. This resolves -EINVALs during boot-time "Reprogramming SDRC" on 3430SDPs with updated bootloaders. Thanks to Kevin Hilman for reporting this issue and testing the patch. These patches will be queued up into the omap-clock-testing branch at the next opportunity. --- size: textdata bss dec hex filename 3667957 196224 113216 3977397 3cb0b5 vmlinux.3430sdp.orig 3667957 196224 113216 3977397 3cb0b5 vmlinux.3430sdp Paul Walmsley (2): OMAP3 SDRC: Add rounded rates for devices using the Qimonda SDRAM OMAP3 SDRC: Drop 133.3MHz, 66.6MHz rates from Qimonda SDRAM params file .../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 25 ++-- 1 files changed, 12 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] PM: OMAP3 SDRC: fix some SDRAM settings for Qimonda parts
On Thu, 14 May 2009, Woodruff, Richard wrote: > > Also when reviewing the timing calculations, it appears that the lowest > > speed > > setting had an error in its autorefresh counter value. I don't know if > > anything out there still uses this low-speed setting - my recollection is > > that it was added for some early Labrador boards that had speed > > restrictions - > > any comments from TI on whether these 133.3MHz/66.6MHz rates should be > > dropped > > is most welcome. > > Alpha LDP board had only 133MHz rated memory on them. These were quickly > replaced with beta then production boards with 166MHz rated memory. > > Probably only a few dumpsters at TI have 133MHz restricted alpha boards (and > maybe at logicpd). I don’t' think you will even find an alpha in plastics. > > Nothing stops a person from running at 133 on the 166 rated parts. But most > won't choose to on a 3430. Great, thanks Richard. Will add a patch to drop those rates... - Paul
RE: [PATCH 0/2] PM: OMAP3 SDRC: fix some SDRAM settings for Qimonda parts
> Also when reviewing the timing calculations, it appears that the lowest speed > setting had an error in its autorefresh counter value. I don't know if > anything out there still uses this low-speed setting - my recollection is > that it was added for some early Labrador boards that had speed restrictions - > any comments from TI on whether these 133.3MHz/66.6MHz rates should be dropped > is most welcome. Alpha LDP board had only 133MHz rated memory on them. These were quickly replaced with beta then production boards with 166MHz rated memory. Probably only a few dumpsters at TI have 133MHz restricted alpha boards (and maybe at logicpd). I don’t' think you will even find an alpha in plastics. Nothing stops a person from running at 133 on the 166 rated parts. But most won't choose to on a 3430. Regards, Richard W.
Re: [PATCH]RESEND:OMAP3:configs: rename sdp and ldp defconfig
Tony Lindgren said the following on 05/14/2009 09:05 PM: > Well we already have products that just have the product > name in the defconfig, like overo_defconfig and n770_defconfig. > > I think we have more urgent patches to get to the mainline tree, > so let's put this on hold. BTW, if you need to find out omap3 > boards, just $ grep CONFIG_ARCH_OMAP3 arch/arm/configs/ > heh ;) sure.. np :) Regards, Nishanth Menon -- 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 SDRC: Add rounded rates for devices using the Qimonda SDRAM
The 3430SDPs, many of which use Qimonda SDRAM, are finally using
bootloaders that program rounded rates for DPLL3. Since no SDRAM
memory timings are defined for the rounded rates, the initial SDRC
reprogram during init fails. Add in the correct timings here.
Problem reported by Kevin Hilman .
Signed-off-by: Paul Walmsley
Tested-by: Kevin Hilman
---
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 22
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
index 304336b..b190b45 100644
--- a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
+++ b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
@@ -20,34 +20,48 @@
/* XXX Using ARE = 0x1 (no autorefresh burst) -- can this be changed? */
static struct omap_sdrc_params hyb18m512160af6_sdrc_params[] = {
[0] = {
- .rate= 165941176,
+ .rate= 16600,
.actim_ctrla = 0x629db4c6,
.actim_ctrlb = 0x00012214,
.rfr_ctrl= 0x0004dc01,
.mr = 0x0032,
},
[1] = {
+ .rate= 165941176,
+ .actim_ctrla = 0x629db4c6,
+ .actim_ctrlb = 0x00012214,
+ .rfr_ctrl= 0x0004dc01,
+ .mr = 0x0032,
+ },
+ [2] = {
.rate= 1,
.actim_ctrla = 0x5219b485,
.actim_ctrlb = 0x00012210,
.rfr_ctrl= 0x0003de01,
.mr = 0x0032,
},
- [2] = {
+ [3] = {
+ .rate= 8300,
+ .actim_ctrla = 0x31512283,
+ .actim_ctrlb = 0x0001220a,
+ .rfr_ctrl= 0x00025501,
+ .mr = 0x0022,
+ },
+ [4] = {
.rate= 82970588,
.actim_ctrla = 0x31512283,
.actim_ctrlb = 0x0001220a,
.rfr_ctrl= 0x00025501,
.mr = 0x0022,
},
- [3] = {
+ [5] = {
.rate= ,
.actim_ctrla = 0x290d2243,
.actim_ctrlb = 0x00012208,
.rfr_ctrl= 0x0001d501,
.mr = 0x0022,
},
- [4] = {
+ [6] = {
.rate= 0
},
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] PM: OMAP3 SDRC: fix some SDRAM settings for Qimonda parts
Hi, This series updates some SDRAM parameter settings for the Qimonda parts used on some 3430SDP boards. Finally some 3430SDP boards are using bootloaders with rounded DPLL3 rates (e.g., 16600 Hz rather than 165941176 Hz); update the Qimonda SDRAM parameters. Also when reviewing the timing calculations, it appears that the lowest speed setting had an error in its autorefresh counter value. I don't know if anything out there still uses this low-speed setting - my recollection is that it was added for some early Labrador boards that had speed restrictions - any comments from TI on whether these 133.3MHz/66.6MHz rates should be dropped is most welcome. These patches will be queued up into the omap-clock-testing branch at the next possible opportunity. - Paul --- size: textdata bss dec hex filename 3667957 196224 113216 3977397 3cb0b5 vmlinux.3430sdp.orig 3667957 196256 113216 3977429 3cb0d5 vmlinux.3430sdp Paul Walmsley (2): OMAP3 SDRC: Add rounded rates for devices using the Qimonda SDRAM OMAP3 SDRC: Fix autorefresh counter for Qimonda SDRAM 66.6MHz rate .../mach-omap2/sdram-qimonda-hyb18m512160af-6.h| 28 +++- 1 files changed, 21 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP3 SDRC: Fix autorefresh counter for Qimonda SDRAM 66.6MHz rate
The autorefresh counter value for the 66.6MHz rate for the Qimonda SDRAM
part is wrong; fix it.
Signed-off-by: Paul Walmsley
---
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h|6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
index 74a92c8..304336b 100644
--- a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
+++ b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
@@ -1,8 +1,8 @@
/*
* SDRC register values for the Qimonda HYB18M512160AF-6
*
- * Copyright (C) 2008 Texas Instruments, Inc.
- * Copyright (C) 2008 Nokia Corporation
+ * Copyright (C) 2008-2009 Texas Instruments, Inc.
+ * Copyright (C) 2008-2009 Nokia Corporation
*
* Paul Walmsley
*
@@ -44,7 +44,7 @@ static struct omap_sdrc_params hyb18m512160af6_sdrc_params[]
= {
.rate= ,
.actim_ctrla = 0x290d2243,
.actim_ctrlb = 0x00012208,
- .rfr_ctrl= 0x0001d601,
+ .rfr_ctrl= 0x0001d501,
.mr = 0x0022,
},
[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 6/8] ARM: OMAP2/3: Change omapfb to use clkdev for dispc and rfbi
On Thu, 14 May 2009 10:49:59 -0700
Tony Lindgren wrote:
> This makes the framebuffer work on omap3.
>
> Also fix the clk_get usage for checkpatch.pl
> "ERROR: do not use assignment in if condition".
>
> Cc: Imre Deak
> Cc: linux-fbdev-de...@lists.sourceforge.net
> Signed-off-by: Tony Lindgren
> ---
Acked-by: Krzysztof Helt
> arch/arm/mach-omap2/clock24xx.c |8
> arch/arm/mach-omap2/clock34xx.c | 10 +-
> drivers/video/omap/dispc.c | 16 +---
> drivers/video/omap/rfbi.c |8 +---
> 4 files changed, 23 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
> index ff9b4c0..e4cef33 100644
> --- a/arch/arm/mach-omap2/clock24xx.c
> +++ b/arch/arm/mach-omap2/clock24xx.c
> @@ -103,10 +103,10 @@ static struct omap_clk omap24xx_clks[] = {
> CLK(NULL, "mdm_ick", &mdm_ick, CK_243X),
> CLK(NULL, "mdm_osc_ck", &mdm_osc_ck,CK_243X),
> /* DSS domain clocks */
> - CLK(NULL, "dss_ick", &dss_ick, CK_243X | CK_242X),
> - CLK(NULL, "dss1_fck", &dss1_fck, CK_243X | CK_242X),
> - CLK(NULL, "dss2_fck", &dss2_fck, CK_243X | CK_242X),
> - CLK(NULL, "dss_54m_fck", &dss_54m_fck, CK_243X | CK_242X),
> + CLK("omapfb", "ick", &dss_ick, CK_243X | CK_242X),
> + CLK("omapfb", "dss1_fck", &dss1_fck, CK_243X | CK_242X),
> + CLK("omapfb", "dss2_fck", &dss2_fck, CK_243X | CK_242X),
> + CLK("omapfb", "tv_fck", &dss_54m_fck, CK_243X | CK_242X),
> /* L3 domain clocks */
> CLK(NULL, "core_l3_ck", &core_l3_ck,CK_243X | CK_242X),
> CLK(NULL, "ssi_fck", &ssi_ssr_sst_fck, CK_243X | CK_242X),
> diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
> index a057539..ba05aa4 100644
> --- a/arch/arm/mach-omap2/clock34xx.c
> +++ b/arch/arm/mach-omap2/clock34xx.c
> @@ -197,11 +197,11 @@ static struct omap_clk omap34xx_clks[] = {
> CLK("omap_rng", "ick", &rng_ick, CK_343X),
> CLK(NULL, "sha11_ick",&sha11_ick, CK_343X),
> CLK(NULL, "des1_ick", &des1_ick, CK_343X),
> - CLK(NULL, "dss1_alwon_fck", &dss1_alwon_fck, CK_343X),
> - CLK(NULL, "dss_tv_fck", &dss_tv_fck,CK_343X),
> - CLK(NULL, "dss_96m_fck", &dss_96m_fck, CK_343X),
> - CLK(NULL, "dss2_alwon_fck", &dss2_alwon_fck, CK_343X),
> - CLK(NULL, "dss_ick", &dss_ick, CK_343X),
> + CLK("omapfb", "dss1_fck", &dss1_alwon_fck, CK_343X),
> + CLK("omapfb", "tv_fck", &dss_tv_fck,CK_343X),
> + CLK("omapfb", "video_fck",&dss_96m_fck, CK_343X),
> + CLK("omapfb", "dss2_fck", &dss2_alwon_fck, CK_343X),
> + CLK("omapfb", "ick", &dss_ick, CK_343X),
> CLK(NULL, "cam_mclk", &cam_mclk, CK_343X),
> CLK(NULL, "cam_ick", &cam_ick, CK_343X),
> CLK(NULL, "csi2_96m_fck", &csi2_96m_fck, CK_343X),
> diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
> index dfb72f5..3668df2 100644
> --- a/drivers/video/omap/dispc.c
> +++ b/drivers/video/omap/dispc.c
> @@ -880,23 +880,25 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
> *dev)
>
> static int get_dss_clocks(void)
> {
> - if (IS_ERR((dispc.dss_ick = clk_get(dispc.fbdev->dev, "dss_ick" {
> - dev_err(dispc.fbdev->dev, "can't get dss_ick\n");
> + dispc.dss_ick = clk_get(dispc.fbdev->dev, "ick");
> + if (IS_ERR(dispc.dss_ick)) {
> + dev_err(dispc.fbdev->dev, "can't get ick\n");
> return PTR_ERR(dispc.dss_ick);
> }
>
> - if (IS_ERR((dispc.dss1_fck = clk_get(dispc.fbdev->dev, "dss1_fck" {
> + dispc.dss1_fck = clk_get(dispc.fbdev->dev, "dss1_fck");
> + if (IS_ERR(dispc.dss1_fck)) {
> dev_err(dispc.fbdev->dev, "can't get dss1_fck\n");
> clk_put(dispc.dss_ick);
> return PTR_ERR(dispc.dss1_fck);
> }
>
> - if (IS_ERR((dispc.dss_54m_fck =
> - clk_get(dispc.fbdev->dev, "dss_54m_fck" {
> - dev_err(dispc.fbdev->dev, "can't get dss_54m_fck\n");
> + dispc.dss_54m_fck = clk_get(dispc.fbdev->dev, "tv_fck");
> + if (IS_ERR(dispc.dss_54m_fck)) {
> + dev_err(dispc.fbdev->dev, "can't get tv_fck\n");
> clk_put(dispc.dss_ick);
> clk_put(dispc.dss1_fck);
> - return PTR_ERR(dispc.dss_54m_fck);
> +
> }
>
> return 0;
> diff --git a/drivers/video/omap/rfbi.c b/drivers/video/omap/rfbi.c
> index a13c8dc..9332d6c 100644
> --- a/drivers/video/omap/rfbi.c
> +++ b/drivers/video/omap/rfbi.c
> @@ -83,12 +83,14 @@ static inline u32 rfbi_read_reg(int idx)
>
> static int rfbi_get_clocks(void)
> {
> - if (IS_ERR((rfbi.dss_i
Re: OMAP3: PM: Add the wakeup source driver, v4
Kim Kyuwon writes:
> Hi Kevin,
>
> Could you please review this fourth version of OMAP wakeup source driver?
>
Yes. I'm working through my backlog of PM branch submissions this
week.
I've been focusing on getting some of the PM branch reworked and
rebased so I can start submitting upstream.
I apologize for the delays, but the upstream work is currently higher
priority than adding large new features to the PM branch.
Kevin
>
> On Tue, May 5, 2009 at 6:13 PM, Kim Kyuwon wrote:
>> Sometimes, it is necessary to find out "what does wake up my board from
>> suspend?". Notifying wake-up source feature may be used to blame unexpected
>> wake-up events which increase power consumption. And user mode applications
>> can act smartly according to the wake-up event from Suspend-to-RAM state to
>> minimize power consumption. Note that this driver can't inform wake-up
>> events from idle state. This driver uses sysfs interface to give information
>> to user mode applications like:
>>
>> cat /sys/power/omap_resume_irq
>> cat /sys/power/omap_resume_event
>>
>> This driver also provides the I/O pad wake-up source configuration. Specific
>> GPIO settings in the board file are:
>>
>> /* I/O pad wakeup source configuration */
>> static struct iopad_wake boardname_iopad_wake[] = {
>>{
>>.mux_index = AE7_34XX_GPIO24,
>>.alias = "KEY_PWRON",
>>},
>>{
>>.mux_index = ETK_D9_GPIO23,
>>.alias = "USB_DETECT",
>>},
>> };
>>
>> static struct omap_wake_platform_data boardname_wake_data = {
>>.iopad_wakes= boardname_iopad_wake,
>>.iopad_wake_num = ARRAY_SIZE(boardname_iopad_wake),
>> };
>>
>> static struct platform_device boardname_wakeup = {
>>.name = "omap-wake",
>>.id = -1,
>>.dev= {
>>.platform_data = &boardname_wake_data,
>>},
>> };
>>
>> The patch adds Kconfig options "OMAP34xx wakeup source support" under
>> "System type"->"TI OMAP implementations" menu.
>>
>> Signed-off-by: Kim Kyuwon
>> ---
>> arch/arm/mach-omap2/Makefile |1 +
>> arch/arm/mach-omap2/irq.c | 21 ++-
>> arch/arm/mach-omap2/omapdev-common.h |3 +
>> arch/arm/mach-omap2/omapdev3xxx.h | 63 +
>> arch/arm/mach-omap2/pm34xx.c | 13 +
>> arch/arm/mach-omap2/prcm-common.h |4 +
>> arch/arm/mach-omap2/prm-regbits-34xx.h|5 +
>> arch/arm/mach-omap2/wake34xx.c| 409
>> +
>> arch/arm/plat-omap/Kconfig|9 +
>> arch/arm/plat-omap/include/mach/irqs.h|4 +
>> arch/arm/plat-omap/include/mach/mux.h |3 +
>> arch/arm/plat-omap/include/mach/omapdev.h |3 +
>> arch/arm/plat-omap/include/mach/wake.h| 52
>> arch/arm/plat-omap/mux.c | 25 ++-
>> 14 files changed, 605 insertions(+), 10 deletions(-)
>> create mode 100644 arch/arm/mach-omap2/wake34xx.c
>> create mode 100644 arch/arm/plat-omap/include/mach/wake.h
>>
>> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
>> index c58bab4..cfc5a13 100644
>> --- a/arch/arm/mach-omap2/Makefile
>> +++ b/arch/arm/mach-omap2/Makefile
>> @@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
>> obj-$(CONFIG_ARCH_OMAP24XX)+= sleep24xx.o
>> obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
>> obj-$(CONFIG_PM_DEBUG) += pm-debug.o
>> +obj-$(CONFIG_OMAP3_WAKE) += wake34xx.o
>> endif
>>
>> # SmartReflex driver
>> diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
>> index 700fc3d..18ac725 100644
>> --- a/arch/arm/mach-omap2/irq.c
>> +++ b/arch/arm/mach-omap2/irq.c
>> @@ -33,9 +33,6 @@
>> #define INTC_MIR_SET0 0x008c
>> #define INTC_PENDING_IRQ0 0x0098
>>
>> -/* Number of IRQ state bits in each MIR register */
>> -#define IRQ_BITS_PER_REG 32
>> -
>> /*
>> * OMAP2 has a number of different interrupt controllers, each interrupt
>> * controller is identified as its own "bank". Register definitions are
>> @@ -193,6 +190,24 @@ int omap_irq_pending(void)
>>return 0;
>> }
>>
>> +void omap_get_pending_irqs(u32 *pending_irqs, unsigned len)
>> +{
>> + int i, j = 0;
>> +
>> + for (i = 0; i < ARRAY_SIZE(irq_banks); i++) {
>> + struct omap_irq_bank *bank = irq_banks + i;
>> + int irq;
>> +
>> + for (irq = 0; irq < bank->nr_irqs && j < len;
>> + irq += IRQ_BITS_PER_REG) {
>> + int offset = irq & (~(IRQ_BITS_PER_REG - 1));
>> +
>> + pending_irqs[j++] = intc_bank_read_reg(bank,
>> + (INTC_PENDING_IRQ0 + offset));
>> + }
>> + }
>>
PM branch updates: 14 may 09
FYI... Just pushed another round of updates to the 'pm' branch of my linux-omap-pm repo[1]. git shortlog below[2] As far as I know, the only outstanding submissions which are being discussed/reviewed are: - Tero Kristo: OMAP3: PM: Force USB to standby if not used 2009-05-14 - Kim Kyuwon: OMAP3: PM: Add the wakeup source driver, v4 2009-05-05 - Russ Dill: [RFC] Allow disabling wakeup for serial ports..., 2009-04-27 [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary [2] git-shortlog: Kalle Jokiniemi (2): ARM: OMAP3: Fix OMAP_CHIP_INIT usage PM: Disable usb host HW save and restore Kevin Hilman (2): OMAP: PM: SmartReflex has build dependency on OMAP PM layer OMAP3: PM: 3430SDP: update pm_defconfig Paul Walmsley (1): PM: OMAP3 SDRC: set FIXEDDELAY when disabling SDRC DLL Tero Kristo (2): OMAP3: PM: Added resource refresh to OPP unlock requests OMAP: PM: Fixed omap_pm_set_min_bus_tput -- 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: Please help creating gpio-switch on ams-delta
* Janusz Krzysztofik [090512 03:54]:
> Hi,
>
> I am playing with OMAP 5910 based Amstrad E3 videophone (ams-delta)
> machine. I am trying to expose GPIO 4, that hook switch hangs off, to
> userspace.
>
> I can successfully access the pin by exporting it using gpiolib sysfs. I
> can check its value, following hook switch state changes. However, I
> would like the switch to generate events.
>
> I have tried two methods: gpio-switch and gpio-keys. gpio-switch device
> is able to report the switch initial state correctly, gpio-keys device
> just initializes without errors. However, for both methods, after first
> switch change, the system stops responding, giving no error messages.
>
> The code of goip-switch initialization sequence together with my
> platform device definition (attached) does not look any different to me
> than those for keyboard or modem (patches available from
> http://the.earth.li/pub/e3/2.6.19/), that both also use GPIO interrupts
> and do work for me.
>
> Any hints?
Please don't use the gpio-switch any longer, that is not in the mainline
and will disappear.
There has been some discussion on LKML on doing it via the input layer.
No other tips right now from me :)
Tony
> Janusz
>
> PS. This is my first post to linux-omap list, I don't know if you accept
> attachments. If not, next time I switch to a different mail user agent
> that allows me for inline file inclusion (or learn how to do it in my
> thunderbird).
>
> --- linux-2.6.27.22/arch/arm/mach-omap1/board-ams-delta.c.orig
> 2009-05-10 18:05:01.0 +0200
> +++ linux-2.6.27.22/arch/arm/mach-omap1/board-ams-delta.c 2009-05-10
> 18:19:18.0 +0200
> @@ -243,6 +243,17 @@ static struct uart_port ams_delta_modem_
> .line = 1
> };
>
> +static struct omap_gpio_switch ams_delta_switches[] __initdata = {
> + /* Low when handset is picked up */
> + {
> + .name = "handset",
> + .gpio = AMS_DELTA_GPIO_PIN_HOOK_SWITCH,
> + .type = OMAP_GPIO_SWITCH_TYPE_ACTIVITY,
> + .flags = OMAP_GPIO_SWITCH_FLAG_INVERTED,
> + /* .notify = ams_delta_handset_detect, */
> + },
> +};
> +
> static void __init ams_delta_init(void)
> {
> printk("ams_delta_init\n\r");
> @@ -259,6 +270,9 @@ static void __init ams_delta_init(void)
>
> platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
>
> + omap_register_gpio_switches(ams_delta_switches,
> + ARRAY_SIZE(ams_delta_switches));
> +
> early_serial_setup(&ams_delta_modem_port);
>
> #ifdef CONFIG_AMS_DELTA_FIQ
--
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]RESEND:OMAP3:configs: rename sdp and ldp defconfig
* Nishanth Menon [090422 13:47]:
> Rename the 3430sdp and ldp defconfig to make
> names to make them collected with omap3 filenames
Well we already have products that just have the product
name in the defconfig, like overo_defconfig and n770_defconfig.
I think we have more urgent patches to get to the mainline tree,
so let's put this on hold. BTW, if you need to find out omap3
boards, just $ grep CONFIG_ARCH_OMAP3 arch/arm/configs/
Regards,
Tony
> Signed-off-by: Nishanth Menon
> ---
> ...p_3430sdp_defconfig => omap3_3430sdp_defconfig} |0
> .../{omap_ldp_defconfig => omap3_zoom1_defconfig} |0
> 2 files changed, 0 insertions(+), 0 deletions(-)
> rename arch/arm/configs/{omap_3430sdp_defconfig => omap3_3430sdp_defconfig}
> (100%)
> rename arch/arm/configs/{omap_ldp_defconfig => omap3_zoom1_defconfig} (100%)
>
> diff --git a/arch/arm/configs/omap_3430sdp_defconfig
> b/arch/arm/configs/omap3_3430sdp_defconfig
> similarity index 100%
> rename from arch/arm/configs/omap_3430sdp_defconfig
> rename to arch/arm/configs/omap3_3430sdp_defconfig
> diff --git a/arch/arm/configs/omap_ldp_defconfig
> b/arch/arm/configs/omap3_zoom1_defconfig
> similarity index 100%
> rename from arch/arm/configs/omap_ldp_defconfig
> rename to arch/arm/configs/omap3_zoom1_defconfig
> --
> 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][UPDATED] DSPBRIDGE: CLK_Enable and CLK_Disable Code cleanup
* Koen Kooi [090425 07:48]: > Op 25 apr 2009, om 13:42 heeft Felipe Contreras het volgende geschreven: > >> While there has been good progress in the bridgedriver, it is still >> *very* far away from meeting mainline standards and this makes many >> people uneasy, including me. > > > Is it "good enough" to go into Greg KHs staging tree? I'd rather keep any code that does non-standard tinkering of omap registers out of the mainline tree until the basics are fixed. 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 8/8] ARM: OMAP3: Fix HW SAVEANDRESTORE shift define
From: Kalle Jokiniemi The OMAP3430ES2_SAVEANDRESTORE_SHIFT macro is used by powerdomain code in "1 << OMAP3430ES2_SAVEANDRESTORE_SHIFT" manner, but the definition was also (1 << 4), meaning we actually modified bit 16. So the definition needs to be 4. This fixes also a cold reset HW bug in OMAP3430 ES3.x where some of the efuse bits are not isolated during wake-up from off mode. This can cause randomish cold resets with off mode. Enabling the USBTLL hardware SAVEANDRESTORE causes the core power up assert to be delayed in a way that we will not get faulty values when boot ROM is reading the unisolated registers. Signed-off-by: Kalle Jokiniemi Acked-by: Kevin Hilman Acked-by: Paul Walmsley Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/prm-regbits-34xx.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h b/arch/arm/mach-omap2/prm-regbits-34xx.h index c6a7940..9fd03a2 100644 --- a/arch/arm/mach-omap2/prm-regbits-34xx.h +++ b/arch/arm/mach-omap2/prm-regbits-34xx.h @@ -409,7 +409,7 @@ /* PM_PREPWSTST_CAM specific bits */ /* PM_PWSTCTRL_USBHOST specific bits */ -#define OMAP3430ES2_SAVEANDRESTORE_SHIFT (1 << 4) +#define OMAP3430ES2_SAVEANDRESTORE_SHIFT 4 /* RM_RSTST_PER specific bits */ -- 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 7/8] ARM: OMAP3: Fix number of GPIO lines for 34xx
From: Tony Lindgren As per 3430 TRM, there are 6 banks [0 to 191] Signed-off-by: Tom Rix Signed-off-by: Vikram Pandita Signed-off-by: Tony Lindgren --- arch/arm/plat-omap/gpio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index 17d7afe..ee0b21f 100644 --- a/arch/arm/plat-omap/gpio.c +++ b/arch/arm/plat-omap/gpio.c @@ -307,7 +307,7 @@ static inline int gpio_valid(int gpio) return 0; if (cpu_is_omap24xx() && gpio < 128) return 0; - if (cpu_is_omap34xx() && gpio < 160) + if (cpu_is_omap34xx() && gpio < 192) return 0; return -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
[PATCH 6/8] ARM: OMAP2/3: Change omapfb to use clkdev for dispc and rfbi
This makes the framebuffer work on omap3.
Also fix the clk_get usage for checkpatch.pl
"ERROR: do not use assignment in if condition".
Cc: Imre Deak
Cc: linux-fbdev-de...@lists.sourceforge.net
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/clock24xx.c |8
arch/arm/mach-omap2/clock34xx.c | 10 +-
drivers/video/omap/dispc.c | 16 +---
drivers/video/omap/rfbi.c |8 +---
4 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index ff9b4c0..e4cef33 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -103,10 +103,10 @@ static struct omap_clk omap24xx_clks[] = {
CLK(NULL, "mdm_ick", &mdm_ick, CK_243X),
CLK(NULL, "mdm_osc_ck", &mdm_osc_ck,CK_243X),
/* DSS domain clocks */
- CLK(NULL, "dss_ick", &dss_ick, CK_243X | CK_242X),
- CLK(NULL, "dss1_fck", &dss1_fck, CK_243X | CK_242X),
- CLK(NULL, "dss2_fck", &dss2_fck, CK_243X | CK_242X),
- CLK(NULL, "dss_54m_fck", &dss_54m_fck, CK_243X | CK_242X),
+ CLK("omapfb", "ick", &dss_ick, CK_243X | CK_242X),
+ CLK("omapfb", "dss1_fck", &dss1_fck, CK_243X | CK_242X),
+ CLK("omapfb", "dss2_fck", &dss2_fck, CK_243X | CK_242X),
+ CLK("omapfb", "tv_fck", &dss_54m_fck, CK_243X | CK_242X),
/* L3 domain clocks */
CLK(NULL, "core_l3_ck", &core_l3_ck,CK_243X | CK_242X),
CLK(NULL, "ssi_fck", &ssi_ssr_sst_fck, CK_243X | CK_242X),
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index a057539..ba05aa4 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -197,11 +197,11 @@ static struct omap_clk omap34xx_clks[] = {
CLK("omap_rng", "ick", &rng_ick, CK_343X),
CLK(NULL, "sha11_ick",&sha11_ick, CK_343X),
CLK(NULL, "des1_ick", &des1_ick, CK_343X),
- CLK(NULL, "dss1_alwon_fck", &dss1_alwon_fck, CK_343X),
- CLK(NULL, "dss_tv_fck", &dss_tv_fck,CK_343X),
- CLK(NULL, "dss_96m_fck", &dss_96m_fck, CK_343X),
- CLK(NULL, "dss2_alwon_fck", &dss2_alwon_fck, CK_343X),
- CLK(NULL, "dss_ick", &dss_ick, CK_343X),
+ CLK("omapfb", "dss1_fck", &dss1_alwon_fck, CK_343X),
+ CLK("omapfb", "tv_fck", &dss_tv_fck,CK_343X),
+ CLK("omapfb", "video_fck",&dss_96m_fck, CK_343X),
+ CLK("omapfb", "dss2_fck", &dss2_alwon_fck, CK_343X),
+ CLK("omapfb", "ick", &dss_ick, CK_343X),
CLK(NULL, "cam_mclk", &cam_mclk, CK_343X),
CLK(NULL, "cam_ick", &cam_ick, CK_343X),
CLK(NULL, "csi2_96m_fck", &csi2_96m_fck, CK_343X),
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index dfb72f5..3668df2 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -880,23 +880,25 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*dev)
static int get_dss_clocks(void)
{
- if (IS_ERR((dispc.dss_ick = clk_get(dispc.fbdev->dev, "dss_ick" {
- dev_err(dispc.fbdev->dev, "can't get dss_ick\n");
+ dispc.dss_ick = clk_get(dispc.fbdev->dev, "ick");
+ if (IS_ERR(dispc.dss_ick)) {
+ dev_err(dispc.fbdev->dev, "can't get ick\n");
return PTR_ERR(dispc.dss_ick);
}
- if (IS_ERR((dispc.dss1_fck = clk_get(dispc.fbdev->dev, "dss1_fck" {
+ dispc.dss1_fck = clk_get(dispc.fbdev->dev, "dss1_fck");
+ if (IS_ERR(dispc.dss1_fck)) {
dev_err(dispc.fbdev->dev, "can't get dss1_fck\n");
clk_put(dispc.dss_ick);
return PTR_ERR(dispc.dss1_fck);
}
- if (IS_ERR((dispc.dss_54m_fck =
- clk_get(dispc.fbdev->dev, "dss_54m_fck" {
- dev_err(dispc.fbdev->dev, "can't get dss_54m_fck\n");
+ dispc.dss_54m_fck = clk_get(dispc.fbdev->dev, "tv_fck");
+ if (IS_ERR(dispc.dss_54m_fck)) {
+ dev_err(dispc.fbdev->dev, "can't get tv_fck\n");
clk_put(dispc.dss_ick);
clk_put(dispc.dss1_fck);
- return PTR_ERR(dispc.dss_54m_fck);
+
}
return 0;
diff --git a/drivers/video/omap/rfbi.c b/drivers/video/omap/rfbi.c
index a13c8dc..9332d6c 100644
--- a/drivers/video/omap/rfbi.c
+++ b/drivers/video/omap/rfbi.c
@@ -83,12 +83,14 @@ static inline u32 rfbi_read_reg(int idx)
static int rfbi_get_clocks(void)
{
- if (IS_ERR((rfbi.dss_ick = clk_get(rfbi.fbdev->dev, "dss_ick" {
- dev_err(rfbi.fbdev->dev, "can't get dss_ick\n");
+ rfbi.dss_ick = clk_get(rfbi.fbdev->dev, "ick");
+ if
[PATCH 5/8] ARM: OMAP2/3: Add name for musb clocks
With the clkdev, musb_core.c needs to register clock with name "ick".
Once all the platforms using the musb driver have been converted
to use clockdev, the clock name does not need to be passed
from the low-level init code.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/clock24xx.c |2 +-
arch/arm/mach-omap2/clock34xx.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index efc59c4..ff9b4c0 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -206,7 +206,7 @@ static struct omap_clk omap24xx_clks[] = {
CLK(NULL, "aes_ick", &aes_ick, CK_243X | CK_242X),
CLK(NULL, "pka_ick", &pka_ick, CK_243X | CK_242X),
CLK(NULL, "usb_fck", &usb_fck, CK_243X | CK_242X),
- CLK(NULL, "usbhs_ick",&usbhs_ick, CK_243X),
+ CLK("musb_hdrc","ick", &usbhs_ick, CK_243X),
CLK("mmci-omap-hs.0", "ick",&mmchs1_ick,CK_243X),
CLK("mmci-omap-hs.0", "fck",&mmchs1_fck,CK_243X),
CLK("mmci-omap-hs.1", "ick",&mmchs2_ick,CK_243X),
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 0a14dca..a057539 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -157,7 +157,7 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, "ssi_ssr_fck", &ssi_ssr_fck, CK_343X),
CLK(NULL, "ssi_sst_fck", &ssi_sst_fck, CK_343X),
CLK(NULL, "core_l3_ick", &core_l3_ick, CK_343X),
- CLK(NULL, "hsotgusb_ick", &hsotgusb_ick, CK_343X),
+ CLK("musb_hdrc","ick", &hsotgusb_ick, CK_343X),
CLK(NULL, "sdrc_ick", &sdrc_ick, CK_343X),
CLK(NULL, "gpmc_fck", &gpmc_fck, CK_343X),
CLK(NULL, "security_l3_ick", &security_l3_ick, CK_343X),
--
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/8] ARM: OMAP2: Fix SPI driver failure on 2420 when running multi-omap config
From: Jarkko Nikula SPI driver will do unhandled fault on OMAP2420 if trying to probe non-existing SPI busses. Register those additional busses runtime only for cpus having them. Signed-off-by: Jarkko Nikula Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/devices.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index 496983a..894cc35 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -354,10 +354,12 @@ static void omap_init_mcspi(void) platform_device_register(&omap2_mcspi1); platform_device_register(&omap2_mcspi2); #if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) - platform_device_register(&omap2_mcspi3); + if (cpu_is_omap2430() || cpu_is_omap343x()) + platform_device_register(&omap2_mcspi3); #endif #ifdef CONFIG_ARCH_OMAP3 - platform_device_register(&omap2_mcspi4); + if (cpu_is_omap343x()) + platform_device_register(&omap2_mcspi4); #endif } -- 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/8] ARM: OMAP2: Fix tusb6010 init error and compilation warning
From: Jarkko Nikula Fix "tusb6010 init error 5, -19" and compilation warning from function tusb6010_platform_retime "warning: 'sysclk_ps' is used uninitialized in this function". I suppose commit c094ba34b8f780885d029ce3c2715a194b780e5d was meant to test for zero fclk_ps instead of sysclk_ps. Signed-off-by: Jarkko Nikula Cc: Roel Kluin Tested-by: Kalle Valo Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/usb-tusb6010.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c index 8df55f4..8622c24 100644 --- a/arch/arm/mach-omap2/usb-tusb6010.c +++ b/arch/arm/mach-omap2/usb-tusb6010.c @@ -187,7 +187,7 @@ int tusb6010_platform_retime(unsigned is_refclk) unsignedsysclk_ps; int status; - if (!refclk_psec || sysclk_ps == 0) + if (!refclk_psec || fclk_ps == 0) return -ENODEV; sysclk_ps = is_refclk ? refclk_psec : TUSB6010_OSCCLK_60; -- 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/8] ARM: OMAP: GPIO de-bounce clocks don't affect module idle state
From: Paul Walmsley
GPIO de-bounce clocks don't have any impact on the module idle state, so
the clock code should not wait for the module to enable after the de-bounce
clocks are enabled.
Problem found by Kevin Hilman .
Signed-off-by: Paul Walmsley
Signed-off-by: Kevin Hilman
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/clock34xx.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 6763b8f..017a30e 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -2182,7 +2182,7 @@ static struct clk wkup_32k_fck = {
static struct clk gpio1_dbck = {
.name = "gpio1_dbck",
- .ops= &clkops_omap2_dflt_wait,
+ .ops= &clkops_omap2_dflt,
.parent = &wkup_32k_fck,
.enable_reg = OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO1_SHIFT,
@@ -2427,7 +2427,7 @@ static struct clk per_32k_alwon_fck = {
static struct clk gpio6_dbck = {
.name = "gpio6_dbck",
- .ops= &clkops_omap2_dflt_wait,
+ .ops= &clkops_omap2_dflt,
.parent = &per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO6_SHIFT,
@@ -2437,7 +2437,7 @@ static struct clk gpio6_dbck = {
static struct clk gpio5_dbck = {
.name = "gpio5_dbck",
- .ops= &clkops_omap2_dflt_wait,
+ .ops= &clkops_omap2_dflt,
.parent = &per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO5_SHIFT,
@@ -2447,7 +2447,7 @@ static struct clk gpio5_dbck = {
static struct clk gpio4_dbck = {
.name = "gpio4_dbck",
- .ops= &clkops_omap2_dflt_wait,
+ .ops= &clkops_omap2_dflt,
.parent = &per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO4_SHIFT,
@@ -2457,7 +2457,7 @@ static struct clk gpio4_dbck = {
static struct clk gpio3_dbck = {
.name = "gpio3_dbck",
- .ops= &clkops_omap2_dflt_wait,
+ .ops= &clkops_omap2_dflt,
.parent = &per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO3_SHIFT,
@@ -2467,7 +2467,7 @@ static struct clk gpio3_dbck = {
static struct clk gpio2_dbck = {
.name = "gpio2_dbck",
- .ops= &clkops_omap2_dflt_wait,
+ .ops= &clkops_omap2_dflt,
.parent = &per_32k_alwon_fck,
.enable_reg = OMAP_CM_REGADDR(OMAP3430_PER_MOD, CM_FCLKEN),
.enable_bit = OMAP3430_EN_GPIO2_SHIFT,
--
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/8] ARM: OMAP: Fix printing of reserved memory for frambuffer
From: Tomi Valkeinen
Print reserved memory only if it was actually reserved.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/fb.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index ce6b4ba..3746222 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -206,9 +206,10 @@ void __init omapfb_reserve_sdram(void)
config_invalid = 1;
return;
}
- if (rg.paddr)
+ if (rg.paddr) {
reserve_bootmem(rg.paddr, rg.size, BOOTMEM_DEFAULT);
- reserved += rg.size;
+ reserved += rg.size;
+ }
omapfb_config.mem_desc.region[i] = rg;
configured_regions++;
}
--
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/8] Omap fixes for 2.6.30-rc5
Hi, Here are some omap fixes for 2.6.30-rc5 for review. Regards, Tony --- Jarkko Nikula (2): ARM: OMAP2: Fix SPI driver failure on 2420 when running multi-omap config ARM: OMAP2: Fix tusb6010 init error and compilation warning Kalle Jokiniemi (1): ARM: OMAP3: Fix HW SAVEANDRESTORE shift define Paul Walmsley (1): ARM: OMAP: GPIO de-bounce clocks don't affect module idle state Tomi Valkeinen (1): ARM: OMAP: Fix printing of reserved memory for frambuffer Tony Lindgren (3): ARM: OMAP3: Fix number of GPIO lines for 34xx ARM: OMAP2/3: Change omapfb to use clkdev for dispc and rfbi ARM: OMAP2/3: Add name for musb clocks arch/arm/mach-omap2/clock24xx.c| 10 +- arch/arm/mach-omap2/clock34xx.c| 12 ++-- arch/arm/mach-omap2/clock34xx.h| 12 ++-- arch/arm/mach-omap2/devices.c |6 -- arch/arm/mach-omap2/prm-regbits-34xx.h |2 +- arch/arm/mach-omap2/usb-tusb6010.c |2 +- arch/arm/plat-omap/fb.c|5 +++-- arch/arm/plat-omap/gpio.c |2 +- drivers/video/omap/dispc.c | 16 +--- drivers/video/omap/rfbi.c |8 +--- 10 files changed, 41 insertions(+), 34 deletions(-) -- Signature -- 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: Disable usb host HW save and restore
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Thursday, May 14, 2009 12:10 PM > To: Kalle Jokiniemi > Kalle Jokiniemi writes: > > > The hardware SAVEANDRESTORE mechanism seems to leave > > USB HOST power domain permanently into active state > > after one transition from off to active state. > > Disabling for now. Some are is needed around USB host domain handling. There are a couple errata impacting different chip revs. Today in the older TI reference code this condition of a stuck on power domain does not happen. However, we are using a software supervised method to disable the power domain. May be this code has a bug or the hardware does around auto use for this domain. You will want TLL or host SAR activated to minimally work around a possible false cold reset issue. There is a window coming back from OFF where a reset will be thrown. Enabling SAR conclusively moves the internal window so there is no danger. The error is fairly easily seen so if you start taking resets know this is likely the root cause. What Rev of CPU is the issue occurring on? The USBTLL SAR in 3.0 and before silicon will case a deadlock on 2nd sleep attempt. On 3.1 and after its fixed. Regards, Richard W. -- 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: LDP support
* Imre Deak [090514 02:09]: > On Wed, May 06, 2009 at 06:00:16AM +0200, ext Tony Lindgren wrote: > > * Russell King - ARM Linux [090505 12:52]: > > > On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote: > > > > * Russell King - ARM Linux [090428 15:07]: > > > > > Tony, et.al., > > > > > > > > > > Any ideas when more LDP support will be pushed into mainline (such as > > > > > the framebuffer support)? > > > > > > > > I'll be looking at the board-*.c patches for the next merge window > > > > hopefully this week or next week. > > > > > > > > Looks like LDP keyboard, touchscreen & RTC are pretty much ready > > > > to go. Then the MMC has some regulator updates, but AFAIK the MMC > > > > should work OK already. > > > > > > > > For the framebuffer, Imre and Tomi know the status the best, so > > > > I've added them to Cc. > > > > > > > > Imre has been meaning to send a bunch of drivers/video/omap changes > > > > to the fbdev list for a while now and LDP framebuffer may depend on > > > > those. Imre, any news on the status of sending the fb patches > > > > upstream? > > > > > > > > Then there are the upcoming DSS patches from Tomi, but those still > > > > need some work before they're ready to go. > > > > > > Is there any news on this? Will we see more functional OMAP3 / LDP > > > support queued for the next merge window? > > > > Yes fro the stuff listed above, but still no news on the framebuffer > > patches. Imre? > > There is a mainline based tree with the missing DSS1 FB stuff that I'm > planning to submit to fb-devel: > > git clone git://koowaldah.org/people/imre/linux-2.6-fb > > I could only compile test it for OMAP2/3 targets, it would be nice > if someone could check if it works too. Also if some DSS1 FB related things > are still missing from that tree, I could add them / submit them with > the rest of the things. > > Sorry for the big delay. Great, I've started mirroring this as omapfb-upstream branch in the linux-omap tree for easy testing. Looks like your patch "ARM: OMAP: NOKIA-770: Add support for HWA742 LCD controller" needs fixing to just pass the clocks to the LCD driver as discussed in the recent 770 thread. Also your patch "ARM: OMAP: FB: Add OMAP3 DISPC support" will be obsolete, I have a fix in my omap-fixes queue that solves the problem with clkdev. 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 9/9] omap mmc host: Use disable_irq_nosync() from within irq handlers.
* Pierre Ossman [090426 12:22]: > Should I queue this up or do you want to do something differently for > this? Looks like a valid fix to me. Acked-by: Tony Lindgren > On Thu, 16 Apr 2009 15:55:21 +1000 > Ben Nizette wrote: > > > > > disable_irq() should wait for all running handlers to complete > > before returning. As such, if it's used to disable an interrupt > > from that interrupt's handler it will deadlock. This replaces > > the dangerous instances with the _nosync() variant which doesn't > > have this problem. > > > > Signed-off-by: Ben Nizette > > --- > > diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c > > index 5570849..d5ea652 100644 > > --- a/drivers/mmc/host/omap.c > > +++ b/drivers/mmc/host/omap.c > > @@ -824,7 +824,7 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id) > > del_timer(&host->cmd_abort_timer); > > host->abort = 1; > > OMAP_MMC_WRITE(host, IE, 0); > > - disable_irq(host->irq); > > + disable_irq_nosync(host->irq); > > schedule_work(&host->cmd_abort_work); > > return IRQ_HANDLED; > > } > > > -- > -- Pierre Ossman > > WARNING: This correspondence is being monitored by the > Swedish government. Make sure your server uses encryption > for SMTP traffic and consider using PGP for end-to-end > encryption. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM:OMAP3: Fix PLL_MOD CLKEN offset in scratchpad
Kalle Jokiniemi writes: > The CM_CLKEN_PLL register saved in scratchpad memory > was wrongly using offset of 0x0004 instead of 0x. > > The effect of this was that boot ROM code would > restore the wrong value when waking up from off mode. > This wrong value, however, will be overwritten by > prcm context restore. Still, a short period of wrong > clock settings in CM_CLKEN_PLL remained between ROM > code and prcm context restore. This is fixed by the > patch. > > Problem reported by: Jouni Högander > > Signed-off-by: Kalle Jokiniemi Thanks, pushed to PM branch. Kevin > --- > arch/arm/mach-omap2/control.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c > index a0429fe..60de860 100644 > --- a/arch/arm/mach-omap2/control.c > +++ b/arch/arm/mach-omap2/control.c > @@ -235,7 +235,7 @@ void omap3_save_scratchpad_contents(void) > prcm_block_contents.cm_clksel_wkup = > cm_read_mod_reg(WKUP_MOD, CM_CLKSEL); > prcm_block_contents.cm_clken_pll = > - cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKEN_PLL); > + cm_read_mod_reg(PLL_MOD, CM_CLKEN); > prcm_block_contents.cm_autoidle_pll = > cm_read_mod_reg(PLL_MOD, OMAP3430_CM_AUTOIDLE_PLL); > prcm_block_contents.cm_clksel1_pll = > -- > 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] PM: Disable usb host HW save and restore
Kalle Jokiniemi writes:
> The hardware SAVEANDRESTORE mechanism seems to leave
> USB HOST power domain permanently into active state
> after one transition from off to active state.
> Disabling for now.
>
> Signed-off-by: Kalle Jokiniemi
Thanks, pushing to PM branch.
Paul, will you incoporate this into your upstream queue as well?
Thanks,
Kevin
> ---
> arch/arm/mach-omap2/powerdomains34xx.h |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
> b/arch/arm/mach-omap2/powerdomains34xx.h
> index 4dcf94b..aa557b2 100644
> --- a/arch/arm/mach-omap2/powerdomains34xx.h
> +++ b/arch/arm/mach-omap2/powerdomains34xx.h
> @@ -338,7 +338,13 @@ static struct powerdomain usbhost_pwrdm = {
> .sleepdep_srcs= dss_per_usbhost_sleepdeps,
> .pwrsts = PWRSTS_OFF_RET_ON,
> .pwrsts_logic_ret = PWRDM_POWER_RET,
> - .flags= PWRDM_HAS_HDWR_SAR, /* for USBHOST ctrlr only */
> + /*
> + * REVISIT: Enabling usb host save and restore mechanism seems to
> + * leave the usb host domain permanently in ACTIVE mode after
> + * changing the usb host power domain state from OFF to active once.
> + * Disabling for now.
> + */
> + /*.flags = PWRDM_HAS_HDWR_SAR,*/ /* for USBHOST ctrlr only */
> .banks= 1,
> .pwrsts_mem_ret = {
> [0] = PWRDM_POWER_RET, /* MEMRETSTATE */
> --
> 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] ARM: OMAP3: Fix OMAP_CHIP_INIT usage
Paul Walmsley writes:
> On Thu, 23 Apr 2009, Kalle Jokiniemi wrote:
>
>> Some modules have been specified only to exist in ES2.0
>> devices while they should exist on >= ES2.0 devices.
>> Fixed OMAP_CHIP_INIT() calls to take this to account.
>>
>> Signed-off-by: Kalle Jokiniemi
>
> At least the omapdev3xxx.h changes are:
>
> Acked-by: Paul Walmsley
>
> This patch is specific to the PM branch.
>
Pushing to PM branch today.
Kevin
>
>> ---
>> arch/arm/mach-omap2/omapdev3xxx.h |8
>> arch/arm/mach-omap2/resource34xx.h |4 ++--
>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omapdev3xxx.h
>> b/arch/arm/mach-omap2/omapdev3xxx.h
>> index dce87df..d2772c4 100644
>> --- a/arch/arm/mach-omap2/omapdev3xxx.h
>> +++ b/arch/arm/mach-omap2/omapdev3xxx.h
>> @@ -374,7 +374,7 @@ static struct omapdev neon_3xxx_omapdev = {
>> static struct omapdev sgx_3xxx_omapdev = {
>> .name = "sgx_omapdev",
>> .pwrdm = { .name = "sgx_pwrdm" },
>> -.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
>> +.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
>> };
>>
>> /* CORE */
>> @@ -435,7 +435,7 @@ static struct omapdev hsmmc3_3xxx_omapdev = {
>> .pwrdm = { .name = "core_pwrdm" },
>> .pdev_name = "mmci-omap",
>> .pdev_id= 2,
>> -.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
>> +.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
>> };
>>
>> static struct omapdev mcspi4_3xxx_omapdev = {
>> @@ -658,7 +658,7 @@ static struct omapdev usbhost_3xxx_omapdev = {
>> .pwrdm = { .name = "usbhost_pwrdm" },
>> .pdev_name = "ehci-omap",
>> .pdev_id= 0,
>> -.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
>> +.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
>> };
>>
>> static struct omapdev usbotg_3xxx_omapdev = {
>> @@ -666,7 +666,7 @@ static struct omapdev usbotg_3xxx_omapdev = {
>> .pwrdm = { .name = "usbhost_pwrdm" },
>> .pdev_name = "musb_hdrc",
>> .pdev_id= -1,
>> -.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
>> +.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
>> };
>>
>> static struct omapdev usbtll_3xxx_omapdev = {
>> diff --git a/arch/arm/mach-omap2/resource34xx.h
>> b/arch/arm/mach-omap2/resource34xx.h
>> index b847208..8d95a00 100644
>> --- a/arch/arm/mach-omap2/resource34xx.h
>> +++ b/arch/arm/mach-omap2/resource34xx.h
>> @@ -133,7 +133,7 @@ static struct shared_resource gfx_pwrdm_latency = {
>>
>> static struct shared_resource sgx_pwrdm_latency = {
>> .name = "sgx_pwrdm_latency",
>> -.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
>> +.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
>> .resource_data = &sgx_pwrdm_lat_db,
>> .ops= &pd_lat_res_ops,
>> };
>> @@ -208,7 +208,7 @@ static struct pd_latency_db usbhost_pwrdm_lat_db = {
>>
>> static struct shared_resource usbhost_pwrdm_latency = {
>> .name = "usbhost_pwrdm_latency",
>> -.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2),
>> +.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
>> .resource_data = &usbhost_pwrdm_lat_db,
>> .ops= &pd_lat_res_ops,
>> };
>> --
>> 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
>>
>
>
> - 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] OMAP: PM: Fixed omap_pm_set_min_bus_tput
Tero Kristo writes:
> From: Tero Kristo
>
> Parameter check for this function was bugged.
>
> Applies on top of PM branch.
>
> Signed-off-by: Tero Kristo
> Signed-off-by: Jouni Hogander
Thanks, pushing to PM branch today.
Kevin
> arch/arm/plat-omap/omap-pm-noop.c |4 ++--
> arch/arm/plat-omap/omap-pm-srf.c |4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/plat-omap/omap-pm-noop.c
> b/arch/arm/plat-omap/omap-pm-noop.c
> index 490bc8e..4ba261a 100644
> --- a/arch/arm/plat-omap/omap-pm-noop.c
> +++ b/arch/arm/plat-omap/omap-pm-noop.c
> @@ -62,8 +62,8 @@ void omap_pm_set_max_mpu_wakeup_lat(struct device *dev,
> long t)
>
> void omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long
> r)
> {
> - if (!dev || agent_id != OCP_INITIATOR_AGENT ||
> - agent_id != OCP_TARGET_AGENT) {
> + if (!dev || (agent_id != OCP_INITIATOR_AGENT &&
> + agent_id != OCP_TARGET_AGENT)) {
> WARN_ON(1);
> return;
> };
> diff --git a/arch/arm/plat-omap/omap-pm-srf.c
> b/arch/arm/plat-omap/omap-pm-srf.c
> index 72e32de..226662d 100644
> --- a/arch/arm/plat-omap/omap-pm-srf.c
> +++ b/arch/arm/plat-omap/omap-pm-srf.c
> @@ -76,8 +76,8 @@ void omap_pm_set_max_mpu_wakeup_lat(struct device *dev,
> long t)
>
> void omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long
> r)
> {
> - if (!dev || agent_id != OCP_INITIATOR_AGENT ||
> - agent_id != OCP_TARGET_AGENT) {
> + if (!dev || (agent_id != OCP_INITIATOR_AGENT &&
> + agent_id != OCP_TARGET_AGENT)) {
> WARN_ON(1);
> return;
> };
> --
> 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
--
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: PM: Added resource refresh to OPP unlock requests
Tero Kristo writes:
> From: Tero Kristo
>
> This will set the correct OPP after a lock has been released from sysfs.
>
> Applies on PM branch.
>
> Signed-off-by: Tero Kristo
> Signed-off-by: Jouni Hogander
Thanks, pushing to PM branch today.
Kevin
> ---
> arch/arm/mach-omap2/pm.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index dde0af3..58ed520 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -166,6 +166,7 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
> kobj_attribute *attr,
> attr = &vdd1_opp_attr;
> if (vdd1_locked && value == 0) {
> resource_unlock_opp(VDD1_OPP);
> + resource_refresh();
> vdd1_locked = 0;
> return n;
> }
> @@ -178,6 +179,7 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
> kobj_attribute *attr,
> attr = &vdd2_opp_attr;
> if (vdd2_locked && value == 0) {
> resource_unlock_opp(VDD2_OPP);
> + resource_refresh();
> vdd2_locked = 0;
> return n;
> }
> --
> 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
--
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] ARM: OMAP: Update contact address of I2C registration helper
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): 33c883f8e2413e0371b895743861d15351419225 PatchWorks http://patchwork.kernel.org/patch/18663/ 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=33c883f8e2413e0371b895743861d15351419225 -- 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] OMAP: Make sure all resources used by the gpio-switch IRQ
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): 3aff56edc2000488d749aca622c667533c28ae0f PatchWorks http://patchwork.kernel.org/patch/18660/ 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=3aff56edc2000488d749aca622c667533c28ae0f -- 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] ARM: OMAP: Fix path for omap-sha1-md5 import of irqs.h
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): 2e4a0b9ddbc1c788d20321b5b8fdf4c1c20baf07 PatchWorks http://patchwork.kernel.org/patch/16356/ 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=2e4a0b9ddbc1c788d20321b5b8fdf4c1c20baf07 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Fix path for omap-sha1-md5 import of irqs.h
Hi, * Mike Auty [090404 14:40]: > Hi there, > > This is my first kernel-type patch, so please go easy on me if I've made > any mistakes. I recently tried building the master kernel from master > (commit e75343a207ef24490176abe3503743d7a006e299) and it failed at > omap-sha1-md5.c with a file not found issue (asm/arch-omap/irqs.h).I > looked for a similar file, and figured that it meant > asm/plat-omap/include/mach/irqs.h, so I produced the patch below. > Hopefully that's the correct solution, but I'd appreciate it if someone > else could look it over too. Thanks very much, Sorry for the delay.. I'll apply this to linux-omap tree. Do you want to take this driver and prepare a patch to the associated driver mailing list so we can get it integrated? Regards, Tony > Mike 5:) > > --- > drivers/crypto/omap-sha1-md5.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/crypto/omap-sha1-md5.c b/drivers/crypto/omap-sha1-md5.c > index 6d77703..90ad56f 100644 > --- a/drivers/crypto/omap-sha1-md5.c > +++ b/drivers/crypto/omap-sha1-md5.c > @@ -13,7 +13,7 @@ > * This driver is based on padlock-sha.c driver. > */ > > -#include > +#include > #include > #include > #include > -- > 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] ARM: OMAP3: Fix HW SAVEANDRESTORE shift define
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): e2196a74ba4faeb272caef961b22e9ab982fb442 PatchWorks http://patchwork.kernel.org/patch/15586/ 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=e2196a74ba4faeb272caef961b22e9ab982fb442 -- 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] OMAP: McBSP: Fix legacy interrupts to clear their status
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): cffe61bb4de2c8f1ccf7e87ed5d7008d68001ff8 PatchWorks http://patchwork.kernel.org/patch/13934/ 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=cffe61bb4de2c8f1ccf7e87ed5d7008d68001ff8 -- 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] ASoC: Added OMAP3 EVM support in ASoC.
On Thu, 2009-05-14 at 08:39 -0700, Tony Lindgren wrote: > Are there still some problems from ASoC point of view to > convert ASoC to do the platform_device_alloc() from > board init files? This is still something that needs to be done for cards - the driver is always called soc-audio. It needs an update to allow the platform device for the codec to call snd_soc_register_card() directly to support this but there's not much demand at the minute, I'm more concerned with getting the CODEC drivers converted to use the standard device model to register first. -- 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
PM: timeout waiting for write of PM_WKEN_WKUP.EN_IO_CHAIN
Kalle, In your "Enable IO-CHAIN wakeup" patch[1], you set a timout based on 1000 tries of reading back from PM_WKST_WKUP. Just curious how you came up with that value. On ES3.1 3430SDP, some TI folks are seeing that timeout warning every time hitting idle. Kevin [1] http://marc.info/?l=linux-omap&m=123807750921423&w=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
Re: [PATCH] OMAP3: PM: Force USB to standby if not used
Tero Kristo writes:
> From: Tero Kristo
>
> This patch will allow device to enter sleep mode while a USB cable is
> connected and USB is either disabled or built as a module from kernel
> config.
>
> Applies on top of PM branch.
>
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/usb-musb.c | 10 --
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
> index 12a9b0a..dd51d2f 100644
> --- a/arch/arm/mach-omap2/usb-musb.c
> +++ b/arch/arm/mach-omap2/usb-musb.c
> @@ -32,7 +32,9 @@
> #include
>
> #define AUTOIDLE(1 << 0)
> +#define FORCESTDBY (1 << 0)
> #define OTG_SYSCONFIG(OMAP34XX_HSUSB_OTG_BASE + 0x404)
> +#define OTG_FORCESTDBY (OMAP34XX_HSUSB_OTG_BASE + 0x414)
>
> static struct resource musb_resources[] = {
> [0] = { /* start and end set dynamically */
> @@ -185,7 +187,11 @@ void __init usb_musb_init(void)
> return;
> }
>
> - /* Enable smartidle on MUSB to improve C1 wakeup latency */
> - if (cpu_is_omap34xx())
> +#if !defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)
> + /* Force MUSB to standby if not used */
> + if (cpu_is_omap34xx()) {
> omap_writel(AUTOIDLE, OTG_SYSCONFIG);
> + omap_writel(FORCESTDBY, OTG_FORCESTDBY);
> + }
> +#endif
Tero,
Is this needed if OTG_SYSCONFIG is set to force-idle?
Yesterday, I pushed a patch changing OTG_SYSCONFIG to force-idle
instead of auto-idle since on ES3.0 3430SDP, having it in auto-idle
was keeping CORE from hitting retention. IIUC, there's an errata
where force-idle doesn't work properly.
Also, why the #ifdefs?
This code is already conditionally compiled based on
CONFIG_USB_MUSB_SOC (see mach-omap2/Makefile) which is set whether
MUSB is built-in or a module.
#if !defined(CONFIG_USB) then CONFIG_USB_MUSB_SOC will not be defined
either.
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
High iowait time with NFS on OMAP3EVM
Hi, When I copy a large file to/from NFS mounted filesystem, the system becomes unresponsive and top command shows very high iowait(80%+) time. Though the IO operation goes through, typical throughput is < 8Mbps/sec. On the same system, testing for Ethernet driver throughput using iperf yields close to 50Mb/sec throughput. (I am using the tip of linux-omap and running on OMAP3EVM using smc911x driver) Any pointers on what could result in degradation of throughput when using NFS and the resulting high iowait time? Regards Sriram -- 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] ASoC: Added OMAP3 EVM support in ASoC.
Hi Mark,
One question below.
* Anuj Aggarwal [090514 01:30]:
> Resending the patch after fixing the minor issues.
>
> Signed-off-by: Anuj Aggarwal
> ---
> sound/soc/omap/Kconfig|8 +++
> sound/soc/omap/Makefile |2 +
> sound/soc/omap/omap3evm.c | 147
> +
> 3 files changed, 157 insertions(+), 0 deletions(-)
> create mode 100644 sound/soc/omap/omap3evm.c
> --- /dev/null
> +++ b/sound/soc/omap/omap3evm.c
> +static int __init omap3evm_soc_init(void)
> +{
> + int ret;
> +
> + if (!machine_is_omap3evm()) {
> + pr_err("Not OMAP3 EVM!\n");
> + return -ENODEV;
> + }
> + pr_info("OMAP3 EVM SoC init\n");
> +
> + omap3evm_snd_device = platform_device_alloc("soc-audio", -1);
> + if (!omap3evm_snd_device) {
> + printk(KERN_ERR "Platform device allocation failed\n");
> + return -ENOMEM;
> + }
> +
> + platform_set_drvdata(omap3evm_snd_device, &omap3evm_snd_devdata);
> + omap3evm_snd_devdata.dev = &omap3evm_snd_device->dev;
> + *(unsigned int *)omap3evm_dai.cpu_dai->private_data = 1;
> +
> + ret = platform_device_add(omap3evm_snd_device);
> + if (ret)
> + goto err1;
> +
> + return 0;
> +
> +err1:
> + printk(KERN_ERR "Unable to add platform device\n");
> + platform_device_put(omap3evm_snd_device);
> +
> + return ret;
> +}
> +
> +static void __exit omap3evm_soc_exit(void)
> +{
> + platform_device_unregister(omap3evm_snd_device);
> +}
Are there still some problems from ASoC point of view to
convert ASoC to do the platform_device_alloc() from
board init files?
So for omaps, the platform_device_add() sould be called from
the arch/arm/*omap*/board-*.c files.
To recap, there should not be any need to do the machine_is_xxx()
calls in the drivers. Currently if multiple boards are called,
all the xxx_soc_init() calls get unnecessarily called.
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 "REMOVE OMAP LEGACY CODE: Reset mach-omap1/board-*.c files to mainline" breaks nokia770
* Felipe Balbi [090514 01:15]: > On Thu, May 14, 2009 at 03:44:14AM +0200, ext Tony Lindgren wrote: > > * Felipe Balbi [090513 17:33]: > > > On Thu, May 14, 2009 at 01:46:51AM +0200, ext Andrew de Quincey wrote: > > > > Hi, I've just discovered that the patch at: > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=3eae3ea7c443fc4330574dffea65b6f2f53a2574 > > > > > > > > Breaks the nokia770's framebuffer as it removes the platform data for > > > > the HWA742 LCD controller. > > > > > > > > As the patch says "Patches against the mainline tree are welcome to > > > > add back the missing functionality if needed!", I'm happy to do this. > > > > > > > > However, since I'm fairly new to the linux-omap project, is simply > > > > extracting the removed nokia770 code and generating a patch against > > > > the mainline kernel sufficient? or is there a newer style of some sort > > > > that should be adopted for this? > > > > > > You can start by generating the new patch against mainline and running > > > scripts/checkpatch.pl, then you should probably find out if there are > > > any API changes and stuff like that. Then send the patch to lkml ccing > > > linux-omap and let's see what comments do you get from those guys :-) > > > > Please change the code to pass the struct clock to > > drivers/video/omap/hwa742.c > > in hwa742_platform_data. The hw742.c can just do standard clk_enable/disable > > there. Otherwise we won't be able to get this missing part to the mainline > > kernel. > > how about clkdev then ? are we gonna support that for omap1 still ? Yeah the clkdev is there, but in the case of the LCD the clock can be any clock, so we cannot set just one "fck" for all the omap1 LCD panels. In this case the "bclk" is used for the LCD, but "bclk" could be used for other devices as well, not just LCD. 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
[APPLIED] [PATCH] Fix the size of twl4030 script
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): f5e41f6b2a0ec9877d0ecee294afd57a8597c671 PatchWorks http://patchwork.kernel.org/patch/17530/ 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=f5e41f6b2a0ec9877d0ecee294afd57a8597c671 -- 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] Fix the size of twl4030 script
* Peter 'p2' De Schrijver [090514 01:58]: > On Thu, May 14, 2009 at 01:40:14AM +0200, ext Tony Lindgren wrote: > > * Kim Kyuwon [090506 18:36]: > > > Hi All, > > > > > > I sent this patch about 1 month ago. > > > Can anybody check I'm sending correct patch? > > > > Peter, care to ack? Any news on sending the scripts part of twl > > driver upstream? > > > > Regards, > > Ack. No news on sending this upstream yet. Too busy resolving other > problems now :( Thanks, will push to l-o. Let's hope you'll get other issues out of the way soon :) 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] OMAP: UART: don't initialize membase and mapbase when its port is not enabled
2009/5/14 Kim Kyuwon :
> Hi All,
>
> We are using two UARTs port in OMAP3430 board shown as following
> UART 1 - not used
> UART 2 - BT
> UART 3 - console ("console=ttyS2,115200n8" in 'bootargs' of bootloader)
>
> Because we are not using UART port 1, I configured our board file as following
> 735 static struct omap_uart_config omap3_boardname_uart_config __initdata = {
> 736 .enabled_uarts = ((1 << 1) | (1 << 2)),
> 737 };
> However, I couldn't see any console message.
>
> If I configured like
> 735 static struct omap_uart_config omap3_boardname_uart_config __initdata = {
> 736 .enabled_uarts = ((1 << 0) (1 << 1) | (1 << 2)),
> 737 };
> I could see console messages. But I think this is not the real solution.
>
> Is it correct to use ttyS2, if I use UART3 as console UART?
>
> Anyway, I kept track of this problem and I'm sending the patch.
In your case UART2 becomes ttyS0 and UART3 becomes ttyS1, so use
"console=ttyS1" in your bootargs. There is no point exposing UART1 as
ttyS0 in Linux if it's not connected on your board.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] DSPBRIDGE: Convert ioctl() to unlocked_ioctl()
Thanks, Doyu-san.
We will push this change once system level validation is completed with TI test
suites.
Thank you,
Best regards,
Hari
> -Original Message-
> From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
> Sent: Thursday, May 14, 2009 1:12 AM
> To: Kanigeri, Hari
> Cc: Menon, Nishanth; linux-omap@vger.kernel.org; Doyu Hiroshi (Nokia-
> D/Helsinki); Hiroshi DOYU
> Subject: [PATCH 1/1] DSPBRIDGE: Convert ioctl() to unlocked_ioctl()
>
> From: Doyu Hiroshi (Nokia-D/Helsinki)
>
> dspbridge doesn't need BKL.
>
> Signed-off-by: Hiroshi DOYU
> ---
> drivers/dsp/bridge/rmgr/drv_interface.c |4 ++--
> drivers/dsp/bridge/rmgr/drv_interface.h |2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
> b/drivers/dsp/bridge/rmgr/drv_interface.c
> index 9466409..1659e2d 100755
> --- a/drivers/dsp/bridge/rmgr/drv_interface.c
> +++ b/drivers/dsp/bridge/rmgr/drv_interface.c
> @@ -197,7 +197,7 @@ static struct GT_Mask driverTrace;
> static struct file_operations bridge_fops = {
> .open = bridge_open,
> .release= bridge_release,
> - .ioctl = bridge_ioctl,
> + .unlocked_ioctl = bridge_ioctl,
> .mmap = bridge_mmap,
> };
>
> @@ -686,7 +686,7 @@ static int bridge_release(struct inode *ip, struct
> file *filp)
> }
>
> /* This function provides IO interface to the bridge driver. */
> -static int bridge_ioctl(struct inode *ip, struct file *filp, unsigned int
> code,
> +static int bridge_ioctl(struct file *filp, unsigned int code,
> unsigned long args)
> {
> int status;
> diff --git a/drivers/dsp/bridge/rmgr/drv_interface.h
> b/drivers/dsp/bridge/rmgr/drv_interface.h
> index f5b068e..3e77ed0 100644
> --- a/drivers/dsp/bridge/rmgr/drv_interface.h
> +++ b/drivers/dsp/bridge/rmgr/drv_interface.h
> @@ -34,7 +34,7 @@ static int __init bridge_init(void);/* Initialize
> bridge */
> static void __exit bridge_exit(void);/* Opposite of initialize */
> static int bridge_open(struct inode *, struct file *); /* Open */
> static int bridge_release(struct inode *, struct file *);/* Release */
> -static int bridge_ioctl(struct inode *, struct file *, unsigned int,
> +static int bridge_ioctl(struct file *, unsigned int,
> unsigned long);
> static int bridge_mmap(struct file *filp, struct vm_area_struct *vma);
> #endif /* ifndef _DRV_INTERFACE_H_ */
> --
> 1.6.0.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: PM: Fixed omap_pm_set_min_bus_tput
From: Tero Kristo
Parameter check for this function was bugged.
Applies on top of PM branch.
Signed-off-by: Tero Kristo
Signed-off-by: Jouni Hogander
---
arch/arm/plat-omap/omap-pm-noop.c |4 ++--
arch/arm/plat-omap/omap-pm-srf.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index 490bc8e..4ba261a 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -62,8 +62,8 @@ void omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long
t)
void omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r)
{
- if (!dev || agent_id != OCP_INITIATOR_AGENT ||
- agent_id != OCP_TARGET_AGENT) {
+ if (!dev || (agent_id != OCP_INITIATOR_AGENT &&
+ agent_id != OCP_TARGET_AGENT)) {
WARN_ON(1);
return;
};
diff --git a/arch/arm/plat-omap/omap-pm-srf.c b/arch/arm/plat-omap/omap-pm-srf.c
index 72e32de..226662d 100644
--- a/arch/arm/plat-omap/omap-pm-srf.c
+++ b/arch/arm/plat-omap/omap-pm-srf.c
@@ -76,8 +76,8 @@ void omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long
t)
void omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r)
{
- if (!dev || agent_id != OCP_INITIATOR_AGENT ||
- agent_id != OCP_TARGET_AGENT) {
+ if (!dev || (agent_id != OCP_INITIATOR_AGENT &&
+ agent_id != OCP_TARGET_AGENT)) {
WARN_ON(1);
return;
};
--
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
[PATCH] OMAP3: PM: Force USB to standby if not used
From: Tero Kristo
This patch will allow device to enter sleep mode while a USB cable is
connected and USB is either disabled or built as a module from kernel
config.
Applies on top of PM branch.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/usb-musb.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 12a9b0a..dd51d2f 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -32,7 +32,9 @@
#include
#define AUTOIDLE(1 << 0)
+#define FORCESTDBY (1 << 0)
#define OTG_SYSCONFIG (OMAP34XX_HSUSB_OTG_BASE + 0x404)
+#define OTG_FORCESTDBY (OMAP34XX_HSUSB_OTG_BASE + 0x414)
static struct resource musb_resources[] = {
[0] = { /* start and end set dynamically */
@@ -185,7 +187,11 @@ void __init usb_musb_init(void)
return;
}
- /* Enable smartidle on MUSB to improve C1 wakeup latency */
- if (cpu_is_omap34xx())
+#if !defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)
+ /* Force MUSB to standby if not used */
+ if (cpu_is_omap34xx()) {
omap_writel(AUTOIDLE, OTG_SYSCONFIG);
+ omap_writel(FORCESTDBY, OTG_FORCESTDBY);
+ }
+#endif
}
--
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
[PATCH] OMAP3: PM: Added resource refresh to OPP unlock requests
From: Tero Kristo
This will set the correct OPP after a lock has been released from sysfs.
Applies on PM branch.
Signed-off-by: Tero Kristo
Signed-off-by: Jouni Hogander
---
arch/arm/mach-omap2/pm.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index dde0af3..58ed520 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -166,6 +166,7 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
kobj_attribute *attr,
attr = &vdd1_opp_attr;
if (vdd1_locked && value == 0) {
resource_unlock_opp(VDD1_OPP);
+ resource_refresh();
vdd1_locked = 0;
return n;
}
@@ -178,6 +179,7 @@ static ssize_t vdd_opp_store(struct kobject *kobj, struct
kobj_attribute *attr,
attr = &vdd2_opp_attr;
if (vdd2_locked && value == 0) {
resource_unlock_opp(VDD2_OPP);
+ resource_refresh();
vdd2_locked = 0;
return n;
}
--
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: [alsa-devel] [PATCH] ASoC: Added OMAP3 EVM support in ASoC.
On Thu, May 14, 2009 at 01:59:19PM +0530, Anuj Aggarwal wrote: > Resending the patch after fixing the minor issues. > > Signed-off-by: Anuj Aggarwal Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] I2C:Moving Register Defines to Header File
> IMO, The regs do not need to move to a separate header unless they will > be used outside of i2c-omap.c. > Would it not be cleaner to move them to a separate header file, especially considering the fact that we have some 19 registers for OMAP3 I2C and when we redefine them for OMAP4, there would be 38 (infact 40, including the two new registers) lines of just register definitions at the top of the file? -- Jagadeesh -- 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: LDP support
On Wed, May 06, 2009 at 06:00:16AM +0200, ext Tony Lindgren wrote: > * Russell King - ARM Linux [090505 12:52]: > > On Tue, Apr 28, 2009 at 03:42:37PM -0700, Tony Lindgren wrote: > > > * Russell King - ARM Linux [090428 15:07]: > > > > Tony, et.al., > > > > > > > > Any ideas when more LDP support will be pushed into mainline (such as > > > > the framebuffer support)? > > > > > > I'll be looking at the board-*.c patches for the next merge window > > > hopefully this week or next week. > > > > > > Looks like LDP keyboard, touchscreen & RTC are pretty much ready > > > to go. Then the MMC has some regulator updates, but AFAIK the MMC > > > should work OK already. > > > > > > For the framebuffer, Imre and Tomi know the status the best, so > > > I've added them to Cc. > > > > > > Imre has been meaning to send a bunch of drivers/video/omap changes > > > to the fbdev list for a while now and LDP framebuffer may depend on > > > those. Imre, any news on the status of sending the fb patches > > > upstream? > > > > > > Then there are the upcoming DSS patches from Tomi, but those still > > > need some work before they're ready to go. > > > > Is there any news on this? Will we see more functional OMAP3 / LDP > > support queued for the next merge window? > > Yes fro the stuff listed above, but still no news on the framebuffer > patches. Imre? There is a mainline based tree with the missing DSS1 FB stuff that I'm planning to submit to fb-devel: git clone git://koowaldah.org/people/imre/linux-2.6-fb I could only compile test it for OMAP2/3 targets, it would be nice if someone could check if it works too. Also if some DSS1 FB related things are still missing from that tree, I could add them / submit them with the rest of the things. Sorry for the big delay. --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
Re: [PATCH] Fix the size of twl4030 script
On Thu, May 14, 2009 at 01:40:14AM +0200, ext Tony Lindgren wrote: > * Kim Kyuwon [090506 18:36]: > > Hi All, > > > > I sent this patch about 1 month ago. > > Can anybody check I'm sending correct patch? > > Peter, care to ack? Any news on sending the scripts part of twl > driver upstream? > > Regards, Ack. No news on sending this upstream yet. Too busy resolving other problems now :( Cheers, Peter. -- goa is a state of mind -- 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] OMAP: UART: don't initialize membase and mapbase when its port is not enabled
Hi All,
We are using two UARTs port in OMAP3430 board shown as following
UART 1 - not used
UART 2 - BT
UART 3 - console ("console=ttyS2,115200n8" in 'bootargs' of bootloader)
Because we are not using UART port 1, I configured our board file as following
735 static struct omap_uart_config omap3_boardname_uart_config __initdata = {
736 .enabled_uarts = ((1 << 1) | (1 << 2)),
737 };
However, I couldn't see any console message.
If I configured like
735 static struct omap_uart_config omap3_boardname_uart_config __initdata = {
736 .enabled_uarts = ((1 << 0) (1 << 1) | (1 << 2)),
737 };
I could see console messages. But I think this is not the real solution.
Is it correct to use ttyS2, if I use UART3 as console UART?
Anyway, I kept track of this problem and I'm sending the patch.
Please let me know your opinion about this patch.
---
>From 88fc1f0872fd2c6ac42501027e5bf69156cce37f Mon Sep 17 00:00:00 2001
From: Kim Kyuwon
Date: Thu, 14 May 2009 17:05:35 +0900
Subject: [PATCH] OMAP: UART: don't initialize membase and mapbase when
its port is not enabled
If membase and mapbase are zero, its uart port which is registered to
serial8250(i.e serial8250_port[i]) is overridden, because the
serial8250_find_match_or_unsed() function consider this port as a
unused entry. This make the serial2850_console_setup function use
incorrect uart port, because co->index is used as the index of
serial8250_port. This patch prevent using wrong index of uart.
Signed-off-by: Kim Kyuwon
---
arch/arm/mach-omap2/serial.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 4dcf39c..01c2da7 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -118,11 +118,8 @@ void __init omap_serial_init(void)
for (i = 0; i < OMAP_MAX_NR_PORTS; i++) {
struct plat_serial8250_port *p = serial_platform_data + i;
- if (!(info->enabled_uarts & (1 << i))) {
- p->membase = NULL;
- p->mapbase = 0;
+ if (!(info->enabled_uarts & (1 << i)))
continue;
- }
sprintf(name, "uart%d_ick", i+1);
uart_ick[i] = clk_get(NULL, name);
--
1.5.2.5
--
Kyuwon (규원)
--
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] ASoC: Added OMAP3 EVM support in ASoC.
Resending the patch after fixing the minor issues.
Signed-off-by: Anuj Aggarwal
---
sound/soc/omap/Kconfig|8 +++
sound/soc/omap/Makefile |2 +
sound/soc/omap/omap3evm.c | 147 +
3 files changed, 157 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/omap/omap3evm.c
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 675732e..b771238 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -39,6 +39,14 @@ config SND_OMAP_SOC_OMAP2EVM
help
Say Y if you want to add support for SoC audio on the omap2evm board.
+config SND_OMAP_SOC_OMAP3EVM
+ tristate "SoC Audio support for OMAP3EVM board"
+ depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3EVM
+ select SND_OMAP_SOC_MCBSP
+ select SND_SOC_TWL4030
+ help
+ Say Y if you want to add support for SoC audio on the omap3evm board.
+
config SND_OMAP_SOC_SDP3430
tristate "SoC Audio support for Texas Instruments SDP3430"
depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP_3430SDP
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index 0c9e4ac..a37f498 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -10,6 +10,7 @@ snd-soc-n810-objs := n810.o
snd-soc-osk5912-objs := osk5912.o
snd-soc-overo-objs := overo.o
snd-soc-omap2evm-objs := omap2evm.o
+snd-soc-omap3evm-objs := omap3evm.o
snd-soc-sdp3430-objs := sdp3430.o
snd-soc-omap3pandora-objs := omap3pandora.o
snd-soc-omap3beagle-objs := omap3beagle.o
@@ -18,6 +19,7 @@ obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o
obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o
obj-$(CONFIG_MACH_OMAP2EVM) += snd-soc-omap2evm.o
+obj-$(CONFIG_MACH_OMAP3EVM) += snd-soc-omap3evm.o
obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o
diff --git a/sound/soc/omap/omap3evm.c b/sound/soc/omap/omap3evm.c
new file mode 100644
index 000..9114c26
--- /dev/null
+++ b/sound/soc/omap/omap3evm.c
@@ -0,0 +1,147 @@
+/*
+ * omap3evm.c -- ALSA SoC support for OMAP3 EVM
+ *
+ * Author: Anuj Aggarwal
+ *
+ * Based on sound/soc/omap/beagle.c by Steve Sakoman
+ *
+ * Copyright (C) 2008 Texas Instruments, Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "omap-mcbsp.h"
+#include "omap-pcm.h"
+#include "../codecs/twl4030.h"
+
+static int omap3evm_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *codec_dai = rtd->dai->codec_dai;
+ struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
+ int ret;
+
+ /* Set codec DAI configuration */
+ ret = snd_soc_dai_set_fmt(codec_dai,
+ SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM);
+ if (ret < 0) {
+ printk(KERN_ERR "Can't set codec DAI configuration\n");
+ return ret;
+ }
+
+ /* Set cpu DAI configuration */
+ ret = snd_soc_dai_set_fmt(cpu_dai,
+ SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM);
+ if (ret < 0) {
+ printk(KERN_ERR "Can't set cpu DAI configuration\n");
+ return ret;
+ }
+
+ /* Set the codec system clock for DAC and ADC */
+ ret = snd_soc_dai_set_sysclk(codec_dai, 0, 2600,
+SND_SOC_CLOCK_IN);
+ if (ret < 0) {
+ printk(KERN_ERR "Can't set codec system clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct snd_soc_ops omap3evm_ops = {
+ .hw_params = omap3evm_hw_params,
+};
+
+/* Digital audio interface glue - connects codec <--> CPU */
+static struct snd_soc_dai_link omap3evm_dai = {
+ .name = "TWL4030",
+ .stream_name= "TWL4030",
+ .cpu_dai= &omap_mcbsp_dai[0],
+ .codec_dai = &twl4030_dai[TWL4030_DAI_HIFI],
+ .ops= &omap3evm_ops,
+};
+
+/* Audio machine driver */
+static struct snd_soc_card snd_soc_omap3evm
Re: Patch "REMOVE OMAP LEGACY CODE: Reset mach-omap1/board-*.c files to mainline" breaks nokia770
On Thu, May 14, 2009 at 03:44:14AM +0200, ext Tony Lindgren wrote: > * Felipe Balbi [090513 17:33]: > > On Thu, May 14, 2009 at 01:46:51AM +0200, ext Andrew de Quincey wrote: > > > Hi, I've just discovered that the patch at: > > > > > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=3eae3ea7c443fc4330574dffea65b6f2f53a2574 > > > > > > Breaks the nokia770's framebuffer as it removes the platform data for > > > the HWA742 LCD controller. > > > > > > As the patch says "Patches against the mainline tree are welcome to > > > add back the missing functionality if needed!", I'm happy to do this. > > > > > > However, since I'm fairly new to the linux-omap project, is simply > > > extracting the removed nokia770 code and generating a patch against > > > the mainline kernel sufficient? or is there a newer style of some sort > > > that should be adopted for this? > > > > You can start by generating the new patch against mainline and running > > scripts/checkpatch.pl, then you should probably find out if there are > > any API changes and stuff like that. Then send the patch to lkml ccing > > linux-omap and let's see what comments do you get from those guys :-) > > Please change the code to pass the struct clock to drivers/video/omap/hwa742.c > in hwa742_platform_data. The hw742.c can just do standard clk_enable/disable > there. Otherwise we won't be able to get this missing part to the mainline > kernel. how about clkdev then ? are we gonna support that for omap1 still ? -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP3: PM: More pedantic parameter and error checking in smartreflex
On Wed, 2009-05-13 at 18:54 +0200, ext Kevin Hilman wrote: > Phil Carmody writes: > > > On Wed, 2009-05-13 at 17:10 +0200, ext Kevin Hilman wrote: > >> Phil Carmody writes: > >> > >> > A couple of simple patches to improve error handling in smartreflex. > >> > The first has a practical benefit of avoiding a string-based search > >> > in situtations where the result wouldn't be needed. The second is > >> > simple paranoia. > >> > >> Thanks, pushing this series today. > >> > >> Note that I pushed this on top of Rajendra's patch: > >> "OMAP3: SR: Fix SR driver to check for omap-pm return values" > >> and had to resolve a couple of conflicts. > >> > >> Could you please sanity check it? > > > > Sanity check successful. Many thanks, Kevin. > > Hmm, you're too fast for me. It's the time zone difference! > Not sure how you tested as I hadn't pushed your changes yet ;) > > I just pushed them to my pm branch, but they are not yet sync'd to > tony's tree. Can you try now. Freshly pulled, indeed I now see the extent of the rework. I don't know whether -ENODEV or -EINVAL is better, the former just came to mind first when I was in the file. Either way, it looks fine. Thanks again. Phil -- 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
