Re: [PATCH v13 06/25] omap3isp: Use generic parser for parsing fwnode endpoints
Hi! > Instead of using driver implementation, use > v4l2_async_notifier_parse_fwnode_endpoints() to parse the fwnode endpoints > of the device. > > Signed-off-by: Sakari Ailus > Acked-by: Hans Verkuil Patches at least up to here look fine o me. We are at version 13 of the series... Is merge of the series expected anytimme soon? If not, can we at least merge patches up to here, so that less stuff is retransmitted over and over? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v13 11/25] v4l: async: Introduce helpers for calling async ops callbacks
On Fri 2017-09-15 17:17:10, Sakari Ailus wrote: > Add three helper functions to call async operations callbacks. Besides > simplifying callbacks, this allows async notifiers to have no ops set, > i.e. it can be left NULL. > > Signed-off-by: Sakari Ailus > Acked-by: Hans Verkuil I'd remove "_call" from these names; they are long enough already and do not add much. But either way is okay. Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v13 06/25] omap3isp: Use generic parser for parsing fwnode endpoints
On Sat 2017-09-16 09:04:31, Pavel Machek wrote: > Hi! > > > Instead of using driver implementation, use > > v4l2_async_notifier_parse_fwnode_endpoints() to parse the fwnode endpoints > > of the device. > > > > Signed-off-by: Sakari Ailus > > Acked-by: Hans Verkuil > > Patches at least up to here look fine o me. I went through some others. So, 2,4,5,6,10,12: Acked-by: Pavel Machek Best regards, -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH] [media] Maxi Radio: Delete an error message for a failed memory allocation in maxiradio_probe()
From: Markus Elfring
Date: Sat, 16 Sep 2017 10:15:29 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/radio/radio-maxiradio.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/radio/radio-maxiradio.c
b/drivers/media/radio/radio-maxiradio.c
index 3aa5ad391581..995bdc7ff4e6 100644
--- a/drivers/media/radio/radio-maxiradio.c
+++ b/drivers/media/radio/radio-maxiradio.c
@@ -125,7 +125,5 @@ static int maxiradio_probe(struct pci_dev *pdev,
- if (dev == NULL) {
- dev_err(&pdev->dev, "not enough memory\n");
+ if (!dev)
return -ENOMEM;
- }
v4l2_dev = &dev->v4l2_dev;
v4l2_device_set_name(v4l2_dev, "maxiradio", &maxiradio_instance);
--
2.14.1
[PATCH 0/3] [media] MR800: Adjustments for usb_amradio_probe()
From: Markus Elfring Date: Sat, 16 Sep 2017 12:35:43 +0200 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete two error messages for a failed memory allocation Improve a size determination Delete an unnecessary variable initialisation drivers/media/radio/radio-mr800.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) -- 2.14.1
[PATCH 1/3] [media] mr800: Delete two error messages for a failed memory allocation in usb_amradio_probe()
From: Markus Elfring
Date: Sat, 16 Sep 2017 11:23:53 +0200
Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/radio/radio-mr800.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/radio/radio-mr800.c
b/drivers/media/radio/radio-mr800.c
index c9f59129af79..63a9b92ab495 100644
--- a/drivers/media/radio/radio-mr800.c
+++ b/drivers/media/radio/radio-mr800.c
@@ -518,5 +518,4 @@ static int usb_amradio_probe(struct usb_interface *intf,
if (!radio) {
- dev_err(&intf->dev, "kmalloc for amradio_device failed\n");
retval = -ENOMEM;
goto err;
}
@@ -526,5 +525,4 @@ static int usb_amradio_probe(struct usb_interface *intf,
if (!radio->buffer) {
- dev_err(&intf->dev, "kmalloc for radio->buffer failed\n");
retval = -ENOMEM;
goto err_nobuf;
}
--
2.14.1
[PATCH 2/3] [media] mr800: Improve a size determination in usb_amradio_probe()
From: Markus Elfring
Date: Sat, 16 Sep 2017 11:34:11 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/radio/radio-mr800.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/radio/radio-mr800.c
b/drivers/media/radio/radio-mr800.c
index 63a9b92ab495..7c4554ce1cf0 100644
--- a/drivers/media/radio/radio-mr800.c
+++ b/drivers/media/radio/radio-mr800.c
@@ -515,4 +515,3 @@ static int usb_amradio_probe(struct usb_interface *intf,
- radio = kzalloc(sizeof(struct amradio_device), GFP_KERNEL);
-
+ radio = kzalloc(sizeof(*radio), GFP_KERNEL);
if (!radio) {
--
2.14.1
Re: [PATCH] [media] solo6x10: hide unused variable
On Fri, Sep 15, 2017 at 09:52:04PM +0200, Arnd Bergmann wrote:
> When building without CONFIG_GPIOLIB, we get a harmless
> warning about an unused variable:
>
> drivers/media/pci/solo6x10/solo6x10-gpio.c: In function 'solo_gpio_init':
> drivers/media/pci/solo6x10/solo6x10-gpio.c:165:6: error: unused variable
> 'ret' [-Werror=unused-variable]
>
> This adds another #ifdef around the declaration.
>
> Fixes: d3202d1981dc ("media: solo6x10: export hardware GPIO pins 8:31 to
> gpiolib interface")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/media/pci/solo6x10/solo6x10-gpio.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/pci/solo6x10/solo6x10-gpio.c
> b/drivers/media/pci/solo6x10/solo6x10-gpio.c
> index 3d0d1aa2f6a8..7b4641a2cb84 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-gpio.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-gpio.c
> @@ -162,7 +162,9 @@ static void solo_gpiochip_set(struct gpio_chip *chip,
>
> int solo_gpio_init(struct solo_dev *solo_dev)
> {
> +#ifdef CONFIG_GPIOLIB
> int ret;
> +#endif
>
> solo_gpio_config(solo_dev);
> #ifdef CONFIG_GPIOLIB
> --
> 2.9.0
>
Acked-by: Anton Sviridenko
[PATCH 3/3] [media] mr800: Delete an unnecessary variable initialisation in usb_amradio_probe()
From: Markus Elfring
Date: Sat, 16 Sep 2017 11:39:50 +0200
The variable "retval" will eventually be set to an appropriate value
a bit later. Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
drivers/media/radio/radio-mr800.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/radio/radio-mr800.c
b/drivers/media/radio/radio-mr800.c
index 7c4554ce1cf0..a1f4dc9be284 100644
--- a/drivers/media/radio/radio-mr800.c
+++ b/drivers/media/radio/radio-mr800.c
@@ -511,5 +511,5 @@ static int usb_amradio_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
struct amradio_device *radio;
- int retval = 0;
+ int retval;
--
2.14.1
[PATCH 0/3] [media] WL1273: Adjustments for two function implementations
From: Markus Elfring Date: Sat, 16 Sep 2017 14:05:45 +0200 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an error message for a failed memory allocation Delete an unnecessary goto statement Delete an unnecessary variable initialisation drivers/media/radio/radio-wl1273.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) -- 2.14.1
[PATCH 1/3] [media] WL1273: Delete an error message for a failed memory allocation in wl1273_fm_radio_probe()
From: Markus Elfring
Date: Sat, 16 Sep 2017 13:28:38 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/radio/radio-wl1273.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
index 903fcd5e99c0..020a792173f6 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -2034,5 +2034,4 @@ static int wl1273_fm_radio_probe(struct platform_device
*pdev)
if (!radio->buffer) {
- pr_err("Cannot allocate memory for RDS buffer.\n");
r = -ENOMEM;
goto pdata_err;
}
--
2.14.1
[PATCH 2/3] [media] WL1273: Delete an unnecessary goto statement in wl1273_fm_suspend()
From: Markus Elfring
Date: Sat, 16 Sep 2017 13:53:22 +0200
* Remove an extra goto statement.
* Delete the label "out" which became unnecessary with this refactoring.
Signed-off-by: Markus Elfring
---
drivers/media/radio/radio-wl1273.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
index 020a792173f6..74dc3195ea2c 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -683,12 +683,9 @@ static int wl1273_fm_suspend(struct wl1273_device *radio)
else
r = -EINVAL;
- if (r) {
+ if (r)
dev_err(radio->dev, "%s: POWER_SET fails: %d\n", __func__, r);
- goto out;
- }
-out:
return r;
}
--
2.14.1
[PATCH 3/3] [media] WL1273: Delete an unnecessary variable initialisation in wl1273_fm_suspend()
From: Markus Elfring
Date: Sat, 16 Sep 2017 13:55:56 +0200
The local variable "r" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring
---
drivers/media/radio/radio-wl1273.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
index 74dc3195ea2c..b8f08bfc31c3 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -671,6 +671,6 @@ static int wl1273_fm_start(struct wl1273_device *radio, int
new_mode)
static int wl1273_fm_suspend(struct wl1273_device *radio)
{
struct wl1273_core *core = radio->core;
- int r = 0;
+ int r;
/* Cannot go from OFF to SUSPENDED */
--
2.14.1
Re: [GIT PULL] SAA716x DVB driver
On 09.09.2017 23:20, Mauro Carvalho Chehab wrote: > Em Sat, 9 Sep 2017 14:52:18 +0200 > Soeren Moch escreveu: > >> Hi Mauro, >> >> sorry for the late reply, unfortunately your email was filtered out as spam. > I'll focus talking about saa716x/av7110 here, as this is out of of > scope of the documentation patches. > >> On 27.08.2017 12:30, Mauro Carvalho Chehab wrote: >>> Em Fri, 21 Jul 2017 22:44:42 +0200 >>> Soeren Moch escreveu: >>> Hi Mauro, On 20.07.2017 07:49:36 -0300, Mauro Carvalho Chehab wrote: > Hi Soeren, > > Em Sun, 16 Jul 2017 20:34:23 +0200 > Soeren Moch escreveu: > >> This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from >> Philips/NXP. The most important of these cards, at least for me, is the >> TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the >> successor of the famous ttpci decoder cards. Other supported cards are: >> Avermedia H788 >> Avermedia HC82 Express-54 >> KNC One Dual S2 >> KWorld DVB-T PE310 >> Technisat SkyStar 2 eXpress HD >> Twinhan/Azurewave VP-1028 >> Twinhan/Azurewave VP-3071 >> Twinhan/Azurewave VP-6002 >> Twinhan/Azurewave VP-6090 >> >> The driver is taken from [1] with adaptations for current mainline, >> converted to git and moved to drivers/staging/media. See TODO for >> required cleanups (from my point of view, maybe more to come from >> additional code review by other developers). I added myself as driver >> maintainer to document my commitment to further development to get this >> out of staging, help from others welcome. >> >> This driver was licensed "GPL" from the beginning. S2-6400 firmware is >> available at [2]. >> >> I want to preserve the development history of the driver, since this >> is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss. >> Unfortunately Andreas seems not to take care of this driver anymore, he >> also did not answer my requests to integrate patches for newer kernel >> versions. So I send this upstream. >> >> With all the history this is a 280 part patch series, so I send this as >> pull request. Of course I can also send this as 'git send-email' series >> if desired. > Even on staging, reviewing a 280 patch series take a while ;) > > As the patches that make it build with current upstream are at the > end of the series, you need to be sure that the saa716x Makefile > won't be included until those fixes get applied. It seems you took > care of it already, with is good! > > > The hole idea of adding a driver to staging is that it will be moved > some day out of staging. That's why a TODO and an entry at MAINTAINERS > is required. > > By looking at the saa716x_ff_main: > > https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/saa716x_ff_main.c > I'm seeing that the main problem of this driver is that it still use > the API from the legacy ttpci driver, e. g. DVB audio, video and osd APIs. > > Those APIs were deprecated because they duplicate a functionality > provided by the V4L2 API, and are obscure, because they're not > properly documented. Also, no other driver uses it upstream. > > So, it was agreed several years ago that new full featured drivers > should use the V4L2 API for audio/video codecs. > > We have a some drivers that use V4L2 for MPEG audio/video decoding > and encoding. The best examples are ivtv and cx18 (as both are for > PCI devices). Currently, none of those drivers support the DVB > API, though, as they're used only on analog TV devices. > > It was also agreed that setup pipelines on more complex DVB > devices should use the media controller API (MC API). > > Yet, we don't have, currently, any full featured drivers upstream > (except for the legacy one). > > So, if we're willing to apply this driver, you should be committed > to do implement the media APIs properly, porting from DVB > audio/video/osd to V4L2 and MC APIs. > > That should also reflect its TODO: > > https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/TODO Thanks for your feedback. I understand all your concerns about the legacy API and your request to convert this to v4l2. For me the whole story looks a little bit different, though. The only application which makes use of the decoder part of this saa716x_ff driver is VDR (Video Disk Recorder by Klaus Schmidinger, [1] [2]) - if anybody else knows about a different use-case, please speak up! In fact the high-definition version of VDR (vdr-2.x) was co-developed with the S2-6400 hardware and this saa716x_ff driver. So it is no surprise, that this driver utilizes
[PATCH 0/3] [media] si470x: Adjustments for si470x_usb_driver_probe()
From: Markus Elfring Date: Sat, 16 Sep 2017 15:16:17 +0200 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an error message for a failed memory allocation Improve a size determination Delete an unnecessary variable initialisation drivers/media/radio/si470x/radio-si470x-usb.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 2.14.1
[PATCH 1/3] [media] si470x: Delete an error message for a failed memory allocation in si470x_usb_driver_probe()
From: Markus Elfring
Date: Sat, 16 Sep 2017 14:53:49 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/radio/si470x/radio-si470x-usb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-usb.c
b/drivers/media/radio/si470x/radio-si470x-usb.c
index c311f9951d80..af295530b20f 100644
--- a/drivers/media/radio/si470x/radio-si470x-usb.c
+++ b/drivers/media/radio/si470x/radio-si470x-usb.c
@@ -618,5 +618,4 @@ static int si470x_usb_driver_probe(struct usb_interface
*intf,
if (!radio->int_in_buffer) {
- dev_info(&intf->dev, "could not allocate int_in_buffer");
retval = -ENOMEM;
goto err_usbbuf;
}
--
2.14.1
[PATCH 2/3] [media] si470x: Improve a size determination in si470x_usb_driver_probe()
From: Markus Elfring
Date: Sat, 16 Sep 2017 14:58:06 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/radio/si470x/radio-si470x-usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-usb.c
b/drivers/media/radio/si470x/radio-si470x-usb.c
index af295530b20f..6fc6e8235f20 100644
--- a/drivers/media/radio/si470x/radio-si470x-usb.c
+++ b/drivers/media/radio/si470x/radio-si470x-usb.c
@@ -584,5 +584,5 @@ static int si470x_usb_driver_probe(struct usb_interface
*intf,
/* private data allocation and initialization */
- radio = kzalloc(sizeof(struct si470x_device), GFP_KERNEL);
+ radio = kzalloc(sizeof(*radio), GFP_KERNEL);
if (!radio) {
retval = -ENOMEM;
goto err_initial;
--
2.14.1
[PATCH 3/3] [media] si470x: Delete an unnecessary variable initialisation in si470x_usb_driver_probe()
From: Markus Elfring Date: Sat, 16 Sep 2017 15:08:39 +0200 The variable "retval" will eventually be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring --- drivers/media/radio/si470x/radio-si470x-usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/radio/si470x/radio-si470x-usb.c b/drivers/media/radio/si470x/radio-si470x-usb.c index 6fc6e8235f20..ae30e3da9d13 100644 --- a/drivers/media/radio/si470x/radio-si470x-usb.c +++ b/drivers/media/radio/si470x/radio-si470x-usb.c @@ -578,6 +578,6 @@ static int si470x_usb_driver_probe(struct usb_interface *intf, struct si470x_device *radio; struct usb_host_interface *iface_desc; struct usb_endpoint_descriptor *endpoint; - int i, int_end_size, retval = 0; + int i, int_end_size, retval; unsigned char version_warning = 0; -- 2.14.1
[PATCHv4 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil
Implement support for this DisplayPort feature.
The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the previous one, then the old cec device is
unregistered and a new one is registered to replace the old one.
Signed-off-by: Hans Verkuil
Tested-by: Carlos Santa
---
drivers/gpu/drm/i915/intel_dp.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 64fa774c855b..fdb853d2c458 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1449,6 +1450,7 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
static void
intel_dp_aux_fini(struct intel_dp *intel_dp)
{
+ cec_unregister_adapter(intel_dp->aux.cec_adap);
kfree(intel_dp->aux.name);
}
@@ -4587,6 +4589,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_connector->detect_edid = edid;
intel_dp->has_audio = drm_detect_monitor_audio(edid);
+ cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
}
static void
@@ -4596,6 +4599,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
+ cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
intel_dp->has_audio = false;
}
@@ -4616,13 +4620,17 @@ intel_dp_long_pulse(struct intel_connector
*intel_connector)
intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
/* Can't disconnect eDP, but you can close the lid... */
- if (is_edp(intel_dp))
+ if (is_edp(intel_dp)) {
status = edp_detect(intel_dp);
- else if (intel_digital_port_connected(to_i915(dev),
- dp_to_dig_port(intel_dp)))
+ } else if (intel_digital_port_connected(to_i915(dev),
+ dp_to_dig_port(intel_dp))) {
status = intel_dp_detect_dpcd(intel_dp);
- else
+ if (status == connector_status_connected)
+ drm_dp_cec_configure_adapter(&intel_dp->aux,
+intel_dp->aux.name, dev->dev);
+ } else {
status = connector_status_disconnected;
+ }
if (status == connector_status_disconnected) {
memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
@@ -5011,6 +5019,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
+ drm_dp_cec_irq(&intel_dp->aux);
+
if (intel_dp->is_mst) {
if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
/*
--
2.14.1
[PATCHv4 2/3] drm-kms-helpers.rst: document the DP CEC helpers
From: Hans Verkuil Document the Display Port CEC helper functions. Signed-off-by: Hans Verkuil --- Documentation/gpu/drm-kms-helpers.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 7c5e2549a58a..0d2fa879edd1 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -175,6 +175,15 @@ Display Port Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c :export: +Display Port CEC Helper Functions Reference +=== + +.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c + :doc: dp cec helpers + +.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c + :export: + Display Port Dual Mode Adaptor Helper Functions Reference = -- 2.14.1
[PATCHv4 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX
From: Hans Verkuil
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is created, it may not actually work.
Signed-off-by: Hans Verkuil
Tested-by: Carlos Santa
---
drivers/gpu/drm/Kconfig | 10 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_dp_cec.c | 292 +++
include/drm/drm_dp_helper.h | 24
4 files changed, 327 insertions(+)
create mode 100644 drivers/gpu/drm/drm_dp_cec.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 83cb2a88c204..1f2708df5c4e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -120,6 +120,16 @@ config DRM_LOAD_EDID_FIRMWARE
default case is N. Details and instructions how to build your own
EDID data are given in Documentation/EDID/HOWTO.txt.
+config DRM_DP_CEC
+ bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
+ select CEC_CORE
+ help
+ Choose this option if you want to enable HDMI CEC support for
+ DisplayPort/USB-C to HDMI adapters.
+
+ Note: not all adapters support this feature, and even for those
+ that do support this they often do not hook up the CEC pin.
+
config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e1841c..c6552c62049e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -40,6 +40,7 @@ drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) +=
drm_edid_load.o
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
+drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
new file mode 100644
index ..d110cac007de
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -0,0 +1,292 @@
+/*
+ * DisplayPort CEC-Tunneling-over-AUX support
+ *
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Unfortunately it turns out that we have a chicken-and-egg situation
+ * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
+ * have a converter chip that supports CEC-Tunneling-over-AUX (usually the
+ * Parade PS176), but they do not wire up the CEC pin, thus making CEC
+ * useless.
+ *
+ * Sadly there is no way for this driver to know this. What happens is
+ * that a /dev/cecX device is created that is isolated and unable to see
+ * any of the other CEC devices. Quite literally the CEC wire is cut
+ * (or in this case, never connected in the first place).
+ *
+ * I suspect that the reason so few adapters support this is that this
+ * tunneling protocol was never supported by any OS. So there was no
+ * easy way of testing it, and no incentive to correctly wire up the
+ * CEC pin.
+ *
+ * Hopefully by creating this driver it will be easier for vendors to
+ * finally fix their adapters and test the CEC functionality.
+ *
+ * I keep a list of known working adapters here:
+ *
+ * https://hverkuil.home.xs4all.nl/cec-status.txt
+ *
+ * Please mail me (hverk...@xs4all.nl) if you find an adapter that works
+ * and is not yet listed there.
+ */
+
+/**
+ * DOC: dp cec helpers
+ *
+ * These functions take care of supporting the CEC-Tunneling-over-AUX
+ * feature of DisplayPort-to-HDMI adapters.
+ */
+
+static int drm_dp_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+ struct drm_dp_aux *aux = cec_get_drvdata(adap);
+ u32 val = enable ? DP_CEC_TUNNELING_ENABLE : 0;
+ ssize_t err = 0;
+
+ err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, val);
+ return (enable && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
+{
+ struct drm_dp_aux *aux = cec_get_drvdata(adap);
[PATCHv4 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
From: Hans Verkuil
This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
feature. This patch series is based on the current pre-4.14-rc1 mainline
which has all the needed cec 4.14 patches merged.
This patch series has been tested with my NUC7i5BNK and a Samsung USB-C to
HDMI adapter.
Please note this comment at the start of drm_dp_cec.c:
--
Unfortunately it turns out that we have a chicken-and-egg situation
here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
have a converter chip that supports CEC-Tunneling-over-AUX (usually the
Parade PS176), but they do not wire up the CEC pin, thus making CEC
useless.
Sadly there is no way for this driver to know this. What happens is
that a /dev/cecX device is created that is isolated and unable to see
any of the other CEC devices. Quite literally the CEC wire is cut
(or in this case, never connected in the first place).
I suspect that the reason so few adapters support this is that this
tunneling protocol was never supported by any OS. So there was no
easy way of testing it, and no incentive to correctly wire up the
CEC pin.
Hopefully by creating this driver it will be easier for vendors to
finally fix their adapters and test the CEC functionality.
I keep a list of known working adapters here:
https://hverkuil.home.xs4all.nl/cec-status.txt
Please mail me (hverk...@xs4all.nl) if you find an adapter that works
and is not yet listed there.
--
I really hope that this work will provide an incentive for vendors to
finally connect the CEC pin. It's a shame that there are so few adapters
that work (I found only two USB-C to HDMI adapters that work, and no
(mini-)DP to HDMI adapters at all).
Note that a colleague who actually knows his way around a soldering iron
modified an UpTab DisplayPort-to-HDMI adapter for me, hooking up the CEC
pin. And after that change it worked. I also received confirmation that
this really is a chicken-and-egg situation: it is because there is no CEC
support for this feature in any OS that they do not hook up the CEC pin.
So hopefully if this gets merged there will be an incentive for vendors
to make adapters where this actually works. It is a very nice feature
for HTPC boxes.
Changes since v3:
Incorporated Ville's comments. The two main changes (besides some small
readability changes) are:
- use drm_dp_read_desc() in drm_dp_cec_adap_status().
- drop the 'for (attempts = 0...)' loop in drm_dp_cec_irq().
Changes since v2:
- Use the new CEC_CAP_DEFAULTS define
- Replace 'if (!IS_ERR_OR_NULL(aux->cec_adap)) {' in
drm_dp_cec_configure_adapter()
by just 'if (aux->cec_adap) {'.
Changes since v1:
- Incorporated Sean's review comments in patch 1/3.
Regards,
Hans
Hans Verkuil (3):
drm: add support for DisplayPort CEC-Tunneling-over-AUX
drm-kms-helpers.rst: document the DP CEC helpers
drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
Documentation/gpu/drm-kms-helpers.rst | 9 ++
drivers/gpu/drm/Kconfig | 10 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_dp_cec.c | 292 ++
drivers/gpu/drm/i915/intel_dp.c | 18 ++-
include/drm/drm_dp_helper.h | 24 +++
6 files changed, 350 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/drm_dp_cec.c
--
2.14.1
[PATCHv5 5/5] MAINTAINERS: add cec-gpio entry
From: Hans Verkuil Add an entry for the CEC GPIO driver. Signed-off-by: Hans Verkuil --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index eb930ebecfcb..5ef0d34ef502 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3205,6 +3205,15 @@ F: include/uapi/linux/cec.h F: include/uapi/linux/cec-funcs.h F: Documentation/devicetree/bindings/media/cec.txt +CEC GPIO DRIVER +M: Hans Verkuil +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Supported +F: drivers/media/platform/cec-gpio/ +F: Documentation/devicetree/bindings/media/cec-gpio.txt + CELL BROADBAND ENGINE ARCHITECTURE M: Arnd Bergmann L: linuxppc-...@lists.ozlabs.org -- 2.14.1
[PATCHv5 3/5] dt-bindings: document the CEC GPIO bindings
From: Hans Verkuil
Document the bindings for the cec-gpio module for hardware where the
CEC line and optionally the HPD line are connected to GPIO lines.
Signed-off-by: Hans Verkuil
---
.../devicetree/bindings/media/cec-gpio.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt
b/Documentation/devicetree/bindings/media/cec-gpio.txt
new file mode 100644
index ..1b7e13f36b08
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
@@ -0,0 +1,29 @@
+* HDMI CEC GPIO driver
+
+The HDMI CEC GPIO module supports CEC implementations where the CEC line
+is hooked up to a pull-up GPIO line and - optionally - the HPD line is
+hooked up to another GPIO line.
+
+Required properties:
+ - compatible: value must be "cec-gpio".
+ - cec-gpios: gpio that the CEC line is connected to.
+
+If the CEC line is associated with an HDMI receiver/transmitter, then the
+following property is also required:
+
+ - hdmi-phandle - phandle to the HDMI controller, see also cec.txt.
+
+If the CEC line is not associated with an HDMI receiver/transmitter, then
+the following property is optional:
+
+ - hpd-gpios: gpio that the HPD line is connected to.
+
+Example for the Raspberry Pi 3 where the CEC line is connected to
+pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
+connected to pin 11 aka BCM17:
+
+cec-gpio {
+ compatible = "cec-gpio";
+ cec-gpio = <&gpio 7 GPIO_OPEN_DRAIN>;
+ hpd-gpio = <&gpio 17 GPIO_ACTIVE_HIGH>;
+};
--
2.14.1
[PATCHv5 2/5] cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events
From: Hans Verkuil
Document these new CEC events.
Signed-off-by: Hans Verkuil
---
Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
index db615e3405c0..32b47763f5a6 100644
--- a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
@@ -160,6 +160,24 @@ it is guaranteed that the state did change in between the
two events.
- Generated if the CEC pin goes from a low voltage to a high voltage.
Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
capability set.
+* .. _`CEC-EVENT-PIN-HPD-LOW`:
+
+ - ``CEC_EVENT_PIN_HPD_LOW``
+ - 5
+ - Generated if the HPD pin goes from a high voltage to a low voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+ capability set. When open() is called, the HPD pin can be read and
+ the HPD is low, then an initial event will be generated for that
+ filehandle.
+* .. _`CEC-EVENT-PIN-HPD-HIGH`:
+
+ - ``CEC_EVENT_PIN_HPD_HIGH``
+ - 6
+ - Generated if the HPD pin goes from a low voltage to a high voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+ capability set. When open() is called, the HPD pin can be read and
+ the HPD is high, then an initial event will be generated for that
+ filehandle.
.. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}|
--
2.14.1
[PATCHv5 0/5] cec-gpio: add HDMI CEC GPIO-based driver
From: Hans Verkuil This driver adds support for CEC implementations that use a pull-up GPIO line. While SoCs exist that do this, the primary use-case is to turn a single-board computer into a cheap CEC debugger. Together with 'cec-ctl --monitor-pin' you can do low-level CEC bus monitoring and do protocol analysis. And error injection is also planned for the future. Here is an example using the Raspberry Pi 3: https://hverkuil.home.xs4all.nl/rpi3-cec.jpg While this example is for the Rpi, this driver will work for any SoC with a pull-up GPIO line. In addition the cec-gpio driver can optionally monitor the HPD line. The state of the HPD line influences the CEC behavior so it is very useful to be able to monitor both. And some HDMI sinks are known to quickly toggle the HPD when e.g. switching between inputs. So it is useful to be able to see an event when the HPD changes value. The first two patches add support for the new HPD events. The last three patches are for the cec-gpio driver itself. Regards, Hans Changes since v4: - cec-gpio.txt: *-gpio -> *-gpios - cec-gpio.txt: document hdmi-phandle. To be used when cec-gpio is associated with an HDMI receiver/transmitter. - cec-gpio.txt: remove incorrect @7 from dts example. Changes since v3: - cec-gpio.txt: refer to lines instead of pins and use OPEN_DRAIN in the example. - Kconfig: add select GPIOLIB - cec-gpio.c: switch to gpiod. - cec-core.c: initialize the devnode mutex/list in allocate_adapter. Doing this in register_adapter is too late if the HPD is high. Changes since v2: - Add support for HPD events. - Switch from pin BCM4 to pin BCM7 in the bindings example Changes since v1: - Updated the bindings doc to not refer to the driver, instead refer to the hardware. Hans Verkuil (5): cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events dt-bindings: document the CEC GPIO bindings cec-gpio: add HDMI CEC GPIO driver MAINTAINERS: add cec-gpio entry .../devicetree/bindings/media/cec-gpio.txt | 29 +++ Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 18 ++ MAINTAINERS| 9 + drivers/media/cec/cec-adap.c | 18 +- drivers/media/cec/cec-api.c| 18 +- drivers/media/cec/cec-core.c | 8 +- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile| 2 + drivers/media/platform/cec-gpio/Makefile | 1 + drivers/media/platform/cec-gpio/cec-gpio.c | 236 + include/media/cec-pin.h| 4 + include/media/cec.h| 12 +- include/uapi/linux/cec.h | 2 + 13 files changed, 357 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt create mode 100644 drivers/media/platform/cec-gpio/Makefile create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c -- 2.14.1
[PATCHv5 4/5] cec-gpio: add HDMI CEC GPIO driver
From: Hans Verkuil
Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework.
While I have heard of SoCs that use the GPIO pin for CEC (apparently an
early RockChip SoC used that), the main use-case of this driver is to
function as a debugging tool.
By connecting the CEC line to a GPIO pin on a Raspberry Pi 3 for example
it turns it into a CEC debugger and protocol analyzer.
With 'cec-ctl --monitor-pin' the CEC traffic can be analyzed.
But of course it can also be used with any hardware project where the
HDMI CEC line is hooked up to a pull-up gpio line.
In addition this has (optional) support for tracing HPD changes if the
HPD is connected to a GPIO.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/Kconfig | 10 ++
drivers/media/platform/Makefile| 2 +
drivers/media/platform/cec-gpio/Makefile | 1 +
drivers/media/platform/cec-gpio/cec-gpio.c | 236 +
4 files changed, 249 insertions(+)
create mode 100644 drivers/media/platform/cec-gpio/Makefile
create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49b8674..e4c89a16a3e7 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -553,6 +553,16 @@ config VIDEO_MESON_AO_CEC
This is a driver for Amlogic Meson SoCs AO CEC interface. It uses the
generic CEC framework interface.
CEC bus is present in the HDMI connector and enables communication
+
+config CEC_GPIO
+ tristate "Generic GPIO-based CEC driver"
+ depends on PREEMPT
+ select CEC_CORE
+ select CEC_PIN
+ select GPIOLIB
+ ---help---
+ This is a generic GPIO-based CEC driver.
+ The CEC bus is present in the HDMI connector and enables communication
between compatible devices.
config VIDEO_SAMSUNG_S5P_CEC
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946bf032..9bf48f118537 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_VIDEO_CODA) += coda/
obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
+obj-$(CONFIG_CEC_GPIO) += cec-gpio/
+
obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
diff --git a/drivers/media/platform/cec-gpio/Makefile
b/drivers/media/platform/cec-gpio/Makefile
new file mode 100644
index ..e82b258afa55
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CEC_GPIO) += cec-gpio.o
diff --git a/drivers/media/platform/cec-gpio/cec-gpio.c
b/drivers/media/platform/cec-gpio/cec-gpio.c
new file mode 100644
index ..eb982bce99fc
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/cec-gpio.c
@@ -0,0 +1,236 @@
+/*
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct cec_gpio {
+ struct cec_adapter *adap;
+ struct device *dev;
+
+ struct gpio_desc*cec_gpio;
+ int cec_irq;
+ boolcec_is_low;
+ boolcec_have_irq;
+
+ struct gpio_desc*hpd_gpio;
+ int hpd_irq;
+ boolhpd_is_high;
+ ktime_t hpd_ts;
+};
+
+static bool cec_gpio_read(struct cec_adapter *adap)
+{
+ struct cec_gpio *cec = cec_get_drvdata(adap);
+
+ if (cec->cec_is_low)
+ return false;
+ return gpiod_get_value(cec->cec_gpio);
+}
+
+static void cec_gpio_high(struct cec_adapter *adap)
+{
+ struct cec_gpio *cec = cec_get_drvdata(adap);
+
+ if (!cec->cec_is_low)
+ return;
+ cec->cec_is_low = false;
+ gpiod_set_value(cec->cec_gpio, 1);
+}
+
+static void cec_gpio_low(struct cec_adapter *adap)
+{
+ struct cec_gpio *cec = cec_get_drvdata(adap);
+
+ if (cec->cec_is_low)
+ return;
+ if (WARN_ON_ONCE(cec->cec_have_irq))
+ free_irq(cec->cec_irq, cec);
+
[PATCHv5 1/5] cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events
From: Hans Verkuil
Add support for two new low-level events: PIN_HPD_LOW and PIN_HPD_HIGH.
This is specifically meant for use with the upcoming cec-gpio driver
and makes it possible to trace when the HPD pin changes. Some HDMI
sinks do strange things with the HPD and this makes it easy to debug
this.
Note that this also moves the initialization of a devnode mutex and
list to the allocate_adapter function: if the HPD is high, then as
soon as the HPD interrupt is created an interrupt occurs and
cec_queue_pin_hpd_event() is called which requires that the devnode
mutex and list are initialized.
Signed-off-by: Hans Verkuil
---
drivers/media/cec/cec-adap.c | 18 +-
drivers/media/cec/cec-api.c | 18 ++
drivers/media/cec/cec-core.c | 8
include/media/cec-pin.h | 4
include/media/cec.h | 12 +++-
include/uapi/linux/cec.h | 2 ++
6 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index dd769e40416f..eb904a71609a 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -86,7 +86,7 @@ void cec_queue_event_fh(struct cec_fh *fh,
const struct cec_event *new_ev, u64 ts)
{
static const u8 max_events[CEC_NUM_EVENTS] = {
- 1, 1, 64, 64,
+ 1, 1, 64, 64, 8, 8,
};
struct cec_event_entry *entry;
unsigned int ev_idx = new_ev->event - 1;
@@ -170,6 +170,22 @@ void cec_queue_pin_cec_event(struct cec_adapter *adap,
bool is_high, ktime_t ts)
}
EXPORT_SYMBOL_GPL(cec_queue_pin_cec_event);
+/* Notify userspace that the HPD pin changed state at the given time. */
+void cec_queue_pin_hpd_event(struct cec_adapter *adap, bool is_high, ktime_t
ts)
+{
+ struct cec_event ev = {
+ .event = is_high ? CEC_EVENT_PIN_HPD_HIGH :
+ CEC_EVENT_PIN_HPD_LOW,
+ };
+ struct cec_fh *fh;
+
+ mutex_lock(&adap->devnode.lock);
+ list_for_each_entry(fh, &adap->devnode.fhs, list)
+ cec_queue_event_fh(fh, &ev, ktime_to_ns(ts));
+ mutex_unlock(&adap->devnode.lock);
+}
+EXPORT_SYMBOL_GPL(cec_queue_pin_hpd_event);
+
/*
* Queue a new message for this filehandle.
*
diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index a079f7fe018c..465bb3ec21f6 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -529,7 +529,7 @@ static int cec_open(struct inode *inode, struct file *filp)
* Initial events that are automatically sent when the cec device is
* opened.
*/
- struct cec_event ev_state = {
+ struct cec_event ev = {
.event = CEC_EVENT_STATE_CHANGE,
.flags = CEC_EVENT_FL_INITIAL_STATE,
};
@@ -569,9 +569,19 @@ static int cec_open(struct inode *inode, struct file *filp)
filp->private_data = fh;
/* Queue up initial state events */
- ev_state.state_change.phys_addr = adap->phys_addr;
- ev_state.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
- cec_queue_event_fh(fh, &ev_state, 0);
+ ev.state_change.phys_addr = adap->phys_addr;
+ ev.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
+ cec_queue_event_fh(fh, &ev, 0);
+#ifdef CONFIG_CEC_PIN
+ if (adap->pin && adap->pin->ops->read_hpd) {
+ err = adap->pin->ops->read_hpd(adap);
+ if (err >= 0) {
+ ev.event = err ? CEC_EVENT_PIN_HPD_HIGH :
+CEC_EVENT_PIN_HPD_LOW;
+ cec_queue_event_fh(fh, &ev, 0);
+ }
+ }
+#endif
list_add(&fh->list, &devnode->fhs);
mutex_unlock(&devnode->lock);
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 648136e552d5..e3a1fb6d6690 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -112,10 +112,6 @@ static int __must_check cec_devnode_register(struct
cec_devnode *devnode,
int minor;
int ret;
- /* Initialization */
- INIT_LIST_HEAD(&devnode->fhs);
- mutex_init(&devnode->lock);
-
/* Part 1: Find a free minor number */
mutex_lock(&cec_devnode_lock);
minor = find_next_zero_bit(cec_devnode_nums, CEC_NUM_DEVICES, 0);
@@ -242,6 +238,10 @@ struct cec_adapter *cec_allocate_adapter(const struct
cec_adap_ops *ops,
INIT_LIST_HEAD(&adap->wait_queue);
init_waitqueue_head(&adap->kthread_waitq);
+ /* adap->devnode initialization */
+ INIT_LIST_HEAD(&adap->devnode.fhs);
+ mutex_init(&adap->devnode.lock);
+
adap->kthread = kthread_run(cec_thread_func, adap, "cec-%s", name);
if (IS_ERR(adap->kthread)) {
pr_err("cec-%s: kernel_thread() failed\n", name);
diff --git a/include/media/cec-pin.h b/include/media/cec-pin.h
index f09cc9579d53..e
[PATCH] [media] Si4713: Delete an error message for a failed memory allocation in two functions
From: Markus Elfring
Date: Sat, 16 Sep 2017 16:15:44 +0200
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/radio/si4713/radio-platform-si4713.c | 1 -
drivers/media/radio/si4713/si4713.c| 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/media/radio/si4713/radio-platform-si4713.c
b/drivers/media/radio/si4713/radio-platform-si4713.c
index 27339ec495f6..4b7943e385a0 100644
--- a/drivers/media/radio/si4713/radio-platform-si4713.c
+++ b/drivers/media/radio/si4713/radio-platform-si4713.c
@@ -162,5 +162,4 @@ static int radio_si4713_pdriver_probe(struct
platform_device *pdev)
if (!rsdev) {
- dev_err(&pdev->dev, "Failed to alloc video device.\n");
rval = -ENOMEM;
goto exit;
}
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index f4a53f1e856e..46b1fe36f713 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -1451,5 +1451,4 @@ static int si4713_probe(struct i2c_client *client,
if (!sdev) {
- dev_err(&client->dev, "Failed to alloc video device.\n");
rval = -ENOMEM;
goto exit;
}
--
2.14.1
[PATCH 0/2] [media] FC0012: Adjustments for fc0012_attach()
From: Markus Elfring Date: Sat, 16 Sep 2017 18:03:21 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination drivers/media/tuners/fc0012.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.14.1
[PATCH 1/2] [media] fc0012: Delete an error message for a failed memory allocation in fc0012_attach()
From: Markus Elfring
Date: Sat, 16 Sep 2017 17:47:52 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/tuners/fc0012.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/tuners/fc0012.c b/drivers/media/tuners/fc0012.c
index 625ac6f51c39..7126dd1d5151 100644
--- a/drivers/media/tuners/fc0012.c
+++ b/drivers/media/tuners/fc0012.c
@@ -449,6 +449,5 @@ struct dvb_frontend *fc0012_attach(struct dvb_frontend *fe,
if (!priv) {
ret = -ENOMEM;
- dev_err(&i2c->dev, "%s: kzalloc() failed\n", KBUILD_MODNAME);
goto err;
}
--
2.14.1
[PATCH 2/2] [media] fc0012: Improve a size determination in fc0012_attach()
From: Markus Elfring
Date: Sat, 16 Sep 2017 17:55:27 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/tuners/fc0012.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/tuners/fc0012.c b/drivers/media/tuners/fc0012.c
index 7126dd1d5151..c008513bd64a 100644
--- a/drivers/media/tuners/fc0012.c
+++ b/drivers/media/tuners/fc0012.c
@@ -445,5 +445,5 @@ struct dvb_frontend *fc0012_attach(struct dvb_frontend *fe,
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 1);
- priv = kzalloc(sizeof(struct fc0012_priv), GFP_KERNEL);
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
--
2.14.1
Re: [GIT PULL] SAA716x DVB driver
Em Sat, 16 Sep 2017 14:54:15 +0200 Soeren Moch escreveu: > On 09.09.2017 23:20, Mauro Carvalho Chehab wrote: > > Em Sat, 9 Sep 2017 14:52:18 +0200 > > Soeren Moch escreveu: > > > >> You explicitly > >> want to discourage new driver and application implementations. > > Me? It is just the opposite: sticking with a poorly documented API > > that almost nobody knows seems to be what discouraged new drivers > > and applications. > OK, then you are fine to keep the audio/video/osd API in this driver, great! My current understanding is that keeping audio/video API doesn't make any sense, for a couple of reasons: 1. it was never fully documented; 2. the only upstream hardware that supports them was developed on about 17 years ago; 3. the API is broken with regards to compat32 and Y2038 (see more below); 4. almost all (if not all) features they support are also supported by V4L2 and ALSA; 5. V4L2 supports a lot more features that video decoders support than video API, like H.264 and other newer video standards, plus HDMI setup features. In the past, we tried a lot to get documentation for those DVB APIs, but, unfortunately, nobody that worked on its development sent us patches addressing the API documentation. With regards to OSD, as no other documented API emerged to fulfill what it does, it could make sense to keep it, if someone properly documents it. > >> With linux core APIs for FF you probably mean some new > >> API combination as successor of the audio/video/osd API. > >> The S2-6400 unfortunately directly implements the old API > >> in hardware and is therefore the worst possible match for > >> such new driver generation. > > It sounds weird that the API is directly implemented in hardware. > > I can't tell much, though, as I didn't see the code yet. > All the available code is in this pull request. I know. I'll look on it if we reach an agreement. > I really don't understand your Kaffeine use case. Kaffeine is a media > player, which displays the decoded video on a KDE/Gnome desktop. > With the S2-6400 it is not possible to read the decoded video back, > so it is not possible to display something in a desktop window. > I cannot image what you want to do with this hardware and Kaffeine. I see. > >>> One alternative we could do would be to add the proper APIs for the > >>> driver and keep for a couple of Kernel versions, in staging, a module > >>> that would provide backward compatibility to the legacy APIs. This way, > >>> applications will have some time to add support for the new API. > >>> > >>> If you're willing to do that, I can merge the patches. > >> Here I do not understand what you expect me to do. The audio/video/osd > >> devices are closely tied together (as frontend/demux/dvr are for the > >> input side). The S2-6400 card expects an transport stream with audio and > >> video packets to be written to that video device (the audio device is > >> not used) and commands for overlay text/graphics over the osd device. > > There are two options here: > > > > 1) if the hardware itself allows to direct a filtered MPEG-TS to the demod, > >by hardware, instead of reading it from /dev/dvb/.../dvr and writing it > >to /dev/dvb.../video, you could use the Media Controller to > >direct the video PID to the video decoder hardware directly; > This is what you want me to implement: this shortcut from > /dev/dvb/.../dvr to /dev/dvb.../video ? Since you said above that this > is already implemented in the dvb core, this should be easy and. > can of course be implemented in this driver. > >The V4L2 driver device node (let's say, /dev/video0) will just > >implement the HDMI output. > There is no separate decoder / HDMI hardware, from the driver's > point of view. The decoded video directly goes to the HDMI output. If there's nothing that can be controlled at the HDMI output, why do you need a /dev/dvb.../video devnode? If it can be controlled, a V4L2 output will do the job. > > 2) if there's no hardware pipelines between the demux and the decoders, > >userspace will read video from .../dvr and write it to a /dev/video > >capture device node, implemented by a mem2mem V4L2 driver. > There cannot be a separate capture device node for the decoded > video. You probably refer to the video_cature:one-shot feature, > which is switched off by default. > This is a debug feature, which vdr supports. It is intended to > take a snapshot of the output image, something for debugging > vdr-skins, the graphical user interface of vdr. Ah, so it can't play an arbitrary MPEG-TS stream from other sources, right? > From the msleep(100); in the read path you can easily see, that > this is meant for still images, not for video. Due to bandwidth > limitations on the hardware this should normally not be used > during normal decoding. > >The mem2mem output device node (let's say, /dev/video1) will control > >the HDMI output. > As mentioned several tim
[PATCH 0/2] [media] IT913X: Adjustments for two function implementations
From: Markus Elfring Date: Sat, 16 Sep 2017 20:12:34 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete two error messages for a failed memory allocation Improve three size determinations drivers/media/tuners/it913x.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.14.1
[PATCH 1/2] [media] it913x: Delete two error messages for a failed memory allocation in it913x_probe()
From: Markus Elfring
Date: Sat, 16 Sep 2017 19:40:47 +0200
* Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
* Delete the label "err" and the variable "ret" which became unnecessary
with this refactoring.
Signed-off-by: Markus Elfring
---
drivers/media/tuners/it913x.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/media/tuners/it913x.c b/drivers/media/tuners/it913x.c
index 27e5bc1c3cb5..6af9507823fa 100644
--- a/drivers/media/tuners/it913x.c
+++ b/drivers/media/tuners/it913x.c
@@ -392,14 +392,10 @@ static int it913x_probe(struct platform_device *pdev)
struct it913x_dev *dev;
const struct platform_device_id *id = platform_get_device_id(pdev);
- int ret;
char *chip_ver_str;
dev = kzalloc(sizeof(struct it913x_dev), GFP_KERNEL);
- if (dev == NULL) {
- ret = -ENOMEM;
- dev_err(&pdev->dev, "kzalloc() failed\n");
- goto err;
- }
+ if (!dev)
+ return -ENOMEM;
dev->pdev = pdev;
dev->regmap = pdata->regmap;
@@ -423,9 +419,6 @@ static int it913x_probe(struct platform_device *pdev)
chip_ver_str);
dev_dbg(&pdev->dev, "chip_ver %u, role %u\n", dev->chip_ver, dev->role);
return 0;
-err:
- dev_dbg(&pdev->dev, "failed %d\n", ret);
- return ret;
}
static int it913x_remove(struct platform_device *pdev)
--
2.14.1
[PATCH 2/2] [media] it913x: Improve three size determinations
From: Markus Elfring Date: Sat, 16 Sep 2017 20:06:01 +0200 Replace the specification of data structures by variable references as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. Signed-off-by: Markus Elfring --- drivers/media/tuners/it913x.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/media/tuners/it913x.c b/drivers/media/tuners/it913x.c index 6af9507823fa..149f36d5e503 100644 --- a/drivers/media/tuners/it913x.c +++ b/drivers/media/tuners/it913x.c @@ -393,5 +393,5 @@ static int it913x_probe(struct platform_device *pdev) const struct platform_device_id *id = platform_get_device_id(pdev); char *chip_ver_str; - dev = kzalloc(sizeof(struct it913x_dev), GFP_KERNEL); + dev = kzalloc(sizeof(*dev), GFP_KERNEL); if (!dev) @@ -404,8 +404,7 @@ static int it913x_probe(struct platform_device *pdev) dev->role = pdata->role; fe->tuner_priv = dev; - memcpy(&fe->ops.tuner_ops, &it913x_tuner_ops, - sizeof(struct dvb_tuner_ops)); + memcpy(&fe->ops.tuner_ops, &it913x_tuner_ops, sizeof(it913x_tuner_ops)); platform_set_drvdata(pdev, dev); if (dev->chip_ver == 1) @@ -427,8 +426,7 @@ static int it913x_remove(struct platform_device *pdev) struct dvb_frontend *fe = dev->fe; dev_dbg(&pdev->dev, "\n"); - - memset(&fe->ops.tuner_ops, 0, sizeof(struct dvb_tuner_ops)); + memset(&fe->ops.tuner_ops, 0, sizeof(it913x_tuner_ops)); fe->tuner_priv = NULL; kfree(dev); -- 2.14.1
[PATCH 0/2] [media] M88RS6000T: Adjustments for two function implementations
From: Markus Elfring Date: Sat, 16 Sep 2017 21:48:45 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve three size determinations drivers/media/tuners/m88rs6000t.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) -- 2.14.1
[PATCH 1/2] [media] tuners: Delete an error message for a failed memory allocation in m88rs6000t_probe()
From: Markus Elfring
Date: Sat, 16 Sep 2017 21:24:27 +0200
* Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
* Add a jump target so that the function "kfree" will be always called
with a non-null pointer.
Signed-off-by: Markus Elfring
---
drivers/media/tuners/m88rs6000t.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/tuners/m88rs6000t.c
b/drivers/media/tuners/m88rs6000t.c
index 9f3e0fd4cad9..d89793a05862 100644
--- a/drivers/media/tuners/m88rs6000t.c
+++ b/drivers/media/tuners/m88rs6000t.c
@@ -626,6 +626,5 @@ static int m88rs6000t_probe(struct i2c_client *client,
if (!dev) {
ret = -ENOMEM;
- dev_err(&client->dev, "kzalloc() failed\n");
- goto err;
+ goto report_failure;
}
@@ -701,8 +700,9 @@ static int m88rs6000t_probe(struct i2c_client *client,
i2c_set_clientdata(client, dev);
return 0;
err:
- dev_dbg(&client->dev, "failed=%d\n", ret);
kfree(dev);
+report_failure:
+ dev_dbg(&client->dev, "failed=%d\n", ret);
return ret;
}
--
2.14.1
[PATCH 2/2] [media] m88rs6000t: Improve three size determinations
From: Markus Elfring
Date: Sat, 16 Sep 2017 21:38:03 +0200
Replace the specification of data structures by variable references
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/media/tuners/m88rs6000t.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/tuners/m88rs6000t.c
b/drivers/media/tuners/m88rs6000t.c
index d89793a05862..1e55c679b25e 100644
--- a/drivers/media/tuners/m88rs6000t.c
+++ b/drivers/media/tuners/m88rs6000t.c
@@ -629,6 +629,6 @@ static int m88rs6000t_probe(struct i2c_client *client,
}
- memcpy(&dev->cfg, cfg, sizeof(struct m88rs6000t_config));
+ memcpy(&dev->cfg, cfg, sizeof(*cfg));
dev->client = client;
dev->regmap = devm_regmap_init_i2c(client, ®map_config);
if (IS_ERR(dev->regmap)) {
@@ -696,7 +696,7 @@ static int m88rs6000t_probe(struct i2c_client *client,
fe->tuner_priv = dev;
memcpy(&fe->ops.tuner_ops, &m88rs6000t_tuner_ops,
- sizeof(struct dvb_tuner_ops));
+ sizeof(fe->ops.tuner_ops));
i2c_set_clientdata(client, dev);
return 0;
err:
@@ -712,8 +712,7 @@ static int m88rs6000t_remove(struct i2c_client *client)
struct dvb_frontend *fe = dev->cfg.fe;
dev_dbg(&client->dev, "\n");
-
- memset(&fe->ops.tuner_ops, 0, sizeof(struct dvb_tuner_ops));
+ memset(&fe->ops.tuner_ops, 0, sizeof(fe->ops.tuner_ops));
fe->tuner_priv = NULL;
kfree(dev);
--
2.14.1
Re: IMX6 ADV7180 no /dev/media
On Fri, Sep 15, 2017 at 8:46 PM, Fabio Estevam wrote: > Tim, > > Care to send the patch enabling CONFIG_VIDEO_MUX? Nevermind. I have just sent it.
[PATCH 1/2] Store device structure in dvb_register_device
From: Jasmin Jessich
The device created by device_create in dvb_register_device was not
available for DVB device drivers.
Added "struct device *dev" to "struct dvb_device" and store the created
device.
Signed-off-by: Jasmin Jessich
---
drivers/media/dvb-core/dvbdev.c | 1 +
drivers/media/dvb-core/dvbdev.h | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 41aad0f..fef9d7c 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -516,6 +516,7 @@ int dvb_register_device(struct dvb_adapter *adap, struct
dvb_device **pdvbdev,
__func__, adap->num, dnames[type], id, PTR_ERR(clsdev));
return PTR_ERR(clsdev);
}
+ dvbdev->dev = clsdev;
dprintk("DVB: register adapter%d/%s%d @ minor: %i (0x%02x)\n",
adap->num, dnames[type], id, minor, minor);
diff --git a/drivers/media/dvb-core/dvbdev.h b/drivers/media/dvb-core/dvbdev.h
index 4918939..94667c8 100644
--- a/drivers/media/dvb-core/dvbdev.h
+++ b/drivers/media/dvb-core/dvbdev.h
@@ -126,10 +126,11 @@ struct dvb_adapter {
* @tsout_num_entities: Number of Transport Stream output entities
* @tsout_entity: array with MC entities associated to each TS output node
* @tsout_pads: array with the source pads for each @tsout_entity
+ * @dev: pointer to struct device that is associated with the dvb device
*
* This structure is used by the DVB core (frontend, CA, net, demux) in
* order to create the device nodes. Usually, driver should not initialize
- * this struct diretly.
+ * this struct directly.
*/
struct dvb_device {
struct list_head list_head;
@@ -162,6 +163,7 @@ struct dvb_device {
#endif
void *priv;
+ struct device *dev;
};
/**
--
2.7.4
[PATCH 2/2] Added timers for dvb_ca_en50221_write_data
From: Jasmin Jessich
Some (older) CAMs are really slow in accepting data. The CI interface
specification doesn't define a handshake for accepted data. Thus, the
en50221 protocol driver can't control if a data byte has been correctly
written to the CAM.
The current implementation writes the length and the data quick after
each other. Thus, the slow CAMs may generate a WR error, which leads to
the known error logging
"CAM tried to send a buffer larger than the ecount size".
To solve this issue the en50221 protocol driver needs to wait some CAM
depending time between the different bytes to be written. Because the
time is CAM dependent, an individual value per CAM needs to be set. For
that SysFS is used in favor of ioctl's to allow the control of the timer
values independent from any user space application.
This patch adds the timers and the SysFS nodes to set/get the timeout
values and the timer waiting between the different steps of the CAM write
access. A timer value of 0 (default) means "no timeout".
Signed-off-by: Jasmin Jessich
---
drivers/media/dvb-core/dvb_ca_en50221.c | 132 +++-
1 file changed, 131 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c
b/drivers/media/dvb-core/dvb_ca_en50221.c
index 95b3723..50c4e45 100644
--- a/drivers/media/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb-core/dvb_ca_en50221.c
@@ -86,6 +86,13 @@ MODULE_PARM_DESC(cam_debug, "enable verbose debug messages");
#define DVB_CA_SLOTSTATE_WAITFR 6
#define DVB_CA_SLOTSTATE_LINKINIT 7
+enum dvb_ca_timers {
+ DVB_CA_TIM_WR_HIGH /* wait after writing length high */
+, DVB_CA_TIM_WR_LOW /* wait after writing length low */
+, DVB_CA_TIM_WR_DATA /* wait between data bytes */
+, DVB_CA_TIM_MAX
+};
+
/* Information on a CA slot */
struct dvb_ca_slot {
/* current state of the CAM */
@@ -119,6 +126,11 @@ struct dvb_ca_slot {
unsigned long timeout;
};
+struct dvb_ca_timer {
+ unsigned long min;
+ unsigned long max;
+};
+
/* Private CA-interface information */
struct dvb_ca_private {
struct kref refcount;
@@ -161,6 +173,14 @@ struct dvb_ca_private {
/* mutex serializing ioctls */
struct mutex ioctl_mutex;
+
+ struct dvb_ca_timer timers[DVB_CA_TIM_MAX];
+};
+
+static const char dvb_ca_tim_names[DVB_CA_TIM_MAX][15] = {
+ "tim_wr_high"
+, "tim_wr_low"
+, "tim_wr_data"
};
static void dvb_ca_private_free(struct dvb_ca_private *ca)
@@ -223,6 +243,14 @@ static char *findstr(char *haystack, int hlen, char
*needle, int nlen)
return NULL;
}
+static void dvb_ca_sleep(struct dvb_ca_private *ca, enum dvb_ca_timers tim)
+{
+ unsigned long min = ca->timers[tim].min;
+
+ if (min)
+ usleep_range(min, ca->timers[tim].max);
+}
+
/* **
*/
/* EN50221 physical interface functions */
@@ -868,10 +896,13 @@ static int dvb_ca_en50221_write_data(struct
dvb_ca_private *ca, int slot,
bytes_write >> 8);
if (status)
goto exit;
+ dvb_ca_sleep(ca, DVB_CA_TIM_WR_HIGH);
+
status = ca->pub->write_cam_control(ca->pub, slot, CTRLIF_SIZE_LOW,
bytes_write & 0xff);
if (status)
goto exit;
+ dvb_ca_sleep(ca, DVB_CA_TIM_WR_LOW);
/* send the buffer */
for (i = 0; i < bytes_write; i++) {
@@ -879,6 +910,7 @@ static int dvb_ca_en50221_write_data(struct dvb_ca_private
*ca, int slot,
buf[i]);
if (status)
goto exit;
+ dvb_ca_sleep(ca, DVB_CA_TIM_WR_DATA);
}
/* check for write error (WE should now be 0) */
@@ -1832,6 +1864,97 @@ static const struct dvb_device dvbdev_ca = {
};
/* **
*/
+/* EN50221 device attributes (SysFS) */
+
+static int dvb_ca_tim_idx(struct dvb_ca_private *ca, const char *name)
+{
+ int tim_idx;
+
+ for (tim_idx = 0; tim_idx < DVB_CA_TIM_MAX; tim_idx++) {
+ if (!strcmp(dvb_ca_tim_names[tim_idx], name))
+ return tim_idx;
+ }
+ return -1;
+}
+
+static ssize_t dvb_ca_tim_show(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct dvb_device *dvbdev = dev_get_drvdata(device);
+ struct dvb_ca_private *ca = dvbdev->priv;
+ int tim_idx = dvb_ca_tim_idx(ca, attr->attr.name);
+
+ if (tim_idx < 0)
+ return -ENXIO;
+
+ return sprintf(buf, "%ld\n", ca->timers[tim_idx].min);
+}
+
+static ssize_t dvb_ca_tim_store(struct device *device,
+ struct device_attribute *attr,
+ const char *buf, siz
[PATCH 0/2] Add timers to en50221 protocol driver
From: Jasmin Jessich Some (older) CAMs are really slow in accepting data. I got sometimes the already known error "CAM tried to send a buffer larger than the ecount size". I could track it down to the dvb_ca_en50221_write_data function not waiting between sending the data length high/low and data bytes. In fact the CAM reported a WR error, which triggered later on the mentioned error. The problem is that a simple module parameter can't be used to solve this by adding timer values, because the protocol handler is used for any CI interface. A module parameter would be influence all the CAMs on all CI interfaces. Thus individual timer definitions per CI interface and CAM are required. There are two possibilities to implement that, ioctl's and SysFS. ioctl's require changes in usermode programs and it my take a lot of time to get this implemented there. SysFS can be used by simple "cat" and "echo" commands and can be therefore simply controlled by scripting, which is immediately available. I decided to go for the SysFS approach, but the required device to add the SysFS files was not available in the "struct dvb_device". The first patch of this series adds this device to the structure and also the setting code. The second patch adds the functions to create the SysFS nodes for all timers and the new timeouts in the en50221 protocol driver. Jasmin Jessich (2): Store device structure in dvb_register_device Added timers for dvb_ca_en50221_write_data drivers/media/dvb-core/dvb_ca_en50221.c | 132 +++- drivers/media/dvb-core/dvbdev.c | 1 + drivers/media/dvb-core/dvbdev.h | 4 +- 3 files changed, 135 insertions(+), 2 deletions(-) -- 2.7.4
cron job: media_tree daily build: WARNINGS
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: Sun Sep 17 05:00:21 CEST 2017 media-tree git hash:1efdf1776e2253b77413c997bed862410e4b6aaf media_build git hash: 19087750b61fc0c5528e798c47ff845f9234 v4l-utils git hash: 8d89a6ad9940f520ae4e816c3973551e52557d71 gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.12.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: 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: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: WARNINGS linux-3.12.67-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9.26-i686: OK linux-4.10.14-i686: OK linux-4.11-i686: OK linux-4.12.1-i686: OK linux-4.13-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12.67-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: WARNINGS linux-4.9.26-x86_64: WARNINGS linux-4.10.14-x86_64: WARNINGS linux-4.11-x86_64: WARNINGS linux-4.12.1-x86_64: WARNINGS linux-4.13-x86_64: OK apps: OK spec-git: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: dvb_usb_rtl2832u vs dvb_usb_rtl28xxu
On 10/09/17 09:29, Eyal Lebedinsky wrote: I was running f19 and had dvb_usb_rtl2832u built from git handling my "Leadtek Winfast DTV2000 DS PLUS TV" tuners. https://www.linuxtv.org/wiki/index.php/Leadtek_WinFast_DTV2000DS_PLUS I am using jaredquinn's driver Yesterday I upgraded to f22 and the tuners stopped working. I discovered that dvb_usb_rtl2832u failed to build (my rc.local had rules for this). A small fix sorted this out but the tuners still did not work. I then noticed a new module is activated, dvb_usb_rtl28xxu. I blacklisted it and now the tuners work. My question: is dvb_usb_rtl28xxu supposed to handle this card? I now tried it and while it does not log issues at boot, and it does create the expected frontend devices, it fails to tune to any channel (using mythtv). I will try again after I upgrade to f26. Or should I continue to build the out of kernel module? Or, is there another module to handle this card now? TIA -- Eyal Lebedinsky (e...@eyal.emu.id.au)
[PATCH 0/2] [media] Si2157: Adjustments for two function implementations
From: Markus Elfring Date: Sun, 17 Sep 2017 08:48:24 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination in two functions drivers/media/tuners/si2157.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 2.14.1
[PATCH 1/2] [media] si2157: Delete an error message for a failed memory allocation in si2157_probe()
From: Markus Elfring
Date: Sun, 17 Sep 2017 08:20:04 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/tuners/si2157.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index e35b1faf0ddc..aefa85718496 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -439,6 +439,5 @@ static int si2157_probe(struct i2c_client *client,
if (!dev) {
ret = -ENOMEM;
- dev_err(&client->dev, "kzalloc() failed\n");
goto err;
}
--
2.14.1
[PATCH 2/2] [media] si2157: Improve a size determination in two functions
From: Markus Elfring Date: Sun, 17 Sep 2017 08:32:17 +0200 Replace the specification of data structures by variable references as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. Signed-off-by: Markus Elfring --- drivers/media/tuners/si2157.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c index aefa85718496..e3e2027a5027 100644 --- a/drivers/media/tuners/si2157.c +++ b/drivers/media/tuners/si2157.c @@ -457,7 +457,7 @@ static int si2157_probe(struct i2c_client *client, if (ret) goto err_kfree; - memcpy(&fe->ops.tuner_ops, &si2157_ops, sizeof(struct dvb_tuner_ops)); + memcpy(&fe->ops.tuner_ops, &si2157_ops, sizeof(si2157_ops)); fe->tuner_priv = client; #ifdef CONFIG_MEDIA_CONTROLLER @@ -514,7 +514,7 @@ static int si2157_remove(struct i2c_client *client) media_device_unregister_entity(&dev->ent); #endif - memset(&fe->ops.tuner_ops, 0, sizeof(struct dvb_tuner_ops)); + memset(&fe->ops.tuner_ops, 0, sizeof(fe->ops.tuner_ops)); fe->tuner_priv = NULL; kfree(dev); -- 2.14.1
