MPC5121e DIU driver - kernel crash writing alpha component

MPC5121e DIU driver - kernel crash writing alpha component

[LD]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,
I am working on Freescale MPC5121e evaluation board ADS512101 rev. 3 (M34K
processor stepping), developing a graphical application.
Just switched to ADS512101 rev. 4, 0M36P processor stepping.

I have problems with the video framebuffer driver, try to explain:

- - app is based on microwindows+fltk, framebuffer driver. On rev3 board working ok.
- - rev4 board: using the kernel from ltib 2009/06/02, just adapted fsl-diu-fb.c
and .h to support resolution and timings of my lcd panel.

The board is booting ok (NFS), but my user space app keeps crashing the kernel.

I noticed that in 0M36P processor stepping there are many changes about the
video interface (DIU), correcting some bugs of the previous stepping ; seems
that when I write to the ram area which is mapped to Panel0 of the DIU the
system randomly hangs.

After some debugging...
800x480, 32 bits per pixel, using plane1 (first plane, as described in the
processor's reference manual).
If, from user space, I write some alpha component != 0 in this plane then I have
a complete system crash.
The reference pdf says "There is no alpha component defined for plane1 because
there are no planes behind it."

I did not yet investigate about writing in other planes ; time is short...
For now, patched microwindows driver for writing 0x00 in alpha components, no
more hangs.
Reported to Freescale FAE, waiting for some answers.

Meanwhile: some suggestions about filtering alpha components in the video driver ?
I was thinking about some sort of double buffering : user space app
(fltk--->microwindows) writes in a buffer,
then the driver clears alpha to 0x00 and memcpy to the real video buffer.

Problems:
- - driver / user space sync. Vertical retrace ? ioctl ?
- - waste of memory, needs double video buffers


Any suggestions are welcome,
work in progress.

Regards
Lucio Dona'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFK4VhdvxHCsvXy9okRAtrtAKCaAectSfrHOfzcbTR7KfF9lHCY1QCeOcND
HC9fMyGUATKeDL9z9IEzAWc=
=ofjv
-----END PGP SIGNATURE-----

RE: MPC5121e DIU driver - kernel crash writing alpha component

[Chen Hongjun-R66092]

Hi,=20

Pls refer to my comment embedded.=20

> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+hong-jun.chen=3Dfreescale.com@lists.ozlabs.
> org=20
> [mailto:linuxppc-dev-bounces+hong-jun.chen=3Dfreescale.com@lists
> .ozlabs.org] On Behalf Of LD
> Sent: Friday, October 23, 2009 3:17 PM
> To: Linux ppc mailing list; Lucio Dona'
> Subject: MPC5121e DIU driver - kernel crash writing alpha component
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hi all,
> I am working on Freescale MPC5121e evaluation board ADS512101=20
> rev. 3 (M34K processor stepping), developing a graphical application.
> Just switched to ADS512101 rev. 4, 0M36P processor stepping.
>=20
> I have problems with the video framebuffer driver, try to explain:
>=20
> - - app is based on microwindows+fltk, framebuffer driver. On=20
> rev3 board working ok.
> - - rev4 board: using the kernel from ltib 2009/06/02, just=20
> adapted fsl-diu-fb.c and .h to support resolution and timings=20
> of my lcd panel.
>=20
> The board is booting ok (NFS), but my user space app keeps=20
> crashing the kernel.
>=20
> I noticed that in 0M36P processor stepping there are many=20
> changes about the video interface (DIU), correcting some bugs=20
> of the previous stepping ; seems that when I write to the ram=20
> area which is mapped to Panel0 of the DIU the system randomly hangs.
>=20
> After some debugging...
> 800x480, 32 bits per pixel, using plane1 (first plane, as=20
> described in the processor's reference manual).
> If, from user space, I write some alpha component !=3D 0 in=20
> this plane then I have a complete system crash.
> The reference pdf says "There is no alpha component defined=20
> for plane1 because there are no planes behind it."
>=20

Sure, panel0 doesn't support alpha function, so you can't operate it.

> I did not yet investigate about writing in other planes ;=20
> time is short...
> For now, patched microwindows driver for writing 0x00 in=20
> alpha components, no more hangs.
> Reported to Freescale FAE, waiting for some answers.
>=20
> Meanwhile: some suggestions about filtering alpha components=20
> in the video driver ?

You can replace panel0 with panel1, which can support alpha function.

> I was thinking about some sort of double buffering : user space app
> (fltk--->microwindows) writes in a buffer, then the driver=20
> clears alpha to 0x00 and memcpy to the real video buffer.
>=20
> Problems:
> - - driver / user space sync. Vertical retrace ? ioctl ?
> - - waste of memory, needs double video buffers
>=20
>=20
> Any suggestions are welcome,
> work in progress.
>=20
> Regards
> Lucio Dona'
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>=20
> iD8DBQFK4VhdvxHCsvXy9okRAtrtAKCaAectSfrHOfzcbTR7KfF9lHCY1QCeOcND
> HC9fMyGUATKeDL9z9IEzAWc=3D
> =3Dofjv
> -----END PGP SIGNATURE-----
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
>=20

Re: MPC5121e DIU driver - kernel crash writing alpha component

[LD]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Chen,
many thanks for your very fast answer.

If I understand well, the situation is as follows:

32 bits mode, plane1 - if I write any alpha component != 0 I have a system hang
; writing alpha components in any other plane is ok.

- -----

- From my first tries I had lockups also in 16 bits 5-6-5 modes, but in this
moment I cannot precisely track down things.
Is there something I cannot do in plane1 in 16 bits modes ?

- -----

With the previous processor stepping I was not experiencing this problem ; is it
something specific from 0M36P ?

- -----

- From this, if I cannot write something in plane1 I would think about a kernel
display driver patch: a user program ->can not<- lock the system by writing
something wrong.
So... two paths:

- - do not "publish" plane1 as /dev/fb0, but plane2 will be /dev/fb0
or
- - see suggestion about double buffering and filtering alpha components

Thanks,
best regards

Lucio Dona'

Chen Hongjun-R66092 wrote:
>> Hi, 
> 
>> Pls refer to my comment embedded. 
> 
> 
> The board is booting ok (NFS), but my user space app keeps 
> crashing the kernel.
> 
> If, from user space, I write some alpha component != 0 in 
> this plane then I have a complete system crash.
> The reference pdf says "There is no alpha component defined 
> for plane1 because there are no planes behind it."
> 
> 
>> Sure, panel0 doesn't support alpha function, so you can't operate it.
> 
> 
>> You can replace panel0 with panel1, which can support alpha function.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFK4X6XvxHCsvXy9okRApsxAJ40VJ+2/+sP4XW1qoviZlQm6m+0HQCgjkmB
p2zNmK+Eyf++r9w0fEQxZxs=
=HWm0
-----END PGP SIGNATURE-----