Pending July patches

Pending July patches

[Dirk Behme]

Hi,

my list of pending OMAP patches from July. Maybe its useful 
for someone.

Start:                07/01/2006
Last updated: 07/31/2006

1. [PATCH] fix PWL macro names
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007503.html

2. [PATCH] ARM: OMAP: Fix missing channel using 
omap_set_dma_priority()
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007508.html

Note: Needs check if channel 0 is really okay for OMAP24xx.

3. ARM: OMAP: omapfb: Fix 444 mode after recent LCD changes
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007525.html

4. [PATCH] ARM: OMAP: omapfb: Add Amstrad Delta LCD driver
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007526.html

5. 2420 boot BUG(): failure to map SRAM
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007578.html

6.[PATCH] ARM: OMAP: mux: add config for 16xx SPI pins
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007596.html

Please add, correct, comment if anything is wrong or 
missing. Are there any older patches pending?

Note that some patches from July were already applied to git 
by Imre (especially the omapfb/ads7846 stuff)

Cheers

Dirk

Re: Pending July patches

[Tony Lindgren]

* Dirk Behme <dirk.behme@googlemail.com> [060801 19:45]:
> Hi,
> 
> my list of pending OMAP patches from July. Maybe its useful 
> for someone.

Cool, thanks. I'll start digging through these patches, and then
tag 2.6.17-omap2 before we pull from Linus' tree.

Tony

Re: Pending July patches

[Komal Shah]

--- Tony Lindgren <tony@atomide.com> wrote:

> 
> Cool, thanks. I'll start digging through these patches, and then
> tag 2.6.17-omap2 before we pull from Linus' tree.
> 

Also, my patches on using gpmc_* apis for board_h4.c was not on the
list of upstream patches for 2.6.18 window. So, please consider them
for 2.6.19 :)

---Komal Shah
http://komalshah.blogspot.com/

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[Tony Lindgren]

* Komal Shah <komal_shah802003@yahoo.com> [060803 15:09]:
> --- Tony Lindgren <tony@atomide.com> wrote:
> 
> > 
> > Cool, thanks. I'll start digging through these patches, and then
> > tag 2.6.17-omap2 before we pull from Linus' tree.
> > 
> 
> Also, my patches on using gpmc_* apis for board_h4.c was not on the
> list of upstream patches for 2.6.18 window. So, please consider them
> for 2.6.19 :)

In general we want to have everything in sync with the mainline, and be
able to use the mainline tree for omap boards.

The reason I did not send h4 smc91x gpmc yet is that we should update it
to use gpmc_cs_set_timings() to have a nice example available for others :)

Could you try something like the sample code below for h4? You most likely
need to modify the values, but this is how Juha intended the gpmc being used.

static int __init smc91x_set_async_mode(int cs)
{
	struct gpmc_timings t;
	u32 reg;

	memset(&t, 0, sizeof(t));
	t.sync_clk = 0;
	t.cs_on = 0;
	t.adv_on = gpmc_round_ns_to_ticks(1);

	/* Read */
	t.adv_rd_off = t.adv_on + gpmc_round_ns_to_ticks(7);
	t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(1);
	t.access = t.oe_on + gpmc_round_ns_to_ticks(1);
	t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
	t.cs_rd_off = t.oe_off;
	t.rd_cycle = t.cs_rd_off + gpmc_round_ns_to_ticks(1);

	/* Write */
	t.adv_wr_off = t.adv_on + gpmc_round_ns_to_ticks(7);
	t.we_on = t.adv_wr_off + gpmc_round_ns_to_ticks(1);
	t.we_off = t.we_on + gpmc_round_ns_to_ticks(1);
	t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(1);
	t.wr_cycle = t.cs_wr_off + gpmc_round_ns_to_ticks(1);

	reg =	GPMC_CONFIG1_PAGE_LEN(2) |
		GPMC_CONFIG1_WAIT_READ_MON |
		GPMC_CONFIG1_WAIT_WRITE_MON |
		GPMC_CONFIG1_WAIT_PIN_SEL(2) |
		GPMC_CONFIG1_READTYPE_ASYNC |
		GPMC_CONFIG1_WRITETYPE_ASYNC |
		GPMC_CONFIG1_DEVICESIZE_16 |
		GPMC_CONFIG1_DEVICETYPE_NOR |
		GPMC_CONFIG1_MUXADDDATA;

	gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, reg);

	return gpmc_cs_set_timings(cs, &t);
}

Then just do something like:

ret = smc91x_set_async_mode(SMC91X_CS);
if (ret != 0) {
	printk(KERN_ERR "dklfjdkfjdkfj\n");
	return ret;
}

Also, do you have a patch to improve the 2422 vs 2423 detection? It
would be nice to get rid of this in board-h4.c:

/* FIXME: This function should be moved to some other file, gpmc.c? */

/* H4-2420's always used muxed mode, H4-2422's always use non-muxed
 *
 * Note: OMAP-GIT doesn't correctly do is_cpu_omap2422 and
 * is_cpu_omap2423
 *  correctly.  The macro needs to look at production_id not just
 *  hawkeye.
 */
static u32 is_gpmc_muxed(void)
{
	u32 mux;
	mux = get_sysboot_value();
	if ((mux & 0xF) == 0xd)
		return 1;	/* NAND config (could be either) */
	if (mux & 0x2)		/* if mux'ed */
		return 1;
	else
		return 0;
}

Regards,

Tony

Need help to understand a #pragma statment.

[Taru Varshney]

 

Hi all,
I'm trying to load bootloader on DM320's Flash memory. Flash writer is
working fine. But it's somebody else's code. I'm not able to understand what
the folowing line in the flash Writer code is doing:

#pragma DATA_SECTION (ucBOOT320Code,".bin"). 

Can anybody help me to understand the above line ??

Thanks in Advance,
Taru
  

Re: Pending July patches

[Tony Lindgren]

Hi all,

I've pushed some patches. Does anybody else have patches that should go in
before I tag 2.6.17-omap2?

 Here's the current status:

1. [PATCH] fix PWL macro names
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007503.html

Pushed.

2. [PATCH] ARM: OMAP: Fix missing channel using
omap_set_dma_priority()
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007508.html

Note: Needs check if channel 0 is really okay for OMAP24xx.

This gets only called for omap1, channel does not matter. Pushed.

3. ARM: OMAP: omapfb: Fix 444 mode after recent LCD changes
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007525.html

Pushed.

4. [PATCH] ARM: OMAP: omapfb: Add Amstrad Delta LCD driver
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007526.html

Pushed.

5. 2420 boot BUG(): failure to map SRAM
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007578.html

Pushed.

6.[PATCH] ARM: OMAP: mux: add config for 16xx SPI pins
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007596.html

Pushed.

7. [PATCH] ARM: OMAP: Apollon MMC support using OMAP2 MMC interface
http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007373.html

Pushed.

8. [PATCH] ARM: OMAP: LEDs dirver support
http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007478.html

Pushed.

9. [PATCH] USB device support on OMAP2
http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007471.html

Not pushed yet, need to leave out MMC code out of the patch and test
first.

Regards,

Tony

[PATCH] ARM: OMAP: Fix lcd_ams_delta to use new PWL defines

[Jonathan McDowell]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Fri, Aug 04, 2006 at 02:05:31PM +0300, Tony Lindgren wrote:
 
> I've pushed some patches. Does anybody else have patches that should go in
> before I tag 2.6.17-omap2?

The attached is necessary to move the Amstrad Delta LCD driver over to
the new PWL defines that have been pushed.

Signed-Off-By: Jonathan McDowell <noodles@earth.li>

J.

-- 
/-\                             |   noodles is a quick meal that is
|@/  Debian GNU/Linux Developer |               healthy
\-                              |

[-- Attachment #2: ams-delta-lcd-pwl-fix.diff --]
[-- Type: text/plain, Size: 741 bytes --]

--- drivers/video/omap/lcd_ams_delta.c.orig	2006-08-04 14:16:22.000000000 +0100
+++ drivers/video/omap/lcd_ams_delta.c	2006-08-04 14:17:59.000000000 +0100
@@ -29,7 +29,7 @@
 #include <asm/io.h>
 
 #include <asm/arch/board-ams-delta.h>
-#include <asm/arch/omap16xx.h>
+#include <asm/arch/hardware.h>
 #include <asm/arch/omapfb.h>
 
 #define AMS_DELTA_DEFAULT_CONTRAST	112
@@ -51,8 +51,8 @@ static int ams_delta_panel_enable(struct
 	ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN,
 			AMS_DELTA_LATCH2_LCD_VBLEN);
 
-	omap_writeb(1, OMAP16XX_PWL_CLK_ENABLE);
-	omap_writeb(AMS_DELTA_DEFAULT_CONTRAST, OMAP16XX_PWL_ENABLE);
+	omap_writeb(1, OMAP_PWL_CLK_ENABLE);
+	omap_writeb(AMS_DELTA_DEFAULT_CONTRAST, OMAP_PWL_ENABLE);
 
 	return 0;
 }

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [PATCH] ARM: OMAP: Fix lcd_ams_delta to use new PWL defines

[Tony Lindgren]

* Jonathan McDowell <noodles@earth.li> [060804 16:21]:
> On Fri, Aug 04, 2006 at 02:05:31PM +0300, Tony Lindgren wrote:
>  
> > I've pushed some patches. Does anybody else have patches that should go in
> > before I tag 2.6.17-omap2?
> 
> The attached is necessary to move the Amstrad Delta LCD driver over to
> the new PWL defines that have been pushed.

Pushed this one and tagged 2.6.17-omap2.

Also updating the tree to 2.6.18-rc4 so some things will probably break
a bit with the generic irq framework :)

Regards,

Tony

mcbsp

[Arnold]

Hi guys,

Is there anyone who knows about mcbsp? Is it possible
to connect a button or a led to it? If yes, how is it
done? Is it the same as programming the gpio? I hope
there's someone who could help me.

Thanks,
Oj

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: 2.6.18-rc4 / generic irq etc.

[Jonathan McDowell]

On Mon, Aug 07, 2006 at 06:22:02PM +0300, Tony Lindgren wrote:
 
> Also updating the tree to 2.6.18-rc4 so some things will probably break
> a bit with the generic irq framework :)

As a data point latest git seems to work fine on the E3 for at least
the serial console and USB host.

J.

-- 
                                            jid: noodles@jabber.earth.li
Everybody needs a little love sometime;
                                            stop hacking and fall in
love!

Re: 2.6.18-rc4 / generic irq etc.

[Tony Lindgren]

* Jonathan McDowell <noodles@earth.li> [060809 00:33]:
> On Mon, Aug 07, 2006 at 06:22:02PM +0300, Tony Lindgren wrote:
>  
> > Also updating the tree to 2.6.18-rc4 so some things will probably break
> > a bit with the generic irq framework :)
> 
> As a data point latest git seems to work fine on the E3 for at least
> the serial console and USB host.

Good to hear. GPIO is the most likely candidate to have some issues..

Tony

Re: Pending July patches

[lamikr]

It would be nice if somebody could test the functionality of usbnet and
mmc/sd with omap1 devices (omap1510)
before tagging. I got the lcd working by using the fixes now already
applied to OMAP kernel but both the MMC/SD
and usbnet failed to work at least for me & h6300.
(2.6.16 kernel worked ok.)

I can also try to test again these but for me it will go over the weekend...

Mika

Tony Lindgren wrote:
> Hi all,
>
> I've pushed some patches. Does anybody else have patches that should go in
> before I tag 2.6.17-omap2?
>
>  Here's the current status:
>
> 1. [PATCH] fix PWL macro names
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007503.html
>
> Pushed.
>
> 2. [PATCH] ARM: OMAP: Fix missing channel using
> omap_set_dma_priority()
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007508.html
>
> Note: Needs check if channel 0 is really okay for OMAP24xx.
>
> This gets only called for omap1, channel does not matter. Pushed.
>
> 3. ARM: OMAP: omapfb: Fix 444 mode after recent LCD changes
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007525.html
>
> Pushed.
>
> 4. [PATCH] ARM: OMAP: omapfb: Add Amstrad Delta LCD driver
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007526.html
>
> Pushed.
>
> 5. 2420 boot BUG(): failure to map SRAM
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007578.html
>
> Pushed.
>
> 6.[PATCH] ARM: OMAP: mux: add config for 16xx SPI pins
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007596.html
>
> Pushed.
>
> 7. [PATCH] ARM: OMAP: Apollon MMC support using OMAP2 MMC interface
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007373.html
>
> Pushed.
>
> 8. [PATCH] ARM: OMAP: LEDs dirver support
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007478.html
>
> Pushed.
>
> 9. [PATCH] USB device support on OMAP2
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007471.html
>
> Not pushed yet, need to leave out MMC code out of the patch and test
> first.
>
> Regards,
>
> Tony
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>
>   

Re: Pending July patches

[Tony Lindgren]

* lamikr <lamikr@cc.jyu.fi> [060804 17:40]:
> It would be nice if somebody could test the functionality of usbnet and
> mmc/sd with omap1 devices (omap1510)
> before tagging. I got the lcd working by using the fixes now already
> applied to OMAP kernel but both the MMC/SD
> and usbnet failed to work at least for me & h6300.
> (2.6.16 kernel worked ok.)
> 
> I can also try to test again these but for me it will go over the weekend...

No patches so I tagged it already :)

Tony

Re: Pending July patches

[lamikr]

Tony Lindgren wrote:
> * lamikr <lamikr@cc.jyu.fi> [060804 17:40]:
>> It would be nice if somebody could test the functionality of usbnet and
>> mmc/sd with omap1 devices (omap1510)
>> before tagging. I got the lcd working by using the fixes now already
>> applied to OMAP kernel but both the MMC/SD
>> and usbnet failed to work at least for me & h6300.
>> (2.6.16 kernel worked ok.)
>>
>> I can also try to test again these but for me it will go over the
weekend...
>
> No patches so I tagged it already :)
Well, I suppose2.6.17-omap2 tag means that it works with omap2 devices :-)

I tried that with my h6340 that but unfortunately I could not find fix
for the usbnet and MMC/SD card problems.
So it probably means that they are failing also for other OMAP1 devices?

I tested usbnet both with the DMA enabled and disabled in omap_udc.c
(#define USE_DMA / #undef USE_DMA) and with both of the options
the usb link was not created to my desktop.
I also tried to mount both the "Kingston Elite Pro 512 MB" SD card and
San Disk 256 MB RC-MMC MMC cards without success.

With 2.6.16 kernel, both the SD, MMC cards were working as well as the
usbnet.
Any idea, which would be the best place to add debug in in the MMC/SD
card subsystem to get more info?

Mika

Re: Pending July patches

[andrzej zaborowski]

On 08/08/06, lamikr <lamikr@cc.jyu.fi> wrote:
> Tony Lindgren wrote:
> > * lamikr <lamikr@cc.jyu.fi> [060804 17:40]:
> >> It would be nice if somebody could test the functionality of usbnet and
> >> mmc/sd with omap1 devices (omap1510)
> >> before tagging. I got the lcd working by using the fixes now already
> >> applied to OMAP kernel but both the MMC/SD
> >> and usbnet failed to work at least for me & h6300.
> >> (2.6.16 kernel worked ok.)
> >>
> >> I can also try to test again these but for me it will go over the
> weekend...
> >
> > No patches so I tagged it already :)
> Well, I suppose2.6.17-omap2 tag means that it works with omap2 devices :-)
>
> I tried that with my h6340 that but unfortunately I could not find fix
> for the usbnet and MMC/SD card problems.
> So it probably means that they are failing also for other OMAP1 devices?
>
> I tested usbnet both with the DMA enabled and disabled in omap_udc.c
> (#define USE_DMA / #undef USE_DMA) and with both of the options
> the usb link was not created to my desktop.
> I also tried to mount both the "Kingston Elite Pro 512 MB" SD card and
> San Disk 256 MB RC-MMC MMC cards without success.
>
> With 2.6.16 kernel, both the SD, MMC cards were working as well as the
> usbnet.
> Any idea, which would be the best place to add debug in in the MMC/SD
> card subsystem to get more info?

Try enabling CONFIG_MMC_DEBUG in the config, it should give at least
some basic info, e.g. what commands are sent to the card and what
error they give (timeouts, crc..).

Personally I didn't have problems with MMC/SD support on OMAP1 with
current git, except the 2GB and 4GB cards (but we have a workaround
for those). Instead I see strange things happen with the LCD -- It
takes about 1 second to initialise (in 2.6.16 you couldn't notice
this) and for some reason I had to change the .pixclock field from
12500 to 29000. The weird part is that it's not anything in the LCD
driver because I reverted this driver alone to 2.6.16 and nothing
changed. I will be investigating this.

>
> Mika
>
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>

Greetings,
Andrew
-- 
balrog 2oo6

Re: Pending July patches

[andrzej zaborowski]

On 08/08/06, andrzej zaborowski <balrog@zabor.org> wrote:
> On 08/08/06, lamikr <lamikr@cc.jyu.fi> wrote:
> > Tony Lindgren wrote:
> > > * lamikr <lamikr@cc.jyu.fi> [060804 17:40]:
> > >> It would be nice if somebody could test the functionality of usbnet and
> > >> mmc/sd with omap1 devices (omap1510)
> > >> before tagging. I got the lcd working by using the fixes now already
> > >> applied to OMAP kernel but both the MMC/SD
> > >> and usbnet failed to work at least for me & h6300.
> > >> (2.6.16 kernel worked ok.)
> > >>
> > >> I can also try to test again these but for me it will go over the
> > weekend...
> > >
> > > No patches so I tagged it already :)
> > Well, I suppose2.6.17-omap2 tag means that it works with omap2 devices :-)
> >
> > I tried that with my h6340 that but unfortunately I could not find fix
> > for the usbnet and MMC/SD card problems.
> > So it probably means that they are failing also for other OMAP1 devices?
> >
> > I tested usbnet both with the DMA enabled and disabled in omap_udc.c
> > (#define USE_DMA / #undef USE_DMA) and with both of the options
> > the usb link was not created to my desktop.
> > I also tried to mount both the "Kingston Elite Pro 512 MB" SD card and
> > San Disk 256 MB RC-MMC MMC cards without success.
> >
> > With 2.6.16 kernel, both the SD, MMC cards were working as well as the
> > usbnet.
> > Any idea, which would be the best place to add debug in in the MMC/SD
> > card subsystem to get more info?
>
> Try enabling CONFIG_MMC_DEBUG in the config, it should give at least
> some basic info, e.g. what commands are sent to the card and what
> error they give (timeouts, crc..).
>
> Personally I didn't have problems with MMC/SD support on OMAP1 with
> current git, except the 2GB and 4GB cards (but we have a workaround
> for those). Instead I see strange things happen with the LCD -- It
> takes about 1 second to initialise (in 2.6.16 you couldn't notice

Oops, actually it was in the MMC/SD driver. Because the lines
        if (!irqs_disabled())
                return -EAGAIN;
in mmc_omap_suspend were removed, LCD & backlight are now suspended
before MMC and resumed first which results in a weird visual effect
while cards are detected but no slowdown as far as I can tell.

A more serious issue I found in this version on my board (OMAP311) is
that Linux gets really confused if a card is inserted or ejected while
suspended. For example the sequence: suspend the system, eject the
card, resume, suspend again -- results in a lockup in 100% cases while
it worked in 2.6.16. I *think* it's not only me and I *think* it's not
even OMAP specific but can't test it. The lock-up is in
mmc_deselect_cards(), the MMC layer thinks a card is selected (even
though no card is inserted).

> this) and for some reason I had to change the .pixclock field from
> 12500 to 29000. The weird part is that it's not anything in the LCD

I haven't figured out why I had to change the pixclock (debugging is
difficult because 1 in 5 tries it works with the old value so you're
never sure).

> driver because I reverted this driver alone to 2.6.16 and nothing
> changed. I will be investigating this.
>
> >
> > Mika
> >
> > _______________________________________________
> > Linux-omap-open-source mailing list
> > Linux-omap-open-source@linux.omap.com
> > http://linux.omap.com/mailman/listinfo/linux-omap-open-source
> >
>
> Greetings,
> Andrew
> --
> balrog 2oo6
>

It seems a number of things were fixed which weren't broken :P
-- 
balrog 2oo6

Re: Pending July patches

[Tony Lindgren]

* andrzej zaborowski <balrog@zabor.org> [060810 07:41]:
> >
> >Personally I didn't have problems with MMC/SD support on OMAP1 with
> >current git, except the 2GB and 4GB cards (but we have a workaround
> >for those). Instead I see strange things happen with the LCD -- It
> >takes about 1 second to initialise (in 2.6.16 you couldn't notice
> 
> Oops, actually it was in the MMC/SD driver. Because the lines
>        if (!irqs_disabled())
>                return -EAGAIN;
> in mmc_omap_suspend were removed, LCD & backlight are now suspended
> before MMC and resumed first which results in a weird visual effect
> while cards are detected but no slowdown as far as I can tell.

Do you have a patch for that?

Tony

Re: Pending July patches

[andrzej zaborowski]

On 10/08/06, Tony Lindgren <tony@atomide.com> wrote:
> * andrzej zaborowski <balrog@zabor.org> [060810 07:41]:
> > >
> > >Personally I didn't have problems with MMC/SD support on OMAP1 with
> > >current git, except the 2GB and 4GB cards (but we have a workaround
> > >for those). Instead I see strange things happen with the LCD -- It
> > >takes about 1 second to initialise (in 2.6.16 you couldn't notice
> >
> > Oops, actually it was in the MMC/SD driver. Because the lines
> >        if (!irqs_disabled())
> >                return -EAGAIN;
> > in mmc_omap_suspend were removed, LCD & backlight are now suspended
> > before MMC and resumed first which results in a weird visual effect
> > while cards are detected but no slowdown as far as I can tell.
>
> Do you have a patch for that?

Well, it's just aesthetics. If you put these two lines back in
mmc_omap_suspend(), resuming will look better because LCD & backlight
resumes last, but there's a trade-off, according to
Documentation/power/devices.txt (which I only found out about today):
when a driver returns -EAGAIN, it will be suspended as last but it can
only be suspended with the whole system. Run-time suspending won't
work (i.e. "echo 1 > /sys/devices/platform/mmci-omap.1/power/state"
will fail) so it's probably not desirable.
I don't know how to force LCD to be resumed last.

>
> Tony
>

Regards,
Andrzej
-- 
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

Re: Pending July patches

[Tony Lindgren]

* andrzej zaborowski <balrog@zabor.org> [060810 11:07]:
> On 10/08/06, Tony Lindgren <tony@atomide.com> wrote:
> >* andrzej zaborowski <balrog@zabor.org> [060810 07:41]:
> >> >
> >> >Personally I didn't have problems with MMC/SD support on OMAP1 with
> >> >current git, except the 2GB and 4GB cards (but we have a workaround
> >> >for those). Instead I see strange things happen with the LCD -- It
> >> >takes about 1 second to initialise (in 2.6.16 you couldn't notice
> >>
> >> Oops, actually it was in the MMC/SD driver. Because the lines
> >>        if (!irqs_disabled())
> >>                return -EAGAIN;
> >> in mmc_omap_suspend were removed, LCD & backlight are now suspended
> >> before MMC and resumed first which results in a weird visual effect
> >> while cards are detected but no slowdown as far as I can tell.
> >
> >Do you have a patch for that?
> 
> Well, it's just aesthetics. If you put these two lines back in
> mmc_omap_suspend(), resuming will look better because LCD & backlight
> resumes last, but there's a trade-off, according to
> Documentation/power/devices.txt (which I only found out about today):
> when a driver returns -EAGAIN, it will be suspended as last but it can
> only be suspended with the whole system. Run-time suspending won't
> work (i.e. "echo 1 > /sys/devices/platform/mmci-omap.1/power/state"
> will fail) so it's probably not desirable.

OK, let's keep as it is then.

> I don't know how to force LCD to be resumed last.

Maybe the makefile order?

Tony