Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
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
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
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
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
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.
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
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
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
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()
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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+
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
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
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+
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
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
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
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
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
* 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
* 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
* 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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
