Re: [PATCH] [OMAP1] Clock fixups for OMAP1 and OMAP7xx

[Paul Walmsley]

Hi Cory,

On Tue, 22 Dec 2009, Cory Maccarrone wrote:

> This change adds in some missing clocks that were needed as a result
> of 526505... (OMAP1 clock: convert mach-omap1/clock.h to
> mach-omap1/clock_data.c).  Prior to this, it was just assumed that
> these clocks existed for all devices, and it was used directly instead
> of calling it out with a clk_get call.  So, not having the CK_7XX
> meant these clocks weren't being used anymore for omap 7xx devices,
> which broke things badly.
> 
> Additionally, that change added an __initdata decoration to the
> structure containing the clk_enable and clk_disable functions.  Once
> init data was freed, these pointers went to null, and the next enable
> or disable call caused the kernel to crash.  This change removes
> this decoration.

Could you please split these two patches, since they fix different 
problems?  Also the first patch is pertinent only to OMAP7xx-family 
chips and the second is OMAP1-wide.  I've already got your first patch, so 
no need to resend that.

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 1/1] ARM: OMAP4: PM: Add check for avoiding dependency related update.

[Paul Walmsley]

Hello Abhijit,

On Wed, 23 Dec 2009, Abhijit Pagare wrote:

> A check is added for avoiding the sleep/wakeup dependency updates
> for OMAP4 as the structures for the dependencies are currently absent.

As a threshold matter, code and data added in temporary hack patches like 
this need to be marked with XXX or FIXME or something similar to indicate 
that these are not intended features, but rather, temporary lines that 
need to be removed in the near term.

But really, I'd rather not apply this patch.  The best way forward is to 
apply a patch that adds the OMAP4 wakeup and sleep dependencies 
themselves.  Have you had a chance to look at the series that I sent you a 
few weeks ago off-list that reorganizes the wakeup and sleep dependencies 
to determine if it is adequate for you to add the OMAP4 wakeup/sleep 
dependencies afterwards?


- Paul  

> 
> Signed-off-by: Abhijit Pagare 
> Cc: Paul Walmsley 
> ---
> 
> Compiled and Boot Tested on OMAP4430 simulator, ES1 Chip & OMAP3430 SDP.
> And also Compiled for OMAP2430 and OMAP2420
> 
> This patch has a dependency on the earlier set of OMAP4 clock-domain patches.
> 
>  arch/arm/mach-omap2/clockdomain.c |   10 ++
>  1 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/clockdomain.c 
> b/arch/arm/mach-omap2/clockdomain.c
> index 8c9e78c..6ec25ee 100644
> --- a/arch/arm/mach-omap2/clockdomain.c
> +++ b/arch/arm/mach-omap2/clockdomain.c
> @@ -507,8 +507,9 @@ void omap2_clkdm_allow_idle(struct clockdomain *clkdm)
>   pr_debug("clockdomain: enabling automatic idle transitions for %s\n",
>clkdm->name);
>  
> - if (atomic_read(&clkdm->usecount) > 0)
> - _clkdm_add_autodeps(clkdm);
> + if (!cpu_is_omap44xx())
> + if (atomic_read(&clkdm->usecount) > 0)
> + _clkdm_add_autodeps(clkdm);
>  
>   _omap2_clkdm_set_hwsup(clkdm, 1);
>  
> @@ -540,8 +541,9 @@ void omap2_clkdm_deny_idle(struct clockdomain *clkdm)
>  
>   _omap2_clkdm_set_hwsup(clkdm, 0);
>  
> - if (atomic_read(&clkdm->usecount) > 0)
> - _clkdm_del_autodeps(clkdm);
> + if (!cpu_is_omap44xx())
> + if (atomic_read(&clkdm->usecount) > 0)
> + _clkdm_del_autodeps(clkdm);
>  }
>  
>  
> -- 
> 1.5.4.7
> 


- 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 1/1] ARM: OMAP4: PM: Add the missing Clock Domain Structure

[Paul Walmsley]

Hello Abhijit,

On Wed, 23 Dec 2009, Abhijit Pagare wrote:

> One of the clock domains was missing from the auto-generated file.
> It has been added here.

Please repost this with the subject line change that Tony mentioned.  The 
rest of the patch is fine.

- Paul

> 
> Signed-off-by: Abhijit Pagare 
> Cc: Paul Walmsley 
> ---
> Compiled and Boot Tested on OMAP4430 simulator, ES1 Chip & OMAP3430 SDP.
> And also Compiled for OMAP2430 and OMAP2420
> 
> This patch has a dependency on the earlier set of OMAP4 clock-domain patches.
> 
>  arch/arm/mach-omap2/clockdomains.h |1 +
>  arch/arm/mach-omap2/clockdomains44xx.h |8 
>  2 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/clockdomains.h 
> b/arch/arm/mach-omap2/clockdomains.h
> index f985e0a..6dc5ddc 100644
> --- a/arch/arm/mach-omap2/clockdomains.h
> +++ b/arch/arm/mach-omap2/clockdomains.h
> @@ -461,6 +461,7 @@ static struct clockdomain *clockdomains_omap[] = {
>   &l4_secure_44xx_clkdm,
>   &l4_per_44xx_clkdm,
>   &abe_44xx_clkdm,
> + &l3_instr_44xx_clkdm,
>   &l3_init_44xx_clkdm,
>   &mpuss_44xx_clkdm,
>   &mpu0_44xx_clkdm,
> diff --git a/arch/arm/mach-omap2/clockdomains44xx.h 
> b/arch/arm/mach-omap2/clockdomains44xx.h
> index 6fc55e4..438aaee 100644
> --- a/arch/arm/mach-omap2/clockdomains44xx.h
> +++ b/arch/arm/mach-omap2/clockdomains44xx.h
> @@ -102,6 +102,14 @@ static struct clockdomain abe_44xx_clkdm = {
>   .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>  };
>  
> +static struct clockdomain l3_instr_44xx_clkdm = {
> + .name = "l3_instr_clkdm",
> + .pwrdm= { .name = "core_pwrdm" },
> + .clkstctrl_reg= OMAP4430_CM_L3INSTR_CLKSTCTRL,
> + .clktrctrl_mask   = OMAP4430_CLKTRCTRL_MASK,
> + .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> +};
> +
>  static struct clockdomain l3_init_44xx_clkdm = {
>   .name = "l3_init_clkdm",
>   .pwrdm= { .name = "l3init_pwrdm" },
> -- 
> 1.5.4.7
> 


- 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 1/1] ARM: OMAP4: PM: Remove the checks preventing OMAP4 clockdomain validation

[Paul Walmsley]

On Wed, 23 Dec 2009, Abhijit Pagare wrote:

> The clockdomain related code being in place, it is not necessary to have
> some part of the clock code commented out. This would help the validation of
> the clockdomain functions using the clock level interfaces.

... likewise, with this patch, please fix the subject line, per Tony's 
E-mail.


- Paul


> 
> Signed-off-by: Abhijit Pagare 
> Cc: Paul Walmsley 
> ---
> 
> Compiled and Boot Tested on OMAP4430 simulator, ES1 Chip & OMAP3430 SDP.
> And also Compiled for OMAP2430 and OMAP2420
> 
> This patch has a dependency on the earlier set of OMAP4 clock-domain patches.
> 
>  arch/arm/mach-omap2/clock.c  |8 
>  arch/arm/mach-omap2/clock44xx_data.c |2 --
>  2 files changed, 0 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index 759c72a..a6d570a 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -181,7 +181,6 @@ static int _dpll_test_fint(struct clk *clk, u8 n)
>   * clockdomain pointer, and save it into the struct clk.  Intended to be
>   * called during clk_register().  No return value.
>   */
> -#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
>  void omap2_init_clk_clkdm(struct clk *clk)
>  {
>   struct clockdomain *clkdm;
> @@ -199,7 +198,6 @@ void omap2_init_clk_clkdm(struct clk *clk)
>"clkdm %s\n", clk->name, clk->clkdm_name);
>   }
>  }
> -#endif
>  
>  /**
>   * omap2_init_clksel_parent - set a clksel clk's parent field from the 
> hardware
> @@ -476,10 +474,8 @@ void omap2_clk_disable(struct clk *clk)
>   _omap2_clk_disable(clk);
>   if (clk->parent)
>   omap2_clk_disable(clk->parent);
> -#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
>   if (clk->clkdm)
>   omap2_clkdm_clk_disable(clk->clkdm, clk);
> -#endif
>  
>   }
>  }
> @@ -489,10 +485,8 @@ int omap2_clk_enable(struct clk *clk)
>   int ret = 0;
>  
>   if (clk->usecount++ == 0) {
> -#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
>   if (clk->clkdm)
>   omap2_clkdm_clk_enable(clk->clkdm, clk);
> -#endif
>  
>   if (clk->parent) {
>   ret = omap2_clk_enable(clk->parent);
> @@ -511,10 +505,8 @@ int omap2_clk_enable(struct clk *clk)
>   return ret;
>  
>  err:
> -#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
>   if (clk->clkdm)
>   omap2_clkdm_clk_disable(clk->clkdm, clk);
> -#endif
>   clk->usecount--;
>   return ret;
>  }
> diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
> b/arch/arm/mach-omap2/clock44xx_data.c
> index 2210e22..f47ba9e 100644
> --- a/arch/arm/mach-omap2/clock44xx_data.c
> +++ b/arch/arm/mach-omap2/clock44xx_data.c
> @@ -2749,9 +2749,7 @@ int __init omap2_clk_init(void)
>   if (c->cpu & cpu_clkflg) {
>   clkdev_add(&c->lk);
>   clk_register(c->lk.clk);
> - /* TODO
>   omap2_init_clk_clkdm(c->lk.clk);
> - */
>   }
>  
>   recalculate_root_clocks();
> -- 
> 1.5.4.7
> 


- 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] OMAP2: add USB platform data and initialization for Nokia N800 and N810

[Luke-Jr]

On Wednesday 30 December 2009 01:17:11 am Kalle Valo wrote:
> "Luke-Jr"  writes:
> > On that topic, is there a reason the newer code is under a unified "N8x0"
> > config option instead of the split N800/N810 that was used for the old
> > code, or is that simply a symptom of the currently-supported features all
> > being common?
> 
> IIRC, I just used one common n8x0 file because the n810 board file was
> very small and I didn't see any benefit from having it separately.

Yeah, that's because someone put all the N810 code in the N800 file ;)

Will probably at least split out the differences, if there's no other reason, 
then. Since I'm doing this stuff only for my own personal interest, I'll 
probably not bother to do much with N800 support unless someone feels like 
sending me one when I finish N810 (definitely not touching N800 before then).

Luke
--
To unsubscribe from this list: send the line "unsubscribe 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: clk2xxx.c doesn't compile if CPUFREQ is enabled

[Paul Walmsley]

Hi Felipe,

On Sat, 26 Dec 2009, Felipe Balbi wrote:

> if we enable CPUFREQ we can't build omap2 for two reasons,
> one of them is fixed by the patch below but the other one
> it seems like it'll need more invasive changes to the code
> so I'll leave it for you to decide how to do it.
> 
> It's basically failing because the __musb_be_array() check
> in ARRAY_SIZE() is failing and printing the following message:
> 
> arch/arm/mach-omap2/clock2xxx.c:453: error: negative width in bit-field 
> ''
> 
> NYET-Signed-off-by: Felipe Balbi 

Care to send a version with a Signed-off-by?  I will base the remaining 
fixes on top of this.  Thanks for reporting this and sending the initial 
patch.


- Paul

> ---
>  arch/arm/mach-omap2/clock2xxx.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
> index d0e3fb7..4e2bdfe 100644
> --- a/arch/arm/mach-omap2/clock2xxx.c
> +++ b/arch/arm/mach-omap2/clock2xxx.c
> @@ -455,12 +455,15 @@ static struct cpufreq_frequency_table 
> freq_table[ARRAY_SIZE(rate_table)];
>  void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
>  {
>   struct prcm_config *prcm;
> + long rate;
>   int i = 0;
>  
> + rate = clk_get_rate(sclk);
> +
>   for (prcm = rate_table; prcm->mpu_speed; prcm++) {
>   if (!(prcm->flags & cpu_mask))
>   continue;
> - if (prcm->xtal_speed != sys_ck.rate)
> + if (prcm->xtal_speed != rate)
>   continue;
>  
>   /* don't put bypass rates in table */
> -- 
> 1.6.6.rc0
> 

--
To unsubscribe from this list: send the line "unsubscribe 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: L4 interconnect memory mapping

[Paul Walmsley]

On Wed, 30 Dec 2009, Felipe Balbi wrote:

> On Tue, 2009-12-29 at 15:46 -0800, Tony Lindgren wrote:
> > * Felipe Balbi  [091229 15:26]:
> > > Hi,
> > > 
> > > On Wed, 2009-12-30 at 01:25 +0200, Felipe Balbi wrote:
> > > > Hi Tony and Paul,
> > > > 
> > > > maybe a silly question, but here it goes:
> > > > 
> > > > Do we have any piece of code handling the L4 interconnect memory space ?
> > > > I mean, looking at omap3 TRM pages 212 - 219, I see that e.g. for the
> > > > musb block we have:
> > > > 
> > > > HS USB OTG  0x480AB000 - 0x480ABFFF 4KB Module
> > > > 0x480AC000 - 0x480ACFFF 4KB L4 interconnect
> > > > 
> > > > So the first 4K is what we pass down to drivers via struct resource and
> > > > the second 4K ? What do we do with that ?
> > > 
> > > no with Paul's address correct.
> > 
> > Looks like you might want to update your earlier patch to just comment
> > that the 8K address space for musb is 4K + 4K for L4 interconnect :)
> 
> was thinking about that just now heh, but what do we do with the extra
> 4k ? It's the same for all other modules. Is omap_hwmod taking care of
> that ?

That second 4KiB range is the interconnect target agent between the 
interconnect and the HS USB OTG IP block.  No need to deal with it.  At 
some point either omap_hwmod or an interconnect driver will probably 
reserve it for bookkeeping purposes.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] ARM : OMAP patches

[Maulik Mankad]

Hi,

Felipe,

Here is the 2 patch series based on top of 
your for-tony branch at [1].

[1] git://gitorious.org/usb/usb.git for-tony

Maulik Mankad (2):
ARM : OMAP: MUSB : Pass board specific data using a structure.
ARM : OMAP4 : MUSB : Add USB support to 4430 SDP board file

The patches are compile tested and do not report
any checkpatch warnings.

The rest of the OMAP4 driver patches shall go through Greg.

Please comment.

Thanks,
Maulik

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ARM : OMAP: MUSB : Pass board specific data using a structure

[Maulik Mankad]

ARM : OMAP: MUSB :Pass board specific data from board file

This patch proposes to pass board specific data for MUSB
(like interface_type, mode etc) from board file by defining
board specific structure.

Each board file can define this structure based on 
its requirement and pass this information to the 
driver.

It addresses a comment from Felipe and thus help
by preventing addition of too many fields in 
musb_platform_data.

Signed-off-by: Maulik Mankad 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Greg Kroah-Hartman 

Index: felipe_musb/arch/arm/mach-omap2/board-2430sdp.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-2430sdp.c
+++ felipe_musb/arch/arm/mach-omap2/board-2430sdp.c
@@ -195,6 +195,12 @@ static struct twl4030_hsmmc_info mmc[] _
{}  /* Terminator */
 };
 
+static struct musb_omap_data omap2430sdp_data = {
+.interface_type= MUSB_INTERFACE_ULPI,
+.mode  = MUSB_OTG,
+.power = 100,
+}
+
 static void __init omap_2430sdp_init(void)
 {
int ret;
@@ -204,7 +210,7 @@ static void __init omap_2430sdp_init(voi
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
omap_serial_init();
twl4030_mmc_init(mmc);
-   usb_musb_init(MUSB_OTG, 100);
+   usb_musb_init(&omap2430sdp_data);
board_smc91x_init();
 
/* Turn off secondary LCD backlight */
Index: felipe_musb/arch/arm/mach-omap2/board-3430sdp.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-3430sdp.c
+++ felipe_musb/arch/arm/mach-omap2/board-3430sdp.c
@@ -651,6 +651,12 @@ static struct omap_board_mux board_mux[]
 #define board_mux  NULL
 #endif
 
+static struct musb_omap_data omap3430sdp_data = {
+.interface_type= MUSB_INTERFACE_ULPI,
+.mode  = MUSB_OTG,
+.power = 100,
+};
+
 static void __init omap_3430sdp_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -665,7 +671,7 @@ static void __init omap_3430sdp_init(voi
ARRAY_SIZE(sdp3430_spi_board_info));
ads7846_dev_init();
omap_serial_init();
-   usb_musb_init(MUSB_OTG, 100);
+   usb_musb_init(&omap3430sdp_data);
board_smc91x_init();
sdp3430_display_init();
enable_board_wakeup_source();
Index: felipe_musb/arch/arm/mach-omap2/board-cm-t35.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-cm-t35.c
+++ felipe_musb/arch/arm/mach-omap2/board-cm-t35.c
@@ -576,6 +576,12 @@ static struct omap_board_mux board_mux[]
{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 
+static struct musb_omap_data omapcm_t35_data = {
+.interface_type= MUSB_INTERFACE_ULPI,
+.mode  = MUSB_OTG,
+.power = 100,
+};
+
 static void __init cm_t35_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CUS);
@@ -586,7 +592,7 @@ static void __init cm_t35_init(void)
cm_t35_init_ethernet();
cm_t35_init_led();
 
-   usb_musb_init(MUSB_OTG, 100);
+   usb_musb_init(&omapcm_t35_data);
 }
 
 MACHINE_START(CM_T35, "Compulab CM-T35")
Index: felipe_musb/arch/arm/mach-omap2/board-igep0020.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-igep0020.c
+++ felipe_musb/arch/arm/mach-omap2/board-igep0020.c
@@ -212,12 +212,18 @@ static struct omap_board_mux board_mux[]
 #define board_mux  NULL
 #endif
 
+static struct musb_omap_data omapigep2_data = {
+.interface_type= MUSB_INTERFACE_ULPI,
+.mode  = MUSB_OTG,
+.power = 100,
+};
+
 static void __init igep2_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
igep2_i2c_init();
omap_serial_init();
-   usb_musb_init(MUSB_OTG, 100);
+   usb_musb_init(&omapigep2_data);
 
igep2_init_smsc911x();
 
Index: felipe_musb/arch/arm/mach-omap2/board-ldp.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-ldp.c
+++ felipe_musb/arch/arm/mach-omap2/board-ldp.c
@@ -384,6 +384,12 @@ static struct omap_board_mux board_mux[]
 #define board_mux  NULL
 #endif
 
+static struct musb_omap_data omapldp_data = {
+.interface_type= MUSB_INTERFACE_ULPI,
+.mode  = MUSB_OTG,
+.power = 100,
+};
+
 static void __init omap_ldp_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -395,7 +401,7 @@ static void __init omap_ldp_init(void)
ARRAY_SIZE(ldp_spi_board_info));
ads7846_dev_init();
omap_serial_init();
-   usb_musb_init(MUSB_OTG, 100);
+   usb_musb_init(&omapldp_data);
 
twl4030_mmc_init(mmc);
/* link regulators to MMC adapters */
Index: felipe_musb/arch/arm/mach-omap2/board-omap3beagle.c
===
--

[PATCH 2/2] ARM : OMAP4 : MUSB : Add USB support to 4430 SDP board file

[Maulik Mankad]

ARM : OMAP4 : Add USB support to 4430 SDP board file

This patch adds support for Mentor USB to 4430 SDP board file.

It also defines the base address for HS USB OTG controller in OMAP4.

Also updates platform specfic structure with base address and IRQ details.

Signed-off-by: Maulik Mankad 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Greg Kroah-Hartman 

Index: felipe_musb/arch/arm/mach-omap2/board-4430sdp.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ felipe_musb/arch/arm/mach-omap2/board-4430sdp.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -27,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct platform_device sdp4430_lcd_device = {
@@ -73,11 +75,22 @@ static void __init omap_4430sdp_init_irq
omap_gpio_init();
 }
 
+static struct musb_omap_data omap4430sdp_data = {
+.interface_type= MUSB_INTERFACE_UTMI,
+.mode  = MUSB_PERIPHERAL,
+.power = 100,
+};
 
 static void __init omap_4430sdp_init(void)
 {
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
+#ifdef CONFIG_NOP_USB_XCEIV
+   /* OMAP4 SDP uses Internal transceiver so register nop transceiver */
+   usb_nop_xceiv_register();
+#endif
+   usb_musb_init(&omap4430sdp_data);
+
 }
 
 static void __init omap_4430sdp_map_io(void)
Index: felipe_musb/arch/arm/mach-omap2/usb-musb.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/usb-musb.c
+++ felipe_musb/arch/arm/mach-omap2/usb-musb.c
@@ -81,8 +81,13 @@ void __init usb_musb_init(void *arch_dat
 
if (cpu_is_omap243x())
musb_resources[0].start = OMAP243X_HS_BASE;
-   else
+   else if (cpu_is_omap34xx())
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
+   else if (cpu_is_omap44xx()) {
+   musb_resources[0].start = OMAP44XX_HSUSB_OTG_BASE;
+   musb_resources[1].start =  INT_44XX_HS_USB_MC;
+   musb_resources[2].start =  INT_44XX_HS_USB_DMA;
+   }
musb_resources[0].end = musb_resources[0].start + SZ_4K - 1;
 
/*
Index: felipe_musb/arch/arm/plat-omap/include/plat/omap44xx.h
===
--- felipe_musb.orig/arch/arm/plat-omap/include/plat/omap44xx.h
+++ felipe_musb/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -43,6 +43,7 @@
 #define OMAP44XX_WKUPGEN_BASE  0x48281000
 
 #define OMAP44XX_MAILBOX_BASE  (L4_44XX_BASE + 0xF4000)
+#define OMAP44XX_HSUSB_OTG_BASE(L4_44XX_BASE + 0xAB000)
 
 #endif /* __ASM_ARCH_OMAP44XX_H */
 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SR2: VDD autocomp is not active

[tarek attia]

Thank you very much :-) .

Appreciate it really .

Regards,

On Wed, Dec 30, 2009 at 8:36 AM, Romit Dasgupta  wrote:
> tarek attia wrote:
>> Thank you :) ,
>>
>> I found the "omap2_clk_init_cpufreq_table" function in the kernel
>> image installed on my board ,and the hanging up is not permanent
>> ,sometimes occurs and some time doesn't .
>>
>> So what the reason may be for this case? ..also what is the usage of
>> "sr_vdd1_autocomp" ??
>>
>> I know that I'm bothering you,,but thanks for your reply in advance :-)
>>
> Nothing to be bothered. Always glad to reply. sr_vdd1_autocomp enables Smart
> reflex voltage autocompensation for VDD1 voltage rail.
> You do seem to have the low level cpufreq driver in place. May be you can try
> with pm branch.
>



-- 
tarek
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/2] ARM : OMAP: MUSB : Pass board specific data using a structure

[Gupta, Ajay Kumar]

Hi,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Mankad, Maulik Ojas
> Sent: Wednesday, December 30, 2009 4:15 PM
> To: linux-omap@vger.kernel.org
> Cc: linux-...@vger.kernel.org; Mankad, Maulik Ojas; Felipe Balbi; Tony
> Lindgren; Greg Kroah-Hartman
> Subject: [PATCH 1/2] ARM : OMAP: MUSB : Pass board specific data using a
> structure
> 
> ARM : OMAP: MUSB :Pass board specific data from board file
> 
> This patch proposes to pass board specific data for MUSB
> (like interface_type, mode etc) from board file by defining
> board specific structure.
> 
> Each board file can define this structure based on
> its requirement and pass this information to the
> driver.
> 
> It addresses a comment from Felipe and thus help
> by preventing addition of too many fields in
> musb_platform_data.
> 
> Signed-off-by: Maulik Mankad 
> Cc: Felipe Balbi 
> Cc: Tony Lindgren 
> Cc: Greg Kroah-Hartman 
> 
> Index: felipe_musb/arch/arm/mach-omap2/board-2430sdp.c
> ===
> --- felipe_musb.orig/arch/arm/mach-omap2/board-2430sdp.c
> +++ felipe_musb/arch/arm/mach-omap2/board-2430sdp.c
> @@ -195,6 +195,12 @@ static struct twl4030_hsmmc_info mmc[] _
>   {}  /* Terminator */
>  };
> 
> +static struct musb_omap_data omap2430sdp_data = {
> +.interface_type  = MUSB_INTERFACE_ULPI,
> +.mode= MUSB_OTG,
> +.power   = 100,
> +}
> +
>  static void __init omap_2430sdp_init(void)
>  {
>   int ret;
> @@ -204,7 +210,7 @@ static void __init omap_2430sdp_init(voi
>   platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
>   omap_serial_init();
>   twl4030_mmc_init(mmc);
> - usb_musb_init(MUSB_OTG, 100);
> + usb_musb_init(&omap2430sdp_data);
>   board_smc91x_init();
> 
>   /* Turn off secondary LCD backlight */
> Index: felipe_musb/arch/arm/mach-omap2/board-3430sdp.c
> ===
> --- felipe_musb.orig/arch/arm/mach-omap2/board-3430sdp.c
> +++ felipe_musb/arch/arm/mach-omap2/board-3430sdp.c
> @@ -651,6 +651,12 @@ static struct omap_board_mux board_mux[]
>  #define board_muxNULL
>  #endif
> 
> +static struct musb_omap_data omap3430sdp_data = {
> +.interface_type  = MUSB_INTERFACE_ULPI,
> +.mode= MUSB_OTG,
> +.power   = 100,
> +};
> +
>  static void __init omap_3430sdp_init(void)
>  {
>   omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> @@ -665,7 +671,7 @@ static void __init omap_3430sdp_init(voi
>   ARRAY_SIZE(sdp3430_spi_board_info));
>   ads7846_dev_init();
>   omap_serial_init();
> - usb_musb_init(MUSB_OTG, 100);
> + usb_musb_init(&omap3430sdp_data);

Isn't it simpler to use same name across the boards like, 'musb_board_data'
Instead of 'omap3430sdp_data'.

>   board_smc91x_init();
>   sdp3430_display_init();
>   enable_board_wakeup_source();
> Index: felipe_musb/arch/arm/mach-omap2/board-cm-t35.c
> ===
> --- felipe_musb.orig/arch/arm/mach-omap2/board-cm-t35.c
> +++ felipe_musb/arch/arm/mach-omap2/board-cm-t35.c
> @@ -576,6 +576,12 @@ static struct omap_board_mux board_mux[]
>   { .reg_offset = OMAP_MUX_TERMINATOR },
>  };
> 
> +static struct musb_omap_data omapcm_t35_data = {
> +.interface_type  = MUSB_INTERFACE_ULPI,
> +.mode= MUSB_OTG,
> +.power   = 100,
> +};
> +
>  static void __init cm_t35_init(void)
>  {
>   omap3_mux_init(board_mux, OMAP_PACKAGE_CUS);
> @@ -586,7 +592,7 @@ static void __init cm_t35_init(void)
>   cm_t35_init_ethernet();
>   cm_t35_init_led();
> 
> - usb_musb_init(MUSB_OTG, 100);
> + usb_musb_init(&omapcm_t35_data);
>  }
> 
>  MACHINE_START(CM_T35, "Compulab CM-T35")
> Index: felipe_musb/arch/arm/mach-omap2/board-igep0020.c
> ===
> --- felipe_musb.orig/arch/arm/mach-omap2/board-igep0020.c
> +++ felipe_musb/arch/arm/mach-omap2/board-igep0020.c
> @@ -212,12 +212,18 @@ static struct omap_board_mux board_mux[]
>  #define board_muxNULL
>  #endif
> 
> +static struct musb_omap_data omapigep2_data = {
> +.interface_type  = MUSB_INTERFACE_ULPI,
> +.mode= MUSB_OTG,
> +.power   = 100,
> +};
> +
>  static void __init igep2_init(void)
>  {
>   omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>   igep2_i2c_init();
>   omap_serial_init();
> - usb_musb_init(MUSB_OTG, 100);
> + usb_musb_init(&omapigep2_data);
> 
>   igep2_init_smsc911x();
> 
> Index: felipe_musb/arch/arm/mach-omap2/board-ldp.c
> ===
> --- felipe_musb.orig/arch/arm/mach-omap2/board-ldp.c
> +++ felipe_musb/arch/arm/mach-omap2/board-ldp.c
> @@ -384,6 +384,12 @@ static struct omap_board_mux board_mux[]
>

Re: [patch-v2.6.33-rc2+ 02/12] arm: omap: musb: fix board power budget by passing it to usb_musb_init

[Sergei Shtylyov]

Hello.

Felipe Balbi wrote:


each board might have a different charge pump and
thus able to source more or less current on vbus
so let power be easily configurable.

Cc: linux-...@vger.kernel.org
Signed-off-by: Felipe Balbi 


[...]


diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index ba71f76..b4b8ccc 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -124,12 +124,7 @@ static struct musb_hdrc_platform_data musb_plat = {
/* .clock is set dynamically */
.set_clock  = musb_set_clock,
.config = &musb_config,
-
-   /* REVISIT charge pump on TWL4030 can supply up to
-* 100 mA ... but this value is board-specific, like
-* "mode", and should be passed to usb_musb_init().
-*/
-   .power  = 50,   /* up to 100 mA */
+   /* .power   = DYNAMIC, */
 };
 
 static u64 musb_dmamask = DMA_BIT_MASK(32);

@@ -146,7 +141,7 @@ static struct platform_device musb_device = {
.resource   = musb_resources,
 };
 
-void __init usb_musb_init(void)

+void __init usb_musb_init(unsigned power)
 {
if (cpu_is_omap243x())
musb_resources[0].start = OMAP243X_HS_BASE;
@@ -159,6 +154,7 @@ void __init usb_musb_init(void)
 * musb_core.c have been converted to use use clkdev.
 */
musb_plat.clock = "ick";
+   musb_plat.power = power >> 1;
  


  Probably OMAP boards never supply much current, but otherwise capping 
the value of 'power' at 510 seems a good idea.


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe 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.6.34 7/9] usb: musb: use only clk framework for clk handling

[Sergei Shtylyov]

Hello.

Felipe Balbi wrote:


get rid of the set_clock hackery.

Cc: linux-...@vger.kernel.org
Signed-off-by: Felipe Balbi 
---

Greg, I'll send this patch to you shortly, it's
only here so that Tony can have it in linux-omap-2.6
to avoid breaking any of his boards.
  


  Er, I'm afraid I have to NAK this patch...


diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 5eb9318..37ca87d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -977,10 +977,8 @@ static void musb_shutdown(struct platform_device *pdev)
spin_lock_irqsave(&musb->lock, flags);
musb_platform_disable(musb);
musb_generic_disable(musb);
-   if (musb->clock) {
-   clk_put(musb->clock);
-   musb->clock = NULL;
-   }
+   clk_put(musb->clock);
+   musb->clock = NULL;
spin_unlock_irqrestore(&musb->lock, flags);
 
 	/* FIXME power down */

@@ -1864,10 +1862,8 @@ static void musb_free(struct musb *musb)
musb_platform_exit(musb);
musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
 
-	if (musb->clock) {

-   clk_disable(musb->clock);
-   clk_put(musb->clock);
-   }
+   clk_disable(musb->clock);
+   clk_put(musb->clock);
 
 #ifdef CONFIG_USB_MUSB_HDRC_HCD

usb_put_hcd(musb_to_hcd(musb));
@@ -1930,7 +1926,6 @@ bad_config:
spin_lock_init(&musb->lock);
musb->board_mode = plat->mode;
musb->board_set_power = plat->set_power;
-   musb->set_clock = plat->set_clock;
musb->min_power = plat->min_power;
 
 	/* Clock usage is chip-specific ... functional clock (DaVinci,

@@ -1938,15 +1933,17 @@ bad_config:
 * code does is make sure a clock handle is available; platform
 * code manages it during start/stop and suspend/resume.
 */
-   if (plat->clock) {
-   musb->clock = clk_get(dev, plat->clock);
-   if (IS_ERR(musb->clock)) {
-   status = PTR_ERR(musb->clock);
-   musb->clock = NULL;
-   goto fail;
-   }
+   musb->clock = clk_get(dev, "ick");
  


  Why always "ick"?! Do you think OMAPs are the only boards using MUSB 
out there?


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe 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.6.34 8/9] arm: omap: musb: do not pass clock name to driver

[Sergei Shtylyov]

Hello.

Felipe Balbi wrote:


we are using clkdev and the driver can use whatever
name it wants.
  


  It's not so actually. This depends on the matching mechanism 
established within clkdev: by device, by name, or by both. Not all 
implementations will match by device, e.g. DA8xx/OMAP-L1x will match by 
clock name.


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ARM : OMAP4 : MUSB : Add USB support to 4430 SDP board file

[Sergei Shtylyov]

Hello.

Maulik Mankad wrote:


ARM : OMAP4 : Add USB support to 4430 SDP board file

This patch adds support for Mentor USB to 4430 SDP board file.

It also defines the base address for HS USB OTG controller in OMAP4.

Also updates platform specfic structure with base address and IRQ details.

Signed-off-by: Maulik Mankad 
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Cc: Greg Kroah-Hartman 

Index: felipe_musb/arch/arm/mach-omap2/board-4430sdp.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ felipe_musb/arch/arm/mach-omap2/board-4430sdp.c
  

[...]

@@ -73,11 +75,22 @@ static void __init omap_4430sdp_init_irq
omap_gpio_init();
 }
 
+static struct musb_omap_data omap4430sdp_data = {

+.interface_type= MUSB_INTERFACE_UTMI,
+.mode  = MUSB_PERIPHERAL,
+.power = 100,
  


   You have lost the indentation here.


Index: felipe_musb/arch/arm/mach-omap2/usb-musb.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/usb-musb.c
+++ felipe_musb/arch/arm/mach-omap2/usb-musb.c
@@ -81,8 +81,13 @@ void __init usb_musb_init(void *arch_dat
 
 	if (cpu_is_omap243x())

musb_resources[0].start = OMAP243X_HS_BASE;
-   else
+   else if (cpu_is_omap34xx())
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
+   else if (cpu_is_omap44xx()) {
+   musb_resources[0].start = OMAP44XX_HSUSB_OTG_BASE;
+   musb_resources[1].start =  INT_44XX_HS_USB_MC;
+   musb_resources[2].start =  INT_44XX_HS_USB_DMA;
  


  Why extra speces here?

WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

regression: crash from 'ls /sys/modules/wl1251_spi/notes'

[Kalle Valo]

Hello,

I noticed weird crashes related to wl1251_spi notes sysfs directory
with current wireless-testing (2.6.33-rc2 plus some wireless patches).
The simplest way to reproduce the problem is to do this on a nokia n900
(arm/omap 3430):

# ls /sys/module/wl1251_spi/notes/
[ 4776.503234] Unable to handle kernel NULL pointer dereference at
virtual address 
[ 4776.511596] pgd = cce88000
[ 4776.514343] [] *pgd=8f04a031, *pte=, *ppte=
[ 4776.520812] Internal error: Oops: 17 [#1]
[ 4776.524871] last sysfs file: /sys/class/net/wlan0/flags
[ 4776.530151] Modules linked in: wl1251_spi wl1251 mac80211 cfg80211
[ 4776.536468] CPU: 0Not tainted  (2.6.33-rc2-wl-47091-g981eb84
#12)
[ 4776.542999] PC is at strlen+0xc/0x20
[ 4776.546630] LR is at sysfs_readdir+0x15c/0x1e0
[ 4776.551116] pc : []lr : []psr: a013
[ 4776.551147] sp : cce87f28  ip :   fp : be99961c
[ 4776.562744] r10: cce87f80  r9 :   r8 : 
[ 4776.568023] r7 : c00b9540  r6 : cce87f80  r5 : ccec4458  r4 :
ce808980
[ 4776.574615] r3 :   r2 : 0002  r1 :   r0 :

[ 4776.581207] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment user
[ 4776.588409] Control: 10c5387d  Table: 8ce88019  DAC: 0015
[ 4776.594238] Process ls (pid: 1148, stack limit = 0xcce862e8)
[ 4776.599945] Stack: (0xcce87f28 to 0xcce88000)
[ 4776.604370] 7f20:   0001  0e16
 0004 
[ 4776.612640] 7f40: ce808980 ce808980 cf79e34c c00b9540 
cf79e2b8 cce86000 c00b982c
[ 4776.620910] 7f60: 0001  1000 000690d0 ce808980
c002bae4  c00b98c4
[ 4776.629180] 7f80: 00069100 000690e8 0fd0 ffea 
  
[ 4776.637451] 7fa0: 00d9 c002b940   0003
000690d0 1000 
[ 4776.645721] 7fc0:    00d9 000690c8
0001  be99961c
[ 4776.654022] 7fe0: 400ef954 be999614 400efa10 400ef908 6010
0003 80c69021 80c69421
[ 4776.662292] [] (strlen+0xc/0x20) from []
(sysfs_readdir+0x15c/0x1e0)
[ 4776.670501] [] (sysfs_readdir+0x15c/0x1e0) from
[] (vfs_readdir+0x80/0xb4)
[ 4776.679229] [] (vfs_readdir+0x80/0xb4) from []
(sys_getdents64+0x64/0xb4)
[ 4776.687866] [] (sys_getdents64+0x64/0xb4) from
[] (ret_fast_syscall+0x0/0x38)
[ 4776.696838] Code: c027700c e1a03000 ea00 e2833001 (e5d32000) 
[ 4776.703063] ---[ end trace 6a3b0fdf4e9def99 ]---
[ 4776.707794] Kernel panic - not syncing: Fatal exception

Also removing wl1251_spi causes a crash. The reason for this is that a
sysfs file with a null string as name is trying to be removed from the
notes directory.

I found out that reverting this patch solves the problem:

  commit 35dead4235e2b67da7275b4122fed37099c2f462
  Author: Helge Deller 
  Date:   Thu Dec 3 00:29:15 2009 +0100

modules: don't export section names of empty sections via sysfs

On the parisc architecture we face for each and every loaded
kernel module this kernel "badness warning":

  sysfs: cannot create duplicate filename
'/module/ac97_bus/sections/.text'
  Badness at fs/sysfs/dir.c:487

Reason for that is, that on parisc all kernel modules do have
multiple .text sections due to the usage of the
-ffunction-sections compiler flag which is needed to reach all
jump targets on this platform.

An objdump on such a kernel module gives:
Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .note.gnu.build-id 0024      0034
2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text       0058  2**0
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .text.ac97_bus_match 001c      0058
2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .text       00d4  2**0
  CONTENTS, ALLOC, LOAD, READONLY, CODE
...
Since the .text sections are empty (size of 0 bytes) and won't be
loaded by the kernel module loader anyway, I don't see a reason
why such sections need to be listed under
/sys/module//sections/ either.

The attached patch does solve this issue by not exporting section
names which are empty.

This fixes bugzilla
http://bugzilla.kernel.org/show_bug.cgi?id=14703

Signed-off-by: Helge Deller 
CC: ru...@rustcorp.com.au
CC: a...@linux-foundation.org
CC: james.bottom...@hansenpartnership.com
CC: rol...@redhat.com
CC: d...@hiauly1.hia.nrc.ca
Signed-off-by: Linus Torvalds 

I was also able to reproduce the problem with vanilla 2.6.32. I'm
pretty sure (but haven't tested) that 2.6.32-rc8 does not have this
problem.

My original mail containing more info:

http://www.spinics.net/lists/linux-wireless/msg44863.html

Simple bandaid patch below fixes the problem. I know it's not a p

Re: [patch-v2.6.34 7/9] usb: musb: use only clk framework for clk handling

[Felipe Balbi]

Hi,

On Wed, 2009-12-30 at 14:18 +0300, Sergei Shtylyov wrote:
>Why always "ick"?! Do you think OMAPs are the only boards using MUSB 
> out there?

err, I'm afraid you have to read more about clock framework. The clock
name should not matter when you issue clk_get(). I used the shortest
name that came to my mind. could've been "usb", "usb_clock",
"musb_otg_default_clock". It doesn't matter.


-- 
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-v2.6.34 8/9] arm: omap: musb: do not pass clock name to driver

[Felipe Balbi]

Hi,

On Wed, 2009-12-30 at 14:23 +0300, Sergei Shtylyov wrote:
>It's not so actually. This depends on the matching mechanism 
> established within clkdev: by device, by name, or by both. Not all 
> implementations will match by device, e.g. DA8xx/OMAP-L1x will match by 
> clock name.

then it has to be fixed. The name shouldn't matter. This was a big
discussion when Russell came up with the clkdev stuff and I remember
clearly that clock names shouldn't be passed down to drivers because
they don't matter.

-- 
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: L4 interconnect memory mapping

[Felipe Balbi]

Hi,

On Wed, 2009-12-30 at 02:16 -0700, Paul Walmsley wrote:
> That second 4KiB range is the interconnect target agent between the 
> interconnect and the HS USB OTG IP block.  No need to deal with it.  At 
> some point either omap_hwmod or an interconnect driver will probably 
> reserve it for bookkeeping purposes.

Ok, got it. Thanks for the info.

-- 
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] OMAP2: add USB platform data and initialization for Nokia N800 and N810

[Felipe Balbi]

Hi,

On Wed, 2009-12-30 at 03:02 -0600, Luke-Jr wrote:
> On Wednesday 30 December 2009 01:17:11 am Kalle Valo wrote:
> > "Luke-Jr"  writes:
> > > On that topic, is there a reason the newer code is under a unified "N8x0"
> > > config option instead of the split N800/N810 that was used for the old
> > > code, or is that simply a symptom of the currently-supported features all
> > > being common?
> > 
> > IIRC, I just used one common n8x0 file because the n810 board file was
> > very small and I didn't see any benefit from having it separately.
> 
> Yeah, that's because someone put all the N810 code in the N800 file ;)
> 
> Will probably at least split out the differences, if there's no other reason, 
> then. Since I'm doing this stuff only for my own personal interest, I'll 
> probably not bother to do much with N800 support unless someone feels like 
> sending me one when I finish N810 (definitely not touching N800 before then).

I think it's not worth the effort. Those boards share a lot of code.
You'll end up with several small board files

-- 
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 7/8] arm: omap: musb: pass board mode to usb_musb_init

[Felipe Balbi]

On Wed, 2009-12-30 at 10:14 +0530, Gupta, Ajay Kumar wrote:
> Hi,
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Felipe Balbi
> > Sent: Monday, December 28, 2009 4:40 PM
> > To: Tony Lindgren
> > Cc: Linux OMAP Mailing List; Felipe Balbi
> > Subject: [PATCH 7/8] arm: omap: musb: pass board mode to usb_musb_init
> > 
> > each board will have a different mode which is peculiar
> > to that board.
> > 
> > Signed-off-by: Felipe Balbi 
> > ---
> 
> 
> > 
> >  #include 
> >  #include 
> > @@ -203,7 +204,7 @@ static void __init omap_2430sdp_init(void)
> > platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
> > omap_serial_init();
> > twl4030_mmc_init(mmc);
> > -   usb_musb_init(100);
> > +   usb_musb_init(MUSB_OTG, 100);
> 
> Similarly, we would need another parameter 'extvbus' which is required by
> OMAP3EVM Rev >= E. This way the parameter list would keep increasing and
> would look ugly.
> 
> So how about passing a "struct musb_board_data" structure completely ? It
> Can be generic across the musb platforms or we can have it only for OMAP
> platforms.


I suggested that off list already. We will add some void * to
musb_platform_data which would allow archs to pass whatever data
structure they want down to drivers/usb/musb/.c

-- 
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 1/1] ARM: OMAP4: PM: Add check for avoiding dependency related update.

[Pagare, Abhijit]

Hi Paul,


> -Original Message-
> From: Paul Walmsley [mailto:p...@pwsan.com]
> Sent: Wednesday, December 30, 2009 2:02 PM
> To: Pagare, Abhijit
> Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/1] ARM: OMAP4: PM: Add check for avoiding dependency
> related update.
> 
> Hello Abhijit,
> 
> On Wed, 23 Dec 2009, Abhijit Pagare wrote:
> 
> > A check is added for avoiding the sleep/wakeup dependency updates
> > for OMAP4 as the structures for the dependencies are currently absent.
> 
> As a threshold matter, code and data added in temporary hack patches like
> this need to be marked with XXX or FIXME or something similar to indicate
> that these are not intended features, but rather, temporary lines that
> need to be removed in the near term.

I think I missed that. I will add the FIXME indication to the check below. I 
think that this check is essential for OMAP4 kernel boot-up as long as the 
dependency patches are not pushed in.

> 
> But really, I'd rather not apply this patch.  The best way forward is to
> apply a patch that adds the OMAP4 wakeup and sleep dependencies
> themselves.  Have you had a chance to look at the series that I sent you a
> few weeks ago off-list that reorganizes the wakeup and sleep dependencies
> to determine if it is adequate for you to add the OMAP4 wakeup/sleep
> dependencies afterwards?

I had a look at the dependency patches that you had sent to me earlier and it 
seems feasible to add the OMAP4 related dependency data on top of those 
patches. A small change exists but can be taken care of.

Regards,
Abhijit

> 
> 
> - Paul
> 
> >
> > Signed-off-by: Abhijit Pagare 
> > Cc: Paul Walmsley 
> > ---
> >
> > Compiled and Boot Tested on OMAP4430 simulator, ES1 Chip & OMAP3430 SDP.
> > And also Compiled for OMAP2430 and OMAP2420
> >
> > This patch has a dependency on the earlier set of OMAP4 clock-domain
> patches.
> >
> >  arch/arm/mach-omap2/clockdomain.c |   10 ++
> >  1 files changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-
> omap2/clockdomain.c
> > index 8c9e78c..6ec25ee 100644
> > --- a/arch/arm/mach-omap2/clockdomain.c
> > +++ b/arch/arm/mach-omap2/clockdomain.c
> > @@ -507,8 +507,9 @@ void omap2_clkdm_allow_idle(struct clockdomain
> *clkdm)
> > pr_debug("clockdomain: enabling automatic idle transitions for
> %s\n",
> >  clkdm->name);
> >
> > -   if (atomic_read(&clkdm->usecount) > 0)
> > -   _clkdm_add_autodeps(clkdm);
> > +   if (!cpu_is_omap44xx())
> > +   if (atomic_read(&clkdm->usecount) > 0)
> > +   _clkdm_add_autodeps(clkdm);
> >
> > _omap2_clkdm_set_hwsup(clkdm, 1);
> >
> > @@ -540,8 +541,9 @@ void omap2_clkdm_deny_idle(struct clockdomain
> *clkdm)
> >
> > _omap2_clkdm_set_hwsup(clkdm, 0);
> >
> > -   if (atomic_read(&clkdm->usecount) > 0)
> > -   _clkdm_del_autodeps(clkdm);
> > +   if (!cpu_is_omap44xx())
> > +   if (atomic_read(&clkdm->usecount) > 0)
> > +   _clkdm_del_autodeps(clkdm);
> >  }
> >
> >
> > --
> > 1.5.4.7
> >
> 
> 
> - 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 1/2] ARM : OMAP: MUSB : Pass board specific data using a structure

[Felipe Balbi]

Hi,

On Wed, 2009-12-30 at 16:29 +0530, Gupta, Ajay Kumar wrote:
> Hi,
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Mankad, Maulik Ojas
> > Sent: Wednesday, December 30, 2009 4:15 PM
> > To: linux-omap@vger.kernel.org
> > Cc: linux-...@vger.kernel.org; Mankad, Maulik Ojas; Felipe Balbi; Tony
> > Lindgren; Greg Kroah-Hartman
> > Subject: [PATCH 1/2] ARM : OMAP: MUSB : Pass board specific data using a
> > structure
> > 
> > ARM : OMAP: MUSB :Pass board specific data from board file
> > 
> > This patch proposes to pass board specific data for MUSB
> > (like interface_type, mode etc) from board file by defining
> > board specific structure.
> > 
> > Each board file can define this structure based on
> > its requirement and pass this information to the
> > driver.
> > 
> > It addresses a comment from Felipe and thus help
> > by preventing addition of too many fields in
> > musb_platform_data.
> > 
> > Signed-off-by: Maulik Mankad 
> > Cc: Felipe Balbi 
> > Cc: Tony Lindgren 
> > Cc: Greg Kroah-Hartman 
> > 
> > Index: felipe_musb/arch/arm/mach-omap2/board-2430sdp.c
> > ===
> > --- felipe_musb.orig/arch/arm/mach-omap2/board-2430sdp.c
> > +++ felipe_musb/arch/arm/mach-omap2/board-2430sdp.c
> > @@ -195,6 +195,12 @@ static struct twl4030_hsmmc_info mmc[] _
> > {}  /* Terminator */
> >  };
> > 
> > +static struct musb_omap_data omap2430sdp_data = {
> > +.interface_type= MUSB_INTERFACE_ULPI,
> > +.mode  = MUSB_OTG,
> > +.power = 100,
> > +}
> > +

fix the indentation.

> > -extern void usb_musb_init(enum musb_mode mode, unsigned power);
> > +struct musb_omap_data {
> > +u8 interface_type;
> > +u8 mode;
> > +u8 power;
> > +};
> 
> It's board data so how about 'struct omap_musb_board_data'.

good point.

> > +
> > +enum musb_interface{MUSB_INTERFACE_ULPI, MUSB_INTERFACE_UTMI};
> > +
> > +extern void usb_musb_init(void *);
> 
> Can be modified to:
> +extern void usb_musb_init(omap_musb_board_data *);

correct

> > if (cpu_is_omap243x())
> > musb_resources[0].start = OMAP243X_HS_BASE;
> > else
> > @@ -88,15 +90,16 @@ void __init usb_musb_init(enum musb_mode
> >  * musb_core.c have been converted to use use clkdev.
> >  */
> > musb_plat.clock = "ick";
> > -   musb_plat.power = power >> 1;
> > -   musb_plat.mode = mode;
> > +   musb_plat.arch_data = arch_data;
> 
> 
> Not needed.

why not ? we still want to pass interface_type down to omap2430.c,
right ?

> We don't need it as we will continue using 'power', 'mode', 'extvbus'
> From musb_plat only.

power and mode, yeah. extvbus is omap-only isn't it ? Then on omap2430.c
is interested in that ?!?

-- 
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 1/2] ARM : OMAP: MUSB : Pass board specific data using a structure

[Maulik]

>>Isn't it simpler to use same name across the boards like,
>>'musb_board_data'
>>Instead of 'omap3430sdp_data'.

[Maulik] Will change in the next version. 

> 
> -extern void usb_musb_init(enum musb_mode mode, unsigned power);
> +struct musb_omap_data {
> +u8   interface_type;
> +u8   mode;
> +u8   power;
> +};

>>It's board data so how about 'struct omap_musb_board_data'.

[Maulik] Will change in the next version.

> +
> +enum musb_interface  {MUSB_INTERFACE_ULPI, MUSB_INTERFACE_UTMI};
> +
> +extern void usb_musb_init(void *);

Can be modified to:
+extern void usb_musb_init(omap_musb_board_data *);

[Maulik] Will change in the next version.


> +void __init usb_musb_init(void *arch_data)

>>It's actually board data so *board_data is clearer.

[Maulik] Can be done. Will change in the next version.


> + musb_plat.arch_data = arch_data;

>>Not needed.

[Maulik] The patch adds a field interface_type for selecting between UTMI
and ULPI PHY. This is done for OMAP4 which uses internal UTMI phy.

Moreover in future if we need to add any board specific data it can be part
of this structure.

> --- felipe_musb.orig/include/linux/usb/musb.h
> +++ felipe_musb/include/linux/usb/musb.h
> @@ -84,6 +84,9 @@ struct musb_hdrc_platform_data {
> 
>   /* MUSB configuration-specific details */
>   struct musb_hdrc_config *config;
> +
> + /* Board specific data  */
> + void*arch_data;

>>We don't need it as we will continue using 'power', 'mode', 'extvbus'
>>From musb_plat only.

[Maulik] The patch adds a field interface_type for selecting between UTMI
and ULPI PHY. This is done for OMAP4 which uses internal UTMI phy.

Moreover in future if we need to add any board specific data it can be part
of this structure.


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] arm: omap2: clk2xxx.c doesn't compile if CPUFREQ is enabled

[Felipe Balbi]

From: Felipe Balbi 

if we enable CPUFREQ we can't build omap2 for two reasons,
one of them is fixed by the patch below but the other one
it seems like it'll need more invasive changes to the code
so I'll leave it for you to decide how to do it.

It's failing because the __must_be_array() check in
ARRAY_SIZE() is failing and printing the following message:

arch/arm/mach-omap2/clock2xxx.c:453: error: negative width in bit-field 
''

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/clock2xxx.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
index d0e3fb7..4e2bdfe 100644
--- a/arch/arm/mach-omap2/clock2xxx.c
+++ b/arch/arm/mach-omap2/clock2xxx.c
@@ -455,12 +455,15 @@ static struct cpufreq_frequency_table 
freq_table[ARRAY_SIZE(rate_table)];
 void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
 {
struct prcm_config *prcm;
+   long rate;
int i = 0;
 
+   rate = clk_get_rate(sclk);
+
for (prcm = rate_table; prcm->mpu_speed; prcm++) {
if (!(prcm->flags & cpu_mask))
continue;
-   if (prcm->xtal_speed != sys_ck.rate)
+   if (prcm->xtal_speed != rate)
continue;
 
/* don't put bypass rates in table */
-- 
1.6.6.35.g1d85d

--
To unsubscribe from this list: send the line "unsubscribe 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.6.34 7/9] usb: musb: use only clk framework for clk handling

[Sergei Shtylyov]

Hello.

Felipe Balbi wrote:

   Why always "ick"?! Do you think OMAPs are the only boards using MUSB 
out there?



err, I'm afraid you have to read more about clock framework. The clock
name should not matter when you issue clk_get().


  It depends on the matching type determined from a clkdev matching 
table -- see dm644x_clks[] in arch/mach-davinci/dm644x.c as an example: 
'struct davinci_clk' incorporates 'struct clk_lookup', and where its 1st 
member is initialized, the matching is done by device, where its second 
member is initialized, the matching is done by clock name -- see 
clk_find() in arch/arm/common/clkdev.c for the logic.



I used the shortest
name that came to my mind. could've been "usb", "usb_clock",
"musb_otg_default_clock". It doesn't matter.


  I know for sure that it still *can* matter with clkdev, and I do use 
matching by clock name with DA8xx/OMAP-L1x glue layer. So I' strongly 
against this patch.


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe 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.6.34 8/9] arm: omap: musb: do not pass clock name to driver

[Sergei Shtylyov]

Hello.

Felipe Balbi wrote:

   It's not so actually. This depends on the matching mechanism 
established within clkdev: by device, by name, or by both. Not all 
implementations will match by device, e.g. DA8xx/OMAP-L1x will match by 
clock name.



then it has to be fixed. The name shouldn't matter.


  It's not always feasible to do as you say. The same clock can be used 
by more than two drivers, or the clock may be used out of driver context 
altogether.



This was a big
discussion when Russell came up with the clkdev stuff and I remember
clearly that clock names shouldn't be passed down to drivers because
they don't matter.


  Why then there are two matching mechanisms in the clkdev code?

WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe 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.6.34 7/9] usb: musb: use only clk framework for clk handling

[Felipe Balbi]

Hi,

On Wed, 2009-12-30 at 16:06 +0300, Sergei Shtylyov wrote:
> Hello.
> 
> Felipe Balbi wrote:
> 
> >>Why always "ick"?! Do you think OMAPs are the only boards using MUSB 
> >> out there?
> >> 
> >
> > err, I'm afraid you have to read more about clock framework. The clock
> > name should not matter when you issue clk_get().
> 
>It depends on the matching type determined from a clkdev matching 
> table -- see dm644x_clks[] in arch/mach-davinci/dm644x.c as an example: 
> 'struct davinci_clk' incorporates 'struct clk_lookup', and where its 1st 
> member is initialized, the matching is done by device, where its second 
> member is initialized, the matching is done by clock name -- see 
> clk_find() in arch/arm/common/clkdev.c for the logic.

diff --git a/arch/arm/mach-davinci/dm644x.c
b/arch/arm/mach-davinci/dm644x.c
index 2cd0081..a0ad7b6 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -306,7 +306,7 @@ struct davinci_clk dm644x_clks[] = {
CLK("davinci_mmc.0", NULL, &mmcsd_clk),
CLK(NULL, "spi", &spi_clk),
CLK(NULL, "gpio", &gpio_clk),
-   CLK(NULL, "usb", &usb_clk),
+   CLK("musb_hdrc", "usb", &usb_clk),
CLK(NULL, "vlynq", &vlynq_clk),
CLK(NULL, "aemif", &aemif_clk),
CLK(NULL, "pwm0", &pwm0_clk),


there you are...

-- 
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-v2.6.34 7/9] usb: musb: use only clk framework for clk handling

[Felipe Balbi]

Hi,

adding Russell to Cc list as he might have comments.

On Wed, 2009-12-30 at 15:14 +0200, Felipe Balbi wrote:
> Hi,
> 
> On Wed, 2009-12-30 at 16:06 +0300, Sergei Shtylyov wrote:
> > Hello.
> > 
> > Felipe Balbi wrote:
> > 
> > >>Why always "ick"?! Do you think OMAPs are the only boards using MUSB 
> > >> out there?
> > >> 
> > >
> > > err, I'm afraid you have to read more about clock framework. The clock
> > > name should not matter when you issue clk_get().
> > 
> >It depends on the matching type determined from a clkdev matching 
> > table -- see dm644x_clks[] in arch/mach-davinci/dm644x.c as an example: 
> > 'struct davinci_clk' incorporates 'struct clk_lookup', and where its 1st 
> > member is initialized, the matching is done by device, where its second 
> > member is initialized, the matching is done by clock name -- see 
> > clk_find() in arch/arm/common/clkdev.c for the logic.
> 
> diff --git a/arch/arm/mach-davinci/dm644x.c
> b/arch/arm/mach-davinci/dm644x.c
> index 2cd0081..a0ad7b6 100644
> --- a/arch/arm/mach-davinci/dm644x.c
> +++ b/arch/arm/mach-davinci/dm644x.c
> @@ -306,7 +306,7 @@ struct davinci_clk dm644x_clks[] = {
> CLK("davinci_mmc.0", NULL, &mmcsd_clk),
> CLK(NULL, "spi", &spi_clk),
> CLK(NULL, "gpio", &gpio_clk),
> -   CLK(NULL, "usb", &usb_clk),
> +   CLK("musb_hdrc", "usb", &usb_clk),
> CLK(NULL, "vlynq", &vlynq_clk),
> CLK(NULL, "aemif", &aemif_clk),
> CLK(NULL, "pwm0", &pwm0_clk),
> 
> 
> there you are...

and the point is that we want to stop passing clock names down to the
driver so either we agree on using a generic name like "ick" or "usb",
or the clockdev implementation for that particular clock will match
device id. We sure need to think about clocks used by several devices,
we want to keep device id NULL, for sure.

Russell, how should we tackle this ?

-- 
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-v2.6.34 7/9] usb: musb: use only clk framework for clk handling

[Sergei Shtylyov]

Hello.

Felipe Balbi wrote:

   Why always "ick"?! Do you think OMAPs are the only boards using MUSB 
out there?



err, I'm afraid you have to read more about clock framework. The clock
name should not matter when you issue clk_get().
  
   It depends on the matching type determined from a clkdev matching 
table -- see dm644x_clks[] in arch/mach-davinci/dm644x.c as an example: 
'struct davinci_clk' incorporates 'struct clk_lookup', and where its 1st 
member is initialized, the matching is done by device, where its second 
member is initialized, the matching is done by clock name -- see 
clk_find() in arch/arm/common/clkdev.c for the logic.



diff --git a/arch/arm/mach-davinci/dm644x.c
b/arch/arm/mach-davinci/dm644x.c
index 2cd0081..a0ad7b6 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -306,7 +306,7 @@ struct davinci_clk dm644x_clks[] = {
CLK("davinci_mmc.0", NULL, &mmcsd_clk),
CLK(NULL, "spi", &spi_clk),
CLK(NULL, "gpio", &gpio_clk),
-   CLK(NULL, "usb", &usb_clk),
+   CLK("musb_hdrc", "usb", &usb_clk),
CLK(NULL, "vlynq", &vlynq_clk),
CLK(NULL, "aemif", &aemif_clk),
CLK(NULL, "pwm0", &pwm0_clk),


there you are...


  Gotcha. This will match in clk_find() by both device and clock name, 
so clk_get() will fail with your patch.


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe 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.6.34 7/9] usb: musb: use only clk framework for clk handling

[Felipe Balbi]

On Wed, 2009-12-30 at 16:25 +0300, Sergei Shtylyov wrote:
>Gotcha. This will match in clk_find() by both device and clock name, 
> so clk_get() will fail with your patch.

then, when it doesn't find, it'll try device id only:

/*
 * Find the correct struct clk for the device and connection ID.
 * We do slightly fuzzy matching here:
 *  An entry with a NULL ID is assumed to be a wildcard.
 *  If an entry has a device ID, it must match
 *  If an entry has a connection ID, it must match
 * Then we take the most specific entry - with the following
 * order of precidence: dev+con > dev only > con only.
 */

and then we have found our clock :-)

-- 
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-v2.6.34 7/9] usb: musb: use only clk framework for clk handling

[Sergei Shtylyov]

Hello.

Felipe Balbi wrote:

   Gotcha. This will match in clk_find() by both device and clock name, 
so clk_get() will fail with your patch.



then, when it doesn't find, it'll try device id only:

/*
 * Find the correct struct clk for the device and connection ID.
 * We do slightly fuzzy matching here:
 *  An entry with a NULL ID is assumed to be a wildcard.
 *  If an entry has a device ID, it must match
 *  If an entry has a connection ID, it must match
 * Then we take the most specific entry - with the following
 * order of precidence: dev+con > dev only > con only.
 */

and then we have found our clock :-)


  Hm, you're right, I haven't completely followed the logic there... in 
any case, specifying con_id wasn't really needed.


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe 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.6.34 7/9] usb: musb: use only clk framework for clk handling

[Felipe Balbi]

Hi,

On Wed, 2009-12-30 at 16:43 +0300, Sergei Shtylyov wrote:
> > /*
> >  * Find the correct struct clk for the device and connection ID.
> >  * We do slightly fuzzy matching here:
> >  *  An entry with a NULL ID is assumed to be a wildcard.
> >  *  If an entry has a device ID, it must match
> >  *  If an entry has a connection ID, it must match
> >  * Then we take the most specific entry - with the following
> >  * order of precidence: dev+con > dev only > con only.
> >  */
> >
> > and then we have found our clock :-)
> 
>Hm, you're right, I haven't completely followed the logic there... in 
> any case, specifying con_id wasn't really needed.

good we've sorted things out. Want me to send a patch for the device id
to davinci tree or can you take care of that ?

I have a for-kevin branch with a few patches I'll send to davinci tree
so I could add the device id patch there.

-- 
balbi

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] ARM : OMAP patches

[Maulik Mankad]

Hi,

Felipe,

Here is the Version 2 of the 2 patch series based on top of 
your for-tony branch at [1].

[1] git://gitorious.org/usb/usb.git for-tony

Maulik Mankad (2):
ARM : OMAP: MUSB : Pass board specific data using a structure.
ARM : OMAP4 : MUSB : Add USB support to 4430 SDP board file

The patches are compile tested and do not report
any checkpatch warnings.

The patch set addresses comments received for Version 1.

Thanks,
Maulik

--
To unsubscribe from this list: send the line "unsubscribe 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 1/2] ARM : OMAP: MUSB : Pass board specific data using a structure

[Maulik Mankad]

ARM : OMAP: MUSB :Pass board specific data from board file

This patch proposes to pass board specific data for MUSB
(like interface_type, mode etc) from board file by defining
board specific structure.

Each board file can define this structure based on 
its requirement and pass this information to the 
driver.

Signed-off-by: Maulik Mankad 
Cc: Tony Lindgren 
Cc: Felipe Balbi 
Cc: David Brownell 
Cc: Greg Kroah-Hartman 
Cc: Gupta Ajay Kumar 
Index: felipe_musb/arch/arm/mach-omap2/board-2430sdp.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-2430sdp.c
+++ felipe_musb/arch/arm/mach-omap2/board-2430sdp.c
@@ -195,6 +195,12 @@ static struct twl4030_hsmmc_info mmc[] _
{}  /* Terminator */
 };
 
+static struct omap_musb_board_data musb_board_data = {
+   .interface_type = MUSB_INTERFACE_ULPI,
+   .mode   = MUSB_OTG,
+   .power  = 100,
+}
+
 static void __init omap_2430sdp_init(void)
 {
int ret;
@@ -204,7 +210,7 @@ static void __init omap_2430sdp_init(voi
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
omap_serial_init();
twl4030_mmc_init(mmc);
-   usb_musb_init(MUSB_OTG, 100);
+   usb_musb_init(&musb_board_data);
board_smc91x_init();
 
/* Turn off secondary LCD backlight */
Index: felipe_musb/arch/arm/mach-omap2/board-3430sdp.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-3430sdp.c
+++ felipe_musb/arch/arm/mach-omap2/board-3430sdp.c
@@ -651,6 +651,12 @@ static struct omap_board_mux board_mux[]
 #define board_mux  NULL
 #endif
 
+static struct omap_musb_board_data musb_board_data = {
+   .interface_type = MUSB_INTERFACE_ULPI,
+   .mode   = MUSB_OTG,
+   .power  = 100,
+};
+
 static void __init omap_3430sdp_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -665,7 +671,7 @@ static void __init omap_3430sdp_init(voi
ARRAY_SIZE(sdp3430_spi_board_info));
ads7846_dev_init();
omap_serial_init();
-   usb_musb_init(MUSB_OTG, 100);
+   usb_musb_init(&musb_board_data);
board_smc91x_init();
sdp3430_display_init();
enable_board_wakeup_source();
Index: felipe_musb/arch/arm/mach-omap2/board-cm-t35.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-cm-t35.c
+++ felipe_musb/arch/arm/mach-omap2/board-cm-t35.c
@@ -576,6 +576,12 @@ static struct omap_board_mux board_mux[]
{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 
+static struct omap_musb_board_data musb_board_data = {
+   .interface_type = MUSB_INTERFACE_ULPI,
+   .mode   = MUSB_OTG,
+   .power  = 100,
+};
+
 static void __init cm_t35_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CUS);
@@ -586,7 +592,7 @@ static void __init cm_t35_init(void)
cm_t35_init_ethernet();
cm_t35_init_led();
 
-   usb_musb_init(MUSB_OTG, 100);
+   usb_musb_init(&musb_board_data);
 }
 
 MACHINE_START(CM_T35, "Compulab CM-T35")
Index: felipe_musb/arch/arm/mach-omap2/board-igep0020.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-igep0020.c
+++ felipe_musb/arch/arm/mach-omap2/board-igep0020.c
@@ -212,12 +212,18 @@ static struct omap_board_mux board_mux[]
 #define board_mux  NULL
 #endif
 
+static struct omap_musb_board_data musb_board_data  = {
+   .interface_type = MUSB_INTERFACE_ULPI,
+   .mode   = MUSB_OTG,
+   .power  = 100,
+};
+
 static void __init igep2_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
igep2_i2c_init();
omap_serial_init();
-   usb_musb_init(MUSB_OTG, 100);
+   usb_musb_init(&musb_board_data);
 
igep2_init_smsc911x();
 
Index: felipe_musb/arch/arm/mach-omap2/board-ldp.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-ldp.c
+++ felipe_musb/arch/arm/mach-omap2/board-ldp.c
@@ -384,6 +384,12 @@ static struct omap_board_mux board_mux[]
 #define board_mux  NULL
 #endif
 
+static struct omap_musb_board_data musb_board_data = {
+   .interface_type = MUSB_INTERFACE_ULPI,
+   .mode   = MUSB_OTG,
+   .power  = 100,
+};
+
 static void __init omap_ldp_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -395,7 +401,7 @@ static void __init omap_ldp_init(void)
ARRAY_SIZE(ldp_spi_board_info));
ads7846_dev_init();
omap_serial_init();
-   usb_musb_init(MUSB_OTG, 100);
+   usb_musb_init(&musb_board_data);
 
twl4030_mmc_init(mmc);
/* link

[PATCH v2 2/2] ARM : OMAP4 : MUSB : Add USB support to 4430 SDP board file

[Maulik Mankad]

ARM : OMAP4 : Add USB support to 4430 SDP board file

This patch adds support for Mentor USB to 4430 SDP board file.

It also defines the base address for HS USB OTG controller in OMAP4.

Also updates platform specfic structure with base address and IRQ details.

Signed-off-by: Maulik Mankad 
Cc: Tony Lindgren 
Cc: Felipe Balbi 
Cc: David Brownell 
Cc: Greg Kroah-Hartman 
Cc: Sergei Shtylyov 
Index: felipe_musb/arch/arm/mach-omap2/board-4430sdp.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/board-4430sdp.c
+++ felipe_musb/arch/arm/mach-omap2/board-4430sdp.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -27,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct platform_device sdp4430_lcd_device = {
@@ -73,11 +75,21 @@ static void __init omap_4430sdp_init_irq
omap_gpio_init();
 }
 
+static struct omap_musb_board_data musb_board_data = {
+   .interface_type = MUSB_INTERFACE_UTMI,
+   .mode   = MUSB_PERIPHERAL,
+   .power  = 100,
+};
 
 static void __init omap_4430sdp_init(void)
 {
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
+#ifdef CONFIG_NOP_USB_XCEIV
+   /* OMAP4 SDP uses Internal transceiver so register nop transceiver */
+   usb_nop_xceiv_register();
+#endif
+   usb_musb_init(&musb_board_data);
 }
 
 static void __init omap_4430sdp_map_io(void)
Index: felipe_musb/arch/arm/mach-omap2/usb-musb.c
===
--- felipe_musb.orig/arch/arm/mach-omap2/usb-musb.c
+++ felipe_musb/arch/arm/mach-omap2/usb-musb.c
@@ -79,8 +79,13 @@ void __init usb_musb_init(struct omap_mu
 {
if (cpu_is_omap243x())
musb_resources[0].start = OMAP243X_HS_BASE;
-   else
+   else if (cpu_is_omap34xx())
musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
+   else if (cpu_is_omap44xx()) {
+   musb_resources[0].start = OMAP44XX_HSUSB_OTG_BASE;
+   musb_resources[1].start = INT_44XX_HS_USB_MC;
+   musb_resources[2].start = INT_44XX_HS_USB_DMA;
+   }
musb_resources[0].end = musb_resources[0].start + SZ_4K - 1;
 
/*
Index: felipe_musb/arch/arm/plat-omap/include/plat/omap44xx.h
===
--- felipe_musb.orig/arch/arm/plat-omap/include/plat/omap44xx.h
+++ felipe_musb/arch/arm/plat-omap/include/plat/omap44xx.h
@@ -43,6 +43,7 @@
 #define OMAP44XX_WKUPGEN_BASE  0x48281000
 
 #define OMAP44XX_MAILBOX_BASE  (L4_44XX_BASE + 0xF4000)
+#define OMAP44XX_HSUSB_OTG_BASE(L4_44XX_BASE + 0xAB000)
 
 #endif /* __ASM_ARCH_OMAP44XX_H */
 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] ARM : OMAP: MUSB : Pass board specific data using a structure

[Felipe Balbi]

Hi,

On Wed, 2009-12-30 at 19:54 +0530, Maulik Mankad wrote:
> Index: felipe_musb/include/linux/usb/musb.h
> ===
> --- felipe_musb.orig/include/linux/usb/musb.h
> +++ felipe_musb/include/linux/usb/musb.h
> @@ -84,6 +84,9 @@ struct musb_hdrc_platform_data {
>  
>   /* MUSB configuration-specific details */
>   struct musb_hdrc_config *config;
> +
> + /* Board specific data  */
> + struct omap_musb_board_data *board_data;

here it should be void *board_data;
so that other archs can pass whatever data structure they want.

-- 
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-v2.6.34 7/9] usb: musb: use only clk framework for clk handling

[Sergei Shtylyov]

Hello.

Felipe Balbi wrote:


/*
 * Find the correct struct clk for the device and connection ID.
 * We do slightly fuzzy matching here:
 *  An entry with a NULL ID is assumed to be a wildcard.
 *  If an entry has a device ID, it must match
 *  If an entry has a connection ID, it must match
 * Then we take the most specific entry - with the following
 * order of precidence: dev+con > dev only > con only.
 */

and then we have found our clock :-)
  
   Hm, you're right, I haven't completely followed the logic there... in 
any case, specifying con_id wasn't really needed.



good we've sorted things out. Want me to send a patch for the device id
to davinci tree or can you take care of that ?

I have a for-kevin branch with a few patches I'll send to davinci tree
so I could add the device id patch there.


  Go ahead, I'm actually ill now.

WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe 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: regression: crash from 'ls /sys/modules/wl1251_spi/notes'

[James Bottomley]

On Wed, 2009-12-30 at 13:41 +0200, Kalle Valo wrote:
> Hello,
> 
> I noticed weird crashes related to wl1251_spi notes sysfs directory
> with current wireless-testing (2.6.33-rc2 plus some wireless patches).
> The simplest way to reproduce the problem is to do this on a nokia n900
> (arm/omap 3430):
> 
> # ls /sys/module/wl1251_spi/notes/
> [ 4776.503234] Unable to handle kernel NULL pointer dereference at
> virtual address 
> [ 4776.511596] pgd = cce88000
> [ 4776.514343] [] *pgd=8f04a031, *pte=, *ppte=
> [ 4776.520812] Internal error: Oops: 17 [#1]
> [ 4776.524871] last sysfs file: /sys/class/net/wlan0/flags
> [ 4776.530151] Modules linked in: wl1251_spi wl1251 mac80211 cfg80211
> [ 4776.536468] CPU: 0Not tainted  (2.6.33-rc2-wl-47091-g981eb84
> #12)
> [ 4776.542999] PC is at strlen+0xc/0x20
> [ 4776.546630] LR is at sysfs_readdir+0x15c/0x1e0
> [ 4776.551116] pc : []lr : []psr: a013
> [ 4776.551147] sp : cce87f28  ip :   fp : be99961c
> [ 4776.562744] r10: cce87f80  r9 :   r8 : 
> [ 4776.568023] r7 : c00b9540  r6 : cce87f80  r5 : ccec4458  r4 :
> ce808980
> [ 4776.574615] r3 :   r2 : 0002  r1 :   r0 :
> 
> [ 4776.581207] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
> Segment user
> [ 4776.588409] Control: 10c5387d  Table: 8ce88019  DAC: 0015
> [ 4776.594238] Process ls (pid: 1148, stack limit = 0xcce862e8)
> [ 4776.599945] Stack: (0xcce87f28 to 0xcce88000)
> [ 4776.604370] 7f20:   0001  0e16
>  0004 
> [ 4776.612640] 7f40: ce808980 ce808980 cf79e34c c00b9540 
> cf79e2b8 cce86000 c00b982c
> [ 4776.620910] 7f60: 0001  1000 000690d0 ce808980
> c002bae4  c00b98c4
> [ 4776.629180] 7f80: 00069100 000690e8 0fd0 ffea 
>   
> [ 4776.637451] 7fa0: 00d9 c002b940   0003
> 000690d0 1000 
> [ 4776.645721] 7fc0:    00d9 000690c8
> 0001  be99961c
> [ 4776.654022] 7fe0: 400ef954 be999614 400efa10 400ef908 6010
> 0003 80c69021 80c69421
> [ 4776.662292] [] (strlen+0xc/0x20) from []
> (sysfs_readdir+0x15c/0x1e0)
> [ 4776.670501] [] (sysfs_readdir+0x15c/0x1e0) from
> [] (vfs_readdir+0x80/0xb4)
> [ 4776.679229] [] (vfs_readdir+0x80/0xb4) from []
> (sys_getdents64+0x64/0xb4)
> [ 4776.687866] [] (sys_getdents64+0x64/0xb4) from
> [] (ret_fast_syscall+0x0/0x38)
> [ 4776.696838] Code: c027700c e1a03000 ea00 e2833001 (e5d32000) 
> [ 4776.703063] ---[ end trace 6a3b0fdf4e9def99 ]---
> [ 4776.707794] Kernel panic - not syncing: Fatal exception

> Also removing wl1251_spi causes a crash. The reason for this is that a
> sysfs file with a null string as name is trying to be removed from the
> notes directory.

Yes, this is because the notes sections describe the text sections.
When we ignore an empty text section, we'd need to ignore its
corresponding notes section.

The reason we didn't see this on parisc is because our compiler doesn't
actually produce any notes sections.

> I found out that reverting this patch solves the problem:
> 
>   commit 35dead4235e2b67da7275b4122fed37099c2f462
>   Author: Helge Deller 
>   Date:   Thu Dec 3 00:29:15 2009 +0100
> 
> modules: don't export section names of empty sections via sysfs
> 
> On the parisc architecture we face for each and every loaded
> kernel module this kernel "badness warning":
> 
>   sysfs: cannot create duplicate filename
> '/module/ac97_bus/sections/.text'
>   Badness at fs/sysfs/dir.c:487
> 
> Reason for that is, that on parisc all kernel modules do have
> multiple .text sections due to the usage of the
> -ffunction-sections compiler flag which is needed to reach all
> jump targets on this platform.
> 
> An objdump on such a kernel module gives:
> Sections:
> Idx Name  Size  VMA   LMA   File off  Algn
>   0 .note.gnu.build-id 0024      0034
> 2**2
>   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   1 .text       0058  2**0
>   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   2 .text.ac97_bus_match 001c      0058
> 2**2
>   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   3 .text       00d4  2**0
>   CONTENTS, ALLOC, LOAD, READONLY, CODE
> ...
> Since the .text sections are empty (size of 0 bytes) and won't be
> loaded by the kernel module loader anyway, I don't see a reason
> why such sections need to be listed under
> /sys/module//sections/ either.
> 
> The attached patch does solve this issue by not exporting section
> names which are empty.
> 
> This fixes bugzilla
> http://bugzilla.kernel.org/show_bug.cgi?id=14703
> 
> Signed-o

[PATCH] ARM: OMAP4 clock domains : Add the missing Clock Domain Structure

[Abhijit Pagare]

One of the clock domains was missing from the auto-generated file.
It has been added here.

Signed-off-by: Abhijit Pagare 
Cc: Paul Walmsley 
---
Re-submitting with proper subject line.

Compiled and Boot Tested on OMAP4430 simulator, ES1 Chip & OMAP3430 SDP.
And also Compiled for OMAP2430 and OMAP2420

This patch has a dependency on the earlier set of OMAP4 clock-domain patches.

 arch/arm/mach-omap2/clockdomains.h |1 +
 arch/arm/mach-omap2/clockdomains44xx.h |8 
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomains.h 
b/arch/arm/mach-omap2/clockdomains.h
index f985e0a..6dc5ddc 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -461,6 +461,7 @@ static struct clockdomain *clockdomains_omap[] = {
&l4_secure_44xx_clkdm,
&l4_per_44xx_clkdm,
&abe_44xx_clkdm,
+   &l3_instr_44xx_clkdm,
&l3_init_44xx_clkdm,
&mpuss_44xx_clkdm,
&mpu0_44xx_clkdm,
diff --git a/arch/arm/mach-omap2/clockdomains44xx.h 
b/arch/arm/mach-omap2/clockdomains44xx.h
index 6fc55e4..438aaee 100644
--- a/arch/arm/mach-omap2/clockdomains44xx.h
+++ b/arch/arm/mach-omap2/clockdomains44xx.h
@@ -102,6 +102,14 @@ static struct clockdomain abe_44xx_clkdm = {
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
 };
 
+static struct clockdomain l3_instr_44xx_clkdm = {
+   .name = "l3_instr_clkdm",
+   .pwrdm= { .name = "core_pwrdm" },
+   .clkstctrl_reg= OMAP4430_CM_L3INSTR_CLKSTCTRL,
+   .clktrctrl_mask   = OMAP4430_CLKTRCTRL_MASK,
+   .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
 static struct clockdomain l3_init_44xx_clkdm = {
.name = "l3_init_clkdm",
.pwrdm= { .name = "l3init_pwrdm" },
-- 
1.5.4.7

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP4 clock framework: Remove the checks preventing OMAP4 clockdomain validation

[Abhijit Pagare]

The clockdomain related code being in place, it is not necessary to have
some part of the clock code commented out. This would help the validation of
the clockdomain functions using the clock level interfaces.

Signed-off-by: Abhijit Pagare 
Cc: Paul Walmsley 
---
Re-submitting with proper subject line.

Compiled and Boot Tested on OMAP4430 simulator, ES1 Chip & OMAP3430 SDP.
And also Compiled for OMAP2430 and OMAP2420

This patch has a dependency on the earlier set of OMAP4 clock-domain patches.

 arch/arm/mach-omap2/clock.c  |8 
 arch/arm/mach-omap2/clock44xx_data.c |2 --
 2 files changed, 0 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 759c72a..a6d570a 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -181,7 +181,6 @@ static int _dpll_test_fint(struct clk *clk, u8 n)
  * clockdomain pointer, and save it into the struct clk.  Intended to be
  * called during clk_register().  No return value.
  */
-#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
 void omap2_init_clk_clkdm(struct clk *clk)
 {
struct clockdomain *clkdm;
@@ -199,7 +198,6 @@ void omap2_init_clk_clkdm(struct clk *clk)
 "clkdm %s\n", clk->name, clk->clkdm_name);
}
 }
-#endif
 
 /**
  * omap2_init_clksel_parent - set a clksel clk's parent field from the hardware
@@ -476,10 +474,8 @@ void omap2_clk_disable(struct clk *clk)
_omap2_clk_disable(clk);
if (clk->parent)
omap2_clk_disable(clk->parent);
-#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
if (clk->clkdm)
omap2_clkdm_clk_disable(clk->clkdm, clk);
-#endif
 
}
 }
@@ -489,10 +485,8 @@ int omap2_clk_enable(struct clk *clk)
int ret = 0;
 
if (clk->usecount++ == 0) {
-#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
if (clk->clkdm)
omap2_clkdm_clk_enable(clk->clkdm, clk);
-#endif
 
if (clk->parent) {
ret = omap2_clk_enable(clk->parent);
@@ -511,10 +505,8 @@ int omap2_clk_enable(struct clk *clk)
return ret;
 
 err:
-#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
if (clk->clkdm)
omap2_clkdm_clk_disable(clk->clkdm, clk);
-#endif
clk->usecount--;
return ret;
 }
diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 2210e22..f47ba9e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2749,9 +2749,7 @@ int __init omap2_clk_init(void)
if (c->cpu & cpu_clkflg) {
clkdev_add(&c->lk);
clk_register(c->lk.clk);
-   /* TODO
omap2_init_clk_clkdm(c->lk.clk);
-   */
}
 
recalculate_root_clocks();
-- 
1.5.4.7

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] ARM : OMAP4 : MUSB : Add USB support to 4430 SDP board file

[Olof Johansson]

Hi,

On Wed, Dec 30, 2009 at 07:56:38PM +0530, Maulik Mankad wrote:

> --- felipe_musb.orig/arch/arm/mach-omap2/board-4430sdp.c
> +++ felipe_musb/arch/arm/mach-omap2/board-4430sdp.c
> @@ -73,11 +75,21 @@ static void __init omap_4430sdp_init_irq
>   omap_gpio_init();
>  }
>  
> +static struct omap_musb_board_data musb_board_data = {
> + .interface_type = MUSB_INTERFACE_UTMI,
> + .mode   = MUSB_PERIPHERAL,
> + .power  = 100,
> +};
>  
>  static void __init omap_4430sdp_init(void)
>  {
>   platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
>   omap_serial_init();
> +#ifdef CONFIG_NOP_USB_XCEIV
> + /* OMAP4 SDP uses Internal transceiver so register nop transceiver */
> + usb_nop_xceiv_register();
> +#endif
> + usb_musb_init(&musb_board_data);

If you add a select of NOP_USB_XCEIV in the board config option you can
do away with the ifdef.

Is there ever a case, for this board, where you don't want NOP_USB_XCEIV
enabled?

Failing that, add an empty init function to the header file such that
you can always call it even when the option is not enabled. It keeps
the amount of ifdeffery in the code to a minimum.


-Olof

--
To unsubscribe from this list: send the line "unsubscribe 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: regression: crash from 'ls /sys/modules/wl1251_spi/notes'

[Kalle Valo]

James Bottomley  writes:

> On Wed, 2009-12-30 at 13:41 +0200, Kalle Valo wrote:
>
>> Also removing wl1251_spi causes a crash. The reason for this is that a
>> sysfs file with a null string as name is trying to be removed from the
>> notes directory.
>
> Yes, this is because the notes sections describe the text sections.
> When we ignore an empty text section, we'd need to ignore its
> corresponding notes section.
>
> The reason we didn't see this on parisc is because our compiler doesn't
> actually produce any notes sections.

Also on omap not all modules can reproduce the problem. For example
cfg80211, mac80211 and wl1251 modules work just fine, but with
wl1251_spi I see the problem everytime.

> A better, and more comprehensive patch would be to try not to count the
> empty text sections when we're building the notes section (and actually
> anywhere else in the file).  This patch actually relies on the fact that
> if sh_size is zero for the text section it should be for the
> corresponding notes section.  If that doesn't work, we'd actually have
> to do the matching in the construction piece.
>
> Can you try it to see if it works for you?  If it doesn't, I'll try
> matching notes to text.  It works fine on parisc, but as we don't have a
> notes section, that's not saying much ...

Thanks. I tested the patch on my setup, this time on top of Linus'
tree (commit 6b7b284). And the patch fixes the issue, I can't
reproduce the problem at all, both 'rmmod wl1251_spi' and ls work
without any problems. So here's my tested-by:

Tested-by: Kalle Valo 

Also please consider sending the fix to stable.

Thank you for fixing this so fast.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe 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] power_supply: Add driver for TWL4030/TPS65950 BCI charger

[Madhusudhan]

> -Original Message-
> From: Anton Vorontsov [mailto:avoront...@ru.mvista.com]
> Sent: Thursday, December 10, 2009 8:44 AM
> To: Felipe Balbi
> Cc: Grazvydas Ignotas; linux-ker...@vger.kernel.org; Madhusudhan
> Chikkature; linux-omap@vger.kernel.org
> Subject: Re: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI
> charger
> 
> On Thu, Dec 10, 2009 at 04:21:27PM +0200, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Dec 10, 2009 at 03:18:30PM +0100, ext Anton Vorontsov wrote:
> > >>Ok since it doesn't look like this will resolve soon, what about
> > >>adding some DEVICE_ATTR for the time being and requiring userspace to
> > >>write charge current here to start actual charging?
> > >
> > >Works for me. Let's think of the kernel charging support as an
> > >yet unimplemented feature.
> >
> > but if you guys are ok with this one for now. It can always be
> > changed later :-)
> 
> Yep. The only thing I'm afraid of is that once the driver is in,
> then nobody will bother with improving it to do the right thing.
> But an imperfect driver is better than none.
> 

So, what is the conclusion then? Are you planning to push the BCI charger
patch currently and handle updates later?

Regards,
Madhu

> Thanks,
> 
> --
> Anton Vorontsov
> email: cbouatmai...@gmail.com
> irc://irc.freenode.net/bd2

--
To unsubscribe from this list: send the line "unsubscribe 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/5] Enable DSS2 for OMAP3EVM & AM3517

[Hiremath, Vaibhav]

> -Original Message-
> From: Hiremath, Vaibhav
> Sent: Thursday, December 17, 2009 8:48 PM
> To: tomi.valkei...@nokia.com
> Cc: linux-omap@vger.kernel.org; linux-fbdev-
> de...@lists.sourceforge.net; linux-fb...@vger.kernel.org; Hiremath,
> Vaibhav
> Subject: [PATCH 0/5] Enable DSS2 for OMAP3EVM & AM3517
> 
> From: Vaibhav Hiremath 
> 
> Patch series adds following features -
> 
>   - Enable DSS2/Fbdev on OMAP3EVM
>   - Add LQ043T1DG01 panel file
>   - Enable DSS2/Fbdev on AM3517EVM
>   - Warning message fix in dss-core
>   - Kconfig option added to choose between S-Video and CVBS
> output
> 
> TODO -
>   - V4L2 Display driver ontop of DSS2 (will post in couple of
> days)
>   - regulator_get for panel-generic.c, which is required to get
> DVI colors
> properly
> 
> Vaibhav Hiremath (5):
>   dss2-core:Warning Fix: core_dump_clocks enclosed under DEBUG_FS
>   OMAP: DSS2: Add Sharp LQ043T1DG01 panel drivers
>   OMAP: Enable DSS2 for OMAP3EVM board
>   AM3517: Enable DSS2 for AM3517EVM board
>   OMAP3EVM: Kconfig option added for selection between SVIDEO and
> CVBS
> 
>  arch/arm/configs/am3517_evm_defconfig  |   53 -
>  arch/arm/configs/omap3_evm_defconfig   |   51 -
>  arch/arm/mach-omap2/board-am3517evm.c  |  142
> +++
>  arch/arm/mach-omap2/board-omap3evm.c   |  250
> +++-
>  drivers/video/omap2/displays/Kconfig   |6 +
>  drivers/video/omap2/displays/Makefile  |1 +
>  .../video/omap2/displays/panel-sharp-lq043t1dg01.c |  120
> ++
>  drivers/video/omap2/dss/Kconfig|   15 ++
>  drivers/video/omap2/dss/core.c |2 +
>  9 files changed, 627 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/video/omap2/displays/panel-sharp-
> lq043t1dg01.c
[Hiremath, Vaibhav] 
Tomi,

Any update on this? Can we merge these patches? 
(Of-course except Kconfig changes for TV out selection, actually I am waiting 
for your comment on this patch.)

Thanks,
Vaibhav

--
To unsubscribe from this list: send the line "unsubscribe 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] OMAP3EVM: Choose OMAP_PACKAGE_CBB

[hvaibhav]

From: Vaibhav Hiremath 

Without this the kernel doesn't boot, it craches in
omap_mux_package_fixup(), since the package_subset becomes NULL.

Signed-off-by: Vaibhav Hiremath 
---
 arch/arm/mach-omap2/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 10eafa7..606bf04 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -80,6 +80,7 @@ config MACH_OVERO
 config MACH_OMAP3EVM
bool "OMAP 3530 EVM board"
depends on ARCH_OMAP3 && ARCH_OMAP34XX
+   select OMAP_PACKAGE_CBB
 
 config MACH_OMAP3517EVM
bool "OMAP3517/ AM3517 EVM board"
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html