> 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 disable
--- On Tue, 12/28/10, Mark Brown 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...
...
>
> Simiarly here as fa
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 NAN
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* nev
--- On Tue, 12/7/10, Dave Martin wrote:
> From: Dave Martin
> 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 overlooking the
fact that there are at le
> > 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
On Fri, 2010-11-26 at 09:34 +0200, Ohad Ben-Cohen wrote:
> On Thu, Nov 25, 2010 at 10:22 PM, David Brownell wrote:
> > So there's no strong reason to think this is
> > actually "ggeneric". Function names no longer
> > specify OMAP, but without other hardware
On Thu, 2010-11-25 at 08:40 +0200, Ohad Ben-Cohen wrote:
> On Thu, Nov 25, 2010 at 5:59 AM, David Brownell 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
> &g
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 "un
e means an active trransfer,
which must not happen during OFF or other
suspend states.
Acked-by: David Brownell
> 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 sus
> >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
--- On Wed, 7/7/10, Tony Lindgren 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: send the line "u
> >> 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
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 majord...@vge
--- On Fri, 6/11/10, James Bottomley 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 to enter the
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 dr
--- On Mon, 6/7/10, Peter Zijlstra 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 CORBA,
That m
> > > 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 w
--- On Tue, 6/1/10, James Bottomley 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 state stops the pro
--- On Mon, 5/31/10, Grazvydas Ignotas 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 file, and the driv
--- On Fri, 5/28/10, Steve Sakoman 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 OTG).
> Fo
--- On Fri, 5/28/10, Sergei Shtylyov 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...
> > Also added AR
--- On Tue, 5/25/10, Kevin Hilman 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 the past few years
>
> >"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 f
--- On Fri, 5/21/10, Gupta, Ajay Kumar 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 configuration.
> > >Th
> 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
> > >> 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;
> > >> };
> > >>
> > 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 de
--- On Fri, 5/21/10, Alan Cox 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 only
> existing on certa
> -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
> 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
>
> > 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 mecha
> +#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
> > 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
> 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
multipl
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
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
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
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 con
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.
>
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. :)
>
>
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 bett
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
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:
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: mov
sed for similar 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
> CC: David Brownell
Acked-by: D
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 t
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 generi
f-by: Vikram Pandita
> Signed-off-by: Anand Gadiyar
> Signed-off-by: Ajay Kumar Gupta
Acked-by: David Brownell
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);
> +}
Bette
AP3EVM board file using
> usb_nop_xceiv_register().
> - Select NOP_USB_XCEIV for OMAP3EVM boards.
>
> Signed-off-by: Ajay Kumar Gupta
Acked-by: David Brownell
... another for-2.6.31 bugfix.
> ---
> This patch is refreshed based on David's recommendations at
> [1] a
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 Rafiudd
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 p
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.
Actualy, no it doesn't. Just adds a few fields to structs.
> DMA and FIFO
> could be enabled together for better throughput. Platform config
> parameters have been added to enable these features on any
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
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
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 pre
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
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
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, 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 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:
> On Tue, Apr 28, 2009 at 02:32:56AM -0700, David Brownell wrote:
> > On Tuesday 28 April 2009, Mark Brown wrote:
> > > >
> > > > For the record, that "incomplete constraints" message is bogus.
> &g
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 t
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 th
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
Acked-by: David Brownell
> CC: David Brownell
> ---
> arch/arm/mach-omap2/board-
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 han
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->d
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, n
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.
that API change went to mainline.
From: Manikandan Pillai
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 chang
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, idProdu
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
> ---
> drivers/mfd/twl4030-core.c |2 +-
> dr
On Thursday 23 April 2009, Mark Brown wrote:
> Since TWL4030 is in mainline now you really ought to submit this and
> the other patches you posted immediately before this one to mainline.
> It'd be best to CC David Brownell (added here) on TWL4030 regulator
> changes too, he&#x
4030 RTC to wake up the system
> from suspend
>
> Signed-off-by: Kim Kyuwon
Looks right to me. If you've tested thhis:
Acked-by: David Brownell
The reason I left that original clearly-wrong code in place
was that I had yet to see an OMAP3-based system which could
use the s
On Friday 06 February 2009, David Brownell wrote:
> From: David Brownell
>
> 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
Here's a
l contexts. If so, that seems buglike to me.
- Dave
From: David Brownell
Subject: GENIRQ: add handle_threaded_irq() flow handler
Define a new flow handler, handle_threaded_irq(), for IRQ threads
to use when chaining IRQs.
Unlike existing flow handlers, handle_simple_irq() and siblings,
this one i
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,
> > 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
On Monday 06 April 2009, Hugo Vincent wrote:
>
> Here are some of the crashes I've seen. Warning - I'm new to -rt and
> to the linux-omap tree, so I'll apologize in advance if these are just
> a result of me missing something obvious.
Thanks, I'll take a look.
> Context: using USB-gadget ethern
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
> ---
> Against latest linux-omap tree as on 6th Apr
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
http://marc.info/?l=linux-us
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 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 behav
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 i
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
device.bus_id doesn't exist any more
Signed-off-by: David Brownell
---
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 ehci_hcd_omap_drv_probe(
On Friday 03 April 2009, Russ Dill wrote:
> On Fri, Apr 3, 2009 at 7:52 PM, David Hagood 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 surprising.
>
>
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 disabl
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 "u
Ack on that v3 patch, FWIW ... but also:
On Tuesday 31 March 2009, Koen Kooi wrote:
> +static const struct twl4030_resconfig ldp_resconfig[] = {
> + /* disable regulators that u-boot left enabled; the
> + * devices' drivers should be managing these.
> + */
> + { .resource
Don't set up VSIM to power DAT4..DAT7 on boards,
like LDP, which only use DAT0..DAT3.
(That is, if this patch were correct, then it's
a bug that mmc[0].wires == 4 instead of 8...)
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...
On Monday 30 March 2009, Mark Brown wrote:
> The approach that's being taken by the mmc-twl4030 driver to disabling
> regulators is a normal and supported one
So when are you going to fix the regulator docs to report that:
ALL regulator consumers must start by enabling and
then d
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
On Wednesday 25 March 2009, Tony Lindgren wrote:
> * David Brownell [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?
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
1 - 100 of 920 matches
Mail list logo
