From: David Brownell [EMAIL PROTECTED]
Finish moving initialization of pullups and pulldowns for twl4030
GPIOs into board specific init. Remove partial/incorrect init code
for that from the hsmmc glue.
Doing this right requires some attention from board init logic,
based on how the TWL chip
From: David Brownell [EMAIL PROTECTED]
Better TWL init on Beagle: use the setup() callback to
learn IRQ assignments; and configure pullups/pulldowns.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Similar patches will be needed for other TWL based boards.
arch/arm/mach-omap2/board
Hi Peter,
On Tuesday 30 September 2008, Peter 'p2' De Schrijver wrote:
I see your patch 68d7477caca19c0b52b5d4e85700cd3e6115577f created
pwrirq.c as a separate file and thread.
I guess choose this solution because it was similar to the GPIO IRQs.
Originally, this was 1 shared IRQ. But I
On Tuesday 30 September 2008, Felipe Balbi wrote:
Hopefully this is the final version:
For the core? This is IMO suitable for merging to linux-omap.
In terms of no-bugs-Dave-knows-about, for stuff he's touched.
There will however be other updates later...
... including the patch 26/25 I'm
From: David Brownell [EMAIL PROTECTED]
Clean up the twl4030-gpio code a bit ... mostly by shrinkage.
Remove a bunch of macros that are just obfuscating what the
TWL4030 GPIO code is doing. Some duplicated standard macros
like BIT(); others hid trivial math (mask/shift); others were
completely
On Tuesday 30 September 2008, Felipe Balbi wrote:
+struct twl4030_keypad_data {
+ int rows;
+ int cols;
+ int *keymap;
+ int irq;
+ unsigned int keymapsize;
+ unsigned int rep:1;
+};
To fix later: irq should be a standard platform resource.
Those
On Tuesday 30 September 2008, Felipe Balbi wrote:
ret = request_irq(TWL4030_MODIRQ_MADC, twl4030_madc_irq_handler,
Likewise: pass the IRQ through a platform driver resource.
These TWL4030_MODIRQ_* symbols should vanish.
(To fix later. No reason to hold up this batch of patches
any
I seem to have gotten four copies of these patches ... I'll assume
that one of the v3 sets is the way to go! :)
On Monday 29 September 2008, Felipe Balbi wrote:
I think now things are in pretty good shape and should be applied
to linux-omap mailing list.
I'll verify that on my test setup,
On Monday 29 September 2008, Felipe Balbi wrote:
On Mon, Sep 29, 2008 at 01:06:19PM -0700, David Brownell wrote:
On Monday 29 September 2008, Felipe Balbi wrote:
drivers/{i2c/chips = gpio}/twl4030-gpio.c | 37
+++
Best to avoid sending this type of patch
Well I can confirm that this is stuff I've seen to behave OK,
by diffing the patches against known-working versions. There
were Overo differences, and some keymap things.
Patch 0002 (don't zero pullup/pulldown configuration) is still
missing the ACK I sent when it first came though. :)
On the
Hi Peter,
I see your patch 68d7477caca19c0b52b5d4e85700cd3e6115577f created
pwrirq.c as a separate file and thread.
I'm wondering if there's any particular reason that bank of
interrupts shouldn't be handled directly by twl4030-core, and
even by the same IRQ handling thread.
As it stands now
On Monday 29 September 2008, Ben Dooks wrote:
-static void __exit omap_i2c_exit_driver(void)
+static void __devexit omap_i2c_exit_driver(void)
a differerent change to the one advertised.
{
platform_driver_unregister(omap_i2c_driver);
}
And incorrect too.
--
To unsubscribe
Similar fix needs merging into patch 21 too.
--- beagle.orig/drivers/i2c/chips/twl4030-core.c2008-09-29
17:21:37.0 -0700
+++ beagle/drivers/i2c/chips/twl4030-core.c 2008-09-29 17:21:25.0
-0700
@@ -75,6 +75,19 @@
#define twl_has_usb() false
#endif
+static inline
On Monday 29 September 2008, Felipe Balbi wrote:
couldn't this be done by set_type() so you could use
set_irq_type(irq, IRQF_VALID); ?
No; type is for trigger modes (edges, levels).
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL
From: David Brownell [EMAIL PROTECTED]
Request two more GPIOs on Beagle: MMC write protect, DVI enable.
Also define the first OMAP3 GPIO mux config symbols, with a new
naming convention. Examples:
- GPIO42 is bidirectional, and uses external pull up/down (if any);
- GPIO42_UP
From: David Brownell [EMAIL PROTECTED]
Portability fixes (simplifications) for rtc-twl4030: don't include
so many needless headers, especially platform-specific ones.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/rtc/rtc-twl4030.c | 10 +-
1 file changed, 1 insertion
Here are some more cleanups to consider including ... these
should apply on top of all nine patches.
=== SNIP HERE!
Provide detailed diagnostics in add_children() when DEBUG is
defined ... and fix the non-DEBUG message to include minimal
status, and not appear unless there was actually an
From: David Brownell [EMAIL PROTECTED]
Move the twl4030 GPIO support from drivers/i2c/chips to drivers/gpio,
which is a more appropriate home for this code.
The Kconfig symbol name is changed to match the GPIO_* convention for
such symbols, so config files must change in the obvious ways
On Saturday 27 September 2008, Felipe Balbi wrote:
On Sat, Sep 27, 2008 at 12:14:29PM -0700, David Brownell wrote:
Here are some more cleanups to consider including ... these
should apply on top of all nine patches.
You want me to keep it on top of the other 9 (10) patches or meld
On Saturday 27 September 2008, Felipe Balbi wrote:
On Sat, Sep 27, 2008 at 04:45:20PM -0700, David Brownell wrote:
On Saturday 27 September 2008, Felipe Balbi wrote:
We need something like the patch below (I can't find a substitute
to twl4030_set_gpio_edge_ctrl
On Friday 26 September 2008, Felipe Balbi wrote:
Err, strike the NYET- for me. Editing mistake, that
should have been removed before. ;)
There were a few comments in the patch header that sugested me this
patch wasn't finished yet :-)
This patch is done. The other work will be done
On Friday 26 September 2008, David Brownell wrote:
Let's apply the following patch 10/9 on top of this though.
And after applying this, and removing MADC config from
the Beagle and Overo board setup files, things worked!!
Moreover ... the USB host code worked, at least partially.
(Finally! RC7
From: David Brownell [EMAIL PROTECTED]
A bunch of little cleanups to twl4030-core.
- Remove needless header inclusions, symbols, and
forward declarations.
- Make coding style more standard.
And shrink the object size a bit.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/i2c
On Thursday 25 September 2008, Felipe Balbi wrote:
Move twl4030 keypad and usb to new style of
registration for twl4030 driver
I can tell I'm going to need to accelerate my
GPIO updates! :)
Cool. I'll look at this after breakfast...
--
To unsubscribe from this list: send the line
On Thursday 25 September 2008, Tony Lindgren wrote:
Get rid of bogus ASOC boot messages on non-Overo boards.
I'm not touching this without an ack from alsa list :)
Has this driver even gone to that list yet? ;)
I haven't really looked at initialization for this yet,
but my initial
On Thursday 25 September 2008, Tony Lindgren wrote:
This updates most of the OMAP drivers which are in mainline to
switch to using the cross-platform GPIO calls instead of the
older OMAP-specific ones.
This is all fairly brainless/obvious stuff. Probably the
most interesting bit
On Thursday 25 September 2008, Kevin Hilman wrote:
In that case, what is the proposed method for other kernel code to use
the debobs lines?
Hmm, good point :) My idea was to use the gpiolib calls on GPIO12 -
GPIO29, but then there is no way for a user to know if the GPIO was
assigned
.
Signed-off-by: Girish S G [EMAIL PROTECTED]
Signed-off-by: Jagadeesh Bhaskar Pakaravoor [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
Now I can remove this from my own GPIO cleanups. ;)
I was wondering why this code existed in the first
place ... at *best* it makes sense when
On Thursday 25 September 2008, Arun KS wrote:
I narrowed this into CONFIG_SLUB. When it's set, I can reproduce the
bug both with N810 and Beagle but not when using CONFIG_SLAB.
So it's confirmed that SLUB is a factor, but
the root cause is still not known or resolved?
--
To unsubscribe from
On Thursday 25 September 2008, Felipe Balbi wrote:
Clean up add_children a bit before adding more children
to twl4030-core.c
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
ACK, except for:
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -145,4 +145,10 @@ int
On Thursday 25 September 2008, Kevin Hilman wrote:
But I'm still not sure how to best deal with the possibiltity that the
pin might not always be a GPIO, but might be reconfigured/re-mux'd by
this debobs interface as a debug observability pin.
Some platforms have interfaces to reserve and
From: David Brownell [EMAIL PROTECTED]
Define platform data for configuring TWL4030 GPIOs,
and provide it for all boards using these chips.
For now all boards use the same fixed assignments for
GPIO and IRQ numbers. Eventually we should be able
to shuffle them without changing platform headers
From: David Brownell [EMAIL PROTECTED]
Make the twl4030 core create a platform device to which its
GPIO code will bind, with platform_data used to configure
board-specific behaviors and configuration.
Update the twl4030 GPIO code:
- Morph its gpio function code into a platform driver
On Wednesday 24 September 2008, Felipe Balbi wrote:
I'll do the GPIO code, which will be a slightly more
interesting example than the RTC.
I can do the keypad since I'm already working on the usb as well.
OK. Good to know folk are actively working on getting
this in shape for upstream!
On Tuesday 23 September 2008, Koen Kooi wrote:
The clean fix requires twl4030 to be a new style driver.
Fix not yet available. :(
Pushing until we have a better fix.
But twl4030 now is a new style driver, so we have a start :)
But who's working on it? :)
Sketch of solution:
-
For boards with twl4030/tps65950 chips, update board setup code to
provide the appropriate board info.
This should evolve a bunch more over time; right now too much of this
data is globally defined (like IRQ and GPIO numbering).
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
NOTE: run
Get rid of bogus ASOC boot messages on non-Overo boards.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
sound/soc/omap/overo.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/sound/soc/omap/overo.c
+++ b/sound/soc/omap/overo.c
@@ -107,11 +107,11 @@ static int __init
On Friday 19 September 2008, arun c wrote:
without this the below error messages were coming continuously
TWL4030 module irq 369 is disabled but can't be masked!
I can see how it would fix that. :)
But this is also a good illustration of why this keypad device
should be initialized
On Friday 19 September 2008, Felipe Balbi wrote:
- * linux/drivers/char/watchdog/omap_wdt.c
+ * linux/drivers/watchdog/omap_wdt.c
current style omits the paths (just use omap_wdt.c)
since they change periodically...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
On Friday 19 September 2008, Felipe Balbi wrote:
+static struct platform_device *omap_wdt_dev;
+
...
+struct omap_wdt_dev {
+ void __iomem *base; /* physical */
+ struct device *dev;
You don't need both omap_wdt_dev (platform device)
and omap_wdt_dev.dev (hmm,
On Friday 19 September 2008, Felipe Balbi wrote:
static int omap_wdt_open(struct inode *inode, struct file *file)
{
- struct omap_wdt_dev *wdev;
- void __iomem *base;
- wdev = platform_get_drvdata(omap_wdt_dev);
- base = wdev-base;
+ struct omap_wdt_dev *wdev
On Friday 19 September 2008, Koen Kooi wrote:
Ok, another datapoint: client mode (tested on beagle by Måns) and host
mode (tested on overo by Steve) work with a similar patch as above,
OTG mode is broken (tested on beagle and evm by me).
one issue being that TWL4030 irqs don't cause the
On Thursday 18 September 2008, Pandita, Vikram wrote:
And, no, I'm not going to try omapzoom stuff, I want it working on the
canonical linux-omap kernel, not some corporate version with god knows
how many hacks.
Your wish.
I thought debugging and fixing the issue was more important
On Thursday 18 September 2008, Woodruff, Richard wrote:
It would be nice if whatever code was on the main branch was not
so frequently broken.
That's (at least) a current problem. And the issue is how
to fix it... a *big* part of that involves having enough
(and current-enough) OMAP code in
On Thursday 18 September 2008, Felipe Balbi wrote:
convert to use ioremap() and __raw_{read/write} friends.
Why is this going to the OMAP list, not to LKML and cc'd
the watchdog maintainer? (I added Wim to the cc list...)
If it's worth having, it's worth having in mainline...
On Saturday 23 August 2008, Tony Lindgren wrote:
I'll get the ehci-omap code in better shape and submit separately to the
linux-usb list.
Given that we've not yet seen patches splitting out the board-specific
bits into arch/arm/mach-omap2, I can't imagine those fixes being ready
for the
On Thursday 18 September 2008, Gadiyar, Anand wrote:
(Hint for TI folk: why not write the
code that way in the first place, avoiding all the delays inherent in
writing code you *know* is unsuitable for merging to mainline?)
Well, there are only a limited number of hours in a
On Tuesday 16 September 2008, Jarkko Nikula wrote:
I think one good measure for this whole work when one can can run
Beagle or Overo with mainline kernel.
Yes ... ideally for 2.6.28 for both. The Overo boards handed
out at the kernel summit are a bit visible right now as not
yet booting with
On Friday 12 September 2008, Felipe Balbi wrote:
- hcd-regs = (void __iomem *) (int) IO_ADDRESS(hcd-rsrc_start);
+ hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
This is missing its sibling iounmap() ...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
On Sunday 07 September 2008, Bryan Wu wrote:
For Blackfin, the register MUSB_CONFIGDATA is not exported out to software.
So in the musb driver, Blackfin code can not access the MUSB_CONFIGDATA.
The configuration is fixed in the software.
So an musb_read_configdata() inline could normally read
On Friday 12 September 2008, Felipe Balbi wrote:
/* Enusre bit is set */
My Cortex Mark-I (cerebral, humanoid) treats that as a compile error ... :)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Friday 12 September 2008, Gadiyar, Anand wrote:
Sounds like code that can live in mach-omap2 and be called
when the drivers start or stop.
Yup. Then a lot of the code in that ehci-omap.c file would need
to be moved there to avoid duplicating code. Will do that when
I add the OHCI
On Thursday 11 September 2008, Singh, Vimal wrote:
I will define NAND_BLOCK_SIZE as:
#define NAND_BLOCK_SIZE 64 * NAND_MAX_PAGESIZE
Never define such things without parentheses ...
Also, that looks wrong as well as sub-optimal. Current NAND chips
can have page sizes up to 4 KB
From: David Brownell [EMAIL PROTECTED]
Make the twl4030 RTC initialization follow the driver model better.
The platform device is created (if needed) as part of twl4030 setup
instead of as a board-specific thing, and fits properly into the
driver model tree.
The only minor glitch here
On Tuesday 09 September 2008, Tony Lindgren wrote:
The patch might be acceptable as a temporary workaround, but obviously
it won't be accepted in mainline, as well as commit
7ef9abe1e9cf53c2dd7556f12d35b06053847f72 which has introduced periodic
IRQ functionality to rtc-twl4030 driver.
On Wednesday 13 August 2008, Madhusudhan Chikkature wrote:
A better way to do this would be to let the boards say exactly
what the hardware configuration is, rather than requiring all
OMAP3 boards to be set up exactly like the SDP...
I think the initial version was written specific to SDP.
On Monday 08 September 2008, Kamat, Nishant wrote:
- while (len--)
- *p++ = cpu_to_le16(readw(info-nand.IO_ADDR_R));
+ if (use_prefetch) {
Em, clearly this does not go on top of the NAND patch I
sent recently ... please do that instead, so we don't
need to repeat the
On Monday 08 September 2008, Russell King - ARM Linux wrote:
- while (len--)
- *p++ = cpu_to_le16(readw(info-nand.IO_ADDR_R));
This driver needs work (see endianness explaination below.)
Already done, but this patch doesn't build on that patch...
--
To unsubscribe from
On Monday 08 September 2008, Kamat, Nishant wrote:
+config MTD_NAND_OMAP_PREFETCH
+ bool GPMC prefetch support for NAND Flash device
+ depends on MTD_NAND MTD_NAND_OMAP2
+ default n
+ help
+ The NAND device can be accessed for Read/Write using GPMC PREFETCH
On Sunday 07 September 2008, Måns Rullgård wrote:
I've also had to revert the usb: musb: pass configuration specifics
via pdata commits:
ffd60d49c70b31d26430a1098edf0eef5e4dfac8 in linux-omap
ca6d1b1333bc2e61e37982de1f28d8604c232414 in mainline
I suspect there are simply some tables
On Tuesday 02 September 2008, Russell King - ARM Linux wrote:
+ ts-irq = OMAP_GPIO_IRQ(dav_gpio);
In fact, this driver requires ARCH_OMAP to set ts-irq, otherwise
it's uninitialized.
Or ts-irq = gpio_to_irq(dav_gpio) ...
--
To unsubscribe from this list: send the line unsubscribe
On Friday 29 August 2008, David Brownell wrote:
You're talking about some other problem. I'm talking about
the one where it *OOPSES* while binding to the gadget driver.
which fyi seems to have gone away ... not sure why though ...
--
To unsubscribe from this list: send the line unsubscribe
On Thursday 04 September 2008, Gadiyar, Anand wrote:
From: Anand Gadiyar [EMAIL PROTECTED]
The Index register needs to be zero to access CONFIGDATA.
musb_ep_select()will not set the MUSB_INDEX register unless INDEXED
mode addressing is used. This change will set the register correctly
in
On Friday 05 September 2008, Pakaravoor, Jagadeesh wrote:
RTC generates an extra spurious interrupt for every actual periodic
interrupt. This is due to a problem with the RTC_IT bit of
REG_PWR_ISR1. It requires two writes or two reads (when COR is
enabled) to clear it. Since COR is enabled
On Thursday 04 September 2008, Madhusudhan Chikkature wrote:
OK, this one may need cleanup ... but I don't disagree that it
should go upstream.
I had fixed several comments provided by Pierre and Russell
before Tony merged this patch. But then we have further added
several fixes on top of
From: David Brownell [EMAIL PROTECTED]
Some rtc-twl4030 cleanup, which among other things adds up to
using about 10% less object code:
- Remove:
* broken/unfixable periodic IRQ support (2^N Hz)
* duplicated constants in the header file
* pointless stuff:
+ support
Breaking this up into digestible chunks ...
This one for USB gadget. I'll send parts of this upstream now,
that seems simplest.
I'll review the patch for ehci-omap separately, when it's submitted.
ISTR already commenting that the Kconfig stuff should become a
platform_data issue. Until that's
On Wednesday 03 September 2008, Woodruff, Richard wrote:
Fixed translations do have some benefits. You can ensure that you
are using section or super section descriptors to cover large areas.
This does result in better TLB usage. Along with freeing up TLB
entries you also generally avoid TLB
On Wednesday 03 September 2008, Russell King - ARM Linux wrote:
- virtual addresses are pointer like.
- physical addresses are integer like.
So, if it's a physical address, it should be stored in an integer type
large enough to contain it, and that means something like u32, or
unsigned
On Wednesday 03 September 2008, Tony Lindgren wrote:
My OSK is booting just fine here with current mainline and the
omap_osk_5912_defconfig. This is the current head at
2.6.27-rc5-00100-gec0c15a. Have you checked if yours boots with
the mainline omap_osk_5912_defconfig?
Today's root seems to
On Wednesday 03 September 2008, Russell King - ARM Linux wrote:
On Wed, Sep 03, 2008 at 03:05:59PM -0700, David Brownell wrote:
According to Mr. Grep, there are at least 10 ARMs that work
like that [__arch_ioremap] in mainline. Maybe Russell can
recommend one of them as a preferred model
On Wednesday 03 September 2008, Steve Sakoman wrote:
I get similar results for both Beagle and Overo, so the error occurs
for both nand and onenand. The boot eventually completes, of course
without nand/onenand support.
Does this help?
http://marc.info/?l=linux-kernelm=121999823616458w=2
On Monday 01 September 2008, stanley.miao wrote:
+ if(!is_sil_rev_less_than(OMAP3430_REV_ES2_0)) {
But checkpatch.pl rejected that, yes? Fixed in a later
version I see.
... and in static int sdp2430_panel_enable(...) this would
seem to be wrong. But for that matter, lcd_2430sdp.c should
On Tuesday 02 September 2008, Felipe Balbi wrote:
The following patches convert twl4030-usb to a platform_device
in order to set the usb mode via platform_data and get
rid of the Kconfig entry for that.
Shouldn't twl4030 first be converted to be a new style
I2C driver? Then if this approach
On Tuesday 02 September 2008, Felipe Balbi wrote:
twl4030_gpio should be
moved to gpiolib also before sending to mainline.
Snapshot of what's in my tree ...
=== CUT HERE
From: David Brownell [EMAIL PROTECTED]
Make the TWL4030 GPIOs hook up to gpiolib.
Start to phase out the older
-beagle hardware; and beagle_init
already runs with other arch_initcall code.)
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-omap3beagle.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b
From: David Brownell [EMAIL PROTECTED]
Minor cleanups to omap 2430/34xx/35x musb_hdrc init:
- num_eps is 16; here, each one is bidirectional
- use DMA_32BIT_MASK to prevent confusion/errors
- initialize root port power to reflect 100 mA limit
This still hard-wires some board-specific data
On Tuesday 02 September 2008, Felipe Balbi wrote:
On Tue, Sep 02, 2008 at 08:39:28AM -0700, David Brownell wrote:
On Tuesday 02 September 2008, Felipe Balbi wrote:
The following patches convert twl4030-usb to a platform_device
in order to set the usb mode via platform_data and get
On Tuesday 02 September 2008, Felipe Balbi wrote:
On Tue, Sep 02, 2008 at 08:43:56AM -0700, David Brownell wrote:
Snapshot of what's in my tree ...
Great, a few comments below.
# should have the base GPIO set up better; minimally
# in a system header, ideally platform data
On Tuesday 02 September 2008, Felipe Balbi wrote:
One thing we might say, Jean Delvare won't accept twl4030 the way it is
now. Old style i2c drivers will be dropped soon. We have to get twl4030
properly done otherwise it'll be a pain later.
He's also not keen on growing
On Tuesday 02 September 2008, Mark Brown wrote:
On Tue, Sep 02, 2008 at 09:36:29AM -0700, Steve Sakoman wrote:
The chip allows 19.2 Mhz, 26 Mhz, or 38.4 Mhz input clocks to the
codec. All existing boards (Overo, Beagle, and OMAP3 EVM) use 26 Mhz
(generated by a fixed external oscillator
On Saturday 30 August 2008, Felipe Balbi wrote:
+static int lp5521_configure(struct i2c_client *client)
+{
+ int ret = 0;
+
+ /* Enable chip and set light to logarithmic mode*/
+ ret |= lp5521_write(client, LP5521_REG_ENABLE, 0xc0);
+
+ /* setting all color pwms to
NAK on this one..
On Saturday 30 August 2008, Felipe Balbi wrote:
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -137,6 +137,13 @@ config TPS65010
This driver can also be built as a module. If so, the module
will be called tps65010.
+config
On Saturday 30 August 2008, Felipe Balbi wrote:
+config LEDS_OMAP_DEBUG
+ boolean LED Support for OMAP debug board LEDs
+ depends on LEDS_CLASS=y ARCH_OMAP
+ help
+ Enables support for the LEDs on the debug board used with OMAP
+ reference boards like
On Saturday 30 August 2008, Felipe Balbi wrote:
From: Felipe Balbi [EMAIL PROTECTED]
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
drivers/mmc/host/Kconfig | 13 +-
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/omap_hsmmc.c | 1069
On Saturday 30 August 2008, Felipe Balbi wrote:
---
drivers/video/backlight/Kconfig | 9 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/omap_bl.c | 218
+
3 files changed, 228 insertions(+), 0 deletions(-)
create mode
From: David Brownell [EMAIL PROTECTED]
Minor updates to the OMAP{2,3} NAND driver:
- Rename those buffer PIO routines as *_buf16()
- Get rid of pointless LE16 data conversions; OMAP is always LE
- Speed up buffer reads by switching to __raw_readsl()
Right now this driver only handles 16-bit
On Friday 29 August 2008, Aguirre Rodriguez, Sergio Alberto wrote:
From: Sakari Ailus [EMAIL PROTECTED]
Date: Tue, 15 Apr 2008 10:35:15 +0300
Subject: [PATCH] Adding IOCTL command to get slave private data.
Signed-off-by: Sakari Ailus [EMAIL PROTECTED]
---
include/media/v4l2-int-device.h
On Sunday 31 August 2008, Felipe Balbi wrote:
One reason I'd like to see this particular driver upstream is
so that folk using www.beagleboard.org hardware can stand a
real chance of using mainline kernels for development. That's
a small set of drivers, so that's a very achievable goal.
From: David Brownell [EMAIL PROTECTED]
Export Beagle's user button through the input framework so it's
accessible using normal mechanisms. This uses BTN_EXTRA for lack
of a more obvious choice.
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- beagle.orig/arch/arm/mach-omap2/board
From: David Brownell [EMAIL PROTECTED]
Assign default roles to two of Beagle's programmable LEDs:
- usr0 has a heartbeat to show basic activity
- usr1 shows MMC activity
A third led is controlled by the TWL4030 LED_B signal, but the
TWL driver doesn't yet support leds...
Signed-off-by: David
From: David Brownell [EMAIL PROTECTED]
Clean up the Beagle NAND config a bit: use SZ_128K instead of
an arithmetic expression for the NAND block size. Set the
NAND_BUSWIDTH_16 flag. Make its init routine static.
(Unrelated: make omap3_beagle_i2c_init be part of beagle_init.
It shouldn't
On Friday 29 August 2008, Igor Stoppa wrote:
I'd like to verify that u-boot is setting things up properly.
CONFIG_OMAP_MUX_WARNINGS helps for some definitions of properly:
when Linux needs one setting, but the boot loader leaves a different
one, you get a warning. That's usually
On Wednesday 27 August 2008, David Brownell wrote:
I tried it on Beagle and found that OTG mode wanted to oops
while binding the gadget driver ... static config. That's
with current GIT. Peripheral-only had the same issue ISTR.
This was with the new CDC Composite driver (ECM and ACM),
so
On Friday 29 August 2008, Felipe Balbi wrote:
On Fri, Aug 29, 2008 at 11:12:24AM -0700, David Brownell wrote:
On Wednesday 27 August 2008, David Brownell wrote:
I tried it on Beagle and found that OTG mode wanted to oops
while binding the gadget driver ... static config. That's
On Friday 29 August 2008, Felipe Balbi wrote:
You're talking about some other problem. I'm talking about
the one where it *OOPSES* while binding to the gadget driver.
Hmm, that I've never seend. Using musb with omap3 and n810.
Right, that's why I thought I'd chase the easier host-side
On Friday 29 August 2008, Woodruff, Richard wrote:
Clean up the Beagle NAND config a bit: use SZ_128K instead of
an arithmetic expression for the NAND block size. Set the
NAND_BUSWIDTH_16 flag. Make its init routine static.
Actually, this was talked about before a bit and the SZ_xyz
-by: Ajay Kumar Gupta [EMAIL PROTECTED]
Looks right to me, other than the lack of line wrapping in that
summary (corrected above). Moreover, there ought to be some way
to make all high speed hosts share TT scheduling code ... ;)
Acked-by: David Brownell [EMAIL PROTECTED]
---
drivers/usb/musb
comments.
regards
swami
From: David Brownell [EMAIL PROTECTED]
Sent: Friday, August 22, 2008 12:45 AM
To: Dmitry Krivoschekov; Subbrathnam, Swaminathan
Cc: linux-omap@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Kevin
Hilman
Subject: Re
arch/arm/mach-omap2/board-3430sdp.c |4
arch/arm/mach-omap2/hsmmc.c | 185
hsmmc.c is used by Beagle too, yet ...
void __init hsmmc_init(void)
{
omap_set_mmc_info(1, hsmmc_data);
+ omap_set_mmc_info(2, hsmmc2_data);
}
... MMC2
601 - 700 of 738 matches
Mail list logo
