With this patch, host mode works.
What about OTG and gadget modes?
The MUSB hardware is flakey with respect to
those init issues. Re-ordering host vs gadget
init has been a good way to waste a few months,
for anyone who has a few to waste. (And a
better way to waste them for folk who do NOT
o lazy-disable state
This is an odd state, and confusion regularly
comes up ... I've never been a fan of having the
imperatively named disable_irq() act like a
disable_irq_at a_random_later_time_ _but_nyet(). If
one must have the latter function, clearer IMO
to name it better and have
--- On Tue, 12/28/10, Mark Brown broo...@opensource.wolfsonmicro.com wrote:
F
You shouldn't need this any more; the driver used to be
faffing around
with this because it wasn't using genirq for
this in the past.
Originally it couldn't, since genirq didn't
support threaded IRQ handling...
ISTR that while JFFS2 worked with NAND, it had
to reserve a few bytes of OOB data that might more
naturally be used for ECC data. I've not looked
at your layout ... does it reserve those bytes
for use by JFFS, or is it using them for ECC?
Also, ISTR that Some People felt that using JFFS2
with
So to recapitulate ... you're agreeing with me on
my key point -- that ARM1156, a V6T2 core with
Thumb2 support (used in fact to introduce
Thumb2), should work for some in-kernel Thumb2
usage, degree TBD, but obviously the v7 cores
are more capable (with SIMD support in T2, etc).
And no, *I*
--- On Tue, 12/7/10, Dave Martin dave.mar...@linaro.org wrote:
From: Dave Martin dave.mar...@linaro.org
Subject: [PATCH] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6...
This makes sense, because Thumb-2
code can't execute on anything
prior to ARMv7.
WRONG ... but you may be
Now force CS to be in inactive state only if it was
inactive when it was suspended.
Note that it's a bug if CS is active in
any suspend state (including OFF). That
strongly suggests $SUBJECT is an incomplete
workaround for that other bug...
When SPI wake up from OFF mode, CS is in the
On Fri, 2010-11-26 at 09:34 +0200, Ohad Ben-Cohen wrote:
On Thu, Nov 25, 2010 at 10:22 PM, David Brownell davi...@pacbell.net wrote:
So there's no strong reason to think this is
actually ggeneric. Function names no longer
specify OMAP, but without other hardware under
the interface
On Thu, 2010-11-25 at 08:40 +0200, Ohad Ben-Cohen wrote:
On Thu, Nov 25, 2010 at 5:59 AM, David Brownell davi...@pacbell.net wrote:
My rule of thumb is that nothing is generic
until at least three whatever-it-is instances
plug in to it. Sometimes this is called
the Rule of Three
an active trransfer,
which must not happen during OFF or other
suspend states.
Acked-by: David Brownell dbrown...@users.sourceforge.net
Also, in the last patch I suggested you do more of a
save/restore of
this value instead of a restore to a hard-coded
value. IOW, save the
value in the suspend
My rule of thumb is that nothing is generic
until at least three whatever-it-is instances
plug in to it. Sometimes this is called
the Rule of Three.
Other than OMAP, what's providing hardware
spinlocks that plug into this framework?
- Dave
--
To unsubscribe from this list: send the line
I know, the sourceforge list is a bit of a pain.
As all sourceforge lists are.
I don't even know
who the admin of that list is.
One of the Russian MontaVista crew created
that list, and presumably maintains it.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
--- On Wed, 7/7/10, Tony Lindgren t...@atomide.com wrote:
Or can we somehow calculate this drift once during init?
If it's set up in the gentime framework, yes; very
standard. AT91 is one model (they all have
32K clocks used to generate the system tick).
--
To unsubscribe from this list:
I wanted to close on the introduction of two new
OMAP device APIs
omap_device_enable_wakeup ()
omap_device_disable_wakeup() in
omap_device layer.
What's the relationship between these
and the sysfs attribute which manages
the per-device wakeup enable?
Should there be driver model
Doesn't the generic clock code have logic
to handle such rounding issues? I'm pretty
sure I remember dealing with that issue for
32K timers on AT91 processors. If so that
means the setup is done wrong, and is fixable.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
As a part of aligning the ISR code for MUSB with the specs,the
ISR code was re-written.
Best say re-aligning. When that code was merged, it was fully aligned with a
version of the MUSB
specification.
Alternatively, specify which version of which spec
was used this time around ... :)
--
When going from PREEMPT_VOLUNTARY to PREEMPT_NONE
the problem goes away.
Have you found whether this is a problem
with the OMAP HSMMC driver
versus the MMC/SD framework code
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
--- On Fri, 6/11/10, James Bottomley james.bottom...@suse.de wrote:
Do we at least have a clean way that a driver can
reject a system suspend? I've lost track of
many
issues, but maybe this could be phrased as a QOS
constraint: the current config of driver X
needs
clock Y active
This is a bit off the topic of Android
flamage, but I thought it would be worth
highlighting an example where the current
frameworks may still have a deficiency...
one that likewise relates to needing to
block entry ot a system suspend state, but
in this case user-space isn't very involved
(just
--- On Mon, 6/7/10, Peter Zijlstra pet...@infradead.org wrote:
So what's up with this Binder stuff, from what I can see
its just
yet-another-CORBA. Why does it need a kernel part at all,
can't you
simply run with a user-space ORB instead?
I really don't get why people keep re-inventing
If suspend is the thing we are used to via
/sys/power/state then the
race will persist forever except for the suspend blocker workaround,
True, because device wakeups are enabled
by device.driver.suspend() methods, which are
invoked towards the end of the activities
triggered by writing
--- On Tue, 6/1/10, James Bottomley james.bottom...@suse.de wrote:
As long as you can set a wakeup timer, an S state is just a C state with
side effects.
I've seen similar statements on this endless
thread before; they're not quite true...
The significant one is that entering an
S
--- On Mon, 5/31/10, Grazvydas Ignotas nota...@gmail.com wrote:
Another issue is that OTG depends on PM, so if I build PM-less kernel
(PM is still more or less in development on OMAPs), Kconfig will only
allow host or peripheral for musb, which doesn't match OTG selection
in the board
--- On Fri, 5/28/10, Sergei Shtylyov sshtyl...@mvista.com wrote:
Ajay Kumar Gupta wrote:
AM35x has musb interface (version 1.8) and uses CPPI41
DMA engine.
It has USB phy built inside the IP itself.
So it's more like DaVinci (earlier CPPI as well as
integrated PHY) than OMAP3...
--- On Fri, 5/28/10, Steve Sakoman sako...@gmail.com wrote:
By the way ... the #ifdeffery should indeed vanish
from all board
configs except the Davinci DM6446 EVM. That board is
kind of quirky
in terms of USB support, and needs jumpering to get
host or peripheral mode (and can't do
--- On Tue, 5/25/10, Kevin Hilman khil...@deeprootsystems.com wrote:
This is a load of crap. If probe() fails that
means that driver does not
manage the device
And thus, dev-driver shouldn't be assigned ...
That probe() looks very odd, lately, yes. It seems
to have changed a lot over
--- On Fri, 5/21/10, Gupta, Ajay Kumar ajay.gu...@ti.com wrote:
Then I think these #ifdefferys are required in all
the board files.
As I already explained: *NO*.
Unless the board has been designed in a flakey
manner (like the DM6446 EVM) it should
have no #ifdeffery in the MUSB
incompatible Kconfig role setting
there's a patch making that a warning instead of an #error
if I'm not wrong.
It's not an #error, it's a dev_err().
But more to the point, it's reporting a real error. As
the comment in the code explains:
/* The driver might handle more features
Actually in OMAP board files, power values have been
provided
With units of 1mA
Everywhere (!!) in the Linux-USB stack, those units
should be 2mA (just like in config descriptors) ...
which gets divided to half in
arch/arm/mach-omap2/usb-musb.c
... which is why there's a divide-by-two
--- On Fri, 5/21/10, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
GPIO is almost always fairly tightly platform bound
Not entirely. SOC based ones, yes. But GPIOs on expanders
and ancillary chips have more variable capabilities, and many
SOC-based boards have a bunch of those.
so features
Not all GPIOs have hardware debounce though, so
offering this
capability sort of begs the question of where/how to
provide a software debounce mechanism too...
how about adding a flag for supported features and if that
hardware doesn't support we simply return,
Presense of a debounce
We are designing a custom OMAP board that
will have a 500mA supply on
the OTG port. It looks like the power
is set with:
struct omap_musb_board_data {
u8
interface_type;
u8
mode;
u8
power;
};
However, with a u8, the max value is
I think better remove .mode parameter from board_data if
its not needed anyways
But it *IS* needed, as I explained before...
if some board
supports only some specific mode they can select those
specifc config only.
No they can't. Recall that kernels are expected to run on
multiple
Subject: [PATCH] ARM: OMAP: Fix board data to support
device only, host only and OTG roles.
Fix board data to support device only, host only and
OTG roles.
The board data hardcodes the mode to OTG or
Peripheral.
Or host. That's correct... because the *BOARD* is hard-wired
that
+#ifdef CONFIG_USB_MUSB_OTG
+ .mode
= MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode
= MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
.mode
= MUSB_PERIPHERAL,
+#endif
= MUSB_PERIPHERAL,
+#endif
By the way ...
during development on MeeGo devices we try to tackle
down as much as
possible the use_time offenders and start by filing
bugs to those apps,
instead of fixing their issues in kernel space.
Some apps do abuse kernel mechanisms, and whether the bug is in the
app or that kernel mechanism
This would be generally useful for embedded systems,
especially where the interrupt concerned is a wake source.
It allows drivers to avoid
spurious interrupts from noisy sources so if the hardware
supports it
the driver can avoid having to explicitly wait for the
signal to become
stable
-0700, David Brownell wrote:
Some apps do abuse kernel mechanisms, and whether the
bug is in the
app or that kernel mechanism can be a judgement
call. I'd expect to
hey come on, there's no judgement call for an app polling
every second
to check battery status or some other status
On Tuesday 26 January 2010, Felipe Balbi wrote:
But nothing in drivers/mfd ... the entry to the whole stack?
...
correct, that's still missing. I tried to play with it for a while, but
had to give up due to other musb tasks. So if someone wants to step up
and code that part, I'd be glad
On Friday 11 December 2009, Felipe Balbi wrote:
The notifier will be used to communicate usb events
to other drivers like the charger chip.
Good idea ... but not OTG-specific. It doesn't seem to me
that charging hookups belong in that header at all.
In fact, usb_gadget_vbus_draw() might
On Tuesday 26 January 2010, Mark Brown wrote:
On Tue, Jan 26, 2010 at 03:16:20AM -0800, David Brownell wrote:
I'd vote to convert all the USB-to-charger interfaces so
they use notifiers. After fixing the events ... see
comments below. :)
Yes please - it's not just chargers either
On Tuesday 26 January 2010, Felipe Balbi wrote:
+enum usb_xceiv_events {
Let's keep charger events separate from anything else,
like enter host mode or enter peripheral mode (or
even disconnect). The audiences for any other types
of event would be entirely different.
the idea was to
On Tuesday 26 January 2010, Felipe Balbi wrote:
but when suspended, we have to cut power ASAP. If not enumerated we can
still draw power for a few miliseconds due to dead battery provision.
When suspended, it's OK to draw a small amount of power.
On the order of one milliamp, based on the
On Tuesday 26 January 2010, Felipe Balbi wrote:
Thing is, supplying current is a bit more involved. If the
board can't supply 300 mA, the USB configuration selection
mechanism has to know that, so it never selects peripheral
configurations which require that much current.
but that's done
On Tuesday 26 January 2010, Felipe Balbi wrote:
just remember of another problem which I couldn't solve yet:
if you boot the board with the usb cable already attached, then we miss
the first notification because when the notifier is called, usb
controller driver isn't probed yet.
That's
On Tuesday 26 January 2010, Mark Brown wrote:
Yes please - it's not just chargers either, this can also be used by
PMICs which do power path management that includes USB.
Color me confused ... what do you mean by power path?
In the sort of design I'm talking about there is generally a
On Monday 14 December 2009, Felipe Balbi wrote:
move twl4030 children to threaded irq.
Felipe Balbi (4):
input: keyboard: twl4030: move to request_threaded_irq
input: misc: twl4030: move to request_threaded_irq
rtc: twl4030: move to request_threaded_irq
usb: otg: twl4030: move to
On Monday 25 January 2010, David Brownell wrote:
Did the threaded IRQ stuff ever get set up so that the top
level IRQ thread didn't have to hand off to another thread
each time? (That's how the current stuff works. One thread
calling out to each handler.)
Yes: set_irq_nested_thread
devices
that reside at different physical addresses (e.g.,
TI's DA8xx/OMAP-L13x SoC's).
Also allow the possibility for the timer and alarm
interrupts to use the same IRQ.
Signed-off-by: Mark A. Greer mgr...@mvista.com
CC: David Brownell davi...@pacbell.net
Acked-by: David Brownell dbrown
On Sunday 05 July 2009, Hemanth V wrote:
Do you see any major changes required to support
slave mode in the SPI core driver.
There *is* no such thing as a SPI core driver...
We are able to
use the existing interface for slave mode also, but
some APIs/ Structures could be made generic.
On Friday 28 August 2009, Hemanth V wrote:
So would it be possible to merge the slave support also for
now, and could be modified to support the new slave interface
as and when available.
Not really. You still haven't split the non-slave stuff into
a patch, note ..
--
To unsubscribe from
gadi...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
This is the right fix, thanks. With these two important
operations *next to each other* it'll be harder to repeat
the goof that cause this breakage.
---
Based
On Friday 10 July 2009, vimal singh wrote:
+static void omap_read_buf8(struct mtd_info *mtd, u_char *buf, int len)
+{
+ struct nand_chip *nand = mtd-priv;
+ u_char *p = (u_char *)buf;
+
+ while (len--)
+ *p++ = __raw_readb(nand-IO_ADDR_R);
+}
Better as
usb_nop_xceiv_register().
- Select NOP_USB_XCEIV for OMAP3EVM boards.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
... another for-2.6.31 bugfix.
---
This patch is refreshed based on David's recommendations at
[1] and [2].
[1
On Tuesday 23 June 2009, Hemanth V wrote:
This series of 2 patches adds support for McSPI slave
and DMA,FIFO. It incorporates review comments from
Kevin Hilman and Tony Lindgren
PATCH[1/2]: Changes to arch specific files
PATCH[2/2]: omap2_mcspi.c file changes
Needs some changes yet:
-
On Tuesday 23 June 2009, Hemanth V wrote:
This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput.
This has a dependency on patch
[RESEND][PATCH 1/2] McSPI Slave and DMA,FIFO support
... in this case I'd think they would better be part
On Monday 29 June 2009, Syed Rafiuddin wrote:
This patch adds McSPI support for OMAP4430 SDP platform. All the base
addresses
are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures
are filled at runtime to have McSPI support on OMAP4.
Signed-off-by: Syed Rafiuddin
On Tuesday 23 June 2009, Felipe Balbi wrote:
Looks like commit 84e250ffa76dddc1bad84e04248a27f442c25986
musb: proper hookup to transceiver drivers breaks booting on omaps
if no transceiver is configured. Got any patches for that?
Tony,
Is this on OMAP35x EVM? If so then the
On Monday 18 May 2009, Woodruff, Richard wrote:
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen
Sent: Monday, May 18, 2009 9:54 AM
Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG
register prevents the
On Thursday 04 June 2009, Remith Ravi wrote:
Hi,
Anybody had a chance to attend this issue? Any hint to solve the problem?
The ASIX AX88772A USB2.0 Fast Ethernet Network Adapter Linux driver
available in Asix website supports only upto Linux 2.6.26.
I integrated that driver into the git
On Sunday 14 June 2009, Hans Verkuil wrote:
+#define dump_reg(sd, reg, val) \
do {\
- val = tvp514x_read_reg(client, reg);\
- v4l_info(client, Reg(0x%.2X): 0x%.2X\n,
On Thursday 30 April 2009, Grazvydas Ignotas wrote:
I get the same on pandora, although it continues booting fine after
that. Maybe regulator folks will comment about regulator errors.
Does mainline 3e59091828ed5406c879b899b4257fcef7271e2c
resolve it for you?
--
To unsubscribe from this list:
On Thursday 30 April 2009, Steve Sakoman wrote:
The platform data messages still appear,
Those platform_data patches are getting reverted.
Ignore the messages for now.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
On Thursday 30 April 2009, Steve Sakoman wrote:
I've also noticed that I now get occasional mmcblk0: retrying using
single block read messages on the serial console. I haven't seen
these before. Anyone see anything similar on their setup?
Yes.
--
To unsubscribe from this list: send the line
On Wednesday 29 April 2009, Adrian Hunter wrote:
+ .shutdown = __devexit_p(omap2_onenand_shutdown),
That looks wrong. Shutdown functions shouldn't get discarded
like exit functions. I'd think the fix for that would be taking
away any __devexit annotation on the shutdown function.
On Tuesday 28 April 2009, Mark Brown wrote:
For the record, that incomplete constraints message is bogus.
On that board, VAUX3 has a complete set of constraints: it may
only emit 2.8V.
It's not VAUX3 that it's saying has incomplete constraints, it's the
board as a whole - if the
On Monday 27 April 2009, Grazvydas Ignotas wrote:
With current l-o head when I insert or remove SD card I'm getting this:
[ 20.733489] [ cut here ]
[ 20.738159] WARNING: at kernel/irq/handle.c:366
handle_IRQ_event+0x4c/0x14c()
[ 20.745330] BUG: IRQ handler
On Sunday 26 April 2009, Grazvydas Ignotas wrote:
Setup regulators for MMC1 and MMC2 to get those SD slots
working again.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
CC: David Brownell davi...@pacbell.net
---
arch/arm
On Saturday 25 April 2009, Paul Walmsley wrote:
device_unregister() calls regulator_dev_release() which frees rdev. The
subsequent kfree corrupts memory and causes some OMAP3 systems to oops on
boot in regulator_get().
For the 3430SDP users out there, this patch also fixes the boot
On Saturday 25 April 2009, Paul Walmsley wrote:
During regulator registration, any error after device_register() will
cause a double-free on the struct regulator_dev 'rdev'. The bug is in
drivers/regulator/core.c:regulator_register():
...
scrub:
device_unregister(rdev-dev);
On Thursday 23 April 2009, Trilok Soni wrote:
Thanks but I was requesting tps 6 5 0 2 3 not tps 6 2 3 5 x :).
Sorry ... maybe they'll help some other time. :)
I was wondering what happened to the tps6235x drivers,
which seemed to have gotten lost. I don't recall having
seen tps65023 code.
On Thursday 23 April 2009, Dmitry Torokhov wrote:
Dave,
It waqs sitting in my local queue, I had some concerns over the keymap
change as it was implemented in the version you sent me. The problem is
that you mangle key codes in your keymap table (encoding row/col data in
Well, not
On Monday 20 April 2009, Amit Kucheria wrote:
Whitespace-fixed version and passed through checkpatch.pl
Check for return values of i2c read/write operations and size of scripts being
uploaded to TWL4030
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
---
On Thursday 23 April 2009, twebb wrote:
It does look like it
recognizes it (REALTEK USB 10/100 LAN), but how to tell if it
recognizes it specifically as a eth adaptor?
drivers/net/usb/Kconfig has a USB_RTL8150 entry you might try.
usb 1-2.2: New USB device found, idVendor=0bda,
to mainline.
From: Manikandan Pillai mani.pil...@ti.com
Subject: regulator: add support for TPS6235x
The patch has been fixed for comments given by David Brownell
and Mark Brown for adding TPS6235x support on OMAP3 EVM.
Comments fixed include
moving Makefile changes
On Friday 06 February 2009, David Brownell wrote:
From: David Brownell dbrown...@users.sourceforge.net
Add a driver for the keypad controller on TWL4030 family chips.
PING? I was told this was in the input queue, but it's not in
http://git.kernel.org/?p=linux/kernel/git/dtor/input.git
device.bus_id doesn't exist any more
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
drivers/usb/host/ehci-omap.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -432,7 +432,8 @@ static int
On Monday 06 April 2009, Russ Dill wrote:
Also, it appears from looking an the openzoom git, there are some
patches to add DMA support in, but I'm not sure what effect they have.
We had asked for some benchmark data -- anything! -- to get a
handle on that, and the prefetch/etc engine; nothing
On Sunday 05 April 2009, Hugo Vincent wrote:
I'm trying to get the realtime patch set to work on OMAP3 (Gumstix
Overo). Linux-omap 2.6.29 with the RT patches -rt1 or -rt2 work mostly
as is (MUSB and the usb-gadget layer have quite a few problems, and
Like what? Way back in 2.6.10 MUSB behaved
On Monday 06 April 2009, Paul Walmsley wrote:
Puzzle: get a dma_copypage() to work faster than copy_page().
Or a dma_clear_page() faster than clear_page(). Not easy...
Doing it via the DMA engine may save power, since MPU can sleep.
But the CPU overhead of calling the DMA engine can
On Monday 06 April 2009, Paul Walmsley wrote:
Hi David
On Mon, 6 Apr 2009, David Brownell wrote:
On Monday 06 April 2009, Russ Dill wrote:
Also, it appears from looking an the openzoom git, there are some
patches to add DMA support in, but I'm not sure what effect they have.
We
On Monday 06 April 2009, Gupta, Ajay Kumar wrote:
David, what's your comment on this?
It was wrong to try registering the transceiver in
the mach-map2/usb2.c file in any case. That's a
board-specific issue for OMAP3; and TUSB60x0 chips
have an integrated one. See
On Monday 06 April 2009, Ajay Kumar Gupta wrote:
As the parent patch for NOP transceiver got modified which now does the
NOP device registration also so removing registration part from
usb-musb.c file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Against latest linux-omap tree as
RX DMA is troublesome with the MUSB code, and there are some bugfixes
pending which should affect it. (Posted to linux-usb over the last
week or two.)
Do these problems show up with DMA disabled?
I guess you mean with CONFIG_MUSB_PIO_ONLY - yes, I've tried that. I
don't observe the
On Monday 06 April 2009, Hugo Vincent wrote:
Here is a complete boot log + config:
http://hugovincent.com/files/lkml-20090407/boot2.log
Erm, not very complete actually. Enable DEBUG_LL to see
more early messages ... like the ones starting right
after the kernel decompression messages.
Also,
On Friday 03 April 2009, Russ Dill wrote:
On Fri, Apr 3, 2009 at 7:52 PM, David Hagood david.hag...@gmail.com wrote:
Well, that's not what I would have expected - I would have thought
reads on POP would have been faster than that, and cheaper - the SD
being the same speed but less CPU is
I find that it's not just Beagle which refuses to reboot
when the twl4030-power driver is configured ... 3430 SDP
does so now, too. (Standard OMAP tree with no particular
PM-related patches applied.)
Does anyone know what the problem is?
- Dave
--
To unsubscribe from this list: send the line
On Tuesday 31 March 2009, Mark Brown wrote:
On Mon, Mar 30, 2009 at 01:53:43PM -0700, David Brownell wrote:
So when are you going to fix the regulator docs to report that:
ALL regulator consumers must start by enabling and
then disabling the regulator.
The documention should
On Wednesday 25 March 2009, Adrian Hunter wrote:
http://community.ti.com/forums/p/3777/14574.aspx
So how do we do it?
I'd prefer seeing the reply from Ghandar to David's last question before
accepting this patch again. It's still not 100% clear from TI, things
seem a little bit
On Wednesday 25 March 2009, Tony Lindgren wrote:
* David Brownell davi...@pacbell.net [090321 02:34]:
On Friday 20 March 2009, dfoley wrote:
Does anyone else get these mmc errors or know why on the OMAP 3530
Development board ?
Which dev board? LDP? EVM?
mmci-omap-hs mmci
On Wednesday 25 March 2009, dfoley wrote:
SD seems to work now with patch below and REGULATOR_TWL4030 [=y].
For the patch, I just copied from other boards in mach-omap2, so
I really have no idea if it's correct.
I think you don't need to set up VSIM, since that board
only seems to support
previously been enabled.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
good catch.
---
arch/arm/mach-omap2/mmc-twl4030.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc
for anything with MMC and TWL4030.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: David Brownell davi...@pacbell.net
Acked-by: David Brownell dbrown...@users.sourceforge.net
I seem to have given up on updating defconfigs, but
that doesn't mean it's not a good thing to do!
Same thing with twl4030
On Friday 20 March 2009, dfoley wrote:
Does anyone else get these mmc errors or know why on the OMAP 3530
Development board ?
Which dev board? LDP? EVM?
mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
regulator: Unable to get requested regulator: vmmc
Needs patches to setup
On Friday 20 March 2009, Tony Lindgren wrote:
* David Brownell davi...@pacbell.net [090319 15:27]:
* Least hassle ... I think all these should merge to the
linux-omap tree in any case (and thence linux-pm):
http://marc.info/?l=linux-omapm=123699264117846w=2
http
From: David Brownell dbrown...@users.sourceforge.net
Hook up VPLL2 regulator on 3430 SDP. Link that and VDAC to the
framebuffer device, supporting eventual conversion to use the
regulator framework.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
Try also to merge
would probably work better ... it doesn't actually
fix the bug in the regulator core, but it's a workaround
that could go to mainline until that core gets fixed.
(Oh, and it includes a real, albeit minor, bugfix.)
- Dave
=
From: David Brownell dbrown...@users.sourceforge.net
Updates
On Friday 20 March 2009, David Brownell wrote:
I may just prepare an mmc-twl4030 patch with ugly workarounds,
since I'm getting the strong feeling that it'll take forever
to get the regulator framework fixed in that area.
I just sent that ...
--
To unsubscribe from this list: send the line
On Friday 20 March 2009, Felipe Balbi wrote:
drivers/regulator/twl4030-regulator.c | 503 +++
Already queued for mainline...
--
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
On Wednesday 18 March 2009, hvaib...@ti.com wrote:
+
+#if defined(CONFIG_TWL4030_CORE)
+ twl4030_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL4030_LED_EN);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_PWMA_PWMAOFF);
+#endif
Hmm, I think I'm going to have to get off my butt and
1 - 100 of 738 matches
Mail list logo
