Re: [PATCH v5 09/17] OMAP2,3: DSS2: DSS: create platform_driver, move init,exit to driver

[Kevin Hilman]

Sumit Semwal  writes:

> From: Senthilvadivu Guruswamy 
>
> Hwmod adaptation design requires each of the DSS HW IP to be a platform 
> driver.
> So a platform_driver of DSS is created and init exit methods are moved from 
> core.c
> to its driver probe,remove. pdev member has to be maintained by its own 
> drivers.
>
> DSS platform driver is registered from inside omap_dss_probe, in the order 
> desired.
>
> Signed-off-by: Senthilvadivu Guruswamy 
> Signed-off-by: Sumit Semwal 
> ---
>  drivers/video/omap2/dss/core.c |   21 +++
>  drivers/video/omap2/dss/dss.c  |   55 ++-
>  drivers/video/omap2/dss/dss.h  |4 +-
>  3 files changed, 65 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
> index 48d20d8..faca859 100644
> --- a/drivers/video/omap2/dss/core.c
> +++ b/drivers/video/omap2/dss/core.c
> @@ -497,9 +497,9 @@ static inline void dss_uninitialize_debugfs(void)
>  static int omap_dss_probe(struct platform_device *pdev)
>  {
>   struct omap_dss_board_info *pdata = pdev->dev.platform_data;
> - int skip_init = 0;
>   int r;
>   int i;
> + int skip_init = 0;

looks like unnessary move.

maybe you meant to remove this var since its usage was removed from this
function?

>   core.pdev = pdev;
>  
> @@ -517,15 +517,9 @@ static int omap_dss_probe(struct platform_device *pdev)
>   core.ctx_id = dss_get_ctx_id();
>   DSSDBG("initial ctx id %u\n", core.ctx_id);
>  
> -#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
> - /* DISPC_CONTROL */
> - if (omap_readl(0x48050440) & 1) /* LCD enabled? */
> - skip_init = 1;
> -#endif
> -
> - r = dss_init(skip_init);
> + r = dss_init_platform_driver();
>   if (r) {
> - DSSERR("Failed to initialize DSS\n");
> + DSSERR("Failed to initialize DSS platform driver\n");
>   goto err_dss;
>   }
>  
> @@ -553,6 +547,11 @@ static int omap_dss_probe(struct platform_device *pdev)
>   goto err_venc;
>   }
>  
> +#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
> + /* DISPC_CONTROL */
> + if (omap_readl(0x48050440) & 1) /* LCD enabled? */
> + skip_init = 1;
> +#endif

nope, you just moved it here.  

But it's also duplicated in dsshw_probe below.  Is that needed?

>   if (cpu_is_omap34xx()) {
>   r = sdi_init(skip_init);
>   if (r) {
> @@ -610,7 +609,7 @@ err_dispc:
>  err_dpi:
>   rfbi_exit();
>  err_rfbi:
> - dss_exit();
> + dss_deinit_platform_driver();

s/deinit/uninit/ or uninitial
>  err_dss:
>   dss_clk_disable_all_no_ctx();
>   dss_put_clocks();
> @@ -636,7 +635,7 @@ static int omap_dss_remove(struct platform_device *pdev)
>   sdi_exit();
>   }
>  
> - dss_exit();
> + dss_deinit_platform_driver();
>  
>   /* these should be removed at some point */
>   c = core.dss_ick->usecount;
> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
> index 77c3621..ebb294a 100644
> --- a/drivers/video/omap2/dss/dss.c
> +++ b/drivers/video/omap2/dss/dss.c
> @@ -59,6 +59,7 @@ struct dss_reg {
>   dss_write_reg(idx, FLD_MOD(dss_read_reg(idx), val, start, end))
>  
>  static struct {
> + struct platform_device *pdev;
>   void __iomem*base;
>  
>   struct clk  *dpll4_m4_ck;
> @@ -549,7 +550,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
>   REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
>  }
>  
> -int dss_init(bool skip_init)
> +static int dss_init(bool skip_init)
>  {
>   int r;
>   u32 rev;
> @@ -629,7 +630,7 @@ fail0:
>   return r;
>  }
>  
> -void dss_exit(void)
> +static void dss_exit(void)
>  {
>   if (cpu_is_omap34xx())
>   clk_put(dss.dpll4_m4_ck);
> @@ -639,3 +640,53 @@ void dss_exit(void)
>   iounmap(dss.base);
>  }
>  
> +/* DSS HW IP initialisation */
> +static int omap_dsshw_probe(struct platform_device *pdev)
> +{
> + int r;
> + int skip_init = 0;
> +
> + dss.pdev = pdev;
> +
> +#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
> + /* DISPC_CONTROL */
> + if (omap_readl(0x48050440) & 1) /* LCD enabled? */
> + skip_init = 1;
> +#endif
> +
> + r = dss_init(skip_init);
> + if (r) {
> + DSSERR("Failed to initialize DSS\n");
> + goto err_dss;
> + }
> +
> +err_dss:
> +
> + return r;
> +}
> +
> +static int omap_dsshw_remove(struct platform_device *pdev)
> +{
> + dss_exit();
> +
> + return 0;
> +}
> +
> +static struct platform_driver omap_dsshw_driver = {
> + .probe  = omap_dsshw_probe,
> + .remove = omap_dsshw_remove,
> + .driver = {
> + .name   = "omap_dss",
> + .owner  = THIS_MODULE,
> + },
> +};
> +
> +int dss_init_platform_driver(void)
> +{
> + return platform_driver_register(&omap_dsshw_driver);
> +}
> +
> +void dss_deinit_platform_driver(void)
> +{
> +

Re: [PATCH v5 08/17] OMAP2,3: DSS2: Build omap_device for each DSS HWIP

[Kevin Hilman]

Sumit Semwal  writes:

> From: Senthilvadivu Guruswamy 
>
> Looks up the hwmod database for each of the given DSS HW IP and builds
> omap_device which inturn does the platform device register for each of DSS HW 
> IP
>
> Signed-off-by: Senthilvadivu Guruswamy 
> Signed-off-by: Sumit Semwal 
> ---
>  arch/arm/mach-omap2/display.c |   44 
> +
>  arch/arm/plat-omap/include/plat/display.h |6 
>  2 files changed, 50 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index 26d3feb..276b800 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -36,10 +36,54 @@ static struct platform_device omap_display_device = {
>   },
>  };
>  
> +static struct omap_device_pm_latency omap_dss_latency[] = {
> + [0] = {
> + .deactivate_func= omap_device_idle_hwmods,
> + .activate_func  = omap_device_enable_hwmods,

Without any latency numbers or AUTO_ADJUST you're going to have noisy
output from omap_device.

> + },
> +};
> +
>  int __init omap_display_init(struct omap_dss_board_info
>   *board_data)
>  {
>   int r = 0;
> + struct omap_hwmod *oh;
> + struct omap_device *od;
> + int i;
> + struct omap_display_platform_data pdata;
> + char *oh_name[] = { "dss_dss",  /* omap2,3 */
> + "dss_dispc",/* omap2,3 */
> + "dss_rfbi", /* omap2,3 */
> + "dss_venc", /* omap2,3 */
> + "dss_dsi1" };   /* omap3 */

Why all the extra whitespace before the strings?

> + char *dev_name[] = { "omap_dss", "omap_dispc", "omap_rfbi",
> + "omap_venc", "omap_dsi1" };

ditto

> + int oh_count;
> +
> + if (cpu_is_omap24xx()) {
> + oh_count = ARRAY_SIZE(oh_name) - 1;
> + /* last hwmod dev in oh_name is not available for omap2 */
> + } else {
> + oh_count = ARRAY_SIZE(oh_name);
> + }

braces not needed

> + pdata.board_data=   board_data;

extra whitespace not necessary

> + pdata.board_data->get_last_off_on_transaction_id = NULL;

instead, you should probably zero all of pdata before using it since it
is on the stack

> + for (i = 0; i < oh_count; i++) {
> + oh = omap_hwmod_lookup(oh_name[i]);
> + if (!oh) {
> + pr_err("Could not look up %s\n", oh_name[i]);
> + return r;
> + }
> + od = omap_device_build(dev_name[i], -1, oh, &pdata,
> + sizeof(struct omap_display_platform_data),
> + omap_dss_latency,
> + ARRAY_SIZE(omap_dss_latency), 0);
> +
> + WARN((IS_ERR(od)), "Could not build omap_device for %s\n",
> + oh_name[i]);

yet code below will still try and register it?

> + }
>   omap_display_device.dev.platform_data = board_data;
>  
>   r = platform_device_register(&omap_display_device);
> diff --git a/arch/arm/plat-omap/include/plat/display.h 
> b/arch/arm/plat-omap/include/plat/display.h
> index 871bbae..23afd6d 100644
> --- a/arch/arm/plat-omap/include/plat/display.h
> +++ b/arch/arm/plat-omap/include/plat/display.h
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  
> +

stray whitespace change

>  #define DISPC_IRQ_FRAMEDONE  (1 << 0)
>  #define DISPC_IRQ_VSYNC  (1 << 1)
>  #define DISPC_IRQ_EVSYNC_EVEN(1 << 2)
> @@ -224,6 +225,11 @@ struct omap_dss_board_info {
>  /* Init with the board info */
>  extern int omap_display_init(struct omap_dss_board_info *board_data);
>  
> +struct omap_display_platform_data {
> + struct omap_dss_board_info *board_data;
> + /* TODO: Additional members to be added when PM is considered */
> +};
> +
>  struct omap_video_timings {
>   /* Unit: pixels */
>   u16 x_res;

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

[GIT PULL] misc. fixes for 2.6.38-rc

[Kevin Hilman]

Tony,

Here's a queue of misc. fixes for 2.6.38.  This branch is on top of your
current omap-fixes branch.

Kevin

The following changes since commit a9b365bdc328bd66e97087d0dba0b9a3d9eb1ac6:

  omap2+: wdt: trivial sparse fixes (2011-01-06 19:58:28 -0800)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
fixes-for-tony

Felipe Balbi (1):
  arm: omap: gpio: don't access irq_desc array directly

Koen Kooi (3):
  omap3: beaglexm: fix EHCI power up GPIO dir
  omap3: beaglexm: fix DVI reset GPIO
  omap3: beaglexm: fix power on of DVI

Mika Westerberg (1):
  OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+

Nishanth Menon (4):
  OMAP3+: sr_device: include pm header
  OMAP2+: TWL: make conversion routines static
  OMAP2+: TWL: include pm header for init protos
  omap2+: pm_bus: make functions used as pointers as static

Santosh Shilimkar (5):
  omap2plus: clockdomain: Trivial fix for build break because of 
clktrctrl_mask
  omap2plus: voltage: Trivial warning fix 'no return statement'
  omap2plus: voltage: Trivial linking fix 'undefined reference'
  omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
  omap2plus: prm: Trvial build break fix for undefined reference to 
'omap2_prm_read_mod_reg'

 arch/arm/mach-omap2/board-omap3beagle.c   |   37 +++--
 arch/arm/mach-omap2/clockdomain.h |2 -
 arch/arm/mach-omap2/omap_twl.c|   10 +++--
 arch/arm/mach-omap2/pm_bus.c  |4 +-
 arch/arm/mach-omap2/prm2xxx_3xxx.h|   63 -
 arch/arm/mach-omap2/sr_device.c   |1 +
 arch/arm/plat-omap/gpio.c |   12 --
 arch/arm/plat-omap/include/plat/voltage.h |   17 ++--
 8 files changed, 124 insertions(+), 22 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 v4 0/3] OMAP3: beaglexm: GPIO fixes

[Kevin Hilman]

Nishanth Menon  writes:

> As discussed in the threads:
> http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
> http://marc.info/?t=12154003084&r=1&w=2
>
> here is the split up series with commit message after discussion:
> http://www.beagleboard.org/irclogs/index.php?date=2011-01-06#T19:12:21
>
> Koen Kooi (3):
>   omap3: beaglexm: fix EHCI power up GPIO dir
>   omap3: beaglexm: fix DVI reset GPIO
>   omap3: beaglexm: fix power on of DVI
>
>  arch/arm/mach-omap2/board-omap3beagle.c |   37 ++
>  1 files changed, 32 insertions(+), 5 deletions(-)
>
> v4:
>   no functional change.
>   minor cleanups in commit logs incorporating offline feedback

Thanks for the updates.  Will queue in  my fixes queue.

Kevin

> v3: http://marc.info/?t=12943438476&r=1&w=2
>   split up the series, addressed review comments
>
> v2: http://marc.info/?t=12927697792&r=1&w=2
>   Reenable the PMU stat LED
> v1: http://marc.info/?t=12917257101&r=1&w=2
>
> 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

Re: [PATCH 0/3] OMAP4: DSS OMAP4 hwmod support

[Kevin Hilman]

Sumit Semwal  writes:

> This patch series enables support for OMAP4 DSS, and adds hwmod support
> for dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods.

This series is confusing as the 3 patches here do not do all the things
described here.

It also doesn't apply to the master branch (e.g. PATCH 3/3 modifies
display.c, which doesn't exist until your other series.)

Please take care when writing these cover letters to be sure they are
accurate, otherwise reviewers/maintainers can't help but be confused
about what is going on.

Kevin


> In OMAP4 there are severals IPs that can be reached by differents
> interconnect paths depending of the access initiator (MPU vs. SDMA).
>
> In the case of the DSS, both L3 direct path and L4 CFG path can be
> used to access all the DSS IPs.
> dss is also considered as an IP as dispc, rfbi, and named as dss_dss.
>
> TODO:
> This patch doesn't handle the opt clocks via hwmod - there will be a separate
> patch series which will take opt clock roles from hwmod, populate them in
> the device structure, so that the driver can ask for relevant opt-clocks.
>
> Also TBD is the migration to pm_runtime APIs, which need to be adapted a 
> little
> for handling DSS-family of clocks completely.
>
> Patch Base:
> ===
> url = git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
> branch "master"
> Commit id: fa3b4e23ec20cfc944db7cc2b30b0d82c20e4472
> Description:  cbus: Fix retu_rtc_do_reset
> +
> hwmod patches under discussion: 
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41534.html
> +
> patch series: OMAP2PLUS: DSS: Generalize clock names
> 
>
> Benoit Cousson (1):
>   OMAP4: hwmod data: add DSS DISPC DSI1,2 RFBI HDMI VENC
>
> Mayuresh Janorkar (1):
>   OMAP2PLUS: DSS2: Add OMAP4 support
>
> Sumit Semwal (1):
>   OMAP4: DSS2: Add hwmod device names for OMAP4.
>
>  arch/arm/mach-omap2/display.c  |   23 +-
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  588 
> 
>  drivers/video/omap2/dss/Kconfig|6 +-
>  drivers/video/omap2/omapfb/Kconfig |6 +-
>  4 files changed, 609 insertions(+), 14 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/3] omap3: beaglexm: fix EHCI power up GPIO dir

[Nishanth Menon]

From: Koen Kooi 

EHCI enable power pin is inverted (active high) in comparison
to vanilla beagle which is active low. Handle this case conditionally.

Without this fix, Beagle XM 4 port EHCI will not function and no
networking will be available

[...@ti.com: split up, added descriptive changelogs]
Signed-off-by: Nishanth Menon 
Signed-off-by: Koen Kooi 
---
 arch/arm/mach-omap2/board-omap3beagle.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 6c12760..1b5aa7a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -297,9 +297,16 @@ static int beagle_twl_gpio_setup(struct device *dev,
gpio_request(gpio + 1, "EHCI_nOC");
gpio_direction_input(gpio + 1);
 
-   /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */
+   /*
+* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
+* high / others active low)
+*/
gpio_request(gpio + TWL4030_GPIO_MAX, "nEN_USB_PWR");
gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+   gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+   else
+   gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
 
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
-- 
1.6.3.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 v4 2/3] omap3: beaglexm: fix DVI reset GPIO

[Nishanth Menon]

From: Koen Kooi 

GPIO reset line for Beagle XM is different from vanilla beagle
so we populate it as part of gpio update routine.

This in part fixes the issue of display not functioning on beagle XM
platform.

[...@ti.com: split up, added descriptive changelogs]
Signed-off-by: Nishanth Menon 
Signed-off-by: Koen Kooi 
---
 arch/arm/mach-omap2/board-omap3beagle.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 1b5aa7a..d628f5e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -199,7 +199,7 @@ static struct omap_dss_device beagle_dvi_device = {
.name = "dvi",
.driver_name = "generic_panel",
.phy.dpi.data_lines = 24,
-   .reset_gpio = 170,
+   .reset_gpio = -EINVAL,
.platform_enable = beagle_enable_dvi,
.platform_disable = beagle_disable_dvi,
 };
@@ -308,6 +308,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
else
gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
 
+   /* DVI reset GPIO is different between beagle revisions */
+   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+   beagle_dvi_device.reset_gpio = 129;
+   else
+   beagle_dvi_device.reset_gpio = 170;
+
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
 
-- 
1.6.3.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 v4 3/3] omap3: beaglexm: fix power on of DVI

[Nishanth Menon]

From: Koen Kooi 

TFP410 DVI chip is used to provide display out.
This chip is controlled by 2 lines:
LDO which supplies the power is controlled over gpio + 2
and the enable of the chip itself is done over gpio + 1
NOTE: the LDO is necessary for LED, serial blocks as well.

gpio + 1 was used to sense USB overcurrent in vanilla beagle.

Without this fix, the display would not function as the LDO
remains shut down.

[...@ti.com: split up, added descriptive changelogs]
Signed-off-by: Nishanth Menon 
Signed-off-by: Koen Kooi 
---
 arch/arm/mach-omap2/board-omap3beagle.c |   20 +---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index d628f5e..7c82730 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -293,9 +293,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* REVISIT: need ehci-omap hooks for external VBUS
 * power switch and overcurrent detect
 */
-
-   gpio_request(gpio + 1, "EHCI_nOC");
-   gpio_direction_input(gpio + 1);
+   if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
+   gpio_request(gpio + 1, "EHCI_nOC");
+   gpio_direction_input(gpio + 1);
+   }
 
/*
 * TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
@@ -317,6 +318,19 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
 
+   /*
+* gpio + 1 on Xm controls the TFP410's enable line (active low)
+* gpio + 2 control varies depending on the board rev as follows:
+* P7/P8 revisions(prototype): Camera EN
+* A2+ revisions (production): LDO (supplies DVI, serial, led blocks)
+*/
+   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+   gpio_request(gpio + 1, "nDVI_PWR_EN");
+   gpio_direction_output(gpio + 1, 0);
+   gpio_request(gpio + 2, "DVI_LDO_EN");
+   gpio_direction_output(gpio + 2, 1);
+   }
+
return 0;
 }
 
-- 
1.6.3.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 v4 0/3] OMAP3: beaglexm: GPIO fixes

[Nishanth Menon]

Hi,
As discussed in the threads:
http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
http://marc.info/?t=12154003084&r=1&w=2

here is the split up series with commit message after discussion:
http://www.beagleboard.org/irclogs/index.php?date=2011-01-06#T19:12:21

Koen Kooi (3):
  omap3: beaglexm: fix EHCI power up GPIO dir
  omap3: beaglexm: fix DVI reset GPIO
  omap3: beaglexm: fix power on of DVI

 arch/arm/mach-omap2/board-omap3beagle.c |   37 ++
 1 files changed, 32 insertions(+), 5 deletions(-)

v4:
  no functional change.
  minor cleanups in commit logs incorporating offline feedback

v3: http://marc.info/?t=12943438476&r=1&w=2
split up the series, addressed review comments

v2: http://marc.info/?t=12927697792&r=1&w=2
Reenable the PMU stat LED
v1: http://marc.info/?t=12917257101&r=1&w=2

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

Re: [PATCH 7/7 v2] OMAP: runtime: McSPI driver runtime conversion

[Kevin Hilman]

Grant Likely  writes:

> On Wed, Dec 01, 2010 at 07:32:11PM +0530, Govindraj.R wrote:
>> McSPI runtime conversion.
>> Changes involves:
>> 1) remove clock framework apis to use runtime framework apis.
>> 2) context restore from runtime resume which is a callback for get_sync.
>> 3) Remove SYSCONFIG(sysc) register handling
>> (a) Remove context save and restore of sysc reg and remove soft reset
>> done from sysc reg as this will be done with hwmod framework.
>> (b) Also cleanup sysc reg bit macros.
>> 4) Rename the omap2_mcspi_reset function to omap2_mcspi_master_setup
>>function as with hwmod changes soft reset will be done in
>>hwmod framework itself and use the return value from clock
>>enable function to return for failure scenarios.
>> 
>> Signed-off-by: Charulatha V 
>> Signed-off-by: Govindraj.R 
>> Reviewed-by: Partha Basak 
>
> One comment below, but otherwise looks good to me.  Since the majority
> of the changes are in arch/arm, feel free to add my Acked-by for the
> whole series and merge via the omap tree.  

Thanks, we'll merge this through the OMAP tree.

> None of my comments are showstoppers, so I'm even fine with merging
> them as-is as long as followup patches are posted to address the
> comments.

Govindraj, since we've missed 2.6.38 for this series, I'd like to see the last 
few
minor issues cleaned up before merge, especially the various casting and
CodingStyle issues that Grant found.

Kevin

> In particular, I'd really like to see the data duplication issue from
> the first 4 patches addressed.
>
> Acked-by: Grant Likely 
>
>
>> ---
>>  drivers/spi/omap2_mcspi.c |  120 
>> +---
>>  1 files changed, 46 insertions(+), 74 deletions(-)
>> 
>> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
>> index ad3811e..a1b157f 100644
>> --- a/drivers/spi/omap2_mcspi.c
>> +++ b/drivers/spi/omap2_mcspi.c
>> @@ -33,6 +33,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> 
>>  #include 
>> 
>> @@ -46,7 +47,6 @@
>>  #define OMAP2_MCSPI_MAX_CTRL4
>> 
>>  #define OMAP2_MCSPI_REVISION0x00
>> -#define OMAP2_MCSPI_SYSCONFIG   0x10
>>  #define OMAP2_MCSPI_SYSSTATUS   0x14
>>  #define OMAP2_MCSPI_IRQSTATUS   0x18
>>  #define OMAP2_MCSPI_IRQENABLE   0x1c
>> @@ -63,13 +63,6 @@
>> 
>>  /* per-register bitmasks: */
>> 
>> -#define OMAP2_MCSPI_SYSCONFIG_SMARTIDLE BIT(4)
>> -#define OMAP2_MCSPI_SYSCONFIG_ENAWAKEUP BIT(2)
>> -#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE  BIT(0)
>> -#define OMAP2_MCSPI_SYSCONFIG_SOFTRESET BIT(1)
>> -
>> -#define OMAP2_MCSPI_SYSSTATUS_RESETDONE BIT(0)
>> -
>>  #define OMAP2_MCSPI_MODULCTRL_SINGLEBIT(0)
>>  #define OMAP2_MCSPI_MODULCTRL_MSBIT(2)
>>  #define OMAP2_MCSPI_MODULCTRL_STEST BIT(3)
>> @@ -122,13 +115,12 @@ struct omap2_mcspi {
>>  spinlock_t  lock;
>>  struct list_headmsg_queue;
>>  struct spi_master   *master;
>> -struct clk  *ick;
>> -struct clk  *fck;
>>  /* Virtual base address of the controller */
>>  void __iomem*base;
>>  unsigned long   phys;
>>  /* SPI1 has 4 channels, while SPI2 has 2 */
>>  struct omap2_mcspi_dma  *dma_channels;
>> +struct  device  *dev;
>
> Inconsistent indentation with the rest of the structure (tabs vs. spaces).
>
>>  };
>> 
>>  struct omap2_mcspi_cs {
>> @@ -144,7 +136,6 @@ struct omap2_mcspi_cs {
>>   * corresponding registers are modified.
>>   */
>>  struct omap2_mcspi_regs {
>> -u32 sysconfig;
>>  u32 modulctrl;
>>  u32 wakeupenable;
>>  struct list_head cs;
>> @@ -268,9 +259,6 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi 
>> *mcspi)
>>  mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
>>  omap2_mcspi_ctx[spi_cntrl->bus_num - 1].modulctrl);
>> 
>> -mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
>> -omap2_mcspi_ctx[spi_cntrl->bus_num - 1].sysconfig);
>> -
>>  mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
>>  omap2_mcspi_ctx[spi_cntrl->bus_num - 1].wakeupenable);
>> 
>> @@ -280,20 +268,12 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi 
>> *mcspi)
>>  }
>>  static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
>>  {
>> -clk_disable(mcspi->ick);
>> -clk_disable(mcspi->fck);
>> +pm_runtime_put_sync(mcspi->dev);
>>  }
>> 
>>  static int omap2_mcspi_enable_clocks(struct omap2_mcspi *mcspi)
>>  {
>> -if (clk_enable(mcspi->ick))
>> -return -ENODEV;
>> -if (clk_enable(mcspi->fck))
>> -return -ENODEV;
>> -
>> -omap2_mcspi_restore_ctx(mcspi);
>> -
>> -return 0;
>> +return pm_runtime_get_sync(mcspi->dev);
>>  }
>> 
>>  static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
>> @@ -819,8 +799,9 @@ static int omap2_mcspi_s

Re: [RFC] omap3: Enable SmartReflex calculations for 720MHz

[Koen Kooi]

Op 7 jan 2011, om 18:26 heeft Sanjeev Premi het volgende geschreven:

> The eFuse registers do not contain the nValue to be used
> with 720MHz (OPP6). This patch implements procedure to
> calculate the nValue(OPP6) based on the nValue(OPP5).
> 
>  [1] SPRUFF1D-June 2009 section 1.5.2.1.1
> 
> This is first attempt to fit this mechanism into new
> smartreflex framework. Do note a FIXME which is added
> to illustrate the calculations; and express need for
> a mechanism to get nValues for each OPP.
> 
> Signed-off-by: Sanjeev Premi 
> ---
> arch/arm/mach-omap2/sr_device.c   |   54 +
> arch/arm/mach-omap2/voltage.c |1 +
> arch/arm/plat-omap/include/plat/voltage.h |1 +
> 3 files changed, 56 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
> index 786d685..43640a3 100644
> --- a/arch/arm/mach-omap2/sr_device.c
> +++ b/arch/arm/mach-omap2/sr_device.c
> @@ -38,6 +38,51 @@ static struct omap_device_pm_latency omap_sr_latency[] = {
>   },
> };
> 
> +static void swcalc_opp6_RG(u32 rFuse, u32 gainFuse, u32 deltaNT,
> +   u32* rAdj, u32* gainAdj)
> +{
> +   u32 nAdj;
> +   u32 g, r;
> +
> +   nAdj = ((1 << (gainFuse + 8))/rFuse) + deltaNT;
> +
> +   for (g = 0; g < GAIN_MAXLIMIT; g++) {

GAIN_MAXLIMIT is undeclared at this point:

arch/arm/mach-omap2/sr_device.c: In function ‘swcalc_opp6_RG’:
arch/arm/mach-omap2/sr_device.c:49: error: ‘GAIN_MAXLIMIT’ undeclared (first 
use in this function)


> +   r = (1 << (g + 8)) / nAdj;
> +   if (r < 256) {
> +   *rAdj = r;
> +   *gainAdj = g;
> +   }
> +   }
> +}
> +
> +#define SWCALC_OPP6_DELTA_NNT379
> +#define SWCALC_OPP6_DELTA_PNT227
> +#define GAIN_MAXLIMIT16

So these have to move up at bit.

regards,

Koen--
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: Latest regressions

[Kevin Hilman]

Tony Lindgren  writes:

> * Russell King - ARM Linux  [110107 03:57]:

[...]

>> diff --git a/arch/arm/plat-omap/include/plat/voltage.h 
>> b/arch/arm/plat-omap/include/plat/voltage.h
>> index 0ff1233..ffcdff9 100644
>> --- a/arch/arm/plat-omap/include/plat/voltage.h
>> +++ b/arch/arm/plat-omap/include/plat/voltage.h
>> @@ -14,6 +14,8 @@
>>  #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
>>  #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
>>  
>> +#include 
>> +
>>  #define VOLTSCALE_VPFORCEUPDATE 1
>>  #define VOLTSCALE_VCBYPASS  2
>
> This fix is already queued up by Kevin, but missing..

Yeah, the one in my queue uses  because of usage of
ERR_PTR(), but fixes the same problem.

>> @@ -133,9 +135,9 @@ void omap_change_voltscale_method(struct voltagedomain 
>> *voltdm,
>>  int voltscale_method);
>>  int omap_voltage_late_init(void);
>>  #else
>> -static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
>> +static inline void omap_voltage_register_pmic(struct voltagedomain *voltdm,
>>  struct omap_volt_pmic_info *pmic_info) {}
>> -static inline  void omap_change_voltscale_method(struct voltagedomain 
>> *voltdm,
>> +static inline void omap_change_voltscale_method(struct voltagedomain 
>> *voltdm,
>>  int voltscale_method) {}
>>  static inline int omap_voltage_late_init(void)
>>  {
>
> ..this change.

And this is fixed in my queue as well, but differently.  Instead of
changing to void, it keeps the int return value and returns -EINVAL.

Will be sending pull request for my queue of fixes shortly, after a
little more build/boot testing.

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

Re: [PATCH v5 06/17] OMAP2,3: DSS2: Create new file display.c for central dss driver registration.

[Kevin Hilman]

Sumit Semwal  writes:

> A new file display.c is introduced for display driver init, which adds a 
> function
> omap_display_init to do the DSS driver registration. This is the first step 
> in moving
> away registration of DSS from board files into a common place.
>
> Signed-off-by: Senthilvadivu Guruswamy 
> Signed-off-by: Sumit Semwal 
> ---
>  arch/arm/mach-omap2/Makefile  |2 +
>  arch/arm/mach-omap2/display.c |   57 
> +
>  arch/arm/plat-omap/include/plat/display.h |4 ++
>  3 files changed, 63 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/display.c
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 4ab82f6..57b89e6 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -237,3 +237,5 @@ obj-y += $(smc91x-m) 
> $(smc91x-y)
>  
>  smsc911x-$(CONFIG_SMSC911X)  := gpmc-smsc911x.o
>  obj-y+= $(smsc911x-m) $(smsc911x-y)
> +
> +obj-y+= display.o
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> new file mode 100644
> index 000..26d3feb
> --- /dev/null
> +++ b/arch/arm/mach-omap2/display.c
> @@ -0,0 +1,57 @@
> +/*
> + * OMAP2plus display device setup / initialization.
> + *
> + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
> + *   Senthilvadivu Guruswamy
> + *  Sumit Semwal
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This 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 

Minor nit: the hwmod and omap_device headers are not needed for this
patch.  Please add them when needed (PATCH 8)

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

Re: [PATCH 4/9] cpuidle: Introduce .abbr (abbrevation) for cpuidle states

[Kevin Hilman]

Thomas Renninger  writes:

> and fill name, description and newly introduced abbrevation
> consistently (always use snprintf) in all cpuidle drivers.
>
> This is mainly for perf timechart. It draws vector graphics
> pictures of sleep/idle state usage catching perf cpu_idle events.
> The string used for the idle state must not exceed 3 chars or
> you can't see much in these pictures.
> The name could get used in the title, the introduced abbrevations
> inside of the picture and the text must therefore be rather short.
>
> Signed-off-by: Thomas Renninger 
> CC: l...@kernel.org
> CC: linux-a...@vger.kernel.org
> CC: linux...@lists.linux-foundation.org
> CC: Arjan van de Ven 
> CC: Ingo Molnar 
> CC: Frederic Weisbecker 
> CC: linux-ker...@vger.kernel.org
> CC: linux-omap@vger.kernel.org
> ---
>  arch/arm/mach-at91/cpuidle.c  |   12 
>  arch/arm/mach-davinci/cpuidle.c   |   13 +
>  arch/arm/mach-kirkwood/cpuidle.c  |   12 
>  arch/arm/mach-omap2/cpuidle34xx.c |3 ++-
>  arch/sh/kernel/cpu/shmobile/cpuidle.c |   19 +++
>  drivers/acpi/processor_idle.c |3 +++
>  drivers/cpuidle/cpuidle.c |1 +
>  drivers/cpuidle/sysfs.c   |3 +++
>  drivers/idle/intel_idle.c |   11 +++
>  include/linux/cpuidle.h   |2 ++
>  10 files changed, 58 insertions(+), 21 deletions(-)

For the davinci & OMAP changes,

Acked-by: Kevin Hilman 


> diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
> index 1cfeac1..6cdeb42 100644
> --- a/arch/arm/mach-at91/cpuidle.c
> +++ b/arch/arm/mach-at91/cpuidle.c
> @@ -73,16 +73,20 @@ static int at91_init_cpuidle(void)
>   device->states[0].exit_latency = 1;
>   device->states[0].target_residency = 1;
>   device->states[0].flags = CPUIDLE_FLAG_TIME_VALID;
> - strcpy(device->states[0].name, "WFI");
> - strcpy(device->states[0].desc, "Wait for interrupt");
> + snprintf(device->states[0].name, CPUIDLE_NAME_LEN, "WFI");
> + snprintf(device->states[0].desc, CPUIDLE_DESC_LEN,
> +  "Wait for interrupt");
> + snprintf(device->states[0].abbr, CPUIDLE_ABBR_LEN, "W");
>  
>   /* Wait for interrupt and RAM self refresh state */
>   device->states[1].enter = at91_enter_idle;
>   device->states[1].exit_latency = 10;
>   device->states[1].target_residency = 1;
>   device->states[1].flags = CPUIDLE_FLAG_TIME_VALID;
> - strcpy(device->states[1].name, "RAM_SR");
> - strcpy(device->states[1].desc, "WFI and RAM Self Refresh");
> + snprintf(device->states[1].name, CPUIDLE_NAME_LEN, "RAM SR");
> + snprintf(device->states[1].desc, CPUIDLE_DESC_LEN,
> +  "WFI and RAM Self Refresh");
> + snprintf(device->states[1].abbr, CPUIDLE_ABBR_LEN, "WSR");
>  
>   if (cpuidle_register_device(device)) {
>   printk(KERN_ERR "at91_init_cpuidle: Failed registering\n");
> diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
> index bd59f31..42ad2d6 100644
> --- a/arch/arm/mach-davinci/cpuidle.c
> +++ b/arch/arm/mach-davinci/cpuidle.c
> @@ -127,16 +127,21 @@ static int __init davinci_cpuidle_probe(struct 
> platform_device *pdev)
>   device->states[0].exit_latency = 1;
>   device->states[0].target_residency = 1;
>   device->states[0].flags = CPUIDLE_FLAG_TIME_VALID;
> - strcpy(device->states[0].name, "WFI");
> - strcpy(device->states[0].desc, "Wait for interrupt");
> + snprintf(device->states[0].name, CPUIDLE_NAME_LEN, "WFI");
> + snprintf(device->states[0].desc, CPUIDLE_DESC_LEN,
> +  "Wait for interrupt");
> + snprintf(device->states[0].abbr, CPUIDLE_ABBR_LEN, "W");
>  
>   /* Wait for interrupt and DDR self refresh state */
>   device->states[1].enter = davinci_enter_idle;
>   device->states[1].exit_latency = 10;
>   device->states[1].target_residency = 1;
>   device->states[1].flags = CPUIDLE_FLAG_TIME_VALID;
> - strcpy(device->states[1].name, "DDR SR");
> - strcpy(device->states[1].desc, "WFI and DDR Self Refresh");
> + snprintf(device->states[1].name, CPUIDLE_NAME_LEN, "RAM SR");
> + snprintf(device->states[1].desc, CPUIDLE_DESC_LEN,
> +  "WFI and RAM Self Refresh");
> + snprintf(device->states[1].abbr, CPUIDLE_ABBR_LEN, "WSR");
> +
>   if (pdata->ddr2_pdown)
>   davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
>   cpuidle_set_statedata(&device->states[1], &davinci_states[1]);
> diff --git a/arch/arm/mach-kirkwood/cpuidle.c 
> b/arch/arm/mach-kirkwood/cpuidle.c
> index f68d33f..48eaabb 100644
> --- a/arch/arm/mach-kirkwood/cpuidle.c
> +++ b/arch/arm/mach-kirkwood/cpuidle.c
> @@ -75,16 +75,20 @@ static int kirkwood_init_cpuidle(void)
>   device->states[0].exit_latency = 1;
>   device->states[0].target_residency = 1;
>   device->states[0].flags = CPUIDLE_FLAG_TIME_VALID;
> -   

RE: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'

[Santosh Shilimkar]

> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Saturday, January 08, 2011 2:44 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; linux-arm-
> ker...@lists.infradead.org; Paul Walmsley
> Subject: Re: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix
> for undefined reference to 'omap2_prm_read_mod_reg'
>
> Santosh Shilimkar  writes:
>
> [...]
>
> >> I think it would be best to use WARN() on these, rather than
> >> WARN_ONCE().  That's because these could be called from different
> >> parts of the code base, and the stack backtrace will help someone
> >> figure out all the code that needs to be fixed.
> >>
> >> Once you do that, this patch is
> >>
> >> Acked-by: Paul Walmsley 
> >>
>
> > With WARN() instead of WARN_ONCE() and Paul's ack, here
> > is an updated patch.
>
> Thanks, will queue for .38-rc cycle.
>
> I'll again plead for working on your git-send-email setup.  It looks
> like your using outlook.  The inline patch is wrapped (as outlook
> almost
> always does.)  The attached version applied fine, but the strong
> preference is for a single inline patch.
>
Its google mail now a days. I thought it will wrap and
hence attached the version.

Fully agree with inline patch but as this one was minor
update I skipped it.

Regards
Santosh
--
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/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'

[Kevin Hilman]

Santosh Shilimkar  writes:

[...] 

>> I think it would be best to use WARN() on these, rather than
>> WARN_ONCE().  That's because these could be called from different
>> parts of the code base, and the stack backtrace will help someone
>> figure out all the code that needs to be fixed.
>>
>> Once you do that, this patch is
>>
>> Acked-by: Paul Walmsley 
>>

> With WARN() instead of WARN_ONCE() and Paul's ack, here
> is an updated patch.

Thanks, will queue for .38-rc cycle.

I'll again plead for working on your git-send-email setup.  It looks
like your using outlook.  The inline patch is wrapped (as outlook almost
always does.)  The attached version applied fine, but the strong
preference is for a single inline patch.  

Thanks,

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

Re: [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask

[Kevin Hilman]

Rajendra Nayak  writes:

[...]

> Just another trivial fix.
>
> From bb46b74d2b0ab3d35e72b760da7e123a891e6813 Mon Sep 17 00:00:00 2001
> From: Rajendra Nayak 
> Date: Fri, 7 Jan 2011 14:07:25 +0530
> Subject: [PATCH] OMAP: powerdomain: remove unused func declaration
>
> Trivial fix to remove the unused function declaration
> from the powerdomain header.
>
> Signed-off-by: Rajendra Nayak 
> ---
>  arch/arm/mach-omap2/powerdomain.h |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/powerdomain.h
> b/arch/arm/mach-omap2/powerdomain.h
> index c66431e..0b7a357 100644
> --- a/arch/arm/mach-omap2/powerdomain.h
> +++ b/arch/arm/mach-omap2/powerdomain.h
> @@ -165,7 +165,6 @@ struct pwrdm_ops {
>   int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
>  };
>
> -void pwrdm_fw_init(void);
>  void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_ops
> *custom_funcs);

Note this is line-wrapped. 

Looks like you need to get get-send-email setup so you can avoid having
the patch sending problems.

>
>  struct powerdomain *pwrdm_lookup(const char *name);

In any case, with Paul's ack, I can queue this with the others.

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

Re: 4430SDP boot failure - solved + SPI bug fix

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 09:25:11AM -0800, Tony Lindgren wrote:
> * Grant Likely  [110107 09:18]:
> > On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote:
> > > Grant,
> > > 
> > > Care to queue or ack the following fix?
> > 
> > If you bounce the patch to me, then I'll pick it up into the spi tree
> > and send it on to Linus right away.  (It didn't get sent to either me
> > or the spi list, so I don't have the original).
> 
> Thanks, bounced it to you.

As noted in the original patch, someone who understands this driver should
fix the other exit paths so buffers aren't left mapped when they shouldn't
be.
--
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: 4430SDP boot failure - solved + SPI bug fix

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 03:49:20PM +, Russell King - ARM Linux wrote:
> And, with one ARM errata disabled, the kernel finally boots.  So the
> "X-Loader hangs" message means that we did something that non-secure
> mode prevented us from doing.

Here's the dmesg with as many things as I could find enabled.

Linux version 2.6.37+ (r...@rmk-pc) (gcc version 4.3.5 (GCC) ) #67 SMP PREEMPT 
Fri Jan 7 19:38:30 GMT 2011
CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: OMAP4430 4430SDP board
vmalloc area is too big, limiting to 864MB
Memory policy: ECC disabled, Data cache writealloc
OMAP4430 ES1.0
SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000
FIXME: omap44xx_sram_init not implemented
On node 0 totalpages: 131072
free_area_init_node: node 0, pgdat c035f540, node_mem_map c0381000
  Normal zone: 64 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 8128 pages, LIFO batch:0
  HighMem zone: 960 pages used for memmap
  HighMem zone: 121920 pages, LIFO batch:31
PERCPU: Embedded 7 pages/cpu @c0786000 s4192 r8192 d16288 u32768
pcpu-alloc: s4192 r8192 d16288 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
Kernel command line: root=/dev/mmcblk0p2 ip=dhcp rw mem=512M vmalloc=1G 
console=ttyO2,115200n8 rootdelay=2
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 512MB = 512MB total
Memory: 516492k/516492k available, 7796k reserved, 491520K highmem
Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
DMA : 0xffc0 - 0xffe0   (   2 MB)
vmalloc : 0xc280 - 0xf800   ( 856 MB)
lowmem  : 0xc000 - 0xc200   (  32 MB)
pkmap   : 0xbfe0 - 0xc000   (   2 MB)
modules : 0xbf00 - 0xbfe0   (  14 MB)
  .init : 0xc0008000 - 0xc002f000   ( 156 kB)
  .text : 0xc002f000 - 0xc0334000   (3092 kB)
  .data : 0xc0334000 - 0xc035ff00   ( 176 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Preemptable hierarchical RCU implementation.
RCU-based detection of stalled CPUs is disabled.
Verbose stalled-CPUs detection is disabled.
NR_IRQS:402
powerdomain: waited too long for powerdomain dss_pwrdm to complete transition
[ cut here ]
WARNING: at arch/arm/mach-omap2/clockdomain.c:868 
omap2_clkdm_deny_idle+0x58/0xcc()
clockdomain: OMAP4 wakeup/sleep dependency support is not yet implemented
Modules linked in:
Backtrace: 
[] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c)
 r7:c0335f30 r6:c004a7f0 r5:c02f6189 r4:0364
[] (dump_stack+0x0/0x1c) from [] 
(warn_slowpath_common+0x58/0x70)
[] (warn_slowpath_common+0x0/0x70) from [] 
(warn_slowpath_fmt+0x38/0x40)
 r8:c0347860 r7:c03464c4 r6:0060 r5:c0346f4c r4:c036032c
[] (warn_slowpath_fmt+0x0/0x40) from [] 
(omap2_clkdm_deny_idle+0x58/0xcc)
 r3: r2:c02f61c7
[] (omap2_clkdm_deny_idle+0x0/0xcc) from [] 
(clkdm_init+0x144/0x17c)
 r5:c0347860 r4:c0346f4c
[] (clkdm_init+0x0/0x17c) from [] 
(omap2_init_common_hw+0x20/0xa0)
[] (omap2_init_common_hw+0x0/0xa0) from [] 
(omap_4430sdp_init_irq+0x34/0x54)
[] (omap_4430sdp_init_irq+0x0/0x54) from [] 
(init_IRQ+0x1c/0x24)
 r4:c035ff00
[] (init_IRQ+0x0/0x24) from [] (start_kernel+0x18c/0x2fc)
[] (start_kernel+0x0/0x2fc) from [<80008038>] (0x80008038)
 r7:c0345cb4 r6:c0029120 r5:c0342bf0 r4:10c53c7d
---[ end trace 1b75b31a2719ed1c ]---
omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
GPMC revision 6.0
OMAP GPIO hardware version 0.1
OMAP clockevent source: GPTIMER1 at 32768 Hz
Console: colour dummy device 80x30
Calibrating delay loop... 2013.49 BogoMIPS (lpj=7864320)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
L310 cache controller enabled
l2x0: 16 ways, CACHE_ID 0x41c2, AUX_CTRL 0x0e05, Cache size: 524288 B
CPU1: Booted secondary processor
CPU1: Unknown IPI message 0x1
Brought up 2 CPUs
SMP: Total of 2 processors activated (4026.98 BogoMIPS).
regulator: core version 0.5
regulator: dummy: 
NET: Registered protocol family 16
OMAP DMA hardware revision 0.0
sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
bio: create slab  at 0
i2c_omap i2c_omap.1: bus 1 rev4.0 at 400 kHz
Skipping twl internal clock init and using bootloader value (unknown osc rate)
twl6030: PIH (irq 39) chaining IRQs 368..387
regulator: VMMC: 1200 <--> 3000 mV at 3000 mV normal standby
regulator: VPP: 1800 <--> 2500 mV at 1900 mV normal standby
regulator: VUSIM: 1200 <--> 2900 mV at 1800 mV normal standby
regulator: VANA: 2100 mV normal standby
regulator: VCXIO: 1800 mV normal standby
regulator: VDAC: 1800 mV normal standby
regulator: VUSB: 

Re: [RFC] omap3: Enable SmartReflex calculations for 720MHz

[Nishanth Menon]

Sanjeev Premi had written, on 01/07/2011 11:26 AM, the following:

The eFuse registers do not contain the nValue to be used
with 720MHz (OPP6). This patch implements procedure to
calculate the nValue(OPP6) based on the nValue(OPP5).

  [1] SPRUFF1D-June 2009 section 1.5.2.1.1

Where is this doc?
http://focus-webapps.ti.com/general/docs/sitesearch/searchsite.tsp;jsessionid=TKKPEXXTMNJCPQC1JAWBVQQ?selectedTopic=1653260327&numRecords=25&searchTerm=SPRUFF1D&statusCode=null

Google seems to point to:
http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
but ti.com responds with document not found.




This is first attempt to fit this mechanism into new
smartreflex framework. Do note a FIXME which is added
to illustrate the calculations; and express need for
a mechanism to get nValues for each OPP.

Signed-off-by: Sanjeev Premi 
---
 arch/arm/mach-omap2/sr_device.c   |   54 +
 arch/arm/mach-omap2/voltage.c |1 +
 arch/arm/plat-omap/include/plat/voltage.h |1 +
 3 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 786d685..43640a3 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -38,6 +38,51 @@ static struct omap_device_pm_latency omap_sr_latency[] = {
},
 };
 
+static void swcalc_opp6_RG(u32 rFuse, u32 gainFuse, u32 deltaNT,

+   u32* rAdj, u32* gainAdj)
+{
+   u32 nAdj;
+   u32 g, r;
+
+   nAdj = ((1 << (gainFuse + 8))/rFuse) + deltaNT;
+
+   for (g = 0; g < GAIN_MAXLIMIT; g++) {
+   r = (1 << (g + 8)) / nAdj;
+   if (r < 256) {
+   *rAdj = r;
+   *gainAdj = g;
+   }
+   }
+}
+
+#define SWCALC_OPP6_DELTA_NNT  379
+#define SWCALC_OPP6_DELTA_PNT  227
+#define GAIN_MAXLIMIT  16


Magic numbers - do they scale from 3430 to 3630?


+
+static u32 swcalc_opp6_nvalue(u32 opp5_nvalue)

so what does this actually do?

+{
+   u32 opp6_nvalue;
+   u32 opp5_senPgain, opp5_senNgain, opp5_senPRN, opp5_senNRN;
+   u32 opp6_senPgain, opp6_senNgain, opp6_senPRN, opp6_senNRN;
+
+   opp5_senPgain = (opp5_nvalue & 0x00f0) >> 0x14;
+   opp5_senNgain = (opp5_nvalue & 0x000f) >> 0x10;
+
+   opp5_senPRN = (opp5_nvalue & 0xff00) >> 0x8;
+   opp5_senNRN = (opp5_nvalue & 0x00ff);
+
+   swcalc_opp6_RG(opp5_senNRN, opp5_senNgain, SWCALC_OPP6_DELTA_NNT,
+   &opp6_senNRN, &opp6_senNgain);
+
+   swcalc_opp6_RG(opp5_senPRN, opp5_senPgain, SWCALC_OPP6_DELTA_PNT,
+   &opp6_senPRN, &opp6_senPgain);
+
+   opp6_nvalue = (opp6_senPgain << 0x14) | (opp6_senNgain < 0x10) |
+   (opp6_senPRN << 0x8) | opp6_senNRN;
+
+   return opp6_nvalue;
+}
+
 /* Read EFUSE values from control registers for OMAP3430 */
 static void __init sr_set_nvalues(struct omap_volt_data *volt_data,
struct omap_sr_data *sr_data)
@@ -72,6 +117,15 @@ static void __init sr_set_nvalues(struct omap_volt_data 
*volt_data,
nvalue_table[i].nvalue = v;
}
 
+	/*

+* FIXME: This is a temporary hack. Need to identify better
+*mechanism to find nvalues corresponding to an OPP.
+*/
+   if (cpu_is_omap34xx() && omap3_has_720mhz()) {
+   nvalue_table[count-1].nvalue = swcalc_opp6_nvalue(
+   nvalue_table[count-2].nvalue);
+   }
+

Sorry, Dumb question:
a) You are using OPP5's nTarget to use in OPP6's nTarget? is'nt it fused 
in for OPP6 offset?

b) you are using OMAP343X_CONTROL_FUSE_OPP5_VDD1 itself
c) these should be __init functions.
d) how would you allow this code to work with 3440?
e) next time could you please try STOP using CaMELCASInG in your 
variables and functions?
f) please add sufficient documentation in kernel-doc style to allow us 
to understand the story below?

g) dont use magic numbers
h) please take care of ROUND_DOWN and ROUND_UP and truncation errors
i) is this equation ONLY valid for opp5 ntarget modification on 
OMAP3530? or valid for 3440 as well? or valid for any OPP ntarget 
modification?



sr_data->nvalue_table = nvalue_table;
sr_data->nvalue_count = count;
 }
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index ed6079c..f23b6d7 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -258,6 +258,7 @@ static struct omap_volt_data omap34xx_vddmpu_volt_data[] = {
VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 
OMAP343X_CONTROL_FUSE_OPP3_VDD1, 0xf9, 0x18),
VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP4_UV, 
OMAP343X_CONTROL_FUSE_OPP4_VDD1, 0xf9, 0x18),
VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP5_UV, 
OMAP343X_CONTROL_FUSE_OPP5_VDD1, 0xf9, 0x18),
+   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP6_UV, 
OMAP343X_CONTROL_FUSE

RE: 4430SDP boot failure - solved + SPI bug fix

[Santosh Shilimkar]

> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Saturday, January 08, 2011 12:50 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Sat, Jan 08, 2011 at 12:35:38AM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > Sent: Saturday, January 08, 2011 12:23 AM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure - solved + SPI bug fix
> > >
> > > On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar
> wrote:
> > > > > And, with one ARM errata disabled, the kernel finally boots.
> So
> > > the
> > > > > "X-Loader hangs" message means that we did something that
> non-
> > > secure
> > > > > mode prevented us from doing.
> > > > >
> > > > Actually it's not. The error message is quite misleading.
> > > Basically in
> > > > x-loader exception handlers are setup and all these handlers
> > > report
> > > > same message ("X-Loader hangs"). This should be fixed so that
> it
> > > can
> > > > report more meaningful info like data abort, prefetch abort
> etc.
> > > >
> > > > Till the vector relocation in the kernel exceptions are not
> set up
> > > > so code jumps to already installed exceptions in the x-loader
> and
> > > > hence the messege.
> > >
> > > I disagree with your "actually it's not".  It was errata 742230,
> > > which
> > > requires access to the CP15, c15, c0, 1 register (a diagnostic
> > > register)
> > > which I bet provokes an undefined instruction trap from non-
> secure
> > > mode.
> > >
> > 742230 errata workaround is not implemented in the x-loader so I
> > can surely say it's not the secure violation.
>
> Precisely.  So when we directly read, modify and write this
> diagnostic
> register in the non-secure world during kernel boot, we end up
> faulting.
> Comment those instructions out, we don't get a fault, and the kernel
> boots normally.

I understand now. Was confused last time.

So your custom build did have this errata
CONFIG_ARM_ERRATA_742230 where there is an access
to diagnostic register which is not accessible on OMAP4
from non-secure side.

Thanks for clarification.

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

Re: linux-next: manual merge of the usb tree with the omap tree

[Felipe Balbi]

On Sat, Jan 08, 2011 at 12:24:24AM +0530, Gadiyar, Anand wrote:
> On Fri, Jan 7, 2011 at 8:50 PM, Anand Gadiyar  wrote:
> > Update: I disabled CONFIG_OMAP_RESET_CLOCKS and the PHY and other
> > connected devices enumerate just fine. Could you try this out on
> > your board as well?
> >
> > I'll look deeper and see if there are some required clocks that are
> > accidentally getting turned off.
> >
> 
> A final update from today: It appears that disabling auxclk3_ck causes
> EHCI to fail. I'm not sure what this clock feeds, and will need to look it
> up. Keeping this clock alive is sufficient to get the hub to enumerate.
> 
> I would've looked it up, but got booted out by a fire alarm drill. I'll
> take a look tomorrow and cook up a fix.

Good finding :-) Thanks a lot :-)

-- 
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: Latest config warning

[Felipe Balbi]

Hi,

On Fri, Jan 07, 2011 at 11:13:40PM +0530, Premi, Sanjeev wrote:
> > * Russell King - ARM Linux  [110107 03:34]:
> > > warning: (ARCH_STMP3XXX &&  || ARCH_OMAP3 && 
> > ARCH_OMAP2PLUS) selects USB_ARCH_HAS_EHCI which has unmet 
> > direct dependencies (USB_SUPPORT)
> > > 
> > > This didn't happen with 2.6.37.  Maybe a missing select USB_SUPPORT
> > > somewhere?
> > 
> 
> I had come across this while building the "minimal kernel" for omap3evm.
> Here is my local patch:
> 
> >From bd4efa15ec96116b359d18913c91bcbb45b46ee1 Mon Sep 17 00:00:00 2001
> From: Sanjeev Premi 
> Date: Tue, 4 Jan 2011 18:37:39 +0530
> Subject: [PATCH] omap3: fix Kconfig dependency on USB_SUPPORT
> 
> This patch fixes the following warning due to unmet dependency:
> 
> warning: (ARCH_STMP3XXX &&  || ARCH_OMAP3 && ARCH_OMAP
> 2PLUS) selects USB_ARCH_HAS_EHCI which has unmet direct depend
> encies (USB_SUPPORT)
> 
> Signed-off-by: Sanjeev Premi 
> ---
>  arch/arm/mach-omap2/Kconfig |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 310b759..3d67b9b 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -33,7 +33,7 @@ config ARCH_OMAP3
>   depends on ARCH_OMAP2PLUS
>   default y
>   select CPU_V7
> - select USB_ARCH_HAS_EHCI
> + select USB_ARCH_HAS_EHCI if USB_SUPPORT
>   select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
>   select ARCH_HAS_OPP if PM
>   select PM_OPP if PM
> -- 
> 1.7.2.2
> 
> If this is a real solution, I can submit it as formal patch

This is one way to do it, but I believe the real fix would be to change
drivers/usb/Kconfig to something like:

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 5a7c8f1..558cf4d 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -10,8 +10,6 @@ menuconfig USB_SUPPORT
  This option adds core support for Universal Serial Bus (USB).
  You will also need drivers from the following menu to make use of it.
 
-if USB_SUPPORT
-
 # Host-side USB depends on having a host controller
 # NOTE:  dummy_hcd is always an option, but it's ignored here ...
 # NOTE:  SL-811 option should be board-specific ...
@@ -70,6 +68,8 @@ config USB_ARCH_HAS_EHCI
default y if ARCH_CNS3XXX
default PCI
 
+if USB_SUPPORT
+
 # ARM SA chips have a non-PCI based "OHCI-compatible" USB host interface.
 config USB
tristate "Support for Host-side USB"

The idea is that ARCHs can select USB_ARCH_HAS_* without having to
enable USB_SUPPORT. Currently, there's a big mess of conditional default
values on all USB_ARCH_HAS_* entries:

config USB_ARCH_HAS_EHCI
boolean
default y if PPC_83xx
default y if PPC_MPC512x
default y if SOC_AU1200
default y if ARCH_IXP4XX
default y if ARCH_W90X900
default y if ARCH_AT91SAM9G45
default y if ARCH_MXC
default y if ARCH_OMAP3
default y if ARCH_CNS3XXX
default PCI

IMHO it's much better to have something like:

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 5a7c8f1..ac137d1 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -10,8 +10,6 @@ menuconfig USB_SUPPORT
  This option adds core support for Universal Serial Bus (USB).
  You will also need drivers from the following menu to make use of it.
 
-if USB_SUPPORT
-
 # Host-side USB depends on having a host controller
 # NOTE:  dummy_hcd is always an option, but it's ignored here ...
 # NOTE:  SL-811 option should be board-specific ...
@@ -59,16 +57,9 @@ config USB_ARCH_HAS_OHCI
 # some non-PCI hcds implement EHCI
 config USB_ARCH_HAS_EHCI
boolean
-   default y if PPC_83xx
-   default y if PPC_MPC512x
-   default y if SOC_AU1200
-   default y if ARCH_IXP4XX
-   default y if ARCH_W90X900
-   default y if ARCH_AT91SAM9G45
-   default y if ARCH_MXC
-   default y if ARCH_OMAP3
-   default y if ARCH_CNS3XXX
-   default PCI
+   default n
+
+if USB_SUPPORT
 
 # ARM SA chips have a non-PCI based "OHCI-compatible" USB host interface.
 config USB

and expect ARCH Kconfigs to select the features they have.

Greg, what do you think ?

-- 
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: 4430SDP boot failure - solved + SPI bug fix

[Russell King - ARM Linux]

On Sat, Jan 08, 2011 at 12:35:38AM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Saturday, January 08, 2011 12:23 AM
> > To: Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: Re: 4430SDP boot failure - solved + SPI bug fix
> >
> > On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > > > And, with one ARM errata disabled, the kernel finally boots.  So
> > the
> > > > "X-Loader hangs" message means that we did something that non-
> > secure
> > > > mode prevented us from doing.
> > > >
> > > Actually it's not. The error message is quite misleading.
> > Basically in
> > > x-loader exception handlers are setup and all these handlers
> > report
> > > same message ("X-Loader hangs"). This should be fixed so that it
> > can
> > > report more meaningful info like data abort, prefetch abort etc.
> > >
> > > Till the vector relocation in the kernel exceptions are not set up
> > > so code jumps to already installed exceptions in the x-loader and
> > > hence the messege.
> >
> > I disagree with your "actually it's not".  It was errata 742230,
> > which
> > requires access to the CP15, c15, c0, 1 register (a diagnostic
> > register)
> > which I bet provokes an undefined instruction trap from non-secure
> > mode.
> >
> 742230 errata workaround is not implemented in the x-loader so I
> can surely say it's not the secure violation.

Precisely.  So when we directly read, modify and write this diagnostic
register in the non-secure world during kernel boot, we end up faulting.
Comment those instructions out, we don't get a fault, and the kernel
boots normally.
--
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: [RFT/PATCH 05/10] cbus: retu: move to threaded IRQ and GENIRQ

[Felipe Balbi]

On Fri, Jan 07, 2011 at 09:04:55AM -0800, Tony Lindgren wrote:
> * Felipe Balbi  [110106 23:47]:
> > 
> > The main point of using Sparse IRQ numbering is exactly avoiding
> > pre-processor branches. Instead of defining ranges only when a device is
> > compile, we can always keep the range allocated no matter if the device
> > probes or not. So, I suggest dropping the ifdeffery on  and
> > move that to something like below:
> 
> This is fine as long as we we don't run out of allocated IRQs before
> switching over to sparse IRQ. The original reason for the ifdeffery
> was to keep NR_IRQS below 256 when possible as it optimizes the interrupt
> handling in that case. See NR_IRQS in arch/arm/include/asm/hardirq.h
> for more info.

I've sent patches (you're in Cc) enabling SPARSE_IRQ on OMAP. I boot
tested on panda and overo and it was working fine.

-- 
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: 4430SDP boot failure - solved + SPI bug fix

[Santosh Shilimkar]

> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Saturday, January 08, 2011 12:23 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > > And, with one ARM errata disabled, the kernel finally boots.  So
> the
> > > "X-Loader hangs" message means that we did something that non-
> secure
> > > mode prevented us from doing.
> > >
> > Actually it's not. The error message is quite misleading.
> Basically in
> > x-loader exception handlers are setup and all these handlers
> report
> > same message ("X-Loader hangs"). This should be fixed so that it
> can
> > report more meaningful info like data abort, prefetch abort etc.
> >
> > Till the vector relocation in the kernel exceptions are not set up
> > so code jumps to already installed exceptions in the x-loader and
> > hence the messege.
>
> I disagree with your "actually it's not".  It was errata 742230,
> which
> requires access to the CP15, c15, c0, 1 register (a diagnostic
> register)
> which I bet provokes an undefined instruction trap from non-secure
> mode.
>
742230 errata workaround is not implemented in the x-loader so I
can surely say it's not the secure violation.

He is the x-loader source tree.
http://dev.omapzoom.org/?p=bootloader/x-loader.git;a=shortlog;h=refs/heads
/omap4_dev

Even simple things like if DDR is not configured correctly or not
Stable, code/data access takes abort which lands up in the "X-loader
hang messege"

> Hence, the reason it vectored to the X-loader was because we tried
> to
> do something in the non-secure mode which we're prevented from
> doing.
My suspect was clock configurations on the older boot loaders were
Incomplete that might have lead to issue since now more drivers are
getting enabled in newer kernels.
--
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: 4430SDP boot failure

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 11:59:07PM +0530, Santosh Shilimkar wrote:
> > ks8851 spi1.0: message enable is 0
> > ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194
> > IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144
> > IP-Config: Complete:
> >  device=eth0, addr=192.168.0.144, mask=255.255.255.0,
> > gw=192.168.0.1,
> >  host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none),
> >  bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
> >
> > but the board doesn't respond to that IP address.  Meanwhile the
> > DHCP
> > server shows:
> >
> > DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0
> >
> > in its log, and the ethernet address appears to be random for each
> > boot.
> > Obviously, as I can't log into the board via any means, it's nigh on
> > impossible to work out what's actually going on.
> 
> DHCP seems to work for me without any issues.

The board now has an ethernet address of 1E:89:8E:DA:80:7C - it
seems to be intentionally random which isn't particularly nice.
At least it's intentionally random and not some undefined region of
memory being poked in there...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: manual merge of the usb tree with the omap tree

[Gadiyar, Anand]

On Fri, Jan 7, 2011 at 8:50 PM, Anand Gadiyar  wrote:
> Update: I disabled CONFIG_OMAP_RESET_CLOCKS and the PHY and other
> connected devices enumerate just fine. Could you try this out on
> your board as well?
>
> I'll look deeper and see if there are some required clocks that are
> accidentally getting turned off.
>

A final update from today: It appears that disabling auxclk3_ck causes
EHCI to fail. I'm not sure what this clock feeds, and will need to look it
up. Keeping this clock alive is sufficient to get the hub to enumerate.

I would've looked it up, but got booted out by a fire alarm drill. I'll
take a look tomorrow and cook up a fix.

- Anand
--
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: 4430SDP boot failure - solved + SPI bug fix

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > And, with one ARM errata disabled, the kernel finally boots.  So the
> > "X-Loader hangs" message means that we did something that non-secure
> > mode prevented us from doing.
> >
> Actually it's not. The error message is quite misleading. Basically in
> x-loader exception handlers are setup and all these handlers report
> same message ("X-Loader hangs"). This should be fixed so that it can
> report more meaningful info like data abort, prefetch abort etc.
> 
> Till the vector relocation in the kernel exceptions are not set up
> so code jumps to already installed exceptions in the x-loader and
> hence the messege.

I disagree with your "actually it's not".  It was errata 742230, which
requires access to the CP15, c15, c0, 1 register (a diagnostic register)
which I bet provokes an undefined instruction trap from non-secure mode.

Hence, the reason it vectored to the X-loader was because we tried to
do something in the non-secure mode which we're prevented from doing.
--
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: 4430SDP boot failure

[Santosh Shilimkar]

> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Friday, January 07, 2011 9:54 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure
>
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > Sent: Friday, January 07, 2011 7:55 PM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure
> > >
> > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar
> wrote:
> > > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > > >
> > > > Low level debug as you reported seems to be broken though.
> > >
> > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely
> on
> > > the board - which should ease the debugging problem as it no
> longer
> > > requires anything but the reset button pressed to test a new
> kernel.
> >
> > Glad to hear that.
>
> Right, next couple of problems.
>
> udev isn't creating the ttyO* nodes for whatever reason on my fs -
> does
> anyone know what device major/minor numbers these end up with?  It
> seems
> they're dynamically assigned.
>
Right now don't have access to my board so can't check this.

> There's also something fishy going on with networking (if I
> configure
> PNP IP, I get an IP:
>
> ks8851 spi1.0: message enable is 0
> ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194
> IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144
> IP-Config: Complete:
>  device=eth0, addr=192.168.0.144, mask=255.255.255.0,
> gw=192.168.0.1,
>  host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none),
>  bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
>
> but the board doesn't respond to that IP address.  Meanwhile the
> DHCP
> server shows:
>
>   DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0
>
> in its log, and the ethernet address appears to be random for each
> boot.
> Obviously, as I can't log into the board via any means, it's nigh on
> impossible to work out what's actually going on.

DHCP seems to work for me without any issues.
--
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: 4430SDP boot failure - solved + SPI bug fix

[Santosh Shilimkar]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Friday, January 07, 2011 9:19 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > Sent: Friday, January 07, 2011 7:55 PM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure
> > >
> > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar
> wrote:
> > > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > > >
> > > > Low level debug as you reported seems to be broken though.
> > >
> > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely
> on
> > > the board - which should ease the debugging problem as it no
> longer
> > > requires anything but the reset button pressed to test a new
> kernel.
> >
> > Glad to hear that.
>
> And, with one ARM errata disabled, the kernel finally boots.  So the
> "X-Loader hangs" message means that we did something that non-secure
> mode prevented us from doing.
>
Actually it's not. The error message is quite misleading. Basically in
x-loader exception handlers are setup and all these handlers report
same message ("X-Loader hangs"). This should be fixed so that it can
report more meaningful info like data abort, prefetch abort etc.

Till the vector relocation in the kernel exceptions are not set up
so code jumps to already installed exceptions in the x-loader and
hence the messege.

> It would be a good idea if X-loader could tell dump out the
> exception,
> register dump, and for data/prefetch aborts, the relevent FSR and
> FAR
> registers - that would make debugging this kind of failure a lot
> easier.
>
Yes. At least it should report data/prefect aborts.

> =
> Subject: Fix DMA API usage in OMAP MCSPI driver
>
> Running the latest kernel on the 4430SDP board with DMA API
> debugging
> enabled results in this:
>
> WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
> NULL NULL: DMA-API: device driver tries to free DMA memory it has
> not allocated
> [device address=0x8129901a] [size=260 bytes]
> Modules linked in:
> Backtrace:
> [] (dump_backtrace+0x0/0x10c) from []
> (dump_stack+0x18/0x1c)
>  r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
> [] (dump_stack+0x0/0x1c) from []
> (warn_slowpath_common+0x58/0x70)
> [] (warn_slowpath_common+0x0/0x70) from []
> (warn_slowpath_fmt+0x38/0x40)
>  r8:c1839e40 r7: r6:0104 r5: r4:8129901a
> [] (warn_slowpath_fmt+0x0/0x40) from []
> (check_unmap+0x19c/0x6f0)
>  r3:c03110de r2:c0304e6b
> [] (check_unmap+0x0/0x6f0) from []
> (debug_dma_unmap_page+0x74/0x80)
> [] (debug_dma_unmap_page+0x0/0x80) from []
> (omap2_mcspi_work+0x514/0xbf0)
> [] (omap2_mcspi_work+0x0/0xbf0) from []
> (process_one_work+0x294/0x400)
> [] (process_one_work+0x0/0x400) from []
> (worker_thread+0x220/0x3f8)
> [] (worker_thread+0x0/0x3f8) from []
> (kthread+0x88/0x90)
> [] (kthread+0x0/0x90) from []
> (do_exit+0x0/0x5fc)
>  r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
> ---[ end trace 1b75b31a2719ed20 ]---
>
> I've no idea why this driver uses NULL for dma_unmap_single instead
> of
> the &spi->dev that is laying around just waiting to be used in that
> function - but it's an easy fix.
>
> Also replace this comment with a FIXME comment:
> /* Do DMA mapping "early" for better error reporting
> and
>  * dcache use.  Note that if dma_unmap_single() ever
> starts
>  * to do real work on ARM, we'd need to clean up
> mappings
>  * for previous transfers on *ALL* exits of this
> loop...
>  */
> as the comment is not true - we do work in dma_unmap() functions,
> particularly on ARMv6 and above.  I've corrected the existing unmap
> functions but if any others are required they must be added ASAP.
>
> Signed-off-by: Russell King 

Thanks for fixing it
> ---
> I'm surprised this driver got merged as it has such a comment, and
> is
> abusing the DMA API... well, at least with the DMA API debugging we
> can now catch this stuff.
>
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> index 951a160..abb1ffb 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi,
> struct spi_transfer *xfer)
>
>   if (tx != NULL) {
>   wait_for_completion(&mcspi_dma->dma_tx_completion);
> - dma_unmap_single(NULL, xfer->tx_dma, count,
> DMA_TO_DEVICE);
> + dma_unmap_single(&spi->dev, xfer->tx_dma, count,
> DMA_TO_DEVICE);
>
>   /* for TX_ONLY mode, be sure

RE: Latest config warning

[Premi, Sanjeev]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Friday, January 07, 2011 10:18 PM
> To: Russell King - ARM Linux; Balbi, Felipe
> Cc: linux-omap@vger.kernel.org
> Subject: Re: Latest config warning
> 
> * Russell King - ARM Linux  [110107 03:34]:
> > warning: (ARCH_STMP3XXX &&  || ARCH_OMAP3 && 
> ARCH_OMAP2PLUS) selects USB_ARCH_HAS_EHCI which has unmet 
> direct dependencies (USB_SUPPORT)
> > 
> > This didn't happen with 2.6.37.  Maybe a missing select USB_SUPPORT
> > somewhere?
> 

I had come across this while building the "minimal kernel" for omap3evm.
Here is my local patch:

>From bd4efa15ec96116b359d18913c91bcbb45b46ee1 Mon Sep 17 00:00:00 2001
From: Sanjeev Premi 
Date: Tue, 4 Jan 2011 18:37:39 +0530
Subject: [PATCH] omap3: fix Kconfig dependency on USB_SUPPORT

This patch fixes the following warning due to unmet dependency:

warning: (ARCH_STMP3XXX &&  || ARCH_OMAP3 && ARCH_OMAP
2PLUS) selects USB_ARCH_HAS_EHCI which has unmet direct depend
encies (USB_SUPPORT)

Signed-off-by: Sanjeev Premi 
---
 arch/arm/mach-omap2/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 310b759..3d67b9b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -33,7 +33,7 @@ config ARCH_OMAP3
depends on ARCH_OMAP2PLUS
default y
select CPU_V7
-   select USB_ARCH_HAS_EHCI
+   select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
select ARCH_HAS_OPP if PM
select PM_OPP if PM
-- 
1.7.2.2

If this is a real solution, I can submit it as formal patch

~sanjeev

> Felipe, care to take a look at this one?
> 
> 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
> --
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: Add basic support for 720MHz part

[Premi, Sanjeev]

> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com] 
> Sent: Friday, January 07, 2011 10:18 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH] omap3: Add basic support for 720MHz part
> 
> Sanjeev Premi  writes:
> 
> > This patch adds support for new speed enhanced parts with ARM
> > and IVA running at 720MHz and 520MHz respectively. These parts
> > can be probed at run-time by reading PRODID.SKUID[3:0] at
> > 0x4830A20C [1].
> 
> Please expand this a little to describe exactly which parts have this
> feature.  All OMAP3?  34xx? 35xx? what about 36xx/37xx?  ISTR the
> runtime probing for this feature is available on 35xx but not on 34xx,
> but a summary of this should be here.
> 

[sp] Will update...

[snip]...[snip]

> nit: Unrelated to this patch, but OMAP3EVM ethernet is still 
> broken due to
> missing GPIO configuration for the network reset.  This has 
> been broken
> since the GPIO hwmod merge and pointed out but nobody seems 
> to be fixing
> it.

[sp] It is currently in works.

[snip]...[snip] 

> > +   omap34xx_opp_def_list[INDEX_MPU_720MHZ]
> > +   .default_available = true;
> > +   omap34xx_opp_def_list[INDEX_IVA_720MHZ]
> > +   .default_available = true;
> > +   }
> > +
> 
> I'm with Nishanth here.  Please stick to the OPP API for 
> enabling OPPs.
> 
> First, it is future proof to internal table changes, but it 
> also sets a
> better precedent for others wanting to fiddle with OPPs.
> 

[sp] Okay. I will have to revert the a patch on my repo
 to to get there. Will send an update patch on MON.

> Thanks,
> 
> Kevin

[snip]...[snip] 
--
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

[RFC] omap3: Enable SmartReflex calculations for 720MHz

[Sanjeev Premi]

The eFuse registers do not contain the nValue to be used
with 720MHz (OPP6). This patch implements procedure to
calculate the nValue(OPP6) based on the nValue(OPP5).

  [1] SPRUFF1D-June 2009 section 1.5.2.1.1

This is first attempt to fit this mechanism into new
smartreflex framework. Do note a FIXME which is added
to illustrate the calculations; and express need for
a mechanism to get nValues for each OPP.

Signed-off-by: Sanjeev Premi 
---
 arch/arm/mach-omap2/sr_device.c   |   54 +
 arch/arm/mach-omap2/voltage.c |1 +
 arch/arm/plat-omap/include/plat/voltage.h |1 +
 3 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 786d685..43640a3 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -38,6 +38,51 @@ static struct omap_device_pm_latency omap_sr_latency[] = {
},
 };
 
+static void swcalc_opp6_RG(u32 rFuse, u32 gainFuse, u32 deltaNT,
+   u32* rAdj, u32* gainAdj)
+{
+   u32 nAdj;
+   u32 g, r;
+
+   nAdj = ((1 << (gainFuse + 8))/rFuse) + deltaNT;
+
+   for (g = 0; g < GAIN_MAXLIMIT; g++) {
+   r = (1 << (g + 8)) / nAdj;
+   if (r < 256) {
+   *rAdj = r;
+   *gainAdj = g;
+   }
+   }
+}
+
+#define SWCALC_OPP6_DELTA_NNT  379
+#define SWCALC_OPP6_DELTA_PNT  227
+#define GAIN_MAXLIMIT  16
+
+static u32 swcalc_opp6_nvalue(u32 opp5_nvalue)
+{
+   u32 opp6_nvalue;
+   u32 opp5_senPgain, opp5_senNgain, opp5_senPRN, opp5_senNRN;
+   u32 opp6_senPgain, opp6_senNgain, opp6_senPRN, opp6_senNRN;
+
+   opp5_senPgain = (opp5_nvalue & 0x00f0) >> 0x14;
+   opp5_senNgain = (opp5_nvalue & 0x000f) >> 0x10;
+
+   opp5_senPRN = (opp5_nvalue & 0xff00) >> 0x8;
+   opp5_senNRN = (opp5_nvalue & 0x00ff);
+
+   swcalc_opp6_RG(opp5_senNRN, opp5_senNgain, SWCALC_OPP6_DELTA_NNT,
+   &opp6_senNRN, &opp6_senNgain);
+
+   swcalc_opp6_RG(opp5_senPRN, opp5_senPgain, SWCALC_OPP6_DELTA_PNT,
+   &opp6_senPRN, &opp6_senPgain);
+
+   opp6_nvalue = (opp6_senPgain << 0x14) | (opp6_senNgain < 0x10) |
+   (opp6_senPRN << 0x8) | opp6_senNRN;
+
+   return opp6_nvalue;
+}
+
 /* Read EFUSE values from control registers for OMAP3430 */
 static void __init sr_set_nvalues(struct omap_volt_data *volt_data,
struct omap_sr_data *sr_data)
@@ -72,6 +117,15 @@ static void __init sr_set_nvalues(struct omap_volt_data 
*volt_data,
nvalue_table[i].nvalue = v;
}
 
+   /*
+* FIXME: This is a temporary hack. Need to identify better
+*mechanism to find nvalues corresponding to an OPP.
+*/
+   if (cpu_is_omap34xx() && omap3_has_720mhz()) {
+   nvalue_table[count-1].nvalue = swcalc_opp6_nvalue(
+   nvalue_table[count-2].nvalue);
+   }
+
sr_data->nvalue_table = nvalue_table;
sr_data->nvalue_count = count;
 }
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index ed6079c..f23b6d7 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -258,6 +258,7 @@ static struct omap_volt_data omap34xx_vddmpu_volt_data[] = {
VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP3_UV, 
OMAP343X_CONTROL_FUSE_OPP3_VDD1, 0xf9, 0x18),
VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP4_UV, 
OMAP343X_CONTROL_FUSE_OPP4_VDD1, 0xf9, 0x18),
VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP5_UV, 
OMAP343X_CONTROL_FUSE_OPP5_VDD1, 0xf9, 0x18),
+   VOLT_DATA_DEFINE(OMAP3430_VDD_MPU_OPP6_UV, 
OMAP343X_CONTROL_FUSE_OPP5_VDD1, 0xf9, 0x18),
VOLT_DATA_DEFINE(0, 0, 0, 0),
 };
 
diff --git a/arch/arm/plat-omap/include/plat/voltage.h 
b/arch/arm/plat-omap/include/plat/voltage.h
index 0ff1233..f3f87a6 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -31,6 +31,7 @@
 #define OMAP3430_VDD_MPU_OPP3_UV   120
 #define OMAP3430_VDD_MPU_OPP4_UV   127
 #define OMAP3430_VDD_MPU_OPP5_UV   135
+#define OMAP3430_VDD_MPU_OPP6_UV135
 
 #define OMAP3430_VDD_CORE_OPP1_UV  975000
 #define OMAP3430_VDD_CORE_OPP2_UV  105
-- 
1.7.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

Re: 4430SDP boot failure - solved + SPI bug fix

[Tony Lindgren]

* Grant Likely  [110107 09:18]:
> On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote:
> > Grant,
> > 
> > Care to queue or ack the following fix?
> 
> If you bounce the patch to me, then I'll pick it up into the spi tree
> and send it on to Linus right away.  (It didn't get sent to either me
> or the spi list, so I don't have the original).

Thanks, bounced it to you.

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: RFBI worked example

[Ben Tucker]

> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
> Sent: 07 January 2011 15:14
> To: ext Ben Tucker
> Cc: linux-omap@vger.kernel.org
> Subject: RE: RFBI worked example
>
> On Fri, 2011-01-07 at 14:18 +, ext Ben Tucker wrote:
> > With further experimentation it appears that I can call the
> > omap_rfbi_update() from the call back, but as the callback is in
> interrupt
> > context this could be dangerous. I would love to see an example of
> this
> > elsewhere.
>
> Did you get it working enough to get an image on the panel?

The panel in this case is under development so (it's actually an FPGA) so we
have some way to go before we have an image.

>
> It's been long since I've touched the rfbi code, and I honestly don't
> know the state of it, but basically it should work similarly as DSI
> command mode:

It appears to be working. As a test I tried using internal triggering with
my panel code (below). Pixel data appears to flow out of the port (the
RFBI_PIXEL_CNT register is decrementing).

>
> The panel driver issues an update when the user space has requested it
> via OMAPFB_UPDATE_WINDOW. So it's not meant to be triggered
> automatically.

OK, that helps my understanding.

>
> If you really want to update the display automatically (which you
> shouldn't, as the point with panels with their own framebuffer is to
> update only when necessary), you can do it either directly as you do,
> or
> via workqueue or thread.

The primary reason for using RFBI in this design is to allow the RFB to
control the H/VSync's and thus the delivery of pixel data. This is not the
traditional RFBI design.

I am concerned that a thread or workqueue may introduce an unacceptable
delay between FRAMEDONE and re-arming the DSS/RFBI for the next frame. I
guess it depends on the rate that the panel requests frames.

>
> I don't know right away if calling omap_rfbi_update() from interrupt
> context is dangerous, but it might well be so you should check if
> carefully.

OK, thankyou. I will check.

>
> Also, remember that you may need to stop updates somehow when the panel
> is blanked or the driver is unloaded.
>

I *think* this is OK because the FRAMEDONE interrupt is deregistered in
omapdss_rfbi_display_disable().

> >
> > static void framedone_callback(void *data)
> > {
> > int r;
> > u16 dw, dh;
> > struct omap_dss_device *dssdev = (struct omap_dss_device *)data;
> >
> > /* Start the next update, triggered on the external H/VSync
> signals */
> > dssdev->driver->get_resolution(dssdev, &dw, &dh);
> > r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback,
> > dssdev);
> > if (r < 0)
> > printk("omap_rfbi_update FAILED");
> > }
> >
> > static int generic_panel_power_on(struct omap_dss_device *dssdev)
> > {
> > int r;
> > u16 dw, dh;
> >
> > r = omapdss_rfbi_display_enable(dssdev);
> > if (r < 0)
> > goto err0;
> >
> > /* Setup external HSYNC/VSYNC triggering */
> > r = omap_rfbi_setup_te(OMAP_DSS_RFBI_TE_MODE_2,
> >400, /* HSYNS pulse 4uS */
> >10,  /* VSYNC pulse 1ms */
> >0, 0,   /* H/VSYNC not inverted */
> >0);
> > if (r < 0)
> > goto err1;
> >
> > /* Enable external triggering */
> > r = omap_rfbi_enable_te(1, 0);
> > if (r < 0)
> > goto err1;
> >
> > #if 0
> > /* At a guess I do not think we need to do the prepare_update
> >  * if we are updating the whole area
> >  */
>
> I'm not sure if it's ok not to call it every time, but you should at
> least call it once to be sure everything is configured properly.

Thanks. I will add this call.

>
>  Tomi
>

Ben
--
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: 4430SDP boot failure - solved + SPI bug fix

[Grant Likely]

On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote:
> Grant,
> 
> Care to queue or ack the following fix?

If you bounce the patch to me, then I'll pick it up into the spi tree
and send it on to Linus right away.  (It didn't get sent to either me
or the spi list, so I don't have the original).

Or if you want to pick it up:

Acked-by: Grant Likely 

Nothing in my tree touches omap_mcspi.c for this merge window, so
there won't be a merge conflict (I'm assuming you want this fix to go
into 2.6.28).

g.

> 
> * Russell King - ARM Linux  [110107 07:48]:
> > On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > > -Original Message-
> > > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > > Sent: Friday, January 07, 2011 7:55 PM
> > > > To: Santosh Shilimkar
> > > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > > Subject: Re: 4430SDP boot failure
> > > >
> > > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > > > >
> > > > > Low level debug as you reported seems to be broken though.
> > > >
> > > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
> > > > the board - which should ease the debugging problem as it no longer
> > > > requires anything but the reset button pressed to test a new kernel.
> > > 
> > > Glad to hear that.
> > 
> > And, with one ARM errata disabled, the kernel finally boots.  So the
> > "X-Loader hangs" message means that we did something that non-secure
> > mode prevented us from doing.
> > 
> > It would be a good idea if X-loader could tell dump out the exception,
> > register dump, and for data/prefetch aborts, the relevent FSR and FAR
> > registers - that would make debugging this kind of failure a lot
> > easier.
> > 
> > =
> > Subject: Fix DMA API usage in OMAP MCSPI driver
> > 
> > Running the latest kernel on the 4430SDP board with DMA API debugging
> > enabled results in this:
> > 
> > WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
> > NULL NULL: DMA-API: device driver tries to free DMA memory it has not 
> > allocated
> > [device address=0x8129901a] [size=260 bytes]
> > Modules linked in:
> > Backtrace:
> > [] (dump_backtrace+0x0/0x10c) from [] 
> > (dump_stack+0x18/0x1c)
> >  r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
> > [] (dump_stack+0x0/0x1c) from [] 
> > (warn_slowpath_common+0x58/0x70)
> > [] (warn_slowpath_common+0x0/0x70) from [] 
> > (warn_slowpath_fmt+0x38/0x40)
> >  r8:c1839e40 r7: r6:0104 r5: r4:8129901a
> > [] (warn_slowpath_fmt+0x0/0x40) from [] 
> > (check_unmap+0x19c/0x6f0)
> >  r3:c03110de r2:c0304e6b
> > [] (check_unmap+0x0/0x6f0) from [] 
> > (debug_dma_unmap_page+0x74/0x80)
> > [] (debug_dma_unmap_page+0x0/0x80) from [] 
> > (omap2_mcspi_work+0x514/0xbf0)
> > [] (omap2_mcspi_work+0x0/0xbf0) from [] 
> > (process_one_work+0x294/0x400)
> > [] (process_one_work+0x0/0x400) from [] 
> > (worker_thread+0x220/0x3f8)
> > [] (worker_thread+0x0/0x3f8) from [] (kthread+0x88/0x90)
> > [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x5fc)
> >  r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
> > ---[ end trace 1b75b31a2719ed20 ]---
> > 
> > I've no idea why this driver uses NULL for dma_unmap_single instead of
> > the &spi->dev that is laying around just waiting to be used in that
> > function - but it's an easy fix.
> > 
> > Also replace this comment with a FIXME comment:
> > /* Do DMA mapping "early" for better error reporting and
> >  * dcache use.  Note that if dma_unmap_single() ever starts
> >  * to do real work on ARM, we'd need to clean up mappings
> >  * for previous transfers on *ALL* exits of this loop...
> >  */
> > as the comment is not true - we do work in dma_unmap() functions,
> > particularly on ARMv6 and above.  I've corrected the existing unmap
> > functions but if any others are required they must be added ASAP.
> > 
> > Signed-off-by: Russell King 
> 
> Acked-by: Tony Lindgren 
> 
> 
> > ---
> > I'm surprised this driver got merged as it has such a comment, and is
> > abusing the DMA API... well, at least with the DMA API debugging we
> > can now catch this stuff.
> > 
> > diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> > index 951a160..abb1ffb 100644
> > --- a/drivers/spi/omap2_mcspi.c
> > +++ b/drivers/spi/omap2_mcspi.c
> > @@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct 
> > spi_transfer *xfer)
> >  
> > if (tx != NULL) {
> > wait_for_completion(&mcspi_dma->dma_tx_completion);
> > -   dma_unmap_single(NULL, xfer->tx_dma, count, DMA_TO_DEVICE);
> > +   dma_unmap_single(&spi->dev, xfer->tx_dma, count, DMA_TO_DEVICE);
> >  
> > /* for TX_ONLY mode, be sure all words have shifted out */
> > if 

Re: Latest regressions

[Tony Lindgren]

* Russell King - ARM Linux  [110107 06:57]:
> > >
> > > Linus' tree prior to the OMAP merge is buildable for the same
> > > config.
> > :)  This one is also fixed with the series but would get merged in rc1
> > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41712.html
> 
> It's something that should be queued up to also go in during the merge
> window IMHO.  Let's try to make rc1 a little less problematical than it
> currently is.

Sorry did not want to mess with the pending patches while waiting
for the merge window to open.

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 v2 1/4] ASoC: DMIC: Adding the OMAP DMIC driver

[Mark Brown]

On Fri, Jan 07, 2011 at 10:34:53AM -0600, Lambert, David wrote:
> On Thu, Jan 6, 2011 at 4:20 PM, Mark Brown

> > I suggested switch statements previously; you didn't comment on my
> > reply.

> Sorry... my personal standard on when to go with a switch statement is
> >2 choices,
> I'll change it over to a switch...

Think about the impression you're creating here: if someone had a review
comment on one version of a patch and you neither reply nor address it
in the patch they're very likely to have the same comment again.

> >> +     switch (rate) {
> >> +     case 192000:
> >> +             div = 5;
> >> +             break;
> >> +     default:
> >> +             div = 8;

> > Shouldn't the default case be a case 96000?

> The default case IS 96000 (only options for rate here are 96000 and
> 192000), isn't it?

Think about this from a robustness, legibility and maintainability point
of view - the above code doesn't clearly do the right thing, and if any
other sample rates are added it'll be buggy.
--
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: 4430SDP boot failure - solved + SPI bug fix

[Tony Lindgren]

Grant,

Care to queue or ack the following fix?

* Russell King - ARM Linux  [110107 07:48]:
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > Sent: Friday, January 07, 2011 7:55 PM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure
> > >
> > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > > >
> > > > Low level debug as you reported seems to be broken though.
> > >
> > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
> > > the board - which should ease the debugging problem as it no longer
> > > requires anything but the reset button pressed to test a new kernel.
> > 
> > Glad to hear that.
> 
> And, with one ARM errata disabled, the kernel finally boots.  So the
> "X-Loader hangs" message means that we did something that non-secure
> mode prevented us from doing.
> 
> It would be a good idea if X-loader could tell dump out the exception,
> register dump, and for data/prefetch aborts, the relevent FSR and FAR
> registers - that would make debugging this kind of failure a lot
> easier.
> 
> =
> Subject: Fix DMA API usage in OMAP MCSPI driver
> 
> Running the latest kernel on the 4430SDP board with DMA API debugging
> enabled results in this:
> 
> WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
> NULL NULL: DMA-API: device driver tries to free DMA memory it has not 
> allocated
> [device address=0x8129901a] [size=260 bytes]
> Modules linked in:
> Backtrace:
> [] (dump_backtrace+0x0/0x10c) from [] 
> (dump_stack+0x18/0x1c)
>  r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
> [] (dump_stack+0x0/0x1c) from [] 
> (warn_slowpath_common+0x58/0x70)
> [] (warn_slowpath_common+0x0/0x70) from [] 
> (warn_slowpath_fmt+0x38/0x40)
>  r8:c1839e40 r7: r6:0104 r5: r4:8129901a
> [] (warn_slowpath_fmt+0x0/0x40) from [] 
> (check_unmap+0x19c/0x6f0)
>  r3:c03110de r2:c0304e6b
> [] (check_unmap+0x0/0x6f0) from [] 
> (debug_dma_unmap_page+0x74/0x80)
> [] (debug_dma_unmap_page+0x0/0x80) from [] 
> (omap2_mcspi_work+0x514/0xbf0)
> [] (omap2_mcspi_work+0x0/0xbf0) from [] 
> (process_one_work+0x294/0x400)
> [] (process_one_work+0x0/0x400) from [] 
> (worker_thread+0x220/0x3f8)
> [] (worker_thread+0x0/0x3f8) from [] (kthread+0x88/0x90)
> [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x5fc)
>  r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
> ---[ end trace 1b75b31a2719ed20 ]---
> 
> I've no idea why this driver uses NULL for dma_unmap_single instead of
> the &spi->dev that is laying around just waiting to be used in that
> function - but it's an easy fix.
> 
> Also replace this comment with a FIXME comment:
> /* Do DMA mapping "early" for better error reporting and
>  * dcache use.  Note that if dma_unmap_single() ever starts
>  * to do real work on ARM, we'd need to clean up mappings
>  * for previous transfers on *ALL* exits of this loop...
>  */
> as the comment is not true - we do work in dma_unmap() functions,
> particularly on ARMv6 and above.  I've corrected the existing unmap
> functions but if any others are required they must be added ASAP.
> 
> Signed-off-by: Russell King 

Acked-by: Tony Lindgren 


> ---
> I'm surprised this driver got merged as it has such a comment, and is
> abusing the DMA API... well, at least with the DMA API debugging we
> can now catch this stuff.
> 
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> index 951a160..abb1ffb 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct 
> spi_transfer *xfer)
>  
>   if (tx != NULL) {
>   wait_for_completion(&mcspi_dma->dma_tx_completion);
> - dma_unmap_single(NULL, xfer->tx_dma, count, DMA_TO_DEVICE);
> + dma_unmap_single(&spi->dev, xfer->tx_dma, count, DMA_TO_DEVICE);
>  
>   /* for TX_ONLY mode, be sure all words have shifted out */
>   if (rx == NULL) {
> @@ -412,7 +412,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct 
> spi_transfer *xfer)
>  
>   if (rx != NULL) {
>   wait_for_completion(&mcspi_dma->dma_rx_completion);
> - dma_unmap_single(NULL, xfer->rx_dma, count, DMA_FROM_DEVICE);
> + dma_unmap_single(&spi->dev, xfer->rx_dma, count, 
> DMA_FROM_DEVICE);
>   omap2_mcspi_set_enable(spi, 0);
>  
>   if (l & OMAP2_MCSPI_CHCONF_TURBO) {
> @@ -1025,11 +1025,6 @@ static int omap2_mcspi_transfer(struct spi_device 
> *spi, struct spi_message *m)
>   if (m->is_dma_mapped || len < DMA_MIN_BYTES)
> 

Re: [RFT/PATCH 05/10] cbus: retu: move to threaded IRQ and GENIRQ

[Tony Lindgren]

* Felipe Balbi  [110106 23:47]:
> 
> The main point of using Sparse IRQ numbering is exactly avoiding
> pre-processor branches. Instead of defining ranges only when a device is
> compile, we can always keep the range allocated no matter if the device
> probes or not. So, I suggest dropping the ifdeffery on  and
> move that to something like below:

This is fine as long as we we don't run out of allocated IRQs before
switching over to sparse IRQ. The original reason for the ifdeffery
was to keep NR_IRQS below 256 when possible as it optimizes the interrupt
handling in that case. See NR_IRQS in arch/arm/include/asm/hardirq.h
for more info.

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: 4430SDP boot failure

[Daniel Díaz]

Hello!


On Fri, Jan 7, 2011 at 10:24 AM, Russell King - ARM Linux
 wrote:
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
>> > -Original Message-
>> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
>> > Sent: Friday, January 07, 2011 7:55 PM
>> > To: Santosh Shilimkar
>> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
>> > Subject: Re: 4430SDP boot failure
>> >
>> > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
>> > > Have sent you latest bootloaders and full bootlog on my ES1.0
>> > > OMAP4430SDP. 2.6.37 just boots fine for me.
>> > >
>> > > Low level debug as you reported seems to be broken though.
>> >
>> > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
>> > the board - which should ease the debugging problem as it no longer
>> > requires anything but the reset button pressed to test a new kernel.
>>
>> Glad to hear that.
>
> Right, next couple of problems.
>
> udev isn't creating the ttyO* nodes for whatever reason on my fs - does
> anyone know what device major/minor numbers these end up with?  It seems
> they're dynamically assigned.

This is what I have:
mazi-gentoo ~ # ls -l /dev/ttyO?
crw-rw 1 root  uucp 247, 0 Dec 31  1999 /dev/ttyO0
crw-rw 1 root  uucp 247, 1 Dec 31  1999 /dev/ttyO1
crw--- 1 ddiaz tty  247, 2 Jan  7 11:02 /dev/ttyO2
crw-rw 1 root  uucp 247, 3 Dec 31  1999 /dev/ttyO3

Greetings!

Daniel Díaz
yo...@danieldiaz.org



> There's also something fishy going on with networking (if I configure
> PNP IP, I get an IP:
>
> ks8851 spi1.0: message enable is 0
> ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194
> IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144
> IP-Config: Complete:
>     device=eth0, addr=192.168.0.144, mask=255.255.255.0, gw=192.168.0.1,
>     host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none),
>     bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
>
> but the board doesn't respond to that IP address.  Meanwhile the DHCP
> server shows:
>
>        DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0
>
> in its log, and the ethernet address appears to be random for each boot.
> Obviously, as I can't log into the board via any means, it's nigh on
> impossible to work out what's actually going on.
--
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: Latest regressions

[Tony Lindgren]

* Russell King - ARM Linux  [110107 03:57]:
> 
> So, this is what I currently have to get that far:
> 
> diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S 
> b/arch/arm/mach-omap2/include/mach/entry-macro.S
> index befa321..81985a6 100644
> --- a/arch/arm/mach-omap2/include/mach/entry-macro.S
> +++ b/arch/arm/mach-omap2/include/mach/entry-macro.S
> @@ -38,20 +38,6 @@
>   */
>  
>  #ifdef MULTI_OMAP2
> -
> -/*
> - * We use __glue to avoid errors with multiple definitions of
> - * .globl omap_irq_base as it's included from entry-armv.S but not
> - * from entry-common.S.
> - */
> -#ifdef __glue
> - .pushsection .data
> - .globl  omap_irq_base
> -omap_irq_base:
> - .word   0
> - .popsection
> -#endif
> -
>   /*
>* Configure the interrupt base on the first interrupt.
>* See also omap_irq_base_init for setting omap_irq_base.
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index e66687b..c203204 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -314,14 +314,13 @@ static int _set_hwmod_postsetup_state(struct omap_hwmod 
> *oh, void *data)
>   return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
>  }
>  
> +void __iomem *omap_irq_base;
> +
>  /*
>   * Initialize asm_irq_base for entry-macro.S
>   */
>  static inline void omap_irq_base_init(void)
>  {
> - extern void __iomem *omap_irq_base;
> -
> -#ifdef MULTI_OMAP2
>   if (cpu_is_omap24xx())
>   omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP24XX_IC_BASE);
>   else if (cpu_is_omap34xx())
> @@ -330,7 +329,6 @@ static inline void omap_irq_base_init(void)
>   omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE);
>   else
>   pr_err("Could not initialize omap_irq_base\n");
> -#endif
>  }
>  
>  void __init omap2_init_common_infrastructure(void)

This looks good to me.

> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index 17bd639..9eaa28c 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -160,7 +160,7 @@ static int __init _omap_mux_get_by_name(struct 
> omap_mux_partition *partition,
>   struct omap_mux *mux = NULL;
>   struct omap_mux_entry *e;
>   const char *mode_name;
> - int found = 0, found_mode, mode0_len = 0;
> + int found = 0, found_mode = 0, mode0_len = 0;
>   struct list_head *muxmodes = &partition->muxmodes;
>  
>   mode_name = strchr(muxname, '.');

Ack.

> diff --git a/arch/arm/plat-omap/include/plat/voltage.h 
> b/arch/arm/plat-omap/include/plat/voltage.h
> index 0ff1233..ffcdff9 100644
> --- a/arch/arm/plat-omap/include/plat/voltage.h
> +++ b/arch/arm/plat-omap/include/plat/voltage.h
> @@ -14,6 +14,8 @@
>  #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
>  #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
>  
> +#include 
> +
>  #define VOLTSCALE_VPFORCEUPDATE  1
>  #define VOLTSCALE_VCBYPASS   2

This fix is already queued up by Kevin, but missing..
  
> @@ -133,9 +135,9 @@ void omap_change_voltscale_method(struct voltagedomain 
> *voltdm,
>   int voltscale_method);
>  int omap_voltage_late_init(void);
>  #else
> -static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
> +static inline void omap_voltage_register_pmic(struct voltagedomain *voltdm,
>   struct omap_volt_pmic_info *pmic_info) {}
> -static inline  void omap_change_voltscale_method(struct voltagedomain 
> *voltdm,
> +static inline void omap_change_voltscale_method(struct voltagedomain *voltdm,
>   int voltscale_method) {}
>  static inline int omap_voltage_late_init(void)
>  {

..this change.

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] omap3: Add basic support for 720MHz part

[Kevin Hilman]

Sanjeev Premi  writes:

> This patch adds support for new speed enhanced parts with ARM
> and IVA running at 720MHz and 520MHz respectively. These parts
> can be probed at run-time by reading PRODID.SKUID[3:0] at
> 0x4830A20C [1].

Please expand this a little to describe exactly which parts have this
feature.  All OMAP3?  34xx? 35xx? what about 36xx/37xx?  ISTR the
runtime probing for this feature is available on 35xx but not on 34xx,
but a summary of this should be here.

> This patch specifically does following:
>  * Detect devices capable of 720MHz.
>  * Add new OPP
>  * Ensure that OPP is conditionally enabled.
>
> The patch was tested on OMAP3EVM.

nit: Unrelated to this patch, but OMAP3EVM ethernet is still broken due to
missing GPIO configuration for the network reset.  This has been broken
since the GPIO hwmod merge and pointed out but nobody seems to be fixing
it.

> On 720MHz capable device:
> # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
> 72
>
> On other devices:
> # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
> 60
>
>   [1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
>
> Signed-off-by: Sanjeev Premi 
> ---
>  arch/arm/mach-omap2/control.h |7 +++
>  arch/arm/mach-omap2/id.c  |   10 ++
>  arch/arm/mach-omap2/opp3xxx_data.c|   19 ++-
>  arch/arm/plat-omap/include/plat/cpu.h |2 ++
>  4 files changed, 37 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
> index f0629ae..eebc045 100644
> --- a/arch/arm/mach-omap2/control.h
> +++ b/arch/arm/mach-omap2/control.h
> @@ -365,6 +365,13 @@
>  #define  FEAT_NEON   0
>  #define  FEAT_NEON_NONE  1
>  
> +/*
> + * Product ID register
> + */
> +#define OMAP3_PRODID 0x020C
> +
> +#define OMAP3_SKUID_MASK 0x0f
> +#define  OMAP3_SKUID_720MHZ  0x08
>  
>  #ifndef __ASSEMBLY__
>  #ifdef CONFIG_ARCH_OMAP2PLUS
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 5f9086c..53fbe01 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -195,6 +195,15 @@ static void __init omap3_check_features(void)
>* TODO: Get additional info (where applicable)
>*   e.g. Size of L2 cache.
>*/
> +
> + /*
> +  * Does it support 720MHz?
> +  */
> + status = (OMAP3_SKUID_MASK & read_tap_reg(OMAP3_PRODID));
> +
> + if (status & OMAP3_SKUID_720MHZ) {
> + omap3_features |= OMAP3_HAS_720MHZ;
> + }
>  }
>  
>  static void __init omap3_check_revision(void)
> @@ -445,6 +454,7 @@ static void __init omap3_cpuinfo(void)
>   OMAP3_SHOW_FEATURE(neon);
>   OMAP3_SHOW_FEATURE(isp);
>   OMAP3_SHOW_FEATURE(192mhz_clk);
> + OMAP3_SHOW_FEATURE(720mhz);
>  
>   printk(")\n");
>  }
> diff --git a/arch/arm/mach-omap2/opp3xxx_data.c 
> b/arch/arm/mach-omap2/opp3xxx_data.c
> index 0486fce..01582b7 100644
> --- a/arch/arm/mach-omap2/opp3xxx_data.c
> +++ b/arch/arm/mach-omap2/opp3xxx_data.c
> @@ -22,6 +22,9 @@
>  
>  #include "omap_opp_data.h"
>  
> +#define INDEX_MPU_720MHZ 5
> +#define INDEX_IVA_720MHZ 14
> +
>  static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
>   /* MPU OPP1 */
>   OPP_INITIALIZER("mpu", true, 12500, 975000),
> @@ -33,6 +36,8 @@ static struct omap_opp_def __initdata 
> omap34xx_opp_def_list[] = {
>   OPP_INITIALIZER("mpu", true, 55000, 127),
>   /* MPU OPP5 */
>   OPP_INITIALIZER("mpu", true, 6, 135),
> + /* MPU OPP6 */
> + OPP_INITIALIZER("mpu", false, 72000, 135),
>  
>   /*
>* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
> @@ -58,6 +63,8 @@ static struct omap_opp_def __initdata 
> omap34xx_opp_def_list[] = {
>   OPP_INITIALIZER("iva", true, 4, 127),
>   /* DSP OPP5 */
>   OPP_INITIALIZER("iva", true, 43000, 135),
> + /* DSP OPP6 */
> + OPP_INITIALIZER("iva", false, 52000, 135),
>  };
>  
>  static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
> @@ -98,9 +105,19 @@ static int __init omap3_opp_init(void)
>   if (cpu_is_omap3630())
>   r = omap_init_opp_table(omap36xx_opp_def_list,
>   ARRAY_SIZE(omap36xx_opp_def_list));
> - else
> + else {
> + if (omap3_has_720mhz()) {
> + pr_info("Enabled OPP corresponding to 720MHz\n");
> +
> + omap34xx_opp_def_list[INDEX_MPU_720MHZ]
> + .default_available = true;
> + omap34xx_opp_def_list[INDEX_IVA_720MHZ]
> + .default_available = true;
> + }
> +

I'm with Nishanth here.  Please stick to the OPP API for enabling OPPs.

First, it is future proof to internal table changes, but it also sets a
better precedent for others wanting to fi

Re: Latest config warning

[Tony Lindgren]

* Russell King - ARM Linux  [110107 03:34]:
> warning: (ARCH_STMP3XXX &&  || ARCH_OMAP3 && ARCH_OMAP2PLUS) selects 
> USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT)
> 
> This didn't happen with 2.6.37.  Maybe a missing select USB_SUPPORT
> somewhere?

Felipe, care to take a look at this one?

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 v2 1/4] ASoC: DMIC: Adding the OMAP DMIC driver

[Lambert, David]

On Thu, Jan 6, 2011 at 4:20 PM, Mark Brown
 wrote:
> On Thu, Jan 06, 2011 at 08:00:36AM -0600, David Lambert wrote:
>
>> @@ -103,6 +106,7 @@ config SND_OMAP_SOC_SDP4430
>>       depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP_4430SDP
>>       select SND_OMAP_SOC_MCPDM
>>       select SND_SOC_TWL6040
>> +     select SND_SOC_DMIC
>>       help
>>         Say Y if you want to add support for SoC audio on Texas Instruments
>>         SDP4430.
>
> Any tweaks to specific machines should be done separately to adding the
> new drivers.

OK... I'll put that in to a separate patch.

>
>> +     struct omap_dmic *dmic = snd_soc_dai_get_drvdata(dai);
>> +     int ctrl, div_sel = -EINVAL;
>> +
>> +     if (div_id != OMAP_DMIC_CLKDIV)
>> +             return -ENODEV;
>> +
>> +     switch (dmic->clk_freq) {
>> +     case 1920:
>> +             if (div == 5)
>> +                     div_sel = 0x1;
>> +             else if (div == 8)
>> +                     div_sel = 0x0;
>
> I suggested switch statements previously; you didn't comment on my
> reply.
>

Sorry... my personal standard on when to go with a switch statement is
>2 choices,
I'll change it over to a switch...

>> +static irqreturn_t omap_dmic_irq_handler(int irq, void *dev_id)
>> +{
>> +     struct omap_dmic *dmic = dev_id;
>
> My comments on this function appear to have been mostly ignored also.
>

Being as with this hardware, the IRQ handler really does nothing, I
think it best
if I just take it out for now.  It is useful in debugging cases to ensure you're
moving data.  I'll just remove it.

>> +     switch (rate) {
>> +     case 192000:
>> +             div = 5;
>> +             break;
>> +     default:
>> +             div = 8;
>
> Shouldn't the default case be a case 96000?

The default case IS 96000 (only options for rate here are 96000 and
192000), isn't it?

>
>> +     case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
>> +             break;
>> +     case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
>> +             break;
>
> Remove the empty cases, they're handled by the default.
>

OK

>> +
>> +MODULE_AUTHOR("David Lambert ");
>> +MODULE_DESCRIPTION("OMAP DMIC SoC Interface");
>> +MODULE_LICENSE("GPL");
>
> As also previously noted you should have a MODULE_ALIAS.

The MODULE_ALIAS is in there... just following example of the other drivers
I looked at, it was placed above the platform_driver declaration.

+MODULE_ALIAS("platform:omap-dmic-dai");
+
+static struct platform_driver asoc_dmic_driver = {
+   .driver = {
+   .name = "omap-dmic-dai",
+   .owner = THIS_MODULE,
+   },
+   .probe = asoc_dmic_probe,
+   .remove = __devexit_p(asoc_dmic_remove),
+};

>

--
David Lambert
OMAP™ Multimedia
214-567-5692
--
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: 4430SDP boot failure

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Friday, January 07, 2011 7:55 PM
> > To: Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: Re: 4430SDP boot failure
> >
> > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > >
> > > Low level debug as you reported seems to be broken though.
> >
> > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
> > the board - which should ease the debugging problem as it no longer
> > requires anything but the reset button pressed to test a new kernel.
> 
> Glad to hear that.

Right, next couple of problems.

udev isn't creating the ttyO* nodes for whatever reason on my fs - does
anyone know what device major/minor numbers these end up with?  It seems
they're dynamically assigned.

There's also something fishy going on with networking (if I configure
PNP IP, I get an IP:

ks8851 spi1.0: message enable is 0
ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144
IP-Config: Complete:
 device=eth0, addr=192.168.0.144, mask=255.255.255.0, gw=192.168.0.1,
 host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none),
 bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=

but the board doesn't respond to that IP address.  Meanwhile the DHCP
server shows:

DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0

in its log, and the ethernet address appears to be random for each boot.
Obviously, as I can't log into the board via any means, it's nigh on
impossible to work out what's actually going on.
--
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: 4430SDP boot failure

[Russell King - ARM Linux]

On Thu, Jan 06, 2011 at 12:40:54PM -0800, Tony Lindgren wrote:
> Anyways, I can debug the DEBUG_LL booting issue further if the patch
> I posted does not help.

This is what I ended up with earlier today to make the debug code work
both in the decompressor and in the kernel - once I had it working I
haven't bothered putting any more effort into it.

diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S 
b/arch/arm/mach-omap2/include/mach/debug-macro.S
index 6a4d413..47df8a6 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -13,6 +13,7 @@
 
 #include 
 
+#if 0
 #include 
 
 #include 
@@ -139,6 +140,24 @@ omap_uart_lsr: .word   0
teq \rd, #(UART_LSR_TEMT | UART_LSR_THRE)
bne 1001b
.endm
+#else
+   .macro  addruart, rp, rv
+   mov \rp, #0x0002
+   orr \rv, \rp, #0xfa00
+   orr \rp, \rp, #0x4800
+   .endm
+
+   .macro  senduart, ch, rb
+   strb\ch, [\rb]
+   .endm
+
+   .macro  busyuart, rb, tmp
+1001:  ldrb\tmp, [\rb, #UART_LSR << 2]
+   and \tmp, \tmp, #UART_LSR_TEMT | UART_LSR_THRE
+   teq \tmp, #UART_LSR_TEMT | UART_LSR_THRE
+   bne 1001b
+   .endm
+#endif
 
.macro  waituart,rd,rx
.endm

--
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: 4430SDP boot failure - solved + SPI bug fix

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Friday, January 07, 2011 7:55 PM
> > To: Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: Re: 4430SDP boot failure
> >
> > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > >
> > > Low level debug as you reported seems to be broken though.
> >
> > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
> > the board - which should ease the debugging problem as it no longer
> > requires anything but the reset button pressed to test a new kernel.
> 
> Glad to hear that.

And, with one ARM errata disabled, the kernel finally boots.  So the
"X-Loader hangs" message means that we did something that non-secure
mode prevented us from doing.

It would be a good idea if X-loader could tell dump out the exception,
register dump, and for data/prefetch aborts, the relevent FSR and FAR
registers - that would make debugging this kind of failure a lot
easier.

=
Subject: Fix DMA API usage in OMAP MCSPI driver

Running the latest kernel on the 4430SDP board with DMA API debugging
enabled results in this:

WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated
[device address=0x8129901a] [size=260 bytes]
Modules linked in:
Backtrace:
[] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c)
 r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
[] (dump_stack+0x0/0x1c) from [] 
(warn_slowpath_common+0x58/0x70)
[] (warn_slowpath_common+0x0/0x70) from [] 
(warn_slowpath_fmt+0x38/0x40)
 r8:c1839e40 r7: r6:0104 r5: r4:8129901a
[] (warn_slowpath_fmt+0x0/0x40) from [] 
(check_unmap+0x19c/0x6f0)
 r3:c03110de r2:c0304e6b
[] (check_unmap+0x0/0x6f0) from [] 
(debug_dma_unmap_page+0x74/0x80)
[] (debug_dma_unmap_page+0x0/0x80) from [] 
(omap2_mcspi_work+0x514/0xbf0)
[] (omap2_mcspi_work+0x0/0xbf0) from [] 
(process_one_work+0x294/0x400)
[] (process_one_work+0x0/0x400) from [] 
(worker_thread+0x220/0x3f8)
[] (worker_thread+0x0/0x3f8) from [] (kthread+0x88/0x90)
[] (kthread+0x0/0x90) from [] (do_exit+0x0/0x5fc)
 r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
---[ end trace 1b75b31a2719ed20 ]---

I've no idea why this driver uses NULL for dma_unmap_single instead of
the &spi->dev that is laying around just waiting to be used in that
function - but it's an easy fix.

Also replace this comment with a FIXME comment:
/* Do DMA mapping "early" for better error reporting and
 * dcache use.  Note that if dma_unmap_single() ever starts
 * to do real work on ARM, we'd need to clean up mappings
 * for previous transfers on *ALL* exits of this loop...
 */
as the comment is not true - we do work in dma_unmap() functions,
particularly on ARMv6 and above.  I've corrected the existing unmap
functions but if any others are required they must be added ASAP.

Signed-off-by: Russell King 
---
I'm surprised this driver got merged as it has such a comment, and is
abusing the DMA API... well, at least with the DMA API debugging we
can now catch this stuff.

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 951a160..abb1ffb 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct 
spi_transfer *xfer)
 
if (tx != NULL) {
wait_for_completion(&mcspi_dma->dma_tx_completion);
-   dma_unmap_single(NULL, xfer->tx_dma, count, DMA_TO_DEVICE);
+   dma_unmap_single(&spi->dev, xfer->tx_dma, count, DMA_TO_DEVICE);
 
/* for TX_ONLY mode, be sure all words have shifted out */
if (rx == NULL) {
@@ -412,7 +412,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct 
spi_transfer *xfer)
 
if (rx != NULL) {
wait_for_completion(&mcspi_dma->dma_rx_completion);
-   dma_unmap_single(NULL, xfer->rx_dma, count, DMA_FROM_DEVICE);
+   dma_unmap_single(&spi->dev, xfer->rx_dma, count, 
DMA_FROM_DEVICE);
omap2_mcspi_set_enable(spi, 0);
 
if (l & OMAP2_MCSPI_CHCONF_TURBO) {
@@ -1025,11 +1025,6 @@ static int omap2_mcspi_transfer(struct spi_device *spi, 
struct spi_message *m)
if (m->is_dma_mapped || len < DMA_MIN_BYTES)
continue;
 
-   /* Do DMA mapping "early" for better error reporting and
-* dcache use.  Note that if dma_unmap_single() ever starts
-* to do real work on ARM, we'd need to clean up mappings
-* for previous transfers on *ALL* exits of this loop...
-

[PATCH v2 2/2] OMAP3: beagle xm: enable upto 800MHz OPP

[Nishanth Menon]

OMP3630 silicon can enable higher frequencies only depending on the board
characteristics meeting the recommended standards, and has to be selectively
toggled.

Beagle XM uses 3730 variant and the board design allows enabling 800MHz and
1GHz OPPs. However, We need Smart reflex class 1.5 and ABB to enable 1GHz
safely.  For the moment, we tweak the default table to allow for 800Mhz OPP
usage.

Reported-by: Koen Kooi 
Tested-by: Koen Kooi 

Signed-off-by: Nishanth Menon 
---
v2: fixed issue when !mh || !dh, updated commit message to point on rationale
for board specific tweaking
v1: http://marc.info/?t=12942606098&r=1&w=2
 arch/arm/mach-omap2/board-omap3beagle.c |   50 +++
 1 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 6c12760..7dc0397 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -44,10 +45,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mux.h"
 #include "hsmmc.h"
 #include "timer-gp.h"
+#include "pm.h"
 
 #define NAND_BLOCK_SIZESZ_128K
 
@@ -556,6 +559,52 @@ static struct omap_musb_board_data musb_board_data = {
.power  = 100,
 };
 
+static void __init beagle_opp_init(void)
+{
+   int r = 0;
+
+   /* Initialize the omap3 opp table */
+   if (omap3_opp_init()) {
+   pr_err("%s: opp default init failed\n", __func__);
+   return;
+   }
+
+   /* Custom OPP enabled for XM */
+   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+   struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
+   struct omap_hwmod *dh = omap_hwmod_lookup("iva");
+   struct device *dev;
+
+   if (!mh || !dh) {
+   pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
+   __func__, mh, dh);
+   return;
+   }
+   /* Enable MPU 1GHz and lower opps */
+   dev = &mh->od->pdev.dev;
+   r = opp_enable(dev, 8);
+   /* TODO: MPU 1GHz needs SR and ABB */
+
+   /* Enable IVA 800MHz and lower opps */
+   dev = &dh->od->pdev.dev;
+   r |= opp_enable(dev, 66000);
+   /* TODO: DSP 800MHz needs SR and ABB */
+   if (r) {
+   pr_err("%s: failed to enable higher opp %d\n",
+   __func__, r);
+   /*
+* Cleanup - disable the higher freqs - we dont care
+* about the results
+*/
+   dev = &mh->od->pdev.dev;
+   opp_disable(dev, 8);
+   dev = &dh->od->pdev.dev;
+   opp_disable(dev, 66000);
+   }
+   }
+   return;
+}
+
 static void __init omap3_beagle_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -579,6 +628,7 @@ static void __init omap3_beagle_init(void)
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
 
beagle_display_init();
+   beagle_opp_init();
 }
 
 MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
-- 
1.6.3.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: linux-next: manual merge of the usb tree with the omap tree

[Anand Gadiyar]

Ming Lei wrote:
> Ming Lei wrote:
> > 2011/1/7 Anand Gadiyar :
> > > Hi Ming Lei,
> > >
> > > I'm able to reproduce this on my panda, and I have it working as of
> > > linux-next-20101221 (the last version I tested last year) and
failing
> > > on linux-next-20101227 (which was the very next linux-next release).
> > >
> > > Not sure why, but my Panda manages to get the VID:PID of the hub as
> > > well, while yours does not even get there.
> > >
> > > I may need a few more hours to debug this, unless someone beats me
> > > to it. ;)
> >
> > Is it caused by the below?
> >
> > [   46.580200] ehci-omap ehci-omap.0: failed to get ehci port0
regulator
> >
>
> Nope. We don't set up any regulators for the PHY on Panda (at least not
> yet).
>
> And the working case (next-20101221) has the same log.
>
> I suspect the PHY doesn't get reset for the proper duration; I'm looking
> for something in that area. (Another option is to bisect between the two
> versions, but I'm not sure if that's any easier).
>

Update: I disabled CONFIG_OMAP_RESET_CLOCKS and the PHY and other
connected devices enumerate just fine. Could you try this out on
your board as well?

I'll look deeper and see if there are some required clocks that are
accidentally getting turned off.

- Anand
--
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: RFBI worked example

[Tomi Valkeinen]

On Fri, 2011-01-07 at 14:18 +, ext Ben Tucker wrote:
> With further experimentation it appears that I can call the
> omap_rfbi_update() from the call back, but as the callback is in interrupt
> context this could be dangerous. I would love to see an example of this
> elsewhere.

Did you get it working enough to get an image on the panel?

It's been long since I've touched the rfbi code, and I honestly don't
know the state of it, but basically it should work similarly as DSI
command mode:

The panel driver issues an update when the user space has requested it
via OMAPFB_UPDATE_WINDOW. So it's not meant to be triggered
automatically.

If you really want to update the display automatically (which you
shouldn't, as the point with panels with their own framebuffer is to
update only when necessary), you can do it either directly as you do, or
via workqueue or thread.

I don't know right away if calling omap_rfbi_update() from interrupt
context is dangerous, but it might well be so you should check if
carefully.

Also, remember that you may need to stop updates somehow when the panel
is blanked or the driver is unloaded.

> 
> static void framedone_callback(void *data)
> {
> int r;
> u16 dw, dh;
> struct omap_dss_device *dssdev = (struct omap_dss_device *)data;
> 
> /* Start the next update, triggered on the external H/VSync signals */
> dssdev->driver->get_resolution(dssdev, &dw, &dh);
> r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback,
> dssdev);
> if (r < 0)
> printk("omap_rfbi_update FAILED");
> }
> 
> static int generic_panel_power_on(struct omap_dss_device *dssdev)
> {
> int r;
> u16 dw, dh;
> 
> r = omapdss_rfbi_display_enable(dssdev);
> if (r < 0)
> goto err0;
> 
> /* Setup external HSYNC/VSYNC triggering */
> r = omap_rfbi_setup_te(OMAP_DSS_RFBI_TE_MODE_2,
>400, /* HSYNS pulse 4uS */
>10,  /* VSYNC pulse 1ms */
>0, 0,   /* H/VSYNC not inverted */
>0);
> if (r < 0)
> goto err1;
> 
> /* Enable external triggering */
> r = omap_rfbi_enable_te(1, 0);
> if (r < 0)
> goto err1;
> 
> #if 0
> /* At a guess I do not think we need to do the prepare_update
>  * if we are updating the whole area
>  */

I'm not sure if it's ok not to call it every time, but you should at
least call it once to be sure everything is configured properly.

 Tomi


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

Re: Latest regressions

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 08:24:26PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> > Sent: Friday, January 07, 2011 8:11 PM
> > To: linux-omap@vger.kernel.org
> > Subject: Re: Latest regressions
> >
> > While trying to build the latest kernel for the SDP4430 board:
> >
> > arch/arm/mach-omap2/clockdomain.c: In function │_enable_hwsup│:
> > arch/arm/mach-omap2/clockdomain.c:251: error: │struct clockdomain│
> > has no member named │clktrctrl_mask│
> > arch/arm/mach-omap2/clockdomain.c:254: error: │struct clockdomain│
> > has no member named │clktrctrl_mask│
> > arch/arm/mach-omap2/clockdomain.c: In function │_disable_hwsup│:
> > arch/arm/mach-omap2/clockdomain.c:277: error: │struct clockdomain│
> > has no member named │clktrctrl_mask│
> > arch/arm/mach-omap2/clockdomain.c:280: error: │struct clockdomain│
> > has no member named │clktrctrl_mask│
> > arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_sleep│:
> > arch/arm/mach-omap2/clockdomain.c:744: error: │struct clockdomain│
> > has no member named │clktrctrl_mask│
> > arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_wakeup│:
> > arch/arm/mach-omap2/clockdomain.c:789: error: │struct clockdomain│
> > has no member named │clktrctrl_mask│
> > arch/arm/mach-omap2/clockdomain.c: In function
> > │omap2_clkdm_clk_enable│:
> > arch/arm/mach-omap2/clockdomain.c:922: error: │struct clockdomain│
> > has no member named │clktrctrl_mask│
> > arch/arm/mach-omap2/clockdomain.c:926: error: │struct clockdomain│
> > has no member named │clktrctrl_mask│
> > arch/arm/mach-omap2/clockdomain.c: In function
> > │omap2_clkdm_clk_disable│:
> > arch/arm/mach-omap2/clockdomain.c:994: error: │struct clockdomain│
> > has no member named │clktrctrl_mask│
> > arch/arm/mach-omap2/clockdomain.c:998: error: │struct clockdomain│
> > has no member named │clktrctrl_mask│
> >
> > Linus' tree prior to the OMAP merge is buildable for the same
> > config.
> :)  This one is also fixed with the series but would get merged in rc1
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41712.html

It's something that should be queued up to also go in during the merge
window IMHO.  Let's try to make rc1 a little less problematical than it
currently is.
--
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: Latest regressions

[Santosh Shilimkar]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Friday, January 07, 2011 8:11 PM
> To: linux-omap@vger.kernel.org
> Subject: Re: Latest regressions
>
> While trying to build the latest kernel for the SDP4430 board:
>
> arch/arm/mach-omap2/clockdomain.c: In function │_enable_hwsup│:
> arch/arm/mach-omap2/clockdomain.c:251: error: │struct clockdomain│
> has no member named │clktrctrl_mask│
> arch/arm/mach-omap2/clockdomain.c:254: error: │struct clockdomain│
> has no member named │clktrctrl_mask│
> arch/arm/mach-omap2/clockdomain.c: In function │_disable_hwsup│:
> arch/arm/mach-omap2/clockdomain.c:277: error: │struct clockdomain│
> has no member named │clktrctrl_mask│
> arch/arm/mach-omap2/clockdomain.c:280: error: │struct clockdomain│
> has no member named │clktrctrl_mask│
> arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_sleep│:
> arch/arm/mach-omap2/clockdomain.c:744: error: │struct clockdomain│
> has no member named │clktrctrl_mask│
> arch/arm/mach-omap2/clockdomain.c: In function │omap2_clkdm_wakeup│:
> arch/arm/mach-omap2/clockdomain.c:789: error: │struct clockdomain│
> has no member named │clktrctrl_mask│
> arch/arm/mach-omap2/clockdomain.c: In function
> │omap2_clkdm_clk_enable│:
> arch/arm/mach-omap2/clockdomain.c:922: error: │struct clockdomain│
> has no member named │clktrctrl_mask│
> arch/arm/mach-omap2/clockdomain.c:926: error: │struct clockdomain│
> has no member named │clktrctrl_mask│
> arch/arm/mach-omap2/clockdomain.c: In function
> │omap2_clkdm_clk_disable│:
> arch/arm/mach-omap2/clockdomain.c:994: error: │struct clockdomain│
> has no member named │clktrctrl_mask│
> arch/arm/mach-omap2/clockdomain.c:998: error: │struct clockdomain│
> has no member named │clktrctrl_mask│
>
> Linus' tree prior to the OMAP merge is buildable for the same
> config.
:)  This one is also fixed with the series but would get merged in rc1
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41712.html

Regards,
Santosh
--
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: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module

[Guenter Roeck]

On Fri, Jan 07, 2011 at 07:12:13AM -0500, J, KEERTHY wrote:
> On Fri, Jan 7, 2011 at 3:25 AM, Guenter Roeck
>  wrote:
> > On Thu, 2011-01-06 at 15:21 -0500, Mark Brown wrote:
> >> On Thu, Jan 06, 2011 at 07:04:30AM -0800, Guenter Roeck wrote:
> >> > On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote:
> >>
> >> > > Why?  It's not like hwmon has an unreasonably large core or similar.
> >>
> >> > Because it creates an unnecessary dependency, and because it is not 
> >> > hwmon's
> >> > responsibility to provide infrastructure for other subsystems or drivers.
> >>
> >> hwmon isn't really doing anything, though.  The *driver* is doing
> >> something but it doesn't really impact the core that much.  Not that I'm
> >> particularly sold on putting the ADC core in here, but total NACK based
> >> on that alone seems rather harsh.
> >
> > Possibly. However, I had suggested the following earlier (to the 1st
> > version of the patch):
> >
> >> I commented on this a couple of times below - the driver mixes generic
> >> ADC reading functions with hwmon functionality. Generic ADC reading
> >> functionality should be moved into another driver, possibly to mfd.
> >
> > Obviously that was ignored. Maybe someone is willing to listen this time
> > around.
> >
> I am sorry for not responding on the generic ADC handling part. Since many
> other ADC drivers are part of hwmon i thought hwmon was the appropriate
> place. However I can surely split the generic ADC handling part in mfd and
> only hardware monitoring part in hwmon as suggested.
> 
Other drivers don't _export_ that functionality. Key difference.

Sure, the lis3 driver does, but that should not be in hwmon in the first place
and is on the way out (if I ever get to do it), and max is just setting
a bad example.

Guenter
--
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: Latest regressions

[Russell King - ARM Linux]

While trying to build the latest kernel for the SDP4430 board:

arch/arm/mach-omap2/clockdomain.c: In function ■_enable_hwsup■:
arch/arm/mach-omap2/clockdomain.c:251: error: ■struct clockdomain■ has no 
member named ■clktrctrl_mask■
arch/arm/mach-omap2/clockdomain.c:254: error: ■struct clockdomain■ has no 
member named ■clktrctrl_mask■
arch/arm/mach-omap2/clockdomain.c: In function ■_disable_hwsup■:
arch/arm/mach-omap2/clockdomain.c:277: error: ■struct clockdomain■ has no 
member named ■clktrctrl_mask■
arch/arm/mach-omap2/clockdomain.c:280: error: ■struct clockdomain■ has no 
member named ■clktrctrl_mask■
arch/arm/mach-omap2/clockdomain.c: In function ■omap2_clkdm_sleep■:
arch/arm/mach-omap2/clockdomain.c:744: error: ■struct clockdomain■ has no 
member named ■clktrctrl_mask■
arch/arm/mach-omap2/clockdomain.c: In function ■omap2_clkdm_wakeup■:
arch/arm/mach-omap2/clockdomain.c:789: error: ■struct clockdomain■ has no 
member named ■clktrctrl_mask■
arch/arm/mach-omap2/clockdomain.c: In function ■omap2_clkdm_clk_enable■:
arch/arm/mach-omap2/clockdomain.c:922: error: ■struct clockdomain■ has no 
member named ■clktrctrl_mask■
arch/arm/mach-omap2/clockdomain.c:926: error: ■struct clockdomain■ has no 
member named ■clktrctrl_mask■
arch/arm/mach-omap2/clockdomain.c: In function ■omap2_clkdm_clk_disable■:
arch/arm/mach-omap2/clockdomain.c:994: error: ■struct clockdomain■ has no 
member named ■clktrctrl_mask■
arch/arm/mach-omap2/clockdomain.c:998: error: ■struct clockdomain■ has no 
member named ■clktrctrl_mask■

Linus' tree prior to the OMAP merge is buildable for the same config.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: linux-next: manual merge of the usb tree with the omap tree

[Anand Gadiyar]

Ming Lei wrote:
> 2011/1/7 Anand Gadiyar :
> > Hi Ming Lei,
> >
> > I'm able to reproduce this on my panda, and I have it working as of
> > linux-next-20101221 (the last version I tested last year) and failing
> > on linux-next-20101227 (which was the very next linux-next release).
> >
> > Not sure why, but my Panda manages to get the VID:PID of the hub as
> > well, while yours does not even get there.
> >
> > I may need a few more hours to debug this, unless someone beats me
> > to it. ;)
>
> Is it caused by the below?
>
> [   46.580200] ehci-omap ehci-omap.0: failed to get ehci port0 regulator
>

Nope. We don't set up any regulators for the PHY on Panda (at least not
yet).

And the working case (next-20101221) has the same log.

I suspect the PHY doesn't get reset for the proper duration; I'm looking
for something in that area. (Another option is to bisect between the two
versions, but I'm not sure if that's any easier).

- Anand
--
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: 4430SDP boot failure

[Santosh Shilimkar]

> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Friday, January 07, 2011 7:55 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure
>
> On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > Have sent you latest bootloaders and full bootlog on my ES1.0
> > OMAP4430SDP. 2.6.37 just boots fine for me.
> >
> > Low level debug as you reported seems to be broken though.
>
> Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
> the board - which should ease the debugging problem as it no longer
> requires anything but the reset button pressed to test a new kernel.

Glad to hear that.

Regards,
Santosh
--
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: 4430SDP boot failure

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> Have sent you latest bootloaders and full bootlog on my ES1.0
> OMAP4430SDP. 2.6.37 just boots fine for me.
> 
> Low level debug as you reported seems to be broken though.

Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
the board - which should ease the debugging problem as it no longer
requires anything but the reset button pressed to test a new kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: RFBI worked example

[Ben Tucker]

With further experimentation it appears that I can call the
omap_rfbi_update() from the call back, but as the callback is in interrupt
context this could be dangerous. I would love to see an example of this
elsewhere.

static void framedone_callback(void *data)
{
int r;
u16 dw, dh;
struct omap_dss_device *dssdev = (struct omap_dss_device *)data;

/* Start the next update, triggered on the external H/VSync signals */
dssdev->driver->get_resolution(dssdev, &dw, &dh);
r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback,
dssdev);
if (r < 0)
printk("omap_rfbi_update FAILED");
}

static int generic_panel_power_on(struct omap_dss_device *dssdev)
{
int r;
u16 dw, dh;

r = omapdss_rfbi_display_enable(dssdev);
if (r < 0)
goto err0;

/* Setup external HSYNC/VSYNC triggering */
r = omap_rfbi_setup_te(OMAP_DSS_RFBI_TE_MODE_2,
   400, /* HSYNS pulse 4uS */
   10,  /* VSYNC pulse 1ms */
   0, 0,   /* H/VSYNC not inverted */
   0);
if (r < 0)
goto err1;

/* Enable external triggering */
r = omap_rfbi_enable_te(1, 0);
if (r < 0)
goto err1;

#if 0
/* At a guess I do not think we need to do the prepare_update
 * if we are updating the whole area
 */
r = omap_rfbi_prepare_update(dssdev, ???);
if (r < 0)
goto err1;
#endif

/* Start the first update, triggered on the external H/VSync siganls.
 * The callback (FRAMEDONE interrupt context) will re-arm this
 * update once more.
 */
dssdev->driver->get_resolution(dssdev, &dw, &dh);
r = omap_rfbi_update(dssdev, 0, 0, dw, dh, framedone_callback,
dssdev);
if (r < 0)
goto err1;


if (dssdev->platform_enable) {
r = dssdev->platform_enable(dssdev);
if (r)
goto err1;
}

return 0;
err1:
omap_rfbi_enable_te(0, 0);
omapdss_dpi_display_disable(dssdev);
err0:
return r;
}




-Original Message-
From: Ben Tucker [mailto:btuc...@mpcdata.com]
Sent: 06 January 2011 15:32
To: 'linux-omap@vger.kernel.org'
Cc: 'tomi.valkei...@nokia.com'
Subject: RFBI worked example



Hi,

I am trying to setup an OMAP3530 based system for RFBI video output using
external triggering. Looking at the omap dss2 source code (and also
searching around) I cannot find any worked example of how to use the rfbi
driver. I know that RFBI has worked in the past for a Nokia N800 device.
Can you dig out any source code that shows how to use the RFBI driver?
In particular I need to see how the omap_rfbi_prepare_update() and
omap_rfbi_update() calls operate with their callback. I am thinking that I
should simply call omap_rfbi_update() in a thread and wait for the
completion call back after each call. I want to confirm that this is the
correct way to run the driver.

Thanks,
Ben



Ben Tucker
Senior Software Engineer
MPC Data Limited
e-mail:   web: www.mpc-data.co.uk
tel: +44 (0) 1225 710600  fax: +44 (0) 1225 710601
ddi: +44 (0) 1225 710660

MPC Data Limited is a company registered in England and Wales with company
number 05507446
Registered Address: County Gate, County Way, Trowbridge, Wiltshire, BA14
7FJ
VAT no: 850625238

The information in this email and in the attached documents is
confidential and may be
legally privileged. Any unauthorized review, copying, disclosure or
distribution is
prohibited and may be unlawful. It is intended solely for the addressee.
Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, please
contact the sender by reply email and destroy all copies of the original
message. When
addressed to our clients any opinions or advice contained in this email is
subject to
the terms and conditions expressed in the governing contract.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: manual merge of the usb tree with the omap tree

[Ming Lei]

Hi Anand,

2011/1/7 Anand Gadiyar :
> Hi Ming Lei,
>
> I'm able to reproduce this on my panda, and I have it working as of
> linux-next-20101221 (the last version I tested last year) and failing
> on linux-next-20101227 (which was the very next linux-next release).
>
> Not sure why, but my Panda manages to get the VID:PID of the hub as
> well, while yours does not even get there.
>
> I may need a few more hours to debug this, unless someone beats me
> to it. ;)

Is it caused by the below?

[   46.580200] ehci-omap ehci-omap.0: failed to get ehci port0 regulator

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

Re: linux-next: manual merge of the usb tree with the omap tree

[Anand Gadiyar]

On 1/6/2011 9:20 PM, Ming Lei wrote:
> Hi,
> 
> 2011/1/6 Ming Lei :
>> Hi,
>>
>> 2011/1/6 Anand Gadiyar :
>>
>>> I'll take a look in a short while. I don't have an XM to
>>> test, so you'll have to help me out here.
>>
>> No problem for me, :-)
> 
> I see why the beagle xM does not work, the attachment patch is
> needed to make it working.
> 
> But the ehci on panda(omap4430) still does not work with
> 2.6.37-next-20110106+, and follows the failure messages:
> 
> [   46.572601] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [   46.580017] ehci_hcd: block sizes: qh 60 qtd 96 itd 160 sitd 96
> [   46.580078] bus: 'platform': add driver ehci-omap
> [   46.580139] bus: 'platform': driver_probe_device: matched device 
> ehci-omap.0 with driver ehci-omap
> [   46.580169] bus: 'platform': really_probe: probing driver ehci-omap with 
> device ehci-omap.0
> [   46.580200] ehci-omap ehci-omap.0: failed to get ehci port0 regulator
> [   46.580200] ehci-omap ehci-omap.0: starting TI EHCI USB Controller
> [   46.580291] ehci-omap ehci-omap.0: OMAP UHH_REVISION 0x50700100
> [   46.580352] ehci-omap ehci-omap.0: TLL RESET DONE
> [   46.580352] ehci-omap ehci-omap.0: UHH setup done, uhh_hostconfig=1c
> [   46.580383] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 
> pcc=3 ordered ports=3
> [   46.580383] ehci-omap ehci-omap.0: reset hcc_params 20016 thresh 1 uframes 
> 256/512/1024 park LPM
> [   46.580383] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
> [   46.588592] drivers/usb/core/inode.c: creating file 'devices'
> [   46.588623] drivers/usb/core/inode.c: creating file '001'
> [   46.588684] device: 'usbmon1': device_add
> [   46.588867] PM: Adding info for No Bus:usbmon1
> [   46.590026] ehci-omap ehci-omap.0: new USB bus registered, assigned bus 
> number 1
> [   46.645721] ehci-omap ehci-omap.0: park 0
> [   46.645721] ehci-omap ehci-omap.0: support lpm
> [   46.645751] ehci-omap ehci-omap.0: irq 109, io mem 0x4a064c00
> [   46.651763] ehci-omap ehci-omap.0: reset command 0080b02  park=3 ithresh=8 
> period=1024 Reset HALT
> [   46.651763] ehci-omap ehci-omap.0: init command 0010005 (park)=0 ithresh=1 
> period=512 RUN
> [   46.661254] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
> [   46.667297] usb usb1: rpm_resume flags 0x0
> [   46.667297] usb usb1: rpm_resume returns 1
> [   46.667358] usb usb1: default language 0x0409
> [   46.667358] usb usb1: udev 1, busnum 1, minor = 0
> [   46.667388] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [   46.675476] usb usb1: New USB device strings: Mfr=3, Product=2, 
> SerialNumber=1
> [   46.683288] usb usb1: Product: OMAP-EHCI Host Controller
> [   46.689086] usb usb1: Manufacturer: Linux 2.6.37-next-20110106+ ehci_hcd
> [   46.696350] usb usb1: SerialNumber: ehci-omap.0
> [   46.701354] device: 'usb1': device_add
> [   46.701568] bus: 'usb': add device usb1
> [   46.701629] PM: Adding info for usb:usb1
> [   46.702758] bus: 'usb': driver_probe_device: matched device usb1 with 
> driver usb
> [   46.702758] bus: 'usb': really_probe: probing driver usb with device usb1
> [   46.702819] usb usb1: usb_probe_device
> [   46.702819] usb usb1: configuration #1 chosen from 1 choice
> [   46.702850] usb usb1: rpm_resume flags 0x4
> [   46.702850] usb usb1: rpm_resume returns 1
> [   46.702911] usb usb1: adding 1-0:1.0 (config #1, interface 0)
> [   46.702911] device: '1-0:1.0': device_add
> [   46.702941] bus: 'usb': add device 1-0:1.0
> [   46.703002] PM: Adding info for usb:1-0:1.0
> [   46.703430] bus: 'usb': driver_probe_device: matched device 1-0:1.0 with 
> driver hub
> [   46.703460] bus: 'usb': really_probe: probing driver hub with device 
> 1-0:1.0
> [   46.703460] hub 1-0:1.0: usb_probe_interface
> [   46.703491] hub 1-0:1.0: usb_probe_interface - got id
> [   46.703491] usb usb1: rpm_resume flags 0x4
> [   46.703491] usb usb1: rpm_resume returns 1
> [   46.703521] hub 1-0:1.0: USB hub found
> [   46.707427] hub 1-0:1.0: 3 ports detected
> [   46.715698] hub 1-0:1.0: standalone hub
> [   46.715698] hub 1-0:1.0: individual port power switching
> [   46.715728] hub 1-0:1.0: individual port over-current protection
> [   46.715728] hub 1-0:1.0: power on to power good time: 20ms
> [   46.715759] hub 1-0:1.0: local power source is good
> [   46.715759] hub 1-0:1.0: enabling power on all ports
> [   46.715820] driver: '1-0:1.0': driver_bound: bound to device 'hub'
> [   46.715820] bus: 'usb': really_probe: bound device 1-0:1.0 to driver hub
> [   46.715850] device: 'ep_81': device_add
> [   46.717468] PM: Adding info for No Bus:ep_81
> [   46.717498] device: 'usbdev1.1': device_add
> [   46.717590] PM: Adding info for No Bus:usbdev1.1
> [   46.717773] drivers/usb/core/inode.c: creating file '001'
> [   46.717803] driver: 'usb1': driver_bound: bound to device 'usb'
> [   46.717803] bus: 'usb': really_probe: bound device usb1 to driver usb
> [   46.717834] device: 'ep_00': device_add
> [   46.717895] PM: Adding info for No Bus:ep

Re: [GIT PULL] OMAP DSS changes for .38 merge window

[Tomi Valkeinen]

On Fri, 2011-01-07 at 22:52 +0900, ext Paul Mundt wrote:

> Hmm, I've just fast-forwarded to Linus's current tree and tried to pull
> your rebase branch in, but it seems to have a board conflict with the
> OMAP tree merge:
> 
> CONFLICT (delete/modify): arch/arm/mach-omap2/board-zoom2.c deleted in HEAD 
> and modified in 122ffebf2191529153c079b457e38ca3829eac40. Version 
> 122ffebf2191529153c079b457e38ca3829eac40 of arch/arm/mach-omap2/board-zoom2.c 
> left in tree.
> 
> Additionally there's a board-zoom.c conflict that looks like this:

Ah. I'll have to fix that. Let's leave this until Monday, as I don't
have a board here to test the fixes.

 Tomi


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

Re: [PATCH] omap3: Add basic support for 720MHz part

[Nishanth Menon]

Premi, Sanjeev wrote, on 01/07/2011 07:50 AM:

-Original Message-
From: Menon, Nishanth
Sent: Friday, January 07, 2011 7:04 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap3: Add basic support for 720MHz part

Sanjeev Premi wrote, on 01/07/2011 07:07 AM:

+   if (omap3_has_720mhz()) {
+   pr_info("Enabled OPP corresponding to

720MHz\n");

+
+   omap34xx_opp_def_list[INDEX_MPU_720MHZ]
+   .default_available = true;
+   omap34xx_opp_def_list[INDEX_IVA_720MHZ]
+   .default_available = true;

for many reasons, I dont like this indexing - I am ok with
most part of
the patch otherwise - how about opp_enable(dev, freq) instead?


I had thought about it, but opp_enable would have to be done after
omap_init_opp_table(). Two factors led me to current implementation:

1) Numer of lines of code required to get same thing done one the
opp table has been initialized.

2) The index definition and usage are localized in same file.


right - i will leave it to kevin to comment - IMHO both will work, 
though (1) might be a little more elgant and resistant to future changes 
to the table (I am not sure if there would be any, but what the heck.)


--
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

Re: [PATCH v5 06/17] OMAP2,3: DSS2: Create new file display.c for central dss driver registration.

[Tomi Valkeinen]

Hi,

On Fri, 2011-01-07 at 16:55 +0530, ext Sumit Semwal wrote:
> A new file display.c is introduced for display driver init, which adds a 
> function
> omap_display_init to do the DSS driver registration. This is the first step 
> in moving
> away registration of DSS from board files into a common place.
> 
> Signed-off-by: Senthilvadivu Guruswamy 
> Signed-off-by: Sumit Semwal 
> ---
>  arch/arm/mach-omap2/Makefile  |2 +
>  arch/arm/mach-omap2/display.c |   57 
> +
>  arch/arm/plat-omap/include/plat/display.h |4 ++
>  3 files changed, 63 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/display.c
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 4ab82f6..57b89e6 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -237,3 +237,5 @@ obj-y += $(smc91x-m) 
> $(smc91x-y)
>  
>  smsc911x-$(CONFIG_SMSC911X)  := gpmc-smsc911x.o
>  obj-y+= $(smsc911x-m) $(smsc911x-y)
> +
> +obj-y+= display.o
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> new file mode 100644
> index 000..26d3feb
> --- /dev/null
> +++ b/arch/arm/mach-omap2/display.c
> @@ -0,0 +1,57 @@
> +/*
> + * OMAP2plus display device setup / initialization.
> + *
> + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
> + *   Senthilvadivu Guruswamy
> + *  Sumit Semwal
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This 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 
> +
> +#ifdef CONFIG_OMAP2_DSS

This also needs to be built in when DSS is configured as module. The
define above is only valid when DSS is configured as built-in.

So you can either check for both CONFIG_OMAP2_DSS and
CONFIG_OMAP2_DSS_MODULE here, or, I think a bit more cleanly:

- Compile display.c only if CONFIG_OMAP2_DSS[_MODULE] is defined (see
the Makefile, look for example how i2c-omap is handled).
- Check for CONFIG_OMAP2_DSS[_MODULE] in the header file, and define an
empty static inline function for omap_display_init() if DSS is disabled.

 Tomi


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

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 02:07:53PM +0100, Koen Kooi wrote:
> Op 7 jan 2011, om 13:51 heeft Russell King - ARM Linux het volgende 
> geschreven:
> > This is the command line I've been giving it:
> > 
> > setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G 
> > console=ttyO2,115200n8 rootdelay=2'
> 
> Why are people still using rootdelay? 'rootwait' is vastly superior and 
> doesn't need tweaking for every card/controller combo.

Does it matter if the effect it produces works?
--
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: [GIT PULL] OMAP DSS changes for .38 merge window

[Paul Mundt]

On Fri, Jan 07, 2011 at 03:37:32PM +0200, Tomi Valkeinen wrote:
> On Fri, 2011-01-07 at 22:25 +0900, ext Paul Mundt wrote:
> I guess it's not out-of-the-question to get driver changes in in early
> rcs, but I'd rather get everything pulled during the merge window. Also,
> some of the patches still out there touch OMAP's arch/ files, so they
> are not plain driver changes.
> 
As long as all the new and big stuff goes in for -rc1 it's certainly fine
to take care of the rest over the next few rc releases. Things do
invariably break when multiple trees are being merged, so it's to be
expected.

> > Looking at the change in question, it's just a correctness fix and
> > doesn't impact the API from the driver point of view, so at least there
> > won't be build damage if they're out of sync for a couple of days
> > (although it may trigger some nasty surprises for anyone unlucky enough
> > to bisect in the middle).
> > 
> > In any event, unless you absolutely need the change to be upstream first,
> > I'll plan to pull the rebase branch. If you need it there earlier we can
> > probably also just prod Andrew and get that one patch off earlier than
> > the rest of the -mm bits.
> 
> No, the fix is not needed urgently. The memblock fix is only important
> for some rare use cases, which I don't think anyone is currently using
> (allocating video memory from SDRAM at a predefined address).
> 
Hmm, I've just fast-forwarded to Linus's current tree and tried to pull
your rebase branch in, but it seems to have a board conflict with the
OMAP tree merge:

CONFLICT (delete/modify): arch/arm/mach-omap2/board-zoom2.c deleted in HEAD and 
modified in 122ffebf2191529153c079b457e38ca3829eac40. Version 
122ffebf2191529153c079b457e38ca3829eac40 of arch/arm/mach-omap2/board-zoom2.c 
left in tree.

Additionally there's a board-zoom.c conflict that looks like this:

diff --cc arch/arm/mach-omap2/board-zoom.c
index e041c53,1523369..000
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@@ -118,29 -113,17 +118,36 @@@ static const struct ehci_hcd_omap_platf
  
  static void __init omap_zoom_init(void)
  {
 -  omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
 -  zoom_peripherals_init();
 +  if (machine_is_omap_zoom2()) {
 +  omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
 +  } else if (machine_is_omap_zoom3()) {
 +  omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
 +  omap_mux_init_gpio(ZOOM3_EHCI_RESET_GPIO, OMAP_PIN_OUTPUT);
 +  usb_ehci_init(&ehci_pdata);
 +  }
 +
board_nand_init(zoom_nand_partitions,
 -   ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
 +  ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
zoom_debugboard_init();
++<<< HEAD:arch/arm/mach-omap2/board-zoom.c
 +  zoom_peripherals_init();
++===
+   zoom_display_init();
+ 
+   omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
+   usb_ehci_init(&ehci_pdata);
++>>> 
122ffebf2191529153c079b457e38ca3829eac40:arch/arm/mach-omap2/board-zoom3.c
  }
  
 +MACHINE_START(OMAP_ZOOM2, "OMAP Zoom2 board")
 +  .boot_params= 0x8100,
 +  .map_io = omap3_map_io,
 +  .reserve= omap_reserve,
 +  .init_irq   = omap_zoom_init_irq,
 +  .init_machine   = omap_zoom_init,
 +  .timer  = &omap_timer,
 +MACHINE_END
 +
  MACHINE_START(OMAP_ZOOM3, "OMAP Zoom3 board")
.boot_params= 0x8100,
.map_io = omap3_map_io,
* Unmerged path arch/arm/mach-omap2/board-zoom2.c

It looks like there has been some consolidation work based on the last commit,
but I'll leave it to you to decide how to handle.
--
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: Add basic support for 720MHz part

[Premi, Sanjeev]

> -Original Message-
> From: Menon, Nishanth 
> Sent: Friday, January 07, 2011 7:04 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH] omap3: Add basic support for 720MHz part
> 
> Sanjeev Premi wrote, on 01/07/2011 07:07 AM:
> > +   if (omap3_has_720mhz()) {
> > +   pr_info("Enabled OPP corresponding to 
> 720MHz\n");
> > +
> > +   omap34xx_opp_def_list[INDEX_MPU_720MHZ]
> > +   .default_available = true;
> > +   omap34xx_opp_def_list[INDEX_IVA_720MHZ]
> > +   .default_available = true;
> for many reasons, I dont like this indexing - I am ok with 
> most part of 
> the patch otherwise - how about opp_enable(dev, freq) instead?

I had thought about it, but opp_enable would have to be done after
omap_init_opp_table(). Two factors led me to current implementation:

1) Numer of lines of code required to get same thing done one the
   opp table has been initialized.

2) The index definition and usage are localized in same file.

> 
> -- 
> 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

Re: 4430SDP boot failure

[Koen Kooi]

Op 7 jan 2011, om 13:51 heeft Russell King - ARM Linux het volgende geschreven:
> This is the command line I've been giving it:
> 
> setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G 
> console=ttyO2,115200n8 rootdelay=2'

Why are people still using rootdelay? 'rootwait' is vastly superior and doesn't 
need tweaking for every card/controller combo.

regards,

Koen--
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: [GIT PULL] OMAP DSS changes for .38 merge window

[Tomi Valkeinen]

On Fri, 2011-01-07 at 22:25 +0900, ext Paul Mundt wrote:
> On Fri, Jan 07, 2011 at 02:41:43PM +0200, Tomi Valkeinen wrote:
> > Hello Paul,
> > 
> > Here are some OMAP display changes for .38. I hope they are not too
> > late, but the holidays messed up my schedules a bit.
> > 
> No, no problem. I usually aim to do two merges per merge window on
> average, one at the beginning and one nearer the end. There are often
> many patches that have dependencies that are blocked while other trees
> merge that get sent off when their dependencies have been met.

Ok, good. There are still some patches going around reviews that would
be nice to get in .38, but time is running short so I decided to send
the current patches.

I guess it's not out-of-the-question to get driver changes in in early
rcs, but I'd rather get everything pulled during the merge window. Also,
some of the patches still out there touch OMAP's arch/ files, so they
are not plain driver changes.

> 
> > I made two branches, as I'm not sure which is better:
> > 
> > for-paul-38 - This one is the original non-rebased branch. This causes a
> > trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M
> > is the right one), and also it contains a patch (memblock: fix
> > memblock_is_region_memory()) which is not yet in mainline, but is in
> > Andrew Morton's tree.
> > 
> > for-paul-38-rebased - The above branch rebased on top of v2.6.37, and
> > the memblock commit removed.
> > 
> > Which one you prefer? Or is there some other way I should handle this?
> > 
> > I could merge v2.6.37 to my branch, which would remove the conflict, but
> > that would still leave the memblock patch. I guess the patch is going in
> > soon, but as it's not in my area, I don't feel it's right to get it in
> > via my patch set. Alternatively I could wait until the patch is in
> > Linus' tree, but that could make it tight to be in time for the merge
> > window.
> > 
> Andrew usually patch-bombs near the end of the window, so it's generally
> a good idea to have things settled before then. In this case if the patch
> is already destined for mainline then I can just pull the rebased branch,
> send that out, and then once -mm syncs up everything should be good to go
> for -rc1.
> 
> Looking at the change in question, it's just a correctness fix and
> doesn't impact the API from the driver point of view, so at least there
> won't be build damage if they're out of sync for a couple of days
> (although it may trigger some nasty surprises for anyone unlucky enough
> to bisect in the middle).
> 
> In any event, unless you absolutely need the change to be upstream first,
> I'll plan to pull the rebase branch. If you need it there earlier we can
> probably also just prod Andrew and get that one patch off earlier than
> the rest of the -mm bits.

No, the fix is not needed urgently. The memblock fix is only important
for some rare use cases, which I don't think anyone is currently using
(allocating video memory from SDRAM at a predefined address).

 Tomi


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

Re: [PATCH] omap3: Add basic support for 720MHz part

[Nishanth Menon]

Sanjeev Premi wrote, on 01/07/2011 07:07 AM:

+   if (omap3_has_720mhz()) {
+   pr_info("Enabled OPP corresponding to 720MHz\n");
+
+   omap34xx_opp_def_list[INDEX_MPU_720MHZ]
+   .default_available = true;
+   omap34xx_opp_def_list[INDEX_IVA_720MHZ]
+   .default_available = true;
for many reasons, I dont like this indexing - I am ok with most part of 
the patch otherwise - how about opp_enable(dev, freq) instead?


--
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

Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP

[Nishanth Menon]

Aaro Koskinen wrote, on 01/07/2011 07:04 AM:


On Wed, 5 Jan 2011, Nishanth Menon wrote:

+static void __init beagle_opp_init(void)
+{
+ int r = 0;
+
+ /* Initialize the omap3 opp table */
+ if (omap3_opp_init()) {
+ pr_err("%s: opp default init failed\n", __func__);
+ return;
+ }
+
+ /* Custom OPP enabled for XM */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
+ struct omap_hwmod *dh = omap_hwmod_lookup("iva");
+ struct device *dev;
+
+ if (!mh || !dh) {
+ pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
+ __func__, mh, dh);
+ r = -EINVAL;
+ } else {
+ /* Enable MPU 1GHz and lower opps */
+ dev = &mh->od->pdev.dev;
+ r = opp_enable(dev, 8);
+ /* TODO: MPU 1GHz needs SR and ABB */
+
+ /* Enable IVA 800MHz and lower opps */
+ dev = &dh->od->pdev.dev;
+ r |= opp_enable(dev, 66000);
+ /* TODO: DSP 800MHz needs SR and ABB */
+ }
+ if (r) {
+ pr_err("%s: failed to enable higher opp %d\n",
+ __func__, r);
+ /*
+ * Cleanup - disable the higher freqs - we dont care
+ * about the results
+ */
+ dev = &mh->od->pdev.dev;
+ opp_disable(dev, 8);
+ dev = &dh->od->pdev.dev;


This branch will be reached also when !mh || !dh, so it won't work.


arrgh.. thanks for catching it - will fix and repost.

--
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

Re: [GIT PULL] OMAP DSS changes for .38 merge window

[Paul Mundt]

On Fri, Jan 07, 2011 at 02:41:43PM +0200, Tomi Valkeinen wrote:
> Hello Paul,
> 
> Here are some OMAP display changes for .38. I hope they are not too
> late, but the holidays messed up my schedules a bit.
> 
No, no problem. I usually aim to do two merges per merge window on
average, one at the beginning and one nearer the end. There are often
many patches that have dependencies that are blocked while other trees
merge that get sent off when their dependencies have been met.

> I made two branches, as I'm not sure which is better:
> 
> for-paul-38 - This one is the original non-rebased branch. This causes a
> trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M
> is the right one), and also it contains a patch (memblock: fix
> memblock_is_region_memory()) which is not yet in mainline, but is in
> Andrew Morton's tree.
> 
> for-paul-38-rebased - The above branch rebased on top of v2.6.37, and
> the memblock commit removed.
> 
> Which one you prefer? Or is there some other way I should handle this?
> 
> I could merge v2.6.37 to my branch, which would remove the conflict, but
> that would still leave the memblock patch. I guess the patch is going in
> soon, but as it's not in my area, I don't feel it's right to get it in
> via my patch set. Alternatively I could wait until the patch is in
> Linus' tree, but that could make it tight to be in time for the merge
> window.
> 
Andrew usually patch-bombs near the end of the window, so it's generally
a good idea to have things settled before then. In this case if the patch
is already destined for mainline then I can just pull the rebased branch,
send that out, and then once -mm syncs up everything should be good to go
for -rc1.

Looking at the change in question, it's just a correctness fix and
doesn't impact the API from the driver point of view, so at least there
won't be build damage if they're out of sync for a couple of days
(although it may trigger some nasty surprises for anyone unlucky enough
to bisect in the middle).

In any event, unless you absolutely need the change to be upstream first,
I'll plan to pull the rebase branch. If you need it there earlier we can
probably also just prod Andrew and get that one patch off earlier than
the rest of the -mm 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

Re: [PATCH v5 00/17] OMAP2,3: hwmod DSS Adaptation

[Tomi Valkeinen]

Hi,

Ah, I just noticed (thanks Nishanth) that you've sent a pull request,
and these patches apply fine on top of the omap-for-linus branch. I'll
use that as a base.

 Tomi

On Fri, 2011-01-07 at 14:56 +0200, Tomi Valkeinen wrote:
> Hi Tony,
> 
> The patch set below is based on l-o tree, as it touches OMAP
> hwmod/clock/board stuff. It doesn't even apply to my mainline based
> tree.
> 
> I'm still in the process of reviewing the latest changes, but is it ok
> for you to apply these to your tree after I've acked the DSS parts? Or
> do you have a stable branch (going to Linus soon) that I can use as a
> base?
> 
>  Tomi
> 
> On Fri, 2011-01-07 at 16:55 +0530, ext Sumit Semwal wrote:
> > v4 of the DSS hwmod patch series focusses on fixing the review comments. 
> > OMAP4 
> > hwmod support will be posted after the acceptance of this basic change in
> > the dss2 design.
> > 
> > This patch series decouples the "Clocks for DSS in hwmod adaptation" changes
> > from this series.  Another series would be posted which could be discussed
> > w.r.t clocks in DSS across omap2,3.
> > 
> > Removing the SYSCONFIG settings from DSS driver would also be part of these
> > clock changes series and not covered in this series as it depends on some of
> > the omap_hwmod framework changes w.r.t opt clocks handling.
> > 
> > Summary of the hwmod DSS design:
> > 
> > DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each 
> > corresponding to the hwmod class in the hwmod database. 
> > 
> > Each of these platform drivers' init / deinit are handled from core.c's
> > omap_dss_probe() in the exact sequence as required.
> > 
> > No Hardcoding of silicon data:
> > hwmod database abstracts the SOC data like base addr, irq numbers and are
> > implemented in this patch series.
> > 
> > Continue to have custom bus for display panels:
> > "omapdss" driver continues to be a platform driver that registers the custom
> > bus.  It also continues to register the display panels(omap_dss_device) on 
> > the
> > board to the panel drivers (omap_dss_driver)
> > For Eg:  primary lcd device would be registered with lcd panel driver.
> > lcd panel driver if it is on a parallel interface would use library 
> > functions 
> > exported from dpi.o.  if it is on a dsi interface would use library 
> > functions
> > exported from dsi platform driver(dsi.o).
> > 
> > Clocks:
> > Handling of clocks in DSS only is one of the design approaches, that does 
> > not
> > change the existing implementation.  If each of the DSS HW IPs had to handle
> > their own clocks, then corresponding clock changes can be requested in the 
> > hwmod
> > database as well which is not the current design/implementation.  As 
> > stated, 
> > this would be handled in another series seperately.
> > For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now 
> > apart
> > for the dss main clocks.  Currently VENC driver needs to be aware of this 
> > and has to
> > use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 
> > 54MCLK.
> > 
> > 
> > 
> > Current dss driver:
> > ---
> > 1.  Omapdss platform driver
> > - initialises necessary Ips dss, dispc.
> > - also initialises Ips like sdi, dsi, venc, rfbi
> > - creates a custom bus and registers the display devices/drivers
> > connected on the board to the custom bus.
> > 
> > 2.  Suspend/resume of omapdss
> > - in turn sends suspend/resume calls for each of the display devices
> > registered to it.
> > 
> > Modified change:
> > ---
> > Platform driver for each DSS HW IP in addition to the software "omapdss"
> > driver.
> > 
> > Omapdss platform driver
> > - initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, 
> > venc, rfbi]
> >   and software libraries like dpi, sdi.
> > - continues to have a custom bus and registers the display devices 
> > and drivers connected on the board to the custom bus.
> > - continues to handle suspend/resume of the display devices 
> > registered
> > to the custom bus.
> > 
> > DSS platform driver
> > - initialises DSS IP alone
> > - Handles the clocks related to the DSS and other DSSHW IPs like RFBI,
> > DSI, VENC, DISPC.  Previously this was a part of "omapdss" driver in 
> > core.c
> > - Continues to handle the DSS IRQs.
> > - No suspend/resume hooks.
> > 
> > DISPC platform driver
> > - initialises DISPC IP alone
> > - Gets the required clock from DSS platform driver.
> > - No suspend/resume hooks.
> > - Continues to provide DISPC library functions.
> > 
> > DSI platform driver
> > - initialises DSI IP alone
> > - Gets the required clock from DSS platform driver.
> > - No suspend/resume hooks.
> > - Continues to provide DSI library functions.
> > 
> > RFBI, VENC platform drivers
> > - initialises DSI,VENC IPs
> > - Gets the required 

Re: Build breakage with omap2plus_defconfig

[Felipe Balbi]

Hi,

On Fri, Jan 07, 2011 at 06:35:39PM +0530, Santosh Shilimkar wrote:
> This patch is good but it does tell you that if
> you will V6 and v7 together, the feature can't be used.
> 
> Like omap2plus_defconfig, and if booted on
> say omap3 or omap4(v7), swp emulation can't be used
> even though its supported.

Sure, I got that from the patch, but we don't have any other simpler
solution currently. And it's indeed a shame we can't support multi-omap
anymore :-(

-- 
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: 4430SDP boot failure

[Santosh Shilimkar]

> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Friday, January 07, 2011 6:22 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure
>
> On Fri, Jan 07, 2011 at 05:48:41PM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
> > > Sent: Friday, January 07, 2011 3:23 PM
> > Ruessell,
> >
> >
> > > To: Russell King - ARM Linux
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: RE: 4430SDP boot failure
> > >
> >
> > []
> >
> > > > BTW, if it makes any difference to the boot loader, please
> note
> > > that
> > > > I'm
> > > > still waiting for the upgrade for the SDP board.
> > > That means your board is with ES1.0. I shall try 2.6.37 on
> > > ES1.0
> >
> > ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing
> an
> > issue. The console is changed to OMAP serial driver from 8250
> > driver.
> >
> > Can you try "console=ttyO2" instead of existing ""console=ttyS2"
> ??
>
> This is the command line I've been giving it:
>
> setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G
> console=ttyO2,115200n8 rootdelay=2'
>
> and in my .config, I have:
>
> CONFIG_SERIAL_OMAP=y
> CONFIG_SERIAL_OMAP_CONSOLE=y
>
Yep. Noticed that after the post.

> so the driver is also enabled.  I found this on the 3430LDP, and so
> switched both OMAP3 and OMAP4 stuff over to the new driver.
>
> That wouldn't explain why I'm getting the "X-loader hangs" message
> which brings everything to a halt, and why the low level debug stuff
> doesn't work.

Have sent you latest bootloaders and full bootlog on my ES1.0
OMAP4430SDP. 2.6.37 just boots fine for me.

Low level debug as you reported seems to be broken though.

Regards,
Santosh
--
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: Add basic support for 720MHz part

[Sanjeev Premi]

This patch adds support for new speed enhanced parts with ARM
and IVA running at 720MHz and 520MHz respectively. These parts
can be probed at run-time by reading PRODID.SKUID[3:0] at
0x4830A20C [1].

This patch specifically does following:
 * Detect devices capable of 720MHz.
 * Add new OPP
 * Ensure that OPP is conditionally enabled.

The patch was tested on OMAP3EVM.

On 720MHz capable device:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
72

On other devices:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
60

  [1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf

Signed-off-by: Sanjeev Premi 
---
 arch/arm/mach-omap2/control.h |7 +++
 arch/arm/mach-omap2/id.c  |   10 ++
 arch/arm/mach-omap2/opp3xxx_data.c|   19 ++-
 arch/arm/plat-omap/include/plat/cpu.h |2 ++
 4 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f0629ae..eebc045 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -365,6 +365,13 @@
 #defineFEAT_NEON   0
 #defineFEAT_NEON_NONE  1
 
+/*
+ * Product ID register
+ */
+#define OMAP3_PRODID   0x020C
+
+#define OMAP3_SKUID_MASK   0x0f
+#defineOMAP3_SKUID_720MHZ  0x08
 
 #ifndef __ASSEMBLY__
 #ifdef CONFIG_ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..53fbe01 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -195,6 +195,15 @@ static void __init omap3_check_features(void)
 * TODO: Get additional info (where applicable)
 *   e.g. Size of L2 cache.
 */
+
+   /*
+* Does it support 720MHz?
+*/
+   status = (OMAP3_SKUID_MASK & read_tap_reg(OMAP3_PRODID));
+
+   if (status & OMAP3_SKUID_720MHZ) {
+   omap3_features |= OMAP3_HAS_720MHZ;
+   }
 }
 
 static void __init omap3_check_revision(void)
@@ -445,6 +454,7 @@ static void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
OMAP3_SHOW_FEATURE(192mhz_clk);
+   OMAP3_SHOW_FEATURE(720mhz);
 
printk(")\n");
 }
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c 
b/arch/arm/mach-omap2/opp3xxx_data.c
index 0486fce..01582b7 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -22,6 +22,9 @@
 
 #include "omap_opp_data.h"
 
+#define INDEX_MPU_720MHZ   5
+#define INDEX_IVA_720MHZ   14
+
 static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
/* MPU OPP1 */
OPP_INITIALIZER("mpu", true, 12500, 975000),
@@ -33,6 +36,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[] 
= {
OPP_INITIALIZER("mpu", true, 55000, 127),
/* MPU OPP5 */
OPP_INITIALIZER("mpu", true, 6, 135),
+   /* MPU OPP6 */
+   OPP_INITIALIZER("mpu", false, 72000, 135),
 
/*
 * L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -58,6 +63,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[] 
= {
OPP_INITIALIZER("iva", true, 4, 127),
/* DSP OPP5 */
OPP_INITIALIZER("iva", true, 43000, 135),
+   /* DSP OPP6 */
+   OPP_INITIALIZER("iva", false, 52000, 135),
 };
 
 static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
@@ -98,9 +105,19 @@ static int __init omap3_opp_init(void)
if (cpu_is_omap3630())
r = omap_init_opp_table(omap36xx_opp_def_list,
ARRAY_SIZE(omap36xx_opp_def_list));
-   else
+   else {
+   if (omap3_has_720mhz()) {
+   pr_info("Enabled OPP corresponding to 720MHz\n");
+
+   omap34xx_opp_def_list[INDEX_MPU_720MHZ]
+   .default_available = true;
+   omap34xx_opp_def_list[INDEX_IVA_720MHZ]
+   .default_available = true;
+   }
+
r = omap_init_opp_table(omap34xx_opp_def_list,
ARRAY_SIZE(omap34xx_opp_def_list));
+   }
 
return r;
 }
diff --git a/arch/arm/plat-omap/include/plat/cpu.h 
b/arch/arm/plat-omap/include/plat/cpu.h
index 3fd8b40..5c77987 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -455,6 +455,7 @@ extern u32 omap3_features;
 #define OMAP3_HAS_ISP  BIT(4)
 #define OMAP3_HAS_192MHZ_CLK   BIT(5)
 #define OMAP3_HAS_IO_WAKEUPBIT(6)
+#define OMAP3_HAS_720MHZ   BIT(7)
 
 #define OMAP3_HAS_FEATURE(feat,flag)   \
 static inline unsigned int omap3_has_ ##feat(void) \
@@ -469,5 +470,6 @@ OMAP3_HAS_FEATURE(neon, NEON)
 OMAP3_HAS_FEATURE(isp, ISP)
 OMAP3_HAS_FEATURE(192mhz_clk, 

RE: Build breakage with omap2plus_defconfig

[Santosh Shilimkar]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Felipe Balbi
> Sent: Friday, January 07, 2011 6:30 PM
> To: Santosh Shilimkar
> Cc: ba...@ti.com; Russell King; Tony Lindgren; Linux OMAP Mailing
> List; Linux ARM Kernel Mailing List
> Subject: Re: Build breakage with omap2plus_defconfig
>
> On Fri, Jan 07, 2011 at 06:18:51PM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > > ow...@vger.kernel.org] On Behalf Of Felipe Balbi
> > > Sent: Friday, January 07, 2011 6:09 PM
> > > To: Russell King; Tony Lindgren
> > > Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List
> > > Subject: Build breakage with omap2plus_defconfig
> > >
> > > Hi all,
> > >
> > > Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63)
> fails
> > > to
> > > build with omap2plus_defconfig:
> > >
> > > $ crossmake
> > >   CHK include/linux/version.h
> > >   CHK include/generated/utsrelease.h
> > > make[1]: `include/generated/mach-types.h' is up to date.
> > >   CALLscripts/checksyscalls.sh
> > >   CHK include/generated/compile.h
> > >   CC  arch/arm/kernel/swp_emulate.o
> > > /tmp/cc2V7p5j.s: Assembler messages:
> > > /tmp/cc2V7p5j.s:161: Error: selected processor does not support
> ARM
> > > mode `ldrexb r3,[r4]'
> > > /tmp/cc2V7p5j.s:162: Error: selected processor does not support
> ARM
> > > mode `strexb r0,r2,[r4]'
> >
> > Well it's not toolchain issue but the omap2plus_defconfig which
> > selects ARMv6 and ARMV7 together.
> >
> > If you remove ARCH_OMAP2 from build, it will go through.
>
> I like Catalin's approach:
>
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 49db8b3..0fe2389 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -644,7 +644,7 @@ config ARM_THUMBEE
>
>  config SWP_EMULATE
> bool "Emulate SWP/SWPB instructions"
> -   depends on CPU_V7
> +   depends on CPU_V7 && !CPU_V6
> select HAVE_PROC_CPU if PROC_FS
> default y if SMP
> help
>
> Simple.
>
This patch is good but it does tell you that if
you will V6 and v7 together, the feature can't be used.

Like omap2plus_defconfig, and if booted on
say omap3 or omap4(v7), swp emulation can't be used
even though its supported.

Regards,
Santosh
--
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] OMAP3: beagle xm: enable upto 800MHz OPP

[Aaro Koskinen]

Hi,

On Wed, 5 Jan 2011, Nishanth Menon wrote:

+static void __init beagle_opp_init(void)
+{
+   int r = 0;
+
+   /* Initialize the omap3 opp table */
+   if (omap3_opp_init()) {
+   pr_err("%s: opp default init failed\n", __func__);
+   return;
+   }
+
+   /* Custom OPP enabled for XM */
+   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+   struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
+   struct omap_hwmod *dh = omap_hwmod_lookup("iva");
+   struct device *dev;
+
+   if (!mh || !dh) {
+   pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
+   __func__, mh, dh);
+   r = -EINVAL;
+   } else {
+   /* Enable MPU 1GHz and lower opps */
+   dev = &mh->od->pdev.dev;
+   r = opp_enable(dev, 8);
+   /* TODO: MPU 1GHz needs SR and ABB */
+
+   /* Enable IVA 800MHz and lower opps */
+   dev = &dh->od->pdev.dev;
+   r |= opp_enable(dev, 66000);
+   /* TODO: DSP 800MHz needs SR and ABB */
+   }
+   if (r) {
+   pr_err("%s: failed to enable higher opp %d\n",
+   __func__, r);
+   /*
+* Cleanup - disable the higher freqs - we dont care
+* about the results
+*/
+   dev = &mh->od->pdev.dev;
+   opp_disable(dev, 8);
+   dev = &dh->od->pdev.dev;


This branch will be reached also when !mh || !dh, so it won't work.


+   opp_disable(dev, 66000);
+   }
+   }
+}


A.
--
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: omap: Beagle: detect new xM revision B

[Nishanth Menon]

Koen Kooi wrote, on 01/07/2011 03:10 AM:

From: Robert Nelson

The xM B uses a DM3730 ES1.1 over the ES1.0 on xM A's, no other board changes.


unrelated to patch: funny why the GPIO version changed then!

related to patch: please add [PATCH] in $subject.. minor comment follows:



Signed-off-by: Robert Nelson
Signed-off-by: Koen Kooi
---
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7c82730..4fd73e7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -58,7 +58,8 @@
   *AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
   *C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
   *C4  = GPIO173, GPIO172, GPIO171: 1 0 1
- * XM  = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMA = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMB = GPIO173, GPIO172, GPIO171: 0 0 1
   */
  enum {
OMAP3BEAGLE_BOARD_UNKN = 0,
@@ -117,7 +118,11 @@ static void __init omap3_beagle_init_rev(void)
omap3_beagle_version = OMAP3BEAGLE_BOARD_C4;
break;
case 0:
-   printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
+   printk(KERN_INFO "OMAP3 Beagle Rev: xM A\n");
+   omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
+   break;
+   case 1:
+   printk(KERN_INFO "OMAP3 Beagle Rev: xM B\n");


could you replace printk(KERN_INFO with pr_info?

omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
break;
default:
--
cgit v0.8.3.1-30-gff3a
--
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



--
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

Re: Build breakage with omap2plus_defconfig

[Felipe Balbi]

On Fri, Jan 07, 2011 at 06:18:51PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Felipe Balbi
> > Sent: Friday, January 07, 2011 6:09 PM
> > To: Russell King; Tony Lindgren
> > Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List
> > Subject: Build breakage with omap2plus_defconfig
> >
> > Hi all,
> >
> > Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails
> > to
> > build with omap2plus_defconfig:
> >
> > $ crossmake
> >   CHK include/linux/version.h
> >   CHK include/generated/utsrelease.h
> > make[1]: `include/generated/mach-types.h' is up to date.
> >   CALLscripts/checksyscalls.sh
> >   CHK include/generated/compile.h
> >   CC  arch/arm/kernel/swp_emulate.o
> > /tmp/cc2V7p5j.s: Assembler messages:
> > /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM
> > mode `ldrexb r3,[r4]'
> > /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM
> > mode `strexb r0,r2,[r4]'
> 
> Well it's not toolchain issue but the omap2plus_defconfig which
> selects ARMv6 and ARMV7 together.
> 
> If you remove ARCH_OMAP2 from build, it will go through.

I like Catalin's approach:

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 49db8b3..0fe2389 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -644,7 +644,7 @@ config ARM_THUMBEE
 
 config SWP_EMULATE
bool "Emulate SWP/SWPB instructions"
-   depends on CPU_V7
+   depends on CPU_V7 && !CPU_V6
select HAVE_PROC_CPU if PROC_FS
default y if SMP
help

Simple.

-- 
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: Latest regressions

[Nishanth Menon]

Russell King - ARM Linux wrote, on 01/07/2011 05:57 AM:

In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:37,
  from arch/arm/mach-omap2/io.c:45:
arch/arm/plat-omap/include/plat/voltage.h: In function 
■omap_voltage_register_pmic■:
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in 
function returning non-void

which gets spammed out all through the build.  voltage.h:137 says:

static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
 struct omap_volt_pmic_info *pmic_info) {}

but no one checks the return value for this:

arch/arm/mach-omap2/omap_twl.c: 
omap_voltage_register_pmic(voltdm,&omap4_mpu_volt_info);
arch/arm/mach-omap2/omap_twl.c: 
omap_voltage_register_pmic(voltdm,&omap4_iva_volt_info);
arch/arm/mach-omap2/omap_twl.c: 
omap_voltage_register_pmic(voltdm,&omap4_core_volt_info);
arch/arm/mach-omap2/omap_twl.c: 
omap_voltage_register_pmic(voltdm,&omap3_mpu_volt_info);
arch/arm/mach-omap2/omap_twl.c: 
omap_voltage_register_pmic(voltdm,&omap3_core_volt_info);

so I don't see the point of it returning an 'int'.
intent was that in the future the volt_info would be validated and users 
will check as well.



--
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

Re: Build breakage with omap2plus_defconfig

[Felipe Balbi]

On Fri, Jan 07, 2011 at 06:20:43PM +0530, Anand Gadiyar wrote:
> Felipe Balbi wrote:
> > Hi all,
> >
> > Today's Linus' tree
> > (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to
> > build with omap2plus_defconfig:
> >
> > $ crossmake
> >   CHK include/linux/version.h
> >   CHK include/generated/utsrelease.h
> > make[1]: `include/generated/mach-types.h' is up to date.
> >   CALLscripts/checksyscalls.sh
> >   CHK include/generated/compile.h
> >   CC  arch/arm/kernel/swp_emulate.o
> > /tmp/cc2V7p5j.s: Assembler messages:
> > /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode
> `ldrexb r3,[r4]'
> > /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode
> `strexb r0,r2,[r4]'
> > make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
> > make: *** [arch/arm/kernel] Error 2
> 
> I haven't found a way around this other than to turn off
> CONFIG_SWP_EMULATE. Here's a patch doing that [1].
> 
> The discussion thread is here [2].

Thanks a lot Anand :-)

-- 
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 v5 00/17] OMAP2,3: hwmod DSS Adaptation

[Tomi Valkeinen]

Hi Tony,

The patch set below is based on l-o tree, as it touches OMAP
hwmod/clock/board stuff. It doesn't even apply to my mainline based
tree.

I'm still in the process of reviewing the latest changes, but is it ok
for you to apply these to your tree after I've acked the DSS parts? Or
do you have a stable branch (going to Linus soon) that I can use as a
base?

 Tomi

On Fri, 2011-01-07 at 16:55 +0530, ext Sumit Semwal wrote:
> v4 of the DSS hwmod patch series focusses on fixing the review comments. 
> OMAP4 
> hwmod support will be posted after the acceptance of this basic change in
> the dss2 design.
> 
> This patch series decouples the "Clocks for DSS in hwmod adaptation" changes
> from this series.  Another series would be posted which could be discussed
> w.r.t clocks in DSS across omap2,3.
> 
> Removing the SYSCONFIG settings from DSS driver would also be part of these
> clock changes series and not covered in this series as it depends on some of
> the omap_hwmod framework changes w.r.t opt clocks handling.
> 
> Summary of the hwmod DSS design:
> 
> DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each 
> corresponding to the hwmod class in the hwmod database. 
> 
> Each of these platform drivers' init / deinit are handled from core.c's
> omap_dss_probe() in the exact sequence as required.
> 
> No Hardcoding of silicon data:
> hwmod database abstracts the SOC data like base addr, irq numbers and are
> implemented in this patch series.
> 
> Continue to have custom bus for display panels:
> "omapdss" driver continues to be a platform driver that registers the custom
> bus.  It also continues to register the display panels(omap_dss_device) on the
> board to the panel drivers (omap_dss_driver)
> For Eg:  primary lcd device would be registered with lcd panel driver.
> lcd panel driver if it is on a parallel interface would use library functions 
> exported from dpi.o.  if it is on a dsi interface would use library functions
> exported from dsi platform driver(dsi.o).
> 
> Clocks:
> Handling of clocks in DSS only is one of the design approaches, that does not
> change the existing implementation.  If each of the DSS HW IPs had to handle
> their own clocks, then corresponding clock changes can be requested in the 
> hwmod
> database as well which is not the current design/implementation.  As stated, 
> this would be handled in another series seperately.
> For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now 
> apart
> for the dss main clocks.  Currently VENC driver needs to be aware of this and 
> has to
> use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK.
> 
> 
> 
> Current dss driver:
> ---
> 1.  Omapdss platform driver
> - initialises necessary Ips dss, dispc.
> - also initialises Ips like sdi, dsi, venc, rfbi
> - creates a custom bus and registers the display devices/drivers
> connected on the board to the custom bus.
> 
> 2.  Suspend/resume of omapdss
> - in turn sends suspend/resume calls for each of the display devices
> registered to it.
> 
> Modified change:
> ---
> Platform driver for each DSS HW IP in addition to the software "omapdss"
> driver.
> 
> Omapdss platform driver
> - initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, 
> venc, rfbi]
> and software libraries like dpi, sdi.
> - continues to have a custom bus and registers the display devices 
> and drivers connected on the board to the custom bus.
> - continues to handle suspend/resume of the display devices registered
> to the custom bus.
> 
> DSS platform driver
> - initialises DSS IP alone
>   - Handles the clocks related to the DSS and other DSSHW IPs like RFBI,
>   DSI, VENC, DISPC.  Previously this was a part of "omapdss" driver in 
> core.c
>   - Continues to handle the DSS IRQs.
>   - No suspend/resume hooks.
> 
> DISPC platform driver
> - initialises DISPC IP alone
>   - Gets the required clock from DSS platform driver.
>   - No suspend/resume hooks.
>   - Continues to provide DISPC library functions.
> 
> DSI platform driver
> - initialises DSI IP alone
>   - Gets the required clock from DSS platform driver.
>   - No suspend/resume hooks.
>   - Continues to provide DSI library functions.
> 
> RFBI, VENC platform drivers
> - initialises DSI,VENC IPs
>   - Gets the required clock from DSS platform driver.
>   - No suspend/resume hooks.
>   - Continues to provide RFBI and VENC library functions.
> 
> Testing:
> -
> The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp.
> Complete bootup with penguins on panel is done on 3430sdp.
> For the rest of the mentioned platforms, kernel is built with "OMAP2_DSS"
> and bootup is tested so that base address and clk_get calls are successful.
> 
> DSS was built successf

Re: 4430SDP boot failure

[Russell King - ARM Linux]

On Fri, Jan 07, 2011 at 05:48:41PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
> > Sent: Friday, January 07, 2011 3:23 PM
> Ruessell,
> 
> 
> > To: Russell King - ARM Linux
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: RE: 4430SDP boot failure
> >
> 
> []
> 
> > > BTW, if it makes any difference to the boot loader, please note
> > that
> > > I'm
> > > still waiting for the upgrade for the SDP board.
> > That means your board is with ES1.0. I shall try 2.6.37 on
> > ES1.0
> 
> ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an
> issue. The console is changed to OMAP serial driver from 8250
> driver.
> 
> Can you try "console=ttyO2" instead of existing ""console=ttyS2" ??

This is the command line I've been giving it:

setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G 
console=ttyO2,115200n8 rootdelay=2'

and in my .config, I have:

CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y

so the driver is also enabled.  I found this on the 3430LDP, and so
switched both OMAP3 and OMAP4 stuff over to the new driver.

That wouldn't explain why I'm getting the "X-loader hangs" message
which brings everything to a halt, and why the low level debug stuff
doesn't work.
--
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: Build breakage with omap2plus_defconfig

[Anand Gadiyar]

Felipe Balbi wrote:
> Hi all,
>
> Today's Linus' tree
> (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to
> build with omap2plus_defconfig:
>
> $ crossmake
>   CHK include/linux/version.h
>   CHK include/generated/utsrelease.h
> make[1]: `include/generated/mach-types.h' is up to date.
>   CALLscripts/checksyscalls.sh
>   CHK include/generated/compile.h
>   CC  arch/arm/kernel/swp_emulate.o
> /tmp/cc2V7p5j.s: Assembler messages:
> /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode
`ldrexb r3,[r4]'
> /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode
`strexb r0,r2,[r4]'
> make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
> make: *** [arch/arm/kernel] Error 2

I haven't found a way around this other than to turn off
CONFIG_SWP_EMULATE. Here's a patch doing that [1].

The discussion thread is here [2].

- Anand

[1] http://marc.info/?l=linux-omap&m=129140165126953&w=2
[2] http://marc.info/?t=12874841253&r=1&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: Build breakage with omap2plus_defconfig

[Santosh Shilimkar]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Felipe Balbi
> Sent: Friday, January 07, 2011 6:09 PM
> To: Russell King; Tony Lindgren
> Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List
> Subject: Build breakage with omap2plus_defconfig
>
> Hi all,
>
> Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails
> to
> build with omap2plus_defconfig:
>
> $ crossmake
>   CHK include/linux/version.h
>   CHK include/generated/utsrelease.h
> make[1]: `include/generated/mach-types.h' is up to date.
>   CALLscripts/checksyscalls.sh
>   CHK include/generated/compile.h
>   CC  arch/arm/kernel/swp_emulate.o
> /tmp/cc2V7p5j.s: Assembler messages:
> /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM
> mode `ldrexb r3,[r4]'
> /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM
> mode `strexb r0,r2,[r4]'

Well it's not toolchain issue but the omap2plus_defconfig which
selects ARMv6 and ARMV7 together.

If you remove ARCH_OMAP2 from build, it will go through.

> make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
> make: *** [arch/arm/kernel] Error 2
>
> Compiler is:
>
> $ arm-linux-gcc --version
> arm-linux-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
> Copyright (C) 2009 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There
> is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
> I'm downloading Sourcery G++ Lite 2010.09-50 for ARM GNU/Linux to
> check
> if it's not a bug on the compiler.

Santosh
--
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: Build breakage with omap2plus_defconfig

[Felipe Balbi]

Hi,

On Fri, Jan 07, 2011 at 02:38:59PM +0200, Felipe Balbi wrote:
> Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to
> build with omap2plus_defconfig:
> 
> $ crossmake
>   CHK include/linux/version.h
>   CHK include/generated/utsrelease.h
> make[1]: `include/generated/mach-types.h' is up to date.
>   CALLscripts/checksyscalls.sh
>   CHK include/generated/compile.h
>   CC  arch/arm/kernel/swp_emulate.o
> /tmp/cc2V7p5j.s: Assembler messages:
> /tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode 
> `ldrexb r3,[r4]'
> /tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode 
> `strexb r0,r2,[r4]'
> make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
> make: *** [arch/arm/kernel] Error 2
> 
> Compiler is:
> 
> $ arm-linux-gcc --version
> arm-linux-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
> Copyright (C) 2009 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> I'm downloading Sourcery G++ Lite 2010.09-50 for ARM GNU/Linux to check
> if it's not a bug on the compiler.

Just tested with newer compiler and it also fails to compile.

$ arm-linux-gcc --version
arm-linux-gcc (Sourcery G++ Lite 2010.09-50) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-- 
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

[GIT PULL] OMAP DSS changes for .38 merge window

[Tomi Valkeinen]

Hello Paul,

Here are some OMAP display changes for .38. I hope they are not too
late, but the holidays messed up my schedules a bit.

I made two branches, as I'm not sure which is better:

for-paul-38 - This one is the original non-rebased branch. This causes a
trivial conflict with fbdev/master in drivers/video/omap2/vram.c (SZ_2M
is the right one), and also it contains a patch (memblock: fix
memblock_is_region_memory()) which is not yet in mainline, but is in
Andrew Morton's tree.

for-paul-38-rebased - The above branch rebased on top of v2.6.37, and
the memblock commit removed.

Which one you prefer? Or is there some other way I should handle this?

I could merge v2.6.37 to my branch, which would remove the conflict, but
that would still leave the memblock patch. I guess the patch is going in
soon, but as it's not in my area, I don't feel it's right to get it in
via my patch set. Alternatively I could wait until the patch is in
Linus' tree, but that could make it tight to be in time for the merge
window.

 Tomi

The following changes since commit c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4:

  Linux 2.6.37-rc1 (2010-11-01 07:54:12 -0400)

are available in the git repository at:
  git://gitorious.org/linux-omap-dss2/linux.git for-paul-38

Archit Taneja (5):
  OMAP: DSS2: Fix: Read correct bit in dispc_enable_alpha_blending()
  OMAP: DSS2: Clean up DISPC color mode validation checks
  OMAP: DSS2: Add dss_features for omap4 and overlay manager related 
features
  OMAP: DSS2: Use dss_features to handle DISPC bits removed on OMAP4
  OMAP: DSS2: Fix build breaks for rfbi.c and dsi.c

Bryan Wu (4):
  OMAP: DSS2: Add generic DPI panel display driver
  OMAP: use generic DPI panel driver in board files
  OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers
  OMAP: DSS2: Add back authors of panel-generic.c based drivers

Erik Gilling (1):
  OMAP: DSS2: Add NEC NL8048HL11-01B display panel

Kishore Y (2):
  OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3
  OMAP3: Enable display on ZOOM2/3/3630SDP

Rajkumar N (1):
  OMAP3630: DSS2: Enable Pre-Multiplied Alpha Support

Samreen (2):
  OMAP3: DSS2: Split OMAP3 has feature for 3430 & 3630
  OMAP: DSS2: OMAPFB: Add null pointer check

Sumit Semwal (5):
  OMAP: DSS2: Represent DISPC register defines with channel as parameter
  OMAP: DSS2: Introduce omap_channel argument to DISPC functions used by 
interface drivers
  OMAP: DSS2: Change remaining DISPC functions for new omap_channel argument
  OMAP: DSS2: LCD2 Channel Changes for DISPC
  OMAP: DSS2: Introduce omap_channel as an omap_dss_device parameter, add 
new overlay manager.

Tomi Valkeinen (4):
  memblock: fix memblock_is_region_memory()
  OMAP: VRAM: improve VRAM error prints
  OMAP: VRAM: Fix boot-time memory allocation
  OMAP: DSS: Fix documentation regarding 'vram' kernel parameter

 Documentation/arm/OMAP/DSS |7 +-
 arch/arm/mach-omap2/Makefile   |3 +
 arch/arm/mach-omap2/board-3430sdp.c|   12 +-
 arch/arm/mach-omap2/board-3630sdp.c|1 +
 arch/arm/mach-omap2/board-am3517evm.c  |   23 +-
 arch/arm/mach-omap2/board-cm-t35.c |   23 +-
 arch/arm/mach-omap2/board-devkit8000.c |   26 +-
 arch/arm/mach-omap2/board-igep0020.c   |   12 +-
 arch/arm/mach-omap2/board-omap3beagle.c|   12 +-
 arch/arm/mach-omap2/board-omap3evm.c   |   12 +-
 arch/arm/mach-omap2/board-omap3stalker.c   |   23 +-
 arch/arm/mach-omap2/board-zoom-display.c   |  168 +
 arch/arm/mach-omap2/board-zoom-peripherals.c   |   49 ++-
 arch/arm/mach-omap2/board-zoom2.c  |1 +
 arch/arm/mach-omap2/board-zoom3.c  |1 +
 arch/arm/mach-omap2/include/mach/board-zoom.h  |3 +
 arch/arm/plat-omap/include/plat/display.h  |9 +
 .../arm/plat-omap/include/plat/panel-generic-dpi.h |   37 ++
 drivers/video/omap2/displays/Kconfig   |   27 +-
 drivers/video/omap2/displays/Makefile  |5 +-
 drivers/video/omap2/displays/panel-generic-dpi.c   |  365 +++
 drivers/video/omap2/displays/panel-generic.c   |  174 --
 .../omap2/displays/panel-nec-nl8048hl11-01b.c  |  325 ++
 .../video/omap2/displays/panel-sharp-lq043t1dg01.c |  165 -
 .../video/omap2/displays/panel-toppoly-tdo35s.c|  164 -
 drivers/video/omap2/dss/dispc.c|  636 +---
 drivers/video/omap2/dss/dpi.c  |   40 +-
 drivers/video/omap2/dss/dsi.c  |   27 +-
 drivers/video/omap2/dss/dss.h  |   35 +-
 drivers/video/omap2/dss/dss_features.c |   66 ++-
 drivers/video/omap2/dss/dss_features.h |   10 +-
 drivers/video/omap2/dss/manager.c  |   80 ++-
 drivers/video/omap2/dss

Build breakage with omap2plus_defconfig

[Felipe Balbi]

Hi all,

Today's Linus' tree (01539ba2a706ab7d35fc0667dff919ade7f87d63) fails to
build with omap2plus_defconfig:

$ crossmake
  CHK include/linux/version.h
  CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  CC  arch/arm/kernel/swp_emulate.o
/tmp/cc2V7p5j.s: Assembler messages:
/tmp/cc2V7p5j.s:161: Error: selected processor does not support ARM mode 
`ldrexb r3,[r4]'
/tmp/cc2V7p5j.s:162: Error: selected processor does not support ARM mode 
`strexb r0,r2,[r4]'
make[1]: *** [arch/arm/kernel/swp_emulate.o] Error 1
make: *** [arch/arm/kernel] Error 2

Compiler is:

$ arm-linux-gcc --version
arm-linux-gcc (Sourcery G++ Lite 2010q1-202) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm downloading Sourcery G++ Lite 2010.09-50 for ARM GNU/Linux to check
if it's not a bug on the compiler.

-- 
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: 4430SDP boot failure

[Santosh Shilimkar]

Sorry,
> -Original Message-
> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
> Sent: Friday, January 07, 2011 5:49 PM
> To: Russell King - ARM Linux
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: RE: 4430SDP boot failure
>
> > -Original Message-
> > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
> > Sent: Friday, January 07, 2011 3:23 PM
> Ruessell,
>
>
> > To: Russell King - ARM Linux
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: RE: 4430SDP boot failure
> >
>
> []
>
> > > BTW, if it makes any difference to the boot loader, please note
> > that
> > > I'm
> > > still waiting for the upgrade for the SDP board.
> > That means your board is with ES1.0. I shall try 2.6.37 on
> > ES1.0
>
> ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an
> issue. The console is changed to OMAP serial driver from 8250
> driver.
>
> Can you try "console=ttyO2" instead of existing ""console=ttyS2" ??
>
Ignore my last email. You have tried that already
Will send you updated boot-loaders in next few mins.
--
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: 4430SDP boot failure

[Santosh Shilimkar]

> -Original Message-
> From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
> Sent: Friday, January 07, 2011 3:23 PM
Ruessell,


> To: Russell King - ARM Linux
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: RE: 4430SDP boot failure
>

[]

> > BTW, if it makes any difference to the boot loader, please note
> that
> > I'm
> > still waiting for the upgrade for the SDP board.
> That means your board is with ES1.0. I shall try 2.6.37 on
> ES1.0

ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an
issue. The console is changed to OMAP serial driver from 8250
driver.

Can you try "console=ttyO2" instead of existing ""console=ttyS2" ??

Will send you the latest boot-loader after doing a boot test.


## Booting image at 8030 ...
   Image Name:   Linux-2.6.37
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:2898440 Bytes =  2.8 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Linux version 2.6.37 (a0393...@a0393909-desktop) (gcc
version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #6 SMP Fri Jan 7 17:12:26
IST 2011
[0.00] CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7),
cr=10c53c7f
[0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction
cache
[0.00] Machine: OMAP4430 4430SDP board
[0.00] Memory policy: ECC disabled, Data cache writealloc
[0.00] OMAP4430 ES1.0
[0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000
[0.00] FIXME: omap44xx_sram_init not implemented
[0.00] PERCPU: Embedded 7 pages/cpu @c0f3d000 s6080 r8192 d14400
u32768
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 130048
[0.00] Kernel command line: console=ttyO2,115200n8 noinitrd
root=/dev/nfs rw
nfsroot=172.24.190.46:/ubuntu/nfs-share/omap4_next/,nolock,tcp,rsize=1024,
wsize=1024 ip=dhcp
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072
bytes)
[0.00] Memory: 512MB = 512MB total
[0.00] Memory: 508228k/508228k available, 16060k reserved, 0K
highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] DMA : 0xffc0 - 0xffe0   (   2 MB)
[0.00] vmalloc : 0xe080 - 0xf800   ( 376 MB)
[0.00] lowmem  : 0xc000 - 0xe000   ( 512 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .init : 0xc0008000 - 0xc004a000   ( 264 kB)
[0.00]   .text : 0xc004a000 - 0xc056904c   (5245 kB)
[0.00]   .data : 0xc056a000 - 0xc05dadc0   ( 452 kB)
[0.00] Hierarchical RCU implementation.
--
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: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module

[J, KEERTHY]

On Fri, Jan 7, 2011 at 3:25 AM, Guenter Roeck
 wrote:
> On Thu, 2011-01-06 at 15:21 -0500, Mark Brown wrote:
>> On Thu, Jan 06, 2011 at 07:04:30AM -0800, Guenter Roeck wrote:
>> > On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote:
>>
>> > > Why?  It's not like hwmon has an unreasonably large core or similar.
>>
>> > Because it creates an unnecessary dependency, and because it is not hwmon's
>> > responsibility to provide infrastructure for other subsystems or drivers.
>>
>> hwmon isn't really doing anything, though.  The *driver* is doing
>> something but it doesn't really impact the core that much.  Not that I'm
>> particularly sold on putting the ADC core in here, but total NACK based
>> on that alone seems rather harsh.
>
> Possibly. However, I had suggested the following earlier (to the 1st
> version of the patch):
>
>> I commented on this a couple of times below - the driver mixes generic
>> ADC reading functions with hwmon functionality. Generic ADC reading
>> functionality should be moved into another driver, possibly to mfd.
>
> Obviously that was ignored. Maybe someone is willing to listen this time
> around.
>
I am sorry for not responding on the generic ADC handling part. Since many
other ADC drivers are part of hwmon i thought hwmon was the appropriate
place. However I can surely split the generic ADC handling part in mfd and
only hardware monitoring part in hwmon as suggested.

> I won't let people break modularity just for convenience in a subsystem
> I am responsible for. And forcing the hwmon subsystem, and with it a
> specific hwmon driver, to exist just because the adc functionality it
> provides is needed by some other (most likely unrelated) subsystem /
> driver _does_ break modularity. Worse, it is completely unnecessary to
> do so. Other twl4030 functionality was extracted into generic code.
> twl-core.c, twl4030-codec.c, twl4030-irq.c, twl4030-power.c are all in
> mfd. I fail to see the problem with mfd/twl4030-adc.c.
>
> Guenter
>
>
>

Hello Samuel,

Is it ok to have the generic ADC functionality in mfd as a separate file?

Regards,
Keerthy
--
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

Latest regressions

[Russell King - ARM Linux]

In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:37,
 from arch/arm/mach-omap2/io.c:45:
arch/arm/plat-omap/include/plat/voltage.h: In function 
■omap_voltage_register_pmic■:
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in 
function returning non-void

which gets spammed out all through the build.  voltage.h:137 says:

static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm,
struct omap_volt_pmic_info *pmic_info) {}

but no one checks the return value for this:

arch/arm/mach-omap2/omap_twl.c: omap_voltage_register_pmic(voltdm, 
&omap4_mpu_volt_info);
arch/arm/mach-omap2/omap_twl.c: omap_voltage_register_pmic(voltdm, 
&omap4_iva_volt_info);
arch/arm/mach-omap2/omap_twl.c: omap_voltage_register_pmic(voltdm, 
&omap4_core_volt_info);
arch/arm/mach-omap2/omap_twl.c: omap_voltage_register_pmic(voltdm, 
&omap3_mpu_volt_info);
arch/arm/mach-omap2/omap_twl.c: omap_voltage_register_pmic(voltdm, 
&omap3_core_volt_info);

so I don't see the point of it returning an 'int'.

There's also:
arch/arm/mach-omap2/io.c: In function ■omap_irq_base_init■:
arch/arm/mach-omap2/io.c:322: warning: unused variable ■omap_irq_base■

This has never been built with !MULTI_OMAP2:

+/*
+ * Initialize asm_irq_base for entry-macro.S
+ */
+static inline void omap_irq_base_init(void)
+{
+   extern void __iomem *omap_irq_base;
+
+#ifdef MULTI_OMAP2
+   if (cpu_is_omap242x())
+   omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP24XX_IC_BASE);
+   else if (cpu_is_omap34xx())
+   omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP34XX_IC_BASE);
+   else if (cpu_is_omap44xx())
+   omap_irq_base = OMAP2_L4_IO_ADDRESS(OMAP44XX_GIC_CPU_BASE);
+   else
+   pr_err("Could not initialize omap_irq_base\n");
+#endif
+}

and given the code and comment in entry-macros.S, it would be far better
to define omap_irq_base in here, get rid of the ifdef and always
initialize it, thereby eliminating that variability from needing
multiple different configurations get proper build coverage.

arch/arm/mach-omap2/mux.c: In function ■_omap_mux_get_by_name■:
arch/arm/mach-omap2/mux.c:163: warning: ■found_mode■ may be used uninitialized 
in this function

The build ends with:

In file included from arch/arm/plat-omap/include/plat/omap_hwmod.h:37,
 from arch/arm/mach-omap2/omap_hwmod_common_data.c:19:
arch/arm/plat-omap/include/plat/voltage.h: In function 
■omap_voltage_register_pmic■:
arch/arm/plat-omap/include/plat/voltage.h:137: warning: no return statement in 
function returning non-void
arch/arm/plat-omap/include/plat/voltage.h: In function ■omap_voltage_late_init■:
arch/arm/plat-omap/include/plat/voltage.h:142: error: ■EINVAL■ undeclared 
(first use in this function)
arch/arm/plat-omap/include/plat/voltage.h:142: error: (Each undeclared 
identifier is reported only once
arch/arm/plat-omap/include/plat/voltage.h:142: error: for each function it 
appears in.)
make[2]: *** [arch/arm/mach-omap2/omap_hwmod_common_data.o] Error 1
make[1]: *** [arch/arm/mach-omap2] Error 2
make[1]: *** Waiting for unfinished jobs

Adding linux/errno.h to that header resolves that.  That gets us down to
the final link, which fails:

arch/arm/mach-omap2/built-in.o: In function `omap2_set_init_voltage':
arch/arm/mach-omap2/pm.c:181: undefined reference to 
`omap_voltage_domain_lookup'
arch/arm/mach-omap2/built-in.o: In function `omap3_twl_init':
arch/arm/mach-omap2/omap_twl.c:270: undefined reference to 
`omap_voltage_domain_lookup'
arch/arm/mach-omap2/omap_twl.c:273: undefined reference to 
`omap_voltage_domain_lookup'

So, this is what I currently have to get that far:

diff --git a/arch/arm/mach-omap2/include/mach/entry-macro.S 
b/arch/arm/mach-omap2/include/mach/entry-macro.S
index befa321..81985a6 100644
--- a/arch/arm/mach-omap2/include/mach/entry-macro.S
+++ b/arch/arm/mach-omap2/include/mach/entry-macro.S
@@ -38,20 +38,6 @@
  */
 
 #ifdef MULTI_OMAP2
-
-/*
- * We use __glue to avoid errors with multiple definitions of
- * .globl omap_irq_base as it's included from entry-armv.S but not
- * from entry-common.S.
- */
-#ifdef __glue
-   .pushsection .data
-   .globl  omap_irq_base
-omap_irq_base:
-   .word   0
-   .popsection
-#endif
-
/*
 * Configure the interrupt base on the first interrupt.
 * See also omap_irq_base_init for setting omap_irq_base.
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e66687b..c203204 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -314,14 +314,13 @@ static int _set_hwmod_postsetup_state(struct omap_hwmod 
*oh, void *data)
return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
 }
 
+void __iomem *omap_irq_base;
+
 /*
  * Initialize asm_irq_base for entry-macro.S
  */
 static inline void omap_irq_base_init(void)
 {
-   extern void __iomem *omap_

Latest config warning

[Russell King - ARM Linux]

warning: (ARCH_STMP3XXX &&  || ARCH_OMAP3 && ARCH_OMAP2PLUS) selects 
USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT)

This didn't happen with 2.6.37.  Maybe a missing select USB_SUPPORT
somewhere?
--
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 v5 16/17] OMAP2,3: DSS2: Use platform device to get baseaddr

[Sumit Semwal]

From: Senthilvadivu Guruswamy 

DSS, DISPC, DSI, RFBI, VENC baseaddr can be obtained from 
platform_get_resource().
This API in turn picks the right silicon baseaddr from the hwmod database.
So hardcoding of base addr could be removed.

Signed-off-by: Senthilvadivu Guruswamy 
---
 drivers/video/omap2/dss/dispc.c |   11 ---
 drivers/video/omap2/dss/dsi.c   |   12 +---
 drivers/video/omap2/dss/dss.c   |   11 ---
 drivers/video/omap2/dss/rfbi.c  |   10 +++---
 drivers/video/omap2/dss/venc.c  |   11 ---
 5 files changed, 40 insertions(+), 15 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 97dfc84..9da59fe 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -42,8 +42,6 @@
 #include "dss_features.h"
 
 /* DISPC */
-#define DISPC_BASE 0x48050400
-
 #define DISPC_SZ_REGS  SZ_1K
 
 struct dispc_reg { u16 idx; };
@@ -3132,6 +3130,8 @@ int dispc_setup_plane(enum omap_plane plane,
 static int omap_dispchw_probe(struct platform_device *pdev)
 {
u32 rev;
+   struct resource *dispc_mem;
+
dispc.pdev = pdev;
 
spin_lock_init(&dispc.irq_lock);
@@ -3143,7 +3143,12 @@ static int omap_dispchw_probe(struct platform_device 
*pdev)
 
INIT_WORK(&dispc.error_work, dispc_error_worker);
 
-   dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
+   dispc_mem = platform_get_resource(dispc.pdev, IORESOURCE_MEM, 0);
+   if (!dispc_mem) {
+   DSSERR("can't get IORESOURCE_MEM DISPC\n");
+   return -EINVAL;
+   }
+   dispc.base = ioremap(dispc_mem->start, resource_size(dispc_mem));
if (!dispc.base) {
DSSERR("can't ioremap DISPC\n");
return -ENOMEM;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index cf1a2ad..74ee776 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -42,8 +42,6 @@
 /*#define VERBOSE_IRQ*/
 #define DSI_CATCH_MISSING_TE
 
-#define DSI_BASE   0x4804FC00
-
 struct dsi_reg { u16 idx; };
 
 #define DSI_REG(idx)   ((const struct dsi_reg) { idx })
@@ -3254,6 +3252,7 @@ static int dsi_init(struct platform_device *pdev)
 {
u32 rev;
int r;
+   struct resource *dsi_mem;
 
spin_lock_init(&dsi.errors_lock);
dsi.errors = 0;
@@ -3280,7 +3279,13 @@ static int dsi_init(struct platform_device *pdev)
dsi.te_timer.function = dsi_te_timeout;
dsi.te_timer.data = 0;
 #endif
-   dsi.base = ioremap(DSI_BASE, DSI_SZ_REGS);
+   dsi_mem = platform_get_resource(dsi.pdev, IORESOURCE_MEM, 0);
+   if (!dsi_mem) {
+   DSSERR("can't get IORESOURCE_MEM DSI\n");
+   r = -EINVAL;
+   goto err0;
+   }
+   dsi.base = ioremap(dsi_mem->start, resource_size(dsi_mem));
if (!dsi.base) {
DSSERR("can't ioremap DSI\n");
r = -ENOMEM;
@@ -3307,6 +3312,7 @@ err2:
iounmap(dsi.base);
 err1:
destroy_workqueue(dsi.workqueue);
+err0:
return r;
 }
 
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 02a2a3e..8ca21cd 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -34,8 +34,6 @@
 #include 
 #include "dss.h"
 
-#define DSS_BASE   0x4805
-
 #define DSS_SZ_REGSSZ_512
 
 struct dss_reg {
@@ -567,8 +565,15 @@ static int dss_init(bool skip_init)
 {
int r;
u32 rev;
+   struct resource *dss_mem;
 
-   dss.base = ioremap(DSS_BASE, DSS_SZ_REGS);
+   dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
+   if (!dss_mem) {
+   DSSERR("can't get IORESOURCE_MEM DSS\n");
+   r = -EINVAL;
+   goto fail0;
+   }
+   dss.base = ioremap(dss_mem->start, resource_size(dss_mem));
if (!dss.base) {
DSSERR("can't ioremap DSS\n");
r = -ENOMEM;
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 24936f8..54f2279 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -36,8 +36,6 @@
 #include 
 #include "dss.h"
 
-#define RFBI_BASE   0x48050800
-
 struct rfbi_reg { u16 idx; };
 
 #define RFBI_REG(idx)  ((const struct rfbi_reg) { idx })
@@ -1017,6 +1015,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
 {
u32 rev;
u32 l;
+   struct resource *rfbi_mem;
 
rfbi.pdev = pdev;
 
@@ -1026,7 +1025,12 @@ static int omap_rfbihw_probe(struct platform_device 
*pdev)
atomic_set(&rfbi.cmd_fifo_full, 0);
atomic_set(&rfbi.cmd_pending, 0);
 
-   rfbi.base = ioremap(RFBI_BASE, SZ_256);
+   rfbi_mem = platform_get_resource(rfbi.pdev, IORESOURCE_MEM, 0);
+   if (!rfbi_mem) {
+   DSSERR("can't get IORESOURCE_MEM RFBI\n");
+

[PATCH v5 15/17] OMAP2,3: DSS2: replace printk with dev_dbg in init

[Sumit Semwal]

This patch replaces printk's in the init/probe functions to dev_dbg
for boot time optimization.

Signed-off-by: Sumit Semwal 
---
 drivers/video/omap2/dss/dispc.c |2 +-
 drivers/video/omap2/dss/dsi.c   |2 +-
 drivers/video/omap2/dss/rfbi.c  |2 +-
 drivers/video/omap2/dss/venc.c  |2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e19c4cd..97dfc84 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3158,7 +3158,7 @@ static int omap_dispchw_probe(struct platform_device 
*pdev)
dispc_save_context();
 
rev = dispc_read_reg(DISPC_REVISION);
-   printk(KERN_INFO "OMAP DISPC rev %d.%d\n",
+   dev_dbg(&pdev->dev, "OMAP DISPC rev %d.%d\n",
   FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
 
enable_clocks(0);
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 411d0c6..cf1a2ad 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -3297,7 +3297,7 @@ static int dsi_init(struct platform_device *pdev)
enable_clocks(1);
 
rev = dsi_read_reg(DSI_REVISION);
-   printk(KERN_INFO "OMAP DSI rev %d.%d\n",
+   dev_dbg(&pdev->dev, "OMAP DSI rev %d.%d\n",
   FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
 
enable_clocks(0);
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 52bfb1c..24936f8 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1044,7 +1044,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
rfbi_write_reg(RFBI_SYSCONFIG, l);
 
rev = rfbi_read_reg(RFBI_REVISION);
-   printk(KERN_INFO "OMAP RFBI rev %d.%d\n",
+   dev_dbg(&pdev->dev, "OMAP RFBI rev %d.%d\n",
   FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
 
rfbi_enable_clocks(0);
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 029fbc3..edccd59 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -739,7 +739,7 @@ static int omap_venchw_probe(struct platform_device *pdev)
venc_enable_clocks(1);
 
rev_id = (u8)(venc_read_reg(VENC_REV_ID) & 0xff);
-   printk(KERN_INFO "OMAP VENC rev %d\n", rev_id);
+   dev_dbg(&pdev->dev, "OMAP VENC rev %d\n", rev_id);
 
venc_enable_clocks(0);
 
-- 
1.7.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 v5 17/17] OMAP2,3: DSS2: Get DSS IRQ from platform device

[Sumit Semwal]

From: Senthilvadivu Guruswamy 

DSS IRQ number can be obtained from platform_get_irq().  This API in turn
picks the right IRQ number belonging to HW IP from the hwmod database.
So hardcoding of IRQ number could be removed.

Signed-off-by: Senthilvadivu Guruswamy 
---
 drivers/video/omap2/dss/dss.c |   13 -
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 8ca21cd..ebf6f76 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -563,7 +563,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
 
 static int dss_init(bool skip_init)
 {
-   int r;
+   int r, dss_irq;
u32 rev;
struct resource *dss_mem;
 
@@ -609,15 +609,18 @@ static int dss_init(bool skip_init)
REG_FLD_MOD(DSS_CONTROL, 0, 2, 2);  /* venc clock mode = normal */
 #endif
 
-   r = request_irq(INT_24XX_DSS_IRQ,
+   dss_irq = platform_get_irq(dss.pdev, 0);
+   if (dss_irq != -ENXIO) {
+   r = request_irq(dss_irq,
cpu_is_omap24xx()
? dss_irq_handler_omap2
: dss_irq_handler_omap3,
0, "OMAP DSS", NULL);
 
-   if (r < 0) {
-   DSSERR("omap2 dss: request_irq failed\n");
-   goto fail1;
+   if (r < 0) {
+   DSSERR("omap2 dss: request_irq failed\n");
+   goto fail1;
+   }
}
 
if (cpu_is_omap34xx()) {
-- 
1.7.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 v5 12/17] OMAP2,3: DSS2: DISPC: create platform_driver, move init,exit to driver

[Sumit Semwal]

From: Senthilvadivu Guruswamy 

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for DISPC is created and init exit methods are moved from 
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.

DISPC platform driver is registered from inside omap_dss_probe, in the order 
desired.

Signed-off-by: Senthilvadivu Guruswamy 
Signed-off-by: Sumit Semwal 
---
 drivers/video/omap2/dss/core.c  |8 ++--
 drivers/video/omap2/dss/dispc.c |  105 ---
 drivers/video/omap2/dss/dss.h   |4 +-
 3 files changed, 70 insertions(+), 47 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 2ad7351..ace869e 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -213,9 +213,9 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_dpi;
}
 
-   r = dispc_init();
+   r = dispc_init_platform_driver();
if (r) {
-   DSSERR("Failed to initialize dispc\n");
+   DSSERR("Failed to initialize dispc platform driver\n");
goto err_dispc;
}
 
@@ -281,7 +281,7 @@ err_dsi:
 err_sdi:
venc_exit();
 err_venc:
-   dispc_exit();
+   dispc_deinit_platform_driver();
 err_dispc:
dpi_exit();
 err_dpi:
@@ -301,7 +301,7 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
 
venc_exit();
-   dispc_exit();
+   dispc_deinit_platform_driver();
dpi_exit();
rfbi_deinit_platform_driver();
if (cpu_is_omap34xx()) {
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index fa40fa5..e19c4cd 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -173,6 +173,7 @@ struct dispc_irq_stats {
 };
 
 static struct {
+   struct platform_device *pdev;
void __iomem*base;
 
u32 fifo_size[3];
@@ -3079,47 +3080,6 @@ static void _omap_dispc_initial_config(void)
dispc_read_plane_fifo_sizes();
 }
 
-int dispc_init(void)
-{
-   u32 rev;
-
-   spin_lock_init(&dispc.irq_lock);
-
-#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
-   spin_lock_init(&dispc.irq_stats_lock);
-   dispc.irq_stats.last_reset = jiffies;
-#endif
-
-   INIT_WORK(&dispc.error_work, dispc_error_worker);
-
-   dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
-   if (!dispc.base) {
-   DSSERR("can't ioremap DISPC\n");
-   return -ENOMEM;
-   }
-
-   enable_clocks(1);
-
-   _omap_dispc_initial_config();
-
-   _omap_dispc_initialize_irq();
-
-   dispc_save_context();
-
-   rev = dispc_read_reg(DISPC_REVISION);
-   printk(KERN_INFO "OMAP DISPC rev %d.%d\n",
-  FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
-
-   enable_clocks(0);
-
-   return 0;
-}
-
-void dispc_exit(void)
-{
-   iounmap(dispc.base);
-}
-
 int dispc_enable_plane(enum omap_plane plane, bool enable)
 {
DSSDBG("dispc_enable_plane %d, %d\n", plane, enable);
@@ -3167,3 +3127,66 @@ int dispc_setup_plane(enum omap_plane plane,
 
return r;
 }
+
+/* DISPC HW IP initialisation */
+static int omap_dispchw_probe(struct platform_device *pdev)
+{
+   u32 rev;
+   dispc.pdev = pdev;
+
+   spin_lock_init(&dispc.irq_lock);
+
+#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
+   spin_lock_init(&dispc.irq_stats_lock);
+   dispc.irq_stats.last_reset = jiffies;
+#endif
+
+   INIT_WORK(&dispc.error_work, dispc_error_worker);
+
+   dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
+   if (!dispc.base) {
+   DSSERR("can't ioremap DISPC\n");
+   return -ENOMEM;
+   }
+
+   enable_clocks(1);
+
+   _omap_dispc_initial_config();
+
+   _omap_dispc_initialize_irq();
+
+   dispc_save_context();
+
+   rev = dispc_read_reg(DISPC_REVISION);
+   printk(KERN_INFO "OMAP DISPC rev %d.%d\n",
+  FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
+
+   enable_clocks(0);
+
+   return 0;
+}
+
+static int omap_dispchw_remove(struct platform_device *pdev)
+{
+   iounmap(dispc.base);
+   return 0;
+}
+
+static struct platform_driver omap_dispchw_driver = {
+   .probe  = omap_dispchw_probe,
+   .remove = omap_dispchw_remove,
+   .driver = {
+   .name   = "omap_dispc",
+   .owner  = THIS_MODULE,
+   },
+};
+
+int dispc_init_platform_driver(void)
+{
+   return platform_driver_register(&omap_dispchw_driver);
+}
+
+void dispc_deinit_platform_driver(void)
+{
+   return platform_driver_unregister(&omap_dispchw_driver);
+}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 665ad58..90048b9 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -319,8 +319,8 @@ static inline void dpi_exit(void

[PATCH v5 13/17] OMAP2,3: DSS2: VENC: create platform_driver, move init,exit to driver

[Sumit Semwal]

From: Senthilvadivu Guruswamy 

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for VENC is created and init exit methods are moved from 
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.

Also, venc_vdda_dac reading is moved to venc.c.

VENC platform driver is registered from inside omap_dss_probe, in the order 
desired.

Signed-off-by: Senthilvadivu Guruswamy 
Signed-off-by: Sumit Semwal 
---
 arch/arm/mach-omap2/board-3430sdp.c |2 +-
 drivers/video/omap2/dss/core.c  |   28 +---
 drivers/video/omap2/dss/dss.h   |9 +--
 drivers/video/omap2/dss/venc.c  |  116 +++
 4 files changed, 85 insertions(+), 70 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index e1a3318..83baba7 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -302,7 +302,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
 };
 
 static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
-   REGULATOR_SUPPLY("vdda_dac", "omap_display");
+   REGULATOR_SUPPLY("vdda_dac", "omap_venc");
 
 static struct omap_board_config_kernel sdp3430_config[] __initdata = {
 };
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index ace869e..5314593 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -43,7 +43,6 @@ static struct {
 
struct regulator *vdds_dsi_reg;
struct regulator *vdds_sdi_reg;
-   struct regulator *vdda_dac_reg;
 } core;
 
 static char *def_disp_name;
@@ -85,20 +84,6 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
 }
 
-struct regulator *dss_get_vdda_dac(void)
-{
-   struct regulator *reg;
-
-   if (core.vdda_dac_reg != NULL)
-   return core.vdda_dac_reg;
-
-   reg = regulator_get(&core.pdev->dev, "vdda_dac");
-   if (!IS_ERR(reg))
-   core.vdda_dac_reg = reg;
-
-   return reg;
-}
-
 #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
 static int dss_debug_show(struct seq_file *s, void *unused)
 {
@@ -219,9 +204,9 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_dispc;
}
 
-   r = venc_init(pdev);
+   r = venc_init_platform_driver();
if (r) {
-   DSSERR("Failed to initialize venc\n");
+   DSSERR("Failed to initialize venc platform driver\n");
goto err_venc;
}
 
@@ -279,7 +264,7 @@ err_dsi:
if (cpu_is_omap34xx())
sdi_exit();
 err_sdi:
-   venc_exit();
+   venc_deinit_platform_driver();
 err_venc:
dispc_deinit_platform_driver();
 err_dispc:
@@ -300,7 +285,7 @@ static int omap_dss_remove(struct platform_device *pdev)
 
dss_uninitialize_debugfs();
 
-   venc_exit();
+   venc_deinit_platform_driver();
dispc_deinit_platform_driver();
dpi_exit();
rfbi_deinit_platform_driver();
@@ -597,11 +582,6 @@ static void __exit omap_dss_exit(void)
core.vdds_sdi_reg = NULL;
}
 
-   if (core.vdda_dac_reg != NULL) {
-   regulator_put(core.vdda_dac_reg);
-   core.vdda_dac_reg = NULL;
-   }
-
platform_driver_unregister(&omap_dss_driver);
 
omap_dss_bus_unregister();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 90048b9..c1ab6c6 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -172,7 +172,6 @@ struct platform_device;
 struct bus_type *dss_get_bus(void);
 struct regulator *dss_get_vdds_dsi(void);
 struct regulator *dss_get_vdds_sdi(void);
-struct regulator *dss_get_vdda_dac(void);
 
 /* display */
 int dss_suspend_all_devices(void);
@@ -405,16 +404,16 @@ int dispc_get_clock_div(struct dispc_clock_info *cinfo);
 
 /* VENC */
 #ifdef CONFIG_OMAP2_DSS_VENC
-int venc_init(struct platform_device *pdev);
-void venc_exit(void);
+int venc_init_platform_driver(void);
+void venc_deinit_platform_driver(void);
 void venc_dump_regs(struct seq_file *s);
 int venc_init_display(struct omap_dss_device *display);
 #else
-static inline int venc_init(struct platform_device *pdev)
+static inline int venc_init_platform_driver(void)
 {
return 0;
 }
-static inline void venc_exit(void)
+static inline void venc_deinit_platform_driver(void)
 {
 }
 #endif
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index eff3505..029fbc3 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -289,6 +289,7 @@ const struct omap_video_timings omap_dss_ntsc_timings = {
 EXPORT_SYMBOL(omap_dss_ntsc_timings);
 
 static struct {
+   struct platform_device *pdev;
void __iomem *base;
struct mutex venc_lock;
u32 wss_data;
@@ -306,6 +307,17 @@ static inline u32 venc_read_reg(int idx)