* Re: New MMC maintainer needed
From: Matt Fleming @ 2009-07-31 10:54 UTC (permalink / raw)
To: Pierre Ossman
Cc: Andrew Morton, linux-kernel, linux-embedded, nico, nicolas.ferre,
hskinnemoen, tony, david-b, manuel.lauss, mirq-linux, ppisa,
jarkko.lavinen, ben, saschasommer, avorontsov, oakad, ian,
HaraldWelte, JosephChan, adrian.hunter
In-Reply-To: <20090731122623.254fd0f1@mjolnir.ossman.eu>
On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote:
>
> [PATCH 0/32] mmc and omap_hsmmc patches
> http://marc.info/?t=124722953900010&r=1&w=2
>
> I haven't looked through these at all. The ones affecting the core
> probably need some thorough reviews.
>
> I did notice the patch to say which cards a controller supports though,
> and I'm very sceptical about that one. The scanning process should work
> anyway, and the performance impact should be negligible as it is only
> on init. So that patch only adds complexity and confusion IMO.
>
How much complexity does it really add? Surely it's better to give the
host controller driver writers the ability to not entertain supporting
some cards if they cannot be used? If they want to avoid the scanning
process for certain cards, why not let them?
^ permalink raw reply
* Re: [PATCH] sdio: add CD disable support
From: Ohad Ben-Cohen @ 2009-07-31 11:10 UTC (permalink / raw)
To: David Vrabel
Cc: Andrew Morton, Philip Langdale, Matt Fleming, ian, pierre,
linux-kernel, linux-embedded, nico, nicolas.ferre, hskinnemoen,
tony, david-b, manuel.lauss, mirq-l, Adrian Hunter, Madhusudhan
In-Reply-To: <4A719811.4060904@csr.com>
Hi David,
Thank you for your comments.
On Thu, Jul 30, 2009 at 3:54 PM, David Vrabel<david.vrabel@csr.com> wrote:
> Platforms may rely on the card's pull-up and not fit/configure an
> external one. There may need to be a way for host controller drivers to
> say this and prevent the disabling of the card's DAT3 pull-up.
Currently the only way to really disable the CD using this patch is by
setting the disable_cd bit on for a specific controller. We are doing so
for a specific controller to which an embedded sdio device is wired,
on certain boards. This is done using the embedded_sdio's .cccr field,
which is used instead of reading the card's cccr.
So as you correctly noted, card has no say here.
> The first sentence of this comment doesn't make sense.
Fixed;
I'll follow-up with a correction of the patch and will appreciate your review.
Thanks,
Ohad.
^ permalink raw reply
* Re: [PATCH] sdio: add CD disable support
From: Ohad Ben-Cohen @ 2009-07-31 11:16 UTC (permalink / raw)
To: Matt Fleming
Cc: Andrew Morton, Philip Langdale, ian, pierre, linux-kernel,
linux-embedded, nico, nicolas.ferre, hskinnemoen, tony, david-b,
manuel.lauss, mirq-l, Adrian Hunter, Madhusudhan
In-Reply-To: <20090730185044.GH3058@console-pimps.org>
Hi Matt,
On Thu, Jul 30, 2009 at 9:50 PM, Matt Fleming<matt@console-pimps.org> wrote:
> As David has already said, both comments need fixing up. It is the host
> controller driver that decides whether to disable the DAT[3] pull-up,
> not the card. If you make those changes then you can add my Acked-by.
I'm posting a follow-up patch with the fixes and your Ack,
will appreciate your second review.
Thanks,
Ohad.
^ permalink raw reply
* [PATCH v2] sdio: add CD disable support
From: Ohad Ben-Cohen @ 2009-07-31 11:31 UTC (permalink / raw)
To: Andrew Morton
Cc: David Vrabel, Philip Langdale, Matt Fleming, ian, pierre,
linux-kernel, linux-embedded, nico, nicolas.ferre, hskinnemoen,
tony, david-b, manuel.lauss, mirq-l, Adrian Hunter, Madhusudhan
From: Ohad Ben-Cohen <ohad@wizery.com>
Add support to disconnect the pull-up resistor on CD/DAT[3] (pin 1)
of the card. This may be desired on certain setups of boards,
controllers and embedded sdio devices which do not need the card's
pull-up. As a result, card detection is disabled and power is saved.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Acked-by: Matt Fleming <matt@console-pimps.org>
---
drivers/mmc/core/sdio.c | 34 ++++++++++++++++++++++++++++++++++
include/linux/mmc/card.h | 3 ++-
2 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index fb99ccf..a962946 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -165,6 +165,33 @@ static int sdio_enable_wide(struct mmc_card *card)
}
/*
+ * If desired, disconnect the pull-up resistor on CD/DAT[3] (pin 1)
+ * of the card. This may be required on certain setups of boards,
+ * controllers and embedded sdio device which do not need the card's
+ * pull-up. As a result, card detection is disabled and power is saved.
+ */
+static int sdio_disable_cd(struct mmc_card *card)
+{
+ int ret;
+ u8 ctrl;
+
+ if (!card->cccr.disable_cd)
+ return 0;
+
+ ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_IF, 0, &ctrl);
+ if (ret)
+ return ret;
+
+ ctrl |= SDIO_BUS_CD_DISABLE;
+
+ ret = mmc_io_rw_direct(card, 1, 0, SDIO_CCCR_IF, ctrl, NULL);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+/*
* Test if the card supports high-speed mode and, if so, switch to it.
*/
static int sdio_enable_hs(struct mmc_card *card)
@@ -392,6 +419,13 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
goto remove;
/*
+ * If needed, disconnect card detection pull-up resistor.
+ */
+ err = sdio_disable_cd(card);
+ if (err)
+ goto remove;
+
+ /*
* Initialize (but don't add) all present functions.
*/
for (i = 0;i < funcs;i++) {
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 403aa50..82a8488 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -62,7 +62,8 @@ struct sdio_cccr {
low_speed:1,
wide_bus:1,
high_power:1,
- high_speed:1;
+ high_speed:1,
+ disable_cd:1;
};
struct sdio_cis {
--
1.5.4.3
^ permalink raw reply related
* Re: New MMC maintainer needed
From: Maxim Levitsky @ 2009-07-31 13:36 UTC (permalink / raw)
To: Alex Dubov
Cc: LKML, linux-embedded, Nicolas Pitre, Nicolas Ferre,
Haavard Skinnemoen, Tony Lindgren, David Brownell, manuel.lauss,
mirq-linux, Pavel Pisa, Jarkko Lavinen, Ben Dooks, saschasommer,
avorontsov, ian, HaraldWelte, JosephChan, Adrian Hunter,
Pierre Ossman
In-Reply-To: <812689.20578.qm@web37604.mail.mud.yahoo.com>
On Wed, Jul 15, 2009 at 7:59 AM, Alex Dubov<oakad@yahoo.com> wrote:
>
>> I'm afraid the time has come for me
>> to step down as maintainer for the
>> MMC/SD/SDIO subsystem and for someone else to take over the
>> rudder. It
>> is no secret that I haven't been able to give the
>> maintainer role the
>> resources it required, and as a result it has gone from
>> being a fun
>> hobby to a burdensome chore. I was hoping it was a
>> temporary slump, but
>> this has been the norm for over a year now, so it's time
>> for me to
>> throw in the towel.
>
> What an unfortunate thing.
>
> Franky speaking, I couldn't manage any time to work on Linux
> in the last year myself. I had such a great plans for Memstick
> and such, yet none advanced.
>
> At this rate, the future of the flash cards on Linux will
> become highly uncertain.
> :-(
>
Me too.
I had plans to reverse engineer and then write drivers for my ricoh 5
in one controller
for SD and memstick mode (especialy XD)
Now I know that RE part isn't the hardest probably, but writing the
core support for XD subsystem (your was rejected I see)
I am also an owner of a jmicron controller, and thanks to you memstick
on it is supported.
What to do now?
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: flicker free booting
From: Robert Schwebel @ 2009-07-31 15:53 UTC (permalink / raw)
To: linux-embedded; +Cc: Juergen Beisert, Sascha Hauer, Wolfram Sang
In-Reply-To: <20090731152617.GW29245@pengutronix.de>
On Tue, Jun 02, 2009 at 08:35:35PM -0700, Greg KH wrote:
> On Tue, Jun 02, 2009 at 11:34:52PM +0200, Robert Schwebel wrote:
> > Could flickerfree-bootsplash be a topic? Or is that completely
> > pushed into the userspace these fastboot days?
>
> We have that working today, no in-kernel work needed other than the
> already-present KMS stuff. See the recent Moblin images for proof of
> this.
Well, I assume that the issue you've addressed is being flicker free
between the kernel and x.org; what I mean is flicker-free even with the
bootloader in mind.
What we want to address is another problem which is present on almost
all display-enabled SoC-type embedded hardware. This kind of hardware is
BIOS-free and is booted from an embedded bootloader like u-boot. These
processors are often pretty slow, being in the 200 MHz ARM926 league.
The boot scenario on these boxes looks like this:
1) power-on
2a) on NAND-only systems, pre-bootloader is fetched from NAND block
2b) bootloader starts from NAND or NOR flash
3) the bootloader fetches Linux from NAND/NOR flash
4) kernel starts
5) userspace starts
6) application starts (i.e. app against qt+dfb or gtk+dfb)
These SoCs are usually built into "devices" which don't look like PCs;
think of it as mobile phones (although our applications are usually more
industry-style, like machine controllers, measurement systems etc). Most
industry applications have been built with microcontrollers + 2x16 alpha
numeric displays in the last generation; this type of hardware has a
boot time (from power-on to full operation) of something like 0.5 s.
So what I would like to see is this:
a) power on
b) almost immediately (< 1s) a splash screen appears
c) optionally be able to do some animation, progress bar etc
d) application appears (instantanously or by fading)
At the moment, we do this by using random hacks in the kernel, which is
pretty bad. So what I'm searching for is a clean API which may be
accesptable form the Linux mainline.
Here's a proposal from my kernel team:
- u-boot initializes framebuffer on some <address> + shows image
- kernel commandline: mem=127MB framebuffer=<num>:<address>:<size>
The framebuffer is reserved at the given address (i.e. 1 MB
at the upper end of the memory, so we have to reduce the
overall memory available for Linux)
- kernel driver recognizes that the framebuffer was already set up and
skips the initialisation step (which would otherwhise result in
flicker)
A second step could be:
- Have this initial framebuffer as /dev/fb0 (mem at the end of RAM)
- In order to avoid flicker, the driver sets up a 2nd framebuffer,
in dynamically allocated memory -> /dev/fb1. This framebuffer
continues to display the splash image (or an animation). Switching
from fb0 -> fb1 is done during VSync.
- While the splash image is still visible in fb1, the application
starts, up to the point where it shows it's main screen. This usually
never works flicker-free, but we don't see it, as fb1 is visible.
- switch back to fb0 (during a VSync to avoid flicker)
- optionally discard fb1 ressources
On some hardware, the switch could be done by fading from fb1 to fb0
(i.e. on i.MX27 this should be possible).
Drivers which see the framebuffer= parameter would have to skip their
hardware initialisation step.
What do you think? Would something like this be acceptable? Other ideas?
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: flicker free booting
From: David VomLehn @ 2009-07-31 18:03 UTC (permalink / raw)
To: Robert Schwebel
Cc: linux-embedded, Juergen Beisert, Sascha Hauer, Wolfram Sang
In-Reply-To: <20090731155352.GA29245@pengutronix.de>
On Fri, Jul 31, 2009 at 05:53:52PM +0200, Robert Schwebel wrote:
> On Tue, Jun 02, 2009 at 08:35:35PM -0700, Greg KH wrote:
> > On Tue, Jun 02, 2009 at 11:34:52PM +0200, Robert Schwebel wrote:
> > > Could flickerfree-bootsplash be a topic? Or is that completely
> > > pushed into the userspace these fastboot days?
...
> So what I would like to see is this:
>
> a) power on
> b) almost immediately (< 1s) a splash screen appears
> c) optionally be able to do some animation, progress bar etc
> d) application appears (instantanously or by fading)
This is an issue that I think is common to many embedded platforms, but I'm
not sure this is the solution. (I'm not sure it's *not* the solution, either).
The question I've been looking at is: do sub-second boot times make all this
a moot point? After all, if you can bring up your graphics driver in a fraction
of a second and use *it* to display a splash screen, it seems like it would
meet your need to give almost immediate feedback to users that the system is
alive.
--
David VomLehn
^ permalink raw reply
* Re: flicker free booting
From: Robert Schwebel @ 2009-07-31 18:09 UTC (permalink / raw)
To: David VomLehn; +Cc: linux-embedded, Juergen Beisert, Sascha Hauer, Wolfram Sang
In-Reply-To: <20090731180309.GA17314@cuplxvomd02.corp.sa.net>
Hi David,
On Fri, Jul 31, 2009 at 11:03:10AM -0700, David VomLehn wrote:
> On Fri, Jul 31, 2009 at 05:53:52PM +0200, Robert Schwebel wrote:
> > On Tue, Jun 02, 2009 at 08:35:35PM -0700, Greg KH wrote:
> > > On Tue, Jun 02, 2009 at 11:34:52PM +0200, Robert Schwebel wrote:
> > > > Could flickerfree-bootsplash be a topic? Or is that completely
> > > > pushed into the userspace these fastboot days?
> ...
> > So what I would like to see is this:
> >
> > a) power on
> > b) almost immediately (< 1s) a splash screen appears
> > c) optionally be able to do some animation, progress bar etc
> > d) application appears (instantanously or by fading)
>
> This is an issue that I think is common to many embedded platforms, but I'm
> not sure this is the solution. (I'm not sure it's *not* the solution, either).
I hope it is more a call-for-discussion :-)
> The question I've been looking at is: do sub-second boot times make
> all this a moot point? After all, if you can bring up your graphics
> driver in a fraction of a second and use *it* to display a splash
> screen, it seems like it would meet your need to give almost immediate
> feedback to users that the system is alive.
Yup, that would be cool.
However, on flash-based systems in the ARM926 / 200...400 MHz class
(which is still quite common) the boot time up to the point where the
penguin appears is still about 3...4 s [1] which is too long. So I
suspect until systems become faster, we'll have no other choice than
such as scenario.
rsc
[1] we can do some benchmarking next week
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: flicker free booting
From: Bill Gatliff @ 2009-07-31 18:42 UTC (permalink / raw)
To: Robert Schwebel
Cc: David VomLehn, linux-embedded, Juergen Beisert, Sascha Hauer,
Wolfram Sang
In-Reply-To: <20090731180932.GC29245@pengutronix.de>
Robert Schwebel wrote:
>
>> The question I've been looking at is: do sub-second boot times make
>> all this a moot point? After all, if you can bring up your graphics
>> driver in a fraction of a second and use *it* to display a splash
>> screen, it seems like it would meet your need to give almost immediate
>> feedback to users that the system is alive.
>>
>
> Yup, that would be cool.
>
> However, on flash-based systems in the ARM926 / 200...400 MHz class
> (which is still quite common) the boot time up to the point where the
> penguin appears is still about 3...4 s [1] which is too long. So I
> suspect until systems become faster, we'll have no other choice than
> such as scenario.
>
Could your bootloader pre-initialize the graphics hardware to the same
mode that the Linux driver will ultimately select, and then throw up a
static graphic? That would give you some output until the driver itself
comes online.
And if the driver was in a demand-loaded module, then the static image
wouldn't disappear until just before the application that does the
animation was ready to start drawing.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: flicker free booting
From: Bill Gatliff @ 2009-07-31 18:46 UTC (permalink / raw)
To: David VomLehn
Cc: Robert Schwebel, linux-embedded, Juergen Beisert, Sascha Hauer,
Wolfram Sang
In-Reply-To: <20090731180309.GA17314@cuplxvomd02.corp.sa.net>
David VomLehn wrote:
> This is an issue that I think is common to many embedded platforms, but I'm
> not sure this is the solution. (I'm not sure it's *not* the solution, either).
> The question I've been looking at is: do sub-second boot times make all this
> a moot point? After all, if you can bring up your graphics driver in a fraction
> of a second and use *it* to display a splash screen, it seems like it would
> meet your need to give almost immediate feedback to users that the system is
> alive.
>
Those fractions-of-seconds boot times are beyond the reach of the 200
MHz-class ARM9 processors and similar, where it takes two or three
seconds just to load and uncompress the kernel from NOR or NAND flash.
And add a second or so on top of that to zeroinit the graphics
framebuffer, if your display is of any decent size and depth.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: flicker free booting
From: Bill Gatliff @ 2009-07-31 19:25 UTC (permalink / raw)
To: Robert Schwebel
Cc: linux-embedded, Juergen Beisert, Sascha Hauer, Wolfram Sang
In-Reply-To: <20090731155352.GA29245@pengutronix.de>
Robert Schwebel wrote:
> A second step could be:
>
> - Have this initial framebuffer as /dev/fb0 (mem at the end of RAM)
> - In order to avoid flicker, the driver sets up a 2nd framebuffer,
> in dynamically allocated memory -> /dev/fb1. This framebuffer
> continues to display the splash image (or an animation). Switching
> from fb0 -> fb1 is done during VSync.
>
What about double-buffering fb0 instead? That's how Android works.
> Drivers which see the framebuffer= parameter would have to skip their
> hardware initialisation step.
>
Actually, I'd rather that drivers look at the hardware itself, and
verify that the configuration matches what the parameter specifies
before making changes. That way you could use framebuffer= to
communicate the desired setup to the driver in cases where the hardware
wasn't already initialized.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: flicker free booting
From: Tim Bird @ 2009-07-31 19:48 UTC (permalink / raw)
To: Bill Gatliff
Cc: David VomLehn, Robert Schwebel, linux-embedded, Juergen Beisert,
Sascha Hauer, Wolfram Sang
In-Reply-To: <4A733C07.3050002@billgatliff.com>
Bill Gatliff wrote:
>
> Those fractions-of-seconds boot times are beyond the reach of the 200
> MHz-class ARM9 processors and similar, where it takes two or three
> seconds just to load and uncompress the kernel from NOR or NAND flash.
While I don't disagree from a practical standpoint - at Sony
using XIP we have been able to finish kernel boot on a 192 MHZ ARM9
in 186 milliseconds. In the lab, anyway?
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: flicker free booting
From: Bill Gatliff @ 2009-07-31 19:51 UTC (permalink / raw)
To: Tim Bird
Cc: David VomLehn, Robert Schwebel, linux-embedded, Juergen Beisert,
Sascha Hauer, Wolfram Sang
In-Reply-To: <4A734A95.6060703@am.sony.com>
Tim Bird wrote:
> Bill Gatliff wrote:
>
>> Those fractions-of-seconds boot times are beyond the reach of the 200
>> MHz-class ARM9 processors and similar, where it takes two or three
>> seconds just to load and uncompress the kernel from NOR or NAND flash.
>>
> While I don't disagree from a practical standpoint - at Sony
> using XIP we have been able to finish kernel boot on a 192 MHZ ARM9
> in 186 milliseconds. In the lab, anyway?
>
Yea, that's an upside of XIP: no uncompression stage. :)
I wonder, though, if the bandwidth limitations of NOR flash make the
system slower overall? I guess the bootloader could copy an
uncompressed image from flash into RAM, and then XIP it from there to
get the best of both worlds, if you could stand the time hit of the
memcpy...
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: flicker free booting
From: Robert Schwebel @ 2009-07-31 20:05 UTC (permalink / raw)
To: Tim Bird
Cc: Bill Gatliff, David VomLehn, Robert Schwebel, linux-embedded,
Juergen Beisert, Sascha Hauer, Wolfram Sang
In-Reply-To: <4A734A95.6060703@am.sony.com>
On Fri, Jul 31, 2009 at 12:48:37PM -0700, Tim Bird wrote:
> > Those fractions-of-seconds boot times are beyond the reach of the
> > 200 MHz-class ARM9 processors and similar, where it takes two or
> > three seconds just to load and uncompress the kernel from NOR or
> > NAND flash.
>
> While I don't disagree from a practical standpoint - at Sony using XIP
> we have been able to finish kernel boot on a 192 MHZ ARM9 in 186
> milliseconds. In the lab, anyway?
Wow, that's pretty fast; if that would be possible for standard
scenarios, it would indeed be better to do everything on the kernel
side.
Can you elaborate about the details of that experiment? Was that normal
XIP from NOR? What size has this kernel been?
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: flicker free booting
From: Tim Bird @ 2009-08-01 1:26 UTC (permalink / raw)
To: Robert Schwebel
Cc: Bill Gatliff, David VomLehn, linux-embedded, Juergen Beisert,
Sascha Hauer, Wolfram Sang
In-Reply-To: <20090731200555.GF29245@pengutronix.de>
Robert Schwebel wrote:
> On Fri, Jul 31, 2009 at 12:48:37PM -0700, Tim Bird wrote:
>>> Those fractions-of-seconds boot times are beyond the reach of the
>>> 200 MHz-class ARM9 processors and similar, where it takes two or
>>> three seconds just to load and uncompress the kernel from NOR or
>>> NAND flash.
>> While I don't disagree from a practical standpoint - at Sony using XIP
>> we have been able to finish kernel boot on a 192 MHZ ARM9 in 186
>> milliseconds. In the lab, anyway?
>
> Wow, that's pretty fast; if that would be possible for standard
> scenarios, it would indeed be better to do everything on the kernel
> side.
>
> Can you elaborate about the details of that experiment? Was that normal
> XIP from NOR? What size has this kernel been?
This was done quite some time ago, and it looks like my memory was
not too good. According to slides I did at the time, it was
actually 110 milliseconds. I'm sure this was a 2.4 kernel (likely
2.4.20). I couldn't find the size of the kernel used in the test, but
I think it was about 800k, uncompressed. (I'm not positive, though.)
It was normal XIP from NOR flash.
See slides 21 and 22 in the following:
http://elinux.org/images/7/78/ReducingStartupTime_v0.8.pdf
Here is some salient data:
With Compression W/ O Compression XIP
Copy 56 msec 120 msec 0 msec
Decompression 545 msec 0 msec 0 msec
Kernel execution 88 msec 88 msec 110 msec
Total: 689 msec 208 msec 110 msec
Note that copy time went up when going from a compressed to an
uncompressed kernel. Decompression time went down (to 0, no
surpise). When XIP was used, both copy time and decompression
time were eliminated, but kernel execution time for the boot
went from 88 msec to 110 msec. So XIP did incur a pretty
hefty runtime penalty.
Aaahhh, 2.4. The kernel was simpler in those days... :-)
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: New MMC maintainer needed
From: Alex Dubov @ 2009-08-01 6:53 UTC (permalink / raw)
To: Maxim Levitsky
Cc: LKML, linux-embedded, Nicolas Pitre, Nicolas Ferre,
Haavard Skinnemoen, Tony Lindgren, David Brownell, manuel.lauss,
mirq-linux, Pavel Pisa, Jarkko Lavinen, Ben Dooks, saschasommer,
avorontsov, ian, HaraldWelte, JosephChan, Adrian Hunter,
Pierre Ossman
In-Reply-To: <6d1efe520907310636g3c8fab76vc495169326fe77f1@mail.gmail.com>
>
> What to do now?
>
Lift up your spirit and get back to work?
;-)
^ permalink raw reply
* Re: New MMC maintainer needed
From: Maxim Levitsky @ 2009-08-01 7:21 UTC (permalink / raw)
To: Alex Dubov
Cc: LKML, linux-embedded, Nicolas Pitre, Nicolas Ferre,
Haavard Skinnemoen, Tony Lindgren, David Brownell, manuel.lauss,
mirq-linux, Pavel Pisa, Jarkko Lavinen, Ben Dooks, saschasommer,
avorontsov, ian, HaraldWelte, JosephChan, Adrian Hunter,
Pierre Ossman
In-Reply-To: <995113.86615.qm@web37607.mail.mud.yahoo.com>
On Fri, 2009-07-31 at 23:53 -0700, Alex Dubov wrote:
> >
> > What to do now?
> >
>
> Lift up your spirit and get back to work?
> ;-)
Not a bad idea :-)
Best regards,
Maxim Levitsky
^ permalink raw reply
* [PATCH] USB:otg:twl4030-usb.c: mark .init as subsys_initcall_sync
From: tom.leiming-Re5JQEeQqe8AvxtiuMwx3w @ 2009-08-01 12:39 UTC (permalink / raw)
To: greg-U8xfFu+wG4EAvxtiuMwx3w,
dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA, Ming Lei
From: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch fixes the .probe failure of twl4030_usb driver if
it is compiled into kernel.
Since twl4030_usb USB transceiver .probe depends on
twl4030-regulator, marking twl4030_usb_init as subsys_initcall_sync
can make it called after twl4030-regulator initialization is finished,
then twl4030_usb USB transceiver driver can be probed successfully.
Signed-off-by: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/usb/otg/twl4030-usb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 9e3e7a5..d1852d4 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -774,7 +774,7 @@ static int __init twl4030_usb_init(void)
{
return platform_driver_register(&twl4030_usb_driver);
}
-subsys_initcall(twl4030_usb_init);
+subsys_initcall_sync(twl4030_usb_init);
static void __exit twl4030_usb_exit(void)
{
--
1.6.0.GIT
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] ARM:omap3:board-omap3beagle.c:support twl4030_usb transceiver device
From: tom.leiming @ 2009-08-01 12:42 UTC (permalink / raw)
To: linux, dbrownell; +Cc: linux-arm-kernel, linux-embedded, Ming Lei
From: Ming Lei <tom.leiming@gmail.com>
This patch defines twl4030_usb_data as platform_data, which can be
passed to twl4030 mfd driver to build twl4030_usb device. Without
twl4030_usb device, we can not use musb on beagle board.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
arch/arm/mach-omap2/board-omap3beagle.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 991ac9c..b8c1ae9 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -249,6 +249,9 @@ static struct regulator_init_data beagle_vpll2 = {
.consumer_supplies = &beagle_vdvi_supply,
};
+static struct twl4030_usb_data beagle_usb = {
+ .usb_mode = T2_USB_MODE_ULPI,
+};
static struct twl4030_platform_data beagle_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end = TWL4030_IRQ_END,
@@ -259,6 +262,7 @@ static struct twl4030_platform_data beagle_twldata = {
.vsim = &beagle_vsim,
.vdac = &beagle_vdac,
.vpll2 = &beagle_vpll2,
+ .usb = &beagle_usb,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
--
1.6.0.GIT
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
^ permalink raw reply related
* [PATCH] USB:musb:fix dependency of selecting TWL4030_USB
From: tom.leiming @ 2009-08-01 13:01 UTC (permalink / raw)
To: greg, dbrownell; +Cc: linux-usb, linux-embedded, Ming Lei
From: Ming Lei <tom.leiming@gmail.com>
All machines based on OMAP34XX should select TWL_4030_USB if
they want to support musb.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
drivers/usb/musb/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 70073b1..6ac465e 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -11,7 +11,7 @@ config USB_MUSB_HDRC
depends on (USB || USB_GADGET) && HAVE_CLK
depends on !SUPERH
select NOP_USB_XCEIV if ARCH_DAVINCI
- select TWL4030_USB if MACH_OMAP_3430SDP
+ select TWL4030_USB if ARCH_OMAP34XX
select USB_OTG_UTILS
tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
help
--
1.6.0.GIT
^ permalink raw reply related
* Re: flicker free booting
From: Jamie Lokier @ 2009-08-01 14:25 UTC (permalink / raw)
To: Bill Gatliff
Cc: Robert Schwebel, linux-embedded, Juergen Beisert, Sascha Hauer,
Wolfram Sang
In-Reply-To: <4A734545.10405@billgatliff.com>
Bill Gatliff wrote:
> Actually, I'd rather that drivers look at the hardware itself, and
> verify that the configuration matches what the parameter specifies
> before making changes. That way you could use framebuffer= to
> communicate the desired setup to the driver in cases where the hardware
> wasn't already initialized.
It's a good idea when possible, but some hardware cannot be queried in
enough detail to confirm the framebuffer configuration - unless the
bootloader passes an extra parameter saying what it has done.
-- Jamie
^ permalink raw reply
* RE: [PATCH] USB:musb:fix dependency of selecting TWL4030_USB
From: Gadiyar, Anand @ 2009-08-01 14:32 UTC (permalink / raw)
To: tom.leiming@gmail.com, greg@kroah.com,
dbrownell@users.sourceforge.net
Cc: linux-usb@vger.kernel.org, linux-embedded@vger.kernel.org
In-Reply-To: <1249131718-21388-1-git-send-email-tom.leiming@gmail.com>
Ming Lei wrote:
>
> From: Ming Lei <tom.leiming@gmail.com>
>
> All machines based on OMAP34XX should select TWL_4030_USB if
> they want to support musb.
Not really. The OMAP3 EVM uses an NXP ISP1504 transceiver instead,
and so registers a NOP transceiver instead.
- Anand
>
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> ---
> drivers/usb/musb/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
> index 70073b1..6ac465e 100644
> --- a/drivers/usb/musb/Kconfig
> +++ b/drivers/usb/musb/Kconfig
> @@ -11,7 +11,7 @@ config USB_MUSB_HDRC
> depends on (USB || USB_GADGET) && HAVE_CLK
> depends on !SUPERH
> select NOP_USB_XCEIV if ARCH_DAVINCI
> - select TWL4030_USB if MACH_OMAP_3430SDP
> + select TWL4030_USB if ARCH_OMAP34XX
> select USB_OTG_UTILS
> tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
> help
> --
> 1.6.0.GIT
>
^ permalink raw reply
* Re: [PATCH] USB:musb:fix dependency of selecting TWL4030_USB
From: Ming Lei @ 2009-08-01 14:51 UTC (permalink / raw)
To: Gadiyar, Anand
Cc: greg@kroah.com, dbrownell@users.sourceforge.net,
linux-usb@vger.kernel.org, linux-embedded@vger.kernel.org
In-Reply-To: <5A47E75E594F054BAF48C5E4FC4B92AB0305398DC4@dbde02.ent.ti.com>
2009/8/1 Gadiyar, Anand <gadiyar@ti.com>:
> Ming Lei wrote:
>>
>> From: Ming Lei <tom.leiming@gmail.com>
>>
>> All machines based on OMAP34XX should select TWL_4030_USB if
>> they want to support musb.
>
> Not really. The OMAP3 EVM uses an NXP ISP1504 transceiver instead,
> and so registers a NOP transceiver instead.
Oh, I forget that twl4030 is a standalone chip, so please ignore the patch.
Maybe we should remove the dependency on MACH_OMAP_3430SDP, because
many machines may use twl4030.
--
Lei Ming
^ permalink raw reply
* Re: flicker free booting
From: Sascha Hauer @ 2009-08-03 8:19 UTC (permalink / raw)
To: Bill Gatliff
Cc: Robert Schwebel, David VomLehn, linux-embedded, Juergen Beisert,
Wolfram Sang
In-Reply-To: <4A733B1B.2000009@billgatliff.com>
On Fri, Jul 31, 2009 at 01:42:35PM -0500, Bill Gatliff wrote:
> Robert Schwebel wrote:
>>
>>> The question I've been looking at is: do sub-second boot times make
>>> all this a moot point? After all, if you can bring up your graphics
>>> driver in a fraction of a second and use *it* to display a splash
>>> screen, it seems like it would meet your need to give almost immediate
>>> feedback to users that the system is alive.
>>>
>>
>> Yup, that would be cool.
>>
>> However, on flash-based systems in the ARM926 / 200...400 MHz class
>> (which is still quite common) the boot time up to the point where the
>> penguin appears is still about 3...4 s [1] which is too long. So I
>> suspect until systems become faster, we'll have no other choice than
>> such as scenario.
>>
>
> Could your bootloader pre-initialize the graphics hardware to the same
> mode that the Linux driver will ultimately select, and then throw up a
> static graphic? That would give you some output until the driver itself
> comes online.
I implemented exactly this for the i.MX framebuffer last week. It works
by looking at the controllers physical screen start address, ioremapping
this address and copying the content to the newly allocated framebuffer.
Currently the driver still reinitilializes the controller with exactly
the same values. We could skip this initialization step depending on a
imxfb.preinitialized=1 command line parameter and read back
resolution/depth from the device in order to fill the fb_info struct.
This approach works good, I just wonder how acceptable it is for
mainline.
The downside of this approach is that we have to add
mem=${physical_mem - 1MB} to the command line.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: flicker free booting
From: Geert Uytterhoeven @ 2009-08-03 8:37 UTC (permalink / raw)
To: Sascha Hauer
Cc: Bill Gatliff, Robert Schwebel, David VomLehn, linux-embedded,
Juergen Beisert, Wolfram Sang
In-Reply-To: <20090803081905.GP2714@pengutronix.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset="ks_c_5601-1987", Size: 1714 bytes --]
On Mon, 3 Aug 2009, Sascha Hauer wrote:
> On Fri, Jul 31, 2009 at 01:42:35PM -0500, Bill Gatliff wrote:
> > Could your bootloader pre-initialize the graphics hardware to the same
> > mode that the Linux driver will ultimately select, and then throw up a
> > static graphic? That would give you some output until the driver itself
> > comes online.
>
> I implemented exactly this for the i.MX framebuffer last week. It works
> by looking at the controllers physical screen start address, ioremapping
> this address and copying the content to the newly allocated framebuffer.
> Currently the driver still reinitilializes the controller with exactly
> the same values. We could skip this initialization step depending on a
> imxfb.preinitialized=1 command line parameter and read back
> resolution/depth from the device in order to fill the fb_info struct.
>
> This approach works good, I just wonder how acceptable it is for
> mainline.
If the actual frame buffer driver doesn't do much after initialization, we
already have (at least) two similar drivers in the kernel: vesafb and offb.
Both rely on firmware (PC BIOS vs. Open Firmware) to initialize the graphics
mode. Feel free to unify all of this into `staticfb.c'...
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox