On Saturday 01 October 2011 15:55:05 Rob Herring wrote:
Kevin Hilman khil...@ti.com 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].
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
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
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 a...@arndb.de
---
arch/arm/mach-omap2/mailbox.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
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 a...@arndb.de
Cc: Jarkko Nikula jarkko.nik...@bitmer.com
---
sound/soc/omap/mcpdm.c |2 +-
sound/soc/omap/mcpdm.h |2 +-
2 files
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 a...@arndb.de
---
arch/arm/mach-omap2/smartreflex.c |2 +-
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 a...@arndb.de
Cc: Avinash.H.M avinas...@ti.com
Cc:
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.
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,
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
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 a...@arndb.de
---
arch/arm/mach-omap2/Kconfig |6
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 a...@arndb.de
---
arch/arm/mach-omap2/devices.c | 10 ++
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
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 a...@arndb.de
---
arch/arm/mach-omap2/Makefile |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile
The cache controller needs to be enabled for the
cortex-a9 specific errata that are also selected
to work.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
arch/arm/mach-omap2/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig
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 a...@arndb.de
---
arch/arm/Kconfig |1 +
1
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
These drivers do not build correctly on omap1, so only allow
selecting them on omap2 or higher.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Jarkko Nikula jarkko.nik...@bitmer.com
Cc: Liam Girdwood l...@ti.com
---
sound/soc/omap/Kconfig |2 +-
1 files changed, 1 insertions(+), 1
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:
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 a...@arndb.de
---
arch/arm/plat-omap/Kconfig |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff
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
This avoids a warning from Kconfig about missing dependencies.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
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
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
We must not reference omap_i2c_reset if the file defining it
does not get built.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
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
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
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 a...@arndb.de
---
arch/arm/mach-omap2/gpmc.c |2 ++
1 files changed, 2
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 a...@arndb.de
Cc: Govindraj.R govindraj.r...@ti.com
---
drivers/tty/serial/Kconfig |2 +-
1 files changed, 1
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 a...@arndb.de
Cc: Tomi Valkeinen tomi.valkei...@ti.com
---
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.
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 a...@arndb.de
---
arch/arm/mach-omap2/Kconfig | 10 ++
1 files changed, 10
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'
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 a...@arndb.de
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc:
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
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)
+/* ||
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
(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 joerg.roe...@amd.com wrote:
No. I suggest a simpler and shorter algorithm using the bit helpers.
Ok, fair enough. I've revised the patches and
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
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
On Sun, Oct 2, 2011 at 4:45 PM, Arnd Bergmann a...@arndb.de 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
On Sun, 2 Oct 2011 16:45:51 +0200
Arnd Bergmann a...@arndb.de wrote:
These drivers do not build correctly on omap1, so only allow
selecting them on omap2 or higher.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Jarkko Nikula jarkko.nik...@bitmer.com
Cc: Liam Girdwood l...@ti.com
---
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.
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
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
On Sun, Oct 2, 2011 at 8:01 PM, Arnd Bergmann a...@arndb.de 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
On Sun, 02 Oct 2011 20:03:38 +0200
Arnd Bergmann a...@arndb.de 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
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
On Tue, Sep 27, 2011 at 4:30 AM, Grant Likely grant.lik...@secretlab.ca 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
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
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
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
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
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
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 a...@arndb.de
Cc: Jarkko Nikula jarkko.nik...@bitmer.com
I've applied this,
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
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
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
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:
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
On Sun, Oct 2, 2011 at 8:15 PM, Arnd Bergmann a...@arndb.de 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 a...@arndb.de
Cc: Govindraj.R
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 a...@arndb.de
---
Thanks for the review,
On Sat, Oct 1, 2011 at 8:03 PM, Rajendra Nayak rna...@ti.com 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
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,
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 a...@arndb.de
---
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send the line
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
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 a...@arndb.de
---
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To
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
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 a...@arndb.de
That should not be the case. Why do you think it is needed for OMAP4 ?
There is
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
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
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 a...@arndb.de
---
OMAP4 would have
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:
On Monday 03 October 2011 10:30 AM, Govindraj wrote:
Thanks for the review,
On Sat, Oct 1, 2011 at 8:03 PM, Rajendra Nayakrna...@ti.com 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
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
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 a...@arndb.de
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this
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
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 a...@arndb.de
---
arch/arm/plat-omap/Kconfig |
On Mon, Oct 3, 2011 at 10:53 AM, Rajendra Nayak rna...@ti.com 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 Nayakrna...@ti.com wrote:
On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
Add API to
77 matches
Mail list logo
