Re: Driver/module in kernel fault. Anyone expert to help me? Siano ID 187f:0600
Ok, many thanks.
I used this guide:
http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
and Ubuntu 14.04.1 LTS with kernel version 3.13.0-44.generic.
I'm not afraid using the terminal if you want to help me :-)
Regards
Francesco
2015-01-15 2:27 GMT+01:00 Roberto Alcântara :
> Ok Francesco, just to confirm that buffer is empty.
>
> Well I'm not expert but seems the driver has some bug on state
> machine. I do not know details about Siano state machine for DVB but
> MSG_SMS_DAB_CHANNEL seems not be the right message expected. I will
> try to look deeply on this code.
>
> Are you able to test driver last version from linux-media tree? What
> kernel are you using?
>
> As I can't test DVB system here I only can suppose some scenario (some
> of them just a try) and do some blind patch for your tests.
>
> Mauro Chehab surely know a lot more about this, but as he do not sent
> message on this thread I suppose he is really busy.
>
> Cheers,
> - Roberto
>
>
>
>
>
>
>
>
> - Roberto
>
>
> On Wed, Jan 14, 2015 at 4:23 PM, Francesco Other
> wrote:
>> Hi Roberto,
>>
>> It doesn't record anything, the file is blank (0 bytes) :-(
>>
>> $ dd if=/dev/dvb/adapter0/dvr0 of=test.ts
>>
>> 0+0 records in
>> 0+0 records out
>> 0 bytes (0 B) copied, 13,4642 s, 0,0 kB/s
>>
>> Francesco
>>
>>
>> 2015-01-14 16:58 GMT+01:00 Roberto Alcântara :
>>> Francesco,
>>>
>>> Seems very strange not work once you have lock (1f) and ber 0. not a
>>> real problem signal report.
>>>
>>> After tzap -r open another console and:
>>>
>>> dd if=/dev/dvb/adapter0/dvr0 of=test.ts
>>>
>>> Wait 10 seconds and stop it. Please check file size (try to open on
>>> vlc too if big enough...).
>>>
>>> Cheers,
>>> - Roberto
>>>
>>> On Tue, Jan 13, 2015 at 6:56 PM, Francesco Other
>>> wrote:
So, this is the output for tzap with the NOT-working-device:
$ tzap -r -c ~/.tzap/channels.conf Italia1
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/home/ionic/.tzap/channels.conf'
Version: 5.10 FE_CAN { DVB-T }
tuning to 69800 Hz
video pid 0x0654, audio pid 0x0655
status 00 | signal | snr | ber | unc |
status 1f | signal | snr 0104 | ber | unc |
FE_HAS_LOCK
status 1f | signal | snr 0104 | ber | unc |
FE_HAS_LOCK
status 1f | signal | snr 0104 | ber | unc |
FE_HAS_LOCK
status 1f | signal | snr 0104 | ber | unc |
FE_HAS_LOCK
status 1f | signal | snr 0104 | ber | unc |
FE_HAS_LOCK
status 1f | signal | snr 010e | ber | unc |
FE_HAS_LOCK
status 1f | signal | snr 0104 | ber | unc |
FE_HAS_LOCK
status 1f | signal | snr 010e | ber | unc |
FE_HAS_LOCK
status 1f | signal | snr 0104 | ber | unc |
FE_HAS_LOCK
>>>
>>>
>>>
>>>
>>> - Roberto
--
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: [3/5, media] pwc-if: fix build warning when !CONFIG_USB_PWC_INPUT_EVDEV
Hi,
On 02-10-14 01:10, Luis Henriques wrote:
Label err_video_unreg in function usb_pwc_probe() is only used when
CONFIG_USB_PWC_INPUT_EVDEV is defined.
drivers/media/usb/pwc/pwc-if.c:1104:1: warning: label 'err_video_unreg' defined
but not used [-Wunused-label]
Signed-off-by: Luis Henriques
Sorry for the slow reaction, I somehow missed this patch and just found it in my
patchwork TODO.
I understand what you're trying to achieve here, but NAK to the implementation,
this is breaking the code flow wrt error handling, making it much harder
to double check that everything is being cleaned up properly.
Regards,
Hans
---
drivers/media/usb/pwc/pwc-if.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
index 15b754da4a2c..e6b7e63b0b8e 100644
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -1078,7 +1078,8 @@ static int usb_pwc_probe(struct usb_interface *intf,
const struct usb_device_id
pdev->button_dev = input_allocate_device();
if (!pdev->button_dev) {
rc = -ENOMEM;
- goto err_video_unreg;
+ video_unregister_device(&pdev->vdev);
+ goto err_unregister_v4l2_dev;
}
usb_make_path(udev, pdev->button_phys, sizeof(pdev->button_phys));
@@ -1095,14 +1096,13 @@ static int usb_pwc_probe(struct usb_interface *intf,
const struct usb_device_id
if (rc) {
input_free_device(pdev->button_dev);
pdev->button_dev = NULL;
- goto err_video_unreg;
+ video_unregister_device(&pdev->vdev);
+ goto err_unregister_v4l2_dev;
}
#endif
return 0;
-err_video_unreg:
- video_unregister_device(&pdev->vdev);
err_unregister_v4l2_dev:
v4l2_device_unregister(&pdev->v4l2_dev);
err_free_controls:
--
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
[PULL patches for 3.20]: New gspca touptek driver, gspca fixes and sunxi-cir driver improvments
Hi Mauro, Note this pull-req superseeds my previous pull-req for 3.20 . Please pull from my tree for a new gspca touptek driver, various gspca fixes and some sunxi-cir driver improvments. The following changes since commit 99f3cd52aee21091ce62442285a68873e3be833f: [media] vb2-vmalloc: Protect DMA-specific code by #ifdef CONFIG_HAS_DMA (2014-12-23 16:28:09 -0200) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.20 for you to fetch changes up to e6a734195e2fbd9386aa58fe8931dd30c013f23e: gspca: Fix underflow in vidioc_s_parm() (2015-01-15 11:46:17 +0100) Antonio Ospite (1): gspca_stv06xx: enable button found on some Quickcam Express variant Hans Verkuil (1): pwc: fix WARN_ON Hans de Goede (3): rc: sunxi-cir: Add support for an optional reset controller rc: sunxi-cir: Add support for the larger fifo found on sun5i and sun6i gspca: Fix underflow in vidioc_s_parm() Joe Howse (1): gspca: Add high-speed modes for PS3 Eye camera John McMaster (1): gspca_touptek: Add support for ToupTek UCMOS series USB cameras .../devicetree/bindings/media/sunxi-ir.txt | 4 +- drivers/media/rc/sunxi-cir.c | 46 +- drivers/media/usb/gspca/Kconfig| 10 + drivers/media/usb/gspca/Makefile | 2 + drivers/media/usb/gspca/gspca.c| 2 +- drivers/media/usb/gspca/ov534.c| 10 +- drivers/media/usb/gspca/stv06xx/stv06xx.c | 4 +- drivers/media/usb/gspca/touptek.c | 732 + drivers/media/usb/pwc/pwc-if.c | 12 +- 9 files changed, 800 insertions(+), 22 deletions(-) create mode 100644 drivers/media/usb/gspca/touptek.c Thanks & Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] gspca: Add high-speed modes for PS3 Eye camera
Hi,
On 04-01-15 16:29, Antonio Ospite wrote:
On Mon, 29 Dec 2014 11:00:03 -0400
Joe Howse wrote:
Add support in the PS3 Eye driver for QVGA capture at higher
frame rates: 187, 150, and 137 FPS. This functionality is valuable
because the PS3 Eye is popular for computer vision projects and no
other camera in its price range supports such high frame rates.
Correct a QVGA mode that was listed as 40 FPS. It is really 37 FPS
(half of 75 FPS).
Tests confirm that the nominal frame rates are achieved.
Signed-off-by: Joe Howse
Tested-by: Antonio Ospite
Joe, thanks for the patch, Antonio, thanks for testing, I've queued
this up in my gspca tree for merging into the 3.20 kernel
Regards,
Hans
Thanks Joe.
I noticed that qv4l2 displays max 60fps even though from the video I can
perceive the higher framerate, and same happens in guvcview.
gst-inspect-1.0 won't even let me set framerates higher than 75 so
I didn't test with GStreamer.
I know that the camera is also able to stream raw Bayer data which
requires less bandwidth than the default YUYV, although the driver does
not currently expose that; maybe some higher framerates can be achieved
also at VGA with Bayer output.
In case you wanted to explore that remember to set supported framerates
appropriately in ov772x_framerates for the 4 combinations of formats and
resolutions (i.e. Bayer outputs will support more framerates).
Ciao,
Antonio
---
drivers/media/usb/gspca/ov534.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/gspca/ov534.c b/drivers/media/usb/gspca/ov534.c
index 90f0d63..a9c866d 100644
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -12,6 +12,8 @@
* PS3 Eye camera enhanced by Richard Kaswy http://kaswy.free.fr
* PS3 Eye camera - brightness, contrast, awb, agc, aec controls
* added by Max Thrun
+ * PS3 Eye camera - FPS range extended by Joseph Howse
+ * http://nummist.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -116,7 +118,7 @@ static const struct v4l2_pix_format ov767x_mode[] = {
.colorspace = V4L2_COLORSPACE_JPEG},
};
-static const u8 qvga_rates[] = {125, 100, 75, 60, 50, 40, 30};
+static const u8 qvga_rates[] = {187, 150, 137, 125, 100, 75, 60, 50, 37, 30};
static const u8 vga_rates[] = {60, 50, 40, 30, 15};
static const struct framerates ov772x_framerates[] = {
@@ -769,12 +771,16 @@ static void set_frame_rate(struct gspca_dev *gspca_dev)
{15, 0x03, 0x41, 0x04},
};
static const struct rate_s rate_1[] = { /* 320x240 */
+/* {205, 0x01, 0xc1, 0x02}, * 205 FPS: video is partly corrupt */
+ {187, 0x01, 0x81, 0x02}, /* 187 FPS or below: video is valid */
+ {150, 0x01, 0xc1, 0x04},
+ {137, 0x02, 0xc1, 0x02},
{125, 0x02, 0x81, 0x02},
{100, 0x02, 0xc1, 0x04},
{75, 0x03, 0xc1, 0x04},
{60, 0x04, 0xc1, 0x04},
{50, 0x02, 0x41, 0x04},
- {40, 0x03, 0x41, 0x04},
+ {37, 0x03, 0x41, 0x04},
{30, 0x04, 0x41, 0x04},
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] gspca_stv06xx: enable button found on some Quickcam Express variant
Hi, On 06-01-15 21:59, Antonio Ospite wrote: On Tue, 28 Oct 2014 15:39:41 +0100 Antonio Ospite wrote: On Mon, 14 Jul 2014 12:27:57 +0200 Hans de Goede wrote: Hi, On 07/11/2014 02:56 PM, Antonio Ospite wrote: Signed-off-by: Antonio Ospite Thanks, I've added this to my tree and send a pull-req for it to Mauro. Hi Hans, I still don't see the change in 3.18-rc2, maybe it got lost. Here is the patchwork link in case you want to pick the change for 3.19: https://patchwork.linuxtv.org/patch/24732/ Ping. Still missing in 3.19-rc3. Yes, weird, I had it in a pull-req for 3.17: http://git.linuxtv.org/cgit.cgi/hgoede/gspca.git/log/?h=media-for_v3.17 Anyways I've queued it up for 3.20 now. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] [media] gspca: underflow in vidioc_s_parm()
Hi, On 07-01-15 12:04, Dan Carpenter wrote: "n" is a user controlled integer. The code here doesn't handle the case where "n" is negative and this causes a static checker warning. drivers/media/usb/gspca/gspca.c:1571 vidioc_s_parm() warn: no lower bound on 'n' Signed-off-by: Dan Carpenter --- I haven't followed through to see if this is a real problem. Thanks for the report, it is a real problem, but since parm->parm.capture.readbuffers is unsigned I've chosen to fix it by making n unsigned too instead. Regards, Hans diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c index 43d6505..27f7da1 100644 --- a/drivers/media/usb/gspca/gspca.c +++ b/drivers/media/usb/gspca/gspca.c @@ -1565,6 +1565,8 @@ static int vidioc_s_parm(struct file *filp, void *priv, int n; n = parm->parm.capture.readbuffers; + if (n < 0) + return -EINVAL; if (n == 0 || n >= GSPCA_MAX_FRAMES) parm->parm.capture.readbuffers = gspca_dev->nbufread; else -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] dvb-core: add template code for i2c binding model
Moikka,
thank you for the comment.
On 2015年01月14日 03:54, Antti Palosaari wrote:
>> --- a/drivers/media/dvb-core/dvb_frontend.h
>> +++ b/drivers/media/dvb-core/dvb_frontend.h
>> @@ -415,6 +415,7 @@ struct dtv_frontend_properties {
>> struct dvb_frontend {
>> struct dvb_frontend_ops ops;
>> struct dvb_adapter *dvb;
>> +struct i2c_client *fe_cl;
>
> IMHO that is ugly as hell. You should not add any hardware/driver things
> to DVB frontend, even more bad this adds I2C dependency to DVB frontend,
> how about some other busses... DVB frontend is *logical* entity
> representing the DVB device to system. All hardware specific things
> belongs to drivers - not the frontend at all.
Currently, the i2c_client pointer is distributed/copied among
each demod drivers plus adapter drivers,
so I thought it would be better to unify them into one place,
but since there seems to be no good (common) place to store it,
I'll consider your advice and remove this fe_cl member.
Regards,
akihiro
--
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/RFC v10 03/19] DT: leds: Add led-sources property
On 12/01/15 18:06, Mark Brown wrote:
> On Mon, Jan 12, 2015 at 10:55:29AM -0600, Rob Herring wrote:
>> > On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski
>>> > > There are however devices that don't fall into this category, i.e. they
>>> > > have many outputs, that can be connected to a single LED or to many LEDs
>>> > > and the driver has to know what is the actual arrangement.
>> >
>> > We may need to extend the regulator binding slightly and allow for
>> > multiple phandles on a supply property, but wouldn't something like
>> > this work:
>> > led-supply = <&led-reg0>, <&led-reg1>, <&led-reg2>, <&led-reg3>;
>> > The shared source is already supported by the regulator binding.
>
> What is the reasoning for this? If a single supply is being supplied by
> multiple regulators then in general those regulators will all know about
> each other at a hardware level and so from a functional and software
> point of view will effectively be one regulator. If they don't/aren't
> then they tend to interfere with each other.
For LED current regulators like this one [1] we want to be able to
communicate to the software the hardware wiring, e.g. if a single LED is
connected to only one or both the current regulators. The device needs
to be programmed differently for each configuration, as shown on page 36
of the datasheet [2].
Now, the LED DT binding describes the LEDs (current consumers) as child
nodes of the LED driver IC (current supplier), e.g. (from [3]):
pca9632@62 {
compatible = "nxp,pca9632";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x62>;
red@0 {
label = "red";
reg = <0>;
linux,default-trigger = "none";
};
green@1 {
label = "green";
reg = <1>;
linux,default-trigger = "none";
};
...
};
What is missing in this binding is the ability to tell that a single LED
is connected to more than one current source.
We could, for example adopt the multiple phandle in the supply property
scheme, but not use the kernel regulator API, e.g.
flash-led {
compatible = "maxim,max77387";
current-reg1 { // FLED1
led-output-id = <0>;
};
current-reg2 { // FLED2
led-output-id = <1>;
};
red_led {
led-supply = <¤t-reg1>, <¤t-reg2>;
};
};
However my feeling is that it is unnecessarily complicated that way.
Perhaps we could use the 'reg' property to describe actual connections,
I'm not sure if it's better than a LED specific property, e.g.
max77387@52 {
compatible = "nxp,max77387";
#address-cells = <2>;
#size-cells = <0>;
reg = <0x52>;
flash_led {
reg = <1 1>;
...
};
};
[1] http://www.maximintegrated.com/en/products/power/led-drivers/MAX77387.html
[2] http://datasheets.maximintegrated.com/en/ds/MAX77387.pdf
[3] Documentation/devicetree/bindings/leds/pca963x.txt
--
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/RFC v10 03/19] DT: leds: Add led-sources property
On Tue, Jan 13, 2015 at 2:42 AM, Jacek Anaszewski wrote: > On 01/12/2015 05:55 PM, Rob Herring wrote: >> >> Adding Mark B and Liam... >> >> On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski >> wrote: >>> >>> On 01/12/2015 02:52 PM, Rob Herring wrote: On Mon, Jan 12, 2015 at 2:32 AM, Jacek Anaszewski wrote: > > On 01/09/2015 07:33 PM, Rob Herring wrote: >> >> On Fri, Jan 9, 2015 at 9:22 AM, Jacek Anaszewski >> wrote: >>> >>> Add a property for defining the device outputs the LED >>> represented by the DT child node is connected to. >> >> >> [...] >> >>> b/Documentation/devicetree/bindings/leds/common.txt >>> index a2c3f7a..29295bf 100644 >>> --- a/Documentation/devicetree/bindings/leds/common.txt >>> +++ b/Documentation/devicetree/bindings/leds/common.txt >>> @@ -1,6 +1,10 @@ >>> Common leds properties. >>> >>> Optional properties for child nodes: >>> +- led-sources : Array of bits signifying the LED current regulator >>> outputs the >>> + LED represented by the child node is connected to (1 >>> - >>> the LED >>> + is connected to the output, 0 - the LED isn't >>> connected >>> to the >>> + output). >> >> >> >> >> Sorry, I just don't understand this. > > > > > In some Flash LED devices one LED can be connected to one or more > electric current outputs, which allows for multiplying the maximum > current allowed for the LED. Each sub-LED is represented by a child > node in the DT binding of the Flash LED device and it needs to declare > which outputs it is connected to. In the example below the led-sources > property is a two element array, which means that the flash LED device > has two current outputs, and the bits signify if the LED is connected > to the output. Sounds like a regulator for which we already have bindings for and we have a driver for regulator based LEDs (but no binding for it). >>> >>> >>> >>> Do you think of drivers/leds/leds-regulator.c driver? This driver just >>> allows for registering an arbitrary regulator device as a LED subsystem >>> device. >>> >>> There are however devices that don't fall into this category, i.e. they >>> have many outputs, that can be connected to a single LED or to many LEDs >>> and the driver has to know what is the actual arrangement. >> >> >> We may need to extend the regulator binding slightly and allow for >> multiple phandles on a supply property, but wouldn't something like >> this work: >> >> led-supply = <&led-reg0>, <&led-reg1>, <&led-reg2>, <&led-reg3>; >> >> The shared source is already supported by the regulator binding. > > > I think that we shouldn't split the LED devices into power supply > providers and consumers as in case of generic regulators. From this > point of view a LED device current output is a provider and a discrete > LED element is a consumer. In this approach each discrete LED element > should have a related driver which is not how LED devices are being > handled in the LED subsystem, where there is a single binding for a LED > device and there is a single driver for it which creates separate LED > class devices for each LED connected to the LED device output. Each > discrete LED is represented by a child node in the LED device binding. > > I am aware that it may be tempting to treat LED devices as common > regulators, but they have their specific features which gave a > reason for introducing LED class for them. Besides, there is already > drivers/leds/leds-regulator.c driver for LED devices which support only > turning on/off and setting brightness level. > > In your proposition a separate regulator provider binding would have > to be created for each current output and a separate binding for > each discrete LED connected to the LED device. It would create > unnecessary noise in a dts file. > > Moreover, using regulator binding implies that we want to treat it > as a sheer power supply for our device (which would be a discrete LED > element in this case), whereas LED devices provide more features like > blinking pattern and for flash LED devices - flash timeout, external > strobe and flash faults. Okay, fair enough. Please include some of this explanation in the binding description. I do still have some concerns about led-sources and whether it can support other scenarios. It is very much tied to the parent node. Are there any cases where we don't want the LEDs to be sub nodes? Perhaps the LEDs are on a separate daughterboard from the driver/supply and we can have different drivers. It's a stretch maybe. Or are there cases where you need more information than just the connection? Rob -- 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/majordom
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
On Thu, Jan 15, 2015 at 6:33 AM, Sylwester Nawrocki
wrote:
> On 12/01/15 18:06, Mark Brown wrote:
>> On Mon, Jan 12, 2015 at 10:55:29AM -0600, Rob Herring wrote:
>>> > On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski
> > There are however devices that don't fall into this category, i.e. they
> > have many outputs, that can be connected to a single LED or to many
> > LEDs
> > and the driver has to know what is the actual arrangement.
>>> >
>>> > We may need to extend the regulator binding slightly and allow for
>>> > multiple phandles on a supply property, but wouldn't something like
>>> > this work:
>>> > led-supply = <&led-reg0>, <&led-reg1>, <&led-reg2>, <&led-reg3>;
>>> > The shared source is already supported by the regulator binding.
>>
>> What is the reasoning for this? If a single supply is being supplied by
>> multiple regulators then in general those regulators will all know about
>> each other at a hardware level and so from a functional and software
>> point of view will effectively be one regulator. If they don't/aren't
>> then they tend to interfere with each other.
>
> For LED current regulators like this one [1] we want to be able to
> communicate to the software the hardware wiring, e.g. if a single LED is
> connected to only one or both the current regulators. The device needs
> to be programmed differently for each configuration, as shown on page 36
> of the datasheet [2].
>
> Now, the LED DT binding describes the LEDs (current consumers) as child
> nodes of the LED driver IC (current supplier), e.g. (from [3]):
>
> pca9632@62 {
> compatible = "nxp,pca9632";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x62>;
>
> red@0 {
> label = "red";
> reg = <0>;
This only works if you don't have sub blocks or different functions to
describe. I suppose you could add yet another level of nodes. This
feels like abuse of the reg property even though to use the reg
property is a frequent review comment.
OTOH, we don't need 2 ways to describe this.
> linux,default-trigger = "none";
> };
> green@1 {
> label = "green";
> reg = <1>;
> linux,default-trigger = "none";
> };
> ...
> };
>
> What is missing in this binding is the ability to tell that a single LED
> is connected to more than one current source.
>
> We could, for example adopt the multiple phandle in the supply property
> scheme, but not use the kernel regulator API, e.g.
>
> flash-led {
> compatible = "maxim,max77387";
>
> current-reg1 { // FLED1
> led-output-id = <0>;
> };
>
> current-reg2 { // FLED2
> led-output-id = <1>;
> };
>
> red_led {
> led-supply = <¤t-reg1>, <¤t-reg2>;
> };
> };
>
> However my feeling is that it is unnecessarily complicated that way.
This example is not so complicated, but I already agreed on not using
regulators on the basis there are other properties of the driver
unique to LEDs.
> Perhaps we could use the 'reg' property to describe actual connections,
> I'm not sure if it's better than a LED specific property, e.g.
>
> max77387@52 {
> compatible = "nxp,max77387";
> #address-cells = <2>;
> #size-cells = <0>;
> reg = <0x52>;
>
> flash_led {
> reg = <1 1>;
Don't you mean <0 1> as the values are the "address" which in this
case are the LED driver output indexes.
Rob
> ...
> };
> };
>
> [1] http://www.maximintegrated.com/en/products/power/led-drivers/MAX77387.html
> [2] http://datasheets.maximintegrated.com/en/ds/MAX77387.pdf
> [3] Documentation/devicetree/bindings/leds/pca963x.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] ARM: at91: dts: sama5d3: add dt support for atmel isi and ov2640 sensor
Le 04/01/2015 10:02, Josh Wu a écrit :
> This patch series add ISI and ov2640 support on dts files.
>
> As the ov2640 driver dt is still in review. The patch is in:
> https://patchwork.linuxtv.org/patch/27554/
> So I want to send this dt patch early for a review.
>
> v1 -> v2:
> 1. add one more patch to change the pin name of ISI_MCK
> 2. rewrite the commit [4/8] ARM: at91: dts: sama5d3: change name of
> pinctrl_isi_{power,reset}.
> 3. move the common chip parts of ISI node to sama5d3.dtsi.
>
> Bo Shen (3):
> ARM: at91: dts: sama5d3: split isi pinctrl
> ARM: at91: dts: sama5d3: add missing pins of isi
> ARM: at91: dts: sama5d3: move the isi mck pin to mb
>
> Josh Wu (5):
> ARM: at91: dts: sama5d3: add isi clock
> ARM: at91: dts: sama5d3: change name of pinctrl_isi_{power,reset}
> ARM: at91: dts: sama5d3: change name of pinctrl of ISI_MCK
> ARM: at91: dts: sama5d3: add ov2640 camera sensor support
> ARM: at91: sama5: enable atmel-isi and ov2640 in defconfig
The whole series:
Acked-by: Nicolas Ferre
stacked on top of at91-3.20-dt.
The defconfig update on his side on at91-3.20-defconfig
Bye,
> arch/arm/boot/dts/sama5d3.dtsi| 24 ++-
> arch/arm/boot/dts/sama5d3xmb.dtsi | 40
> +++
> arch/arm/configs/sama5_defconfig | 6 ++
> 3 files changed, 61 insertions(+), 9 deletions(-)
>
--
Nicolas Ferre
--
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/RFC v10 03/19] DT: leds: Add led-sources property
On Thu, Jan 15, 2015 at 08:24:26AM -0600, Rob Herring wrote: > On Tue, Jan 13, 2015 at 2:42 AM, Jacek Anaszewski > > I am aware that it may be tempting to treat LED devices as common > > regulators, but they have their specific features which gave a > > reason for introducing LED class for them. Besides, there is already > > drivers/leds/leds-regulator.c driver for LED devices which support only > > turning on/off and setting brightness level. > > > > In your proposition a separate regulator provider binding would have > > to be created for each current output and a separate binding for > > each discrete LED connected to the LED device. It would create > > unnecessary noise in a dts file. > > > > Moreover, using regulator binding implies that we want to treat it > > as a sheer power supply for our device (which would be a discrete LED > > element in this case), whereas LED devices provide more features like > > blinking pattern and for flash LED devices - flash timeout, external > > strobe and flash faults. > Okay, fair enough. Please include some of this explanation in the > binding description. Right, the other thing here is that these chips are not normally designed with the goal that the various components be used separately - I've seen devices where the startup and shutdown procedures involve interleaved actions to the boost regulator and current sink for example. Trying to insert an abstraction layer typically just makes life more complex. signature.asc Description: Digital signature
Re: [PATCH] cx23885/vb2 regression: please test this patch
Hi Hans, On Tue, 2015-01-13 at 17:59 +0100, Jurgen Kramer wrote: > Hi Hans, > On Tue, 2015-01-13 at 15:01 +0100, Hans Verkuil wrote: > > Hi Raimonds, Jurgen, > > > > Can you both test this patch? It should (I hope) solve the problems you > > both had with the cx23885 driver. > > > > This patch fixes a race condition in the vb2_thread that occurs when > > the thread is stopped. The crucial fix is calling kthread_stop much > > earlier in vb2_thread_stop(). But I also made the vb2_thread more > > robust. > > Thanks. Will test your patch and report back. I have tested the patch, unfortunately results are not positive. With the patch MythTV has issues with the tuners. Live TV no longer works and eventually mythbackend hangs. Reverting the patch brings everything back to a working state. Regards, Jurgen > > > -- > 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: [RFC PATCH] [media] coda: Use S_PARM to set nominal framerate for h.264 encoder
Le 2015-01-15 11:23, Frédéric Sureau a écrit : Maybe a->parm.output.capability should be set to |V4L2_CAP_TIMEPERFRAME| here. I think it is required by GStreamer V4L2 plugin. Looking at this, I think output device is indeed the right place to set this, and the capability should indeed be updated. Now for the GStreamer side, it will need patching. At the moment, this cap is only checked for capture device. It's not a major change to enabled that for output device with that capability. cheers, Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] [media] coda: Use S_PARM to set nominal framerate for h.264 encoder
Hi Philipp,
Le 22/12/2014 17:00, Philipp Zabel a écrit :
The encoder needs to know the nominal framerate for the constant bitrate
control mechanism to work. Currently the only way to set the framerate is
by using VIDIOC_S_PARM on the output queue.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda/coda-common.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 39330a7..63eb510 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -803,6 +803,32 @@ static int coda_decoder_cmd(struct file *file, void *fh,
return 0;
}
+static int coda_g_parm(struct file *file, void *fh, struct v4l2_streamparm *a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(fh);
+
+ a->parm.output.timeperframe.denominator = 1;
+ a->parm.output.timeperframe.numerator = ctx->params.framerate;
+
Maybe a->parm.output.capability should be set to V4L2_CAP_TIMEPERFRAME here.
I think it is required by GStreamer V4L2 plugin.
+ return 0;
+}
+
+static int coda_s_parm(struct file *file, void *fh, struct v4l2_streamparm *a)
+{
+ struct coda_ctx *ctx = fh_to_ctx(fh);
+
+ if (a->type == V4L2_BUF_TYPE_VIDEO_OUTPUT &&
+ a->parm.output.timeperframe.numerator != 0) {
+ ctx->params.framerate = a->parm.output.timeperframe.denominator
+ / a->parm.output.timeperframe.numerator;
+ }
+
+ a->parm.output.timeperframe.denominator = 1;
+ a->parm.output.timeperframe.numerator = ctx->params.framerate;
+
+ return 0;
+}
+
static int coda_subscribe_event(struct v4l2_fh *fh,
const struct v4l2_event_subscription *sub)
{
@@ -843,6 +869,9 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
.vidioc_try_decoder_cmd = coda_try_decoder_cmd,
.vidioc_decoder_cmd = coda_decoder_cmd,
+ .vidioc_g_parm = coda_g_parm,
+ .vidioc_s_parm = coda_s_parm,
+
.vidioc_subscribe_event = coda_subscribe_event,
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
Thanks for the patch!
Fred
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors
On 14/01/15 18:14, Baluta, Teodora wrote: > On Vi, 2014-12-26 at 11:13 +, Jonathan Cameron wrote: >> On 18/12/14 16:51, Lars-Peter Clausen wrote: >>> Adding V4L folks to Cc for more input. >> >> Thanks Lars - we definitely would need the v4l guys to agree to a driver like >> this going in IIO. (not that I'm convinced it should!) >> >>> On 12/08/2014 03:10 PM, Baluta, Teodora wrote: Hello, On Vi, 2014-12-05 at 02:15 +, Jonathan Cameron wrote: > On 04/12/14 13:00, Teodora Baluta wrote: >> This patchset adds support for fingerprint sensors through the IIO >> interface. >> This way userspace applications collect information in a uniform way. All >> processing would be done in the upper layers as suggested in [0]. >> >> In order to test out this proposal, a minimal implementation for UPEK's >> TouchChip Fingerprint Sensor via USB is also available. Although there >> is an >> existing implementation in userspace for USB fingerprint devices, >> including this >> particular device, the driver represents a proof of concept of how >> fingerprint >> sensors could be integrated in the IIO framework regardless of the used >> bus. For >> lower power requirements, the SPI bus is preferred and a kernel driver >> implementation makes more sense. > > So why not v4l? These are effectively image sensors.. Well, here's why I don't think v4l would be the best option: - an image scanner could be implemented in the v4l subsystem, but it seems far more complicated for a simple fingerprint scanner - it usually has drivers for webcams, TVs or video streaming devices. The v4l subsystem (with all its support for colorspace, decoders, image compression, frame control) seems a bit of an overkill for a very straightforward fingerprint imaging sensor. > >> Whilst those are there, I would doubt the irrelevant bits would put much >> burden on a fingerprint scanning driver. Been a while since I did >> anything in that area though so I could be wrong! IMO V4L is much better fit for this kind of devices than IIO. You can use just a subset of the API, it shouldn't take much effort to write a simple v4l2 capture driver, supporting fixed (probably vendor/chip specific) image format. I'm not sure if it's better to use the v4l2 controls [1], define a new v4l2 controls class for the fingerprint scanner processing features, rather than trying to pass raw data to user space and interpret it then in some library. I know there has been resistance to allowing passing unknown binary blobs to user space, due to possible abuses. [1] Documentation/video4linux/v4l2-controls.txt - a fingerprint device could also send out a processed information, not just the image of a fingerprint. This means that the processing is done in hardware - the UPEK TouchStrip chipset in libfprint has this behavior (see [0]). So, the IIO framework would support a uniform way of handling fingerprint devices that either do processing in software or in hardware. You can use the v4l2 controls API for that, which also supports events. The controls could be made read only. It would be interesting to list what kind of features these could be. >> This is more interesting, but does that map well to IIO style >> channels anyway? If not we are going to end up with a whole new >> interface which ever subsystem is used for the image side of things. The way I see it now, for processed fingerprint information, an IIO device could have an IIO_FINGERPRINT channel with a modifier and only the sensitivity threshold attribute set. We would also need two triggers: one for enrollment and one for the verification mode to control the device from a userspace application. This could be all well handled with the v4l2 controls, for instance see what features are available in the Camera Flash controls subset http://linuxtv.org/downloads/v4l-dvb-apis/extended-controls.html#flash-controls >> Sure - what you proposed would work. The question is whether it is >> the best way to do it. > > Any thoughts on this from the v4l community? I would try it with V4L2, it seems to me most suitable subsystem for such devices to me. The question is what ends up in the kernel and what in user space. Anyway IMO V4L2 API is quite flexible with regards to that, due to wide range of devices it needs to cover. [0] http://www.freedesktop.org/wiki/Software/fprint/libfprint/upekts/ >> A sysfs trigger is enabled and the device starts scanning. As soon as an >> image >> is available it is written in the character device /dev/iio:deviceX. >> >> Userspace applications will be able to calculate the expected image size >> using >> the fingerprint attributes height, width and bit depth. Other attributes >> introduced for the fingerprint channel in IIO represent information that
[PATCH 3/3] bttv: Improve TEA575x support
Improve g_tuner and add s_hw_freq_seek and enum_freq_bands support for cards
with TEA575x radio.
This allows signal/stereo detection and HW seek to work on these cards.
Signed-off-by: Ondrej Zary
---
drivers/media/pci/bt8xx/bttv-driver.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index e7f8ade..5476a7d 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -2515,6 +2515,8 @@ static int bttv_querycap(struct file *file, void *priv,
if (btv->has_saa6588)
cap->device_caps |= V4L2_CAP_READWRITE |
V4L2_CAP_RDS_CAPTURE;
+ if (btv->has_tea575x)
+ cap->device_caps |= V4L2_CAP_HW_FREQ_SEEK;
}
return 0;
}
@@ -3244,6 +3246,9 @@ static int radio_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *t)
if (btv->audio_mode_gpio)
btv->audio_mode_gpio(btv, t, 0);
+ if (btv->has_tea575x)
+ return snd_tea575x_g_tuner(&btv->tea, t);
+
return 0;
}
@@ -3261,6 +3266,30 @@ static int radio_s_tuner(struct file *file, void *priv,
return 0;
}
+static int radio_s_hw_freq_seek(struct file *file, void *priv,
+ const struct v4l2_hw_freq_seek *a)
+{
+ struct bttv_fh *fh = priv;
+ struct bttv *btv = fh->btv;
+
+ if (btv->has_tea575x)
+ return snd_tea575x_s_hw_freq_seek(file, &btv->tea, a);
+ else
+ return -ENOTTY;
+}
+
+static int radio_enum_freq_bands(struct file *file, void *priv,
+struct v4l2_frequency_band *band)
+{
+ struct bttv_fh *fh = priv;
+ struct bttv *btv = fh->btv;
+
+ if (btv->has_tea575x)
+ return snd_tea575x_enum_freq_bands(&btv->tea, band);
+ else
+ return -ENOTTY;
+}
+
static ssize_t radio_read(struct file *file, char __user *data,
size_t count, loff_t *ppos)
{
@@ -3318,6 +3347,8 @@ static const struct v4l2_ioctl_ops radio_ioctl_ops = {
.vidioc_s_tuner = radio_s_tuner,
.vidioc_g_frequency = bttv_g_frequency,
.vidioc_s_frequency = bttv_s_frequency,
+ .vidioc_s_hw_freq_seek = radio_s_hw_freq_seek,
+ .vidioc_enum_freq_bands = radio_enum_freq_bands,
.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] bttv: Convert to generic TEA575x interface
Remove tea575x-specific code from bttv and use the common driver instead.
Only set_frequency is implemented (signal/stereo detection or seek would
require more changes to bttv).
It works fine on Video Highway Xtreme (it actually makes the radio usable as
it currently cannot be tuned properly).
Miro/Pinnacle is untested but seems to be simple and should work.
However, I don't understand the Terratec Active Radio Upgrade code. The HW
seems to need IOR, IOW and CSEL signals that were taken from ISA bus on
older cards (IOR and IOW directly and CSEL from some address decoder) and
are emulated here using GPIOs. But the code manipulating these signals in
bttv seems to be broken - it never asserts the IOR signal. If anyone has
this HW, please test if I got that right.
Signed-off-by: Ondrej Zary
---
drivers/media/pci/bt8xx/Kconfig |3 +
drivers/media/pci/bt8xx/bttv-cards.c | 317 -
drivers/media/pci/bt8xx/bttv-driver.c |6 +-
drivers/media/pci/bt8xx/bttvp.h | 14 +-
4 files changed, 125 insertions(+), 215 deletions(-)
diff --git a/drivers/media/pci/bt8xx/Kconfig b/drivers/media/pci/bt8xx/Kconfig
index 496cf6b..4a93f6d 100644
--- a/drivers/media/pci/bt8xx/Kconfig
+++ b/drivers/media/pci/bt8xx/Kconfig
@@ -4,12 +4,15 @@ config VIDEO_BT848
select I2C_ALGOBIT
select VIDEOBUF_DMA_SG
depends on RC_CORE
+ depends on MEDIA_RADIO_SUPPORT
select VIDEO_TUNER
select VIDEO_TVEEPROM
select VIDEO_MSP3400 if MEDIA_SUBDRV_AUTOSELECT
select VIDEO_TVAUDIO if MEDIA_SUBDRV_AUTOSELECT
select VIDEO_TDA7432 if MEDIA_SUBDRV_AUTOSELECT
select VIDEO_SAA6588 if MEDIA_SUBDRV_AUTOSELECT
+ select RADIO_ADAPTERS
+ select RADIO_TEA575X
---help---
Support for BT848 based frame grabber/overlay boards. This includes
the Miro, Hauppauge and STB boards. Please read the material in
diff --git a/drivers/media/pci/bt8xx/bttv-cards.c
b/drivers/media/pci/bt8xx/bttv-cards.c
index c518677..4654fb6 100644
--- a/drivers/media/pci/bt8xx/bttv-cards.c
+++ b/drivers/media/pci/bt8xx/bttv-cards.c
@@ -84,8 +84,7 @@ static void gv800s_init(struct bttv *btv);
static void td3116_muxsel(struct bttv *btv, unsigned int input);
static int terratec_active_radio_upgrade(struct bttv *btv);
-static int tea5757_read(struct bttv *btv);
-static int tea5757_write(struct bttv *btv, int value);
+static int tea575x_init(struct bttv *btv);
static void identify_by_eeprom(struct bttv *btv,
unsigned char eeprom_data[256]);
static int pvr_boot(struct bttv *btv);
@@ -3085,12 +3084,12 @@ static void miro_pinnacle_gpio(struct bttv *btv)
if (0 == (gpio & 0x20)) {
btv->has_radio = 1;
if (!miro_fmtuner[id]) {
- btv->has_matchbox = 1;
- btv->mbox_we= (1<<6);
- btv->mbox_most = (1<<7);
- btv->mbox_clk = (1<<8);
- btv->mbox_data = (1<<9);
- btv->mbox_mask = (1<<6)|(1<<7)|(1<<8)|(1<<9);
+ btv->has_tea575x = 1;
+ btv->tea_gpio.wren = 6;
+ btv->tea_gpio.most = 7;
+ btv->tea_gpio.clk = 8;
+ btv->tea_gpio.data = 9;
+ tea575x_init(btv);
}
} else {
btv->has_radio = 0;
@@ -3104,7 +3103,7 @@ static void miro_pinnacle_gpio(struct bttv *btv)
pr_info("%d: miro: id=%d tuner=%d radio=%s stereo=%s\n",
btv->c.nr, id+1, btv->tuner_type,
!btv->has_radio ? "no" :
- (btv->has_matchbox ? "matchbox" : "fmtuner"),
+ (btv->has_tea575x ? "tea575x" : "fmtuner"),
(-1 == msp) ? "no" : "yes");
} else {
/* new cards with microtune tuner */
@@ -3382,12 +3381,12 @@ void bttv_init_card2(struct bttv *btv)
break;
case BTTV_BOARD_VHX:
btv->has_radio= 1;
- btv->has_matchbox = 1;
- btv->mbox_we = 0x20;
- btv->mbox_most= 0;
- btv->mbox_clk = 0x08;
- btv->mbox_data= 0x10;
- btv->mbox_mask= 0x38;
+ btv->has_tea575x = 1;
+ btv->tea_gpio.wren = 5;
+ btv->tea_gpio.most = 6;
+ btv->tea_gpio.clk = 3;
+ btv->tea_gpio.data = 4;
+ tea575x_init(btv);
break;
case BTTV_BOARD_VOBIS_BOOSTAR:
case BTTV_BOARD_TERRATV:
@@ -3745,33 +3744,112 @@ static void hauppauge_eeprom(struct bttv *btv)
btv->radio_uses_msp_demodulator
[PATCH 2/3] tea575x: split and export functions
Split ioctl interface from enum_freq_bands, g_tuner and s_hw_freq_seek
functions and export them to be used in other drivers like bttv.
Signed-off-by: Ondrej Zary
---
drivers/media/radio/tea575x.c | 41 -
include/media/tea575x.h |5 +
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/media/radio/tea575x.c b/drivers/media/radio/tea575x.c
index f1a0867..43d1ea5 100644
--- a/drivers/media/radio/tea575x.c
+++ b/drivers/media/radio/tea575x.c
@@ -247,10 +247,9 @@ static int vidioc_querycap(struct file *file, void *priv,
return 0;
}
-static int vidioc_enum_freq_bands(struct file *file, void *priv,
-struct v4l2_frequency_band *band)
+int snd_tea575x_enum_freq_bands(struct snd_tea575x *tea,
+ struct v4l2_frequency_band *band)
{
- struct snd_tea575x *tea = video_drvdata(file);
int index;
if (band->tuner != 0)
@@ -279,18 +278,25 @@ static int vidioc_enum_freq_bands(struct file *file, void
*priv,
return 0;
}
+EXPORT_SYMBOL(snd_tea575x_enum_freq_bands);
-static int vidioc_g_tuner(struct file *file, void *priv,
- struct v4l2_tuner *v)
+static int vidioc_enum_freq_bands(struct file *file, void *priv,
+struct v4l2_frequency_band *band)
{
struct snd_tea575x *tea = video_drvdata(file);
+
+ return snd_tea575x_enum_freq_bands(tea, band);
+}
+
+int snd_tea575x_g_tuner(struct snd_tea575x *tea, struct v4l2_tuner *v)
+{
struct v4l2_frequency_band band_fm = { 0, };
if (v->index > 0)
return -EINVAL;
snd_tea575x_read(tea);
- vidioc_enum_freq_bands(file, priv, &band_fm);
+ snd_tea575x_enum_freq_bands(tea, &band_fm);
memset(v, 0, sizeof(*v));
strlcpy(v->name, tea->has_am ? "FM/AM" : "FM", sizeof(v->name));
@@ -304,6 +310,15 @@ static int vidioc_g_tuner(struct file *file, void *priv,
v->signal = tea->tuned ? 0x : 0;
return 0;
}
+EXPORT_SYMBOL(snd_tea575x_g_tuner);
+
+static int vidioc_g_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct snd_tea575x *tea = video_drvdata(file);
+
+ return snd_tea575x_g_tuner(tea, v);
+}
static int vidioc_s_tuner(struct file *file, void *priv,
const struct v4l2_tuner *v)
@@ -356,10 +371,9 @@ static int vidioc_s_frequency(struct file *file, void
*priv,
return 0;
}
-static int vidioc_s_hw_freq_seek(struct file *file, void *fh,
- const struct v4l2_hw_freq_seek *a)
+int snd_tea575x_s_hw_freq_seek(struct file *file, struct snd_tea575x *tea,
+ const struct v4l2_hw_freq_seek *a)
{
- struct snd_tea575x *tea = video_drvdata(file);
unsigned long timeout;
int i, spacing;
@@ -442,6 +456,15 @@ static int vidioc_s_hw_freq_seek(struct file *file, void
*fh,
snd_tea575x_set_freq(tea);
return -ENODATA;
}
+EXPORT_SYMBOL(snd_tea575x_s_hw_freq_seek);
+
+static int vidioc_s_hw_freq_seek(struct file *file, void *fh,
+ const struct v4l2_hw_freq_seek *a)
+{
+ struct snd_tea575x *tea = video_drvdata(file);
+
+ return snd_tea575x_s_hw_freq_seek(file, tea, a);
+}
static int tea575x_s_ctrl(struct v4l2_ctrl *ctrl)
{
diff --git a/include/media/tea575x.h b/include/media/tea575x.h
index 2d4fa59..5d09657 100644
--- a/include/media/tea575x.h
+++ b/include/media/tea575x.h
@@ -71,6 +71,11 @@ struct snd_tea575x {
int (*ext_init)(struct snd_tea575x *tea);
};
+int snd_tea575x_enum_freq_bands(struct snd_tea575x *tea,
+ struct v4l2_frequency_band *band);
+int snd_tea575x_g_tuner(struct snd_tea575x *tea, struct v4l2_tuner *v);
+int snd_tea575x_s_hw_freq_seek(struct file *file, struct snd_tea575x *tea,
+ const struct v4l2_hw_freq_seek *a);
int snd_tea575x_hw_init(struct snd_tea575x *tea);
int snd_tea575x_init(struct snd_tea575x *tea, struct module *owner);
void snd_tea575x_exit(struct snd_tea575x *tea);
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
Hi!
> Perhaps we could use the 'reg' property to describe actual connections,
> I'm not sure if it's better than a LED specific property, e.g.
>
> max77387@52 {
> compatible = "nxp,max77387";
> #address-cells = <2>;
> #size-cells = <0>;
> reg = <0x52>;
>
> flash_led {
> reg = <1 1>;
> ...
> };
> };
Normally, reg property is , if I understand things
correctly? Would that be enough here, or would we be doing list of
outputs?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
[PATCH] media: i2c: add support for omnivision's ov2659 sensor
From: Benoit Parrot
this patch adds support for omnivision's ov2659
sensor.
Signed-off-by: Benoit Parrot
Signed-off-by: Lad, Prabhakar
---
.../devicetree/bindings/media/i2c/ov2659.txt | 33 +
.../devicetree/bindings/vendor-prefixes.txt|1 +
MAINTAINERS| 10 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov2659.c | 1623
include/media/ov2659.h | 33 +
7 files changed, 1712 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2659.txt
create mode 100644 drivers/media/i2c/ov2659.c
create mode 100644 include/media/ov2659.h
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2659.txt
b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
new file mode 100644
index 000..fc49f44
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
@@ -0,0 +1,33 @@
+* OV2659 1/5-Inch 2Mp SOC Camera
+
+The OV2659 is a 1/5-inch SOC camera, with an active array size of 1632H x
1212V.
+It is programmable through a SCCB.
+
+Required Properties:
+- compatible: Must be "ovt,ov2659"
+
+- reg: I2C slave address
+
+- clock-frequency: Input clock frequency.
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ov2659@30 {
+ compatible = "ovt,ov2659";
+ reg = <0x30>;
+
+ port {
+ ov2659_0: endpoint {
+ clock-frequency = <1200>;
+ remote-endpoint = <&vpfe_ep>;
+ };
+ };
+ };
+ ...
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index b1df0ad..153cd92 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -118,6 +118,7 @@ nvidia NVIDIA
nxpNXP Semiconductors
onnn ON Semiconductor Corp.
opencores OpenCores.org
+ovtOmniVision Technologies
panasonic Panasonic Corporation
pericomPericom Technology Inc.
phytec PHYTEC Messtechnik GmbH
diff --git a/MAINTAINERS b/MAINTAINERS
index 4318f34..fa62c91 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8754,6 +8754,16 @@ T: git
git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
S: Maintained
F: drivers/media/platform/am437x/
+OV2659 OMNIVISION SENSOR DRIVER
+M: Lad, Prabhakar
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
+S: Maintained
+F: drivers/media/i2c/ov2659.c
+F: include/media/ov2659.h
+
SIS 190 ETHERNET DRIVER
M: Francois Romieu
L: net...@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index ca84543..47f5042 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -465,6 +465,17 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+config VIDEO_OV2659
+ tristate "OmniVision OV2659 sensor support"
+ depends on VIDEO_V4L2 && I2C
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2659 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2659.
+
config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..f165fae 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_VIDEO_SMIAPP_PLL)+= smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
+obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
new file mode 100644
index 000..ce8ec8d
--- /dev/null
+++ b/drivers/media/i2c/ov2659.c
@@ -0,0 +1,1623 @@
+/*
+ * Omnivision OV2659 CMOS Image Sensor driver
+ *
+ * Copyright (C) 2015 Texas Instruments, Inc.
+ *
+ * Benoit Parrot
+ * Lad, Prabhakar
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Jan 16 04:00:14 CET 2015 git branch: test git hash: 99f3cd52aee21091ce62442285a68873e3be833f gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK 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: 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: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK linux-3.18-i686: OK linux-3.19-rc4-i686: OK 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: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16-x86_64: ERRORS linux-3.17-x86_64: ERRORS linux-3.18-x86_64: ERRORS linux-3.19-rc4-x86_64: ERRORS apps: OK spec-git: OK sparse: ERRORS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
