Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk

2012-12-17 Thread Benoit Cousson
Hi,

On 12/14/2012 07:44 PM, Paul Walmsley wrote:
 Hi
 
 On Fri, 14 Dec 2012, Tony Lindgren wrote:
 
 Paul, what about this patch? Looks like you've acked the other clock 
 patches in this series but not this one?
 
 I commented on it briefly here:
 
 https://patchwork.kernel.org/patch/1838111/
 
 Maybe Benoît could comment here, but it looks to me (based on a 
 superficial look at the hardware clock tree data) that these clock nodes 
 should exist.  In an ideal world, we'd be able to get back to the 
 autogeneration of this clock data.

I'm not sure to understand either the rational for that patch. What the
point of merging the two nodes?
I mean, we can do it, but AFAIR, we have always decided to use atomic
node instead of big nodes that handle everything.

Regards,
Benoit

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


Re: [PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes

2012-12-17 Thread Benoit Cousson
Hi Jon,

On 12/14/2012 10:18 PM, Jon Hunter wrote:
 Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
 
 Please note that the node for OMAP4460 has been placed in a separate
 header file for OMAP4460, because the node is not compatible with
 OMAP4430.

But where is the omap4430 node then?

Regards,
Benoit

 
 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
  arch/arm/boot/dts/omap2.dtsi |5 +
  arch/arm/boot/dts/omap3.dtsi |6 ++
  arch/arm/boot/dts/omap4-panda-es.dts |2 ++
  arch/arm/boot/dts/omap4460.dtsi  |   18 ++
  arch/arm/mach-omap2/pmu.c|2 ++
  5 files changed, 33 insertions(+)
  create mode 100644 arch/arm/boot/dts/omap4460.dtsi
 
 diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
 index 761c4b6..27f5ea1 100644
 --- a/arch/arm/boot/dts/omap2.dtsi
 +++ b/arch/arm/boot/dts/omap2.dtsi
 @@ -26,6 +26,11 @@
   };
   };
  
 + pmu {
 + compatible = arm,arm1136-pmu;
 + interrupts = 3;
 + };
 +
   soc {
   compatible = ti,omap-infra;
   mpu {
 diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
 index 1acc261..6c63118 100644
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -26,6 +26,12 @@
   };
   };
  
 + pmu {
 + compatible = arm,cortex-a8-pmu;
 + interrupts = 3;
 + ti,hwmods = debugss;
 + };
 +
   /*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
 diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
 b/arch/arm/boot/dts/omap4-panda-es.dts
 index 73bc1a6..2a6e344 100644
 --- a/arch/arm/boot/dts/omap4-panda-es.dts
 +++ b/arch/arm/boot/dts/omap4-panda-es.dts
 @@ -5,7 +5,9 @@
   * it under the terms of the GNU General Public License version 2 as
   * published by the Free Software Foundation.
   */
 +
  /include/ omap4-panda.dts
 +/include/ omap4460.dtsi
  
  /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
  sound {
 diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
 new file mode 100644
 index 000..1270890
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap4460.dtsi
 @@ -0,0 +1,18 @@
 +/*
 + * Device Tree Source for OMAP4460 SoC
 + *
 + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This file is licensed under the terms of the GNU General Public License
 + * version 2.  This program is licensed as is without any warranty of any
 + * kind, whether express or implied.
 + */
 +
 +/ {
 + pmu {
 + compatible = arm,cortex-a9-pmu;
 + interrupts = 0 54 0x4
 +   0 55 0x4;
 + ti,hwmods = debugss;
 + };
 +};
 diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
 index 6e620eb..1a0799c 100644
 --- a/arch/arm/mach-omap2/pmu.c
 +++ b/arch/arm/mach-omap2/pmu.c
 @@ -11,6 +11,8 @@
   * the Free Software Foundation; either version 2 of the License, or
   * (at your option) any later version.
   */
 +#include linux/of.h
 +
  #include asm/pmu.h
  
  #include soc.h
 

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


Re: [PATCH 2/2] ARM: OMAP2+: Drop plat/cpu.h for omap2plus

2012-12-17 Thread Laurent Pinchart
Hi Tony,

Thanks for the patch.

On Sunday 16 December 2012 12:03:17 Tony Lindgren wrote:
 The cpu_is_omap macros are now local to arch/arm/mach-omap2
 in soc.h and plat/cpu.h can finally be dropped for omap2+.
 Thanks everybody for help with fixing the drivers.
 
 Note that we can now also remove the unused plat/cpu.h from
 smartreflex.c and isp.c as they will cause compile errors
 with ARCH_MULTIPLATFORM enabled.
 
 Cc: Jean Pihet jean.pi...@newoldbits.com
 Cc: Kevin Hilman khil...@deeprootsystems.com
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Mauro Carvalho Chehab mche...@redhat.com
 Signed-off-by: Tony Lindgren t...@atomide.com

For the OMAP3 ISP part,

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

 ---
  arch/arm/mach-omap2/drm.c |1 -
  arch/arm/mach-omap2/dss-common.c  |3 +--
  arch/arm/mach-omap2/prm2xxx.c |3 +--
  arch/arm/mach-omap2/prm3xxx.c |3 +--
  arch/arm/plat-omap/include/plat/cpu.h |4 
  drivers/media/platform/omap3isp/isp.c |2 --
  drivers/power/avs/smartreflex.c   |2 --
  7 files changed, 3 insertions(+), 15 deletions(-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line unsubscribe 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] fbdev changes for 3.8

2012-12-17 Thread Tomi Valkeinen
On 2012-12-16 22:35, Tony Lindgren wrote:

 Those are all omap internal devices and should be all marked with
 depends on ARCH_OMAP2PLUS.

 It's a different story for external devices that may be used on other
 architectures.

 I only came up with one reason to compile internal devices for other
 architectures: In some cases the driver subsystem maintainer may want to
 be able to compile test subsystem wide changes without having to compile
 for each target separately. But for those cases it's trivial to carry a
 compile test patch that just drops the depends Kconfig entries.
 
 And here's a patch to limit the omap drivers above to omap only.

The patch looks good to me.

The reason I removed the OMAP dependency from OMAP DSS was not (only)
because of the compile testing, but also because I thought it was right:
a driver for an IP block shouldn't presume that the IP is used only on
particular SoC.

But perhaps that's a bit too academic approach for an IP that's in real
world only used for OMAP.

 Tomi




signature.asc
Description: OpenPGP digital signature


Re: [PATCH 1/2] ARM: OMAP: Split vrfb.c to remove last remaining cpu_is_omap usage

2012-12-17 Thread Tomi Valkeinen
On 2012-12-16 22:03, Tony Lindgren wrote:
 Looks like we missed plat-omap/fb.c for cpu_is_omap usage
 mach-omap2. This is the last user of cpu_is_omap, so let's
 quickly fix it up so we can finally remove plat/cpu.h for
 omap2lus.
 
 We want to limit cpu_is_omap macro usage to mach-omap2 only so
 we can make plat/cpu.h private. After this we can finally drop
 plat/cpu.h for omap2+.
 
 Cc: Tomi Valkeinen tomi.valkei...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap1/Makefile |2 +
  arch/arm/mach-omap1/fb.c |   80 
 ++
  arch/arm/mach-omap2/Makefile |2 +
  arch/arm/mach-omap2/fb.c |   50 +-
  arch/arm/plat-omap/Makefile  |2 +
  5 files changed, 85 insertions(+), 51 deletions(-)
  create mode 100644 arch/arm/mach-omap1/fb.c
  rename arch/arm/{plat-omap/fb.c = mach-omap2/fb.c} (76%)

Ok, I didn't realize that plat-omap cannot refer to cpu_is_omap either.
The patch looks fine, except the subject should say split fb.c, not
split vrfb.c.

 Tomi




signature.asc
Description: OpenPGP digital signature


[PATCH] gpio/omap: implement irq_enable/disable using mask/unmask.

2012-12-17 Thread Andreas Fenkart
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
---
 drivers/gpio/gpio-omap.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index d335af1..c1951ec 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -815,6 +815,8 @@ static struct irq_chip gpio_irq_chip = {
.irq_unmask = gpio_unmask_irq,
.irq_set_type   = gpio_irq_type,
.irq_set_wake   = gpio_wake_enable,
+   .irq_disable= gpio_mask_irq,
+   .irq_enable = gpio_unmask_irq,
 };
 
 /*-*/
-- 
1.7.10.4

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


Re: [GIT PULL] fbdev changes for 3.8

2012-12-17 Thread Felipe Balbi
Hi,

On Sun, Dec 16, 2012 at 12:35:37PM -0800, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [121216 09:49]:
  * Dave Jones da...@redhat.com [121215 14:27]:
   On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote:
 On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen 
   tomi.valkei...@ti.com wrote:
  Hi Linus,
 
  Florian, the fbdev maintainer, has been very busy lately, so I 
   offered to send
  the pull request for fbdev for this merge window.
 
 Pulled. However, with this I get the Kconfig question
 
OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW)
 
 which doesn't make a whole lot of sense on x86-64, unless there's
 something about OMAP2 that I don't know.
 
 So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at
 least ARM. Because showing it to anybody else seems insane.
 
 Same goes for FB_OMAP2 for that matter. I realize that it's likely
 nice to get compile testing for this on x86-64 too, but if that's the
 intent, we need to think about it some more. I don't think it's good
 to ask actual normal users questions like this just for compile
 coverage.
   
   This OMAP stuff has been creeping into x86 builds for a while.
   Grep from my current build config ..
   
   # CONFIG_OMAP_OCP2SCP is not set
   # CONFIG_KEYBOARD_OMAP4 is not set
   # CONFIG_OMAP2_DSS is not set
   # CONFIG_OMAP_USB2 is not set
   
   There was some other arm-ism that does the same that I' currently 
   forgetting,
   or maybe that got fixed..
  
  Those are all omap internal devices and should be all marked with
  depends on ARCH_OMAP2PLUS.
  
  It's a different story for external devices that may be used on other
  architectures.
  
  I only came up with one reason to compile internal devices for other
  architectures: In some cases the driver subsystem maintainer may want to
  be able to compile test subsystem wide changes without having to compile
  for each target separately. But for those cases it's trivial to carry a
  compile test patch that just drops the depends Kconfig entries.
 
 And here's a patch to limit the omap drivers above to omap only.
 
 Regards,
 
 Tony
 
 
 From: Tony Lindgren t...@atomide.com
 Date: Sun, 16 Dec 2012 12:28:46 -0800
 Subject: [PATCH] ARM: OMAP: Fix drivers to depend on omap for internal devices
 
 These devices are not available on other architectures, so
 let's limit them to omap.
 
 If the driver subsystem maintainers want to build test
 system wide changes without building for each target,
 it's easy to carry a test patch that just strips out the
 depends entries from Kconfig files.
 
 Signed-off-by: Tony Lindgren t...@atomide.com
 
 --- a/drivers/bus/Kconfig
 +++ b/drivers/bus/Kconfig
 @@ -6,6 +6,7 @@ menu Bus devices
  
  config OMAP_OCP2SCP
   tristate OMAP OCP2SCP DRIVER
 + depends on ARCH_OMAP2PLUS
   help
 Driver to enable ocp2scp module which transforms ocp interface
 protocol to scp protocol. In OMAP4, USB PHY is connected via
 --- a/drivers/input/keyboard/Kconfig
 +++ b/drivers/input/keyboard/Kconfig
 @@ -544,6 +544,7 @@ config KEYBOARD_OMAP
  
  config KEYBOARD_OMAP4
   tristate TI OMAP4+ keypad support
 + depends on ARCH_OMAP2PLUS
   select INPUT_MATRIXKMAP
   help
 Say Y here if you want to use the OMAP4+ keypad.
 --- a/drivers/usb/phy/Kconfig
 +++ b/drivers/usb/phy/Kconfig
 @@ -6,6 +6,7 @@ comment USB Physical Layer drivers
  
  config OMAP_USB2
   tristate OMAP USB2 PHY Driver
 + depends on ARCH_OMAP2PLUS
   select USB_OTG_UTILS
   help
 Enable this to support the transceiver that is part of SOC. This

for Keypad, PHY and OCP2SCP I would rather not as I want to use
linux-next for compile testing our stuff in all arches.

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH 2/2] ARM: OMAP2+: Drop plat/cpu.h for omap2plus

2012-12-17 Thread Jean Pihet
Hi Tony,

On Sun, Dec 16, 2012 at 9:03 PM, Tony Lindgren t...@atomide.com wrote:
 The cpu_is_omap macros are now local to arch/arm/mach-omap2
 in soc.h and plat/cpu.h can finally be dropped for omap2+.
 Thanks everybody for help with fixing the drivers.
Great!

 Note that we can now also remove the unused plat/cpu.h from
 smartreflex.c and isp.c as they will cause compile errors
 with ARCH_MULTIPLATFORM enabled.

 Cc: Jean Pihet jean.pi...@newoldbits.com
 Cc: Kevin Hilman khil...@deeprootsystems.com
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Mauro Carvalho Chehab mche...@redhat.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap2/drm.c |1 -
  arch/arm/mach-omap2/dss-common.c  |3 +--
  arch/arm/mach-omap2/prm2xxx.c |3 +--
  arch/arm/mach-omap2/prm3xxx.c |3 +--
  arch/arm/plat-omap/include/plat/cpu.h |4 
  drivers/media/platform/omap3isp/isp.c |2 --
  drivers/power/avs/smartreflex.c   |2 --
  7 files changed, 3 insertions(+), 15 deletions(-)

For the smartreflex driver:
Acked-by: Jean Pihet j-pi...@ti.com

Regards,
Jean

...

 diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
 index a17d084..6b2238b 100644
 --- a/drivers/power/avs/smartreflex.c
 +++ b/drivers/power/avs/smartreflex.c
 @@ -27,8 +27,6 @@
  #include linux/pm_runtime.h
  #include linux/power/smartreflex.h

 -#include plat/cpu.h
 -
  #define SMARTREFLEX_NAME_LEN   16
  #define NVALUE_NAME_LEN40
  #define SR_DISABLE_TIMEOUT 200

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


Re: [PATCH] OMAP: DSS: add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list

2012-12-17 Thread Tomi Valkeinen
On 2012-12-15 23:08, NeilBrown wrote:
 
 commit 195e672a76056478cc79f5c48343164c9237852e
OMAPDSS: DPI: Remove cpu_is_ checks
 
 made the mistake of assuming that cpu_is_omap34xx() is exclusive of
 other cpu_is_* predicates whereas it includes cpu_is_omap3630().
 
 So on an omap3630, code that was previously enabled by
   if (cpu_is_omap34xx())
 is now disabled as
   dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
 fails.
 
 So add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list.
 
 Cc: Chandrabhanu Mahapatra cmahapa...@ti.com
 Cc: Tomi Valkeinen tomi.valkei...@ti.com
 Signed-off-by: NeilBrown ne...@suse.de
 
 diff --git a/drivers/video/omap2/dss/dss_features.c 
 b/drivers/video/omap2/dss/dss_features.c
 index acbc1e1..aaf3c3f 100644
 --- a/drivers/video/omap2/dss/dss_features.c
 +++ b/drivers/video/omap2/dss/dss_features.c
 @@ -546,6 +546,7 @@ static const enum dss_feat_id omap3630_dss_feat_list[] = {
   FEAT_ALPHA_FIXED_ZORDER,
   FEAT_FIFO_MERGE,
   FEAT_OMAP3_DSI_FIFO_BUG,
 + FEAT_DPI_USES_VDDS_DSI,
  };
  
  static const enum dss_feat_id omap4430_es1_0_dss_feat_list[] = {
 

Thanks, looks correct. Did you encounter a bug related to this, or just
happened to notice?

 Tomi




signature.asc
Description: OpenPGP digital signature


Re: [patch] OMAPDSS: reading past end of array in dispc_dump_regs()

2012-12-17 Thread Tomi Valkeinen
On 2012-12-14 17:01, Dan Carpenter wrote:
 We added another kind of plane in 66a0f9e4ac OMAPDSS: Use WB fifo for
 GFX overlay so this array needs a new entry as well.
 
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
 ---
 Static checker work.  I don't have a way to test this.
 
 diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
 index fedbd2c..bfe62cc 100644
 --- a/drivers/video/omap2/dss/dispc.c
 +++ b/drivers/video/omap2/dss/dispc.c
 @@ -3163,6 +3163,7 @@ static void dispc_dump_regs(struct seq_file *s)
   [OMAP_DSS_VIDEO1]   = VID1,
   [OMAP_DSS_VIDEO2]   = VID2,
   [OMAP_DSS_VIDEO3]   = VID3,
 + [OMAP_DSS_WB]   = WB,
   };
   const char **p_names;
  
 

We don't count WB as an overlay currently, as it's handled a bit
differently, so we never try to access that array with OMAP_DSS_WB. We
don't actually dump any WB related registers currently, it seems.

So I think I'll leave this out for now.

Why does the static checker think OMAP_DSS_WB is needed in the array? I
wonder if I'm reading the code wrong, and we indeed do access the array
with OMAP_DSS_WB...

 Tomi




signature.asc
Description: OpenPGP digital signature


Re: [PATCH V2 4/6] OMAPDSS: DSI: Move DSI specific reg_fields to dsi_feats

2012-12-17 Thread Tomi Valkeinen
Hi,

On 2012-12-05 12:16, Chandrabhanu Mahapatra wrote:
 The DSI specific dss_reg_fields are moved to corresponding dsi_reg_fields
 initialized in dsi_feats. The dsi_feats structure is initialized as per
 corresponding DSS version in dsi_init_features().
 
 Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
 ---
  drivers/video/omap2/dss/dsi.c  |  126 
 +---
  drivers/video/omap2/dss/dss_features.c |   16 
  drivers/video/omap2/dss/dss_features.h |4 -
  3 files changed, 114 insertions(+), 32 deletions(-)
 

 +static int __init dsi_init_features(struct platform_device *dsidev)
 +{
 + const struct feats *src;
 + struct feats *dst;
 +
 + dst = devm_kzalloc(dsidev-dev, sizeof(*dst), GFP_KERNEL);
 + if (!dst) {
 + dev_err(dsidev-dev, Failed to allocate DISPC Features\n);
 + return -ENOMEM;
 + }
 +
 + switch (omapdss_get_version()) {
 + case OMAPDSS_VER_OMAP24xx:
 + src = omap24xx_dsi_feats;
 + break;
 +
 + case OMAPDSS_VER_OMAP34xx_ES1:
 + case OMAPDSS_VER_OMAP34xx_ES3:
 + case OMAPDSS_VER_OMAP3630:
 + case OMAPDSS_VER_AM35xx:
 + src = omap34xx_dsi_feats;
 + break;
 +
 + case OMAPDSS_VER_OMAP4430_ES1:
 + case OMAPDSS_VER_OMAP4430_ES2:
 + case OMAPDSS_VER_OMAP4:
 + src = omap44xx_dsi_feats;
 + break;
 +
 + case OMAPDSS_VER_OMAP5:
 + src = omap54xx_dsi_feats;
 + break;
 +
 + default:
 + return -ENODEV;
 + }

There's no DSI on OMAP2, so that case can be left out.

 Tomi




signature.asc
Description: OpenPGP digital signature


Re: [PATCH V2 2/6] OMAPDSS: DISPC: Move DISPC specific dss_reg_fields to dispc_features

2012-12-17 Thread Tomi Valkeinen
On 2012-12-05 12:16, Chandrabhanu Mahapatra wrote:
 The register fields in dss_reg_fields specific to DISPC are moved from struct
 omap_dss_features to corresponding dispc_reg_fields, initialized in struct
 dispc_features, thereby enabling local access.
 
 Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
 ---
  drivers/video/omap2/dss/dispc.c|  114 
 
  drivers/video/omap2/dss/dss.h  |4 ++
  drivers/video/omap2/dss/dss_features.c |   28 
  drivers/video/omap2/dss/dss_features.h |7 --
  4 files changed, 89 insertions(+), 64 deletions(-)
 
 diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
 index bbba83f..ee4b152 100644
 --- a/drivers/video/omap2/dss/dispc.c
 +++ b/drivers/video/omap2/dss/dispc.c
 @@ -80,6 +80,16 @@ struct dispc_irq_stats {
   unsigned irqs[32];
  };
  
 +struct dispc_reg_fields {
 + struct omapdss_reg_field firhinc;
 + struct omapdss_reg_field firvinc;
 + struct omapdss_reg_field fifo_low_thresh;
 + struct omapdss_reg_field fifo_high_thresh;
 + struct omapdss_reg_field fifosize;
 + struct omapdss_reg_field hori_accu;
 + struct omapdss_reg_field vert_accu;
 +};
 +
  struct dispc_features {
   u8 sw_start;
   u8 fp_start;
 @@ -110,6 +120,8 @@ struct dispc_features {
  
   u32 buffer_size_unit; /* in bytes */
   u32 burst_size_unit; /* in bytes */
 +
 + struct dispc_reg_fields *reg_fields;

This can be pointer to const.

  };
  
  #define DISPC_MAX_NR_FIFOS 5
 @@ -1137,17 +1149,17 @@ static void dispc_mgr_set_size(enum omap_channel 
 channel, u16 width,
  
  static void dispc_init_fifos(void)
  {
 - u32 size;
 + u32 size, unit;
   int fifo;
 - u8 start, end;
 - u32 unit;
 + const struct omapdss_reg_field *fifo_field;
  
   unit = dispc.feat-buffer_size_unit;
  
 - dss_feat_get_reg_field(FEAT_REG_FIFOSIZE, start, end);
 + fifo_field = dispc.feat-reg_fields-fifosize;
  
   for (fifo = 0; fifo  dispc.feat-num_fifos; ++fifo) {
 - size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(fifo), start, end);
 + size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(fifo),
 + fifo_field-start, fifo_field-end);
   size *= unit;
   dispc.fifo_size[fifo] = size;
  
 @@ -1197,8 +1209,8 @@ static u32 dispc_ovl_get_fifo_size(enum omap_plane 
 plane)
  
  void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
  {
 - u8 hi_start, hi_end, lo_start, lo_end;
   u32 unit;
 + const struct omapdss_reg_field *hi_field, *lo_field;
  
   unit = dispc.feat-buffer_size_unit;
  
 @@ -1208,20 +1220,20 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane 
 plane, u32 low, u32 high)
   low /= unit;
   high /= unit;
  
 - dss_feat_get_reg_field(FEAT_REG_FIFOHIGHTHRESHOLD, hi_start, hi_end);
 - dss_feat_get_reg_field(FEAT_REG_FIFOLOWTHRESHOLD, lo_start, lo_end);
 + hi_field = dispc.feat-reg_fields-fifo_high_thresh;
 + lo_field = dispc.feat-reg_fields-fifo_low_thresh;
  
   DSSDBG(fifo(%d) threshold (bytes), old %u/%u, new %u/%u\n,
   plane,
   REG_GET(DISPC_OVL_FIFO_THRESHOLD(plane),
 - lo_start, lo_end) * unit,
 + lo_field-start, lo_field-end) * unit,
   REG_GET(DISPC_OVL_FIFO_THRESHOLD(plane),
 - hi_start, hi_end) * unit,
 + hi_field-start, hi_field-end) * unit,
   low * unit, high * unit);
  
   dispc_write_reg(DISPC_OVL_FIFO_THRESHOLD(plane),
 - FLD_VAL(high, hi_start, hi_end) |
 - FLD_VAL(low, lo_start, lo_end));
 + FLD_VAL(high, hi_field-start, hi_field-end) |
 + FLD_VAL(low, lo_field-start, lo_field-end));
  }
  
  void dispc_enable_fifomerge(bool enable)
 @@ -1289,14 +1301,13 @@ static void dispc_ovl_set_fir(enum omap_plane plane,
   u32 val;
  
   if (color_comp == DISPC_COLOR_COMPONENT_RGB_Y) {
 - u8 hinc_start, hinc_end, vinc_start, vinc_end;
 + const struct omapdss_reg_field *hinc_field, *vinc_field;
  
 - dss_feat_get_reg_field(FEAT_REG_FIRHINC,
 - hinc_start, hinc_end);
 - dss_feat_get_reg_field(FEAT_REG_FIRVINC,
 - vinc_start, vinc_end);
 - val = FLD_VAL(vinc, vinc_start, vinc_end) |
 - FLD_VAL(hinc, hinc_start, hinc_end);
 + hinc_field = dispc.feat-reg_fields-firhinc;
 + vinc_field = dispc.feat-reg_fields-firvinc;
 +
 + val = FLD_VAL(vinc, vinc_field-start, vinc_field-end) |
 + FLD_VAL(hinc, hinc_field-start, hinc_field-end);
  
   dispc_write_reg(DISPC_OVL_FIR(plane), val);
   } else {
 @@ 

Re: [patch] OMAPDSS: reading past end of array in dispc_dump_regs()

2012-12-17 Thread Dan Carpenter
On Mon, Dec 17, 2012 at 02:09:00PM +0200, Tomi Valkeinen wrote:
 Why does the static checker think OMAP_DSS_WB is needed in the array?

drivers/video/omap2/dss/dispc.c +3284

  3274  #define DISPC_REG(plane, name, i) name(plane, i)
  3275  #define DUMPREG(plane, name, i) \
  3276  seq_printf(s, %s_%d(%s)%*s %08x\n, #name, i, p_names[plane], \
  3277  (int)(46 - strlen(#name) - strlen(p_names[plane])),  , \
  3278  dispc_read_reg(DISPC_REG(plane, name, i)))
  3279  
  3280  /* Video pipeline coefficient registers */
  3281  
  3282  /* start from OMAP_DSS_VIDEO1 */
  3283  for (i = 1; i  dss_feat_get_num_ovls(); i++) {
  3284  for (j = 0; j  8; j++)
  3285  DUMPREG(i, DISPC_OVL_FIR_COEF_H, j);

The logic here is that we pass i to DISPC_OVL_FIR_COEF_H() which
passes i to DISPC_FIR_COEF_H_OFFSET().  Anything higher than
OMAP_DSS_WB will trigger a BUG() in DISPC_FIR_COEF_H_OFFSET().

So it's not rock hard logic at all.

regards,
dan carpenter

--
To unsubscribe from this list: send the line unsubscribe 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: [RFC] drm/lcdc: add TI LCD Controller DRM driver

2012-12-17 Thread Tomi Valkeinen
On 2012-12-14 02:04, Rob Clark wrote:
 A simple DRM/KMS driver for the TI LCD Controller found in various
 smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
 CMA helpers.  Currently only the TFP410 DVI encoder is supported
 (tested with beaglebone + DVI cape).  There are also various LCD
 displays, for which support can be added (as I get hw to test on),
 and an external i2c HDMI encoder found on some boards.
 
 The display controller supports a single CRTC.  And the encoder+
 connector are split out into sub-devices.  Depending on which LCD
 or external encoder is actually present, the appropriate output
 module(s) will be loaded.
 
 Signed-off-by: Rob Clark robdcl...@gmail.com
 ---
  drivers/gpu/drm/Kconfig|   2 +
  drivers/gpu/drm/Makefile   |   1 +
  drivers/gpu/drm/lcdc/Kconfig   |  11 +
  drivers/gpu/drm/lcdc/Makefile  |   8 +
  drivers/gpu/drm/lcdc/lcdc_crtc.c   | 544 +
  drivers/gpu/drm/lcdc/lcdc_drv.c| 604 
 +
  drivers/gpu/drm/lcdc/lcdc_drv.h| 162 ++
  drivers/gpu/drm/lcdc/lcdc_regs.h   | 154 ++
  drivers/gpu/drm/lcdc/lcdc_tfp410.c | 424 ++
  drivers/gpu/drm/lcdc/lcdc_tfp410.h |  26 ++
  10 files changed, 1936 insertions(+)
  create mode 100644 drivers/gpu/drm/lcdc/Kconfig
  create mode 100644 drivers/gpu/drm/lcdc/Makefile
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_crtc.c
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.c
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.h
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_regs.h
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.c
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.h

lcdc is quite a common term. The directory should perhaps be something
like ti-lcdc?

Probably not relevant, but I wonder if the same LCDC was used in
omap1... It'd be nice to get rid of the omap1 fb driver.

I'm not very enthusiastic about adding ti-lcdc specific panel/chip
drivers. It's not really a big deal if it's only kernel code, but you
add device-tree bindings also, which is an external API that you need to
support after adding it.

I'd rather see the energy put to common display framework, and get this
whole panel/chip driver issue solved in a generic manner.

 Tomi




signature.asc
Description: OpenPGP digital signature


Re: [PATCH] regulator: core: if voltage scaling fails, restore original voltage values

2012-12-17 Thread Mark Brown
On Sat, Dec 15, 2012 at 04:57:38PM +0200, Felipe Balbi wrote:
 On Sat, Dec 15, 2012 at 11:15:20PM +0900, Mark Brown wrote:

  It's perfectly OK to omit this unless there's an awareness that the
  backport won't work on some kernels.

 that's not what Greg says, but fair enough. Won't discuss it...

Uh, no.  Think about this for a minute - we want bug fixes backporting,
we don't want to be putting process blockers in the way of that
especially not in the cases where fixes apply to all the stable kernels
that are currently active.


signature.asc
Description: Digital signature


Re: [RFC] drm/lcdc: add TI LCD Controller DRM driver

2012-12-17 Thread Rob Clark
On Mon, Dec 17, 2012 at 7:56 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On 2012-12-14 02:04, Rob Clark wrote:
 A simple DRM/KMS driver for the TI LCD Controller found in various
 smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
 CMA helpers.  Currently only the TFP410 DVI encoder is supported
 (tested with beaglebone + DVI cape).  There are also various LCD
 displays, for which support can be added (as I get hw to test on),
 and an external i2c HDMI encoder found on some boards.

 The display controller supports a single CRTC.  And the encoder+
 connector are split out into sub-devices.  Depending on which LCD
 or external encoder is actually present, the appropriate output
 module(s) will be loaded.

 Signed-off-by: Rob Clark robdcl...@gmail.com
 ---
  drivers/gpu/drm/Kconfig|   2 +
  drivers/gpu/drm/Makefile   |   1 +
  drivers/gpu/drm/lcdc/Kconfig   |  11 +
  drivers/gpu/drm/lcdc/Makefile  |   8 +
  drivers/gpu/drm/lcdc/lcdc_crtc.c   | 544 +
  drivers/gpu/drm/lcdc/lcdc_drv.c| 604 
 +
  drivers/gpu/drm/lcdc/lcdc_drv.h| 162 ++
  drivers/gpu/drm/lcdc/lcdc_regs.h   | 154 ++
  drivers/gpu/drm/lcdc/lcdc_tfp410.c | 424 ++
  drivers/gpu/drm/lcdc/lcdc_tfp410.h |  26 ++
  10 files changed, 1936 insertions(+)
  create mode 100644 drivers/gpu/drm/lcdc/Kconfig
  create mode 100644 drivers/gpu/drm/lcdc/Makefile
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_crtc.c
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.c
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.h
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_regs.h
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.c
  create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.h

 lcdc is quite a common term. The directory should perhaps be something
 like ti-lcdc?

yeah.. but not one else was using it (other than internally to the
driver).. I guess we could call it tilcdc or ti-lcdc

 Probably not relevant, but I wonder if the same LCDC was used in
 omap1... It'd be nice to get rid of the omap1 fb driver.

would be interesting if you have any idea where to find hw to test
with (museum?)

 I'm not very enthusiastic about adding ti-lcdc specific panel/chip
 drivers. It's not really a big deal if it's only kernel code, but you
 add device-tree bindings also, which is an external API that you need to
 support after adding it.

 I'd rather see the energy put to common display framework, and get this
 whole panel/chip driver issue solved in a generic manner.

yeah, I was expecting to migrate to CDF once it exists, but needed
something for now.  I'm using the exercise to get my thoughts straight
on how CDF should fit into KMS.  (One thing I plan to add support for
is an i2c connected hdmi encoder.. which looks like it would fit well
in drivers/gpu/drm/i2c.. so the drm encoder-slave stuff might be the
way.)

If you have any suggestions on the DT bindings, I'd like to hear 'em.

BR,
-R

  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 2/2] ARM: OMAP2+: Drop plat/cpu.h for omap2plus

2012-12-17 Thread Mauro Carvalho Chehab
Em Sun, 16 Dec 2012 12:03:17 -0800
Tony Lindgren t...@atomide.com escreveu:

 The cpu_is_omap macros are now local to arch/arm/mach-omap2
 in soc.h and plat/cpu.h can finally be dropped for omap2+.
 Thanks everybody for help with fixing the drivers.
 
 Note that we can now also remove the unused plat/cpu.h from
 smartreflex.c and isp.c as they will cause compile errors
 with ARCH_MULTIPLATFORM enabled.
 
 Cc: Jean Pihet jean.pi...@newoldbits.com
 Cc: Kevin Hilman khil...@deeprootsystems.com
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Mauro Carvalho Chehab mche...@redhat.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap2/drm.c |1 -
  arch/arm/mach-omap2/dss-common.c  |3 +--
  arch/arm/mach-omap2/prm2xxx.c |3 +--
  arch/arm/mach-omap2/prm3xxx.c |3 +--
  arch/arm/plat-omap/include/plat/cpu.h |4 

  drivers/media/platform/omap3isp/isp.c |2 --

Acked-by: Mauro Carvalho Chehab mche...@redhat.com


  drivers/power/avs/smartreflex.c   |2 --

  7 files changed, 3 insertions(+), 15 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
 index fce5aa3..4c7566c 100644
 --- a/arch/arm/mach-omap2/drm.c
 +++ b/arch/arm/mach-omap2/drm.c
 @@ -27,7 +27,6 @@
  
  #include omap_device.h
  #include omap_hwmod.h
 -#include plat/cpu.h
  
  #if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
  
 diff --git a/arch/arm/mach-omap2/dss-common.c 
 b/arch/arm/mach-omap2/dss-common.c
 index 679a047..4be5cfc 100644
 --- a/arch/arm/mach-omap2/dss-common.c
 +++ b/arch/arm/mach-omap2/dss-common.c
 @@ -31,8 +31,7 @@
  #include video/omap-panel-nokia-dsi.h
  #include video/omap-panel-picodlp.h
  
 -#include plat/cpu.h
 -
 +#include soc.h
  #include dss-common.h
  #include mux.h
  
 diff --git a/arch/arm/mach-omap2/prm2xxx.c b/arch/arm/mach-omap2/prm2xxx.c
 index faeab18..cc0e714 100644
 --- a/arch/arm/mach-omap2/prm2xxx.c
 +++ b/arch/arm/mach-omap2/prm2xxx.c
 @@ -18,9 +18,8 @@
  #include linux/io.h
  #include linux/irq.h
  
 +#include soc.h
  #include common.h
 -#include plat/cpu.h
 -
  #include vp.h
  #include powerdomain.h
  #include clockdomain.h
 diff --git a/arch/arm/mach-omap2/prm3xxx.c b/arch/arm/mach-omap2/prm3xxx.c
 index db198d0..39822aa 100644
 --- a/arch/arm/mach-omap2/prm3xxx.c
 +++ b/arch/arm/mach-omap2/prm3xxx.c
 @@ -18,9 +18,8 @@
  #include linux/io.h
  #include linux/irq.h
  
 +#include soc.h
  #include common.h
 -#include plat/cpu.h
 -
  #include vp.h
  #include powerdomain.h
  #include prm3xxx.h
 diff --git a/arch/arm/plat-omap/include/plat/cpu.h 
 b/arch/arm/plat-omap/include/plat/cpu.h
 index b4516ab..c9a66bf 100644
 --- a/arch/arm/plat-omap/include/plat/cpu.h
 +++ b/arch/arm/plat-omap/include/plat/cpu.h
 @@ -32,8 +32,4 @@
  #include mach/soc.h
  #endif
  
 -#ifdef CONFIG_ARCH_OMAP2PLUS
 -#include ../../mach-omap2/soc.h
 -#endif
 -
  #endif
 diff --git a/drivers/media/platform/omap3isp/isp.c 
 b/drivers/media/platform/omap3isp/isp.c
 index a9f6de5..2e8c0cb 100644
 --- a/drivers/media/platform/omap3isp/isp.c
 +++ b/drivers/media/platform/omap3isp/isp.c
 @@ -71,8 +71,6 @@
  #include media/v4l2-common.h
  #include media/v4l2-device.h
  
 -#include plat/cpu.h
 -
  #include isp.h
  #include ispreg.h
  #include ispccdc.h
 diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
 index a17d084..6b2238b 100644
 --- a/drivers/power/avs/smartreflex.c
 +++ b/drivers/power/avs/smartreflex.c
 @@ -27,8 +27,6 @@
  #include linux/pm_runtime.h
  #include linux/power/smartreflex.h
  
 -#include plat/cpu.h
 -
  #define SMARTREFLEX_NAME_LEN 16
  #define NVALUE_NAME_LEN  40
  #define SR_DISABLE_TIMEOUT   200
 


-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe 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: [RFC] drm/lcdc: add TI LCD Controller DRM driver

2012-12-17 Thread Rob Clark
On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark robdcl...@gmail.com wrote:
 I'm not very enthusiastic about adding ti-lcdc specific panel/chip
 drivers. It's not really a big deal if it's only kernel code, but you
 add device-tree bindings also, which is an external API that you need to
 support after adding it.

 I'd rather see the energy put to common display framework, and get this
 whole panel/chip driver issue solved in a generic manner.

 yeah, I was expecting to migrate to CDF once it exists, but needed
 something for now.  I'm using the exercise to get my thoughts straight
 on how CDF should fit into KMS.  (One thing I plan to add support for
 is an i2c connected hdmi encoder.. which looks like it would fit well
 in drivers/gpu/drm/i2c.. so the drm encoder-slave stuff might be the
 way.)

 If you have any suggestions on the DT bindings, I'd like to hear 'em.

btw, a little bit of-topic, but speaking of DT...

Anybody have any clue about how backlight devices are supposed to work
in this brave new DT world?  In the old days, the board file would
stuff a fxn ptr to control backlight in pdata for the driver.  But we
don't have this any more.  I think I need some way to retrieve the
'struct backlight_device' ptr associated with the panel driver, so
that the appropriate dpms fxn ptrs can enable/disable the backlight.

I'm thinking the dt file should have something that looks roughly like:

/* Settings for CDTech_S035Q01 / LCD3 cape: */
panel {
compatible = lcdc,panel;
pinctrl-names = default;
pinctrl-0 = bone_lcd3_cape_lcd_pins;
panel-info {
ac-bias   = 255;
ac-bias-intrpt= 0;
dma-burst-sz  = 16;
bpp   = 16;
fdd   = 0x80;
tft-alt-mode  = 0;
stn-565-mode  = 0;
mono-8bit-mode= 0;
invert-line-clock = 1;
invert-frm-clock  = 1;
sync-edge = 0;
sync-ctrl = 1;
raster-order  = 0;
fifo-th   = 0;
};
display-timings {
native-mode = timing0;
timing0: 320x240 {
hactive = 320;
vactive = 240;
hback-porch = 21;
hfront-porch= 58;
hsync-len   = 47;
vback-porch = 11;
vfront-porch= 23;
vsync-len   = 2;
clock-frequency = 800;
};
};

backlight {
compatible = tps65217-backlight;
isel = 1;
fdim = 200;

tps = tps;   /* link to the tps */
brightness = 100;
};
};

display-timings is based on the of-videomode helpers patch..
panel-info probably needs to be made to be something more generic, but
we need something to know how to configure the crtc properly..

but I'm not quite sure what to do with the backlight..

BR,
-R
--
To unsubscribe from this list: send the line unsubscribe 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] regulator: core: if voltage scaling fails, restore original voltage values

2012-12-17 Thread Felipe Balbi
Hi,

On Mon, Dec 17, 2012 at 02:15:36PM +, Mark Brown wrote:
 On Sat, Dec 15, 2012 at 04:57:38PM +0200, Felipe Balbi wrote:
  On Sat, Dec 15, 2012 at 11:15:20PM +0900, Mark Brown wrote:
 
   It's perfectly OK to omit this unless there's an awareness that the
   backport won't work on some kernels.
 
  that's not what Greg says, but fair enough. Won't discuss it...
 
 Uh, no.  Think about this for a minute - we want bug fixes backporting,
 we don't want to be putting process blockers in the way of that
 especially not in the cases where fixes apply to all the stable kernels
 that are currently active.

then omit the  # v3.x, v3.y  part, but Cc: sta...@vger.kernel.org should
still be there

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH] regulator: core: if voltage scaling fails, restore original voltage values

2012-12-17 Thread Mark Brown
On Mon, Dec 17, 2012 at 05:18:48PM +0200, Felipe Balbi wrote:
 On Mon, Dec 17, 2012 at 02:15:36PM +, Mark Brown wrote:

  Uh, no.  Think about this for a minute - we want bug fixes backporting,
  we don't want to be putting process blockers in the way of that
  especially not in the cases where fixes apply to all the stable kernels
  that are currently active.

 then omit the  # v3.x, v3.y  part, but Cc: sta...@vger.kernel.org should
 still be there

Oh, yes - that's needed.  Sorry, I thought it was the v3.x bit you were
complaining was missing.


signature.asc
Description: Digital signature


Re: [PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes

2012-12-17 Thread Jon Hunter

On 12/17/2012 02:16 AM, Benoit Cousson wrote:
 Hi Jon,
 
 On 12/14/2012 10:18 PM, Jon Hunter wrote:
 Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.

 Please note that the node for OMAP4460 has been placed in a separate
 header file for OMAP4460, because the node is not compatible with
 OMAP4430.
 
 But where is the omap4430 node then?

I have left it out deliberately because OMAP4430 is not yet supported by
PMU as it is dependent on having a driver for the cross-trigger interface.

If you prefer to stick the node in the omap4.dtsi for now then that is
ok, but I wanted to make it clear that this is for omap4460.

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


Re: [PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes

2012-12-17 Thread Benoit Cousson
Hi Jon,

On 12/17/2012 04:58 PM, Jon Hunter wrote:
 
 On 12/17/2012 02:16 AM, Benoit Cousson wrote:
 Hi Jon,

 On 12/14/2012 10:18 PM, Jon Hunter wrote:
 Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.

 Please note that the node for OMAP4460 has been placed in a separate
 header file for OMAP4460, because the node is not compatible with
 OMAP4430.

 But where is the omap4430 node then?
 
 I have left it out deliberately because OMAP4430 is not yet supported by
 PMU as it is dependent on having a driver for the cross-trigger interface.
 
 If you prefer to stick the node in the omap4.dtsi for now then that is
 ok, but I wanted to make it clear that this is for omap4460.

No, that's fine, I was just wondering. You should just add that comment
in the cover letter to make it explicit.

Thanks,
Benoit

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


Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk

2012-12-17 Thread Roger Quadros
On 12/17/2012 10:13 AM, Benoit Cousson wrote:
 Hi,
 
 On 12/14/2012 07:44 PM, Paul Walmsley wrote:
 Hi

 On Fri, 14 Dec 2012, Tony Lindgren wrote:

 Paul, what about this patch? Looks like you've acked the other clock 
 patches in this series but not this one?

 I commented on it briefly here:

 https://patchwork.kernel.org/patch/1838111/

 Maybe Benoît could comment here, but it looks to me (based on a 
 superficial look at the hardware clock tree data) that these clock nodes 
 should exist.  In an ideal world, we'd be able to get back to the 
 autogeneration of this clock data.
 
 I'm not sure to understand either the rational for that patch. What the
 point of merging the two nodes?
 I mean, we can do it, but AFAIR, we have always decided to use atomic
 node instead of big nodes that handle everything.


I can see a similar thing done for mcbsp clocks (e.g. /* Merged
func_mcbsp1_gfclk into mcbsp1 */), mmc clocks, timer clocks, mcasp
clock, and sgx clock. i.e. The clock sel (mux) is combined with clock
gate. I don't see why USB host has to be done differently.

Were exceptions made for the above clocks in the auto generation code?

The problem from driver point of view is that it has to manage an
additional clock per port. Not a big deal, but I thought it could be
avoided.

regards,
-roger


--
To unsubscribe from this list: send the line unsubscribe 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: MUSB-HDRC Gadget driving VBUS inappropriately

2012-12-17 Thread Felipe Balbi
On Fri, Dec 14, 2012 at 05:38:10PM -0800, ian coolidge wrote:
 Felipe, Tony, Grazvydas, Thanks for the responses,
 
 On Fri, Dec 14, 2012 at 4:13 AM, Felipe Balbi ba...@ti.com wrote:
 
  Hi,
 
  On Fri, Dec 14, 2012 at 02:13:07PM +0200, Grazvydas Ignotas wrote:
   On Fri, Dec 14, 2012 at 11:53 AM, Ian Coolidge iancooli...@gmail.com
  wrote:
we find that with about a 2% chance, the gadget comes up in some kind
  of firmware failed state, driving VBUS.
In this condition, we found that MUSB_DEVCTL_SESSION bit was set.
I understand this to be indicative of MUSB thinking it is in host
  mode, which agrees with the driven VBUS.
Further, in this state, I found that usually, there was one interrupt
  from twl4030_usb, but NO interrupts from musb-hdrc.
  
   I'm also also often seeing this and don't know any workaround except
   powercycling the board :(
   This was kind or relieved for me after I changed it to deinit musb on
   shutdown/reset (3.3 should have that patch merged), however if you
   randomly reset the board, there is still something like 30-50% chance
   musb will come up dead, and on proper reset it's still something like
   5% chance like you reported.
 
  hehe, then you should've reported earlier :-)
 
  Anyway, I really think this has something to do with some bogus
  set_vbus() calls.
 
  Likely that looking at probe() path for checks for MUSB_DEVCTL_VBUS will
  probably show you something which is wrong. Maybe the driver is assuming
  that if VBUS bitfield is zero, then it kicks host side, or something.
 
  Go over that part of the code and you probably will find something.
 
  --
  balbi
 
 
 So, I did some more testing, just printing out MUSB_DEVCTL each time. At
 omap2430.c init,
 musb_probe()-musb_init_controller()-omap2430_musb_init(),
 I always saw 0x80. This corresponds to MUSB_DEVCTL_BDEVICE.
 It appears, then, that the MUSB is initialized correctly, but becomes bad
 somehow. I'll continue to dig into this, but it would be nice to have some
 simple abstract description of what the SESSION bit actually does here.
 It's used as both an input and an output throughout the MUSB Linux driver,
 and judging by comments, appears to have different behavior in different
 configurations. Felipe?

Session bit, really means a session, a USB session. It has different
meanings (to some extent) when working with Host or Gadget. For Gadget
mode, the session bit also triggers SRP, on host mode, maybe it's used
to start sourcing VBUS, who knows.

Also look at the usage of musb-is_active. That's a flag use for host
mode. IIRC, it tells other parts of the driver to connect the vbus
charge pump, but my memory fails now :-s

-- 
balbi


signature.asc
Description: Digital signature


Re: [RFC 2/5] ARM: dts: Add Cross Trigger Interface binding

2012-12-17 Thread Mark Rutland
On Thu, Dec 13, 2012 at 07:21:30PM +, Jon Hunter wrote:
 
 On 12/13/2012 11:41 AM, Will Deacon wrote:
  On Wed, Dec 12, 2012 at 09:43:05PM +, Jon Hunter wrote:
  Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
  The ARM Cross Trigger Interface provides a way to route events between
  processor modules. For example, on OMAP4430 we use the CTI module to
  route PMU events to the GIC interrupt module.
 
  Signed-off-by: Jon Hunter jon-hun...@ti.com
  ---
   Documentation/devicetree/bindings/arm/cti.txt |   32 
  +
   1 file changed, 32 insertions(+)
   create mode 100644 Documentation/devicetree/bindings/arm/cti.txt
 
  diff --git a/Documentation/devicetree/bindings/arm/cti.txt 
  b/Documentation/devicetree/bindings/arm/cti.txt
  new file mode 100644
  index 000..4a0e2d3
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/arm/cti.txt
  @@ -0,0 +1,32 @@
  +* ARM Cross Trigger Interface (CTI)
  +
  +The ARM Cross Trigger Interface provides a way to route events between
  +processor modules. For example, debug events from one processor can be
  +broadcasted to other processors. The events that can be routed between
  +processors are specific to the device.
  +
  +Required properties:
  +
  +- compatible: Should be arm,primecell.
  +- interrupts: Interrupt associated with CTI module.
  +- reg:Contains timer register address range 
  (base
  +  address and length).
  +- arm,cti-name:   A unique name for the CTI module, that 
  will be
  +  used when requesting the CTI module instance.
  +
  +
  +Optional properties:
  +
  +- arm-primecell-periphid: Primecell peripheral ID associated with CTI
  +  module.
  
  For multi-cluster systems, I wouldn't be surprised to see multiple CTI
  instances, each with different CPU affinities. Can we include an affinity
  property following Mark's proposed binding?
  

  http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html
 
 Yes I can take a look. Would something like that be applicable to pmu as
 well or is that unlikely to have different affinities? I am just
 wondering if there is something that we should implement in general for
 the various primecell components.

Do you mean for describing the PMU's affinity to the perf subsystem or its
wiring to the CTI?

It's certainly applicable for the former; I've been working on a series to
enable support for the PMUs in both clusters in a A15x2 A7x3 coretile using the
binding, and I intend to post a series shortly. I'm not sure about the latter,
as I don't have much of an understanding about the CTI.

I'm not sure how many other components have affinity concerns, but the
intention is for the binding to be reusable.

 
 Cheers
 Jon
 

Thanks,
Mark.

--
To unsubscribe from this list: send the line unsubscribe 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 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk

2012-12-17 Thread Benoit Cousson
On 12/17/2012 05:13 PM, Roger Quadros wrote:
 On 12/17/2012 10:13 AM, Benoit Cousson wrote:
 Hi,

 On 12/14/2012 07:44 PM, Paul Walmsley wrote:
 Hi

 On Fri, 14 Dec 2012, Tony Lindgren wrote:

 Paul, what about this patch? Looks like you've acked the other clock 
 patches in this series but not this one?

 I commented on it briefly here:

 https://patchwork.kernel.org/patch/1838111/

 Maybe Benoît could comment here, but it looks to me (based on a 
 superficial look at the hardware clock tree data) that these clock nodes 
 should exist.  In an ideal world, we'd be able to get back to the 
 autogeneration of this clock data.

 I'm not sure to understand either the rational for that patch. What the
 point of merging the two nodes?
 I mean, we can do it, but AFAIR, we have always decided to use atomic
 node instead of big nodes that handle everything.

 
 I can see a similar thing done for mcbsp clocks (e.g. /* Merged
 func_mcbsp1_gfclk into mcbsp1 */), mmc clocks, timer clocks, mcasp
 clock, and sgx clock. i.e. The clock sel (mux) is combined with clock
 gate. I don't see why USB host has to be done differently.

Hehe, well, in fact USB is using the right approach, the others are the
exceptions :-)

It was done for legacy reason but should disappear once the modulemode
will be be removed from the clock nodes.

 Were exceptions made for the above clocks in the auto generation code?
 
 The problem from driver point of view is that it has to manage an
 additional clock per port. Not a big deal, but I thought it could be
 avoided.

In theory, the driver should just managed the mux. The modulemode being
managed already by hwmod.

Regards,
Benoit

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


Re: [RFC 2/5] ARM: dts: Add Cross Trigger Interface binding

2012-12-17 Thread Jon Hunter

On 12/17/2012 10:20 AM, Mark Rutland wrote:
 On Thu, Dec 13, 2012 at 07:21:30PM +, Jon Hunter wrote:

 On 12/13/2012 11:41 AM, Will Deacon wrote:
 On Wed, Dec 12, 2012 at 09:43:05PM +, Jon Hunter wrote:
 Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
 The ARM Cross Trigger Interface provides a way to route events between
 processor modules. For example, on OMAP4430 we use the CTI module to
 route PMU events to the GIC interrupt module.

 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
  Documentation/devicetree/bindings/arm/cti.txt |   32 
 +
  1 file changed, 32 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/arm/cti.txt

 diff --git a/Documentation/devicetree/bindings/arm/cti.txt 
 b/Documentation/devicetree/bindings/arm/cti.txt
 new file mode 100644
 index 000..4a0e2d3
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/arm/cti.txt
 @@ -0,0 +1,32 @@
 +* ARM Cross Trigger Interface (CTI)
 +
 +The ARM Cross Trigger Interface provides a way to route events between
 +processor modules. For example, debug events from one processor can be
 +broadcasted to other processors. The events that can be routed between
 +processors are specific to the device.
 +
 +Required properties:
 +
 +- compatible: Should be arm,primecell.
 +- interrupts: Interrupt associated with CTI module.
 +- reg:Contains timer register address range 
 (base
 +  address and length).
 +- arm,cti-name:   A unique name for the CTI module, that 
 will be
 +  used when requesting the CTI module instance.
 +
 +
 +Optional properties:
 +
 +- arm-primecell-periphid: Primecell peripheral ID associated with CTI
 +  module.

 For multi-cluster systems, I wouldn't be surprised to see multiple CTI
 instances, each with different CPU affinities. Can we include an affinity
 property following Mark's proposed binding?

   
 http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html

 Yes I can take a look. Would something like that be applicable to pmu as
 well or is that unlikely to have different affinities? I am just
 wondering if there is something that we should implement in general for
 the various primecell components.
 
 Do you mean for describing the PMU's affinity to the perf subsystem or its
 wiring to the CTI?

Yes the PMU's affinity in general, ignoring CTI for now.

 It's certainly applicable for the former; I've been working on a series to
 enable support for the PMUs in both clusters in a A15x2 A7x3 coretile using 
 the
 binding, and I intend to post a series shortly. I'm not sure about the latter,
 as I don't have much of an understanding about the CTI.

Ok great. I think that this use-case of PMU+CTI is a special case for
OMAP. CTI could be used for many things and for some reason TI hooked up
the PMU interrupt via the CTI on OMAP4430 (which has been giving me
grief ;-)

So if there is a general way to describe the affinity of a module, such
as PMU, I could re-use this and add to the CTI binding as Will suggested.

 I'm not sure how many other components have affinity concerns, but the
 intention is for the binding to be reusable.

Great.

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


Re: [RFC] drm/lcdc: add TI LCD Controller DRM driver

2012-12-17 Thread Rob Clark
On Mon, Dec 17, 2012 at 9:26 AM, Sekhar Nori nori.sek...@gmail.com wrote:
 Hi Rob,


 On Monday, December 17, 2012, Rob Clark wrote:

 On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark robdcl...@gmail.com wrote:
  I'm not very enthusiastic about adding ti-lcdc specific panel/chip
  drivers. It's not really a big deal if it's only kernel code, but you
  add device-tree bindings also, which is an external API that you need
  to
  support after adding it.
 
  I'd rather see the energy put to common display framework, and get this
  whole panel/chip driver issue solved in a generic manner.
 
  yeah, I was expecting to migrate to CDF once it exists, but needed
  something for now.  I'm using the exercise to get my thoughts straight
  on how CDF should fit into KMS.  (One thing I plan to add support for
  is an i2c connected hdmi encoder.. which looks like it would fit well
  in drivers/gpu/drm/i2c.. so the drm encoder-slave stuff might be the
  way.)
 
  If you have any suggestions on the DT bindings, I'd like to hear 'em.

 btw, a little bit of-topic, but speaking of DT...

 Anybody have any clue about how backlight devices are supposed to work
 in this brave new DT world?


 See Runtime interpreted power sequences here:
  http://lkml.indiana.edu/hypermail/linux/kernel/1208.2/00029.html

 It is an attempt to address this need.

hmm, I'm not really sure that is what is needed..  or rather, it might
perhaps make sense to have a generic backlight driver implementation
that could be used where appropriate, but I'm a bit suspicious about
that trying to cover absolutely everything.

From the drm/display driver we don't even want to care how the
backlight is implemented.  You could have (just making something up
hypothetically) a backlight controlled via a uart or some sort of
other crazy magic.. and eventually the generic interpreter gets out of
hand.

Really I think we just want a way to retrieve a 'struct
backlight_device *' that is created somewhere else.  We don't care how
that backlight driver is implemented.  I don't think we want an
interpreter.. we want a way to lookup backlight device by name or
phandle or something like that.

BR,
-R
--
To unsubscribe from this list: send the line unsubscribe 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: [RESEND PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes

2012-12-17 Thread Mark Rutland
On Fri, Dec 14, 2012 at 09:26:37PM +, Jon Hunter wrote:
 Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
 
 Please note that the node for OMAP4460 has been placed in a separate
 header file for OMAP4460, because the node is not compatible with
 OMAP4430.
 
 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
  arch/arm/boot/dts/omap2.dtsi |5 +
  arch/arm/boot/dts/omap3.dtsi |6 ++
  arch/arm/boot/dts/omap4-panda-es.dts |2 ++
  arch/arm/boot/dts/omap4460.dtsi  |   18 ++
  4 files changed, 31 insertions(+)
  create mode 100644 arch/arm/boot/dts/omap4460.dtsi
 
 diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
 index 761c4b6..27f5ea1 100644
 --- a/arch/arm/boot/dts/omap2.dtsi
 +++ b/arch/arm/boot/dts/omap2.dtsi
 @@ -26,6 +26,11 @@
   };
   };
  
 + pmu {
 + compatible = arm,arm1136-pmu;
 + interrupts = 3;
 + };
 +
   soc {
   compatible = ti,omap-infra;
   mpu {
 diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
 index 1acc261..6c63118 100644
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -26,6 +26,12 @@
   };
   };
  
 + pmu {
 + compatible = arm,cortex-a8-pmu;
 + interrupts = 3;
 + ti,hwmods = debugss;
 + };
 +
   /*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
 diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
 b/arch/arm/boot/dts/omap4-panda-es.dts
 index 73bc1a6..2a6e344 100644
 --- a/arch/arm/boot/dts/omap4-panda-es.dts
 +++ b/arch/arm/boot/dts/omap4-panda-es.dts
 @@ -5,7 +5,9 @@
   * it under the terms of the GNU General Public License version 2 as
   * published by the Free Software Foundation.
   */
 +
  /include/ omap4-panda.dts
 +/include/ omap4460.dtsi
  
  /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
  sound {
 diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
 new file mode 100644
 index 000..1270890
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap4460.dtsi
 @@ -0,0 +1,18 @@
 +/*
 + * Device Tree Source for OMAP4460 SoC
 + *
 + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This file is licensed under the terms of the GNU General Public License
 + * version 2.  This program is licensed as is without any warranty of any
 + * kind, whether express or implied.
 + */
 +
 +/ {
 + pmu {
 + compatible = arm,cortex-a9-pmu;
 + interrupts = 0 54 0x4
 +   0 55 0x4;

In other places I've seen interrupts properties written as:

interrupts =  irq1... ,
  irq2... ,
  irqN... ;

Where each individual interrupt is surrounded by angle brackets. This produces
the exact same dtb, but may appear easier to read.

This might not be the right time and place to raise it, but it'd be nice if we
used one style consistently.

 + ti,hwmods = debugss;
 + };
 +};
 -- 
 1.7.10.4
 
 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss
 

Thanks,
Mark.

--
To unsubscribe from this list: send the line unsubscribe 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: [RESEND PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes

2012-12-17 Thread Jon Hunter

On 12/17/2012 10:38 AM, Mark Rutland wrote:
 On Fri, Dec 14, 2012 at 09:26:37PM +, Jon Hunter wrote:
 Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.

 Please note that the node for OMAP4460 has been placed in a separate
 header file for OMAP4460, because the node is not compatible with
 OMAP4430.

 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
  arch/arm/boot/dts/omap2.dtsi |5 +
  arch/arm/boot/dts/omap3.dtsi |6 ++
  arch/arm/boot/dts/omap4-panda-es.dts |2 ++
  arch/arm/boot/dts/omap4460.dtsi  |   18 ++
  4 files changed, 31 insertions(+)
  create mode 100644 arch/arm/boot/dts/omap4460.dtsi

 diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
 index 761c4b6..27f5ea1 100644
 --- a/arch/arm/boot/dts/omap2.dtsi
 +++ b/arch/arm/boot/dts/omap2.dtsi
 @@ -26,6 +26,11 @@
  };
  };
  
 +pmu {
 +compatible = arm,arm1136-pmu;
 +interrupts = 3;
 +};
 +
  soc {
  compatible = ti,omap-infra;
  mpu {
 diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
 index 1acc261..6c63118 100644
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -26,6 +26,12 @@
  };
  };
  
 +pmu {
 +compatible = arm,cortex-a8-pmu;
 +interrupts = 3;
 +ti,hwmods = debugss;
 +};
 +
  /*
   * The soc node represents the soc top level view. It is uses for IPs
   * that are not memory mapped in the MPU view or for the MPU itself.
 diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
 b/arch/arm/boot/dts/omap4-panda-es.dts
 index 73bc1a6..2a6e344 100644
 --- a/arch/arm/boot/dts/omap4-panda-es.dts
 +++ b/arch/arm/boot/dts/omap4-panda-es.dts
 @@ -5,7 +5,9 @@
   * it under the terms of the GNU General Public License version 2 as
   * published by the Free Software Foundation.
   */
 +
  /include/ omap4-panda.dts
 +/include/ omap4460.dtsi
  
  /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
  sound {
 diff --git a/arch/arm/boot/dts/omap4460.dtsi 
 b/arch/arm/boot/dts/omap4460.dtsi
 new file mode 100644
 index 000..1270890
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap4460.dtsi
 @@ -0,0 +1,18 @@
 +/*
 + * Device Tree Source for OMAP4460 SoC
 + *
 + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This file is licensed under the terms of the GNU General Public License
 + * version 2.  This program is licensed as is without any warranty of any
 + * kind, whether express or implied.
 + */
 +
 +/ {
 +pmu {
 +compatible = arm,cortex-a9-pmu;
 +interrupts = 0 54 0x4
 +  0 55 0x4;
 
 In other places I've seen interrupts properties written as:
 
 interrupts =  irq1... ,
   irq2... ,
 irqN... ;
 
 Where each individual interrupt is surrounded by angle brackets. This produces
 the exact same dtb, but may appear easier to read.
 
 This might not be the right time and place to raise it, but it'd be nice if we
 used one style consistently.

I see that we do define interrupts like that for other OMAP devices and
so I can update this to be consistent.

Benoit, let me know if you want me to resend or if you want to update
locally.

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


Re: [PATCH 1/2] ARM: OMAP: Split vrfb.c to remove last remaining cpu_is_omap usage

2012-12-17 Thread Tony Lindgren
* Tomi Valkeinen tomi.valkei...@ti.com [121217 01:33]:
 On 2012-12-16 22:03, Tony Lindgren wrote:
  Looks like we missed plat-omap/fb.c for cpu_is_omap usage
  mach-omap2. This is the last user of cpu_is_omap, so let's
  quickly fix it up so we can finally remove plat/cpu.h for
  omap2lus.
  
  We want to limit cpu_is_omap macro usage to mach-omap2 only so
  we can make plat/cpu.h private. After this we can finally drop
  plat/cpu.h for omap2+.
  
  Cc: Tomi Valkeinen tomi.valkei...@ti.com
  Signed-off-by: Tony Lindgren t...@atomide.com
  ---
   arch/arm/mach-omap1/Makefile |2 +
   arch/arm/mach-omap1/fb.c |   80 
  ++
   arch/arm/mach-omap2/Makefile |2 +
   arch/arm/mach-omap2/fb.c |   50 +-
   arch/arm/plat-omap/Makefile  |2 +
   5 files changed, 85 insertions(+), 51 deletions(-)
   create mode 100644 arch/arm/mach-omap1/fb.c
   rename arch/arm/{plat-omap/fb.c = mach-omap2/fb.c} (76%)
 
 Ok, I didn't realize that plat-omap cannot refer to cpu_is_omap either.

We could, but I'd rather not as what we have left in plat-omap should
all be just drivers eventually. And in this case the fb code is already
completely separate for omap1 and omap2+, so it's better just to split
it up. It makes fixing up the initcalls for omap2+ multiplatform easier
when booting on other SoCs than omap.

 The patch looks fine, except the subject should say split fb.c, not
 split vrfb.c.

Thanks I'll update the subject.

Regards,

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


[PATCH 1/2] ARM: OMAP3: PRCM: Fix incorrect read of reset sources

2012-12-17 Thread Ivan Khoronzhuk
The flag mask are incorrect, so fix it.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
 arch/arm/mach-omap2/prcm.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 0f51e03..dc45156 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -48,9 +48,10 @@ void __iomem *prcm_mpu_base;
 
 u32 omap_prcm_get_reset_sources(void)
 {
-   /* XXX This presumably needs modification for 34XX */
-   if (cpu_is_omap24xx() || cpu_is_omap34xx())
+   if (cpu_is_omap24xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP2_RM_RSTST)  0x7f;
+   if (cpu_is_omap34xx())
+   return omap2_prm_read_mod_reg(WKUP_MOD, OMAP2_RM_RSTST)  0x7ff;
if (cpu_is_omap44xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP4_RM_RSTST)  0x7f;
 
-- 
1.7.9.5

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


[PATCH 2/2] ARM: OMAP4: PRCM: Fix incorrect read of reset sources

2012-12-17 Thread Ivan Khoronzhuk
The address of PRM_RSTST register and flag mask are incorrect,
so fix it.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
 arch/arm/mach-omap2/prcm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index dc45156..02f27f2 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -53,8 +53,8 @@ u32 omap_prcm_get_reset_sources(void)
if (cpu_is_omap34xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP2_RM_RSTST)  0x7ff;
if (cpu_is_omap44xx())
-   return omap2_prm_read_mod_reg(WKUP_MOD, OMAP4_RM_RSTST)  0x7f;
-
+   return omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+  OMAP4_PRM_RSTST_OFFSET)  0x7ff;
return 0;
 }
 EXPORT_SYMBOL(omap_prcm_get_reset_sources);
-- 
1.7.9.5

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


Re: [RESEND PATCH 2/2] ARM: dts: OMAP2+: Add PMU nodes

2012-12-17 Thread Benoit Cousson
On 12/17/2012 05:58 PM, Jon Hunter wrote:
 
 On 12/17/2012 10:38 AM, Mark Rutland wrote:
 On Fri, Dec 14, 2012 at 09:26:37PM +, Jon Hunter wrote:
 Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.

 Please note that the node for OMAP4460 has been placed in a separate
 header file for OMAP4460, because the node is not compatible with
 OMAP4430.

 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
  arch/arm/boot/dts/omap2.dtsi |5 +
  arch/arm/boot/dts/omap3.dtsi |6 ++
  arch/arm/boot/dts/omap4-panda-es.dts |2 ++
  arch/arm/boot/dts/omap4460.dtsi  |   18 ++
  4 files changed, 31 insertions(+)
  create mode 100644 arch/arm/boot/dts/omap4460.dtsi

 diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
 index 761c4b6..27f5ea1 100644
 --- a/arch/arm/boot/dts/omap2.dtsi
 +++ b/arch/arm/boot/dts/omap2.dtsi
 @@ -26,6 +26,11 @@
 };
 };
  
 +   pmu {
 +   compatible = arm,arm1136-pmu;
 +   interrupts = 3;
 +   };
 +
 soc {
 compatible = ti,omap-infra;
 mpu {
 diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
 index 1acc261..6c63118 100644
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -26,6 +26,12 @@
 };
 };
  
 +   pmu {
 +   compatible = arm,cortex-a8-pmu;
 +   interrupts = 3;
 +   ti,hwmods = debugss;
 +   };
 +
 /*
  * The soc node represents the soc top level view. It is uses for IPs
  * that are not memory mapped in the MPU view or for the MPU itself.
 diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
 b/arch/arm/boot/dts/omap4-panda-es.dts
 index 73bc1a6..2a6e344 100644
 --- a/arch/arm/boot/dts/omap4-panda-es.dts
 +++ b/arch/arm/boot/dts/omap4-panda-es.dts
 @@ -5,7 +5,9 @@
   * it under the terms of the GNU General Public License version 2 as
   * published by the Free Software Foundation.
   */
 +
  /include/ omap4-panda.dts
 +/include/ omap4460.dtsi
  
  /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
  sound {
 diff --git a/arch/arm/boot/dts/omap4460.dtsi 
 b/arch/arm/boot/dts/omap4460.dtsi
 new file mode 100644
 index 000..1270890
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap4460.dtsi
 @@ -0,0 +1,18 @@
 +/*
 + * Device Tree Source for OMAP4460 SoC
 + *
 + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This file is licensed under the terms of the GNU General Public License
 + * version 2.  This program is licensed as is without any warranty of any
 + * kind, whether express or implied.
 + */
 +
 +/ {
 +   pmu {
 +   compatible = arm,cortex-a9-pmu;
 +   interrupts = 0 54 0x4
 + 0 55 0x4;

 In other places I've seen interrupts properties written as:

 interrupts =  irq1... ,
   irq2... ,
irqN... ;

 Where each individual interrupt is surrounded by angle brackets. This 
 produces
 the exact same dtb, but may appear easier to read.

 This might not be the right time and place to raise it, but it'd be nice if 
 we
 used one style consistently.
 
 I see that we do define interrupts like that for other OMAP devices and
 so I can update this to be consistent.
 
 Benoit, let me know if you want me to resend or if you want to update
 locally.

Yep, I agree with Mark, I don't like this style either.

If you don't mind, I'd prefer you resend the series...

Thanks,
Benoit


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


[PATCH V2 0/2] ARM: dts: Add PMU support for OMAP2+

2012-12-17 Thread Jon Hunter
Add device-tree PMU support for OMAP2, OMAP3 and OMAP4460. OMAP4430
is not included because PMU is not currently supported on this device
due to absence of a cross-trigger interface driver.

Tested with PERF on OMAP3430 Beagle Board and OMAP4460 Panda Board.
Boot tested only on OMAP2420 H4.

Jon Hunter (2):
  ARM: OMAP2+: Prepare for device-tree PMU support
  ARM: dts: OMAP2+: Add PMU nodes

 arch/arm/boot/dts/omap2.dtsi |5 +
 arch/arm/boot/dts/omap3.dtsi |6 ++
 arch/arm/boot/dts/omap4-panda-es.dts |2 ++
 arch/arm/boot/dts/omap4460.dtsi  |   18 ++
 arch/arm/mach-omap2/pmu.c|   14 +++---
 5 files changed, 42 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap4460.dtsi

-- 
1.7.10.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 V2 2/2] ARM: dts: OMAP2+: Add PMU nodes

2012-12-17 Thread Jon Hunter
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.

Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the absence of a cross-trigger
interface driver.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/boot/dts/omap2.dtsi |5 +
 arch/arm/boot/dts/omap3.dtsi |6 ++
 arch/arm/boot/dts/omap4-panda-es.dts |2 ++
 arch/arm/boot/dts/omap4460.dtsi  |   18 ++
 4 files changed, 31 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap4460.dtsi

diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
 
+   pmu {
+   compatible = arm,arm1136-pmu;
+   interrupts = 3;
+   };
+
soc {
compatible = ti,omap-infra;
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6c63118 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
 
+   pmu {
+   compatible = arm,cortex-a8-pmu;
+   interrupts = 3;
+   ti,hwmods = debugss;
+   };
+
/*
 * The soc node represents the soc top level view. It is uses for IPs
 * that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+
 /include/ omap4-panda.dts
+/include/ omap4460.dtsi
 
 /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
 sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 000..0a1d38b
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+   pmu {
+   compatible = arm,cortex-a9-pmu;
+   interrupts = 0 54 0x4,
+0 55 0x4;
+   ti,hwmods = debugss;
+   };
+};
-- 
1.7.10.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 V2 1/2] ARM: OMAP2+: Prepare for device-tree PMU support

2012-12-17 Thread Jon Hunter
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.

PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/pmu.c |   14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index eb78ae7..1a0799c 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  */
+#include linux/of.h
+
 #include asm/pmu.h
 
 #include soc.h
@@ -64,6 +66,15 @@ static int __init omap_init_pmu(void)
unsigned oh_num;
char **oh_names;
 
+   /* XXX Remove this check when the CTI driver is available */
+   if (cpu_is_omap443x()) {
+   pr_info(ARM PMU: not yet supported on OMAP4430 due to missing 
CTI driver\n);
+   return 0;
+   }
+
+   if (of_have_populated_dt())
+   return 0;
+
/*
 * To create an ARM-PMU device the following HWMODs
 * are required for the various OMAP2+ devices.
@@ -76,9 +87,6 @@ static int __init omap_init_pmu(void)
if (cpu_is_omap443x()) {
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
-   /* XXX Remove the next two lines when CTI driver available */
-   pr_info(ARM PMU: not yet supported on OMAP4430 due to missing 
CTI driver\n);
-   return 0;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
-- 
1.7.10.4

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


Re: [PATCH V2 0/2] ARM: dts: Add PMU support for OMAP2+

2012-12-17 Thread Jon Hunter

On 12/17/2012 11:49 AM, Jon Hunter wrote:
 Add device-tree PMU support for OMAP2, OMAP3 and OMAP4460. OMAP4430
 is not included because PMU is not currently supported on this device
 due to absence of a cross-trigger interface driver.
 
 Tested with PERF on OMAP3430 Beagle Board and OMAP4460 Panda Board.
 Boot tested only on OMAP2420 H4.

Forgot to mention that V2, addresses Mark Rutland's comment on interrupt
syntax for omap4460 PMU node. I also added a comment on why OMAP4430 is
not supported too.

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


[GIT PULL] omap fixes and cleanups for v3.8 merge window

2012-12-17 Thread Tony Lindgren
Hi Arnd  Olof,

Here are some fixes, including a omap2plus_defconfig build fix
caused by the merge conflict with fb branch as the merge notes
were missed probably because the pull got resolved automatically.

I had to fix the subject line for one patch and added some acks,
so the patches have recent timestamps. The patches themselves
have not changed since yesterday.

See also the tag notes below for the other changes included.

Regards,

Tony


The following changes since commit 2b8318881ddbcb67c5e8d2178b4228474944:

  Merge tag 'fbdev-for-3.8' of git://gitorious.org/linux-omap-dss2/linux 
(2012-12-15 13:03:48 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v3.8/fixes-for-merge-window-v3-signed

for you to fetch changes up to 3e194c88f8b71700822828749187e65853ed8166:

  ARM: OMAP: Fix drivers to depend on omap for internal devices (2012-12-17 
09:20:47 -0800)


These patches fixes a build error caused by a merge
conflict with the fb code, few timer warnings, and longer
term regressions for tfp410 and omap h4 ethernet. Also
included is a GPIO mode fix for the legacy mux code.

I've also included few more patches to finish the omap
changes for multiplatform conversion that are not strictly
fixes, but were too complex to do with the dependencies
during the merge window. Those are to move of serial-omap.h
to platform_data, and the removal of remaining cpu_is_omap
macro usage outside mach-omap2.

Then there are several trivial fixes for typos and
few minimal omap2plus_defconfig updates.


AnilKumar Chimata (1):
  ARM: OMAP2+: omap2plus_defconfig: Add tps65217 support

Javier Martinez Canillas (3):
  ARM: OMAP2+: common: remove use of vram
  ARM: OMAP2+: enable devtmpfs and devtmpfs automount
  ARM: OMAP2+: omap2plus_defconfig: enable twl4030 SoC audio

Jon Hunter (7):
  ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
  ARM: AM335x: Fix warning in timer.c
  ARM: OMAP2420: Fix ethernet support for OMAP2420 H4
  ARM: OMAP: Remove debug-devices.c
  ARM: dts: OMAP2420: Correct H4 board memory size
  ARM: dts: Add build target for omap4-panda-a4
  ARM: OMAP2+: PMU: Remove unused header

Julia Lawall (1):
  arch/arm/mach-omap2/dpll3xxx.c: drop if around WARN_ON

Oleg Matcovschi (1):
  OMAP2+: mux: Fixed gpio mux mode analysis

Peter Ujfalusi (1):
  ARM: OMAP2+: omap_twl: Change TWL4030_MODULE_PM_RECEIVER to 
TWL_MODULE_PM_RECEIVER

Roger Quadros (1):
  mfd: omap-usb-host: get rid of cpu_is_omap..() macros

Srinivas Kandagatla (1):
  ARM/omap: use module_platform_driver macro

Tomi Valkeinen (1):
  OMAP: board-files: fix i2c_bus for tfp410

Tony Lindgren (7):
  Merge branch 'fixes-timer-build' of git://github.com/jonhunter/linux into 
omap-for-v3.8/fixes-for-merge-window
  ARM: OMAP: Move plat/omap-serial.h to 
include/linux/platform_data/serial-omap.h
  Merge branch 'omap-for-v3.8/fixes-for-merge-window' into 
omap-for-v3.8/fixes-for-merge-window-v2
  MAINTAINERS: Add an entry for omap related .dts files
  ARM: OMAP: Split fb.c to remove last remaining cpu_is_omap usage
  ARM: OMAP2+: Drop plat/cpu.h for omap2plus
  ARM: OMAP: Fix drivers to depend on omap for internal devices

Vaibhav Hiremath (1):
  ARM: OMAP2+: Fix sparse warnings in timer.c

Wei Yongjun (1):
  ARM: OMAP4: remove duplicated include from omap_hwmod_44xx_data.c

YOSHIFUJI Hideaki (1):
  OMAP2: Fix a typo - replace regist with register.

 MAINTAINERS|  9 +++
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/omap2420-h4.dts  |  2 +-
 arch/arm/configs/omap2plus_defconfig   |  5 ++
 arch/arm/mach-omap1/Makefile   |  2 +-
 arch/arm/mach-omap1/fb.c   | 80 +++
 arch/arm/mach-omap2/Kconfig|  3 +-
 arch/arm/mach-omap2/Makefile   |  2 +-
 arch/arm/mach-omap2/board-3430sdp.c|  1 +
 arch/arm/mach-omap2/board-am3517evm.c  |  1 +
 arch/arm/mach-omap2/board-cm-t35.c |  1 +
 arch/arm/mach-omap2/board-devkit8000.c |  1 +
 arch/arm/mach-omap2/board-h4.c | 83 +--
 arch/arm/mach-omap2/board-omap3evm.c   |  1 +
 arch/arm/mach-omap2/board-omap3stalker.c   |  1 +
 arch/arm/mach-omap2/common.c   |  3 -
 arch/arm/mach-omap2/control.h  |  2 +-
 arch/arm/mach-omap2/dpll3xxx.c |  3 +-
 arch/arm/mach-omap2/drm.c  |  1 -
 arch/arm/mach-omap2/dss-common.c   |  3 +-
 arch/arm/{plat-omap = mach-omap2}/fb.c| 50 +---
 

Re: [GIT PULL] omap fixes and cleanups for v3.8 merge window

2012-12-17 Thread Felipe Balbi
Hi,

On Mon, Dec 17, 2012 at 10:02:01AM -0800, Tony Lindgren wrote:
  drivers/mfd/omap-usb-host.c|  3 +-
  drivers/tty/serial/omap-serial.c   |  3 +-
  drivers/usb/phy/Kconfig|  1 +

I did mention I was against adding OMAP dependencies do drivers.
Interesting to see to commit going upstream without a reply to my
comment :-s

http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=3e194c88f8b71700822828749187e65853ed8166

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH 1/2] ARM: OMAP3: PRCM: Fix incorrect read of reset sources

2012-12-17 Thread Paul Walmsley
Hi

On Mon, 17 Dec 2012, Ivan Khoronzhuk wrote:

 The flag mask are incorrect, so fix it.
 
 Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com

arch/arm/mach-omap2/prcm.c no longer exists in current mainline; please 
rebase this against Linus' current tree.


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


Re: [PATCH 2/2] ARM: OMAP4: PRCM: Fix incorrect read of reset sources

2012-12-17 Thread Paul Walmsley
Hi

On Mon, 17 Dec 2012, Ivan Khoronzhuk wrote:

 The address of PRM_RSTST register and flag mask are incorrect,
 so fix it.
 
 Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com

arch/arm/mach-omap2/prcm.c no longer exists in current mainline; please
rebase this against Linus' current tree.


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


Re: [GIT PULL] fbdev changes for 3.8

2012-12-17 Thread Tony Lindgren
* Dmitry Torokhov dmitry.torok...@gmail.com [121216 22:03]:
 On Sun, Dec 16, 2012 at 12:35:37PM -0800, Tony Lindgren wrote:
  * Tony Lindgren t...@atomide.com [121216 09:49]:
   * Dave Jones da...@redhat.com [121215 14:27]:
On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote:
  On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen 
tomi.valkei...@ti.com wrote:
   Hi Linus,
  
   Florian, the fbdev maintainer, has been very busy lately, so I 
offered to send
   the pull request for fbdev for this merge window.
  
  Pulled. However, with this I get the Kconfig question
  
 OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW)
  
  which doesn't make a whole lot of sense on x86-64, unless there's
  something about OMAP2 that I don't know.
  
  So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at
  least ARM. Because showing it to anybody else seems insane.
  
  Same goes for FB_OMAP2 for that matter. I realize that it's likely
  nice to get compile testing for this on x86-64 too, but if that's the
  intent, we need to think about it some more. I don't think it's good
  to ask actual normal users questions like this just for compile
  coverage.

This OMAP stuff has been creeping into x86 builds for a while.
Grep from my current build config ..

# CONFIG_OMAP_OCP2SCP is not set
# CONFIG_KEYBOARD_OMAP4 is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_OMAP_USB2 is not set

There was some other arm-ism that does the same that I' currently 
forgetting,
or maybe that got fixed..
   
   Those are all omap internal devices and should be all marked with
   depends on ARCH_OMAP2PLUS.
   
   It's a different story for external devices that may be used on other
   architectures.
   
   I only came up with one reason to compile internal devices for other
   architectures: In some cases the driver subsystem maintainer may want to
   be able to compile test subsystem wide changes without having to compile
   for each target separately. But for those cases it's trivial to carry a
   compile test patch that just drops the depends Kconfig entries.
  
  And here's a patch to limit the omap drivers above to omap only.
 
 Do you think we could add a new symbol to debug options, something like
 COMPILE_COVERAGE, and have drivers that can be compiled on platforms
 other than ones having the hardware to do
 
   depend on ARCH_XXX || COMPILE_CONVERAGE
 
 This way people who want to do compile coverage do not have to carry
 patches and allyesconfig will pick this right up.

I like that idea. Looks like Linus already applied the earlier
patch, I'll do a patch for COMPILE_COVERAGE separately.

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: [GIT PULL] omap fixes and cleanups for v3.8 merge window

2012-12-17 Thread Tony Lindgren
* Felipe Balbi ba...@ti.com [121217 10:18]:
 Hi,
 
 On Mon, Dec 17, 2012 at 10:02:01AM -0800, Tony Lindgren wrote:
   drivers/mfd/omap-usb-host.c|  3 +-
   drivers/tty/serial/omap-serial.c   |  3 +-
   drivers/usb/phy/Kconfig|  1 +
 
 I did mention I was against adding OMAP dependencies do drivers.
 Interesting to see to commit going upstream without a reply to my
 comment :-s
 
 http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=3e194c88f8b71700822828749187e65853ed8166

Looks like Linus already applied it. Anyways, I like Dmitry's idea
of adding an extra COMPILE_COVERAGE flag to enable the build of
arch specific drivers for driver subsystem maintainers, I'll
do a patch for that so you can test build all the arch specific
USB drivers on x86 also.

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: [GIT PULL] omap fixes and cleanups for v3.8 merge window

2012-12-17 Thread Tony Lindgren
* Tony Lindgren t...@atomide.com [121217 10:33]:
 * Felipe Balbi ba...@ti.com [121217 10:18]:
  Hi,
  
  On Mon, Dec 17, 2012 at 10:02:01AM -0800, Tony Lindgren wrote:
drivers/mfd/omap-usb-host.c|  3 +-
drivers/tty/serial/omap-serial.c   |  3 +-
drivers/usb/phy/Kconfig|  1 +
  
  I did mention I was against adding OMAP dependencies do drivers.
  Interesting to see to commit going upstream without a reply to my
  comment :-s
  
  http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=3e194c88f8b71700822828749187e65853ed8166
 
 Looks like Linus already applied it. Anyways, I like Dmitry's idea
 of adding an extra COMPILE_COVERAGE flag to enable the build of
 arch specific drivers for driver subsystem maintainers, I'll
 do a patch for that so you can test build all the arch specific
 USB drivers on x86 also.

Oh I see I have it also in my fixes, that should not be there.

I'll fix that and do another pull request. The commit Linus
applied is 770b6cb4.

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


[GIT PULL] ARM: OMAP: clock/cpuidle: fixes for the v3.8 merge window

2012-12-17 Thread Paul Walmsley
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tony

The following changes since commit 7a280cf512053137a37da2801eac73a8842fa50d:

  Merge tag 'disintegrate-x86-20121214' of 
git://git.infradead.org/users/dhowells/linux-headers (2012-12-14 15:48:52 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
tags/omap-fixes-a-for-v3.8-window

for you to fetch changes up to 9db316b6bf0234d9391f87dd0d28b23f5a44facb:

  ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings (2012-12-15 
01:41:24 -0700)

- 
Fix some OMAP4 clock problems, and deal with some sparse warnings from
the OMAP CPUIdle code.

- 
Jon Hunter (5):
  ARM: OMAP4: Update timer clock aliases
  ARM: OMAP4: Add function table for non-M4X dplls
  ARM: OMAP4: Enhance support for DPLLs with 4X multiplier
  ARM: OMAP4460: Workaround ABE DPLL failing to turn-on
  ARM: OMAP4: Fix EMU clock domain always on

Paul Walmsley (3):
  ARM: OMAP4: clock data: div_iva_hs_clk is a power-of-two divider
  ARM: OMAP4: clock data: DPLLs are missing bypass clocks in their parent 
lists
  ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings

 arch/arm/mach-omap2/cclock44xx_data.c |   78 +++--
 arch/arm/mach-omap2/clock.h   |   10 +
 arch/arm/mach-omap2/clockdomain.c |3 +-
 arch/arm/mach-omap2/cpuidle34xx.c |   14 +++---
 arch/arm/mach-omap2/cpuidle44xx.c |   28 +++-
 arch/arm/mach-omap2/dpll3xxx.c|   46 +--
 arch/arm/mach-omap2/dpll44xx.c|   64 +++
 7 files changed, 189 insertions(+), 54 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQz22wAAoJEMePsQ0LvSpLRt4QALJ8InjX2uveeN5GaCVRRJiN
RIcibgvGsgGCi2wfKxeOicb0hoTd/JZzaRzUAIS0mfTIFBIbmq0UGMZRhzlqS+eH
IRx+ACcA/d23UqEOtYcvGrZsMvGQTqBCtifcAHTQ+kXPQWDskBTLUFDR5Nd3UIQO
6oQtr9xXgGowGEQbldfTP0H1su+wpU0VcbtrptUJtKR+eBYMuhgvV1o9MCRR9cmd
hfIfgmNT2xeJJ3MGjsy1tBpY5EYHtPztTxv1RFjpyO6tZeHUMrNLAJwVV3kxNn4k
SCyikMNvnFFiVI6XTdmG75lTf+8zYksP64FJG7PSwPh3saqdGiLDtGd1ZYSq9uuI
1rbmOVQzvg85wRbNphXbxRW+F3CHzdBN1E6OfBVeRJia37mqPx1fEBBwsxar7yho
B5WcoseszWIhGow/xYYfXL2eU0PI6gwFy1JOctfzSYccfjwXH8HFODMxyxOigyD1
JMRIyPw6GnuTkIFP89UTCcdjGvwcajeP9cxTp/Dr8WQERWSQEWDPdHqxwofc6mos
hzKhsanN8c6JiYq5meg+8fS8+WLG379FhMvh9+GWMpIT4ZhBavGRPjspbFG6RZ5K
azI/Flolh4jJ2+7qbM0Tv18bR7xbAbTTdvsR8ore+OhL6ulzgh2sqEGsGoTHJzzH
VheVL42zAnsPU03I52o8
=gGVB
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PULL 1/2] omap fixes for v3.8 merge window

2012-12-17 Thread Tony Lindgren
The following changes since commit 2b8318881ddbcb67c5e8d2178b4228474944:

  Merge tag 'fbdev-for-3.8' of git://gitorious.org/linux-omap-dss2/linux 
(2012-12-15 13:03:48 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v3.8/fixes-for-merge-window-v4-signed

for you to fetch changes up to 2cb85a7bd2ca6db3ab3d632d0a1b6ca3770ddcf4:

  Merge branch 'omap-for-v3.8/fixes-for-merge-window' into 
omap-for-v3.8/fixes-for-merge-window-v2 (2012-12-16 11:28:10 -0800)



These patches fixes a build error caused by a merge
conflict with the fb code, few timer warnings, and longer
term regressions for tfp410 and omap h4 ethernet. Also
included is a GPIO mode fix for the legacy mux code.


Javier Martinez Canillas (1):
  ARM: OMAP2+: common: remove use of vram

Jon Hunter (6):
  ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
  ARM: AM335x: Fix warning in timer.c
  ARM: OMAP2420: Fix ethernet support for OMAP2420 H4
  ARM: OMAP: Remove debug-devices.c
  ARM: dts: OMAP2420: Correct H4 board memory size
  ARM: dts: Add build target for omap4-panda-a4

Oleg Matcovschi (1):
  OMAP2+: mux: Fixed gpio mux mode analysis

Roger Quadros (1):
  mfd: omap-usb-host: get rid of cpu_is_omap..() macros

Tomi Valkeinen (1):
  OMAP: board-files: fix i2c_bus for tfp410

Tony Lindgren (3):
  Merge branch 'fixes-timer-build' of git://github.com/jonhunter/linux into 
omap-for-v3.8/fixes-for-merge-window
  ARM: OMAP: Move plat/omap-serial.h to 
include/linux/platform_data/serial-omap.h
  Merge branch 'omap-for-v3.8/fixes-for-merge-window' into 
omap-for-v3.8/fixes-for-merge-window-v2

Vaibhav Hiremath (1):
  ARM: OMAP2+: Fix sparse warnings in timer.c

 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/omap2420-h4.dts  |  2 +-
 arch/arm/mach-omap2/Kconfig|  3 +-
 arch/arm/mach-omap2/board-3430sdp.c|  1 +
 arch/arm/mach-omap2/board-am3517evm.c  |  1 +
 arch/arm/mach-omap2/board-cm-t35.c |  1 +
 arch/arm/mach-omap2/board-devkit8000.c |  1 +
 arch/arm/mach-omap2/board-h4.c | 83 +--
 arch/arm/mach-omap2/board-omap3evm.c   |  1 +
 arch/arm/mach-omap2/board-omap3stalker.c   |  1 +
 arch/arm/mach-omap2/common.c   |  3 -
 arch/arm/mach-omap2/mux.c  | 10 +--
 arch/arm/mach-omap2/mux.h  | 20 +++--
 arch/arm/mach-omap2/mux34xx.c  |  2 +-
 arch/arm/mach-omap2/serial.c   |  3 +-
 arch/arm/mach-omap2/timer.c|  6 +-
 arch/arm/mach-omap2/usb-host.c |  4 +
 arch/arm/plat-omap/Makefile|  1 -
 arch/arm/plat-omap/debug-devices.c | 92 --
 arch/arm/plat-omap/include/plat/debug-devices.h|  2 -
 drivers/mfd/omap-usb-host.c|  3 +-
 drivers/tty/serial/omap-serial.c   |  3 +-
 .../linux/platform_data/serial-omap.h  |  0
 include/linux/platform_data/usb-omap.h |  3 +
 include/video/omap-panel-tfp410.h  |  2 +-
 25 files changed, 64 insertions(+), 185 deletions(-)
 delete mode 100644 arch/arm/plat-omap/debug-devices.c
 delete mode 100644 arch/arm/plat-omap/include/plat/debug-devices.h
 rename arch/arm/plat-omap/include/plat/omap-serial.h = 
include/linux/platform_data/serial-omap.h (100%)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


AM33xx not booting here after d01e4afd

2012-12-17 Thread Paul Walmsley

Hi

just a brief note that AM33xx has stopped booting in the testbed here with 
a concatenated kernel+DTB after the following mainline commit:

commit d01e4afdbb65e030fd6f1f96c30a558e2eb0f279
Merge: 8287361 794b175
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Wed Dec 12 11:51:39 2012 -0800

Merge tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm


Here's a boot log (after some other changes, but same behavior):

http://www.pwsan.com/omap/testlogs/prcm_fixes_a_3.8-rc/20121217103645/boot/am335xbone/am335xbone_log.txt


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


[PATCH] ARM: OMAP4: PRM: Correct PRM_RSTST and PRM_RSTTIME registers shifts

2012-12-17 Thread Ivan Khoronzhuk
According to TRMs the assigned shifts are wrong, so correct them.
---
 arch/arm/mach-omap2/prm44xx.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 22b0979..8ee1fbd 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -62,8 +62,8 @@
 
 /* OMAP4 specific register offsets */
 #define OMAP4_RM_RSTCTRL   0x
-#define OMAP4_RM_RSTTIME   0x0004
-#define OMAP4_RM_RSTST 0x0008
+#define OMAP4_RM_RSTST 0x0004
+#define OMAP4_RM_RSTTIME   0x0008
 #define OMAP4_PM_PWSTCTRL  0x
 #define OMAP4_PM_PWSTST0x0004
 
-- 
1.7.9.5

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


[PATCH] ARM: OMAP4: PRM: Correct PRM_RSTST and PRM_RSTTIME registers shifts

2012-12-17 Thread Ivan Khoronzhuk
According to TRMs the assigned shifts are wrong, so correct them.
---
 arch/arm/mach-omap2/prm44xx.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 22b0979..8ee1fbd 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -62,8 +62,8 @@
 
 /* OMAP4 specific register offsets */
 #define OMAP4_RM_RSTCTRL   0x
-#define OMAP4_RM_RSTTIME   0x0004
-#define OMAP4_RM_RSTST 0x0008
+#define OMAP4_RM_RSTST 0x0004
+#define OMAP4_RM_RSTTIME   0x0008
 #define OMAP4_PM_PWSTCTRL  0x
 #define OMAP4_PM_PWSTST0x0004
 
-- 
1.7.9.5

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


[PATCH] ARM: OMAP4: PRM: Correct wrong instance usage for reading reset sources

2012-12-17 Thread Ivan Khoronzhuk
To read reset sources registers we have to use PRM_DEVICE_INST
---
 arch/arm/mach-omap2/prm44xx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 7498bc7..0b61b8d 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -333,7 +333,7 @@ static u32 omap44xx_prm_read_reset_sources(void)
u32 r = 0;
u32 v;
 
-   v = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
+   v = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
OMAP4_RM_RSTST);
 
p = omap44xx_prm_reset_src_map;
-- 
1.7.9.5

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


[PATCH] ARM: OMAP4: PRM: Correct reset source map

2012-12-17 Thread Ivan Khoronzhuk
In the map for reset sources register we use defines intended for
using with PRM_RSTCTRL register. So fix it.
---
 arch/arm/mach-omap2/prm44xx.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 7498bc7..e335216 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -56,9 +56,9 @@ static struct omap_prcm_irq_setup omap4_prcm_irq_setup = {
  *   enumeration)
  */
 static struct prm_reset_src_map omap44xx_prm_reset_src_map[] = {
-   { OMAP4430_RST_GLOBAL_WARM_SW_SHIFT,
+   { OMAP4430_GLOBAL_WARM_SW_RST_SHIFT,
  OMAP_GLOBAL_WARM_RST_SRC_ID_SHIFT },
-   { OMAP4430_RST_GLOBAL_COLD_SW_SHIFT,
+   { OMAP4430_GLOBAL_COLD_RST_SHIFT,
  OMAP_GLOBAL_COLD_RST_SRC_ID_SHIFT },
{ OMAP4430_MPU_SECURITY_VIOL_RST_SHIFT,
  OMAP_SECU_VIOL_RST_SRC_ID_SHIFT },
-- 
1.7.9.5

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


[PATCH] ARM: OMAP4: clock/hwmod data: start to remove some IP block control clocks

2012-12-17 Thread Paul Walmsley

Remove some leaf clocks that are actually IP block idle control
points, since these should now be handled by the hwmod code.

There are still a few types of MODULEMODE clocks that need to be
cleaned up:

- those still in use by driver or integration code

- those in DEFINE_CLK_OMAP_MUX_GATE() blocks; the gate portion of
  these should be removed

A similar process may also be possible on OMAP2/3.

Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---

It boots with omap2plus_defconfig, at least.

 arch/arm/mach-omap2/cclock44xx_data.c  |  291 +---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   62 +++---
 2 files changed, 36 insertions(+), 317 deletions(-)

diff --git a/arch/arm/mach-omap2/cclock44xx_data.c 
b/arch/arm/mach-omap2/cclock44xx_data.c
index 5789a5e..c772ea5 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -16,6 +16,11 @@
  * XXX Some of the ES1 clocks have been removed/changed; once support
  * is added for discriminating clocks by ES level, these should be added back
  * in.
+ *
+ * XXX All of the CLK_OMAP_MUX_GATE entries with MODULEMODE registers should
+ * be split into separate mux and gate nodes, then the gates should be removed
+ * (handled by hwmod).  Also all of the other remaining MODULEMODE entries
+ * should be removed once the drivers are updated to use pm_runtime.
  */
 
 #include linux/kernel.h
@@ -749,10 +754,6 @@ DEFINE_CLK_GATE(aes2_fck, l3_div_ck, l3_div_ck, 0x0,
OMAP4430_CM_L4SEC_AES2_CLKCTRL,
OMAP4430_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
 
-DEFINE_CLK_GATE(aess_fck, aess_fclk, aess_fclk, 0x0,
-   OMAP4430_CM1_ABE_AESS_CLKCTRL, OMAP4430_MODULEMODE_SWCTRL_SHIFT,
-   0x0, NULL);
-
 DEFINE_CLK_GATE(bandgap_fclk, sys_32k_ck, sys_32k_ck, 0x0,
OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
OMAP4430_OPTFCLKEN_BGAP_32K_SHIFT, 0x0, NULL);
@@ -774,11 +775,6 @@ DEFINE_CLK_GATE(bandgap_ts_fclk, div_ts_ck, div_ts_ck, 
0x0,
OMAP4460_OPTFCLKEN_TS_FCLK_SHIFT,
0x0, NULL);
 
-DEFINE_CLK_GATE(des3des_fck, l4_div_ck, l4_div_ck, 0x0,
-   OMAP4430_CM_L4SEC_DES3DES_CLKCTRL,
-   OMAP4430_MODULEMODE_SWCTRL_SHIFT,
-   0x0, NULL);
-
 static const char *dmic_sync_mux_ck_parents[] = {
abe_24m_fclk, syc_clk_div_ck, func_24m_clk,
 };
@@ -809,10 +805,6 @@ DEFINE_CLK_OMAP_MUX_GATE(dmic_fck, abe_clkdm, 
func_dmic_abe_gfclk_sel,
 OMAP4430_MODULEMODE_SWCTRL_SHIFT, NULL,
 dmic_fck_parents, dmic_fck_ops);
 
-DEFINE_CLK_GATE(dsp_fck, dpll_iva_m4x2_ck, dpll_iva_m4x2_ck, 0x0,
-   OMAP4430_CM_TESLA_TESLA_CLKCTRL,
-   OMAP4430_MODULEMODE_HWCTRL_SHIFT, 0x0, NULL);
-
 DEFINE_CLK_GATE(dss_sys_clk, syc_clk_div_ck, syc_clk_div_ck, 0x0,
OMAP4430_CM_DSS_DSS_CLKCTRL,
OMAP4430_OPTFCLKEN_SYS_CLK_SHIFT, 0x0, NULL);
@@ -833,78 +825,34 @@ DEFINE_CLK_GATE(dss_fck, l3_div_ck, l3_div_ck, 0x0,
OMAP4430_CM_DSS_DSS_CLKCTRL, OMAP4430_MODULEMODE_SWCTRL_SHIFT,
0x0, NULL);
 
-DEFINE_CLK_GATE(efuse_ctrl_cust_fck, sys_clkin_ck, sys_clkin_ck, 0x0,
-   OMAP4430_CM_CEFUSE_CEFUSE_CLKCTRL,
-   OMAP4430_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(emif1_fck, ddrphy_ck, ddrphy_ck, 0x0,
-   OMAP4430_CM_MEMIF_EMIF_1_CLKCTRL,
-   OMAP4430_MODULEMODE_HWCTRL_SHIFT, 0x0, NULL);
-
-DEFINE_CLK_GATE(emif2_fck, ddrphy_ck, ddrphy_ck, 0x0,
-   OMAP4430_CM_MEMIF_EMIF_2_CLKCTRL,
-   OMAP4430_MODULEMODE_HWCTRL_SHIFT, 0x0, NULL);
-
 DEFINE_CLK_DIVIDER(fdif_fck, dpll_per_m4x2_ck, dpll_per_m4x2_ck, 0x0,
   OMAP4430_CM_CAM_FDIF_CLKCTRL, OMAP4430_CLKSEL_FCLK_SHIFT,
   OMAP4430_CLKSEL_FCLK_WIDTH, CLK_DIVIDER_POWER_OF_TWO, NULL);
 
-DEFINE_CLK_GATE(fpka_fck, l4_div_ck, l4_div_ck, 0x0,
-   OMAP4430_CM_L4SEC_PKAEIP29_CLKCTRL,
-   OMAP4430_MODULEMODE_SWCTRL_SHIFT, 0x0, NULL);
-
 DEFINE_CLK_GATE(gpio1_dbclk, sys_32k_ck, sys_32k_ck, 0x0,
OMAP4430_CM_WKUP_GPIO1_CLKCTRL,
OMAP4430_OPTFCLKEN_DBCLK_SHIFT, 0x0, NULL);
 
-DEFINE_CLK_GATE(gpio1_ick, l4_wkup_clk_mux_ck, l4_wkup_clk_mux_ck, 0x0,
-   OMAP4430_CM_WKUP_GPIO1_CLKCTRL,
-   OMAP4430_MODULEMODE_HWCTRL_SHIFT, 0x0, NULL);
-
 DEFINE_CLK_GATE(gpio2_dbclk, sys_32k_ck, sys_32k_ck, 0x0,
OMAP4430_CM_L4PER_GPIO2_CLKCTRL, OMAP4430_OPTFCLKEN_DBCLK_SHIFT,
0x0, NULL);
 
-DEFINE_CLK_GATE(gpio2_ick, l4_div_ck, l4_div_ck, 0x0,
-   OMAP4430_CM_L4PER_GPIO2_CLKCTRL,
-   OMAP4430_MODULEMODE_HWCTRL_SHIFT, 0x0, NULL);
-
 DEFINE_CLK_GATE(gpio3_dbclk, sys_32k_ck, sys_32k_ck, 0x0,
OMAP4430_CM_L4PER_GPIO3_CLKCTRL,

Re: [PATCH] OMAP: DSS: add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list

2012-12-17 Thread NeilBrown
On Mon, 17 Dec 2012 13:58:59 +0200 Tomi Valkeinen tomi.valkei...@ti.com
wrote:

 On 2012-12-15 23:08, NeilBrown wrote:
  
  commit 195e672a76056478cc79f5c48343164c9237852e
 OMAPDSS: DPI: Remove cpu_is_ checks
  
  made the mistake of assuming that cpu_is_omap34xx() is exclusive of
  other cpu_is_* predicates whereas it includes cpu_is_omap3630().
  
  So on an omap3630, code that was previously enabled by
if (cpu_is_omap34xx())
  is now disabled as
dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
  fails.
  
  So add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list.
  
  Cc: Chandrabhanu Mahapatra cmahapa...@ti.com
  Cc: Tomi Valkeinen tomi.valkei...@ti.com
  Signed-off-by: NeilBrown ne...@suse.de
  
  diff --git a/drivers/video/omap2/dss/dss_features.c 
  b/drivers/video/omap2/dss/dss_features.c
  index acbc1e1..aaf3c3f 100644
  --- a/drivers/video/omap2/dss/dss_features.c
  +++ b/drivers/video/omap2/dss/dss_features.c
  @@ -546,6 +546,7 @@ static const enum dss_feat_id omap3630_dss_feat_list[] 
  = {
  FEAT_ALPHA_FIXED_ZORDER,
  FEAT_FIFO_MERGE,
  FEAT_OMAP3_DSI_FIFO_BUG,
  +   FEAT_DPI_USES_VDDS_DSI,
   };
   
   static const enum dss_feat_id omap4430_es1_0_dss_feat_list[] = {
  
 
 Thanks, looks correct. Did you encounter a bug related to this, or just
 happened to notice?
 

When I tried 3.7 on my gta04 phone the display had a slightly greenish (or
maybe yellowish) tinge, particularly when viewed at an angle.
I at first thought it might be related to the changes in the panel
configuration (I have an out-of-tree panel driver) but making changes there
had no effect.
So I bit the bullet and did a git-bisect, and that is how I found that
problem.

NeilBrown


signature.asc
Description: PGP signature


Re: [PATCH] ARM: OMAP4: PRM: Correct reset source map

2012-12-17 Thread Paul Walmsley
Hi

On Mon, 17 Dec 2012, Ivan Khoronzhuk wrote:

 In the map for reset sources register we use defines intended for
 using with PRM_RSTCTRL register. So fix it.

your changes look good, but they are missing Signed-off-by: lines.  Could 
you please either resend with those, or confirm that you intended to add 
them?  You may wish to read Documentation/SubmittingPatches, particularly 
item 12.


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


Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk

2012-12-17 Thread Paul Walmsley
On Mon, 17 Dec 2012, Benoit Cousson wrote:

 It was done for legacy reason but should disappear once the modulemode
 will be be removed from the clock nodes.

Here's a start at taking care of the low-hanging fruit:

http://marc.info/?l=linux-omapm=135577685007813w=2

Only lightly tested, so tests with Kconfigs with lots of OMAP drivers 
enabled would be appreciated.


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


invalid references to vram.h

2012-12-17 Thread Carlos Hernandez
Just an fyi... am335x mainline compilation is broken due to invalid
references to vram.h

|   CC  arch/arm/mach-omap2/common.o
| arch/arm/mach-omap2/common.c:19:23: fatal error: plat/vram.h: No such
file or directory

Test run against commit fa4c95bfdb85d568ae327d57aa33a4f55bab79c4

Regards,
Carlos




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


[PATCH] ARM: OMAP4: clock/hwmod data: remove MODULEMODE entries in mux + gate combos

2012-12-17 Thread Paul Walmsley

Convert all DEFINE_OMAP_MUX_GATE() combinations that list MODULEMODE
registers in their gate arguments to DEFINE_OMAP_MUX(), dropping the
MODULEMODE data.  This is possible because the MODULEMODE bits control
IP blocks, not clocks; and the hwmod code takes care of IP block
control.  Rename these clocks to reflect the original multiplexer name
as specified in the comments.  And convert the hwmod data to use the
multiplexer clock name.

Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---

Seems to boot with omap2plus_defconfig, anyway.

 arch/arm/mach-omap2/cclock44xx_data.c  |  301 +++-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   41 ++--
 2 files changed, 141 insertions(+), 201 deletions(-)

diff --git a/arch/arm/mach-omap2/cclock44xx_data.c 
b/arch/arm/mach-omap2/cclock44xx_data.c
index c772ea5..f673138 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -17,10 +17,9 @@
  * is added for discriminating clocks by ES level, these should be added back
  * in.
  *
- * XXX All of the CLK_OMAP_MUX_GATE entries with MODULEMODE registers should
- * be split into separate mux and gate nodes, then the gates should be removed
- * (handled by hwmod).  Also all of the other remaining MODULEMODE entries
- * should be removed once the drivers are updated to use pm_runtime.
+ * XXX All of the remaining MODULEMODE clock nodes should be removed
+ * once the drivers are updated to use pm_runtime or to use the appropriate
+ * upstream clock node for rate/parent selection.
  */
 
 #include linux/kernel.h
@@ -320,7 +319,7 @@ DEFINE_CLK_DIVIDER(dpll_abe_m2_ck, dpll_abe_ck, 
dpll_abe_ck, 0x0,
   OMAP4430_CM_DIV_M2_DPLL_ABE, OMAP4430_DPLL_CLKOUT_DIV_SHIFT,
   OMAP4430_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
 
-static const struct clk_ops dmic_fck_ops = {
+static const struct clk_ops dpll_hsd_ops = {
.enable = omap2_dflt_clk_enable,
.disable= omap2_dflt_clk_disable,
.is_enabled = omap2_dflt_clk_is_enabled,
@@ -330,6 +329,12 @@ static const struct clk_ops dmic_fck_ops = {
.init   = omap2_init_clk_clkdm,
 };
 
+static const struct clk_ops func_dmic_abe_gfclk_ops = {
+   .recalc_rate= omap2_clksel_recalc,
+   .get_parent = omap2_clksel_find_parent_index,
+   .set_parent = omap2_clksel_set_parent,
+};
+
 static const char *dpll_core_m3x2_ck_parents[] = {
dpll_core_x2_ck,
 };
@@ -345,7 +350,7 @@ DEFINE_CLK_OMAP_MUX_GATE(dpll_core_m3x2_ck, NULL, 
dpll_core_m3x2_div,
 OMAP4430_DPLL_CLKOUTHIF_DIV_MASK,
 OMAP4430_CM_DIV_M3_DPLL_CORE,
 OMAP4430_DPLL_CLKOUTHIF_GATE_CTRL_SHIFT, NULL,
-dpll_core_m3x2_ck_parents, dmic_fck_ops);
+dpll_core_m3x2_ck_parents, dpll_hsd_ops);
 
 DEFINE_CLK_OMAP_HSDIVIDER(dpll_core_m7x2_ck, dpll_core_x2_ck,
  dpll_core_x2_ck, 0x0, OMAP4430_CM_DIV_M7_DPLL_CORE,
@@ -552,7 +557,7 @@ DEFINE_CLK_OMAP_MUX_GATE(dpll_per_m3x2_ck, NULL, 
dpll_per_m3x2_div,
 OMAP4430_DPLL_CLKOUTHIF_DIV_MASK,
 OMAP4430_CM_DIV_M3_DPLL_PER,
 OMAP4430_DPLL_CLKOUTHIF_GATE_CTRL_SHIFT, NULL,
-dpll_per_m3x2_ck_parents, dmic_fck_ops);
+dpll_per_m3x2_ck_parents, dpll_hsd_ops);
 
 DEFINE_CLK_OMAP_HSDIVIDER(dpll_per_m4x2_ck, dpll_per_x2_ck, dpll_per_x2_ck,
  0x0, OMAP4430_CM_DIV_M4_DPLL_PER,
@@ -791,19 +796,13 @@ static const struct clksel func_dmic_abe_gfclk_sel[] = {
{ .parent = NULL },
 };
 
-static const char *dmic_fck_parents[] = {
+static const char *func_dmic_abe_gfclk_parents[] = {
dmic_sync_mux_ck, pad_clks_ck, slimbus_clk,
 };
 
-/* Merged func_dmic_abe_gfclk into dmic */
-static struct clk dmic_fck;
-
-DEFINE_CLK_OMAP_MUX_GATE(dmic_fck, abe_clkdm, func_dmic_abe_gfclk_sel,
-OMAP4430_CM1_ABE_DMIC_CLKCTRL,
-OMAP4430_CLKSEL_SOURCE_MASK,
-OMAP4430_CM1_ABE_DMIC_CLKCTRL,
-OMAP4430_MODULEMODE_SWCTRL_SHIFT, NULL,
-dmic_fck_parents, dmic_fck_ops);
+DEFINE_CLK_OMAP_MUX(func_dmic_abe_gfclk, abe_clkdm, func_dmic_abe_gfclk_sel,
+   OMAP4430_CM1_ABE_DMIC_CLKCTRL, OMAP4430_CLKSEL_SOURCE_MASK,
+   func_dmic_abe_gfclk_parents, func_dmic_abe_gfclk_ops);
 
 DEFINE_CLK_GATE(dss_sys_clk, syc_clk_div_ck, syc_clk_div_ck, 0x0,
OMAP4430_CM_DSS_DSS_CLKCTRL,
@@ -859,17 +858,13 @@ static const struct clksel sgx_clk_mux_sel[] = {
{ .parent = NULL },
 };
 
-static const char *gpu_fck_parents[] = {
+static const char *sgx_clk_mux_parents[] = {
dpll_core_m7x2_ck, dpll_per_m7x2_ck,
 };
 
-/* Merged sgx_clk_mux into 

Re: invalid references to vram.h

2012-12-17 Thread Jon Hunter

On 12/17/2012 04:14 PM, Carlos Hernandez wrote:
 Just an fyi... am335x mainline compilation is broken due to invalid
 references to vram.h
 
 |   CC  arch/arm/mach-omap2/common.o
 | arch/arm/mach-omap2/common.c:19:23: fatal error: plat/vram.h: No such
 file or directory
 
 Test run against commit fa4c95bfdb85d568ae327d57aa33a4f55bab79c4

I believe a fix is already queued [1].

Jon

[1] http://marc.info/?l=linux-omapm=135577145305783w=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: About 1-Wire driver of OMAP4

2012-12-17 Thread Paul Walmsley
Hi

On Mon, 10 Dec 2012, herman...@totalbb.net.tw wrote:

 I implemented gas gauge driver by 1-Wire interface in OMAP4 CPU, the
 driver we used is a GPIO pin to simulate 1-Wire bus but it sometimes can't
 work well of timing issue. So we want to use HDQ/1Wire controller in OMAP4,
 does anyone have experience of OMAP4 1-Wire driver of using its controller?
 Our gas gauge is DS2780 and we use android-omap-3.0 kernel branch. I
 tried to do below steps but it still can't work. Or do you have any
 suggestion? Thanks.
 
 1. Add hwmod of hdq1w in omap_hwmod_44xx_data.c file
 2. Use omap_hdq.c file
 3. Select CONFIG_HDQ_MASTER_OMAP, CONFIG_W1, CONFIG_HDQ_MASTER_OMAP
 and CONFIG_BATTERY_DS2780 in menuconfig.

HDQ1W should work on OMAP3 in mainline if the 

hdq_experimental_idle_fix_3.5

branch of

git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-devel.git

is added in.  (Of course, it will have to be forward-ported to take 
account of the recent common clock framework changes.)

But that branch won't help the OMAP4 situation, since it doesn't have 
explicit interface clock autoidle control.  The question here is whether 
the OMAP4 has the same hardware idle handling bug that the OMAP3 did.  If 
so, you might have to enable another IP block in the L4_PER clockdomain 
while the HDQ is active :-( It might also be possible to keep the L4_PER 
clockdomain in software-supervised mode; not sure.

So.  You might want to try backporting the HDQ driver in current mainline, 
along with the relevant hwmod integration data and any associated hwmod 
code, to the 3.0 Android kernel you're using.  Then if that doesn't help, 
maybe try the l4_per hacks mentioned above.

With regards to OMAP3, we still need to plug in a more permanent fix for 
mainline.  Unfortunately it's fallen down the priority ladder :-(


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


Re: [GIT PULL] ARM: OMAP: clock/cpuidle: fixes for the v3.8 merge window

2012-12-17 Thread Tony Lindgren
Olof,

* Paul Walmsley p...@pwsan.com [121217 11:12]:
 Hi Tony
 
 The following changes since commit 7a280cf512053137a37da2801eac73a8842fa50d:
 
   Merge tag 'disintegrate-x86-20121214' of 
 git://git.infradead.org/users/dhowells/linux-headers (2012-12-14 15:48:52 
 -0800)
 
 are available in the git repository at:
 
 
   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
 tags/omap-fixes-a-for-v3.8-window
 
 for you to fetch changes up to 9db316b6bf0234d9391f87dd0d28b23f5a44facb:
 
   ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings (2012-12-15 
 01:41:24 -0700)
 
 
 Fix some OMAP4 clock problems, and deal with some sparse warnings from
 the OMAP CPUIdle code.

Can you please pick up this one too?

Thanks,

Tony
 
 
 Jon Hunter (5):
   ARM: OMAP4: Update timer clock aliases
   ARM: OMAP4: Add function table for non-M4X dplls
   ARM: OMAP4: Enhance support for DPLLs with 4X multiplier
   ARM: OMAP4460: Workaround ABE DPLL failing to turn-on
   ARM: OMAP4: Fix EMU clock domain always on
 
 Paul Walmsley (3):
   ARM: OMAP4: clock data: div_iva_hs_clk is a power-of-two divider
   ARM: OMAP4: clock data: DPLLs are missing bypass clocks in their parent 
 lists
   ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings
 
  arch/arm/mach-omap2/cclock44xx_data.c |   78 
 +++--
  arch/arm/mach-omap2/clock.h   |   10 +
  arch/arm/mach-omap2/clockdomain.c |3 +-
  arch/arm/mach-omap2/cpuidle34xx.c |   14 +++---
  arch/arm/mach-omap2/cpuidle44xx.c |   28 +++-
  arch/arm/mach-omap2/dpll3xxx.c|   46 +--
  arch/arm/mach-omap2/dpll44xx.c|   64 +++
  7 files changed, 189 insertions(+), 54 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


Re: [GIT PULL 1/2] omap fixes for v3.8 merge window

2012-12-17 Thread Tony Lindgren
* Tony Lindgren t...@atomide.com [121217 11:13]:
 The following changes since commit 2b8318881ddbcb67c5e8d2178b4228474944:
 
   Merge tag 'fbdev-for-3.8' of git://gitorious.org/linux-omap-dss2/linux 
 (2012-12-15 13:03:48 -0800)
 
 are available in the git repository at:
 
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.8/fixes-for-merge-window-v4-signed
 
 for you to fetch changes up to 2cb85a7bd2ca6db3ab3d632d0a1b6ca3770ddcf4:
 
   Merge branch 'omap-for-v3.8/fixes-for-merge-window' into 
 omap-for-v3.8/fixes-for-merge-window-v2 (2012-12-16 11:28:10 -0800)
 
 
 
 These patches fixes a build error caused by a merge
 conflict with the fb code, few timer warnings, and longer
 term regressions for tfp410 and omap h4 ethernet. Also
 included is a GPIO mode fix for the legacy mux code.

Also please pick up Paul Walmsley's series [GIT PULL] ARM: OMAP:
clock/cpuidle: fixes for the v3.8 merge window if you have
a chance.

Thanks,

Tony
 
 
 Javier Martinez Canillas (1):
   ARM: OMAP2+: common: remove use of vram
 
 Jon Hunter (6):
   ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
   ARM: AM335x: Fix warning in timer.c
   ARM: OMAP2420: Fix ethernet support for OMAP2420 H4
   ARM: OMAP: Remove debug-devices.c
   ARM: dts: OMAP2420: Correct H4 board memory size
   ARM: dts: Add build target for omap4-panda-a4
 
 Oleg Matcovschi (1):
   OMAP2+: mux: Fixed gpio mux mode analysis
 
 Roger Quadros (1):
   mfd: omap-usb-host: get rid of cpu_is_omap..() macros
 
 Tomi Valkeinen (1):
   OMAP: board-files: fix i2c_bus for tfp410
 
 Tony Lindgren (3):
   Merge branch 'fixes-timer-build' of git://github.com/jonhunter/linux 
 into omap-for-v3.8/fixes-for-merge-window
   ARM: OMAP: Move plat/omap-serial.h to 
 include/linux/platform_data/serial-omap.h
   Merge branch 'omap-for-v3.8/fixes-for-merge-window' into 
 omap-for-v3.8/fixes-for-merge-window-v2
 
 Vaibhav Hiremath (1):
   ARM: OMAP2+: Fix sparse warnings in timer.c
 
  arch/arm/boot/dts/Makefile |  1 +
  arch/arm/boot/dts/omap2420-h4.dts  |  2 +-
  arch/arm/mach-omap2/Kconfig|  3 +-
  arch/arm/mach-omap2/board-3430sdp.c|  1 +
  arch/arm/mach-omap2/board-am3517evm.c  |  1 +
  arch/arm/mach-omap2/board-cm-t35.c |  1 +
  arch/arm/mach-omap2/board-devkit8000.c |  1 +
  arch/arm/mach-omap2/board-h4.c | 83 +--
  arch/arm/mach-omap2/board-omap3evm.c   |  1 +
  arch/arm/mach-omap2/board-omap3stalker.c   |  1 +
  arch/arm/mach-omap2/common.c   |  3 -
  arch/arm/mach-omap2/mux.c  | 10 +--
  arch/arm/mach-omap2/mux.h  | 20 +++--
  arch/arm/mach-omap2/mux34xx.c  |  2 +-
  arch/arm/mach-omap2/serial.c   |  3 +-
  arch/arm/mach-omap2/timer.c|  6 +-
  arch/arm/mach-omap2/usb-host.c |  4 +
  arch/arm/plat-omap/Makefile|  1 -
  arch/arm/plat-omap/debug-devices.c | 92 
 --
  arch/arm/plat-omap/include/plat/debug-devices.h|  2 -
  drivers/mfd/omap-usb-host.c|  3 +-
  drivers/tty/serial/omap-serial.c   |  3 +-
  .../linux/platform_data/serial-omap.h  |  0
  include/linux/platform_data/usb-omap.h |  3 +
  include/video/omap-panel-tfp410.h  |  2 +-
  25 files changed, 64 insertions(+), 185 deletions(-)
  delete mode 100644 arch/arm/plat-omap/debug-devices.c
  delete mode 100644 arch/arm/plat-omap/include/plat/debug-devices.h
  rename arch/arm/plat-omap/include/plat/omap-serial.h = 
 include/linux/platform_data/serial-omap.h (100%)
 --
 To unsubscribe from this list: send the line unsubscribe 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 v3 1/5] ARM: OMAP4+: HDMI: Rename platform devices for ASoC drivers

2012-12-17 Thread Ricardo Neri
Assign more logical and meaningful names to the platform devices used
by ASoC OMAP HDMI drivers.

The previous omap-hdmi-audio device is renamed as omap-hdmi-audio-card
This is to better illustrate the fact that it describes the whole HDMI
audio in a given board.

The previous omap-hdmi-audio-dai is renamed as omap-hdmi-audio. The -dai
part is removed to not have references to ASoC concepts in the OMAPDSS
HDMI driver. Also, as it will be used by the ASoC HDMI CPU DAI driver,
the name refers only to OMAP HDMI audio functionality, irrespective of the
board.

The names of the ASoC drivers are also updated accordingly.

Signed-off-by: Ricardo Neri rn...@dextratech.com
---
 arch/arm/mach-omap2/devices.c   |4 ++--
 sound/soc/omap/omap-hdmi-card.c |4 ++--
 sound/soc/omap/omap-hdmi.c  |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index cba60e0..66518b2 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -356,7 +356,7 @@ static inline void omap_init_dmic(void) {}
defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)
 
 static struct platform_device omap_hdmi_audio = {
-   .name   = omap-hdmi-audio,
+   .name   = omap-hdmi-audio-card,
.id = -1,
 };
 
@@ -371,7 +371,7 @@ static void __init omap_init_hdmi_audio(void)
return;
}
 
-   pdev = omap_device_build(omap-hdmi-audio-dai,
+   pdev = omap_device_build(omap-hdmi-audio,
-1, oh, NULL, 0, NULL, 0, 0);
WARN(IS_ERR(pdev),
 Can't build omap_device for omap-hdmi-audio-dai.\n);
diff --git a/sound/soc/omap/omap-hdmi-card.c b/sound/soc/omap/omap-hdmi-card.c
index eaa2ea0..07b9959 100644
--- a/sound/soc/omap/omap-hdmi-card.c
+++ b/sound/soc/omap/omap-hdmi-card.c
@@ -27,12 +27,12 @@
 #include asm/mach-types.h
 #include video/omapdss.h
 
-#define DRV_NAME omap-hdmi-audio
+#define DRV_NAME omap-hdmi-audio-card
 
 static struct snd_soc_dai_link omap_hdmi_dai = {
.name = HDMI,
.stream_name = HDMI,
-   .cpu_dai_name = omap-hdmi-audio-dai,
+   .cpu_dai_name = omap-hdmi-audio,
.platform_name = omap-pcm-audio,
.codec_name = hdmi-audio-codec,
.codec_dai_name = omap-hdmi-hifi,
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index f59c69f..db08501 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -37,7 +37,7 @@
 #include omap-pcm.h
 #include omap-hdmi.h
 
-#define DRV_NAME omap-hdmi-audio-dai
+#define DRV_NAME omap-hdmi-audio
 
 struct hdmi_priv {
struct omap_pcm_dma_data dma_params;
-- 
1.7.10.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 v3 2/5] ARM: OMAP4: Assign IDs to DSS HDMI devices

2012-12-17 Thread Ricardo Neri
While Pandaboard and SDP4430 have only one HDMI output connector, it may be
possible that future boards and SoCs support more than one HDMI output.
Thus, we define the identifier of the device. This is used by display
common code to identify and create the platform devices for HDMI audio drivers.

Signed-off-by: Ricardo Neri rn...@dextratech.com
---
 arch/arm/mach-omap2/board-4430sdp.c|3 +++
 arch/arm/mach-omap2/board-omap4panda.c |3 +++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 3669c12..5a486d9 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -666,6 +666,9 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.type = OMAP_DISPLAY_TYPE_HDMI,
.channel = OMAP_DSS_CHANNEL_DIGIT,
.data = sdp4430_hdmi_data,
+   .dev = {
+   .id = -1,
+   },
 };
 
 static struct picodlp_panel_data sdp4430_picodlp_pdata = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..9f336a3 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -440,6 +440,9 @@ static struct omap_dss_device  omap4_panda_hdmi_device = {
.type = OMAP_DISPLAY_TYPE_HDMI,
.channel = OMAP_DSS_CHANNEL_DIGIT,
.data = omap4_panda_hdmi_data,
+   .dev = {
+   .id = -1,
+   },
 };
 
 static struct omap_dss_device *omap4_panda_dss_devices[] = {
-- 
1.7.10.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 v3 0/5] ARM: OMAP4+: HDMI: Update platform devices for audio

2012-12-17 Thread Ricardo Neri
Hi Mark, Tomi, Liam, Tony,

This set aims to be the version 3 of my previous submission[1] and aims to
address the comments that Mark and Tomi kindly provided on such submission.

The creation of the platform device for the HDMI audio interface from within the
OMAPDSS HDMI driver that was previously submitted[2] is resubmitted to be
complemented with code to relocate to arch/arm/mach-omap2/display.c the
creation of the platform devices for the HDMI ASoC codec and card drivers. This
series does not break the HDMI audio functionality in any patch.

Also, the names of the platform devices are changed to give them more logical
and more descriptive names.

As the commit

commit 14840b9a83c6a56629db2ba0ec247503e975f143
Author: Ricardo Neri ricardo.n...@ti.com
Date:   Tue Nov 6 00:19:17 2012 -0600

OMAPDSS: HDMI: Create platform device for audio support

is reverted in Tomi's git://gitorious.org/linux-omap-dss2/linux.git master
branch, this series applies cleanly.

Changes from v1:
*Put in a single series all the patches related to platform device updates.
*Now HDMI audio works correctly in every patch.
*Remove reference to the TPD12S015 HDMI companion chip as the ASoC drivers
 are not aware of this and other chips could be used in the future.

 Changes from v2:
*Split in two patches the renaming and the relocation of the platform devices.
*Create a separate patch to pass only the address offset of the DMA data port
 to the audio interface platform device.
*Keep the name hdmi-audio-codec to not refer to explicitly to OMAP. The codec
 can be made generic in a different patch series submitted to alsa-devel.

 BR,

 Ricardo


[1]. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80785.html
[2]. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg79795.html

Ricardo Neri (5):
  ARM: OMAP4+: HDMI: Rename platform devices for ASoC drivers
  ARM: OMAP4: Assign IDs to DSS HDMI devices
  ARM4: OMAP4+: HDMI: Relocate devices for audio codec and card
  ARM: OMAP4+: HDMI: Relocate the device for audio interface
  ARM: OMAP4+: HDMI: Refine the DMA port resource for audio

 arch/arm/mach-omap2/board-4430sdp.c|9 ++---
 arch/arm/mach-omap2/board-omap4panda.c |9 ++---
 arch/arm/mach-omap2/devices.c  |   31 
 arch/arm/mach-omap2/display.c  |   31 
 drivers/video/omap2/dss/hdmi.c |   62 
 sound/soc/omap/omap-hdmi-card.c|4 +--
 sound/soc/omap/omap-hdmi.c |5 ++-
 sound/soc/omap/omap-hdmi.h |2 --
 8 files changed, 103 insertions(+), 50 deletions(-)

--
1.7.10.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 v3 3/5] ARM4: OMAP4+: HDMI: Relocate devices for audio codec and card

2012-12-17 Thread Ricardo Neri
Relocate the creation the platform devices for audio the HDMI audio codec and
the audio card to display.c. This allows the display code to create the required
platform devices based on what is wired on the board. Thus, as many devices as
required are created; or none if the HDMI output is not implemented.

Signed-off-by: Ricardo Neri rn...@dextratech.com
---
 arch/arm/mach-omap2/board-4430sdp.c|6 --
 arch/arm/mach-omap2/board-omap4panda.c |6 --
 arch/arm/mach-omap2/devices.c  |7 ---
 arch/arm/mach-omap2/display.c  |   31 +++
 4 files changed, 31 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 5a486d9..0830d98 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -383,11 +383,6 @@ static struct platform_device sdp4430_dmic_codec = {
.id = -1,
 };

-static struct platform_device sdp4430_hdmi_audio_codec = {
-   .name   = hdmi-audio-codec,
-   .id = -1,
-};
-
 static struct omap_abe_twl6040_data sdp4430_abe_audio_data = {
.card_name = SDP4430,
.has_hs = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
@@ -422,7 +417,6 @@ static struct platform_device *sdp4430_devices[] __initdata 
= {
sdp4430_vbat,
sdp4430_dmic_codec,
sdp4430_abe_audio,
-   sdp4430_hdmi_audio_codec,
 };

 static struct omap_musb_board_data musb_board_data = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 9f336a3..561a5a7 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -126,11 +126,6 @@ static struct platform_device panda_abe_audio = {
},
 };

-static struct platform_device panda_hdmi_audio_codec = {
-   .name   = hdmi-audio-codec,
-   .id = -1,
-};
-
 static struct platform_device btwilink_device = {
.name   = btwilink,
.id = -1,
@@ -140,7 +135,6 @@ static struct platform_device *panda_devices[] __initdata = 
{
leds_gpio,
wl1271_device,
panda_abe_audio,
-   panda_hdmi_audio_codec,
btwilink_device,
 };

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 66518b2..6d37438 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -355,11 +355,6 @@ static inline void omap_init_dmic(void) {}
 #if defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)

-static struct platform_device omap_hdmi_audio = {
-   .name   = omap-hdmi-audio-card,
-   .id = -1,
-};
-
 static void __init omap_init_hdmi_audio(void)
 {
struct omap_hwmod *oh;
@@ -375,8 +370,6 @@ static void __init omap_init_hdmi_audio(void)
-1, oh, NULL, 0, NULL, 0, 0);
WARN(IS_ERR(pdev),
 Can't build omap_device for omap-hdmi-audio-dai.\n);
-
-   platform_device_register(omap_hdmi_audio);
 }
 #else
 static inline void omap_init_hdmi_audio(void) {}
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 282c814e..6cc9cea 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -414,6 +414,37 @@ int __init omap_display_init(struct omap_dss_board_info 
*board_data)
}
}

+   /* Create devices for HDMI audio drivers */
+   for (i = 0; i  board_data-num_devices; i++) {
+   struct platform_device *au_pdev;
+   struct omap_dss_device *dssdev = board_data-devices[i];
+   bool card_created = false;
+
+   if (dssdev-type != OMAP_DISPLAY_TYPE_HDMI)
+   continue;
+
+   /* We need only one device for the audio card */
+   if (card_created == false) {
+   au_pdev = create_simple_dss_pdev(omap-hdmi-audio-card,
+-1, NULL, 0, dss_pdev);
+   if (IS_ERR(au_pdev)) {
+   pr_err(Could not build platform_device for 
omap-hdmi-audio-card\n);
+   return PTR_ERR(au_pdev);
+   }
+   card_created = true;
+   }
+
+   /* One device for each HDMI connector in the board */
+   au_pdev = create_simple_dss_pdev(hdmi-audio-codec,
+ dssdev-dev.id,
+ NULL, 0, dss_pdev);
+   if (IS_ERR(au_pdev)) {
+   pr_err(Could not build platform_device for 
hdmi-audio-codec\n);
+   return PTR_ERR(au_pdev);
+   }
+
+   }
+
return 0;
 }

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

[PATCH v3 4/5] ARM: OMAP4+: HDMI: Relocate the device for audio interface

2012-12-17 Thread Ricardo Neri
The HDMI display and audio functionality share the same resources (e.g., 
register
spaces). The ASoC HDMI CPU-DAI driver needs access to some (but not all) the
resources of the dss_hdmi platform device. As such resources are within the
address space of omapdss_hdmi, it makes sense to have the DSS HDMI driver to
create the platform driver with the required resources.

Signed-off-by: Ricardo Neri rn...@dextratech.com
---
 arch/arm/mach-omap2/devices.c  |   24 
 drivers/video/omap2/dss/hdmi.c |   59 
 2 files changed, 59 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 6d37438..9fdc1f9 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -352,29 +352,6 @@ static void __init omap_init_dmic(void)
 static inline void omap_init_dmic(void) {}
 #endif
 
-#if defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI) || \
-   defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)
-
-static void __init omap_init_hdmi_audio(void)
-{
-   struct omap_hwmod *oh;
-   struct platform_device *pdev;
-
-   oh = omap_hwmod_lookup(dss_hdmi);
-   if (!oh) {
-   printk(KERN_ERR Could not look up dss_hdmi hw_mod\n);
-   return;
-   }
-
-   pdev = omap_device_build(omap-hdmi-audio,
-   -1, oh, NULL, 0, NULL, 0, 0);
-   WARN(IS_ERR(pdev),
-Can't build omap_device for omap-hdmi-audio-dai.\n);
-}
-#else
-static inline void omap_init_hdmi_audio(void) {}
-#endif
-
 #if defined(CONFIG_SPI_OMAP24XX) || defined(CONFIG_SPI_OMAP24XX_MODULE)
 
 #include linux/platform_data/spi-omap2-mcspi.h
@@ -620,7 +597,6 @@ static int __init omap2_init_devices(void)
 */
omap_init_audio();
omap_init_camera();
-   omap_init_hdmi_audio();
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 769d082..0dde2b5 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -60,6 +60,9 @@
 static struct {
struct mutex lock;
struct platform_device *pdev;
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+   struct platform_device *audio_pdev;
+#endif
 
struct hdmi_ip_data ip_data;
 
@@ -822,6 +825,51 @@ static void hdmi_put_clocks(void)
 }
 
 #if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+static int hdmi_probe_audio(struct platform_device *pdev)
+{
+   struct resource *res;
+   struct platform_device *aud_pdev;
+   struct resource aud_res[2] = {
+   DEFINE_RES_MEM(-1, -1),
+   DEFINE_RES_DMA(-1),
+   };
+
+   res = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   DSSERR(can't get IORESOURCE_MEM HDMI\n);
+   return -EINVAL;
+   }
+
+   /*
+* Pass this resource to audio drivers to find the DMA port address.
+* Audio drivers should not ioremap it.
+*/
+   aud_res[0].start = res-start;
+   aud_res[0].end = res-end;
+
+   res = platform_get_resource(hdmi.pdev, IORESOURCE_DMA, 0);
+   if (!res) {
+   DSSERR(can't get IORESOURCE_DMA HDMI\n);
+   return -EINVAL;
+   }
+
+   /* Pass the audio DMA request resource to audio drivers. */
+   aud_res[1].start = res-start;
+
+   /* create platform device for HDMI audio driver */
+   aud_pdev = platform_device_register_simple(omap-hdmi-audio,
+  pdev-id, aud_res,
+  ARRAY_SIZE(aud_res));
+   if (IS_ERR(aud_pdev)) {
+   DSSERR(Can't instantiate hdmi-audio\n);
+   return -ENODEV;
+   }
+
+   hdmi.audio_pdev = aud_pdev;
+
+   return 0;
+}
+
 int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts)
 {
u32 deep_color;
@@ -,6 +1159,12 @@ static int __init omapdss_hdmihw_probe(struct 
platform_device *pdev)
 
hdmi_probe_pdata(pdev);
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+   r = hdmi_probe_audio(pdev);
+   if (r)
+   DSSWARN(could not create platform device for audio);
+#endif
+
return 0;
 
 err_panel_init:
@@ -1127,6 +1181,11 @@ static int __exit hdmi_remove_child(struct device *dev, 
void *data)
 
 static int __exit omapdss_hdmihw_remove(struct platform_device *pdev)
 {
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+   if (hdmi.audio_pdev != NULL)
+   platform_device_unregister(hdmi.audio_pdev);
+#endif
+
device_for_each_child(pdev-dev, NULL, hdmi_remove_child);
 
dss_unregister_child_devices(pdev-dev);
-- 
1.7.10.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 v3 5/5] ARM: OMAP4+: HDMI: Refine the DMA port resource for audio

2012-12-17 Thread Ricardo Neri
Instead of passing the complete address space to the platform device for audio,
just pass the address offset of the DMA port for audio samples. Thus, we prevent
that two drivers try to ioremap the same resources. This is to be safe, as the
ASoC HDMI CPU-DAI driver will not need to ioremap such resource.

Signed-off-by: Ricardo Neri rn...@dextratech.com
---
 drivers/video/omap2/dss/hdmi.c |9 ++---
 sound/soc/omap/omap-hdmi.c |3 +--
 sound/soc/omap/omap-hdmi.h |2 --
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 0dde2b5..b758f83 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -829,6 +829,7 @@ static int hdmi_probe_audio(struct platform_device *pdev)
 {
struct resource *res;
struct platform_device *aud_pdev;
+   u32 port_offset, port_size;
struct resource aud_res[2] = {
DEFINE_RES_MEM(-1, -1),
DEFINE_RES_DMA(-1),
@@ -841,11 +842,13 @@ static int hdmi_probe_audio(struct platform_device *pdev)
}
 
/*
-* Pass this resource to audio drivers to find the DMA port address.
+* Pass DMA audio port to audio drivers.
 * Audio drivers should not ioremap it.
 */
-   aud_res[0].start = res-start;
-   aud_res[0].end = res-end;
+   hdmi.ip_data.ops-audio_get_dma_port(port_offset, port_size);
+
+   aud_res[0].start = res-start + port_offset;
+   aud_res[0].end =  aud_res[0].start + port_size - 1;
 
res = platform_get_resource(hdmi.pdev, IORESOURCE_DMA, 0);
if (!res) {
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index db08501..33418fc 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -281,8 +281,7 @@ static __devinit int omap_hdmi_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
-   hdmi_data-dma_params.port_addr =  hdmi_rsrc-start
-   + OMAP_HDMI_AUDIO_DMA_PORT;
+   hdmi_data-dma_params.port_addr =  hdmi_rsrc-start;
 
hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_DMA, 0);
if (!hdmi_rsrc) {
diff --git a/sound/soc/omap/omap-hdmi.h b/sound/soc/omap/omap-hdmi.h
index 6ad2bf4..33d7a93 100644
--- a/sound/soc/omap/omap-hdmi.h
+++ b/sound/soc/omap/omap-hdmi.h
@@ -25,8 +25,6 @@
 #ifndef __OMAP_HDMI_H__
 #define __OMAP_HDMI_H__
 
-#define OMAP_HDMI_AUDIO_DMA_PORT 0x8c
-
 #define OMAP_HDMI_RATES(SNDRV_PCM_RATE_32000 | \
SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | \
SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000 | \
-- 
1.7.10.4

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


Re: [GIT PULL] ARM: OMAP: clock/cpuidle: fixes for the v3.8 merge window

2012-12-17 Thread Olof Johansson
On Mon, Dec 17, 2012 at 04:38:55PM -0800, Tony Lindgren wrote:
 Olof,
 
 * Paul Walmsley p...@pwsan.com [121217 11:12]:
  Hi Tony
  
  The following changes since commit 7a280cf512053137a37da2801eac73a8842fa50d:
  
Merge tag 'disintegrate-x86-20121214' of 
  git://git.infradead.org/users/dhowells/linux-headers (2012-12-14 15:48:52 
  -0800)
  
  are available in the git repository at:
  
  
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
  tags/omap-fixes-a-for-v3.8-window
  
  for you to fetch changes up to 9db316b6bf0234d9391f87dd0d28b23f5a44facb:
  
ARM: OMAP3/4: cpuidle: fix sparse and checkpatch warnings (2012-12-15 
  01:41:24 -0700)
  
  
  Fix some OMAP4 clock problems, and deal with some sparse warnings from
  the OMAP CPUIdle code.
 
 Can you please pick up this one too?

Done, pulled.


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


Re: [GIT PULL 1/2] omap fixes for v3.8 merge window

2012-12-17 Thread Olof Johansson
On Mon, Dec 17, 2012 at 11:10:46AM -0800, Tony Lindgren wrote:
 The following changes since commit 2b8318881ddbcb67c5e8d2178b4228474944:
 
   Merge tag 'fbdev-for-3.8' of git://gitorious.org/linux-omap-dss2/linux 
 (2012-12-15 13:03:48 -0800)
 
 are available in the git repository at:
 
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.8/fixes-for-merge-window-v4-signed
 
 for you to fetch changes up to 2cb85a7bd2ca6db3ab3d632d0a1b6ca3770ddcf4:
 
   Merge branch 'omap-for-v3.8/fixes-for-merge-window' into 
 omap-for-v3.8/fixes-for-merge-window-v2 (2012-12-16 11:28:10 -0800)

Thanks, pulled.


-Olof

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