On Wed, 2012-08-29 at 17:20 -0700, Tony Lindgren wrote: > * Chandrabhanu Mahapatra <cmahapatra@xxxxxx> [120820 06:26]: > > Hi everyone, > > this patch series aims at cleaning up of DSS of cpu_is checks thereby making it > > more generic. > > > > The 1st patch cleans up cpu_is checks from DISPC code. > > The 2nd patch removes unused functions from DSS code. > > The 3rd patch cleans up cpu_is checks from DSS code. > > The 4th patch removes cpu_is checks from VENC code. > > The 5th patch disables VENC support on OMAP4. > > The 6th patch removes cpu_is checks from DPI code and replaces it with a > > dss feature. > > Good to see this, we need this badly to avoid blocking > single zImage effort on omaps. Can you also please take What is the issue with single zImage? How do cpu_is_ check affect it? > a look at the omap dss headers and make sure that > drivers/video/omap code does not do any #include <mach/*.h> > or <plat/*.h>? > > The driver specific headers should be now moved to live in > include/linux/platform_data directory instead of the current > arch/arm/*omap*/include/*. I had a brief look at drivers/video/omap*. Here's a brief status. I don't really know much about the old fb driver (drivers/video/omap) so my comments may not be totally correct. And all fixing I do there is done in blind, I don't have any omap1 devices. I've left out the trivial cleanups from the list (i.e. file includes a header that it doesn't need), there were a bunch of those. I'll make a patch for these. $ git grep -E "<plat|<mach" drivers/video/omap* drivers/video/omap/lcd_ams_delta.c:#include <plat/board-ams-delta.h> * Needs to be moved * lcd_ams_delta uses also omap_write/read drivers/video/omap/lcd_inn1510.c:#include <plat/fpga.h> * No idea about this. Who wants to convert the fpga support? =) drivers/video/omap/lcd_mipid.c:#include <plat/lcd_mipid.h> * Needs to be moved drivers/video/omap/lcd_osk.c:#include <plat/mux.h> * Uses omap_cfg_reg(PWL). I don't know what this is... * lcd_osk.c uses omap_write/read drivers/video/omap/lcdc.c:#include <mach/lcdc.h> * Needs to be moved drivers/video/omap/lcdc.c:#include <plat/dma.h> * Uses arch/arm/mach-omap1/lcd_dma.c. Any idea about this? Will DMA engine support OMAP1's LCD DMA? drivers/video/omap/omapfb_main.c:#include <plat/dma.h> * Uses DMA API to set DMA priority drivers/video/omap/sossi.c:#include <plat/dma.h> * Uses arch/arm/mach-omap1/lcd_dma.c drivers/video/omap2/dss/dss.c:#include <plat/cpu.h> * Uses cpu_is_* to find out the DSS version. dispc.c also uses cpu_is_* functions, but doesn't include plat/cpu.h. I know cpu_is_* checks should be removed, but is there some other file to include for the time being than plat/cpu.h? drivers/video/omap2/dss/dss_features.c:#include <plat/cpu.h> * Uses cpu_is_* to find out the DSS version drivers/video/omap2/omapfb/omapfb-ioctl.c:#include <plat/vrfb.h> drivers/video/omap2/omapfb/omapfb-ioctl.c:#include <plat/vram.h> drivers/video/omap2/omapfb/omapfb-main.c:#include <plat/vram.h> drivers/video/omap2/omapfb/omapfb-main.c:#include <plat/vrfb.h> drivers/video/omap2/omapfb/omapfb-sysfs.c:#include <plat/vrfb.h> drivers/video/omap2/vram.c:#include <plat/vram.h> drivers/video/omap2/vram.c:#include <plat/dma.h> drivers/video/omap2/vrfb.c:#include <plat/vrfb.h> drivers/video/omap2/vrfb.c:#include <plat/sdrc.h> Of these, I'm not sure how to handle. Grep shows that vram.c is only used by (the newer) omapfb, so it could be considered a part of that driver. It still needs to be built-in, as it needs to reserve memory early in the boot process (done with a call from arch/arm/plat-omap/common.c). Also board files can use a func call to define the amount of memory to allocate, but only rx51 seems to do this in the mainline. Anyway, I believe vram.c is going away when we start to use CMA. As for vrfb... I'm not really sure where it belongs. It is used by the newer omapfb and OMAP V4L2 driver. VRFB is a part of the OMAP's memory controller, so I'm not sure if it's really a normal driver. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
