From: Ben G. <gar...@gm...> - 2006-11-16 16:30:02
|
Hi all, I'm using the Geode GX processor and the associated frame buffer driver in 2.6.19-rc5. I have a 640x480 LCD attached, without DDC support (not sure if that matters). The frame buffer driver takes 12.5 seconds to initialize. Is this normal? Relevant kernel log: [ 18.516093] io scheduler deadline registered (default) [ 18.539818] gxfb 0000:00:01.1: 16384 Kibyte of video memory at 0x41000000 [ 31.052135] Console: switching to colour frame buffer device 80x30 [ 31.070906] fb0: Geode GX frame buffer device [ 31.094200] Real Time Clock Driver v1.12ac I tried building the driver as a module, but that makes no difference -- modprobe 'hangs' for 13 seconds. I looked through the Geode driver code and didn't see anything obvious that would eat up 13 seconds. Any idea as to what is going on? Thanks, Ben |
From: James S. <jsi...@in...> - 2006-11-20 16:35:06
|
> Hi all, > > I'm using the Geode GX processor and the associated frame buffer > driver in 2.6.19-rc5. > I have a 640x480 LCD attached, without DDC support (not sure if that matters). > > The frame buffer driver takes 12.5 seconds to initialize. > > Is this normal? > > Relevant kernel log: > [ 18.516093] io scheduler deadline registered (default) > [ 18.539818] gxfb 0000:00:01.1: 16384 Kibyte of video memory at 0x41000000 > [ 31.052135] Console: switching to colour frame buffer device 80x30 > [ 31.070906] fb0: Geode GX frame buffer device > [ 31.094200] Real Time Clock Driver v1.12ac > > I tried building the driver as a module, but that makes no difference > -- modprobe 'hangs' for 13 seconds. > > I looked through the Geode driver code and didn't see anything obvious > that would eat up 13 seconds. > > Any idea as to what is going on? No idea. I do have hardware with this chipset altho I don't have a 2.6.X kernel running on it. So I will see what the problem is in the next few weeks. |
From: Ben G. <gar...@gm...> - 2006-11-20 22:48:15
|
I tracked it down to the memset_io() call in gxfb_core.c that clears all the video memory. It take 12.5 seconds to memset() a mere 16,384 Kibyte of memory. That seems a bit strange to me. What's stranger is the time it takes to clear the fb memory: The first 4 MB clear in 0.01 s each. The last 12MB are SLOW. Check out this dd output: ~ # time dd if=/dev/zero of=/dev/fb0 bs=1M count=4 4+0 records in 4+0 records out real 0m 0.04s user 0m 0.00s sys 0m 0.04s ~ # time dd if=/dev/zero of=/dev/fb0 bs=1M count=5 5+0 records in 5+0 records out real 0m 1.08s user 0m 0.00s sys 0m 1.08s ~ # time dd if=/dev/zero of=/dev/fb0 bs=1M count=10 10+0 records in 10+0 records out real 0m 6.29s user 0m 0.00s sys 0m 6.29s ~ # time dd if=/dev/zero of=/dev/fb0 bs=1M count=16 16+0 records in 16+0 records out real 0m 12.54s user 0m 0.00s sys 0m 12.54s Removing the memset_io() didn't seem to affect anything other than speeding the boot by 12.5 seconds. Would anyone object to a patch that removes the call to memset_io() ? If there's some reason why that shouldn't be removed, is it OK to reduce the memset_io() to clear the memory used by the current resolution (xres * yres * bpp / 8)? Thanks, Ben On 11/20/06, James Simmons <jsi...@in...> wrote: > > > Hi all, > > > > I'm using the Geode GX processor and the associated frame buffer > > driver in 2.6.19-rc5. > > I have a 640x480 LCD attached, without DDC support (not sure if that matters). > > > > The frame buffer driver takes 12.5 seconds to initialize. > > > > Is this normal? > > > > Relevant kernel log: > > [ 18.516093] io scheduler deadline registered (default) > > [ 18.539818] gxfb 0000:00:01.1: 16384 Kibyte of video memory at 0x41000000 > > [ 31.052135] Console: switching to colour frame buffer device 80x30 > > [ 31.070906] fb0: Geode GX frame buffer device > > [ 31.094200] Real Time Clock Driver v1.12ac > > > > I tried building the driver as a module, but that makes no difference > > -- modprobe 'hangs' for 13 seconds. > > > > I looked through the Geode driver code and didn't see anything obvious > > that would eat up 13 seconds. > > > > Any idea as to what is going on? > > No idea. I do have hardware with this chipset altho I don't have a 2.6.X > kernel running on it. So I will see what the problem is in the next few > weeks. > > |
From: Jordan C. <jor...@am...> - 2006-11-20 23:14:07
|
On 16/11/06 10:29 -0600, Ben Gardner wrote: > Hi all, > > I'm using the Geode GX processor and the associated frame buffer > driver in 2.6.19-rc5. > I have a 640x480 LCD attached, without DDC support (not sure if that > matters). > > The frame buffer driver takes 12.5 seconds to initialize. > > Is this normal? It shouldn't be. We're beating the stuffing out of this driver for the OLPCs, and people certainly would have complained loudly if it didn't work. We are building it in (rather then as a module) so its not exactly an equivalent test. Can you get any indication of where the break down is happening during the init sequence? Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. <www.amd.com/embeddedprocessors> |
From: Jordan C. <jor...@am...> - 2006-11-21 00:31:02
Attachments:
patch_011
|
On 20/11/06 16:47 -0600, Ben Gardner wrote: > I tracked it down to the memset_io() call in gxfb_core.c that clears > all the video memory. > > It take 12.5 seconds to memset() a mere 16,384 Kibyte of memory. > That seems a bit strange to me. > > What's stranger is the time it takes to clear the fb memory: > The first 4 MB clear in 0.01 s each. > The last 12MB are SLOW. Hmmm - thats interesting. One thing about the current gxfb driver is that it assumes a 16Mb framebuffer, which may or may not be what you have, since the amount of memory that is assigned to the graphics engine is configurable. Its possible that you only have 4Mb of memory assigned to the graphics engine, and that memsetting further is out being subtractively decoded on the PCI bus and going nowhere slowly. The attached patch queries the BIOS for the true amount of memory that is configured. The patch has been kicking around in the Geode git tree and -mm for a while so it should be sane. Give it a try and see if it helps. Jordan |
From: James S. <jsi...@in...> - 2006-11-21 15:07:25
|
Thank you :-) If this works it will save me alot of trouble. On Mon, 20 Nov 2006, Jordan Crouse wrote: > On 20/11/06 16:47 -0600, Ben Gardner wrote: > > I tracked it down to the memset_io() call in gxfb_core.c that clears > > all the video memory. > > > > It take 12.5 seconds to memset() a mere 16,384 Kibyte of memory. > > That seems a bit strange to me. > > > > What's stranger is the time it takes to clear the fb memory: > > The first 4 MB clear in 0.01 s each. > > The last 12MB are SLOW. > > Hmmm - thats interesting. One thing about the current gxfb driver is that > it assumes a 16Mb framebuffer, which may or may not be what you have, since > the amount of memory that is assigned to the graphics engine is configurable. > > Its possible that you only have 4Mb of memory assigned to the graphics > engine, and that memsetting further is out being subtractively decoded on > the PCI bus and going nowhere slowly. > > The attached patch queries the BIOS for the true amount of memory that > is configured. The patch has been kicking around in the Geode git tree and > -mm for a while so it should be sane. Give it a try and see if it helps. > > Jordan > |
From: Ben G. <gar...@gm...> - 2006-11-21 14:44:10
|
Hi Jordan, Now that you mention it, the kernel logs say it has 123 MB of LOWMEM, so it must have 4 MB allocated to video memory. (128 MB total). I'll try the patch on Monday -- I'm on holiday and don't have access to the hardware. If it works, (and I assume it will), can we get this pushed into the main kernel tree? IMO, this is a bug fix, not a new feature. =) Thanks, Ben On 11/20/06, Jordan Crouse <jor...@am...> wrote: > On 20/11/06 16:47 -0600, Ben Gardner wrote: > > I tracked it down to the memset_io() call in gxfb_core.c that clears > > all the video memory. > > > > It take 12.5 seconds to memset() a mere 16,384 Kibyte of memory. > > That seems a bit strange to me. > > > > What's stranger is the time it takes to clear the fb memory: > > The first 4 MB clear in 0.01 s each. > > The last 12MB are SLOW. > > Hmmm - thats interesting. One thing about the current gxfb driver is that > it assumes a 16Mb framebuffer, which may or may not be what you have, since > the amount of memory that is assigned to the graphics engine is configurable. > > Its possible that you only have 4Mb of memory assigned to the graphics > engine, and that memsetting further is out being subtractively decoded on > the PCI bus and going nowhere slowly. > > The attached patch queries the BIOS for the true amount of memory that > is configured. The patch has been kicking around in the Geode git tree and > -mm for a while so it should be sane. Give it a try and see if it helps. > > Jordan > > > Author: Jordan Crouse <jor...@am...> > Date: Mon May 15 20:54:51 2006 -0600 > > FB: Get the Geode GX frambuffer size from the BIOS > > Use the Geode GX BIOS virtual registers to get the actual size of the > framebuffer. > > Signed-off-by: Jordan Crouse <jor...@am...> > > diff --git a/drivers/video/geode/display_gx.c b/drivers/video/geode/display_gx.c > index 825c340..0245169 100644 > --- a/drivers/video/geode/display_gx.c > +++ b/drivers/video/geode/display_gx.c > @@ -21,10 +21,19 @@ #include <asm/delay.h> > #include "geodefb.h" > #include "display_gx.h" > > -int gx_frame_buffer_size(void) > +unsigned int gx_frame_buffer_size(void) > { > - /* Assuming 16 MiB. */ > - return 16*1024*1024; > + unsigned int val; > + > + /* FB size is reported by a virtual register */ > + /* Virtual register class = 0x02 */ > + /* VG_MEM_SIZE(512Kb units) = 0x00 */ > + > + outw(0xFC53, 0xAC1C); > + outw(0x0200, 0xAC1C); > + > + val = (unsigned int)(inw(0xAC1E)) & 0xFFl; > + return (val << 19); > } > > int gx_line_delta(int xres, int bpp) > diff --git a/drivers/video/geode/display_gx.h b/drivers/video/geode/display_gx.h > index 86c6233..41e79f4 100644 > --- a/drivers/video/geode/display_gx.h > +++ b/drivers/video/geode/display_gx.h > @@ -11,7 +11,7 @@ > #ifndef __DISPLAY_GX_H__ > #define __DISPLAY_GX_H__ > > -int gx_frame_buffer_size(void); > +unsigned int gx_frame_buffer_size(void); > int gx_line_delta(int xres, int bpp); > > extern struct geode_dc_ops gx_dc_ops; > > > > |
From: Ben G. <gar...@gm...> - 2006-11-27 16:28:09
|
Hi Jordan, > > Author: Jordan Crouse <jor...@am...> > > Date: Mon May 15 20:54:51 2006 -0600 > > > > FB: Get the Geode GX frambuffer size from the BIOS > > > > Use the Geode GX BIOS virtual registers to get the actual size of the > > framebuffer. > > > > Signed-off-by: Jordan Crouse <jor...@am...> The patch works. The frame buffer size now matches what is really there (4 MB). Out of curiosity, where are the magic registers (0xAC1C, 0xAC1E) documented? I searched "AMD Geode GX Processors Data Book", but had no luck... Also, I notice that the pci_resource_len() shows 16 MB, even though the resource should only cover 4 MB. I assume this is a BIOS bug... =) Is there anything I can do to help get this pushed into the 2.6.19 kernel? Thanks, Ben |
From: Jordan C. <jor...@am...> - 2006-11-27 18:31:21
|
On 27/11/06 10:28 -0600, Ben Gardner wrote: > Out of curiosity, where are the magic registers (0xAC1C, 0xAC1E) documented? > I searched "AMD Geode GX Processors Data Book", but had no luck... Those are virtual magic registers courtesy of our VSA. The document is on the Developers website, though its probably time that I go down and throw things until the technical marketing department agrees to put that document on the public site as well. > Also, I notice that the pci_resource_len() shows 16 MB, even though > the resource should only cover 4 MB. I assume this is a BIOS bug... > =) You say bug, I say limitation... :) IIRC, PCI resource sizes can only be powers of two, but the video memory doesn't nessesarly need to be a power of two. So the VSA just sets the PCI resource to 16MB and expects the code to access the virtual register, as you have experienced. > Is there anything I can do to help get this pushed into the 2.6.19 kernel? Ask folks more important then me... :) I don't know if this really qualifies for a -rc release. There should be nothing standing in our way for 2.6.20, though (I hope). Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. <www.amd.com/embeddedprocessors> |
From: James S. <jsi...@in...> - 2006-11-27 18:21:36
|
> Hi Jordan, > > > > Author: Jordan Crouse <jor...@am...> > > > Date: Mon May 15 20:54:51 2006 -0600 > > > > > > FB: Get the Geode GX frambuffer size from the BIOS > > > > > > Use the Geode GX BIOS virtual registers to get the actual size of the > > > framebuffer. > > > > > > Signed-off-by: Jordan Crouse <jor...@am...> > > The patch works. The frame buffer size now matches what is really there (4 > MB). > > Out of curiosity, where are the magic registers (0xAC1C, 0xAC1E) documented? > I searched "AMD Geode GX Processors Data Book", but had no luck... > > Also, I notice that the pci_resource_len() shows 16 MB, even though > the resource should only cover 4 MB. I assume this is a BIOS bug... > =) > > Is there anything I can do to help get this pushed into the 2.6.19 kernel? Jordan can you repost the patch and CC andrew morton with it so the patch will be in the -mm tree. Thank you. |
From: Jordan C. <jor...@am...> - 2006-11-27 18:37:06
|
> Jordan can you repost the patch and CC andrew morton with it so the patch > will be in the -mm tree. Thank you. Its in the geode GIT tree (http://git.infradead.org/?p=users/jcrouse/geode.git;a=summary), and I believe that Andrew already pulls from there - so all should be well. Am I right in saying that? Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. <www.amd.com/embeddedprocessors> |
From: Andrew M. <ak...@os...> - 2006-11-27 19:55:17
|
On Mon, 27 Nov 2006 11:39:30 -0700 "Jordan Crouse" <jor...@am...> wrote: > > Jordan can you repost the patch and CC andrew morton with it so the patch > > will be in the -mm tree. Thank you. > > Its in the geode GIT tree > (http://git.infradead.org/?p=users/jcrouse/geode.git;a=summary), and I > believe that Andrew already pulls from there - so all should be > well. Am I right in saying that? > I was including git://git.infradead.org/users/jcrouse/geode.git but I tossed it out a few weeks back due, I think, to unpleasant interactions with git-cryptodev. I'll bring git-geode back, see what happens. |
From: Andrew M. <ak...@os...> - 2006-11-27 20:35:55
|
On Mon, 27 Nov 2006 11:54:03 -0800 Andrew Morton <ak...@os...> wrote: > I'll bring git-geode back, see what happens. patching file arch/i386/Kconfig Hunk #1 succeeded at 752 (offset 11 lines). patching file arch/i386/Makefile.cpu Hunk #1 succeeded at 39 (offset 1 line). patching file arch/i386/boot/setup.S Hunk #1 succeeded at 405 (offset 11 lines). Hunk #2 succeeded at 1022 (offset 13 lines). patching file drivers/crypto/Kconfig Hunk #2 succeeded at 65 with fuzz 2 (offset 13 lines). patching file drivers/crypto/Makefile Hunk #1 succeeded at 1 with fuzz 1. The next patch would create the file drivers/crypto/geode-aes.c, which already exists! Applying it anyway. patching file drivers/crypto/geode-aes.c Patch attempted to create file drivers/crypto/geode-aes.c, which already exists. Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file drivers/crypto/geode-aes.c.rej The next patch would create the file drivers/crypto/geode-aes.h, which already exists! Applying it anyway. patching file drivers/crypto/geode-aes.h Patch attempted to create file drivers/crypto/geode-aes.h, which already exists. Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file drivers/crypto/geode-aes.h.rej It seems that there's duplication between Herbert's git-cryptodev tree and your git-geode tree. What's the story here? |
From: Jordan C. <jor...@am...> - 2006-11-27 21:02:24
|
On 27/11/06 12:35 -0800, Andrew Morton wrote: > It seems that there's duplication between Herbert's git-cryptodev tree > and your git-geode tree. > > What's the story here? Does - I'm an idiot count as an explanation? I committed the crime of a duplicate commit (well, actually several crimes). Go ahead and pull the tree from your list. I've decided to rebuild the tree from scratch without the newbie behavior. I'll let you know when its clean again. Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. <www.amd.com/embeddedprocessors> |