Re: [PATCH V5 0/6] OMAPDSS: Cleanup cpu_is checks
* Tomi Valkeinen tomi.valkei...@ti.com [120831 04:24]: On Thu, 2012-08-30 at 10:19 -0700, Tony Lindgren wrote: Hi, * Tomi Valkeinen tomi.valkei...@ti.com [120830 00:35]: On Wed, 2012-08-29 at 17:20 -0700, Tony Lindgren wrote: 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? The usage for that should only be limited to arch/arm/mach-omap2 so we can make cpu.h local as we can't include mach and plat header files from the drivers with single zImage. Ok. $ 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 Yes, that should be either mach/board-ams-delta.h, or separate driver specific headers in include/linux/platform_data. For omap1 we are not planning common zImage support, so let's just make sure we're not breaking anything there as people are still using it. Hmm, so did I understand right, for omap1 stuff we can still include from arch/arm/mach-omap1/include/mach? Yes that's a separate issue to fix that up for armv4/5 common zImage support if people want to do that later on. If so, that makes things easier. I can manage the omap2+ stuff fine, but I have no experience with omap1, nor do I have any omap1 devices. So I'd rather keep the omap1 code as it is, in fear that I'd just break it totally, and I'd rather spend my time on omap2+ code. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 0/6] OMAPDSS: Cleanup cpu_is checks
On Thu, 2012-08-30 at 10:19 -0700, Tony Lindgren wrote: Hi, * Tomi Valkeinen tomi.valkei...@ti.com [120830 00:35]: On Wed, 2012-08-29 at 17:20 -0700, Tony Lindgren wrote: 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? The usage for that should only be limited to arch/arm/mach-omap2 so we can make cpu.h local as we can't include mach and plat header files from the drivers with single zImage. Ok. $ 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 Yes, that should be either mach/board-ams-delta.h, or separate driver specific headers in include/linux/platform_data. For omap1 we are not planning common zImage support, so let's just make sure we're not breaking anything there as people are still using it. Hmm, so did I understand right, for omap1 stuff we can still include from arch/arm/mach-omap1/include/mach? If so, that makes things easier. I can manage the omap2+ stuff fine, but I have no experience with omap1, nor do I have any omap1 devices. So I'd rather keep the omap1 code as it is, in fear that I'd just break it totally, and I'd rather spend my time on omap2+ code. 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? We could make it mach/cpu.h for omap1, but ideally we would just pass DSS_VERSION_XYZ type flag in platform data on omap1. Ok. The omap1 fb driver seems to contain a few cpu_is_omap15xx() checks, nothing else. drivers/video/omap2/dss/dss_features.c:#include plat/cpu.h * Uses cpu_is_* to find out the DSS version Here too. Yep, for omap2+ I'll create a version ID that we'll pass via plat data. 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. These should eventually be in platform_data as driver specific headers. 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). Hmm it sounds like omap_vram_reserve_sdram_memblock() should be in plat-omap and just pass the pointer for later use for vram.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. OK cool. 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. Maybe just split it to platform code for the memblock stuff and pass the necessary information to the driver in platform_data? I'll try to figure out something for vrfb. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH V5 0/6] OMAPDSS: Cleanup cpu_is checks
On Wed, 2012-08-29 at 17:20 -0700, Tony Lindgren wrote: * Chandrabhanu Mahapatra cmahapa...@ti.com [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 signature.asc Description: This is a digitally signed message part
Re: [PATCH V5 0/6] OMAPDSS: Cleanup cpu_is checks
Hi, * Tomi Valkeinen tomi.valkei...@ti.com [120830 00:35]: On Wed, 2012-08-29 at 17:20 -0700, Tony Lindgren wrote: 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? The usage for that should only be limited to arch/arm/mach-omap2 so we can make cpu.h local as we can't include mach and plat header files from the drivers with single zImage. 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 Yes, that should be either mach/board-ams-delta.h, or separate driver specific headers in include/linux/platform_data. For omap1 we are not planning common zImage support, so let's just make sure we're not breaking anything there as people are still using it. * lcd_ams_delta uses also omap_write/read Limiting omap_write/read to omap1 is OK for now, unless the fix is trivial to do with ioremap + readw/writew. drivers/video/omap/lcd_inn1510.c:#include plat/fpga.h * No idea about this. Who wants to convert the fpga support? =) I'll move it to mach/fpga.h as it's omap1 specifc. 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... I'll move plat/mux.h into mach for omap1. For omap2+, we have a local mux.h and are moving to use device tree based pinctrl-single driver. * lcd_osk.c uses omap_write/read drivers/video/omap/lcdc.c:#include mach/lcdc.h * Needs to be moved This you can move to platform_data or mach for omap1? 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? I think it should eventually as it can detect the device and could automatically call those functions. Not sure if all options for configuring it are available yet in dma engine. 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? We could make it mach/cpu.h for omap1, but ideally we would just pass DSS_VERSION_XYZ type flag in platform data on omap1. drivers/video/omap2/dss/dss_features.c:#include plat/cpu.h * Uses cpu_is_* to find out the DSS version Here too. 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. These should eventually be in platform_data as driver specific headers. 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). Hmm it sounds like omap_vram_reserve_sdram_memblock() should be in plat-omap and just pass the pointer for later use for vram.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. OK cool. 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. Maybe just split it to platform code for the memblock stuff and pass the necessary information to the driver in platform_data? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 0/6] OMAPDSS: Cleanup cpu_is checks
* Chandrabhanu Mahapatra cmahapa...@ti.com [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 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/*. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 0/6] OMAPDSS: Cleanup cpu_is checks
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. Changes with respect to V1 series: 1st patch : * moved dispc_ops structure definitions from dss_features.c to dispc.c and renamed it to dispc_features * moved dispc_features definitions close to dispc_init_features() thereby eliminating various functions declarations from top of dispc.c * used __initconst before dispc_features definitions and __init before dispc_init_features() * removed definitions of _dispc_lcd_timings_ok_24xx, _dispc_lcd_timings_ok_44xx, _dispc_mgr_set_lcd_timings_hv_24xx and _dispc_mgr_set_lcd_timings_hv_44xx replacing them with appropiate variables * renamed various dispc_features structures to give consistent naming 3rd patch : * moved dss_ops structure definitions from dss_features.c to dss.c and renamed it to dss_features * removed all functions from dss_features structure and replaced them with appropiate variables * used __initconst before dss_features definitions and __init before dss_init_features() * renamed various dss_features structures to give consistent naming * renamed factor variable of dss_features structure to dss_fck_multiplier All your comments and suggestions are welcome. Refenence Tree: g...@gitorious.org:~chandrabhanu/linux-omap-dss2/chandrabhanus-linux.git dss_cleanup Chandrabhanu Mahapatra (6): OMAPDSS: DISPC: cleanup cpu_is_ checks OMAPDSS: DSS: Remove redundant functions OMAPDSS: DSS: Cleanup cpu_is_ checks OMAPDSS: VENC: Remove cpu_is_ checks ARM: OMAP: Disable venc for OMAP4 OMAPDSS: DPI: Remove cpu_is_ checks arch/arm/mach-omap2/display.c |1 - drivers/video/omap2/dss/dispc.c| 433 drivers/video/omap2/dss/dpi.c | 12 +- drivers/video/omap2/dss/dss.c | 162 ++-- drivers/video/omap2/dss/dss.h |2 - drivers/video/omap2/dss/dss_features.c |1 + drivers/video/omap2/dss/dss_features.h |1 + drivers/video/omap2/dss/venc.c | 11 - 8 files changed, 363 insertions(+), 260 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
