In future kernels, debugfs files need to specify
the llseek operation explicitly to allow seeking.
This sets the llseek operation in the omap iommu
debugfs files to generic_file_llseek, which is
appropriate for files using simple_read_from_buffer.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc
the automatic mass-conversion part when this gets ready
for inclusion in 2.6.37, to accomodate any drivers
that got added without a .llseek method.
Stephen, please add
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git llseek
Arnd Bergmann (15):
drm: use noop_llseek
net/wireless: use
On Wednesday 15 September 2010, valdis.kletni...@vt.edu wrote:
Show Details
On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said:
This changes all instances of struct file_operations in
the kernel to have a .llseek operation and then changes
the default to no_llseek, which returns
On Sunday 10 October 2010, Felipe Contreras wrote:
The mempool area is not handled by the kernel any more.
But tidspbridge still uses ioremap to set up the mapping for RAM,
even though it now is outside of the kernel linar mapping.
You should really only use ioremap on MMIO registers, nothing
On Monday 11 October 2010, Felipe Contreras wrote:
On Mon, Oct 11, 2010 at 1:40 PM, Arnd Bergmann a...@arndb.de wrote:
On Sunday 10 October 2010, Felipe Contreras wrote:
The mempool area is not handled by the kernel any more.
But tidspbridge still uses ioremap to set up the mapping
On Monday 18 October 2010 09:44:33 Ohad Ben-Cohen wrote:
+ int omap_hwspin_lock(struct omap_hwspinlock *hwlock, unsigned long *flags);
...
+ The flags parameter is a pointer to where the interrupts state of the
+ caller will be saved at.
This seems to encourage sloppy coding: The
On Tuesday 19 October 2010 22:43:34 Ohad Ben-Cohen wrote:
Disabling irqs might be a concern as a source of RT latency. It
might be better to make the caller responsible for managing local spin
locks and irq disable/enable.
This a coming from an hardware requirement, rather than a choice
On Tuesday 19 October 2010 22:51:22 Ohad Ben-Cohen wrote:
, which is generally discouraged
in all places where you know if you need to disable interrupts or not.
IMHO the default should be a version that only allows locks that don't get
taken at IRQ time and consequently don't require
On Thursday 21 October 2010, Ohad Ben-Cohen wrote:
This sounds like adding a set of API that resembles spin_{unlock,lock}_irq.
My gut feeling here is that while this may be useful and simple at
certain places, it is somewhat error prone; a driver which would
erroneously use this at the wrong
On Thursday 21 October 2010, Ohad Ben-Cohen wrote:
The change is also pretty trivial:
* move the internal locking implementation to raw_ methods
* the raw_ methods would save the current interrupt state only if
given a placeholder
* wrap those raw_ methods with the desired API (but only
On Tuesday 09 November 2010, Felipe Contreras wrote:
Felipe Contreras (14):
Revert staging: tidspbridge - update Kconfig to select IOMMU module
Revert staging: tidspbridge - remove dmm custom module
Revert staging: tidspbridge - deprecate reserve/unreserve_memory
funtions
On Monday 06 December 2010, David Sin wrote:
Tiling and Isometric Lightweight Engine for Rotation (TILER) driver
=
Dynamic Memory Manager (DMM) is a hardware block made by Texas Instruments.
Within the DMM exists at least one TILER hardware component. Its purpose is
to
organize
On Thursday 16 December 2010 18:37:38 David Sin wrote:
I'm not sure exactly how DRM/GEM works.. What functionality do you think is
overlapping? The main feature, aside from reduced page accesses, of the DMM
hw block is to provide physically contiguous 2 dimensional memory blocks for
image
and mutual exclusion
operations.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Hari Kanigeri h-kanige...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Arnd Bergmann a...@arndb.de
Cc: Paul Walmsley p...@pwsan.com
Acked
On Tuesday 08 February 2011, Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op instead of wfi() is probably bad, so for older
processors than v6,
On Tuesday 08 February 2011, Russell King - ARM Linux wrote:
I don't see any users of the sev/wfe/wfi macros in the current kernel,
so removing them seems like a good strategy to avoid people from
using them incorrectly.
That's because they've only just been added. See the massive
On Tuesday 08 February 2011, Dave Martin wrote:
I guess there are two problems we're trying to solve here:
1) a lowest-common denominator implementation of things like wfi(),
for use in common code. This must be based on __LINUX_ARM_ARCH__
(which IIUC gives the lowest arch supported by all
On Tuesday 08 February 2011, Dave Martin wrote:
CFLAGS_cpu_specific_object.o+= -march=armv7-a
Whether it's safe to do it depends on whether code from that file
could ever get run on other processors. I'm not so sure of the answer
to that..., but perhaps someone else has a better
On Tuesday 08 February 2011, Dave Martin wrote:
Why not have macros for these cases? (Which kinda brings the
discussion full-circle...)
My immediate concern is that too often, the Thumb-2 case will be
handled incorrectly or not at all ... and the kernel will silently
build without flagging
On Tuesday 08 February 2011 17:25:16 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
But that doesn't work if you build a combined v5/v6/v7 kernel, because
v5 supports neither form, right? I think to do that, it needs the
same kind
On Tuesday 08 February 2011 17:32:29 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:17:58PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011, Dave Martin wrote:
CFLAGS_cpu_specific_object.o+= -march=armv7-a
Whether it's safe to do it depends on whether code
On Tuesday 08 February 2011, Dave Martin wrote:
I have a (possibly silly) question ... are the definitions in
arm/system.h intended to be fully generic, or not? Some features
suggest an attempt at genericness, but not everything there is
generic. Maybe I have misconstrued the purpose of this
On Monday 12 July 2010 20:50:29 Uwe Kleine-König wrote:
[1] The following changes since commit
67a3e12b05e055c0415c556a315a3d3eb637e29e:
Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/ukl/linux-2.6.git
On Monday 05 September 2011, Jean Delvare wrote:
As said before, I'm not sure. Yes, it makes it easier to select misc
device drivers from Kconfig files. But it also makes it impossible to
deselect all misc device drivers at once.
I think that what we really need is the implementation in the
On Monday 05 September 2011, Cousson, Benoit wrote:
Yeah, I saw that in the cpus node documentation. My point here is that
I do need to represent the MPU subsystem that will contain the cpus. And
thus the Cortex is inside the MPU subsystem.
I can potentially keep the CPUs inside the cpus
On Thursday 08 September 2011, Ohad Ben-Cohen wrote:
On Thu, Sep 8, 2011 at 11:07 AM, Cousson, Benoit b-cous...@ti.com wrote:
The (small) issue for my point of view is that the #hwspinlock is already
encoded in the IP itself. So adding a baseid directly in DT will look like
duplicating
On Tuesday 06 September 2011, Russell King - ARM Linux wrote:
On Tue, Sep 06, 2011 at 04:29:14AM -0700, Tony Lindgren wrote:
Arnd,
Care to pull the following fixes to the -rc series from Paul?
Tony,
I don't think that will happen until master.kernel.org is back online
as the tree
On Thursday 08 September 2011 20:05:48 Mans Rullgard wrote:
Can't we do by having omap_init_audio() in arch/arm/mach-omap2/devices.c
generate a platform device of name depending upon machine_is_* ?
I had the same thought, but I couldn't find a suitable string anywhere.
Are you suggesting
On Thursday 08 September 2011, Cousson, Benoit wrote:
OK, this is indeed much more aligned with the current practice, and what
DMA should do as well.
Practically speaking, that change will go beyond the original scope of
that patch that was just adding the DT support based on the existing
On Thursday 08 September 2011, Ohad Ben-Cohen wrote:
On Thu, Sep 8, 2011 at 5:47 PM, Arnd Bergmann a...@arndb.de wrote:
I think a number would work here but is not optimal for the device tree
representation. I think a better binding would be to encode it like
interrupt numbers, where every
On Friday 09 September 2011, Russell King - ARM Linux wrote:
That's just twisted and utterly insane - adding more code for precisely
zero benefit what so ever. Think about it - the device tree is already
creating platform devices for entries in the device tree file. What's
the point of
On Thursday 08 September 2011, Nicolas Pitre wrote:
On Thu, 8 Sep 2011, Arnd Bergmann wrote:
On Tuesday 06 September 2011, Russell King - ARM Linux wrote:
On Tue, Sep 06, 2011 at 04:29:14AM -0700, Tony Lindgren wrote:
Arnd,
Care to pull the following fixes to the -rc series
On Sunday 11 September 2011, Ohad Ben-Cohen wrote:
but instead the controller should have a list of the available
spinlocks.
Might make more sense to give it the list of reserved (i.e. those that
were statically allocated) spinlocks, and then let it treat the rest
as available.
Fair
On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
consistent or timely with applying drivers/misc/ patches. It deserves
better.
[added him to Cc: list]
I do try to handle patches sent to me for misc/ in
On Thursday 15 September 2011, Grant Likely wrote:
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 21574bd..1836cdf 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2,10 +2,9 @@
# Multifunction miscellaneous devices
#
-menuconfig MFD_SUPPORT
-
On Monday 19 September 2011, Greg KH wrote:
That sounds good to me, I'll be glad to collect the patches and push
them to Linus for both of those trees (might as well keep them in the
same git tree, no need to separate them, right?) and I'll rely on you
for review and acking them. Much like I
On Saturday 17 September 2011, Tony Lindgren wrote:
Please pull the first part of omap cleanup from:
git://github.com/tmlind/linux.git cleanup
This series cleans up early_init functions and removes
CHIP_IS macro usage. This makes it easier to have SoC
specific init functions so adding
On Saturday 17 September 2011, Tony Lindgren wrote:
Please pull omap voltage cleanup series:
git://github.com/tmlind/linux.git voltage
This has a dependency to the cleanup part 1 series. As
this contains some voltage fixes too, it's a separate
series. You can either pull it into cleanup
On Saturday 17 September 2011, Tony Lindgren wrote:
Hi Arnd,
Please pull the first part of omap cleanup from:
git://github.com/tmlind/linux.git cleanup
This series cleans up early_init functions and removes
CHIP_IS macro usage. This makes it easier to have SoC
specific init functions
On Tuesday 20 September 2011, Arnd Bergmann wrote:
On Saturday 17 September 2011, Tony Lindgren wrote:
Hi Arnd,
Please pull the first part of omap cleanup from:
git://github.com/tmlind/linux.git cleanup
This series cleans up early_init functions and removes
CHIP_IS macro usage
On Tuesday 20 September 2011 15:33:12 Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [110920 14:12]:
On Tuesday 20 September 2011, Arnd Bergmann wrote:
One more thing: my randconfig tests are running now and
have spit out a new error after merging lost of stuff
today:
Good
On Tuesday 20 September 2011 23:46:11 Arnd Bergmann wrote:
It seems that you replace the #ifdef in the board-flash.c file
with a similar #ifdef in the header that replaces this with an
empty inline function when the object is not built.
Found another similar problem over night, presumably
On Wednesday 21 September 2011, Tony Lindgren wrote:
* Ohad Ben-Cohen o...@wizery.com [110920 01:34]:
On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen o...@wizery.com wrote:
I'm wondering how hwspinlock updates like this should go upstream.
The first hwspinlock batch was picked by
On Wednesday 21 September 2011, Linus Walleij wrote:
On Wed, Sep 21, 2011 at 4:12 PM, Arnd Bergmann a...@arndb.de wrote:
My feeling is that it would be best for Ohad to send these directly
to Linus, since it's basically a standalone subsystem and he's listed
as the maintainer (well, after
On Wednesday 21 September 2011, Kevin Hilman wrote:
Found. Patch below.
If this one is OK, I'll push to my for_3.2/voltage-cleanup branch (which
is already pulled into arm-soc/next/voltage) so just re-pulling will
pick up the fix.
Looks good to me, it's always nice when a bug fix is also a
On Friday 23 September 2011, Tony Lindgren wrote:
Please pull omap cleanup branch again from:
git://github.com/tmlind/linux.git cleanup
This contains a fix for earlier cleanup patches and has omap_device
cleanup and PM cleanup merged in.
As some of the later cleanup was based on a -rc6
On Saturday 24 September 2011, Tony Lindgren wrote:
If this one is OK, I'll push to my for_3.2/voltage-cleanup branch (which
is already pulled into arm-soc/next/voltage) so just re-pulling will
pick up the fix.
Arnd, care to pull this in directly from Kevin into voltage branch?
It's
On Thursday 29 September 2011, Tony Lindgren wrote:
Please pull omap dmtimer changes from:
git://github.com/tmlind/linux.git dmtimer
This series completes the system timer separation from the
driver like features. It also adds support for v2 ip that is
available for some timers starting
On Friday 30 September 2011, Tony Lindgren wrote:
How about a branch called driver?
There are still lots of pieces of code under arch/arm that should
be eventually moved to live under drivers. For example the mux
code and most of PM code can eventually be under drivers.
Yes, good idea! For
On Friday 30 September 2011, Tony Lindgren wrote:
Please pull omap cleanup part3 into cleanup from:
git://github.com/tmlind/linux.git cleanup-part3
If you did not already pull the earlier updated
cleanup, pulling this is enough and will bring that
in too.
Ok, I've ended up replacing the
On Friday 30 September 2011 22:13:42 Arnd Bergmann wrote:
On Thursday 29 September 2011, Tony Lindgren wrote:
Please pull omap dmtimer changes from:
git://github.com/tmlind/linux.git dmtimer
This series completes the system timer separation from the
driver like features. It also
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].
at it, simplify the Makefile syntax.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap/Kconfig | 41 +---
drivers/video/omap/Makefile | 64 ---
2 files changed, 67 insertions
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 a/arch/arm/mach-omap2
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 changed
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 +-
arch/arm/plat-omap
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
-by: Arnd Bergmann a...@arndb.de
---
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
, and exports the necessary
symbols.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Felipe Balbi ba...@ti.com
---
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
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
/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 a...@arndb.de
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Archit Taneja arc...@ti.com
Cc: Amber
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 b
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 b/arch/arm
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
it.
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 b/arch/arm/mach-omap2/Kconfig
index fdd45dd..12ae86e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach
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 deletions
-by: Arnd Bergmann a...@arndb.de
Cc: Keshava Munegowda keshava_mgo...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
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
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
for each family.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
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
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
combinations to build cleanly.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
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
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
b/arch/arm
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
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
---
drivers
. by converting n8x0 to be probed through the
device tree and moving that code into the driver.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
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
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 insertions
:(.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 a...@arndb.de
---
arch/arm/mach-omap2/Makefile |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git
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
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 a...@arndb.de
Cc: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/Kconfig | 57
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 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 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
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
On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote:
+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
On Monday 03 October 2011 11:09:33 Santosh Shilimkar wrote:
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
On Monday 03 October 2011 11:39:59 Archit Taneja wrote:
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.
Ok, thanks for
On Monday 03 October 2011 10:35:25 Santosh Shilimkar wrote:
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 ?
On Monday 03 October 2011 01:10:51 Felipe Balbi wrote:
Anyway, I'll take your patches in, but their too late for this merge
window I already sent my last pull to Greg.
No problem. I need the full set of arm-randconfig patches upstream in order
to make randconfig work in general, and that's not
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 a...@arndb.de
On Monday 03 October 2011 09:53:50 Tomi Valkeinen wrote:
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
On Monday 03 October 2011 09:59:35 Tomi Valkeinen wrote:
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
On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
In the long run, I'd hope we can just get rid of these for subarchitectures
that support device tree probing and make the device tree based machine
description unconditional.
This is really our goal, we will have soon the
On Monday 03 October 2011 10:49:10 Santosh Shilimkar wrote:
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
On Monday 03 October 2011, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [111003 02:20]:
On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
In the long run, I'd hope we can just get rid of these for
subarchitectures
that support device tree probing and make
1 - 100 of 749 matches
Mail list logo
