Re: [PATCH v10 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
2013/3/1 Vikas Sajjan vikas.saj...@linaro.org:
Add support for parsing the display-timing node using video helper
function.
The DT node parsing is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..e323cf9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
#include linux/of_device.h
#include linux/pm_runtime.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ ret = of_get_fb_videomode(dev-of_node, pdata-panel.timing,
+ OF_USE_NATIVE_MODE);
Add select OF_VIDEOMODE and select FB_MODE_HELPERS to
drivers/gpu/drm/exynos/Kconfig. When EXYNOS_DRM_FIMD config is
selected, these two configs should also be selected.
Thanks,
Inki Dae
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode() : %d\n,
ret);
+ return ret;
+ }
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
--
1.7.9.5
___
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-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] [media] dvb-usb/dw2102: Remove duplicate inclusion of ts2020.h
ts2020.h was included twice. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/usb/dvb-usb/dw2102.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/usb/dvb-usb/dw2102.c b/drivers/media/usb/dvb-usb/dw2102.c index 9578a67..c629d02 100644 --- a/drivers/media/usb/dvb-usb/dw2102.c +++ b/drivers/media/usb/dvb-usb/dw2102.c @@ -29,7 +29,6 @@ #include stb6100.h #include stb6100_proc.h #include m88rs2000.h -#include ts2020.h #ifndef USB_PID_DW2102 #define USB_PID_DW2102 0x2102 -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: davinci: kconfig: fix incorrect selects
Hi Sekhar, Thanks for the patch! On Tue, Mar 5, 2013 at 7:43 PM, Sekhar Nori nsek...@ti.com wrote: drivers/media/platform/davinci/Kconfig uses selects where it should be using 'depends on'. This results in warnings of the following sort when doing randconfig builds. warning: (VIDEO_DM6446_CCDC VIDEO_DM355_CCDC VIDEO_ISIF VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT V4L_PLATFORM_DRIVERS ARCH_DAVINCI) The VPIF kconfigs had a strange 'select' and 'depends on' cross linkage which have been fixed as well. This patch has only been build tested, I do not have the setup to test video. I also do not know if the dependencies are really needed, I have just tried to not break any existing assumptions. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Sekhar Nori nsek...@ti.com --- drivers/media/platform/davinci/Kconfig | 22 -- 1 file changed, 8 insertions(+), 14 deletions(-) diff --git a/drivers/media/platform/davinci/Kconfig b/drivers/media/platform/davinci/Kconfig index 3c56037..313e343 100644 --- a/drivers/media/platform/davinci/Kconfig +++ b/drivers/media/platform/davinci/Kconfig @@ -1,8 +1,7 @@ config VIDEO_DAVINCI_VPIF_DISPLAY tristate DM646x/DA850/OMAPL138 EVM Video Display - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 if MEDIA_SUBDRV_AUTOSELECT select VIDEO_THS7303 if MEDIA_SUBDRV_AUTOSELECT help @@ -15,9 +14,8 @@ config VIDEO_DAVINCI_VPIF_DISPLAY config VIDEO_DAVINCI_VPIF_CAPTURE tristate DM646x/DA850/OMAPL138 EVM Video Capture - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF help Enables Davinci VPIF module used for captur devices. This module is common for following DM6467/DA850/OMAPL138 @@ -28,7 +26,7 @@ config VIDEO_DAVINCI_VPIF_CAPTURE config VIDEO_DAVINCI_VPIF tristate DaVinci VPIF Driver - depends on VIDEO_DAVINCI_VPIF_DISPLAY || VIDEO_DAVINCI_VPIF_CAPTURE + depends on ARCH_DAVINCI It would be better if this was depends on MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM rather than 'ARCH_DAVINCI' then you can remove 'MACH_DAVINCI_DM6467_EVM' and 'MACH_DAVINCI_DA850_EVM' dependency from VIDEO_DAVINCI_VPIF_DISPLAY and VIDEO_DAVINCI_VPIF_CAPTURE. So it would be just 'depends on VIDEO_DEV VIDEO_DAVINCI_VPIF' BTW this patch doesn’t apply on3.9.0-rc1. Regards, --Prabhakar Lad help Support for DaVinci VPIF Driver. @@ -56,8 +54,7 @@ config VIDEO_VPFE_CAPTURE config VIDEO_DM6446_CCDC tristate DM6446 CCDC HW module - depends on VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM + depends on VIDEO_VPFE_CAPTURE VIDEO_VPSS_SYSTEM default y help Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces @@ -71,8 +68,7 @@ config VIDEO_DM6446_CCDC config VIDEO_DM355_CCDC tristate DM355 CCDC HW module - depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM + depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE VIDEO_VPSS_SYSTEM default y help Enables DM355 CCD hw module. DM355 CCDC hw interfaces @@ -86,8 +82,7 @@ config VIDEO_DM355_CCDC config VIDEO_ISIF tristate ISIF HW module - depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM + depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE VIDEO_VPSS_SYSTEM default y help Enables ISIF hw module. This is the hardware module for @@ -99,8 +94,7 @@ config VIDEO_ISIF config VIDEO_DM644X_VPBE tristate DM644X VPBE HW module - depends on ARCH_DAVINCI_DM644x - select VIDEO_VPSS_SYSTEM + depends on ARCH_DAVINCI_DM644x VIDEO_VPSS_SYSTEM select VIDEOBUF2_DMA_CONTIG help Enables VPBE modules used for display on a DM644x @@ -113,7 +107,7 @@ config VIDEO_DM644X_VPBE config VIDEO_VPBE_DISPLAY tristate VPBE V4L2 Display driver depends on ARCH_DAVINCI_DM644x - select VIDEO_DM644X_VPBE + depends on VIDEO_DM644X_VPBE help Enables VPBE V4L2 Display driver on a DM644x device -- 1.7.10.1 ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- To unsubscribe from this list:
Re: tw2804.c
On Wed 6 March 2013 10:48:13 volok...@gmail.com wrote: Hi, Hans I found in d8077d2df184f3ef63ed9ff4579d41ca64e12855 commit, that V4L2_CTRL_FLAG_VOLATILE flag was disabled for some STD controls and fully disabled g_ctrl iface. So How can userspace know about changing some values? VOLATILE is used when register values can change automatically (e.g. if autogain is on and the device regulates the gain and updates that gain register itself). However, testing proved that the hardware doesn't update anything when in autogain mode, hence volatile support isn't needed. Note that the control framework always caches the last control value, so to get non-volatile controls the framework just returns that cached value. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: davinci: kconfig: fix incorrect selects
On 3/6/2013 2:59 PM, Prabhakar Lad wrote: config VIDEO_DAVINCI_VPIF_DISPLAY tristate DM646x/DA850/OMAPL138 EVM Video Display - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 if MEDIA_SUBDRV_AUTOSELECT select VIDEO_THS7303 if MEDIA_SUBDRV_AUTOSELECT help @@ -15,9 +14,8 @@ config VIDEO_DAVINCI_VPIF_DISPLAY config VIDEO_DAVINCI_VPIF_CAPTURE tristate DM646x/DA850/OMAPL138 EVM Video Capture - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF help Enables Davinci VPIF module used for captur devices. This module is common for following DM6467/DA850/OMAPL138 @@ -28,7 +26,7 @@ config VIDEO_DAVINCI_VPIF_CAPTURE config VIDEO_DAVINCI_VPIF tristate DaVinci VPIF Driver - depends on VIDEO_DAVINCI_VPIF_DISPLAY || VIDEO_DAVINCI_VPIF_CAPTURE + depends on ARCH_DAVINCI It would be better if this was depends on MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM rather than 'ARCH_DAVINCI' then you can remove 'MACH_DAVINCI_DM6467_EVM' and 'MACH_DAVINCI_DA850_EVM' dependency from VIDEO_DAVINCI_VPIF_DISPLAY and VIDEO_DAVINCI_VPIF_CAPTURE. So it would be just 'depends on VIDEO_DEV VIDEO_DAVINCI_VPIF' I could, but vpif.c seems pretty board independent to me. Are you sure no other board would like to build vpif.c? BTW, are vpif_display.c and vpif_capture.c really that board specific? May be we can all make them depend on ARCH_DAVINCI? BTW this patch doesn’t apply on3.9.0-rc1. Oops. I based this on a handy v3.8. I will fix. Thanks, sekhar -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
Hi,
On 6 March 2013 14:12, Inki Dae inki@samsung.com wrote:
2013/3/1 Vikas Sajjan vikas.saj...@linaro.org:
Add support for parsing the display-timing node using video helper
function.
The DT node parsing is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..e323cf9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
#include linux/of_device.h
#include linux/pm_runtime.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ ret = of_get_fb_videomode(dev-of_node, pdata-panel.timing,
+ OF_USE_NATIVE_MODE);
Add select OF_VIDEOMODE and select FB_MODE_HELPERS to
drivers/gpu/drm/exynos/Kconfig. When EXYNOS_DRM_FIMD config is
selected, these two configs should also be selected.
Sure. Will add and resend.
Thanks,
Inki Dae
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode() : %d\n,
ret);
+ return ret;
+ }
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
--
1.7.9.5
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thanks and Regards
Vikas Sajjan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tw2804.c
On Wed, Mar 06, 2013 at 11:02:47AM +0100, Hans Verkuil wrote: On Wed 6 March 2013 10:48:13 volok...@gmail.com wrote: Hi, Hans I found in d8077d2df184f3ef63ed9ff4579d41ca64e12855 commit, that V4L2_CTRL_FLAG_VOLATILE flag was disabled for some STD controls and fully disabled g_ctrl iface. So How can userspace know about changing some values? VOLATILE is used when register values can change automatically (e.g. if autogain is on and the device regulates the gain and updates that gain register itself). Right that!!! there one register for all 4 channell for each of AUTOGAIN,CHROMA,RED_B,BLUE_B reg, so if one channel changes CHROMA value (it changes all 4 channels), the another channel will have cached old value, instead new (case it value have not volatile control) However, testing proved that the hardware doesn't update anything when in autogain mode, hence volatile support isn't needed. Note that the control framework always caches the last control value, so to get non-volatile controls the framework just returns that cached value. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: davinci: kconfig: fix incorrect selects
Sekhar, On Wed, Mar 6, 2013 at 3:37 PM, Sekhar Nori nsek...@ti.com wrote: On 3/6/2013 2:59 PM, Prabhakar Lad wrote: config VIDEO_DAVINCI_VPIF_DISPLAY tristate DM646x/DA850/OMAPL138 EVM Video Display - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 if MEDIA_SUBDRV_AUTOSELECT select VIDEO_THS7303 if MEDIA_SUBDRV_AUTOSELECT help @@ -15,9 +14,8 @@ config VIDEO_DAVINCI_VPIF_DISPLAY config VIDEO_DAVINCI_VPIF_CAPTURE tristate DM646x/DA850/OMAPL138 EVM Video Capture - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF help Enables Davinci VPIF module used for captur devices. This module is common for following DM6467/DA850/OMAPL138 @@ -28,7 +26,7 @@ config VIDEO_DAVINCI_VPIF_CAPTURE config VIDEO_DAVINCI_VPIF tristate DaVinci VPIF Driver - depends on VIDEO_DAVINCI_VPIF_DISPLAY || VIDEO_DAVINCI_VPIF_CAPTURE + depends on ARCH_DAVINCI It would be better if this was depends on MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM rather than 'ARCH_DAVINCI' then you can remove 'MACH_DAVINCI_DM6467_EVM' and 'MACH_DAVINCI_DA850_EVM' dependency from VIDEO_DAVINCI_VPIF_DISPLAY and VIDEO_DAVINCI_VPIF_CAPTURE. So it would be just 'depends on VIDEO_DEV VIDEO_DAVINCI_VPIF' I could, but vpif.c seems pretty board independent to me. Are you sure no other board would like to build vpif.c? BTW, are vpif_display.c and vpif_capture.c really that board specific? May be we can all make them depend on ARCH_DAVINCI? VPIF is present only in DM646x and DA850/OMAP-L1138. vpif.c is common file which is used by vpif_capture and vpif_display. Regards, --Prabhakar Lad BTW this patch doesn’t apply on3.9.0-rc1. Oops. I based this on a handy v3.8. I will fix. Thanks, sekhar -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: davinci: kconfig: fix incorrect selects
Sekhar, On Wed, Mar 6, 2013 at 3:46 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: Sekhar, On Wed, Mar 6, 2013 at 3:37 PM, Sekhar Nori nsek...@ti.com wrote: On 3/6/2013 2:59 PM, Prabhakar Lad wrote: config VIDEO_DAVINCI_VPIF_DISPLAY tristate DM646x/DA850/OMAPL138 EVM Video Display - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 if MEDIA_SUBDRV_AUTOSELECT select VIDEO_THS7303 if MEDIA_SUBDRV_AUTOSELECT help @@ -15,9 +14,8 @@ config VIDEO_DAVINCI_VPIF_DISPLAY config VIDEO_DAVINCI_VPIF_CAPTURE tristate DM646x/DA850/OMAPL138 EVM Video Capture - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF help Enables Davinci VPIF module used for captur devices. This module is common for following DM6467/DA850/OMAPL138 @@ -28,7 +26,7 @@ config VIDEO_DAVINCI_VPIF_CAPTURE config VIDEO_DAVINCI_VPIF tristate DaVinci VPIF Driver - depends on VIDEO_DAVINCI_VPIF_DISPLAY || VIDEO_DAVINCI_VPIF_CAPTURE + depends on ARCH_DAVINCI It would be better if this was depends on MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM rather than 'ARCH_DAVINCI' then you can remove 'MACH_DAVINCI_DM6467_EVM' and 'MACH_DAVINCI_DA850_EVM' dependency from VIDEO_DAVINCI_VPIF_DISPLAY and VIDEO_DAVINCI_VPIF_CAPTURE. So it would be just 'depends on VIDEO_DEV VIDEO_DAVINCI_VPIF' I could, but vpif.c seems pretty board independent to me. Are you sure no other board would like to build vpif.c? BTW, are vpif_display.c and vpif_capture.c really that board specific? May be we can all make them depend on ARCH_DAVINCI? VPIF is present only in DM646x and DA850/OMAP-L1138. vpif.c is common file which is used by vpif_capture and vpif_display. Forgot to mention earlier, for some reason this patch didn’t make into media ML. Regards, --Prabhakar Regards, --Prabhakar Lad BTW this patch doesn’t apply on3.9.0-rc1. Oops. I based this on a handy v3.8. I will fix. Thanks, sekhar -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tw2804.c
On Wed, Mar 06, 2013 at 02:11:24PM +0400, volok...@gmail.com wrote: On Wed, Mar 06, 2013 at 11:02:47AM +0100, Hans Verkuil wrote: On Wed 6 March 2013 10:48:13 volok...@gmail.com wrote: Hi, Hans I found in d8077d2df184f3ef63ed9ff4579d41ca64e12855 commit, that V4L2_CTRL_FLAG_VOLATILE flag was disabled for some STD controls and fully disabled g_ctrl iface. So How can userspace know about changing some values? VOLATILE is used when register values can change automatically (e.g. if autogain is on and the device regulates the gain and updates that gain register itself). Right that!!! there one register for all 4 channell for each of AUTOGAIN,CHROMA,RED_B,BLUE_B reg, so if one channel changes CHROMA value (it changes all 4 channels), Sorry not AUTOGAIN, just GAIN the another channel will have cached old value, instead new (case it value have not volatile control) However, testing proved that the hardware doesn't update anything when in autogain mode, hence volatile support isn't needed. Note that the control framework always caches the last control value, so to get non-volatile controls the framework just returns that cached value. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
tw2804.c
Hi, Hans I found in d8077d2df184f3ef63ed9ff4579d41ca64e12855 commit, that V4L2_CTRL_FLAG_VOLATILE flag was disabled for some STD controls and fully disabled g_ctrl iface. So How can userspace know about changing some values? Or is that right? Regards, Volokh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: davinci: kconfig: fix incorrect selects
On 3/6/2013 3:46 PM, Prabhakar Lad wrote: Sekhar, On Wed, Mar 6, 2013 at 3:37 PM, Sekhar Nori nsek...@ti.com wrote: On 3/6/2013 2:59 PM, Prabhakar Lad wrote: config VIDEO_DAVINCI_VPIF_DISPLAY tristate DM646x/DA850/OMAPL138 EVM Video Display - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 if MEDIA_SUBDRV_AUTOSELECT select VIDEO_THS7303 if MEDIA_SUBDRV_AUTOSELECT help @@ -15,9 +14,8 @@ config VIDEO_DAVINCI_VPIF_DISPLAY config VIDEO_DAVINCI_VPIF_CAPTURE tristate DM646x/DA850/OMAPL138 EVM Video Capture - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF help Enables Davinci VPIF module used for captur devices. This module is common for following DM6467/DA850/OMAPL138 @@ -28,7 +26,7 @@ config VIDEO_DAVINCI_VPIF_CAPTURE config VIDEO_DAVINCI_VPIF tristate DaVinci VPIF Driver - depends on VIDEO_DAVINCI_VPIF_DISPLAY || VIDEO_DAVINCI_VPIF_CAPTURE + depends on ARCH_DAVINCI It would be better if this was depends on MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM rather than 'ARCH_DAVINCI' then you can remove 'MACH_DAVINCI_DM6467_EVM' and 'MACH_DAVINCI_DA850_EVM' dependency from VIDEO_DAVINCI_VPIF_DISPLAY and VIDEO_DAVINCI_VPIF_CAPTURE. So it would be just 'depends on VIDEO_DEV VIDEO_DAVINCI_VPIF' I could, but vpif.c seems pretty board independent to me. Are you sure no other board would like to build vpif.c? BTW, are vpif_display.c and vpif_capture.c really that board specific? May be we can all make them depend on ARCH_DAVINCI? VPIF is present only in DM646x and DA850/OMAP-L1138. vpif.c is common file which is used by vpif_capture and vpif_display. So vpif.c per se doesn't do anything useful. Why the dependency on EVMs? There are other boards for these platform which could use VPIF. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tw2804.c
On Wed 6 March 2013 11:11:24 volok...@gmail.com wrote: On Wed, Mar 06, 2013 at 11:02:47AM +0100, Hans Verkuil wrote: On Wed 6 March 2013 10:48:13 volok...@gmail.com wrote: Hi, Hans I found in d8077d2df184f3ef63ed9ff4579d41ca64e12855 commit, that V4L2_CTRL_FLAG_VOLATILE flag was disabled for some STD controls and fully disabled g_ctrl iface. So How can userspace know about changing some values? VOLATILE is used when register values can change automatically (e.g. if autogain is on and the device regulates the gain and updates that gain register itself). Right that!!! there one register for all 4 channell for each of AUTOGAIN,CHROMA,RED_B,BLUE_B reg, so if one channel changes CHROMA value (it changes all 4 channels), the another channel will have cached old value, instead new (case it value have not volatile control) Ah, yes. Good point. I need to modify the code to have two control handlers: one for the global controls and one for the channel controls. That's the right way to do this. I'll implement that later this week. Regards, Hans However, testing proved that the hardware doesn't update anything when in autogain mode, hence volatile support isn't needed. Note that the control framework always caches the last control value, so to get non-volatile controls the framework just returns that cached value. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: davinci: kconfig: fix incorrect selects
On Wed, Mar 6, 2013 at 3:53 PM, Sekhar Nori nsek...@ti.com wrote: On 3/6/2013 3:46 PM, Prabhakar Lad wrote: Sekhar, On Wed, Mar 6, 2013 at 3:37 PM, Sekhar Nori nsek...@ti.com wrote: On 3/6/2013 2:59 PM, Prabhakar Lad wrote: config VIDEO_DAVINCI_VPIF_DISPLAY tristate DM646x/DA850/OMAPL138 EVM Video Display - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 if MEDIA_SUBDRV_AUTOSELECT select VIDEO_THS7303 if MEDIA_SUBDRV_AUTOSELECT help @@ -15,9 +14,8 @@ config VIDEO_DAVINCI_VPIF_DISPLAY config VIDEO_DAVINCI_VPIF_CAPTURE tristate DM646x/DA850/OMAPL138 EVM Video Capture - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF help Enables Davinci VPIF module used for captur devices. This module is common for following DM6467/DA850/OMAPL138 @@ -28,7 +26,7 @@ config VIDEO_DAVINCI_VPIF_CAPTURE config VIDEO_DAVINCI_VPIF tristate DaVinci VPIF Driver - depends on VIDEO_DAVINCI_VPIF_DISPLAY || VIDEO_DAVINCI_VPIF_CAPTURE + depends on ARCH_DAVINCI It would be better if this was depends on MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM rather than 'ARCH_DAVINCI' then you can remove 'MACH_DAVINCI_DM6467_EVM' and 'MACH_DAVINCI_DA850_EVM' dependency from VIDEO_DAVINCI_VPIF_DISPLAY and VIDEO_DAVINCI_VPIF_CAPTURE. So it would be just 'depends on VIDEO_DEV VIDEO_DAVINCI_VPIF' I could, but vpif.c seems pretty board independent to me. Are you sure no other board would like to build vpif.c? BTW, are vpif_display.c and vpif_capture.c really that board specific? May be we can all make them depend on ARCH_DAVINCI? VPIF is present only in DM646x and DA850/OMAP-L1138. vpif.c is common file which is used by vpif_capture and vpif_display. So vpif.c per se doesn't do anything useful. Why the dependency on EVMs? There are other boards for these platform which could use VPIF. yep agreed! Regards, --Prabhakar Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HAUPPAUGE HVR-930C analog tv feasible ??
On Tue, Mar 05, 2013 at 10:32:33PM +0100, jande...@dommel.be wrote: Your local avf4910a copy probably offers not much more than the one over here ? https://github.com/wurststulle/ngene_2400i/tree/2377b1fd99d91ff355a5e46881ef27ccc87cb376 No, mainly cleanup and coding style conversion. A few DSP writes are amended to MSP_InitTable to set registers a second time with different values. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 00/12] Adding media device driver for Exynos imaging subsystem
The following patchset features: 1] Creating a common pipeline framework which can be used by all Exynos series SoCs for developing media device drivers. 2] Modified the existing fimc-mdevice for exynos4 to use the common pipeline framework. 3] Adding of media device driver for Exynos5 Imaging subsystem. 4] Upgrading mipi-csis and fimc-lite drivers for Exynos5 SoCs. 5] Adding DT support to m5mols driver and tested with Exynos5 media device driver. Current changes are not tested on exynos4 series SoCs. Current media device driver only support one pipeline (pipeline0) which consists of Sensor -- MIPI-CSIS -- FIMC-LITE Sensor -- FIMC-LITE G-Scaler support to pipeline0 will be added later. Once the fimc-is device driver is posted, one more pipeline (pipeline1) will be added for exynos5 media device driver for fimc-is sub-devices. This patchset is rebased on: git://linuxtv.org/media_tree.git:staging/for_v3.9 This patchset depends on: from Thomas Abraham: [1] pinctrl: exynos: add support for Samsung's Exynos5250 [2] ARM: dts: add pinctrl nodes for Exynos5250 SoC from Sylwester Nawrocki: [1] Device tree support for Exynos SoC camera subsystem Shaik Ameer Basha (12): media: s5p-fimc: modify existing mdev to use common pipeline fimc-lite: Adding Exynos5 compatibility to fimc-lite driver media: fimc-lite: Adding support for Exynos5 s5p-csis: Adding Exynos5250 compatibility ARM: EXYNOS: Add devicetree node for mipi-csis driver for exynos5 ARM: EXYNOS: Add devicetree node for FIMC-LITE driver for exynos5 media: exynos5-is: Adding media device driver for exynos5 ARM: dts: add camera specific pinctrl nodes for Exynos5250 SoC ARM: dts: Adding pinctrl support to Exynos5250 i2c nodes ARM: dts: Adding media device nodes to Exynos5 SoCs media: m5mols: Adding dt support to m5mols driver ARM: dts: Add camera node to exynos5250-smdk5250.dts arch/arm/boot/dts/exynos5250-pinctrl.dtsi| 41 + arch/arm/boot/dts/exynos5250-smdk5250.dts| 65 +- arch/arm/boot/dts/exynos5250.dtsi| 54 + arch/arm/mach-exynos/clock-exynos5.c | 20 +- arch/arm/mach-exynos/include/mach/map.h |7 + arch/arm/mach-exynos/mach-exynos5-dt.c | 10 + drivers/media/i2c/m5mols/m5mols_core.c | 54 +- drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile |1 + drivers/media/platform/exynos5-is/Kconfig|7 + drivers/media/platform/exynos5-is/Makefile |4 + drivers/media/platform/exynos5-is/exynos5-mdev.c | 1309 ++ drivers/media/platform/exynos5-is/exynos5-mdev.h | 107 ++ drivers/media/platform/s5p-fimc/fimc-capture.c | 96 +- drivers/media/platform/s5p-fimc/fimc-core.h |4 +- drivers/media/platform/s5p-fimc/fimc-lite-reg.c | 16 +- drivers/media/platform/s5p-fimc/fimc-lite-reg.h | 41 +- drivers/media/platform/s5p-fimc/fimc-lite.c | 292 - drivers/media/platform/s5p-fimc/fimc-lite.h | 12 +- drivers/media/platform/s5p-fimc/fimc-mdevice.c | 186 ++- drivers/media/platform/s5p-fimc/fimc-mdevice.h | 41 +- drivers/media/platform/s5p-fimc/mipi-csis.c |1 + include/media/s5p_fimc.h | 66 +- 23 files changed, 2261 insertions(+), 174 deletions(-) create mode 100644 drivers/media/platform/exynos5-is/Kconfig create mode 100644 drivers/media/platform/exynos5-is/Makefile create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.c create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 01/12] media: s5p-fimc: modify existing mdev to use common pipeline
This patch modifies the current fimc_pipeline to exynos_pipeline,
which can be used across multiple media device drivers.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/s5p-fimc/fimc-capture.c | 96 +++-
drivers/media/platform/s5p-fimc/fimc-core.h|4 +-
drivers/media/platform/s5p-fimc/fimc-lite.c| 73 --
drivers/media/platform/s5p-fimc/fimc-lite.h|4 +-
drivers/media/platform/s5p-fimc/fimc-mdevice.c | 186 ++--
drivers/media/platform/s5p-fimc/fimc-mdevice.h | 41 +++---
include/media/s5p_fimc.h | 66 ++---
7 files changed, 326 insertions(+), 144 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 4cbaf46..106466e 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -27,24 +27,26 @@
#include media/videobuf2-core.h
#include media/videobuf2-dma-contig.h
-#include fimc-mdevice.h
#include fimc-core.h
#include fimc-reg.h
static int fimc_capture_hw_init(struct fimc_dev *fimc)
{
struct fimc_ctx *ctx = fimc-vid_cap.ctx;
- struct fimc_pipeline *p = fimc-pipeline;
+ struct exynos_pipeline *p = fimc-pipeline;
struct fimc_sensor_info *sensor;
unsigned long flags;
+ struct v4l2_subdev *sd;
int ret = 0;
- if (p-subdevs[IDX_SENSOR] == NULL || ctx == NULL)
+ sd = exynos_pipeline_get_subdev(fimc-pipeline_ops,
+ get_subdev_sensor, p);
+ if (sd == NULL || ctx == NULL)
return -ENXIO;
if (ctx-s_frame.fmt == NULL)
return -EINVAL;
- sensor = v4l2_get_subdev_hostdata(p-subdevs[IDX_SENSOR]);
+ sensor = v4l2_get_subdev_hostdata(sd);
spin_lock_irqsave(fimc-slock, flags);
fimc_prepare_dma_offset(ctx, ctx-d_frame);
@@ -118,7 +120,7 @@ static int fimc_capture_state_cleanup(struct fimc_dev
*fimc, bool suspend)
spin_unlock_irqrestore(fimc-slock, flags);
if (streaming)
- return fimc_pipeline_call(fimc, set_stream,
+ return exynos_pipeline_call(fimc, set_stream,
fimc-pipeline, 0);
else
return 0;
@@ -177,13 +179,16 @@ static int fimc_capture_config_update(struct fimc_ctx
*ctx)
void fimc_capture_irq_handler(struct fimc_dev *fimc, int deq_buf)
{
- struct v4l2_subdev *csis = fimc-pipeline.subdevs[IDX_CSIS];
+ struct v4l2_subdev *csis;
struct fimc_vid_cap *cap = fimc-vid_cap;
struct fimc_frame *f = cap-ctx-d_frame;
struct fimc_vid_buffer *v_buf;
struct timeval *tv;
struct timespec ts;
+ csis = exynos_pipeline_get_subdev(fimc-pipeline_ops,
+ get_subdev_csis, fimc-pipeline);
+
if (test_and_clear_bit(ST_CAPT_SHUT, fimc-state)) {
wake_up(fimc-irq_queue);
goto done;
@@ -286,7 +291,7 @@ static int start_streaming(struct vb2_queue *q, unsigned
int count)
fimc_activate_capture(ctx);
if (!test_and_set_bit(ST_CAPT_ISP_STREAM, fimc-state))
- fimc_pipeline_call(fimc, set_stream,
+ exynos_pipeline_call(fimc, set_stream,
fimc-pipeline, 1);
}
@@ -311,7 +316,7 @@ int fimc_capture_suspend(struct fimc_dev *fimc)
int ret = fimc_stop_capture(fimc, suspend);
if (ret)
return ret;
- return fimc_pipeline_call(fimc, close, fimc-pipeline);
+ return exynos_pipeline_call(fimc, close, fimc-pipeline);
}
static void buffer_queue(struct vb2_buffer *vb);
@@ -327,7 +332,7 @@ int fimc_capture_resume(struct fimc_dev *fimc)
INIT_LIST_HEAD(fimc-vid_cap.active_buf_q);
vid_cap-buf_index = 0;
- fimc_pipeline_call(fimc, open, fimc-pipeline,
+ exynos_pipeline_call(fimc, open, fimc-pipeline,
vid_cap-vfd.entity, false);
fimc_capture_hw_init(fimc);
@@ -447,7 +452,7 @@ static void buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(fimc-slock, flags);
if (!test_and_set_bit(ST_CAPT_ISP_STREAM, fimc-state))
- fimc_pipeline_call(fimc, set_stream,
+ exynos_pipeline_call(fimc, set_stream,
fimc-pipeline, 1);
return;
}
@@ -486,9 +491,12 @@ static struct vb2_ops fimc_capture_qops = {
int fimc_capture_ctrls_create(struct fimc_dev *fimc)
{
struct fimc_vid_cap *vid_cap = fimc-vid_cap;
- struct v4l2_subdev *sensor = fimc-pipeline.subdevs[IDX_SENSOR];
+ struct v4l2_subdev *sensor;
int ret;
+ sensor = exynos_pipeline_get_subdev(fimc-pipeline_ops,
+
[RFC 02/12] fimc-lite: Adding Exynos5 compatibility to fimc-lite driver
This patch adds the Exynos5 soc compatibility to the fimc-lite driver.
It also adds a version checking to deal with the changes between
different fimc-lite hardware versions.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/s5p-fimc/fimc-lite.c | 23 +++
drivers/media/platform/s5p-fimc/fimc-lite.h |7 ++-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index 122cf95..eb64f87 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -1653,6 +1653,16 @@ static struct flite_variant fimc_lite0_variant_exynos4 =
{
.out_width_align= 8,
.win_hor_offs_align = 2,
.out_hor_offs_align = 8,
+ .version= FLITE_VER_EXYNOS4,
+};
+
+static struct flite_variant fimc_lite0_variant_exynos5 = {
+ .max_width = 8192,
+ .max_height = 8192,
+ .out_width_align= 8,
+ .win_hor_offs_align = 2,
+ .out_hor_offs_align = 8,
+ .version= FLITE_VER_EXYNOS5,
};
/* EXYNOS4212, EXYNOS4412 */
@@ -1663,6 +1673,15 @@ static struct flite_drvdata fimc_lite_drvdata_exynos4 = {
},
};
+/* EXYNOS5250 */
+static struct flite_drvdata fimc_lite_drvdata_exynos5 = {
+ .variant = {
+ [0] = fimc_lite0_variant_exynos5,
+ [1] = fimc_lite0_variant_exynos5,
+ [2] = fimc_lite0_variant_exynos5,
+ },
+};
+
static struct platform_device_id fimc_lite_driver_ids[] = {
{
.name = exynos-fimc-lite,
@@ -1677,6 +1696,10 @@ static const struct of_device_id flite_of_match[] = {
.compatible = samsung,exynos4212-fimc-lite,
.data = fimc_lite_drvdata_exynos4,
},
+ {
+ .compatible = samsung,exynos5250-fimc-lite,
+ .data = fimc_lite_drvdata_exynos5,
+ },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, flite_of_match);
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.h
b/drivers/media/platform/s5p-fimc/fimc-lite.h
index 66d6eeb..ef43fe0 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.h
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.h
@@ -28,7 +28,7 @@
#define FIMC_LITE_DRV_NAME exynos-fimc-lite
#define FLITE_CLK_NAME flite
-#define FIMC_LITE_MAX_DEVS 2
+#define FIMC_LITE_MAX_DEVS 3
#define FLITE_REQ_BUFS_MIN 2
/* Bit index definitions for struct fimc_lite::state */
@@ -49,12 +49,17 @@ enum {
#define FLITE_SD_PAD_SOURCE_ISP2
#define FLITE_SD_PADS_NUM 3
+#define FLITE_VER_EXYNOS4 0
+#define FLITE_VER_EXYNOS5 1
+
+
struct flite_variant {
unsigned short max_width;
unsigned short max_height;
unsigned short out_width_align;
unsigned short win_hor_offs_align;
unsigned short out_hor_offs_align;
+ unsigned short version;
};
struct flite_drvdata {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 03/12] media: fimc-lite: Adding support for Exynos5
This patch adds the following functionalities to existing driver
1] FIMC-LITE supports multiple DMA shadow registers from Exynos5 onwards.
This patch adds the functionality of using shadow registers by
checking the current FIMC-LITE hardware version.
2] Fixes Buffer corruption on DMA output from fimc-lite
3] Modified the driver to be used as pipeline endpoint
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-fimc/fimc-lite-reg.c | 16 +-
drivers/media/platform/s5p-fimc/fimc-lite-reg.h | 41 -
drivers/media/platform/s5p-fimc/fimc-lite.c | 196 +--
drivers/media/platform/s5p-fimc/fimc-lite.h |3 +-
4 files changed, 236 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite-reg.c
b/drivers/media/platform/s5p-fimc/fimc-lite-reg.c
index 3c7dd65..3d63526 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite-reg.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite-reg.c
@@ -68,7 +68,8 @@ void flite_hw_set_interrupt_mask(struct fimc_lite *dev)
if (atomic_read(dev-out_path) == FIMC_IO_DMA) {
intsrc = FLITE_REG_CIGCTRL_IRQ_OVFEN |
FLITE_REG_CIGCTRL_IRQ_LASTEN |
-FLITE_REG_CIGCTRL_IRQ_STARTEN;
+FLITE_REG_CIGCTRL_IRQ_STARTEN |
+FLITE_REG_CIGCTRL_IRQ_ENDEN;
} else {
/* An output to the FIMC-IS */
intsrc = FLITE_REG_CIGCTRL_IRQ_OVFEN |
@@ -215,6 +216,18 @@ void flite_hw_set_camera_bus(struct fimc_lite *dev,
flite_hw_set_camera_port(dev, si-mux_id);
}
+static void flite_hw_set_pack12(struct fimc_lite *dev, int on)
+{
+ u32 cfg = readl(dev-regs + FLITE_REG_CIODMAFMT);
+
+ cfg = ~FLITE_REG_CIODMAFMT_PACK12;
+
+ if (on)
+ cfg |= FLITE_REG_CIODMAFMT_PACK12;
+
+ writel(cfg, dev-regs + FLITE_REG_CIODMAFMT);
+}
+
static void flite_hw_set_out_order(struct fimc_lite *dev, struct flite_frame
*f)
{
static const u32 pixcode[4][2] = {
@@ -267,6 +280,7 @@ void flite_hw_set_output_dma(struct fimc_lite *dev, struct
flite_frame *f,
flite_hw_set_out_order(dev, f);
flite_hw_set_dma_window(dev, f);
+ flite_hw_set_pack12(dev, 0);
}
void flite_hw_dump_regs(struct fimc_lite *dev, const char *label)
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite-reg.h
b/drivers/media/platform/s5p-fimc/fimc-lite-reg.h
index 0e34584..716df6c 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite-reg.h
+++ b/drivers/media/platform/s5p-fimc/fimc-lite-reg.h
@@ -120,6 +120,10 @@
/* b0: 1 - camera B, 0 - camera A */
#define FLITE_REG_CIGENERAL_CAM_B (1 0)
+
+#define FLITE_REG_CIFCNTSEQ0x100
+#define FLITE_REG_CIOSAN(x)(0x200 + (4 * (x)))
+
/*
* Function declarations
*/
@@ -143,8 +147,41 @@ void flite_hw_set_dma_window(struct fimc_lite *dev, struct
flite_frame *f);
void flite_hw_set_test_pattern(struct fimc_lite *dev, bool on);
void flite_hw_dump_regs(struct fimc_lite *dev, const char *label);
-static inline void flite_hw_set_output_addr(struct fimc_lite *dev, u32 paddr)
+static inline void flite_hw_set_output_addr(struct fimc_lite *dev,
+ u32 paddr, u32 index)
+{
+ u32 config;
+
+ /* FLITE in EXYNOS4 has only one DMA register */
+ if (dev-variant-version == FLITE_VER_EXYNOS4)
+ index = 0;
+
+ config = readl(dev-regs + FLITE_REG_CIFCNTSEQ);
+ config |= 1 index;
+ writel(config, dev-regs + FLITE_REG_CIFCNTSEQ);
+
+ if (index == 0)
+ writel(paddr, dev-regs + FLITE_REG_CIOSA);
+ else
+ writel(paddr, dev-regs + FLITE_REG_CIOSAN(index-1));
+}
+
+static inline void flite_hw_clear_output_addr(struct fimc_lite *dev, u32 index)
{
- writel(paddr, dev-regs + FLITE_REG_CIOSA);
+ u32 config;
+
+ /* FLITE in EXYNOS4 has only one DMA register */
+ if (dev-variant-version == FLITE_VER_EXYNOS4)
+ index = 0;
+
+ config = readl(dev-regs + FLITE_REG_CIFCNTSEQ);
+ config = ~(1 index);
+ writel(config, dev-regs + FLITE_REG_CIFCNTSEQ);
}
+
+static inline void flite_hw_clear_output_index(struct fimc_lite *dev)
+{
+ writel(0, dev-regs + FLITE_REG_CIFCNTSEQ);
+}
+
#endif /* FIMC_LITE_REG_H */
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index eb64f87..1edc5ce 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -136,6 +136,8 @@ static int fimc_lite_hw_init(struct fimc_lite *fimc, bool
isp_output)
if (fimc-fmt == NULL)
return -EINVAL;
+ flite_hw_clear_output_index(fimc);
+
/* Get sensor configuration data from the sensor
[RFC 04/12] s5p-csis: Adding Exynos5250 compatibility
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/s5p-fimc/mipi-csis.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/s5p-fimc/mipi-csis.c
b/drivers/media/platform/s5p-fimc/mipi-csis.c
index df4411c..debda7c 100644
--- a/drivers/media/platform/s5p-fimc/mipi-csis.c
+++ b/drivers/media/platform/s5p-fimc/mipi-csis.c
@@ -1002,6 +1002,7 @@ static const struct dev_pm_ops s5pcsis_pm_ops = {
static const struct of_device_id s5pcsis_of_match[] __devinitconst = {
{ .compatible = samsung,exynos3110-csis },
{ .compatible = samsung,exynos4210-csis },
+ { .compatible = samsung,exynos5250-csis },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, s5pcsis_of_match);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 05/12] ARM: EXYNOS: Add devicetree node for mipi-csis driver for exynos5
This patch adds necessary source definations needed for mipi-csis
driver and adds devicetree node for exynos5250.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 18 ++
arch/arm/mach-exynos/clock-exynos5.c| 16 ++--
arch/arm/mach-exynos/include/mach/map.h |3 +++
arch/arm/mach-exynos/mach-exynos5-dt.c |4
4 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3a2cd9a..4fff98b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -47,6 +47,8 @@
i2c6 = i2c_6;
i2c7 = i2c_7;
i2c8 = i2c_8;
+ csis0 = csis_0;
+ csis1 = csis_1;
};
gic:interrupt-controller@10481000 {
@@ -357,4 +359,20 @@
reg = 0x1445 0x1;
interrupts = 0 94 0;
};
+
+ csis_0: csis@13C2 {
+ compatible = samsung,exynos5250-csis;
+ reg = 0x13C2 0x4000;
+ interrupts = 0 79 0;
+ bus-width = 4;
+ status = disabled;
+ };
+
+ csis_1: csis@13C3 {
+ compatible = samsung,exynos5250-csis;
+ reg = 0x13C3 0x4000;
+ interrupts = 0 80 0;
+ bus-width = 4;
+ status = disabled;
+ };
};
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index e9d7b80..34a22ff 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -859,6 +859,16 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_gscl_ctrl,
.ctrlbit= (1 3),
}, {
+ .name = csis,
+ .devname= s5p-mipi-csis.0,
+ .enable = exynos5_clk_ip_gscl_ctrl,
+ .ctrlbit= (1 5),
+ }, {
+ .name = csis,
+ .devname= s5p-mipi-csis.1,
+ .enable = exynos5_clk_ip_gscl_ctrl,
+ .ctrlbit= (1 6),
+ }, {
.name = SYSMMU_CLOCK_NAME,
.devname= SYSMMU_CLOCK_DEVNAME(mfc_l, 0),
.enable = exynos5_clk_ip_mfc_ctrl,
@@ -1263,9 +1273,10 @@ static struct clksrc_clk exynos5_clksrcs[] = {
.reg_div = { .reg = EXYNOS5_CLKDIV_FSYS0, .shift = 20, .size =
4 },
}, {
.clk= {
- .name = sclk_gscl_wrap,
+ .name = sclk_csis,
.devname= s5p-mipi-csis.0,
.enable = exynos5_clksrc_mask_gscl_ctrl,
+ .parent = exynos5_clk_mout_mpll_user.clk,
.ctrlbit= (1 24),
},
.sources = exynos5_clkset_group,
@@ -1273,9 +1284,10 @@ static struct clksrc_clk exynos5_clksrcs[] = {
.reg_div = { .reg = EXYNOS5_CLKDIV_GSCL, .shift = 24, .size = 4
},
}, {
.clk= {
- .name = sclk_gscl_wrap,
+ .name = sclk_csis,
.devname= s5p-mipi-csis.1,
.enable = exynos5_clksrc_mask_gscl_ctrl,
+ .parent = exynos5_clk_mout_mpll_user.clk,
.ctrlbit= (1 28),
},
.sources = exynos5_clkset_group,
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 1df6abb..c834321 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -177,6 +177,9 @@
#define EXYNOS4_PA_MIPI_CSIS0 0x1188
#define EXYNOS4_PA_MIPI_CSIS1 0x1189
+#define EXYNOS5_PA_MIPI_CSIS0 0x13C2
+#define EXYNOS5_PA_MIPI_CSIS1 0x13C3
+
#define EXYNOS4_PA_FIMD0 0x11C0
#define EXYNOS4_PA_HSMMC(x)(0x1251 + ((x) * 0x1))
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index e99d3d8..c420349 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -104,6 +104,10 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
OF_DEV_AUXDATA(samsung,mfc-v6, 0x1100, s5p-mfc-v6, NULL),
OF_DEV_AUXDATA(samsung,exynos5250-tmu, 0x1006,
exynos-tmu, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-csis, EXYNOS5_PA_MIPI_CSIS0,
+ s5p-mipi-csis.0, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-csis, EXYNOS5_PA_MIPI_CSIS1,
+
[RFC 06/12] ARM: EXYNOS: Add devicetree node for FIMC-LITE driver for exynos5
This patch adds necessary source definitions needed for FIMC-LITE
driver and adds devicetree node for exynos5250.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 21 +
arch/arm/mach-exynos/clock-exynos5.c|4
arch/arm/mach-exynos/include/mach/map.h |4
arch/arm/mach-exynos/mach-exynos5-dt.c |6 ++
4 files changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 4fff98b..4754865 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -49,6 +49,9 @@
i2c8 = i2c_8;
csis0 = csis_0;
csis1 = csis_1;
+ fimc-lite0 = fimc_lite_0;
+ fimc-lite1 = fimc_lite_1;
+ fimc-lite2 = fimc_lite_2;
};
gic:interrupt-controller@10481000 {
@@ -375,4 +378,22 @@
bus-width = 4;
status = disabled;
};
+
+ fimc_lite_0: fimc-lite@13C0 {
+ compatible = samsung,exynos5250-fimc-lite;
+ reg = 0x13C0 0x1000;
+ interrupts = 0 125 0;
+ };
+
+ fimc_lite_1: fimc-lite@13C1 {
+ compatible = samsung,exynos5250-fimc-lite;
+ reg = 0x13C1 0x1000;
+ interrupts = 0 126 0;
+ };
+
+ fimc_lite_2: fimc-lite@13C9 {
+ compatible = samsung,exynos5250-fimc-lite;
+ reg = 0x13C9 0x1000;
+ interrupts = 0 110 0;
+ };
};
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 34a22ff..4536515 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -859,6 +859,10 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_gscl_ctrl,
.ctrlbit= (1 3),
}, {
+ .name = flite,
+ .enable = exynos5_clk_ip_gscl_ctrl,
+ .ctrlbit= (1 4),
+ }, {
.name = csis,
.devname= s5p-mipi-csis.0,
.enable = exynos5_clk_ip_gscl_ctrl,
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index c834321..5bfc744 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -125,6 +125,10 @@
#define EXYNOS4_PA_SYSMMU_MFC_L0x1362
#define EXYNOS4_PA_SYSMMU_MFC_R0x1363
+#define EXYNOS5_PA_FIMC_LITE0 0x13C0
+#define EXYNOS5_PA_FIMC_LITE1 0x13C1
+#define EXYNOS5_PA_FIMC_LITE2 0x13C9
+
#define EXYNOS5_PA_GSC00x13E0
#define EXYNOS5_PA_GSC10x13E1
#define EXYNOS5_PA_GSC20x13E2
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index c420349..f6c3223 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -108,6 +108,12 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
s5p-mipi-csis.0, NULL),
OF_DEV_AUXDATA(samsung,exynos5250-csis, EXYNOS5_PA_MIPI_CSIS1,
s5p-mipi-csis.1, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-fimc-lite, EXYNOS5_PA_FIMC_LITE0,
+ exynos5-fimc-lite.0, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-fimc-lite, EXYNOS5_PA_FIMC_LITE1,
+ exynos5-fimc-lite.1, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-fimc-lite, EXYNOS5_PA_FIMC_LITE2,
+ exynos5-fimc-lite.2, NULL),
{},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 07/12] media: exynos5-is: Adding media device driver for exynos5
This patch adds support for media device for EXYNOS5 SoCs. The current media device supports the following ips to connect through the media controller framework. * MIPI-CSIS Support interconnection(subdev interface) between devices * FIMC-LITE Support capture interface from device(Sensor, MIPI-CSIS) to memory Support interconnection(subdev interface) between devices G-Scaler will be added later to the current media device. * Gscaler: general scaler Support memory to memory interface Support output interface from memory to display device(LCD, TV) Support capture interface from device(FIMC-LITE, FIMD) to memory -- media 0 Camera Capture path consists of MIPI-CSIS, FIMC-LITE and G-Scaler ++ +---+ +-+ | Sensor | -- | FIMC-LITE | -- | G-Scaler-capture | ++ +---+ +-+ ++ +---+ +---+ +-+ | Sensor | -- | MIPI-CSIS | -- | FIMC-LITE | -- | G-Scaler-capture | ++ +---+ +---+ +-+ Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com --- drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile |1 + drivers/media/platform/exynos5-is/Kconfig|7 + drivers/media/platform/exynos5-is/Makefile |4 + drivers/media/platform/exynos5-is/exynos5-mdev.c | 1309 ++ drivers/media/platform/exynos5-is/exynos5-mdev.h | 107 ++ 6 files changed, 1429 insertions(+) create mode 100644 drivers/media/platform/exynos5-is/Kconfig create mode 100644 drivers/media/platform/exynos5-is/Makefile create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.c create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 2433e2b..f74bd92 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -123,6 +123,7 @@ config VIDEO_S3C_CAMIF source drivers/media/platform/soc_camera/Kconfig source drivers/media/platform/s5p-fimc/Kconfig +source drivers/media/platform/exynos5-is/Kconfig source drivers/media/platform/s5p-tv/Kconfig endif # V4L_PLATFORM_DRIVERS diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 42089ba..43da7ab 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)+= s5p-tv/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/ +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS5_MDEV) += exynos5-is/ obj-$(CONFIG_BLACKFIN) += blackfin/ diff --git a/drivers/media/platform/exynos5-is/Kconfig b/drivers/media/platform/exynos5-is/Kconfig new file mode 100644 index 000..7aacf3b --- /dev/null +++ b/drivers/media/platform/exynos5-is/Kconfig @@ -0,0 +1,7 @@ +config VIDEO_SAMSUNG_EXYNOS5_MDEV + bool Samsung Exynos5 Media Device driver + depends on VIDEO_DEV VIDEO_V4L2 ARCH_EXYNOS5 + help + This is a v4l2 based media controller driver for + Exynos5 SoC. + diff --git a/drivers/media/platform/exynos5-is/Makefile b/drivers/media/platform/exynos5-is/Makefile new file mode 100644 index 000..472d8e1 --- /dev/null +++ b/drivers/media/platform/exynos5-is/Makefile @@ -0,0 +1,4 @@ +ccflags-y += -Idrivers/media/platform/s5p-fimc +exynos-mdevice-objs := exynos5-mdev.o + +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS5_MDEV) += exynos-mdevice.o diff --git a/drivers/media/platform/exynos5-is/exynos5-mdev.c b/drivers/media/platform/exynos5-is/exynos5-mdev.c new file mode 100644 index 000..1158696 --- /dev/null +++ b/drivers/media/platform/exynos5-is/exynos5-mdev.c @@ -0,0 +1,1309 @@ +/* + * S5P/EXYNOS4 SoC series camera host interface media device driver + * + * Copyright (C) 2011 - 2012 Samsung Electronics Co., Ltd. + * Sylwester Nawrocki s.nawro...@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published + * by the Free Software Foundation, either version 2 of the License, + * or (at your option) any later version. + */ + +#include linux/bug.h +#include linux/device.h +#include linux/errno.h +#include linux/i2c.h +#include linux/kernel.h +#include linux/list.h +#include linux/module.h +#include linux/of.h +#include linux/of_platform.h +#include linux/of_device.h +#include linux/of_i2c.h +#include linux/pinctrl/consumer.h +#include linux/platform_device.h +#include linux/pm_runtime.h +#include linux/types.h +#include linux/slab.h +#include media/v4l2-ctrls.h +#include media/v4l2-of.h +#include media/media-device.h + +#include exynos5-mdev.h + +#define dbg(fmt, args...) \ + pr_debug(%s:%d: fmt \n, __func__, __LINE__, ##args) + +static struct fimc_md *g_exynos_mdev; + +static int fimc_md_set_camclk(struct
[RFC 08/12] ARM: dts: add camera specific pinctrl nodes for Exynos5250 SoC
Add device nodes for pinctrl group-1 for Exynos5250 SoC.
This only adds cam1 specific pinctrl nodes to the file.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 41 +
arch/arm/boot/dts/exynos5250.dtsi |7 +
2 files changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
index 24180fc..3caaa21 100644
--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
@@ -555,6 +555,47 @@
};
};
+ pinctrl@1340 {
+ gph0: gph0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gph1: gph1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ cam_port_a_io: cam-port-a-io {
+ samsung,pins = gph0-0, gph0-1, gph0-2, gph0-3,
+ gph1-0, gph1-1, gph1-2, gph1-3,
+ gph1-4, gph1-5, gph1-6, gph1-7;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 3;
+ };
+
+ cam_port_a_clk_active: cam-port-a-clk-active {
+ samsung,pins = gph0-3;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 3;
+ };
+
+ cam_port_a_clk_idle: cam-port-a-clk-idle {
+ samsung,pins = gph0-3;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+ };
+
pinctrl_3: pinctrl@0368 {
gpz: gpz {
gpio-controller;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 4754865..e09cda0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -37,6 +37,7 @@
mshc2 = dwmmc_2;
mshc3 = dwmmc_3;
pinctrl0 = pinctrl_0;
+ pinctrl1 = pinctrl_1;
pinctrl3 = pinctrl_3;
i2c0 = i2c_0;
i2c1 = i2c_1;
@@ -95,6 +96,12 @@
};
};
+ pinctrl_1: pinctrl@1340 {
+ compatible = samsung,pinctrl-exynos5250;
+ reg = 0x1340 0x1000;
+ interrupts = 0 47 0;
+ };
+
pinctrl_3: pinctrl@0368 {
compatible = samsung,pinctrl-exynos5250;
reg = 0x0368000 0x1000;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 09/12] ARM: dts: Adding pinctrl support to Exynos5250 i2c nodes
This patch adds the default pinctrl functionality to the
i2c device nodes on exynos5250-smdk5250.dts file
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 942d576..4b10744 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -30,8 +30,8 @@
i2c@12C6 {
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 2;
- gpios = gpb3 0 2 3 0,
- gpb3 1 2 3 0;
+ pinctrl-0 = i2c0_bus;
+ pinctrl-names = default;
eeprom@50 {
compatible = samsung,s524ad0xd1;
@@ -42,8 +42,8 @@
i2c@12C7 {
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 2;
- gpios = gpb3 2 2 3 0,
- gpb3 3 2 3 0;
+ pinctrl-0 = i2c1_bus;
+ pinctrl-names = default;
eeprom@51 {
compatible = samsung,s524ad0xd1;
@@ -69,8 +69,8 @@
i2c@12C8 {
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
- gpios = gpa0 6 3 3 0,
- gpa0 7 3 3 0;
+ pinctrl-0 = i2c2_bus;
+ pinctrl-names = default;
hdmiddc@50 {
compatible = samsung,exynos5-hdmiddc;
@@ -80,22 +80,32 @@
i2c@12C9 {
status = disabled;
+ pinctrl-0 = i2c3_bus;
+ pinctrl-names = default;
};
i2c@12CA {
status = disabled;
+ pinctrl-0 = i2c4_bus;
+ pinctrl-names = default;
};
i2c@12CB {
status = disabled;
+ pinctrl-0 = i2c5_bus;
+ pinctrl-names = default;
};
i2c@12CC {
status = disabled;
+ pinctrl-0 = i2c6_bus;
+ pinctrl-names = default;
};
i2c@12CD {
status = disabled;
+ pinctrl-0 = i2c7_bus;
+ pinctrl-names = default;
};
i2c@12CE {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 10/12] ARM: dts: Adding media device nodes to Exynos5 SoCs
This patch adds the media device driver specific dt bindings
to the Exynos5 specific SoCs.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 64 +
1 file changed, 36 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index e09cda0..564c05f 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -370,37 +370,45 @@
interrupts = 0 94 0;
};
- csis_0: csis@13C2 {
- compatible = samsung,exynos5250-csis;
- reg = 0x13C2 0x4000;
- interrupts = 0 79 0;
- bus-width = 4;
- status = disabled;
- };
+ camera {
+ compatible = samsung,exynos5-fimc, simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
- csis_1: csis@13C3 {
- compatible = samsung,exynos5250-csis;
- reg = 0x13C3 0x4000;
- interrupts = 0 80 0;
- bus-width = 4;
- status = disabled;
- };
+ fimc_lite_0: fimc-lite@13C0 {
+ compatible = samsung,exynos5250-fimc-lite;
+ reg = 0x13C0 0x1000;
+ interrupts = 0 125 0;
+ };
- fimc_lite_0: fimc-lite@13C0 {
- compatible = samsung,exynos5250-fimc-lite;
- reg = 0x13C0 0x1000;
- interrupts = 0 125 0;
- };
+ fimc_lite_1: fimc-lite@13C1 {
+ compatible = samsung,exynos5250-fimc-lite;
+ reg = 0x13C1 0x1000;
+ interrupts = 0 126 0;
+ };
- fimc_lite_1: fimc-lite@13C1 {
- compatible = samsung,exynos5250-fimc-lite;
- reg = 0x13C1 0x1000;
- interrupts = 0 126 0;
- };
+ fimc_lite_2: fimc-lite@13C9 {
+ compatible = samsung,exynos5250-fimc-lite;
+ reg = 0x13C9 0x1000;
+ interrupts = 0 110 0;
+ };
- fimc_lite_2: fimc-lite@13C9 {
- compatible = samsung,exynos5250-fimc-lite;
- reg = 0x13C9 0x1000;
- interrupts = 0 110 0;
+ csis_0: csis@13C2 {
+ compatible = samsung,exynos5250-csis;
+ reg = 0x13C2 0x4000;
+ interrupts = 0 79 0;
+ bus-width = 4;
+ clock-names = csis, sclk_csis, mux, parent;
+ status = disabled;
+ };
+
+ csis_1: csis@13C3 {
+ compatible = samsung,exynos5250-csis;
+ reg = 0x13C3 0x4000;
+ interrupts = 0 80 0;
+ bus-width = 2;
+ status = disabled;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 11/12] media: m5mols: Adding dt support to m5mols driver
This patch adds the dt support to m5mols driver.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/i2c/m5mols/m5mols_core.c | 54 +++-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/m5mols/m5mols_core.c
b/drivers/media/i2c/m5mols/m5mols_core.c
index d4e7567..21c66ef 100644
--- a/drivers/media/i2c/m5mols/m5mols_core.c
+++ b/drivers/media/i2c/m5mols/m5mols_core.c
@@ -19,6 +19,8 @@
#include linux/interrupt.h
#include linux/delay.h
#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/pinctrl/consumer.h
#include linux/regulator/consumer.h
#include linux/videodev2.h
#include linux/module.h
@@ -926,13 +928,38 @@ static irqreturn_t m5mols_irq_handler(int irq, void *data)
return IRQ_HANDLED;
}
+static const struct of_device_id m5mols_match[];
+
static int m5mols_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- const struct m5mols_platform_data *pdata = client-dev.platform_data;
+ struct m5mols_platform_data *pdata;
struct m5mols_info *info;
+ const struct of_device_id *of_id;
struct v4l2_subdev *sd;
int ret;
+ struct pinctrl *pctrl;
+ int eint_gpio = 0;
+
+ if (client-dev.of_node) {
+ of_id = of_match_node(m5mols_match, client-dev.of_node);
+ if (of_id)
+ pdata = (struct m5mols_platform_data *)of_id-data;
+ client-dev.platform_data = pdata;
+ } else {
+ pdata = client-dev.platform_data;
+ }
+
+ if (!pdata)
+ return -EINVAL;
+
+ pctrl = devm_pinctrl_get_select_default(client-dev);
+ if (client-dev.of_node) {
+ eint_gpio = of_get_named_gpio(client-dev.of_node, gpios, 0);
+ client-irq = gpio_to_irq(eint_gpio);
+ pdata-gpio_reset = of_get_named_gpio(client-dev.of_node,
+ gpios, 1);
+ }
if (pdata == NULL) {
dev_err(client-dev, No platform data\n);
@@ -1040,9 +1067,34 @@ static const struct i2c_device_id m5mols_id[] = {
};
MODULE_DEVICE_TABLE(i2c, m5mols_id);
+static int m5mols_set_power(struct device *dev, int on)
+{
+ struct m5mols_platform_data *pdata =
+ (struct m5mols_platform_data *)dev-platform_data;
+ gpio_set_value(pdata-gpio_reset, !on);
+ gpio_set_value(pdata-gpio_reset, !!on);
+ return 0;
+}
+
+static struct m5mols_platform_data m5mols_drvdata = {
+ .gpio_reset = 0,
+ .reset_polarity = 0,
+ .set_power = m5mols_set_power,
+};
+
+static const struct of_device_id m5mols_match[] = {
+ {
+ .compatible = fujitsu,m-5mols,
+ .data = m5mols_drvdata,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, m5mols_match);
+
static struct i2c_driver m5mols_i2c_driver = {
.driver = {
.name = MODULE_NAME,
+ .of_match_table = m5mols_match,
},
.probe = m5mols_probe,
.remove = m5mols_remove,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 12/12] ARM: dts: Add camera node to exynos5250-smdk5250.dts
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 43 -
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 4b10744..7fbc236 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -85,9 +85,26 @@
};
i2c@12CA {
- status = disabled;
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 10;
pinctrl-0 = i2c4_bus;
pinctrl-names = default;
+
+ m5mols@1f {
+ compatible = fujitsu,m-5mols;
+ reg = 0x1F;
+ gpios = gpx3 3 0xf, gpx1 2 1;
+ clock-frequency = 2400;
+ pinctrl-0 = cam_port_a_clk_active;
+ pinctrl-names = default;
+
+ port {
+ m5mols_ep: endpoint {
+ remote-endpoint = csis0_ep;
+ };
+ };
+
+ };
};
i2c@12CB {
@@ -214,4 +231,28 @@
samsung,mfc-r = 0x4300 0x80;
samsung,mfc-l = 0x5100 0x80;
};
+
+ camera {
+ compatible = samsung,exynos5-fimc, simple-bus;
+ status = okay;
+
+ csis_0: csis@13C2 {
+ status = okay;
+ clock-frequency = 16600;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ /* Camera C (3) MIPI CSI-2 (CSIS0) */
+ port@3 {
+ reg = 3;
+ csis0_ep: endpoint {
+ remote-endpoint = m5mols_ep;
+ data-lanes = 1 2 3 4;
+ samsung,csis-hs-settle = 12;
+ samsung,csis-wclk;
+ };
+ };
+ };
+
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] s5p-mfc: Fix encoder control 15 issue
mfc-encoder is not working in the latest kernel giving the
erorr Adding control (15) failed. Adding the missing step
parameter in this control to fix the issue.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 2356fd5..4f6b553 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -232,6 +232,7 @@ static struct mfc_control controls[] = {
.minimum = 0,
.maximum = 1,
.default_value = 0,
+ .step = 1,
.menu_skip_mask = 0,
},
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
TerraTec Cinergy T PCIe Dual not working
Hi all, I have a TerraTec Cinergy T PCIe Dual card and I can't get it to work. I had been using it several months ago, with some success, although the stability wasn't ideal. Then I moved it to another machine to check if it was any better on Windows (and indeed it was better.) Now I put it back in my system and I can't get it to work at all. I have the following relevant kernel log messages: [0.362783] pci :0b:00.0: [14f1:8852] type 00 class 0x04 [0.362809] pci :0b:00.0: reg 10: [mem 0xfbc0-0xfbdf 64bit] [0.362940] pci :0b:00.0: supports D1 D2 [0.362942] pci :0b:00.0: PME# supported from D0 D1 D2 D3hot [0.362967] pci :0b:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' [6.313259] cx23885 driver version 0.0.3 loaded [6.313898] CORE cx23885[0]: subsystem: 153b:117e, board: TerraTec Cinergy T PCIe Dual [card=34,autodetected] [6.498999] cx25840 11-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0]) [7.114399] cx25840 11-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [7.150641] cx23885_dvb_register() allocating 1 frontend(s) [7.150704] cx23885[0]: cx23885 based dvb card [7.178681] drxk: status = 0x639160d9 [7.180049] drxk: detected a drx-3916k, spin A3, xtal 20.250 MHz [7.245259] DRXK driver version 0.9.4300 [7.268760] drxk: frontend initialized. [7.961207] mt2063_attach: Attaching MT2063 [7.961271] DVB: registering new adapter (cx23885[0]) [7.961332] DVB: registering adapter 0 frontend 0 (DRXK DVB-T)... [7.961877] cx23885_dvb_register() allocating 1 frontend(s) [7.961881] cx23885[0]: cx23885 based dvb card [7.974320] drxk: status = 0x639130d9 [7.975838] drxk: detected a drx-3913k, spin A3, xtal 20.250 MHz [8.040888] DRXK driver version 0.9.4300 [8.064459] drxk: frontend initialized. [8.064467] mt2063_attach: Attaching MT2063 [8.064475] DVB: registering new adapter (cx23885[0]) [8.064482] DVB: registering adapter 1 frontend 0 (DRXK DVB-C DVB-T)... [8.065919] cx23885_dev_checkrevision() Hardware revision = 0xa5 [8.066004] cx23885[0]/0: found at :0b:00.0, rev: 4, irq: 28, latency: 0, mmio: 0xfbc0 [ 27.281490] mt2063: detected a mt2063 B3 [ 27.319390] mt2063: detected a mt2063 B3 I don't see anything wrong here, all the components are apparently found and identified properly. However I can't get the card to actually work, neither in me-tv nor in VLC. Me-tv (version 1.3.6) tells me: 03/06/13 14:20:10: Device: 'DRXK DVB-T' (DVB-T) at /dev/dvb/adapter0/frontend0 03/06/13 14:20:11: Device: 'DRXK DVB-C DVB-T' (DVB-C) at /dev/dvb/adapter1/frontend0 03/06/13 14:20:11: Frontend::tune_to(49000) 03/06/13 14:20:11: Waiting for signal lock ... And then Failed to lock channel. VLC (version 2.0.5) tells me: main stream error: cannot pre fill buffer I tried with kernels 3.4.30, 3.5.7, 3.6.0, 3.6.11, 3.7.10 and 3.8.2, with exactly the same results. How would I debug this further? Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TerraTec Cinergy T PCIe Dual not working
I have the same card, and have not much problems. I have some reception issues, but I don't think it's to blame on the card (yet). I do use tvheadend however. In anycase, can you use w_scan or dvb-scan? On 06-03-13 14:27, Jean Delvare wrote: Hi all, I have a TerraTec Cinergy T PCIe Dual card and I can't get it to work. I had been using it several months ago, with some success, although the stability wasn't ideal. Then I moved it to another machine to check if it was any better on Windows (and indeed it was better.) Now I put it back in my system and I can't get it to work at all. I have the following relevant kernel log messages: [0.362783] pci :0b:00.0: [14f1:8852] type 00 class 0x04 [0.362809] pci :0b:00.0: reg 10: [mem 0xfbc0-0xfbdf 64bit] [0.362940] pci :0b:00.0: supports D1 D2 [0.362942] pci :0b:00.0: PME# supported from D0 D1 D2 D3hot [0.362967] pci :0b:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' [6.313259] cx23885 driver version 0.0.3 loaded [6.313898] CORE cx23885[0]: subsystem: 153b:117e, board: TerraTec Cinergy T PCIe Dual [card=34,autodetected] [6.498999] cx25840 11-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0]) [7.114399] cx25840 11-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [7.150641] cx23885_dvb_register() allocating 1 frontend(s) [7.150704] cx23885[0]: cx23885 based dvb card [7.178681] drxk: status = 0x639160d9 [7.180049] drxk: detected a drx-3916k, spin A3, xtal 20.250 MHz [7.245259] DRXK driver version 0.9.4300 [7.268760] drxk: frontend initialized. [7.961207] mt2063_attach: Attaching MT2063 [7.961271] DVB: registering new adapter (cx23885[0]) [7.961332] DVB: registering adapter 0 frontend 0 (DRXK DVB-T)... [7.961877] cx23885_dvb_register() allocating 1 frontend(s) [7.961881] cx23885[0]: cx23885 based dvb card [7.974320] drxk: status = 0x639130d9 [7.975838] drxk: detected a drx-3913k, spin A3, xtal 20.250 MHz [8.040888] DRXK driver version 0.9.4300 [8.064459] drxk: frontend initialized. [8.064467] mt2063_attach: Attaching MT2063 [8.064475] DVB: registering new adapter (cx23885[0]) [8.064482] DVB: registering adapter 1 frontend 0 (DRXK DVB-C DVB-T)... [8.065919] cx23885_dev_checkrevision() Hardware revision = 0xa5 [8.066004] cx23885[0]/0: found at :0b:00.0, rev: 4, irq: 28, latency: 0, mmio: 0xfbc0 [ 27.281490] mt2063: detected a mt2063 B3 [ 27.319390] mt2063: detected a mt2063 B3 I don't see anything wrong here, all the components are apparently found and identified properly. However I can't get the card to actually work, neither in me-tv nor in VLC. Me-tv (version 1.3.6) tells me: 03/06/13 14:20:10: Device: 'DRXK DVB-T' (DVB-T) at /dev/dvb/adapter0/frontend0 03/06/13 14:20:11: Device: 'DRXK DVB-C DVB-T' (DVB-C) at /dev/dvb/adapter1/frontend0 03/06/13 14:20:11: Frontend::tune_to(49000) 03/06/13 14:20:11: Waiting for signal lock ... And then Failed to lock channel. VLC (version 2.0.5) tells me: main stream error: cannot pre fill buffer I tried with kernels 3.4.30, 3.5.7, 3.6.0, 3.6.11, 3.7.10 and 3.8.2, with exactly the same results. How would I debug this further? Thanks, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH V4 01/12] [media] marvell-ccic: add MIPI support for marvell-ccic driver
Hi, Guennadi
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Tuesday, 05 March, 2013 18:21
To: Albert Wang
Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [REVIEW PATCH V4 01/12] [media] marvell-ccic: add MIPI support for
marvell-ccic driver
Oh, one more thing occurred to me after looking at your another patch:
On Thu, 7 Feb 2013, Albert Wang wrote:
From: Libin Yang lby...@marvell.com
This patch adds the MIPI support for marvell-ccic.
Board driver should determine whether using MIPI or not.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 66 +
drivers/media/platform/marvell-ccic/mcam-core.h | 28 +-
drivers/media/platform/marvell-ccic/mmp-driver.c | 113
+-
include/media/mmp-camera.h | 10 ++
4 files changed, 214 insertions(+), 3 deletions(-)
[snip]
@@ -183,8 +285,18 @@ static int mmpcam_probe(struct platform_device *pdev)
mcam = cam-mcam;
mcam-plat_power_up = mmpcam_power_up;
mcam-plat_power_down = mmpcam_power_down;
+mcam-calc_dphy = mmpcam_calc_dphy;
mcam-dev = pdev-dev;
mcam-use_smbus = 0;
+mcam-bus_type = pdata-bus_type;
+mcam-dphy = pdata-dphy;
+/* mosetly it won't happen. dphy is an array in pdata, but in case .. */
+if (unlikely(mcam-dphy == NULL)) {
There's no such case - you did define it as an array, this will never be
NULL.
Yes, we will change it.
+ret = -EINVAL;
+goto out_free;
+}
+mcam-mipi_enabled = 0;
+mcam-lane = pdata-lane;
mcam-chip_id = V4L2_IDENT_ARMADA610;
mcam-buffer_mode = B_DMA_sg;
spin_lock_init(mcam-dev_lock);
@@ -223,7 +335,6 @@ static int mmpcam_probe(struct platform_device *pdev)
* Find the i2c adapter. This assumes, of course, that the
* i2c bus is already up and functioning.
*/
-pdata = pdev-dev.platform_data;
mcam-i2c_adapter = platform_get_drvdata(pdata-i2c_device);
if (mcam-i2c_adapter == NULL) {
ret = -ENODEV;
diff --git a/include/media/mmp-camera.h b/include/media/mmp-camera.h
index 7611963..813efe2 100755
--- a/include/media/mmp-camera.h
+++ b/include/media/mmp-camera.h
@@ -1,3 +1,4 @@
+#include media/v4l2-mediabus.h
/*
* Information for the Marvell Armada MMP camera
*/
@@ -6,4 +7,13 @@ struct mmp_camera_platform_data {
struct platform_device *i2c_device;
int sensor_power_gpio;
int sensor_reset_gpio;
+enum v4l2_mbus_type bus_type;
+/*
+ * MIPI support
+ */
+int dphy[3];/* DPHY: CSI2_DPHY3, CSI2_DPHY5, CSI2_DPHY6 */
+int dphy3_algo; /* Exist 2 algos for calculate CSI2_DPHY3 */
+int mipi_enabled; /* MIPI enabled flag */
+int lane; /* ccic used lane number; 0 means DVP mode */
+int lane_clk;
};
--
1.7.9.5
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Thanks
Albert Wang
86-21-61092656
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH V4 05/12] [media] marvell-ccic: add new formats support for marvell-ccic driver
Hi, Guennadi
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Tuesday, 05 March, 2013 18:08
To: Albert Wang
Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [REVIEW PATCH V4 05/12] [media] marvell-ccic: add new formats
support
for marvell-ccic driver
Looks pretty good to me now, just one nitpick:
On Thu, 7 Feb 2013, Albert Wang wrote:
From: Libin Yang lby...@marvell.com
This patch adds the new formats support for marvell-ccic.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 189
+++
drivers/media/platform/marvell-ccic/mcam-core.h |6 +
2 files changed, 162 insertions(+), 33 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index f89fce7..0f9604e 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
[snip]
@@ -971,11 +1062,35 @@ static void mcam_vb_buf_queue(struct vb2_buffer *vb)
{
struct mcam_vb_buffer *mvb = vb_to_mvb(vb);
struct mcam_camera *cam = vb2_get_drv_priv(vb-vb2_queue);
+struct v4l2_pix_format *fmt = cam-pix_format;
unsigned long flags;
int start;
+dma_addr_t dma_handle;
+u32 pixel_count = fmt-width * fmt-height;
spin_lock_irqsave(cam-dev_lock, flags);
+dma_handle = vb2_dma_contig_plane_dma_addr(vb, 0);
+BUG_ON(!dma_handle);
Again - a bit too strong. But the truth is - .buf_queue() cannot fail...
Would it be possible to move this pointer calculation to .buf_prepare(),
which does return an error code?
Yes, we will remove all BUG_ON macros, replace them with error or warning msg.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Thanks
Albert Wang
86-21-61092656
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH V4 01/12] [media] marvell-ccic: add MIPI support for marvell-ccic driver
Hi, Guennadi
Thank you very much for your review and comments!
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Tuesday, 05 March, 2013 05:35
To: Albert Wang
Cc: cor...@lwn.net; Linux Media Mailing List; Libin Yang
Subject: Re: [REVIEW PATCH V4 01/12] [media] marvell-ccic: add MIPI support for
marvell-ccic driver
Hi Albert
A general comment first: I have no idea about this hardware, so, feel free
to ignore all my hardware-handling related comments. But just from looking
your handling of the pll1 clock does seem a bit fishy to me. You acquire
and release the clock in the generic mcam code, but only use it in the mmp
driver. Is it really needed centrally? Wouldn't it suffice to only acquire
it in mmp? Same goes for your mcam_config_mipi() function - is it really
needed centrally? But as I said, maybe I'm just missing something.
On Thu, 7 Feb 2013, Albert Wang wrote:
From: Libin Yang lby...@marvell.com
This patch adds the MIPI support for marvell-ccic.
Board driver should determine whether using MIPI or not.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 66 +
drivers/media/platform/marvell-ccic/mcam-core.h | 28 +-
drivers/media/platform/marvell-ccic/mmp-driver.c | 113
+-
include/media/mmp-camera.h | 10 ++
4 files changed, 214 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 7012913f..7e178d8 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -19,6 +19,7 @@
#include linux/delay.h
#include linux/vmalloc.h
#include linux/io.h
+#include linux/clk.h
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
@@ -253,6 +254,39 @@ static void mcam_ctlr_stop(struct mcam_camera *cam)
mcam_reg_clear_bit(cam, REG_CTRL0, C0_ENABLE);
}
+static int mcam_config_mipi(struct mcam_camera *mcam, int enable)
+{
+if (mcam-bus_type == V4L2_MBUS_CSI2 enable) {
This function is only called twice in the code: both times with a const
enable - once 1 and once 0. But you also do a disable, if the parallel
bus is used. Wouldn't it look prettier as
+static int mcam_config_mipi(struct mcam_camera *mcam, bool enable)
+{
+ if (enable) {
And then see the change below.
OK, we can think about it.
+/* Using MIPI mode and enable MIPI */
+cam_dbg(mcam, camera: DPHY3=0x%x, DPHY5=0x%x,
DPHY6=0x%x\n,
+mcam-dphy[0], mcam-dphy[1], mcam-dphy[2]);
+mcam_reg_write(mcam, REG_CSI2_DPHY3, mcam-dphy[0]);
+mcam_reg_write(mcam, REG_CSI2_DPHY5, mcam-dphy[1]);
+mcam_reg_write(mcam, REG_CSI2_DPHY6, mcam-dphy[2]);
+
+if (mcam-mipi_enabled == 0) {
+BUG_ON(mcam-lane 4 || mcam-lane = 0);
A recent discussion about the use of BUG* macros in the kernel indicated,
that you only should BUG() the kernel, when there's really no way to
continue and the system would die soon anyway. Otherwise produce an error
/ warning message and return an error code (if possible).
Yes, you are right, we will change it.
+/*
+ * 0x41 actives 1 lane
+ * 0x43 actives 2 lanes
+ * 0x45 actives 3 lanes (never happen)
+ * 0x47 actives 4 lanes
+ */
+mcam_reg_write(mcam, REG_CSI2_CTRL0,
+CSI2_C0_MIPI_EN | CSI2_C0_ACT_LANE(mcam-lane));
+mcam-mipi_enabled = 1;
+}
+} else {
+/* Using Parallel mode or disable MIPI */
+mcam_reg_write(mcam, REG_CSI2_CTRL0, 0x0);
+mcam_reg_write(mcam, REG_CSI2_DPHY3, 0x0);
+mcam_reg_write(mcam, REG_CSI2_DPHY5, 0x0);
+mcam_reg_write(mcam, REG_CSI2_DPHY6, 0x0);
+mcam-mipi_enabled = 0;
+}
+return 0;
If you convert the above BUG() to a failure, then you need this return
value, in this version this function never fails.
+}
+
/* --- */
#ifdef MCAM_MODE_VMALLOC
@@ -656,6 +690,13 @@ static void mcam_ctlr_image(struct mcam_camera *cam)
*/
mcam_reg_write_mask(cam, REG_CTRL0, C0_SIF_HVSYNC,
C0_SIFM_MASK);
+
+/*
+ * This field controls the generation of EOF(DVP only)
+ */
+if (cam-bus_type != V4L2_MBUS_CSI2)
+mcam_reg_set_bit(cam, REG_CTRL0,
+C0_EOF_VSYNC | C0_VEDGE_CTRL);
}
@@ -886,6 +927,16 @@ static int mcam_read_setup(struct mcam_camera *cam)
spin_lock_irqsave(cam-dev_lock, flags);
clear_bit(CF_DMA_ACTIVE,
RE: [REVIEW PATCH V4 02/12] [media] marvell-ccic: add clock tree support for marvell-ccic driver
Hi, Guennadi
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Tuesday, 05 March, 2013 17:51
To: Albert Wang
Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [REVIEW PATCH V4 02/12] [media] marvell-ccic: add clock tree
support for
marvell-ccic driver
Hi Albert
On Thu, 7 Feb 2013, Albert Wang wrote:
From: Libin Yang lby...@marvell.com
This patch adds the clock tree support for marvell-ccic.
Signed-off-by: Libin Yang lby...@marvell.com
Signed-off-by: Albert Wang twan...@marvell.com
Acked-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/platform/marvell-ccic/mcam-core.h |4 ++
drivers/media/platform/marvell-ccic/mmp-driver.c | 47
++
2 files changed, 51 insertions(+)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index f73a801..2b2dc06 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -82,6 +82,8 @@ struct mcam_frame_state {
unsigned int delivered;
};
+#define NR_MCAM_CLK 3
+
/*
* A description of one of our devices.
* Locking: controlled by s_mutex. Certain fields, however, require
@@ -109,6 +111,8 @@ struct mcam_camera {
int lane; /* lane number */
struct clk *pll1;
+/* clock tree support */
+struct clk *clk[NR_MCAM_CLK];
/*
* Callbacks from the core to the platform code.
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 7ab01e9..2fe0324 100755
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -35,6 +35,8 @@ MODULE_ALIAS(platform:mmp-camera);
MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
MODULE_LICENSE(GPL);
+static char *mcam_clks[] = {CCICAXICLK, CCICFUNCLK, CCICPHYCLK};
+
It's good, you are using fixed clock names now!
struct mmp_camera {
void *power_regs;
struct platform_device *pdev;
@@ -104,6 +106,26 @@ static struct mmp_camera *mmpcam_find_device(struct
platform_device *pdev)
#define REG_CCIC_DCGCR 0x28/* CCIC dyn clock gate ctrl reg
*/
#define REG_CCIC_CRCR 0x50/* CCIC clk reset ctrl reg
*/
+static void mcam_clk_enable(struct mcam_camera *mcam)
+{
+unsigned int i;
+
+for (i = 0; i NR_MCAM_CLK; i++) {
+if (mcam-clk[i])
+clk_enable(mcam-clk[i]);
I think it's generally considered a better option to use
clk_prepare_enable() and clk_disable_unprepare() instead of just
clk_enable() and clk_disable().
Sounds great, we will think about it.
+}
+}
+
+static void mcam_clk_disable(struct mcam_camera *mcam)
+{
+int i;
+
+for (i = NR_MCAM_CLK - 1; i = 0; i--) {
+if (mcam-clk[i])
+clk_disable(mcam-clk[i]);
+}
+}
+
/*
* Power control.
*/
@@ -134,6 +156,8 @@ static void mmpcam_power_up(struct mcam_camera *mcam)
mdelay(5);
gpio_set_value(pdata-sensor_reset_gpio, 1); /* reset is active low */
mdelay(5);
+
+mcam_clk_enable(mcam);
}
static void mmpcam_power_down(struct mcam_camera *mcam)
@@ -151,6 +175,8 @@ static void mmpcam_power_down(struct mcam_camera
*mcam)
pdata = cam-pdev-dev.platform_data;
gpio_set_value(pdata-sensor_power_gpio, 0);
gpio_set_value(pdata-sensor_reset_gpio, 0);
+
+mcam_clk_disable(mcam);
}
/*
@@ -263,6 +289,23 @@ static irqreturn_t mmpcam_irq(int irq, void *data)
return IRQ_RETVAL(handled);
}
+static int mcam_init_clk(struct mcam_camera *mcam,
+struct mmp_camera_platform_data *pdata)
+{
+unsigned int i;
+
+for (i = 0; i NR_MCAM_CLK; i++) {
+if (mcam_clks[i] != NULL) {
+mcam-clk[i] = devm_clk_get(mcam-dev, mcam_clks[i]);
+if (IS_ERR(mcam-clk[i])) {
+dev_err(mcam-dev, Could not get clk: %s\n,
+mcam_clks[i]);
+return PTR_ERR(mcam-clk[i]);
+}
+}
+}
+return 0;
+}
static int mmpcam_probe(struct platform_device *pdev)
{
@@ -331,6 +374,10 @@ static int mmpcam_probe(struct platform_device *pdev)
ret = -ENODEV;
goto out_unmap1;
}
+
+ret = mcam_init_clk(mcam, pdata);
+if (ret)
+goto out_unmap2;
Now, I'm confused again: doesn't this mean, that all existing users of
this driver will fail?
Sorry, I don't understand what's your concern?
/*
* Find the i2c adapter. This assumes, of course, that the
* i2c bus is already up and functioning.
--
1.7.9.5
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
RE: [REVIEW PATCH V4 07/12] [media] marvell-ccic: switch to resource managed allocation and request
Hi, Guennadi
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Tuesday, 05 March, 2013 18:18
To: Albert Wang
Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [REVIEW PATCH V4 07/12] [media] marvell-ccic: switch to resource
managed allocation and request
Yet one more nitpick
On Thu, 7 Feb 2013, Albert Wang wrote:
This patch switchs to resource managed allocation and request in mmp-driver.
It can remove free resource operations.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
Acked-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/platform/marvell-ccic/mmp-driver.c | 65
--
1 file changed, 22 insertions(+), 43 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 818abf3..d355840 100755
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
[snip]
@@ -374,14 +373,12 @@ static int mmpcam_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
dev_err(pdev-dev, no iomem resource!\n);
-ret = -ENODEV;
-goto out_free;
+return -ENODEV;
}
-mcam-regs = ioremap(res-start, resource_size(res));
+mcam-regs = devm_request_and_ioremap(pdev-dev, res);
Don't kill me, but they've recently invented devm_ioremap_resource(),
which is essentially the same as devm_request_and_ioremap(), but also
returns an error code and prints an error message, so, you wouldn't have
to invent -ENODEV yourself and you don't need the dev_err() below.
OK, we will investigate devm_ioremap_resource() and use it if need.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Thanks
Albert Wang
86-21-61092656
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: davinci: kconfig: fix incorrect selects
On 3/6/2013 4:05 PM, Prabhakar Lad wrote: On Wed, Mar 6, 2013 at 3:53 PM, Sekhar Nori nsek...@ti.com wrote: On 3/6/2013 3:46 PM, Prabhakar Lad wrote: Sekhar, On Wed, Mar 6, 2013 at 3:37 PM, Sekhar Nori nsek...@ti.com wrote: On 3/6/2013 2:59 PM, Prabhakar Lad wrote: config VIDEO_DAVINCI_VPIF_DISPLAY tristate DM646x/DA850/OMAPL138 EVM Video Display - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 if MEDIA_SUBDRV_AUTOSELECT select VIDEO_THS7303 if MEDIA_SUBDRV_AUTOSELECT help @@ -15,9 +14,8 @@ config VIDEO_DAVINCI_VPIF_DISPLAY config VIDEO_DAVINCI_VPIF_CAPTURE tristate DM646x/DA850/OMAPL138 EVM Video Capture - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF help Enables Davinci VPIF module used for captur devices. This module is common for following DM6467/DA850/OMAPL138 @@ -28,7 +26,7 @@ config VIDEO_DAVINCI_VPIF_CAPTURE config VIDEO_DAVINCI_VPIF tristate DaVinci VPIF Driver - depends on VIDEO_DAVINCI_VPIF_DISPLAY || VIDEO_DAVINCI_VPIF_CAPTURE + depends on ARCH_DAVINCI It would be better if this was depends on MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM rather than 'ARCH_DAVINCI' then you can remove 'MACH_DAVINCI_DM6467_EVM' and 'MACH_DAVINCI_DA850_EVM' dependency from VIDEO_DAVINCI_VPIF_DISPLAY and VIDEO_DAVINCI_VPIF_CAPTURE. So it would be just 'depends on VIDEO_DEV VIDEO_DAVINCI_VPIF' I could, but vpif.c seems pretty board independent to me. Are you sure no other board would like to build vpif.c? BTW, are vpif_display.c and vpif_capture.c really that board specific? May be we can all make them depend on ARCH_DAVINCI? VPIF is present only in DM646x and DA850/OMAP-L1138. vpif.c is common file which is used by vpif_capture and vpif_display. So vpif.c per se doesn't do anything useful. Why the dependency on EVMs? There are other boards for these platform which could use VPIF. yep agreed! So instead of presenting a non-useful vpif selection to users, vpif.c dependency is better handled in makefile, no? How about the patch below (now also rebased on v3.9-rc1)? What about vpss.c? Does it make sense not to present a config for that as well? I also noticed that module build of VPIF is broken in mainline. That needs to be fixed too. Thanks, Sekhar ---8--- From: Sekhar Nori nsek...@ti.com Date: Tue, 5 Mar 2013 19:08:59 +0530 Subject: [PATCH] media: davinci: kconfig: fix incorrect selects drivers/media/platform/davinci/Kconfig uses selects where it should be using 'depends on'. This results in warnings of the following sort when doing randconfig builds. warning: (VIDEO_DM6446_CCDC VIDEO_DM355_CCDC VIDEO_ISIF VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT V4L_PLATFORM_DRIVERS ARCH_DAVINCI) The VPIF kconfigs had a strange 'select' and 'depends on' cross linkage which have been fixed as well by removing unneeded VIDEO_DAVINCI_VPIF config symbol. Selecting VPIF is now possible on all DaVinci platforms instead of two specific EVMs earlier. While at it, fix the Kconfig help text to make it more readable. This patch has only been build tested, I do not have the setup to test video. I also do not know if the dependencies are really needed, I have just tried to not break any existing assumptions. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Sekhar Nori nsek...@ti.com --- drivers/media/platform/davinci/Kconfig | 41 ++- drivers/media/platform/davinci/Makefile |7 ++ 2 files changed, 15 insertions(+), 33 deletions(-) diff --git a/drivers/media/platform/davinci/Kconfig b/drivers/media/platform/davinci/Kconfig index ccfde4e..42152f9 100644 --- a/drivers/media/platform/davinci/Kconfig +++ b/drivers/media/platform/davinci/Kconfig @@ -1,40 +1,29 @@ config VIDEO_DAVINCI_VPIF_DISPLAY - tristate DM646x/DA850/OMAPL138 EVM Video Display - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + tristate TI DaVinci VPIF Video Display + depends on VIDEO_DEV ARCH_DAVINCI select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 if MEDIA_SUBDRV_AUTOSELECT select VIDEO_THS7303 if MEDIA_SUBDRV_AUTOSELECT help Enables Davinci VPIF module used for display devices. - This module is common for following DM6467/DA850/OMAPL138 - based display devices. + This module is used for display on TI
Re: No Signal with TerraTec Cinergy T PCIe dual
On Tue, Jan 8, 2013 at 10:46 PM, Antti Palosaari wrote: Try to downgrade Kernels until you find working one. Guess it is probably the only way. I will try. Seeing other message about a problem with the same card, made me think I forgot to post my conclusion. I downgraded to 3.6.5 which was a working one at the time I got the card and the problem is the same. The problem is thus elsewhere (maybe hardware related but it is difficult to me to test the card in another computer). -- Cédric Girard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH V4 10/12] [media] marvell-ccic: add soc_camera support for marvell-ccic driver
Hi, Guennadi -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Tuesday, 05 March, 2013 21:33 To: Albert Wang Cc: cor...@lwn.net; Linux Media Mailing List; Libin Yang Subject: Re: [REVIEW PATCH V4 10/12] [media] marvell-ccic: add soc_camera support for marvell-ccic driver Ok, can we test existing systems, have they been tested? It is hard to review this, as you might imagine. At least I don't think I can in any reasonably way verify by just looking at this whether it's breaking anything... I think, people, really using / developing this driver for other platforms would have to just extensively test this and verify the final result (I think I know one such person ;-)). A couple of minor comments below. In general - it does look quite good to me! So, provided relevant testing is done and, possibly, my comments addressed: Actually, we have tested it on all Marvell platforms which we have. But we have no OLPC board on hand. You are right and we still need test it on OLPC. Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi On Thu, 7 Feb 2013, Albert Wang wrote: This patch adds the soc_camera mode support in marvell-ccic driver. It also removes the old mode for maintaining single mode in the future. Signed-off-by: Libin Yang lby...@marvell.com Signed-off-by: Albert Wang twan...@marvell.com --- drivers/media/platform/Makefile |4 +- drivers/media/platform/marvell-ccic/Kconfig |6 +- drivers/media/platform/marvell-ccic/mcam-core.c | 1084 +++--- drivers/media/platform/marvell-ccic/mcam-core.h | 27 +- drivers/media/platform/marvell-ccic/mmp-driver.c | 73 +- include/media/mmp-camera.h |5 + 6 files changed, 402 insertions(+), 797 deletions(-) At least the stats look good ;-) diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 4817d28..1a345c8 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -11,8 +11,6 @@ obj-$(CONFIG_VIDEO_TIMBERDALE) += timblogiw.o obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o -obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/ -obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/ obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o obj-$(CONFIG_VIDEO_OMAP3) += omap3isp/ @@ -43,6 +41,8 @@ obj-$(CONFIG_ARCH_DAVINCI) += davinci/ obj-$(CONFIG_VIDEO_SH_VOU) += sh_vou.o obj-$(CONFIG_SOC_CAMERA)+= soc_camera/ +obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/ +obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/ obj-y += davinci/ diff --git a/drivers/media/platform/marvell-ccic/Kconfig b/drivers/media/platform/marvell-ccic/Kconfig index bf739e3..7fa3c62 100755 --- a/drivers/media/platform/marvell-ccic/Kconfig +++ b/drivers/media/platform/marvell-ccic/Kconfig @@ -10,14 +10,14 @@ config VIDEO_CAFE_CCIC generation OLPC systems. config VIDEO_MMP_CAMERA -tristate Marvell Armada 610 integrated camera controller support +tristate Marvell Armada integrated camera controller support depends on ARCH_MMP I2C VIDEO_V4L2 Perhaps, you want to add SOC_CAMERA above Yes, we missed it. Thanks! -select VIDEO_OV7670 select I2C_GPIO +select VIDEOBUF2_DMA_CONTIG select VIDEOBUF2_DMA_SG ---help--- This is a Video4Linux2 driver for the integrated camera - controller found on Marvell Armada 610 application + controller found on Marvell Armada application processors (and likely beyond). This is the controller found in OLPC XO 1.75 systems. [snip] diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c b/drivers/media/platform/marvell-ccic/mmp-driver.c index 732af16..3d5db24 100755 --- a/drivers/media/platform/marvell-ccic/mmp-driver.c +++ b/drivers/media/platform/marvell-ccic/mmp-driver.c @@ -28,6 +28,10 @@ #include linux/list.h #include linux/pm.h #include linux/clk.h +#include linux/regulator/consumer.h Looks like you don't need this header. Ok, will remove it. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Thanks Albert Wang 86-21-61092656 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH V4 09/12] [media] marvell-ccic: use unsigned int type replace int type
Hi, Guennadi
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Tuesday, 05 March, 2013 18:43
To: Albert Wang
Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [REVIEW PATCH V4 09/12] [media] marvell-ccic: use unsigned int
type
replace int type
I'm not against this patch, but I don't see a lot of meaning in it either,
apart from the .irq part - that makes the type match *request_*irq()
prototypes. Apart from that... Using int i for a simple iterator, that
doesn't go beyond INT_MAX is kinda traditional, I think. You change int
frame to unsigned, but if you look at mcam_buffer_done(), as it is called
from mcam_frame_tasklet(), the
int bufno = cam-next_buf;
variable is used for its second parameter (int frame). And -next_buf is
declared as (signed) int, and can indeed be negative in
mcam_reset_buffers():
cam-next_buf = -1;
So... You might need to be more careful with those changes, if you
_really_ need them. Otherwise, unless there are real reasons, like
matching an existing API, avoiding warnings, I'd really just drop all
this, perhaps, apart from -irq.
Actually, this patch is prepared for [PATCH 12/12] [media] marvell-ccic: add 3
frame buffers support in DMA_CONTIG mode
In that patch we need do that calculate with frame:
buf = cam-vb_bufs[(frame + (MAX_FRAME_BUFS - 1)) % MAX_FRAME_BUFS];
So we think frame should be unsigned from the original meaning.
But sometimes buffer number may be negative for some special design, I leave
them alone.
So how about we change to keep buffer number with original definition if you
think there is no meaning to change it and just change frame number and irq?
Thanks
Guennadi
On Thu, 7 Feb 2013, Albert Wang wrote:
This patch uses unsigned int type replace int type in marvell-ccic.
These variables: frame number, buf number, irq... should be unsigned.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
Acked-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/platform/marvell-ccic/mcam-core.c | 22
+++---
drivers/media/platform/marvell-ccic/mcam-core.h |2 +-
drivers/media/platform/marvell-ccic/mmp-driver.c |2 +-
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 939c430..b668f2b 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -233,7 +233,7 @@ static inline struct mcam_vb_buffer *vb_to_mvb(struct
vb2_buffer *vb)
/*
* Hand a completed buffer back to user space.
*/
-static void mcam_buffer_done(struct mcam_camera *cam, int frame,
+static void mcam_buffer_done(struct mcam_camera *cam, unsigned int frame,
struct vb2_buffer *vbuf)
{
vbuf-v4l2_buf.bytesused = cam-pix_format.sizeimage;
@@ -260,7 +260,7 @@ static void mcam_buffer_done(struct mcam_camera *cam, int
frame,
*/
static void mcam_reset_buffers(struct mcam_camera *cam)
{
-int i;
+unsigned int i;
cam-next_buf = -1;
for (i = 0; i cam-nbufs; i++) {
@@ -344,7 +344,7 @@ static int mcam_config_mipi(struct mcam_camera *mcam, int
enable)
*/
static int mcam_alloc_dma_bufs(struct mcam_camera *cam, int loadtime)
{
-int i;
+unsigned int i;
mcam_set_config_needed(cam, 1);
if (loadtime)
@@ -385,7 +385,7 @@ static int mcam_alloc_dma_bufs(struct mcam_camera *cam,
int loadtime)
static void mcam_free_dma_bufs(struct mcam_camera *cam)
{
-int i;
+unsigned int i;
for (i = 0; i cam-nbufs; i++) {
dma_free_coherent(cam-dev, cam-dma_buf_size,
@@ -424,7 +424,7 @@ static void mcam_ctlr_dma_vmalloc(struct mcam_camera
*cam)
static void mcam_frame_tasklet(unsigned long data)
{
struct mcam_camera *cam = (struct mcam_camera *) data;
-int i;
+unsigned int i;
unsigned long flags;
struct mcam_vb_buffer *buf;
@@ -472,7 +472,7 @@ static int mcam_check_dma_buffers(struct mcam_camera
*cam)
return 0;
}
-static void mcam_vmalloc_done(struct mcam_camera *cam, int frame)
+static void mcam_vmalloc_done(struct mcam_camera *cam, unsigned int frame)
{
tasklet_schedule(cam-s_tasklet);
}
@@ -521,7 +521,7 @@ static bool mcam_fmt_is_planar(__u32 pfmt)
* space. In this way, we always have a buffer to DMA to and don't
* have to try to play games stopping and restarting the controller.
*/
-static void mcam_set_contig_buffer(struct mcam_camera *cam, int frame)
+static void mcam_set_contig_buffer(struct mcam_camera *cam, unsigned int
frame)
{
struct mcam_vb_buffer *buf;
struct v4l2_pix_format *fmt = cam-pix_format;
@@ -567,7 +567,7 @@ static void mcam_ctlr_dma_contig(struct mcam_camera *cam)
/*
* Frame completion handling.
*/
-static void mcam_dma_contig_done(struct mcam_camera *cam,
RE: [REVIEW PATCH V4 12/12] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode
Hi, Guennadi
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Tuesday, 05 March, 2013 22:17
To: Albert Wang
Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [REVIEW PATCH V4 12/12] [media] marvell-ccic: add 3 frame buffers
support in DMA_CONTIG mode
On Thu, 7 Feb 2013, Albert Wang wrote:
This patch adds support of 3 frame buffers in DMA-contiguous mode.
In current DMA_CONTIG mode, only 2 frame buffers can be supported.
Actually, Marvell CCIC can support 2 or 3 frame buffers.
Currently 3 frame buffers mode will be used by default.
To use 2 frame buffers mode, can do:
#define MAX_FRAME_BUFS 2
in mcam-core.h.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
Acked-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/platform/marvell-ccic/mcam-core.c | 59
+--
drivers/media/platform/marvell-ccic/mcam-core.h | 13 +
2 files changed, 57 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index f206e3c..33fce6c 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -494,13 +494,32 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, unsigned int frame)
struct mcam_vb_buffer *buf;
struct v4l2_pix_format *fmt = cam-pix_format;
-/*
- * If there are no available buffers, go into single mode
- */
if (list_empty(cam-buffers)) {
-buf = cam-vb_bufs[frame ^ 0x1];
-set_bit(CF_SINGLE_BUFFER, cam-flags);
-cam-frame_state.singles++;
+/*
+ * If there are no available buffers
+ * go into single buffer mode
+ *
+ * If CCIC use Two Buffers mode
+ * will use another remaining frame buffer
+ * frame 0 - buf 1
+ * frame 1 - buf 0
+ *
+ * If CCIC use Three Buffers mode
+ * will use the 2rd remaining frame buffer
+ * frame 0 - buf 2
+ * frame 1 - buf 0
+ * frame 2 - buf 1
+ */
+buf = cam-vb_bufs[(frame + (MAX_FRAME_BUFS - 1))
+% MAX_FRAME_BUFS];
+if (cam-frame_state.usebufs == 0)
+cam-frame_state.usebufs++;
+else {
+set_bit(CF_SINGLE_BUFFER, cam-flags);
+cam-frame_state.singles++;
+if (cam-frame_state.usebufs 2)
+cam-frame_state.usebufs++;
What is this .usebufs actually supposed to do? AFAICS, it is only used to
decide, whether it should be changed, I don't see it having any effect on
anything else?
Actually, we use .usebufs to decide if will enter single buffer mode.
Only usebufs == 2 can enter single buffer mode.
But when init it:
If CCIC use Two Buffers mode, init usebufs == 1
If CCIC use Three Buffers mode, init usebufs == 0
That means when CCIC use Two Buffers mode, once buffer used out, CCIC will
enter single buffer mode soon
But when CCIC use Two Buffers mode, we can have 1 frame time to wait for new
buffer and needn't enter single buffer mode.
If we still can't get new buffer after 1 frame, then CCIC has to enter single
buffer mode.
But if we are lucky enough and get new buffer when next frame come, then we can
still run in normal mode.
+}
} else {
/*
* OK, we have a buffer we can use.
@@ -509,15 +528,15 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, unsigned int frame)
queue);
list_del_init(buf-queue);
clear_bit(CF_SINGLE_BUFFER, cam-flags);
+if (cam-frame_state.usebufs != (3 - MAX_FRAME_BUFS))
+cam-frame_state.usebufs--;
}
cam-vb_bufs[frame] = buf;
-mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR, buf-yuv_p.y);
+mcam_reg_write(cam, REG_Y0BAR + (frame 2), buf-yuv_p.y);
if (mcam_fmt_is_planar(fmt-pixelformat)) {
-mcam_reg_write(cam, frame == 0 ?
-REG_U0BAR : REG_U1BAR, buf-yuv_p.u);
-mcam_reg_write(cam, frame == 0 ?
-REG_V0BAR : REG_V1BAR, buf-yuv_p.v);
+mcam_reg_write(cam, REG_U0BAR + (frame 2), buf-yuv_p.u);
+mcam_reg_write(cam, REG_V0BAR + (frame 2), buf-yuv_p.v);
}
}
@@ -526,10 +545,14 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, unsigned int frame)
*/
static void mcam_ctlr_dma_contig(struct mcam_camera *cam)
{
-mcam_reg_set_bit(cam, REG_CTRL1, C1_TWOBUFS);
-cam-nbufs = 2;
-mcam_set_contig_buffer(cam, 0);
-mcam_set_contig_buffer(cam, 1);
RE: [REVIEW PATCH V4 02/12] [media] marvell-ccic: add clock tree support for marvell-ccic driver
Hi Albert On Wed, 6 Mar 2013, Albert Wang wrote: Hi, Guennadi -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Tuesday, 05 March, 2013 17:51 To: Albert Wang Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang Subject: Re: [REVIEW PATCH V4 02/12] [media] marvell-ccic: add clock tree support for marvell-ccic driver [snip] @@ -331,6 +374,10 @@ static int mmpcam_probe(struct platform_device *pdev) ret = -ENODEV; goto out_unmap1; } + + ret = mcam_init_clk(mcam, pdata); + if (ret) + goto out_unmap2; Now, I'm confused again: doesn't this mean, that all existing users of this driver will fail? Sorry, I don't understand what's your concern? I mean - wouldn't the above function fail for all existing users, because they don't provide the clocks, that you're requesting here? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH V4 12/12] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode
On Wed, 6 Mar 2013, Albert Wang wrote:
[snip]
+ if (cam-frame_state.usebufs == 0)
+ cam-frame_state.usebufs++;
+ else {
+ set_bit(CF_SINGLE_BUFFER, cam-flags);
+ cam-frame_state.singles++;
+ if (cam-frame_state.usebufs 2)
+ cam-frame_state.usebufs++;
What is this .usebufs actually supposed to do? AFAICS, it is only used to
decide, whether it should be changed, I don't see it having any effect on
anything else?
Actually, we use .usebufs to decide if will enter single buffer mode.
Only usebufs == 2 can enter single buffer mode.
But when init it:
If CCIC use Two Buffers mode, init usebufs == 1
If CCIC use Three Buffers mode, init usebufs == 0
That means when CCIC use Two Buffers mode, once buffer used out, CCIC will
enter single buffer mode soon
But when CCIC use Two Buffers mode, we can have 1 frame time to wait for
new buffer and needn't enter single buffer mode.
If we still can't get new buffer after 1 frame, then CCIC has to enter single
buffer mode.
But if we are lucky enough and get new buffer when next frame come, then
we can still run in normal mode.
Thanks for the explanation. Could you please tell me where in the code
this .usebufs field is used as you describe?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TerraTec Cinergy T PCIe Dual not working
Hi Oliver, Thanks for your fast reply. On Wed, 06 Mar 2013 14:58:05 +0100, Oliver Schinagl wrote: I have the same card, and have not much problems. I have some reception issues, but I don't think it's to blame on the card (yet). I do use tvheadend however. In anycase, can you use w_scan or dvb-scan? I have neither but I have scan from package dvb which does work. This gave me the idea to re-run scan with different frequency files and different antennas. It turns out that my problem is the antenna. I was using the antenna I have been using with my previous card, which is an internal DVB-T antenna with amplification (external power supply.) I get zero signal with that. But using the Terratec-provided cheap stick antenna, I get signal again, with reasonable quality (although not as stable as with the old card and the powered antenna.) I also get signal (but not all channels) with my original antenna _unpowered_ (thus signal not amplified.) I admit I don't quite understand. I would understand that a bad, unpowered antenna causes no signal to be sensed. But how is it possible that a supposedly better, powered antenna causes that kind of issue? Oliver, out of curiosity, what antenna are you using? The Terratec-provided one, or another one? -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH V4 02/12] [media] marvell-ccic: add clock tree support for marvell-ccic driver
Hi, Guennadi -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Wednesday, 06 March, 2013 23:00 To: Albert Wang Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang Subject: RE: [REVIEW PATCH V4 02/12] [media] marvell-ccic: add clock tree support for marvell-ccic driver Hi Albert On Wed, 6 Mar 2013, Albert Wang wrote: Hi, Guennadi -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Tuesday, 05 March, 2013 17:51 To: Albert Wang Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang Subject: Re: [REVIEW PATCH V4 02/12] [media] marvell-ccic: add clock tree support for marvell-ccic driver [snip] @@ -331,6 +374,10 @@ static int mmpcam_probe(struct platform_device *pdev) ret = -ENODEV; goto out_unmap1; } + + ret = mcam_init_clk(mcam, pdata); + if (ret) + goto out_unmap2; Now, I'm confused again: doesn't this mean, that all existing users of this driver will fail? Sorry, I don't understand what's your concern? I mean - wouldn't the above function fail for all existing users, because they don't provide the clocks, that you're requesting here? OK, I see. We will update it. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Thanks Albert Wang 86-21-61092656 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH V4 09/12] [media] marvell-ccic: use unsigned int type replace int type
On Wed, 6 Mar 2013, Albert Wang wrote: Hi, Guennadi -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Tuesday, 05 March, 2013 18:43 To: Albert Wang Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang Subject: Re: [REVIEW PATCH V4 09/12] [media] marvell-ccic: use unsigned int type replace int type I'm not against this patch, but I don't see a lot of meaning in it either, apart from the .irq part - that makes the type match *request_*irq() prototypes. Apart from that... Using int i for a simple iterator, that doesn't go beyond INT_MAX is kinda traditional, I think. You change int frame to unsigned, but if you look at mcam_buffer_done(), as it is called from mcam_frame_tasklet(), the int bufno = cam-next_buf; variable is used for its second parameter (int frame). And -next_buf is declared as (signed) int, and can indeed be negative in mcam_reset_buffers(): cam-next_buf = -1; So... You might need to be more careful with those changes, if you _really_ need them. Otherwise, unless there are real reasons, like matching an existing API, avoiding warnings, I'd really just drop all this, perhaps, apart from -irq. Actually, this patch is prepared for [PATCH 12/12] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode In that patch we need do that calculate with frame: buf = cam-vb_bufs[(frame + (MAX_FRAME_BUFS - 1)) % MAX_FRAME_BUFS]; So we think frame should be unsigned from the original meaning. But sometimes buffer number may be negative for some special design, I leave them alone. So how about we change to keep buffer number with original definition if you think there is no meaning to change it and just change frame number and irq? Sounds good to me! Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH V4 12/12] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode
Hi, Guennadi
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Wednesday, 06 March, 2013 23:02
To: Albert Wang
Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang
Subject: RE: [REVIEW PATCH V4 12/12] [media] marvell-ccic: add 3 frame buffers
support in DMA_CONTIG mode
On Wed, 6 Mar 2013, Albert Wang wrote:
[snip]
+ if (cam-frame_state.usebufs == 0)
+ cam-frame_state.usebufs++;
+ else {
+ set_bit(CF_SINGLE_BUFFER, cam-flags);
+ cam-frame_state.singles++;
+ if (cam-frame_state.usebufs 2)
+ cam-frame_state.usebufs++;
What is this .usebufs actually supposed to do? AFAICS, it is only used to
decide, whether it should be changed, I don't see it having any effect on
anything else?
Actually, we use .usebufs to decide if will enter single buffer mode.
Only usebufs == 2 can enter single buffer mode.
But when init it:
If CCIC use Two Buffers mode, init usebufs == 1
If CCIC use Three Buffers mode, init usebufs == 0
That means when CCIC use Two Buffers mode, once buffer used out, CCIC will
enter
single buffer mode soon
But when CCIC use Three Buffers mode, we can have 1 frame time to wait for
new buffer and needn't enter single buffer mode.
If we still can't get new buffer after 1 frame, then CCIC has to enter
single buffer mode.
But if we are lucky enough and get new buffer when next frame come, then
we can still run in normal mode.
Thanks for the explanation. Could you please tell me where in the code
this .usebufs field is used as you describe?
Firstly, we will init this field, the initial value depends on selected CCIC
buffer mode:
+ /*
+* If CCIC use Two Buffers mode, init usebufs == 1
+* If CCIC use Three Buffers mode, init usebufs == 0
+*/
+ cam-frame_state.usebufs = 3 - MAX_FRAME_BUFS;
Then:
/*
+* If there are no available buffers
+* go into single buffer mode
+*
But it depends on usebufs state:
+ if (cam-frame_state.usebufs == 0)
+ cam-frame_state.usebufs++;
+ else {
+ set_bit(CF_SINGLE_BUFFER, cam-flags);
+ cam-frame_state.singles++;
+ if (cam-frame_state.usebufs 2)
+ cam-frame_state.usebufs++;
+ }
usebufs range is 0, 1, 2:
0 - Use Three buffer mode, and CCIC needn't enter single buffer mode when
buffer used out in the first time
1 - Use Two buffer mode and CCIC need enter single buffer mode
Or Use Three buffer mode and CCIC also need enter single buffer mode when we
still can't get new buffer after continuous 2 frames
2 - CCIC had enterer single buffer mode whatever use Two buffer or Three buffer
mode
And if:
/*
* OK, we have a buffer we can use.
We will exit the single buffer mode:
clear_bit(CF_SINGLE_BUFFER, cam-flags);
+ if (cam-frame_state.usebufs != (3 - MAX_FRAME_BUFS))
+ cam-frame_state.usebufs--;
}
And we will try to let usebufs back to initial value.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Thanks
Albert Wang
86-21-61092656
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] em28xx: Add a separate config dir for secondary bus
Am 05.03.2013 11:55, schrieb Mauro Carvalho Chehab:
Prepare to register a separate bus for the second bus.
For now, just add a new field. A latter patch will add the
bits to make it work.
This patch was generated by this script:
perl -e 'while () { if (s/EM2874_I2C_SECONDARY_BUS_SELECT.*\n//) {
printf \t\t.def_i2c_bus = 1,\n; $found = 1; print $_ } else { if
($found) { s/^\s+// }; $found = 0; print $_; } }' \
drivers/media/usb/em28xx/em28xx-cards.c a mv a
drivers/media/usb/em28xx/em28xx-cards.c
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 43
++---
drivers/media/usb/em28xx/em28xx.h | 1 +
2 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index d81f7ee..16ab4d7 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -958,8 +958,8 @@ struct em28xx_board em28xx_boards[] = {
#else
.tuner_type = TUNER_ABSENT,
#endif
- .i2c_speed= EM2874_I2C_SECONDARY_BUS_SELECT |
- EM28XX_I2C_CLK_WAIT_ENABLE |
+ .def_i2c_bus = 1,
+ .i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
...
Looks good, we need a separate field like this for em2765 and Co., too
(which don't use reg 0x06 for bus switching).
Regards,
Frank
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] em28xx: add support for registering multiple i2c buses
Hi Mauro,
I'm basically fine this patch, just a few comments/thoughts:
Am 05.03.2013 11:55, schrieb Mauro Carvalho Chehab:
Register both buses 0 and 1 via I2C API. For now, bus 0 is used
only by eeprom on all known devices. Later patches will be needed
if this changes in the future.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 29 +++---
drivers/media/usb/em28xx/em28xx-i2c.c | 93
++---
drivers/media/usb/em28xx/em28xx.h | 19 +--
3 files changed, 97 insertions(+), 44 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 16ab4d7..496b938 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2235,8 +2235,8 @@ static inline void em28xx_set_model(struct em28xx *dev)
dev-board.i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_100_KHZ;
- if (dev-board.def_i2c_bus == 1)
- dev-board.i2c_speed |= EM2874_I2C_SECONDARY_BUS_SELECT;
+ /* Should be initialized early, for I2C to work */
+ dev-def_i2c_bus = dev-board.def_i2c_bus;
}
@@ -2642,7 +2642,7 @@ static int em28xx_hint_board(struct em28xx *dev)
/* user did not request i2c scanning = do it now */
if (!dev-i2c_hash)
- em28xx_do_i2c_scan(dev);
+ em28xx_do_i2c_scan(dev, dev-def_i2c_bus);
for (i = 0; i ARRAY_SIZE(em28xx_i2c_hash); i++) {
if (dev-i2c_hash == em28xx_i2c_hash[i].hash) {
@@ -2953,7 +2953,9 @@ void em28xx_release_resources(struct em28xx *dev)
em28xx_release_analog_resources(dev);
- em28xx_i2c_unregister(dev);
+ if (dev-def_i2c_bus)
+ em28xx_i2c_unregister(dev, 1);
+ em28xx_i2c_unregister(dev, 0);
v4l2_ctrl_handler_free(dev-ctrl_handler);
@@ -3109,14 +3111,23 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
v4l2_ctrl_handler_init(hdl, 8);
dev-v4l2_dev.ctrl_handler = hdl;
- /* register i2c bus */
- retval = em28xx_i2c_register(dev);
+ /* register i2c bus 0 */
+ retval = em28xx_i2c_register(dev, 0);
if (retval 0) {
- em28xx_errdev(%s: em28xx_i2c_register - error [%d]!\n,
+ em28xx_errdev(%s: em28xx_i2c_register bus 0 - error [%d]!\n,
__func__, retval);
goto unregister_dev;
}
+ if (dev-def_i2c_bus) {
+ retval = em28xx_i2c_register(dev, 1);
Hmm, ok, so you don't want to register unused busses ?
What about bus A when all subdevices are on bus B ?
You don't have to register the adapter for eeprom reading, the i2c
transfer functions work with unregistered i2c_adapters, too.
+ if (retval 0) {
+ em28xx_errdev(%s: em28xx_i2c_register bus 1 - error
[%d]!\n,
+ __func__, retval);
+ goto unregister_dev;
+ }
+ }
+
/*
* Default format, used for tvp5150 or saa711x output formats
*/
@@ -3186,7 +3197,9 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
return 0;
fail:
- em28xx_i2c_unregister(dev);
+ if (dev-def_i2c_bus)
+ em28xx_i2c_unregister(dev, 1);
+ em28xx_i2c_unregister(dev, 0);
v4l2_ctrl_handler_free(dev-ctrl_handler);
unregister_dev:
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 9086e57..ea63ac4 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -280,9 +280,22 @@ static int em28xx_i2c_check_for_device(struct em28xx
*dev, u16 addr)
static int em28xx_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg msgs[], int num)
{
- struct em28xx *dev = i2c_adap-algo_data;
+ struct em28xx_i2c_bus *i2c_bus = i2c_adap-algo_data;
+ struct em28xx *dev = i2c_bus-dev;
+ unsigned bus = i2c_bus-bus, last_bus;
int addr, rc, i, byte;
+ /* Switch I2C bus if needed */
+ last_bus = (dev-board.i2c_speed EM2874_I2C_SECONDARY_BUS_SELECT) ?
+1 : 0;
+ if (bus != last_bus) {
+ if (bus == 1)
+ dev-board.i2c_speed |= EM2874_I2C_SECONDARY_BUS_SELECT;
+ else
+ dev-board.i2c_speed =
~EM2874_I2C_SECONDARY_BUS_SELECT;
+ em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, dev-board.i2c_speed);
+ }
+
FYI: although it seems to be not necessary for the devices we've seen so
far, the Windows driver clear/sets bit EM2874_I2C_SECONDARY_BUS_SELECT
at the beginning of each i2c operation.
Anyway, we shouldn't abuse the board data struct for saving the
currently selected bus.
This will also not work for briges which switch
drxk driver statistics
Hi all, I have a TerraTec Cinergy T PCIe Dual card, with DRX-3916K and DRX-3913K frontends. I am thus using the drxk dvb-frontend driver. While trying to find the best antenna, position and amplification, I found that the statistics returned by the drxk driver look quite bad: $ femon -H 3 FE: DRXK DVB-T (DVBT) status SCVYL | signal 0% | snr 0% | ber 0 | unc 38822 | FE_HAS_LOCK status SCVYL | signal 0% | snr 0% | ber 0 | unc 38822 | FE_HAS_LOCK status SCVYL | signal 0% | snr 0% | ber 0 | unc 38822 | FE_HAS_LOCK This is with TV looking reasonably good, so these figures are not plausible. $ femon 10 FE: DRXK DVB-T (DVBT) status SCVYL | signal 00de | snr 00f5 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00f0 | snr 00f5 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 0117 | snr 00f6 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00b6 | snr 00eb | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00d1 | snr 00e7 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 0073 | snr 00ea | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00a3 | snr 00ee | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00b5 | snr 00f4 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00ba | snr 00f3 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00be | snr 00f0 | ber | unc 97a6 | FE_HAS_LOCK Signal values are changing too much, snr is stable enough but way too low, ber is apparently unimplemented, and unc is never reset AFAICS (it started at 1 when the system started and has been only increasing since then.) On my previous card, unc was an instant measurement, not a cumulative value, not sure which is correct. I would like to see these statistics improved. I am willing to help, however the drxk driver is rather complex (at least to my eyes) and I do not have a datasheet so I wouldn't know where to start. Is there anyone who can work on this and/or provide some guidance? Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] [media] ir-rx51: fix clock API related build issues
* Timo Kokkonen timo.t.kokko...@iki.fi [130305 22:26]: On 03.05 2013 17:09:53, Tony Lindgren wrote: * Mauro Carvalho Chehab mche...@redhat.com [130305 16:28]: Em Tue, 5 Mar 2013 23:16:46 +0100 Arnd Bergmann a...@arndb.de escreveu: OMAP1 no longer provides its own clock interfaces since patch a135eaae52 ARM: OMAP: remove plat/clock.h. This is great, but we now have to convert the ir-rx51 driver to use the generic interface from linux/clk.h. The driver also uses the omap_dm_timer_get_fclk() function, which is not exported for OMAP1, so we have to move the definition out of the OMAP2 specific section. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Mauro Carvalho Chehab mche...@redhat.com From my side: Acked-by: Mauro Carvalho Chehab mche...@redhat.com There's just one issue, this driver most likely only needed on rx51 board.. So I suggest we just mark the driver depends on ARCH_OMAP2PLUS and let's drop this patch. This driver is already disabled for ARCH_MULTIPLATFORM as we need to move dmtimer.c to drivers and have some minimal include/linux/timer-omap.h for it. I've also had this cunning plan that if or when the PWM subsystem starts supporting the PWM output in OMAP3, I could convert this driver to generate the IR carrier wave through the PWM subsystem and then use HR timers to generate the pulses. I think that's much better approach than trying to depend on interfaces that are not easily available. Should be possible, but I haven't proven yet that it will work :) Sounds good to me. Unfortunately I haven't got into executing on that plan yet. In addition to the challenge of scheduling some of my free time for doing this, my RX51 device is not enumerating the USB with the latest kernel and I haven't figured out that yet. And because of that, I haven't been able to get my user space running over nfsroot setup I've been using.. Git bisect might help there. Maybe post the output and cc the usb people? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-media 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] em28xx: add support for two buses on em2874 and upper
Am 05.03.2013 16:43, schrieb Devin Heitmueller: 2013/3/5 Mauro Carvalho Chehab mche...@redhat.com: The em2874 chips and upper have 2 buses. On all known devices, bus 0 is currently used only by eeprom, and bus 1 for the rest. Add support to register both buses. Did you add a mutex to ensure that both buses cannot be used at the same time? Because using the bus requires you to toggle a register (thus you cannot be using both busses at the same time), you cannot rely on the existing i2c adapter lock anymore. You don't want a situation where something is actively talking on bus 0, and then something else tries to talk on bus 1, flips the register bit and then the thread talking on bus 0 starts failing. Devin Hmm... there are several writes to EM28XX_R06_I2C_CLK in em28xx-dvb... See hauppauge_hvr930c_init(), terratec_h5_init() and terratec_htc_stick_init(). These functions are called from em28xx_dvb_init() at module init. Module init is async, so yes, this is (or could at least become) a problem... I wonder if we can't simply remove all those writes to EM28XX_R06_I2C_CLK from em28xx-dvb. This is what the functions are doing: hauppauge_hvr930c_init() ... em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40); msleep(10); em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x44); msleep(10); ... [init sequence for slave at address 0x82] em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x44); msleep(30); em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x45); msleep(10); terratec_h5_init(): ... em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40); msleep(10); em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x45); msleep(10); ... terratec_htc_stick_init() ... em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40); msleep(10); em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x44); msleep(10); ... All three boards are using the following settings: .i2c_speed= EM2874_I2C_SECONDARY_BUS_SELECT | EM28XX_I2C_CLK_WAIT_ENABLE | EM28XX_I2C_FREQ_400_KHZ = 0x45 So what these functions are doing is - switch to bus A and do nothing fo 10ms - overwrite board settings for reg 0x06 with a local value (clears EM28XX_I2C_FREQ_400_KHZ permanently for the HTC-Stick !). I can test the HVR-930C next week. Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TerraTec Cinergy T PCIe Dual not working
On 03/06/13 16:03, Jean Delvare wrote: Hi Oliver, Thanks for your fast reply. On Wed, 06 Mar 2013 14:58:05 +0100, Oliver Schinagl wrote: I have the same card, and have not much problems. I have some reception issues, but I don't think it's to blame on the card (yet). I do use tvheadend however. In anycase, can you use w_scan or dvb-scan? I have neither but I have scan from package dvb which does work. This gave me the idea to re-run scan with different frequency files and different antennas. It turns out that my problem is the antenna. I was using the antenna I have been using with my previous card, which is an internal DVB-T antenna with amplification (external power supply.) I get zero signal with that. But using the Terratec-provided cheap stick antenna, I get signal again, with reasonable quality (although not as stable as with the old card and the powered antenna.) I also get signal (but not all channels) with my original antenna _unpowered_ (thus signal not amplified.) I admit I don't quite understand. I would understand that a bad, unpowered antenna causes no signal to be sensed. But how is it possible that a supposedly better, powered antenna causes that kind of issue? Oliver, out of curiosity, what antenna are you using? The Terratec-provided one, or another one? Right now, I use 11cm stripped coax :) But that's because I live 600 meters from the broadcasting tower. This actually gives me the best reception. The mini antenna that came with the thing worked quite well, but the wire was a bit short. Besides that I did use a powered antenna for a while, without the power connected, because it actually dampens the signal. That worked quite well for a while. Using it powered, with an external power source, actually made it much worse. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [REVIEW PATCH V4 12/12] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode
On Wed, 6 Mar 2013, Albert Wang wrote:
Hi, Guennadi
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Wednesday, 06 March, 2013 23:02
To: Albert Wang
Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang
Subject: RE: [REVIEW PATCH V4 12/12] [media] marvell-ccic: add 3 frame
buffers
support in DMA_CONTIG mode
On Wed, 6 Mar 2013, Albert Wang wrote:
[snip]
+ if (cam-frame_state.usebufs == 0)
+ cam-frame_state.usebufs++;
+ else {
+ set_bit(CF_SINGLE_BUFFER, cam-flags);
+ cam-frame_state.singles++;
+ if (cam-frame_state.usebufs 2)
+ cam-frame_state.usebufs++;
What is this .usebufs actually supposed to do? AFAICS, it is only used to
decide, whether it should be changed, I don't see it having any effect on
anything else?
Actually, we use .usebufs to decide if will enter single buffer mode.
Only usebufs == 2 can enter single buffer mode.
But when init it:
If CCIC use Two Buffers mode, init usebufs == 1
If CCIC use Three Buffers mode, init usebufs == 0
That means when CCIC use Two Buffers mode, once buffer used out, CCIC will
enter
single buffer mode soon
But when CCIC use Three Buffers mode, we can have 1 frame time to wait for
new buffer and needn't enter single buffer mode.
If we still can't get new buffer after 1 frame, then CCIC has to enter
single buffer mode.
But if we are lucky enough and get new buffer when next frame come, then
we can still run in normal mode.
Thanks for the explanation. Could you please tell me where in the code
this .usebufs field is used as you describe?
Firstly, we will init this field, the initial value depends on selected CCIC
buffer mode:
+ /*
+ * If CCIC use Two Buffers mode, init usebufs == 1
+ * If CCIC use Three Buffers mode, init usebufs == 0
+ */
+ cam-frame_state.usebufs = 3 - MAX_FRAME_BUFS;
Then:
/*
+ * If there are no available buffers
+ * go into single buffer mode
+ *
But it depends on usebufs state:
+ if (cam-frame_state.usebufs == 0)
+ cam-frame_state.usebufs++;
+ else {
+ set_bit(CF_SINGLE_BUFFER, cam-flags);
+ cam-frame_state.singles++;
+ if (cam-frame_state.usebufs 2)
+ cam-frame_state.usebufs++;
Aaargh, I must've been blind, sorry :(
+ }
usebufs range is 0, 1, 2:
0 - Use Three buffer mode, and CCIC needn't enter single buffer mode when
buffer used out in the first time
1 - Use Two buffer mode and CCIC need enter single buffer mode
Or Use Three buffer mode and CCIC also need enter single buffer mode when
we still can't get new buffer after continuous 2 frames
2 - CCIC had enterer single buffer mode whatever use Two buffer or Three
buffer mode
And if:
/*
* OK, we have a buffer we can use.
We will exit the single buffer mode:
clear_bit(CF_SINGLE_BUFFER, cam-flags);
+ if (cam-frame_state.usebufs != (3 - MAX_FRAME_BUFS))
+ cam-frame_state.usebufs--;
}
And we will try to let usebufs back to initial value.
Ok, it's clearer now. So, in fact, it is a kind of a remaining available
buffer count, right? You could probably also do it the natural way -
initialise this field not to 3 - MAX_FRAME_BUFS, but to cam-nbufs (or
cam-nbufs - 1 if you prefer) directly and then count it down?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TerraTec Cinergy T PCIe Dual not working
Hi Oliver, On Wed, 06 Mar 2013 19:07:01 +0100, Oliver Schinagl wrote: On 03/06/13 16:03, Jean Delvare wrote: It turns out that my problem is the antenna. I was using the antenna I have been using with my previous card, which is an internal DVB-T antenna with amplification (external power supply.) I get zero signal with that. But using the Terratec-provided cheap stick antenna, I get signal again, with reasonable quality (although not as stable as with the old card and the powered antenna.) I also get signal (but not all channels) with my original antenna _unpowered_ (thus signal not amplified.) I admit I don't quite understand. I would understand that a bad, unpowered antenna causes no signal to be sensed. But how is it possible that a supposedly better, powered antenna causes that kind of issue? Oliver, out of curiosity, what antenna are you using? The Terratec-provided one, or another one? Right now, I use 11cm stripped coax :) But that's because I live 600 meters from the broadcasting tower. This actually gives me the best reception. The mini antenna that came with the thing worked quite well, but the wire was a bit short. Besides that I did use a powered antenna for a while, without the power connected, because it actually dampens the signal. That worked quite well for a while. Using it powered, with an external power source, actually made it much worse. My experience matches yours exactly. Thanks for confirming. I wonder if this is a limitation of the Linux drivers (not adjusting the tuner sensibility to the signal strength) or a hardware characteristic. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Mar 6 19:00:28 CET 2013 git branch: test git hash: 4ca286610f664acf3153634f3930acd2de993a9f gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8.03-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-Module.symvers: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9-rc1-i686: OK linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drxk driver statistics
On 03/06/13 18:36, Jean Delvare wrote: Hi all, I have a TerraTec Cinergy T PCIe Dual card, with DRX-3916K and DRX-3913K frontends. I am thus using the drxk dvb-frontend driver. While trying to find the best antenna, position and amplification, I found that the statistics returned by the drxk driver look quite bad: $ femon -H 3 FE: DRXK DVB-T (DVBT) status SCVYL | signal 0% | snr 0% | ber 0 | unc 38822 | FE_HAS_LOCK status SCVYL | signal 0% | snr 0% | ber 0 | unc 38822 | FE_HAS_LOCK status SCVYL | signal 0% | snr 0% | ber 0 | unc 38822 | FE_HAS_LOCK This is with TV looking reasonably good, so these figures are not plausible. $ femon 10 FE: DRXK DVB-T (DVBT) status SCVYL | signal 00de | snr 00f5 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00f0 | snr 00f5 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 0117 | snr 00f6 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00b6 | snr 00eb | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00d1 | snr 00e7 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 0073 | snr 00ea | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00a3 | snr 00ee | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00b5 | snr 00f4 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00ba | snr 00f3 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00be | snr 00f0 | ber | unc 97a6 | FE_HAS_LOCK Signal values are changing too much, snr is stable enough but way too low, ber is apparently unimplemented, and unc is never reset AFAICS (it started at 1 when the system started and has been only increasing since then.) On my previous card, unc was an instant measurement, not a cumulative value, not sure which is correct. Yes I found that out aswell, but since image quality has always been very fine, I haven't looked what this all should be. I would like to see these statistics improved. I am willing to help, however the drxk driver is rather complex (at least to my eyes) and I do not have a datasheet so I wouldn't know where to start. Is there anyone who can work on this and/or provide some guidance? Thanks, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx231xx : Add support for OTG102 aka EZGrabber2
Hi Matt,
While I added this patch to my cx231xx patch series, Mauro didn't pick it
up for some reason. So for when he gets around to looking at your patch, I want
to
add my:
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
On Sat March 2 2013 00:53:30 Matt Gomboc wrote:
Thanks for the response, I have done as you suggested.
Below is an updated patch for the OTG102 device against
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cx231xx,
kernel version 3.8.
With further testing it appears the extra clauses in cx231xx-cards.c were not
necessary (in static in cx231xx_init_dev and static int cx231xx_usb_probe),
so those have been also been removed.
Signed-off-by: Matt Gomboc gomb...@gmail.com
--
drivers/media/usb/cx231xx/cx231xx-avcore.c | 2 ++
drivers/media/usb/cx231xx/cx231xx-cards.c | 35
++
drivers/media/usb/cx231xx/cx231xx.h| 1 +
3 files changed, 38 insertions(+)
diff --git a/drivers/media/usb/cx231xx/cx231xx-avcore.c
b/drivers/media/usb/cx231xx/cx231xx-avcore.c
index 2e51fb9..235ba65 100644
--- a/drivers/media/usb/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/usb/cx231xx/cx231xx-avcore.c
@@ -357,6 +357,7 @@ int cx231xx_afe_update_power_control(struct cx231xx *dev,
case CX231XX_BOARD_PV_PLAYTV_USB_HYBRID:
case CX231XX_BOARD_HAUPPAUGE_USB2_FM_PAL:
case CX231XX_BOARD_HAUPPAUGE_USB2_FM_NTSC:
+ case CX231XX_BOARD_OTG102:
if (avmode == POLARIS_AVMODE_ANALOGT_TV) {
while (afe_power_status != (FLD_PWRDN_TUNING_BIAS |
FLD_PWRDN_ENABLE_PLL)) {
@@ -1720,6 +1721,7 @@ int cx231xx_dif_set_standard(struct cx231xx *dev, u32
standard)
case CX231XX_BOARD_CNXT_RDU_250:
case CX231XX_BOARD_CNXT_VIDEO_GRABBER:
case CX231XX_BOARD_HAUPPAUGE_EXETER:
+ case CX231XX_BOARD_OTG102:
func_mode = 0x03;
break;
case CX231XX_BOARD_CNXT_RDE_253S:
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index b7b1acd..13249e5 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -634,6 +634,39 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+ [CX231XX_BOARD_OTG102] = {
+ .name = Geniatech OTG102,
+ .tuner_type = TUNER_ABSENT,
+ .decoder = CX231XX_AVDECODER,
+ .output_mode = OUT_MODE_VIP11,
+ .ctl_pin_status_mask = 0xFFC4,
+ .agc_analog_digital_select_gpio = 0x0c,
+ /* According with PV CxPlrCAP.inf file */
+ .gpio_pin_status_mask = 0x4001000,
+ .norm = V4L2_STD_NTSC,
+ .no_alt_vanc = 1,
+ .external_av = 1,
+ .dont_use_port_3 = 1,
+ /*.has_417 = 1, */
+ /* This board is believed to have a hardware encoding chip
+ * supporting mpeg1/2/4, but as the 417 is apparently not
+ * working for the reference board it is not here either. */
+
+ .input = {{
+ .type = CX231XX_VMUX_COMPOSITE1,
+ .vmux = CX231XX_VIN_2_1,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ }, {
+ .type = CX231XX_VMUX_SVIDEO,
+ .vmux = CX231XX_VIN_1_1 |
+ (CX231XX_VIN_1_2 8) |
+ CX25840_SVIDEO_ON,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ }
+ },
+ },
};
const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
@@ -675,6 +708,8 @@ struct usb_device_id cx231xx_id_table[] = {
.driver_info = CX231XX_BOARD_ICONBIT_U100},
{USB_DEVICE(0x0fd9, 0x0037),
.driver_info = CX231XX_BOARD_ELGATO_VIDEO_CAPTURE_V2},
+ {USB_DEVICE(0x1f4d, 0x0102),
+ .driver_info = CX231XX_BOARD_OTG102},
{},
};
diff --git a/drivers/media/usb/cx231xx/cx231xx.h
b/drivers/media/usb/cx231xx/cx231xx.h
index a8e50d2..dff3f1d 100644
--- a/drivers/media/usb/cx231xx/cx231xx.h
+++ b/drivers/media/usb/cx231xx/cx231xx.h
@@ -71,6 +71,7 @@
#define CX231XX_BOARD_HAUPPAUGE_USB2_FM_PAL 14
#define CX231XX_BOARD_HAUPPAUGE_USB2_FM_NTSC 15
#define CX231XX_BOARD_ELGATO_VIDEO_CAPTURE_V2 16
+#define CX231XX_BOARD_OTG102 17
/* Limits minimum and default number of buffers */
#define CX231XX_MIN_BUF 4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH v1] lmedm04: Remove redundant NULL check before kfree
From: Syam Sidhardhan s.s...@samsung.com
kfree on NULL pointer is a no-op.
Signed-off-by: Syam Sidhardhan s.s...@samsung.com
---
v1 - Corrected the from address
drivers/media/usb/dvb-usb-v2/lmedm04.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index 96804be..b3fd0ff 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -1302,8 +1302,7 @@ static void lme2510_exit(struct dvb_usb_device *d)
if (d != NULL) {
usb_buffer = lme2510_exit_int(d);
- if (usb_buffer != NULL)
- kfree(usb_buffer);
+ kfree(usb_buffer);
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] rc-core fixes
Three minor patches for rc-core...(against the for_v3.9 branch) --- David Härdeman (3): rc-core: don't treat dev-rc_map.rc_type as a bitmap rc-core: rename ir_input_class to rc_class rc-core: initialize rc-core earlier if built-in drivers/media/i2c/ir-kbd-i2c.c|1 + drivers/media/rc/ir-jvc-decoder.c |2 + drivers/media/rc/ir-lirc-codec.c |2 + drivers/media/rc/ir-mce_kbd-decoder.c |2 + drivers/media/rc/ir-nec-decoder.c |2 + drivers/media/rc/ir-raw.c |2 + drivers/media/rc/ir-rc5-decoder.c |6 ++-- drivers/media/rc/ir-rc5-sz-decoder.c |2 + drivers/media/rc/ir-rc6-decoder.c |2 + drivers/media/rc/ir-sanyo-decoder.c |2 + drivers/media/rc/ir-sony-decoder.c|8 +++--- drivers/media/rc/rc-core-priv.h |1 - drivers/media/rc/rc-main.c| 46 - include/media/rc-core.h |2 + 14 files changed, 35 insertions(+), 45 deletions(-) -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] rc-core: don't treat dev-rc_map.rc_type as a bitmap
store_protocols() treats dev-rc_map.rc_type as a bitmap which is wrong for
two reasons. First of all, it is pretty bogus to change the protocol type of
the keymap just because the hardware has been asked to decode a different
protocol.
Second, dev-rc_map.rc_type is an enum (i.e. a single protocol) as pointed
out by James Hogan james.ho...@imgtec.com.
Fix both issues by introducing a separate enabled_protocols member to
struct rc_dev.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/i2c/ir-kbd-i2c.c|1 +
drivers/media/rc/ir-jvc-decoder.c |2 +-
drivers/media/rc/ir-lirc-codec.c |2 +-
drivers/media/rc/ir-mce_kbd-decoder.c |2 +-
drivers/media/rc/ir-nec-decoder.c |2 +-
drivers/media/rc/ir-raw.c |2 +-
drivers/media/rc/ir-rc5-decoder.c |6 +++---
drivers/media/rc/ir-rc5-sz-decoder.c |2 +-
drivers/media/rc/ir-rc6-decoder.c |2 +-
drivers/media/rc/ir-sanyo-decoder.c |2 +-
drivers/media/rc/ir-sony-decoder.c|8
drivers/media/rc/rc-core-priv.h |1 -
drivers/media/rc/rc-main.c| 32 ++--
include/media/rc-core.h |2 ++
14 files changed, 28 insertions(+), 38 deletions(-)
diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index 08ae067..2586e46 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -423,6 +423,7 @@ static int ir_probe(struct i2c_client *client, const struct
i2c_device_id *id)
*/
rc-map_name = ir-ir_codes;
rc-allowed_protos = rc_type;
+ rc-enabled_protocols = rc_type;
if (!rc-driver_name)
rc-driver_name = MODULE_NAME;
diff --git a/drivers/media/rc/ir-jvc-decoder.c
b/drivers/media/rc/ir-jvc-decoder.c
index 69edffb..3948138 100644
--- a/drivers/media/rc/ir-jvc-decoder.c
+++ b/drivers/media/rc/ir-jvc-decoder.c
@@ -47,7 +47,7 @@ static int ir_jvc_decode(struct rc_dev *dev, struct
ir_raw_event ev)
{
struct jvc_dec *data = dev-raw-jvc;
- if (!(dev-raw-enabled_protocols RC_BIT_JVC))
+ if (!(dev-enabled_protocols RC_BIT_JVC))
return 0;
if (!is_timing_event(ev)) {
diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 9945e5e..ff4d93d 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -35,7 +35,7 @@ static int ir_lirc_decode(struct rc_dev *dev, struct
ir_raw_event ev)
struct lirc_codec *lirc = dev-raw-lirc;
int sample;
- if (!(dev-raw-enabled_protocols RC_BIT_LIRC))
+ if (!(dev-enabled_protocols RC_BIT_LIRC))
return 0;
if (!dev-raw-lirc.drv || !dev-raw-lirc.drv-rbuf)
diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c
b/drivers/media/rc/ir-mce_kbd-decoder.c
index 33fafa4..9f3c9b5 100644
--- a/drivers/media/rc/ir-mce_kbd-decoder.c
+++ b/drivers/media/rc/ir-mce_kbd-decoder.c
@@ -216,7 +216,7 @@ static int ir_mce_kbd_decode(struct rc_dev *dev, struct
ir_raw_event ev)
u32 scancode;
unsigned long delay;
- if (!(dev-raw-enabled_protocols RC_BIT_MCE_KBD))
+ if (!(dev-enabled_protocols RC_BIT_MCE_KBD))
return 0;
if (!is_timing_event(ev)) {
diff --git a/drivers/media/rc/ir-nec-decoder.c
b/drivers/media/rc/ir-nec-decoder.c
index a47ee36..9a90094 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -52,7 +52,7 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
u8 address, not_address, command, not_command;
bool send_32bits = false;
- if (!(dev-raw-enabled_protocols RC_BIT_NEC))
+ if (!(dev-enabled_protocols RC_BIT_NEC))
return 0;
if (!is_timing_event(ev)) {
diff --git a/drivers/media/rc/ir-raw.c b/drivers/media/rc/ir-raw.c
index 17c94be..5c42750 100644
--- a/drivers/media/rc/ir-raw.c
+++ b/drivers/media/rc/ir-raw.c
@@ -256,7 +256,7 @@ int ir_raw_event_register(struct rc_dev *dev)
return -ENOMEM;
dev-raw-dev = dev;
- dev-raw-enabled_protocols = ~0;
+ dev-enabled_protocols = ~0;
rc = kfifo_alloc(dev-raw-kfifo,
sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE,
GFP_KERNEL);
diff --git a/drivers/media/rc/ir-rc5-decoder.c
b/drivers/media/rc/ir-rc5-decoder.c
index 5b4d1dd..4e53a31 100644
--- a/drivers/media/rc/ir-rc5-decoder.c
+++ b/drivers/media/rc/ir-rc5-decoder.c
@@ -52,7 +52,7 @@ static int ir_rc5_decode(struct rc_dev *dev, struct
ir_raw_event ev)
u8 toggle;
u32 scancode;
- if (!(dev-raw-enabled_protocols (RC_BIT_RC5 | RC_BIT_RC5X)))
+ if (!(dev-enabled_protocols (RC_BIT_RC5 | RC_BIT_RC5X)))
return 0;
if (!is_timing_event(ev)) {
@@ -128,7 +128,7 @@ again:
if (data-wanted_bits == RC5X_NBITS) {
[PATCH 2/3] rc-core: rename ir_input_class to rc_class
The name is already misleading and will be more so in the future as the
connection to the input subsystem is obscured away further.
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/rc-main.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 3090b40..c56650c 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -715,14 +715,14 @@ static void ir_close(struct input_dev *idev)
}
/* class for /sys/class/rc */
-static char *ir_devnode(struct device *dev, umode_t *mode)
+static char *rc_devnode(struct device *dev, umode_t *mode)
{
return kasprintf(GFP_KERNEL, rc/%s, dev_name(dev));
}
-static struct class ir_input_class = {
+static struct class rc_class = {
.name = rc,
- .devnode= ir_devnode,
+ .devnode= rc_devnode,
};
/*
@@ -1004,7 +1004,7 @@ struct rc_dev *rc_allocate_device(void)
setup_timer(dev-timer_keyup, ir_timer_keyup, (unsigned long)dev);
dev-dev.type = rc_dev_type;
- dev-dev.class = ir_input_class;
+ dev-dev.class = rc_class;
device_initialize(dev-dev);
__module_get(THIS_MODULE);
@@ -1178,7 +1178,7 @@ EXPORT_SYMBOL_GPL(rc_unregister_device);
static int __init rc_core_init(void)
{
- int rc = class_register(ir_input_class);
+ int rc = class_register(rc_class);
if (rc) {
printk(KERN_ERR rc_core: unable to register rc class\n);
return rc;
@@ -1191,7 +1191,7 @@ static int __init rc_core_init(void)
static void __exit rc_core_exit(void)
{
- class_unregister(ir_input_class);
+ class_unregister(rc_class);
rc_map_unregister(empty_map);
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] rc-core: initialize rc-core earlier if built-in
rc-core is a subsystem so it should be registered earlier if built into the kernel. Signed-off-by: David Härdeman da...@hardeman.nu --- drivers/media/rc/rc-main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index c56650c..1cf382a 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -1195,7 +1195,7 @@ static void __exit rc_core_exit(void) rc_map_unregister(empty_map); } -module_init(rc_core_init); +subsys_initcall(rc_core_init); module_exit(rc_core_exit); int rc_core_debug;/* ir_debug level (0,1,2) */ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drxk driver statistics
Em Wed, 06 Mar 2013 20:53:23 +0100 Oliver Schinagl oli...@schinagl.nl escreveu: On 03/06/13 18:36, Jean Delvare wrote: Hi all, I have a TerraTec Cinergy T PCIe Dual card, with DRX-3916K and DRX-3913K frontends. I am thus using the drxk dvb-frontend driver. While trying to find the best antenna, position and amplification, I found that the statistics returned by the drxk driver look quite bad: $ femon -H 3 FE: DRXK DVB-T (DVBT) status SCVYL | signal 0% | snr 0% | ber 0 | unc 38822 | FE_HAS_LOCK status SCVYL | signal 0% | snr 0% | ber 0 | unc 38822 | FE_HAS_LOCK status SCVYL | signal 0% | snr 0% | ber 0 | unc 38822 | FE_HAS_LOCK This is with TV looking reasonably good, so these figures are not plausible. $ femon 10 FE: DRXK DVB-T (DVBT) status SCVYL | signal 00de | snr 00f5 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00f0 | snr 00f5 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 0117 | snr 00f6 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00b6 | snr 00eb | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00d1 | snr 00e7 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 0073 | snr 00ea | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00a3 | snr 00ee | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00b5 | snr 00f4 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00ba | snr 00f3 | ber | unc 97a6 | FE_HAS_LOCK status SCVYL | signal 00be | snr 00f0 | ber | unc 97a6 | FE_HAS_LOCK Signal values are changing too much, snr is stable enough but way too low, ber is apparently unimplemented, and unc is never reset AFAICS (it started at 1 when the system started and has been only increasing since then.) On my previous card, unc was an instant measurement, not a cumulative value, not sure which is correct. Yes I found that out aswell, but since image quality has always been very fine, I haven't looked what this all should be. I would like to see these statistics improved. I am willing to help, however the drxk driver is rather complex (at least to my eyes) and I do not have a datasheet so I wouldn't know where to start. Is there anyone who can work on this and/or provide some guidance? Terratec released some time ago the source code for Azureus 6007 that uses the drx-k demod. I think it is still there at: http://linux.terratec.de/files/TERRATEC_H7/20110323_TERRATEC_H7_Linux.tar.gz The stats logic there is a little more complete than the one backported to the Kernel. I've plans to add support for DVBv5 statistics, but, even on the above driver, it was not trivial to discover the scale for the parameters. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] s5p-mfc: Fix encoder control 15 issue
Hi Arun,
On 03/06/2013 02:15 PM, Arun Kumar K wrote:
mfc-encoder is not working in the latest kernel giving the
erorr Adding control (15) failed. Adding the missing step
parameter in this control to fix the issue.
Do you mean this problem was not observed in 3.8 kernel and something
has changed in the v4l2 core so it fails in 3.9-rc now ? Or is it
related to some change in the driver itself ?
Signed-off-by: Arun Kumar Karun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 2356fd5..4f6b553 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -232,6 +232,7 @@ static struct mfc_control controls[] = {
.minimum = 0,
.maximum = 1,
.default_value = 0,
+ .step = 1,
.menu_skip_mask = 0,
},
{
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regarding linux go7007 driver
On Wed, Mar 06, 2013 at 12:52:00PM -0500, Darrick Burch wrote: Kolokh: I've been doing some work on the go7007 driver in order to make it work properly with my device, an ADS DVD XPress DX2. This device is USB and uses the EZ-USB controller using a tw9906 as a video decoder. There is actually a patch floating around which is supposed to make this work and I've been able to merge the needed changes in order for the go7007-usb driver to detect the device. Hi, Darrick, Hans Verkuil start to a massive overhaul of the go7007 driver , so he collect these patches on http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/go7007 for git use latest: git remote add hverkuil git://git.linuxtv.org/hverkuil/media_tree.git git remote update git checkout -b go7007 hverkuil/go7007 So, there are last patches applied (including mine). I hope, what that work will be merged in linux.git branch (when repair will done) However, I see that there is a problem with the way the i2c subdevice modules are written. When the go7007 module attempts to register any of these subdevices with video4linux, there is a kernel oops since their private state structs do not contain v4l2_subdev as a first member. I see that you had attempted to correct this problem for the tw2804 in this patch... https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/media/go7007?id=0982db20aba5fd124bb5942d679d8732478e992a ..but it was rejected and reverted. Was there a reason why it was never resubmitted? I see an opportunity to get acquainted with kernel module development by fixing the subdevice drivers, but I didn't know if there were any existing plans for this module and whether or not my effort would be worth it. Thanks, -Darrick Regards, Volokh -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] saa7134: Add AverMedia A706 AverTV Satellite Hybrid+FM
On Monday 18 February 2013 03:57:01 Michael Krufky wrote: On Sat, Feb 16, 2013 at 11:39 AM, Ondrej Zary li...@rainbow-software.org wrote: On Friday 01 February 2013 21:21:23 Ondrej Zary wrote: Add AverMedia AverTV Satellite Hybrid+FM (A706) card to saa7134 driver. This requires some changes to tda8290 - disabling I2C gate control and passing custom std_map to tda18271. Also tuner-core needs to be changed because there's currently no way to pass any complex configuration to analog tuners. What's the status of this patch series? The two tda8290 patches are in Michael's dvb tree. I've sent an additional clean-up patch (on Mauro's suggestion) for the tuner-core change. I guess that the final AverMedia A706 patch would be easily merged once the tda8290 and tuner-core changess are done. Should I resend something? I've just been a bit busier lately that I had foreseen, but no need to resend anything - I have your patches. You'll hear back from me shortly. Any news about these patches? -- Ondrej Zary -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] hverkuil/go7007: media: i2c: Fix compilation errors
Fix warnings as errors:
error: implicit declaration of function ‘kzalloc’
[-Werror=implicit-function-declaration]
error: implicit declaration of function ‘kfree’
[-Werror=implicit-function-declaration]
Signed-off-by: Volokh Konstantin volok...@gmail.com
---
drivers/media/i2c/ov7640.c|1 +
drivers/media/i2c/tw9903.c|1 +
drivers/media/i2c/uda1342.c |1 +
drivers/media/tuners/sony-tuner.c |1 +
4 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/i2c/ov7640.c b/drivers/media/i2c/ov7640.c
index 535cf29..224d7cd 100644
--- a/drivers/media/i2c/ov7640.c
+++ b/drivers/media/i2c/ov7640.c
@@ -21,6 +21,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include linux/slab.h
MODULE_DESCRIPTION(OmniVision ov7640 sensor driver);
MODULE_LICENSE(GPL v2);
diff --git a/drivers/media/i2c/tw9903.c b/drivers/media/i2c/tw9903.c
index f859d3a..0c39d38 100644
--- a/drivers/media/i2c/tw9903.c
+++ b/drivers/media/i2c/tw9903.c
@@ -22,6 +22,7 @@
#include linux/ioctl.h
#include media/v4l2-device.h
#include media/v4l2-ctrls.h
+#include linux/slab.h
MODULE_DESCRIPTION(TW9903 I2C subdev driver);
MODULE_LICENSE(GPL v2);
diff --git a/drivers/media/i2c/uda1342.c b/drivers/media/i2c/uda1342.c
index 82319d0..7800236 100644
--- a/drivers/media/i2c/uda1342.c
+++ b/drivers/media/i2c/uda1342.c
@@ -21,6 +21,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/uda1342.h
+#include linux/slab.h
static int write_reg(struct i2c_client *client, int reg, int value)
{
diff --git a/drivers/media/tuners/sony-tuner.c
b/drivers/media/tuners/sony-tuner.c
index 1b77529..8411e97 100644
--- a/drivers/media/tuners/sony-tuner.c
+++ b/drivers/media/tuners/sony-tuner.c
@@ -23,6 +23,7 @@
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
#include media/v4l2-device.h
+#include linux/slab.h
MODULE_DESCRIPTION(Sony TV Tuner driver);
MODULE_LICENSE(GPL v2);
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] hverkuil/go7007: media: i2c: Correct authorship info
Signed-off-by: Volokh Konstantin volok...@gmail.com --- drivers/media/i2c/tw2804.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/i2c/tw2804.c b/drivers/media/i2c/tw2804.c index 096b657..45a4cd3 100644 --- a/drivers/media/i2c/tw2804.c +++ b/drivers/media/i2c/tw2804.c @@ -431,5 +431,4 @@ module_i2c_driver(wis_tw2804_driver); MODULE_LICENSE(GPL v2); MODULE_DESCRIPTION(TW2804/TW2802 V4L2 i2c driver); -MODULE_AUTHOR(Volokh Konstantin volok...@gmail.com); MODULE_AUTHOR(Micronas USA Inc); -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: cx231xx : Add support for OTG102 aka EZGrabber2
That is welcome by me, let me know if any action is needed on my end.
I was also wondering about adding the definition for the device 0572:58a3
which is identically identified in the distributed Windows driver from
Geniatech, but as it is not verified and may not even be in production, I
suppose it is best to wait until someone with such a device cares to test
it.
Thanks,
Matt
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Wednesday, March 06, 2013 12:56 PM
To: gomb...@gmail.com
Cc: linux-media@vger.kernel.org
Subject: Re: cx231xx : Add support for OTG102 aka EZGrabber2
Hi Matt,
While I added this patch to my cx231xx patch series, Mauro didn't pick it
up for some reason. So for when he gets around to looking at your patch, I
want to
add my:
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
On Sat March 2 2013 00:53:30 Matt Gomboc wrote:
Thanks for the response, I have done as you suggested.
Below is an updated patch for the OTG102 device against
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cx231xx,
kernel version 3.8.
With further testing it appears the extra clauses in cx231xx-cards.c were
not necessary (in static in cx231xx_init_dev and static int
cx231xx_usb_probe), so those have been also been removed.
Signed-off-by: Matt Gomboc gomb...@gmail.com
--
drivers/media/usb/cx231xx/cx231xx-avcore.c | 2 ++
drivers/media/usb/cx231xx/cx231xx-cards.c | 35
++
drivers/media/usb/cx231xx/cx231xx.h| 1 +
3 files changed, 38 insertions(+)
diff --git a/drivers/media/usb/cx231xx/cx231xx-avcore.c
b/drivers/media/usb/cx231xx/cx231xx-avcore.c
index 2e51fb9..235ba65 100644
--- a/drivers/media/usb/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/usb/cx231xx/cx231xx-avcore.c
@@ -357,6 +357,7 @@ int cx231xx_afe_update_power_control(struct cx231xx
*dev,
case CX231XX_BOARD_PV_PLAYTV_USB_HYBRID:
case CX231XX_BOARD_HAUPPAUGE_USB2_FM_PAL:
case CX231XX_BOARD_HAUPPAUGE_USB2_FM_NTSC:
+ case CX231XX_BOARD_OTG102:
if (avmode == POLARIS_AVMODE_ANALOGT_TV) {
while (afe_power_status != (FLD_PWRDN_TUNING_BIAS |
FLD_PWRDN_ENABLE_PLL)) {
@@ -1720,6 +1721,7 @@ int cx231xx_dif_set_standard(struct cx231xx *dev,
u32 standard)
case CX231XX_BOARD_CNXT_RDU_250:
case CX231XX_BOARD_CNXT_VIDEO_GRABBER:
case CX231XX_BOARD_HAUPPAUGE_EXETER:
+ case CX231XX_BOARD_OTG102:
func_mode = 0x03;
break;
case CX231XX_BOARD_CNXT_RDE_253S:
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index b7b1acd..13249e5 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -634,6 +634,39 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+ [CX231XX_BOARD_OTG102] = {
+ .name = Geniatech OTG102,
+ .tuner_type = TUNER_ABSENT,
+ .decoder = CX231XX_AVDECODER,
+ .output_mode = OUT_MODE_VIP11,
+ .ctl_pin_status_mask = 0xFFC4,
+ .agc_analog_digital_select_gpio = 0x0c,
+ /* According with PV CxPlrCAP.inf file */
+ .gpio_pin_status_mask = 0x4001000,
+ .norm = V4L2_STD_NTSC,
+ .no_alt_vanc = 1,
+ .external_av = 1,
+ .dont_use_port_3 = 1,
+ /*.has_417 = 1, */
+ /* This board is believed to have a hardware encoding chip
+ * supporting mpeg1/2/4, but as the 417 is apparently not
+ * working for the reference board it is not here either. */
+
+ .input = {{
+ .type = CX231XX_VMUX_COMPOSITE1,
+ .vmux = CX231XX_VIN_2_1,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ }, {
+ .type = CX231XX_VMUX_SVIDEO,
+ .vmux = CX231XX_VIN_1_1 |
+ (CX231XX_VIN_1_2 8) |
+ CX25840_SVIDEO_ON,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ }
+ },
+ },
};
const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
@@ -675,6 +708,8 @@ struct usb_device_id cx231xx_id_table[] = {
.driver_info = CX231XX_BOARD_ICONBIT_U100},
{USB_DEVICE(0x0fd9, 0x0037),
.driver_info = CX231XX_BOARD_ELGATO_VIDEO_CAPTURE_V2},
+ {USB_DEVICE(0x1f4d, 0x0102),
+ .driver_info = CX231XX_BOARD_OTG102},
{},
};
diff --git a/drivers/media/usb/cx231xx/cx231xx.h
b/drivers/media/usb/cx231xx/cx231xx.h
index
[PATCH] cxd2820r_t2: Multistream support (MultiPLP)
MultiPLP filtering support for CXD2820r, not tested.
Somebody from Russia please test (exclude Moscow, because used singlePLP).
Usual used PLP 0 (4TV + 3 radio) and 1 (4TV). PLP 2,3 reserved (regional
channels).
P.S. You can use my scan-s2 with multistream support -
https://bitbucket.org/CrazyCat/scan-s2. Generated channel list compatible with
current VDR 1.7.3x
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c
b/drivers/media/dvb-frontends/cxd2820r_core.c
index 9b658c1..7ca5c69 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -660,7 +660,8 @@ static const struct dvb_frontend_ops cxd2820r_ops = {
FE_CAN_GUARD_INTERVAL_AUTO |
FE_CAN_HIERARCHY_AUTO |
FE_CAN_MUTE_TS |
- FE_CAN_2G_MODULATION
+ FE_CAN_2G_MODULATION|
+ FE_CAN_MULTISTREAM
},
.release= cxd2820r_release,
diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c
b/drivers/media/dvb-frontends/cxd2820r_t2.c
index e82d82a..c2bfea7 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t2.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
@@ -124,6 +124,23 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)
buf[1] = ((if_ctl 8) 0xff);
buf[2] = ((if_ctl 0) 0xff);
+ /* PLP filtering */
+ if (c-stream_id 0 || c-stream_id 255) {
+ dev_dbg(priv-i2c-dev, %s: Disable PLP filtering\n,
__func__);
+ ret = cxd2820r_wr_reg(priv, 0x023ad , 0);
+ if (ret)
+ goto error;
+ } else {
+ dev_dbg(priv-i2c-dev, %s: Enable PLP filtering = %d\n,
__func__,
+ c-stream_id);
+ ret = cxd2820r_wr_reg(priv, 0x023af , c-stream_id 0xFF);
+ if (ret)
+ goto error;
+ ret = cxd2820r_wr_reg(priv, 0x023ad , 1);
+ if (ret)
+ goto error;
+ }
+
ret = cxd2820r_wr_regs(priv, 0x020b6, buf, 3);
if (ret)
goto error;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] s5p-mfc: Fix encoder control 15 issue
Hi Sylwester,
On Thu, Mar 7, 2013 at 3:40 AM, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
Hi Arun,
On 03/06/2013 02:15 PM, Arun Kumar K wrote:
mfc-encoder is not working in the latest kernel giving the
erorr Adding control (15) failed. Adding the missing step
parameter in this control to fix the issue.
Do you mean this problem was not observed in 3.8 kernel and something
has changed in the v4l2 core so it fails in 3.9-rc now ? Or is it
related to some change in the driver itself ?
v4l2_ctrl_new() uses check_range() for control range checking (which
is added newly).
This function expects 'step' value for V4L2_CTRL_TYPE_BOOLEAN type control.
If 'step' value doesn't match to '1', it returns -ERANGE error.
Its a change in v4l2 core.
Regards,
Shaik Ameer Basha
Signed-off-by: Arun Kumar Karun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 2356fd5..4f6b553 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -232,6 +232,7 @@ static struct mfc_control controls[] = {
.minimum = 0,
.maximum = 1,
.default_value = 0,
+ .step = 1,
.menu_skip_mask = 0,
},
{
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pixel Formats
Hi, I'm looking for some guidance on the correct way to handle a new pixel format. What I'm dealing with is a CMOS image sensor that supports dynamic switching between linear and iHDR modes. iHDR stands for interlaced High Dynamic Range and is a mode where odd and even lines have different exposure times, typically with an 8:1 ratio. When I started implementing a driver for this sensor I used V4L2_MBUS_FMT_SGRBG10_1X10 as the format for the linear mode and defined a new format V4L2_MBUS_FMT_SGRBG10_IHDR_1X10 for the iHDR mode. I used the format to control which mode I put the sensor in. But now I'm having trouble switching modes without reinitializing the sensor. Does anyone (everyone?) have an opinion about the correct way to implement this? I'm thinking that the format is overloaded because it represents both the size and type of the data. Should I use a single format and add a control to switch the mode? Chris Rhodin Aptina Imaging Aptina, LLC / 3080 North First Street, San Jose, CA 95134 This e-mail and any attachments contain confidential information and are solely for the review and use of the intended recipient. If you have received this e-mail in error, please notify the sender and destroy this e-mail and any copies. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] s5p-mfc: Fix encoder control 15 issue
Hi Sylwester, Do you mean this problem was not observed in 3.8 kernel and something has changed in the v4l2 core so it fails in 3.9-rc now ? Or is it related to some change in the driver itself ? I saw this problem in 3.9rc1 and also in 3.8 stable. But I havent seen this in media-tree v3.9 staging branch. I didnt dig in much into what changed in v4l2 framework for this to happen now. Regards Arun -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 0/2] Add display-timing node parsing to exynos drm fimd
Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html changes since v10: - abandoned the pinctrl patch, as commented by Linus Walleij linus.wall...@linaro.org - added new patch to enable the OF_VIDEOMODE and FB_MODE_HELPERS for EXYNOS DRM FIMD. changes since v9: - replaced IS_ERR_OR_NULL() with IS_ERR(), since IS_ERR_OR_NULL() will be depreciated, as discussed at http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140543.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg78030.html changes since v8: - replaced IS_ERR() with IS_ERR_OR_NULL(), because devm_pinctrl_get_select_default can return NULL, If CONFIG_PINCTRL is disabled. - modified the error log, such that it shall NOT cross 80 column. - added Acked-by. changes since v7: - addressed comments from Joonyoung Shim jy0922.s...@samsung.com to remove a unnecessary variable. changes since v6: addressed comments from Inki Dae inki@samsung.com to separated out the pinctrl functionality and made a separate patch. changes since v5: - addressed comments from Inki Dae inki@samsung.com, to remove the allocation of 'fbmode' and replaced '-1'in of_get_fb_videomode(dev-of_node, fbmode, -1) with OF_USE_NATIVE_MODE. changes since v4: - addressed comments from Paul Menzel paulepan...@users.sourceforge.net, to modify the commit message changes since v3: - addressed comments from Sean Paul seanp...@chromium.org, to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev-dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma r.sh.o...@gmail.com) changes since v1: - addressed comments from Sean Paul seanp...@chromium.org Vikas Sajjan (2): video: drm: exynos: Add display-timing node parsing using video helper function drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd drivers/gpu/drm/exynos/Kconfig |2 ++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 27 +++ 2 files changed, 25 insertions(+), 4 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
Add support for parsing the display-timing node using video helper
function.
The DT node parsing is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..f322ec3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
#include linux/of_device.h
#include linux/pm_runtime.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ ret = of_get_fb_videomode(dev-of_node, pdata-panel.timing,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode() : %d\n, ret);
+ return ret;
+ }
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 2/2] drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd
patch adds select OF_VIDEOMODE and select FB_MODE_HELPERS when EXYNOS_DRM_FIMD config is selected. Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org --- drivers/gpu/drm/exynos/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 046bcda..bb25130 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -25,6 +25,8 @@ config DRM_EXYNOS_DMABUF config DRM_EXYNOS_FIMD bool Exynos DRM FIMD depends on DRM_EXYNOS !FB_S3C !ARCH_MULTIPLATFORM + select OF_VIDEOMODE + select FB_MODE_HELPERS help Choose this option if you want to use Exynos FIMD for DRM. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: modify the compatible string for exynos fimd
Hi Mr Inki Dae,
On 28 February 2013 08:12, Joonyoung Shim jy0922.s...@samsung.com wrote:
On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
modified compatible string for exynos4 fimd as exynos4210-fimd and
exynos5 fimd as exynos5250-fimd to stick to the rule that compatible
value should be named after first specific SoC model in which this
particular IP version was included as discussed at
https://patchwork.kernel.org/patch/2144861/
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..433ed35 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -109,9 +109,9 @@ struct fimd_context {
#ifdef CONFIG_OF
static const struct of_device_id fimd_driver_dt_match[] = {
- { .compatible = samsung,exynos4-fimd,
+ { .compatible = samsung,exynos4210-fimd,
.data = exynos4_fimd_driver_data },
- { .compatible = samsung,exynos5-fimd,
+ { .compatible = samsung,exynos5250-fimd,
.data = exynos5_fimd_driver_data },
{},
};
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
Can you please apply this patch.
Thanks.
--
Thanks and Regards
Vikas Sajjan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] davinci: vpif: Fix module build for capture and display
From: Lad, Prabhakar prabhakar@ti.com
export the symbols which are used by two modules vpif_capture and
vpif_display.
This patch fixes following error:
ERROR: ch_params [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: vpif_ch_params_count [drivers/media/platform/davinci/vpif_display.ko]
undefined!
ERROR: vpif_base [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: ch_params [drivers/media/platform/davinci/vpif_capture.ko] undefined!
ERROR: vpif_ch_params_count [drivers/media/platform/davinci/vpif_capture.ko]
undefined!
ERROR: vpif_base [drivers/media/platform/davinci/vpif_capture.ko] undefined!
make[1]: *** [__modpost] Error 1
Reported-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
drivers/media/platform/davinci/vpif.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c
b/drivers/media/platform/davinci/vpif.c
index 28638a8..8fbb4a2 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -44,6 +44,8 @@ static struct resource*res;
spinlock_t vpif_lock;
void __iomem *vpif_base;
+EXPORT_SYMBOL(vpif_base);
+
struct clk *vpif_clk;
/**
@@ -220,8 +222,10 @@ const struct vpif_channel_config_params ch_params[] = {
.stdid = V4L2_STD_625_50,
},
};
+EXPORT_SYMBOL(ch_params);
const unsigned int vpif_ch_params_count = ARRAY_SIZE(ch_params);
+EXPORT_SYMBOL(vpif_ch_params_count);
static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
{
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] [media] davinci_vpfe: Use module_platform_driver macro
On 5 March 2013 17:46, Prabhakar Lad prabhakar.cse...@gmail.com wrote: Hi Sachin, Thanks for the patch! On Tue, Mar 5, 2013 at 5:22 PM, Sachin Kamat sachin.ka...@linaro.org wrote: module_platform_driver() eliminates the boilerplate and simplifies the code. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Acked-by: Lad, Prabhakar prabhakar@ti.com Thanks Prabhakar. BTW, who is supposed to pick this patch? -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] drm/exynos: modify the compatible string for exynos fimd
Already merged. :)
-Original Message-
From: Vikas Sajjan [mailto:vikas.saj...@linaro.org]
Sent: Thursday, March 07, 2013 4:09 PM
To: InKi Dae
Cc: dri-de...@lists.freedesktop.org; linux-media@vger.kernel.org;
kgene@samsung.com; Joonyoung Shim; sunil joshi
Subject: Re: [PATCH] drm/exynos: modify the compatible string for exynos
fimd
Hi Mr Inki Dae,
On 28 February 2013 08:12, Joonyoung Shim jy0922.s...@samsung.com wrote:
On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
modified compatible string for exynos4 fimd as exynos4210-fimd and
exynos5 fimd as exynos5250-fimd to stick to the rule that compatible
value should be named after first specific SoC model in which this
particular IP version was included as discussed at
https://patchwork.kernel.org/patch/2144861/
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..433ed35 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -109,9 +109,9 @@ struct fimd_context {
#ifdef CONFIG_OF
static const struct of_device_id fimd_driver_dt_match[] = {
- { .compatible = samsung,exynos4-fimd,
+ { .compatible = samsung,exynos4210-fimd,
.data = exynos4_fimd_driver_data },
- { .compatible = samsung,exynos5-fimd,
+ { .compatible = samsung,exynos5250-fimd,
.data = exynos5_fimd_driver_data },
{},
};
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
Can you please apply this patch.
Thanks.
--
Thanks and Regards
Vikas Sajjan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: davinci: kconfig: fix incorrect selects
Sekhar, On Wed, Mar 6, 2013 at 7:51 PM, Sekhar Nori nsek...@ti.com wrote: On 3/6/2013 4:05 PM, Prabhakar Lad wrote: On Wed, Mar 6, 2013 at 3:53 PM, Sekhar Nori nsek...@ti.com wrote: On 3/6/2013 3:46 PM, Prabhakar Lad wrote: Sekhar, On Wed, Mar 6, 2013 at 3:37 PM, Sekhar Nori nsek...@ti.com wrote: On 3/6/2013 2:59 PM, Prabhakar Lad wrote: config VIDEO_DAVINCI_VPIF_DISPLAY tristate DM646x/DA850/OMAPL138 EVM Video Display - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 if MEDIA_SUBDRV_AUTOSELECT select VIDEO_THS7303 if MEDIA_SUBDRV_AUTOSELECT help @@ -15,9 +14,8 @@ config VIDEO_DAVINCI_VPIF_DISPLAY config VIDEO_DAVINCI_VPIF_CAPTURE tristate DM646x/DA850/OMAPL138 EVM Video Capture - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) VIDEO_DAVINCI_VPIF select VIDEOBUF2_DMA_CONTIG - select VIDEO_DAVINCI_VPIF help Enables Davinci VPIF module used for captur devices. This module is common for following DM6467/DA850/OMAPL138 @@ -28,7 +26,7 @@ config VIDEO_DAVINCI_VPIF_CAPTURE config VIDEO_DAVINCI_VPIF tristate DaVinci VPIF Driver - depends on VIDEO_DAVINCI_VPIF_DISPLAY || VIDEO_DAVINCI_VPIF_CAPTURE + depends on ARCH_DAVINCI It would be better if this was depends on MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM rather than 'ARCH_DAVINCI' then you can remove 'MACH_DAVINCI_DM6467_EVM' and 'MACH_DAVINCI_DA850_EVM' dependency from VIDEO_DAVINCI_VPIF_DISPLAY and VIDEO_DAVINCI_VPIF_CAPTURE. So it would be just 'depends on VIDEO_DEV VIDEO_DAVINCI_VPIF' I could, but vpif.c seems pretty board independent to me. Are you sure no other board would like to build vpif.c? BTW, are vpif_display.c and vpif_capture.c really that board specific? May be we can all make them depend on ARCH_DAVINCI? VPIF is present only in DM646x and DA850/OMAP-L1138. vpif.c is common file which is used by vpif_capture and vpif_display. So vpif.c per se doesn't do anything useful. Why the dependency on EVMs? There are other boards for these platform which could use VPIF. yep agreed! So instead of presenting a non-useful vpif selection to users, vpif.c dependency is better handled in makefile, no? Agreed that’s a better fix. How about the patch below (now also rebased on v3.9-rc1)? Looks good. What about vpss.c? Does it make sense not to present a config for that as well? Yes there isn't a need in config for it too, this also should be handled in Makefile as well. I also noticed that module build of VPIF is broken in mainline. That needs to be fixed too. Posted a patch fixing it(http://patchwork.linuxtv.org/patch/17145/). Regards, --Prabhakar Thanks, Sekhar ---8--- From: Sekhar Nori nsek...@ti.com Date: Tue, 5 Mar 2013 19:08:59 +0530 Subject: [PATCH] media: davinci: kconfig: fix incorrect selects drivers/media/platform/davinci/Kconfig uses selects where it should be using 'depends on'. This results in warnings of the following sort when doing randconfig builds. warning: (VIDEO_DM6446_CCDC VIDEO_DM355_CCDC VIDEO_ISIF VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT V4L_PLATFORM_DRIVERS ARCH_DAVINCI) The VPIF kconfigs had a strange 'select' and 'depends on' cross linkage which have been fixed as well by removing unneeded VIDEO_DAVINCI_VPIF config symbol. Selecting VPIF is now possible on all DaVinci platforms instead of two specific EVMs earlier. While at it, fix the Kconfig help text to make it more readable. This patch has only been build tested, I do not have the setup to test video. I also do not know if the dependencies are really needed, I have just tried to not break any existing assumptions. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Sekhar Nori nsek...@ti.com --- drivers/media/platform/davinci/Kconfig | 41 ++- drivers/media/platform/davinci/Makefile |7 ++ 2 files changed, 15 insertions(+), 33 deletions(-) diff --git a/drivers/media/platform/davinci/Kconfig b/drivers/media/platform/davinci/Kconfig index ccfde4e..42152f9 100644 --- a/drivers/media/platform/davinci/Kconfig +++ b/drivers/media/platform/davinci/Kconfig @@ -1,40 +1,29 @@ config VIDEO_DAVINCI_VPIF_DISPLAY - tristate DM646x/DA850/OMAPL138 EVM Video Display - depends on VIDEO_DEV (MACH_DAVINCI_DM6467_EVM || MACH_DAVINCI_DA850_EVM) + tristate TI DaVinci VPIF Video Display + depends on VIDEO_DEV ARCH_DAVINCI select VIDEOBUF2_DMA_CONTIG - select
Re: [PATCH 1/1] [media] davinci_vpfe: Use module_platform_driver macro
Hi Sachin, On Thu, Mar 7, 2013 at 12:46 PM, Sachin Kamat sachin.ka...@linaro.org wrote: On 5 March 2013 17:46, Prabhakar Lad prabhakar.cse...@gmail.com wrote: Hi Sachin, Thanks for the patch! On Tue, Mar 5, 2013 at 5:22 PM, Sachin Kamat sachin.ka...@linaro.org wrote: module_platform_driver() eliminates the boilerplate and simplifies the code. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Acked-by: Lad, Prabhakar prabhakar@ti.com Thanks Prabhakar. BTW, who is supposed to pick this patch? I'll queue it for 3.10 and a issue a pull request to Mauro soon. Or if you have a branch and want to issue a pull no problem(anyways I have Acked it). what do you suggest ? Regards, --Prabhakar Lad -- With warm regards, Sachin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: modify the compatible string for exynos fimd
Thanks.
On 7 March 2013 12:47, Inki Dae inki@samsung.com wrote:
Already merged. :)
-Original Message-
From: Vikas Sajjan [mailto:vikas.saj...@linaro.org]
Sent: Thursday, March 07, 2013 4:09 PM
To: InKi Dae
Cc: dri-de...@lists.freedesktop.org; linux-media@vger.kernel.org;
kgene@samsung.com; Joonyoung Shim; sunil joshi
Subject: Re: [PATCH] drm/exynos: modify the compatible string for exynos
fimd
Hi Mr Inki Dae,
On 28 February 2013 08:12, Joonyoung Shim jy0922.s...@samsung.com wrote:
On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
modified compatible string for exynos4 fimd as exynos4210-fimd and
exynos5 fimd as exynos5250-fimd to stick to the rule that compatible
value should be named after first specific SoC model in which this
particular IP version was included as discussed at
https://patchwork.kernel.org/patch/2144861/
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..433ed35 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -109,9 +109,9 @@ struct fimd_context {
#ifdef CONFIG_OF
static const struct of_device_id fimd_driver_dt_match[] = {
- { .compatible = samsung,exynos4-fimd,
+ { .compatible = samsung,exynos4210-fimd,
.data = exynos4_fimd_driver_data },
- { .compatible = samsung,exynos5-fimd,
+ { .compatible = samsung,exynos5250-fimd,
.data = exynos5_fimd_driver_data },
{},
};
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
Can you please apply this patch.
Thanks.
--
Thanks and Regards
Vikas Sajjan
--
Thanks and Regards
Vikas Sajjan
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v12 0/2] Add display-timing node parsing to exynos drm fimd
Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html changes since v11: - Oops, there was a build error, fixed that. changes since v10: - abandoned the pinctrl patch, as commented by Linus Walleij linus.wall...@linaro.org - added new patch to enable the OF_VIDEOMODE and FB_MODE_HELPERS for EXYNOS DRM FIMD. changes since v9: - replaced IS_ERR_OR_NULL() with IS_ERR(), since IS_ERR_OR_NULL() will be depreciated, as discussed at http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140543.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg78030.html changes since v8: - replaced IS_ERR() with IS_ERR_OR_NULL(), because devm_pinctrl_get_select_default can return NULL, If CONFIG_PINCTRL is disabled. - modified the error log, such that it shall NOT cross 80 column. - added Acked-by. changes since v7: - addressed comments from Joonyoung Shim jy0922.s...@samsung.com to remove a unnecessary variable. changes since v6: addressed comments from Inki Dae inki@samsung.com to separated out the pinctrl functionality and made a separate patch. changes since v5: - addressed comments from Inki Dae inki@samsung.com, to remove the allocation of 'fbmode' and replaced '-1'in of_get_fb_videomode(dev-of_node, fbmode, -1) with OF_USE_NATIVE_MODE. changes since v4: - addressed comments from Paul Menzel paulepan...@users.sourceforge.net, to modify the commit message changes since v3: - addressed comments from Sean Paul seanp...@chromium.org, to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev-dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma r.sh.o...@gmail.com) changes since v1: - addressed comments from Sean Paul seanp...@chromium.org Vikas Sajjan (2): video: drm: exynos: Add display-timing node parsing using video helper function drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd drivers/gpu/drm/exynos/Kconfig |2 ++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 27 +++ 2 files changed, 25 insertions(+), 4 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v12 1/2] video: drm: exynos: Add display-timing node parsing using video helper function
Add support for parsing the display-timing node using video helper
function.
The DT node parsing is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9537761..e323cf9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,7 @@
#include linux/of_device.h
#include linux/pm_runtime.h
+#include video/of_display_timing.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -883,10 +884,25 @@ static int fimd_probe(struct platform_device *pdev)
DRM_DEBUG_KMS(%s\n, __FILE__);
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(dev, no platform data specified\n);
- return -EINVAL;
+ if (pdev-dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ return -ENOMEM;
+ }
+
+ ret = of_get_fb_videomode(dev-of_node, pdata-panel.timing,
+ OF_USE_NATIVE_MODE);
+ if (ret) {
+ DRM_ERROR(failed: of_get_fb_videomode() : %d\n, ret);
+ return ret;
+ }
+ } else {
+ pdata = pdev-dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR(no platform data specified\n);
+ return -EINVAL;
+ }
}
panel = pdata-panel;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v12 2/2] drm/exynos: enable OF_VIDEOMODE and FB_MODE_HELPERS for exynos drm fimd
patch adds select OF_VIDEOMODE and select FB_MODE_HELPERS when EXYNOS_DRM_FIMD config is selected. Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org --- drivers/gpu/drm/exynos/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 046bcda..bb25130 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -25,6 +25,8 @@ config DRM_EXYNOS_DMABUF config DRM_EXYNOS_FIMD bool Exynos DRM FIMD depends on DRM_EXYNOS !FB_S3C !ARCH_MULTIPLATFORM + select OF_VIDEOMODE + select FB_MODE_HELPERS help Choose this option if you want to use Exynos FIMD for DRM. -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
China silicone gifts factory
ZCH Industrial Co., Ltd is is located in Donguang city since 2006's, We have strong area in fields of silicone rubber series, Such as silicone watches, wristband, bracelet,phone case,kitchware,cake mould,ballet point toe pads,keyboard etc. Also our sales term responsible for promotion, business and shipping. it's our pleasure to be your reliable representative office in China For more our company information, please browse or downlad catalogue at http://www.giftzch.com , Your questions,OEM,ODM design please contact us at sa...@giftzch.com or 0086 769 81187183. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
