Re: [PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver
On Thu, Aug 21, 2014 at 12:36 AM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Aug 19, 2014 at 09:02:39PM -0700, Stéphane Marchesin wrote: On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote: Hi Thierry, On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote: Register exynos_dp_panel before the list of exynos crtcs and connectors are probed. This is needed because exynos_dp_panel should be registered to the drm_panel list via panel-exynos-dp probe, i.e much before exynos_dp_bind calls of_drm_find_panel(). Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Changes since V1: Added platform_driver_unregister(exynos_dp_panel_driver) to exynos_drm_platform_remove as per Jingoo Han's correction drivers/gpu/drm/exynos/exynos_drm_drv.c | 15 +++ drivers/gpu/drm/exynos/exynos_drm_drv.h |1 + 2 files changed, 16 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 1d653f8..2db7f67 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) goto err_unregister_ipp_drv; #endif +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP + ret = platform_driver_register(exynos_dp_panel_driver); + if (ret 0) + goto err_unregister_dp_panel; +#endif No, this is not how you're supposed to use DRM panel drivers. The idea is that you write a standalone driver for a given panel. What you do here has a number of problems. For one it's a driver that's tightly coupled to Exynos SoCs. But if I have a different SoC that uses the same panel I want to be able to use the same driver, and not have to rewrite the driver for my SoC. Another problem is that you're assuming here that the driver is built in and it will break if you try to build either Exynos DRM or the panel driver as a module. This is perhaps nothing you care about right now, but eventually people will want to ship a single kernel that can run on a number of SoCs. But if we keep adding things like this, that kernel will keep growing in size until it no longer fits in any kind of memory. Thierry I completely agree with you in this! Yes, this is not acceptable, but I want to know an acceptable workaround for the situation below: I register the driver using module_init(). And, exynos_drm gets probed much before the panel driver probe happens. So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm tries to call of_drm_find_panel which always returns NULL. That's a situation that your driver needs to be able to deal with. The driver registration order doesn't matter one bit. It may happen to work most of the time, but as soon as one of the resources that your panel driver needs isn't there when the panel is probed, then it won't be registered and of_drm_find_panel() will still return NULL. Usually the right thing to do in that case would be to return (and propagate) -EPROBE_DEFER so that your driver's probe is deferred and retried when other drivers have been probed. That way it should eventually get a non-NULL panel. So I just gave this (drm_panel + probe deferring) a shot on exynos, and correctly reacting to -EPROBE_DEFER postpones DP initialization by approximately 1.5 second. Is there a good way to handle that? As it stands, this isn't usable. How much is 1.5 seconds compared to the overall boot time of the device? 1.5s is 15-20% of my boot time (if you count the boot time from firmware start to login prompt, otherwise it's more). Note that on other platforms, we've seen this take as much as 5 or 6s, but for the exynos case it is only 1.5s. What exactly is causing this 1.5 second delay? A regulator isn't ready, and then drm_panel returns defer. Then the whole drm driver init is deferred. This really is a fundamental issue with deferred probing and the issue has come up several times in the past. A couple of possible solutions have been proposed, with the latest being here[0] I think. That ended in a bit of a debacle, unfortunately, but on of the outcomes was that a lot of the ordering problems could be fixed by using phandle references to track dependencies. I'm not aware of anyone working on that right now, presumably because everyone is busy getting features merged rather than optimizing boot speed. Yes, I don't believe boot time ordering will ever happen upstream, but then the current implementation with EPROBE_DEFER isn't usable either. Any ideas? ATM it seems like the only way out is to just write my own dt format
Re: [PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver
On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote: Hi Thierry, On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote: Register exynos_dp_panel before the list of exynos crtcs and connectors are probed. This is needed because exynos_dp_panel should be registered to the drm_panel list via panel-exynos-dp probe, i.e much before exynos_dp_bind calls of_drm_find_panel(). Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Changes since V1: Added platform_driver_unregister(exynos_dp_panel_driver) to exynos_drm_platform_remove as per Jingoo Han's correction drivers/gpu/drm/exynos/exynos_drm_drv.c | 15 +++ drivers/gpu/drm/exynos/exynos_drm_drv.h |1 + 2 files changed, 16 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 1d653f8..2db7f67 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) goto err_unregister_ipp_drv; #endif +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP + ret = platform_driver_register(exynos_dp_panel_driver); + if (ret 0) + goto err_unregister_dp_panel; +#endif No, this is not how you're supposed to use DRM panel drivers. The idea is that you write a standalone driver for a given panel. What you do here has a number of problems. For one it's a driver that's tightly coupled to Exynos SoCs. But if I have a different SoC that uses the same panel I want to be able to use the same driver, and not have to rewrite the driver for my SoC. Another problem is that you're assuming here that the driver is built in and it will break if you try to build either Exynos DRM or the panel driver as a module. This is perhaps nothing you care about right now, but eventually people will want to ship a single kernel that can run on a number of SoCs. But if we keep adding things like this, that kernel will keep growing in size until it no longer fits in any kind of memory. Thierry I completely agree with you in this! Yes, this is not acceptable, but I want to know an acceptable workaround for the situation below: I register the driver using module_init(). And, exynos_drm gets probed much before the panel driver probe happens. So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm tries to call of_drm_find_panel which always returns NULL. That's a situation that your driver needs to be able to deal with. The driver registration order doesn't matter one bit. It may happen to work most of the time, but as soon as one of the resources that your panel driver needs isn't there when the panel is probed, then it won't be registered and of_drm_find_panel() will still return NULL. Usually the right thing to do in that case would be to return (and propagate) -EPROBE_DEFER so that your driver's probe is deferred and retried when other drivers have been probed. That way it should eventually get a non-NULL panel. So I just gave this (drm_panel + probe deferring) a shot on exynos, and correctly reacting to -EPROBE_DEFER postpones DP initialization by approximately 1.5 second. Is there a good way to handle that? As it stands, this isn't usable. Stéphane -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next on Chromebook2: DRM failing to allocate
On Tue, Jun 10, 2014 at 10:56 AM, Kevin Hilman khil...@linaro.org wrote: I'm trying to get the latest linux-next working on my Chromebook2 (it's booting to a serial console) and am now trying to get the display working (at least for a frambuffer console.) Since the display nodes seem to be present in the exynos5800-peach-pi DTS, I tried enabling DRM and it's failing to allocate memory (log below[1] Is there some additional memory setup/allocations I should be doing? maybe with CMA? Probably not CMA, but maybe you don't have the iommu enabled? Stéphane Thanks for any advice, Kevin [1] DRM output with drm.debug=0xf on command line [1.095622] [drm] Initialized drm 1.1.0 20060810 [1.099792] [drm:drm_platform_init] [1.102311] [drm:drm_get_platform_dev] [1.106211] [drm:drm_minor_register] [1.11] [drm:drm_minor_register] new minor assigned 64 [1.115265] [drm:drm_minor_register] [1.118900] [drm:drm_minor_register] [1.122693] [drm:drm_minor_register] new minor assigned 0 [1.127970] [drm:exynos_drm_encoder_create] possible_crtcs = 0x1 [1.133915] [drm:exynos_drm_encoder_create] encoder has been created [1.140407] [drm:drm_sysfs_connector_add] adding eDP-1 to sysfs [1.146335] [drm:drm_sysfs_hotplug_event] generating hotplug event [1.152488] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [1.159065] [drm] No driver support for vblank timestamp query. [1.164965] [drm:drm_helper_hpd_irq_event] [CONNECTOR:15:eDP-1] status updated from unknown to connected [1.174418] [drm:drm_sysfs_hotplug_event] generating hotplug event [1.180590] [drm:exynos_drm_encoder_dpms] encoder dpms: 3 [1.185959] [drm:exynos_drm_crtc_dpms] crtc[6] mode[3] [1.191074] [drm:exynos_drm_crtc_dpms] desired dpms mode is same as previous one. [1.198538] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:15:eDP-1] [1.206698] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:15:eDP-1] probed modes : [1.216149] [drm:drm_mode_debug_printmodeline] Modeline 16:1920x1080 60 150660 1920 1980 2060 2232 1080 1090 1100 1125 0x48 0x0 [1.227779] [drm:drm_setup_crtcs] [1.231135] [drm:drm_enable_connectors] connector 15 enabled? yes [1.237227] [drm:drm_target_preferred] looking for cmdline mode on connector 15 [1.244512] [drm:drm_target_preferred] looking for preferred mode on connector 15 [1.251972] [drm:drm_target_preferred] found mode 1920x1080 [1.257525] [drm:drm_setup_crtcs] picking CRTCs for 4096x4096 config [1.263859] [drm:drm_setup_crtcs] desired mode 1920x1080 set on crtc 6 [1.270367] [drm:exynos_drm_fbdev_create] surface width(1920), height(1080) and bpp(32 [1.278260] [drm:exynos_drm_init_buf] desired size = 0x7e9000 [1.283995] [drm:exynos_drm_gem_init] created file object = 0xed7f9200 [1.290502] [ cut here ] [1.295094] WARNING: CPU: 1 PID: 1 at ../mm/page_alloc.c:2509 __alloc_pages_nodemask+0x220/0x76c() [1.304022] Modules linked in: [1.307044] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc8-next-20140605-4-gde16f7d3b2b5-dirty #31 [1.316882] [800152ac] (unwind_backtrace) from [80011d94] (show_stack+0x20/0x24) [1.324595] [80011d94] (show_stack) from [805128d8] (dump_stack+0x74/0x90) [1.331790] [805128d8] (dump_stack) from [80024208] (warn_slowpath_common+0x78/0x9c) [1.339854] [80024208] (warn_slowpath_common) from [80024258] (warn_slowpath_null+0x2c/0x34) [1.348622] [80024258] (warn_slowpath_null) from [800c9334] (__alloc_pages_nodemask+0x220/0x76c) [1.357730] [800c9334] (__alloc_pages_nodemask) from [80019fb8] (__dma_alloc_buffer.isra.13+0x3c/0x184) [1.367443] [80019fb8] (__dma_alloc_buffer.isra.13) from [8001a124] (__alloc_remap_buffer.isra.15+0x24/0xc0) [1.377592] [8001a124] (__alloc_remap_buffer.isra.15) from [8001a410] (__dma_alloc+0x250/0x2e0) [1.386613] [8001a410] (__dma_alloc) from [8001a5d8] (arm_dma_alloc+0x94/0xa0) [1.394166] [8001a5d8] (arm_dma_alloc) from [802cf650] (exynos_drm_alloc_buf+0x118/0x294) [1.402663] [802cf650] (exynos_drm_alloc_buf) from [802cfd10] (exynos_drm_gem_create+0x84/0xec) [1.411684] [802cfd10] (exynos_drm_gem_create) from [802cea14] (exynos_drm_fbdev_create+0xdc/0x2ec) [1.421056] [802cea14] (exynos_drm_fbdev_create) from [802b306c] (drm_fb_helper_initial_config+0x324/0x440) [1.431117] [802b306c] (drm_fb_helper_initial_config) from [802ced58] (exynos_drm_fbdev_init+0xd0/0x10c) [1.440918] [802ced58] (exynos_drm_fbdev_init) from [802cef10] (exynos_drm_output_poll_changed+0x34/0x38) [1.450808] [802cef10] (exynos_drm_output_poll_changed) from [802b0a08] (drm_kms_helper_hotplug_event+0x34/0x38) [1.461305] [802b0a08] (drm_kms_helper_hotplug_event) from [802b1148] (drm_helper_hpd_irq_event+0x108/0x120) [1.471455] [802b1148]
Re: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
On Wed, Mar 6, 2013 at 8:43 PM, Inki Dae inki@samsung.com wrote: 2013/3/7 김승우 sw0312@samsung.com: On 2013년 03월 04일 23:05, Rahul Sharma wrote: Thanks Sean, On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul seanp...@google.com wrote: On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma rahul.sha...@samsung.com wrote: Right now hdmiphy operations and configs are kept inside hdmi driver. hdmiphy related code is tightly coupled with hdmi ip driver. Physicaly they are different devices and s/Physicaly/Physically/ should be instantiated independently. In terms of versions/mapping/configurations Hdmi and hdmiphy are independent of each other. It is preferred to isolate them and maintained independently. This implementations is tested for: 1) Resolutions supported by exynos4 and 5 hdmi. 2) Runtime PM and S2R scenarions for exynos5. I don't like the idea of spawning off yet another driver in here. It adds more globals, more suspend/resume ordering issues, and more implicit dependencies. I understand, however, that this is the Chosen Way for the exynos driver, so I will save my rant. I agree to it. splitting phy to a new driver will complicate the power related scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of config values, mapping (i2c/platform bus) etc. Handling this diversity inside hdmi driver is complicating it with unrelated changes. Basically, I agree with the idea to split hdmiphy from hdmi. And it seems that already existing hdmiphy i2c device is just reused and hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling flow of power operations is reordered. But I'm not sure exynos_hdmiphy_driver_register() really need to be called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy is only used from hdmi. I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem. But this is probably going to break dpms and/or suspend/resume functionality. Has that been tested? Stéphane Thanks, Inki Dae Thanks and Regards, - Seung-Woo Kim I have tested this RFC for Runtime PM / S2R. But if we see any major roadblock we should re-factor this by explicitly calling power related callbacks of mixer, phy, hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf device. AFAIR something like this is already in place in chrome-kernel. I've made some comments below. This patch is dependent on http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- It is based on exynos-drm-next-todo branch at git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 ++- drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 8 files changed, 738 insertions(+), 368 deletions(-) create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h snip -- Seung-Woo Kim Samsung Software RD Center -- ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] add mie driver for exynos
On Tue, Dec 11, 2012 at 8:01 PM, Inki Dae inki@samsung.com wrote: 2012/12/12 Stéphane Marchesin stephane.marche...@gmail.com On Mon, Dec 10, 2012 at 1:27 AM, Inki Dae inki@samsung.com wrote: 2012/12/10 Stéphane Marchesin stephane.marche...@gmail.com On Sun, Dec 9, 2012 at 10:26 PM, Inki Dae inki@samsung.com wrote: 2012/12/6 R. Chandrasekar rcse...@samsung.com From: R. Chandrasekar rcse...@samsung.com this patch set adds the driver support for the dithering functionality of the mobile image enhancement (mie) module. device tree support is added for mie. fimd adds the mie module as plugin and calls the dithering function. dithere is required when the panels bpp is less then fimd output. though mie mie has other functionalities, current system uses only dithereing. Please, move mie module into drivers/video/exynos. The mie is a interface between fimd and lcd panel(or mipi-dsi, eDP) to enhance image to be displayed. And it seems like that this doesn't need drm framework-relevant interfaces, such as gem. Well, if you want to support it from the DRM, it should live in drivers/gpu/drm, and I don't think you should add another platform driver in the first place. The profusion of platform drivers in exynos makes it really difficult to support suspend/resume and initialization properly as many devices which operate separately need to sync through global variables. MIE could be used by linux framebuffer-based specific driver(s3c-fb) also. Yes, but it is a DRM driver we're talking about here. Again it is really difficult to work with it across suspend-resume. I don't think You want to use Exynos drm core framework just for suspend/resume to MIE module? as I mentioned before, I think the framework suitable to MIE is Common Display Framework. Of course, maybe you should add new features to Common Display Framework for it like MIPI DBI bus support framework because current Common Display Framework supports only display bus. Logically, MIE should be used without dependency of any frameworks such as Linux Framebuffer or DRM frameworks. And see the below hardware path, fimdmie-lcd panel fimdmiemipi-dsi--lcd panel fimdmieeDP---lcd panel Thus, the MIE is placed between fimd and lcd panel, mipi dsi or eDP. But for example the MIE only affects one of the layers. So your drawing doesn't match reality. You'd need to pass a layer number somehow which the API doesn't seem to allow... And fimd, as display controller, could be controlled by linux framebuffer or drm framework. I don't think it's a valid point. If the framebuffer is properly done on top of the DRM, you don't need all of that at all. Stéphane the DRM was ever meant to be a collection of independent platform drivers. If linux framebuffer-based driver want to use this mie module, should the mie module be placed in drivers/video coping it? I think it's not good so it's better way to use this mie module commonly without duplicated codes. And mipi-dsi and eDP drivers also have their own platform device/driver and are being used by exynos drm driver or s3c-fb driver. Of course, for some IPs such as mie between display controller and lcd panel, It seems like that there should be proper framework or interfaces in drivers/video/exynos or somewhere so that other frameworks can use it commonly. And drm and linux framebuffer drivers should call the interfaces. For the short term, I think it's fine to duplicate the code. For the longer term, I think framebuffer support should be provided by the drm framebuffer compat layer, and s3c-fb should disappear. This is what has been done with all the other DRM drivers. Stéphane Thanks, Inki Dae Stéphane And also, please refer to the below link, Common Display Framework, for more generic way. http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html Thanks, Inki Dae R. Chandrasekar (3): DTS: exynos: add device tree support for exynos mie drm: fimd: add mie plugin support for dithering drm: mie: add mie driver for exynos arch/arm/boot/dts/exynos5250.dtsi |7 +- drivers/gpu/drm/exynos/Kconfig |7 + drivers/gpu/drm/exynos/Makefile |1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c| 58 +- drivers/gpu/drm/exynos/exynos_drm_fimd_common.h | 20 ++ drivers/gpu/drm/exynos/exynos_drm_mie.c | 250 +++ drivers/gpu/drm/exynos/exynos_drm_mie.h | 50 + drivers/gpu/drm/exynos/exynos_regs-mie.h| 75 +++ 8 files changed, 465 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/exynos
Re: [PATCH 0/3] add mie driver for exynos
On Mon, Dec 10, 2012 at 1:27 AM, Inki Dae inki@samsung.com wrote: 2012/12/10 Stéphane Marchesin stephane.marche...@gmail.com On Sun, Dec 9, 2012 at 10:26 PM, Inki Dae inki@samsung.com wrote: 2012/12/6 R. Chandrasekar rcse...@samsung.com From: R. Chandrasekar rcse...@samsung.com this patch set adds the driver support for the dithering functionality of the mobile image enhancement (mie) module. device tree support is added for mie. fimd adds the mie module as plugin and calls the dithering function. dithere is required when the panels bpp is less then fimd output. though mie mie has other functionalities, current system uses only dithereing. Please, move mie module into drivers/video/exynos. The mie is a interface between fimd and lcd panel(or mipi-dsi, eDP) to enhance image to be displayed. And it seems like that this doesn't need drm framework-relevant interfaces, such as gem. Well, if you want to support it from the DRM, it should live in drivers/gpu/drm, and I don't think you should add another platform driver in the first place. The profusion of platform drivers in exynos makes it really difficult to support suspend/resume and initialization properly as many devices which operate separately need to sync through global variables. MIE could be used by linux framebuffer-based specific driver(s3c-fb) also. Yes, but it is a DRM driver we're talking about here. Again it is really difficult to work with it across suspend-resume. I don't think the DRM was ever meant to be a collection of independent platform drivers. If linux framebuffer-based driver want to use this mie module, should the mie module be placed in drivers/video coping it? I think it's not good so it's better way to use this mie module commonly without duplicated codes. And mipi-dsi and eDP drivers also have their own platform device/driver and are being used by exynos drm driver or s3c-fb driver. Of course, for some IPs such as mie between display controller and lcd panel, It seems like that there should be proper framework or interfaces in drivers/video/exynos or somewhere so that other frameworks can use it commonly. And drm and linux framebuffer drivers should call the interfaces. For the short term, I think it's fine to duplicate the code. For the longer term, I think framebuffer support should be provided by the drm framebuffer compat layer, and s3c-fb should disappear. This is what has been done with all the other DRM drivers. Stéphane Thanks, Inki Dae Stéphane And also, please refer to the below link, Common Display Framework, for more generic way. http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html Thanks, Inki Dae R. Chandrasekar (3): DTS: exynos: add device tree support for exynos mie drm: fimd: add mie plugin support for dithering drm: mie: add mie driver for exynos arch/arm/boot/dts/exynos5250.dtsi |7 +- drivers/gpu/drm/exynos/Kconfig |7 + drivers/gpu/drm/exynos/Makefile |1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c| 58 +- drivers/gpu/drm/exynos/exynos_drm_fimd_common.h | 20 ++ drivers/gpu/drm/exynos/exynos_drm_mie.c | 250 +++ drivers/gpu/drm/exynos/exynos_drm_mie.h | 50 + drivers/gpu/drm/exynos/exynos_regs-mie.h| 75 +++ 8 files changed, 465 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd_common.h create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.c create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.h create mode 100644 drivers/gpu/drm/exynos/exynos_regs-mie.h -- 1.7.9.5 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] add mie driver for exynos
On Sun, Dec 9, 2012 at 10:26 PM, Inki Dae inki@samsung.com wrote: 2012/12/6 R. Chandrasekar rcse...@samsung.com From: R. Chandrasekar rcse...@samsung.com this patch set adds the driver support for the dithering functionality of the mobile image enhancement (mie) module. device tree support is added for mie. fimd adds the mie module as plugin and calls the dithering function. dithere is required when the panels bpp is less then fimd output. though mie mie has other functionalities, current system uses only dithereing. Please, move mie module into drivers/video/exynos. The mie is a interface between fimd and lcd panel(or mipi-dsi, eDP) to enhance image to be displayed. And it seems like that this doesn't need drm framework-relevant interfaces, such as gem. Well, if you want to support it from the DRM, it should live in drivers/gpu/drm, and I don't think you should add another platform driver in the first place. The profusion of platform drivers in exynos makes it really difficult to support suspend/resume and initialization properly as many devices which operate separately need to sync through global variables. Stéphane And also, please refer to the below link, Common Display Framework, for more generic way. http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html Thanks, Inki Dae R. Chandrasekar (3): DTS: exynos: add device tree support for exynos mie drm: fimd: add mie plugin support for dithering drm: mie: add mie driver for exynos arch/arm/boot/dts/exynos5250.dtsi |7 +- drivers/gpu/drm/exynos/Kconfig |7 + drivers/gpu/drm/exynos/Makefile |1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c| 58 +- drivers/gpu/drm/exynos/exynos_drm_fimd_common.h | 20 ++ drivers/gpu/drm/exynos/exynos_drm_mie.c | 250 +++ drivers/gpu/drm/exynos/exynos_drm_mie.h | 50 + drivers/gpu/drm/exynos/exynos_regs-mie.h| 75 +++ 8 files changed, 465 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd_common.h create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.c create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mie.h create mode 100644 drivers/gpu/drm/exynos/exynos_regs-mie.h -- 1.7.9.5 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
