Thread (3 messages) flat view 3 messages, 3 authors, 2011-07-09

Re: [PATCH] drivers/video: use strings to specify the Freescale DIU monitor port

From: Tabi Timur-B04825 <hidden>
Date: 2011-07-09 19:37:26
Also in: linux-fbdev

Anatolij Gustschin wrote:
quoted
quoted
   	ad->pix_fmt =3D
 -		diu_ops.get_pixel_format(var->bits_per_pixel,
 -					 machine_data->monitor_port);
 +		cpu_to_be32(diu_ops.get_pixel_format(machine_data->monitor_port,
 +						     var->bits_per_pixel));
I think you can drop cpu_to_be32 here, it is somehow confusing. The
descriptor fields are LE32,
Not according to the structure definition:

struct diu_ad {
	/* Word 0(32-bit) in DDR memory */
/* 	__u16 comp; */
/* 	__u16 pixel_s:2; */
/* 	__u16 pallete:1; */
/* 	__u16 red_c:2; */
/* 	__u16 green_c:2; */
/* 	__u16 blue_c:2; */
/* 	__u16 alpha_c:3; */
/* 	__u16 byte_f:1; */
/* 	__u16 res0:3; */

	__be32 pix_fmt; /* hard coding pixel format */

I see other places where the endianness of pix_fmt is assumed.  I'll have=20
to fix those later.

When I look at the 5121 and 1022 reference manuals, it says that the area=20
descriptor is little-endian.  I think York made this register big-endian=20
so that it matches the endianness of get_pixel_format(), which doesn't=20
make much sense.  I'll have to fix the whole endianness thing with pix_fmt=
=20
in another patch.

 > get_pixel_format() returns LE32 value.

I don't think the endianness of get_pixel_format() is fixed.  It's=20
whatever the CPU native endiannes is.  That's why I added a cpu_to_be32().

Anyway, I'm not quite sure what the right answer is, but it seems obvious=20
that cpu_to_be32() is wrong.  I'll post another patch which removes it.

--=20
Timur Tabi
Linux kernel developer at Freescale=
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help