Skip to contentSkip to conversation

Nokia n810 LCD (MIPID/blizzard) on 2.6.38

DISCUSSION NAK Michael Buesch 5 participants 10 messages Feb 28, 2011 – Mar 10, 2011

lore
Share & tools
lore
#0 lore raw

The n810 LCD does not work on the 2.6.38(-rc6) kernel due to changes in the OMAP GPIO-hwmod code.

The hwmod code performs a soft-reset on the GPIO module. The first GPIO module carries the MIPID "nreset" line, which is toggled due to the hwmod soft reset. This resets Blizzard and breaks it, because
it assumes the LCD was left in the state that the bootloader initialized it to:

	if (!(blizzard_read_reg(BLIZZARD_PLL_DIV) & 0x80)) {
		dev_err(fbdev->dev,
			  "controller not initialized by the bootloader\n");
		r = -ENODEV;
		goto err3;
	}

My temporary workaround to this issue is to disable soft reset for the first GPIO module:

static struct omap_hwmod omap2420_gpio1_hwmod = {
.name = "gpio1",
.flags = HWMOD_INIT_NO_RESET, /* Workaround: Don't reset the n810 MIPID */

I'm wondering if a better fix suitable for the mainline kernel inclusion could be found.
Any ideas?

Signature · 1 line
Greetings, Michael.
#1 lore raw
Quoted 9 lines · Michael Buesch

The n810 LCD does not work on the 2.6.38(-rc6) kernel due to changes in the OMAP GPIO-hwmod code.

The hwmod code performs a soft-reset on the GPIO module. The first GPIO module carries the MIPID "nreset" line, which is toggled due to the hwmod soft reset. This resets Blizzard and breaks it, because
it assumes the LCD was left in the state that the bootloader initialized it to:

so that's the bug which needs to be fixed. Unfortunately I don't have any documentation available anymore. Maybe someone from Nokia would fix that ?

Quoted 3 lines

I'm wondering if a better fix suitable for the mainline kernel inclusion could be found.
Any ideas?

Don't depend on the bootloader :-)

Signature · 1 line
balbi
#2 lore raw
Quoted 15 lines · Felipe Balbi
Quoted 9 lines · Michael Buesch

The n810 LCD does not work on the 2.6.38(-rc6) kernel due to changes in the OMAP GPIO-hwmod code.

The hwmod code performs a soft-reset on the GPIO module. The first GPIO module carries the MIPID "nreset" line, which is toggled due to the hwmod soft reset. This resets Blizzard and breaks it, because
it assumes the LCD was left in the state that the bootloader initialized it to:

so that's the bug which needs to be fixed. Unfortunately I don't have any documentation available anymore. Maybe someone from Nokia would fix that ?

Quoted 5 lines
Quoted 3 lines

I'm wondering if a better fix suitable for the mainline kernel inclusion could be found.
Any ideas?

Don't depend on the bootloader :-)

Yeah that's the obvious fix, of course. However, it requires deep knowledge of the device and/or hardware documentation. Both of which I don't have.
The driver also doesn't seem to have a maintainer.

If someone can get me documentation, I'm willing to implement the required bits to remove the bootloader dependency.

Signature · 1 line
Greetings Michael.
#3 lore raw
Quoted 22 lines · Michael Büsch
Quoted 15 lines · Felipe Balbi
Quoted 9 lines · Michael Buesch

The n810 LCD does not work on the 2.6.38(-rc6) kernel due to changes in the OMAP GPIO-hwmod code.

The hwmod code performs a soft-reset on the GPIO module. The first GPIO module carries the MIPID "nreset" line, which is toggled due to the hwmod soft reset. This resets Blizzard and breaks it, because
it assumes the LCD was left in the state that the bootloader initialized it to:

so that's the bug which needs to be fixed. Unfortunately I don't have any documentation available anymore. Maybe someone from Nokia would fix that ?

Quoted 5 lines
Quoted 3 lines

I'm wondering if a better fix suitable for the mainline kernel inclusion could be found.
Any ideas?

Don't depend on the bootloader :-)

Quoted 7 lines

Yeah that's the obvious fix, of course. However, it requires deep knowledge of the device and/or hardware documentation. Both of which I don't have.
The driver also doesn't seem to have a maintainer.

If someone can get me documentation, I'm willing to implement the required bits to remove the bootloader dependency.

Someone from Nokia might be able to help. Kai ??

Signature · 5 lines
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#4 lore raw
In reply to Michael Buesch

Hi,

Quoted 9 lines · Michael Buesch

The n810 LCD does not work on the 2.6.38(-rc6) kernel due to changes in the OMAP GPIO-hwmod code.

The hwmod code performs a soft-reset on the GPIO module. The first GPIO module carries the MIPID "nreset" line, which is toggled due to the hwmod soft reset. This resets Blizzard and breaks it, because
it assumes the LCD was left in the state that the bootloader initialized it to:

It is the design of hwmod framework that all the omap devices should be reset independent of bootloader settings. The corresponding board file/ the driver should take care of init settings of the device based on the requirement. Avoid dependency on bootloader.

Quoted 8 lines

       if (!(blizzard_read_reg(BLIZZARD_PLL_DIV) & 0x80)) { dev_err(fbdev->dev,
                         "controller not initialized by the bootloader\n"); r = -ENODEV;
               goto err3;
       }

Quoted 6 lines

My temporary workaround to this issue is to disable soft reset for the first GPIO module:

       static struct omap_hwmod omap2420_gpio1_hwmod = {
               .name           = "gpio1",
               .flags          = HWMOD_INIT_NO_RESET, /* Workaround: Don't reset the n810 MIPID */

NACK.

As the problem is specific to the board settings, this shall be handled in the board file itself.

Quoted 4 lines

I'm wondering if a better fix suitable for the mainline kernel inclusion could be found.
Any ideas?

Re-initialize the "nreset" line of the Blizzard in the corresponding board file.

- V Charulatha

Quoted 8 lines

--
Greetings, Michael.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#5 lore raw
Quoted 11 lines · Charulatha
Quoted 6 lines

My temporary workaround to this issue is to disable soft reset for the first GPIO module:

static struct omap_hwmod omap2420_gpio1_hwmod = {
.name = "gpio1",
.flags = HWMOD_INIT_NO_RESET, /* Workaround: Don't reset the n810 MIPID */

NACK.

As the problem is specific to the board settings, this shall be handled in the board file itself.

Yeah, sure. But how can I handle this in the board file? Is there a hwmod API for this?

Quoted 6 lines
Quoted 3 lines

I'm wondering if a better fix suitable for the mainline kernel inclusion could be found.
Any ideas?

Re-initialize the "nreset" line of the Blizzard in the corresponding board file.

That is not sufficient. The blizzard chip has to be reinitialized completely.
Code for that doesn't exist in the current driver. It currently depends on the bootloader doing the lowlevel init. As long as I don't have documentation for that chip, I'm stuck with that.

Signature · 1 line
Greetings Michael.
#6 lore raw
Quoted 20 lines · Michael Büsch
Quoted 11 lines · Charulatha
Quoted 6 lines

My temporary workaround to this issue is to disable soft reset for the first GPIO module:

       static struct omap_hwmod omap2420_gpio1_hwmod = {
               .name           = "gpio1",
               .flags          = HWMOD_INIT_NO_RESET, /* Workaround: Don't reset the n810 MIPID */

NACK.

As the problem is specific to the board settings, this shall be handled in the board file itself.

Yeah, sure. But how can I handle this in the board file? Is there a hwmod API for this?

Quoted 4 lines
Quoted 3 lines

I'm wondering if a better fix suitable for the mainline kernel inclusion could be found.
Any ideas?

Quoted 5 lines
Quoted 2 lines

Re-initialize the  "nreset" line of the Blizzard in the corresponding board file.

That is not sufficient. The blizzard chip has to be reinitialized completely.

Yes. I meant the same but did not mention it clearly :-(

Quoted 3 lines

Code for that doesn't exist in the current driver. It currently depends on the bootloader doing the lowlevel init. As long as I don't have documentation for that chip, I'm stuck with that.

How about the following driver?
drivers/video/omap/blizzard.c

I guess this is the same Blizzard LCD driver.

You may also be interested in the following which I came across while searching for Blizzard LCD.

https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.36/300-nokia-board.patch?rev=23082

-V Charulatha

Quoted 5 lines

--
Greetings Michael.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#7 lore raw
In reply to Michael Buesch
Quoted 7 lines · Michael Buesch

The hwmod code performs a soft-reset on the GPIO module. The first GPIO module carries the MIPID "nreset" line, which is toggled due to the hwmod soft reset. This resets Blizzard and breaks it, because
it assumes the LCD was left in the state that the bootloader initialized it to:

The long term solution is to allow passing options to the hwmod framework to not reset pins from both board-*.c files and from cmdline.

For this case it would be nice to pass info from the board-*.c file to hwmod so it knows to skip reset only for this GPIO.

For booting Linux from other OS, something like hwmod.reset_disable=all is needed to keep the LCD on.

Regrads,

Tony

#8 lore raw
In reply to Michael Buesch

Greetings Michael,

Quoted 9 lines · Michael Buesch

The n810 LCD does not work on the 2.6.38(-rc6) kernel due to changes in the OMAP GPIO-hwmod code.

The hwmod code performs a soft-reset on the GPIO module. The first GPIO module carries the MIPID "nreset" line, which is toggled due to the hwmod soft reset. This resets Blizzard and breaks it, because
it assumes the LCD was left in the state that the bootloader initialized it to:

...

Quoted 2 lines

My temporary workaround to this issue is to disable soft reset for the first GPIO module:

...

Quoted 3 lines

I'm wondering if a better fix suitable for the mainline kernel inclusion could be found.
Any ideas?

Perhaps this patch will do:

http://marc.info/?l=linux-omap&m=129971920806386&w=2

Afterwards, it should be possible to look up the GPIO1 hwmod in mach-omap2/board-n8x0.c after the call to omap2_init_common_infrastructure(), and then to call omap_hwmod_no_setup_reset() on it. Perhaps you might wish to try it?

...

Thanks for maintaining your N810 pages, they have proven quite useful over the years,

MfG,

- Paul

#9 lore raw
Quoted 8 lines · Paul Walmsley

Perhaps this patch will do:

   http://marc.info/?l=linux-omap&m=129971920806386&w=2

Afterwards, it should be possible to look up the GPIO1 hwmod in mach-omap2/board-n8x0.c after the call to omap2_init_common_infrastructure(), and then to call omap_hwmod_no_setup_reset() on it. Perhaps you might wish to try it?

Yep, this looks like the short-term fix I was looking for.

We're still working on a possible long-term fix by fixing up the blizzard driver, but that will eventually take some time, if we finally get it sorted out...

Signature · 1 line
Greetings Michael.