Re: Hauppauge WinTV-HVR2205 driver feedback
On 06/03/2015 10:08 PM, Olli Salonen wrote: I cold booted my number cruncher after a hiatus of a couple of weeks, applied a couple of extra dev_dbg printouts in the si2168_cmd_execute and installed the newly built module. The results: [ 663.147757] si2168 2-0066: Silicon Labs Si2168 successfully attached [ 663.151735] si2157 1-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 663.152436] DVB: registering new adapter (saa7164) [ 663.152441] saa7164 :07:00.0: DVB: registering adapter 1 frontend 0 (Silicon Labs Si2168)... [ 678.690104] si2168:si2168_init: si2168 2-0064: [ 678.690111] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 13, rlen: 0 [ 678.690115] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0 12 00 0c 00 0d 16 00 00 00 00 00 00 [ 678.693331] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 8, rlen: 1 [ 678.693337] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0 06 01 0f 00 20 20 01 [ 678.701914] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80 [ 678.701920] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 6 ms [ 678.701923] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 1, rlen: 13 [ 678.701926] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: 02 [ 678.708631] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80 00 44 34 30 02 00 00 00 00 00 00 00 [ 678.708636] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 2 ms [ 678.708639] si2168 2-0064: unknown chip version Si2168- [ 678.714777] si2168:si2168_init: si2168 2-0064: failed=-22 [ 678.727424] si2157 0-0060: found a 'Silicon Labs Si2157-A30' [ 678.783587] si2157 0-0060: firmware version: 3.0.5 The answer to the 02 command seems really odd. You can see it is a Si2168, version 40, but I'd expect the second octet to say 42 instead of 00. Yeah, very odd. That byte should be letter A (0x41) or B (0x42) or likely C (0x43) in future when current C revision chips are seen. Are you really sure it has returned (and worked) 0x42 earlier? Have you used Windows driver - I speculate if it could make permanent upgrade to chip to change it. Timing issues are also possible. Maybe you could test with some extra sleeps, like adding 100ms delay between command request and reply. Unfortunately value of those 3 bytes are really important as driver selects firmware to download according them. regards Antti -- http://palosaari.fi/ -- 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 1/2] media: new media controller API for device resource support
Em Wed, 03 Jun 2015 12:14:09 -0600
Shuah Khan shua...@osg.samsung.com escreveu:
On 06/03/2015 11:42 AM, Mauro Carvalho Chehab wrote:
Em Wed, 03 Jun 2015 09:12:53 -0600
Shuah Khan shua...@osg.samsung.com escreveu:
Add new media controller API to allocate media device as a
device resource. When a media device is created on the main
struct device which is the parent device for the interface
device, it will be available to all drivers associated with
that interface. For example, if a usb media device driver
creates the media device on the main struct device which is
common for all the drivers that control the media device,
including the non-media ALSA driver, media controller API
can be used to share access to the resources on the media
device. This new interface provides the above described
feature. A second interface that finds and returns the media
device is added to allow drivers to find the media device
created by any of the drivers associated with the device.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/media-device.c | 33 +
include/media/media-device.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 7b39440..a4d5b24 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -462,3 +462,36 @@ void media_device_unregister_entity(struct
media_entity *entity)
entity-parent = NULL;
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity);
+
+static void media_device_release_devres(struct device *dev, void *res)
+{
+}
+
+/*
+ * media_device_get_devres() -get media device as device resource
+ *creates if one doesn't exist
+*/
+struct media_device *media_device_get_devres(struct device *dev)
+{
+ struct media_device *mdev;
+
+ mdev = devres_find(dev, media_device_release_devres, NULL, NULL);
+ if (mdev)
+ return mdev;
+
+ mdev = devres_alloc(media_device_release_devres,
+ sizeof(struct media_device), GFP_KERNEL);
+ if (!mdev)
+ return NULL;
+ return devres_get(dev, mdev, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(media_device_get_devres);
+
+/*
+ * media_device_find_devres() - find media device as device resource
+*/
+struct media_device *media_device_find_devres(struct device *dev)
+{
+ return devres_find(dev, media_device_release_devres, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(media_device_find_devres);
diff --git a/include/media/media-device.h b/include/media/media-device.h
index 6e6db78..22792cd 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -95,6 +95,8 @@ void media_device_unregister(struct media_device *mdev);
int __must_check media_device_register_entity(struct media_device *mdev,
struct media_entity *entity);
void media_device_unregister_entity(struct media_entity *entity);
+struct media_device *media_device_get_devres(struct device *dev);
+struct media_device *media_device_find_devres(struct device *dev);
Hmm... what happens if the Kernel is compiled without MC controller
support?
Yeah. I noticed media controller api users have the code in ifdef
CONFIG_MEDIA_CONTROLLER.
I think that the best would be to add a #ifdef at the header file and
provide an alternate dummy method to avoid the need of testing for it
everywhere.
I agree with you that a better way to do it would be defining media
controller api in ifdef CONFIG_MEDIA_CONTROLLER and provide stubs for
else case, similar to what I did in sound/usb/media.c
I followed the existing code to add new interfaces. Do you want to see
all media controller interfaces in ifdef clause with stubs or just the
two new interfaces I added? Or is this something that should be done as
a separate change to catch all media controller interfaces?
It could be on a separate patch. IMHO, the best is to put all defines
on stubs.
thanks,
-- Shuah
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
I cold booted my number cruncher after a hiatus of a couple of weeks, applied a couple of extra dev_dbg printouts in the si2168_cmd_execute and installed the newly built module. The results: [ 663.147757] si2168 2-0066: Silicon Labs Si2168 successfully attached [ 663.151735] si2157 1-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 663.152436] DVB: registering new adapter (saa7164) [ 663.152441] saa7164 :07:00.0: DVB: registering adapter 1 frontend 0 (Silicon Labs Si2168)... [ 678.690104] si2168:si2168_init: si2168 2-0064: [ 678.690111] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 13, rlen: 0 [ 678.690115] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0 12 00 0c 00 0d 16 00 00 00 00 00 00 [ 678.693331] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 8, rlen: 1 [ 678.693337] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: c0 06 01 0f 00 20 20 01 [ 678.701914] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80 [ 678.701920] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 6 ms [ 678.701923] si2168:si2168_cmd_execute: si2168 2-0064: wlen: 1, rlen: 13 [ 678.701926] si2168:si2168_cmd_execute: si2168 2-0064: i2c write: 02 [ 678.708631] si2168:si2168_cmd_execute: si2168 2-0064: i2c read: 80 00 44 34 30 02 00 00 00 00 00 00 00 [ 678.708636] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 2 ms [ 678.708639] si2168 2-0064: unknown chip version Si2168- [ 678.714777] si2168:si2168_init: si2168 2-0064: failed=-22 [ 678.727424] si2157 0-0060: found a 'Silicon Labs Si2157-A30' [ 678.783587] si2157 0-0060: firmware version: 3.0.5 The answer to the 02 command seems really odd. You can see it is a Si2168, version 40, but I'd expect the second octet to say 42 instead of 00. Cheers, -olli On 3 June 2015 at 17:34, Antti Palosaari cr...@iki.fi wrote: On 06/03/2015 12:29 PM, Olli Salonen wrote: I'm seeing the same issue as well. I thought that maybe some recent Si2168 changes did impact this, but it does not seem to be the case. I made a quick test myself. I reverted the latest si2168 patches one by one, but that did not remedy the situation. Anyway, the kernel log does not seem to indicate that the si2168_cmd_execute itself would fail (which is what happens after the I2C error handling patch in case the demod sets the error bit). olli@dl160:~/src/media_tree/drivers/media/dvb-frontends$ git log --oneline si2168.c d4b3830 Revert [media] si2168: add support for gapped clock eb62eb1 Revert [media] si2168: add I2C error handling 7adf99d [media] si2168: add I2C error handling 8117a31 [media] si2168: add support for gapped clock 17d4d6a [media] si2168: add support for 1.7MHz bandwidth 683e98b [media] si2168: return error if set_frontend is called with invalid para c32b281 [media] si2168: change firmware variable name and type 9b7839c [media] si2168: print chip version dmesg lines when it fails (this is with a card that has worked before): [1.336898] saa7164[0]: registered device video0 [mpeg] [1.567295] saa7164[0]: registered device video1 [mpeg] [1.778660] saa7164[0]: registered device vbi0 [vbi] [1.778817] saa7164[0]: registered device vbi1 [vbi] [66675.175508] si2168:si2168_init: si2168 2-0064: [66675.187299] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 6 ms [66675.194105] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 2 ms [OLLI: The result of this I2C cmd must be bogus] [66675.194110] si2168 2-0064: unknown chip version Si2168- [66675.200244] si2168:si2168_init: si2168 2-0064: failed=-22 [66675.213020] si2157 0-0060: found a 'Silicon Labs Si2157-A30' [66675.242856] si2157 0-0060: firmware version: 3.0.5 Okei, so it has been working earlier... Could you enable I2C debugs to see what kind of data that command returns? What I suspect in first hand is that Windows driver has downloaded firmware to chip and linux driver does it again, but with incompatible firmware, which leads to situation it starts failing. But if that is issue you likely already noted it. regards Antti -- http://palosaari.fi/ -- 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
Manjaro Linux distro-specific hint for media-build
Hi together, I just installed my new DVR-Card. Therefor I had to clone the linuxtv.org/media_build.git and get a text for my distro. I can't write a patch, but with this part of the log I think it will be easy for you to extend the dependency-administration. Greatings! $ git clone git://linuxtv.org/media_build.git Klone nach 'media_build' ... remote: Counting objects: 2855, done. remote: Compressing objects: 100% (1238/1238), done. remote: Total 2855 (delta 2014), reused 2258 (delta 1577) Empfange Objekte: 100% (2855/2855), 544.18 KiB | 972.00 KiB/s, Fertig. Löse Unterschiede auf: 100% (2014/2014), Fertig. Prüfe Konnektivität ... Fertig. $ cd media_build $ ./build Checking if the needed tools for Manjaro Linux are available ERROR: please install lsdiff, otherwise, build won't work. I don't know distro Manjaro Linux. So, I can't provide you a hint with the package names. Be welcome to contribute with a patch for media-build, by submitting a distro-specific hint to linux-media@vger.kernel.org Build can't procceed as 1 dependency is missing at ./build line 266. $ yaourt -S lsdiff Fehler: Ziel nicht gefunden: lsdiff $ yaourt -S patchutils Löse Abhängigkeiten auf... Suche nach in Konflikt stehenden Paketen... Pakete (1) patchutils-0.3.3-1 Gesamtgröße der zu installierenden Pakete: 0,16 MiB :: Installation fortsetzen? [J/n] (1/1) Prüfe Schlüssel im Schlüsselring [] 100% (1/1) Überprüfe Paket-Integrität [] 100% (1/1) Lade Paket-Dateien [] 100% (1/1) Prüfe auf Dateikonflikte [] 100% (1/1) Überprüfe verfügbaren Festplattenspeicher [] 100% (1/1) Installiere patchutils [] 100% $ ./build Checking if the needed tools for Manjaro Linux are available Needed package dependencies are met. * This script will download the latest tarball and build it* * Assuming that your kernel is compatible with the latest * * drivers. If not, you'll need to add some extra backports,* * ./backports/kernel directory. * * It will also update this tree to be sure that all compat * * bits are there, to avoid compilation failures* * All drivers and build system are under GPLv2 License * * Firmware files are under the license terms found at: * * http://www.linuxtv.org/downloads/firmware/ * * Please abort in the next 5 secs if you don't agree with * * the license * Not aborted. It means that the licence was agreed. Proceeding... -- 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 v9 2/8] media: Add registration helpers for V4L2 flash sub-devices
Hi Jacek,
On Wed, Jun 03, 2015 at 09:56:39AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 06/02/2015 05:32 PM, Sakari Ailus wrote:
Hi, Jacek!
On Tue, Jun 02, 2015 at 11:13:54AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 06/01/2015 10:59 PM, Sakari Ailus wrote:
Hi Jacek,
On Mon, May 25, 2015 at 05:13:57PM +0200, Jacek Anaszewski wrote:
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Thanks for adding indicator support!
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
I missed one thing - sysfs interface of the indicator LED class
also has to be disabled/enabled of v4l2_flash_open/close.
Good catch.
I am planning to reimplement the functions as follows,
please let me know if you see any issues here:
static int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind;
int ret = 0;
I think you could spare some newlines above (and below as well).
There must have been some issue on thunderbird side,
originally there were no newlines above.
Ok. I've used Seamonkey, I believe it uses the same editor. Some bugs were
unintroduced a few years ago, and since that I've mostly used a different
editor (and MUA) when replying to patches.
mutex_lock(led_cdev-led_access);
if (!v4l2_fh_is_singular(fh-vfh))
goto unlock;
led_sysfs_disable(led_cdev);
led_trigger_remove(led_cdev);
if (iled_cdev) {
led_cdev_ind = iled_cdev-led_cdev;
You can also declare led_cdev_ind here as you don't need it outside the
basic block.
With new approach it will be required also in error path.
True.
mutex_lock(led_cdev_ind-led_access);
led_sysfs_disable(led_cdev_ind);
led_trigger_remove(led_cdev_ind);
mutex_unlock(led_cdev_ind-led_access);
Please don't acquire the indicator mutex while holding the flash mutex. I
don't think there's a need to do so, thus creating a dependency between the
two.Just remember to check for v4l2_fh_is_singular() in both cases.
I thought that the code would be simpler this way. Nevertheless I
produced a new version by following your advise.
}
ret = __sync_device_with_v4l2_controls(v4l2_flash);
If ret is 0 here, you end up disabling the sysfs interface while open()
fails (and v4l2_flash_close() will not be run). Shouldn't you handle that?
Good point.
Please find the new version of v4l2_flash{open|close} functions below:
static int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind = NULL;
int ret = 0;
mutex_lock(led_cdev-led_access);
if (!v4l2_fh_is_singular(fh-vfh)) {
Hmm. I just realised that this might be a bit broken ---
v4l2_fh_is_singular() should return the same value independently of where in
subdev's open() handler it is called.
But adding file handles to the list and checking how many there are of them
is not properly serialised, i.e. another process could change the list in
between. I'll try to submit a patch for that. No need to wait for that
though.
So please ignore my earlier request to check for v4l2_fh_is_singular() for
multiple times, it won't help. Once is enough, albeit more than that won't
hurt.
mutex_unlock(led_cdev-led_access);
return 0;
}
led_sysfs_disable(led_cdev);
led_trigger_remove(led_cdev);
mutex_unlock(led_cdev-led_access);
if (iled_cdev) {
led_cdev_ind = iled_cdev-led_cdev;
mutex_lock(led_cdev_ind-led_access);
if (!v4l2_fh_is_singular(fh-vfh)) {
mutex_unlock(led_cdev_ind-led_access);
return 0;
}
Re: [PATCH v2 2/2] sound/usb: Update ALSA driver to use media controller API
Em Wed, 03 Jun 2015 09:12:54 -0600
Shuah Khan shua...@osg.samsung.com escreveu:
Change ALSA driver to use media controller API to share tuner
with DVB and V4L2 drivers that control AU0828 media device.
Media device is created based on a newly added field value
in the struct snd_usb_audio_quirk. Using this approach, the
media controller API usage can be added for a specific device.
In this patch, media controller API is enabled for AU0828 hw.
snd_usb_create_quirk() will check this new field, if set will
create a media device using media_device_get_devres() interface.
media_device_get_devres() will allocate a new media device
devres or return an existing one, if it finds one.
During probe, media usb driver could have created the media
device devres. It will then register the media device if it
isn't already registered. Media device unregister is done
from usb_audio_disconnect().
New structure media_ctl is added to group the new fields
to support media entity and links. This new structure is
added to struct snd_usb_substream. A new media entity for
ALSA and a link from tuner entity to the newly registered
ALSA entity are created from snd_usb_init_substream() and
removed from free_substream(). The state is kept to indicate
if tuner is linked. This is to account for case when tuner
entity doesn't exist. Media pipeline gets started to mark
the tuner busy from snd_usb_substream_capture_trigger in
response to SNDRV_PCM_TRIGGER_START and pipeline is stopped
in response to SNDRV_PCM_TRIGGER_STOP. snd_usb_pcm_close()
stops pipeline to cover the case when SNDRV_PCM_TRIGGER_STOP
isn't issued. Pipeline start and stop are done only when
tuner_linked is set.
Tested with and without CONFIG_MEDIA_CONTROLLER enabled.
Tested tuner entity doesn't exist case as au0828 v4l2
driver is the one that will create the tuner when it gets
updated to use media controller API.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
sound/usb/Makefile | 3 +-
sound/usb/card.c | 5 ++
sound/usb/card.h | 1 +
sound/usb/media.c| 181
+++
sound/usb/media.h| 40 +++
sound/usb/pcm.c | 10 ++-
sound/usb/quirks-table.h | 1 +
sound/usb/quirks.c | 9 ++-
sound/usb/stream.c | 3 +
sound/usb/usbaudio.h | 1 +
10 files changed, 251 insertions(+), 3 deletions(-)
create mode 100644 sound/usb/media.c
create mode 100644 sound/usb/media.h
diff --git a/sound/usb/Makefile b/sound/usb/Makefile
index 2d2d122..7fe4fdd 100644
--- a/sound/usb/Makefile
+++ b/sound/usb/Makefile
@@ -13,7 +13,8 @@ snd-usb-audio-objs := card.o \
pcm.o \
proc.o \
quirks.o \
- stream.o
+ stream.o \
+ media.o
snd-usbmidi-lib-objs := midi.o
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 1fab977..469d2bf 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -66,6 +66,7 @@
#include format.h
#include power.h
#include stream.h
+#include media.h
MODULE_AUTHOR(Takashi Iwai ti...@suse.de);
MODULE_DESCRIPTION(USB Audio);
@@ -619,6 +620,10 @@ static void usb_audio_disconnect(struct usb_interface
*intf)
list_for_each_entry(mixer, chip-mixer_list, list) {
snd_usb_mixer_disconnect(mixer);
}
+ /* Nice to check quirk quirk-media_device
+ * need some special handlings. Doesn't look like
+ * we have access to quirk here */
+ media_device_delete(intf);
}
chip-num_interfaces--;
diff --git a/sound/usb/card.h b/sound/usb/card.h
index ef580b4..235a85f 100644
--- a/sound/usb/card.h
+++ b/sound/usb/card.h
@@ -155,6 +155,7 @@ struct snd_usb_substream {
} dsd_dop;
bool trigger_tstamp_pending_update; /* trigger timestamp being updated
from initial estimate */
+ void *media_ctl;
};
struct snd_usb_stream {
diff --git a/sound/usb/media.c b/sound/usb/media.c
new file mode 100644
index 000..8e8a0b3
--- /dev/null
+++ b/sound/usb/media.c
@@ -0,0 +1,181 @@
+/*
+ * media.c - managed media token resource
+ *
+ * Copyright (c) 2015 Shuah Khan shua...@osg.samsung.com
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ *
+ * This file is released under the GPLv2.
+ */
+
+/*
+ * This file adds Media Controller support to ALSA driver
+ * to use the Media Controller API to share tuner with DVB
+ * and V4L2 drivers that control media device. Media device
+ * is created based on existing quirks framework. Using this
+ * approach, the media controller API usage can be added for
+ * a specific device.
+*/
+
+#ifdef CONFIG_MEDIA_CONTROLLER
+#if defined(CONFIG_MEDIA_SUPPORT) || \
+ (defined(CONFIG_MEDIA_SUPPORT_MODULE) defined(MODULE))
+#define USE_MEDIA_CONTROLLER
Re: Hauppauge WinTV-HVR2205 driver feedback
I have a working solution (workaround) for the HVR2205/HVR2215 firmware
loading issue.
In the file:
dvb-frontends/si2168.c
change:
#define SI2168_B40 ('B' 24 | 68 16 | '4' 8 | '0' 0)
to:
#define SI2168_B40 (68 16 | '4' 8 | '0' 0)
I do not know why this works, but this is the place where the new chip
is not being detected correctly.
In my case the chip is labelled as: SI2168 40
When the firmware failed to load the error log reported as: si2168-x0040
I hope this is helpful.
I have 2x HVR2215 cards both working for DVB-T on OpenSuse13.2
So the hardware is reporting as a 'D' revision, and a prior firmware
is being loaded and its working nicely. Looks like an easy fix to the
2168 driver.
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
Steven Toth stoth at kernellabs.com writes:
Many thanks to the developers for all of your hard work.
Let me guess they have changed Si2168 chip to latest C version. Driver
supports only A and B (A20, A30 and B40). I have never seen C version.
I'll look in detail and report back shortly.
Hi,
I have a working solution (workaround) for the HVR2205/HVR2215 firmware
loading issue.
In the file:
dvb-frontends/si2168.c
change:
#define SI2168_B40 ('B' 24 | 68 16 | '4' 8 | '0' 0)
to:
#define SI2168_B40 (68 16 | '4' 8 | '0' 0)
I do not know why this works, but this is the place where the new chip
is not being detected correctly.
In my case the chip is labelled as: SI2168 40
When the firmware failed to load the error log reported as: si2168-x0040
I hope this is helpful.
I have 2x HVR2215 cards both working for DVB-T on OpenSuse13.2
To get them working, I installed the latest HEAD kernel, downloaded the
media_build tree from LinuxTV, made the change as above, make, make
install, reboot
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Hauppauge WinTV-HVR2205 driver feedback
Hi, Just thought I'd clarify that in my case I haven't ever used this board with Windows. See a more detailed dmesg output below for saa7168 and si21xx messages. From what I am seeing the firmware is loading correctly. However I may be wrong. dmesg | grep 'saa7164\|si21' [ 18.112439] saa7164 driver loaded [ 18.113429] CORE saa7164[0]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 [card=13,autodetected] [ 18.113435] saa7164[0]/0: found at :03:00.0, rev: 129, irq: 16, latency: 0, mmio: 0xf780 [ 18.113470] saa7164 :03:00.0: irq 46 for MSI/MSI-X [ 18.270310] saa7164_downloadfirmware() no first image [ 18.270322] saa7164_downloadfirmware() Waiting for firmware upload (NXP7164-2010-03-10.1.fw) [ 20.240635] saa7164_downloadfirmware() firmware read 4019072 bytes. [ 20.240637] saa7164_downloadfirmware() firmware loaded. [ 20.240642] saa7164_downloadfirmware() SecBootLoader.FileSize = 4019072 [ 20.240648] saa7164_downloadfirmware() FirmwareSize = 0x1fd6 [ 20.240649] saa7164_downloadfirmware() BSLSize = 0x0 [ 20.240650] saa7164_downloadfirmware() Reserved = 0x0 [ 20.240650] saa7164_downloadfirmware() Version = 0x1661c00 [ 27.096269] saa7164_downloadimage() Image downloaded, booting... [ 27.200300] saa7164_downloadimage() Image booted successfully. [ 29.936962] saa7164_downloadimage() Image downloaded, booting... [ 31.705407] saa7164_downloadimage() Image booted successfully. [ 31.750358] saa7164[0]: Hauppauge eeprom: model=151609 [ 31.776446] si2168 22-0064: Silicon Labs Si2168 successfully attached [ 31.781307] si2157 20-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 31.781695] DVB: registering new adapter (saa7164) [ 31.781698] saa7164 :03:00.0: DVB: registering adapter 4 frontend 0 (Silicon Labs Si2168)... [ 31.782652] si2168 22-0066: Silicon Labs Si2168 successfully attached [ 31.785961] si2157 21-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 31.786340] DVB: registering new adapter (saa7164) [ 31.786342] saa7164 :03:00.0: DVB: registering adapter 5 frontend 0 (Silicon Labs Si2168)... [ 31.786562] saa7164[0]: registered device video1 [mpeg] [ 32.021659] saa7164[0]: registered device video2 [mpeg] [ 32.238336] saa7164[0]: registered device vbi0 [vbi] [ 32.238389] saa7164[0]: registered device vbi1 [vbi] [165512.436662] si2168 22-0066: unknown chip version Si2168- [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30' [165512.480559] si2157 21-0060: firmware version: 3.0.5 [165517.981155] si2168 22-0064: unknown chip version Si2168- [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30' [165518.024867] si2157 20-0060: firmware version: 3.0.5 [165682.334171] si2168 22-0064: unknown chip version Si2168- [165730.579085] si2168 22-0064: unknown chip version Si2168- [165838.420693] si2168 22-0064: unknown chip version Si2168- [166337.342437] si2168 22-0064: unknown chip version Si2168- [167305.393572] si2168 22-0064: unknown chip version Si2168- [170762.907071] si2168 22-0064: unknown chip version Si2168- -Original Message- From: Antti Palosaari [mailto:cr...@iki.fi] Sent: Wednesday, June 3, 2015 6:03 PM To: Stephen Allan; linux-media@vger.kernel.org Subject: Re: Hauppauge WinTV-HVR2205 driver feedback On 06/03/2015 10:55 AM, Antti Palosaari wrote: On 06/03/2015 06:55 AM, Stephen Allan wrote: I am aware that there is some development going on for the saa7164 driver to support the Hauppauge WinTV-HVR2205. I thought I would post some feedback. I have recently compiled the driver as at 2015-05-31 using media build tree. I am unable to tune a channel. When running the following w_scan command: w_scan -a4 -ft -cAU -t 3 -X /tmp/tzap/channels.conf I get the following error after scanning the frequency range for Australia. ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! At the same time I get the following messages being logged to the Linux console. dmesg [165512.436662] si2168 22-0066: unknown chip version Si2168- [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30' [165512.480559] si2157 21-0060: firmware version: 3.0.5 [165517.981155] si2168 22-0064: unknown chip version Si2168- [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30' [165518.024867] si2157 20-0060: firmware version: 3.0.5 [165682.334171] si2168 22-0064: unknown chip version Si2168- [165730.579085] si2168 22-0064: unknown chip version Si2168- [165838.420693] si2168 22-0064: unknown chip version Si2168- [166337.342437] si2168 22-0064: unknown chip version Si2168- [167305.393572] si2168 22-0064: unknown chip version Si2168- Many thanks to the developers for all of your hard work. Let me guess they have changed Si2168 chip to latest C version. Driver supports only A and B (A20, A30 and B40). I have never seen C version. gah, looking the driver I think that is not issue - it will
[PATCH] ts2020: Copy loop_through from the config to the internal data
Copy the loop_through setting from the ts2020_config struct to the internal
ts2020_priv struct so that it can actually be used.
Whilst we're at it, group the bitfields together in the same order in both
structs so that the compiler has a good chance to copy them in one go.
Signed-off-by: David Howells dhowe...@redhat.com
---
drivers/media/dvb-frontends/ts2020.c |3 ++-
drivers/media/dvb-frontends/ts2020.h |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/ts2020.c
b/drivers/media/dvb-frontends/ts2020.c
index 80ae039..8c997d0 100644
--- a/drivers/media/dvb-frontends/ts2020.c
+++ b/drivers/media/dvb-frontends/ts2020.c
@@ -37,6 +37,7 @@ struct ts2020_priv {
/* i2c details */
struct i2c_adapter *i2c;
int i2c_address;
+ bool loop_through:1;
u8 clk_out:2;
u8 clk_out_div:5;
u32 frequency_div; /* LO output divider switch frequency */
@@ -44,7 +45,6 @@ struct ts2020_priv {
#define TS2020_M88TS2020 0
#define TS2020_M88TS2022 1
u8 tuner;
- u8 loop_through:1;
};
struct ts2020_reg_val {
@@ -582,6 +582,7 @@ static int ts2020_probe(struct i2c_client *client,
dev-i2c = client-adapter;
dev-i2c_address = client-addr;
+ dev-loop_through = pdata-loop_through;
dev-clk_out = pdata-clk_out;
dev-clk_out_div = pdata-clk_out_div;
dev-frequency_div = pdata-frequency_div;
diff --git a/drivers/media/dvb-frontends/ts2020.h
b/drivers/media/dvb-frontends/ts2020.h
index 3779724..002bc0a 100644
--- a/drivers/media/dvb-frontends/ts2020.h
+++ b/drivers/media/dvb-frontends/ts2020.h
@@ -32,7 +32,7 @@ struct ts2020_config {
/*
* RF loop-through
*/
- u8 loop_through:1;
+ bool loop_through:1;
/*
* clock output
--
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] ts2020: Provide DVBv5 API signal strength
Malcolm Priestley tvbox...@gmail.com wrote: Yes, also, the workqueue appears not to be initialized when using the dvb attached method. I'm not sure what you're referring to. It's initialised in ts2020_probe() just after the ts2020_priv struct is allocated - the only place it is allocated. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
On 06/03/2015 06:55 AM, Stephen Allan wrote: I am aware that there is some development going on for the saa7164 driver to support the Hauppauge WinTV-HVR2205. I thought I would post some feedback. I have recently compiled the driver as at 2015-05-31 using media build tree. I am unable to tune a channel. When running the following w_scan command: w_scan -a4 -ft -cAU -t 3 -X /tmp/tzap/channels.conf I get the following error after scanning the frequency range for Australia. ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! At the same time I get the following messages being logged to the Linux console. dmesg [165512.436662] si2168 22-0066: unknown chip version Si2168- [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30' [165512.480559] si2157 21-0060: firmware version: 3.0.5 [165517.981155] si2168 22-0064: unknown chip version Si2168- [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30' [165518.024867] si2157 20-0060: firmware version: 3.0.5 [165682.334171] si2168 22-0064: unknown chip version Si2168- [165730.579085] si2168 22-0064: unknown chip version Si2168- [165838.420693] si2168 22-0064: unknown chip version Si2168- [166337.342437] si2168 22-0064: unknown chip version Si2168- [167305.393572] si2168 22-0064: unknown chip version Si2168- Many thanks to the developers for all of your hard work. Let me guess they have changed Si2168 chip to latest C version. Driver supports only A and B (A20, A30 and B40). I have never seen C version. regards Antti -- http://palosaari.fi/ -- 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] ts2020: Provide DVBv5 API signal strength
On 05/28/2015 11:07 PM, Malcolm Priestley wrote: On 28/05/15 11:08, David Howells wrote: Malcolm Priestley tvbox...@gmail.com wrote: Statistics polling can not be done by lmedm04 driver's implementation of M88RS2000/TS2020 because I2C messages stop the devices demuxer. I did make tests (using that same lme2510 + rs2000 device) and didn't saw the issue TS was lost. Could test and and tell me how to reproduce it? Signal strength returned was quite boring though, about same value all the time, but it is different issue... So any polling must be a config option for this driver. Ummm... I presume a runtime config option is okay. Yes, also, the workqueue appears not to be initialized when using the dvb attached method. Also, does that mean that the lmedm04 driver can't be made compatible with the DVBv5 API? No, the driver will have to implement its own version. It doesn't need a polling thread it simply gets it directly from its interrupt urb buffer. I assume lme2510 firmware will read signal strength from rs2000 and it is returned then directly by USB interface. regards Antti -- http://palosaari.fi/ -- 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] ts2020: Allow stats polling to be suppressed
Statistics polling can not be done by lmedm04 driver's implementation of
M88RS2000/TS2020 because I2C messages stop the device's demuxer, so allow
polling for statistics to be suppressed in the ts2020 driver by setting
dont_poll in the ts2020_config struct.
Reported-by: Malcolm Priestley tvbox...@gmail.com
Signed-off-by: David Howells dhowe...@redhat.com
cc: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb-frontends/ts2020.c | 18 ++
drivers/media/dvb-frontends/ts2020.h |3 +++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-frontends/ts2020.c
b/drivers/media/dvb-frontends/ts2020.c
index 8c997d0..946d8e950 100644
--- a/drivers/media/dvb-frontends/ts2020.c
+++ b/drivers/media/dvb-frontends/ts2020.c
@@ -40,6 +40,7 @@ struct ts2020_priv {
bool loop_through:1;
u8 clk_out:2;
u8 clk_out_div:5;
+ bool dont_poll:1;
u32 frequency_div; /* LO output divider switch frequency */
u32 frequency_khz; /* actual used LO frequency */
#define TS2020_M88TS2020 0
@@ -52,6 +53,8 @@ struct ts2020_reg_val {
u8 val;
};
+static void ts2020_stat_work(struct work_struct *work);
+
static int ts2020_release(struct dvb_frontend *fe)
{
struct ts2020_priv *priv = fe-tuner_priv;
@@ -79,7 +82,8 @@ static int ts2020_sleep(struct dvb_frontend *fe)
return ret;
/* stop statistics polling */
- cancel_delayed_work_sync(priv-stat_work);
+ if (!priv-dont_poll)
+ cancel_delayed_work_sync(priv-stat_work);
return 0;
}
@@ -152,8 +156,8 @@ static int ts2020_init(struct dvb_frontend *fe)
c-strength.stat[0].scale = FE_SCALE_DECIBEL;
c-strength.stat[0].uvalue = 0;
- /* Start statistics polling */
- schedule_delayed_work(priv-stat_work, 0);
+ /* Start statistics polling by invoking the work function */
+ ts2020_stat_work(priv-stat_work.work);
return 0;
}
@@ -445,7 +449,8 @@ static void ts2020_stat_work(struct work_struct *work)
c-strength.stat[0].scale = FE_SCALE_DECIBEL;
- schedule_delayed_work(priv-stat_work, msecs_to_jiffies(2000));
+ if (!priv-dont_poll)
+ schedule_delayed_work(priv-stat_work, msecs_to_jiffies(2000));
return;
err:
dev_dbg(client-dev, failed=%d\n, ret);
@@ -458,9 +463,13 @@ static int ts2020_read_signal_strength(struct dvb_frontend
*fe,
u16 *_signal_strength)
{
struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ struct ts2020_priv *priv = fe-tuner_priv;
unsigned strength;
__s64 gain;
+ if (priv-dont_poll)
+ ts2020_stat_work(priv-stat_work.work);
+
if (c-strength.stat[0].scale == FE_SCALE_NOT_AVAILABLE) {
*_signal_strength = 0;
return 0;
@@ -585,6 +594,7 @@ static int ts2020_probe(struct i2c_client *client,
dev-loop_through = pdata-loop_through;
dev-clk_out = pdata-clk_out;
dev-clk_out_div = pdata-clk_out_div;
+ dev-dont_poll = pdata-dont_poll;
dev-frequency_div = pdata-frequency_div;
dev-fe = fe;
dev-get_agc_pwm = pdata-get_agc_pwm;
diff --git a/drivers/media/dvb-frontends/ts2020.h
b/drivers/media/dvb-frontends/ts2020.h
index 002bc0a..9220e5c 100644
--- a/drivers/media/dvb-frontends/ts2020.h
+++ b/drivers/media/dvb-frontends/ts2020.h
@@ -48,6 +48,9 @@ struct ts2020_config {
*/
u8 clk_out_div:5;
+ /* Set to true to suppress stat polling */
+ bool dont_poll:1;
+
/*
* pointer to DVB frontend
*/
--
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 v9 2/8] media: Add registration helpers for V4L2 flash sub-devices
Hi Sakari,
On 06/02/2015 05:32 PM, Sakari Ailus wrote:
Hi, Jacek!
On Tue, Jun 02, 2015 at 11:13:54AM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On 06/01/2015 10:59 PM, Sakari Ailus wrote:
Hi Jacek,
On Mon, May 25, 2015 at 05:13:57PM +0200, Jacek Anaszewski wrote:
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Thanks for adding indicator support!
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
I missed one thing - sysfs interface of the indicator LED class
also has to be disabled/enabled of v4l2_flash_open/close.
Good catch.
I am planning to reimplement the functions as follows,
please let me know if you see any issues here:
static int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind;
int ret = 0;
I think you could spare some newlines above (and below as well).
There must have been some issue on thunderbird side,
originally there were no newlines above.
mutex_lock(led_cdev-led_access);
if (!v4l2_fh_is_singular(fh-vfh))
goto unlock;
led_sysfs_disable(led_cdev);
led_trigger_remove(led_cdev);
if (iled_cdev) {
led_cdev_ind = iled_cdev-led_cdev;
You can also declare led_cdev_ind here as you don't need it outside the
basic block.
With new approach it will be required also in error path.
mutex_lock(led_cdev_ind-led_access);
led_sysfs_disable(led_cdev_ind);
led_trigger_remove(led_cdev_ind);
mutex_unlock(led_cdev_ind-led_access);
Please don't acquire the indicator mutex while holding the flash mutex. I
don't think there's a need to do so, thus creating a dependency between the
two.Just remember to check for v4l2_fh_is_singular() in both cases.
I thought that the code would be simpler this way. Nevertheless I
produced a new version by following your advise.
}
ret = __sync_device_with_v4l2_controls(v4l2_flash);
If ret is 0 here, you end up disabling the sysfs interface while open()
fails (and v4l2_flash_close() will not be run). Shouldn't you handle that?
Good point.
Please find the new version of v4l2_flash{open|close} functions below:
static int v4l2_flash_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
struct led_classdev *led_cdev = fled_cdev-led_cdev;
struct led_classdev_flash *iled_cdev = v4l2_flash-iled_cdev;
struct led_classdev *led_cdev_ind = NULL;
int ret = 0;
mutex_lock(led_cdev-led_access);
if (!v4l2_fh_is_singular(fh-vfh)) {
mutex_unlock(led_cdev-led_access);
return 0;
}
led_sysfs_disable(led_cdev);
led_trigger_remove(led_cdev);
mutex_unlock(led_cdev-led_access);
if (iled_cdev) {
led_cdev_ind = iled_cdev-led_cdev;
mutex_lock(led_cdev_ind-led_access);
if (!v4l2_fh_is_singular(fh-vfh)) {
mutex_unlock(led_cdev_ind-led_access);
return 0;
}
led_sysfs_disable(led_cdev_ind);
led_trigger_remove(led_cdev_ind);
mutex_unlock(led_cdev_ind-led_access);
}
ret = __sync_device_with_v4l2_controls(v4l2_flash);
if (ret 0)
goto out_sync_device;
return 0;
out_sync_device:
mutex_lock(led_cdev-led_access);
if (v4l2_fh_is_singular(fh-vfh))
led_sysfs_enable(led_cdev);
mutex_unlock(led_cdev-led_access);
if (led_cdev_ind) {
mutex_lock(led_cdev_ind-led_access);
if (v4l2_fh_is_singular(fh-vfh))
led_sysfs_enable(led_cdev_ind);
mutex_unlock(led_cdev_ind-led_access);
}
return ret;
}
static int v4l2_flash_close(struct v4l2_subdev *sd, struct
v4l2_subdev_fh *fh)
{
struct v4l2_flash *v4l2_flash = v4l2_subdev_to_v4l2_flash(sd);
struct led_classdev_flash *fled_cdev = v4l2_flash-fled_cdev;
Re: Hauppauge WinTV-HVR2205 driver feedback
On 06/03/2015 10:55 AM, Antti Palosaari wrote: On 06/03/2015 06:55 AM, Stephen Allan wrote: I am aware that there is some development going on for the saa7164 driver to support the Hauppauge WinTV-HVR2205. I thought I would post some feedback. I have recently compiled the driver as at 2015-05-31 using media build tree. I am unable to tune a channel. When running the following w_scan command: w_scan -a4 -ft -cAU -t 3 -X /tmp/tzap/channels.conf I get the following error after scanning the frequency range for Australia. ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! At the same time I get the following messages being logged to the Linux console. dmesg [165512.436662] si2168 22-0066: unknown chip version Si2168- [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30' [165512.480559] si2157 21-0060: firmware version: 3.0.5 [165517.981155] si2168 22-0064: unknown chip version Si2168- [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30' [165518.024867] si2157 20-0060: firmware version: 3.0.5 [165682.334171] si2168 22-0064: unknown chip version Si2168- [165730.579085] si2168 22-0064: unknown chip version Si2168- [165838.420693] si2168 22-0064: unknown chip version Si2168- [166337.342437] si2168 22-0064: unknown chip version Si2168- [167305.393572] si2168 22-0064: unknown chip version Si2168- Many thanks to the developers for all of your hard work. Let me guess they have changed Si2168 chip to latest C version. Driver supports only A and B (A20, A30 and B40). I have never seen C version. gah, looking the driver I think that is not issue - it will likely print unknown chip version Si2168-C.. on that case already. However, I remember I have seen that kind of issue earlier too, but don't remember what was actual reason. Probably something to do with firmware, wrong firmware and loading has failed? Could you make cold boot, remove socket from the wallet and wait minute it really powers down, then boot and look what happens. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On Wed, Jun 03, 2015 at 08:39:55AM +0200, Hans Verkuil wrote:
Hi Sumit,
On 05/05/2015 04:41 PM, Sumit Semwal wrote:
Hi Russell, everyone,
First up, sincere apologies for being awol for sometime; had some
personal / medical things to take care of, and then I thought I'd wait
for the merge window to get over before beginning to discuss this
again.
On 11 February 2015 at 21:53, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote:
Hello,
On 2015-02-11 12:12, Russell King - ARM Linux wrote:
Which is a damn good reason to NAK it - by that admission, it's a
half-baked
idea.
If all we want to know is whether the importer can accept only contiguous
memory or not, make a flag to do that, and allow the exporter to test
this
flag. Don't over-engineer this to make it _seem_ like it can do
something
that it actually totally fails with.
As I've already pointed out, there's a major problem if you have already
had a less restrictive attachment which has an active mapping, and a new
more restrictive attachment comes along later.
It seems from Rob's descriptions that we also need another flag in the
importer to indicate whether it wants to have a valid struct page in the
scatter list, or whether it (correctly) uses the DMA accessors on the
scatter list - so that exporters can reject importers which are buggy.
Okay, but flag-based approach also have limitations.
Yes, the flag-based approach doesn't let you describe in detail what
the importer can accept - which, given the issues that I've raised
is a *good* thing. We won't be misleading anyone into thinking that
we can do something that's really half-baked, and which we have no
present requirement for.
This is precisely what Linus talks about when he says don't over-
engineer - if we over-engineer this, we end up with something that
sort-of works, and that's a bad thing.
The Keep It Simple approach here makes total sense - what are our
current requirements - to be able to say that an importer can only accept:
- contiguous memory rather than a scatterlist
- scatterlists with struct page pointers
Does solving that need us to compare all the constraints of each and
every importer, possibly ending up with constraints which can't be
satisfied? No. Does the flag approach satisfy the requirements? Yes.
So, for basic constraint-sharing, we'll just go with the flag based
approach, with a flag (best place for it is still dev-dma_params I
suppose) for denoting contiguous or scatterlist. Is that agreed, then?
Also, with this idea, of course, there won't be any helpers for trying
to calculate constraints; it would be totally the exporter's
responsibility to handle it via the attach() dma_buf_op if it wishes
to.
What's wrong with the proposed max_segment_count? Many media devices do
have a limited max_segment_count and that should be taken into account.
So what happens if you have a dma_buf exporter, and several dma_buf
importers. One dma_buf importer attaches to the exporter, and asks
for the buffer, and starts making use of the buffer. This export has
many scatterlist segments.
Another dma_buf importer attaches to the same buffer, and now asks for
the buffer, but the number of scatterlist segments exceeds it's
requirement.
You can't reallocate the buffer because it's in-use by another importer.
There is no way to revoke the buffer from the other importer. So there
is no way to satisfy this importer's requirements.
What I'm showing is that the idea that exporting these parameters fixes
some problem is just an illusion - it may work for the single importer
case, but doesn't for the multiple importer case.
Importers really have two choices here: either they accept what the
exporter is giving them, or they reject it.
The other issue here is that DMA scatterlists are _not_ really that
determinable in terms of number of entries when it comes to systems with
system IOMMUs. System IOMMUs, which should be integrated into the DMA
API, are permitted to coalesce entries in the physical page range. For
example:
nsg = 128;
n = dma_map_sg(dev, sg, nsg, DMA_TO_DEVICE);
Here, n might be 4 if the system IOMMU has been able to coalesce the 128
entries down to 4 IOMMU entries - and that means for DMA purposes, only
the first four scatterlist entries should be walked (this is why
dma_map_sg() returns a positive integer when mapping.)
Each struct device has a set of parameters which control how the IOMMU
entries are coalesced:
struct device_dma_parameters {
/*
* a low level driver may set these to teach IOMMU code about
* sg limitations.
*/
unsigned int max_segment_size;
unsigned long segment_boundary_mask;
};
and this is independent of the dma_buf API. This doesn't indicate the
maximum number of segments, but as
Re: [PATCH 2/9] mm: Provide new get_vaddr_frames() helper
On Tue 02-06-15 15:29:12, Andrew Morton wrote: On Tue, 2 Jun 2015 17:23:00 +0200 Jan Kara j...@suse.cz wrote: That's a lump of new code which many kernels won't be needing. Can we put all this in a new .c file and select it within drivers/media Kconfig? So the attached patch should do what you had in mind. OK? lgtm. drivers/gpu/drm/exynos/Kconfig | 1 + drivers/media/platform/omap/Kconfig | 1 + drivers/media/v4l2-core/Kconfig | 1 + mm/Kconfig | 3 + mm/Makefile | 1 + mm/frame-vec.c | 233 But frame_vector.c would be a more pleasing name. For `struct frame_vector'. OK, makes sense. Updated patch attached. Honza -- Jan Kara j...@suse.cz SUSE Labs, CR From a129ecf637e75421d823d54eab885cd36e54c6ec Mon Sep 17 00:00:00 2001 From: Jan Kara j...@suse.cz Date: Tue, 2 Jun 2015 16:40:32 +0200 Subject: [PATCH] mm: Move get_vaddr_frames() behind a config option get_vaddr_frames() is used by relatively rare drivers so hide it and the related functions behind a config option that is selected only by drivers that need the infrastructure. Suggested-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Jan Kara j...@suse.cz --- drivers/gpu/drm/exynos/Kconfig | 1 + drivers/media/platform/omap/Kconfig | 1 + drivers/media/v4l2-core/Kconfig | 1 + mm/Kconfig | 3 + mm/Makefile | 1 + mm/frame_vector.c | 233 mm/gup.c| 225 -- 7 files changed, 240 insertions(+), 225 deletions(-) create mode 100644 mm/frame_vector.c diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 0a6780367d28..fc678289cf79 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -71,6 +71,7 @@ config DRM_EXYNOS_VIDI config DRM_EXYNOS_G2D bool Exynos DRM G2D depends on DRM_EXYNOS !VIDEO_SAMSUNG_S5P_G2D + select FRAME_VECTOR help Choose this option if you want to use Exynos G2D for DRM. diff --git a/drivers/media/platform/omap/Kconfig b/drivers/media/platform/omap/Kconfig index dc2aaab54aef..217d613b0fe7 100644 --- a/drivers/media/platform/omap/Kconfig +++ b/drivers/media/platform/omap/Kconfig @@ -10,6 +10,7 @@ config VIDEO_OMAP2_VOUT select OMAP2_DSS if HAS_IOMEM ARCH_OMAP2PLUS select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3 select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT OMAP2_VRFB + select FRAME_VECTOR default n ---help--- V4L2 Display driver support for OMAP2/3 based boards. diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig index ba7e21a73023..0cb22add650b 100644 --- a/drivers/media/v4l2-core/Kconfig +++ b/drivers/media/v4l2-core/Kconfig @@ -73,6 +73,7 @@ config VIDEOBUF2_CORE config VIDEOBUF2_MEMOPS tristate + select FRAME_VECTOR config VIDEOBUF2_DMA_CONTIG tristate diff --git a/mm/Kconfig b/mm/Kconfig index 390214da4546..2ca52e9986f0 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -635,3 +635,6 @@ config MAX_STACK_SIZE_MB changed to a smaller value in which case that is used. A sane initial value is 80 MB. + +config FRAME_VECTOR + bool diff --git a/mm/Makefile b/mm/Makefile index 98c4eaeabdcb..be5d5c866305 100644 --- a/mm/Makefile +++ b/mm/Makefile @@ -78,3 +78,4 @@ obj-$(CONFIG_CMA) += cma.o obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o +obj-$(CONFIG_FRAME_VECTOR) += frame_vector.o diff --git a/mm/frame_vector.c b/mm/frame_vector.c new file mode 100644 index ..5d85bcd150ae --- /dev/null +++ b/mm/frame_vector.c @@ -0,0 +1,233 @@ +#include linux/kernel.h +#include linux/errno.h +#include linux/err.h +#include linux/mm.h +#include linux/slab.h +#include linux/pagemap.h +#include linux/sched.h + +/* + * get_vaddr_frames() - map virtual addresses to pfns + * @start: starting user address + * @nr_frames: number of pages / pfns from start to map + * @write: whether pages will be written to by the caller + * @force: whether to force write access even if user mapping is + * readonly. See description of the same argument of + get_user_pages(). + * @vec: structure which receives pages / pfns of the addresses mapped. + * It should have space for at least nr_frames entries. + * + * This function maps virtual addresses from @start and fills @vec structure + * with page frame numbers or page pointers to corresponding pages (choice + * depends on the type of the vma underlying the virtual address). If @start + * belongs to a normal vma, the function grabs reference to each of the pages + * to pin them in memory. If @start belongs to VM_IO | VM_PFNMAP vma, we don't + * touch page structures and the caller
Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On 06/03/15 10:41, Russell King - ARM Linux wrote:
On Wed, Jun 03, 2015 at 08:39:55AM +0200, Hans Verkuil wrote:
Hi Sumit,
On 05/05/2015 04:41 PM, Sumit Semwal wrote:
Hi Russell, everyone,
First up, sincere apologies for being awol for sometime; had some
personal / medical things to take care of, and then I thought I'd wait
for the merge window to get over before beginning to discuss this
again.
On 11 February 2015 at 21:53, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote:
Hello,
On 2015-02-11 12:12, Russell King - ARM Linux wrote:
Which is a damn good reason to NAK it - by that admission, it's a
half-baked
idea.
If all we want to know is whether the importer can accept only contiguous
memory or not, make a flag to do that, and allow the exporter to test
this
flag. Don't over-engineer this to make it _seem_ like it can do
something
that it actually totally fails with.
As I've already pointed out, there's a major problem if you have already
had a less restrictive attachment which has an active mapping, and a new
more restrictive attachment comes along later.
It seems from Rob's descriptions that we also need another flag in the
importer to indicate whether it wants to have a valid struct page in the
scatter list, or whether it (correctly) uses the DMA accessors on the
scatter list - so that exporters can reject importers which are buggy.
Okay, but flag-based approach also have limitations.
Yes, the flag-based approach doesn't let you describe in detail what
the importer can accept - which, given the issues that I've raised
is a *good* thing. We won't be misleading anyone into thinking that
we can do something that's really half-baked, and which we have no
present requirement for.
This is precisely what Linus talks about when he says don't over-
engineer - if we over-engineer this, we end up with something that
sort-of works, and that's a bad thing.
The Keep It Simple approach here makes total sense - what are our
current requirements - to be able to say that an importer can only accept:
- contiguous memory rather than a scatterlist
- scatterlists with struct page pointers
Does solving that need us to compare all the constraints of each and
every importer, possibly ending up with constraints which can't be
satisfied? No. Does the flag approach satisfy the requirements? Yes.
So, for basic constraint-sharing, we'll just go with the flag based
approach, with a flag (best place for it is still dev-dma_params I
suppose) for denoting contiguous or scatterlist. Is that agreed, then?
Also, with this idea, of course, there won't be any helpers for trying
to calculate constraints; it would be totally the exporter's
responsibility to handle it via the attach() dma_buf_op if it wishes
to.
What's wrong with the proposed max_segment_count? Many media devices do
have a limited max_segment_count and that should be taken into account.
So what happens if you have a dma_buf exporter, and several dma_buf
importers. One dma_buf importer attaches to the exporter, and asks
for the buffer, and starts making use of the buffer. This export has
many scatterlist segments.
Another dma_buf importer attaches to the same buffer, and now asks for
the buffer, but the number of scatterlist segments exceeds it's
requirement.
You can't reallocate the buffer because it's in-use by another importer.
There is no way to revoke the buffer from the other importer. So there
is no way to satisfy this importer's requirements.
What I'm showing is that the idea that exporting these parameters fixes
some problem is just an illusion - it may work for the single importer
case, but doesn't for the multiple importer case.
Importers really have two choices here: either they accept what the
exporter is giving them, or they reject it.
I agree completely with that.
The other issue here is that DMA scatterlists are _not_ really that
determinable in terms of number of entries when it comes to systems with
system IOMMUs. System IOMMUs, which should be integrated into the DMA
API, are permitted to coalesce entries in the physical page range. For
example:
nsg = 128;
n = dma_map_sg(dev, sg, nsg, DMA_TO_DEVICE);
Here, n might be 4 if the system IOMMU has been able to coalesce the 128
entries down to 4 IOMMU entries - and that means for DMA purposes, only
the first four scatterlist entries should be walked (this is why
dma_map_sg() returns a positive integer when mapping.)
Each struct device has a set of parameters which control how the IOMMU
entries are coalesced:
struct device_dma_parameters {
/*
* a low level driver may set these to teach IOMMU code about
* sg limitations.
*/
unsigned int max_segment_size;
unsigned long segment_boundary_mask;
};
and this is independent of the dma_buf API.
Re: Hauppauge WinTV-HVR2205 driver feedback
I'm seeing the same issue as well. I thought that maybe some recent Si2168 changes did impact this, but it does not seem to be the case. I made a quick test myself. I reverted the latest si2168 patches one by one, but that did not remedy the situation. Anyway, the kernel log does not seem to indicate that the si2168_cmd_execute itself would fail (which is what happens after the I2C error handling patch in case the demod sets the error bit). olli@dl160:~/src/media_tree/drivers/media/dvb-frontends$ git log --oneline si2168.c d4b3830 Revert [media] si2168: add support for gapped clock eb62eb1 Revert [media] si2168: add I2C error handling 7adf99d [media] si2168: add I2C error handling 8117a31 [media] si2168: add support for gapped clock 17d4d6a [media] si2168: add support for 1.7MHz bandwidth 683e98b [media] si2168: return error if set_frontend is called with invalid para c32b281 [media] si2168: change firmware variable name and type 9b7839c [media] si2168: print chip version dmesg lines when it fails (this is with a card that has worked before): [1.336898] saa7164[0]: registered device video0 [mpeg] [1.567295] saa7164[0]: registered device video1 [mpeg] [1.778660] saa7164[0]: registered device vbi0 [vbi] [1.778817] saa7164[0]: registered device vbi1 [vbi] [66675.175508] si2168:si2168_init: si2168 2-0064: [66675.187299] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 6 ms [66675.194105] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 2 ms [OLLI: The result of this I2C cmd must be bogus] [66675.194110] si2168 2-0064: unknown chip version Si2168- [66675.200244] si2168:si2168_init: si2168 2-0064: failed=-22 [66675.213020] si2157 0-0060: found a 'Silicon Labs Si2157-A30' [66675.242856] si2157 0-0060: firmware version: 3.0.5 Cheers, -olli On 3 June 2015 at 10:02, Antti Palosaari cr...@iki.fi wrote: On 06/03/2015 10:55 AM, Antti Palosaari wrote: On 06/03/2015 06:55 AM, Stephen Allan wrote: I am aware that there is some development going on for the saa7164 driver to support the Hauppauge WinTV-HVR2205. I thought I would post some feedback. I have recently compiled the driver as at 2015-05-31 using media build tree. I am unable to tune a channel. When running the following w_scan command: w_scan -a4 -ft -cAU -t 3 -X /tmp/tzap/channels.conf I get the following error after scanning the frequency range for Australia. ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! At the same time I get the following messages being logged to the Linux console. dmesg [165512.436662] si2168 22-0066: unknown chip version Si2168- [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30' [165512.480559] si2157 21-0060: firmware version: 3.0.5 [165517.981155] si2168 22-0064: unknown chip version Si2168- [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30' [165518.024867] si2157 20-0060: firmware version: 3.0.5 [165682.334171] si2168 22-0064: unknown chip version Si2168- [165730.579085] si2168 22-0064: unknown chip version Si2168- [165838.420693] si2168 22-0064: unknown chip version Si2168- [166337.342437] si2168 22-0064: unknown chip version Si2168- [167305.393572] si2168 22-0064: unknown chip version Si2168- Many thanks to the developers for all of your hard work. Let me guess they have changed Si2168 chip to latest C version. Driver supports only A and B (A20, A30 and B40). I have never seen C version. gah, looking the driver I think that is not issue - it will likely print unknown chip version Si2168-C.. on that case already. However, I remember I have seen that kind of issue earlier too, but don't remember what was actual reason. Probably something to do with firmware, wrong firmware and loading has failed? Could you make cold boot, remove socket from the wallet and wait minute it really powers down, then boot and look what happens. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [RFCv3 1/2] device: add dma_params-max_segment_count
Hi Sumit, Rob,
Is there any reason why this patch hasn't been merged yet? It makes perfect
sense to me and I would really like to use this in the media drivers.
Many DMA engines do have a limit to the number of segments (obviously
a max count of 1 being the most common limitation, but other limits are
definitely possible), so this patch seems a no-brainer to me.
So:
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
On 01/27/2015 09:25 AM, Sumit Semwal wrote:
From: Rob Clark robdcl...@gmail.com
For devices which have constraints about maximum number of segments in
an sglist. For example, a device which could only deal with contiguous
buffers would set max_segment_count to 1.
The initial motivation is for devices sharing buffers via dma-buf,
to allow the buffer exporter to know the constraints of other
devices which have attached to the buffer. The dma_mask and fields
in 'struct device_dma_parameters' tell the exporter everything else
that is needed, except whether the importer has constraints about
maximum number of segments.
Signed-off-by: Rob Clark robdcl...@gmail.com
[sumits: Minor updates wrt comments]
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
v3: include Robin Murphy's fix[1] for handling '0' as a value for
max_segment_count
v2: minor updates wrt comments on the first version
[1]: http://article.gmane.org/gmane.linux.kernel.iommu/8175/
include/linux/device.h | 1 +
include/linux/dma-mapping.h | 19 +++
2 files changed, 20 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index fb506738f7b7..a32f9b67315c 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -647,6 +647,7 @@ struct device_dma_parameters {
* sg limitations.
*/
unsigned int max_segment_size;
+ unsigned int max_segment_count;/* INT_MAX for unlimited */
unsigned long segment_boundary_mask;
};
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c3007cb4bfa6..d3351a36d5ec 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct
device *dev,
return -EIO;
}
+#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
+
+static inline unsigned int dma_get_max_seg_count(struct device *dev)
+{
+ if (dev-dma_parms dev-dma_parms-max_segment_count)
+ return dev-dma_parms-max_segment_count;
+ return DMA_SEGMENTS_MAX_SEG_COUNT;
+}
+
+static inline int dma_set_max_seg_count(struct device *dev,
+ unsigned int count)
+{
+ if (dev-dma_parms) {
+ dev-dma_parms-max_segment_count = count;
+ return 0;
+ }
+ return -EIO;
+}
+
static inline unsigned long dma_get_seg_boundary(struct device *dev)
{
return dev-dma_parms ?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
Hi Sumit, On 05/05/2015 04:41 PM, Sumit Semwal wrote: Hi Russell, everyone, First up, sincere apologies for being awol for sometime; had some personal / medical things to take care of, and then I thought I'd wait for the merge window to get over before beginning to discuss this again. On 11 February 2015 at 21:53, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote: Hello, On 2015-02-11 12:12, Russell King - ARM Linux wrote: Which is a damn good reason to NAK it - by that admission, it's a half-baked idea. If all we want to know is whether the importer can accept only contiguous memory or not, make a flag to do that, and allow the exporter to test this flag. Don't over-engineer this to make it _seem_ like it can do something that it actually totally fails with. As I've already pointed out, there's a major problem if you have already had a less restrictive attachment which has an active mapping, and a new more restrictive attachment comes along later. It seems from Rob's descriptions that we also need another flag in the importer to indicate whether it wants to have a valid struct page in the scatter list, or whether it (correctly) uses the DMA accessors on the scatter list - so that exporters can reject importers which are buggy. Okay, but flag-based approach also have limitations. Yes, the flag-based approach doesn't let you describe in detail what the importer can accept - which, given the issues that I've raised is a *good* thing. We won't be misleading anyone into thinking that we can do something that's really half-baked, and which we have no present requirement for. This is precisely what Linus talks about when he says don't over- engineer - if we over-engineer this, we end up with something that sort-of works, and that's a bad thing. The Keep It Simple approach here makes total sense - what are our current requirements - to be able to say that an importer can only accept: - contiguous memory rather than a scatterlist - scatterlists with struct page pointers Does solving that need us to compare all the constraints of each and every importer, possibly ending up with constraints which can't be satisfied? No. Does the flag approach satisfy the requirements? Yes. So, for basic constraint-sharing, we'll just go with the flag based approach, with a flag (best place for it is still dev-dma_params I suppose) for denoting contiguous or scatterlist. Is that agreed, then? Also, with this idea, of course, there won't be any helpers for trying to calculate constraints; it would be totally the exporter's responsibility to handle it via the attach() dma_buf_op if it wishes to. What's wrong with the proposed max_segment_count? Many media devices do have a limited max_segment_count and that should be taken into account. Although to be fair I have to say that in practice the limited segment counts are all well above what is needed for a normal capture buffer, but it might be reached if you have video strides line width, so each line has its own segment (or two, if there is a page boundary in the middle of the line). It's a somewhat contrived use-case, though, although I have done this once myself. Anyway, the worst-case number of segments would be: height * ((bytesperline + PAGE_SIZE - 1) / PAGE_SIZE) That might well exceed the max segment count for some devices. I think I have also seen devices in the past that have a coarse-grained IOMMU that uses very large segment sizes, but have a very limited segment count. We don't have media drivers like that, and to be honest I am not sure whether we should bother too much with this corner case. Frankly, if we want to make it really portable and sharable between devices, then IMO we should get rid of struct scatterlist and replace it with simple array of pfns in dma_buf. This way at least the problem of missing struct page will be solved and the buffer representation will be also a bit more compact. ... and move the mapping and unmapping of the PFNs to the importer, which IMHO is where it should already be (so the importer can decide when it should map the buffer itself independently of getting the details of the buffer.) Such solution however also requires extending dma-mapping API to handle mapping and unmapping of such pfn arrays. The advantage of this approach is the fact that it will be completely new API, so it can be designed well from the beginning. As far as I'm aware, there was no big discussion of the dma_buf API - it's something that just appeared one day (I don't remember seeing it discussed.) So, that may well be a good thing if it means we can get these kinds of details better hammered out. However, I don't share your view of completely new API - that would be far too disruptive. I think we can modify the existing API, to achieve our goals. I don't think changing the dma-mapping API
[PATCH 1/2] media: s5p-mfc: add return value check in mfc_sys_init_cmd
alloc_dev_context_buffer method might fail, so add proper return value
check.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
index f176096..b1b1491 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
@@ -37,8 +37,12 @@ static int s5p_mfc_sys_init_cmd_v6(struct s5p_mfc_dev *dev)
{
struct s5p_mfc_cmd_args h2r_args;
struct s5p_mfc_buf_size_v6 *buf_size = dev-variant-buf_size-priv;
+ int ret;
+
+ ret = s5p_mfc_hw_call(dev-mfc_ops, alloc_dev_context_buffer, dev);
+ if (ret)
+ return ret;
- s5p_mfc_hw_call(dev-mfc_ops, alloc_dev_context_buffer, dev);
mfc_write(dev, dev-ctx_buf.dma, S5P_FIMV_CONTEXT_MEM_ADDR_V6);
mfc_write(dev, buf_size-dev_ctx, S5P_FIMV_CONTEXT_MEM_SIZE_V6);
return s5p_mfc_cmd_host2risc_v6(dev, S5P_FIMV_H2R_CMD_SYS_INIT_V6,
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] media: s5p-mfc: add additional check for incorrect memory configuration
MFC hardware is known to trash random memory if one tries to use a
buffer buffer, which has lower DMA addresses than the configured DMA
base address. This patch adds a check for this case and proper error
handling.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr.c| 11 +--
drivers/media/platform/s5p-mfc/s5p_mfc_opr.h| 2 +-
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 12 +++-
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 8 +---
4 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
index 00a1d8b..8d27f88 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
@@ -37,10 +37,9 @@ void s5p_mfc_init_regs(struct s5p_mfc_dev *dev)
dev-mfc_regs = s5p_mfc_init_regs_v6_plus(dev);
}
-int s5p_mfc_alloc_priv_buf(struct device *dev,
+int s5p_mfc_alloc_priv_buf(struct device *dev, dma_addr_t base,
struct s5p_mfc_priv_buf *b)
{
-
mfc_debug(3, Allocating priv: %zu\n, b-size);
b-virt = dma_alloc_coherent(dev, b-size, b-dma, GFP_KERNEL);
@@ -50,6 +49,14 @@ int s5p_mfc_alloc_priv_buf(struct device *dev,
return -ENOMEM;
}
+ if (b-dma base) {
+ mfc_err(Invaling memory configuration!\n);
+ mfc_err(Allocated buffer (%pad) is lower than memory base
addres (%pad)\n,
+ b-dma, base);
+ dma_free_coherent(dev, b-size, b-virt, b-dma);
+ return -ENOMEM;
+ }
+
mfc_debug(3, Allocated addr %p %pad\n, b-virt, b-dma);
return 0;
}
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
index 22dfb3e..77a08b1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
@@ -334,7 +334,7 @@ struct s5p_mfc_hw_ops {
void s5p_mfc_init_hw_ops(struct s5p_mfc_dev *dev);
void s5p_mfc_init_regs(struct s5p_mfc_dev *dev);
-int s5p_mfc_alloc_priv_buf(struct device *dev,
+int s5p_mfc_alloc_priv_buf(struct device *dev, dma_addr_t base,
struct s5p_mfc_priv_buf *b);
void s5p_mfc_release_priv_buf(struct device *dev,
struct s5p_mfc_priv_buf *b);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
index c7adc3d..b3f6700 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
@@ -41,7 +41,7 @@ static int s5p_mfc_alloc_dec_temp_buffers_v5(struct
s5p_mfc_ctx *ctx)
int ret;
ctx-dsc.size = buf_size-dsc;
- ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, ctx-dsc);
+ ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, dev-bank1, ctx-dsc);
if (ret) {
mfc_err(Failed to allocate temporary buffer\n);
return ret;
@@ -172,7 +172,8 @@ static int s5p_mfc_alloc_codec_buffers_v5(struct
s5p_mfc_ctx *ctx)
/* Allocate only if memory from bank 1 is necessary */
if (ctx-bank1.size 0) {
- ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, ctx-bank1);
+ ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, dev-bank1,
+ctx-bank1);
if (ret) {
mfc_err(Failed to allocate Bank1 temporary buffer\n);
return ret;
@@ -181,7 +182,8 @@ static int s5p_mfc_alloc_codec_buffers_v5(struct
s5p_mfc_ctx *ctx)
}
/* Allocate only if memory from bank 2 is necessary */
if (ctx-bank2.size 0) {
- ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_r, ctx-bank2);
+ ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_r, dev-bank2,
+ctx-bank2);
if (ret) {
mfc_err(Failed to allocate Bank2 temporary buffer\n);
s5p_mfc_release_priv_buf(ctx-dev-mem_dev_l,
ctx-bank1);
@@ -212,7 +214,7 @@ static int s5p_mfc_alloc_instance_buffer_v5(struct
s5p_mfc_ctx *ctx)
else
ctx-ctx.size = buf_size-non_h264_ctx;
- ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, ctx-ctx);
+ ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, dev-bank1, ctx-ctx);
if (ret) {
mfc_err(Failed to allocate instance buffer\n);
return ret;
@@ -225,7 +227,7 @@ static int s5p_mfc_alloc_instance_buffer_v5(struct
s5p_mfc_ctx *ctx)
/* Initialize shared memory */
ctx-shm.size = buf_size-shm;
- ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, ctx-shm);
+ ret = s5p_mfc_alloc_priv_buf(dev-mem_dev_l, dev-bank1, ctx-shm);
if (ret) {
mfc_err(Failed to allocate shared
Re: [PATCH] media: videobuf2-dc: set properly dma_max_segment_size
Hello,
On 2015-06-03 03:22, Laurent Pinchart wrote:
On Monday 01 June 2015 14:14:17 Marek Szyprowski wrote:
If device has no DMA max_seg_size set, we assume that there is no limit
and it is safe to force it to use DMA_BIT_MASK(32) as max_seg_size to
let DMA-mapping API always create contiguous mappings in DMA address
space. This is essential for all devices, which use dma-contig
videobuf2 memory allocator.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c index
644dec73d220..9d7c1814b0f3 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -862,6 +862,23 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
void *vb2_dma_contig_init_ctx(struct device *dev)
{
struct vb2_dc_conf *conf;
+ int err;
+
+ /*
+* if device has no max_seg_size set, we assume that there is no limit
+* and force it to DMA_BIT_MASK(32) to always use contiguous mappings
+* in DMA address space
+*/
+ if (!dev-dma_parms) {
+ dev-dma_parms = kzalloc(sizeof(*dev-dma_parms), GFP_KERNEL);
I was checking how dma_parms was usually allocated and freed, and was shocked
to find that the memory is never freed. OK, actually not shocked, I had a bad
feeling about it already, but it's still not good :-/
This goes beyond the scope of this patch, but I think we need to clean up
dma_parms. The structure is 8 bytes long on 32-bit systems and 16 bytes long
on 64-bit systems. I wonder if it's really worth it to allocate it separately
from struct device. It might if we moved more DMA-related fields to struct
device_dma_parameters but that hasn't happened since 2008 when the structure
was introduced (yes that's more than 7 years ago).
If we consider it's worth it (and I believe Josh Triplett might, in the
context of the Linux kernel tinification project), we should at least handle
allocation and free of the field coherently across drivers.
Right, the whole dma_params approach looks like some unfinished thing.
Maybe it
would be better to remove it completely instead of having separate structure
just for 2 values? This will solve the allocation/freeing issue as well.
+ if (!dev-dma_parms)
+ return ERR_PTR(-ENOMEM);
+ }
+ if (dma_get_max_seg_size(dev) DMA_BIT_MASK(32)) {
+ err = dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
What if the device has set a maximum segment size smaller than 4GB because of
hardware limitations ?
Then it looks that it will make more sense to set max_seg_size only when dma
params structure has been allocated and keep the old value otherwise.
I also wonder whether this is the correct place to solve the issue.
Frankly I don't see any good place for this code, especially if you consider
the default 64kB value and the fact that some code relies on it, so you
cannot
change it easily in generic code.
Why is the
default value returned by dma_get_max_seg_size() set to 64kB ?
I really have no idea why the default value is 64kB, but it looks that
there are
drivers that rely on this value:
https://www.marc.info/?l=linux-arm-kernelm=141692087708203w=2
+ if (err)
+ return ERR_PTR(err);
+ }
conf = kzalloc(sizeof *conf, GFP_KERNEL);
if (!conf)
Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
Many thanks to the developers for all of your hard work. Let me guess they have changed Si2168 chip to latest C version. Driver supports only A and B (A20, A30 and B40). I have never seen C version. I'll look in detail and report back shortly. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/15] media: soc_camera: soc_scale_crop: Use correct pad number in try_fmt
From: Rob Taylor rob.tay...@codethink.co.uk
Fix calls to subdev try_fmt to use correct pad. Fixes failures with
subdevs that care about having the right pad number set.
Signed-off-by: William Towle william.to...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/soc_scale_crop.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/platform/soc_camera/soc_scale_crop.c
b/drivers/media/platform/soc_camera/soc_scale_crop.c
index bda29bc..90e2769 100644
--- a/drivers/media/platform/soc_camera/soc_scale_crop.c
+++ b/drivers/media/platform/soc_camera/soc_scale_crop.c
@@ -225,6 +225,10 @@ static int client_set_fmt(struct soc_camera_device *icd,
bool host_1to1;
int ret;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ format-pad = icd-src_pad_idx;
+#endif
+
ret = v4l2_device_call_until_err(sd-v4l2_dev,
soc_camera_grp_id(icd), pad,
set_fmt, NULL, format);
@@ -261,10 +265,16 @@ static int client_set_fmt(struct soc_camera_device *icd,
/* width = max_width height = max_height - guaranteed by try_fmt */
while ((width tmp_w || height tmp_h)
tmp_w max_width tmp_h max_height) {
+
tmp_w = min(2 * tmp_w, max_width);
tmp_h = min(2 * tmp_h, max_height);
mf-width = tmp_w;
mf-height = tmp_h;
+
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ format-pad = icd-src_pad_idx;
+#endif
+
ret = v4l2_device_call_until_err(sd-v4l2_dev,
soc_camera_grp_id(icd), pad,
set_fmt, NULL, format);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/15] media: soc_camera pad-aware driver initialisation
Add detection of source pad number for drivers aware of the media
controller API, so that the combination of soc_camera and rcar_vin
can create device nodes to support modern drivers such as adv7604.c
(for HDMI on Lager) and the converted adv7180.c (for composite)
underneath.
Building rcar_vin gains a dependency on CONFIG_MEDIA_CONTROLLER, in
line with requirements for building the drivers associated with it.
Signed-off-by: William Towle william.to...@codethink.co.uk
Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/Kconfig |1 +
drivers/media/platform/soc_camera/rcar_vin.c |1 +
drivers/media/platform/soc_camera/soc_camera.c | 46
include/media/soc_camera.h |1 +
4 files changed, 49 insertions(+)
diff --git a/drivers/media/platform/soc_camera/Kconfig
b/drivers/media/platform/soc_camera/Kconfig
index f2776cd..5c45c83 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -38,6 +38,7 @@ config VIDEO_RCAR_VIN
depends on VIDEO_DEV SOC_CAMERA
depends on ARCH_SHMOBILE || COMPILE_TEST
depends on HAS_DMA
+ depends on MEDIA_CONTROLLER
select VIDEOBUF2_DMA_CONTIG
select SOC_CAMERA_SCALE_CROP
---help---
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 16352a8..00c1034 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1359,6 +1359,7 @@ static int rcar_vin_get_formats(struct soc_camera_device
*icd, unsigned int idx,
struct device *dev = icd-parent;
int shift;
+ fmt.pad = icd-src_pad_idx;
ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
if (ret 0)
return ret;
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index d708df4..c4952c8 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1293,6 +1293,9 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
struct v4l2_mbus_framefmt *mf = fmt.format;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_pad pad;
+#endif
int ret;
sd-grp_id = soc_camera_grp_id(icd);
@@ -1310,8 +1313,40 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
return ret;
}
+ icd-src_pad_idx = -1;
+#if defined(CONFIG_MEDIA_CONTROLLER)
/* At this point client .probe() should have run already */
+ ret = media_entity_init(icd-vdev-entity, 1, pad, 0);
+ if (ret 0) {
+ goto eusrfmt;
+ } else {
+ int pad_idx;
+
+ for (pad_idx = 0; pad_idx sd-entity.num_pads; pad_idx++)
+ if (sd-entity.pads[pad_idx].flags
+ == MEDIA_PAD_FL_SOURCE)
+ break;
+ if (pad_idx = sd-entity.num_pads)
+ goto eusrfmt;
+
+ ret = media_entity_create_link(icd-vdev-entity, 0,
+ sd-entity, pad_idx,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED);
+ if (ret 0)
+ goto eusrfmt;
+
+ icd-src_pad_idx = pad_idx;
+ ret = soc_camera_init_user_formats(icd);
+ if (ret 0) {
+ icd-src_pad_idx = -1;
+ goto eusrfmt;
+ }
+ }
+#else
ret = soc_camera_init_user_formats(icd);
+#endif
+
if (ret 0)
goto eusrfmt;
@@ -1322,6 +1357,9 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
goto evidstart;
/* Try to improve our guess of a reasonable window format */
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ fmt.pad = icd-src_pad_idx;
+#endif
if (!v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt)) {
icd-user_width = mf-width;
icd-user_height= mf-height;
@@ -1335,6 +1373,9 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
evidstart:
soc_camera_free_user_formats(icd);
eusrfmt:
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ media_entity_cleanup(icd-vdev-entity);
+#endif
soc_camera_remove_device(icd);
return ret;
@@ -1856,6 +1897,11 @@ static int soc_camera_remove(struct soc_camera_device
*icd)
if (icd-num_user_formats)
soc_camera_free_user_formats(icd);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ if (icd-vdev-entity.num_pads)
+
Re: Hauppauge WinTV-HVR2205 driver feedback
On Wed, Jun 3, 2015 at 5:29 AM, Olli Salonen olli.salo...@iki.fi wrote: I'm seeing the same issue as well. I thought that maybe some recent Si2168 changes did impact this, but it does not seem to be the case. We've had a couple of people raise this so its highly likely we have an issue. I had some patches to the 2168 driver to add support for a new firmware revision. The last time I tested the HVR2205 I convinced myself those were not required, thus I discarded those and re-tested. Probably a warm boot. If the GPIOs aren't truly resetting the SI2168 and thus a warm boot didn't flush the firmware, I suspect dropping the patches would have no immediate effect until a full power-down took place. I'm wondering whether the testing was invalid and indeed we have a problem in the field, as well as a GPIO issue. Two potential issues. I'll schedule sometime later this week to fire up my HVR22xx dev platform and re-validate the 2205. Thanks for raising this. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/15] media: adv7604: chip info and formats for ADV7612
Add support for the ADV7612 chip as implemented on Renesas' Lager
board to adv7604.c, including lists for formats/colourspace/timing
selection and an IRQ handler.
Signed-off-by: William Towle william.to...@codethink.co.uk
---
drivers/media/i2c/adv7604.c | 91 +--
1 file changed, 87 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index aaa37b0..16646517 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -80,6 +80,7 @@ MODULE_LICENSE(GPL);
enum adv76xx_type {
ADV7604,
ADV7611,
+ ADV7612,
};
struct adv76xx_reg_seq {
@@ -758,6 +759,23 @@ static const struct adv76xx_format_info adv7611_formats[]
= {
ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_12BIT },
};
+static const struct adv76xx_format_info adv7612_formats[] = {
+ { MEDIA_BUS_FMT_RGB888_1X24, ADV76XX_OP_CH_SEL_RGB, true, false,
+ ADV76XX_OP_MODE_SEL_SDR_444 | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_YUYV8_2X8, ADV76XX_OP_CH_SEL_RGB, false, false,
+ ADV76XX_OP_MODE_SEL_SDR_422 | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_YVYU8_2X8, ADV76XX_OP_CH_SEL_RGB, false, true,
+ ADV76XX_OP_MODE_SEL_SDR_422 | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_UYVY8_1X16, ADV76XX_OP_CH_SEL_RBG, false, false,
+ ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_VYUY8_1X16, ADV76XX_OP_CH_SEL_RBG, false, true,
+ ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_YUYV8_1X16, ADV76XX_OP_CH_SEL_RGB, false, false,
+ ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT },
+ { MEDIA_BUS_FMT_YVYU8_1X16, ADV76XX_OP_CH_SEL_RGB, false, true,
+ ADV76XX_OP_MODE_SEL_SDR_422_2X | ADV76XX_OP_FORMAT_SEL_8BIT },
+};
+
static const struct adv76xx_format_info *
adv76xx_format_info(struct adv76xx_state *state, u32 code)
{
@@ -2471,6 +2489,11 @@ static void adv7611_setup_irqs(struct v4l2_subdev *sd)
io_write(sd, 0x41, 0xd0); /* STDI irq for any change, disable INT2 */
}
+static void adv7612_setup_irqs(struct v4l2_subdev *sd)
+{
+ io_write(sd, 0x41, 0xd0); /* disable INT2 */
+}
+
static void adv76xx_unregister_clients(struct adv76xx_state *state)
{
unsigned int i;
@@ -2558,6 +2581,19 @@ static const struct adv76xx_reg_seq
adv7611_recommended_settings_hdmi[] = {
{ ADV76XX_REG_SEQ_TERM, 0 },
};
+static const struct adv76xx_reg_seq adv7612_recommended_settings_hdmi[] = {
+ { ADV76XX_REG(ADV76XX_PAGE_CP, 0x6c), 0x00 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x9b), 0x03 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x6f), 0x08 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x85), 0x1f },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x87), 0x70 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x57), 0xda },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x58), 0x01 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x03), 0x98 },
+ { ADV76XX_REG(ADV76XX_PAGE_HDMI, 0x4c), 0x44 },
+ { ADV76XX_REG_SEQ_TERM, 0 },
+};
+
static const struct adv76xx_chip_info adv76xx_chip_info[] = {
[ADV7604] = {
.type = ADV7604,
@@ -2646,17 +2682,59 @@ static const struct adv76xx_chip_info
adv76xx_chip_info[] = {
.field1_vsync_mask = 0x3fff,
.field1_vbackporch_mask = 0x3fff,
},
+ [ADV7612] = {
+ .type = ADV7612,
+ .has_afe = false,
+ .max_port = ADV7604_PAD_HDMI_PORT_B,
+ .num_dv_ports = 2,
+ .edid_enable_reg = 0x74,
+ .edid_status_reg = 0x76,
+ .lcf_reg = 0xa3,
+ .tdms_lock_mask = 0x43,
+ .cable_det_mask = 0x01,
+ .fmt_change_digital_mask = 0x03,
+ .formats = adv7612_formats,
+ .nformats = ARRAY_SIZE(adv7612_formats),
+ .set_termination = adv7611_set_termination,
+ .setup_irqs = adv7612_setup_irqs,
+ .read_hdmi_pixelclock = adv7611_read_hdmi_pixelclock,
+ .read_cable_det = adv7611_read_cable_det,
+ .recommended_settings = {
+ [1] = adv7612_recommended_settings_hdmi,
+ },
+ .num_recommended_settings = {
+ [1] = ARRAY_SIZE(adv7612_recommended_settings_hdmi),
+ },
+ .page_mask = BIT(ADV76XX_PAGE_IO) | BIT(ADV76XX_PAGE_CEC) |
+ BIT(ADV76XX_PAGE_INFOFRAME) | BIT(ADV76XX_PAGE_AFE) |
+ BIT(ADV76XX_PAGE_REP) | BIT(ADV76XX_PAGE_EDID) |
+ BIT(ADV76XX_PAGE_HDMI) | BIT(ADV76XX_PAGE_CP),
+ .linewidth_mask = 0x1fff,
+ .field0_height_mask = 0x1fff,
+ .field1_height_mask = 0x1fff,
+ .hfrontporch_mask = 0x1fff,
+ .hsync_mask =
[PATCH 07/15] ARM: shmobile: lager dts: specify default-input for ADV7612
Set 'default-input' property for ADV7612. Enables image/video capture
without the need to have userspace specifying routing.
Signed-off-by: Ian Molton ian.mol...@codethink.co.uk
Tested-by: William Towle william.to...@codethink.co.uk
---
arch/arm/boot/dts/r8a7790-lager.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 90c4531..6946e9a 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -544,6 +544,7 @@
port {
hdmi_in_ep: endpoint {
remote-endpoint = vin0ep0;
+ default-input = 0;
};
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/15] media: adv7180: add of match table
From: Ben Dooks ben.do...@codethink.co.uk
Add a proper of match id for use when the device is being bound via
device tree, to avoid having to use the i2c old-style binding of the
device.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
Signed-off-by: William.Towle william.to...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/i2c/adv7180.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index a493c0b..09a96df 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -25,6 +25,7 @@
#include linux/interrupt.h
#include linux/i2c.h
#include linux/slab.h
+#include linux/of.h
#include media/v4l2-ioctl.h
#include linux/videodev2.h
#include media/v4l2-device.h
@@ -1324,11 +1325,21 @@ static SIMPLE_DEV_PM_OPS(adv7180_pm_ops,
adv7180_suspend, adv7180_resume);
#define ADV7180_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id adv7180_of_id[] = {
+ { .compatible = adi,adv7180, },
+ { },
+};
+
+MODULE_DEVICE_TABLE(of, adv7180_of_id);
+#endif
+
static struct i2c_driver adv7180_driver = {
.driver = {
.owner = THIS_MODULE,
.name = KBUILD_MODNAME,
.pm = ADV7180_PM_OPS,
+ .of_match_table = of_match_ptr(adv7180_of_id),
},
.probe = adv7180_probe,
.remove = adv7180_remove,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/15] media: soc_camera: fill in bus_info field
From: Rob Taylor rob.tay...@codethink.co.uk Adapt soc_camera_querycap() so that cap-bus_info is populated in addition to cap-driver. Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk Reviewed-by: William Towle william.to...@codethink.co.uk --- drivers/media/platform/soc_camera/soc_camera.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index 4e59833..675cfc4 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -954,6 +954,7 @@ static int soc_camera_querycap(struct file *file, void *priv, WARN_ON(priv != file-private_data); strlcpy(cap-driver, ici-drv_name, sizeof(cap-driver)); + strlcpy(cap-bus_info, platform:soc_camera, sizeof(cap-bus_info)); return ici-ops-querycap(ici, cap); } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
HDMI and Composite capture on Lager, for kernel 4.1, version 3
Version 3. Obsoletes version 2, as seen at: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/91668 Key changes in this version: this has some reworking of the adv7604 driver probe and soc_camera initialisation functions. In addition, we give rcar_vin.c a dependency on CONFIG_MEDIA_CONTROLLER in line with the drivers used with it. Cheers, Wills. To follow: [PATCH 01/15] ARM: shmobile: lager dts: Add entries for VIN HDMI [PATCH 02/15] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 [PATCH 03/15] media: adv7180: add of match table [PATCH 04/15] media: adv7604: chip info and formats for ADV7612 [PATCH 05/15] media: adv7604: document support for ADV7612 dual HDMI [PATCH 06/15] media: adv7604: ability to read default input port [PATCH 07/15] ARM: shmobile: lager dts: specify default-input for [PATCH 08/15] v4l: subdev: Add pad config allocator and init [PATCH 09/15] media: soc_camera pad-aware driver initialisation [PATCH 10/15] media: rcar_vin: Use correct pad number in try_fmt [PATCH 11/15] media: soc_camera: soc_scale_crop: Use correct pad [PATCH 12/15] media: soc_camera: Fill std field in enum_input [PATCH 13/15] media: soc_camera: Fix error reporting in expbuf [PATCH 14/15] media: soc_camera: fill in bus_info field [PATCH 15/15] media: rcar_vin: Reject videobufs that are too small -- 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 10/15] media: rcar_vin: Use correct pad number in try_fmt
Fix rcar_vin_try_fmt to use the correct pad number when calling the
subdev set_fmt. Previously pad number 0 was always used, resulting in
EINVAL if the subdev cares about the pad number (e.g. ADV7612).
Signed-off-by: William Towle william.to...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 00c1034..cc993bc 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1697,7 +1697,7 @@ static int rcar_vin_try_fmt(struct soc_camera_device *icd,
const struct soc_camera_format_xlate *xlate;
struct v4l2_pix_format *pix = f-fmt.pix;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- struct v4l2_subdev_pad_config pad_cfg;
+ struct v4l2_subdev_pad_config *pad_cfg;
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_TRY,
};
@@ -1706,6 +1706,8 @@ static int rcar_vin_try_fmt(struct soc_camera_device *icd,
int width, height;
int ret;
+ pad_cfg = v4l2_subdev_alloc_pad_config(sd);
+
xlate = soc_camera_xlate_by_fourcc(icd, pixfmt);
if (!xlate) {
xlate = icd-current_fmt;
@@ -1734,10 +1736,15 @@ static int rcar_vin_try_fmt(struct soc_camera_device
*icd,
mf-code = xlate-code;
mf-colorspace = pix-colorspace;
- ret = v4l2_device_call_until_err(sd-v4l2_dev, soc_camera_grp_id(icd),
-pad, set_fmt, pad_cfg, format);
- if (ret 0)
+ format.pad = icd-src_pad_idx;
+ ret = v4l2_device_call_until_err(sd-v4l2_dev,
+ soc_camera_grp_id(icd), pad,
+ set_fmt, pad_cfg,
+ format);
+ if (ret 0) {
+ v4l2_subdev_free_pad_config(pad_cfg);
return ret;
+ }
/* Adjust only if VIN cannot scale */
if (pix-width mf-width * 2)
@@ -1759,13 +1766,15 @@ static int rcar_vin_try_fmt(struct soc_camera_device
*icd,
*/
mf-width = VIN_MAX_WIDTH;
mf-height = VIN_MAX_HEIGHT;
+ format.pad = icd-src_pad_idx;
ret = v4l2_device_call_until_err(sd-v4l2_dev,
soc_camera_grp_id(icd),
-pad, set_fmt, pad_cfg,
+pad, set_fmt, pad_cfg,
format);
if (ret 0) {
dev_err(icd-parent,
client try_fmt() = %d\n, ret);
+ v4l2_subdev_free_pad_config(pad_cfg);
return ret;
}
}
@@ -1776,6 +1785,7 @@ static int rcar_vin_try_fmt(struct soc_camera_device *icd,
pix-height = height;
}
+ v4l2_subdev_free_pad_config(pad_cfg);
return ret;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/15] ARM: shmobile: lager dts: Add entries for VIN HDMI input support
Add DT entries for vin0, vin0_pins, and adv7612
Signed-off-by: William Towle william.to...@codethink.co.uk
Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk
---
arch/arm/boot/dts/r8a7790-lager.dts | 41 ++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index aaa4f25..90c4531 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -370,7 +370,12 @@
renesas,function = usb2;
};
- vin1_pins: vin {
+ vin0_pins: vin0 {
+ renesas,groups = vin0_data24, vin0_sync, vin0_field,
vin0_clkenb, vin0_clk;
+ renesas,function = vin0;
+ };
+
+ vin1_pins: vin1 {
renesas,groups = vin1_data8, vin1_clk;
renesas,function = vin1;
};
@@ -531,6 +536,18 @@
reg = 0x12;
};
+ hdmi-in@4c {
+ compatible = adi,adv7612;
+ reg = 0x4c;
+ remote = vin0;
+
+ port {
+ hdmi_in_ep: endpoint {
+ remote-endpoint = vin0ep0;
+ };
+ };
+ };
+
composite-in@20 {
compatible = adi,adv7180;
reg = 0x20;
@@ -646,6 +663,28 @@
status = okay;
};
+/* HDMI video input */
+vin0 {
+ pinctrl-0 = vin0_pins;
+ pinctrl-names = default;
+
+ status = ok;
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ vin0ep0: endpoint {
+ remote-endpoint = hdmi_in_ep;
+ bus-width = 24;
+ hsync-active = 0;
+ vsync-active = 0;
+ pclk-sample = 1;
+ data-active = 1;
+ };
+ };
+};
+
/* composite video input */
vin1 {
pinctrl-0 = vin1_pins;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/15] media: rcar_vin: Reject videobufs that are too small for current format
From: Rob Taylor rob.tay...@codethink.co.uk In videobuf_setup reject buffers that are too small for the configured format. Fixes v4l2-complience issue. Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk Reviewed-by: William Towle william.to...@codethink.co.uk --- drivers/media/platform/soc_camera/rcar_vin.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index cc993bc..1531a76 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -541,6 +541,9 @@ static int rcar_vin_videobuf_setup(struct vb2_queue *vq, unsigned int bytes_per_line; int ret; + if (fmt-fmt.pix.sizeimage icd-sizeimage) + return -EINVAL; + xlate = soc_camera_xlate_by_fourcc(icd, fmt-fmt.pix.pixelformat); if (!xlate) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/15] media: adv7604: ability to read default input port from DT
From: Ian Molton ian.mol...@codethink.co.uk
Adds support to the adv7604 driver for specifying the default input
port in the Device tree. If no value is provided, the driver will be
unable to select an input without help from userspace.
Tested-by: William Towle william.to...@codethink.co.uk
Signed-off-by: Ian Molton ian.mol...@codethink.co.uk
---
Documentation/devicetree/bindings/media/i2c/adv7604.txt |3 +++
drivers/media/i2c/adv7604.c |8 +++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index 7eafdbc..8337f75 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -47,6 +47,7 @@ Optional Endpoint Properties:
If none of hsync-active, vsync-active and pclk-sample is specified the
endpoint will use embedded BT.656 synchronization.
+ - default-input: Select which input is selected after reset.
Example:
@@ -60,6 +61,8 @@ Example:
#address-cells = 1;
#size-cells = 0;
+ default-input = 0;
+
port@0 {
reg = 0;
};
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 16646517..5b6ac8e 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2745,6 +2745,7 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
struct device_node *endpoint;
struct device_node *np;
unsigned int flags;
+ u32 v;
np = state-i2c_clients[ADV76XX_PAGE_IO]-dev.of_node;
@@ -2754,6 +2755,12 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
return -EINVAL;
v4l2_of_parse_endpoint(endpoint, bus_cfg);
+
+ if (!of_property_read_u32(endpoint, default-input, v))
+ state-pdata.default_input = v;
+ else
+ state-pdata.default_input = -1;
+
of_node_put(endpoint);
flags = bus_cfg.bus.parallel.flags;
@@ -2792,7 +2799,6 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
/* Hardcode the remaining platform data fields. */
state-pdata.disable_pwrdnb = 0;
state-pdata.disable_cable_det_rst = 0;
- state-pdata.default_input = -1;
state-pdata.blank_data = 1;
state-pdata.alt_data_sat = 1;
state-pdata.op_format_mode_sel = ADV7604_OP_FORMAT_MODE0;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/15] media: soc_camera: Fill std field in enum_input
From: Hans Verkuil hans.verk...@cisco.com
Fill in the std field from the video_device tvnorms field in
enum_input.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/soc_camera.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index c4952c8..51daeb1 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -309,11 +309,14 @@ static int soc_camera_try_fmt_vid_cap(struct file *file,
void *priv,
static int soc_camera_enum_input(struct file *file, void *priv,
struct v4l2_input *inp)
{
+ struct soc_camera_device *icd = file-private_data;
+
if (inp-index != 0)
return -EINVAL;
/* default is camera */
inp-type = V4L2_INPUT_TYPE_CAMERA;
+ inp-std = icd-vdev-tvnorms;
strcpy(inp-name, Camera);
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/15] media: soc_camera: rcar_vin: Add BT.709 24-bit RGB888 input support
This adds V4L2_MBUS_FMT_RGB888_1X24 input format support
which is used by the ADV7612 chip.
Signed-off-by: Koji Matsuoka koji.matsuoka...@renesas.com
Signed-off-by: Simon Horman horms+rene...@verge.net.au
Signed-off-by: Yoshihiro Kaneko ykaneko0...@gmail.com
Modified to use MEDIA_BUS_FMT_* constants
Signed-off-by: William Towle william.to...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index db7700b..16352a8 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -98,6 +98,7 @@
#define VNMC_INF_YUV10_BT656 (2 16)
#define VNMC_INF_YUV10_BT601 (3 16)
#define VNMC_INF_YUV16 (5 16)
+#define VNMC_INF_RGB888(6 16)
#define VNMC_VUP (1 10)
#define VNMC_IM_ODD(0 3)
#define VNMC_IM_ODD_EVEN (1 3)
@@ -589,7 +590,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
struct soc_camera_device *icd = priv-ici.icd;
struct rcar_vin_cam *cam = icd-host_priv;
u32 vnmc, dmr, interrupts;
- bool progressive = false, output_is_yuv = false;
+ bool progressive = false, output_is_yuv = false, input_is_yuv = false;
switch (priv-field) {
case V4L2_FIELD_TOP:
@@ -623,16 +624,22 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
case MEDIA_BUS_FMT_YUYV8_1X16:
/* BT.601/BT.1358 16bit YCbCr422 */
vnmc |= VNMC_INF_YUV16;
+ input_is_yuv = true;
break;
case MEDIA_BUS_FMT_YUYV8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
vnmc |= priv-pdata_flags RCAR_VIN_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
+ input_is_yuv = true;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ vnmc |= VNMC_INF_RGB888;
break;
case MEDIA_BUS_FMT_YUYV10_2X10:
/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
vnmc |= priv-pdata_flags RCAR_VIN_BT656 ?
VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
+ input_is_yuv = true;
break;
default:
break;
@@ -676,7 +683,7 @@ static int rcar_vin_setup(struct rcar_vin_priv *priv)
vnmc |= VNMC_VUP;
/* If input and output use the same colorspace, use bypass mode */
- if (output_is_yuv)
+ if (input_is_yuv == output_is_yuv)
vnmc |= VNMC_BPS;
/* progressive or interlaced mode */
@@ -1423,6 +1430,7 @@ static int rcar_vin_get_formats(struct soc_camera_device
*icd, unsigned int idx,
case MEDIA_BUS_FMT_YUYV8_1X16:
case MEDIA_BUS_FMT_YUYV8_2X8:
case MEDIA_BUS_FMT_YUYV10_2X10:
+ case MEDIA_BUS_FMT_RGB888_1X24:
if (cam-extra_fmt)
break;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/15] media: soc_camera: Fix error reporting in expbuf
From: Hans Verkuil hans.verk...@cisco.com Remove unnecessary check and fix the error code for vb1 drivers. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk --- drivers/media/platform/soc_camera/soc_camera.c |8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index 51daeb1..4e59833 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -470,14 +470,10 @@ static int soc_camera_expbuf(struct file *file, void *priv, struct soc_camera_device *icd = file-private_data; struct soc_camera_host *ici = to_soc_camera_host(icd-parent); - if (icd-streamer != file) - return -EBUSY; - /* videobuf2 only */ if (ici-ops-init_videobuf) - return -EINVAL; - else - return vb2_expbuf(icd-vb2_vidq, p); + return -ENOTTY; + return vb2_expbuf(icd-vb2_vidq, p); } /* Always entered with .host_lock held */ -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/15] media: adv7604: document support for ADV7612 dual HDMI input decoder
From: Ian Molton ian.mol...@codethink.co.uk This documentation accompanies the patch adding support for the ADV7612 dual HDMI decoder / repeater chip. Signed-off-by: Ian Molton ian.mol...@codethink.co.uk Reviewed-by: William Towle william.to...@codethink.co.uk --- .../devicetree/bindings/media/i2c/adv7604.txt| 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index c27cede..7eafdbc 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -1,15 +1,17 @@ -* Analog Devices ADV7604/11 video decoder with HDMI receiver +* Analog Devices ADV7604/11/12 video decoder with HDMI receiver -The ADV7604 and ADV7611 are multiformat video decoders with an integrated HDMI -receiver. The ADV7604 has four multiplexed HDMI inputs and one analog input, -and the ADV7611 has one HDMI input and no analog input. +The ADV7604 and ADV7611/12 are multiformat video decoders with an integrated +HDMI receiver. The ADV7604 has four multiplexed HDMI inputs and one analog +input, and the ADV7611 has one HDMI input and no analog input. The 7612 is +similar to the 7611 but has 2 HDMI inputs. -These device tree bindings support the ADV7611 only at the moment. +These device tree bindings support the ADV7611/12 only at the moment. Required Properties: - compatible: Must contain one of the following - adi,adv7611 for the ADV7611 +- adi,adv7612 for the ADV7612 - reg: I2C slave address @@ -22,10 +24,10 @@ port, in accordance with the video interface bindings defined in Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes are numbered as follows. - Port ADV7611 + Port ADV7611ADV7612 - HDMI 0 - Digital output 1 + HDMI 0 0, 1 + Digital output 12 The digital output port node must contain at least one endpoint. -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/15] v4l: subdev: Add pad config allocator and init
From: Laurent Pinchart laurent.pinch...@linaro.org
Add a new subdev operation to initialize a subdev pad config array, and
a helper function to allocate and initialize the array. This can be used
by bridge drivers to implement try format based on subdev pad
operations.
Signed-off-by: Laurent Pinchart laurent.pinch...@linaro.org
Acked-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/media/v4l2-core/v4l2-subdev.c | 19 ++-
include/media/v4l2-subdev.h | 10 ++
2 files changed, 28 insertions(+), 1 deletion(-)
Changes since v1:
- Added v4l2_subdev_free_pad_config
---
drivers/media/v4l2-core/v4l2-subdev.c | 19 ++-
include/media/v4l2-subdev.h | 10 ++
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c
index 6359606..d594fe5 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -35,7 +35,7 @@
static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev *sd)
{
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
- fh-pad = kzalloc(sizeof(*fh-pad) * sd-entity.num_pads, GFP_KERNEL);
+ fh-pad = v4l2_subdev_alloc_pad_config(sd);
if (fh-pad == NULL)
return -ENOMEM;
#endif
@@ -569,6 +569,23 @@ int v4l2_subdev_link_validate(struct media_link *link)
sink, link, source_fmt, sink_fmt);
}
EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate);
+
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct v4l2_subdev
*sd)
+{
+ struct v4l2_subdev_pad_config *cfg;
+
+ if (!sd-entity.num_pads)
+ return NULL;
+
+ cfg = kcalloc(sd-entity.num_pads, sizeof(*cfg), GFP_KERNEL);
+ if (!cfg)
+ return NULL;
+
+ v4l2_subdev_call(sd, pad, init_cfg, cfg);
+
+ return cfg;
+}
+EXPORT_SYMBOL_GPL(v4l2_subdev_alloc_pad_config);
#endif /* CONFIG_MEDIA_CONTROLLER */
void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops
*ops)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index dc20102..4a609f6 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -485,6 +485,8 @@ struct v4l2_subdev_pad_config {
* may be adjusted by the subdev driver to device
capabilities.
*/
struct v4l2_subdev_pad_ops {
+ void (*init_cfg)(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg);
int (*enum_mbus_code)(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code);
@@ -677,7 +679,15 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev
*sd,
struct v4l2_subdev_format *source_fmt,
struct v4l2_subdev_format *sink_fmt);
int v4l2_subdev_link_validate(struct media_link *link);
+
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct v4l2_subdev
*sd);
+
+static inline void v4l2_subdev_free_pad_config(struct v4l2_subdev_pad_config
*cfg)
+{
+ kfree(cfg);
+}
#endif /* CONFIG_MEDIA_CONTROLLER */
+
void v4l2_subdev_init(struct v4l2_subdev *sd,
const struct v4l2_subdev_ops *ops);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ISDB Dongle MyGica S2870
Nicolas Antonio Corrarello ncorrare at gmail.com writes: Hey Everyone, I just bought this new dongle, and while the parts seem to be supported, the usb id is not recognised. It seems to be based on the dibcom 0700 IC and it identifies itself as STK8096-PVR. I tried the patch in http://www.spinics.net/lists/linux-media/msg63445.html on the latest linux media tree, but while the dib0700 module now loads automatically, I don't see anything on dmesg showing that its loading the firmware, and I most definitely don't get a /dev/dvb directory. Hi Nicolas, Could you make this work? I'm having the same results as you with the same device. Below is my output: [ 154.192777] usb 3-1: new high-speed USB device number 4 using xhci_hcd [ 154.209368] usb 3-1: New USB device found, idVendor=10b8, idProduct=1faa [ 154.209375] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 154.209379] usb 3-1: Product: STK8096-PVR [ 154.209382] usb 3-1: Manufacturer: Geniatech [ 154.209385] usb 3-1: SerialNumber: 1 Installed the latest drivers from the git repo. Any help much appreciated. Thanks, Luciano -- 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] ts2020: Provide DVBv5 API signal strength
On 03/06/15 11:17, David Howells wrote: Malcolm Priestley tvbox...@gmail.com wrote: Yes, also, the workqueue appears not to be initialized when using the dvb attached method. I'm not sure what you're referring to. It's initialised in ts2020_probe() just after the ts2020_priv struct is allocated - the only place it is allocated. ts2020_probe() isn't touched by devices not converted to I2C binding. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] sound/usb: Update ALSA driver to use media controller API
Change ALSA driver to use media controller API to share tuner
with DVB and V4L2 drivers that control AU0828 media device.
Media device is created based on a newly added field value
in the struct snd_usb_audio_quirk. Using this approach, the
media controller API usage can be added for a specific device.
In this patch, media controller API is enabled for AU0828 hw.
snd_usb_create_quirk() will check this new field, if set will
create a media device using media_device_get_devres() interface.
media_device_get_devres() will allocate a new media device
devres or return an existing one, if it finds one.
During probe, media usb driver could have created the media
device devres. It will then register the media device if it
isn't already registered. Media device unregister is done
from usb_audio_disconnect().
New structure media_ctl is added to group the new fields
to support media entity and links. This new structure is
added to struct snd_usb_substream. A new media entity for
ALSA and a link from tuner entity to the newly registered
ALSA entity are created from snd_usb_init_substream() and
removed from free_substream(). The state is kept to indicate
if tuner is linked. This is to account for case when tuner
entity doesn't exist. Media pipeline gets started to mark
the tuner busy from snd_usb_substream_capture_trigger in
response to SNDRV_PCM_TRIGGER_START and pipeline is stopped
in response to SNDRV_PCM_TRIGGER_STOP. snd_usb_pcm_close()
stops pipeline to cover the case when SNDRV_PCM_TRIGGER_STOP
isn't issued. Pipeline start and stop are done only when
tuner_linked is set.
Tested with and without CONFIG_MEDIA_CONTROLLER enabled.
Tested tuner entity doesn't exist case as au0828 v4l2
driver is the one that will create the tuner when it gets
updated to use media controller API.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
sound/usb/Makefile | 3 +-
sound/usb/card.c | 5 ++
sound/usb/card.h | 1 +
sound/usb/media.c| 181 +++
sound/usb/media.h| 40 +++
sound/usb/pcm.c | 10 ++-
sound/usb/quirks-table.h | 1 +
sound/usb/quirks.c | 9 ++-
sound/usb/stream.c | 3 +
sound/usb/usbaudio.h | 1 +
10 files changed, 251 insertions(+), 3 deletions(-)
create mode 100644 sound/usb/media.c
create mode 100644 sound/usb/media.h
diff --git a/sound/usb/Makefile b/sound/usb/Makefile
index 2d2d122..7fe4fdd 100644
--- a/sound/usb/Makefile
+++ b/sound/usb/Makefile
@@ -13,7 +13,8 @@ snd-usb-audio-objs := card.o \
pcm.o \
proc.o \
quirks.o \
- stream.o
+ stream.o \
+ media.o
snd-usbmidi-lib-objs := midi.o
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 1fab977..469d2bf 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -66,6 +66,7 @@
#include format.h
#include power.h
#include stream.h
+#include media.h
MODULE_AUTHOR(Takashi Iwai ti...@suse.de);
MODULE_DESCRIPTION(USB Audio);
@@ -619,6 +620,10 @@ static void usb_audio_disconnect(struct usb_interface
*intf)
list_for_each_entry(mixer, chip-mixer_list, list) {
snd_usb_mixer_disconnect(mixer);
}
+ /* Nice to check quirk quirk-media_device
+* need some special handlings. Doesn't look like
+* we have access to quirk here */
+ media_device_delete(intf);
}
chip-num_interfaces--;
diff --git a/sound/usb/card.h b/sound/usb/card.h
index ef580b4..235a85f 100644
--- a/sound/usb/card.h
+++ b/sound/usb/card.h
@@ -155,6 +155,7 @@ struct snd_usb_substream {
} dsd_dop;
bool trigger_tstamp_pending_update; /* trigger timestamp being updated
from initial estimate */
+ void *media_ctl;
};
struct snd_usb_stream {
diff --git a/sound/usb/media.c b/sound/usb/media.c
new file mode 100644
index 000..8e8a0b3
--- /dev/null
+++ b/sound/usb/media.c
@@ -0,0 +1,181 @@
+/*
+ * media.c - managed media token resource
+ *
+ * Copyright (c) 2015 Shuah Khan shua...@osg.samsung.com
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ *
+ * This file is released under the GPLv2.
+ */
+
+/*
+ * This file adds Media Controller support to ALSA driver
+ * to use the Media Controller API to share tuner with DVB
+ * and V4L2 drivers that control media device. Media device
+ * is created based on existing quirks framework. Using this
+ * approach, the media controller API usage can be added for
+ * a specific device.
+*/
+
+#ifdef CONFIG_MEDIA_CONTROLLER
+#if defined(CONFIG_MEDIA_SUPPORT) || \
+ (defined(CONFIG_MEDIA_SUPPORT_MODULE) defined(MODULE))
+#define USE_MEDIA_CONTROLLER
+#endif
+#endif
+
+#include linux/init.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/string.h
+#include linux/ctype.h
+#include linux/usb.h
+#include
[PATCH v2 0/2] Update ALSA driver to use media controller API
This patch series updates ALSA driver to use media controller API to share tuner with DVB and V4L2 drivers that control AU0828 media device. Two new interfaces are added to media controller API to enable creating media device as a device resource. This allows creating media device as a device resource on the main struct device that is common to all drivers that control a single media hardware and share resources on it. Drivers then can find the common media device to register entities and manage links, and pipelines. Tested with and without CONFIG_MEDIA_CONTROLLER enabled. Tested tuner entity doesn't exist case as au0828 v4l2 driver is the one that will create the tuner when it gets updated to use media controller API. Please note that au0828 updates media controller are necessary before the resource sharing can work across ALSA and au0828 dvb and v4l2 drivers. This work is in progress and another developer is working on it. Changes since v1: - Moved media specific code into new header and source file - Created a new structure for media controller specific fields - Added a new define USE_MEDIA_CONTROLLER to add media specific code. This new define is defined only when Media Controller support is enabled. New media specific code is active only when this define is defined. - Moved media_deviced_delete() check under !was_shutdown block - Removed return check for media_device_init() - Changed new Media Controller interface names for clarity. Now they are named media_device_get_devres() and media_device_find_devres(). - Calling media_entity_pipeline_stop() on a pipe that isn't active appears to be safe. This needs further testing once AU0828 media controller patches are ready. Shuah Khan (2): media: new media controller API for device resource support sound/usb: Update ALSA driver to use media controller API drivers/media/media-device.c | 33 include/media/media-device.h | 2 + sound/usb/Makefile | 3 +- sound/usb/card.c | 5 ++ sound/usb/card.h | 1 + sound/usb/media.c| 181 +++ sound/usb/media.h| 40 ++ sound/usb/pcm.c | 10 ++- sound/usb/quirks-table.h | 1 + sound/usb/quirks.c | 9 ++- sound/usb/stream.c | 3 + sound/usb/usbaudio.h | 1 + 12 files changed, 286 insertions(+), 3 deletions(-) create mode 100644 sound/usb/media.c create mode 100644 sound/usb/media.h -- 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
[PATCH v2 1/2] media: new media controller API for device resource support
Add new media controller API to allocate media device as a
device resource. When a media device is created on the main
struct device which is the parent device for the interface
device, it will be available to all drivers associated with
that interface. For example, if a usb media device driver
creates the media device on the main struct device which is
common for all the drivers that control the media device,
including the non-media ALSA driver, media controller API
can be used to share access to the resources on the media
device. This new interface provides the above described
feature. A second interface that finds and returns the media
device is added to allow drivers to find the media device
created by any of the drivers associated with the device.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/media-device.c | 33 +
include/media/media-device.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 7b39440..a4d5b24 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -462,3 +462,36 @@ void media_device_unregister_entity(struct media_entity
*entity)
entity-parent = NULL;
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity);
+
+static void media_device_release_devres(struct device *dev, void *res)
+{
+}
+
+/*
+ * media_device_get_devres() - get media device as device resource
+ * creates if one doesn't exist
+*/
+struct media_device *media_device_get_devres(struct device *dev)
+{
+ struct media_device *mdev;
+
+ mdev = devres_find(dev, media_device_release_devres, NULL, NULL);
+ if (mdev)
+ return mdev;
+
+ mdev = devres_alloc(media_device_release_devres,
+ sizeof(struct media_device), GFP_KERNEL);
+ if (!mdev)
+ return NULL;
+ return devres_get(dev, mdev, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(media_device_get_devres);
+
+/*
+ * media_device_find_devres() - find media device as device resource
+*/
+struct media_device *media_device_find_devres(struct device *dev)
+{
+ return devres_find(dev, media_device_release_devres, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(media_device_find_devres);
diff --git a/include/media/media-device.h b/include/media/media-device.h
index 6e6db78..22792cd 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -95,6 +95,8 @@ void media_device_unregister(struct media_device *mdev);
int __must_check media_device_register_entity(struct media_device *mdev,
struct media_entity *entity);
void media_device_unregister_entity(struct media_entity *entity);
+struct media_device *media_device_get_devres(struct device *dev);
+struct media_device *media_device_find_devres(struct device *dev);
/* Iterate over all entities. */
#define media_device_for_each_entity(entity, mdev) \
--
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] ts2020: Provide DVBv5 API signal strength
On 03/06/15 12:13, Antti Palosaari wrote: On 05/28/2015 11:07 PM, Malcolm Priestley wrote: On 28/05/15 11:08, David Howells wrote: Malcolm Priestley tvbox...@gmail.com wrote: Statistics polling can not be done by lmedm04 driver's implementation of M88RS2000/TS2020 because I2C messages stop the devices demuxer. I did make tests (using that same lme2510 + rs2000 device) and didn't saw the issue TS was lost. Could test and and tell me how to reproduce it? Signal strength returned was quite boring though, about same value all the time, but it is different issue... Hi Antti The workqueue is not working because ts2020_probe() isn't called. I am thinking that other drivers that still use dvb_attach may be broken. It will become an issue when the driver is converted to I2C binding. Regards Malcolm -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV-HVR2205 driver feedback
On 06/03/2015 12:29 PM, Olli Salonen wrote: I'm seeing the same issue as well. I thought that maybe some recent Si2168 changes did impact this, but it does not seem to be the case. I made a quick test myself. I reverted the latest si2168 patches one by one, but that did not remedy the situation. Anyway, the kernel log does not seem to indicate that the si2168_cmd_execute itself would fail (which is what happens after the I2C error handling patch in case the demod sets the error bit). olli@dl160:~/src/media_tree/drivers/media/dvb-frontends$ git log --oneline si2168.c d4b3830 Revert [media] si2168: add support for gapped clock eb62eb1 Revert [media] si2168: add I2C error handling 7adf99d [media] si2168: add I2C error handling 8117a31 [media] si2168: add support for gapped clock 17d4d6a [media] si2168: add support for 1.7MHz bandwidth 683e98b [media] si2168: return error if set_frontend is called with invalid para c32b281 [media] si2168: change firmware variable name and type 9b7839c [media] si2168: print chip version dmesg lines when it fails (this is with a card that has worked before): [1.336898] saa7164[0]: registered device video0 [mpeg] [1.567295] saa7164[0]: registered device video1 [mpeg] [1.778660] saa7164[0]: registered device vbi0 [vbi] [1.778817] saa7164[0]: registered device vbi1 [vbi] [66675.175508] si2168:si2168_init: si2168 2-0064: [66675.187299] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 6 ms [66675.194105] si2168:si2168_cmd_execute: si2168 2-0064: cmd execution took 2 ms [OLLI: The result of this I2C cmd must be bogus] [66675.194110] si2168 2-0064: unknown chip version Si2168- [66675.200244] si2168:si2168_init: si2168 2-0064: failed=-22 [66675.213020] si2157 0-0060: found a 'Silicon Labs Si2157-A30' [66675.242856] si2157 0-0060: firmware version: 3.0.5 Okei, so it has been working earlier... Could you enable I2C debugs to see what kind of data that command returns? What I suspect in first hand is that Windows driver has downloaded firmware to chip and linux driver does it again, but with incompatible firmware, which leads to situation it starts failing. But if that is issue you likely already noted it. regards Antti -- http://palosaari.fi/ -- 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] ts2020: Provide DVBv5 API signal strength
On 06/03/2015 07:37 PM, David Howells wrote: Malcolm Priestley tvbox...@gmail.com wrote: Yes, also, the workqueue appears not to be initialized when using the dvb attached method. I'm not sure what you're referring to. It's initialised in ts2020_probe() just after the ts2020_priv struct is allocated - the only place it is allocated. ts2020_probe() isn't touched by devices not converted to I2C binding. Hmmm... Doesn't that expose a larger problem? The only place the ts2020_priv struct is allocated is in ts2020_probe() within ts2020.c and the struct definition is private to that file and so it can't be allocated from outside. So if you don't pass through ts2020_probe(), fe-tuner_priv will remain NULL and the driver will crash. Malcolm misses some pending patches where attach() is wrapped to I2C model probe(). http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=ts2020 regards Antti -- http://palosaari.fi/ -- 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] ts2020: Provide DVBv5 API signal strength
Antti Palosaari cr...@iki.fi wrote: Malcolm misses some pending patches where attach() is wrapped to I2C model probe(). http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=ts2020 Aha! That explains it. ts2020: register I2C driver from legacy media attach removes the allocation from attach() in the branch I'm working on top of. David -- 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] ts2020: Provide DVBv5 API signal strength
Malcolm Priestley tvbox...@gmail.com wrote: Yes, also, the workqueue appears not to be initialized when using the dvb attached method. I'm not sure what you're referring to. It's initialised in ts2020_probe() just after the ts2020_priv struct is allocated - the only place it is allocated. ts2020_probe() isn't touched by devices not converted to I2C binding. Hmmm... Doesn't that expose a larger problem? The only place the ts2020_priv struct is allocated is in ts2020_probe() within ts2020.c and the struct definition is private to that file and so it can't be allocated from outside. So if you don't pass through ts2020_probe(), fe-tuner_priv will remain NULL and the driver will crash. David -- 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] ts2020: Provide DVBv5 API signal strength
On 03/06/15 17:43, Antti Palosaari wrote: On 06/03/2015 07:37 PM, David Howells wrote: Malcolm Priestley tvbox...@gmail.com wrote: Yes, also, the workqueue appears not to be initialized when using the dvb attached method. I'm not sure what you're referring to. It's initialised in ts2020_probe() just after the ts2020_priv struct is allocated - the only place it is allocated. ts2020_probe() isn't touched by devices not converted to I2C binding. Hmmm... Doesn't that expose a larger problem? The only place the ts2020_priv struct is allocated is in ts2020_probe() within ts2020.c and the struct definition is private to that file and so it can't be allocated from outside. So if you don't pass through ts2020_probe(), fe-tuner_priv will remain NULL and the driver will crash. Malcolm misses some pending patches where attach() is wrapped to I2C model probe(). http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=ts2020 Hmmm... Yes, I am indeed missing those patches. I will test. -- 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] ts2020: Provide DVBv5 API signal strength
On 03/06/15 17:37, David Howells wrote: Malcolm Priestley tvbox...@gmail.com wrote: Yes, also, the workqueue appears not to be initialized when using the dvb attached method. I'm not sure what you're referring to. It's initialised in ts2020_probe() just after the ts2020_priv struct is allocated - the only place it is allocated. ts2020_probe() isn't touched by devices not converted to I2C binding. Hmmm... Doesn't that expose a larger problem? The only place the ts2020_priv struct is allocated is in ts2020_probe() within ts2020.c and the struct definition is private to that file and so it can't be allocated from outside. So if you don't pass through ts2020_probe(), fe-tuner_priv will remain NULL and the driver will crash. No, it is also allocated in ts2020_attach. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On 3 June 2015 at 15:07, Hans Verkuil hverk...@xs4all.nl wrote: On 06/03/15 10:41, Russell King - ARM Linux wrote: On Wed, Jun 03, 2015 at 08:39:55AM +0200, Hans Verkuil wrote: Hi Sumit, On 05/05/2015 04:41 PM, Sumit Semwal wrote: Hi Russell, everyone, First up, sincere apologies for being awol for sometime; had some personal / medical things to take care of, and then I thought I'd wait for the merge window to get over before beginning to discuss this again. On 11 February 2015 at 21:53, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote: Hello, On 2015-02-11 12:12, Russell King - ARM Linux wrote: Which is a damn good reason to NAK it - by that admission, it's a half-baked idea. If all we want to know is whether the importer can accept only contiguous memory or not, make a flag to do that, and allow the exporter to test this flag. Don't over-engineer this to make it _seem_ like it can do something that it actually totally fails with. As I've already pointed out, there's a major problem if you have already had a less restrictive attachment which has an active mapping, and a new more restrictive attachment comes along later. It seems from Rob's descriptions that we also need another flag in the importer to indicate whether it wants to have a valid struct page in the scatter list, or whether it (correctly) uses the DMA accessors on the scatter list - so that exporters can reject importers which are buggy. Okay, but flag-based approach also have limitations. Yes, the flag-based approach doesn't let you describe in detail what the importer can accept - which, given the issues that I've raised is a *good* thing. We won't be misleading anyone into thinking that we can do something that's really half-baked, and which we have no present requirement for. This is precisely what Linus talks about when he says don't over- engineer - if we over-engineer this, we end up with something that sort-of works, and that's a bad thing. The Keep It Simple approach here makes total sense - what are our current requirements - to be able to say that an importer can only accept: - contiguous memory rather than a scatterlist - scatterlists with struct page pointers Does solving that need us to compare all the constraints of each and every importer, possibly ending up with constraints which can't be satisfied? No. Does the flag approach satisfy the requirements? Yes. So, for basic constraint-sharing, we'll just go with the flag based approach, with a flag (best place for it is still dev-dma_params I suppose) for denoting contiguous or scatterlist. Is that agreed, then? Also, with this idea, of course, there won't be any helpers for trying to calculate constraints; it would be totally the exporter's responsibility to handle it via the attach() dma_buf_op if it wishes to. What's wrong with the proposed max_segment_count? Many media devices do have a limited max_segment_count and that should be taken into account. So what happens if you have a dma_buf exporter, and several dma_buf importers. One dma_buf importer attaches to the exporter, and asks for the buffer, and starts making use of the buffer. This export has many scatterlist segments. Another dma_buf importer attaches to the same buffer, and now asks for the buffer, but the number of scatterlist segments exceeds it requirement. So, in the midst of all the various directions this discussion has taken, I seem to have missed to reiterate the base premise for this suggestion [1] - that we can use this information to help implement a deferred allocation logic - so that all the importers can attach first, and the exporter can do the actual allocation on the first map() call. This is also inline with the prescribed usage of dma_buf_attach() / dma_buf_map_attachment() sequence - ideally speaking, all participating 'importers' of dma_buf should only attach first, and then map() at a 'later' time, which is usually right before using the buffer actually. Note: at present, both DRI and V4L subsystems don't do that; while proposing this RFC I had deliberately kept that separate, as it is a related but orthogonal problem to solve. I guess I should address that in parallel. You can't reallocate the buffer because it's in-use by another importer. There is no way to revoke the buffer from the other importer. So there is no way to satisfy this importer's requirements. You're right; but in a deferred allocation mechanism, this constraint-sharing can atleast help decide on the most restrictive allocation at the time of first map() ,and if later, an importer with more relaxed constraints attaches, it can still use the same buffer. A more restrictive importer would still be not allowed, but in that case the exporter can disallow that importer from attaching, and a feedback to userspace is possible. What I'm showing is that the idea
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: Thu Jun 4 04:00:17 CEST 2015 git branch: test git hash: c1c3c85ddf60a6d97c122d57d385b4929fcec4b3 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: 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.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK 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-i686: WARNINGS linux-4.1-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: WARNINGS linux-4.1-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Hauppauge WinTV-HVR2205 driver feedback
The board has multiple chips, each of which are detected and configured as part of the driver loading. saa7164 This chip requires firmware which appears to load correctly at 20.240637 si2168 This chip requires firmware The chip is detected and loaded but the chip version is not identified, so the firmware load does not occur. As this is a dual tuner card, there are 2 of these chips. si2157 this is the actual tuner chip, again there are 2 chips on the card, and it does not need to load any firmware. The firmware version already in the chip is reported at 165512.480559 and 165518.024867 both of the si21xx chips don't get the firmware loaded until the tuner is accessed by an application, so the card appears to be loading correctly, but will not tune. See my other post for a workaround. I'm sure one of the developers will provide a more elegant/correct solution soon. Regards Peter On 04/06/2015 12:38 pm, Stephen Allan wrote: Hi, Just thought I'd clarify that in my case I haven't ever used this board with Windows. See a more detailed dmesg output below for saa7168 and si21xx messages. From what I am seeing the firmware is loading correctly. However I may be wrong. dmesg | grep 'saa7164\|si21' [ 18.112439] saa7164 driver loaded [ 18.113429] CORE saa7164[0]: subsystem: 0070:f120, board: Hauppauge WinTV-HVR2205 [card=13,autodetected] [ 18.113435] saa7164[0]/0: found at :03:00.0, rev: 129, irq: 16, latency: 0, mmio: 0xf780 [ 18.113470] saa7164 :03:00.0: irq 46 for MSI/MSI-X [ 18.270310] saa7164_downloadfirmware() no first image [ 18.270322] saa7164_downloadfirmware() Waiting for firmware upload (NXP7164-2010-03-10.1.fw) [ 20.240635] saa7164_downloadfirmware() firmware read 4019072 bytes. [ 20.240637] saa7164_downloadfirmware() firmware loaded. [ 20.240642] saa7164_downloadfirmware() SecBootLoader.FileSize = 4019072 [ 20.240648] saa7164_downloadfirmware() FirmwareSize = 0x1fd6 [ 20.240649] saa7164_downloadfirmware() BSLSize = 0x0 [ 20.240650] saa7164_downloadfirmware() Reserved = 0x0 [ 20.240650] saa7164_downloadfirmware() Version = 0x1661c00 [ 27.096269] saa7164_downloadimage() Image downloaded, booting... [ 27.200300] saa7164_downloadimage() Image booted successfully. [ 29.936962] saa7164_downloadimage() Image downloaded, booting... [ 31.705407] saa7164_downloadimage() Image booted successfully. [ 31.750358] saa7164[0]: Hauppauge eeprom: model=151609 [ 31.776446] si2168 22-0064: Silicon Labs Si2168 successfully attached [ 31.781307] si2157 20-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 31.781695] DVB: registering new adapter (saa7164) [ 31.781698] saa7164 :03:00.0: DVB: registering adapter 4 frontend 0 (Silicon Labs Si2168)... [ 31.782652] si2168 22-0066: Silicon Labs Si2168 successfully attached [ 31.785961] si2157 21-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 31.786340] DVB: registering new adapter (saa7164) [ 31.786342] saa7164 :03:00.0: DVB: registering adapter 5 frontend 0 (Silicon Labs Si2168)... [ 31.786562] saa7164[0]: registered device video1 [mpeg] [ 32.021659] saa7164[0]: registered device video2 [mpeg] [ 32.238336] saa7164[0]: registered device vbi0 [vbi] [ 32.238389] saa7164[0]: registered device vbi1 [vbi] [165512.436662] si2168 22-0066: unknown chip version Si2168- [165512.450315] si2157 21-0060: found a 'Silicon Labs Si2157-A30' [165512.480559] si2157 21-0060: firmware version: 3.0.5 [165517.981155] si2168 22-0064: unknown chip version Si2168- [165517.994620] si2157 20-0060: found a 'Silicon Labs Si2157-A30' [165518.024867] si2157 20-0060: firmware version: 3.0.5 [165682.334171] si2168 22-0064: unknown chip version Si2168- [165730.579085] si2168 22-0064: unknown chip version Si2168- [165838.420693] si2168 22-0064: unknown chip version Si2168- [166337.342437] si2168 22-0064: unknown chip version Si2168- [167305.393572] si2168 22-0064: unknown chip version Si2168- [170762.907071] si2168 22-0064: unknown chip version Si2168- -Original Message- From: Antti Palosaari [mailto:cr...@iki.fi] Sent: Wednesday, June 3, 2015 6:03 PM To: Stephen Allan; linux-media@vger.kernel.org Subject: Re: Hauppauge WinTV-HVR2205 driver feedback On 06/03/2015 10:55 AM, Antti Palosaari wrote: On 06/03/2015 06:55 AM, Stephen Allan wrote: I am aware that there is some development going on for the saa7164 driver to support the Hauppauge WinTV-HVR2205. I thought I would post some feedback. I have recently compiled the driver as at 2015-05-31 using media build tree. I am unable to tune a channel. When running the following w_scan command: w_scan -a4 -ft -cAU -t 3 -X /tmp/tzap/channels.conf I get the following error after scanning the frequency range for Australia. ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! At the same time I get the following messages being logged to the Linux console. dmesg [165512.436662]
Re: [PATCH] ts2020: Allow stats polling to be suppressed
On 03/06/15 12:35, David Howells wrote: Statistics polling can not be done by lmedm04 driver's implementation of M88RS2000/TS2020 because I2C messages stop the device's demuxer, so allow polling for statistics to be suppressed in the ts2020 driver by setting dont_poll in the ts2020_config struct. Hi David As expected the lmedm04 driver needs this patch along with another patch to enable it for the driver which I will post shortly. Otherwise everything is working fine on Antti's ts2020 branch Regards Malcolm -- 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 1/2] media: new media controller API for device resource support
Em Wed, 03 Jun 2015 09:12:53 -0600
Shuah Khan shua...@osg.samsung.com escreveu:
Add new media controller API to allocate media device as a
device resource. When a media device is created on the main
struct device which is the parent device for the interface
device, it will be available to all drivers associated with
that interface. For example, if a usb media device driver
creates the media device on the main struct device which is
common for all the drivers that control the media device,
including the non-media ALSA driver, media controller API
can be used to share access to the resources on the media
device. This new interface provides the above described
feature. A second interface that finds and returns the media
device is added to allow drivers to find the media device
created by any of the drivers associated with the device.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/media-device.c | 33 +
include/media/media-device.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 7b39440..a4d5b24 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -462,3 +462,36 @@ void media_device_unregister_entity(struct media_entity
*entity)
entity-parent = NULL;
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity);
+
+static void media_device_release_devres(struct device *dev, void *res)
+{
+}
+
+/*
+ * media_device_get_devres() - get media device as device resource
+ * creates if one doesn't exist
+*/
+struct media_device *media_device_get_devres(struct device *dev)
+{
+ struct media_device *mdev;
+
+ mdev = devres_find(dev, media_device_release_devres, NULL, NULL);
+ if (mdev)
+ return mdev;
+
+ mdev = devres_alloc(media_device_release_devres,
+ sizeof(struct media_device), GFP_KERNEL);
+ if (!mdev)
+ return NULL;
+ return devres_get(dev, mdev, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(media_device_get_devres);
+
+/*
+ * media_device_find_devres() - find media device as device resource
+*/
+struct media_device *media_device_find_devres(struct device *dev)
+{
+ return devres_find(dev, media_device_release_devres, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(media_device_find_devres);
diff --git a/include/media/media-device.h b/include/media/media-device.h
index 6e6db78..22792cd 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -95,6 +95,8 @@ void media_device_unregister(struct media_device *mdev);
int __must_check media_device_register_entity(struct media_device *mdev,
struct media_entity *entity);
void media_device_unregister_entity(struct media_entity *entity);
+struct media_device *media_device_get_devres(struct device *dev);
+struct media_device *media_device_find_devres(struct device *dev);
Hmm... what happens if the Kernel is compiled without MC controller
support?
I think that the best would be to add a #ifdef at the header file and
provide an alternate dummy method to avoid the need of testing for it
everywhere.
/* Iterate over all entities. */
#define media_device_for_each_entity(entity, mdev) \
--
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 1/2] media: new media controller API for device resource support
On 06/03/2015 11:42 AM, Mauro Carvalho Chehab wrote:
Em Wed, 03 Jun 2015 09:12:53 -0600
Shuah Khan shua...@osg.samsung.com escreveu:
Add new media controller API to allocate media device as a
device resource. When a media device is created on the main
struct device which is the parent device for the interface
device, it will be available to all drivers associated with
that interface. For example, if a usb media device driver
creates the media device on the main struct device which is
common for all the drivers that control the media device,
including the non-media ALSA driver, media controller API
can be used to share access to the resources on the media
device. This new interface provides the above described
feature. A second interface that finds and returns the media
device is added to allow drivers to find the media device
created by any of the drivers associated with the device.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/media-device.c | 33 +
include/media/media-device.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 7b39440..a4d5b24 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -462,3 +462,36 @@ void media_device_unregister_entity(struct media_entity
*entity)
entity-parent = NULL;
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity);
+
+static void media_device_release_devres(struct device *dev, void *res)
+{
+}
+
+/*
+ * media_device_get_devres() - get media device as device resource
+ * creates if one doesn't exist
+*/
+struct media_device *media_device_get_devres(struct device *dev)
+{
+struct media_device *mdev;
+
+mdev = devres_find(dev, media_device_release_devres, NULL, NULL);
+if (mdev)
+return mdev;
+
+mdev = devres_alloc(media_device_release_devres,
+sizeof(struct media_device), GFP_KERNEL);
+if (!mdev)
+return NULL;
+return devres_get(dev, mdev, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(media_device_get_devres);
+
+/*
+ * media_device_find_devres() - find media device as device resource
+*/
+struct media_device *media_device_find_devres(struct device *dev)
+{
+return devres_find(dev, media_device_release_devres, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(media_device_find_devres);
diff --git a/include/media/media-device.h b/include/media/media-device.h
index 6e6db78..22792cd 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -95,6 +95,8 @@ void media_device_unregister(struct media_device *mdev);
int __must_check media_device_register_entity(struct media_device *mdev,
struct media_entity *entity);
void media_device_unregister_entity(struct media_entity *entity);
+struct media_device *media_device_get_devres(struct device *dev);
+struct media_device *media_device_find_devres(struct device *dev);
Hmm... what happens if the Kernel is compiled without MC controller
support?
Yeah. I noticed media controller api users have the code in ifdef
CONFIG_MEDIA_CONTROLLER.
I think that the best would be to add a #ifdef at the header file and
provide an alternate dummy method to avoid the need of testing for it
everywhere.
I agree with you that a better way to do it would be defining media
controller api in ifdef CONFIG_MEDIA_CONTROLLER and provide stubs for
else case, similar to what I did in sound/usb/media.c
I followed the existing code to add new interfaces. Do you want to see
all media controller interfaces in ifdef clause with stubs or just the
two new interfaces I added? Or is this something that should be done as
a separate change to catch all media controller interfaces?
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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
