Re: [RFC PATCH 1/3] s5p-g2d: fix compiler warning
On Wed October 3 2012 12:16:48 Sylwester Nawrocki wrote: On 10/02/2012 10:57 AM, Hans Verkuil wrote: drivers/media/platform/s5p-g2d/g2d.c:535:2: warning: passing argument 3 of 'vidioc_try_crop' discards 'const' qualifier from pointer target type [enabled by default] drivers/media/platform/s5p-g2d/g2d.c:510:12: note: expected 'struct v4l2_crop *' but argument is of type 'const struct v4l2_crop *' This is fall-out from this commit: commit 4f996594ceaf6c3f9bc42b40c40b0f7f87b79c86 Author: Hans Verkuil hans.verk...@cisco.com Date: Wed Sep 5 05:10:48 2012 -0300 [media] v4l2: make vidioc_s_crop const Signed-off-by: Hans Verkuil hans.verk...@cisco.com Aplied, thanks. Just to be clear, you're taking care of these s5p patches through your tree, right? 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
[PATCH v1 00/14] drm: exynos: hdmi: add dt based support for exynos5 hdmi
This patch set adds the DT based support for Samsung's Exynos5250 in DRM-HDMI. It includes disabling of hdmi internal interrupt, suppport for platform variants for hdmi and mixer, support to disable video processor based on platform type and removal of drm common platform data. This patchset is based on branch exynos-drm-next at git://git.infradead.org/users/kmpark/linux-samsung (linux v3.6-rc4) v2: - removed MXR_VER_INVALID - moved layer update from vsync ISR to mixer_graph_buffer - stopped enabling vsync interrupt after poweron Rahul Sharma (9): drm: exynos: remove drm hdmi platform data struct drm: exynos: hdmi: add support for exynos5 ddc drm: exynos: hdmi: add support for exynos5 hdmiphy drm: exynos: hdmi: add support for platform variants for mixer drm: exynos: hdmi: add support to disable video processor in mixer drm: exynos: hdmi: add support for exynos5 mixer drm: exynos: hdmi: replace is_v13 with version check in hdmi drm: exynos: hdmi: add support for exynos5 hdmi drm: exynos: hdmi: remove drm common hdmi platform data struct Tomasz Stanislawski (5): media: s5p-hdmi: add HPD GPIO to platform data drm: exynos: hdmi: support for platform variants drm: exynos: hdmi: fix interrupt handling drm: exynos: hdmi: use s5p-hdmi platform data drm: exynos: hdmi: turn off HPD interrupt in HDMI chip drivers/gpu/drm/exynos/exynos_ddc.c | 22 +++- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 51 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 + drivers/gpu/drm/exynos/exynos_hdmi.c | 196 +++--- drivers/gpu/drm/exynos/exynos_hdmiphy.c | 12 ++- drivers/gpu/drm/exynos/exynos_mixer.c| 227 +++--- drivers/gpu/drm/exynos/regs-mixer.h |3 + include/drm/exynos_drm.h | 27 include/media/s5p_hdmi.h |2 + 9 files changed, 378 insertions(+), 164 deletions(-) -- 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 v1 02/14] drm: exynos: hdmi: support for platform variants
From: Tomasz Stanislawski t.stanisl...@samsung.com
This patch implements check if HDMI is version 1.3 by using a driver variant
instead of platform data.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 25 -
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a6aea6f..b3a802b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2262,6 +2262,26 @@ void hdmi_attach_hdmiphy_client(struct i2c_client
*hdmiphy)
hdmi_hdmiphy = hdmiphy;
}
+enum hdmi_type {
+ HDMI_TYPE13,
+ HDMI_TYPE14,
+};
+
+static struct platform_device_id hdmi_driver_types[] = {
+ {
+ .name = s5pv210-hdmi,
+ .driver_data= HDMI_TYPE13,
+ }, {
+ .name = exynos4-hdmi,
+ .driver_data= HDMI_TYPE13,
+ }, {
+ .name = exynos4-hdmi14,
+ .driver_data= HDMI_TYPE14,
+ }, {
+ /* end node */
+ }
+};
+
static int __devinit hdmi_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -2270,6 +2290,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
struct exynos_drm_hdmi_pdata *pdata;
struct resource *res;
int ret;
+ enum hdmi_type hdmi_type;
DRM_DEBUG_KMS([%d]\n, __LINE__);
@@ -2300,7 +2321,8 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, drm_hdmi_ctx);
- hdata-is_v13 = pdata-is_v13;
+ hdmi_type = platform_get_device_id(pdev)-driver_data;
+ hdata-is_v13 = (hdmi_type == HDMI_TYPE13);
hdata-cfg_hpd = pdata-cfg_hpd;
hdata-get_hpd = pdata-get_hpd;
hdata-dev = dev;
@@ -2447,6 +2469,7 @@ static SIMPLE_DEV_PM_OPS(hdmi_pm_ops, hdmi_suspend,
hdmi_resume);
struct platform_driver hdmi_driver = {
.probe = hdmi_probe,
.remove = __devexit_p(hdmi_remove),
+ .id_table = hdmi_driver_types,
.driver = {
.name = exynos4-hdmi,
.owner = THIS_MODULE,
--
1.7.0.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 http://vger.kernel.org/majordomo-info.html
[PATCH v1 03/14] drm: exynos: hdmi: fix interrupt handling
From: Tomasz Stanislawski t.stanisl...@samsung.com
This patch fixes 'unsigned 0' check in probe. Moreover it
releases an interrupt at remove.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index b3a802b..3902917 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -64,8 +64,8 @@ struct hdmi_context {
struct mutexhdmi_mutex;
void __iomem*regs;
- unsigned intexternal_irq;
- unsigned intinternal_irq;
+ int external_irq;
+ int internal_irq;
struct i2c_client *ddc_port;
struct i2c_client *hdmiphy_port;
@@ -2424,6 +2424,7 @@ static int __devexit hdmi_remove(struct platform_device
*pdev)
pm_runtime_disable(dev);
free_irq(hdata-internal_irq, hdata);
+ free_irq(hdata-external_irq, hdata);
hdmi_resources_cleanup(hdata);
--
1.7.0.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 http://vger.kernel.org/majordomo-info.html
[PATCH v1 04/14] drm: exynos: hdmi: use s5p-hdmi platform data
From: Tomasz Stanislawski t.stanisl...@samsung.com
The 'exynos-drm-hdmi' driver makes use of s5p-tv platform devices. Therefore
the driver should use the same platform data to prevent crashes caused by
dereferencing incorrect types. This patch corrects the exynos-drm-hdmi driver
to the platform data from s5p-hdmi.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 55 +++---
1 files changed, 24 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3902917..90dce8c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -40,6 +40,9 @@
#include exynos_hdmi.h
+#include linux/gpio.h
+#include media/s5p_hdmi.h
+
#define MAX_WIDTH 1920
#define MAX_HEIGHT 1080
#define get_hdmi_context(dev) platform_get_drvdata(to_platform_device(dev))
@@ -76,8 +79,7 @@ struct hdmi_context {
struct hdmi_resources res;
void*parent_ctx;
- void(*cfg_hpd)(bool external);
- int (*get_hpd)(void);
+ int hpd_gpio;
};
/* HDMI Version 1.3 */
@@ -2024,8 +2026,6 @@ static void hdmi_poweron(struct hdmi_context *hdata)
hdata-powered = true;
- if (hdata-cfg_hpd)
- hdata-cfg_hpd(true);
mutex_unlock(hdata-hdmi_mutex);
pm_runtime_get_sync(hdata-dev);
@@ -2061,8 +2061,6 @@ static void hdmi_poweroff(struct hdmi_context *hdata)
pm_runtime_put_sync(hdata-dev);
mutex_lock(hdata-hdmi_mutex);
- if (hdata-cfg_hpd)
- hdata-cfg_hpd(false);
hdata-powered = false;
@@ -2110,17 +2108,13 @@ static irqreturn_t hdmi_external_irq_thread(int irq,
void *arg)
struct exynos_drm_hdmi_context *ctx = arg;
struct hdmi_context *hdata = ctx-ctx;
- if (!hdata-get_hpd)
- goto out;
-
mutex_lock(hdata-hdmi_mutex);
- hdata-hpd = hdata-get_hpd();
+ hdata-hpd = gpio_get_value(hdata-hpd_gpio);
mutex_unlock(hdata-hdmi_mutex);
if (ctx-drm_dev)
drm_helper_hpd_irq_event(ctx-drm_dev);
-out:
return IRQ_HANDLED;
}
@@ -2143,18 +2137,9 @@ static irqreturn_t hdmi_internal_irq_thread(int irq,
void *arg)
HDMI_INTC_FLAG_HPD_PLUG);
}
- mutex_lock(hdata-hdmi_mutex);
- hdata-hpd = hdmi_reg_read(hdata, HDMI_HPD_STATUS);
- if (hdata-powered hdata-hpd) {
- mutex_unlock(hdata-hdmi_mutex);
- goto out;
- }
- mutex_unlock(hdata-hdmi_mutex);
-
if (ctx-drm_dev)
drm_helper_hpd_irq_event(ctx-drm_dev);
-out:
return IRQ_HANDLED;
}
@@ -2287,7 +2272,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
struct device *dev = pdev-dev;
struct exynos_drm_hdmi_context *drm_hdmi_ctx;
struct hdmi_context *hdata;
- struct exynos_drm_hdmi_pdata *pdata;
+ struct s5p_hdmi_platform_data *pdata;
struct resource *res;
int ret;
enum hdmi_type hdmi_type;
@@ -2323,8 +2308,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
hdmi_type = platform_get_device_id(pdev)-driver_data;
hdata-is_v13 = (hdmi_type == HDMI_TYPE13);
- hdata-cfg_hpd = pdata-cfg_hpd;
- hdata-get_hpd = pdata-get_hpd;
+ hdata-hpd_gpio = pdata-hpd_gpio;
hdata-dev = dev;
ret = hdmi_resources_init(hdata);
@@ -2342,11 +2326,17 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
goto err_resource;
}
+ ret = gpio_request(hdata-hpd_gpio, HPD);
+ if (ret) {
+ DRM_ERROR(failed to request HPD gpio\n);
+ goto err_resource;
+ }
+
/* DDC i2c driver */
if (i2c_add_driver(ddc_driver)) {
DRM_ERROR(failed to register ddc i2c driver\n);
ret = -ENOENT;
- goto err_resource;
+ goto err_gpio;
}
hdata-ddc_port = hdmi_ddc;
@@ -2360,32 +2350,31 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
hdata-hdmiphy_port = hdmi_hdmiphy;
- hdata-external_irq = platform_get_irq_byname(pdev, external_irq);
+ hdata-external_irq = gpio_to_irq(hdata-hpd_gpio);
if (hdata-external_irq 0) {
- DRM_ERROR(failed to get platform irq\n);
+ DRM_ERROR(failed to get GPIO external irq\n);
ret = hdata-external_irq;
goto err_hdmiphy;
}
- hdata-internal_irq = platform_get_irq_byname(pdev, internal_irq);
+ hdata-internal_irq =
[PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform data
From: Tomasz Stanislawski t.stanisl...@samsung.com
This patch extends s5p-hdmi platform data by a GPIO identifier for
Hot-Plug-Detection pin.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/media/s5p_hdmi.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 361a751..181642b 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -20,6 +20,7 @@ struct i2c_board_info;
* @hdmiphy_info: template for HDMIPHY I2C device
* @mhl_bus: controller id for MHL control bus
* @mhl_info: template for MHL I2C device
+ * @hpd_gpio: GPIO for Hot-Plug-Detect pin
*
* NULL pointer for *_info fields indicates that
* the corresponding chip is not present
@@ -29,6 +30,7 @@ struct s5p_hdmi_platform_data {
struct i2c_board_info *hdmiphy_info;
int mhl_bus;
struct i2c_board_info *mhl_info;
+ int hpd_gpio;
};
#endif /* S5P_HDMI_H */
--
1.7.0.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 http://vger.kernel.org/majordomo-info.html
[PATCH v1 05/14] drm: exynos: hdmi: turn off HPD interrupt in HDMI chip
From: Tomasz Stanislawski t.stanisl...@samsung.com
The plug/unplug interrupt are handled by a separate interrupt.
So there is no need to replicate this mechanism in HDMI core.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 90dce8c..e3ab840 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1532,12 +1532,9 @@ static void hdmi_conf_reset(struct hdmi_context *hdata)
static void hdmi_conf_init(struct hdmi_context *hdata)
{
- /* enable HPD interrupts */
+ /* disable HPD interrupts */
hdmi_reg_writemask(hdata, HDMI_INTC_CON, 0, HDMI_INTC_EN_GLOBAL |
HDMI_INTC_EN_HPD_PLUG | HDMI_INTC_EN_HPD_UNPLUG);
- mdelay(10);
- hdmi_reg_writemask(hdata, HDMI_INTC_CON, ~0, HDMI_INTC_EN_GLOBAL |
- HDMI_INTC_EN_HPD_PLUG | HDMI_INTC_EN_HPD_UNPLUG);
/* choose HDMI mode */
hdmi_reg_writemask(hdata, HDMI_MODE_SEL,
--
1.7.0.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 http://vger.kernel.org/majordomo-info.html
[PATCH v1 07/14] drm: exynos: hdmi: add support for exynos5 ddc
This patch adds support for exynos5 ddc with device tree enabled.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_ddc.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 7e1051d..ef28779 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -26,29 +26,41 @@ static int s5p_ddc_probe(struct i2c_client *client,
{
hdmi_attach_ddc_client(client);
- dev_info(client-adapter-dev, attached s5p_ddc
- into i2c adapter successfully\n);
+ dev_info(client-adapter-dev,
+ attached %s into i2c adapter successfully\n,
+ client-name);
return 0;
}
static int s5p_ddc_remove(struct i2c_client *client)
{
- dev_info(client-adapter-dev, detached s5p_ddc
- from i2c adapter successfully\n);
+ dev_info(client-adapter-dev,
+ detached %s from i2c adapter successfully\n,
+ client-name);
return 0;
}
static struct i2c_device_id ddc_idtable[] = {
{s5p_ddc, 0},
+ {exynos5-hdmiddc, 0},
{ },
};
+static struct of_device_id hdmiddc_match_types[] = {
+ {
+ .compatible = samsung,exynos5-hdmiddc,
+ }, {
+ /* end node */
+ }
+};
+
struct i2c_driver ddc_driver = {
.driver = {
- .name = s5p_ddc,
+ .name = exynos-hdmiddc,
.owner = THIS_MODULE,
+ .of_match_table = hdmiddc_match_types,
},
.id_table = ddc_idtable,
.probe = s5p_ddc_probe,
--
1.7.0.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 http://vger.kernel.org/majordomo-info.html
[PATCH v1 06/14] drm: exynos: remove drm hdmi platform data struct
This patch removes the drm hdmi platform data structure which is no
longer in use by drm hdmi driver after this patch set get merged. s5p
hdmi platform data structure is used instead.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
include/drm/exynos_drm.h | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
index 0d1c503..8bdd49a 100644
--- a/include/drm/exynos_drm.h
+++ b/include/drm/exynos_drm.h
@@ -254,18 +254,5 @@ struct exynos_drm_common_hdmi_pd {
struct device *mixer_dev;
};
-/**
- * Platform Specific Structure for DRM based HDMI core.
- *
- * @is_v13: set if hdmi version 13 is.
- * @cfg_hpd: function pointer to configure hdmi hotplug detection pin
- * @get_hpd: function pointer to get value of hdmi hotplug detection pin
- */
-struct exynos_drm_hdmi_pdata {
- bool is_v13;
- void (*cfg_hpd)(bool external);
- int (*get_hpd)(void);
-};
-
#endif /* __KERNEL__ */
#endif /* _EXYNOS_DRM_H_ */
--
1.7.0.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 http://vger.kernel.org/majordomo-info.html
[PATCH v1 14/14] drm: exynos: hdmi: remove drm common hdmi platform data struct
exynos-drm-hdmi need context pointers from hdmi and mixer. These
pointers were expected from the plf data. Cleaned this dependency
by exporting i/f which are called by hdmi, mixer driver probes
for setting their context.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 51 +++--
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +
drivers/gpu/drm/exynos/exynos_hdmi.c |3 ++
drivers/gpu/drm/exynos/exynos_mixer.c|3 ++
include/drm/exynos_drm.h | 14
5 files changed, 34 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 0584132..85304c4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -29,6 +29,11 @@
#define get_ctx_from_subdrv(subdrv)container_of(subdrv,\
struct drm_hdmi_context, subdrv);
+/* Common hdmi subdrv needs to access the hdmi and mixer though context.
+* These should be initialied by the repective drivers */
+static struct exynos_drm_hdmi_context *hdmi_ctx;
+static struct exynos_drm_hdmi_context *mixer_ctx;
+
/* these callback points shoud be set by specific drivers. */
static struct exynos_hdmi_ops *hdmi_ops;
static struct exynos_mixer_ops *mixer_ops;
@@ -41,6 +46,18 @@ struct drm_hdmi_context {
boolenabled[MIXER_WIN_NR];
};
+void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx)
+{
+ if (ctx)
+ hdmi_ctx = ctx;
+}
+
+void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx)
+{
+ if (ctx)
+ mixer_ctx = ctx;
+}
+
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops)
{
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -303,46 +320,30 @@ static int hdmi_subdrv_probe(struct drm_device *drm_dev,
{
struct exynos_drm_subdrv *subdrv = to_subdrv(dev);
struct drm_hdmi_context *ctx;
- struct platform_device *pdev = to_platform_device(dev);
- struct exynos_drm_common_hdmi_pd *pd;
DRM_DEBUG_KMS(%s\n, __FILE__);
- pd = pdev-dev.platform_data;
-
- if (!pd) {
- DRM_DEBUG_KMS(platform data is null.\n);
+ if (!hdmi_ctx) {
+ DRM_ERROR(hdmi context not initialized.\n);
return -EFAULT;
}
- if (!pd-hdmi_dev) {
- DRM_DEBUG_KMS(hdmi device is null.\n);
- return -EFAULT;
- }
-
- if (!pd-mixer_dev) {
- DRM_DEBUG_KMS(mixer device is null.\n);
+ if (!mixer_ctx) {
+ DRM_ERROR(mixer context not initialized.\n);
return -EFAULT;
}
ctx = get_ctx_from_subdrv(subdrv);
- ctx-hdmi_ctx = (struct exynos_drm_hdmi_context *)
- to_context(pd-hdmi_dev);
- if (!ctx-hdmi_ctx) {
- DRM_DEBUG_KMS(hdmi context is null.\n);
+ if (!ctx) {
+ DRM_ERROR(no drm hdmi context.\n);
return -EFAULT;
}
- ctx-hdmi_ctx-drm_dev = drm_dev;
-
- ctx-mixer_ctx = (struct exynos_drm_hdmi_context *)
- to_context(pd-mixer_dev);
- if (!ctx-mixer_ctx) {
- DRM_DEBUG_KMS(mixer context is null.\n);
- return -EFAULT;
- }
+ ctx-hdmi_ctx = hdmi_ctx;
+ ctx-mixer_ctx = mixer_ctx;
+ ctx-hdmi_ctx-drm_dev = drm_dev;
ctx-mixer_ctx-drm_dev = drm_dev;
return 0;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index d9f9e9f..2da5ffd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -73,6 +73,8 @@ struct exynos_mixer_ops {
void (*win_disable)(void *ctx, int zpos);
};
+void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx);
+void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5caf49f..e6b784d 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2454,6 +2454,9 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
goto err_free_irq;
}
+ /* Attach HDMI Driver to common hdmi. */
+ exynos_hdmi_drv_attach(drm_hdmi_ctx);
+
/* register specific callbacks to common hdmi. */
exynos_hdmi_ops_register(hdmi_ops);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 39d2b95..1a319e4 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1171,6 +1171,9 @@ static int __devinit mixer_probe(struct platform_device
*pdev)
[PATCH v1 11/14] drm: exynos: hdmi: add support for exynos5 mixer
This patch adds support for exynos5 mixer with device tree enabled.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Fahad Kunnathadi faha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c | 49 +++--
drivers/gpu/drm/exynos/regs-mixer.h |3 ++
2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 1677345..39d2b95 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -481,6 +481,18 @@ static void vp_video_buffer(struct mixer_context *ctx, int
win)
vp_regs_dump(ctx);
}
+static void mixer_layer_update(struct mixer_context *ctx)
+{
+ struct mixer_resources *res = ctx-mixer_res;
+ u32 val;
+
+ val = mixer_reg_read(res, MXR_CFG);
+
+ /* allow one update per vsync only */
+ if (!(val MXR_CFG_LAYER_UPDATE_COUNT_MASK))
+ mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
+}
+
static void mixer_graph_buffer(struct mixer_context *ctx, int win)
{
struct mixer_resources *res = ctx-mixer_res;
@@ -561,6 +573,11 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
mixer_cfg_scan(ctx, win_data-mode_height);
mixer_cfg_rgb_fmt(ctx, win_data-mode_height);
mixer_cfg_layer(ctx, win, true);
+
+ /* layer update mandatory for mixer 16.0.33.0 */
+ if (ctx-mxr_ver == MXR_VER_16_0_33_0)
+ mixer_layer_update(ctx);
+
mixer_run(ctx);
mixer_vsync_set_update(ctx, true);
@@ -1065,6 +1082,11 @@ fail:
return ret;
}
+static struct mixer_drv_data exynos5_mxr_drv_data = {
+ .version = MXR_VER_16_0_33_0,
+ .is_vp_enabled = 0,
+};
+
static struct mixer_drv_data exynos4_mxr_drv_data = {
.version = MXR_VER_0_0_0_16,
.is_vp_enabled = 1,
@@ -1075,6 +1097,18 @@ static struct platform_device_id mixer_driver_types[] = {
.name = s5p-mixer,
.driver_data= (unsigned long)exynos4_mxr_drv_data,
}, {
+ .name = exynos5-mixer,
+ .driver_data= (unsigned long)exynos5_mxr_drv_data,
+ }, {
+ /* end node */
+ }
+};
+
+static struct of_device_id mixer_match_types[] = {
+ {
+ .compatible = samsung,exynos5-mixer,
+ .data = exynos5_mxr_drv_data,
+ }, {
/* end node */
}
};
@@ -1104,8 +1138,16 @@ static int __devinit mixer_probe(struct platform_device
*pdev)
mutex_init(ctx-mixer_mutex);
- drv = (struct mixer_drv_data *)platform_get_device_id(
- pdev)-driver_data;
+ if (dev-of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(of_match_ptr(mixer_match_types),
+ pdev-dev.of_node);
+ drv = match-data;
+ } else {
+ drv = (struct mixer_drv_data *)
+ platform_get_device_id(pdev)-driver_data;
+ }
+
ctx-dev = pdev-dev;
drm_hdmi_ctx-ctx = (void *)ctx;
ctx-vp_enabled = drv-is_vp_enabled;
@@ -1167,9 +1209,10 @@ static SIMPLE_DEV_PM_OPS(mixer_pm_ops, mixer_suspend,
NULL);
struct platform_driver mixer_driver = {
.driver = {
- .name = s5p-mixer,
+ .name = exynos-mixer,
.owner = THIS_MODULE,
.pm = mixer_pm_ops,
+ .of_match_table = mixer_match_types,
},
.probe = mixer_probe,
.remove = __devexit_p(mixer_remove),
diff --git a/drivers/gpu/drm/exynos/regs-mixer.h
b/drivers/gpu/drm/exynos/regs-mixer.h
index fd2f4d1..5d8dbc0 100644
--- a/drivers/gpu/drm/exynos/regs-mixer.h
+++ b/drivers/gpu/drm/exynos/regs-mixer.h
@@ -69,6 +69,7 @@
(((val) (low_bit)) MXR_MASK(high_bit, low_bit))
/* bits for MXR_STATUS */
+#define MXR_STATUS_SOFT_RESET (1 8)
#define MXR_STATUS_16_BURST(1 7)
#define MXR_STATUS_BURST_MASK (1 7)
#define MXR_STATUS_BIG_ENDIAN (1 3)
@@ -77,6 +78,8 @@
#define MXR_STATUS_REG_RUN (1 0)
/* bits for MXR_CFG */
+#define MXR_CFG_LAYER_UPDATE (1 31)
+#define MXR_CFG_LAYER_UPDATE_COUNT_MASK (3 29)
#define MXR_CFG_RGB601_0_255 (0 9)
#define MXR_CFG_RGB601_16_235 (1 9)
#define MXR_CFG_RGB709_0_255 (2 9)
--
1.7.0.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 http://vger.kernel.org/majordomo-info.html
[PATCH v1 12/14] drm: exynos: hdmi: replace is_v13 with version check in hdmi
This patch removed the is_v13 variable from the hdmi driver context.
It is replaced with condition check for the hdmi version. This cleans
the way for handling further hdmi versions.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 40 +-
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index e3ab840..89e798b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -47,6 +47,11 @@
#define MAX_HEIGHT 1080
#define get_hdmi_context(dev) platform_get_drvdata(to_platform_device(dev))
+enum hdmi_type {
+ HDMI_TYPE13,
+ HDMI_TYPE14,
+};
+
struct hdmi_resources {
struct clk *hdmi;
struct clk *sclk_hdmi;
@@ -62,7 +67,6 @@ struct hdmi_context {
struct drm_device *drm_dev;
boolhpd;
boolpowered;
- boolis_v13;
booldvi_mode;
struct mutexhdmi_mutex;
@@ -80,6 +84,8 @@ struct hdmi_context {
void*parent_ctx;
int hpd_gpio;
+
+ enum hdmi_type type;
};
/* HDMI Version 1.3 */
@@ -1211,7 +1217,7 @@ static void hdmi_v14_regs_dump(struct hdmi_context
*hdata, char *prefix)
static void hdmi_regs_dump(struct hdmi_context *hdata, char *prefix)
{
- if (hdata-is_v13)
+ if (hdata-type == HDMI_TYPE13)
hdmi_v13_regs_dump(hdata, prefix);
else
hdmi_v14_regs_dump(hdata, prefix);
@@ -1252,7 +1258,7 @@ static int hdmi_v14_conf_index(struct drm_display_mode
*mode)
static int hdmi_conf_index(struct hdmi_context *hdata,
struct drm_display_mode *mode)
{
- if (hdata-is_v13)
+ if (hdata-type == HDMI_TYPE13)
return hdmi_v13_conf_index(mode);
return hdmi_v14_conf_index(mode);
@@ -1348,7 +1354,7 @@ static int hdmi_check_timing(void *ctx, void *timing)
check_timing-yres, check_timing-refresh,
check_timing-vmode);
- if (hdata-is_v13)
+ if (hdata-type == HDMI_TYPE13)
return hdmi_v13_check_timing(check_timing);
else
return hdmi_v14_check_timing(check_timing);
@@ -1414,7 +1420,7 @@ static void hdmi_reg_acr(struct hdmi_context *hdata, u8
*acr)
hdmi_reg_writeb(hdata, HDMI_ACR_CTS1, acr[2]);
hdmi_reg_writeb(hdata, HDMI_ACR_CTS2, acr[1]);
- if (hdata-is_v13)
+ if (hdata-type == HDMI_TYPE13)
hdmi_reg_writeb(hdata, HDMI_V13_ACR_CON, 4);
else
hdmi_reg_writeb(hdata, HDMI_ACR_CON, 4);
@@ -1518,7 +1524,7 @@ static void hdmi_conf_reset(struct hdmi_context *hdata)
{
u32 reg;
- if (hdata-is_v13)
+ if (hdata-type == HDMI_TYPE13)
reg = HDMI_V13_CORE_RSTOUT;
else
reg = HDMI_CORE_RSTOUT;
@@ -1550,7 +1556,7 @@ static void hdmi_conf_init(struct hdmi_context *hdata)
HDMI_VID_PREAMBLE_DIS | HDMI_GUARD_BAND_DIS);
}
- if (hdata-is_v13) {
+ if (hdata-type == HDMI_TYPE13) {
/* choose bluescreen (fecal) color */
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_0, 0x12);
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_1, 0x34);
@@ -1832,7 +1838,7 @@ static void hdmi_v14_timing_apply(struct hdmi_context
*hdata)
static void hdmi_timing_apply(struct hdmi_context *hdata)
{
- if (hdata-is_v13)
+ if (hdata-type == HDMI_TYPE13)
hdmi_v13_timing_apply(hdata);
else
hdmi_v14_timing_apply(hdata);
@@ -1854,7 +1860,7 @@ static void hdmiphy_conf_reset(struct hdmi_context *hdata)
if (hdata-hdmiphy_port)
i2c_master_send(hdata-hdmiphy_port, buffer, 2);
- if (hdata-is_v13)
+ if (hdata-type == HDMI_TYPE13)
reg = HDMI_V13_PHY_RSTOUT;
else
reg = HDMI_PHY_RSTOUT;
@@ -1881,7 +1887,7 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata)
}
/* pixel clock */
- if (hdata-is_v13)
+ if (hdata-type == HDMI_TYPE13)
hdmiphy_data = hdmi_v13_confs[hdata-cur_conf].hdmiphy_data;
else
hdmiphy_data = hdmi_confs[hdata-cur_conf].hdmiphy_data;
@@ -1949,7 +1955,7 @@ static void hdmi_mode_fixup(void *ctx, struct
drm_connector *connector,
drm_mode_set_crtcinfo(adjusted_mode, 0);
- if (hdata-is_v13)
+ if (hdata-type == HDMI_TYPE13)
index = hdmi_v13_conf_index(adjusted_mode);
else
index = hdmi_v14_conf_index(adjusted_mode);
[PATCH v1 10/14] drm: exynos: hdmi: add support to disable video processor in mixer
This patch adds support for disabling the video processor code based
on the platform type. This is done based on a field in the mixer driver
data which changes with the platform variant.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c | 151 +
1 files changed, 98 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e312fb1..1677345 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -83,6 +83,7 @@ struct mixer_context {
int pipe;
boolinterlace;
boolpowered;
+ boolvp_enabled;
u32 int_en;
struct mutexmixer_mutex;
@@ -93,6 +94,7 @@ struct mixer_context {
struct mixer_drv_data {
enum mixer_version_id version;
+ boolis_vp_enabled;
};
static const u8 filter_y_horiz_tap8[] = {
@@ -261,7 +263,8 @@ static void mixer_vsync_set_update(struct mixer_context
*ctx, bool enable)
mixer_reg_writemask(res, MXR_STATUS, enable ?
MXR_STATUS_SYNC_ENABLE : 0, MXR_STATUS_SYNC_ENABLE);
- vp_reg_write(res, VP_SHADOW_UPDATE, enable ?
+ if (ctx-vp_enabled)
+ vp_reg_write(res, VP_SHADOW_UPDATE, enable ?
VP_SHADOW_UPDATE_ENABLE : 0);
}
@@ -343,8 +346,11 @@ static void mixer_cfg_layer(struct mixer_context *ctx, int
win, bool enable)
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
break;
case 2:
- vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
- mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_VP_ENABLE);
+ if (ctx-vp_enabled) {
+ vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
+ mixer_reg_writemask(res, MXR_CFG, val,
+ MXR_CFG_VP_ENABLE);
+ }
break;
}
}
@@ -602,7 +608,8 @@ static void mixer_win_reset(struct mixer_context *ctx)
*/
val = MXR_LAYER_CFG_GRP1_VAL(3);
val |= MXR_LAYER_CFG_GRP0_VAL(2);
- val |= MXR_LAYER_CFG_VP_VAL(1);
+ if (ctx-vp_enabled)
+ val |= MXR_LAYER_CFG_VP_VAL(1);
mixer_reg_write(res, MXR_LAYER_CFG, val);
/* setting background color */
@@ -625,14 +632,17 @@ static void mixer_win_reset(struct mixer_context *ctx)
val = MXR_GRP_CFG_ALPHA_VAL(0);
mixer_reg_write(res, MXR_VIDEO_CFG, val);
- /* configuration of Video Processor Registers */
- vp_win_reset(ctx);
- vp_default_filter(res);
+ if (ctx-vp_enabled) {
+ /* configuration of Video Processor Registers */
+ vp_win_reset(ctx);
+ vp_default_filter(res);
+ }
/* disable all layers */
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_GRP0_ENABLE);
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_GRP1_ENABLE);
- mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_VP_ENABLE);
+ if (ctx-vp_enabled)
+ mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_VP_ENABLE);
mixer_vsync_set_update(ctx, true);
spin_unlock_irqrestore(res-reg_slock, flags);
@@ -655,8 +665,10 @@ static void mixer_poweron(struct mixer_context *ctx)
pm_runtime_get_sync(ctx-dev);
clk_enable(res-mixer);
- clk_enable(res-vp);
- clk_enable(res-sclk_mixer);
+ if (ctx-vp_enabled) {
+ clk_enable(res-vp);
+ clk_enable(res-sclk_mixer);
+ }
mixer_reg_write(res, MXR_INT_EN, ctx-int_en);
mixer_win_reset(ctx);
@@ -676,8 +688,10 @@ static void mixer_poweroff(struct mixer_context *ctx)
ctx-int_en = mixer_reg_read(res, MXR_INT_EN);
clk_disable(res-mixer);
- clk_disable(res-vp);
- clk_disable(res-sclk_mixer);
+ if (ctx-vp_enabled) {
+ clk_disable(res-vp);
+ clk_disable(res-sclk_mixer);
+ }
pm_runtime_put_sync(ctx-dev);
@@ -810,7 +824,7 @@ static void mixer_win_commit(void *ctx, int win)
DRM_DEBUG_KMS([%d] %s, win: %d\n, __LINE__, __func__, win);
- if (win 1)
+ if (win 1 mixer_ctx-vp_enabled)
vp_video_buffer(mixer_ctx, win);
else
mixer_graph_buffer(mixer_ctx, win);
@@ -946,39 +960,20 @@ static int __devinit mixer_resources_init(struct
exynos_drm_hdmi_context *ctx,
ret = -ENODEV;
goto fail;
}
- mixer_res-vp = clk_get(dev, vp);
- if (IS_ERR_OR_NULL(mixer_res-vp)) {
- dev_err(dev, failed to get clock 'vp'\n);
- ret = -ENODEV;
- goto fail;
- }
- mixer_res-sclk_mixer =
[PATCH v1 08/14] drm: exynos: hdmi: add support for exynos5 hdmiphy
This patch adds support for exynos5 hdmi phy with device tree enabled.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmiphy.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
index 9fe2995..a33073b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
@@ -42,13 +42,23 @@ static int hdmiphy_remove(struct i2c_client *client)
static const struct i2c_device_id hdmiphy_id[] = {
{ s5p_hdmiphy, 0 },
+ { exynos5-hdmiphy, 0 },
{ },
};
+static struct of_device_id hdmiphy_match_types[] = {
+ {
+ .compatible = samsung,exynos5-hdmiphy,
+ }, {
+ /* end node */
+ }
+};
+
struct i2c_driver hdmiphy_driver = {
.driver = {
- .name = s5p-hdmiphy,
+ .name = exynos-hdmiphy,
.owner = THIS_MODULE,
+ .of_match_table = hdmiphy_match_types,
},
.id_table = hdmiphy_id,
.probe = hdmiphy_probe,
--
1.7.0.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 http://vger.kernel.org/majordomo-info.html
[PATCH v1 09/14] drm: exynos: hdmi: add support for platform variants for mixer
This patch adds the support for multiple mixer versions avaialble in
various platform variants. Version is passed as a driver data field
instead of paltform data.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 8a43ee1..e312fb1 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -73,6 +73,11 @@ struct mixer_resources {
struct clk *sclk_dac;
};
+enum mixer_version_id {
+ MXR_VER_0_0_0_16,
+ MXR_VER_16_0_33_0,
+};
+
struct mixer_context {
struct device *dev;
int pipe;
@@ -83,6 +88,11 @@ struct mixer_context {
struct mutexmixer_mutex;
struct mixer_resources mixer_res;
struct hdmi_win_datawin_data[MIXER_WIN_NR];
+ enum mixer_version_id mxr_ver;
+};
+
+struct mixer_drv_data {
+ enum mixer_version_id version;
};
static const u8 filter_y_horiz_tap8[] = {
@@ -1023,11 +1033,25 @@ fail:
return ret;
}
+static struct mixer_drv_data exynos4_mxr_drv_data = {
+ .version = MXR_VER_0_0_0_16,
+};
+
+static struct platform_device_id mixer_driver_types[] = {
+ {
+ .name = s5p-mixer,
+ .driver_data= (unsigned long)exynos4_mxr_drv_data,
+ }, {
+ /* end node */
+ }
+};
+
static int __devinit mixer_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
struct exynos_drm_hdmi_context *drm_hdmi_ctx;
struct mixer_context *ctx;
+ struct mixer_drv_data *drv;
int ret;
dev_info(dev, probe start\n);
@@ -1047,8 +1071,11 @@ static int __devinit mixer_probe(struct platform_device
*pdev)
mutex_init(ctx-mixer_mutex);
+ drv = (struct mixer_drv_data *)platform_get_device_id(
+ pdev)-driver_data;
ctx-dev = pdev-dev;
drm_hdmi_ctx-ctx = (void *)ctx;
+ ctx-mxr_ver = drv-version;
platform_set_drvdata(pdev, drm_hdmi_ctx);
@@ -1101,4 +1128,5 @@ struct platform_driver mixer_driver = {
},
.probe = mixer_probe,
.remove = __devexit_p(mixer_remove),
+ .id_table = mixer_driver_types,
};
--
1.7.0.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 http://vger.kernel.org/majordomo-info.html
[PATCH v1 13/14] drm: exynos: hdmi: add support for exynos5 hdmi
This patch adds support for exynos5 hdmi with device tree enabled.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 83 --
1 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 89e798b..5caf49f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -32,6 +32,9 @@
#include linux/pm_runtime.h
#include linux/clk.h
#include linux/regulator/consumer.h
+#include linux/io.h
+#include linux/of_gpio.h
+#include plat/gpio-cfg.h
#include drm/exynos_drm.h
@@ -2250,6 +2253,41 @@ void hdmi_attach_hdmiphy_client(struct i2c_client
*hdmiphy)
hdmi_hdmiphy = hdmiphy;
}
+#ifdef CONFIG_OF
+static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
+ (struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ struct s5p_hdmi_platform_data *pd;
+ enum of_gpio_flags flags;
+ u32 value;
+
+ pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ DRM_ERROR(memory allocation for pdata failed\n);
+ goto err_data;
+ }
+
+ if (!of_find_property(np, hpd-gpio, value)) {
+ DRM_ERROR(no hpd gpio property found\n);
+ goto err_data;
+ }
+
+ pd-hpd_gpio = of_get_named_gpio_flags(np, hpd-gpio, 0, flags);
+
+ return pd;
+
+err_data:
+ return NULL;
+}
+#else
+static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
+ (struct device *dev)
+{
+ return NULL;
+}
+#endif
+
static struct platform_device_id hdmi_driver_types[] = {
{
.name = s5pv210-hdmi,
@@ -2259,7 +2297,19 @@ static struct platform_device_id hdmi_driver_types[] = {
.driver_data= HDMI_TYPE13,
}, {
.name = exynos4-hdmi14,
- .driver_data= HDMI_TYPE14,
+ .driver_data= HDMI_TYPE14,
+ }, {
+ .name = exynos5-hdmi,
+ .driver_data= HDMI_TYPE14,
+ }, {
+ /* end node */
+ }
+};
+
+static struct of_device_id hdmi_match_types[] = {
+ {
+ .compatible = samsung,exynos5-hdmi,
+ .data = (void *)HDMI_TYPE14,
}, {
/* end node */
}
@@ -2276,7 +2326,16 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
DRM_DEBUG_KMS([%d]\n, __LINE__);
- pdata = pdev-dev.platform_data;
+ if (pdev-dev.of_node) {
+ pdata = drm_hdmi_dt_parse_pdata(dev);
+ if (IS_ERR(pdata)) {
+ DRM_ERROR(failed to parse dt\n);
+ return PTR_ERR(pdata);
+ }
+ } else {
+ pdata = pdev-dev.platform_data;
+ }
+
if (!pdata) {
DRM_ERROR(no platform data specified\n);
return -EINVAL;
@@ -2303,18 +2362,33 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, drm_hdmi_ctx);
- hdata-type = (enum hdmi_type)platform_get_device_id
+ if (dev-of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(of_match_ptr(hdmi_match_types),
+ pdev-dev.of_node);
+ hdata-type = (enum hdmi_type)match-data;
+ } else {
+ hdata-type = (enum hdmi_type)platform_get_device_id
(pdev)-driver_data;
+ }
+
hdata-hpd_gpio = pdata-hpd_gpio;
hdata-dev = dev;
ret = hdmi_resources_init(hdata);
+
if (ret) {
ret = -EINVAL;
+ DRM_ERROR(hdmi_resources_init failed\n);
goto err_data;
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ DRM_ERROR(failed to find registers\n);
+ ret = -ENOENT;
+ goto err_resource;
+ }
hdata-regs = devm_request_and_ioremap(pdev-dev, res);
if (!hdata-regs) {
@@ -2462,8 +2536,9 @@ struct platform_driver hdmi_driver = {
.remove = __devexit_p(hdmi_remove),
.id_table = hdmi_driver_types,
.driver = {
- .name = exynos4-hdmi,
+ .name = exynos-hdmi,
.owner = THIS_MODULE,
.pm = hdmi_pm_ops,
+ .of_match_table = hdmi_match_types,
},
};
--
1.7.0.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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform data
Hi Mr. Tomasz, Mr. Park, list,
First patch in the following set belongs to s5p-media, rest to exynos-drm.
Please review the media patch so that It can be merged for mainline.
regards,
Rahul Sharma
On Thu, Oct 4, 2012 at 9:12 PM, Rahul Sharma rahul.sha...@samsung.com wrote:
From: Tomasz Stanislawski t.stanisl...@samsung.com
This patch extends s5p-hdmi platform data by a GPIO identifier for
Hot-Plug-Detection pin.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/media/s5p_hdmi.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 361a751..181642b 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -20,6 +20,7 @@ struct i2c_board_info;
* @hdmiphy_info: template for HDMIPHY I2C device
* @mhl_bus: controller id for MHL control bus
* @mhl_info: template for MHL I2C device
+ * @hpd_gpio: GPIO for Hot-Plug-Detect pin
*
* NULL pointer for *_info fields indicates that
* the corresponding chip is not present
@@ -29,6 +30,7 @@ struct s5p_hdmi_platform_data {
struct i2c_board_info *hdmiphy_info;
int mhl_bus;
struct i2c_board_info *mhl_info;
+ int hpd_gpio;
};
#endif /* S5P_HDMI_H */
--
1.7.0.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
RE: [PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform data
Hello Media guys,
This is dependent of exynos drm patch set to be merged to mainline so if
there is no problem then please, give me ack so that I can merge this patch
with exynos drm patch set.
Thanks,
Inki Dae
-Original Message-
From: RAHUL SHARMA [mailto:rahul.sha...@samsung.com]
Sent: Thursday, October 04, 2012 4:40 PM
To: Tomasz Stanislawski; Kyungmin Park; linux-arm-
ker...@lists.infradead.org; linux-media@vger.kernel.org
Cc: In-Ki Dae; SUNIL JOSHI; r.sh.o...@gmail.com
Subject: Re: [PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform
data
Hi Mr. Tomasz, Mr. Park, list,
First patch in the following set belongs to s5p-media, rest to exynos-drm.
Please review the media patch so that It can be merged for mainline.
regards,
Rahul Sharma
On Thu, Oct 4, 2012 at 9:12 PM, Rahul Sharma rahul.sha...@samsung.com
wrote:
From: Tomasz Stanislawski t.stanisl...@samsung.com
This patch extends s5p-hdmi platform data by a GPIO identifier for
Hot-Plug-Detection pin.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/media/s5p_hdmi.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 361a751..181642b 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -20,6 +20,7 @@ struct i2c_board_info;
* @hdmiphy_info: template for HDMIPHY I2C device
* @mhl_bus: controller id for MHL control bus
* @mhl_info: template for MHL I2C device
+ * @hpd_gpio: GPIO for Hot-Plug-Detect pin
*
* NULL pointer for *_info fields indicates that
* the corresponding chip is not present
@@ -29,6 +30,7 @@ struct s5p_hdmi_platform_data {
struct i2c_board_info *hdmiphy_info;
int mhl_bus;
struct i2c_board_info *mhl_info;
+ int hpd_gpio;
};
#endif /* S5P_HDMI_H */
--
1.7.0.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: vpif: Add return code check at vb2_queue_init()
Hi Prabhakar,
I think this introduces a memory leak, see my comments below.
On Wed 3 October 2012 15:42:29 Prabhakar wrote:
From: Lad, Prabhakar prabhakar@ti.com
from commit with id 896f38f582730a19eb49677105b4fe4c0270b82e
it's mandatory to check the return code of vb2_queue_init().
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/davinci/vpif_capture.c |8 ++--
drivers/media/platform/davinci/vpif_display.c |8 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 83b80ba..3521725 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -976,6 +976,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
struct common_obj *common;
u8 index = 0;
struct vb2_queue *q;
+ int ret;
vpif_dbg(2, debug, vpif_reqbufs\n);
@@ -1015,8 +1016,11 @@ static int vpif_reqbufs(struct file *file, void *priv,
q-mem_ops = vb2_dma_contig_memops;
q-buf_struct_size = sizeof(struct vpif_cap_buffer);
- vb2_queue_init(q);
-
+ ret = vb2_queue_init(q);
+ if (ret) {
+ vpif_err(vpif_capture: vb2_queue_init() failed\n);
I think you need to call vb2_dma_contig_cleanup_ctx(common-alloc_ctx); here
to prevent a memory leak.
+ return ret;
+ }
/* Set io allowed member of file handle to TRUE */
fh-io_allowed[index] = 1;
/* Increment io usrs member of channel object to 1 */
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index ae8329d..84cee9d 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -936,6 +936,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
enum v4l2_field field;
struct vb2_queue *q;
u8 index = 0;
+ int ret;
/* This file handle has not initialized the channel,
It is not allowed to do settings */
@@ -981,8 +982,11 @@ static int vpif_reqbufs(struct file *file, void *priv,
q-mem_ops = vb2_dma_contig_memops;
q-buf_struct_size = sizeof(struct vpif_disp_buffer);
- vb2_queue_init(q);
-
+ ret = vb2_queue_init(q);
+ if (ret) {
+ vpif_err(vpif_display: vb2_queue_init() failed\n);
Ditto.
+ return ret;
+ }
/* Set io allowed member of file handle to TRUE */
fh-io_allowed[index] = 1;
/* Increment io usrs member of channel object to 1 */
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 v2] media: davinci: vpif: set device capabilities
On Tue 25 September 2012 16:21:55 Prabhakar wrote:
From: Lad, Prabhakar prabhakar@ti.com
set device_caps and also change the driver and
bus_info to proper values as per standard.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
---
Changes for v2:
1: Change the bus_info and driver to proper values,
pointed by Hans.
drivers/media/platform/davinci/vpif_capture.c |9 ++---
drivers/media/platform/davinci/vpif_display.c |9 ++---
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 482..cb70e98 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1630,9 +1630,12 @@ static int vpif_querycap(struct file *file, void
*priv,
{
struct vpif_capture_config *config = vpif_dev-platform_data;
- cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
- strlcpy(cap-driver, vpif capture, sizeof(cap-driver));
- strlcpy(cap-bus_info, VPIF Platform, sizeof(cap-bus_info));
+ cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
+ V4L2_CAP_READWRITE;
Why add READWRITE? There is no read/write support in these drivers.
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
+ snprintf(cap-driver, sizeof(cap-driver), %s, dev_name(vpif_dev));
+ snprintf(cap-bus_info, sizeof(cap-bus_info), platform:%s,
+ dev_name(vpif_dev));
strlcpy(cap-card, config-card_name, sizeof(cap-card));
return 0;
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index d94b8a2..411b547 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -827,9 +827,12 @@ static int vpif_querycap(struct file *file, void *priv,
{
struct vpif_display_config *config = vpif_dev-platform_data;
- cap-capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
- strlcpy(cap-driver, vpif display, sizeof(cap-driver));
- strlcpy(cap-bus_info, Platform, sizeof(cap-bus_info));
+ cap-device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING |
+ V4L2_CAP_READWRITE;
Ditto.
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
+ snprintf(cap-driver, sizeof(cap-driver), %s, dev_name(vpif_dev));
+ snprintf(cap-bus_info, sizeof(cap-bus_info), platform:%s,
+ dev_name(vpif_dev));
strlcpy(cap-card, config-card_name, sizeof(cap-card));
return 0;
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: [RFC PATCH 1/3] s5p-g2d: fix compiler warning
On 10/04/2012 08:43 AM, Hans Verkuil wrote: On Wed October 3 2012 12:16:48 Sylwester Nawrocki wrote: On 10/02/2012 10:57 AM, Hans Verkuil wrote: drivers/media/platform/s5p-g2d/g2d.c:535:2: warning: passing argument 3 of 'vidioc_try_crop' discards 'const' qualifier from pointer target type [enabled by default] drivers/media/platform/s5p-g2d/g2d.c:510:12: note: expected 'struct v4l2_crop *' but argument is of type 'const struct v4l2_crop *' This is fall-out from this commit: commit 4f996594ceaf6c3f9bc42b40c40b0f7f87b79c86 Author: Hans Verkuil hans.verk...@cisco.com Date: Wed Sep 5 05:10:48 2012 -0300 [media] v4l2: make vidioc_s_crop const Signed-off-by: Hans Verkuil hans.verk...@cisco.com Aplied, thanks. Just to be clear, you're taking care of these s5p patches through your tree, right? Yes, from now on I will be picking all s5p/exynos patches from LMML and sending it through my tree, were appropriate. In fact I have been doing it already in most part. Same with other Samsung media drivers, like camera sensors. I'll look what needs to be changed at the MAINTAINERS file. This is to lower volume of patches that needs to be handled by Mauro. Please Cc me on any s5p/Exynos patches. -- Thanks, 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
[PATCH v2] media: davinci: vpif: Add return code check at vb2_queue_init()
From: Lad, Prabhakar prabhakar@ti.com
from commit with id 896f38f582730a19eb49677105b4fe4c0270b82e
it's mandatory to check the return code of vb2_queue_init().
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
---
Changes for v2:
1: Added vb2_dma_contig_cleanup_ctx() on failure of
vb2_queue_init() to avoid memory leak, pointed by Hans.
drivers/media/platform/davinci/vpif_capture.c |9 +++--
drivers/media/platform/davinci/vpif_display.c |9 +++--
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 83b80ba..cabd5a2 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -976,6 +976,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
struct common_obj *common;
u8 index = 0;
struct vb2_queue *q;
+ int ret;
vpif_dbg(2, debug, vpif_reqbufs\n);
@@ -1015,8 +1016,12 @@ static int vpif_reqbufs(struct file *file, void *priv,
q-mem_ops = vb2_dma_contig_memops;
q-buf_struct_size = sizeof(struct vpif_cap_buffer);
- vb2_queue_init(q);
-
+ ret = vb2_queue_init(q);
+ if (ret) {
+ vpif_err(vpif_capture: vb2_queue_init() failed\n);
+ vb2_dma_contig_cleanup_ctx(common-alloc_ctx);
+ return ret;
+ }
/* Set io allowed member of file handle to TRUE */
fh-io_allowed[index] = 1;
/* Increment io usrs member of channel object to 1 */
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index ae8329d..7f20ca5 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -936,6 +936,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
enum v4l2_field field;
struct vb2_queue *q;
u8 index = 0;
+ int ret;
/* This file handle has not initialized the channel,
It is not allowed to do settings */
@@ -981,8 +982,12 @@ static int vpif_reqbufs(struct file *file, void *priv,
q-mem_ops = vb2_dma_contig_memops;
q-buf_struct_size = sizeof(struct vpif_disp_buffer);
- vb2_queue_init(q);
-
+ ret = vb2_queue_init(q);
+ if (ret) {
+ vpif_err(vpif_display: vb2_queue_init() failed\n);
+ vb2_dma_contig_cleanup_ctx(common-alloc_ctx);
+ return ret;
+ }
/* Set io allowed member of file handle to TRUE */
fh-io_allowed[index] = 1;
/* Increment io usrs member of channel object to 1 */
--
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
[PATCH v3] media: davinci: vpif: set device capabilities
From: Lad, Prabhakar prabhakar@ti.com
set device_caps and also change the driver and
bus_info to proper values as per standard.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
---
Changes for v3:
1: Removed READWRITE flag for device_caps pointed by Hans.
Changes for v2:
1: Change the bus_info and driver to proper values,
pointed by Hans.
drivers/media/platform/davinci/vpif_capture.c |8 +---
drivers/media/platform/davinci/vpif_display.c |8 +---
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index cabd5a2..fcabc02 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1635,9 +1635,11 @@ static int vpif_querycap(struct file *file, void *priv,
{
struct vpif_capture_config *config = vpif_dev-platform_data;
- cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
- strlcpy(cap-driver, vpif capture, sizeof(cap-driver));
- strlcpy(cap-bus_info, VPIF Platform, sizeof(cap-bus_info));
+ cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
+ snprintf(cap-driver, sizeof(cap-driver), %s, dev_name(vpif_dev));
+ snprintf(cap-bus_info, sizeof(cap-bus_info), platform:%s,
+dev_name(vpif_dev));
strlcpy(cap-card, config-card_name, sizeof(cap-card));
return 0;
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 7f20ca5..b716fbd 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -827,9 +827,11 @@ static int vpif_querycap(struct file *file, void *priv,
{
struct vpif_display_config *config = vpif_dev-platform_data;
- cap-capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
- strlcpy(cap-driver, vpif display, sizeof(cap-driver));
- strlcpy(cap-bus_info, Platform, sizeof(cap-bus_info));
+ cap-device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
+ snprintf(cap-driver, sizeof(cap-driver), %s, dev_name(vpif_dev));
+ snprintf(cap-bus_info, sizeof(cap-bus_info), platform:%s,
+dev_name(vpif_dev));
strlcpy(cap-card, config-card_name, sizeof(cap-card));
return 0;
--
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
[GIT PULL FOR v3.7] Fix fsl-viu compiler warning
Hi Mauro, Here is a quick fix for a compiler warning due to the constifying of vidioc_s_fbuf. Regards, Hans The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4: em28xx: regression fix: use DRX-K sync firmware requests on em28xx (2012-10-02 17:15:22 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git const2 for you to fetch changes up to c6419c4e74aa986d234f2ce8e13ea3c9d53f1015: fsl-viu: fix compiler warning. (2012-10-04 08:46:00 +0200) Hans Verkuil (1): fsl-viu: fix compiler warning. drivers/media/platform/fsl-viu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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] media: davinci: vpif: Add return code check at vb2_queue_init()
On Thu 4 October 2012 11:29:57 Prabhakar wrote:
From: Lad, Prabhakar prabhakar@ti.com
from commit with id 896f38f582730a19eb49677105b4fe4c0270b82e
it's mandatory to check the return code of vb2_queue_init().
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
---
Changes for v2:
1: Added vb2_dma_contig_cleanup_ctx() on failure of
vb2_queue_init() to avoid memory leak, pointed by Hans.
drivers/media/platform/davinci/vpif_capture.c |9 +++--
drivers/media/platform/davinci/vpif_display.c |9 +++--
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 83b80ba..cabd5a2 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -976,6 +976,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
struct common_obj *common;
u8 index = 0;
struct vb2_queue *q;
+ int ret;
vpif_dbg(2, debug, vpif_reqbufs\n);
@@ -1015,8 +1016,12 @@ static int vpif_reqbufs(struct file *file, void *priv,
q-mem_ops = vb2_dma_contig_memops;
q-buf_struct_size = sizeof(struct vpif_cap_buffer);
- vb2_queue_init(q);
-
+ ret = vb2_queue_init(q);
+ if (ret) {
+ vpif_err(vpif_capture: vb2_queue_init() failed\n);
+ vb2_dma_contig_cleanup_ctx(common-alloc_ctx);
+ return ret;
+ }
/* Set io allowed member of file handle to TRUE */
fh-io_allowed[index] = 1;
/* Increment io usrs member of channel object to 1 */
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index ae8329d..7f20ca5 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -936,6 +936,7 @@ static int vpif_reqbufs(struct file *file, void *priv,
enum v4l2_field field;
struct vb2_queue *q;
u8 index = 0;
+ int ret;
/* This file handle has not initialized the channel,
It is not allowed to do settings */
@@ -981,8 +982,12 @@ static int vpif_reqbufs(struct file *file, void *priv,
q-mem_ops = vb2_dma_contig_memops;
q-buf_struct_size = sizeof(struct vpif_disp_buffer);
- vb2_queue_init(q);
-
+ ret = vb2_queue_init(q);
+ if (ret) {
+ vpif_err(vpif_display: vb2_queue_init() failed\n);
+ vb2_dma_contig_cleanup_ctx(common-alloc_ctx);
+ return ret;
+ }
/* Set io allowed member of file handle to TRUE */
fh-io_allowed[index] = 1;
/* Increment io usrs member of channel object to 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 v3] media: davinci: vpif: set device capabilities
On Thu 4 October 2012 11:29:58 Prabhakar wrote:
From: Lad, Prabhakar prabhakar@ti.com
set device_caps and also change the driver and
bus_info to proper values as per standard.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
---
Changes for v3:
1: Removed READWRITE flag for device_caps pointed by Hans.
Changes for v2:
1: Change the bus_info and driver to proper values,
pointed by Hans.
drivers/media/platform/davinci/vpif_capture.c |8 +---
drivers/media/platform/davinci/vpif_display.c |8 +---
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index cabd5a2..fcabc02 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1635,9 +1635,11 @@ static int vpif_querycap(struct file *file, void
*priv,
{
struct vpif_capture_config *config = vpif_dev-platform_data;
- cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
- strlcpy(cap-driver, vpif capture, sizeof(cap-driver));
- strlcpy(cap-bus_info, VPIF Platform, sizeof(cap-bus_info));
+ cap-device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
+ snprintf(cap-driver, sizeof(cap-driver), %s, dev_name(vpif_dev));
+ snprintf(cap-bus_info, sizeof(cap-bus_info), platform:%s,
+ dev_name(vpif_dev));
strlcpy(cap-card, config-card_name, sizeof(cap-card));
return 0;
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 7f20ca5..b716fbd 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -827,9 +827,11 @@ static int vpif_querycap(struct file *file, void *priv,
{
struct vpif_display_config *config = vpif_dev-platform_data;
- cap-capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
- strlcpy(cap-driver, vpif display, sizeof(cap-driver));
- strlcpy(cap-bus_info, Platform, sizeof(cap-bus_info));
+ cap-device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
+ snprintf(cap-driver, sizeof(cap-driver), %s, dev_name(vpif_dev));
+ snprintf(cap-bus_info, sizeof(cap-bus_info), platform:%s,
+ dev_name(vpif_dev));
strlcpy(cap-card, config-card_name, sizeof(cap-card));
return 0;
--
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
[GIT PULL FOR v3.7] Davinci VPIF driver cleanup
Hi Mauro, Can you please pull the following patches for davinci VPIF driver. There are patches which affect davinci platform code, on top of which cleanup was done, So to avoid conflicts these patches need to go through media tree. Patches affecting davinci platform code have been Acked by Sekhar. Thanks and Regards, --Prabhakar Lad The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4: em28xx: regression fix: use DRX-K sync firmware requests on em28xx (2012-10-02 17:15:22 -0300) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git da850_vpif_machine Hans Verkuil (14): vpif_capture: remove unused data structure. vpif_display: remove unused data structures. vpif_capture: move input_idx to channel_obj. vpif_display: move output_id to channel_obj. vpif_capture: remove unnecessary can_route flag. vpif_capture: move routing info from subdev to input. vpif_capture: first init subdevs, then register device nodes. vpif_display: first init subdevs, then register device nodes. vpif_display: fix cleanup code. vpif_capture: fix cleanup code. vpif_capture: separate subdev from input. vpif_display: use a v4l2_subdev pointer to call a subdev. davinci: move struct vpif_interface to chan_cfg. tvp514x: s_routing should just change routing, not try to detect a signal. Lad, Prabhakar (4): media: davinci: vpif: add check for NULL handler media: davinci: vpif: display: separate out subdev from output media: davinci: vpif: Add return code check at vb2_queue_init() media: davinci: vpif: set device capabilities Manjunath Hadli (2): ARM: davinci: da850: Add SoC related definitions for VPIF ARM: davinci: da850 evm: Add EVM specific code for VPIF to work arch/arm/mach-davinci/Kconfig |7 + arch/arm/mach-davinci/board-da850-evm.c | 179 arch/arm/mach-davinci/board-dm646x-evm.c | 80 -- arch/arm/mach-davinci/da850.c | 152 ++ arch/arm/mach-davinci/include/mach/da8xx.h| 11 + arch/arm/mach-davinci/include/mach/mux.h | 42 +++ arch/arm/mach-davinci/include/mach/psc.h |1 + drivers/media/i2c/tvp514x.c | 77 +- drivers/media/platform/davinci/vpif_capture.c | 370 - drivers/media/platform/davinci/vpif_capture.h | 16 +- drivers/media/platform/davinci/vpif_display.c | 275 -- drivers/media/platform/davinci/vpif_display.h | 18 +- include/media/davinci/vpif_types.h| 26 ++- 13 files changed, 837 insertions(+), 417 deletions(-) -- 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: udev breakages -
[Kay removed because I don't like emailing arguable flamebait directly to the person flamed.] On 4 Oct 2012, n...@esperi.org.uk stated: By udev 175 I, and a lot of other people, had simply stopped upgrading udev entirely on the grounds that we could no longer tolerate the uncertainty over whether our systems would boot every time we upgraded it, for no discernible benefit. Yes, all the incompatible changes are (or were, as of udev 175) called out in the release notes -- but there are so *many* of them, it's easy to miss one. And they all seem so completely unnecessary, and their implications for your system configuration grow more and more invasive all the time. In the bright light of day I realize that this post is not as off-topic for this thread as it appears. This is all of a piece. The udev maintainer insists that everyone else adapt to udev's demands: before now, it has been users, sysadmins, and userspace who must adapt, but now is is pushing its demands in the other direction as well: this thread is the result. -- NULL (void) -- 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
[GIT PULL FOR v3.7] Some videobuf2 multiplanar fixes
Hi Mauro, Here is a bunch of vb2 fixes for the vb2 multiplanar support. It's unchanged from my RFCv2: http://www.spinics.net/lists/linux-media/msg54123.html except for being rebased. Regards, Hans The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4: em28xx: regression fix: use DRX-K sync firmware requests on em28xx (2012-10-02 17:15:22 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git vb2 for you to fetch changes up to 509de2634fef1755b8ed862bb323f00dc53520a9: DocBook: various updates w.r.t. v4l2_buffer and multiplanar. (2012-10-04 12:49:43 +0200) Hans Verkuil (4): videobuf2-core: move plane verification out of __fill_v4l2/vb_buffer. videobuf2-core: fill in length field for multiplanar buffers. v4l2-ioctl.c: handle PREPARE_BUF like QUERYBUF. DocBook: various updates w.r.t. v4l2_buffer and multiplanar. Documentation/DocBook/media/v4l/io.xml |6 ++-- Documentation/DocBook/media/v4l/vidioc-qbuf.xml |3 +- Documentation/DocBook/media/v4l/vidioc-querybuf.xml | 11 --- drivers/media/v4l2-core/v4l2-ioctl.c|1 + drivers/media/v4l2-core/videobuf2-core.c| 79 +-- 5 files changed, 52 insertions(+), 48 deletions(-) -- 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: Set vfl_dir for encoder
The vfl_dir flag is presently set to VFL_DIR_M2M only for decoder. The encoder is not working because of this. So adding this flag to the encoder part also. Signed-off-by: Arun Kumar K arun...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index aa55133..130f4ac 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -1155,6 +1155,7 @@ static int s5p_mfc_probe(struct platform_device *pdev) vfd-release= video_device_release, vfd-lock = dev-mfc_mutex; vfd-v4l2_dev = dev-v4l2_dev; + vfd-vfl_dir= VFL_DIR_M2M; snprintf(vfd-name, sizeof(vfd-name), %s, S5P_MFC_ENC_NAME); dev-vfd_enc= vfd; ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0); -- 1.7.0.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 http://vger.kernel.org/majordomo-info.html
RE: [Linaro-mm-sig] [RFC] New dma_buf - EGLImage EGL extension
Hi Rob, -Original Message- From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob Clark Sent: 03 October 2012 13:39 To: Maarten Lankhorst Cc: Tom Cooksey; mesa-...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; dri- de...@lists.freedesktop.org; Jesse Barker; linux-media@vger.kernel.org Subject: Re: [Linaro-mm-sig] [RFC] New dma_buf - EGLImage EGL extension On Tue, Oct 2, 2012 at 2:10 PM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: How do you want to deal with the case where Y' and CbCr are different hardware buffers? Could some support for 2d arrays be added in case Y' and CbCr are separated into top/bottom fields? How are semi-planar/planar formats handled that have a different width/height for Y' and CbCr? (YUV420) The API works (AFAIU) like drm addfb2 ioctl, take I420 for example, you could either do: single buffer: fd0 = fd offset0 = 0 pitch0 = width fd1 = fd offset1 = width * height pitch1 = width / 2 fd2 = fd offset2 = offset1 + (width / height / 4) pitch2 = width / 2 multiple buffers: offset0 = offset1 = offset2 = 0 fd0 = fd_luma fd1 = fd_u fd2 = fd_v ... and so on Yup, that's pretty much how I'd envisaged it. for interlaced/stereo.. is sticking our heads in sand an option? :-P You could get lots of permutations for data layout of fields between interlaced and stereo. One option might be to ignore and let the user create two egl-images and deal with blending in the shader? I think for interlaced video the only option really is to create two EGLImages as the two fields have to be displayed at different times. If the application wanted to display them progressively they'd have to run a de-interlacing filter over the two images. Perhaps writing such a filter as a GLSL shader might not be such a bad idea, but it's kinda the app's problem. Same deal with stereo. Cheers, Tom PS: I've updated the spec and sent out a new draft. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- 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
hvr-1600 fails frequently on multiple recordings
I have a fairly new HVR-1600 which I have seen fail quite a number of times now when it's asked to record more than one channel on a clearqam multiplex. This time it was 3 recordings at once. There's nothing at all in the kernel ring buffer, just mythtv reports a failed recording. Usually one of the files being recorded to will only be 376 bytes long and the rest will be 0 bytes. I am running ubuntu's 3.2.0-27-generic kernel with what looks like a 1.5.1 cx18 driver. The card is either a: 14f1:5b7a Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast Audio Decoder or a: :0016 Internext Compression Inc iTVC16 (CX23416) Video Decoder (rev 01) Sorry. I don't recall which is which any more. But I really need to figure this out since failed recordings is causing all kinds of disappointment around here. I'm really at the end of my rope with it. Tomorrow morning I am going to demote this card to secondary duty and promote my HVR-950Q to primary duty since I never had this kind of grief with it. But even in secondary duty, it could very well be called upon to record multiple clearqam channels simultaneously so I would really like to get this figured out. Any ideas? Cheers, b. signature.asc Description: OpenPGP digital signature
[GIT PULL FOR v3.7] Exynos/S5P MIPI-CSIS driver updates
Hi Mauro, The following changes since commit 4fc8566367d6e0b460f67373423aa4f6b9cbf3ec: ARM: samsung: move platform_data definitions (2012-10-03 18:42:54 +0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l_for_mauro_2 for you to fetch changes up to f53db50df38ab6d688ca76326784ce5837448cca: s5p-csis: Allow to specify pixel clock's source through platform data (2012-10-03 18:49:26 +0200) This pull request depends on patch from Arnd Bergman, moving platform data headers out of arch/arm to include/linux/platform_data. This commit is already in Linus' tree 436d42c61c3eef1d02256174c8615046c61a28ad ARM: samsung: move platform_data definitions and I have cherry-picked it on top of staging/for_v3.7 branch, before applying my patches. The patches touching arch/arm/mach-exynos and arch/arm/plat-samsung have been already acked by the Samsung maintainer. The changes here are related mostly to the device tree support for the s5p-csis driver. Sylwester Nawrocki (7): ARM: samsung: Remove unused fields from FIMC and CSIS platform data ARM: samsung: Change __s5p_mipi_phy_control() function signature s5p-csis: Change regulator supply names ARM: EXYNOS: Change MIPI-CSIS device regulator supply names s5p-csis: Replace phy_enable platform data callback with direct call s5p-fimc: Remove unused platform data structure fields s5p-csis: Allow to specify pixel clock's source through platform data arch/arm/mach-exynos/mach-nuri.c|7 ++- arch/arm/mach-exynos/mach-origen.c |4 ++-- arch/arm/mach-exynos/mach-universal_c210.c |7 ++- arch/arm/plat-samsung/setup-mipiphy.c | 20 +++--- drivers/media/platform/s5p-fimc/mipi-csis.c | 23 +++- include/linux/platform_data/mipi-csis.h | 30 +++ include/media/s5p_fimc.h|2 -- 7 files changed, 38 insertions(+), 55 deletions(-) --- 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: [PATCH] [media] s5p-mfc: Set vfl_dir for encoder
On 10/04/2012 09:14 PM, Arun Kumar K wrote: The vfl_dir flag is presently set to VFL_DIR_M2M only for decoder. The encoder is not working because of this. So adding this flag to the encoder part also. Signed-off-by: Arun Kumar K arun...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index aa55133..130f4ac 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -1155,6 +1155,7 @@ static int s5p_mfc_probe(struct platform_device *pdev) vfd-release= video_device_release, vfd-lock = dev-mfc_mutex; vfd-v4l2_dev = dev-v4l2_dev; + vfd-vfl_dir= VFL_DIR_M2M; snprintf(vfd-name, sizeof(vfd-name), %s, S5P_MFC_ENC_NAME); dev-vfd_enc= vfd; ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0); I have added it to my tree, will send out to Mauro together with your v10 of the patch series adding MFC v6 firmware support, with Kamil's Ack. -- Thanks, 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: udev breakages - was: Re: Need of an .async_probe() type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 6:58 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Oct 3, 2012 at 3:48 PM, Andy Walls awa...@md.metrocast.net wrote: I don't know if you can remove the /sys/.../firmware ABI altogether, because there is at least one, somewhat popular udev replacement that also uses it: mdev http://git.busybox.net/busybox/plain/docs/mdev.txt Heh. That web doc documents /lib/firmware as being the place to be. That said, there's clearly enough variation here that I think that for now I won't take the step to disable the udev part. I'll do the patch to support direct filesystem firmware loading using the udev default paths, and that hopefully fixes the particular case people see with media modules. As you probably noticed, we had a tester in the RH bug report success with the commit you included yesterday. Do you think this is something worth including in the stable kernels after it gets some further testing during the merge window? Perhaps not that specific commit as there seems to be some additional changes needed for configurable paths, etc, but a backport of the fleshed out changeset might be wanted. We have a new enough udev in Fedora 17 to hit this issue with 3.5 and 3.6 when we rebase. I'm sure other distributions will be in similar circumstances soon if they aren't already. Udev isn't going to be fixed, so having something working in these cases would be great. josh -- 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: udev breakages - was: Re: Need of an .async_probe() type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Thu, Oct 04, 2012 at 09:39:41AM -0400, Josh Boyer wrote: That said, there's clearly enough variation here that I think that for now I won't take the step to disable the udev part. I'll do the patch to support direct filesystem firmware loading using the udev default paths, and that hopefully fixes the particular case people see with media modules. As you probably noticed, we had a tester in the RH bug report success with the commit you included yesterday. Do you think this is something worth including in the stable kernels after it gets some further testing during the merge window? Perhaps not that specific commit as there seems to be some additional changes needed for configurable paths, etc, but a backport of the fleshed out changeset might be wanted. We have a new enough udev in Fedora 17 to hit this issue with 3.5 and 3.6 when we rebase. I'm sure other distributions will be in similar circumstances soon if they aren't already. Udev isn't going to be fixed, so having something working in these cases would be great. Yes, I don't have a problem taking this into the stable kernel releases once it gets some testing and fleshed out. I'll be watching it to see how it goes. thanks, greg k-h -- 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: hvr-1600 fails frequently on multiple recordings
On Thu, Oct 4, 2012 at 7:58 AM, Brian J. Murrell br...@interlinx.bc.ca wrote: I have a fairly new HVR-1600 which I have seen fail quite a number of times now when it's asked to record more than one channel on a clearqam multiplex. This time it was 3 recordings at once. There's nothing at all in the kernel ring buffer, just mythtv reports a failed recording. Usually one of the files being recorded to will only be 376 bytes long and the rest will be 0 bytes. I am running ubuntu's 3.2.0-27-generic kernel with what looks like a 1.5.1 cx18 driver. The card is either a: 14f1:5b7a Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast Audio Decoder or a: :0016 Internext Compression Inc iTVC16 (CX23416) Video Decoder (rev 01) Sorry. I don't recall which is which any more. But I really need to figure this out since failed recordings is causing all kinds of disappointment around here. I'm really at the end of my rope with it. Tomorrow morning I am going to demote this card to secondary duty and promote my HVR-950Q to primary duty since I never had this kind of grief with it. But even in secondary duty, it could very well be called upon to record multiple clearqam channels simultaneously so I would really like to get this figured out. Any ideas? I think the real question at this point is: what version of MythTV are you running? I've seen so many reports recently of breakage in the MythTV codebase related to recording, I am almost inclined to demand you reproduce it outside of MythTV before we even spend any time talking about it. Also, has anything changed in your environment? Was it working before, and then you upgraded the kernel or Myth, and now it's not working? Or has there been a consistent pattern of failure over some extended period of time? The cx18 driver has changed very little as of late - the MythTV codebase has changed heavily and people are all over the place complaining about breakage. I'm not trying to get into the finger-pointing game, but I just want to better understand the history/background before I can make any recommendations. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: udev breakages - was: Re: Need of an .async_probe() type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Tue, 2 Oct 2012, Linus Torvalds wrote: Now, at the same time, I do agree that network devices should generally try to delay it until ifup time Slightly tangential to the ongoing discussion, but still ... I think that even all network drivers should delay firmware loading to ifup time might be too general. I would expect that there are network cards which require firmware to be present for PHY to work, right? On such cards, if you want to have link detection even on interfaces that are down (so that things like ifplugd can detect the link presence and configure the interface), ifup is too late. I admit I haven't checked whether there actually are such cards out there, but it doesn't seem to be completely unrealistic to me. -- Jiri Kosina SUSE Labs -- 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] tm6000: Add parameter to keep urb bufs allocated.
On systems where it cannot be assured that enough continous memory is available
all the time it can be very useful to only allocate the memory once when it is
needed the first time. Afterwards the initially allocated memory will be
reused, so it is ensured that the memory will stay available until the driver
is unloaded.
Signed-off-by: Julian Scheel jul...@jusst.de
---
drivers/media/video/tm6000/tm6000-video.c | 111 +-
drivers/media/video/tm6000/tm6000.h | 5 ++
2 files changed, 97 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-video.c
b/drivers/media/video/tm6000/tm6000-video.c
index 03de3d8..1b8db35 100644
--- a/drivers/media/video/tm6000/tm6000-video.c
+++ b/drivers/media/video/tm6000/tm6000-video.c
@@ -49,12 +49,15 @@
#define TM6000_MIN_BUF 4
#define TM6000_DEF_BUF 8
+#define TM6000_NUM_URB_BUF 8
+
#define TM6000_MAX_ISO_PACKETS 46 /* Max number of ISO packets */
/* Declare static vars that will be used as parameters */
static unsigned int vid_limit = 16;/* Video memory limit, in Mb */
static int video_nr = -1; /* /dev/videoN, -1 for autodetect */
static int radio_nr = -1; /* /dev/radioN, -1 for autodetect */
+static int keep_urb = 0; /* keep urb buffers allocated */
/* Debug level */
int tm6000_debug;
@@ -570,6 +573,70 @@ static void tm6000_irq_callback(struct urb *urb)
}
/*
+ * Allocate URB buffers
+ */
+static int tm6000_alloc_urb_buffers(struct tm6000_core *dev)
+{
+ int num_bufs = TM6000_NUM_URB_BUF;
+ int i;
+
+ if (dev-urb_buffer != NULL)
+ return 0;
+
+ dev-urb_buffer = kmalloc(sizeof(void *)*num_bufs, GFP_KERNEL);
+ if (!dev-urb_buffer) {
+ tm6000_err(cannot allocate memory for urb buffers\n);
+ return -ENOMEM;
+ }
+
+ dev-urb_dma = kmalloc(sizeof(dma_addr_t *)*num_bufs, GFP_KERNEL);
+ if (!dev-urb_dma) {
+ tm6000_err(cannot allocate memory for urb dma pointers\n);
+ return -ENOMEM;
+ }
+
+ for (i = 0; i num_bufs; i++) {
+ dev-urb_buffer[i] = usb_alloc_coherent(dev-udev,
dev-urb_size,
+ GFP_KERNEL, dev-urb_dma[i]);
+ if (!dev-urb_buffer[i]) {
+ tm6000_err(unable to allocate %i bytes for transfer
+buffer %i\n, dev-urb_size, i);
+ return -ENOMEM;
+ }
+ memset(dev-urb_buffer[i], 0, dev-urb_size);
+ }
+
+ return 0;
+}
+
+/*
+ * Free URB buffers
+ */
+static int tm6000_free_urb_buffers(struct tm6000_core *dev)
+{
+ int i;
+
+ if (dev-urb_buffer == NULL)
+ return 0;
+
+ for (i = 0; i TM6000_NUM_URB_BUF; i++) {
+ if (dev-urb_buffer[i]) {
+ usb_free_coherent(dev-udev,
+ dev-urb_size,
+ dev-urb_buffer[i],
+ dev-urb_dma[i]);
+ dev-urb_buffer[i] = NULL;
+ }
+ }
+ kfree (dev-urb_buffer);
+ kfree (dev-urb_dma);
+ dev-urb_buffer = NULL;
+ dev-urb_dma = NULL;
+
+ return 0;
+}
+
+/*
* Stop and Deallocate URBs
*/
static void tm6000_uninit_isoc(struct tm6000_core *dev)
@@ -585,18 +652,15 @@ static void tm6000_uninit_isoc(struct tm6000_core *dev)
if (urb) {
usb_kill_urb(urb);
usb_unlink_urb(urb);
- if (dev-isoc_ctl.transfer_buffer[i]) {
- usb_free_coherent(dev-udev,
- urb-transfer_buffer_length,
-
dev-isoc_ctl.transfer_buffer[i],
- urb-transfer_dma);
- }
usb_free_urb(urb);
dev-isoc_ctl.urb[i] = NULL;
}
dev-isoc_ctl.transfer_buffer[i] = NULL;
}
+ if (!keep_urb)
+ tm6000_free_urb_buffers(dev);
+
kfree(dev-isoc_ctl.urb);
kfree(dev-isoc_ctl.transfer_buffer);
@@ -606,12 +670,12 @@ static void tm6000_uninit_isoc(struct tm6000_core *dev)
}
/*
- * Allocate URBs and start IRQ
+ * Assign URBs and start IRQ
*/
static int tm6000_prepare_isoc(struct tm6000_core *dev)
{
struct tm6000_dmaqueue *dma_q = dev-vidq;
- int i, j, sb_size, pipe, size, max_packets, num_bufs = 8;
+ int i, j, sb_size, pipe, size, max_packets, num_bufs =
TM6000_NUM_URB_BUF;
struct urb *urb;
/* De-allocates all pending stuff */
@@ -634,6 +698,7 @@ static int tm6000_prepare_isoc(struct tm6000_core *dev)
max_packets = TM6000_MAX_ISO_PACKETS;
sb_size = max_packets * size;
+
Re: hvr-1600 fails frequently on multiple recordings
On 12-10-04 10:18 AM, Devin Heitmueller wrote: I think the real question at this point is: what version of MythTV are you running? 0.25-fixes, specifically 46cab93 from 20120801. Indeed, not the latest, but I don't think much if anything has been done in the affected code paths. I want to upgrade and even thought about doing it today but today I also moved the HVR-1600 into secondary duty (and promoted the HVR-950Q) and didn't want to make another change which would only confuse the original cause. I understand that making such a change is not ideal in terms of debugging, but the grief of having a whole night of television recordings fail just causes too much strife here. And most nights it wouldn't really matter but of course it has to happen on the one night of the week that people here have to watch a show the same night it's broadcast or else hear about all of the spoilers at work the next day. :-( I've seen so many reports recently of breakage in the MythTV codebase related to recording, I am almost inclined to demand you reproduce it outside of MythTV before we even spend any time talking about it. That's fair enough I suppose. The one problem is that this problem is very intermittent. It only happens about once a week or so, not really at the same time every week though so not nearly repeatable. Is there much more to recording from these devices though than: # [ tune channel ] # cat $device $file akin to recording from PVR-x50s? I guess what I'm driving at is how much/little code are we talking about in Mythtv to do this? Also, has anything changed in your environment? Nothing other than the HVR-1600 being somewhat new. It has not really been worked hard since I got it given that I got it in the low season. Now that fall is here there is lots more on television and the card is being asked to perform multiplexed recordings way more frequently. Was it working before, Yes, but has always been on light duty since I got it. and then you upgraded the kernel or Myth, and now it's not working? Nope. No upgrades correlating. Or has there been a consistent pattern of failure over some extended period of time? Well, it's happened now 2-3 times since the start of the fall season, which means when it's being asked to do more. The cx18 driver has changed very little as of late - the MythTV codebase has changed heavily and people are all over the place complaining about breakage. Which does seem like a fair correlation. The only other possibility I am considering is a defective card since it's never really proven itself yet. I'm not trying to get into the finger-pointing game, No, I completely understand your perspective and these are all very fair questions. I hope you will allow me to be devil's advocate in hopes of getting to the bottom of it. :-) but I just want to better understand the history/background before I can make any recommendations. Indeed. Always a good idea. There's a reason doctors take patient histories before diagnosing. :-) FWIW, I'd be happy to take this over to the mythtv list if you want to pursue it being a mythtv problem. I filed a bug about mythtv's inability to recover from this situation and it deadlocking until killed (a KILL signal is typically required, demonstrating how badly mythtv is handling this situation) when this happens and even posted to the list about the bug but got zero response. Cheers, b. signature.asc Description: OpenPGP digital signature
[GIT PULL v2 FOR v3.7] Samsung Exynos MFC driver update
Hi Mauro,
The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4:
em28xx: regression fix: use DRX-K sync firmware requests on em28xx
(2012-10-02 17:15:22 -0300)
are available in the git repository at:
git://git.infradead.org/users/kmpark/linux-samsung v4l_mfc_for_mauro
for you to fetch changes up to e2b0cbe5e32bfbbd68773c90411a9e1309df7ec3:
s5p-mfc: Set vfl_dir for encoder (2012-10-04 14:52:29 +0200)
I ensured this time it's rebased onto latest staging/for_v3.7 branch.
Additionally the patch
[media] s5p-mfc: Update MFCv5 driver for callback based architecture
has been split in two and there is also included one patch adding
missing vfl_dir flag for the codec device (s5p-mfc: Set vfl_dir for
encoder).
Arun Kumar K (6):
v4l: Add fourcc definitions for new formats
v4l: Add control definitions for new H264 encoder features
s5p-mfc: Prepare driver for callback based re-architecture
s5p-mfc: Update MFCv5 driver for callback based architecture
s5p-mfc: Add MFC variant data to device context
s5p-mfc: Set vfl_dir for encoder
Jeongtae Park (2):
s5p-mfc: MFCv6 register definitions
s5p-mfc: Update MFC v4l2 driver to support MFC6.x
Documentation/DocBook/media/v4l/controls.xml | 268 ++-
Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 17 +-
Documentation/DocBook/media/v4l/pixfmt.xml | 10 +
drivers/media/platform/Kconfig |4 +-
drivers/media/platform/s5p-mfc/Makefile|7 +-
drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 408
drivers/media/platform/s5p-mfc/regs-mfc.h | 41 +
drivers/media/platform/s5p-mfc/s5p_mfc.c | 294 ++-
drivers/media/platform/s5p-mfc/s5p_mfc_cmd.c | 111 +-
drivers/media/platform/s5p-mfc/s5p_mfc_cmd.h | 17 +-
drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c| 166 ++
drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.h| 20 +
drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c| 156 ++
drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.h| 20 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h| 191 +-
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 202 +-
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h |1 +
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 258 ++-
drivers/media/platform/s5p-mfc/s5p_mfc_dec.h |1 +
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 236 ++-
drivers/media/platform/s5p-mfc/s5p_mfc_enc.h |1 +
drivers/media/platform/s5p-mfc/s5p_mfc_intr.c | 11 +-
drivers/media/platform/s5p-mfc/s5p_mfc_opr.c | 1418 +-
drivers/media/platform/s5p-mfc/s5p_mfc_opr.h | 137 +-
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c| 1794 ++
.../s5p-mfc/{s5p_mfc_shm.h = s5p_mfc_opr_v5.h}| 41 +-
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c| 1956
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h| 50 +
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c|3 +-
drivers/media/platform/s5p-mfc/s5p_mfc_shm.c | 47 -
drivers/media/v4l2-core/v4l2-ctrls.c | 42 +
include/linux/v4l2-controls.h | 41 +
include/linux/videodev2.h |4 +
33 files changed, 5915 insertions(+), 2058 deletions(-)
create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v6.h
create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c
create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.h
create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.h
create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
rename drivers/media/platform/s5p-mfc/{s5p_mfc_shm.h = s5p_mfc_opr_v5.h} (76%)
create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
delete mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_shm.c
---
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: udev breakages -
Kay Sievers k...@vrfy.org writes: If that works out, it would a bit like devtmpfs which turned out to be very simple, reliable and absolutely the right thing we could do to primarily mange /dev content. ROFL. There are still quite a few interesting cases that devtmpfs does not even think about supporting. Cases that were reported when devtmpfs was being reviewed. Additionally the devtmpfs maintainership has not dealt with legitimate concerns any better than this firmware issue has been dealt with. I still haven't even hear a productive suggestion back on the hole /dev/ptmx mess. As it happens devtmpfs wound up being a userspace process that happens to reside in the kernel and call mknod. How it makes sense two layers of messaging and device management instead of just one I don't know. Certainly I would not crow about that being a success of anything except passing the buck. There is debacle written all over the user space interface for dealing with devices right now. Eric -- 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] tm6000: Add parameter to keep urb bufs allocated.
Hi Julian,
Nice work! Just one pico-tiny nitpick:
On Thu, Oct 4, 2012 at 11:04 AM, Julian Scheel jul...@jusst.de wrote:
On systems where it cannot be assured that enough continous memory is
available
all the time it can be very useful to only allocate the memory once when it is
needed the first time. Afterwards the initially allocated memory will be
reused, so it is ensured that the memory will stay available until the driver
is unloaded.
Signed-off-by: Julian Scheel jul...@jusst.de
---
drivers/media/video/tm6000/tm6000-video.c | 111
+-
drivers/media/video/tm6000/tm6000.h | 5 ++
2 files changed, 97 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-video.c
b/drivers/media/video/tm6000/tm6000-video.c
index 03de3d8..1b8db35 100644
--- a/drivers/media/video/tm6000/tm6000-video.c
+++ b/drivers/media/video/tm6000/tm6000-video.c
@@ -49,12 +49,15 @@
#define TM6000_MIN_BUF 4
#define TM6000_DEF_BUF 8
+#define TM6000_NUM_URB_BUF 8
+
#define TM6000_MAX_ISO_PACKETS 46 /* Max number of ISO packets */
/* Declare static vars that will be used as parameters */
static unsigned int vid_limit = 16;/* Video memory limit, in Mb */
static int video_nr = -1; /* /dev/videoN, -1 for autodetect */
static int radio_nr = -1; /* /dev/radioN, -1 for autodetect */
+static int keep_urb = 0; /* keep urb buffers allocated */
There's no need to initialize this one to zero.
/* Debug level */
int tm6000_debug;
@@ -570,6 +573,70 @@ static void tm6000_irq_callback(struct urb *urb)
}
/*
+ * Allocate URB buffers
+ */
+static int tm6000_alloc_urb_buffers(struct tm6000_core *dev)
+{
+ int num_bufs = TM6000_NUM_URB_BUF;
+ int i;
+
+ if (dev-urb_buffer != NULL)
+ return 0;
+
+ dev-urb_buffer = kmalloc(sizeof(void *)*num_bufs, GFP_KERNEL);
+ if (!dev-urb_buffer) {
+ tm6000_err(cannot allocate memory for urb buffers\n);
+ return -ENOMEM;
+ }
+
+ dev-urb_dma = kmalloc(sizeof(dma_addr_t *)*num_bufs, GFP_KERNEL);
+ if (!dev-urb_dma) {
+ tm6000_err(cannot allocate memory for urb dma pointers\n);
+ return -ENOMEM;
+ }
+
+ for (i = 0; i num_bufs; i++) {
+ dev-urb_buffer[i] = usb_alloc_coherent(dev-udev,
dev-urb_size,
+ GFP_KERNEL, dev-urb_dma[i]);
+ if (!dev-urb_buffer[i]) {
+ tm6000_err(unable to allocate %i bytes for transfer
+buffer %i\n, dev-urb_size, i);
+ return -ENOMEM;
+ }
+ memset(dev-urb_buffer[i], 0, dev-urb_size);
+ }
+
+ return 0;
+}
+
+/*
+ * Free URB buffers
+ */
+static int tm6000_free_urb_buffers(struct tm6000_core *dev)
+{
+ int i;
+
+ if (dev-urb_buffer == NULL)
+ return 0;
+
+ for (i = 0; i TM6000_NUM_URB_BUF; i++) {
+ if (dev-urb_buffer[i]) {
+ usb_free_coherent(dev-udev,
+ dev-urb_size,
+ dev-urb_buffer[i],
+ dev-urb_dma[i]);
+ dev-urb_buffer[i] = NULL;
+ }
+ }
+ kfree (dev-urb_buffer);
+ kfree (dev-urb_dma);
+ dev-urb_buffer = NULL;
+ dev-urb_dma = NULL;
+
+ return 0;
+}
+
+/*
* Stop and Deallocate URBs
*/
static void tm6000_uninit_isoc(struct tm6000_core *dev)
@@ -585,18 +652,15 @@ static void tm6000_uninit_isoc(struct tm6000_core *dev)
if (urb) {
usb_kill_urb(urb);
usb_unlink_urb(urb);
- if (dev-isoc_ctl.transfer_buffer[i]) {
- usb_free_coherent(dev-udev,
- urb-transfer_buffer_length,
-
dev-isoc_ctl.transfer_buffer[i],
- urb-transfer_dma);
- }
usb_free_urb(urb);
dev-isoc_ctl.urb[i] = NULL;
}
dev-isoc_ctl.transfer_buffer[i] = NULL;
}
+ if (!keep_urb)
+ tm6000_free_urb_buffers(dev);
+
kfree(dev-isoc_ctl.urb);
kfree(dev-isoc_ctl.transfer_buffer);
@@ -606,12 +670,12 @@ static void tm6000_uninit_isoc(struct tm6000_core *dev)
}
/*
- * Allocate URBs and start IRQ
+ * Assign URBs and start IRQ
*/
static int tm6000_prepare_isoc(struct tm6000_core *dev)
{
struct tm6000_dmaqueue *dma_q = dev-vidq;
- int i, j, sb_size, pipe, size, max_packets, num_bufs = 8;
+ int i, j, sb_size, pipe,
Re: udev breakages -
On Thu, Oct 04, 2012 at 10:29:51AM -0700, Eric W. Biederman wrote: There are still quite a few interesting cases that devtmpfs does not even think about supporting. Cases that were reported when devtmpfs was being reviewed. Care to refresh my memory? Additionally the devtmpfs maintainership has not dealt with legitimate concerns any better than this firmware issue has been dealt with. I still haven't even hear a productive suggestion back on the hole /dev/ptmx mess. I don't know how to handle the /dev/ptmx issue properly from within devtmpfs, does anyone? Proposals are always welcome, the last time this came up a week or so ago, I don't recall seeing any proposals, just a general complaint. thanks, greg k-h -- 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/2 v6] of: add display helper
Hi! In accordance with Stepehn Warren, I downsized the binding. Now, just the display-timing is described, as I think, it is way easier to agree on those and have a complete binding. Regards, Steffen Steffen Trumtrar (2): of: add helper to parse display timings of: add generic videomode description .../devicetree/bindings/video/display-timings.txt | 222 drivers/of/Kconfig | 10 + drivers/of/Makefile|2 + drivers/of/of_display_timings.c| 183 drivers/of/of_videomode.c | 212 +++ include/linux/of_display_timings.h | 85 include/linux/of_videomode.h | 41 7 files changed, 755 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt create mode 100644 drivers/of/of_display_timings.c create mode 100644 drivers/of/of_videomode.c create mode 100644 include/linux/of_display_timings.h create mode 100644 include/linux/of_videomode.h -- 1.7.10.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 http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v6] of: add helper to parse display timings
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
.../devicetree/bindings/video/display-timings.txt | 222
drivers/of/Kconfig |5 +
drivers/of/Makefile|1 +
drivers/of/of_display_timings.c| 183
include/linux/of_display_timings.h | 85
5 files changed, 496 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
create mode 100644 drivers/of/of_display_timings.c
create mode 100644 include/linux/of_display_timings.h
diff --git a/Documentation/devicetree/bindings/video/display-timings.txt
b/Documentation/devicetree/bindings/video/display-timings.txt
new file mode 100644
index 000..45e39bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timings.txt
@@ -0,0 +1,222 @@
+display-timings bindings
+==
+
+display-timings-node
+
+
+required properties:
+ - none
+
+optional properties:
+ - default-timing: the default timing value
+
+timings-subnode
+---
+
+required properties:
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
+ lines
+ - clock: displayclock in Hz
+
+optional properties:
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
+ - de-active-high (bool): Data-Enable pulse is active high
+ - pixelclk-inverted (bool): pixelclock is inverted
+ - interlaced (bool)
+ - doublescan (bool)
+
+There are different ways of describing the capabilities of a display. The
devicetree
+representation corresponds to the one commonly found in datasheets for
displays.
+If a display supports multiple signal timings, the default-timing can be
specified.
+
+The parameters are defined as
+
+struct signal_timing
+===
+
+ +--+-+--+---+
+ | |↑| | |
+ | ||vback_porch | | |
+ | |↓| | |
+ +--###--+---+
+ | #↑# | |
+ | #|# | |
+ | hback #|# hfront | hsync |
+ | porch #| hactive # porch | len |
+ |#---+---#|-|
+ | #|# | |
+ | #|vactive # | |
+ | #|# | |
+ | #↓# | |
+ +--###--+---+
+ | |↑| | |
+ | ||vfront_porch| | |
+ | |↓| | |
+ +--+-+--+---+
+ | |↑| | |
+ | ||vsync_len | | |
+ | |↓| | |
+ +--+-+--+---+
+
+
+Example:
+
+ display-timings {
+ default-timing = timing0;
+ timing0: 1920p24 {
+ /* 1920x1080p24 */
+ clock = 5200;
+ hactive = 1920;
+ vactive = 1080;
+ hfront-porch = 25;
+ hback-porch = 25;
+ hsync-len = 25;
+ vback-porch = 2;
+ vfront-porch = 2;
+ vsync-len = 2;
+ hsync-active-high;
+ };
+ };
+
+Every property also supports the use of ranges, so the commonly used datasheet
+description with min typ max-tuples can be used.
+
+Example:
+
+ timing1: timing {
+ /* 1920x1080p24 */
+ clock = 14850;
+ hactive = 1920;
+ vactive = 1080;
+ hsync-len = 0 44 60;
+ hfront-porch = 80 88 95;
+ hback-porch = 100 148 160;
+ vfront-porch = 0 4 6;
+ vback-porch = 0
[PATCH 2/2 v6] of: add generic videomode description
Get videomode from devicetree in a format appropriate for the
backend. drm_display_mode and fb_videomode are supported atm.
Uses the display signal timings from of_display_timings
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/of/Kconfig |5 +
drivers/of/Makefile |1 +
drivers/of/of_videomode.c| 212 ++
include/linux/of_videomode.h | 41
4 files changed, 259 insertions(+)
create mode 100644 drivers/of/of_videomode.c
create mode 100644 include/linux/of_videomode.h
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 646deb0..74282e2 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -88,4 +88,9 @@ config OF_DISPLAY_TIMINGS
help
helper to parse display timings from the devicetree
+config OF_VIDEOMODE
+ def_bool y
+ help
+ helper to get videomodes from the devicetree
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index c8e9603..09d556f 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
obj-$(CONFIG_OF_DISPLAY_TIMINGS) += of_display_timings.o
+obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
new file mode 100644
index 000..76ac16e
--- /dev/null
+++ b/drivers/of/of_videomode.c
@@ -0,0 +1,212 @@
+/*
+ * generic videomode helper
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+#include linux/of.h
+#include linux/fb.h
+#include linux/slab.h
+#include drm/drm_mode.h
+#include linux/of_display_timings.h
+#include linux/of_videomode.h
+
+void dump_fb_videomode(struct fb_videomode *m)
+{
+pr_debug(fb_videomode = %d %d %d %d %d %d %d %d %d %d %d %d %d\n,
+m-refresh, m-xres, m-yres, m-pixclock, m-left_margin,
+m-right_margin, m-upper_margin, m-lower_margin,
+m-hsync_len, m-vsync_len, m-sync, m-vmode, m-flag);
+}
+
+void dump_drm_displaymode(struct drm_display_mode *m)
+{
+pr_debug(drm_displaymode = %d %d %d %d %d %d %d %d %d\n,
+m-hdisplay, m-hsync_start, m-hsync_end, m-htotal,
+m-vdisplay, m-vsync_start, m-vsync_end, m-vtotal,
+m-clock);
+}
+
+int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
+ int index)
+{
+ struct signal_timing *st = NULL;
+
+ if (!vm)
+ return -EINVAL;
+
+ st = display_timings_get(disp, index);
+
+ if (!st) {
+ pr_err(%s: no signal timings found\n, __func__);
+ return -EINVAL;
+ }
+
+ vm-pixelclock = signal_timing_get_value(st-pixelclock, 0);
+ vm-hactive = signal_timing_get_value(st-hactive, 0);
+ vm-hfront_porch = signal_timing_get_value(st-hfront_porch, 0);
+ vm-hback_porch = signal_timing_get_value(st-hback_porch, 0);
+ vm-hsync_len = signal_timing_get_value(st-hsync_len, 0);
+
+ vm-vactive = signal_timing_get_value(st-vactive, 0);
+ vm-vfront_porch = signal_timing_get_value(st-vfront_porch, 0);
+ vm-vback_porch = signal_timing_get_value(st-vback_porch, 0);
+ vm-vsync_len = signal_timing_get_value(st-vsync_len, 0);
+
+ vm-vah = st-vsync_pol_active_high;
+ vm-hah = st-hsync_pol_active_high;
+ vm-interlaced = st-interlaced;
+ vm-doublescan = st-doublescan;
+
+ return 0;
+}
+
+int of_get_videomode(struct device_node *np, struct videomode *vm, int index)
+{
+ struct display_timings *disp;
+ int ret = 0;
+
+ disp = of_get_display_timing_list(np);
+
+ if (!disp) {
+ pr_err(%s: no timings specified\n, __func__);
+ return -EINVAL;
+ }
+
+ if (index == OF_DEFAULT_TIMING)
+ index = disp-default_timing;
+
+ ret = videomode_from_timing(disp, vm, index);
+
+ if (ret)
+ return ret;
+
+ display_timings_release(disp);
+
+ if (!vm) {
+ pr_err(%s: could not get videomode %d\n, __func__, index);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_videomode);
+
+#if defined(CONFIG_DRM)
+int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode
*dmode)
+{
+ memset(dmode, 0, sizeof(*dmode));
+
+ dmode-hdisplay = vm-hactive;
+ dmode-hsync_start = dmode-hdisplay + vm-hfront_porch;
+ dmode-hsync_end = dmode-hsync_start + vm-hsync_len;
+ dmode-htotal = dmode-hsync_end + vm-hback_porch;
+
+ dmode-vdisplay = vm-vactive;
+ dmode-vsync_start = dmode-vdisplay + vm-vfront_porch;
+ dmode-vsync_end = dmode-vsync_start + vm-vsync_len;
+ dmode-vtotal = dmode-vsync_end + vm-vback_porch;
+
+
[PATCH 1/2] em28xx: Better support for the Terratec Cinergy HTC USB XS. This intializes the card just like the windows driver does.
Signed-off-by: Martin Blumenstingl martin.blumensti...@googlemail.com
---
drivers/media/usb/em28xx/em28xx-cards.c | 13 -
drivers/media/usb/em28xx/em28xx-dvb.c | 84 -
drivers/media/usb/em28xx/em28xx.h | 1 +
3 files changed, 94 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index ab98d08..9418c5e 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -1979,6 +1979,15 @@ struct em28xx_board em28xx_boards[] = {
EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
},
+ [EM2884_BOARD_TERRATEC_HTC_USB_XS] = {
+ .name = Terratec Cinergy HTC USB XS,
+ .has_dvb = 1,
+ .ir_codes = RC_MAP_NEC_TERRATEC_CINERGY_XS,
+ .tuner_type = TUNER_ABSENT,
+ .i2c_speed= EM2874_I2C_SECONDARY_BUS_SELECT |
+ EM28XX_I2C_CLK_WAIT_ENABLE |
+ EM28XX_I2C_FREQ_400_KHZ,
+ },
};
const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
@@ -2057,9 +2066,9 @@ struct usb_device_id em28xx_id_table[] = {
{ USB_DEVICE(0x0ccd, 0x0043),
.driver_info = EM2870_BOARD_TERRATEC_XS },
{ USB_DEVICE(0x0ccd, 0x008e), /* Cinergy HTC USB XS Rev. 1 */
- .driver_info = EM2884_BOARD_TERRATEC_H5 },
+ .driver_info = EM2884_BOARD_TERRATEC_HTC_USB_XS },
{ USB_DEVICE(0x0ccd, 0x00ac), /* Cinergy HTC USB XS Rev. 2 */
- .driver_info = EM2884_BOARD_TERRATEC_H5 },
+ .driver_info = EM2884_BOARD_TERRATEC_HTC_USB_XS },
{ USB_DEVICE(0x0ccd, 0x10a2), /* H5 Rev. 1 */
.driver_info = EM2884_BOARD_TERRATEC_H5 },
{ USB_DEVICE(0x0ccd, 0x10ad), /* H5 Rev. 2 */
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 913e522..14f8f17 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -331,7 +331,7 @@ static struct drxk_config hauppauge_930c_drxk = {
.load_firmware_sync = true,
};
-struct drxk_config terratec_htc_stick_drxk = {
+static struct drxk_config terratec_htc_stick_drxk = {
.adr = 0x29,
.single_master = 1,
.no_i2c_bridge = 1,
@@ -520,7 +520,10 @@ static void terratec_htc_stick_init(struct em28xx *dev)
{ -1, -1, -1, -1},
};
- /* Init the analog decoder? */
+ /*
+* Init the analog decoder (not yet supported), but
+* it's probably still a good idea.
+*/
struct {
unsigned char r[4];
int len;
@@ -547,6 +550,64 @@ static void terratec_htc_stick_init(struct em28xx *dev)
em28xx_gpio_set(dev, terratec_htc_stick_end);
};
+static void terratec_htc_usb_xs_init(struct em28xx *dev)
+{
+ int i;
+
+ struct em28xx_reg_seq terratec_htc_usb_xs_init[] = {
+ {EM28XX_R08_GPIO, 0xff, 0xff, 10},
+ {EM2874_R80_GPIO, 0xb2, 0xff, 100},
+ {EM2874_R80_GPIO, 0xb2, 0xff, 50},
+ {EM2874_R80_GPIO, 0xb6, 0xff, 100},
+ { -1, -1, -1, -1},
+ };
+ struct em28xx_reg_seq terratec_htc_usb_xs_end[] = {
+ {EM2874_R80_GPIO, 0xa6, 0xff, 100},
+ {EM2874_R80_GPIO, 0xa6, 0xff, 50},
+ {EM2874_R80_GPIO, 0xe6, 0xff, 100},
+ { -1, -1, -1, -1},
+ };
+
+ /*
+* Init the analog decoder (not yet supported), but
+* it's probably still a good idea.
+*/
+ struct {
+ unsigned char r[4];
+ int len;
+ } regs[] = {
+ {{ 0x06, 0x02, 0x00, 0x31 }, 4},
+ {{ 0x01, 0x02 }, 2},
+ {{ 0x01, 0x02, 0x00, 0xc6 }, 4},
+ {{ 0x01, 0x00 }, 2},
+ {{ 0x01, 0x00, 0xff, 0xaf }, 4},
+ {{ 0x01, 0x00, 0x03, 0xa0 }, 4},
+ {{ 0x01, 0x00 }, 2},
+ {{ 0x01, 0x00, 0x73, 0xaf }, 4},
+ {{ 0x04, 0x00 }, 2},
+ {{ 0x00, 0x04 }, 2},
+ {{ 0x00, 0x04, 0x00, 0x0a }, 4},
+ {{ 0x04, 0x14 }, 2},
+ {{ 0x04, 0x14, 0x00, 0x00 }, 4},
+ };
+
+ em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40);
+
+ em28xx_gpio_set(dev, terratec_htc_usb_xs_init);
+
+ em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40);
+ msleep(10);
+ em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x44);
+ msleep(10);
+
+ dev-i2c_client.addr = 0x82 1;
+
+ for (i = 0; i ARRAY_SIZE(regs); i++)
+
[PATCH 2/2] drxk: Use the #define instead of hardcoded values.
Signed-off-by: Martin Blumenstingl martin.blumensti...@googlemail.com --- drivers/media/dvb-frontends/drxk_hard.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/dvb-frontends/drxk_hard.c b/drivers/media/dvb-frontends/drxk_hard.c index 8b4c6d5..894b6eca 100644 --- a/drivers/media/dvb-frontends/drxk_hard.c +++ b/drivers/media/dvb-frontends/drxk_hard.c @@ -921,7 +921,7 @@ static int GetDeviceCapabilities(struct drxk_state *state) status = write16(state, SCU_RAM_GPIO__A, SCU_RAM_GPIO_HW_LOCK_IND_DISABLE); if (status 0) goto error; - status = write16(state, SIO_TOP_COMM_KEY__A, 0xFABA); + status = write16(state, SIO_TOP_COMM_KEY__A, SIO_TOP_COMM_KEY_KEY); if (status 0) goto error; status = read16(state, SIO_PDR_OHW_CFG__A, sioPdrOhwCfg); @@ -1217,7 +1217,7 @@ static int MPEGTSConfigurePins(struct drxk_state *state, bool mpegEnable) goto error; /* MPEG TS pad configuration */ - status = write16(state, SIO_TOP_COMM_KEY__A, 0xFABA); + status = write16(state, SIO_TOP_COMM_KEY__A, SIO_TOP_COMM_KEY_KEY); if (status 0) goto error; -- 1.7.12.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: [PATCH 1/2] em28xx: Better support for the Terratec Cinergy HTC USB XS. This intializes the card just like the windows driver does.
Hi, I forgot to add some clarification: - the HTC USB XS HD uses the same firmware as the HTC Stick HD. - both have different GPIO and reg init sequences - I tested my changes only with DVB-C, but I guess DVB-T will work fine (unfortunately I can't test that, but it was working fine on the HTC Stick HD back when I tested it). I tested with and without firmware - it was working fine in both cases. - the remote control should work fine now (also untested) Regards, Martin -- 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/2 v6] of: add helper to parse display timings
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote: A patch description would be useful for something like this. diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt new file mode 100644 ... +Usage in backend + Everything before that point in the file looks fine to me. Everything after this point in the file seems to be Linux-specific implementation details. Does it really belong in the DT binding documentation, rather than some Linux-specific documentation file? +struct drm_display_mode +=== + + +--+-+--+---+ + | | | | | ↑ + | | | | | | + | | | | | | + +--###--+---+ | I suspect the entire horizontal box above (and the entire vertical box all the way down the left-hand side) should be on the bottom/right instead of top/left. The reason I think this is because all of vsync_start, vsync_end, vdisplay have to be referenced to some known point, which is usually zero or the start of the timing definition, /or/ there would be some value indicating the size of the top marging/porch in order to say where those other values are referenced to. + | # ↑ ↑ ↑# | | | + | # | | |# | | | + | # | | |# | | | + | # | | |# | | | + | # | | |# | | | + | # | | | hdisplay # | | | + | #--++---# | | | + | # | | |# | | | + | # |vsync_start |# | | | + | # | | |# | | | + | # | |vsync_end |# | | | + | # | | |vdisplay# | | | + | # | | |# | | | + | # | | |# | | | + | # | | |# | | | vtotal + | # | | |# | | | + | # | | | hsync_start# | | | + | #--+-+--+--| | | + | # | | |# | | | + | # | | | hsync_end # | | | + | #--+-+--+--| | + | # | | ↓# | | | + +--|#|--+---+ | + | | | | | | | | + | | | | | | | | + | | ↓ | | | | | + +--+-+---+--+---+ | + | | | | | | | + | | | | | | | + | | ↓ | | | ↓ + +--+-+--+---+ + htotal + - diff --git a/drivers/of/of_display_timings.c b/drivers/of/of_display_timings.c +static int parse_property(struct device_node *np, char *name, + struct timing_entry *result) + if (cells == 1) + ret = of_property_read_u32_array(np, name, result-typ, cells); Should that branch not just set result-min/max to typ as well? Presumably it'd prevent any code that interprets struct timing_entry from having to check if those values were 0 or not? + else if (cells == 3) + ret = of_property_read_u32_array(np, name, result-min, cells); +struct display_timings
Re: [PATCH 2/2 v6] of: add generic videomode description
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
Get videomode from devicetree in a format appropriate for the
backend. drm_display_mode and fb_videomode are supported atm.
Uses the display signal timings from of_display_timings
+++ b/drivers/of/of_videomode.c
+int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
+ st = display_timings_get(disp, index);
+
+ if (!st) {
It's a little odd to leave a blank line between those two lines.
Only half of the code in this file seems OF-related; the routines to
convert a timing to a videomode or drm display mode seem like they'd be
useful outside device tree, so I wonder if putting them into
of_videomode.c is the correct thing to do. Still, it's probably not a
big deal.
--
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: udev breakages -
I don't know how to handle the /dev/ptmx issue properly from within devtmpfs, does anyone? Proposals are always welcome, the last time this came up a week or so ago, I don't recall seeing any proposals, just a general complaint. Is it really a problem - devtmpfs is optional. It's a problem for the userspace folks to handle and if they made it mandatory in their code diddums, someone better go fork working versions. Alan -- 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:Thu Oct 4 19:00:29 CEST 2012 git hash:2425bb3d4016ed95ce83a90b53bd92c7f31091e4 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-sh: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification 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: [PATCH 1/2 v6] of: add helper to parse display timings
Hi Steffen Sorry for chiming in so late in the game, but I've long been wanting to have a look at this and compare with what we do for V4L2, so, this seems a great opportunity to me:-) On Thu, 4 Oct 2012, Steffen Trumtrar wrote: Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de --- .../devicetree/bindings/video/display-timings.txt | 222 drivers/of/Kconfig |5 + drivers/of/Makefile|1 + drivers/of/of_display_timings.c| 183 include/linux/of_display_timings.h | 85 5 files changed, 496 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt create mode 100644 drivers/of/of_display_timings.c create mode 100644 include/linux/of_display_timings.h diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt new file mode 100644 index 000..45e39bd --- /dev/null +++ b/Documentation/devicetree/bindings/video/display-timings.txt @@ -0,0 +1,222 @@ +display-timings bindings +== + +display-timings-node + + +required properties: + - none + +optional properties: + - default-timing: the default timing value + +timings-subnode +--- + +required properties: + - hactive, vactive: Display resolution + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters + in pixels + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in + lines + - clock: displayclock in Hz You're going to hate me for this, but eventually we want to actually reference clock objects in our DT bindings. For now, even if you don't want to actually add clock phandles and stuff here, I think, using the standard clock-frequency property would be much better! + +optional properties: + - hsync-active-high (bool): Hsync pulse is active high + - vsync-active-high (bool): Vsync pulse is active high For the above two we also considered using bool properties but eventually settled down with integer ones: - hsync-active = 1 for active-high and 0 for active low. This has the added advantage of being able to omit this property in the .dts, which then doesn't mean, that the polarity is active low, but rather, that the hsync line is not used on this hardware. So, maybe it would be good to use the same binding here too? + - de-active-high (bool): Data-Enable pulse is active high + - pixelclk-inverted (bool): pixelclock is inverted We don't (yet) have a de-active property in V4L, don't know whether we'll ever have to distingsuish between what some datasheets call HREF and HSYNC in DT, but maybe similarly to the above an integer would be preferred. As for pixclk, we call the property pclk-sample and it's also an integer. + - interlaced (bool) Is interlaced a property of the hardware, i.e. of the board? Can the same display controller on one board require interlaced data and on another board - progressive? BTW, I'm not very familiar with display interfaces, but for interlaced you probably sometimes use a field signal, whose polarity you also want to specify here? We use a field-even-active integer property for it. 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: omap3isp: timeout in ccdc_disable()
Hi Michael, On Tuesday 02 October 2012 16:07:07 Michael Jones wrote: Hi Laurent, I am looking at a case where the sensor may stop delivering data, at which point I want to do a STREAMOFF. In this case, the STREAMOFF takes 2s because of the wait_event_timeout() in ccdc_disable(). This wait waits for ccdc-stopping to be CCDC_STOP_FINISHED, which happens in two stages (only 2 because LSC is always LSC_STATE_STOPPED for me), 1. in VD1 because CCDC_STOP_REQUEST has been set by ccdc_disable() 2. in VD0 after CCDC_STOP_REQUEST had happened in VD1. But because the data has already stopped coming from the sensor, when I do STREAMOFF, I'm no longer getting VD1/0, so ccdc-stopping will never become CCDC_STOP_FINISHED, and the wait_event_timeout() has to run its course of 2 seconds. This doesn't change the control flow in ccdc_disable(), except to print a warning CCDC stop timeout! and return -ETIMEDOUT to ccdc_set_stream(), which in turn returns that as its return value. But this value is ignored by its caller, isp_pipeline_disable(). It looks to me, then, like the only difference between timing out and not timing out is getting the warning message. omap3isp_sbl_disble() is called the same in both cases. Q: Is there another reason for the wait timeout? Is there some functional difference between timing out and not timing out? Yes. The main reason is that the ISP hardware is pretty buggy, and we're lucky it works :-) The ISP modules (CCDC, preview engine, resizer, ...) can be started independently, synchronize themselves to the input signal (at least in theory, sync can sometime be lost), but can't easily be stopped. To stop a module the driver requests a stop by writing to a register and then busy-loops to wait until the busy bit is cleared. For reasons I can't understand it seems that stopping a module in the middle of a frame was considered as a useless features, so modules can only be stopped on a frame boundary. A module that has been started will stay busy until it finishes processing a frame, even if a stop if requested before the frame begins. Trying to reconfigure a module that hasn't been stopped results in an undefined behaviour. The preview engine, for instance, can crash completely, leading to a complete SoC crash. The CCDC seems to be a little more tolerant, but memory corruption or other bad issues can't be ruled out. The CCDC case is even more complex, as we need to stop LSC (Lens Shading Correction) as well. There's a pretty complex state machine in the code, based on the assumption that the module will need to wait for the end of the frame before stopping anyway. That, coupled with the fact that requesting a stop at a random point might be race-prone, lead to the current implementation. It might be possible to modify the state machine to request a stop sooner without waiting for VD1, but even then the CCDC won't be able to stop properly, as it won't get a complete frame to process. It would be better than not stopping the CCDC at all though. TI mentioned at some point that forcing the CCDC to stop without busy-loops was possible but I've never been told how it could be done. If you can come up with a fix (that doesn't break LSC usage) I'll be very happy to review and merge it :-) 2 seconds sounds fairly arbitrary, are there constraints on that, or could I at least lower it to speed up STREAMOFF? It's arbitrary. The timeout needs to be large enough to wait until the end of the frame in the normal case. I know that normally the data wouldn't stop coming from the sensor until after the CCDC is disabled, when the sensor's s_stream(0) is called. But in this case the sensor is being driven externally, and I'm trying to react to that. The OMAP3 ISP hardware doesn't like that much unfortunately :-S -- Regards, Laurent Pinchart -- 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 16/16] ARM: OMAP: Make plat/omap-pm.h local to mach-omap2
We must move this for ARM common zImage support.
Note that neither drivers/media/rc/ir-rx51.c or
drivers/media/platform/omap3isp/ispvideo.c need
to include omap-pm.h, so this patch removes the
include for those files.
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Timo Kokkonen timo.t.kokko...@iki.fi
Cc: linux-media@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/pm_bus.c |2 --
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
arch/arm/mach-omap2/display.c|2 +-
arch/arm/mach-omap2/dsp.c|2 +-
arch/arm/mach-omap2/gpio.c |2 +-
arch/arm/mach-omap2/hsmmc.c |2 +-
arch/arm/mach-omap2/i2c.c|2 +-
arch/arm/mach-omap2/io.c |2 +-
arch/arm/mach-omap2/omap-pm.h|0
arch/arm/mach-omap2/pm-debug.c |2 +-
arch/arm/mach-omap2/pm.c |2 +-
arch/arm/mach-omap2/serial.c |2 +-
arch/arm/mach-omap2/timer.c |2 +-
arch/arm/plat-omap/dmtimer.c |3 ++-
arch/arm/plat-omap/omap-pm-noop.c|4 +---
drivers/media/platform/omap3isp/ispvideo.c |1 -
drivers/media/rc/ir-rx51.c |1 -
17 files changed, 14 insertions(+), 19 deletions(-)
rename arch/arm/{plat-omap/include/plat/omap-pm.h = mach-omap2/omap-pm.h}
(100%)
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
index 8a74ec5..16bf2f9 100644
--- a/arch/arm/mach-omap1/pm_bus.c
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -19,8 +19,6 @@
#include linux/clk.h
#include linux/err.h
-#include plat/omap-pm.h
-
#ifdef CONFIG_PM_RUNTIME
static int omap1_pm_runtime_suspend(struct device *dev)
{
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index ed85fb8..0199b24 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -33,7 +33,7 @@
#include common.h
#include plat/dma.h
#include plat/gpmc.h
-#include plat/omap-pm.h
+#include omap-pm.h
#include gpmc-smc91x.h
#include board-rx51.h
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 261f79f..bfa3e4c 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -27,7 +27,7 @@
#include video/omapdss.h
#include omap_hwmod.h
#include omap_device.h
-#include plat/omap-pm.h
+#include omap-pm.h
#include common.h
#include iomap.h
diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c
index 9838810..b155500 100644
--- a/arch/arm/mach-omap2/dsp.c
+++ b/arch/arm/mach-omap2/dsp.c
@@ -27,7 +27,7 @@
#include cm2xxx_3xxx.h
#include prm2xxx_3xxx.h
#ifdef CONFIG_BRIDGE_DVFS
-#include plat/omap-pm.h
+#include omap-pm.h
#endif
#include linux/platform_data/dsp-omap.h
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 80b1e1a..399acab 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -25,7 +25,7 @@
#include omap_hwmod.h
#include omap_device.h
-#include plat/omap-pm.h
+#include omap-pm.h
#include powerdomain.h
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index b0b11be..1d5957e 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -18,7 +18,7 @@
#include linux/platform_data/gpio-omap.h
#include mmc.h
-#include plat/omap-pm.h
+#include omap-pm.h
#include omap_device.h
#include mux.h
diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c
index 5904a7a..af4e0de 100644
--- a/arch/arm/mach-omap2/i2c.c
+++ b/arch/arm/mach-omap2/i2c.c
@@ -24,7 +24,7 @@
#include common.h
#include omap_hwmod.h
#include omap_device.h
-#include plat/omap-pm.h
+#include omap-pm.h
#include mux.h
#include i2c.h
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 1e0ba6f..fe807d1 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -26,7 +26,7 @@
#include asm/mach/map.h
#include plat/sdrc.h
-#include plat/omap-pm.h
+#include omap-pm.h
#include omap_hwmod.h
#include plat/dma.h
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/mach-omap2/omap-pm.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/omap-pm.h
rename to arch/arm/mach-omap2/omap-pm.h
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 3e1345f..d6d575f 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -31,7 +31,7 @@
#include powerdomain.h
#include clockdomain.h
#include plat/dmtimer.h
-#include plat/omap-pm.h
+#include omap-pm.h
#include cm2xxx_3xxx.h
#include prm2xxx_3xxx.h
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index bb01ac6..29c82ad 100644
--- a/arch/arm/mach-omap2/pm.c
+++
Re: [PATCH RFC] media: v4l2-ctrl: Add digital gain controls
Hi Prabhakar, Thanks for the patch. On Monday 01 October 2012 19:33:39 Prabhakar wrote: From: Lad, Prabhakar prabhakar@ti.com add support for per color component digital gain controls and also their corresponding offset. Signed-off-by: Lad, Prabhakar prabhakar@ti.com Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Hans Verkuil hans.verk...@cisco.com Cc: Hans de Goede hdego...@redhat.com Cc: Chris MacGregor ch...@cybermato.com Cc: Rob Landley r...@landley.net Cc: Mauro Carvalho Chehab mche...@infradead.org --- Documentation/DocBook/media/v4l/controls.xml | 54 +++ drivers/media/v4l2-core/v4l2-ctrls.c | 11 + include/linux/v4l2-controls.h| 11 + 3 files changed, 76 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index a84a08c..9bf54f3 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4277,6 +4277,60 @@ interface and may change in the future./para specific test patterns can be used to test if a device is working properly./entry /row + row + entry spanname=idconstantV4L2_CID_GAIN_RED/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN_RED/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN_BLUE/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_BLUE/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_GREEN/constant/entry + entryinteger/entry + /row + row + entry spanname=descr Some capture/sensor devices have + the capability to set per color component digital gain values./entry + /row + row + entry spanname=idconstantV4L2_CID_GAIN_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_BLUE_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_RED_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_RED_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=idconstantV4L2_CID_GREEN_BLUE_OFFSET/constant/entry + entryinteger/entry + /row + row + entry spanname=descr Some capture/sensor devices have the + capability to set per color component digital gain offset values. + V4L2_CID_GAIN_OFFSET is the global gain offset and the rest are per + color component gain offsets./entry + /row rowentry/entry/row /tbody /tgroup diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c index 93cd0a4..02cc1d2 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -750,6 +750,17 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_LINK_FREQ:return Link Frequency; case V4L2_CID_PIXEL_RATE: return Pixel Rate; case V4L2_CID_TEST_PATTERN: return Test Pattern; + case V4L2_CID_GAIN_RED: return Digital Gain Red; + case V4L2_CID_GAIN_GREEN_RED: return Digital Gain Green Red; + case V4L2_CID_GAIN_GREEN_BLUE: return Digital Gain Green Blue; + case V4L2_CID_GAIN_BLUE:return Digital Gain Blue; + case V4L2_CID_GAIN_GREEN: return Digital Gain Green; + case V4L2_CID_GAIN_OFFSET: return Digital Gain Offset; + case V4L2_CID_BLUE_OFFSET: return Digital Gain Blue Offset; + case V4L2_CID_RED_OFFSET: return Digital Gain Red Offset; + case V4L2_CID_GREEN_OFFSET: return Digital Gain Green Offset; + case V4L2_CID_GREEN_RED_OFFSET: return Digital Gain Green Red Offset; + case V4L2_CID_GREEN_BLUE_OFFSET:return Digital Gain Green Blue Offset; I would remove the mention of Digital here, as those controls can be used for analog gains as well. Same above in the documentation. /* DV controls */ case V4L2_CID_DV_CLASS: return Digital Video Controls; diff --git
Re: [PATCH 16/16] ARM: OMAP: Make plat/omap-pm.h local to mach-omap2
Hi Tony, Thanks for the patch. On Thursday 04 October 2012 15:05:10 Tony Lindgren wrote: We must move this for ARM common zImage support. Note that neither drivers/media/rc/ir-rx51.c or drivers/media/platform/omap3isp/ispvideo.c need to include omap-pm.h, so this patch removes the include for those files. drivers/media/platform/omap3isp/ispvideo.c used omap-pm.h APIs in the past, we forgot to remove the #include when we changed that. For the OMAP3 ISP driver, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Timo Kokkonen timo.t.kokko...@iki.fi Cc: linux-media@vger.kernel.org Signed-off-by: Tony Lindgren t...@atomide.com -- Regards, Laurent Pinchart -- 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
hvr-1600 fails frequently on multiple recordings
I have a fairly new HVR-1600 which I have seen fail quite a number of times now when it's asked to record more than one channel on a clearqam multiplex. This time it was 3 recordings at once. There's nothing at all in the kernel ring buffer, just mythtv reports a failed recording. Usually one of the files being recorded to will only be 376 bytes long and the rest will be 0 bytes. I am running ubuntu's 3.2.0-27-generic kernel with what looks like a 1.5.1 cx18 driver. The card is either a: 14f1:5b7a Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast Audio Decoder or a: :0016 Internext Compression Inc iTVC16 (CX23416) Video Decoder (rev 01) Sorry. I don't recall which is which any more. But I really need to figure this out since failed recordings is causing all kinds of disappointment around here. I'm really at the end of my rope with it. Tomorrow morning I am going to demote this card to secondary duty and promote my HVR-950Q to primary duty since I never had this kind of grief with it. But even in secondary duty, it could very well be called upon to record multiple clearqam channels simultaneously so I would really like to get this figured out. Any ideas? Cheers, b. signature.asc Description: OpenPGP digital signature
