Re: [PATCH 03/30] video/omap: fix build dependencies
Hi Arnd, On Sun, 2011-10-02 at 16:45 +0200, Arnd Bergmann wrote: > Four of the LCD panel drivers depend on the backlight class, > so add the dependency in Kconfig. > Selecting the BACKLIGHT_CLASS_DEVICE symbol does not generally > work since it has other dependencies. > > Signed-off-by: Arnd Bergmann > Cc: Tomi Valkeinen This looks ok to me. If it's fine to you, I'll queue this patch in my DSS tree to prevent possible conflicts. 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 02/30] video/omap: fix dependencies
Hi Arnd, On Sun, 2011-10-02 at 16:45 +0200, Arnd Bergmann wrote: > The lcd_2430sdp and lcd_ldp drivers depend on TWL4030, which is not > well expressed in the Kconfig. Create new configuration options for > these in order to describe the dependencies correctly. > > In some cases, the driver cannot be a loadable module, so better > force it to be built-in. > > While we're at it, simplify the Makefile syntax. > > Signed-off-by: Arnd Bergmann > Cc: Tomi Valkeinen > --- > drivers/video/omap/Kconfig | 41 +--- > drivers/video/omap/Makefile | 64 > --- > 2 files changed, 67 insertions(+), 38 deletions(-) I have ported lcd_2430sdp and lcd_ldp drivers (and also other OMAP2/3 panel drivers, except N800) to the newer omapdss driver (drivers/video/omap2), and the code is in my for-next branch (git://gitorious.org/linux-omap-dss2/linux.git for-next). I have also worked on removing OMAP2/3 support from the old omapfb driver, thus making it OMAP1 fb driver. This code is not yet ready, and won't make it in the next merge window. Your patch will conflict with both of those changes. Is it ok for you to drop this patch, and I'll make a new one on top of my changes to clean up the Makefile in a similar way than you did? The new patch wouldn't make it in the next merge window, though, but I don't think this patch is fixing any bigger bug, so perhaps it's not so urgent. 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 20/30] media/omap_vout: disable driver for now
Hi Arnd, On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: This driver was broken by 8cff88c5d "OMAP: DSS2: remove update_mode from omapdss": /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c: In function 'omap_vout_probe': /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2202:15: error: 'struct omap_dss_driver' has no member named 'set_update_mode' /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2203:12: error: 'struct omap_dss_driver' has no member named 'set_update_mode' /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2204:8: error: 'OMAP_DSS_UPDATE_MANUAL' undeclared (first use in this function) /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2204:8: note: each undeclared identifier is reported only once for each function it appears in /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2206:15: error: 'struct omap_dss_driver' has no member named 'set_update_mode' /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2207:12: error: 'struct omap_dss_driver' has no member named 'set_update_mode' /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2208:8: error: 'OMAP_DSS_UPDATE_AUTO' undeclared (first use in this function) make[3]: *** [drivers/media/video/omap/omap_vout.o] Error 1 make[2]: *** [drivers/media/video/omap] Error 2 make[1]: *** [drivers/media/video/] Error 2 make: *** [sub-make] Error 2 A fix for this is already in the master branch of Mauro's tree: git://linuxtv.org/media_tree.git with the commit id: 5ebbf72dc51bd3b481aa91fea37a7157da5fc548 I am guessing this would during the 3.2 merge window. Regards, Archit Let's disable it for now. Signed-off-by: Arnd Bergmann Cc: Mauro Carvalho Chehab Cc: Archit Taneja Cc: Amber Jain Cc: Vaibhav Hiremath --- drivers/media/video/omap/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap/Kconfig b/drivers/media/video/omap/Kconfig index 390ab09..ee21f36 100644 --- a/drivers/media/video/omap/Kconfig +++ b/drivers/media/video/omap/Kconfig @@ -4,6 +4,7 @@ config VIDEO_OMAP2_VOUT_VRFB config VIDEO_OMAP2_VOUT tristate "OMAP2/OMAP3 V4L2-Display driver" depends on ARCH_OMAP2 || ARCH_OMAP3 + depends on BROKEN # broken by 8cff88c5da "OMAP: DSS2: remove update_mode from omapdss" select VIDEOBUF_GEN select VIDEOBUF_DMA_CONTIG select OMAP2_DSS -- To unsubscribe from this list: send the line "unsubscribe 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 v6 02/16] OMAP2+: hwmod: Add API to check IO PAD wakeup status
On Mon, Oct 3, 2011 at 10:53 AM, Rajendra Nayak wrote:
> On Monday 03 October 2011 10:30 AM, Govindraj wrote:
>>
>> Thanks for the review,
>>
>>
>> On Sat, Oct 1, 2011 at 8:03 PM, Rajendra Nayak wrote:
>>>
>>> On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Wake up event set will be cleared on pad mux_read.
>>>
>>> Are these api's even getting used in this series?
>>
>> Used in Tero's irq_chaining patches.
>
> So shouldn't this patch be part of his series instead?
Yes it is. Part of his v9-series.
--
Thanks,
Govindraj.R
>
>>
>> http://lkml.org/lkml/2011/9/23/121
>>
>> --
>> Thanks,
>> Govindraj.R
>>
>>
>>>
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/mux.c | 30
++
arch/arm/mach-omap2/mux.h | 13 +++
arch/arm/mach-omap2/omap_hwmod.c | 7 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 +
4 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 655e948..fb75aae 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -351,6 +351,36 @@ err1:
return NULL;
}
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Gets the wakeup status of given pad from omap-hwmod.
+ * Returns true if wakeup capability is set and wakeup event occurred.
+ * Returns false if wakeup event has not occurred or pads are not
available.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ int i;
+ unsigned int val;
+ u8 ret = false;
+
+ for (i = 0; i< hmux->nr_pads; i++) {
+ struct omap_device_pad *pad =&hmux->pads[i];
+
+ if (pad->flags& OMAP_DEVICE_PAD_WAKEUP) {
+ val = omap_mux_read(pad->partition,
+ pad->mux->reg_offset);
+ if (val& OMAP_WAKEUP_EVENT) {
+ ret = true;
+ break;
+ }
+ }
+ }
+
+ return ret;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 2132308..8b2150a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,21 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads,
int nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Called only from omap_hwmod.c, do not use.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux);
#else
+static inline bool
+omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index e751dd9..a8b24d7 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2724,3 +2724,10 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod
*oh)
return 0;
}
+
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh)
+{
+ if (oh&& oh->mux)
+ return omap_hwmod_mux_get_wake_status(oh->mux);
+ return -EINVAL;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0e329ca..9a6195c 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -607,6 +607,7 @@ u32 omap_hwmod_get_context_loss_count(struct
omap_hwmod *oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh);
/*
* Chip variant-specific hwmod init routines - XXX should be converted
* to use initcalls once the initial boot ordering is straightened out
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-serial"
>>> in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>
>
--
To unsubsc
Re: [PATCH 28/30] ARM: omap: select CPU_FREQ_TABLE where needed
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > The omap platform requires CPU_FREQ_TABLE support to be enabled for its > CPU_FREQ implementations, so automatically select that when CPU_FREQ > is enabled. > > Signed-off-by: Arnd Bergmann > --- > arch/arm/plat-omap/Kconfig |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig > index bb8f4a6..f7ef9f4 100644 > --- a/arch/arm/plat-omap/Kconfig > +++ b/arch/arm/plat-omap/Kconfig > @@ -217,6 +217,11 @@ config OMAP_PM_NOOP > > endchoice > > +config OMAP_CPU_FREQ > + def_bool "y" > + depends on CPU_FREQ > + select CPU_FREQ_TABLE > + > endmenu With CPUFREQ series from Kevin [1], I don't think we need this any-more. More so, I didn't find OMAP_CPU_FREQ is being used anywhere on mainline. Regards Santosh [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg56288.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 30/30] ARM: omap2: select ARM_AMBA for OMAP3_EMU
On Sunday 02 October 2011 08:16 PM, Arnd Bergmann wrote: > OMAP3_EMU needs OC_ETM, which needs ARM_AMBA. Since the latter > dependency is getting turned from a 'select' into a 'depends', > omap has to select ARM_AMBA itself in order to have a correct > dependency chain. Alternatively, we could change OMAP3_EMU > to have a 'depends on OC_ETM' instead of selecting it. > > Signed-off-by: Arnd Bergmann Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe 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 27/30] ARM: omap: select L2X0 cache on omap4
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > The cache controller needs to be enabled for the > cortex-a9 specific errata that are also selected > to work. > > Signed-off-by: Arnd Bergmann Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe 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 26/30] ARM: omap: add board autoselection
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > At least one board file needs to be selected to successfully build > a kernel, so this one adds logic to the omap Kconfig file to > pick one default board file when all others are disabled. Since > the available boards depend on the SoC family (omap2/3/4) being > selected first, this adds one default for each family. > > Signed-off-by: Arnd Bergmann > --- > arch/arm/mach-omap2/Kconfig | 39 +++ > 1 files changed, 39 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 3c9fb89..fd0ab18 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -120,6 +120,45 @@ config MACH_OMAP_GENERIC > depends on ARCH_OMAP2 > default y > > +config MACH_OMAP_AUTO_BOARD > + def_bool y > + depends on !MACH_OMAP2_TUSB6010 > + depends on !MACH_OMAP_H4 > + depends on !MACH_OMAP_APOLLON > + depends on !MACH_OMAP_APOLLON > + depends on !MACH_OMAP_2430SDP > + depends on !MACH_OMAP3_BEAGLE > + depends on !MACH_DEVKIT8000 > + depends on !MACH_OMAP_LDP > + depends on !MACH_OMAP3530_LV_SOM > + depends on !MACH_OMAP3_TORPEDO > + depends on !MACH_OVERO > + depends on !MACH_OMAP3EVM > + depends on !MACH_OMAP3517EVM > + depends on !MACH_CRANEBOARD > + depends on !MACH_OMAP3_PANDORA > + depends on !MACH_OMAP3_TOUCHBOOK > + depends on !MACH_NOKIA_N8X0 > + depends on !MACH_NOKIA_RM680 > + depends on !MACH_NOKIA_RX51 > + depends on !MACH_OMAP_ZOOM2 > + depends on !MACH_OMAP_ZOOM3 > + depends on !MACH_CM_T35 > + depends on !MACH_CM_T3517 > + depends on !MACH_IGEP0020 > + depends on !MACH_IGEP0030 > + depends on !MACH_SBC3530 > + depends on !MACH_OMAP_3630SDP > + depends on !MACH_TI8168EVM > + depends on !MACH_OMAP4_PANDA Do we need all above 'depends on *' ? Even if they get selected for one of the below ARCH along with default machine, build should be happy. Right ? > + select MACH_OMAP_GENERIC if ARCH_OMAP2 > + select MACH_OMAP_3430SDP if ARCH_OMAP3 && !ARCH_OMAP2 > + select MACH_OMAP_4430SDP if ARCH_OMAP4 && !ARCH_OMAP3 && !ARCH_OMAP2 This is fine. Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe 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 v6 02/16] OMAP2+: hwmod: Add API to check IO PAD wakeup status
On Monday 03 October 2011 10:30 AM, Govindraj wrote:
Thanks for the review,
On Sat, Oct 1, 2011 at 8:03 PM, Rajendra Nayak wrote:
On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Wake up event set will be cleared on pad mux_read.
Are these api's even getting used in this series?
Used in Tero's irq_chaining patches.
So shouldn't this patch be part of his series instead?
http://lkml.org/lkml/2011/9/23/121
--
Thanks,
Govindraj.R
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/mux.c| 30
++
arch/arm/mach-omap2/mux.h| 13 +++
arch/arm/mach-omap2/omap_hwmod.c |7 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
4 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 655e948..fb75aae 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -351,6 +351,36 @@ err1:
return NULL;
}
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Gets the wakeup status of given pad from omap-hwmod.
+ * Returns true if wakeup capability is set and wakeup event occurred.
+ * Returns false if wakeup event has not occurred or pads are not
available.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ int i;
+ unsigned int val;
+ u8 ret = false;
+
+ for (i = 0; inr_pads; i++) {
+ struct omap_device_pad *pad =&hmux->pads[i];
+
+ if (pad->flags&OMAP_DEVICE_PAD_WAKEUP) {
+ val = omap_mux_read(pad->partition,
+ pad->mux->reg_offset);
+ if (val&OMAP_WAKEUP_EVENT) {
+ ret = true;
+ break;
+ }
+ }
+ }
+
+ return ret;
+}
+
/* Assumes the calling function takes care of locking */
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
{
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 2132308..8b2150a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,21 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads,
int nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+/**
+ * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
+ * @hmux: Pads for a hwmod
+ *
+ * Called only from omap_hwmod.c, do not use.
+ */
+bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux);
#else
+static inline bool
+omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index e751dd9..a8b24d7 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2724,3 +2724,10 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod
*oh)
return 0;
}
+
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh)
+{
+ if (oh&&oh->mux)
+ return omap_hwmod_mux_get_wake_status(oh->mux);
+ return -EINVAL;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0e329ca..9a6195c 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -607,6 +607,7 @@ u32 omap_hwmod_get_context_loss_count(struct
omap_hwmod *oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
+int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh);
/*
* Chip variant-specific hwmod init routines - XXX should be converted
* to use initcalls once the initial boot ordering is straightened out
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 25/30] ARM: OMAP depends on MMU
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > There is no way to build OMAP kernels without an MMU > at this point because of dependencies on MMU-only functions. > > As long as nobody is interested in fixing this, let's just disable > this platforms for nommu kernels. > > Signed-off-by: Arnd Bergmann > --- Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe 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 24/30] ARM: omap2+: ensure that one of omap2/3/4 is selected
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > Random configurations can fail if none of the omap families > in mach-omap2 is selected. This patch automatically selects > omap2 if the user has not made any other choice. > > Signed-off-by: Arnd Bergmann > --- OMAP4 would have been a better default but am fine with OMAP2 too. Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe 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] OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader
Hi Paul,
On Monday 03 October 2011 10:15 AM, Paul Walmsley wrote:
Hi
some comments:
On Mon, 12 Sep 2011, Archit Taneja wrote:
Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
inconsistent state. Thus if the bootloader has enabled a display, the hwmod code
cannot reset the DISPC module just like that, but the outputs need to be
disabled first.
Add function dispc_disable_outputs() which disables all active overlay manager
and ensure all frame transfers are completed.
Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the
DSS2 driver starts.
This resolves the hang issue(caused by a L3 error during boot) seen on the
beagle board C3, which has a factory bootloader that enables display. The issue
is resolved with this patch.
Acked-by: Tomi Valkeinen
Tested-by: R, Sricharan
Signed-off-by: Archit Taneja
---
v2:
- Added more info in the commit message, fixed some typos.
The patch depends on a HWMOD patch series which has been posted by Tomi, it can
be tested by applying over the following branch:
https://gitorious.org/linux-omap-dss2/linux/commits/master
arch/arm/mach-omap2/display.c | 110 +
1 files changed, 110 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 93db7c1..eab81f4 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -30,6 +30,30 @@
#include "control.h"
+#define DISPC_BASE_OMAP2 0x48050400
+#define DISPC_BASE_OMAP4 0x48041000
These should definitely not be needed -- they can be obtained from the
hwmod data and there is clearly something wrong if any IP block addresses
exist outside of those data files.
The reason we had to do this was because the function omap_dss_reset()
is tied to the dss hwmod and not dispc hwmod. Hence, we don't have DISPC
related info through the hwmod struct available through omap_dss_reset().
It would have been easy(and more sensible) if we had tied the code in
dispc_disable_outputs() to a custom reset function for the dispc hwmod
directly, but that unfortunately breaks some functionality. The current
omap_dss_reset() function does this:
- enable DSS opt clocks to complete power on reset.
- see if the power on reset is completed by reading DSS_SYSNCONG
- disable DSS opt clocks
If we don't do the things done in dispc_disable_outputs() before
disabling DSS opt clocks, we would be in trouble.
Hence, there is a need to access DISPC registers in the dss hwmod
itself, this forced us to create the base macros and the use of
omap_readl/writel functions.
I considered changing the order in which the hwmods are registered, i.e
dispc first and dss later, but that didn't seem right
Could you suggest how we could go about this? Is there a way to access
dispc hwmod's data in dss hwmod's custom reset function?
I agree with all the other comments and things you have done in the
patch you made. Thanks for the thorough review and the patch, i'll keep
these comments in mind for future.
Regards,
Archit
+
+#define DISPC_REG(base, offset) (base + offset)
+
+#define DISPC_CONTROL0x0040
+#define DISPC_CONTROL2 0x0238
+#define DISPC_IRQSTATUS 0x0018
+
+#define DSS_SYSCONFIG0x10
+#define DSS_SYSSTATUS0x14
+#define DSS_CONTROL 0x40
+#define DSS_SDI_CONTROL 0x44
+#define DSS_PLL_CONTROL 0x48
+
+#define LCD_EN_MASK (0x1<< 0)
+#define DIGIT_EN_MASK(0x1<< 1)
+
+#define FRAMEDONE_IRQ_SHIFT 0
+#define EVSYNC_EVEN_IRQ_SHIFT2
+#define EVSYNC_ODD_IRQ_SHIFT 3
+#define FRAMEDONE2_IRQ_SHIFT 22
+#define FRAMEDONETV_IRQ_SHIFT24
+
static struct platform_device omap_display_device = {
.name = "omapdss",
.id= -1,
@@ -182,6 +206,78 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
return r;
}
+static void dispc_disable_outputs(void)
+{
+ u32 val, irq_mask, base;
+ bool lcd_en, digit_en, lcd2_en = false;
+ int i, num_mgrs;
+
+ if (cpu_is_omap44xx()) {
+ base = DISPC_BASE_OMAP4;
+ num_mgrs = 3;
+ } else {
+ base = DISPC_BASE_OMAP2;
+ num_mgrs = 2;
+ }
base should not be needed here. The num_mgrs should come from the hwmod
data. We're trying to get rid of cpu_is_omap*() functions wherever
possible.
+
+ /* store value of LCDENABLE and DIGITENABLE bits */
+ val = omap_readl(DISPC_REG(base, DISPC_CONTROL));
omap_{read,write}l() are deprecated and should no longer be used. This
code can use omap_hwmod_{read,write}() instead. You can pass the struct
omap_hwmod * into this function from the caller.
+ lcd_en = val& LCD_EN_MASK;
+ digit_en = val& DIGIT_EN_MASK;
+
+ /* st
Re: [PATCH 23/30] ARM: omap2: select twl4030 support on boards that need it
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > These three boards unconditionally use the twl4030 driver > from the board-zoom-display.c file. Make sure that the driver > is always there. > We also need to select the I2C core so we are able to build > that driver. > > Signed-off-by: Arnd Bergmann > --- > arch/arm/mach-omap2/Kconfig |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 57b66d5..4deeade 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -253,6 +253,8 @@ config MACH_OMAP_ZOOM2 > select SERIAL_CORE_CONSOLE > select SERIAL_8250_CONSOLE > select REGULATOR_FIXED_VOLTAGE > + select TWL4030_CORE > + select I2C > Another option to ensure I2C is selected when TWL* drivers are selected is let it depends on I2C. That wat we can avoid patching every machine entry with I2C option. Not a strong opinion though. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/30] ARM: omap2: irq.c is always needed
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > The Makefile only includes irq.o for omap2 and omap3, but it's in > fact also required to build omap4-only kernels. > > Signed-off-by: Arnd Bergmann That should not be the case. Why do you think it is needed for OMAP4 ? There is nothing in this file which OMAP4 needs since it makes use of GIC and wakeupgen for it's interrupt handling. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/30] ARM: omap2+: fix omap_hdq_init compilation
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > The definition of the device must depend on the hardware > we run on, not on the kernel configuration. > > arch/arm/mach-omap2/devices.c:624:13: error: 'OMAP_HDQ_BASE' undeclared here > (not in a function) > > Signed-off-by: Arnd Bergmann > --- Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe 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 07/30] ARM: omap: fix visibility of omap2_mbox_iva_priv
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > map2_mbox_iva_priv is used on multiple omap2 socs but is hidden > in an outdated #ifdef that is specific to a single soc. > > Signed-off-by: Arnd Bergmann > --- Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe 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 05/30] ARM: omap: enable building omap2 without omap2420/2430
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > Kconfig allows selecting CONFIG_OMAP2 but no specific SOC, the options > being omap2420 and omap2430, but that leads to a build error when > omap3 or omap4 are also enabled and the MULTI_OMAP2 symbol is > undefined. > > This adds another clause to plat/multi.h, mainly to allow all > possible randconfig combinations to build cleanly. > > Signed-off-by: Arnd Bergmann Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe 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 06/30] ARM: omap: fix build with CONFIG_I2C_OMAP disabled
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > We must not reference omap_i2c_reset if the file defining it > does not get built. > > Signed-off-by: Arnd Bergmann > --- Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe 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 00/30] ARM/omap: omap specific randconfig fixes
Arnd, On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > Hi Tony, > > I've mentioned these patches before, and now I've managed to > go through them again and clean them enough for submission. > > If nobody has any objections, I would like to send them to > Linus in the coming merge window, otherwise it would be nice > if you could pick the ones that look good to you and send > me a pull request. If any of these look like they should be > backported to stable kernels, please tell me and I'll add > a cc:stable@k.o tag. > > The entire set is also available from > git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/omap > > but I have not yet pulled them into the for-next branch. > Do you have any scripts to create these randconfigs ? These are useful to run on newer set of patches also to get all builds right first place. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 02/16] OMAP2+: hwmod: Add API to check IO PAD wakeup status
Thanks for the review,
On Sat, Oct 1, 2011 at 8:03 PM, Rajendra Nayak wrote:
> On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
>>
>> Add API to determine IO-PAD wakeup event status for a given
>> hwmod dynamic_mux pad.
>>
>> Wake up event set will be cleared on pad mux_read.
>
> Are these api's even getting used in this series?
Used in Tero's irq_chaining patches.
http://lkml.org/lkml/2011/9/23/121
--
Thanks,
Govindraj.R
>
>>
>> Signed-off-by: Govindraj.R
>> ---
>> arch/arm/mach-omap2/mux.c | 30
>> ++
>> arch/arm/mach-omap2/mux.h | 13 +++
>> arch/arm/mach-omap2/omap_hwmod.c | 7 ++
>> arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 +
>> 4 files changed, 51 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
>> index 655e948..fb75aae 100644
>> --- a/arch/arm/mach-omap2/mux.c
>> +++ b/arch/arm/mach-omap2/mux.c
>> @@ -351,6 +351,36 @@ err1:
>> return NULL;
>> }
>>
>> +/**
>> + * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
>> + * @hmux: Pads for a hwmod
>> + *
>> + * Gets the wakeup status of given pad from omap-hwmod.
>> + * Returns true if wakeup capability is set and wakeup event occurred.
>> + * Returns false if wakeup event has not occurred or pads are not
>> available.
>> + */
>> +bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
>> +{
>> + int i;
>> + unsigned int val;
>> + u8 ret = false;
>> +
>> + for (i = 0; i< hmux->nr_pads; i++) {
>> + struct omap_device_pad *pad =&hmux->pads[i];
>> +
>> + if (pad->flags& OMAP_DEVICE_PAD_WAKEUP) {
>> + val = omap_mux_read(pad->partition,
>> + pad->mux->reg_offset);
>> + if (val& OMAP_WAKEUP_EVENT) {
>> + ret = true;
>> + break;
>> + }
>> + }
>> + }
>> +
>> + return ret;
>> +}
>> +
>> /* Assumes the calling function takes care of locking */
>> void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
>> {
>> diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
>> index 2132308..8b2150a 100644
>> --- a/arch/arm/mach-omap2/mux.h
>> +++ b/arch/arm/mach-omap2/mux.h
>> @@ -225,8 +225,21 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads,
>> int nr_pads);
>> */
>> void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
>>
>> +/**
>> + * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup
>> + * @hmux: Pads for a hwmod
>> + *
>> + * Called only from omap_hwmod.c, do not use.
>> + */
>> +bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux);
>> #else
>>
>> +static inline bool
>> +omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux)
>> +{
>> + return 0;
>> +}
>> +
>> static inline int omap_mux_init_gpio(int gpio, int val)
>> {
>> return 0;
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
>> b/arch/arm/mach-omap2/omap_hwmod.c
>> index e751dd9..a8b24d7 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -2724,3 +2724,10 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod
>> *oh)
>>
>> return 0;
>> }
>> +
>> +int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh)
>> +{
>> + if (oh&& oh->mux)
>> + return omap_hwmod_mux_get_wake_status(oh->mux);
>> + return -EINVAL;
>> +}
>> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> index 0e329ca..9a6195c 100644
>> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> @@ -607,6 +607,7 @@ u32 omap_hwmod_get_context_loss_count(struct
>> omap_hwmod *oh);
>>
>> int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
>>
>> +int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh);
>> /*
>> * Chip variant-specific hwmod init routines - XXX should be converted
>> * to use initcalls once the initial boot ordering is straightened out
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/30] ARM: omap: add missing __devexit_p() annotations
On Sunday 02 October 2011 08:15 PM, Arnd Bergmann wrote: > Drivers that refer to a __devexit function in an operations > structure need to annotate that pointer with __devexit_p so > replace it with a NULL pointer when the section gets discarded. > > Signed-off-by: Arnd Bergmann > --- Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe 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 19/30] tty/serial/omap: console can only be built-in
On Sun, Oct 2, 2011 at 8:15 PM, Arnd Bergmann wrote: > When the omap serial driver is built as a module, we must > not allow the console driver to be selected, because consoles > can not be loadable modules. Agree. > > Signed-off-by: Arnd Bergmann > Cc: Govindraj.R Acked-by: Govindraj.R > --- > drivers/tty/serial/Kconfig | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > index 4dcb37bb..eb04b2f 100644 > --- a/drivers/tty/serial/Kconfig > +++ b/drivers/tty/serial/Kconfig > @@ -1346,7 +1346,7 @@ config SERIAL_OMAP > > config SERIAL_OMAP_CONSOLE > bool "Console on OMAP serial port" > - depends on SERIAL_OMAP > + depends on SERIAL_OMAP=y > select SERIAL_CORE_CONSOLE > help > Select this option if you would like to use omap serial port as > -- > 1.7.5.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe 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] OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader
Hi
some comments:
On Mon, 12 Sep 2011, Archit Taneja wrote:
> Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
> inconsistent state. Thus if the bootloader has enabled a display, the hwmod
> code
> cannot reset the DISPC module just like that, but the outputs need to be
> disabled first.
>
> Add function dispc_disable_outputs() which disables all active overlay manager
> and ensure all frame transfers are completed.
>
> Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
> DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the
> DSS2 driver starts.
>
> This resolves the hang issue(caused by a L3 error during boot) seen on the
> beagle board C3, which has a factory bootloader that enables display. The
> issue
> is resolved with this patch.
>
> Acked-by: Tomi Valkeinen
> Tested-by: R, Sricharan
> Signed-off-by: Archit Taneja
> ---
> v2:
>
> - Added more info in the commit message, fixed some typos.
>
> The patch depends on a HWMOD patch series which has been posted by Tomi, it
> can
> be tested by applying over the following branch:
>
> https://gitorious.org/linux-omap-dss2/linux/commits/master
>
> arch/arm/mach-omap2/display.c | 110
> +
> 1 files changed, 110 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index 93db7c1..eab81f4 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -30,6 +30,30 @@
>
> #include "control.h"
>
> +#define DISPC_BASE_OMAP2 0x48050400
> +#define DISPC_BASE_OMAP4 0x48041000
These should definitely not be needed -- they can be obtained from the
hwmod data and there is clearly something wrong if any IP block addresses
exist outside of those data files.
> +
> +#define DISPC_REG(base, offset) (base + offset)
> +
> +#define DISPC_CONTROL0x0040
> +#define DISPC_CONTROL2 0x0238
> +#define DISPC_IRQSTATUS 0x0018
> +
> +#define DSS_SYSCONFIG0x10
> +#define DSS_SYSSTATUS0x14
> +#define DSS_CONTROL 0x40
> +#define DSS_SDI_CONTROL 0x44
> +#define DSS_PLL_CONTROL 0x48
> +
> +#define LCD_EN_MASK (0x1 << 0)
> +#define DIGIT_EN_MASK(0x1 << 1)
> +
> +#define FRAMEDONE_IRQ_SHIFT 0
> +#define EVSYNC_EVEN_IRQ_SHIFT2
> +#define EVSYNC_ODD_IRQ_SHIFT 3
> +#define FRAMEDONE2_IRQ_SHIFT 22
> +#define FRAMEDONETV_IRQ_SHIFT24
> +
> static struct platform_device omap_display_device = {
> .name = "omapdss",
> .id= -1,
> @@ -182,6 +206,78 @@ int __init omap_display_init(struct omap_dss_board_info
> *board_data)
> return r;
> }
>
> +static void dispc_disable_outputs(void)
> +{
> + u32 val, irq_mask, base;
> + bool lcd_en, digit_en, lcd2_en = false;
> + int i, num_mgrs;
> +
> + if (cpu_is_omap44xx()) {
> + base = DISPC_BASE_OMAP4;
> + num_mgrs = 3;
> + } else {
> + base = DISPC_BASE_OMAP2;
> + num_mgrs = 2;
> + }
base should not be needed here. The num_mgrs should come from the hwmod
data. We're trying to get rid of cpu_is_omap*() functions wherever
possible.
> +
> + /* store value of LCDENABLE and DIGITENABLE bits */
> + val = omap_readl(DISPC_REG(base, DISPC_CONTROL));
omap_{read,write}l() are deprecated and should no longer be used. This
code can use omap_hwmod_{read,write}() instead. You can pass the struct
omap_hwmod * into this function from the caller.
> + lcd_en = val & LCD_EN_MASK;
> + digit_en = val & DIGIT_EN_MASK;
> +
> + /* store value of LCDENABLE for LCD2 */
> + if (num_mgrs > 2) {
> + val = omap_readl(DISPC_REG(base, DISPC_CONTROL2));
> + lcd2_en = val & LCD_EN_MASK;
> + }
> +
> + /*
> + * If any manager was enabled, we need to disable it before DSS clocks
> + * are disabled or DISPC module is reset
> + */
> + if (lcd_en || digit_en || lcd2_en) {
Rather than this massive if block, please test the inverse condition and
bail out early. This avoids unnecessary indentation levels that make code
harder to read.
> + irq_mask = (lcd_en ? 1 : 0) << FRAMEDONE_IRQ_SHIFT;
> +
> + if (cpu_is_omap44xx())
> + irq_mask |= (digit_en ? 1 : 0) << FRAMEDONETV_IRQ_SHIFT;
> + else
> + irq_mask |= (digit_en ? 1 : 0) << EVSYNC_EVEN_IRQ_SHIFT
> |
> + (digit_en ? 1 : 0) << EVSYNC_ODD_IRQ_SHIFT;
Rather than a cpu_is_omap*() test, the presence of a working FRAMEDONETV
interrupt bit should be passed through the hwmod data.
> +
> + irq_mask |= (lcd2_en ? 1 : 0) << FRAMEDONE2_IRQ_SHIFT;
> +
> + /*
> + * clear any previous FRAMEDONE, FRAMEDONETV, EVSYNC_EVEN/ODD
> + * or FRAME
Re: [PATCH 08/30] ARM: omap2+: fix building without i2c
Hello Arnd, On Sun, 2 Oct 2011, Arnd Bergmann wrote: > A trivial typo causes build breakage when I2C is disabled > and omap_i2c_reset is set to NULL on OMAP: > > omap_hwmod_44xx_data.c:2287:11: error: lvalue required as unary '&' operand > > Removing the '&' character solves this. > > Signed-off-by: Arnd Bergmann > Cc: Avinash.H.M > Cc: Paul Walmsley Nice catch. I think the bug is different, though. omap_i2c_reset should never be NULL: that code is intended to execute even when CONFIG_I2C_OMAP=n. The idea is to prevent the IP block from interfering with the rest of the kernel even if the driver is not compiled in, no matter how the bootloader or previous OS programmed the IP block. I'd suggest something like the following patch instead. - Paul From: Paul Walmsley Date: Sun, 2 Oct 2011 19:15:10 -0600 Subject: [PATCH] ARM: omap2+: fix build breakage when CONFIG_I2C_OMAP=n arch/arm/mach-omap2/Makefile incorrectly skips compilation of the I2C IP block reset code when CONFIG_I2C_OMAP=n. Fix by unconditionally compiling arch/arm/mach-omap2/i2c.o, which is needed on all OMAP2+ platforms. Problem noted by Arnd Bergmann . Signed-off-by: Paul Walmsley Cc: Avinash.H.M Cc: Arnd Bergmann Cc: Tony Lindgren --- arch/arm/mach-omap2/Makefile |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index f343365..0951986 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -4,7 +4,7 @@ # Common support obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \ -common.o gpio.o dma.o wd_timer.o +common.o gpio.o dma.o wd_timer.o i2c.o omap-2-3-common= irq.o sdrc.o hwmod-common = omap_hwmod.o \ @@ -175,9 +175,6 @@ obj-$(CONFIG_OMAP_IOMMU)+= iommu2.o iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o obj-y += $(iommu-m) $(iommu-y) -i2c-omap-$(CONFIG_I2C_OMAP):= i2c.o -obj-y += $(i2c-omap-m) $(i2c-omap-y) - ifneq ($(CONFIG_TIDSPBRIDGE),) obj-y += dsp.o endif -- 1.7.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
Hi, On Sun, Oct 02, 2011 at 09:44:26PM +0200, Arnd Bergmann wrote: > > that's how MUSB works now and that's what I have been discussing with > > Alan Stern for the past month or so, wrt to *HCI. There are even patches > > floating on linux-usb right now trying to hash out the problems. > > Ah, glad to see that is happening. I can probably get rid of a bunch > of randconfig patches I have for those then. glad to hear you're sorting out randconfig :-) > > Maybe you should have consulted the maintainers of those drivers before > > making such statements. > > > > MUSB is not the best example because of its history. I understand the > > DMA part is still really messy, but we have been working very hard to > > hash the problems and still allow new glue layers to be merged. > > Sorry if I have made my statement sound like an accusation, it wasn't > meant as one, merely as a sigh at having identified yet another area > that needs to be changed in order to have cross-platform ARM kernels > working in every case. no big deal ;-) > > How about taking a sneak pick at what the code does right now ? As of > > today, I can even even have all UDC controller drivers into one kernel > > and I generally compile x86 with all controllers available. There's some > > very small work that has to be done on each of the UDC drivers to remove > > any references to and headers but that work > > in in progress. > > I didn't really see any problems with UDC at all. What I saw were a lot > of build problems with the musb host side, and I rewrote this patch half > a dozen times before I ended up with a version that consistently built > without making the code look worse. I understand. > I also agree that the musb implementation is less of a problem than > ohci/ehci in its current form, as it already is layered in the right > way. I did not attempt to turn the Kconfig 'choice' statement there > into a flat list though, so I wouldn't know what problems to expect. Actually, MUSB still has lots of goofage from the original mentor release but that's another story. Anyway, I'll take your patches in, but their too late for this merge window :-( I already sent my last pull to Greg. -- balbi signature.asc Description: Digital signature
[PATCH] omap-serial: add RS485 mode support
Add support for asserting RTS line while TX is in progress. OMAP
hardware doesn't support auto-RS485 mode so we control the line from
software. We use TX_EMPTY_CTL_IT bit in SCR register to generate TX
empty interrupt.
We use SER_RS485_RTS_ON_SEND flag to control the polarity of RTS signal
(RTS is asserted high during transmition if this flag is set and low
otherwise) though I'm not sure if this is what this flag is for...
Signed-off-by: Ilya Yanok
---
arch/arm/plat-omap/include/plat/omap-serial.h |3 +
drivers/tty/serial/omap-serial.c | 127 ++---
include/linux/serial_reg.h|2 +
3 files changed, 120 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 2682043..5003400 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -111,6 +111,9 @@ struct uart_omap_port {
unsigned char msr_saved_flags;
charname[20];
unsigned long port_activity;
+ struct serial_rs485 rs485;
+ unsigned inttx_in_progress:1,
+ tx_wait_end:1;
};
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 47cadf4..6526171 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -37,11 +37,14 @@
#include
#include
#include
+#include
#include
#include
#include
+#define OMAP_RS485_SUPPORTED (SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND)
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
@@ -114,6 +117,45 @@ static void serial_omap_enable_ms(struct uart_port *port)
serial_out(up, UART_IER, up->ier);
}
+static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
+{
+ if (!(up->ier & UART_IER_THRI)) {
+ up->ier |= UART_IER_THRI;
+ serial_out(up, UART_IER, up->ier);
+ }
+}
+
+static inline void serial_omap_disable_ier_thri(struct uart_omap_port *up)
+{
+ if (up->ier & UART_IER_THRI) {
+ up->ier &= ~UART_IER_THRI;
+ serial_out(up, UART_IER, up->ier);
+ }
+}
+
+static inline void serial_omap_thri_mode(struct uart_omap_port *up)
+{
+ unsigned char scr = serial_in(up, UART_OMAP_SCR);
+
+ if (up->tx_wait_end)
+ scr |= UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+ else
+ scr &= ~UART_OMAP_SCR_TX_EMPTY_CTL_IT;
+ serial_out(up, UART_OMAP_SCR, scr);
+}
+
+static inline void serial_omap_update_rts(struct uart_omap_port *up)
+{
+ unsigned char mcr = up->mcr;
+ int rts_on_send = up->rs485.flags & SER_RS485_RTS_ON_SEND;
+
+ if ((up->rs485.flags & SER_RS485_ENABLED) &&
+ ((up->tx_in_progress && rts_on_send) ||
+!(up->tx_in_progress || rts_on_send)))
+ mcr |= UART_MCR_RTS;
+ serial_out(up, UART_MCR, mcr);
+}
+
static void serial_omap_stop_tx(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -131,10 +173,14 @@ static void serial_omap_stop_tx(struct uart_port *port)
up->uart_dma.tx_dma_channel = OMAP_UART_DMA_CH_FREE;
}
- if (up->ier & UART_IER_THRI) {
- up->ier &= ~UART_IER_THRI;
- serial_out(up, UART_IER, up->ier);
+ if (!(up->rs485.flags & SER_RS485_ENABLED)) {
+ serial_omap_disable_ier_thri(up);
+ return;
}
+
+ up->tx_wait_end = 1;
+ serial_omap_thri_mode(up);
+ serial_omap_enable_ier_thri(up);
}
static void serial_omap_stop_rx(struct uart_port *port)
@@ -246,14 +292,6 @@ static void transmit_chars(struct uart_omap_port *up)
serial_omap_stop_tx(&up->port);
}
-static inline void serial_omap_enable_ier_thri(struct uart_omap_port *up)
-{
- if (!(up->ier & UART_IER_THRI)) {
- up->ier |= UART_IER_THRI;
- serial_out(up, UART_IER, up->ier);
- }
-}
-
static void serial_omap_start_tx(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
@@ -261,6 +299,18 @@ static void serial_omap_start_tx(struct uart_port *port)
unsigned int start;
int ret = 0;
+ if (up->rs485.flags & SER_RS485_ENABLED) {
+ if (!up->tx_in_progress) {
+ up->tx_in_progress = 1;
+ serial_omap_update_rts(up);
+ }
+ if (up->tx_wait_end) {
+ up->tx_wait_end = 0;
+ serial_omap_thri_mode(up);
+ serial_omap_disable_ier_thri(up);
+ }
+ }
+
if (!up->use_dma) {
serial_omap_enable_ier_thri(up);
retur
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
On Sunday 02 October 2011 21:56:09 Felipe Balbi wrote: > > > Unfortunately, even with the dma parts out of the way there is > > a lot that needs to be done to make musb, ehci or ohci > > really cross-platform. Right now, you can only have one > > platform driver glue for each of those drivers, and they > > that's not true for musb. I can already compile am35x and omap2430 > together. TUSB is a different story though. With a small effort, we > could also allow DaVinci and the like to compile cleanly and work. Ok, good. > > should eventually be converted to a large library module for > > the core, with independent platform driver front-end, similar > > that's how MUSB works now and that's what I have been discussing with > Alan Stern for the past month or so, wrt to *HCI. There are even patches > floating on linux-usb right now trying to hash out the problems. Ah, glad to see that is happening. I can probably get rid of a bunch of randconfig patches I have for those then. > Maybe you should have consulted the maintainers of those drivers before > making such statements. > > MUSB is not the best example because of its history. I understand the > DMA part is still really messy, but we have been working very hard to > hash the problems and still allow new glue layers to be merged. Sorry if I have made my statement sound like an accusation, it wasn't meant as one, merely as a sigh at having identified yet another area that needs to be changed in order to have cross-platform ARM kernels working in every case. > How about taking a sneak pick at what the code does right now ? As of > today, I can even even have all UDC controller drivers into one kernel > and I generally compile x86 with all controllers available. There's some > very small work that has to be done on each of the UDC drivers to remove > any references to and headers but that work > in in progress. I didn't really see any problems with UDC at all. What I saw were a lot of build problems with the musb host side, and I rewrote this patch half a dozen times before I ended up with a version that consistently built without making the code look worse. I also agree that the musb implementation is less of a problem than ohci/ehci in its current form, as it already is layered in the right way. I did not attempt to turn the Kconfig 'choice' statement there into a flat list though, so I wouldn't know what problems to expect. Arnd -- To unsubscribe from this list: send the line "unsubscribe 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 01/30] sound/omap: omap_mcpdm_remove cannot be __devexit
On Sun, Oct 02, 2011 at 04:45:31PM +0200, Arnd Bergmann wrote: > omap_mcpdm_remove is used from asoc_mcpdm_probe, which is an > initcall, and must not be discarded when HOTPLUG is disabled. > > Signed-off-by: Arnd Bergmann > Cc: Jarkko Nikula I've applied this, thanks. It'd be helpful if you could say if you're working on Linus' tree rather than -next, this one doesn't actually apply against -next as the driver has been totally rewritten. -- To unsubscribe from this list: send the line "unsubscribe 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 21/30] sound/soc/omap: limit to omap2plus
On Sun, Oct 02, 2011 at 04:45:51PM +0200, Arnd Bergmann wrote: > These drivers do not build correctly on omap1, so only allow > selecting them on omap2 or higher. No, OMAP1 is supposed to work and people actively seem to care about it. If there's some problem with OMAP1 then please report it so that it can be fixed. You should also *always* both CC maintainers and relevant mailing lists on patches so they can see what's going on (I'm being especially grumpy now because you really should know better), and my previous comments about subject lines also apply. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Please Response
My names are Abda Hassan Mohammed a wife to one of Gadaffi closet enemy. I have something important I want to discuss with you but first I want to know if your E-mail is Valid. Contact me on my personal E-mail: abda.has...@hotmail.com This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. -- To unsubscribe from this list: send the line "unsubscribe 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 16/30] usb/musb: HDRC depends on TWL4030_CORE for OMAP3/4
Hi, On Sun, Oct 02, 2011 at 04:45:46PM +0200, Arnd Bergmann wrote: > The musb_hdrc driver tries to select TWL4030_USB or TWL6030_USB > on some platforms, but those symbols in turn depend on TWL4030_CORE. the very fact that MUSB tries to select those is wrong. That's also some buggy legacy crap which is still floating around... MUSB does not depend on TWL4030. MUSB depends on a PHY being available, no matter which one. IMHO, this would be better moved to board definition, ideally with an option for selecting some symbol as module (as I have suggested before). Ideally, all those broken dependencies on MUSB would be cut down to depends on USB && USB_GADGET. -- balbi signature.asc Description: Digital signature
Re: [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
Hi, On Sun, Oct 02, 2011 at 08:00:31PM +0200, Arnd Bergmann wrote: > On Sunday 02 October 2011 17:14:47 Russell King - ARM Linux wrote: > > On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote: > > > The logic to allow only one DMA driver in MUSB is currently > > > flawed, because it also allows picking no DMA driver at all > > > and also not selecting PIO mode. > > > > > > Using a choice statement makes this foolproof for now and > > > also simplifies the Makefile. > > > > > > Unfortunately, we will have to revisit this when we start > > > supporting multiple ARM platforms in a single kernel binary, > > > because at that point we will actually need to select > > > multiple DMA drivers and pick the right one at run-time. > > > > I thought there was some work going on to convert this to use the > > dmaengine stuff? > > That would certainly be the best solution here, I wasn't aware > that it has already been discussed. > > Unfortunately, even with the dma parts out of the way there is > a lot that needs to be done to make musb, ehci or ohci > really cross-platform. Right now, you can only have one > platform driver glue for each of those drivers, and they that's not true for musb. I can already compile am35x and omap2430 together. TUSB is a different story though. With a small effort, we could also allow DaVinci and the like to compile cleanly and work. > should eventually be converted to a large library module for > the core, with independent platform driver front-end, similar that's how MUSB works now and that's what I have been discussing with Alan Stern for the past month or so, wrt to *HCI. There are even patches floating on linux-usb right now trying to hash out the problems. Maybe you should have consulted the maintainers of those drivers before making such statements. MUSB is not the best example because of its history. I understand the DMA part is still really messy, but we have been working very hard to hash the problems and still allow new glue layers to be merged. How about taking a sneak pick at what the code does right now ? As of today, I can even even have *all* UDC controller drivers into one kernel and I generally compile x86 with all controllers available. There's some very small work that has to be done on each of the UDC drivers to remove any references to and headers but that work in in progress. Also, when sending USB patches, be sure to Cc linux-usb@vger where most of the discussion is happening. -- balbi signature.asc Description: Digital signature
Re: [PATCH 11/30] ARM: omap2/n8x0: work around modular omap mmc
On Sunday 02 October 2011 16:53:31 Russell King - ARM Linux wrote: > On Sun, Oct 02, 2011 at 04:45:41PM +0200, Arnd Bergmann wrote: > > -#if defined(CONFIG_MENELAUS) && > > \ > > - (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)) > > +#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP) > > +/* || defined(CONFIG_MMC_OMAP_MODULE)) */ > > +/* FIXME: cannot call omap_mmc_notify_cover_event for > > ONFIG_MMC_OMAP_MODULE */ > > #ifdef CONFIG_MMC_OMAP_MODULE > #warning FIXME: cannot call omap_mmc_notify_cover_event for > CONFIG_MMC_OMAP_MODULE > #endif > #if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP) > > So that it can be seen at build time? > > Also note the 'ONFIG' typo... Ok, good idea. I've updated the patch in the git tree accordingly. Depending on what Tony wants, I might send out the entire series again once there are no more new comments. Arnd -- To unsubscribe from this list: send the line "unsubscribe 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 1/5] ARM: dev_archdata: add private iommu extension
On Tue, Sep 27, 2011 at 4:30 AM, Grant Likely wrote: > Blech. Oh well. Not much point in doing something different if x86 > uses a void*. x86 probably does this because two different implementations needs to plug their private data there: intel-iommu plugs there a 'struct device_domain_info *' and amd_iommu uses it with a 'struct iommu_dev_data *'. On ARM we'd eventually end up with even a bigger variety, and I guess that even if we'd use a type-safe member here, it would itself end up having 'void *'. If it looks reasonable to you, can I please have your Ack ? Russell, can you please take a look too and ack/nack ? Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe 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 21/30] sound/soc/omap: limit to omap2plus
On Sunday 02 October 2011 21:24:26 Jarkko Nikula wrote: > Now when I remember we had one build error. Hopefully it was the same > than you observed? I think it was something different, but it's possible. Arnd -- To unsubscribe from this list: send the line "unsubscribe 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 21/30] sound/soc/omap: limit to omap2plus
On Sun, 02 Oct 2011 20:03:38 +0200
Arnd Bergmann wrote:
> On Sunday 02 October 2011 20:40:35 Jarkko Nikula wrote:
> > Strange. I'm able to build them fine with omap1_defconfig and with two
> > supported OMAP1 ASoC machine drivers we have:
> >
> > CONFIG_SND_OMAP_SOC_AMS_DELTA=y
> > CONFIG_SND_OMAP_SOC_OSK5912=y
> >
> > What's the error you are seeing? I guess there might be some missing
> > dependency that doesn't get visible with omap1_defconfig.
> >
> > I would like to get that fixed instead of disabling OMAP1 ASoC support
> > as the ams-delta in kernel is alive device thanks to active developer
> > Janusz Krzysztofik .
>
> I no longer have the original bug, maybe it was a false positive.
> I'll drop this patch and have another look if the problem comes back.
>
> Thanks for taking a closer look!
>
Now when I remember we had one build error. Hopefully it was the same
than you observed?
commit e574044acbad7421879270a80acd337459c94cc8
Author: Jarkko Nikula
Date: Thu Aug 18 15:02:47 2011 +0300
ASoC: omap: Fix build errors in ams-delta
Fix "error: too few arguments to function 'ams_delta_set_bias_level'"
build errors in ams-delta.c that were introduced after commit d4c6005 ("ASoC
Add context parameter to card DAPM callbacks") by adding dapm context
to ams_delta_set_bias_level calls.
--
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe 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 10/30] ARM: omap/iommu: always provide iommu debug code
On Sun, Oct 2, 2011 at 8:01 PM, Arnd Bergmann wrote: > Yes, please take it into the iommu tree, so I don't have to track > the conflict. Sure thing. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe 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 21/30] sound/soc/omap: limit to omap2plus
On Sunday 02 October 2011 20:40:35 Jarkko Nikula wrote: > Strange. I'm able to build them fine with omap1_defconfig and with two > supported OMAP1 ASoC machine drivers we have: > > CONFIG_SND_OMAP_SOC_AMS_DELTA=y > CONFIG_SND_OMAP_SOC_OSK5912=y > > What's the error you are seeing? I guess there might be some missing > dependency that doesn't get visible with omap1_defconfig. > > I would like to get that fixed instead of disabling OMAP1 ASoC support > as the ams-delta in kernel is alive device thanks to active developer > Janusz Krzysztofik . I no longer have the original bug, maybe it was a false positive. I'll drop this patch and have another look if the problem comes back. Thanks for taking a closer look! Arnd -- To unsubscribe from this list: send the line "unsubscribe 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 10/30] ARM: omap/iommu: always provide iommu debug code
On Sunday 02 October 2011 18:34:52 Ohad Ben-Cohen wrote: > > The driver has moved to drivers/iommu/ and changed a bit, but this > patch is still relevant. > > The merge conflict will be trivial to resolve, but if you prefer, we > can prevent it by taking this patch via the iommu tree. Yes, please take it into the iommu tree, so I don't have to track the conflict. Thanks, Arnd -- To unsubscribe from this list: send the line "unsubscribe 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 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
On Sunday 02 October 2011 17:14:47 Russell King - ARM Linux wrote: > On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote: > > The logic to allow only one DMA driver in MUSB is currently > > flawed, because it also allows picking no DMA driver at all > > and also not selecting PIO mode. > > > > Using a choice statement makes this foolproof for now and > > also simplifies the Makefile. > > > > Unfortunately, we will have to revisit this when we start > > supporting multiple ARM platforms in a single kernel binary, > > because at that point we will actually need to select > > multiple DMA drivers and pick the right one at run-time. > > I thought there was some work going on to convert this to use the > dmaengine stuff? That would certainly be the best solution here, I wasn't aware that it has already been discussed. Unfortunately, even with the dma parts out of the way there is a lot that needs to be done to make musb, ehci or ohci really cross-platform. Right now, you can only have one platform driver glue for each of those drivers, and they should eventually be converted to a large library module for the core, with independent platform driver front-end, similar to the recent conversion of the sdhci driver by Shawn Guo, and the way that a lot of the other common drivers work. Arnd -- To unsubscribe from this list: send the line "unsubscribe 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 21/30] sound/soc/omap: limit to omap2plus
On Sun, 2 Oct 2011 16:45:51 +0200 Arnd Bergmann wrote: > These drivers do not build correctly on omap1, so only allow > selecting them on omap2 or higher. > > Signed-off-by: Arnd Bergmann > Cc: Jarkko Nikula > Cc: Liam Girdwood > --- Strange. I'm able to build them fine with omap1_defconfig and with two supported OMAP1 ASoC machine drivers we have: CONFIG_SND_OMAP_SOC_AMS_DELTA=y CONFIG_SND_OMAP_SOC_OSK5912=y What's the error you are seeing? I guess there might be some missing dependency that doesn't get visible with omap1_defconfig. I would like to get that fixed instead of disabling OMAP1 ASoC support as the ams-delta in kernel is alive device thanks to active developer Janusz Krzysztofik . -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe 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 10/30] ARM: omap/iommu: always provide iommu debug code
On Sun, Oct 2, 2011 at 4:45 PM, Arnd Bergmann wrote: > The iommu module on omap contains a few functions that are > only used by the debug module. These are however only there > when the debug code is built as a module. Since it is possible > to build the debug code into the kernel, the functions should > also be provided for the built-in case. > > Signed-off-by: Arnd Bergmann > --- > arch/arm/plat-omap/iommu.c | 2 +- Thanks, Arnd. The driver has moved to drivers/iommu/ and changed a bit, but this patch is still relevant. The merge conflict will be trivial to resolve, but if you prefer, we can prevent it by taking this patch via the iommu tree. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe 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 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote: > The logic to allow only one DMA driver in MUSB is currently > flawed, because it also allows picking no DMA driver at all > and also not selecting PIO mode. > > Using a choice statement makes this foolproof for now and > also simplifies the Makefile. > > Unfortunately, we will have to revisit this when we start > supporting multiple ARM platforms in a single kernel binary, > because at that point we will actually need to select > multiple DMA drivers and pick the right one at run-time. I thought there was some work going on to convert this to use the dmaengine stuff? But in any case, a stop-gap fix is needed for randconfig. -- To unsubscribe from this list: send the line "unsubscribe 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 04/30] ARM: omap: add missing __devexit_p() annotations
On Sun, Oct 02, 2011 at 05:56:07PM +0200, Bjarne Steinsbo wrote: > Arnd, > > Ref http://www.spinics.net/lists/linux-omap/msg57274.html > > Don't get me wrong. This is not about you "stealing" my patch, or > anything like that. But look also at thread starting at > http://www.spinics.net/lists/linux-omap/msg57667.html Also a patch > that I have posted previously. Something is not right with the > workflow when bugs are identified, patches are submitted, then > ignored, only for someone else to fix the same bug. Enough said. That is where re-sending is important. Don't throw patches over the wall and then forget them - that's precisely how this happens. Consider who has the higher workload, and who ends up dealing with many many many emails, and realise that the options for those of us who receive patches are either to drop patches, or have an endlessly growing backlog of patches when things get busy. Unless we drop patches, things can get pretty rediculous - consider the effect of a backlog of one month worth of patches would cause... -- To unsubscribe from this list: send the line "unsubscribe 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 v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
(sorry for the late response; we had a big holiday here and I was forced away from my keyboard :) On Tue, Sep 27, 2011 at 9:14 PM, Roedel, Joerg wrote: > No. I suggest a simpler and shorter algorithm using the bit helpers. Ok, fair enough. I've revised the patches and attached the main one below; please tell me if it looks ok, and then I'll resubmit the entire patch set. The main changes I've done from your pseudo-code are: 1. removed the internal while loop, and used several bits manipulations to replace it 2. removed the call to get_order(), and instead used the bytes order we already have to deduct it 3. considered iova alignment requirements too 4. removed the BUG_ON()s, since we're checking for minimal size/alignment conditions in the beginning of the map function > And yes, overhead is important when we implement the generic dma-ops > on-top of the iommu-api because this will make the iommu_map function a > fast-path. So we really care about overhead here. Don't get me wrong; I don't underestimate the importance of performance here. I just think that as long as some code is reasonably efficient and not badly designed (so it's not too hard to optimize later if needed), then it's usually better to postpone optimizations until we benchmark and know for certain that the effort in squeezing away several cpu cycles is noticeable. In this case, I'm not entirely convinced that it is, because every map call anyway ends up flushing the caches, which might take hundreds of cpu cycles. In addition, at least the ARM version of find_next_bit doesn't look terribly bad. YMMV though: I didn't find an optimized assembly implementation of find_next_bit for x86, and the generic one does look complex. In addition, the variable page size behavior of the x86 iommu drivers may have caused much more iterations than any of the ARM drivers would have had, so the penalty of running that generic find_next_bit repeatedly could have accumulated into something noticeable. Anyway, here comes the revised patch. Thanks for your review! Ohad. >From 042690394b1a121202e0eeeb47d267b1a8d65132 Mon Sep 17 00:00:00 2001 From: Ohad Ben-Cohen Date: Wed, 31 Aug 2011 16:46:47 +0300 Subject: [PATCH 2/7] iommu/core: split mapping to page sizes as supported by the hardware When mapping a memory region, split it to page sizes as supported by the iommu hardware. Always prefer bigger pages, when possible, in order to reduce the TLB pressure. The logic to do that is now added to the IOMMU core, so neither the iommu drivers themselves nor users of the IOMMU API have to duplicate it. This allows a more lenient granularity of mappings; traditionally the IOMMU API took 'order' (of a page) as a mapping size, and directly let the low level iommu drivers handle the mapping, but now that the IOMMU core can split arbitrary memory regions into pages, we can remove this limitation, so users don't have to split those regions by themselves. Currently the supported page sizes are advertised once and they then remain static. That works well for OMAP and MSM but it would probably not fly well with intel's hardware, where the page size capabilities seem to have the potential to be different between several DMA remapping devices. As requested, register_iommu() isn't changed yet, so we can convert the IOMMU drivers in subsequent patches, and after all the drivers are converted, register_iommu will be changed (and the temporary register_iommu_pgsize() will be removed). Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted to send the mapping size in bytes instead of in page order. Signed-off-by: Ohad Ben-Cohen Cc: David Brown Cc: David Woodhouse Cc: Joerg Roedel Cc: Stepan Moskovchenko Cc: Hiroshi DOYU Cc: Laurent Pinchart Cc: k...@vger.kernel.org --- drivers/iommu/iommu.c | 138 --- drivers/iommu/omap-iovmm.c | 12 +--- include/linux/iommu.h |6 +- virt/kvm/iommu.c |4 +- 4 files changed, 137 insertions(+), 23 deletions(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index a7b0862..f23563f 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -16,6 +16,8 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#define pr_fmt(fmt)"%s: " fmt, __func__ + #include #include #include @@ -23,15 +25,54 @@ #include #include #include +#include static struct iommu_ops *iommu_ops; +/* bitmap of supported page sizes */ +static unsigned long iommu_pgsize_bitmap; + +/* size of the smallest supported page (in bytes) */ +static unsigned int iommu_min_pagesz; + +/** + * register_iommu() - register an IOMMU hardware + * @ops: iommu handlers + * @pgsize_bitmap: bitmap of page sizes supported by the hardware + * + * Note: this is a temporary function, which will be removed once + * all IOMMU drivers are converted. The only reason it exists is to + * allow splitting the pgsizes changes to several patches in o
Re: [PATCH 04/30] ARM: omap: add missing __devexit_p() annotations
Arnd,
Ref http://www.spinics.net/lists/linux-omap/msg57274.html
Don't get me wrong. This is not about you "stealing" my patch, or
anything like that. But look also at thread starting at
http://www.spinics.net/lists/linux-omap/msg57667.html Also a patch
that I have posted previously. Something is not right with the
workflow when bugs are identified, patches are submitted, then
ignored, only for someone else to fix the same bug. Enough said.
Best regards,
Bjarne Steinsbo
On Sun, Oct 2, 2011 at 4:45 PM, Arnd Bergmann wrote:
> Drivers that refer to a __devexit function in an operations
> structure need to annotate that pointer with __devexit_p so
> replace it with a NULL pointer when the section gets discarded.
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/mach-omap2/smartreflex.c | 2 +-
> arch/arm/plat-omap/dma.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c
> b/arch/arm/mach-omap2/smartreflex.c
> index 34c01a7..67bc6ce 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -1002,7 +1002,7 @@ static int __devexit omap_sr_remove(struct
> platform_device *pdev)
> }
>
> static struct platform_driver smartreflex_driver = {
> - .remove = omap_sr_remove,
> + .remove = __devexit_p(omap_sr_remove),
> .driver = {
> .name = "smartreflex",
> },
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index c22217c..f7150ba 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -2105,7 +2105,7 @@ static int __devexit omap_system_dma_remove(struct
> platform_device *pdev)
>
> static struct platform_driver omap_system_dma_driver = {
> .probe = omap_system_dma_probe,
> - .remove = omap_system_dma_remove,
> + .remove = __devexit_p(omap_system_dma_remove),
> .driver = {
> .name = "omap_dma_system"
> },
> --
> 1.7.5.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
>
--
To unsubscribe from this list: send the line "unsubscribe 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 11/30] ARM: omap2/n8x0: work around modular omap mmc
On Sun, Oct 02, 2011 at 04:45:41PM +0200, Arnd Bergmann wrote: > -#if defined(CONFIG_MENELAUS) && > \ > - (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)) > +#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP) > +/* || defined(CONFIG_MMC_OMAP_MODULE)) */ > +/* FIXME: cannot call omap_mmc_notify_cover_event for ONFIG_MMC_OMAP_MODULE > */ #ifdef CONFIG_MMC_OMAP_MODULE #warning FIXME: cannot call omap_mmc_notify_cover_event for CONFIG_MMC_OMAP_MODULE #endif #if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP) So that it can be seen at build time? Also note the 'ONFIG' typo... -- To unsubscribe from this list: send the line "unsubscribe 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 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
The logic to allow only one DMA driver in MUSB is currently flawed, because it also allows picking no DMA driver at all and also not selecting PIO mode. Using a choice statement makes this foolproof for now and also simplifies the Makefile. Unfortunately, we will have to revisit this when we start supporting multiple ARM platforms in a single kernel binary, because at that point we will actually need to select multiple DMA drivers and pick the right one at run-time. Signed-off-by: Arnd Bergmann Cc: Felipe Balbi --- drivers/usb/musb/Kconfig | 57 ++-- drivers/usb/musb/Makefile | 26 +++- 2 files changed, 38 insertions(+), 45 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index fc34b8b..d596fb2 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -64,46 +64,57 @@ config USB_MUSB_UX500 endchoice -config MUSB_PIO_ONLY - bool 'Disable DMA (always use PIO)' - depends on USB_MUSB_HDRC - default USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X +choice + prompt 'MUSB DMA mode' + default USB_UX500_DMA if USB_MUSB_UX500 + default USB_INVENTRA_DMA if USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN + default USB_TI_CPPI_DMA if USB_MUSB_DAVINCI + default USB_TUSB_OMAP_DMA if USB_MUSB_TUSB6010 + default MUSB_PIO_ONLY if USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X help - All data is copied between memory and FIFO by the CPU. - DMA controllers are ignored. - - Do not select 'n' here unless DMA support for your SOC or board - is unavailable (or unstable). When DMA is enabled at compile time, - you can still disable it at run time using the "use_dma=n" module - parameter. + Unfortunately, only one option can be enabled here. Ideally one + should be able to build all these drivers into one kernel to + allow using DMA on multiplatform kernels. config USB_UX500_DMA - bool - depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY - default USB_MUSB_UX500 + bool 'ST Ericsson U8500 and U5500' + depends on USB_MUSB_HDRC + depends on USB_MUSB_UX500 help Enable DMA transfers on UX500 platforms. config USB_INVENTRA_DMA - bool - depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY - default USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN + bool 'Inventra' + depends on USB_MUSB_HDRC + depends on USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN help Enable DMA transfers using Mentor's engine. config USB_TI_CPPI_DMA - bool - depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY - default USB_MUSB_DAVINCI + bool 'TI CPPI (Davinci)' + depends on USB_MUSB_HDRC + depends on USB_MUSB_DAVINCI help Enable DMA transfers when TI CPPI DMA is available. config USB_TUSB_OMAP_DMA - bool - depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY + bool 'TUSB 6010' + depends on USB_MUSB_HDRC depends on USB_MUSB_TUSB6010 depends on ARCH_OMAP - default y help Enable DMA transfers on TUSB 6010 when OMAP DMA is available. +config MUSB_PIO_ONLY + bool 'Disable DMA (always use PIO)' + depends on USB_MUSB_HDRC + help + All data is copied between memory and FIFO by the CPU. + DMA controllers are ignored. + + Do not choose this unless DMA support for your SOC or board + is unavailable (or unstable). When DMA is enabled at compile time, + you can still disable it at run time using the "use_dma=n" module + parameter. + +endchoice diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile index d8fd9d0..88bfb9d 100644 --- a/drivers/usb/musb/Makefile +++ b/drivers/usb/musb/Makefile @@ -24,25 +24,7 @@ obj-$(CONFIG_USB_MUSB_UX500) += ux500.o # PIO only, or DMA (several potential schemes). # though PIO is always there to back up DMA, and for ep0 -ifneq ($(CONFIG_MUSB_PIO_ONLY),y) - - ifeq ($(CONFIG_USB_INVENTRA_DMA),y) -musb_hdrc-y+= musbhsdma.o - - else -ifeq ($(CONFIG_USB_TI_CPPI_DMA),y) - musb_hdrc-y += cppi_dma.o - -else - ifeq ($(CONFIG_USB_TUSB_OMAP_DMA),y) - musb_hdrc-y += tusb6010_omap.o - - else -ifeq ($(CONFIG_USB_UX500_DMA),y) - musb_hdrc-y += ux500_dma.o - -endif - endif -endif - endif -endif +musb_hdrc-$(CONFIG_USB_INVENTRA_DMA) += musbhsdma.o +musb_hdrc-$(CONFIG_USB_TI_CPPI_DMA)+= cppi_dma.o +musb_hdrc-$(CONFIG_USB_TUSB_OMAP_DMA) += tusb6010_omap.o +musb_hdrc-$(CONFIG_USB_UX500_DMA) += ux500_dma.o -- 1.7.5.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 ht
[PATCH 22/30] mfd: build twl6030 only on omap2
We can only have one pwm driver built into the kernel, so make sure that this one is only available on omap2 to avoid conflicts with pwm drivers of other platforms. Signed-off-by: Arnd Bergmann Cc: Samuel Ortiz Cc: Peter Ujfalusi Cc: Balaji T K Cc: Hemanth V --- drivers/mfd/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 48cce35..26bebe8 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -256,8 +256,8 @@ config MFD_TWL4030_AUDIO default n config TWL6030_PWM - tristate "TWL6030 PWM (Pulse Width Modulator) Support" - depends on TWL4030_CORE + bool "TWL6030 PWM (Pulse Width Modulator) Support" + depends on TWL4030_CORE && ARCH_OMAP2 select HAVE_PWM default n help -- 1.7.5.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 12/30] ARM: omap4: always build omap_phy_internal
The functions defined in omap_phy_internal.c are requrired on omap4-only configurations, not just for specific boards. twl-common.c:(.init.text+0x6b40): undefined reference to `omap4430_phy_init' twl-common.c:(.init.text+0x6c68): undefined reference to `omap4430_phy_init' mach-omap2/built-in.o:(.data+0x154e0): undefined reference to `omap4430_phy_init' mach-omap2/built-in.o:(.data+0x154e4): undefined reference to `omap4430_phy_exit' Signed-off-by: Arnd Bergmann --- arch/arm/mach-omap2/Makefile |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index f343365..dc36bd4 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -242,12 +242,9 @@ obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \ obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o \ - hsmmc.o \ - omap_phy_internal.o + hsmmc.o obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o \ - hsmmc.o \ - omap_phy_internal.o - + hsmmc.o obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \ omap_phy_internal.o \ @@ -275,6 +272,7 @@ obj-y += $(smc91x-m) $(smc91x-y) smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o obj-y += $(smsc911x-m) $(smsc911x-y) obj-$(CONFIG_ARCH_OMAP4) += hwspinlock.o +obj-$(CONFIG_ARCH_OMAP4) += omap_phy_internal.o disp-$(CONFIG_OMAP2_DSS) := display.o obj-y += $(disp-m) $(disp-y) -- 1.7.5.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 24/30] ARM: omap2+: ensure that one of omap2/3/4 is selected
Random configurations can fail if none of the omap families in mach-omap2 is selected. This patch automatically selects omap2 if the user has not made any other choice. Signed-off-by: Arnd Bergmann --- arch/arm/mach-omap2/Kconfig | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 4deeade..3c9fb89 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -51,6 +51,16 @@ config ARCH_OMAP4 select PM_OPP if PM select USB_ARCH_HAS_EHCI +config ARCH_OMAP2_AUTO + bool + depends on !ARCH_OMAP3 && !ARCH_OMAP4 + select ARCH_OMAP2 + default y + help + At least one of OMAP2/OMAP3/OMAP4 needs to be enabled, this + selects OMAP2 if nothing else gets selected, to avoid non-building + configurations. + comment "OMAP Core Type" depends on ARCH_OMAP2 -- 1.7.5.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 11/30] ARM: omap2/n8x0: work around modular omap mmc
When the omap driver is built as a module for n8x0,
n8x0_mmc_set_power_menelaus cannot call into the driver:
arch/arm/mach-omap2/board-n8x0.c:374: undefined reference to
`omap_mmc_notify_cover_event'
As a workaround, do not provide that device in this case. This needs
to be fixed properly, e.g. by converting n8x0 to be probed through the
device tree and moving that code into the driver.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap2/board-n8x0.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index e11f0c5..403325d 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -193,8 +193,9 @@ static struct omap_onenand_platform_data
board_onenand_data[] = {
};
#endif
-#if defined(CONFIG_MENELAUS) &&
\
- (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE))
+#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
+/* || defined(CONFIG_MMC_OMAP_MODULE)) */
+/* FIXME: cannot call omap_mmc_notify_cover_event for ONFIG_MMC_OMAP_MODULE */
/*
* On both N800 and N810, only the first of the two MMC controllers is in use.
--
1.7.5.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 19/30] tty/serial/omap: console can only be built-in
When the omap serial driver is built as a module, we must not allow the console driver to be selected, because consoles can not be loadable modules. Signed-off-by: Arnd Bergmann Cc: Govindraj.R --- drivers/tty/serial/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 4dcb37bb..eb04b2f 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1346,7 +1346,7 @@ config SERIAL_OMAP config SERIAL_OMAP_CONSOLE bool "Console on OMAP serial port" - depends on SERIAL_OMAP + depends on SERIAL_OMAP=y select SERIAL_CORE_CONSOLE help Select this option if you would like to use omap serial port as -- 1.7.5.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 03/30] video/omap: fix build dependencies
Four of the LCD panel drivers depend on the backlight class, so add the dependency in Kconfig. Selecting the BACKLIGHT_CLASS_DEVICE symbol does not generally work since it has other dependencies. Signed-off-by: Arnd Bergmann Cc: Tomi Valkeinen --- drivers/video/omap2/displays/Kconfig |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig index 609a280..8e4278c 100644 --- a/drivers/video/omap2/displays/Kconfig +++ b/drivers/video/omap2/displays/Kconfig @@ -19,13 +19,15 @@ config PANEL_LGPHILIPS_LB035Q02 config PANEL_SHARP_LS037V7DW01 tristate "Sharp LS037V7DW01 LCD Panel" depends on OMAP2_DSS_DPI -select BACKLIGHT_CLASS_DEVICE +depends on BACKLIGHT_CLASS_DEVICE help LCD Panel used in TI's SDP3430 and EVM boards config PANEL_NEC_NL8048HL11_01B tristate "NEC NL8048HL11-01B Panel" depends on OMAP2_DSS_DPI + depends on SPI + depends on BACKLIGHT_CLASS_DEVICE help This NEC NL8048HL11-01B panel is TFT LCD used in the Zoom2/3/3630 sdp boards. @@ -33,6 +35,7 @@ config PANEL_NEC_NL8048HL11_01B config PANEL_TAAL tristate "Taal DSI Panel" depends on OMAP2_DSS_DSI +depends on BACKLIGHT_CLASS_DEVICE help Taal DSI command mode panel from TPO. @@ -45,7 +48,7 @@ config PANEL_TPO_TD043MTEA1 config PANEL_ACX565AKM tristate "ACX565AKM Panel" depends on OMAP2_DSS_SDI && SPI - select BACKLIGHT_CLASS_DEVICE + depends on BACKLIGHT_CLASS_DEVICE help This is the LCD panel used on Nokia N900 endmenu -- 1.7.5.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 09/30] ARM: omap2: export functions used by nand driver
The omap nand driver uses the gpmc_enable_hwecc and gpmc_calculate_ecc functions from the platform code, but can be built as a module. This only works if the functions are exported. Signed-off-by: Arnd Bergmann --- arch/arm/mach-omap2/gpmc.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 130034b..4ed6880 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -882,6 +882,7 @@ int gpmc_enable_hwecc(int cs, int mode, int dev_width, int ecc_size) gpmc_write_reg(GPMC_ECC_CONFIG, val); return 0; } +EXPORT_SYMBOL_GPL(gpmc_enable_hwecc); /** * gpmc_calculate_ecc - generate non-inverted ecc bytes @@ -912,3 +913,4 @@ int gpmc_calculate_ecc(int cs, const u_char *dat, u_char *ecc_code) gpmc_ecc_used = -EINVAL; return 0; } +EXPORT_SYMBOL_GPL(gpmc_calculate_ecc); -- 1.7.5.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 00/30] ARM/omap: omap specific randconfig fixes
Hi Tony, I've mentioned these patches before, and now I've managed to go through them again and clean them enough for submission. If nobody has any objections, I would like to send them to Linus in the coming merge window, otherwise it would be nice if you could pick the ones that look good to you and send me a pull request. If any of these look like they should be backported to stable kernels, please tell me and I'll add a cc:stable@k.o tag. The entire set is also available from git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/omap but I have not yet pulled them into the for-next branch. Arnd Arnd Bergmann (30): sound/omap: omap_mcpdm_remove cannot be __devexit video/omap: fix dependencies video/omap: fix build dependencies ARM: omap: add missing __devexit_p() annotations ARM: omap: enable building omap2 without omap2420/2430 ARM: omap: fix build with CONFIG_I2C_OMAP disabled ARM: omap: fix visibility of omap2_mbox_iva_priv ARM: omap2+: fix building without i2c ARM: omap2: export functions used by nand driver ARM: omap/iommu: always provide iommu debug code ARM: omap2/n8x0: work around modular omap mmc ARM: omap4: always build omap_phy_internal ARM: omap2+: fix omap_hdq_init compilation ARM: omap2: irq.c is always needed usb/musb: use a Kconfig choice to pick the right DMA method usb/musb: HDRC depends on TWL4030_CORE for OMAP3/4 usb/musb: allow building USB_MUSB_TUSB6010 as a module omap-usb: automatically select MFD_OMAP_USB_HOST tty/serial/omap: console can only be built-in media/omap_vout: disable driver for now sound/soc/omap: limit to omap2plus mfd: build twl6030 only on omap2 ARM: omap2: select twl4030 support on boards that need it ARM: omap2+: ensure that one of omap2/3/4 is selected ARM: OMAP depends on MMU ARM: omap: add board autoselection ARM: omap: select L2X0 cache on omap4 ARM: omap: select CPU_FREQ_TABLE where needed ARM: omap: select USB_ARCH_HAS_EHCI only when USB is enabled ARM: omap2: select ARM_AMBA for OMAP3_EMU arch/arm/Kconfig |1 + arch/arm/mach-omap2/Kconfig| 61 +- arch/arm/mach-omap2/Makefile | 12 ++--- arch/arm/mach-omap2/board-n8x0.c |7 ++- arch/arm/mach-omap2/devices.c | 10 +++-- arch/arm/mach-omap2/gpmc.c |2 + arch/arm/mach-omap2/mailbox.c |2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/mach-omap2/smartreflex.c |2 +- arch/arm/plat-omap/Kconfig |5 ++ arch/arm/plat-omap/dma.c |2 +- arch/arm/plat-omap/include/plat/i2c.h |6 +- arch/arm/plat-omap/include/plat/multi.h|5 ++ arch/arm/plat-omap/iommu.c |2 +- drivers/media/video/omap/Kconfig |1 + drivers/mfd/Kconfig|6 +- drivers/tty/serial/Kconfig |2 +- drivers/usb/musb/Kconfig | 58 +++-- drivers/usb/musb/Makefile | 26 ++-- drivers/usb/musb/musb_core.c |3 +- drivers/usb/musb/musb_io.h |2 +- drivers/usb/musb/tusb6010.c|1 + drivers/video/omap/Kconfig | 41 -- drivers/video/omap/Makefile| 64 +--- drivers/video/omap2/displays/Kconfig |7 ++- sound/soc/omap/Kconfig |2 +- sound/soc/omap/mcpdm.c |2 +- sound/soc/omap/mcpdm.h |2 +- 31 files changed, 221 insertions(+), 121 deletions(-) -- 1.7.5.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 06/30] ARM: omap: fix build with CONFIG_I2C_OMAP disabled
We must not reference omap_i2c_reset if the file defining it
does not get built.
Signed-off-by: Arnd Bergmann
---
arch/arm/plat-omap/include/plat/i2c.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/i2c.h
b/arch/arm/plat-omap/include/plat/i2c.h
index 7c22b9e..ae72013 100644
--- a/arch/arm/plat-omap/include/plat/i2c.h
+++ b/arch/arm/plat-omap/include/plat/i2c.h
@@ -28,6 +28,8 @@
extern int omap_register_i2c_bus(int bus_id, u32 clkrate,
struct i2c_board_info const *info,
unsigned len);
+struct omap_hwmod;
+int omap_i2c_reset(struct omap_hwmod *oh);
#else
static inline int omap_register_i2c_bus(int bus_id, u32 clkrate,
struct i2c_board_info const *info,
@@ -35,6 +37,7 @@ static inline int omap_register_i2c_bus(int bus_id, u32
clkrate,
{
return 0;
}
+#define omap_i2c_reset NULL
#endif
/**
@@ -53,7 +56,4 @@ struct omap_i2c_dev_attr {
void __init omap1_i2c_mux_pins(int bus_id);
void __init omap2_i2c_mux_pins(int bus_id);
-struct omap_hwmod;
-int omap_i2c_reset(struct omap_hwmod *oh);
-
#endif /* __ASM__ARCH_OMAP_I2C_H */
--
1.7.5.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 05/30] ARM: omap: enable building omap2 without omap2420/2430
Kconfig allows selecting CONFIG_OMAP2 but no specific SOC, the options being omap2420 and omap2430, but that leads to a build error when omap3 or omap4 are also enabled and the MULTI_OMAP2 symbol is undefined. This adds another clause to plat/multi.h, mainly to allow all possible randconfig combinations to build cleanly. Signed-off-by: Arnd Bergmann --- arch/arm/plat-omap/include/plat/multi.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/multi.h b/arch/arm/plat-omap/include/plat/multi.h index 999ffba..fb7f196 100644 --- a/arch/arm/plat-omap/include/plat/multi.h +++ b/arch/arm/plat-omap/include/plat/multi.h @@ -82,6 +82,11 @@ # define OMAP_NAME omap2430 # endif #endif +#ifdef CONFIG_ARCH_OMAP2 +# ifndef OMAP_NAME +# define OMAP_NAME omap2 +# endif +#endif #ifdef CONFIG_ARCH_OMAP3 # ifdef OMAP_NAME # undef MULTI_OMAP2 -- 1.7.5.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 29/30] ARM: omap: select USB_ARCH_HAS_EHCI only when USB is enabled
This avoids a warning from Kconfig about missing dependencies. Signed-off-by: Arnd Bergmann --- arch/arm/mach-omap2/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 3921a95..fdd45dd 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -32,7 +32,7 @@ config ARCH_OMAP3 depends on ARCH_OMAP2PLUS default y select CPU_V7 - select USB_ARCH_HAS_EHCI + select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4 select ARCH_HAS_OPP select PM_OPP if PM @@ -50,7 +50,7 @@ config ARCH_OMAP4 select CACHE_L2X0 select ARCH_HAS_OPP select PM_OPP if PM - select USB_ARCH_HAS_EHCI + select USB_ARCH_HAS_EHCI if USB_SUPPORT config ARCH_OMAP2_AUTO bool -- 1.7.5.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 26/30] ARM: omap: add board autoselection
At least one board file needs to be selected to successfully build a kernel, so this one adds logic to the omap Kconfig file to pick one default board file when all others are disabled. Since the available boards depend on the SoC family (omap2/3/4) being selected first, this adds one default for each family. Signed-off-by: Arnd Bergmann --- arch/arm/mach-omap2/Kconfig | 39 +++ 1 files changed, 39 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 3c9fb89..fd0ab18 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -120,6 +120,45 @@ config MACH_OMAP_GENERIC depends on ARCH_OMAP2 default y +config MACH_OMAP_AUTO_BOARD + def_bool y + depends on !MACH_OMAP2_TUSB6010 + depends on !MACH_OMAP_H4 + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_APOLLON + depends on !MACH_OMAP_2430SDP + depends on !MACH_OMAP3_BEAGLE + depends on !MACH_DEVKIT8000 + depends on !MACH_OMAP_LDP + depends on !MACH_OMAP3530_LV_SOM + depends on !MACH_OMAP3_TORPEDO + depends on !MACH_OVERO + depends on !MACH_OMAP3EVM + depends on !MACH_OMAP3517EVM + depends on !MACH_CRANEBOARD + depends on !MACH_OMAP3_PANDORA + depends on !MACH_OMAP3_TOUCHBOOK + depends on !MACH_NOKIA_N8X0 + depends on !MACH_NOKIA_RM680 + depends on !MACH_NOKIA_RX51 + depends on !MACH_OMAP_ZOOM2 + depends on !MACH_OMAP_ZOOM3 + depends on !MACH_CM_T35 + depends on !MACH_CM_T3517 + depends on !MACH_IGEP0020 + depends on !MACH_IGEP0030 + depends on !MACH_SBC3530 + depends on !MACH_OMAP_3630SDP + depends on !MACH_TI8168EVM + depends on !MACH_OMAP4_PANDA + select MACH_OMAP_GENERIC if ARCH_OMAP2 + select MACH_OMAP_3430SDP if ARCH_OMAP3 && !ARCH_OMAP2 + select MACH_OMAP_4430SDP if ARCH_OMAP4 && !ARCH_OMAP3 && !ARCH_OMAP2 + help + The kernel needs to have support for at least one board + in order to build. If none is selected, default to the + generic board. + config MACH_OMAP2_TUSB6010 bool depends on ARCH_OMAP2 && SOC_OMAP2420 -- 1.7.5.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 28/30] ARM: omap: select CPU_FREQ_TABLE where needed
The omap platform requires CPU_FREQ_TABLE support to be enabled for its CPU_FREQ implementations, so automatically select that when CPU_FREQ is enabled. Signed-off-by: Arnd Bergmann --- arch/arm/plat-omap/Kconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index bb8f4a6..f7ef9f4 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -217,6 +217,11 @@ config OMAP_PM_NOOP endchoice +config OMAP_CPU_FREQ + def_bool "y" + depends on CPU_FREQ + select CPU_FREQ_TABLE + endmenu endif -- 1.7.5.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 18/30] omap-usb: automatically select MFD_OMAP_USB_HOST
The ehci-omap and ohci-omap3 drivers both depend on the omap-usb-host MFD support driver. By default, this is automatically turned on, but it is possible to disable the driver, which results in a link error. This patch makes the option invisible so we always do the right thing. Signed-off-by: Arnd Bergmann Cc: Keshava Munegowda Cc: Samuel Ortiz --- drivers/mfd/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 21574bd..48cce35 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -721,7 +721,7 @@ config MFD_WL1273_CORE audio codec. config MFD_OMAP_USB_HOST - bool "Support OMAP USBHS core driver" + bool depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3 default y help -- 1.7.5.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 21/30] sound/soc/omap: limit to omap2plus
These drivers do not build correctly on omap1, so only allow selecting them on omap2 or higher. Signed-off-by: Arnd Bergmann Cc: Jarkko Nikula Cc: Liam Girdwood --- sound/soc/omap/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index fe83d0d..493733e 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -1,6 +1,6 @@ config SND_OMAP_SOC tristate "SoC Audio for the Texas Instruments OMAP chips" - depends on ARCH_OMAP + depends on ARCH_OMAP2PLUS config SND_OMAP_SOC_MCBSP tristate -- 1.7.5.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 30/30] ARM: omap2: select ARM_AMBA for OMAP3_EMU
OMAP3_EMU needs OC_ETM, which needs ARM_AMBA. Since the latter dependency is getting turned from a 'select' into a 'depends', omap has to select ARM_AMBA itself in order to have a correct dependency chain. Alternatively, we could change OMAP3_EMU to have a 'depends on OC_ETM' instead of selecting it. Signed-off-by: Arnd Bergmann --- arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index fdd45dd..12ae86e 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -386,6 +386,7 @@ config OMAP3_EMU bool "OMAP3 debugging peripherals" depends on ARCH_OMAP3 select OC_ETM + select ARM_AMBA help Say Y here to enable debugging hardware of omap3 -- 1.7.5.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 25/30] ARM: OMAP depends on MMU
There is no way to build OMAP kernels without an MMU at this point because of dependencies on MMU-only functions. As long as nobody is interested in fixing this, let's just disable this platforms for nommu kernels. Signed-off-by: Arnd Bergmann --- arch/arm/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5ebc5d9..e688ca4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -875,6 +875,7 @@ config ARCH_DAVINCI config ARCH_OMAP bool "TI OMAP" + depends on MMU select HAVE_CLK select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ -- 1.7.5.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 27/30] ARM: omap: select L2X0 cache on omap4
The cache controller needs to be enabled for the cortex-a9 specific errata that are also selected to work. Signed-off-by: Arnd Bergmann --- arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index fd0ab18..3921a95 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -47,6 +47,7 @@ config ARCH_OMAP4 select PL310_ERRATA_588369 select PL310_ERRATA_727915 select ARM_ERRATA_720789 + select CACHE_L2X0 select ARCH_HAS_OPP select PM_OPP if PM select USB_ARCH_HAS_EHCI -- 1.7.5.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 14/30] ARM: omap2: irq.c is always needed
The Makefile only includes irq.o for omap2 and omap3, but it's in fact also required to build omap4-only kernels. Signed-off-by: Arnd Bergmann --- arch/arm/mach-omap2/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index dc36bd4..f14549d 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -4,9 +4,9 @@ # Common support obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \ -common.o gpio.o dma.o wd_timer.o +common.o gpio.o dma.o wd_timer.o irq.o -omap-2-3-common= irq.o sdrc.o +omap-2-3-common= sdrc.o hwmod-common = omap_hwmod.o \ omap_hwmod_common_data.o clock-common = clock.o clock_common_data.o \ -- 1.7.5.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 20/30] media/omap_vout: disable driver for now
This driver was broken by 8cff88c5d "OMAP: DSS2: remove update_mode from omapdss": /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c: In function 'omap_vout_probe': /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2202:15: error: 'struct omap_dss_driver' has no member named 'set_update_mode' /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2203:12: error: 'struct omap_dss_driver' has no member named 'set_update_mode' /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2204:8: error: 'OMAP_DSS_UPDATE_MANUAL' undeclared (first use in this function) /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2204:8: note: each undeclared identifier is reported only once for each function it appears in /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2206:15: error: 'struct omap_dss_driver' has no member named 'set_update_mode' /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2207:12: error: 'struct omap_dss_driver' has no member named 'set_update_mode' /home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2208:8: error: 'OMAP_DSS_UPDATE_AUTO' undeclared (first use in this function) make[3]: *** [drivers/media/video/omap/omap_vout.o] Error 1 make[2]: *** [drivers/media/video/omap] Error 2 make[1]: *** [drivers/media/video/] Error 2 make: *** [sub-make] Error 2 Let's disable it for now. Signed-off-by: Arnd Bergmann Cc: Mauro Carvalho Chehab Cc: Archit Taneja Cc: Amber Jain Cc: Vaibhav Hiremath --- drivers/media/video/omap/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap/Kconfig b/drivers/media/video/omap/Kconfig index 390ab09..ee21f36 100644 --- a/drivers/media/video/omap/Kconfig +++ b/drivers/media/video/omap/Kconfig @@ -4,6 +4,7 @@ config VIDEO_OMAP2_VOUT_VRFB config VIDEO_OMAP2_VOUT tristate "OMAP2/OMAP3 V4L2-Display driver" depends on ARCH_OMAP2 || ARCH_OMAP3 + depends on BROKEN # broken by 8cff88c5da "OMAP: DSS2: remove update_mode from omapdss" select VIDEOBUF_GEN select VIDEOBUF_DMA_CONTIG select OMAP2_DSS -- 1.7.5.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 13/30] ARM: omap2+: fix omap_hdq_init compilation
The definition of the device must depend on the hardware
we run on, not on the kernel configuration.
arch/arm/mach-omap2/devices.c:624:13: error: 'OMAP_HDQ_BASE' undeclared here
(not in a function)
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap2/devices.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1077ad6..392f2b0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -615,10 +616,8 @@ void __init omap242x_init_mmc(struct
omap_mmc_platform_data **mmc_data)
/*-*/
-#if defined(CONFIG_HDQ_MASTER_OMAP) || defined(CONFIG_HDQ_MASTER_OMAP_MODULE)
#if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430)
#define OMAP_HDQ_BASE 0x480B2000
-#endif
static struct resource omap_hdq_resources[] = {
{
.start = OMAP_HDQ_BASE,
@@ -641,10 +640,13 @@ static struct platform_device omap_hdq_dev = {
};
static inline void omap_hdq_init(void)
{
- (void) platform_device_register(&omap_hdq_dev);
+ if (cpu_is_omap2430() || cpu_is_omap3430())
+ (void) platform_device_register(&omap_hdq_dev);
}
#else
-static inline void omap_hdq_init(void) {}
+static inline void omap_hdq_init(void)
+{
+}
#endif
/*---*/
--
1.7.5.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 23/30] ARM: omap2: select twl4030 support on boards that need it
These three boards unconditionally use the twl4030 driver from the board-zoom-display.c file. Make sure that the driver is always there. We also need to select the I2C core so we are able to build that driver. Signed-off-by: Arnd Bergmann --- arch/arm/mach-omap2/Kconfig |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 57b66d5..4deeade 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -253,6 +253,8 @@ config MACH_OMAP_ZOOM2 select SERIAL_CORE_CONSOLE select SERIAL_8250_CONSOLE select REGULATOR_FIXED_VOLTAGE + select TWL4030_CORE + select I2C config MACH_OMAP_ZOOM3 bool "OMAP3630 Zoom3 board" @@ -263,6 +265,8 @@ config MACH_OMAP_ZOOM3 select SERIAL_CORE_CONSOLE select SERIAL_8250_CONSOLE select REGULATOR_FIXED_VOLTAGE + select TWL4030_CORE + select I2C config MACH_CM_T35 bool "CompuLab CM-T35/CM-T3730 modules" @@ -304,6 +308,8 @@ config MACH_OMAP_3630SDP depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBP + select TWL4030_CORE + select I2C config MACH_TI8168EVM bool "TI8168 Evaluation Module" -- 1.7.5.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 16/30] usb/musb: HDRC depends on TWL4030_CORE for OMAP3/4
The musb_hdrc driver tries to select TWL4030_USB or TWL6030_USB on some platforms, but those symbols in turn depend on TWL4030_CORE. Trying not to spread the 'select' further, this makes the driver depend on the TWL4030_CORE for the platforms that do other selects. Signed-off-by: Arnd Bergmann Cc: Felipe Balbi --- drivers/usb/musb/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index d596fb2..b6732ee 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -7,6 +7,7 @@ config USB_MUSB_HDRC depends on USB && USB_GADGET depends on (ARM || (BF54x && !BF544) || (BF52x && !BF522 && !BF523)) + depends on TWL4030_CORE || !(MACH_OMAP_3430SDP || MACH_OMAP_4430SDP || MACH_OMAP4_PANDA) select NOP_USB_XCEIV if (ARCH_DAVINCI || MACH_OMAP3EVM || BLACKFIN) select TWL4030_USB if MACH_OMAP_3430SDP select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA -- 1.7.5.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 17/30] usb/musb: allow building USB_MUSB_TUSB6010 as a module
Commit 1376d92f9 "usb: musb: allow musb and glue layers to be modules"
made the USB_MUSB_TUSB6010 option modular, but actually building
the driver as a module does not work, so various randconfig builds
actually fail. This changes all code that depends on the
option to also check for modular builds, and exports the necessary
symbols.
Signed-off-by: Arnd Bergmann
Cc: Felipe Balbi
---
arch/arm/mach-omap2/board-n8x0.c |2 +-
drivers/usb/musb/musb_core.c |3 ++-
drivers/usb/musb/musb_io.h |2 +-
drivers/usb/musb/tusb6010.c |1 +
4 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 403325d..c096dc2 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -46,7 +46,7 @@ static struct device *mmc_device;
#define TUSB6010_GPIO_ENABLE 0
#define TUSB6010_DMACHAN 0x3f
-#ifdef CONFIG_USB_MUSB_TUSB6010
+#if defined(CONFIG_USB_MUSB_TUSB6010) ||
defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
/*
* Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
* 1.5 V voltage regulators of PM companion chip. Companion chip will then
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 20a2873..9fa2596 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1432,7 +1432,7 @@ static int __init musb_core_init(u16 musb_type, struct
musb *musb)
struct musb_hw_ep *hw_ep = musb->endpoints + i;
hw_ep->fifo = MUSB_FIFO_OFFSET(i) + mbase;
-#ifdef CONFIG_USB_MUSB_TUSB6010
+#if defined(CONFIG_USB_MUSB_TUSB6010) || defined
(CONFIG_USB_MUSB_TUSB6010_MODULE)
hw_ep->fifo_async = musb->async + 0x400 + MUSB_FIFO_OFFSET(i);
hw_ep->fifo_sync = musb->sync + 0x400 + MUSB_FIFO_OFFSET(i);
hw_ep->fifo_sync_va =
@@ -1632,6 +1632,7 @@ void musb_dma_completion(struct musb *musb, u8 epnum, u8
transmit)
}
}
}
+EXPORT_SYMBOL_GPL(musb_dma_completion);
#else
#define use_dma0
diff --git a/drivers/usb/musb/musb_io.h b/drivers/usb/musb/musb_io.h
index 03c6ccd..e61aa95 100644
--- a/drivers/usb/musb/musb_io.h
+++ b/drivers/usb/musb/musb_io.h
@@ -74,7 +74,7 @@ static inline void musb_writel(void __iomem *addr, unsigned
offset, u32 data)
{ __raw_writel(data, addr + offset); }
-#ifdef CONFIG_USB_MUSB_TUSB6010
+#if defined(CONFIG_USB_MUSB_TUSB6010) || defined
(CONFIG_USB_MUSB_TUSB6010_MODULE)
/*
* TUSB6010 doesn't allow 8-bit access; 16-bit access is the minimum.
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index ec14801..1f40561 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -56,6 +56,7 @@ u8 tusb_get_revision(struct musb *musb)
return rev;
}
+EXPORT_SYMBOL_GPL(tusb_get_revision);
static int tusb_print_revision(struct musb *musb)
{
--
1.7.5.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 10/30] ARM: omap/iommu: always provide iommu debug code
The iommu module on omap contains a few functions that are
only used by the debug module. These are however only there
when the debug code is built as a module. Since it is possible
to build the debug code into the kernel, the functions should
also be provided for the built-in case.
Signed-off-by: Arnd Bergmann
---
arch/arm/plat-omap/iommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 34fc31e..9d43ce1 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -391,7 +391,7 @@ void iommu_set_twl(struct iommu *obj, bool on)
}
EXPORT_SYMBOL_GPL(iommu_set_twl);
-#if defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
+#if defined(CONFIG_OMAP_IOMMU_DEBUG) || defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
ssize_t iommu_dump_ctx(struct iommu *obj, char *buf, ssize_t bytes)
{
--
1.7.5.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 08/30] ARM: omap2+: fix building without i2c
A trivial typo causes build breakage when I2C is disabled
and omap_i2c_reset is set to NULL on OMAP:
omap_hwmod_44xx_data.c:2287:11: error: lvalue required as unary '&' operand
Removing the '&' character solves this.
Signed-off-by: Arnd Bergmann
Cc: Avinash.H.M
Cc: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a015c69..3aa6c62 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1030,7 +1030,7 @@ static struct omap_hwmod_class i2c_class = {
.name = "i2c",
.sysc = &i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_1,
- .reset = &omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 16743c7..d9ab245 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1079,7 +1079,7 @@ static struct omap_hwmod_class i2c_class = {
.name = "i2c",
.sysc = &i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_1,
- .reset = &omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 25bf43b..b0a0113 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1309,7 +1309,7 @@ static struct omap_hwmod_class i2c_class = {
.name = "i2c",
.sysc = &i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_1,
- .reset = &omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_hwmod_dma_info omap3xxx_dss_sdma_chs[] = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..a6d42fc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2284,7 +2284,7 @@ static struct omap_hwmod_class omap44xx_i2c_hwmod_class =
{
.name = "i2c",
.sysc = &omap44xx_i2c_sysc,
.rev= OMAP_I2C_IP_VERSION_2,
- .reset = &omap_i2c_reset,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
--
1.7.5.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 04/30] ARM: omap: add missing __devexit_p() annotations
Drivers that refer to a __devexit function in an operations
structure need to annotate that pointer with __devexit_p so
replace it with a NULL pointer when the section gets discarded.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap2/smartreflex.c |2 +-
arch/arm/plat-omap/dma.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 34c01a7..67bc6ce 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1002,7 +1002,7 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
}
static struct platform_driver smartreflex_driver = {
- .remove = omap_sr_remove,
+ .remove = __devexit_p(omap_sr_remove),
.driver = {
.name = "smartreflex",
},
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..f7150ba 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2105,7 +2105,7 @@ static int __devexit omap_system_dma_remove(struct
platform_device *pdev)
static struct platform_driver omap_system_dma_driver = {
.probe = omap_system_dma_probe,
- .remove = omap_system_dma_remove,
+ .remove = __devexit_p(omap_system_dma_remove),
.driver = {
.name = "omap_dma_system"
},
--
1.7.5.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 07/30] ARM: omap: fix visibility of omap2_mbox_iva_priv
map2_mbox_iva_priv is used on multiple omap2 socs but is hidden
in an outdated #ifdef that is specific to a single soc.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap2/mailbox.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 86d564a..5a2a0e4 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -257,7 +257,7 @@ struct omap_mbox mbox_dsp_info = {
struct omap_mbox *omap3_mboxes[] = { &mbox_dsp_info, NULL };
#endif
-#if defined(CONFIG_SOC_OMAP2420)
+#if defined(CONFIG_ARCH_OMAP2)
/* IVA */
static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
--
1.7.5.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 02/30] video/omap: fix dependencies
The lcd_2430sdp and lcd_ldp drivers depend on TWL4030, which is not well expressed in the Kconfig. Create new configuration options for these in order to describe the dependencies correctly. In some cases, the driver cannot be a loadable module, so better force it to be built-in. While we're at it, simplify the Makefile syntax. Signed-off-by: Arnd Bergmann Cc: Tomi Valkeinen --- drivers/video/omap/Kconfig | 41 +--- drivers/video/omap/Makefile | 64 --- 2 files changed, 67 insertions(+), 38 deletions(-) diff --git a/drivers/video/omap/Kconfig b/drivers/video/omap/Kconfig index 196fa2e..bd15431 100644 --- a/drivers/video/omap/Kconfig +++ b/drivers/video/omap/Kconfig @@ -1,11 +1,11 @@ config FB_OMAP - tristate "OMAP frame buffer support (EXPERIMENTAL)" - depends on FB && (OMAP2_DSS = "n") + bool "OMAP frame buffer support (EXPERIMENTAL)" + # cannot be a module if more than one LCD driver is linked in + depends on (FB = "y") && (OMAP2_DSS = "n") depends on ARCH_OMAP1 || ARCH_OMAP2 || ARCH_OMAP3 select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT - select TWL4030_CORE if MACH_OMAP_2430SDP help Frame buffer driver for OMAP based boards. @@ -105,4 +105,37 @@ config FB_OMAP_DMA_TUNE answer yes. Answer no if you have a dedicated video memory, or don't use any of the accelerated features. - +config FB_OMAP_SOSSI + def_bool y + depends on ARCH_OMAP1 + depends on FB_OMAP_LCDC_EXTERNAL + +config FB_OMAP_RFBI + def_bool y + depends on ARCH_OMAP2 || ARCH_OMAP3 + depends on FB_OMAP_LCDC_EXTERNAL + +config FB_OMAP_INN1610 + def_bool y + depends on ARCH_OMAP16XX + depends on MACH_OMAP_INNOVATOR + +config FB_OMAP_INN1510 + def_bool y + depends on ARCH_OMAP15XX + depends on MACH_OMAP_INNOVATOR + +config FB_OMAP_OMAP3EVM + def_bool y + depends on MACH_OMAP3EVM + depends on TWL4030_CORE + +config FB_OMAP_X430SDP + def_bool y + depends on MACH_OMAP_2430SDP || MACH_OMAP_3430SDP + depends on TWL4030_CORE + +config FB_OMAP_LDP + def_bool y + depends on MACH_OMAP_LDP + depends on TWL4030_CORE diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile index 25db556..8c2cd56 100644 --- a/drivers/video/omap/Makefile +++ b/drivers/video/omap/Makefile @@ -4,37 +4,33 @@ obj-$(CONFIG_FB_OMAP) += omapfb.o -objs-yy := omapfb_main.o - -objs-y$(CONFIG_ARCH_OMAP1) += lcdc.o -objs-y$(CONFIG_ARCH_OMAP2) += dispc.o -objs-y$(CONFIG_ARCH_OMAP3) += dispc.o - -objs-$(CONFIG_ARCH_OMAP1)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o -objs-$(CONFIG_ARCH_OMAP2)$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += rfbi.o - -objs-y$(CONFIG_FB_OMAP_LCDC_HWA742) += hwa742.o -objs-y$(CONFIG_FB_OMAP_LCDC_BLIZZARD) += blizzard.o - -objs-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o -objs-y$(CONFIG_MACH_OMAP_H4) += lcd_h4.o -objs-y$(CONFIG_MACH_OMAP_H3) += lcd_h3.o -objs-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o -objs-y$(CONFIG_MACH_OMAP_PALMTT) += lcd_palmtt.o -objs-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o -objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o -objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o -objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o - -objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o -objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o -objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o -objs-y$(CONFIG_MACH_OMAP_LDP) += lcd_ldp.o -objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o -objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o -objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o -objs-y$(CONFIG_MACH_OVERO) += lcd_overo.o -objs-y$(CONFIG_MACH_HERALD) += lcd_htcherald.o - -omapfb-objs := $(objs-yy) - +omapfb-y += omapfb_main.o + +omapfb-$(CONFIG_ARCH_OMAP1)+= lcdc.o +omapfb-$(CONFIG_ARCH_OMAP2)+= dispc.o +omapfb-$(CONFIG_ARCH_OMAP3)+= dispc.o + +omapfb-$(CONFIG_FB_OMAP_SOSSI) += sossi.o +omapfb-$(CONFIG_FB_OMAP_RFBI) += rfbi.o + +omapfb-$(CONFIG_FB_OMAP_LCDC_HWA742) += hwa742.o +omapfb-$(CONFIG_FB_OMAP_LCDC_BLIZZARD) += blizzard.o + +omapfb-$(CONFIG_MACH_AMS_DELTA)+= lcd_ams_delta.o +omapfb-$(CONFIG_MACH_OMAP_H4) += lcd_h4.o +omapfb-$(CONFIG_MACH_OMAP_H3) += lcd_h3.o +omapfb-$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o +omapfb-$(CONFIG_MACH_OMAP_PALMTT) += lcd_palmtt.o +omapfb-$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o +omapfb-$(CONFIG_FB_OMAP_INN1610) += lcd_inn1610.o +omapfb-$(CONFIG_FB_OMAP_INN1510) += lcd_inn1510.o +omapfb-$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o + +omapfb-$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o +omapfb-$(CONFIG_FB_OMAP_X430SDP) += lcd_2430sdp.o +omapfb-$(CONFIG_FB_OMAP_LDP)
[PATCH 01/30] sound/omap: omap_mcpdm_remove cannot be __devexit
omap_mcpdm_remove is used from asoc_mcpdm_probe, which is an
initcall, and must not be discarded when HOTPLUG is disabled.
Signed-off-by: Arnd Bergmann
Cc: Jarkko Nikula
---
sound/soc/omap/mcpdm.c |2 +-
sound/soc/omap/mcpdm.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/mcpdm.c b/sound/soc/omap/mcpdm.c
index 928f037..50e59194 100644
--- a/sound/soc/omap/mcpdm.c
+++ b/sound/soc/omap/mcpdm.c
@@ -449,7 +449,7 @@ exit:
return ret;
}
-int __devexit omap_mcpdm_remove(struct platform_device *pdev)
+int omap_mcpdm_remove(struct platform_device *pdev)
{
struct omap_mcpdm *mcpdm_ptr = platform_get_drvdata(pdev);
diff --git a/sound/soc/omap/mcpdm.h b/sound/soc/omap/mcpdm.h
index df3e16f..20c20a8 100644
--- a/sound/soc/omap/mcpdm.h
+++ b/sound/soc/omap/mcpdm.h
@@ -150,4 +150,4 @@ extern int omap_mcpdm_request(void);
extern void omap_mcpdm_free(void);
extern int omap_mcpdm_set_offset(int offset1, int offset2);
int __devinit omap_mcpdm_probe(struct platform_device *pdev);
-int __devexit omap_mcpdm_remove(struct platform_device *pdev);
+int omap_mcpdm_remove(struct platform_device *pdev);
--
1.7.5.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 v3 3/3] ARM: OMAP: TI814X: Create board support and enable build for TI8148 EVM
Hi Hemant,
On 09/29/11 04:09, Hemant Pedanekar wrote:
> This patch adds minimal support and build configuration for TI8148 EVM. Also
> adds support for low level debugging on UART1 console on the EVM.
>
> Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with machine
> info for TI8148 EVM and renamed as board-ti81xxevm.c.
Should we really rename the existing file?
Shouldn't we just stick to the name of the file submitted first?
(e.g. board-ti8168evm.c) and just add the support for the new
TI8148 EVM in to the existing file?
Because, I don't see any real necessity in renaming that file.
Also, it will spare the changes in Makefile.
>
> Signed-off-by: Hemant Pedanekar
> ---
> arch/arm/mach-omap2/Kconfig|5
> arch/arm/mach-omap2/Makefile |3 +-
> .../{board-ti8168evm.c => board-ti81xxevm.c} | 22 ++-
> arch/arm/plat-omap/include/plat/uncompress.h |3 ++
> 4 files changed, 26 insertions(+), 7 deletions(-)
> rename arch/arm/mach-omap2/{board-ti8168evm.c => board-ti81xxevm.c} (66%)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index a3b9227..cc4f213 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -316,6 +316,11 @@ config MACH_TI8168EVM
> depends on SOC_OMAPTI81XX
> default y
>
> +config MACH_TI8148EVM
> + bool "TI8148 Evaluation Module"
> + depends on SOC_OMAPTI81XX
> + default y
> +
> config MACH_OMAP_4430SDP
> bool "OMAP 4430 SDP board"
> default y
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 5ee4cd6..1dc2c6b 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -239,7 +239,8 @@ obj-$(CONFIG_MACH_OMAP3517EVM)+=
> board-am3517evm.o \
> obj-$(CONFIG_MACH_CRANEBOARD)+= board-am3517crane.o
>
> obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
> -obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o
> +obj-$(CONFIG_MACH_TI8168EVM) += board-ti81xxevm.o
> +obj-$(CONFIG_MACH_TI8148EVM) += board-ti81xxevm.o
>
> # Platform specific device init code
>
> diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
> b/arch/arm/mach-omap2/board-ti81xxevm.c
> similarity index 66%
> rename from arch/arm/mach-omap2/board-ti8168evm.c
> rename to arch/arm/mach-omap2/board-ti81xxevm.c
> index 7935fc9..b858921 100644
> --- a/arch/arm/mach-omap2/board-ti8168evm.c
> +++ b/arch/arm/mach-omap2/board-ti81xxevm.c
> @@ -1,5 +1,5 @@
> /*
> - * Code for TI8168 EVM.
> + * Code for TI8168/TI8148 EVM.
> *
> * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
> *
> @@ -24,15 +24,15 @@
> #include
> #include
>
> -static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
> +static struct omap_board_config_kernel ti81xx_evm_config[] __initdata = {
> };
>
> -static void __init ti8168_evm_init(void)
> +static void __init ti81xx_evm_init(void)
> {
> omap_serial_init();
> omap_sdrc_init(NULL, NULL);
> - omap_board_config = ti8168_evm_config;
> - omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
> + omap_board_config = ti81xx_evm_config;
> + omap_board_config_size = ARRAY_SIZE(ti81xx_evm_config);
> }
>
> MACHINE_START(TI8168EVM, "ti8168evm")
> @@ -42,5 +42,15 @@ MACHINE_START(TI8168EVM, "ti8168evm")
> .init_early = ti81xx_init_early,
> .init_irq = ti81xx_init_irq,
> .timer = &omap3_timer,
> - .init_machine = ti8168_evm_init,
> + .init_machine = ti81xx_evm_init,
> +MACHINE_END
> +
> +MACHINE_START(TI8148EVM, "ti8148evm")
> + /* Maintainer: Texas Instruments */
> + .atag_offset= 0x100,
> + .map_io = ti81xx_map_io,
> + .init_early = ti81xx_init_early,
> + .init_irq = ti81xx_init_irq,
> + .timer = &omap3_timer,
> + .init_machine = ti81xx_evm_init,
> MACHINE_END
> diff --git a/arch/arm/plat-omap/include/plat/uncompress.h
> b/arch/arm/plat-omap/include/plat/uncompress.h
> index 40336ad..8d052e7 100644
> --- a/arch/arm/plat-omap/include/plat/uncompress.h
> +++ b/arch/arm/plat-omap/include/plat/uncompress.h
> @@ -175,6 +175,9 @@ static inline void __arch_decomp_setup(unsigned long
> arch_id)
> /* TI8168 base boards using UART3 */
> DEBUG_LL_TI81XX(3, ti8168evm);
>
> + /* TI8148 base boards using UART1 */
> + DEBUG_LL_TI81XX(1, ti8148evm);
> +
> } while (0);
> }
>
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe 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: ARM SoC tree: OMAP PM dependency on tip irq/core
On Saturday 01 October 2011 15:55:05 Rob Herring wrote: > > > > Kevin Hilman writes: > > > >> The upcoming OMAP4 PM series from Santosh[1] that we're planning to > >> queue for v3.2 has a dependency[2] on a patch currently queued for v3.2 > >> in the irq/core branch of Thomas' tip tree[3]. > >> > >> In the past, I noticed you merged external trees like this to solve > >> dependencies. > >> > >> Could you pull the irq/core branch into your tree to meet this > >> dependency? > > > > On second thought, since Santosh's branch is the only one with this > > dependency (and we also have a dependency on Russell's devel-stable) > > I'll just build up a branch for Santosh's series that includes > > rmk/devel-stable and tglx/irq-core. > > > > Any new platforms will have a dependency on rmk/devel-stable with the > mach header clean-up. I'll probably have a dependency on tglx's tree as > well. Good point. Also, I think in general it's better if I try to keep track of the depencies myself, so I don't accidentally submit patches upstream that belong into someone else's realm. I haven't come up with a good scheme for that yet. Right now I just add a depends/* branch and try to remember which branches depend on that. If it gets harder than this, I'll have to write it down somewhere, but it would be nice to have some tool that can automatically warn if I try to submit something that has an unfulfilled dependency. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
