Re: [PATCHv2 2/4] exynos_hdmi: add HPD notifier support

[Andrzej Hajda]

On 02.01.2017 15:19, Hans Verkuil wrote:
> From: Hans Verkuil 
>
> Implement the HPD notifier support to allow CEC drivers to
> be informed when there is a new EDID and when a connect or
> disconnect happens.
>
> Signed-off-by: Hans Verkuil 
> Tested-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/Kconfig   |  1 +
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 24 +---
>  2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index d706ca4..80bfd1d 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -77,6 +77,7 @@ config DRM_EXYNOS_DP
>  config DRM_EXYNOS_HDMI
>   bool "HDMI"
>   depends on DRM_EXYNOS_MIXER || DRM_EXYNOS5433_DECON
> + select HPD_NOTIFIERS
>   help
> Choose this option if you want to use Exynos HDMI for DRM.
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 5ed8b1e..28bf609 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -118,6 +119,7 @@ struct hdmi_context {
>   booldvi_mode;
>   struct delayed_work hotplug_work;
>   struct drm_display_mode current_mode;
> + struct hpd_notifier *notifier;
>   const struct hdmi_driver_data   *drv_data;
>  
>   void __iomem*regs;
> @@ -807,9 +809,12 @@ static enum drm_connector_status hdmi_detect(struct 
> drm_connector *connector,
>  {
>   struct hdmi_context *hdata = connector_to_hdmi(connector);
>  
> - if (gpiod_get_value(hdata->hpd_gpio))
> + if (gpiod_get_value(hdata->hpd_gpio)) {
> + hpd_event_connect(hdata->notifier);
>   return connector_status_connected;
> + }
>  
> + hpd_event_disconnect(hdata->notifier);
>   return connector_status_disconnected;
>  }
>  
> @@ -848,6 +853,9 @@ static int hdmi_get_modes(struct drm_connector *connector)
>   edid->width_cm, edid->height_cm);
>  
>   drm_mode_connector_update_edid_property(connector, edid);
> + hpd_event_connect(hdata->notifier);

Is there a reason to call hpd_event_connect here? It was called already
from hdmi_detect.

Regards
Andrzej

> + hpd_event_new_edid(hdata->notifier, edid,
> + EDID_LENGTH * (1 + edid->extensions));
>  
>   ret = drm_add_edid_modes(connector, edid);
>  
> @@ -1483,6 +1491,7 @@ static void hdmi_disable(struct drm_encoder *encoder)
>   if (funcs && funcs->disable)
>   (*funcs->disable)(crtc);
>  
> + hpd_event_disconnect(hdata->notifier);
>   cancel_delayed_work(&hdata->hotplug_work);
>  
>   hdmiphy_disable(hdata);
> @@ -1832,15 +1841,22 @@ static int hdmi_probe(struct platform_device *pdev)
>   }
>   }
>  
> + hdata->notifier = hpd_notifier_get(&pdev->dev);
> + if (hdata->notifier == NULL) {
> + ret = -ENOMEM;
> + goto err_hdmiphy;
> + }
> +
>   pm_runtime_enable(dev);
>  
>   ret = component_add(&pdev->dev, &hdmi_component_ops);
>   if (ret)
> - goto err_disable_pm_runtime;
> + goto err_notifier_put;
>  
>   return ret;
>  
> -err_disable_pm_runtime:
> +err_notifier_put:
> + hpd_notifier_put(hdata->notifier);
>   pm_runtime_disable(dev);
>  
>  err_hdmiphy:
> @@ -1859,9 +1875,11 @@ static int hdmi_remove(struct platform_device *pdev)
>   struct hdmi_context *hdata = platform_get_drvdata(pdev);
>  
>   cancel_delayed_work_sync(&hdata->hotplug_work);
> + hpd_event_disconnect(hdata->notifier);
>  
>   component_del(&pdev->dev, &hdmi_component_ops);
>  
> + hpd_notifier_put(hdata->notifier);
>   pm_runtime_disable(&pdev->dev);
>  
>   if (!IS_ERR(hdata->reg_hdmi_en))


--
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: [PATCHv2 1/4] video: add hotplug detect notifier support

[Hans Verkuil]

On 01/03/2017 08:50 AM, Andrzej Hajda wrote:
> Hi Hans,
> 
> On 02.01.2017 15:19, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Add support for video hotplug detect and EDID/ELD notifiers, which is used
>> to convey information from video drivers to their CEC and audio counterparts.
>>
>> Based on an earlier version from Russell King:
>>
>> https://patchwork.kernel.org/patch/9277043/
>>
>> The hpd_notifier is a reference counted object containing the HPD/EDID/ELD 
>> state
>> of a video device.
>>
>> When a new notifier is registered the current state will be reported to
>> that notifier at registration time.
>>
>> Signed-off-by: Hans Verkuil 
>> Tested-by: Marek Szyprowski 
>> ---
>>  drivers/video/Kconfig|   3 +
>>  drivers/video/Makefile   |   1 +
>>  drivers/video/hpd-notifier.c | 134 
>> +++
>>  include/linux/hpd-notifier.h | 109 +++
>>  4 files changed, 247 insertions(+)
>>  create mode 100644 drivers/video/hpd-notifier.c
>>  create mode 100644 include/linux/hpd-notifier.h
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index 3c20af9..cddc860 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
>>  config HDMI
>>  bool
>>  
>> +config HPD_NOTIFIERS
>> +bool
>> +
>>  if VT
>>  source "drivers/video/console/Kconfig"
>>  endif
>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
>> index 9ad3c17..424698b 100644
>> --- a/drivers/video/Makefile
>> +++ b/drivers/video/Makefile
>> @@ -1,5 +1,6 @@
>>  obj-$(CONFIG_VGASTATE)+= vgastate.o
>>  obj-$(CONFIG_HDMI)+= hdmi.o
>> +obj-$(CONFIG_HPD_NOTIFIERS)   += hpd-notifier.o
>>  
>>  obj-$(CONFIG_VT)  += console/
>>  obj-$(CONFIG_LOGO)+= logo/
>> diff --git a/drivers/video/hpd-notifier.c b/drivers/video/hpd-notifier.c
>> new file mode 100644
>> index 000..54f7a6b
>> --- /dev/null
>> +++ b/drivers/video/hpd-notifier.c
>> @@ -0,0 +1,134 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static LIST_HEAD(hpd_notifiers);
>> +static DEFINE_MUTEX(hpd_notifiers_lock);
>> +
>> +struct hpd_notifier *hpd_notifier_get(struct device *dev)
>> +{
>> +struct hpd_notifier *n;
>> +
>> +mutex_lock(&hpd_notifiers_lock);
>> +list_for_each_entry(n, &hpd_notifiers, head) {
>> +if (n->dev == dev) {
>> +mutex_unlock(&hpd_notifiers_lock);
> 
> I think this place is racy, we have pointer to unprotected area
> (n->kref), so if concurrent thread calls hpd_notifier_put in this moment
> &n->kref could be freed and kref_get in the next line will operate on
> dangling pointer. Am I right?

You're right. I took the hpd_notifiers_lock in hpd_notifier_release,
but I should take it in hpd_notifier_put.

Thanks! I'll fix that.

Regards,

Hans

> 
> Regards
> Andrzej
> 
>> +kref_get(&n->kref);
>> +return n;
>> +}
>> +}
>> +n = kzalloc(sizeof(*n), GFP_KERNEL);
>> +if (!n)
>> +goto unlock;
>> +n->dev = dev;
>> +mutex_init(&n->lock);
>> +BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
>> +kref_init(&n->kref);
>> +list_add_tail(&n->head, &hpd_notifiers);
>> +unlock:
>> +mutex_unlock(&hpd_notifiers_lock);
>> +return n;
>> +}
>> +EXPORT_SYMBOL_GPL(hpd_notifier_get);
>> +
>> +static void hpd_notifier_release(struct kref *kref)
>> +{
>> +struct hpd_notifier *n =
>> +container_of(kref, struct hpd_notifier, kref);
>> +
>> +mutex_lock(&hpd_notifiers_lock);
>> +list_del(&n->head);
>> +mutex_unlock(&hpd_notifiers_lock);
>> +kfree(n->edid);
>> +kfree(n);
>> +}
>> +
>> +void hpd_notifier_put(struct hpd_notifier *n)
>> +{
>> +kref_put(&n->kref, hpd_notifier_release);
>> +}
>> +EXPORT_SYMBOL_GPL(hpd_notifier_put);
>> +
>> +int hpd_notifier_register(struct hpd_notifier *n, struct notifier_block *nb)
>> +{
>> +int ret = blocking_notifier_chain_register(&n->notifiers, nb);
>> +
>> +if (ret)
>> +return ret;
>> +kref_get(&n->kref);
>> +mutex_lock(&n->lock);
>> +if (n->connected) {
>> +blocking_notifier_call_chain(&n->notifiers, HPD_CONNECTED, n);
>> +if (n->edid_size)
>> +blocking_notifier_call_chain(&n->notifiers, 
>> HPD_NEW_EDID, n);
>> +if (n->has_eld)
>> +blocking_notifier_call_chain(&n->notifiers, 
>> HPD_NEW_ELD, n);
>> +}
>> +mutex_unlock(&n->lock);
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(hpd_notifier_register);
>> +
>> +int hpd_notifier_unregister(struct hpd_notifier *n, struct notifier_block 
>> *nb)
>> +{
>> +int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
>> +
>> +if (ret == 0)
>> +hpd_notifier_put(n);
>> +return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(hpd_notifier_unregister);
> (...)
> 
> -

Re: [PATCHv2 1/4] video: add hotplug detect notifier support

[Andrzej Hajda]

Hi Hans,

On 02.01.2017 15:19, Hans Verkuil wrote:
> From: Hans Verkuil 
>
> Add support for video hotplug detect and EDID/ELD notifiers, which is used
> to convey information from video drivers to their CEC and audio counterparts.
>
> Based on an earlier version from Russell King:
>
> https://patchwork.kernel.org/patch/9277043/
>
> The hpd_notifier is a reference counted object containing the HPD/EDID/ELD 
> state
> of a video device.
>
> When a new notifier is registered the current state will be reported to
> that notifier at registration time.
>
> Signed-off-by: Hans Verkuil 
> Tested-by: Marek Szyprowski 
> ---
>  drivers/video/Kconfig|   3 +
>  drivers/video/Makefile   |   1 +
>  drivers/video/hpd-notifier.c | 134 
> +++
>  include/linux/hpd-notifier.h | 109 +++
>  4 files changed, 247 insertions(+)
>  create mode 100644 drivers/video/hpd-notifier.c
>  create mode 100644 include/linux/hpd-notifier.h
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af9..cddc860 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
>  config HDMI
>   bool
>  
> +config HPD_NOTIFIERS
> + bool
> +
>  if VT
>   source "drivers/video/console/Kconfig"
>  endif
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 9ad3c17..424698b 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_VGASTATE)+= vgastate.o
>  obj-$(CONFIG_HDMI)+= hdmi.o
> +obj-$(CONFIG_HPD_NOTIFIERS)   += hpd-notifier.o
>  
>  obj-$(CONFIG_VT)   += console/
>  obj-$(CONFIG_LOGO) += logo/
> diff --git a/drivers/video/hpd-notifier.c b/drivers/video/hpd-notifier.c
> new file mode 100644
> index 000..54f7a6b
> --- /dev/null
> +++ b/drivers/video/hpd-notifier.c
> @@ -0,0 +1,134 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static LIST_HEAD(hpd_notifiers);
> +static DEFINE_MUTEX(hpd_notifiers_lock);
> +
> +struct hpd_notifier *hpd_notifier_get(struct device *dev)
> +{
> + struct hpd_notifier *n;
> +
> + mutex_lock(&hpd_notifiers_lock);
> + list_for_each_entry(n, &hpd_notifiers, head) {
> + if (n->dev == dev) {
> + mutex_unlock(&hpd_notifiers_lock);

I think this place is racy, we have pointer to unprotected area
(n->kref), so if concurrent thread calls hpd_notifier_put in this moment
&n->kref could be freed and kref_get in the next line will operate on
dangling pointer. Am I right?

Regards
Andrzej

> + kref_get(&n->kref);
> + return n;
> + }
> + }
> + n = kzalloc(sizeof(*n), GFP_KERNEL);
> + if (!n)
> + goto unlock;
> + n->dev = dev;
> + mutex_init(&n->lock);
> + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
> + kref_init(&n->kref);
> + list_add_tail(&n->head, &hpd_notifiers);
> +unlock:
> + mutex_unlock(&hpd_notifiers_lock);
> + return n;
> +}
> +EXPORT_SYMBOL_GPL(hpd_notifier_get);
> +
> +static void hpd_notifier_release(struct kref *kref)
> +{
> + struct hpd_notifier *n =
> + container_of(kref, struct hpd_notifier, kref);
> +
> + mutex_lock(&hpd_notifiers_lock);
> + list_del(&n->head);
> + mutex_unlock(&hpd_notifiers_lock);
> + kfree(n->edid);
> + kfree(n);
> +}
> +
> +void hpd_notifier_put(struct hpd_notifier *n)
> +{
> + kref_put(&n->kref, hpd_notifier_release);
> +}
> +EXPORT_SYMBOL_GPL(hpd_notifier_put);
> +
> +int hpd_notifier_register(struct hpd_notifier *n, struct notifier_block *nb)
> +{
> + int ret = blocking_notifier_chain_register(&n->notifiers, nb);
> +
> + if (ret)
> + return ret;
> + kref_get(&n->kref);
> + mutex_lock(&n->lock);
> + if (n->connected) {
> + blocking_notifier_call_chain(&n->notifiers, HPD_CONNECTED, n);
> + if (n->edid_size)
> + blocking_notifier_call_chain(&n->notifiers, 
> HPD_NEW_EDID, n);
> + if (n->has_eld)
> + blocking_notifier_call_chain(&n->notifiers, 
> HPD_NEW_ELD, n);
> + }
> + mutex_unlock(&n->lock);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(hpd_notifier_register);
> +
> +int hpd_notifier_unregister(struct hpd_notifier *n, struct notifier_block 
> *nb)
> +{
> + int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
> +
> + if (ret == 0)
> + hpd_notifier_put(n);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(hpd_notifier_unregister);
(...)

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] media: Properly pass through media entity types in entity enumeration

[Sakari Ailus]

When the functions replaced media entity types, the range which was
allowed for the types was incorrect. This meant that media entity types
for specific devices were not passed correctly to the userspace through
MEDIA_IOC_ENUM_ENTITIES. Fix it.

Fixes: commit b2cd27448b33 ("[media] media-device: map new functions into old 
types for legacy API")
Reported-and-tested-by: Antti Laakso 
Signed-off-by: Sakari Ailus 
---
Should go to stable as well. I'll add cc stable to the pull request later
on.

 drivers/media/media-device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 8756275..8927456 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -130,7 +130,7 @@ static long media_device_enum_entities(struct media_device 
*mdev,
 * old range.
 */
if (ent->function < MEDIA_ENT_F_OLD_BASE ||
-   ent->function > MEDIA_ENT_T_DEVNODE_UNKNOWN) {
+   ent->function > MEDIA_ENT_F_TUNER) {
if (is_media_entity_v4l2_subdev(ent))
entd->type = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN;
else if (ent->function != MEDIA_ENT_F_IO_V4L)
-- 
2.1.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 2/2] rainshadow-cec: new RainShadow Tech HDMI CEC driver

[Dmitry Torokhov]

Hi Hans,

On Thu, Dec 15, 2016 at 02:02:07PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This driver supports the RainShadow Tech USB HDMI CEC adapter.
> 
> See: http://rainshadowtech.com/HdmiCecUsb.html
> 
> Signed-off-by: Hans Verkuil 
> ---
>  MAINTAINERS   |   7 +
>  drivers/media/usb/Kconfig |   1 +
>  drivers/media/usb/Makefile|   1 +
>  drivers/media/usb/rainshadow-cec/Kconfig  |  10 +
>  drivers/media/usb/rainshadow-cec/Makefile |   1 +
>  drivers/media/usb/rainshadow-cec/rainshadow-cec.c | 344 
> ++
>  6 files changed, 364 insertions(+)
>  create mode 100644 drivers/media/usb/rainshadow-cec/Kconfig
>  create mode 100644 drivers/media/usb/rainshadow-cec/Makefile
>  create mode 100644 drivers/media/usb/rainshadow-cec/rainshadow-cec.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 52cc077..78ebc5d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10069,6 +10069,13 @@ L:   linux-fb...@vger.kernel.org
>  S:   Maintained
>  F:   drivers/video/fbdev/aty/aty128fb.c
>  
> +RAINSHADOW-CEC DRIVER
> +M:   Hans Verkuil 
> +L:   linux-media@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Maintained
> +F:   drivers/media/usb/rainshadow-cec/*
> +
>  RALINK MIPS ARCHITECTURE
>  M:   John Crispin 
>  L:   linux-m...@linux-mips.org
> diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig
> index c9644b6..b24e753 100644
> --- a/drivers/media/usb/Kconfig
> +++ b/drivers/media/usb/Kconfig
> @@ -63,6 +63,7 @@ endif
>  if MEDIA_CEC_SUPPORT
>   comment "USB HDMI CEC adapters"
>  source "drivers/media/usb/pulse8-cec/Kconfig"
> +source "drivers/media/usb/rainshadow-cec/Kconfig"
>  endif
>  
>  endif #MEDIA_USB_SUPPORT
> diff --git a/drivers/media/usb/Makefile b/drivers/media/usb/Makefile
> index 0f15e33..738b993 100644
> --- a/drivers/media/usb/Makefile
> +++ b/drivers/media/usb/Makefile
> @@ -25,3 +25,4 @@ obj-$(CONFIG_VIDEO_USBTV) += usbtv/
>  obj-$(CONFIG_VIDEO_GO7007) += go7007/
>  obj-$(CONFIG_DVB_AS102) += as102/
>  obj-$(CONFIG_USB_PULSE8_CEC) += pulse8-cec/
> +obj-$(CONFIG_USB_RAINSHADOW_CEC) += rainshadow-cec/
> diff --git a/drivers/media/usb/rainshadow-cec/Kconfig 
> b/drivers/media/usb/rainshadow-cec/Kconfig
> new file mode 100644
> index 000..447291b
> --- /dev/null
> +++ b/drivers/media/usb/rainshadow-cec/Kconfig
> @@ -0,0 +1,10 @@
> +config USB_RAINSHADOW_CEC
> + tristate "RainShadow Tech HDMI CEC"
> + depends on USB_ACM && MEDIA_CEC_SUPPORT
> + select SERIO
> + select SERIO_SERPORT
> + ---help---
> +   This is a cec driver for the RainShadow Tech HDMI CEC device.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called rainshadow-cec.
> diff --git a/drivers/media/usb/rainshadow-cec/Makefile 
> b/drivers/media/usb/rainshadow-cec/Makefile
> new file mode 100644
> index 000..a79fbc7
> --- /dev/null
> +++ b/drivers/media/usb/rainshadow-cec/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_USB_RAINSHADOW_CEC) += rainshadow-cec.o
> diff --git a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c 
> b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
> new file mode 100644
> index 000..dc7f287
> --- /dev/null
> +++ b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
> @@ -0,0 +1,344 @@
> +/*
> + * RainShadow Tech HDMI CEC driver
> + *
> + * Copyright 2016 Hans Verkuil  + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version of 2 of the License, or (at your
> + * option) any later version. See the file COPYING in the main directory of
> + * this archive for more details.
> + */
> +
> +/*
> + * Notes:
> + *
> + * The higher level protocols are currently disabled. This can be added
> + * later, similar to how this is done for the Pulse Eight CEC driver.
> + *
> + * Documentation of the protocol is available here:
> + *
> + * http://rainshadowtech.com/doc/HDMICECtoUSBandRS232v2.0.pdf
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +MODULE_AUTHOR("Hans Verkuil ");
> +MODULE_DESCRIPTION("RainShadow Tech HDMI CEC driver");
> +MODULE_LICENSE("GPL");
> +
> +static int debug;
> +module_param(debug, int, 0644);
> +MODULE_PARM_DESC(debug, "debug level (0-1)");
> +
> +#define DATA_SIZE 256
> +
> +struct rain {
> + struct device *dev;
> + struct serio *serio;
> + struct cec_adapter *adap;
> + struct completion cmd_done;
> + struct work_struct work;
> + struct cec_msg rx_msg;
> + char data[DATA_SIZE];
> + char buf[DATA_SIZE];
> + unsigned int idx;
> + bool started;
> + struct mutex write_lock;
> +};
> +
> +static void rain_irq_work_handler(struct work_struct *work)
> +{
> +  

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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:   Tue Jan  3 05:00:10 CET 2017
media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a
media_build git hash:   1606032398b1d79149c1507be2029e1a00d8dff0
v4l-utils git hash: 951c4878a93f4722146f8bc6515a47fba6470bb3
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9-x86_64: ERRORS
apps: WARNINGS
spec-git: ERRORS
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] cx231xx: Initial support for Evromedia USB Full Hybrid Full HD

[Oleh Kravchenko]

Tested with Kaffeine https://kaffeine.kde.org/

dmesg output:
usb 3-4: new high-speed USB device number 3 using ehci-pci
usb 3-4: New USB device found, idVendor=1b80, idProduct=d3b2
usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-4: Product: Polaris AV Capture
usb 3-4: Manufacturer: Conexant Corporation
usb 3-4: SerialNumber: 00
cx231xx 3-4:1.1: New device Conexant Corporation Polaris AV Capture @
480 Mbps (1b80:d3b2) with 7 interfaces
cx231xx 3-4:1.1: Identified as Evromedia USB Full Hybrid Full HD (card=23)
i2c i2c-6: Added multiplexed i2c bus 8
i2c i2c-6: Added multiplexed i2c bus 9
cx231xx 3-4:1.1: v4l2 driver version 0.0.3
cx231xx 3-4:1.1: Unknown tuner type configuring SIF
cx231xx 3-4:1.1: Registered video device video1 [v4l2]
cx231xx 3-4:1.1: Registered VBI device vbi0
cx231xx 3-4:1.1: audio EndPoint Addr 0x83, Alternate settings: 3
i2c i2c-9: Added multiplexed i2c bus 10
si2168 9-0064: Silicon Labs Si2168-A30 successfully identified
si2168 9-0064: firmware version: A 3.0.2
si2157 7-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached
DVB: registering new adapter (cx231xx #0)
cx231xx 3-4:1.1: DVB: registering adapter 0 frontend 0 (Silicon Labs
Si2168)...
cx231xx 3-4:1.1: Successfully loaded cx231xx-dvb
cx231xx 3-4:1.1: video EndPoint Addr 0x84, Alternate settings: 5
cx231xx 3-4:1.1: VBI EndPoint Addr 0x85, Alternate settings: 2
cx231xx 3-4:1.1: sliced CC EndPoint Addr 0x86, Alternate settings: 2
cx231xx 3-4:1.1: TS EndPoint Addr 0x81, Alternate settings: 6
si2168 9-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw'
si2168 9-0064: firmware version: A 3.0.19
si2157 7-0060: found a 'Silicon Labs Si2158-A20'
si2157 7-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw'
si2157 7-0060: firmware version: 2.1.9

Tested-by: Oleh Kravchenko 

On 01.01.17 19:28, Oleh Kravchenko wrote:
> Add initial support for the Evromedia USB Full Hybrid Full HD
> with USB ID 1b80:d3b2.
> 
> Status:
> - DVB-T2 works fine;
> - Analog not implemented.
> 
> Signed-off-by: Oleh Kravchenko 
> ---
>  drivers/media/usb/cx231xx/Kconfig |  1 +
>  drivers/media/usb/cx231xx/cx231xx-cards.c | 16 +++
>  drivers/media/usb/cx231xx/cx231xx-dvb.c   | 74 
> +++
>  drivers/media/usb/cx231xx/cx231xx-i2c.c   | 37 
>  drivers/media/usb/cx231xx/cx231xx.h   |  1 +
>  5 files changed, 129 insertions(+)
> 
> diff --git a/drivers/media/usb/cx231xx/Kconfig 
> b/drivers/media/usb/cx231xx/Kconfig
> index 0cced3e..58de80b 100644
> --- a/drivers/media/usb/cx231xx/Kconfig
> +++ b/drivers/media/usb/cx231xx/Kconfig
> @@ -50,6 +50,7 @@ config VIDEO_CX231XX_DVB
>   select DVB_LGDT3306A if MEDIA_SUBDRV_AUTOSELECT
>   select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
>   select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
> + select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
>   select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
>  
>   ---help---
> diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
> b/drivers/media/usb/cx231xx/cx231xx-cards.c
> index 36bc254..380aff7 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-cards.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
> @@ -841,6 +841,20 @@ struct cx231xx_board cx231xx_boards[] = {
>   .gpio = NULL,
>   } },
>   },
> + [CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD] = {
> + .name = "Evromedia USB Full Hybrid Full HD",
> + .tuner_type = TUNER_ABSENT,
> + .has_dvb = 1,
> + .demod_i2c_master = I2C_1_MUX_3,
> + .demod_addr = 0xc8 >> 1,
> + .tuner_i2c_master = I2C_2,
> + .tuner_addr = 0xc0 >> 1,
> + .input = {{
> + .type = CX231XX_VMUX_TELEVISION,
> + .vmux = 0,
> + .amux = CX231XX_AMUX_VIDEO,
> + } },
> + },
>  };
>  const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
>  
> @@ -908,6 +922,8 @@ struct usb_device_id cx231xx_id_table[] = {
>.driver_info = CX231XX_BOARD_OTG102},
>   {USB_DEVICE(USB_VID_TERRATEC, 0x00a6),
>.driver_info = CX231XX_BOARD_TERRATEC_GRABBY},
> + {USB_DEVICE(0x1b80, 0xd3b2),
> + .driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
>   {},
>  };
>  
> diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
> b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> index 1417515..131c1e2 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> @@ -33,6 +33,7 @@
>  #include "s5h1411.h"
>  #include "lgdt3305.h"
>  #include "si2165.h"
> +#include "si2168.h"
>  #include "mb86a20s.h"
>  #include "si2157.h"
>  #include "lgdt3306a.h"
> @@ -949,6 +950,79 @@ static int dvb_init(struct cx231xx *dev)
>  &pv_tda18271_config);
>   break;
>  
> + case CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD:
> + {
> + struct si21

Re: [PATCH 00/15] atmel-isi/ov7670/ov2640: convert to standalone drivers

[Sakari Ailus]

On Mon, Jan 02, 2017 at 02:41:47PM +0100, Hans Verkuil wrote:
> On 01/02/17 14:37, Hans Verkuil wrote:
> >On 12/18/16 23:10, Sakari Ailus wrote:
> >>On Mon, Dec 12, 2016 at 04:55:05PM +0100, Hans Verkuil wrote:
> >>>From: Hans Verkuil 
> >>>
> >>>This patch series converts the soc-camera atmel-isi to a standalone V4L2
> >>>driver.
> >>>
> >>>The same is done for the ov7670 and ov2640 sensor drivers: the ov7670 was
> >>>used to test the atmel-isi driver. The ov2640 is needed because the em28xx
> >>>driver has a soc_camera include dependency. Both ov7670 and ov2640 sensors
> >>>have been tested with the atmel-isi driver.
> >>>
> >>>The first 6 patches improve the ov7670 sensor driver, mostly adding modern
> >>>features such as MC and DT support.
> >>>
> >>>The next three convert the atmel-isi and move it out of soc_camera.
> >>
> >>You're adding Media controller support but without device nodes. Does that
> >>make sense? You'll have an entity but the user won't be able to do anything
> >>with it.
> >>
> >
> >Well, without the MC support the sensor driver wouldn't load since the atmel
> >driver expects that the subdev is MC-enabled. However, the atmel-isi doesn't
> >need the user to configure the pipeline, it's just a simple standard v4l 
> >driver.
> >
> >So just filling in the entity information is sufficient in this case.
> >
> >That said, I see that the atmel-isi driver calls 
> >v4l2_device_register_subdev_nodes().
> >Since this is a simple V4L driver, that call should probably be dropped, 
> >since
> >we really don't want or need subdev nodes.
> >
> >I will also need to take another look at the atmel-isi code to see if this MC
> >dependency is really needed: I think I copied some of that code from the rcar
> >driver, and it may not be relevant for the atmel driver.
> 
> In fact, I don't think it is needed at all.
> 
> But does it hurt to add MC support to these ov drivers?

Certainly not, as long as it doesn't cause issues with non-MC aware bridge
drivers. If the sensor drivers have MC support as well they can be used with
MC aware bridge / ISP drivers.

If there are issues we definitely have to fix them, otherwise there'll be
two different kinds of sensor drivers again. I guess it's again been that
the group of sensors that have MC-aware ISPs connected to them is distinct
from the other group using non-MC-aware bridges? :-)

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 00/20] i.MX Media Driver

[Fabio Estevam]

Hi Steve,

On Thu, Dec 29, 2016 at 8:27 PM, Steve Longerbeam  wrote:
> This is a media driver for video capture on i.MX.
>
> Refer to Documentation/media/v4l-drivers/imx.rst for example capture
> pipelines on SabreSD, SabreAuto, and SabreLite reference platforms.
>
> This patchset includes the OF graph layout as proposed by Philipp Zabel,
> with only minor changes which are enumerated in the patch header.

Patches 13, 14 and 19 miss your Signed-off-by tag.

Tested the whole series on a mx6qsabresd:

Tested-by: Fabio Estevam 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] smiapp: Use runtime PM for power iff CONFIG_PM is defined

[Sakari Ailus]

If CONFIG_PM is defined, always use runtime PM to manage power to the
device. Controlling the power state directly in probe does have the
problem of ignoring the device parent power management. Fix this.

Fixes: commit 9447082ae666 ("[media] smiapp: Implement power-on and power-off 
sequences without runtime PM")
Signed-off-by: Sakari Ailus 
Cc: Alan Stern 
---
 drivers/media/i2c/smiapp/smiapp-core.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
b/drivers/media/i2c/smiapp/smiapp-core.c
index e290601..0ea0303 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2904,9 +2904,16 @@ static int smiapp_probe(struct i2c_client *client,
if (IS_ERR(sensor->xshutdown))
return PTR_ERR(sensor->xshutdown);
 
+   pm_runtime_set_suspended(&client->dev);
+   pm_runtime_enable(&client->dev);
+   rval = pm_runtime_get_sync(&client->dev);
+   if (rval < 0)
+   goto out_power_off;
+#ifndef CONFIG_PM
rval = smiapp_power_on(&client->dev);
if (rval < 0)
return rval;
+#endif
 
rval = smiapp_identify_module(sensor);
if (rval) {
@@ -3087,12 +3094,12 @@ static int smiapp_probe(struct i2c_client *client,
if (rval < 0)
goto out_media_entity_cleanup;
 
-   pm_runtime_set_active(&client->dev);
-   pm_runtime_get_noresume(&client->dev);
-   pm_runtime_enable(&client->dev);
pm_runtime_set_autosuspend_delay(&client->dev, 1000);
pm_runtime_use_autosuspend(&client->dev);
pm_runtime_put_autosuspend(&client->dev);
+#ifndef CONFIG_PM
+   smiapp_power_off(&client->dev);
+#endif
 
return 0;
 
@@ -3103,7 +3110,10 @@ static int smiapp_probe(struct i2c_client *client,
smiapp_cleanup(sensor);
 
 out_power_off:
+   pm_runtime_put_sync(&client->dev);
+#ifndef CONFIG_PM
smiapp_power_off(&client->dev);
+#endif
 
return rval;
 }
@@ -3118,8 +3128,11 @@ static int smiapp_remove(struct i2c_client *client)
 
pm_runtime_disable(&client->dev);
if (!pm_runtime_status_suspended(&client->dev))
-   smiapp_power_off(&client->dev);
+   pm_runtime_suspend(&client->dev);
pm_runtime_set_suspended(&client->dev);
+#ifndef CONFIG_PM
+   smiapp_power_off(&client->dev);
+#endif
 
for (i = 0; i < sensor->ssds_used; i++) {
v4l2_device_unregister_subdev(&sensor->ssds[i].sd);
-- 
2.1.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 v2 00/21] Basic i.MX IPUv3 capture support

[Steve Longerbeam]

Hi JM,


On 01/02/2017 06:59 AM, Jean-Michel Hautbois wrote:


Steve: which branch is the correct one on your github ?


branch imx-media-staging-md-v4 on
g...@github.com:slongerbeam/mediatree.git

Steve

--
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 00/21] Basic i.MX IPUv3 capture support

[Fabio Estevam]

Hi Jean-Michel,

On Mon, Jan 2, 2017 at 12:59 PM, Jean-Michel Hautbois
 wrote:

> Steve: which branch is the correct one on your github ?

I have tested imx-media-staging-md-v2 (based on 4.9-rc) and also
imx-media-staging-md-v4 branch, which is based on 4.10-rc1.
--
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 00/21] Basic i.MX IPUv3 capture support

[Steve Longerbeam]

Hi Hans,


On 01/02/2017 06:45 AM, Hans Verkuil wrote:

On 01/02/17 14:51, Jean-Michel Hautbois wrote:

Hi,

2016-12-30 21:26 GMT+01:00 Steve Longerbeam 
:



On 12/30/2016 11:06 AM, Marek Vasut wrote:


On 12/29/2016 09:51 PM, Robert Schwebel wrote:


Hi Jean-Michel,


Hi,


On Thu, Dec 29, 2016 at 04:08:33PM +0100, Jean-Michel Hautbois wrote:


What is the status of this work?


Philipp's patches have been reworked with the review feedback from 
the

last round and a new version will be posted when he is back from
holidays.


IMO Philipp's patches are better integrated and well structured, so 
I'd

rather like to see his work in at some point.



Granted I am biased, but I will state my case. "Better integrated" - my
patches
are also well integrated with the media core infrastructure. Philipp's
patches
in fact require modification to media core, whereas mine require none.
Some changes are needed of course (more subdev type definitions for
one).

As for "well structured", I don't really understand what is meant by 
that,

but my driver is also well structured.

Philipp's driver only supports unconverted image capture from the 
SMFC. In

addition
to that, mine allows for all the hardware links supported by the IPU,
including routing
frames from the CSI directly to the Image converter for scaling up to
4096x4096,
colorspace conversion, rotation, and motion compensated 
de-interlace. Yes

all these
conversion can be carried out post-capture via a mem2mem device, but
conversion
directly from CSI capture has advantages, including minimized CPU
utilization and
lower AXI bus traffic. In any case, Freescale added these hardware 
paths,

and my
driver supports them.


I had a deeper look to both drivers, and I must say the features of
Steve's one are really interesting.
I don't think any of those has been tested with digital inputs (I have
ADV76xx chips on my board, which I hope will be available one day for
those interested) and so, I can test and help adding some of the
missing parts.
And for at least a week or two, I have all of my time for it, so it
would be of great help to know which one has the bigger chance to be
integrated... :)


Steve's series is definitely preferred from my point of view. The feature
set is clearly superior to Philipp's driver.

I plan on reviewing Steve's series soonish but a quick scan didn't see 
anything
suspicious. The code looks clean, and I am leaning towards getting 
this in sooner
rather than later, so if you have the time to work on this, then go 
for it!


Steve, I have a SabreLite and a ov5642 sensor, so I should be able to 
test

that driver.


Ok, just remember to disable the ov5640 node in imx6qdl-sabrelite.dtsi,
otherwise the driver will expect to see an async registration callback from
the ov5640.



There is also an ov5642 sensor driver in 
drivers/media/i2/soc_camera/ov5642.c.
But nobody AFAIK is using it, so I would be inclined to take your code 
and

remove the soc_camera driver.


Ok, and at some point ov5642.c and ov5640_mipi.c need to be merged into 
a single
ov564x.c, cleaned up (get rid of, or significantly prune, those huge 
register tables - they
were created by FSL by dumping the i2c register set after a reset, so 
they consist mostly

of the POR register values), and finally moved to drivers/media/i2c.

Steve


--
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

Urgent Please;;

[Dr. David White]

Dear,
With due respect to your person and much sincerity of purpose. I have a 
business proposal which I will like to handle with you and $14.5 Million USD is 
involve. But be rest assured that everything is legal and risk free as I have 
concluded all the arrangements and the legal papers that will back the 
transaction up. Kindly indicate your interest as to enable me tell you more 
detail of the proposal. Waiting for your urgent response.

Yours Faithfully,
Dr. David White
--
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: [PATCHv2 4/4] s5p-cec: add hpd-notifier support, move out of staging

[Krzysztof Kozlowski]

On Mon, Jan 02, 2017 at 03:19:07PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> By using the HPD notifier framework there is no longer any reason
> to manually set the physical address. This was the one blocking
> issue that prevented this driver from going out of staging, so do
> this move as well.
> 
> Update the bindings documenting the new hdmi phandle and
> update exynos4.dtsi accordingly.
> 
> Tested with my Odroid U3.
> 
> Signed-off-by: Hans Verkuil 
> Tested-by: Marek Szyprowski 
> ---
>  .../devicetree/bindings/media/s5p-cec.txt  |  2 ++
>  arch/arm/boot/dts/exynos4.dtsi |  1 +
>  drivers/media/platform/Kconfig | 18 +++
>  drivers/media/platform/Makefile|  1 +
>  .../media => media/platform}/s5p-cec/Makefile  |  0
>  .../platform}/s5p-cec/exynos_hdmi_cec.h|  0
>  .../platform}/s5p-cec/exynos_hdmi_cecctrl.c|  0
>  .../media => media/platform}/s5p-cec/regs-cec.h|  0
>  .../media => media/platform}/s5p-cec/s5p_cec.c | 35 
> ++
>  .../media => media/platform}/s5p-cec/s5p_cec.h |  3 ++
>  drivers/staging/media/Kconfig  |  2 --
>  drivers/staging/media/Makefile |  1 -
>  drivers/staging/media/s5p-cec/Kconfig  |  9 --
>  drivers/staging/media/s5p-cec/TODO |  7 -
>  14 files changed, 55 insertions(+), 24 deletions(-)
>  rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h 
> (100%)
>  rename drivers/{staging/media => 
> media/platform}/s5p-cec/exynos_hdmi_cecctrl.c (100%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
>  rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
>  delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
>  delete mode 100644 drivers/staging/media/s5p-cec/TODO
> 
> diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
> b/Documentation/devicetree/bindings/media/s5p-cec.txt
> index 925ab4d..710fc00 100644
> --- a/Documentation/devicetree/bindings/media/s5p-cec.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
> @@ -15,6 +15,7 @@ Required properties:
>- clock-names : from common clock binding: must contain "hdmicec",
> corresponding to entry in the clocks property.
>- samsung,syscon-phandle - phandle to the PMU system controller
> +  - samsung,hdmi-phandle - phandle to the HDMI controller
>  
>  Example:
>  
> @@ -25,6 +26,7 @@ hdmicec: cec@100B {
>   clocks = <&clock CLK_HDMI_CEC>;
>   clock-names = "hdmicec";
>   samsung,syscon-phandle = <&pmu_system_controller>;
> + samsung,hdmi-phandle = <&hdmi>;
>   pinctrl-names = "default";
>   pinctrl-0 = <&hdmi_cec>;
>   status = "okay";
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index c64737b..51dfcbb 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -762,6 +762,7 @@
>   clocks = <&clock CLK_HDMI_CEC>;
>   clock-names = "hdmicec";
>   samsung,syscon-phandle = <&pmu_system_controller>;
> + samsung,hdmi-phandle = <&hdmi>;
>   pinctrl-names = "default";
>   pinctrl-0 = <&hdmi_cec>;
>   status = "disabled";

DTS change has to be a separate patch. It should also go through
arm-soc/samsung-soc tree.

If it is a dependency, then I could provide a tag with it.

Best regards,
Krzysztof

> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index d944421..cab1637 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -392,6 +392,24 @@ config VIDEO_TI_SC
>  config VIDEO_TI_CSC
>   tristate
>  
> +menuconfig V4L_CEC_DRIVERS
> + bool "Platform HDMI CEC drivers"
> + depends on MEDIA_CEC_SUPPORT
> +
> +if V4L_CEC_DRIVERS
> +
> +config VIDEO_SAMSUNG_S5P_CEC
> +   tristate "Samsung S5P CEC driver"
> +   depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (PLAT_S5P || ARCH_EXYNOS 
> || COMPILE_TEST)
> +   select HPD_NOTIFIERS
> +   ---help---
> + This is a driver for Samsung S5P HDMI CEC interface. It uses the
> + generic CEC framework interface.
> + CEC bus is present in the HDMI connector and enables communication
> + between compatible devices.
> +
> +endif #V4L_CEC_DRIVERS
> +
>  menuconfig V4L_TEST_DRIVERS
>   bool "Media test drivers"
>   depends on MEDIA_CAMERA_SUPPORT
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 5b3cb27..ad3bf22 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)+= s5p-jpeg/
>  obj-$(CONFIG_VID

Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support

[Fabio Estevam]

On Mon, Jan 2, 2017 at 12:45 PM, Hans Verkuil  wrote:

> Steve's series is definitely preferred from my point of view. The feature
> set is clearly superior to Philipp's driver.
>
> I plan on reviewing Steve's series soonish but a quick scan didn't see
> anything
> suspicious. The code looks clean, and I am leaning towards getting this in
> sooner
> rather than later, so if you have the time to work on this, then go for it!

This is good news!

I had a chance to test Steve's series on a mx6qsabresd and it worked fine.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support

[Jean-Michel Hautbois]

2017-01-02 15:45 GMT+01:00 Hans Verkuil :
> On 01/02/17 14:51, Jean-Michel Hautbois wrote:
>>
>> Hi,
>>
>> 2016-12-30 21:26 GMT+01:00 Steve Longerbeam :
>>>
>>>
>>>
>>> On 12/30/2016 11:06 AM, Marek Vasut wrote:


 On 12/29/2016 09:51 PM, Robert Schwebel wrote:
>
>
> Hi Jean-Michel,


 Hi,

> On Thu, Dec 29, 2016 at 04:08:33PM +0100, Jean-Michel Hautbois wrote:
>>
>>
>> What is the status of this work?
>
>
> Philipp's patches have been reworked with the review feedback from the
> last round and a new version will be posted when he is back from
> holidays.


 IMO Philipp's patches are better integrated and well structured, so I'd
 rather like to see his work in at some point.
>>>
>>>
>>>
>>> Granted I am biased, but I will state my case. "Better integrated" - my
>>> patches
>>> are also well integrated with the media core infrastructure. Philipp's
>>> patches
>>> in fact require modification to media core, whereas mine require none.
>>> Some changes are needed of course (more subdev type definitions for
>>> one).
>>>
>>> As for "well structured", I don't really understand what is meant by
>>> that,
>>> but my driver is also well structured.
>>>
>>> Philipp's driver only supports unconverted image capture from the SMFC.
>>> In
>>> addition
>>> to that, mine allows for all the hardware links supported by the IPU,
>>> including routing
>>> frames from the CSI directly to the Image converter for scaling up to
>>> 4096x4096,
>>> colorspace conversion, rotation, and motion compensated de-interlace. Yes
>>> all these
>>> conversion can be carried out post-capture via a mem2mem device, but
>>> conversion
>>> directly from CSI capture has advantages, including minimized CPU
>>> utilization and
>>> lower AXI bus traffic. In any case, Freescale added these hardware paths,
>>> and my
>>> driver supports them.
>>
>>
>> I had a deeper look to both drivers, and I must say the features of
>> Steve's one are really interesting.
>> I don't think any of those has been tested with digital inputs (I have
>> ADV76xx chips on my board, which I hope will be available one day for
>> those interested) and so, I can test and help adding some of the
>> missing parts.
>> And for at least a week or two, I have all of my time for it, so it
>> would be of great help to know which one has the bigger chance to be
>> integrated... :)
>
>
> Steve's series is definitely preferred from my point of view. The feature
> set is clearly superior to Philipp's driver.
>
> I plan on reviewing Steve's series soonish but a quick scan didn't see
> anything
> suspicious. The code looks clean, and I am leaning towards getting this in
> sooner
> rather than later, so if you have the time to work on this, then go for it!

Glad to here it !

> Steve, I have a SabreLite and a ov5642 sensor, so I should be able to test
> that driver.
>
> There is also an ov5642 sensor driver in
> drivers/media/i2/soc_camera/ov5642.c.
> But nobody AFAIK is using it, so I would be inclined to take your code and
> remove the soc_camera driver.

Steve: which branch is the correct one on your github ?
Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] [media] v4l2-core: Fine-tuning for some function implementations

[Hans Verkuil]

On 12/27/16 12:51, Sakari Ailus wrote:

Hi Markus,

On Mon, Dec 26, 2016 at 09:41:19PM +0100, SF Markus Elfring wrote:

From: Markus Elfring 
Date: Mon, 26 Dec 2016 21:30:12 +0100

Some update suggestions were taken into account
from static source code analysis.

Markus Elfring (8):
  v4l2-async: Use kmalloc_array() in v4l2_async_notifier_unregister()
  v4l2-async: Delete an error message for a failed memory allocation in 
v4l2_async_notifier_unregister()
  videobuf-dma-sg: Use kmalloc_array() in videobuf_dma_init_user_locked()
  videobuf-dma-sg: Adjust 24 checks for null values
  videobuf-dma-sg: Move two assignments for error codes in 
__videobuf_mmap_mapper()
  videobuf-dma-sg: Improve a size determination in __videobuf_mmap_mapper()
  videobuf-dma-sg: Delete an unnecessary return statement in videobuf_vm_close()
  videobuf-dma-sg: Add some spaces for better code readability in 
videobuf_dma_init_user_locked()


I don't really disagree with the videobuf changes as such --- the original
code sure seems quite odd, but I wonder whether we want to do this kind of
cleanups in videobuf. Videobuf will be removed likely in not too distant
future; when exactly, Hans can guesstimate better than me. Cc him.



The videobuf code is frozen as far as I am concerned, and I won't pick up
these cleanup patches. While they look perfectly reasonable, I don't want
to risk any breakage there. The last thing I want to do is to have to debug
in the videobuf code.

Sorry Markus, just stay away from the videobuf-* sources.

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 00/21] Basic i.MX IPUv3 capture support

[Hans Verkuil]

On 01/02/17 14:51, Jean-Michel Hautbois wrote:

Hi,

2016-12-30 21:26 GMT+01:00 Steve Longerbeam :



On 12/30/2016 11:06 AM, Marek Vasut wrote:


On 12/29/2016 09:51 PM, Robert Schwebel wrote:


Hi Jean-Michel,


Hi,


On Thu, Dec 29, 2016 at 04:08:33PM +0100, Jean-Michel Hautbois wrote:


What is the status of this work?


Philipp's patches have been reworked with the review feedback from the
last round and a new version will be posted when he is back from
holidays.


IMO Philipp's patches are better integrated and well structured, so I'd
rather like to see his work in at some point.



Granted I am biased, but I will state my case. "Better integrated" - my
patches
are also well integrated with the media core infrastructure. Philipp's
patches
in fact require modification to media core, whereas mine require none.
Some changes are needed of course (more subdev type definitions for
one).

As for "well structured", I don't really understand what is meant by that,
but my driver is also well structured.

Philipp's driver only supports unconverted image capture from the SMFC. In
addition
to that, mine allows for all the hardware links supported by the IPU,
including routing
frames from the CSI directly to the Image converter for scaling up to
4096x4096,
colorspace conversion, rotation, and motion compensated de-interlace. Yes
all these
conversion can be carried out post-capture via a mem2mem device, but
conversion
directly from CSI capture has advantages, including minimized CPU
utilization and
lower AXI bus traffic. In any case, Freescale added these hardware paths,
and my
driver supports them.


I had a deeper look to both drivers, and I must say the features of
Steve's one are really interesting.
I don't think any of those has been tested with digital inputs (I have
ADV76xx chips on my board, which I hope will be available one day for
those interested) and so, I can test and help adding some of the
missing parts.
And for at least a week or two, I have all of my time for it, so it
would be of great help to know which one has the bigger chance to be
integrated... :)


Steve's series is definitely preferred from my point of view. The feature
set is clearly superior to Philipp's driver.

I plan on reviewing Steve's series soonish but a quick scan didn't see anything
suspicious. The code looks clean, and I am leaning towards getting this in 
sooner
rather than later, so if you have the time to work on this, then go for it!

Steve, I have a SabreLite and a ov5642 sensor, so I should be able to test
that driver.

There is also an ov5642 sensor driver in drivers/media/i2/soc_camera/ov5642.c.
But nobody AFAIK is using it, so I would be inclined to take your code and
remove the soc_camera driver.

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

[PATCHv2 1/4] video: add hotplug detect notifier support

[Hans Verkuil]

From: Hans Verkuil 

Add support for video hotplug detect and EDID/ELD notifiers, which is used
to convey information from video drivers to their CEC and audio counterparts.

Based on an earlier version from Russell King:

https://patchwork.kernel.org/patch/9277043/

The hpd_notifier is a reference counted object containing the HPD/EDID/ELD state
of a video device.

When a new notifier is registered the current state will be reported to
that notifier at registration time.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
---
 drivers/video/Kconfig|   3 +
 drivers/video/Makefile   |   1 +
 drivers/video/hpd-notifier.c | 134 +++
 include/linux/hpd-notifier.h | 109 +++
 4 files changed, 247 insertions(+)
 create mode 100644 drivers/video/hpd-notifier.c
 create mode 100644 include/linux/hpd-notifier.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af9..cddc860 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
 config HDMI
bool
 
+config HPD_NOTIFIERS
+   bool
+
 if VT
source "drivers/video/console/Kconfig"
 endif
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9ad3c17..424698b 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_VGASTATE)+= vgastate.o
 obj-$(CONFIG_HDMI)+= hdmi.o
+obj-$(CONFIG_HPD_NOTIFIERS)   += hpd-notifier.o
 
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
diff --git a/drivers/video/hpd-notifier.c b/drivers/video/hpd-notifier.c
new file mode 100644
index 000..54f7a6b
--- /dev/null
+++ b/drivers/video/hpd-notifier.c
@@ -0,0 +1,134 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static LIST_HEAD(hpd_notifiers);
+static DEFINE_MUTEX(hpd_notifiers_lock);
+
+struct hpd_notifier *hpd_notifier_get(struct device *dev)
+{
+   struct hpd_notifier *n;
+
+   mutex_lock(&hpd_notifiers_lock);
+   list_for_each_entry(n, &hpd_notifiers, head) {
+   if (n->dev == dev) {
+   mutex_unlock(&hpd_notifiers_lock);
+   kref_get(&n->kref);
+   return n;
+   }
+   }
+   n = kzalloc(sizeof(*n), GFP_KERNEL);
+   if (!n)
+   goto unlock;
+   n->dev = dev;
+   mutex_init(&n->lock);
+   BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
+   kref_init(&n->kref);
+   list_add_tail(&n->head, &hpd_notifiers);
+unlock:
+   mutex_unlock(&hpd_notifiers_lock);
+   return n;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_get);
+
+static void hpd_notifier_release(struct kref *kref)
+{
+   struct hpd_notifier *n =
+   container_of(kref, struct hpd_notifier, kref);
+
+   mutex_lock(&hpd_notifiers_lock);
+   list_del(&n->head);
+   mutex_unlock(&hpd_notifiers_lock);
+   kfree(n->edid);
+   kfree(n);
+}
+
+void hpd_notifier_put(struct hpd_notifier *n)
+{
+   kref_put(&n->kref, hpd_notifier_release);
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_put);
+
+int hpd_notifier_register(struct hpd_notifier *n, struct notifier_block *nb)
+{
+   int ret = blocking_notifier_chain_register(&n->notifiers, nb);
+
+   if (ret)
+   return ret;
+   kref_get(&n->kref);
+   mutex_lock(&n->lock);
+   if (n->connected) {
+   blocking_notifier_call_chain(&n->notifiers, HPD_CONNECTED, n);
+   if (n->edid_size)
+   blocking_notifier_call_chain(&n->notifiers, 
HPD_NEW_EDID, n);
+   if (n->has_eld)
+   blocking_notifier_call_chain(&n->notifiers, 
HPD_NEW_ELD, n);
+   }
+   mutex_unlock(&n->lock);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_register);
+
+int hpd_notifier_unregister(struct hpd_notifier *n, struct notifier_block *nb)
+{
+   int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
+
+   if (ret == 0)
+   hpd_notifier_put(n);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_unregister);
+
+void hpd_event_connect(struct hpd_notifier *n)
+{
+   mutex_lock(&n->lock);
+   n->connected = true;
+   blocking_notifier_call_chain(&n->notifiers, HPD_CONNECTED, n);
+   mutex_unlock(&n->lock);
+}
+EXPORT_SYMBOL_GPL(hpd_event_connect);
+
+void hpd_event_disconnect(struct hpd_notifier *n)
+{
+   mutex_lock(&n->lock);
+   n->connected = false;
+   n->has_eld = false;
+   n->edid_size = 0;
+   blocking_notifier_call_chain(&n->notifiers, HPD_DISCONNECTED, n);
+   mutex_unlock(&n->lock);
+}
+EXPORT_SYMBOL_GPL(hpd_event_disconnect);
+
+int hpd_event_new_edid(struct hpd_notifier *n, const void *edid, size_t size)
+{
+   mutex_lock(&n->lock);
+   if (n->edid_allocated_size < size) {
+   void *p = kmalloc(size, GFP_KERNEL);
+
+   if (p == NULL) {
+   

[PATCHv2 3/4] cec: integrate HPD notifier support

[Hans Verkuil]

From: Hans Verkuil 

Support the HPD notifier framework, simplifying drivers that
depend on this.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
---
 drivers/media/cec/cec-core.c | 50 
 include/media/cec.h  | 15 +
 2 files changed, 65 insertions(+)

diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index aca3ab8..a466dbe 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -195,6 +195,52 @@ static void cec_devnode_unregister(struct cec_devnode 
*devnode)
put_device(&devnode->dev);
 }
 
+#ifdef CONFIG_HPD_NOTIFIERS
+static u16 parse_hdmi_addr(const struct edid *edid)
+{
+   if (!edid || edid->extensions == 0)
+   return CEC_PHYS_ADDR_INVALID;
+
+   return cec_get_edid_phys_addr((u8 *)edid,
+   EDID_LENGTH * (edid->extensions + 1), NULL);
+}
+
+static int cec_hpd_notify(struct notifier_block *nb, unsigned long event,
+  void *data)
+{
+   struct cec_adapter *adap = container_of(nb, struct cec_adapter, nb);
+   struct hpd_notifier *n = data;
+   unsigned int phys;
+
+   dprintk(1, "event %lu\n", event);
+
+   switch (event) {
+   case HPD_DISCONNECTED:
+   cec_s_phys_addr(adap, CEC_PHYS_ADDR_INVALID, false);
+   break;
+
+   case HPD_NEW_EDID:
+   phys = parse_hdmi_addr(n->edid);
+   cec_s_phys_addr(adap, phys, false);
+   break;
+   }
+
+   return NOTIFY_OK;
+}
+
+void cec_register_hpd_notifier(struct cec_adapter *adap,
+   struct hpd_notifier *notifier)
+{
+   if (WARN_ON(!adap->devnode.registered))
+   return;
+
+   adap->nb.notifier_call = cec_hpd_notify;
+   adap->notifier = notifier;
+   hpd_notifier_register(adap->notifier, &adap->nb);
+}
+EXPORT_SYMBOL_GPL(cec_register_hpd_notifier);
+#endif
+
 struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
 void *priv, const char *name, u32 caps,
 u8 available_las)
@@ -344,6 +390,10 @@ void cec_unregister_adapter(struct cec_adapter *adap)
adap->rc = NULL;
 #endif
debugfs_remove_recursive(adap->cec_dir);
+#ifdef CONFIG_HPD_NOTIFIERS
+   if (adap->notifier)
+   hpd_notifier_unregister(adap->notifier, &adap->nb);
+#endif
cec_devnode_unregister(&adap->devnode);
 }
 EXPORT_SYMBOL_GPL(cec_unregister_adapter);
diff --git a/include/media/cec.h b/include/media/cec.h
index 96a0aa7..d6c7b20 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -28,6 +28,11 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_HPD_NOTIFIERS
+#include 
+#include 
+#include 
+#endif
 #include 
 #include 
 
@@ -173,6 +178,11 @@ struct cec_adapter {
bool passthrough;
struct cec_log_addrs log_addrs;
 
+#ifdef CONFIG_HPD_NOTIFIERS
+   struct hpd_notifier *notifier;
+   struct notifier_block   nb;
+#endif
+
struct dentry *cec_dir;
struct dentry *status_file;
 
@@ -213,6 +223,11 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
status, u8 arb_lost_cnt,
   u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);
 void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
 
+#ifdef CONFIG_HPD_NOTIFIERS
+void cec_register_hpd_notifier(struct cec_adapter *adap,
+   struct hpd_notifier *notifier);
+#endif
+
 #else
 
 static inline int cec_register_adapter(struct cec_adapter *adap,
-- 
2.8.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

[PATCHv2 2/4] exynos_hdmi: add HPD notifier support

[Hans Verkuil]

From: Hans Verkuil 

Implement the HPD notifier support to allow CEC drivers to
be informed when there is a new EDID and when a connect or
disconnect happens.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/Kconfig   |  1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c | 24 +---
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index d706ca4..80bfd1d 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -77,6 +77,7 @@ config DRM_EXYNOS_DP
 config DRM_EXYNOS_HDMI
bool "HDMI"
depends on DRM_EXYNOS_MIXER || DRM_EXYNOS5433_DECON
+   select HPD_NOTIFIERS
help
  Choose this option if you want to use Exynos HDMI for DRM.
 
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5ed8b1e..28bf609 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -118,6 +119,7 @@ struct hdmi_context {
booldvi_mode;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
+   struct hpd_notifier *notifier;
const struct hdmi_driver_data   *drv_data;
 
void __iomem*regs;
@@ -807,9 +809,12 @@ static enum drm_connector_status hdmi_detect(struct 
drm_connector *connector,
 {
struct hdmi_context *hdata = connector_to_hdmi(connector);
 
-   if (gpiod_get_value(hdata->hpd_gpio))
+   if (gpiod_get_value(hdata->hpd_gpio)) {
+   hpd_event_connect(hdata->notifier);
return connector_status_connected;
+   }
 
+   hpd_event_disconnect(hdata->notifier);
return connector_status_disconnected;
 }
 
@@ -848,6 +853,9 @@ static int hdmi_get_modes(struct drm_connector *connector)
edid->width_cm, edid->height_cm);
 
drm_mode_connector_update_edid_property(connector, edid);
+   hpd_event_connect(hdata->notifier);
+   hpd_event_new_edid(hdata->notifier, edid,
+   EDID_LENGTH * (1 + edid->extensions));
 
ret = drm_add_edid_modes(connector, edid);
 
@@ -1483,6 +1491,7 @@ static void hdmi_disable(struct drm_encoder *encoder)
if (funcs && funcs->disable)
(*funcs->disable)(crtc);
 
+   hpd_event_disconnect(hdata->notifier);
cancel_delayed_work(&hdata->hotplug_work);
 
hdmiphy_disable(hdata);
@@ -1832,15 +1841,22 @@ static int hdmi_probe(struct platform_device *pdev)
}
}
 
+   hdata->notifier = hpd_notifier_get(&pdev->dev);
+   if (hdata->notifier == NULL) {
+   ret = -ENOMEM;
+   goto err_hdmiphy;
+   }
+
pm_runtime_enable(dev);
 
ret = component_add(&pdev->dev, &hdmi_component_ops);
if (ret)
-   goto err_disable_pm_runtime;
+   goto err_notifier_put;
 
return ret;
 
-err_disable_pm_runtime:
+err_notifier_put:
+   hpd_notifier_put(hdata->notifier);
pm_runtime_disable(dev);
 
 err_hdmiphy:
@@ -1859,9 +1875,11 @@ static int hdmi_remove(struct platform_device *pdev)
struct hdmi_context *hdata = platform_get_drvdata(pdev);
 
cancel_delayed_work_sync(&hdata->hotplug_work);
+   hpd_event_disconnect(hdata->notifier);
 
component_del(&pdev->dev, &hdmi_component_ops);
 
+   hpd_notifier_put(hdata->notifier);
pm_runtime_disable(&pdev->dev);
 
if (!IS_ERR(hdata->reg_hdmi_en))
-- 
2.8.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

[PATCHv2 4/4] s5p-cec: add hpd-notifier support, move out of staging

[Hans Verkuil]

From: Hans Verkuil 

By using the HPD notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.

Update the bindings documenting the new hdmi phandle and
update exynos4.dtsi accordingly.

Tested with my Odroid U3.

Signed-off-by: Hans Verkuil 
Tested-by: Marek Szyprowski 
---
 .../devicetree/bindings/media/s5p-cec.txt  |  2 ++
 arch/arm/boot/dts/exynos4.dtsi |  1 +
 drivers/media/platform/Kconfig | 18 +++
 drivers/media/platform/Makefile|  1 +
 .../media => media/platform}/s5p-cec/Makefile  |  0
 .../platform}/s5p-cec/exynos_hdmi_cec.h|  0
 .../platform}/s5p-cec/exynos_hdmi_cecctrl.c|  0
 .../media => media/platform}/s5p-cec/regs-cec.h|  0
 .../media => media/platform}/s5p-cec/s5p_cec.c | 35 ++
 .../media => media/platform}/s5p-cec/s5p_cec.h |  3 ++
 drivers/staging/media/Kconfig  |  2 --
 drivers/staging/media/Makefile |  1 -
 drivers/staging/media/s5p-cec/Kconfig  |  9 --
 drivers/staging/media/s5p-cec/TODO |  7 -
 14 files changed, 55 insertions(+), 24 deletions(-)
 rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h 
(100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c 
(100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
 rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
 delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
 delete mode 100644 drivers/staging/media/s5p-cec/TODO

diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt 
b/Documentation/devicetree/bindings/media/s5p-cec.txt
index 925ab4d..710fc00 100644
--- a/Documentation/devicetree/bindings/media/s5p-cec.txt
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -15,6 +15,7 @@ Required properties:
   - clock-names : from common clock binding: must contain "hdmicec",
  corresponding to entry in the clocks property.
   - samsung,syscon-phandle - phandle to the PMU system controller
+  - samsung,hdmi-phandle - phandle to the HDMI controller
 
 Example:
 
@@ -25,6 +26,7 @@ hdmicec: cec@100B {
clocks = <&clock CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <&pmu_system_controller>;
+   samsung,hdmi-phandle = <&hdmi>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_cec>;
status = "okay";
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index c64737b..51dfcbb 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -762,6 +762,7 @@
clocks = <&clock CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <&pmu_system_controller>;
+   samsung,hdmi-phandle = <&hdmi>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_cec>;
status = "disabled";
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421..cab1637 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -392,6 +392,24 @@ config VIDEO_TI_SC
 config VIDEO_TI_CSC
tristate
 
+menuconfig V4L_CEC_DRIVERS
+   bool "Platform HDMI CEC drivers"
+   depends on MEDIA_CEC_SUPPORT
+
+if V4L_CEC_DRIVERS
+
+config VIDEO_SAMSUNG_S5P_CEC
+   tristate "Samsung S5P CEC driver"
+   depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (PLAT_S5P || ARCH_EXYNOS 
|| COMPILE_TEST)
+   select HPD_NOTIFIERS
+   ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
+endif #V4L_CEC_DRIVERS
+
 menuconfig V4L_TEST_DRIVERS
bool "Media test drivers"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 5b3cb27..ad3bf22 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)  += s5p-jpeg/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
 
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
 
 obj-$(CONFIG_VIDEO_STI_BDISP)  += sti/bdisp/
diff --git a/drivers/staging/media/s5p-cec/Makefile 
b/drivers/media/platform/s5p-cec/Makefile
similarity index 100%
rename from drivers/staging/media/s5p-cec/Makefile
rename to

[PATCHv2 0/4] video/exynos/cec: add HPD state notifier & use in s5p-cec

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds the hotplug detect notifier code, based on Russell's 
code:

https://patchwork.kernel.org/patch/9277043/

It adds support for it to the exynos_hdmi drm driver, adds support for
it to the CEC framework and finally adds support to the s5p-cec driver,
which now can be moved out of staging.

Tested with my Odroid U3 exynos4 devboard.

Comments are welcome. I'd like to get this in for the 4.11 kernel as
this is a missing piece needed to integrate CEC drivers.

Changes since v1:

Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is
not HDMI specific, but is interesting for any video source that has to
deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ).
Only the use with CEC adapters is HDMI specific, but the HPD notifier
is more generic.

Regards,

Hans

Hans Verkuil (4):
  video: add hotplug detect notifier support
  exynos_hdmi: add HPD notifier support
  cec: integrate HPD notifier support
  s5p-cec: add hpd-notifier support, move out of staging

 .../devicetree/bindings/media/s5p-cec.txt  |   2 +
 arch/arm/boot/dts/exynos4.dtsi |   1 +
 drivers/gpu/drm/exynos/Kconfig |   1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  24 +++-
 drivers/media/cec/cec-core.c   |  50 
 drivers/media/platform/Kconfig |  18 +++
 drivers/media/platform/Makefile|   1 +
 .../media => media/platform}/s5p-cec/Makefile  |   0
 .../platform}/s5p-cec/exynos_hdmi_cec.h|   0
 .../platform}/s5p-cec/exynos_hdmi_cecctrl.c|   0
 .../media => media/platform}/s5p-cec/regs-cec.h|   0
 .../media => media/platform}/s5p-cec/s5p_cec.c |  35 +-
 .../media => media/platform}/s5p-cec/s5p_cec.h |   3 +
 drivers/staging/media/Kconfig  |   2 -
 drivers/staging/media/Makefile |   1 -
 drivers/staging/media/s5p-cec/Kconfig  |   9 --
 drivers/staging/media/s5p-cec/TODO |   7 --
 drivers/video/Kconfig  |   3 +
 drivers/video/Makefile |   1 +
 drivers/video/hpd-notifier.c   | 134 +
 include/linux/hpd-notifier.h   | 109 +
 include/media/cec.h|  15 +++
 22 files changed, 389 insertions(+), 27 deletions(-)
 rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h 
(100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c 
(100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
 rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
 rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
 delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
 delete mode 100644 drivers/staging/media/s5p-cec/TODO
 create mode 100644 drivers/video/hpd-notifier.c
 create mode 100644 include/linux/hpd-notifier.h

-- 
2.8.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 v2 00/21] Basic i.MX IPUv3 capture support

[Jean-Michel Hautbois]

Hi,

2016-12-30 21:26 GMT+01:00 Steve Longerbeam :
>
>
> On 12/30/2016 11:06 AM, Marek Vasut wrote:
>>
>> On 12/29/2016 09:51 PM, Robert Schwebel wrote:
>>>
>>> Hi Jean-Michel,
>>
>> Hi,
>>
>>> On Thu, Dec 29, 2016 at 04:08:33PM +0100, Jean-Michel Hautbois wrote:

 What is the status of this work?
>>>
>>> Philipp's patches have been reworked with the review feedback from the
>>> last round and a new version will be posted when he is back from
>>> holidays.
>>
>> IMO Philipp's patches are better integrated and well structured, so I'd
>> rather like to see his work in at some point.
>
>
> Granted I am biased, but I will state my case. "Better integrated" - my
> patches
> are also well integrated with the media core infrastructure. Philipp's
> patches
> in fact require modification to media core, whereas mine require none.
> Some changes are needed of course (more subdev type definitions for
> one).
>
> As for "well structured", I don't really understand what is meant by that,
> but my driver is also well structured.
>
> Philipp's driver only supports unconverted image capture from the SMFC. In
> addition
> to that, mine allows for all the hardware links supported by the IPU,
> including routing
> frames from the CSI directly to the Image converter for scaling up to
> 4096x4096,
> colorspace conversion, rotation, and motion compensated de-interlace. Yes
> all these
> conversion can be carried out post-capture via a mem2mem device, but
> conversion
> directly from CSI capture has advantages, including minimized CPU
> utilization and
> lower AXI bus traffic. In any case, Freescale added these hardware paths,
> and my
> driver supports them.

I had a deeper look to both drivers, and I must say the features of
Steve's one are really interesting.
I don't think any of those has been tested with digital inputs (I have
ADV76xx chips on my board, which I hope will be available one day for
those interested) and so, I can test and help adding some of the
missing parts.
And for at least a week or two, I have all of my time for it, so it
would be of great help to know which one has the bigger chance to be
integrated... :)

Thanks again,
JM
--
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 00/15] atmel-isi/ov7670/ov2640: convert to standalone drivers

[Hans Verkuil]

On 01/02/17 14:37, Hans Verkuil wrote:

On 12/18/16 23:10, Sakari Ailus wrote:

On Mon, Dec 12, 2016 at 04:55:05PM +0100, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series converts the soc-camera atmel-isi to a standalone V4L2
driver.

The same is done for the ov7670 and ov2640 sensor drivers: the ov7670 was
used to test the atmel-isi driver. The ov2640 is needed because the em28xx
driver has a soc_camera include dependency. Both ov7670 and ov2640 sensors
have been tested with the atmel-isi driver.

The first 6 patches improve the ov7670 sensor driver, mostly adding modern
features such as MC and DT support.

The next three convert the atmel-isi and move it out of soc_camera.


You're adding Media controller support but without device nodes. Does that
make sense? You'll have an entity but the user won't be able to do anything
with it.



Well, without the MC support the sensor driver wouldn't load since the atmel
driver expects that the subdev is MC-enabled. However, the atmel-isi doesn't
need the user to configure the pipeline, it's just a simple standard v4l driver.

So just filling in the entity information is sufficient in this case.

That said, I see that the atmel-isi driver calls 
v4l2_device_register_subdev_nodes().
Since this is a simple V4L driver, that call should probably be dropped, since
we really don't want or need subdev nodes.

I will also need to take another look at the atmel-isi code to see if this MC
dependency is really needed: I think I copied some of that code from the rcar
driver, and it may not be relevant for the atmel driver.


In fact, I don't think it is needed at all.

But does it hurt to add MC support to these ov drivers?

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 00/15] atmel-isi/ov7670/ov2640: convert to standalone drivers

[Hans Verkuil]

On 12/18/16 23:10, Sakari Ailus wrote:

On Mon, Dec 12, 2016 at 04:55:05PM +0100, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series converts the soc-camera atmel-isi to a standalone V4L2
driver.

The same is done for the ov7670 and ov2640 sensor drivers: the ov7670 was
used to test the atmel-isi driver. The ov2640 is needed because the em28xx
driver has a soc_camera include dependency. Both ov7670 and ov2640 sensors
have been tested with the atmel-isi driver.

The first 6 patches improve the ov7670 sensor driver, mostly adding modern
features such as MC and DT support.

The next three convert the atmel-isi and move it out of soc_camera.


You're adding Media controller support but without device nodes. Does that
make sense? You'll have an entity but the user won't be able to do anything
with it.



Well, without the MC support the sensor driver wouldn't load since the atmel
driver expects that the subdev is MC-enabled. However, the atmel-isi doesn't
need the user to configure the pipeline, it's just a simple standard v4l driver.

So just filling in the entity information is sufficient in this case.

That said, I see that the atmel-isi driver calls 
v4l2_device_register_subdev_nodes().
Since this is a simple V4L driver, that call should probably be dropped, since
we really don't want or need subdev nodes.

I will also need to take another look at the atmel-isi code to see if this MC
dependency is really needed: I think I copied some of that code from the rcar
driver, and it may not be relevant for the atmel driver.

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 v3 4/7] [media] coda: add debug output about tiling

[Michael Tretter]

From: Philipp Zabel 

In order to make the VDOA work correctly, the CODA must produce frames
in tiled format. Print this information in the debug output.

Also print the color format in fourcc instead of the numeric value.

Signed-off-by: Philipp Zabel 
Signed-off-by: Michael Tretter 
---
 drivers/media/platform/coda/coda-common.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index fa3ed74af116..b23fe0f0fb56 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -616,8 +616,10 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f,
}
 
v4l2_dbg(1, coda_debug, &ctx->dev->v4l2_dev,
-   "Setting format for type %d, wxh: %dx%d, fmt: %d\n",
-   f->type, q_data->width, q_data->height, q_data->fourcc);
+   "Setting format for type %d, wxh: %dx%d, fmt: %4.4s %c\n",
+   f->type, q_data->width, q_data->height,
+   (char *)&q_data->fourcc,
+   (ctx->tiled_map_type == GDI_LINEAR_FRAME_MAP) ? 'L' : 'T');
 
return 0;
 }
-- 
2.11.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

[PATCH v3 2/7] [media] coda: add i.MX6 VDOA driver

[Michael Tretter]

From: Philipp Zabel 

The i.MX6 Video Data Order Adapter's (VDOA) sole purpose is to convert
from a custom macroblock tiled format produced by the CODA960 decoder
into linear formats that can be used for scanout.

Signed-off-by: Philipp Zabel 
Signed-off-by: Michael Tretter 
---
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/coda/Makefile   |   1 +
 drivers/media/platform/coda/imx-vdoa.c | 335 +
 drivers/media/platform/coda/imx-vdoa.h |  58 ++
 4 files changed, 397 insertions(+)
 create mode 100644 drivers/media/platform/coda/imx-vdoa.c
 create mode 100644 drivers/media/platform/coda/imx-vdoa.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421e392d..595652613db9 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,9 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_IMX_VDOA
+   def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/coda/Makefile 
b/drivers/media/platform/coda/Makefile
index 9342ac57b230..858284328af9 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)
 coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-jpeg.o
 
 obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_IMX_VDOA) += imx-vdoa.o
diff --git a/drivers/media/platform/coda/imx-vdoa.c 
b/drivers/media/platform/coda/imx-vdoa.c
new file mode 100644
index ..36ceffbf08de
--- /dev/null
+++ b/drivers/media/platform/coda/imx-vdoa.c
@@ -0,0 +1,335 @@
+/*
+ * i.MX6 Video Data Order Adapter (VDOA)
+ *
+ * Copyright (C) 2014 Philipp Zabel
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-vdoa.h"
+
+#define VDOA_NAME "imx-vdoa"
+
+#define VDOAC  0x00
+#define VDOASRR0x04
+#define VDOAIE 0x08
+#define VDOAIST0x0c
+#define VDOAFP 0x10
+#define VDOAIEBA00 0x14
+#define VDOAIEBA01 0x18
+#define VDOAIEBA02 0x1c
+#define VDOAIEBA10 0x20
+#define VDOAIEBA11 0x24
+#define VDOAIEBA12 0x28
+#define VDOASL 0x2c
+#define VDOAIUBO   0x30
+#define VDOAVEBA0  0x34
+#define VDOAVEBA1  0x38
+#define VDOAVEBA2  0x3c
+#define VDOAVUBO   0x40
+#define VDOASR 0x44
+
+#define VDOAC_ISEL BIT(6)
+#define VDOAC_PFS  BIT(5)
+#define VDOAC_SO   BIT(4)
+#define VDOAC_SYNC BIT(3)
+#define VDOAC_NF   BIT(2)
+#define VDOAC_BNDM_MASK0x3
+#define VDOAC_BAND_HEIGHT_80x0
+#define VDOAC_BAND_HEIGHT_16   0x1
+#define VDOAC_BAND_HEIGHT_32   0x2
+
+#define VDOASRR_START  BIT(1)
+#define VDOASRR_SWRST  BIT(0)
+
+#define VDOAIE_EITERR  BIT(1)
+#define VDOAIE_EIEOT   BIT(0)
+
+#define VDOAIST_TERR   BIT(1)
+#define VDOAIST_EOTBIT(0)
+
+#define VDOAFP_FH_MASK (0x1fff << 16)
+#define VDOAFP_FW_MASK (0x3fff)
+
+#define VDOASL_VSLY_MASK   (0x3fff << 16)
+#define VDOASL_ISLY_MASK   (0x7fff)
+
+#define VDOASR_ERRWBIT(4)
+#define VDOASR_EOB BIT(3)
+#define VDOASR_CURRENT_FRAME   (0x3 << 1)
+#define VDOASR_CURRENT_BUFFER  BIT(1)
+
+enum {
+   V4L2_M2M_SRC = 0,
+   V4L2_M2M_DST = 1,
+};
+
+struct vdoa_data {
+   struct vdoa_ctx *curr_ctx;
+   struct device   *dev;
+   struct clk  *vdoa_clk;
+   void __iomem*regs;
+   int irq;
+};
+
+struct vdoa_q_data {
+   unsigned intwidth;
+   unsigned intheight;
+   unsigned intbytesperline;
+   unsigned intsizeimage;
+   u32 pixelformat;
+};
+
+struct vdoa_ctx {
+   struct vdoa_data*vdoa;
+   struct completion   completion;
+   struct vdoa_q_data  q_data[2];
+};
+
+static irqreturn_t vdoa_irq_handler(int irq, void *data)
+{
+   struct vdoa_data *vdoa = data;
+   struct vdoa_ctx *curr_ctx;
+   u32 val;
+
+   /* Disable interrupts */
+   writel(0, vdoa->regs + VDOAIE);
+
+   curr_ctx = vdoa->curr_ctx;
+   if (

[PATCH v3 7/7] [media] coda: support YUYV output if VDOA is used

[Michael Tretter]

The VDOA is able to transform the NV12 custom macroblock tiled format of
the CODA to YUYV format. If and only if the VDOA is available, the
driver can also provide YUYV support.

While the driver is configured to produce YUYV output, the CODA must be
configured to produce NV12 macroblock tiled frames and the VDOA must
transform the intermediate result into the final YUYV output.

Signed-off-by: Michael Tretter 
Reviewed-by: Philipp Zabel 
---
 drivers/media/platform/coda/coda-bit.c|  7 +--
 drivers/media/platform/coda/coda-common.c | 30 ++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index f608de4c52ac..466a44e4549e 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -759,7 +759,7 @@ static void coda9_set_frame_cache(struct coda_ctx *ctx, u32 
fourcc)
cache_config = 1 << CODA9_CACHE_PAGEMERGE_OFFSET;
}
coda_write(ctx->dev, cache_size, CODA9_CMD_SET_FRAME_CACHE_SIZE);
-   if (fourcc == V4L2_PIX_FMT_NV12) {
+   if (fourcc == V4L2_PIX_FMT_NV12 || fourcc == V4L2_PIX_FMT_YUYV) {
cache_config |= 32 << CODA9_CACHE_LUMA_BUFFER_SIZE_OFFSET |
16 << CODA9_CACHE_CR_BUFFER_SIZE_OFFSET |
0 << CODA9_CACHE_CB_BUFFER_SIZE_OFFSET;
@@ -1537,7 +1537,7 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
 
ctx->frame_mem_ctrl &= ~(CODA_FRAME_CHROMA_INTERLEAVE | (0x3 << 9) |
 CODA9_FRAME_TILED2LINEAR);
-   if (dst_fourcc == V4L2_PIX_FMT_NV12)
+   if (dst_fourcc == V4L2_PIX_FMT_NV12 || dst_fourcc == V4L2_PIX_FMT_YUYV)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
ctx->frame_mem_ctrl |= (0x3 << 9) |
@@ -2079,6 +2079,9 @@ static void coda_finish_decode(struct coda_ctx *ctx)
trace_coda_dec_rot_done(ctx, dst_buf, meta);
 
switch (q_data_dst->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   payload = width * height * 2;
+   break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_NV12:
diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 8977a56d6a38..756a235895e5 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -95,6 +95,8 @@ void coda_write_base(struct coda_ctx *ctx, struct coda_q_data 
*q_data,
u32 base_cb, base_cr;
 
switch (q_data->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   /* Fallthrough: IN -H264-> CODA -NV12 MB-> VDOA -YUYV-> OUT */
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_YUV420:
default:
@@ -201,6 +203,11 @@ static const struct coda_video_device coda_bit_decoder = {
V4L2_PIX_FMT_NV12,
V4L2_PIX_FMT_YUV420,
V4L2_PIX_FMT_YVU420,
+   /*
+* If V4L2_PIX_FMT_YUYV should be default,
+* set_default_params() must be adjusted.
+*/
+   V4L2_PIX_FMT_YUYV,
},
 };
 
@@ -246,6 +253,7 @@ static u32 coda_format_normalize_yuv(u32 fourcc)
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_YUV422P:
+   case V4L2_PIX_FMT_YUYV:
return V4L2_PIX_FMT_YUV420;
default:
return fourcc;
@@ -434,6 +442,11 @@ static int coda_try_pixelformat(struct coda_ctx *ctx, 
struct v4l2_format *f)
return -EINVAL;
 
for (i = 0; i < CODA_MAX_FORMATS; i++) {
+   /* Skip YUYV if the vdoa is not available */
+   if (!ctx->vdoa && f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE &&
+   formats[i] == V4L2_PIX_FMT_YUYV)
+   continue;
+
if (formats[i] == f->fmt.pix.pixelformat) {
f->fmt.pix.pixelformat = formats[i];
return 0;
@@ -520,6 +533,11 @@ static int coda_try_fmt(struct coda_ctx *ctx, const struct 
coda_codec *codec,
f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
f->fmt.pix.height * 3 / 2;
break;
+   case V4L2_PIX_FMT_YUYV:
+   f->fmt.pix.bytesperline = round_up(f->fmt.pix.width, 16) * 2;
+   f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
+   f->fmt.pix.height;
+   break;
case V4L2_PIX_FMT_YUV422P:
f->fmt.pix.bytesperline = round_up(f->fmt.pix.width, 16);
f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
@@ -593,6 +611,15 @@ static int coda_try_fmt_vid_cap(struct file *file, vo

[PATCH v3 0/7] Add support for Video Data Order Adapter

[Michael Tretter]

Hello,

This is v3 of a patch series that adds support for the Video Data Order
Adapter (VDOA) that can be found on Freescale i.MX6. It converts the
macroblock tiled format produced by the CODA 960 video decoder to a
raster-ordered format for scanout.

Changes since v2:

- Patch 1/7: Update commit message to include binding change; fix
  spelling/style in binding documentation

Changes since v1:

- Dropped patch 8/9 of v1
- Patch 1/7: Add devicetree binding documentation for fsl-vdoa
- Patch 6/7: I merged patch 5/9 and patch 8/9 of v1 into a single patch
- Patch 6/7: Use dt compatible instead of a phandle to find VDOA device
- Patch 6/7: Always check VDOA availability even if disabled via module
  parameter and do not print a message if VDOA cannot be found
- Patch 6/7: Do not change the CODA context in coda_try_fmt()
- Patch 6/7: Allocate an additional internal frame if the VDOA is in use


Michael Tretter (3):
  [media] coda: fix frame index to returned error
  [media] coda: use VDOA for un-tiling custom macroblock format
  [media] coda: support YUYV output if VDOA is used

Philipp Zabel (4):
  [media] dt-bindings: Add a binding for Video Data Order Adapter
  [media] coda: add i.MX6 VDOA driver
  [media] coda: correctly set capture compose rectangle
  [media] coda: add debug output about tiling

 .../devicetree/bindings/media/fsl-vdoa.txt |  21 ++
 arch/arm/boot/dts/imx6qdl.dtsi |   2 +
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/coda/Makefile   |   1 +
 drivers/media/platform/coda/coda-bit.c |  93 --
 drivers/media/platform/coda/coda-common.c  | 175 ++-
 drivers/media/platform/coda/coda.h |   3 +
 drivers/media/platform/coda/imx-vdoa.c | 335 +
 drivers/media/platform/coda/imx-vdoa.h |  58 
 9 files changed, 649 insertions(+), 42 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt
 create mode 100644 drivers/media/platform/coda/imx-vdoa.c
 create mode 100644 drivers/media/platform/coda/imx-vdoa.h

-- 
2.11.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

[PATCH v3 3/7] [media] coda: correctly set capture compose rectangle

[Michael Tretter]

From: Philipp Zabel 

Correctly store the rectangle of valid video data in the destination
q_data before rounding up to macroblock size. This fixes the output
of VIDIOC_G_SELECTION for the capture side compose rectangle.

Signed-off-by: Philipp Zabel 
Signed-off-by: Michael Tretter 
---
 drivers/media/platform/coda/coda-common.c | 37 ---
 1 file changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 9e6bdafa16f5..fa3ed74af116 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -566,7 +566,8 @@ static int coda_try_fmt_vid_out(struct file *file, void 
*priv,
return coda_try_fmt(ctx, codec, f);
 }
 
-static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
+static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f,
+ struct v4l2_rect *r)
 {
struct coda_q_data *q_data;
struct vb2_queue *vq;
@@ -589,10 +590,14 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f)
q_data->height = f->fmt.pix.height;
q_data->bytesperline = f->fmt.pix.bytesperline;
q_data->sizeimage = f->fmt.pix.sizeimage;
-   q_data->rect.left = 0;
-   q_data->rect.top = 0;
-   q_data->rect.width = f->fmt.pix.width;
-   q_data->rect.height = f->fmt.pix.height;
+   if (r) {
+   q_data->rect = *r;
+   } else {
+   q_data->rect.left = 0;
+   q_data->rect.top = 0;
+   q_data->rect.width = f->fmt.pix.width;
+   q_data->rect.height = f->fmt.pix.height;
+   }
 
switch (f->fmt.pix.pixelformat) {
case V4L2_PIX_FMT_NV12:
@@ -621,27 +626,37 @@ static int coda_s_fmt_vid_cap(struct file *file, void 
*priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_cap(file, priv, f);
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, f);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, f, &r);
 }
 
 static int coda_s_fmt_vid_out(struct file *file, void *priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
struct v4l2_format f_cap;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_out(file, priv, f);
if (ret)
return ret;
 
-   ret = coda_s_fmt(ctx, f);
+   ret = coda_s_fmt(ctx, f, NULL);
if (ret)
return ret;
 
@@ -657,7 +672,13 @@ static int coda_s_fmt_vid_out(struct file *file, void 
*priv,
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, &f_cap);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, &f_cap, &r);
 }
 
 static int coda_reqbufs(struct file *file, void *priv,
-- 
2.11.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

[PATCH v3 6/7] [media] coda: use VDOA for un-tiling custom macroblock format

[Michael Tretter]

If the CODA driver is configured to produce NV12 output and the VDOA is
available, the VDOA can be used to transform the custom macroblock tiled
format to a raster-ordered format for scanout.

In this case, set the output format of the CODA to the custom macroblock
tiled format, disable the rotator, and use the VDOA to write to the v4l2
buffer. The VDOA is synchronized with the CODA to always un-tile the
frame that the CODA finished in the previous run.

Signed-off-by: Michael Tretter 
---
 drivers/media/platform/coda/coda-bit.c|  86 +
 drivers/media/platform/coda/coda-common.c | 102 --
 drivers/media/platform/coda/coda.h|   3 +
 3 files changed, 161 insertions(+), 30 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index 309eb4eb5ad1..f608de4c52ac 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -30,6 +30,7 @@
 #include 
 
 #include "coda.h"
+#include "imx-vdoa.h"
 #define CREATE_TRACE_POINTS
 #include "trace.h"
 
@@ -1517,6 +1518,10 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
u32 val;
int ret;
 
+   v4l2_dbg(1, coda_debug, &dev->v4l2_dev,
+"Video Data Order Adapter: %s\n",
+ctx->use_vdoa ? "Enabled" : "Disabled");
+
/* Start decoding */
q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
@@ -1535,7 +1540,8 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
if (dst_fourcc == V4L2_PIX_FMT_NV12)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
-   ctx->frame_mem_ctrl |= (0x3 << 9) | CODA9_FRAME_TILED2LINEAR;
+   ctx->frame_mem_ctrl |= (0x3 << 9) |
+   ((ctx->use_vdoa) ? 0 : CODA9_FRAME_TILED2LINEAR);
coda_write(dev, ctx->frame_mem_ctrl, CODA_REG_BIT_FRAME_MEM_CTRL);
 
ctx->display_idx = -1;
@@ -1618,6 +1624,15 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
 __func__, ctx->idx, width, height);
 
ctx->num_internal_frames = coda_read(dev, CODA_RET_DEC_SEQ_FRAME_NEED);
+   /*
+* If the VDOA is used, the decoder needs one additional frame,
+* because the frames are freed when the next frame is decoded.
+* Otherwise there are visible errors in the decoded frames (green
+* regions in displayed frames) and a broken order of frames (earlier
+* frames are sporadically displayed after later frames).
+*/
+   if (ctx->use_vdoa)
+   ctx->num_internal_frames += 1;
if (ctx->num_internal_frames > CODA_MAX_FRAMEBUFFERS) {
v4l2_err(&dev->v4l2_dev,
 "not enough framebuffers to decode (%d < %d)\n",
@@ -1724,6 +1739,7 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
struct coda_q_data *q_data_dst;
struct coda_buffer_meta *meta;
unsigned long flags;
+   u32 rot_mode = 0;
u32 reg_addr, reg_stride;
 
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
@@ -1759,27 +1775,40 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
if (dev->devtype->product == CODA_960)
coda_set_gdi_regs(ctx);
 
-   if (dev->devtype->product == CODA_960) {
-   /*
-* The CODA960 seems to have an internal list of buffers with
-* 64 entries that includes the registered frame buffers as
-* well as the rotator buffer output.
-* ROT_INDEX needs to be < 0x40, but > ctx->num_internal_frames.
-*/
-   coda_write(dev, CODA_MAX_FRAMEBUFFERS + dst_buf->vb2_buf.index,
-   CODA9_CMD_DEC_PIC_ROT_INDEX);
-
-   reg_addr = CODA9_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA9_CMD_DEC_PIC_ROT_STRIDE;
+   if (ctx->use_vdoa &&
+   ctx->display_idx >= 0 &&
+   ctx->display_idx < ctx->num_internal_frames) {
+   vdoa_device_run(ctx->vdoa,
+   
vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0),
+   ctx->internal_frames[ctx->display_idx].paddr);
} else {
-   reg_addr = CODA_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA_CMD_DEC_PIC_ROT_STRIDE;
+   if (dev->devtype->product == CODA_960) {
+   /*
+* The CODA960 seems to have an internal list of
+* buffers with 64 entries that includes the
+* registered frame buffers as well as the rotator
+* buffer output.
+*
+* ROT_INDEX needs to be < 0x40, but >
+* ctx->num_i

[PATCH v3 5/7] [media] coda: fix frame index to returned error

[Michael Tretter]

display_idx refers to the frame that will be returned in the next round.
The currently processed frame is ctx->display_idx and errors should be
reported for this frame.

Signed-off-by: Michael Tretter 
Acked-by: Philipp Zabel 
---
 drivers/media/platform/coda/coda-bit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index b6625047250d..309eb4eb5ad1 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2057,7 +2057,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
}
vb2_set_plane_payload(&dst_buf->vb2_buf, 0, payload);
 
-   coda_m2m_buf_done(ctx, dst_buf, ctx->frame_errors[display_idx] ?
+   coda_m2m_buf_done(ctx, dst_buf, 
ctx->frame_errors[ctx->display_idx] ?
  VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
 
v4l2_dbg(1, coda_debug, &dev->v4l2_dev,
-- 
2.11.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

[PATCH v3 1/7] [media] dt-bindings: Add a binding for Video Data Order Adapter

[Michael Tretter]

From: Philipp Zabel 

Add a DT binding documentation for the Video Data Order Adapter (VDOA)
of the Freescale i.MX6 SoC.

Also, add the compatible property and correct clock to the device tree
to match the documentation.

Signed-off-by: Philipp Zabel 
Signed-off-by: Michael Tretter 
---
 .../devicetree/bindings/media/fsl-vdoa.txt  | 21 +
 arch/arm/boot/dts/imx6qdl.dtsi  |  2 ++
 2 files changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt

diff --git a/Documentation/devicetree/bindings/media/fsl-vdoa.txt 
b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
new file mode 100644
index ..6c5628530bb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
@@ -0,0 +1,21 @@
+Freescale Video Data Order Adapter
+==
+
+The Video Data Order Adapter (VDOA) is present on the i.MX6q. Its sole purpose
+is to reorder video data from the macroblock tiled order produced by the CODA
+960 VPU to the conventional raster-scan order for scanout.
+
+Required properties:
+- compatible: must be "fsl,imx6q-vdoa"
+- reg: the register base and size for the device registers
+- interrupts: the VDOA interrupt
+- clocks: the vdoa clock
+
+Example:
+
+vdoa@21e4000 {
+compatible = "fsl,imx6q-vdoa";
+reg = <0x021e4000 0x4000>;
+interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+clocks = <&clks IMX6QDL_CLK_VDOA>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63cbb02..61569c86d28e 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1157,8 +1157,10 @@
};
 
vdoa@021e4000 {
+   compatible = "fsl,imx6q-vdoa";
reg = <0x021e4000 0x4000>;
interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks IMX6QDL_CLK_VDOA>;
};
 
uart2: serial@021e8000 {
-- 
2.11.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

Re: [PATCH 04/15] ov7670: get xclk

[Hans Verkuil]

On 12/18/16 23:15, Sakari Ailus wrote:

Hi Hans,

On Mon, Dec 12, 2016 at 04:55:09PM +0100, Hans Verkuil wrote:

From: Hans Verkuil 

Get the clock for this sensor.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/ov7670.c | 35 ---
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 35b09d2..d2c0e23 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -10,6 +10,7 @@
  * This file may be distributed under the terms of the GNU General
  * Public License, version 2.
  */
+#include 
 #include 
 #include 
 #include 
@@ -230,6 +231,7 @@ struct ov7670_info {
struct v4l2_ctrl *hue;
};
struct ov7670_format_struct *fmt;  /* Current format */
+   struct clk *clk;
int min_width;  /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -1590,13 +1592,28 @@ static int ov7670_probe(struct i2c_client *client,
info->pclk_hb_disable = true;
}

+   info->clk = clk_get(&client->dev, "xclk");
+   if (IS_ERR(info->clk))
+   return -EPROBE_DEFER;


How about devm_clk_get() instead? I think there's nothing wrong in using
devm.*() here as it's not memory.


True. Changed to devm_clk_get.




+   clk_prepare_enable(info->clk);
+
+   ret = ov7670_probe_dt(client, info);
+   if (ret)
+   goto clk_put;
+
+   info->clock_speed = clk_get_rate(info->clk) / 100;
+   if (info->clock_speed < 12 || info->clock_speed > 48) {


What's the clock expected to be? I don't know the sensor but all sensors
I've seen do derive their internal clocks from the one provided to the
sensor, meaning that any frequency would be directly related to this one. As
the sensor driver makes no effort in programming the PLL according to the
input clock, I bet the register lists used assume a certain frequency
instead. Shouldn't you check instead you're getting exactly that frequency?


All the datasheet says is that the clock is expected to be between 10 and 48 MHz
with 24 MHz as the recommended frequency. So the < 12 should be < 10.

Of course, if the given clock is slower, then the framerate will be 
correspondingly
slower as well.

All this test does is to check that the given clock is within the spec.

Regards,

Hans




+   ret = -EINVAL;
+   goto clk_put;
+   }
+
/* Make sure it's an ov7670 */
ret = ov7670_detect(sd);
if (ret) {
v4l_dbg(1, debug, client,
"chip found @ 0x%x (%s) is not an ov7670 chip.\n",
client->addr << 1, client->adapter->name);
-   return ret;
+   goto clk_put;
}
v4l_info(client, "chip found @ 0x%02x (%s)\n",
client->addr << 1, client->adapter->name);
@@ -1637,9 +1654,8 @@ static int ov7670_probe(struct i2c_client *client,
V4L2_EXPOSURE_AUTO);
sd->ctrl_handler = &info->hdl;
if (info->hdl.error) {
-   int err = info->hdl.error;
-
-   goto fail;
+   ret = info->hdl.error;
+   goto hdl_free;
}

 #if defined(CONFIG_MEDIA_CONTROLLER)
@@ -1647,7 +1663,7 @@ static int ov7670_probe(struct i2c_client *client,
info->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
ret = media_entity_pads_init(&info->sd.entity, 1, &info->pad);
if (ret < 0)
-   goto fail;
+   goto hdl_free;
 #endif
/*
 * We have checked empirically that hw allows to read back the gain
@@ -1664,13 +1680,16 @@ static int ov7670_probe(struct i2c_client *client,
 #if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(&info->sd.entity);
 #endif
-   goto fail;
+   goto hdl_free;
}

return 0;

-fail:
+hdl_free:
v4l2_ctrl_handler_free(&info->hdl);
+clk_put:
+   clk_disable_unprepare(info->clk);
+   clk_put(info->clk);
return ret;
 }

@@ -1685,6 +1704,8 @@ static int ov7670_remove(struct i2c_client *client)
 #if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(&sd->entity);
 #endif
+   clk_disable_unprepare(info->clk);
+   clk_put(info->clk);
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

Re: [PATCH 02/15] ov7670: call v4l2_async_register_subdev

[Hans Verkuil]

On 12/18/16 23:08, Sakari Ailus wrote:

On Mon, Dec 12, 2016 at 04:55:07PM +0100, Hans Verkuil wrote:

From: Hans Verkuil 

Add v4l2-async support for this driver.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/ov7670.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index b0315bb..3f0522f 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1641,18 +1641,15 @@ static int ov7670_probe(struct i2c_client *client,
if (info->hdl.error) {
int err = info->hdl.error;

-   v4l2_ctrl_handler_free(&info->hdl);
-   return err;
+   goto fail;
}

 #if defined(CONFIG_MEDIA_CONTROLLER)
info->pad.flags = MEDIA_PAD_FL_SOURCE;
info->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
ret = media_entity_pads_init(&info->sd.entity, 1, &info->pad);
-   if (ret < 0) {
-   v4l2_ctrl_handler_free(&info->hdl);
-   return ret;
-   }
+   if (ret < 0)
+   goto fail;
 #endif
/*
 * We have checked empirically that hw allows to read back the gain
@@ -1664,7 +1661,19 @@ static int ov7670_probe(struct i2c_client *client,
v4l2_ctrl_cluster(2, &info->saturation);
v4l2_ctrl_handler_setup(&info->hdl);

+   ret = v4l2_async_register_subdev(&info->sd);
+   if (ret < 0) {
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   media_entity_cleanup(&info->sd.entity);


I think it'd be cleaner if you added another label for this. Up to you.


That's better indeed. Added the label.

Hans



Acked-by: Sakari Ailus 


+#endif
+   goto fail;
+   }
+
return 0;
+
+fail:
+   v4l2_ctrl_handler_free(&info->hdl);
+   return ret;
 }






--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[ayaka]

On 01/02/2017 07:07 PM, Sakari Ailus wrote:

Hi,

On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:


On 01/02/2017 05:10 PM, Sakari Ailus wrote:

Hi Randy,

Thanks for the patch.

On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:

The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those format for profile_10
HEVC/AVC video.

Signed-off-by: Randy Li 

If the format resembles the existing formats but on a different bit depth,
it should be named in similar fashion.

Do you mean it would be better if it is called as NV12_10?

If it otherwise resembles NV12 but just has 10 bits per pixel, I think
NV12_10 is a good name for it.
The main reason I don't like it is that there is a various of software 
having used the P010 for this kind of pixel format. It would leadi a 
conflict between them(and I never saw it is used as NV12_10), as the 
P010 is more common to be used.
I left a problem unsolved for P010 in v4l2, P010 have two variant, 
little endian and big endian. Which could be easy identified in drm 
driver(there is a flag for all the big endian pixel format).



Could you also add ReST documentation for the format, please?

I will.

The common requirement for merging patches that change interfaces has been
that there's a user for that change. It'll still help you to get this

The kernel used in rockchip has supported that format in drm driver, but
just we don't have a agreement about the pixel format. As the Gstreamer and
some others would call it with a P010_ prefix, but Mark(rockchip's drm
author) prefer the something like NV12_10, that is why I sent out those
patches, I want the upstream decided its final name.

Ack.

I think we haven't really tried to unify the format naming in the past
between the two subsystems. If existing conventions exist on both regarding
this format, then it's probably better to follow those.

Cc Laurent as well.


reviewed now so the interface that the future hopefully-in-mainline driver
provides will not change.


---
  include/uapi/linux/videodev2.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 46e8a2e3..9e03f20 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -551,6 +551,7 @@ struct v4l2_pix_format {
  #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 
4:2:2  */
  #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 
4:4:4  */
  #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 
4:4:4  */
+#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15  Y/CbCr 
4:2:0, 10 bits per channel */
  /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
  #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 
4:2:0  */
@@ -559,6 +560,7 @@ struct v4l2_pix_format {
  #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 
4:2:2  */
  #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 
4:2:0 64x32 macroblocks */
  #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
Y/CbCr 4:2:0 16x16 macroblocks */
+#define V4L2_PIX_FMT_P010M   v4l2_fourcc('P', 'M', '1', '0') /* 15  Y/CbCr 
4:2:0, 10 bits per channel */
  /* three planes - Y Cb, Cr */
  #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1: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

Re: [PATCH 0/2] Add support for the RainShadow Tech HDMI CEC adapter

[Hans Verkuil]

Dmitry: ping!

And of course a happy New Year to you as well!

Regards,

Hans

On 12/15/16 14:02, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series adds support to the RainShadow Tech HDMI CEC adapter
(http://rainshadowtech.com/HdmiCecUsb.html).

The first patch adds the needed serio ID, the second adds the driver itself.

Dmitry, will you take the first patch, or can we take it together with the
second patch?

This is of course for 4.11.

Regards,

Hans

Hans Verkuil (2):
  serio.h: add SERIO_RAINSHADOW_CEC ID
  rainshadow-cec: new RainShadow Tech HDMI CEC driver

 MAINTAINERS   |   7 +
 drivers/media/usb/Kconfig |   1 +
 drivers/media/usb/Makefile|   1 +
 drivers/media/usb/rainshadow-cec/Kconfig  |  10 +
 drivers/media/usb/rainshadow-cec/Makefile |   1 +
 drivers/media/usb/rainshadow-cec/rainshadow-cec.c | 344 ++
 include/uapi/linux/serio.h|   1 +
 7 files changed, 365 insertions(+)
 create mode 100644 drivers/media/usb/rainshadow-cec/Kconfig
 create mode 100644 drivers/media/usb/rainshadow-cec/Makefile
 create mode 100644 drivers/media/usb/rainshadow-cec/rainshadow-cec.c



--
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 for v4.10 2/2] cec-intro.rst: mention the v4l-utils package and CEC utilities

[Hans Verkuil]

From: Hans Verkuil 

Mention where to find the CEC utilities.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/cec/cec-intro.rst | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/media/uapi/cec/cec-intro.rst 
b/Documentation/media/uapi/cec/cec-intro.rst
index 7d31d37..07ee2b8 100644
--- a/Documentation/media/uapi/cec/cec-intro.rst
+++ b/Documentation/media/uapi/cec/cec-intro.rst
@@ -26,3 +26,15 @@ control just the CEC pin.
 Drivers that support CEC will create a CEC device node (/dev/cecX) to
 give userspace access to the CEC adapter. The
 :ref:`CEC_ADAP_G_CAPS` ioctl will tell userspace what it is allowed to do.
+
+In order to check the support and test it, it is suggested to download
+the `v4l-utils `_ package. It
+provides three tools to handle CEC:
+
+- cec-ctl: the Swiss army knife of CEC. Allows you to configure, transmit
+  and monitor CEC messages.
+
+- cec-compliance: does a CEC compliance test of a remote CEC device to
+  determine how compliant the CEC implementation is.
+
+- cec-follower: emulates a CEC follower.
-- 
2.8.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 for v4.10 1/2] cec rst: remove "This API is not yet finalized" notice

[Hans Verkuil]

From: Hans Verkuil 

The API is now finalized, so this notice should be dropped.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/cec/cec-func-close.rst   | 5 -
 Documentation/media/uapi/cec/cec-func-ioctl.rst   | 5 -
 Documentation/media/uapi/cec/cec-func-open.rst| 5 -
 Documentation/media/uapi/cec/cec-func-poll.rst| 5 -
 Documentation/media/uapi/cec/cec-intro.rst| 5 -
 Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst  | 5 -
 Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst | 5 -
 Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst | 5 -
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst  | 5 -
 Documentation/media/uapi/cec/cec-ioc-g-mode.rst   | 5 -
 Documentation/media/uapi/cec/cec-ioc-receive.rst  | 5 -
 11 files changed, 55 deletions(-)

diff --git a/Documentation/media/uapi/cec/cec-func-close.rst 
b/Documentation/media/uapi/cec/cec-func-close.rst
index 8267c31..895d9c2 100644
--- a/Documentation/media/uapi/cec/cec-func-close.rst
+++ b/Documentation/media/uapi/cec/cec-func-close.rst
@@ -33,11 +33,6 @@ Arguments
 Description
 ===
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 Closes the cec device. Resources associated with the file descriptor are
 freed. The device configuration remain unchanged.
 
diff --git a/Documentation/media/uapi/cec/cec-func-ioctl.rst 
b/Documentation/media/uapi/cec/cec-func-ioctl.rst
index 9e8dbb1..7dcfd17 100644
--- a/Documentation/media/uapi/cec/cec-func-ioctl.rst
+++ b/Documentation/media/uapi/cec/cec-func-ioctl.rst
@@ -39,11 +39,6 @@ Arguments
 Description
 ===
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 The :c:func:`ioctl()` function manipulates cec device parameters. The
 argument ``fd`` must be an open file descriptor.
 
diff --git a/Documentation/media/uapi/cec/cec-func-open.rst 
b/Documentation/media/uapi/cec/cec-func-open.rst
index af3f5b5..0304388 100644
--- a/Documentation/media/uapi/cec/cec-func-open.rst
+++ b/Documentation/media/uapi/cec/cec-func-open.rst
@@ -46,11 +46,6 @@ Arguments
 Description
 ===
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 To open a cec device applications call :c:func:`open()` with the
 desired device name. The function has no side effects; the device
 configuration remain unchanged.
diff --git a/Documentation/media/uapi/cec/cec-func-poll.rst 
b/Documentation/media/uapi/cec/cec-func-poll.rst
index cfb73e6..6a863cf 100644
--- a/Documentation/media/uapi/cec/cec-func-poll.rst
+++ b/Documentation/media/uapi/cec/cec-func-poll.rst
@@ -39,11 +39,6 @@ Arguments
 Description
 ===
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 With the :c:func:`poll()` function applications can wait for CEC
 events.
 
diff --git a/Documentation/media/uapi/cec/cec-intro.rst 
b/Documentation/media/uapi/cec/cec-intro.rst
index 4a19ea5..7d31d37 100644
--- a/Documentation/media/uapi/cec/cec-intro.rst
+++ b/Documentation/media/uapi/cec/cec-intro.rst
@@ -3,11 +3,6 @@
 Introduction
 
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 HDMI connectors provide a single pin for use by the Consumer Electronics
 Control protocol. This protocol allows different devices connected by an
 HDMI cable to communicate. The protocol for CEC version 1.4 is defined
diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst 
b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
index 2b0ddb1..a0e961f 100644
--- a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
@@ -29,11 +29,6 @@ Arguments
 Description
 ===
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is currently only available as a staging kernel module.
-
 All cec devices must support :ref:`ioctl CEC_ADAP_G_CAPS `. 
To query
 device information, applications call the ioctl with a pointer to a
 struct :c:type:`cec_caps`. The driver fills the structure and
diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst 
b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst
index b878637..09f09bb 100644
--- a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst
@@ -35,11 +35,6 @@ Arguments
 Description
 ===
 
-.. note::
-
-   This documents the proposed CEC API. This API is not yet finalized
-   and is current

[PATCH for v4.10 0/2] CEC documentation updates

[Hans Verkuil]

From: Hans Verkuil 

Two documentation updates that should go to 4.10.

Regards,

Hans

Hans Verkuil (2):
  cec rst: remove "This API is not yet finalized" notice
  cec-intro.rst: mention the v4l-utils package and CEC utilities

 Documentation/media/uapi/cec/cec-func-close.rst |  5 -
 Documentation/media/uapi/cec/cec-func-ioctl.rst |  5 -
 Documentation/media/uapi/cec/cec-func-open.rst  |  5 -
 Documentation/media/uapi/cec/cec-func-poll.rst  |  5 -
 Documentation/media/uapi/cec/cec-intro.rst  | 17 -
 Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst|  5 -
 .../media/uapi/cec/cec-ioc-adap-g-log-addrs.rst |  5 -
 .../media/uapi/cec/cec-ioc-adap-g-phys-addr.rst |  5 -
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst|  5 -
 Documentation/media/uapi/cec/cec-ioc-g-mode.rst |  5 -
 Documentation/media/uapi/cec/cec-ioc-receive.rst|  5 -
 11 files changed, 12 insertions(+), 55 deletions(-)

-- 
2.8.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 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[Sakari Ailus]

Hi,

On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:
> 
> 
> On 01/02/2017 05:10 PM, Sakari Ailus wrote:
> >Hi Randy,
> >
> >Thanks for the patch.
> >
> >On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
> >>The formats added by this patch are:
> >>V4L2_PIX_FMT_P010
> >>V4L2_PIX_FMT_P010M
> >>Currently, none of driver uses those format, but some video device
> >>has been confirmed with could as those format for video output.
> >>The Rockchip's new decoder has supported those format for profile_10
> >>HEVC/AVC video.
> >>
> >>Signed-off-by: Randy Li 
> >If the format resembles the existing formats but on a different bit depth,
> >it should be named in similar fashion.
> Do you mean it would be better if it is called as NV12_10?

If it otherwise resembles NV12 but just has 10 bits per pixel, I think
NV12_10 is a good name for it.

> >
> >Could you also add ReST documentation for the format, please?
> I will.
> >
> >The common requirement for merging patches that change interfaces has been
> >that there's a user for that change. It'll still help you to get this
> The kernel used in rockchip has supported that format in drm driver, but
> just we don't have a agreement about the pixel format. As the Gstreamer and
> some others would call it with a P010_ prefix, but Mark(rockchip's drm
> author) prefer the something like NV12_10, that is why I sent out those
> patches, I want the upstream decided its final name.

Ack.

I think we haven't really tried to unify the format naming in the past
between the two subsystems. If existing conventions exist on both regarding
this format, then it's probably better to follow those.

Cc Laurent as well.

> >reviewed now so the interface that the future hopefully-in-mainline driver
> >provides will not change.
> >
> >>---
> >>  include/uapi/linux/videodev2.h | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >>diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> >>index 46e8a2e3..9e03f20 100644
> >>--- a/include/uapi/linux/videodev2.h
> >>+++ b/include/uapi/linux/videodev2.h
> >>@@ -551,6 +551,7 @@ struct v4l2_pix_format {
> >>  #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16  
> >> Y/CrCb 4:2:2  */
> >>  #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24  
> >> Y/CbCr 4:4:4  */
> >>  #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24  
> >> Y/CrCb 4:4:4  */
> >>+#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15  Y/CbCr 
> >>4:2:0, 10 bits per channel */
> >>  /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
> >>  #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  
> >> Y/CbCr 4:2:0  */
> >>@@ -559,6 +560,7 @@ struct v4l2_pix_format {
> >>  #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  
> >> Y/CrCb 4:2:2  */
> >>  #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  
> >> Y/CbCr 4:2:0 64x32 macroblocks */
> >>  #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
> >> Y/CbCr 4:2:0 16x16 macroblocks */
> >>+#define V4L2_PIX_FMT_P010M   v4l2_fourcc('P', 'M', '1', '0') /* 15  Y/CbCr 
> >>4:2:0, 10 bits per channel */
> >>  /* three planes - Y Cb, Cr */
> >>  #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 
> >> 4:1:0 */
> 

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[ayaka]

On 01/02/2017 05:10 PM, Sakari Ailus wrote:

Hi Randy,

Thanks for the patch.

On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:

The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those format for profile_10
HEVC/AVC video.

Signed-off-by: Randy Li 

If the format resembles the existing formats but on a different bit depth,
it should be named in similar fashion.

Do you mean it would be better if it is called as NV12_10?


Could you also add ReST documentation for the format, please?

I will.


The common requirement for merging patches that change interfaces has been
that there's a user for that change. It'll still help you to get this
The kernel used in rockchip has supported that format in drm driver, but 
just we don't have a agreement about the pixel format. As the Gstreamer 
and some others would call it with a P010_ prefix, but Mark(rockchip's 
drm author) prefer the something like NV12_10, that is why I sent out 
those patches, I want the upstream decided its final name.

reviewed now so the interface that the future hopefully-in-mainline driver
provides will not change.


---
  include/uapi/linux/videodev2.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 46e8a2e3..9e03f20 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -551,6 +551,7 @@ struct v4l2_pix_format {
  #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 
4:2:2  */
  #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 
4:4:4  */
  #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 
4:4:4  */
+#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15  Y/CbCr 
4:2:0, 10 bits per channel */
  
  /* two non contiguous planes - one Y, one Cr + Cb interleaved  */

  #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 
4:2:0  */
@@ -559,6 +560,7 @@ struct v4l2_pix_format {
  #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 
4:2:2  */
  #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 
4:2:0 64x32 macroblocks */
  #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
Y/CbCr 4:2:0 16x16 macroblocks */
+#define V4L2_PIX_FMT_P010M   v4l2_fourcc('P', 'M', '1', '0') /* 15  Y/CbCr 
4:2:0, 10 bits per channel */
  
  /* three planes - Y Cb, Cr */

  #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1: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

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[Sakari Ailus]

Hi Randy,

Thanks for the patch.

On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
> The formats added by this patch are:
>   V4L2_PIX_FMT_P010
>   V4L2_PIX_FMT_P010M
> Currently, none of driver uses those format, but some video device
> has been confirmed with could as those format for video output.
> The Rockchip's new decoder has supported those format for profile_10
> HEVC/AVC video.
> 
> Signed-off-by: Randy Li 

If the format resembles the existing formats but on a different bit depth,
it should be named in similar fashion.

Could you also add ReST documentation for the format, please?

The common requirement for merging patches that change interfaces has been
that there's a user for that change. It'll still help you to get this
reviewed now so the interface that the future hopefully-in-mainline driver
provides will not change.

> ---
>  include/uapi/linux/videodev2.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 46e8a2e3..9e03f20 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -551,6 +551,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 
> 4:2:2  */
>  #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 
> 4:4:4  */
>  #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 
> 4:4:4  */
> +#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15  Y/CbCr 
> 4:2:0, 10 bits per channel */
>  
>  /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 
> 4:2:0  */
> @@ -559,6 +560,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 
> 4:2:2  */
>  #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 
> 4:2:0 64x32 macroblocks */
>  #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
> Y/CbCr 4:2:0 16x16 macroblocks */
> +#define V4L2_PIX_FMT_P010M   v4l2_fourcc('P', 'M', '1', '0') /* 15  Y/CbCr 
> 4:2:0, 10 bits per channel */
>  
>  /* three planes - Y Cb, Cr */
>  #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 
> 4:1:0 */

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[Randy Li]

The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those format for profile_10
HEVC/AVC video.

Signed-off-by: Randy Li 
---
 include/uapi/linux/videodev2.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 46e8a2e3..9e03f20 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -551,6 +551,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 
4:2:2  */
 #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 
4:4:4  */
 #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 
4:4:4  */
+#define V4L2_PIX_FMT_P010v4l2_fourcc('P', '0', '1', '0') /* 15  Y/CbCr 
4:2:0, 10 bits per channel */
 
 /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
 #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 
4:2:0  */
@@ -559,6 +560,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 
4:2:2  */
 #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 
4:2:0 64x32 macroblocks */
 #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  
Y/CbCr 4:2:0 16x16 macroblocks */
+#define V4L2_PIX_FMT_P010M   v4l2_fourcc('P', 'M', '1', '0') /* 15  Y/CbCr 
4:2:0, 10 bits per channel */
 
 /* three planes - Y Cb, Cr */
 #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1:0  
   */
-- 
2.7.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] drm_fourcc: Add new P010 video format

[Randy Li]

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format. Rockchip's vop support this
video format(little endian only) as the input video format.

Signed-off-by: Randy Li 
---
 include/uapi/drm/drm_fourcc.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7f..d2721da 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -119,6 +119,7 @@ extern "C" {
 #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1 
subsampled Cb:Cr plane */
 #define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /* 
non-subsampled Cr:Cb plane */
 #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cr:Cb plane 10 bits per channel */
 
 /*
  * 3 plane YCbCr
-- 
2.7.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 0/2] Add pixel format for 10 bits YUV video

[Randy Li]

Those pixel formats comes from Gstreamer and ffmpeg. Currently,
the VOP(video output mixer) found on RK3288 and future support
those pixel formats are input. Also the decoder on RK3288
could use them as output.

Randy Li (2):
  drm_fourcc: Add new P010 video format
  [media] v4l: Add 10-bits per channel YUV pixel formats

 include/uapi/drm/drm_fourcc.h  | 1 +
 include/uapi/linux/videodev2.h | 2 ++
 2 files changed, 3 insertions(+)

-- 
2.7.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