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: Sat Dec 27 04:00:08 CET 2014 git branch: test git hash: cb9564e133f4f790920d715714790512085bb2e3 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.17-3.slh.2-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: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16-i686: ERRORS linux-3.17-i686: ERRORS linux-3.18-i686: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.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 apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653
On Fri, Dec 26, 2014 at 2:33 PM, Pavel Machek wrote:
> Hi!
>
>> > We are moving to device tree support on OMAP3, but that currently
>> > breaks ADP1653 driver. This adds device tree support, plus required
>> > documentation.
>> >
>> > Signed-off-by: Pavel Machek
>> >
>> > ---
>> >
>> > Changed -microsec to -us, as requested by devicetree people.
>> >
>> > Fixed checkpatch issues.
>> >
>> > diff --git a/Documentation/devicetree/bindings/leds/common.txt
>> > b/Documentation/devicetree/bindings/leds/common.txt
>> > index 2d88816..2c6c7c5 100644
>> > --- a/Documentation/devicetree/bindings/leds/common.txt
>> > +++ b/Documentation/devicetree/bindings/leds/common.txt
>> > @@ -14,6 +14,15 @@ Optional properties for child nodes:
>> > "ide-disk" - LED indicates disk activity
>> > "timer" - LED flashes at a fixed, configurable rate
>> >
>> > +- max-microamp : maximum intensity in microamperes of the LED
>> > +(torch LED for flash devices)
>> > +- flash-max-microamp : maximum intensity in microamperes of the
>> > + flash LED; it is mandatory if the LED should
>> > + support the flash mode
>> > +- flash-timeout-microsec : timeout in microseconds after which the flash
>> > + LED is turned off
>>
>> Doesn't all this go in your flash led binding patch?
>
> No, I should not have included this part.
>
>> > +Example:
>> > +
>> > +adp1653: led-controller@30 {
>> > +compatible = "adi,adp1653";
>> > + reg = <0x30>;
>> > +gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
>> > +
>> > + flash {
>> > +flash-timeout-us = <50>;
>> > +flash-max-microamp = <32>;
>> > +max-microamp = <5>;
>> > + };
>> > +indicator {
>>
>> These are different LEDs or different modes?
>
> flash & indicator are different LEDs. One is white, one is red. Flash
> can be used as a flash and as a torch.
>
>> > +max-microamp = <17500>;
>>
>> This is a bit inconsistent. The binding says this is for flash LEDs
>> torch mode, but I see no reason why it can't be common. Can you update
>> the binding doc to be clear here.
>
> By inconsisnent, you mean you want patch below?
Yes.
>> Also, aren't you missing label properties?
>
> label is optional, and as my driver does not yet use it, I forgot
> about it.
Based on your node names, there are obviously user defined functions
for them already. So they should have labels whether or not the driver
uses them.
Rob
> Signed-off-by: Pavel Machek
>
> index 2c6c7c5..92d4dac 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -15,7 +15,6 @@ Optional properties for child nodes:
> "timer" - LED flashes at a fixed, configurable rate
>
> - max-microamp : maximum intensity in microamperes of the LED
> -(torch LED for flash devices)
> - flash-max-microamp : maximum intensity in microamperes of the
> flash LED; it is mandatory if the LED should
>support the flash mode
>
>
> --
> (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
Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653
Hi!
> > We are moving to device tree support on OMAP3, but that currently
> > breaks ADP1653 driver. This adds device tree support, plus required
> > documentation.
> >
> > Signed-off-by: Pavel Machek
> >
> > ---
> >
> > Changed -microsec to -us, as requested by devicetree people.
> >
> > Fixed checkpatch issues.
> >
> > diff --git a/Documentation/devicetree/bindings/leds/common.txt
> > b/Documentation/devicetree/bindings/leds/common.txt
> > index 2d88816..2c6c7c5 100644
> > --- a/Documentation/devicetree/bindings/leds/common.txt
> > +++ b/Documentation/devicetree/bindings/leds/common.txt
> > @@ -14,6 +14,15 @@ Optional properties for child nodes:
> > "ide-disk" - LED indicates disk activity
> > "timer" - LED flashes at a fixed, configurable rate
> >
> > +- max-microamp : maximum intensity in microamperes of the LED
> > +(torch LED for flash devices)
> > +- flash-max-microamp : maximum intensity in microamperes of the
> > + flash LED; it is mandatory if the LED should
> > + support the flash mode
> > +- flash-timeout-microsec : timeout in microseconds after which the flash
> > + LED is turned off
>
> Doesn't all this go in your flash led binding patch?
No, I should not have included this part.
> > +Example:
> > +
> > +adp1653: led-controller@30 {
> > +compatible = "adi,adp1653";
> > + reg = <0x30>;
> > +gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> > +
> > + flash {
> > +flash-timeout-us = <50>;
> > +flash-max-microamp = <32>;
> > +max-microamp = <5>;
> > + };
> > +indicator {
>
> These are different LEDs or different modes?
flash & indicator are different LEDs. One is white, one is red. Flash
can be used as a flash and as a torch.
> > +max-microamp = <17500>;
>
> This is a bit inconsistent. The binding says this is for flash LEDs
> torch mode, but I see no reason why it can't be common. Can you update
> the binding doc to be clear here.
By inconsisnent, you mean you want patch below?
> Also, aren't you missing label properties?
label is optional, and as my driver does not yet use it, I forgot
about it.
Signed-off-by: Pavel Machek
index 2c6c7c5..92d4dac 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -15,7 +15,6 @@ Optional properties for child nodes:
"timer" - LED flashes at a fixed, configurable rate
- max-microamp : maximum intensity in microamperes of the LED
-(torch LED for flash devices)
- flash-max-microamp : maximum intensity in microamperes of the
flash LED; it is mandatory if the LED should
support the flash mode
--
(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
Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653
On Wed, Dec 24, 2014 at 4:34 PM, Pavel Machek wrote:
>
> We are moving to device tree support on OMAP3, but that currently
> breaks ADP1653 driver. This adds device tree support, plus required
> documentation.
>
> Signed-off-by: Pavel Machek
>
> ---
>
> Changed -microsec to -us, as requested by devicetree people.
>
> Fixed checkpatch issues.
>
> diff --git a/Documentation/devicetree/bindings/leds/common.txt
> b/Documentation/devicetree/bindings/leds/common.txt
> index 2d88816..2c6c7c5 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -14,6 +14,15 @@ Optional properties for child nodes:
> "ide-disk" - LED indicates disk activity
> "timer" - LED flashes at a fixed, configurable rate
>
> +- max-microamp : maximum intensity in microamperes of the LED
> +(torch LED for flash devices)
> +- flash-max-microamp : maximum intensity in microamperes of the
> + flash LED; it is mandatory if the LED should
> + support the flash mode
> +- flash-timeout-microsec : timeout in microseconds after which the flash
> + LED is turned off
Doesn't all this go in your flash led binding patch?
> +
> +
> Examples:
>
> system-status {
> @@ -21,3 +30,10 @@ system-status {
> linux,default-trigger = "heartbeat";
> ...
> };
> +
> +camera-flash {
> + label = "Flash";
> + max-microamp = <5>;
> + flash-max-microamp = <32>;
> + flash-timeout-microsec = <50>;
> +}
> diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
> b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
> new file mode 100644
> index 000..3c7065f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
> @@ -0,0 +1,38 @@
> +* Analog Devices ADP1653 flash LED driver
> +
> +Required Properties:
> +
> + - compatible: Must contain one of the following
> +- "adi,adp1653"
> +
> + - reg: I2C slave address
> +
> + - gpios: References to the GPIO that controls the power for the chip.
> +
> +There are two led outputs available - flash and indicator. One led is
> +represented by one child node, nodes need to be named "flash" and
> "indicator".
> +
> +Required properties of the LED child node:
> +- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> +
> +Required properties of the flash LED child node:
> +
> +- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> +- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
> +
> +Example:
> +
> +adp1653: led-controller@30 {
> +compatible = "adi,adp1653";
> + reg = <0x30>;
> +gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> +
> + flash {
> +flash-timeout-us = <50>;
> +flash-max-microamp = <32>;
> +max-microamp = <5>;
> + };
> +indicator {
These are different LEDs or different modes?
> +max-microamp = <17500>;
This is a bit inconsistent. The binding says this is for flash LEDs
torch mode, but I see no reason why it can't be common. Can you update
the binding doc to be clear here.
Also, aren't you missing label properties?
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/majordomo-info.html
[PATCH 2/27] [media] au0828: Use setup_timer
Convert a call to init_timer and accompanying intializations of the timer's data and function fields to a call to setup_timer. A simplified version of the semantic match that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression t,f,d; @@ -t.function = f; -t.data = d; -init_timer(&t); +setup_timer(&t,f,d); // Signed-off-by: Julia Lawall --- drivers/media/usb/au0828/au0828-video.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c index 5f337b1..0b24791 100644 --- a/drivers/media/usb/au0828/au0828-video.c +++ b/drivers/media/usb/au0828/au0828-video.c @@ -2043,13 +2043,10 @@ int au0828_analog_register(struct au0828_dev *dev, INIT_LIST_HEAD(&dev->vbiq.active); INIT_LIST_HEAD(&dev->vbiq.queued); - dev->vid_timeout.function = au0828_vid_buffer_timeout; - dev->vid_timeout.data = (unsigned long) dev; - init_timer(&dev->vid_timeout); - - dev->vbi_timeout.function = au0828_vbi_buffer_timeout; - dev->vbi_timeout.data = (unsigned long) dev; - init_timer(&dev->vbi_timeout); + setup_timer(&dev->vid_timeout, au0828_vid_buffer_timeout, + (unsigned long)dev); + setup_timer(&dev->vbi_timeout, au0828_vbi_buffer_timeout, + (unsigned long)dev); dev->width = NTSC_STD_W; dev->height = NTSC_STD_H; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/27] [media] pvrusb2: Use setup_timer
Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.
A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
expression t,f,d;
@@
-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
//
Signed-off-by: Julia Lawall
---
drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index 2fd9b5e..08f2f5a 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -2425,22 +2425,18 @@ struct pvr2_hdw *pvr2_hdw_create(struct usb_interface
*intf,
}
if (!hdw) goto fail;
- init_timer(&hdw->quiescent_timer);
- hdw->quiescent_timer.data = (unsigned long)hdw;
- hdw->quiescent_timer.function = pvr2_hdw_quiescent_timeout;
+ setup_timer(&hdw->quiescent_timer, pvr2_hdw_quiescent_timeout,
+ (unsigned long)hdw);
- init_timer(&hdw->decoder_stabilization_timer);
- hdw->decoder_stabilization_timer.data = (unsigned long)hdw;
- hdw->decoder_stabilization_timer.function =
- pvr2_hdw_decoder_stabilization_timeout;
+ setup_timer(&hdw->decoder_stabilization_timer,
+ pvr2_hdw_decoder_stabilization_timeout,
+ (unsigned long)hdw);
- init_timer(&hdw->encoder_wait_timer);
- hdw->encoder_wait_timer.data = (unsigned long)hdw;
- hdw->encoder_wait_timer.function = pvr2_hdw_encoder_wait_timeout;
+ setup_timer(&hdw->encoder_wait_timer, pvr2_hdw_encoder_wait_timeout,
+ (unsigned long)hdw);
- init_timer(&hdw->encoder_run_timer);
- hdw->encoder_run_timer.data = (unsigned long)hdw;
- hdw->encoder_run_timer.function = pvr2_hdw_encoder_run_timeout;
+ setup_timer(&hdw->encoder_run_timer, pvr2_hdw_encoder_run_timeout,
+ (unsigned long)hdw);
hdw->master_state = PVR2_STATE_DEAD;
@@ -3680,10 +3676,8 @@ static int pvr2_send_request_ex(struct pvr2_hdw *hdw,
hdw->ctl_timeout_flag = 0;
hdw->ctl_write_pend_flag = 0;
hdw->ctl_read_pend_flag = 0;
- init_timer(&timer);
+ setup_timer(&timer, pvr2_ctl_timeout, (unsigned long)hdw);
timer.expires = jiffies + timeout;
- timer.data = (unsigned long)hdw;
- timer.function = pvr2_ctl_timeout;
if (write_len) {
hdw->cmd_debug_state = 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 1/27] [media] s2255drv: Use setup_timer
Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.
A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
expression t,f,d;
@@
-init_timer(&t);
+setup_timer(&t,f,d);
-t.function = f;
-t.data = d;
//
Signed-off-by: Julia Lawall
---
drivers/media/usb/s2255/s2255drv.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/usb/s2255/s2255drv.c
b/drivers/media/usb/s2255/s2255drv.c
index de55e96..0f3c34d 100644
--- a/drivers/media/usb/s2255/s2255drv.c
+++ b/drivers/media/usb/s2255/s2255drv.c
@@ -2274,9 +2274,7 @@ static int s2255_probe(struct usb_interface *interface,
dev_err(&interface->dev, "Could not find bulk-in endpoint\n");
goto errorEP;
}
- init_timer(&dev->timer);
- dev->timer.function = s2255_timer;
- dev->timer.data = (unsigned long)dev->fw_data;
+ setup_timer(&dev->timer, s2255_timer, (unsigned long)dev->fw_data);
init_waitqueue_head(&dev->fw_data->wait_fw);
for (i = 0; i < MAX_CHANNELS; i++) {
struct s2255_vc *vc = &dev->vc[i];
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/27] Use setup_timer
These patches group a call to init_timer and initialization of the function and data fields into a call to setup_timer. Is there is no initialization of the data field before add_timer is called, the the data value is set to 0UL. If the data value has a cast to something other than unsigned long, it is changes to a cast to unsigned long, which is the type of the data field. The semantic patch that performs this change is shown below (http://coccinelle.lip6.fr/). This semantic patch is fairly restrictive on what appears between the init_timer call and the two field initializations, to ensure that the there is no code that the initializations depend on. // @@ expression t,d,f,e1,e2; identifier x1,x2; statement S1,S2; @@ ( -t.data = d; | -t.function = f; | -init_timer(&t); +setup_timer(&t,f,d); | -init_timer_on_stack(&t); +setup_timer_on_stack(&t,f,d); ) <... when != S1 t.x1 = e1; ...> ( -t.data = d; | -t.function = f; | -init_timer(&t); +setup_timer(&t,f,d); | -init_timer_on_stack(&t); +setup_timer_on_stack(&t,f,d); ) <... when != S2 t.x2 = e2; ...> ( -t.data = d; | -t.function = f; | -init_timer(&t); +setup_timer(&t,f,d); | -init_timer_on_stack(&t); +setup_timer_on_stack(&t,f,d); ) // -- @@ expression t,d,f,e1,e2; identifier x1,x2; statement S1,S2; @@ ( -t->data = d; | -t->function = f; | -init_timer(t); +setup_timer(t,f,d); | -init_timer_on_stack(t); +setup_timer_on_stack(t,f,d); ) <... when != S1 t->x1 = e1; ...> ( -t->data = d; | -t->function = f; | -init_timer(t); +setup_timer(t,f,d); | -init_timer_on_stack(t); +setup_timer_on_stack(t,f,d); ) <... when != S2 t->x2 = e2; ...> ( -t->data = d; | -t->function = f; | -init_timer(t); +setup_timer(t,f,d); | -init_timer_on_stack(t); +setup_timer_on_stack(t,f,d); ) // - // no initialization of data field @@ expression t,d1,d2,f; @@ ( -init_timer(&t); +setup_timer(&t,f,0UL); | -init_timer_on_stack(&t); +setup_timer_on_stack(&t,f,0UL); ) ... when != t.data = d1; -t.function = f; ... when != t.data = d2; add_timer(&t); @@ expression t,d,f,fn; type T; @@ -t.function = f; ... when != t.data when != fn(...,(T)t,...) ( -init_timer(&t); +setup_timer(&t,f,d); | -init_timer_on_stack(&t); +setup_timer_on_stack(&t,f,0UL); ) ... when != t.data = d; add_timer(&t); // -- @@ expression t,d1,d2,f; @@ ( -init_timer(t); +setup_timer(t,f,0UL); | -init_timer_on_stack(t); +setup_timer_on_stack(t,f,0UL); ) ... when != t->data = d1; -t->function = f; ... when != t->data = d2; add_timer(t); @@ expression t,d,f,fn; type T; @@ -t->function = f; ... when != t.data when != fn(...,(T)t,...) ( -init_timer(t); +setup_timer(t,f,d); | -init_timer_on_stack(t); +setup_timer_on_stack(t,f,0UL); ) ... when != t->data = d; add_timer(t); // - // change data field type @@ expression d; type T; @@ ( setup_timer | setup_timer_on_stack ) (..., ( (unsigned long)d | - (T) + (unsigned long) d ) ) // -- 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 5/27] [media] usbvision: Use setup_timer
Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.
A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
expression t,f,d;
@@
-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
//
The semantic patch also changes the cast to long to a cast to unsigned
long in the data initializer, as unsigned long is the type of the data field.
Signed-off-by: Julia Lawall
---
drivers/media/usb/usbvision/usbvision-core.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/usbvision/usbvision-core.c
b/drivers/media/usb/usbvision/usbvision-core.c
index 302aa07..64c63d3 100644
--- a/drivers/media/usb/usbvision/usbvision-core.c
+++ b/drivers/media/usb/usbvision/usbvision-core.c
@@ -2194,9 +2194,8 @@ static void usbvision_power_off_timer(unsigned long data)
void usbvision_init_power_off_timer(struct usb_usbvision *usbvision)
{
- init_timer(&usbvision->power_off_timer);
- usbvision->power_off_timer.data = (long)usbvision;
- usbvision->power_off_timer.function = usbvision_power_off_timer;
+ setup_timer(&usbvision->power_off_timer, usbvision_power_off_timer,
+ (unsigned long)usbvision);
}
void usbvision_set_power_off_timer(struct usb_usbvision *usbvision)
--
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 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! >> >> - 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. 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. Sure - what you proposed would work. The question is whether it is the best way to do it. >> >> Thanks, >> Teodora >> >> [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 aids in the fingerprint image processing. Besides these, the proposed interface offers userspace a way to read a feedback after a scan (like the swipe was too slow or too fast) through a modified fingerprint_status channel. [0] http://www.spinics.net/lists/linux-iio/msg11463.html Teodora Baluta (3): iio: core: add support for fingerprint devices iio: core: change channel's storagebits/realbits to u32 iio: fingerprint: add fingerprint sensor via USB Documentation/ABI/testing/sysfs-bus-iio | 51 +++ drivers/iio/Kconfig | 1 + drivers/iio/Makefile| 1 + drivers/iio/fingerprint/Kconfig | 15 + drivers/iio/fingerprint/Makefile| 5 + drivers/iio/fingerprint/fp_tc.c | 162 + drivers/iio/fingerprint/fp_tc.h | 22 ++ drivers/iio/fingerprint/fp_tc_usb.c | 618 drivers/iio/fingerprint/fp_tc_usb.h | 144 drivers/iio/industrialio-core.c | 9 + include/linux/iio/iio.h | 11 +- include/linux/iio/types.h | 10 + 12 files changed, 1047 insertions(+), 2 deletions(-) create mode 100644 drivers/iio/fingerprint/Kconfig create mode 100644 drivers/iio/fingerprint/Makefile create mode 100644 drivers/iio/fingerprint/fp_tc.c create mode 100644 drivers/iio/fingerprint/fp_tc.h cre
Re: [RFC/PATCH] dvb-core: add template code for i2c binding model
ping. we don't need this kind of feature in the dvb-core? -- 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
[PATCH] dvb: tc90522: re-add symbol-rate report
From: Akihiro Tsukada symbol-rate report was wrongly removed off by the commit:906aaf5a . Signed-off-by: Akihiro Tsukada --- drivers/media/dvb-frontends/tc90522.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/dvb-frontends/tc90522.c b/drivers/media/dvb-frontends/tc90522.c index a06d6f5..813f2ac 100644 --- a/drivers/media/dvb-frontends/tc90522.c +++ b/drivers/media/dvb-frontends/tc90522.c @@ -202,6 +202,7 @@ static int tc90522s_get_frontend(struct dvb_frontend *fe) c = &fe->dtv_property_cache; c->delivery_system = SYS_ISDBS; + c->symbol_rate = 2886; layers = 0; ret = reg_read(fe, 0xe6, val, 5); -- 2.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/5] media: ov2640: add async probe function
On Fri, 26 Dec 2014, Laurent Pinchart wrote:
> Hi Guennadi,
>
> On Friday 26 December 2014 10:14:26 Guennadi Liakhovetski wrote:
> > On Fri, 26 Dec 2014, Laurent Pinchart wrote:
> > > On Friday 26 December 2014 14:37:14 Josh Wu wrote:
> > >> On 12/25/2014 6:39 AM, Guennadi Liakhovetski wrote:
> > >>> On Mon, 22 Dec 2014, Josh Wu wrote:
> > On 12/20/2014 6:16 AM, Guennadi Liakhovetski wrote:
> > > On Fri, 19 Dec 2014, Josh Wu wrote:
> > >> On 12/19/2014 5:59 AM, Guennadi Liakhovetski wrote:
> > >>> On Thu, 18 Dec 2014, Josh Wu wrote:
> > To support async probe for ov2640, we need remove the code to get
> > 'mclk' in ov2640_probe() function. oterwise, if soc_camera host
> > is not probed in the moment, then we will fail to get 'mclk' and
> > quit the ov2640_probe() function.
> >
> > So in this patch, we move such 'mclk' getting code to
> > ov2640_s_power() function. That make ov2640 survive, as we can
> > pass a NULL (priv-clk) to soc_camera_set_power() function.
> >
> > And if soc_camera host is probed, the when ov2640_s_power() is
> > called, then we can get the 'mclk' and that make us
> > enable/disable soc_camera host's clock as well.
> >
> > Signed-off-by: Josh Wu
> > ---
> > v3 -> v4:
> > v2 -> v3:
> > v1 -> v2:
> > no changes.
> >
> > drivers/media/i2c/soc_camera/ov2640.c | 31 ++---
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/media/i2c/soc_camera/ov2640.c
> > b/drivers/media/i2c/soc_camera/ov2640.c
> > index 1fdce2f..9ee910d 100644
> > --- a/drivers/media/i2c/soc_camera/ov2640.c
> > +++ b/drivers/media/i2c/soc_camera/ov2640.c
> > @@ -739,6 +739,15 @@ static int ov2640_s_power(struct v4l2_subdev
> > *sd, int on)
> > struct i2c_client *client = v4l2_get_subdevdata(sd);
> > struct soc_camera_subdev_desc *ssdd =
> > soc_camera_i2c_to_desc(client);
> > struct ov2640_priv *priv = to_ov2640(client);
> > + struct v4l2_clk *clk;
> > +
> > + if (!priv->clk) {
> > + clk = v4l2_clk_get(&client->dev, "mclk");
> > + if (IS_ERR(clk))
> > + dev_warn(&client->dev, "Cannot get the mclk.
> > maybe soc-camera host is not probed yet.\n");
> > + else
> > + priv->clk = clk;
> > + }
> > return soc_camera_set_power(&client->dev, ssdd, priv
> > ->clk, on);
> > }
> >
> > Just let me explained a little more details at first:
> >
> > As my understanding, current the priv->clk is a v4l2_clk: mclk, which
> > is a wrapper clock in soc_camera.c. it can make soc_camera to call
> > camera host's clock_start() clock_stop(). As in ov2640, the real mck
> > (pck1) is in ov2640 dt node (xvclk). So the camera host's
> > clock_start()/stop() only need to enable/disable his peripheral
> > clock.
> > >>>
> > >>> I'm looking at the ov2640 datasheet. In the block diagram I only see
> > >>> one input clock - the xvclk. Yes, it can be supplied by the camera
> > >>> host controller, in which case it is natural for the camera host
> > >>> driver to own and control it, or it can be a separate clock device -
> > >>> either static or configurable. This is just a note to myself to
> > >>> clarify, that it's one and the same clock pin we're talking about.
> > >>>
> > >>> Now, from the hardware / DT PoV, I think, the DT should look like:
> > >>>
> > >>> a) in the ov2640 I2C DT node we should have a clock consumer entry,
> > >>> linking to a board-specific source.
> > >>
> > >> That's what this patch series do right now.
> > >> In my patch 5/5 DT document said, ov2640 need a clock consumer which
> > >> refer to the xvclk input clock.
> > >> And it is a required property.
> > >>
> > >>> b) if the ov2640 clock is supplied by a camera host, its DT entry
> > >>> should have a clock source subnode, to which ov2640 clock consumer
> > >>> entry should link. The respective camera host driver should then parse
> > >>> that clock subnode and register the respective clock with the V4L2
> > >>> framework, by calling v4l2_clk_register().
> > >>
> > >> Ok, So in this case, I need to wait for the "mclk" in probe of ov2640
> > >> driver. So that I can be compatible for the camera host which provide
> > >> the clock source.
> > >
> > > Talking about mclk and xvclk is quite confusing. There's no mclk from an
> > > ov2640 point of view. The ov2640 driver should call v4l2_clk_get("xvclk").
> >
> > Yes, I also was thinking about this, and yes, requesting a "xvclk" clock
> > would be more logical. But then, as you
Re: [PATCH v4 2/5] media: ov2640: add async probe function
Hi Guennadi,
On Friday 26 December 2014 10:14:26 Guennadi Liakhovetski wrote:
> On Fri, 26 Dec 2014, Laurent Pinchart wrote:
> > On Friday 26 December 2014 14:37:14 Josh Wu wrote:
> >> On 12/25/2014 6:39 AM, Guennadi Liakhovetski wrote:
> >>> On Mon, 22 Dec 2014, Josh Wu wrote:
> On 12/20/2014 6:16 AM, Guennadi Liakhovetski wrote:
> > On Fri, 19 Dec 2014, Josh Wu wrote:
> >> On 12/19/2014 5:59 AM, Guennadi Liakhovetski wrote:
> >>> On Thu, 18 Dec 2014, Josh Wu wrote:
> To support async probe for ov2640, we need remove the code to get
> 'mclk' in ov2640_probe() function. oterwise, if soc_camera host
> is not probed in the moment, then we will fail to get 'mclk' and
> quit the ov2640_probe() function.
>
> So in this patch, we move such 'mclk' getting code to
> ov2640_s_power() function. That make ov2640 survive, as we can
> pass a NULL (priv-clk) to soc_camera_set_power() function.
>
> And if soc_camera host is probed, the when ov2640_s_power() is
> called, then we can get the 'mclk' and that make us
> enable/disable soc_camera host's clock as well.
>
> Signed-off-by: Josh Wu
> ---
> v3 -> v4:
> v2 -> v3:
> v1 -> v2:
> no changes.
>
> drivers/media/i2c/soc_camera/ov2640.c | 31 ++---
> 1 file changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/i2c/soc_camera/ov2640.c
> b/drivers/media/i2c/soc_camera/ov2640.c
> index 1fdce2f..9ee910d 100644
> --- a/drivers/media/i2c/soc_camera/ov2640.c
> +++ b/drivers/media/i2c/soc_camera/ov2640.c
> @@ -739,6 +739,15 @@ static int ov2640_s_power(struct v4l2_subdev
> *sd, int on)
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> struct soc_camera_subdev_desc *ssdd =
> soc_camera_i2c_to_desc(client);
> struct ov2640_priv *priv = to_ov2640(client);
> +struct v4l2_clk *clk;
> +
> +if (!priv->clk) {
> +clk = v4l2_clk_get(&client->dev, "mclk");
> +if (IS_ERR(clk))
> +dev_warn(&client->dev, "Cannot get the mclk.
> maybe soc-camera host is not probed yet.\n");
> +else
> +priv->clk = clk;
> +}
> return soc_camera_set_power(&client->dev, ssdd, priv
> ->clk, on);
> }
>
> Just let me explained a little more details at first:
>
> As my understanding, current the priv->clk is a v4l2_clk: mclk, which
> is a wrapper clock in soc_camera.c. it can make soc_camera to call
> camera host's clock_start() clock_stop(). As in ov2640, the real mck
> (pck1) is in ov2640 dt node (xvclk). So the camera host's
> clock_start()/stop() only need to enable/disable his peripheral
> clock.
> >>>
> >>> I'm looking at the ov2640 datasheet. In the block diagram I only see
> >>> one input clock - the xvclk. Yes, it can be supplied by the camera
> >>> host controller, in which case it is natural for the camera host
> >>> driver to own and control it, or it can be a separate clock device -
> >>> either static or configurable. This is just a note to myself to
> >>> clarify, that it's one and the same clock pin we're talking about.
> >>>
> >>> Now, from the hardware / DT PoV, I think, the DT should look like:
> >>>
> >>> a) in the ov2640 I2C DT node we should have a clock consumer entry,
> >>> linking to a board-specific source.
> >>
> >> That's what this patch series do right now.
> >> In my patch 5/5 DT document said, ov2640 need a clock consumer which
> >> refer to the xvclk input clock.
> >> And it is a required property.
> >>
> >>> b) if the ov2640 clock is supplied by a camera host, its DT entry
> >>> should have a clock source subnode, to which ov2640 clock consumer
> >>> entry should link. The respective camera host driver should then parse
> >>> that clock subnode and register the respective clock with the V4L2
> >>> framework, by calling v4l2_clk_register().
> >>
> >> Ok, So in this case, I need to wait for the "mclk" in probe of ov2640
> >> driver. So that I can be compatible for the camera host which provide
> >> the clock source.
> >
> > Talking about mclk and xvclk is quite confusing. There's no mclk from an
> > ov2640 point of view. The ov2640 driver should call v4l2_clk_get("xvclk").
>
> Yes, I also was thinking about this, and yes, requesting a "xvclk" clock
> would be more logical. But then, as you write below, if we let the
> v4l2_clk wrapper first check for a CCF "xvclk" clock, say, none is found.
> How do we then find the exported "mclk" V4L2 clock? Maybe v4l2_clk_get()
> should use two names?..
Given that v4l2_clk_get() is only used b
Re: [PATCH v7 1/3] of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint
Hi Philipp,
Thank you for the patch.
On Tuesday 23 December 2014 14:09:16 Philipp Zabel wrote:
> Decrementing the reference count of the previous endpoint node allows to
> use the of_graph_get_next_endpoint function in a for_each_... style macro.
> All current users of this function that pass a non-NULL prev parameter
> (coresight, rcar-du, imx-drm, soc_camera, and omap2-dss) are changed to
> not decrement the passed prev argument's refcount themselves.
>
> Signed-off-by: Philipp Zabel
> Acked-by: Mauro Carvalho Chehab
> Acked-by: Mathieu Poirier
> ---
> Changes since v6:
> - Added omap2-dss.
> - Added Mathieu's ack.
> ---
> drivers/coresight/of_coresight.c | 13 ++---
> drivers/gpu/drm/imx/imx-drm-core.c| 13 ++---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 ---
For rcar-du,
Acked-by: Laurent Pinchart
> drivers/media/platform/soc_camera/soc_camera.c| 3 ++-
> drivers/of/base.c | 9 +
> drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 7 +--
> 6 files changed, 12 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/coresight/of_coresight.c
> b/drivers/coresight/of_coresight.c index 5030c07..349c88b 100644
> --- a/drivers/coresight/of_coresight.c
> +++ b/drivers/coresight/of_coresight.c
> @@ -52,15 +52,6 @@ of_coresight_get_endpoint_device(struct device_node
> *endpoint) endpoint, of_dev_node_match);
> }
>
> -static struct device_node *of_get_coresight_endpoint(
> - const struct device_node *parent, struct device_node *prev)
> -{
> - struct device_node *node = of_graph_get_next_endpoint(parent, prev);
> -
> - of_node_put(prev);
> - return node;
> -}
> -
> static void of_coresight_get_ports(struct device_node *node,
> int *nr_inport, int *nr_outport)
> {
> @@ -68,7 +59,7 @@ static void of_coresight_get_ports(struct device_node
> *node, int in = 0, out = 0;
>
> do {
> - ep = of_get_coresight_endpoint(node, ep);
> + ep = of_graph_get_next_endpoint(node, ep);
> if (!ep)
> break;
>
> @@ -140,7 +131,7 @@ struct coresight_platform_data
> *of_get_coresight_platform_data( /* Iterate through each port to discover
> topology */
> do {
> /* Get a handle on a port */
> - ep = of_get_coresight_endpoint(node, ep);
> + ep = of_graph_get_next_endpoint(node, ep);
> if (!ep)
> break;
>
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> b/drivers/gpu/drm/imx/imx-drm-core.c index b250130..fed627d 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -436,15 +436,6 @@ static uint32_t imx_drm_find_crtc_mask(struct
> imx_drm_device *imxdrm, return 0;
> }
>
> -static struct device_node *imx_drm_of_get_next_endpoint(
> - const struct device_node *parent, struct device_node *prev)
> -{
> - struct device_node *node = of_graph_get_next_endpoint(parent, prev);
> -
> - of_node_put(prev);
> - return node;
> -}
> -
> int imx_drm_encoder_parse_of(struct drm_device *drm,
> struct drm_encoder *encoder, struct device_node *np)
> {
> @@ -456,7 +447,7 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
> for (i = 0; ; i++) {
> u32 mask;
>
> - ep = imx_drm_of_get_next_endpoint(np, ep);
> + ep = of_graph_get_next_endpoint(np, ep);
> if (!ep)
> break;
>
> @@ -504,7 +495,7 @@ int imx_drm_encoder_get_mux_id(struct device_node *node,
> return -EINVAL;
>
> do {
> - ep = imx_drm_of_get_next_endpoint(node, ep);
> + ep = of_graph_get_next_endpoint(node, ep);
> if (!ep)
> break;
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 0c5ee61..480c4d9 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -206,7 +206,7 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu, enum rcar_du_encoder_type enc_type =
> RCAR_DU_ENCODER_NONE;
> struct device_node *connector = NULL;
> struct device_node *encoder = NULL;
> - struct device_node *prev = NULL;
> + struct device_node *ep_node = NULL;
> struct device_node *entity_ep_node;
> struct device_node *entity;
> int ret;
> @@ -225,11 +225,7 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu, entity_ep_node = of_parse_phandle(ep->local_node,
> "remote-endpoint", 0);
>
> while (1) {
> - struct device_node *ep_node;
> -
> - ep_node = of_graph_get_next_endpoint(entity, prev);
> - of_node_put(prev);
> - prev = ep_node;
> + ep_node = of_graph_get_next_endpoint(entit
Re: [PATCH v4 2/5] media: ov2640: add async probe function
Hi Laurent,
On Fri, 26 Dec 2014, Laurent Pinchart wrote:
> Hi Josh,
>
> On Friday 26 December 2014 14:37:14 Josh Wu wrote:
> > On 12/25/2014 6:39 AM, Guennadi Liakhovetski wrote:
> > > On Mon, 22 Dec 2014, Josh Wu wrote:
> > >> On 12/20/2014 6:16 AM, Guennadi Liakhovetski wrote:
> > >>> On Fri, 19 Dec 2014, Josh Wu wrote:
> > On 12/19/2014 5:59 AM, Guennadi Liakhovetski wrote:
> > > On Thu, 18 Dec 2014, Josh Wu wrote:
> > >> To support async probe for ov2640, we need remove the code to get
> > >> 'mclk' in ov2640_probe() function. oterwise, if soc_camera host is
> > >> not probed in the moment, then we will fail to get 'mclk' and quit
> > >> the ov2640_probe() function.
> > >>
> > >> So in this patch, we move such 'mclk' getting code to
> > >> ov2640_s_power() function. That make ov2640 survive, as we can pass a
> > >> NULL (priv-clk) to soc_camera_set_power() function.
> > >>
> > >> And if soc_camera host is probed, the when ov2640_s_power() is
> > >> called, then we can get the 'mclk' and that make us enable/disable
> > >> soc_camera host's clock as well.
> > >>
> > >> Signed-off-by: Josh Wu
> > >> ---
> > >> v3 -> v4:
> > >> v2 -> v3:
> > >> v1 -> v2:
> > >> no changes.
> > >>
> > >> drivers/media/i2c/soc_camera/ov2640.c | 31 +
> > >> 1 file changed, 21 insertions(+), 10 deletions(-)
> > >>
> > >> diff --git a/drivers/media/i2c/soc_camera/ov2640.c
> > >> b/drivers/media/i2c/soc_camera/ov2640.c
> > >> index 1fdce2f..9ee910d 100644
> > >> --- a/drivers/media/i2c/soc_camera/ov2640.c
> > >> +++ b/drivers/media/i2c/soc_camera/ov2640.c
> > >> @@ -739,6 +739,15 @@ static int ov2640_s_power(struct v4l2_subdev
> > >> *sd, int on)
> > >> struct i2c_client *client = v4l2_get_subdevdata(sd);
> > >> struct soc_camera_subdev_desc *ssdd =
> > >> soc_camera_i2c_to_desc(client);
> > >> struct ov2640_priv *priv = to_ov2640(client);
> > >>
> > >> +struct v4l2_clk *clk;
> > >> +
> > >> +if (!priv->clk) {
> > >> +clk = v4l2_clk_get(&client->dev, "mclk");
> > >> +if (IS_ERR(clk))
> > >> +dev_warn(&client->dev, "Cannot get the mclk.
> > >> maybe
> > >> soc-camera host is not probed yet.\n");
> > >> +else
> > >> +priv->clk = clk;
> > >> +}
> > >> return soc_camera_set_power(&client->dev, ssdd,
> > >> priv->clk,
> > >> on);
> > >> }
> > >>
> > >> Just let me explained a little more details at first:
> > >>
> > >> As my understanding, current the priv->clk is a v4l2_clk: mclk, which is
> > >> a wrapper clock in soc_camera.c.
> > >> it can make soc_camera to call camera host's clock_start() clock_stop().
> > >> As in ov2640, the real mck (pck1) is in ov2640 dt node (xvclk). So the
> > >> camera host's clock_start()/stop() only need to enable/disable his
> > >> peripheral clock.
> > >
> > > I'm looking at the ov2640 datasheet. In the block diagram I only see one
> > > input clock - the xvclk. Yes, it can be supplied by the camera host
> > > controller, in which case it is natural for the camera host driver to own
> > > and control it, or it can be a separate clock device - either static or
> > > configurable. This is just a note to myself to clarify, that it's one and
> > > the same clock pin we're talking about.
> > >
> > > Now, from the hardware / DT PoV, I think, the DT should look like:
> > >
> > > a) in the ov2640 I2C DT node we should have a clock consumer entry,
> > > linking to a board-specific source.
> >
> > That's what this patch series do right now.
> > In my patch 5/5 DT document said, ov2640 need a clock consumer which
> > refer to the xvclk input clock.
> > And it is a required property.
> >
> > > b) if the ov2640 clock is supplied by a camera host, its DT entry should
> > > have a clock source subnode, to which ov2640 clock consumer entry should
> > > link. The respective camera host driver should then parse that clock
> > > subnode and register the respective clock with the V4L2 framework, by
> > > calling v4l2_clk_register().
> >
> > Ok, So in this case, I need to wait for the "mclk" in probe of ov2640
> > driver. So that I can be compatible for the camera host which provide
> > the clock source.
>
> Talking about mclk and xvclk is quite confusing. There's no mclk from an
> ov2640 point of view. The ov2640 driver should call v4l2_clk_get("xvclk").
Yes, I also was thinking about this, and yes, requesting a "xvclk" clock
would be more logical. But then, as you write below, if we let the
v4l2_clk wrapper first check for a CCF "xvclk" clock, say, none is found.
How do we then find the exported "mclk" V4L2 clock? Maybe v4l2_clk_get()
should use two names?..
> > > c) if the ov2640 clock is supplied by a different clock source, the
> > >
Re: [PATCH v4 2/5] media: ov2640: add async probe function
Hi Josh,
On Friday 26 December 2014 14:37:14 Josh Wu wrote:
> On 12/25/2014 6:39 AM, Guennadi Liakhovetski wrote:
> > On Mon, 22 Dec 2014, Josh Wu wrote:
> >> On 12/20/2014 6:16 AM, Guennadi Liakhovetski wrote:
> >>> On Fri, 19 Dec 2014, Josh Wu wrote:
> On 12/19/2014 5:59 AM, Guennadi Liakhovetski wrote:
> > On Thu, 18 Dec 2014, Josh Wu wrote:
> >> To support async probe for ov2640, we need remove the code to get
> >> 'mclk' in ov2640_probe() function. oterwise, if soc_camera host is
> >> not probed in the moment, then we will fail to get 'mclk' and quit
> >> the ov2640_probe() function.
> >>
> >> So in this patch, we move such 'mclk' getting code to
> >> ov2640_s_power() function. That make ov2640 survive, as we can pass a
> >> NULL (priv-clk) to soc_camera_set_power() function.
> >>
> >> And if soc_camera host is probed, the when ov2640_s_power() is
> >> called, then we can get the 'mclk' and that make us enable/disable
> >> soc_camera host's clock as well.
> >>
> >> Signed-off-by: Josh Wu
> >> ---
> >> v3 -> v4:
> >> v2 -> v3:
> >> v1 -> v2:
> >> no changes.
> >>
> >> drivers/media/i2c/soc_camera/ov2640.c | 31 +
> >> 1 file changed, 21 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/soc_camera/ov2640.c
> >> b/drivers/media/i2c/soc_camera/ov2640.c
> >> index 1fdce2f..9ee910d 100644
> >> --- a/drivers/media/i2c/soc_camera/ov2640.c
> >> +++ b/drivers/media/i2c/soc_camera/ov2640.c
> >> @@ -739,6 +739,15 @@ static int ov2640_s_power(struct v4l2_subdev
> >> *sd, int on)
> >>struct i2c_client *client = v4l2_get_subdevdata(sd);
> >>struct soc_camera_subdev_desc *ssdd =
> >> soc_camera_i2c_to_desc(client);
> >>struct ov2640_priv *priv = to_ov2640(client);
> >>
> >> + struct v4l2_clk *clk;
> >> +
> >> + if (!priv->clk) {
> >> + clk = v4l2_clk_get(&client->dev, "mclk");
> >> + if (IS_ERR(clk))
> >> + dev_warn(&client->dev, "Cannot get the mclk.
> >> maybe
> >> soc-camera host is not probed yet.\n");
> >> + else
> >> + priv->clk = clk;
> >> + }
> >>return soc_camera_set_power(&client->dev, ssdd, priv->clk,
> >> on);
> >> }
> >>
> >> Just let me explained a little more details at first:
> >>
> >> As my understanding, current the priv->clk is a v4l2_clk: mclk, which is
> >> a wrapper clock in soc_camera.c.
> >> it can make soc_camera to call camera host's clock_start() clock_stop().
> >> As in ov2640, the real mck (pck1) is in ov2640 dt node (xvclk). So the
> >> camera host's clock_start()/stop() only need to enable/disable his
> >> peripheral clock.
> >
> > I'm looking at the ov2640 datasheet. In the block diagram I only see one
> > input clock - the xvclk. Yes, it can be supplied by the camera host
> > controller, in which case it is natural for the camera host driver to own
> > and control it, or it can be a separate clock device - either static or
> > configurable. This is just a note to myself to clarify, that it's one and
> > the same clock pin we're talking about.
> >
> > Now, from the hardware / DT PoV, I think, the DT should look like:
> >
> > a) in the ov2640 I2C DT node we should have a clock consumer entry,
> > linking to a board-specific source.
>
> That's what this patch series do right now.
> In my patch 5/5 DT document said, ov2640 need a clock consumer which
> refer to the xvclk input clock.
> And it is a required property.
>
> > b) if the ov2640 clock is supplied by a camera host, its DT entry should
> > have a clock source subnode, to which ov2640 clock consumer entry should
> > link. The respective camera host driver should then parse that clock
> > subnode and register the respective clock with the V4L2 framework, by
> > calling v4l2_clk_register().
>
> Ok, So in this case, I need to wait for the "mclk" in probe of ov2640
> driver. So that I can be compatible for the camera host which provide
> the clock source.
Talking about mclk and xvclk is quite confusing. There's no mclk from an
ov2640 point of view. The ov2640 driver should call v4l2_clk_get("xvclk").
> > c) if the ov2640 clock is supplied by a different clock source, the
> > respective driver should parse it and also eventually call
> > v4l2_clk_register().
> >
> > Implementing case (b) above is so far up to each individual (soc-camera)
> > camera host driver. In soc-camera host drivers don't register V4L2 clocks
> > themselves, as you correctly noticed, they just provide a .clock_start()
> > and a .clock_stop() callbacks. The registration is done by the soc-camera
> > core.
> >
> > If I understand correctly you have case (c). Unfortunately, this case
> > isn't supported atm. I think, a suitable way to do this would be:
> >
> > (
