geodefb issues, possible patch

geodefb issues, possible patch

[Jorge Luis Zapata Muga]

hi all,

i am having problems with the geode fb driver in 2.6 kernels. it seems
that it cant ioremap the video registers. ive debug a little bit of
code and compared it to the
previous kernel tree (2.4) geode fb driver amd (i think) provided. the
old driver works perfectly on my SBP.

ok here are the things i found:
* when requesting the pci regions all the pci_resource_start,
pci_resource_len return 0's
* the hardcoded offsets for mapping are different from what i found in
the other driver, ive changed them to the older values. (to map the
video reg, display controller reg, and the fb memory)
* the display controller functions to blank the screen, configure
display, set clock freq, etc used the vid_regs  for writel readl
instead (as seen in the other driver) of the dc_vid (display
controller registers).

after changed all this i can get the frame buffer mapped, but then
suddenly the screen goes blank, and the monitor off. like it has power
down the screen,  suspend, disable the crt, or something.

i have a patch if someone is interested. the problem is that i dont
know what else to do, as i cant debug (with printf's) the driver as i
dont have a screen, how does a fb driver gets debugged? does this
driver actually works? what are the pci bar ranges? maybe i have an
issue with the pci detection?

any help will be appreciated.
thanks


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: geodefb issues, possible patch

[David Vrabel]

Jorge Luis Zapata Muga wrote:
> 
> i am having problems with the geode fb driver in 2.6 kernels. it seems
> that it cant ioremap the video registers. ive debug a little bit of
> code and compared it to the
> previous kernel tree (2.4) geode fb driver amd (i think) provided. the
> old driver works perfectly on my SBP.

What CPU and companion chip is on this board?  The current 2.6 driver
only supports the Geode GX1 with CS5530A.

What kernel version are you using?

> ok here are the things i found:
> * when requesting the pci regions all the pci_resource_start,
> pci_resource_len return 0's

Can you send the output of 'lspci -vvv -x' for the companion chip video
device?

> * the hardcoded offsets for mapping are different from what i found in
> the other driver, ive changed them to the older values. (to map the
> video reg, display controller reg, and the fb memory)

Er. I doubt this is the correct thing to do since the driver matches the
GX1 data sheet.

> * the display controller functions to blank the screen, configure
> display, set clock freq, etc used the vid_regs  for writel readl
> instead (as seen in the other driver) of the dc_vid (display
> controller registers).

I don't follow you here. The display controller has nothing to do with
the DCLK frequency nor blanking the screen -- that's purely a function
of the video device in the companion chip.

> i have a patch if someone is interested. the problem is that i dont
> know what else to do, as i cant debug (with printf's) the driver as i
> dont have a screen, how does a fb driver gets debugged?

I use a serial console.

> does this driver actually works?

It works on the board I have.

> maybe i have an issue with the pci detection?

It's possible that the BIOS not correctly initializing all PCI devices
correctly.  I don't really know a whole lot about PCI on x86 platforms,
though.

David Vrabel

ps. I'd suggest ignoring the old 2.4 driver for the most part since it's
crap and very hard to follow -- refer to the datasheets instead.
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: geodefb issues, possible patch

[Jorge Luis Zapata Muga]

Hi David, and thanks for your fast answer :)

On 11/11/05, David Vrabel <dvrabel@arcom.com> wrote:
> Jorge Luis Zapata Muga wrote:
> >
> > i am having problems with the geode fb driver in 2.6 kernels. it seems
> > that it cant ioremap the video registers. ive debug a little bit of
> > code and compared it to the
> > previous kernel tree (2.4) geode fb driver amd (i think) provided. the
> > old driver works perfectly on my SBP.
>
> What CPU and companion chip is on this board?  The current 2.6 driver
> only supports the Geode GX1 with CS5530A.
>

as seen on the chip it is a Geode GX1 with CS5530

> What kernel version are you using?

2.6.14

>
> > ok here are the things i found:
> > * when requesting the pci regions all the pci_resource_start,
> > pci_resource_len return 0's
>
> Can you send the output of 'lspci -vvv -x' for the companion chip video
> device?
>

ok here it is (i have manually copy it from the screen)

00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video
[Kahlua] (prog-if 00 [VGA])
Subsystem: Cyrix Corporation Unknown device 0001
Control: I/0+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=mdeium >TAbort-
<Tabort- <MAbort< >SERR- <PERR-
Region 0: Memory at 408000000 (32-bit, non-prefetchable) [size=8M]
Expansion ROM at <unassigned> [dissabled]
00: 78 10 04 01 03 00 80 02 00 00 00 03 00 00 80 02
10: 00 00 80 40 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 78 10 01 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


> > * the hardcoded offsets for mapping are different from what i found in
> > the other driver, ive changed them to the older values. (to map the
> > video reg, display controller reg, and the fb memory)
>
> Er. I doubt this is the correct thing to do since the driver matches the
> GX1 data sheet.
>
> > * the display controller functions to blank the screen, configure
> > display, set clock freq, etc used the vid_regs  for writel readl
> > instead (as seen in the other driver) of the dc_vid (display
> > controller registers).
>
> I don't follow you here. The display controller has nothing to do with
> the DCLK frequency nor blanking the screen -- that's purely a function
> of the video device in the companion chip.
>
> > i have a patch if someone is interested. the problem is that i dont
> > know what else to do, as i cant debug (with printf's) the driver as i
> > dont have a screen, how does a fb driver gets debugged?
>
> I use a serial console.
>
> > does this driver actually works?
>
> It works on the board I have.
>
> > maybe i have an issue with the pci detection?
>
> It's possible that the BIOS not correctly initializing all PCI devices
> correctly.  I don't really know a whole lot about PCI on x86 platforms,
> though.
>
> David Vrabel
>
> ps. I'd suggest ignoring the old 2.4 driver for the most part since it's
> crap and very hard to follow -- refer to the datasheets instead.
> --
> David Vrabel, Design Engineer
>
> Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
> Cambridge CB1 7EA, UK         Web: http://www.arcom.com/
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: geodefb issues, possible patch

[David Vrabel]

Jorge Luis Zapata Muga wrote:
> 
> ok here it is (i have manually copy it from the screen)
> 
> 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video
> [Kahlua] (prog-if 00 [VGA])
> Subsystem: Cyrix Corporation Unknown device 0001
> Control: I/0+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=mdeium >TAbort-
> <Tabort- <MAbort< >SERR- <PERR-
> Region 0: Memory at 408000000 (32-bit, non-prefetchable) [size=8M]
> Expansion ROM at <unassigned> [dissabled]

Okay, this is wrong. It should have a 4 KiB region for the video device
registers.  For example:

00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua]
(prog-if 00 [VGA])
	[...]
        Region 0: Memory at 40800000 (32-bit, non-prefetchable) [size=8M]
        Region 1: Memory at 40010000 (32-bit, non-prefetchable) [size=4K]
	[...]

Your BIOS isn't properly initializing the device resources and I'm
rather surprised it ever worked...

Now I thought the kernel was supposed to fix-up problems with PCI
resources and I'm not sure why it isn't doing it in this case.

Perhaps you could try a PCI fixup to straighten out the BARs/resources?

David Vrabel
-- 
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: geodefb issues, possible patch

[Jorge Luis Zapata Muga]

On 11/14/05, David Vrabel <dvrabel@arcom.com> wrote:
> Jorge Luis Zapata Muga wrote:
> >
> > ok here it is (i have manually copy it from the screen)
> >
> > 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video
> > [Kahlua] (prog-if 00 [VGA])
> > Subsystem: Cyrix Corporation Unknown device 0001
> > Control: I/0+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> > Stepping- SERR- FastB2B-
> > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=mdeium >TAbort-
> > <Tabort- <MAbort< >SERR- <PERR-
> > Region 0: Memory at 408000000 (32-bit, non-prefetchable) [size=8M]
> > Expansion ROM at <unassigned> [dissabled]
>
> Okay, this is wrong. It should have a 4 KiB region for the video device
> registers.  For example:
>
> 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua]
> (prog-if 00 [VGA])
>         [...]
>         Region 0: Memory at 40800000 (32-bit, non-prefetchable) [size=8M]
>         Region 1: Memory at 40010000 (32-bit, non-prefetchable) [size=4K]
>         [...]
>
> Your BIOS isn't properly initializing the device resources and I'm
> rather surprised it ever worked...
>

Well, with the previous driver (2.4) it worked because it mapped the
registers without depending on the pci bus. :)

> Now I thought the kernel was supposed to fix-up problems with PCI
> resources and I'm not sure why it isn't doing it in this case.
>
> Perhaps you could try a PCI fixup to straighten out the BARs/resources?

i am confused, maybe you can explain me a little here, i am not used
to code drivers, sorry if i am totally wrong with this assumptions.

the thing is that checking the datasheets it looks that in my case the
pci driver is only allocating the first and only region the pci device
has. looking at the datasheets it says that the 10h-13h offset of the
pci header references the base address of the memory mapped video
controller registers, in my case looking at the lspci -xx it is in
fact the frame buffer memory instead of the graphics controller
registers.

Also looking in the durango (i know its old) and in the old driver,
this memory mapped registers (region 1 in your case) reside initially
on the cpu, or at least they took the values from there (from the CCR3
register).

And finally the bios traps the access to the base addres registers and
returns the address of the framebuffer.

any ideas about this? am i correct, or all of this are just some confused ideas.


thanks in advance.

Jorge Zapata

>
> David Vrabel
> --
> David Vrabel, Design Engineer
>
> Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
> Cambridge CB1 7EA, UK         Web: http://www.arcom.com/
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id\x16845&op=click

Re: geodefb issues, possible patch

[Knut Petersen]

>i have a patch if someone is interested. the problem is that i dont
>know what else to do, as i cant debug (with printf's) the driver as i
>dont have a screen, how does a fb driver gets debugged? 
>
First of all, it´s a good idea to allow the driver to be compiled either 
as a
module or as a permanent part of the kernel. If it´s a module, it is really
helpfull if it can be unloaded / reloaded.  Allow your driver to be loaded
with vesafb or vesafb-tng compiled into the kernel, normally that should
be possible if you do not fail if you cannot get exclusive access to some
resources vesafb reserves. That way you might start with vesafb, load 
version
1 of your driver, map consoles to either one, do some testing, map all
consoles to vesafb, unload your module and load a new version. That helped
a lot in debugging cyblafb.

If you do loop for some conditions, always include a timeout.

Use printks, and have a look at the system log after a reboot.

Use a serial console or another computer connected via network.

Let the driver display some status information at a fixed location of
the screen.

First of all: write a userspace program that does a complete register dump.
Boot with vesafb and all vga=??? parameters supported by the bios and store
those register dump.  Include a register dump function in the driver and 
compare
the register values to those found for vesafb.

Don´t believe documentation that indexed registers end at index x if x is
less than the highest possible value. If bits of a value are stored in 
several
places (e.g. vga screen start address), don´t assume that the documentation
documents all high bits.

Get it right unaccelerated first.

cu,
 knut



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php