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 Dec 23 05:00:18 CET 2016 media-tree git hash:c739c0a7c3c2472d7562b8f802cdce44d2597c8b media_build git hash: 1606032398b1d79149c1507be2029e1a00d8dff0 v4l-utils git hash: c9aacef24d152007c7344b691da0cc90788395a7 gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.8.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: OK linux-3.12.67-i686: OK linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: ERRORS linux-3.18.7-i686: ERRORS linux-3.19-i686: ERRORS linux-4.0.9-i686: ERRORS linux-4.1.33-i686: ERRORS linux-4.2.8-i686: ERRORS linux-4.3.6-i686: ERRORS linux-4.4.22-i686: ERRORS linux-4.5.7-i686: ERRORS linux-4.6.7-i686: ERRORS linux-4.7.5-i686: ERRORS linux-4.8-i686: OK linux-4.9-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: OK linux-3.12.67-x86_64: OK linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: ERRORS linux-3.18.7-x86_64: ERRORS linux-3.19-x86_64: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.33-x86_64: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.22-x86_64: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.5-x86_64: ERRORS linux-4.8-x86_64: OK linux-4.9-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS 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/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] media: Add video bus switch
Hi,
On Thu, Dec 22, 2016 at 11:42:26PM +0100, Pavel Machek wrote:
> On Thu 2016-12-22 15:32:44, Sebastian Reichel wrote:
> > Hi Pavel,
> >
> > On Thu, Dec 22, 2016 at 02:39:38PM +0100, Pavel Machek wrote:
> > > N900 contains front and back camera, with a switch between the
> > > two. This adds support for the swich component.
> > >
> > > Signed-off-by: Sebastian Reichel
> > > Signed-off-by: Ivaylo Dimitrov
> > > Signed-off-by: Pavel Machek
> > >
> > > --
> > >
> > > I see this needs dts documentation, anything else than needs to be
> > > done?
> >
> > Yes. This driver takes care of the switch gpio, but the cameras also
> > use different bus settings. Currently omap3isp gets the bus-settings
> > from the link connected to the CCP2 port in DT at probe time (*).
> >
> > So there are two general problems:
> >
> > 1. Settings must be applied before the streaming starts instead of
> > at probe time, since the settings may change (based one the selected
> > camera). That should be fairly easy to implement by just moving the
> > code to the s_stream callback as far as I can see.
> >
> > 2. omap3isp should try to get the bus settings from using a callback
> > in the connected driver instead of loading it from DT. Then the
> > video-bus-switch can load the bus-settings from its downstream links
> > in DT and propagate the correct ones to omap3isp based on the
> > selected port. The DT loading part should actually remain in omap3isp
> > as fallback, in case it does not find a callback in the connected driver.
> > That way everything is backward compatible and the DT variant is
> > nice for 1-on-1 scenarios.
>
> So... did I understood it correctly? (Needs some work to be done...)
I had a quick look and yes, that's basically what I had in mind to
solve the issue. If callback is not available the old system should
be used of course.
> [...]
>
> static int isp_subdev_notifier_bound(struct v4l2_async_notifier *async,
> diff --git a/drivers/media/platform/video-bus-switch.c
> b/drivers/media/platform/video-bus-switch.c
> index 1a5d944..3a2d442 100644
> --- a/drivers/media/platform/video-bus-switch.c
> +++ b/drivers/media/platform/video-bus-switch.c
> @@ -247,12 +247,21 @@ static int vbs_s_stream(struct v4l2_subdev *sd, int
> enable)
> {
> struct v4l2_subdev *subdev = vbs_get_remote_subdev(sd);
>
> + /* FIXME: we need to set the GPIO here */
> +
The gpio is set when the pad is selected, so no need to do it again.
The gpio selection actually works with your branch (assuming its
based on Ivo's).
> if (IS_ERR(subdev))
> return PTR_ERR(subdev);
>
> return v4l2_subdev_call(subdev, video, s_stream, enable);
> }
>
> +static int vbs_g_endpoint_config(struct v4l2_subdev *sd, struct isp_bus_cfg
> *cfg)
> +{
> + printk("vbs_g_endpoint_config...\n");
> + return 0;
> +}
Would be nice to find something more abstract than isp_bus_cfg,
which is specific to omap3isp.
-- Sebastian
signature.asc
Description: PGP signature
Re: [RFC/PATCH] media: Add video bus switch
Hi, On Thu, Dec 22, 2016 at 09:53:17PM +0100, Pavel Machek wrote: > > 1. Settings must be applied before the streaming starts instead of > > at probe time, since the settings may change (based one the selected > > camera). That should be fairly easy to implement by just moving the > > code to the s_stream callback as far as I can see. > > Ok, I see, where "the code" is basically in vbs_link_setup, right? I'm not talking about the video bus switch, but about omap3isp. omap3isp must update the buscfg registers when it starts streaming instead of at probe time. I just checked and it actually seems to do so already. So the problem is only updating the buscfg inside of ccp2_s_stream() before writing the device registers. See next paragraph for more details. > > 2. omap3isp should try to get the bus settings from using a callback > > in the connected driver instead of loading it from DT. Then the > > video-bus-switch can load the bus-settings from its downstream links > > in DT and propagate the correct ones to omap3isp based on the > > selected port. The DT loading part should actually remain in omap3isp > > as fallback, in case it does not find a callback in the connected driver. > > That way everything is backward compatible and the DT variant is > > nice for 1-on-1 scenarios. > > So basically... (struct isp_bus_cfg *) isd->bus would change in > isp_pipeline_enable()...? isp_of_parse_node_csi1(), which is called by isp_of_parse_node() inits buscfg using DT information. This does not work for N900, which needs two different buscfg settings based on the selected camera. I suggest to add a callback to the subdevice instead. So something like pseudocode is needed in ccp2_s_stream(): /* get current buscfg */ if (subdevice->get_buscfg) buscfg = subdevice->get_buscfg(); else buscfg = isp_of_parse_node_csi1(); /* configure device registers */ ccp2_if_configure(buscfg); This new callback must be implemented in the video-bus-switch, so that it returns the buscfg based upon the selected camera. > > Apart from that Sakari told me at ELCE, that the port numbers > > should be reversed to match the order of other drivers. That's > > obviously very easy to do :) > > Ok, I guess that can come later :-). > > > Regarding the binding document. I actually did write one: > > https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/commit/?h=n900-camera&id=81e74af53fe6d180616b05792f78badc615e871f > > Thanks, got it. > > > So all in all it shouldn't be that hard to implement the remaining > > bits. > > :-). > > > (*) Actually it does not for CCP2, but there are some old patches > > from Sakari adding it for CCP2. It is implemented for parallel port > > and CSI in this way. > > I think I got the patches in my tree. Camera currently works for me. If you have working camera you have the CCP2 DT patches in your tree. They are not yet mainline, though. As far as I can see. -- Sebastian signature.asc Description: PGP signature
Re: [RFC/PATCH] media: Add video bus switch
On Thu 2016-12-22 15:32:44, Sebastian Reichel wrote:
> Hi Pavel,
>
> On Thu, Dec 22, 2016 at 02:39:38PM +0100, Pavel Machek wrote:
> > N900 contains front and back camera, with a switch between the
> > two. This adds support for the swich component.
> >
> > Signed-off-by: Sebastian Reichel
> > Signed-off-by: Ivaylo Dimitrov
> > Signed-off-by: Pavel Machek
> >
> > --
> >
> > I see this needs dts documentation, anything else than needs to be
> > done?
>
> Yes. This driver takes care of the switch gpio, but the cameras also
> use different bus settings. Currently omap3isp gets the bus-settings
> from the link connected to the CCP2 port in DT at probe time (*).
>
> So there are two general problems:
>
> 1. Settings must be applied before the streaming starts instead of
> at probe time, since the settings may change (based one the selected
> camera). That should be fairly easy to implement by just moving the
> code to the s_stream callback as far as I can see.
>
> 2. omap3isp should try to get the bus settings from using a callback
> in the connected driver instead of loading it from DT. Then the
> video-bus-switch can load the bus-settings from its downstream links
> in DT and propagate the correct ones to omap3isp based on the
> selected port. The DT loading part should actually remain in omap3isp
> as fallback, in case it does not find a callback in the connected driver.
> That way everything is backward compatible and the DT variant is
> nice for 1-on-1 scenarios.
So... did I understood it correctly? (Needs some work to be done...)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 45c69ed..1f44da1 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -702,6 +704,33 @@ static int isp_pipeline_enable(struct isp_pipeline *pipe,
entity = &pipe->output->video.entity;
while (1) {
+ struct v4l2_of_endpoint vep;
+ pad = &entity->pads[0];
+ if (!(pad->flags & MEDIA_PAD_FL_SINK))
+ break;
+
+ pad = media_entity_remote_pad(pad);
+ if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
+ break;
+
+ entity = pad->entity;
+ subdev = media_entity_to_v4l2_subdev(entity);
+
+ printk("Entity = %p\n", entity);
+ ret = v4l2_subdev_call(subdev, video, g_endpoint_config, &vep);
+ /* Is there better method than walking a list?
+ Can I easily get dev and isd pointers here? */
+#if 0
+ if (ret == 0) {
+ printk("success\n");
+ /* notifier->subdevs[notifier->num_subdevs] ...
contains isd */
+ isp_endpoint_to_buscfg(dev, vep, isd->bus);
+ }
+#endif
+ }
+
+ entity = &pipe->output->video.entity;
+ while (1) {
pad = &entity->pads[0];
if (!(pad->flags & MEDIA_PAD_FL_SINK))
break;
@@ -2099,27 +2128,8 @@ static void isp_of_parse_node_csi2(struct device *dev,
buscfg->bus.csi2.crc = 1;
}
-static int isp_of_parse_node_endpoint(struct device *dev,
- struct device_node *node,
- struct isp_async_subdev *isd)
+static int isp_endpoint_to_buscfg(struct device *dev, struct v4l2_of_endpoint
vep, struct isp_bus_cfg *buscfg)
{
- struct isp_bus_cfg *buscfg;
- struct v4l2_of_endpoint vep;
- int ret;
-
- isd->bus = devm_kzalloc(dev, sizeof(*isd->bus), GFP_KERNEL);
- if (!isd->bus)
- return -ENOMEM;
-
- buscfg = isd->bus;
-
- ret = v4l2_of_parse_endpoint(node, &vep);
- if (ret)
- return ret;
-
- dev_dbg(dev, "parsing endpoint %s, interface %u\n", node->full_name,
- vep.base.port);
-
switch (vep.base.port) {
case ISP_OF_PHY_PARALLEL:
buscfg->interface = ISP_INTERFACE_PARALLEL;
@@ -2147,10 +2157,35 @@ static int isp_of_parse_node_endpoint(struct device
*dev,
break;
default:
+ return -1;
+ }
+ return 0;
+}
+
+static int isp_of_parse_node_endpoint(struct device *dev,
+ struct device_node *node,
+ struct isp_async_subdev *isd)
+{
+ struct isp_bus_cfg *buscfg;
+ struct v4l2_of_endpoint vep;
+ int ret;
+
+ isd->bus = devm_kzalloc(dev, sizeof(*isd->bus), GFP_KERNEL);
+ if (!isd->bus)
+ return -ENOMEM;
+
+ buscfg = isd->bus;
+
+ ret = v4l2_of_parse_endpoint(node, &vep);
+ if (ret)
+ return ret;
+
+ dev_dbg(dev, "parsing endpoint %s, interface %u\n", node->full_name,
+ vep.base.port);
+
+ if (isp_endpoint_to_buscfg(dev, vep, buscfg))
de
Re: [RFC/PATCH] media: Add video bus switch
Hi! > > I see this needs dts documentation, anything else than needs to be > > done? > > Yes. This driver takes care of the switch gpio, but the cameras also > use different bus settings. Currently omap3isp gets the bus-settings > from the link connected to the CCP2 port in DT at probe time (*). > > So there are two general problems: > > 1. Settings must be applied before the streaming starts instead of > at probe time, since the settings may change (based one the selected > camera). That should be fairly easy to implement by just moving the > code to the s_stream callback as far as I can see. Ok, I see, where "the code" is basically in vbs_link_setup, right? > 2. omap3isp should try to get the bus settings from using a callback > in the connected driver instead of loading it from DT. Then the > video-bus-switch can load the bus-settings from its downstream links > in DT and propagate the correct ones to omap3isp based on the > selected port. The DT loading part should actually remain in omap3isp > as fallback, in case it does not find a callback in the connected driver. > That way everything is backward compatible and the DT variant is > nice for 1-on-1 scenarios. So basically... (struct isp_bus_cfg *) isd->bus would change in isp_pipeline_enable()...? > Apart from that Sakari told me at ELCE, that the port numbers > should be reversed to match the order of other drivers. That's > obviously very easy to do :) Ok, I guess that can come later :-). > Regarding the binding document. I actually did write one: > https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/commit/?h=n900-camera&id=81e74af53fe6d180616b05792f78badc615e871f Thanks, got it. > So all in all it shouldn't be that hard to implement the remaining > bits. :-). > (*) Actually it does not for CCP2, but there are some old patches > from Sakari adding it for CCP2. It is implemented for parallel port > and CSI in this way. I think I got the patches in my tree. Camera currently works for me. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: Media summit in Feb? - Was: Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed
Em Thu, 22 Dec 2016 19:47:15 +0200 Laurent Pinchart escreveu: > Hi Mauro, > > On Tuesday 20 Dec 2016 23:31:42 Mauro Carvalho Chehab wrote: > > Em Mon, 19 Dec 2016 07:28:29 -0200 Mauro Carvalho Chehab escreveu: > > > Em Fri, 16 Dec 2016 15:45:10 +0100 Hans Verkuil escreveu: > > >> We really need a whiteboard for this :-( > > > > > > Well, we could schedule a media summit together with ELC NA. > > > > > > ELC will be in Feb, 21-23 in Portland. > > > > Btw, I'm pre reserving a room for us in Feb, 20, assuming that > > people can make it. > > I'll be in Portland from the 18th to the 25th. I'm not sure yet whether I'll > be free on the 20th though as I also have other meetings to schedule. I'll > try > to find out soon. Unfortunately, Feb, 20th seems to be the only day outside ELC that LF can provide us a room. We could try to do something between Feb, 21-23, but I guess this would be harder for us, as people may have different arrangements during ELC days. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] pvrusb2-io: Add some spaces for better code readability
From: Markus Elfring
Date: Thu, 22 Dec 2016 20:25:39 +0100
Use space characters at some source code places according to
the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/media/usb/pvrusb2/pvrusb2-io.c | 120 -
1 file changed, 60 insertions(+), 60 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-io.c
b/drivers/media/usb/pvrusb2/pvrusb2-io.c
index a01510bfc84f..c89e037f72c3 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-io.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-io.c
@@ -37,13 +37,13 @@ static const char *pvr2_buffer_state_decode(enum
pvr2_buffer_state);
if ((bp)->signature != BUFFER_SIG) { \
pvr2_trace(PVR2_TRACE_ERROR_LEGS, \
"Buffer %p is bad at %s:%d", \
- (bp),__FILE__,__LINE__); \
- pvr2_buffer_describe(bp,"BadSig"); \
+ (bp), __FILE__, __LINE__); \
+ pvr2_buffer_describe(bp, "BadSig"); \
BUG(); \
} \
} while (0)
#else
-#define BUFFER_CHECK(bp) do {} while(0)
+#define BUFFER_CHECK(bp) do {} while (0)
#endif
struct pvr2_stream {
@@ -110,7 +110,7 @@ static const char *pvr2_buffer_state_decode(enum
pvr2_buffer_state st)
}
#ifdef SANITY_CHECK_BUFFERS
-static void pvr2_buffer_describe(struct pvr2_buffer *bp,const char *msg)
+static void pvr2_buffer_describe(struct pvr2_buffer *bp, const char *msg)
{
pvr2_trace(PVR2_TRACE_INFO,
"buffer%s%s %p state=%s id=%d status=%d stream=%p purb=%p
sig=0x%x",
@@ -156,7 +156,7 @@ static void pvr2_buffer_remove(struct pvr2_buffer *bp)
(*bcnt) -= ccnt;
pvr2_trace(PVR2_TRACE_BUF_FLOW,
"/*---TRACE_FLOW---*/ bufferPool %8s dec cap=%07d
cnt=%02d",
- pvr2_buffer_state_decode(bp->state),*bcnt,*cnt);
+ pvr2_buffer_state_decode(bp->state), *bcnt, *cnt);
bp->state = pvr2_buffer_state_none;
}
@@ -171,9 +171,9 @@ static void pvr2_buffer_set_none(struct pvr2_buffer *bp)
bp,
pvr2_buffer_state_decode(bp->state),
pvr2_buffer_state_decode(pvr2_buffer_state_none));
- spin_lock_irqsave(&sp->list_lock,irq_flags);
+ spin_lock_irqsave(&sp->list_lock, irq_flags);
pvr2_buffer_remove(bp);
- spin_unlock_irqrestore(&sp->list_lock,irq_flags);
+ spin_unlock_irqrestore(&sp->list_lock, irq_flags);
}
static int pvr2_buffer_set_ready(struct pvr2_buffer *bp)
@@ -188,18 +188,18 @@ static int pvr2_buffer_set_ready(struct pvr2_buffer *bp)
bp,
pvr2_buffer_state_decode(bp->state),
pvr2_buffer_state_decode(pvr2_buffer_state_ready));
- spin_lock_irqsave(&sp->list_lock,irq_flags);
+ spin_lock_irqsave(&sp->list_lock, irq_flags);
fl = (sp->r_count == 0);
pvr2_buffer_remove(bp);
- list_add_tail(&bp->list_overhead,&sp->ready_list);
+ list_add_tail(&bp->list_overhead, &sp->ready_list);
bp->state = pvr2_buffer_state_ready;
(sp->r_count)++;
sp->r_bcount += bp->used_count;
pvr2_trace(PVR2_TRACE_BUF_FLOW,
"/*---TRACE_FLOW---*/ bufferPool %8s inc cap=%07d
cnt=%02d",
pvr2_buffer_state_decode(bp->state),
- sp->r_bcount,sp->r_count);
- spin_unlock_irqrestore(&sp->list_lock,irq_flags);
+ sp->r_bcount, sp->r_count);
+ spin_unlock_irqrestore(&sp->list_lock, irq_flags);
return fl;
}
@@ -214,17 +214,17 @@ static void pvr2_buffer_set_idle(struct pvr2_buffer *bp)
bp,
pvr2_buffer_state_decode(bp->state),
pvr2_buffer_state_decode(pvr2_buffer_state_idle));
- spin_lock_irqsave(&sp->list_lock,irq_flags);
+ spin_lock_irqsave(&sp->list_lock, irq_flags);
pvr2_buffer_remove(bp);
- list_add_tail(&bp->list_overhead,&sp->idle_list);
+ list_add_tail(&bp->list_overhead, &sp->idle_list);
bp->state = pvr2_buffer_state_idle;
(sp->i_count)++;
sp->i_bcount += bp->max_count;
pvr2_trace(PVR2_TRACE_BUF_FLOW,
"/*---TRACE_FLOW---*/ bufferPool %8s inc cap=%07d
cnt=%02d",
pvr2_buffer_state_decode(bp->state),
- sp->i_bcount,sp->i_count);
- spin_unlock_irqrestore(&sp->list_lock,irq_flags);
+ sp->i_bcount, sp->i_count);
+ spin_unlock_irqrestore(&sp->list_lock, irq_flags);
}
static void pvr2_buffer_set_queued(struct pvr2_buffer *bp)
@@ -238,17 +238,17 @@ static void pvr2_buffer_set_queued(struct pvr2_buffer *bp)
bp,
pvr2_buffer_state_decode(bp->state),
pvr2_buffer_state_decode(pvr2_buffer_state_queued));
- spin_lock_irqsave(&sp->list_lock,irq_flags);
+ spin_lock_irqsave(&sp->list_lock, irq_flags);
pvr2_buffer_remove(bp);
- list_add_tail(&
[PATCH 1/2] [media] pvrusb2-io: Use kmalloc_array() in pvr2_stream_buffer_count()
From: Markus Elfring
Date: Thu, 22 Dec 2016 19:26:52 +0100
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/usb/pvrusb2/pvrusb2-io.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-io.c
b/drivers/media/usb/pvrusb2/pvrusb2-io.c
index e3103ecd4828..a01510bfc84f 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-io.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-io.c
@@ -312,7 +312,8 @@ static int pvr2_stream_buffer_count(struct pvr2_stream
*sp,unsigned int cnt)
if (cnt > sp->buffer_total_count) {
if (scnt > sp->buffer_slot_count) {
struct pvr2_buffer **nb;
- nb = kmalloc(scnt * sizeof(*nb),GFP_KERNEL);
+
+ nb = kmalloc_array(scnt, sizeof(*nb), GFP_KERNEL);
if (!nb) return -ENOMEM;
if (sp->buffer_slot_count) {
memcpy(nb,sp->buffers,
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] [media] pvrusb2-io: Fine-tuning for some function implementations
From: Markus Elfring Date: Thu, 22 Dec 2016 20:48:04 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (2): Use kmalloc_array() Add some spaces for better code readability drivers/media/usb/pvrusb2/pvrusb2-io.c | 123 + 1 file changed, 62 insertions(+), 61 deletions(-) -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding
Hi Laurent,
On Thu, Dec 22, 2016 at 6:05 PM, Laurent Pinchart
wrote:
> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote:
>> Add binding documentation for Renesas R-Car Digital Radio Interface
>> (DRIF) controller.
>>
>> Signed-off-by: Ramesh Shanmugasundaram
>> ---
>> .../devicetree/bindings/media/renesas,drif.txt | 202 ++
>> 1 file changed, 202 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
>> b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode
>> 100644
>> index 000..1f3feaf
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>> +Optional properties of an internal channel when:
>> + - It is the only enabled channel of the bond (or)
>> + - If it acts as primary among enabled bonds
>> +
>> +- renesas,syncmd : sync mode
>> + 0 (Frame start sync pulse mode. 1-bit width pulse
>> + indicates start of a frame)
>> + 1 (L/R sync or I2S mode) (default)
>> +- renesas,lsb-first: empty property indicates lsb bit is received
>> first.
>> + When not defined msb bit is received first (default)
>> +- renesas,syncac-active: Indicates sync signal polarity, 0/1 for low/high
>> + respectively. The default is 1 (active high)
>> +- renesas,dtdl : delay between sync signal and start of reception.
>> + The possible values are represented in 0.5 clock
>> + cycle units and the range is 0 to 4. The default
>> + value is 2 (i.e.) 1 clock cycle delay.
>> +- renesas,syncdl : delay between end of reception and sync signal
>> edge.
>> + The possible values are represented in 0.5 clock
>> + cycle units and the range is 0 to 4 & 6. The default
>> + value is 0 (i.e.) no delay.
>
> Most of these properties are pretty similar to the video bus properties
> defined at the endpoint level in
> Documentation/devicetree/bindings/media/video-interfaces.txt. I believe it
> would make sense to use OF graph and try to standardize these properties
> similarly.
Note that the last two properties match the those in
Documentation/devicetree/bindings/spi/sh-msiof.txt.
We may want to use one DRIF channel as a plain SPI slave with the
(modified) MSIOF driver in the future.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: Media summit in Feb? - Was: Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed
Hi Mauro, On Tuesday 20 Dec 2016 23:31:42 Mauro Carvalho Chehab wrote: > Em Mon, 19 Dec 2016 07:28:29 -0200 Mauro Carvalho Chehab escreveu: > > Em Fri, 16 Dec 2016 15:45:10 +0100 Hans Verkuil escreveu: > >> We really need a whiteboard for this :-( > > > > Well, we could schedule a media summit together with ELC NA. > > > > ELC will be in Feb, 21-23 in Portland. > > Btw, I'm pre reserving a room for us in Feb, 20, assuming that > people can make it. I'll be in Portland from the 18th to the 25th. I'm not sure yet whether I'll be free on the 20th though as I also have other meetings to schedule. I'll try to find out soon. -- Regards, Laurent Pinchart -- 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 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding
Hi Ramesh, Thank you for the patch. On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote: > Add binding documentation for Renesas R-Car Digital Radio Interface > (DRIF) controller. > > Signed-off-by: Ramesh Shanmugasundaram > --- > .../devicetree/bindings/media/renesas,drif.txt | 202 ++ > 1 file changed, 202 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt > > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt > b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode > 100644 > index 000..1f3feaf > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt > @@ -0,0 +1,202 @@ > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF) > + > + > +R-Car Gen3 DRIF is a SPI like receive only slave device. A general > +representation of DRIF interfacing with a master device is shown below. > + > ++-++-+ > +| |-SCK--->|CLK | > +| Master|-SS>|SYNC DRIFn (slave) | > +| |-SD0--->|D0 | > +| |-SD1--->|D1 | > ++-++-+ > + > +As per datasheet, each DRIF channel (drifn) is made up of two internal > +channels (drifn0 & drifn1). These two internal channels share the common > +CLK & SYNC. Each internal channel has its own dedicated resources like > +irq, dma channels, address space & clock. This internal split is not > +visible to the external master device. > + > +The device tree model represents each internal channel as a separate node. > +The internal channels sharing the CLK & SYNC are tied together by their > +phandles using a new property called "renesas,bonding". For the rest of > +the documentation, unless explicitly stated, the word channel implies an > +internal channel. > + > +When both internal channels are enabled they need to be managed together > +as one (i.e.) they cannot operate alone as independent devices. Out of the > +two, one of them needs to act as a primary device that accepts common > +properties of both the internal channels. This channel is identified by a > +new property called "renesas,primary-bond". > + > +To summarize, > + - When both the internal channels that are bonded together are enabled, > + the zeroth channel is selected as primary-bond. This channels accepts > + properties common to all the members of the bond. > + - When only one of the bonded channels need to be enabled, the property > + "renesas,bonding" or "renesas,primary-bond" will have no effect. That > + enabled channel can act alone as any other independent device. > + > +Required properties of an internal channel: > +--- > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of > R8A7795 SoC. > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible > device. > + When compatible with the generic version, nodes must list the > + SoC-specific version corresponding to the platform first > + followed by the generic version. > +- reg: offset and length of that channel. > +- interrupts: associated with that channel. > +- clocks: phandle and clock specifier of that channel. > +- clock-names: clock input name string: "fck". > +- dmas: phandles to the DMA channels. > +- dma-names: names of the DMA channel: "rx". > +- renesas,bonding: phandle to the other channel. > + > +Optional properties of an internal channel: > +--- > +- power-domains: phandle to the respective power domain. > + > +Required properties of an internal channel when: > + - It is the only enabled channel of the bond (or) > + - If it acts as primary among enabled bonds > + > +- pinctrl-0: pin control group to be used for this channel. > +- pinctrl-names: must be "default". > +- renesas,primary-bond: empty property indicating the channel acts as > primary > + among the bonded channels. > +- port: child port node of a channel that defines the local and remote > + endpoints. The remote endpoint is assumed to be a third party tuner > + device endpoint. > + > +Optional properties of an internal channel when: > + - It is the only enabled channel of the bond (or) > + - If it acts as primary among enabled bonds > + > +- renesas,syncmd : sync mode > + 0 (Frame start sync pulse mode. 1-bit width pulse > + indicates start of a frame) > + 1 (L/R sync or I2S mode) (default) > +- renesas,lsb-first: empty property indicates l
Re: [PATCH v6 5/6] Documentation: bindings: add documentation for ir-spi device driver
On Sun, Dec 18, 2016 at 08:11:37PM +0900, Andi Shyti wrote: > Document the ir-spi driver's binding which is a IR led driven > through the SPI line. > > Signed-off-by: Andi Shyti > Reviewed-by: Sean Young > --- > .../devicetree/bindings/leds/irled/spi-ir-led.txt | 29 > ++ > 1 file changed, 29 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt Acked-by: Rob Herring -- 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: Add video bus switch
Hi Pavel, On Thu, Dec 22, 2016 at 02:39:38PM +0100, Pavel Machek wrote: > N900 contains front and back camera, with a switch between the > two. This adds support for the swich component. > > Signed-off-by: Sebastian Reichel > Signed-off-by: Ivaylo Dimitrov > Signed-off-by: Pavel Machek > > -- > > I see this needs dts documentation, anything else than needs to be > done? Yes. This driver takes care of the switch gpio, but the cameras also use different bus settings. Currently omap3isp gets the bus-settings from the link connected to the CCP2 port in DT at probe time (*). So there are two general problems: 1. Settings must be applied before the streaming starts instead of at probe time, since the settings may change (based one the selected camera). That should be fairly easy to implement by just moving the code to the s_stream callback as far as I can see. 2. omap3isp should try to get the bus settings from using a callback in the connected driver instead of loading it from DT. Then the video-bus-switch can load the bus-settings from its downstream links in DT and propagate the correct ones to omap3isp based on the selected port. The DT loading part should actually remain in omap3isp as fallback, in case it does not find a callback in the connected driver. That way everything is backward compatible and the DT variant is nice for 1-on-1 scenarios. Apart from that Sakari told me at ELCE, that the port numbers should be reversed to match the order of other drivers. That's obviously very easy to do :) Regarding the binding document. I actually did write one: https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/commit/?h=n900-camera&id=81e74af53fe6d180616b05792f78badc615e871f So all in all it shouldn't be that hard to implement the remaining bits. (*) Actually it does not for CCP2, but there are some old patches from Sakari adding it for CCP2. It is implemented for parallel port and CSI in this way. -- Sebastian signature.asc Description: PGP signature
[RFC/PATCH] media: Add video bus switch
N900 contains front and back camera, with a switch between the
two. This adds support for the swich component.
Signed-off-by: Sebastian Reichel
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pavel Machek
--
I see this needs dts documentation, anything else than needs to be
done?
Thanks,
Pavel
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421..0a99e63 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -91,6 +91,16 @@ config VIDEO_OMAP3_DEBUG
---help---
Enable debug messages on OMAP 3 camera controller driver.
+config VIDEO_BUS_SWITCH
+ tristate "Video Bus switch"
+ depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on MEDIA_CONTROLLER
+ depends on OF
+ ---help---
+ Driver for a GPIO controlled video bus switch, which is used to
+ connect two camera sensors to the same port a the image signal
+ processor.
+
config VIDEO_PXA27x
tristate "PXA27x Quick Capture Interface driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 5b3cb27..a4c9eab 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
obj-$(CONFIG_VIDEO_OMAP3) += omap3isp/
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
+obj-$(CONFIG_VIDEO_BUS_SWITCH) += video-bus-switch.o
+
obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
obj-$(CONFIG_VIDEO_VIVID) += vivid/
diff --git a/drivers/media/platform/video-bus-switch.c
b/drivers/media/platform/video-bus-switch.c
new file mode 100644
index 000..1a5d944
--- /dev/null
+++ b/drivers/media/platform/video-bus-switch.c
@@ -0,0 +1,371 @@
+/*
+ * Generic driver for video bus switches
+ *
+ * Copyright (C) 2015 Sebastian Reichel
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#define DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * TODO:
+ * isp_subdev_notifier_complete() calls v4l2_device_register_subdev_nodes()
+ */
+
+#define CSI_SWITCH_SUBDEVS 2
+#define CSI_SWITCH_PORTS 3
+
+enum vbs_state {
+ CSI_SWITCH_DISABLED,
+ CSI_SWITCH_PORT_1,
+ CSI_SWITCH_PORT_2,
+};
+
+struct vbs_src_pads {
+ struct media_entity *src;
+ int src_pad;
+};
+
+struct vbs_data {
+ struct gpio_desc *swgpio;
+ struct v4l2_subdev subdev;
+ struct v4l2_async_notifier notifier;
+ struct media_pad pads[CSI_SWITCH_PORTS];
+ struct vbs_src_pads src_pads[CSI_SWITCH_PORTS];
+ enum vbs_state state;
+};
+
+struct vbs_async_subdev {
+ struct v4l2_subdev *sd;
+ struct v4l2_async_subdev asd;
+ u8 port;
+};
+
+static int vbs_of_parse_nodes(struct device *dev, struct vbs_data *pdata)
+{
+ struct v4l2_async_notifier *notifier = &pdata->notifier;
+ struct device_node *node = NULL;
+
+ notifier->subdevs = devm_kcalloc(dev, CSI_SWITCH_SUBDEVS,
+ sizeof(*notifier->subdevs), GFP_KERNEL);
+ if (!notifier->subdevs)
+ return -ENOMEM;
+
+ notifier->num_subdevs = 0;
+ while (notifier->num_subdevs < CSI_SWITCH_SUBDEVS &&
+ (node = of_graph_get_next_endpoint(dev->of_node, node))) {
+ struct v4l2_of_endpoint vep;
+ struct vbs_async_subdev *ssd;
+
+ /* skip first port (connected to isp) */
+ v4l2_of_parse_endpoint(node, &vep);
+ if (vep.base.port == 0) {
+ struct device_node *ispnode;
+
+ ispnode = of_graph_get_remote_port_parent(node);
+ if (!ispnode) {
+ dev_warn(dev, "bad remote port parent\n");
+ return -EINVAL;
+ }
+
+ of_node_put(node);
+ continue;
+ }
+
+ ssd = devm_kzalloc(dev, sizeof(*ssd), GFP_KERNEL);
+ if (!ssd) {
+ of_node_put(node);
+ return -ENOMEM;
+ }
+
+ ssd->port = vep.base.port;
+
+ notifier->subdevs[notifier->num_subdevs] = &ssd->asd;
+
+ ssd->asd.match.of.node = of_graph_get_remote_port_parent(node);
+ of_node_put(node);
+ if (!ssd->asd.match.of.node) {
+
[PATCH v6] media: Driver for Toshiba et8ek8 5MP sensor
Add driver for et8ek8 sensor, found in Nokia N900 main camera. Can be
used for taking photos in 2.5MP resolution with fcam-dev.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pavel Machek
---
From v5: fix 16bit writing so that swab() is not neccessary.
From v4 I did cleanups to coding style and removed various oddities.
Exposure value is now in native units, which simplifies the code.
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 2669b4b..6d01e15 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -667,6 +667,7 @@ config VIDEO_S5K5BAF
camera sensor with an embedded SoC image signal processor.
source "drivers/media/i2c/smiapp/Kconfig"
+source "drivers/media/i2c/et8ek8/Kconfig"
config VIDEO_S5C73M3
tristate "Samsung S5C73M3 sensor support"
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 92773b2..5bc7bbe 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -2,6 +2,7 @@ msp3400-objs:= msp3400-driver.o msp3400-kthreads.o
obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
obj-$(CONFIG_VIDEO_SMIAPP) += smiapp/
+obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8/
obj-$(CONFIG_VIDEO_CX25840) += cx25840/
obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
obj-y += soc_camera/
diff --git a/drivers/media/i2c/et8ek8/Kconfig b/drivers/media/i2c/et8ek8/Kconfig
new file mode 100644
index 000..1439936
--- /dev/null
+++ b/drivers/media/i2c/et8ek8/Kconfig
@@ -0,0 +1,6 @@
+config VIDEO_ET8EK8
+ tristate "ET8EK8 camera sensor support"
+ depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ ---help---
+ This is a driver for the Toshiba ET8EK8 5 MP camera sensor.
+ It is used for example in Nokia N900 (RX-51).
diff --git a/drivers/media/i2c/et8ek8/Makefile
b/drivers/media/i2c/et8ek8/Makefile
new file mode 100644
index 000..66d1b7d
--- /dev/null
+++ b/drivers/media/i2c/et8ek8/Makefile
@@ -0,0 +1,2 @@
+et8ek8-objs+= et8ek8_mode.o et8ek8_driver.o
+obj-$(CONFIG_VIDEO_ET8EK8) += et8ek8.o
diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c
b/drivers/media/i2c/et8ek8/et8ek8_driver.c
new file mode 100644
index 000..d3de087
--- /dev/null
+++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
@@ -0,0 +1,1515 @@
+/*
+ * et8ek8_driver.c
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Contact: Sakari Ailus
+ * Tuukka Toivonen
+ * Pavel Machek
+ *
+ * Based on code from Toni Leinonen .
+ *
+ * This driver is based on the Micron MT9T012 camera imager driver
+ * (C) Texas Instruments.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "et8ek8_reg.h"
+
+#define ET8EK8_NAME"et8ek8"
+#define ET8EK8_PRIV_MEM_SIZE 128
+#define ET8EK8_MAX_MSG 48
+
+struct et8ek8_sensor {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt format;
+ struct gpio_desc *reset;
+ struct regulator *vana;
+ struct clk *ext_clk;
+ u32 xclk_freq;
+
+ u16 version;
+
+ struct v4l2_ctrl_handler ctrl_handler;
+ struct v4l2_ctrl *exposure;
+ struct v4l2_ctrl *pixel_rate;
+ struct et8ek8_reglist *current_reglist;
+
+ u8 priv_mem[ET8EK8_PRIV_MEM_SIZE];
+
+ struct mutex power_lock;
+ int power_count;
+};
+
+#define to_et8ek8_sensor(sd) container_of(sd, struct et8ek8_sensor, subdev)
+
+enum et8ek8_versions {
+ ET8EK8_REV_1 = 0x0001,
+ ET8EK8_REV_2,
+};
+
+/*
+ * This table describes what should be written to the sensor register
+ * for each gain value. The gain(index in the table) is in terms of
+ * 0.1EV, i.e. 10 indexes in the table give 2 time more gain [0] in
+ * the *analog gain, [1] in the digital gain
+ *
+ * Analog gain [dB] = 20*log10(regvalue/32); 0x20..0x100
+ */
+static struct et8ek8_gain {
+ u16 analog;
+ u16 digital;
+} const et8ek8_gain_table[] = {
+ { 32,0}, /* x1 */
+ { 34,0},
+ { 37,0},
+ { 39,0},
+ { 42,0},
+ { 45,0},
+ { 49,0},
+ { 52,0},
+ { 56,0},
+ { 60,0},
+ { 64,0}, /* x2 */
+ { 69,0},
+ { 74,0},
+ { 79,0},
+ { 84,0},
+ { 91,0},
+ { 97,0},
+ {104,0},
+ {111,0},
+ {119,0},
+ {128,0},
Re: [PATCH v5] media: Driver for Toshiba et8ek8 5MP sensor
Hi!
> > > Thanks for the update.
> > >
> > > On Wed, Dec 14, 2016 at 01:24:51PM +0100, Pavel Machek wrote:
> > > ...
> > > > +static int et8ek8_set_ctrl(struct v4l2_ctrl *ctrl)
> > > > +{
> > > > + struct et8ek8_sensor *sensor =
> > > > + container_of(ctrl->handler, struct et8ek8_sensor,
> > > > ctrl_handler);
> > > > +
> > > > + switch (ctrl->id) {
> > > > + case V4L2_CID_GAIN:
> > > > + return et8ek8_set_gain(sensor, ctrl->val);
> > > > +
> > > > + case V4L2_CID_EXPOSURE:
> > > > + {
> > > > + int rows;
> > > > + struct i2c_client *client =
> > > > v4l2_get_subdevdata(&sensor->subdev);
> > > > + rows = ctrl->val;
> > > > + return et8ek8_i2c_write_reg(client, ET8EK8_REG_16BIT,
> > > > 0x1243,
> > > > + swab16(rows));
> > >
> > > Why swab16()? Doesn't the et8ek8_i2c_write_reg() already do the right
> > > thing?
> > >
> > > 16-bit writes aren't used elsewhere... and the register address and value
> > > seem to have different endianness there, it looks like a bug to me in that
> > > function.
> >
> > I'm pretty sure I did not invent that swab16(). I checked, and
> > exposure seems to work properly. I tried swapping the bytes, but then
> > exposure did not seem to work. So this one seems to be correct.
>
> I can fix that too, but I have no device to test. In terms of how the
> hardware is controlled there should be no difference anyway.
Aha, now I understand; you want me to fix write_reg. I can do that. It
seems read_reg has similar problem, but as noone is using 16-bit
reads, so it is dormant. Ok, let me fix that.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
