Re: Xilinx framebuffer

Hi Krzysztof,

First of all, thanks for replying so fast, I was starting to think  
that nobody could help with this...

Due to my unexperience in this field I will have to ask you some basic  
questions. What do you mean when you say 'device definition file'? I  
have been reading some things about platform devices and drivers but I  
still don't know where can I find the file which defines the features  
of my platform device.

Could be the problem that I am not configuring properly the parameters  
REG_FB_ADDR and REG_CTRL? As far as I know, these values are the  
addresses of the control registers of my TFT controller. In my case,  
the values are 0x86e00000 and 0x86e00004. Inside the first register,  
the starting address of the framebuffer can be found (which is  
0x8FC00000). Is this right or should I define the parameter  
REG_FB_ADDR as the physical address of the framebuffer directly  
(0x8FC00000)?

Thank you so much for your help Krzysztof.

Regards,

Pablo


Krzysztof Helt escribió:

Hi Pablo,


On Thu, 26 Mar 2009 12:28:00 +0100
pcolodron@uvigo.es wrote:

quoted

Hi all,

My name is Pablo and I am a new subscriber of this list.

I have seen many post here related to the framebuffer driver   
'xilinxfb.c' and I hope you can solve some doubts that I have about  
it.

I am actually trying to generate a uClinux core for my Virtex4   
development kit, which uses Microblaze and has a Xilinx TFT  
controller  IP core (which I have tested and it works correctly).

When it comes to boot the kernel, I have used some printk()  
functions  to follow the execution flow because I am quite  
unexperienced in  device drivers. I have seen something strange in  
silinxfb.c, and I  would like you to tell me if this is a common  
error of begginer users.  The issue is that I added printk() in the  
following parts of  'xilinxfb.c':

(... )

quoted

Checking the message on the console when the system boots, I can  
see  the following:

io scheduler deadline registered
io scheduler cfq registered (default)
step 1
step 2
step 3
step 4
paso 5
xgpio0 #0 at 0x81400000 mapped to 0x81400000 device: 10,185 not using IRQ
xgpio1 #1 at 0x81420000 mapped to 0x81420000 device: 10,186 not using IRQ

I think this means that the function xilinxfb_platform_probe() in   
'xilinxfb.c' is not being executed and, as a consequence, either   
xilinxfb_assing() is. It seems logic because there are no message   
about the framebuffer in the boot log (in xilinxfb_assign there are  
 some dev_dbg() functions that should show this information  
messages).

Do you have any idea about why this is happening? Other devices  
like  xgpio are recognized by the kernel and the structure of the  
drivers is  similar to the one used in xilinxfb.c. Moreover, in my  
uClinux system  I can see the following:

# ls sys/bus/platform/drivers/
i8042        uartlite     xilinx_gpio  xilinxfb
# ls sys/bus/platform/devices/
i8042          uartlite.0     xilinx_gpio.0  xilinx_gpio.1

The xilinxfb_init function is called if only the xilinxfb driver is  
loaded or during kernel boot if it is compiled into the kernel.

The xilinxfb_probe function is called if you registered a correct  
xilinxfb platform device.
Can you post a part of your device definition file which contains  a  
definition of the xilinxfb platform device?

The error seems to be in your platform definition. You have to  
register a correct platform device
for the xilinxfb. Then the probe function will be called.

Regards,
Krzysztof


----------------------------------------------------------------------
Udar sloneczny prezesa Kaczynskiego... >>> http://link.interia.pl/f2083

------------------------------------------------------------------------------

On Fri, 27 Mar 2009 10:51:53 +0100
pcolodron@uvigo.es wrote:

Hi Krzysztof,

First of all, thanks for replying so fast, I was starting to think  
that nobody could help with this...

Due to my unexperience in this field I will have to ask you some basic  
questions. What do you mean when you say 'device definition file'? I  
have been reading some things about platform devices and drivers but I  
still don't know where can I find the file which defines the features  
of my platform device.

Probably you have to define the file for your platform device. Look
how it is done for ARM sa1100 platforms:

There is a common part of definition for such a platform called
arch/arm/mach-sa1100/generic.c

Inside the file there is defined a table for the sa1100fb frame buffer
(platform device):

static struct platform_device sa11x0fb_device = {
    .name       = "sa11x0-fb",
    .id     = -1,
    .dev = {
        .coherent_dma_mask = 0xffffffff,
    },
    .num_resources  = ARRAY_SIZE(sa11x0fb_resources),
    .resource   = sa11x0fb_resources,
};

The field name is used to find a platform driver so it should
be exactly the same as the name the driver is registered with
("xilinxfb" for the xilinxfb driver).

The structure is later added to table of platform devices:

static struct platform_device *sa11x0_devices[] __initdata = {
    &sa11x0udc_device,
    &sa11x0uart1_device,
    &sa11x0uart3_device,
    &sa11x0mcp_device,
    &sa11x0ssp_device,
    &sa11x0pcmcia_device,
    &sa11x0fb_device,
    &sa11x0mtd_device,
    &sa11x0rtc_device,
};

The later structure is used to register platform devices with

platform_add_devices(sa11x0_devices, ARRAY_SIZE(sa11x0_devices));

This line calls sa1100fb_probe() function indirectly. This is what is missing
in your xilinxfb handling - the probe function is not called.

Could be the problem that I am not configuring properly the parameters  
REG_FB_ADDR and REG_CTRL? 

No. It can be problem after the probe function is called.

As far as I know, these values are the  
addresses of the control registers of my TFT controller. In my case,  
the values are 0x86e00000 and 0x86e00004. Inside the first register,  
the starting address of the framebuffer can be found (which is  
0x8FC00000).

It should be set through resources settings of the platform device
table (see above)

Is this right or should I define the parameter  
REG_FB_ADDR as the physical address of the framebuffer directly  
(0x8FC00000)?

No.

There is one more thing for the xilinxfb driver. You have to set platform_data
field of the platform device. The xilinxfb expects this field to be a pointer to
the struct xilinxfb_platform_data. See the xilinxfb sources for this structure
definition. You should fill its fields before calling the platform_add_device(s).

Kind regards,
Krzysztof


----------------------------------------------------------------------
Twoj znajomy na stronie glownej portalu? Wkrec go! ;) 
Sprawdz >>> http://link.interia.pl/f20f2


------------------------------------------------------------------------------