Pending July patches

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

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

Tony

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

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

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

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

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

J.

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

@@ -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;
 }

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

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

No patches so I tagged it already :)

Tony

weekend...

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

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.

Greetings,
Andrew

balrog 2oo6

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

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

J.

                                            jid: [email protected]
Everybody needs a little love sometime;
                                            stop hacking and fall in
love!

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

Tony

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).

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).

It seems a number of things were fixed which weren't broken :P

balrog 2oo6

Do you have a patch for that?

Tony

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.

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

OK, let's keep as it is then.

Maybe the makefile order?

Tony