Xilinx framebuffer device driver - 2nd version

drivers/video/xilinxfb.c struct xilinxfb_drvdata { · line 129

Quoted 13 lines

drivers/video/xilinxfb.c +6 -0

@@ -118,6 +118,12 @@ struct xilinxfb_drvdata {
 #define to_xilinxfb_drvdata(_info) \
 	container_of(_info, struct xilinxfb_drvdata, info)
 
+#define xilinx_fb_out_be32(driverdata, offset, val) \
+	if (driverdata->use_dcr) \
+		mtdcr(driverdata->regs_phys + offset, val); \
+	else \
+		out_be32(driverdata->regs + offset, val)
+
 static int
 xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue,
 	unsigned transp, struct fb_info *fbi)

This should probably be an inline function, or use do { ... } while (0) instead, to make it less error-prone, see
http://kernelnewbies.org/FAQ/DoWhile0 for an explanation.

	Arnd <><

Add support for the video controller IP block included into Xilinx ML300 and ML403 reference designs.

Signed-off-by Andrei Konovalov <[email protected]>

---

This patch relies on the "Patchset to establish sanity in Xilinx Virtex support" by Gran Likely to have the frame buffer device registered on the platform bus. Without this patchset one needs to fill in the struct platform_device and make sure platform_device_register() is called elsewhere. The DCR access has been added but not tested - my targets are configured in the "memory mapped IO" way. I would appreciate if those having the video controller registers accessible as DCRs test the DCR mode.

This is the 2nd version that addresses what was pointed out by Arnd and Grant.
Please find the interdiff against the 1st version below, and the whole patch attached to this message Comments are welcome.

Would be nice to get this driver into mainline for the 2.6.22.

===================================================================

drivers/video/Kconfig +0 -0

@@ -1648,6 +1648,16 @@ config FB_XILINX_ROTATE
        bool "Rotate display"
        depends on FB_XILINX
 

Quoted 13 lines · Andrei Konovalov

Add support for the video controller IP block included into Xilinx ML300 and ML403 reference designs.

Signed-off-by Andrei Konovalov <[email protected]>

---

This patch relies on the "Patchset to establish sanity in Xilinx Virtex support" by Gran Likely to have the frame buffer device registered on the platform bus. Without this patchset one needs to fill in the struct platform_device and make sure platform_device_register() is called elsewhere. The DCR access has been added but not tested - my targets are configured in the "memory mapped IO" way. I would appreciate if those having the video controller registers accessible as DCRs test the DCR mode.

Quoted 3 lines

This is the 2nd version that addresses what was pointed out by Arnd and Grant.
Please find the interdiff against the 1st version below, and the whole patch attached to this message Comments are welcome.

First off; I'm an idiot. The ml403 ref design *does* use the opb2dcr bridge; and my design *does not* use DCR instructions; so I haven't been able to test direct DCR access. :-) It might just be better to drop the DCR stuff for now until it's accepted into mainline; or someone is able to test it.

I've got it running on my custom board. Seems to work well and it's
more featureful than my driver, so I'll migrate over to using yours. The design that I'm using has a different color map from the ml300 ref design. blue is at offset 0 and red offset 16 (vs. blue-16 and red-0
on the ml300 ref design). It's probably worthwhile to add those
parameters to the xilinxfb_platform_data structure.

Quoted 1 line

Would be nice to get this driver into mainline for the 2.6.22.

I certainly support getting it submitted. Have you emailed it to the linux-fb-devel list?

Can you split the driver and the platform device registration up into 2 patches?

It will probably make submission less painful; the device registration patch can go through paulus, and the driver itself through the linux-fbdev-devel list.

Quoted 7 lines

===================================================================

drivers/video/Kconfig +0 -0

@@ -1648,6 +1648,16 @@ config FB_XILINX_ROTATE
        bool "Rotate display"
        depends on FB_XILINX
 

drivers/video/Kconfig config FB_XILINX_ROTATE · line 1660

Quoted 10 lines

drivers/video/Kconfig +10 -0

+config FB_XILINX_SCR_HEIGHT
+       int "Screen height in mm"
+       depends on FB_XILINX
+       default 99
+
+config FB_XILINX_SCR_WIDTH
+       int "Screen width in mm"
+       depends on FB_XILINX
+       default 132
+

I'm not so fond of doing this via KCONFIG options; at least not at the driver level. Also, the board I'm using will have 2 of these cores, each with different display dimesions. For these parameters, I think it makes more sense for the board setup code to override virtex_device_fixup() and insert the correct values into the pdata structure before virtex_init() registers the device. Individual board ports can add Kconfig setting for the dimensions if appropriate for the system.

Cheers,
g.