Re: v4l2-ctrl is unable to set autogain to 0 with gspca/ov534

[Hans Verkuil]

Hi Antonio,

On 10/07/2015 10:05 AM, Antonio Ospite wrote:
> Hi,
> 
> It looks like it is not possible to set the autogain from 1 to 0 using
> v4l2-ctrl with the driver I am using.
> 
> I am testing with the gspca/ov534 driver, and this sequence of commands
> does not change the value of the control:
> 
>   v4l2-ctl --set-ctrl=gain_automatic=1
>   v4l2-ctl --list-ctrls | grep gain_automatic
>   # The following does not work
>   v4l2-ctl --set-ctrl=gain_automatic=0
>   v4l2-ctl --list-ctrls | grep gain_automatic
> 
> The same thing happens with guvcview, but setting the control with qv4l2
> works fine.
> 
> After a little investigation I figured out some more details: in my use
> case the autogain is a master control in an auto cluster, and switching
> it from auto to manual does not work when using VIDIOC_S_CTRL i.e. when
> calling set_ctrl().
> 
> It works with qv4l2 because it uses VIDIOC_S_EXT_CTRLS.
> 
> So the difference is between v4l2-ctrls.c::v4l2_s_ctrl() and
> v4l2-ctrls.c::v4l2_s_ext_ctrls().
> 
> Wrt. auto clusters going from auto to manual the two functions do
> basically this:
> 
> 
>   v4l2_s_ctrl()
> set_ctrl_lock()
>   user_to_new()
>   set_ctrl()
> update_from_auto_cluster(master)
> try_or_set_cluster()
>   cur_to_user()
> 
> 
>   v4l2_s_ext_ctrls()
> try_set_ext_ctrls()
>   update_from_auto_cluster(master)
>   user_to_new() for each control
>   try_or_set_cluster()
>   new_to_user()
> 
> 
> I think the problem is that when update_from_auto_cluster(master) is
> called it overrides the new master control value from userspace by
> calling cur_to_new(). This also happens when calling VIDIOC_S_EXT_CTRLS
> (in try_set_ext_ctrls), but in that case, AFTER the call to
> update_from_auto_cluster(master), the code calls user_to_new() that sets
> back again the correct new value in the control before making the value
> permanent with try_or_set_cluster().
> 
> The regression may have been introduced in
> 5d0360a4f027576e5419d4a7c711c9ca0f1be8ca, in fact by just reverting
> these two interdependent commits:
> 
> 7a7f1ab37dc8f66cf0ef10f3d3f1b79ac4bc67fc
> 5d0360a4f027576e5419d4a7c711c9ca0f1be8ca
> 
> the problem goes away, so the regression is about user_to_new() not
> being called AFTER update_from_auto_cluster(master) anymore in
> set_ctrl(), as per 5d0360a4f027576e5419d4a7c711c9ca0f1be8ca.

Excellent analysis!

> 
> A quick and dirty fixup could look like this:
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index b6b7dcc..55d78fc 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -3198,8 +3198,11 @@ static int set_ctrl(struct v4l2_fh *fh, struct 
> v4l2_ctrl *ctrl, u32 ch_flags)
>manual mode we have to update the current volatile values since
>those will become the initial manual values after such a switch. */
> if (master->is_auto && master->has_volatiles && ctrl == master &&
> -   !is_cur_manual(master) && ctrl->val == master->manual_mode_value)
> +   !is_cur_manual(master) && ctrl->val == master->manual_mode_value) 
> {
> +   s32 new_auto_val = master->val;
> update_from_auto_cluster(master);
> +   master->val = new_auto_val;
> +   }
> 
> ctrl->is_new = 1;
> return try_or_set_cluster(fh, master, true, ch_flags);
> 
> 
> However I think that calling user_to_new() after
> update_from_auto_cluster() has always been masking a bug in the latter.
> 
> Maybe this is a better fix, in place of the one above.
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index b6b7dcc..19fc06e 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -3043,7 +3043,7 @@ static void update_from_auto_cluster(struct v4l2_ctrl 
> *master)
>  {
> int i;
> 
> -   for (i = 0; i < master->ncontrols; i++)
> +   for (i = 1; i < master->ncontrols; i++)
> cur_to_new(master->cluster[i]);
> if (!call_op(master, g_volatile_ctrl))
> for (i = 1; i < master->ncontrols; i++)
> 

I agree, this is the right fix.

> 
> We can assume that the master control in an auto cluster is always the
> first one, can't we? With the change above we don't override the new
> value of the master control, in this case when it's being changed from
> auto to manual.
> 
> I may be missing some details tho, so I am asking if my reasoning is
> correct before sending a proper patch. And should I CC stable on it as
> the change fixes a regression?

Just post the patch to linux-media, but add this line after your Signed-off-by:

Cc:   # for v3.17 and up

Thanks for looking at this!

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to 

Re: H264 headers generation for driver

[Hans Verkuil]

On 09/29/2015 08:59 PM, Andrey Utkin wrote:
> This is a new chapter of tw5864 video grabber & encoder driver
> development drama.
> Last state of code is here (tw5864 branch, drivers/staging/media/tw5864):
> https://github.com/bluecherrydvr/linux/tree/tw5864/drivers/staging/media/tw5864
> 
> Currently I use a third-side LGPL library for H.264 headers generation
> - SPS, PPS and slice headers (because device doesn't generate them).
> It is included as a git submodule "h264bitstream". It is used from
> tw5864-h264.c .
> Of course we want our driver to get to upstream repository when it
> matures enough, that's why we want to ask for advice regarding this.
> I see that there is no similar case in upstream kernel repo - no
> submodules and no libraries for H264 bitstreams.
> Device datasheet
> (http://lizard.bluecherry.net/~autkin/tw5864/tw5864b1-ds.pdf , page
> 47) shows that there's almost no variety of modes, so minimally an
> implementation of bitstream writing functions ue() and se() will
> suffice.
> I guess that one acceptable way is to pre-generate all headers for all
> needed cases and ship them inlined; for correctness checking purpose,
> it is possible to ship also a script or additional source code file
> which is able to generate same headers.
> Please advise.
> 
> Thanks in advance for any kind reply.
> 

You can do something like this:

drivers/media/platform/vivid/vivid-tpg-colors.c

Both the generated tables and the code that generates them are in one
file.

An alternative is to add a source to v4l2-core that generates the tables,
but I don't know if that is feasible (i.e., if it can be made sufficiently
generic).

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] ADV7604: VGA support

[Hans Verkuil]

On 10/04/2015 06:17 PM, Jean-Michel Hautbois wrote:
> Hi,
> 
> I had another look into the ADV7604 HW manual, and I understand that
> in automatic mode, there is 4 AIN_SEL values possible, determining the
> connection on AIN pins.
> Now, having a look at the current ADV76xx files, I can see that two
> pads are there :
> ADV7604_PAD_VGA_RGB and ADV7604_PAD_VGA_COMP.
> 
> According to the manual, my understanding is that we should have four
> HDMI pads and four analog pads. The latter would be configured as RGB
> or component, which allows four analog inputs as described in the HW
> manual.

When I wrote the driver we only needed one VGA input receiving either RGB
or YCbCr. Hence there is only one analog input and two pads. I wouldn't have
been able to test the additional analog inputs anyway.

I chose to use pads to select between the two modes, but that's something
that can be changed (it's not something you can autodetect, unfortunately).

If you want to add support for all four analog inputs, then feel free to
do so.

Regards,

Hans

> 
> I don't know if you agree with that or if you had something else in
> mind when designing it in the first place, I may have missed something
> (Lars :) ?).
> 
> Thanks,
> JM
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l2 api: supported resolution negotiation

[Hans Verkuil]

On 10/04/2015 08:49 PM, Sakari Ailus wrote:
> On Sun, Oct 04, 2015 at 12:23:08PM +0300, Matwey V. Kornilov wrote:
>> Hello,
>>
>> I learned from V2L2 API how to detect all supported formats using
>> VIDIOC_ENUM_FMT.
>> When I perform VIDIOC_S_FMT I don't know how to fill fmt.pix.width and
>> fmt.pix.height, since I know only format.
>> How should I negotiate device resolution? Could you point me?
> 
> VIDIOC_ENUM_FRAMESIZES may give you hints, but it's optional. You can use
> values you prefer to try if drivers support them; I think the GStreamer
> v4lsrc tries very small and very large values. The driver will clamp them to
> a supported values which are passed to the application from the IOCTL.
> 
> 
> 

You can also call G_FMT first, then change the pixelformat and call S_FMT.
This will only change the pixelformat and leave the resolution the same (unless
the driver has some restrictions for the new pixelformat, but that's unlikely).

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

[Hans Verkuil]

On 10/06/2015 01:11 AM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
>> +cec->adap = cec_create_adapter(_cec_adap_ops, cec,
>> +CEC_NAME, CEC_CAP_STATE |
>> +CEC_CAP_PHYS_ADDR | CEC_CAP_LOG_ADDRS | CEC_CAP_IO |
>> +CEC_CAP_IS_SOURCE,
>> +0, THIS_MODULE, >dev);
>> +ret = PTR_ERR_OR_ZERO(cec->adap);
>> +if (ret)
>> +return ret;
>> +cec->adap->available_log_addrs = 1;
>> +
>> +platform_set_drvdata(pdev, cec);
>> +pm_runtime_enable(dev);
> 
> This is really not a good interface.
> 
> "cec_create_adapter" creates and registers the adapter, at which point it
> becomes available to userspace.  However, you haven't finished setting it
> up, so it's possible to nip in here and start using it before the setup
> has completed.  This needs fixing.
> 

Good point, I'll split off the registration part into a separate function.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gspca/ov534 gets two failures with v4l2-compliance

[Hans Verkuil]

On 10/03/2015 04:44 PM, Antonio Ospite wrote:
> Hi,
> 
> I tried running v4l2-compliance with the PS3 Eye and I got these two
> failures:
> 
> ...
> Test input 0:
> ...
> Format ioctls:
> fail: v4l2-test-formats.cpp(122): found frame intervals for 
> invalid size 321x240
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL
> test VIDIOC_G/S_PARM: OK
> test VIDIOC_G_FBUF: OK (Not Supported)
> fail: v4l2-test-formats.cpp(425): unknown pixelformat 
> 56595559 for buftype 1
> test VIDIOC_G_FMT: FAIL
> test VIDIOC_TRY_FMT: OK (Not Supported)
> test VIDIOC_S_FMT: OK (Not Supported)
> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> test Cropping: OK (Not Supported)
> test Composing: OK (Not Supported)
> test Scaling: OK
> 
> About the first failure: by looking at the kernel code in gspca.c it
> looks like the supported frame sizes are declared as
> V4L2_FRMSIZE_TYPE_DISCRETE in vidioc_enum_framesizes(), but then the
> driver accepts invalid ones when listing frameintervals trying to find
> the "closest" size for width and height using wxh_to_mode().
> 
> Can this discrepancy be what makes v4l2-compliance fail?

Yes, that's the reason it fails.

> 
> If you think it's OK to change the gspca behavior to be stricter about
> what frame sizes are considered valid, I may take a shot at it.

I would say this is OK to change. UVC is also strict about this, so apps should
do this correct, otherwise they would fail with uvc webcams.

> By looking at the v4l2-compliance code I think the second failure will
> go away once the first one is fixed: node->buftype_pixfmts does not get
> populated because of the first failure.

Correct.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

[Hans Verkuil]

On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
>> +if (status & CEC_STATUS_TX_DONE) {
>> +if (status & CEC_STATUS_TX_ERROR) {
>> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
>> +cec->tx = STATE_ERROR;
>> +} else {
>> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
>> +cec->tx = STATE_DONE;
>> +}
>> +s5p_clr_pending_tx(cec);
>> +}
> 
> Your CEC implementation seems to be written around the idea that there
> are only two possible outcomes from a CEC message - "done" and "error",
> which get translated to:

This code is for the Samsung exynos CEC implementation. Marek, is this all
that the exynos CEC hardware returns?

> 
>> +case STATE_DONE:
>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
>> +cec->tx = STATE_IDLE;
>> +break;
>> +case STATE_ERROR:
>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
>> +cec->tx = STATE_IDLE;
> 
> "okay" and "retry_timeout".  So, if we have an adapter which can report
> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
> Why this obscure naming - why can't we have something that uses the
> terminology in the spec?
> 

Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC 7.1.
The assumption of the CEC framework is that this is done by the CEC adapter
driver, not by the framework. So if after repeated retransmissions there is
still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
change this to _MAX_RETRIES_REACHED if you prefer.

The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] media: Correctly determine whether an entity is a sub-device

[Sakari Ailus]

If the function of an entity is not one of the pre-defined ones, it is not
correctly recognised as a V4L2 sub-device.

Signed-off-by: Sakari Ailus 
---
 include/media/media-entity.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index a60872a..76e9a124 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -328,6 +328,7 @@ static inline bool is_media_entity_v4l2_subdev(struct 
media_entity *entity)
case MEDIA_ENT_F_LENS:
case MEDIA_ENT_F_ATV_DECODER:
case MEDIA_ENT_F_TUNER:
+   case MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN:
return true;
 
default:
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] media: Correctly determine whether an entity is a sub-device

[Mauro Carvalho Chehab]

Em Mon, 12 Oct 2015 18:38:23 +0300
Sakari Ailus  escreveu:

> If the function of an entity is not one of the pre-defined ones, it is not
> correctly recognised as a V4L2 sub-device.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  include/media/media-entity.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index a60872a..76e9a124 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -328,6 +328,7 @@ static inline bool is_media_entity_v4l2_subdev(struct 
> media_entity *entity)
>   case MEDIA_ENT_F_LENS:
>   case MEDIA_ENT_F_ATV_DECODER:
>   case MEDIA_ENT_F_TUNER:
> + case MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN:
>   return true;

OK.

Reviewed-by: Mauro Carvalho Chehab 

>  
>   default:
--
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: Current status of MC patches?

[Sakari Ailus]

Hi Mauro and Hans,

On Mon, Oct 12, 2015 at 12:11:53PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 12 Oct 2015 15:08:33 +0200
> Hans Verkuil  escreveu:
> 
> > Hi Mauro,
> > 
> > Can you give an update of the current status of the MC work? To be honest,
> > I've lost track.
> > 
> > In particular, is there anything I and/or others need to review before you
> > can start merging patches?
> 
> Basically, we're still waiting for Laurent and Sakari's review.

Could you resend what you have to the list, please? Currently it's a number
of sets some of which contain updates only on particular patches. It'd be
easier to review that way.

I've been working on top of the set to add support for unlimited number of
entities, so unfortunately I've had less time for reviews. These patches are
still required before the rest can be applied so I've priorised them.

> > This is also relevant for the workshop agenda. I plan to put any MC topics
> > at the end of the workshop. As you mentioned in a mail exchange with Shuah,
> > as long as these patches aren't merged there is not all that much point in
> > discussing future work.
> 
> Yep. There's no sense to even discuss MC at the workshop while the
> current work is not reviewed, as the other MC topic for discussion
> is related to dynamic support, to be added after the MC next gen
> support for G_TOPOLOGY.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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: Current status of MC patches?

[Mauro Carvalho Chehab]

Em Mon, 12 Oct 2015 18:20:49 +0200
Hans Verkuil  escreveu:

> On 10/12/2015 05:56 PM, Sakari Ailus wrote:
> > Hi Mauro and Hans,
> > 
> > On Mon, Oct 12, 2015 at 12:11:53PM -0300, Mauro Carvalho Chehab wrote:
> >> Em Mon, 12 Oct 2015 15:08:33 +0200
> >> Hans Verkuil  escreveu:
> >>
> >>> Hi Mauro,
> >>>
> >>> Can you give an update of the current status of the MC work? To be honest,
> >>> I've lost track.
> >>>
> >>> In particular, is there anything I and/or others need to review before you
> >>> can start merging patches?
> >>
> >> Basically, we're still waiting for Laurent and Sakari's review.
> > 
> > Could you resend what you have to the list, please? Currently it's a number
> > of sets some of which contain updates only on particular patches. It'd be
> > easier to review that way.
> 
> I would actually appreciate that as well. That way I can see which patches I
> have and which I haven't reviewed.
> 
> If you don't want to spam the ml, then you can also send it directly, but I
> think it is OK to include the ml. Up to you, though.

Let me send the patches then to the Workshop ML. There are 83 patches.
That's too many to flood at the main list, specially since all patches
there are already at the main ML.

Regards,
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

Re: [PATCH v8 32/55] [media] media: use macros to check for V4L2 subdev entities

[Sakari Ailus]

Hi Mauro,

On Sun, Oct 11, 2015 at 09:56:25PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 12 Oct 2015 00:07:52 +0300
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > On Sun, Aug 30, 2015 at 12:06:43AM -0300, Mauro Carvalho Chehab wrote:
> > > Instead of relying on media subtype, use the new macros to detect
> > > if an entity is a subdev or an A/V DMA entity.
> > > 
> > > Please note that most drivers assume that there's just AV_DMA or
> > > V4L2 subdevs. This is not true anymore, as we've added MC support
> > > for DVB, and there are plans to add support for ALSA and FB/DRM
> > > too.
> > > 
> > > Ok, on the current pipelines supported by those drivers, just V4L
> > > stuff are there, but, assuming that some day a pipeline that also
> > > works with other subsystems will ever added, it is better to add
> > > explicit checks for the AV_DMA stuff.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab 
> > > 
> > > diff --git a/drivers/media/platform/exynos4-is/common.c 
> > > b/drivers/media/platform/exynos4-is/common.c
> > > index 0eb34ecb8ee4..8c9a29e0e294 100644
> > > --- a/drivers/media/platform/exynos4-is/common.c
> > > +++ b/drivers/media/platform/exynos4-is/common.c
> > > @@ -22,8 +22,7 @@ struct v4l2_subdev *fimc_find_remote_sensor(struct 
> > > media_entity *entity)
> > >   while (pad->flags & MEDIA_PAD_FL_SINK) {
> > >   /* source pad */
> > >   pad = media_entity_remote_pad(pad);
> > > - if (pad == NULL ||
> > > - media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > > + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > >   break;
> > >  
> > >   sd = media_entity_to_v4l2_subdev(pad->entity);
> > > diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c 
> > > b/drivers/media/platform/exynos4-is/fimc-capture.c
> > > index 0627a93b2f3b..e9810fee4c30 100644
> > > --- a/drivers/media/platform/exynos4-is/fimc-capture.c
> > > +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
> > > @@ -1141,8 +1141,7 @@ static int fimc_pipeline_validate(struct fimc_dev 
> > > *fimc)
> > >   }
> > >   }
> > >  
> > > - if (src_pad == NULL ||
> > > - media_entity_type(src_pad->entity) != 
> > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > + if (!src_pad || !is_media_entity_v4l2_subdev(src_pad->entity))
> > >   break;
> > >  
> > >   /* Don't call FIMC subdev operation to avoid nested locking */
> > > @@ -1397,7 +1396,7 @@ static int fimc_link_setup(struct media_entity 
> > > *entity,
> > >   struct fimc_vid_cap *vc = >vid_cap;
> > >   struct v4l2_subdev *sensor;
> > >  
> > > - if (media_entity_type(remote->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > > + if (!is_media_entity_v4l2_subdev(remote->entity))
> > >   return -EINVAL;
> > >  
> > >   if (WARN_ON(fimc == NULL))
> > > diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c 
> > > b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > index 3d9ccbf5f10f..5fbaf5e39903 100644
> > > --- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > @@ -467,8 +467,7 @@ static int isp_video_pipeline_validate(struct 
> > > fimc_isp *isp)
> > >  
> > >   /* Retrieve format at the source pad */
> > >   pad = media_entity_remote_pad(pad);
> > > - if (pad == NULL ||
> > > - media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > > + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > >   break;
> > >  
> > >   sd = media_entity_to_v4l2_subdev(pad->entity);
> > > diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
> > > b/drivers/media/platform/exynos4-is/fimc-lite.c
> > > index b2607da4ad14..c2327147b360 100644
> > > --- a/drivers/media/platform/exynos4-is/fimc-lite.c
> > > +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
> > > @@ -814,8 +814,7 @@ static int fimc_pipeline_validate(struct fimc_lite 
> > > *fimc)
> > >   }
> > >   /* Retrieve format at the source pad */
> > >   pad = media_entity_remote_pad(pad);
> > > - if (pad == NULL ||
> > > - media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> > > + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > >   break;
> > >  
> > >   sd = media_entity_to_v4l2_subdev(pad->entity);
> > > @@ -988,7 +987,6 @@ static int fimc_lite_link_setup(struct media_entity 
> > > *entity,
> > >  {
> > >   struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> > >   struct fimc_lite *fimc = v4l2_get_subdevdata(sd);
> > > - unsigned int remote_ent_type = media_entity_type(remote->entity);
> > >   int ret = 0;
> > >  
> > >   if (WARN_ON(fimc == NULL))
> > > @@ -1000,7 +998,7 @@ static int fimc_lite_link_setup(struct media_entity 
> > > *entity,
> > >  
> > >   switch 

Re: [PATCHv5 10/13] hackrf: add support for transmitter

[Sebastian Reichel]

Hi,

On Sun, Oct 11, 2015 at 05:42:05PM +0300, Antti Palosaari wrote:
> Moikka!
> IMHO it is false positive. Variable which is defined on line 777 is used
> just few lines later on line 782 as can be seen easily. I think it is
> because option CONFIG_DYNAMIC_DEBUG is not set => dev_dbg_ratelimited()
> macro is likely just NOP and gives that warning. Maybe some more logic to is
> needed in order to avoid that kind of warnings.

You can flag it with __maybe_unused:

struct usb_interface __maybe_unused *intf = dev->intf;

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH v8 32/55] [media] media: use macros to check for V4L2 subdev entities

[Mauro Carvalho Chehab]

Em Mon, 12 Oct 2015 18:35:05 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Sun, Oct 11, 2015 at 09:56:25PM -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 12 Oct 2015 00:07:52 +0300
> > Sakari Ailus  escreveu:
> > 
> > > Hi Mauro,
> > > 
> > > On Sun, Aug 30, 2015 at 12:06:43AM -0300, Mauro Carvalho Chehab wrote:
> > > > Instead of relying on media subtype, use the new macros to detect
> > > > if an entity is a subdev or an A/V DMA entity.
> > > > 
> > > > Please note that most drivers assume that there's just AV_DMA or
> > > > V4L2 subdevs. This is not true anymore, as we've added MC support
> > > > for DVB, and there are plans to add support for ALSA and FB/DRM
> > > > too.
> > > > 
> > > > Ok, on the current pipelines supported by those drivers, just V4L
> > > > stuff are there, but, assuming that some day a pipeline that also
> > > > works with other subsystems will ever added, it is better to add
> > > > explicit checks for the AV_DMA stuff.
> > > > 
> > > > Signed-off-by: Mauro Carvalho Chehab 
> > > > 
> > > > diff --git a/drivers/media/platform/exynos4-is/common.c 
> > > > b/drivers/media/platform/exynos4-is/common.c
> > > > index 0eb34ecb8ee4..8c9a29e0e294 100644
> > > > --- a/drivers/media/platform/exynos4-is/common.c
> > > > +++ b/drivers/media/platform/exynos4-is/common.c
> > > > @@ -22,8 +22,7 @@ struct v4l2_subdev *fimc_find_remote_sensor(struct 
> > > > media_entity *entity)
> > > > while (pad->flags & MEDIA_PAD_FL_SINK) {
> > > > /* source pad */
> > > > pad = media_entity_remote_pad(pad);
> > > > -   if (pad == NULL ||
> > > > -   media_entity_type(pad->entity) != 
> > > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > > +   if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > > > break;
> > > >  
> > > > sd = media_entity_to_v4l2_subdev(pad->entity);
> > > > diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c 
> > > > b/drivers/media/platform/exynos4-is/fimc-capture.c
> > > > index 0627a93b2f3b..e9810fee4c30 100644
> > > > --- a/drivers/media/platform/exynos4-is/fimc-capture.c
> > > > +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
> > > > @@ -1141,8 +1141,7 @@ static int fimc_pipeline_validate(struct fimc_dev 
> > > > *fimc)
> > > > }
> > > > }
> > > >  
> > > > -   if (src_pad == NULL ||
> > > > -   media_entity_type(src_pad->entity) != 
> > > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > > +   if (!src_pad || 
> > > > !is_media_entity_v4l2_subdev(src_pad->entity))
> > > > break;
> > > >  
> > > > /* Don't call FIMC subdev operation to avoid nested 
> > > > locking */
> > > > @@ -1397,7 +1396,7 @@ static int fimc_link_setup(struct media_entity 
> > > > *entity,
> > > > struct fimc_vid_cap *vc = >vid_cap;
> > > > struct v4l2_subdev *sensor;
> > > >  
> > > > -   if (media_entity_type(remote->entity) != 
> > > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > > +   if (!is_media_entity_v4l2_subdev(remote->entity))
> > > > return -EINVAL;
> > > >  
> > > > if (WARN_ON(fimc == NULL))
> > > > diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c 
> > > > b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > > index 3d9ccbf5f10f..5fbaf5e39903 100644
> > > > --- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > > +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > > > @@ -467,8 +467,7 @@ static int isp_video_pipeline_validate(struct 
> > > > fimc_isp *isp)
> > > >  
> > > > /* Retrieve format at the source pad */
> > > > pad = media_entity_remote_pad(pad);
> > > > -   if (pad == NULL ||
> > > > -   media_entity_type(pad->entity) != 
> > > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > > +   if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > > > break;
> > > >  
> > > > sd = media_entity_to_v4l2_subdev(pad->entity);
> > > > diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
> > > > b/drivers/media/platform/exynos4-is/fimc-lite.c
> > > > index b2607da4ad14..c2327147b360 100644
> > > > --- a/drivers/media/platform/exynos4-is/fimc-lite.c
> > > > +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
> > > > @@ -814,8 +814,7 @@ static int fimc_pipeline_validate(struct fimc_lite 
> > > > *fimc)
> > > > }
> > > > /* Retrieve format at the source pad */
> > > > pad = media_entity_remote_pad(pad);
> > > > -   if (pad == NULL ||
> > > > -   media_entity_type(pad->entity) != 
> > > > MEDIA_ENT_T_V4L2_SUBDEV)
> > > > +   if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> > > > break;
> > > >  
> > > >

Re: Current status of MC patches?

[Hans Verkuil]

On 10/12/2015 05:56 PM, Sakari Ailus wrote:
> Hi Mauro and Hans,
> 
> On Mon, Oct 12, 2015 at 12:11:53PM -0300, Mauro Carvalho Chehab wrote:
>> Em Mon, 12 Oct 2015 15:08:33 +0200
>> Hans Verkuil  escreveu:
>>
>>> Hi Mauro,
>>>
>>> Can you give an update of the current status of the MC work? To be honest,
>>> I've lost track.
>>>
>>> In particular, is there anything I and/or others need to review before you
>>> can start merging patches?
>>
>> Basically, we're still waiting for Laurent and Sakari's review.
> 
> Could you resend what you have to the list, please? Currently it's a number
> of sets some of which contain updates only on particular patches. It'd be
> easier to review that way.

I would actually appreciate that as well. That way I can see which patches I
have and which I haven't reviewed.

If you don't want to spam the ml, then you can also send it directly, but I
think it is OK to include the ml. Up to you, though.

Regards,

Hans

> 
> I've been working on top of the set to add support for unlimited number of
> entities, so unfortunately I've had less time for reviews. These patches are
> still required before the rest can be applied so I've priorised them.
> 
>>> This is also relevant for the workshop agenda. I plan to put any MC topics
>>> at the end of the workshop. As you mentioned in a mail exchange with Shuah,
>>> as long as these patches aren't merged there is not all that much point in
>>> discussing future work.
>>
>> Yep. There's no sense to even discuss MC at the workshop while the
>> current work is not reviewed, as the other MC topic for discussion
>> is related to dynamic support, to be added after the MC next gen
>> support for G_TOPOLOGY.
> 

--
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 v6 0/4] Refactoring Videobuf2 for common use

[Hans Verkuil]

Hi Junghak,

I've accepted this v6 series and made a pull request for Mauro.

I am still not happy about the queue_setup patch, but that can be changed
later.

Regards,

Hans

On 10/06/2015 11:37 AM, Junghak Sung wrote:
> Hello everybody,
> 
> This is the 6th round for refactoring Videobuf2(a.k.a VB2).
> The purpose of this patch series is to separate existing VB2 framework
> into core part and V4L2 specific part. So that not only V4L2 but also other
> frameworks can use them to manage buffer and utilize queue.
> 
> Why do we try to make the VB2 framework to be common?
> 
> As you may know, current DVB framework uses ringbuffer mechanism to demux
> MPEG-2 TS data and pass it to userspace. However, this mechanism requires
> extra memory copy because DVB framework provides only read() system call for
> application - read() system call copies the kernel data to user-space buffer.
> So if we can use VB2 framework which supports streaming I/O and buffer
> sharing mechanism, then we could enhance existing DVB framework by removing
> the extra memory copy - with VB2 framework, application can access the kernel
> data directly through mmap system call.
> 
> We have a plan for this work as follows:
> 1. Separate existing VB2 framework into three parts - VB2 core, VB2 v4l2.
>Of course, this change will not affect other v4l2-based
>device drivers. This patch series corresponds to this step.
> 
> 2. Add and implement new APIs for DVB streaming I/O.
>We can remove unnecessary memory copy between kernel-space and user-space
>by using these new APIs. However, we leaves legacy interfaces as-is
>for backward compatibility.
> 
> This patch series is the first step for it.
> The previous version of this patch series can be found at belows.
> 
> [1] RFC PATCH v1 - http://www.spinics.net/lists/linux-media/msg90688.html
> [2] RFC PATCH v2 - http://www.spinics.net/lists/linux-media/msg92130.html
> [3] RFC PATCH v3 - http://www.spinics.net/lists/linux-media/msg92953.html
> [4] RFC PATCH v4 - http://www.spinics.net/lists/linux-media/msg93421.html
> [5] RFC PATCH v5 - http://www.spinics.net/lists/linux-media/msg93810.html
> 
> Changes since v5
> 1. v5 is merged partially to media_tree
> 4 of 8 patches - restructuring vb2_buffer for common use - are merged to
> media_tree. So, v6 is rebased on later version than that.
> 
> 2. vb2_format is reverted to void *
> vb2_format - which is newly defined for queue_setup() in v5 to deliver
> the format information from user-space to device driver - is reverted to
> void pointer. This change requires more discussion about the way to do
> the format validation and decide the image size.
> So, in this version, I would like to revert it to original version.
> 
> 3. The change related with v4l2_buf_ops is moved
> The change related with v4l2_buf_ops seems to be a sort of functional change.
> So, it was moved to patch 3/4 - which includes the most of functional changes.
> 
> 
> Changes since v4
> 1. Rebase on 4.3-rc1
> Kernel 4.3-rc1 was released. So, this patch set is made based on
> that version.
> 
> 2. Modify queue_setup() argument
> In previous patch set, struct v4l2_format, which is a parameter of
> queue_setup(), is abstracted by using void pointer. But, it is better way to
> pass the parameter with presise meaning than abstracting it.
> So, replace void * with struct vb2_format which is newly defined to contain
> the format information for common use.
> 
> 3. Add a code to check if VB2_MAX_* match with VIDEO_MAX_*
> Add a check code to videobuf2-v4l2.c where the compiler compares 
> VIDEO_MAX_FRAME
> and VB2_MAX_FRAME (and ditto for MAX_PLANES) and throws an #error if they
> do not match.
> 
> 4. Change the commit order
> For easier review, the patch that just move things around without doing any
> functional change is moved to the last.
> 
> All ideas above are from Hans and it seems to be better and right way.
> 
> 
> Changes since v3
> 
> 1. Resolve build errors
> In previous patch set, the build errors prevented reviewers from applying
> the patch. So, in this patch, I tryed to fix the build errors but I hadn't
> the build test on all architectures except for x86 and ARM.
> 
> 2. Modify descriptions for DocBook
> Descriptions not complying with the DocBook rule are modified,
> which was pointed out by Mauro.
> 
> 3. Initialize reserved fields explicitly
> The reserved fields of v4l2_buffer are initialized by 0 explicitly
> when the vb2_buffer information is returned to userspace,
> which was pointed out by Hans.
> 
> 4. Remove unnecessary type-cast
> According to Mauro's advice, the unnecessary type-cast are removed
> because it's better for the compiler - rather than human - to check those
> things.
> 
> 5. Sperate the patch - not easy to review - into two patches
> In previous patch set, patch 5 was too difficult to review. So accoring to
> Hans' opinion, it separated the patch without any functional changes.
> 
> 
> Changes since v2
> 
> 1. Remove v4l2 

Current status of MC patches?

[Hans Verkuil]

Hi Mauro,

Can you give an update of the current status of the MC work? To be honest,
I've lost track.

In particular, is there anything I and/or others need to review before you
can start merging patches?

This is also relevant for the workshop agenda. I plan to put any MC topics
at the end of the workshop. As you mentioned in a mail exchange with Shuah,
as long as these patches aren't merged there is not all that much point in
discussing future work.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv9 06/15] rc: Add HDMI CEC protocol handling

[Hans Verkuil]

On 10/06/2015 08:05 PM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote:
>> From: Kamil Debski 
>>
>> Add handling of remote control events coming from the HDMI CEC bus.
>> This patch includes a new keymap that maps values found in the CEC
>> messages to the keys pressed and released. Also, a new protocol has
>> been added to the core.
>>
>> Signed-off-by: Kamil Debski 
>> Signed-off-by: Hans Verkuil 
> 
> (Added Mauro)
> 
> Hmm, how is rc-cec supposed to be loaded?

Is CONFIG_RC_MAP enabled in your config? Ran 'depmod -a'? (Sorry, I'm sure 
you've done
that, just checking...)

It's optional as I understand it, since you could configure the keytable from
userspace instead of using this module.

For the record (just tried it), it does load fine on my setup.

BTW, I am still on the fence whether using the kernel RC subsystem is the
right thing to do. There are a number of CEC RC commands that use extra 
parameters
that cannot be mapped to the RC API, so you still need to handle those manually.

I know Mauro would like to see this integration, but I am wondering whether it
really makes sense.

What is your opinion on this?

Perhaps I should split it off into a separate patch and keep it out from the 
initial
pull request once we're ready for that.

Regards,

Hans

> 
> At boot, I see:
> 
> [   16.577704] IR keymap rc-cec not found
> [   16.586675] Registered IR keymap rc-empty
> [   16.591668] input: RC for dw_hdmi as 
> /devices/soc0/soc/12.hdmi/rc/rc1/input3
> [   16.597769] rc1: RC for dw_hdmi as /devices/soc0/soc/12.hdmi/rc/rc1
> 
> Yet the rc-cec is a module in the filesystem, but it doesn't seem to
> be loaded automatically - even after the system has booted, the module
> hasn't been loaded.
> 
> It looks like it _should_ be loaded, but this plainly isn't working:
> 
> map = seek_rc_map(name);
> #ifdef MODULE
> if (!map) {
> int rc = request_module("%s", name);
> if (rc < 0) {
> printk(KERN_ERR "Couldn't load IR keymap %s\n", name);
> return NULL;
> }
> msleep(20); /* Give some time for IR to register */
> 
> map = seek_rc_map(name);
> }
> #endif
> if (!map) {
> printk(KERN_ERR "IR keymap %s not found\n", name);
> return NULL;
> }
> 
> Any ideas?
> 

--
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: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

[Kamil Debski]

Hi,

On 12 October 2015 at 12:50, Hans Verkuil  wrote:
> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
>> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
>>> +if (status & CEC_STATUS_TX_DONE) {
>>> +if (status & CEC_STATUS_TX_ERROR) {
>>> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
>>> +cec->tx = STATE_ERROR;
>>> +} else {
>>> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
>>> +cec->tx = STATE_DONE;
>>> +}
>>> +s5p_clr_pending_tx(cec);
>>> +}
>>
>> Your CEC implementation seems to be written around the idea that there
>> are only two possible outcomes from a CEC message - "done" and "error",
>> which get translated to:
>
> This code is for the Samsung exynos CEC implementation. Marek, is this all
> that the exynos CEC hardware returns?

The possible status values that are implemented in the CEC framework
are following:

+/* cec status field */
+#define CEC_TX_STATUS_OK   (0)
+#define CEC_TX_STATUS_ARB_LOST (1 << 0)
+#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
+#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
+#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
+#define CEC_RX_STATUS_READY(0)

The only two ones I could match with the Exynos CEC module status bits are
CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.

The status bits in Exynos HW are:
- Tx_Error
- Tx_Done
- Tx_Transferring
- Tx_Running
- Tx_Bytes_Transferred

- Tx_Wait
- Tx_Sending_Status_Bit
- Tx_Sending_Hdr_Blk
- Tx_Sending_Data_Blk
- Tx_Latest_Initiator

- Tx_Wait_SFT_Succ
- Tx_Wait_SFT_New
- Tx_Wait_SFT_Retran
- Tx_Retrans_Cnt
- Tx_ACK_Failed

>
>>
>>> +case STATE_DONE:
>>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
>>> +cec->tx = STATE_IDLE;
>>> +break;
>>> +case STATE_ERROR:
>>> +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
>>> +cec->tx = STATE_IDLE;
>>
>> "okay" and "retry_timeout".  So, if we have an adapter which can report
>> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
>> Why this obscure naming - why can't we have something that uses the
>> terminology in the spec?
>>
>
> Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC 
> 7.1.
> The assumption of the CEC framework is that this is done by the CEC adapter
> driver, not by the framework. So if after repeated retransmissions there is
> still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
> change this to _MAX_RETRIES_REACHED if you prefer.
>
> The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
> for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).
>
> Regards,
>
> Hans

Best wishes,
Kamil
--
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: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

[Hans Verkuil]

On 10/12/2015 02:33 PM, Kamil Debski wrote:
> Hi,
> 
> On 12 October 2015 at 12:50, Hans Verkuil  wrote:
>> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
>>> On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
 +if (status & CEC_STATUS_TX_DONE) {
 +if (status & CEC_STATUS_TX_ERROR) {
 +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
 +cec->tx = STATE_ERROR;
 +} else {
 +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
 +cec->tx = STATE_DONE;
 +}
 +s5p_clr_pending_tx(cec);
 +}
>>>
>>> Your CEC implementation seems to be written around the idea that there
>>> are only two possible outcomes from a CEC message - "done" and "error",
>>> which get translated to:
>>
>> This code is for the Samsung exynos CEC implementation. Marek, is this all
>> that the exynos CEC hardware returns?
> 
> The possible status values that are implemented in the CEC framework
> are following:
> 
> +/* cec status field */
> +#define CEC_TX_STATUS_OK   (0)
> +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
> +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
> +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
> +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
> +#define CEC_RX_STATUS_READY(0)
> 
> The only two ones I could match with the Exynos CEC module status bits are
> CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.
> 
> The status bits in Exynos HW are:
> - Tx_Error
> - Tx_Done
> - Tx_Transferring
> - Tx_Running
> - Tx_Bytes_Transferred
> 
> - Tx_Wait
> - Tx_Sending_Status_Bit
> - Tx_Sending_Hdr_Blk
> - Tx_Sending_Data_Blk
> - Tx_Latest_Initiator
> 
> - Tx_Wait_SFT_Succ
> - Tx_Wait_SFT_New
> - Tx_Wait_SFT_Retran
> - Tx_Retrans_Cnt
> - Tx_ACK_Failed

So are these all intermediate states? And every transfer always ends with 
Tx_Done or
Tx_Error state?

It does look that way...

Regards,

Hans

> 
>>
>>>
 +case STATE_DONE:
 +cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
 +cec->tx = STATE_IDLE;
 +break;
 +case STATE_ERROR:
 +cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
 +cec->tx = STATE_IDLE;
>>>
>>> "okay" and "retry_timeout".  So, if we have an adapter which can report
>>> (eg) a NACK, we have to report it as the obscure "retry timeout" status?
>>> Why this obscure naming - why can't we have something that uses the
>>> terminology in the spec?
>>>
>>
>> Actually, a NACK should lead to a re-transmission (up to 5 times), see CEC 
>> 7.1.
>> The assumption of the CEC framework is that this is done by the CEC adapter
>> driver, not by the framework. So if after repeated retransmissions there is
>> still no Ack, the CEC_TX_STATUS_RETRY_TIMEOUT error is returned. I could
>> change this to _MAX_RETRIES_REACHED if you prefer.
>>
>> The CEC_TX_STATUS_ macros were based on what the adv drivers support (except
>> for CEC_TX_STATUS_REPLY_TIMEOUT which is specific to the framework).
>>
>> Regards,
>>
>> Hans
> 
> Best wishes,
> Kamil
> 

--
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: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

[Kamil Debski]

Hi,

On 12 October 2015 at 14:39, Hans Verkuil  wrote:
> On 10/12/2015 02:33 PM, Kamil Debski wrote:
>> Hi,
>>
>> On 12 October 2015 at 12:50, Hans Verkuil  wrote:
>>> On 10/06/2015 12:32 AM, Russell King - ARM Linux wrote:
 On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
> +if (status & CEC_STATUS_TX_DONE) {
> +if (status & CEC_STATUS_TX_ERROR) {
> +dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
> +cec->tx = STATE_ERROR;
> +} else {
> +dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
> +cec->tx = STATE_DONE;
> +}
> +s5p_clr_pending_tx(cec);
> +}

 Your CEC implementation seems to be written around the idea that there
 are only two possible outcomes from a CEC message - "done" and "error",
 which get translated to:
>>>
>>> This code is for the Samsung exynos CEC implementation. Marek, is this all
>>> that the exynos CEC hardware returns?
>>
>> The possible status values that are implemented in the CEC framework
>> are following:
>>
>> +/* cec status field */
>> +#define CEC_TX_STATUS_OK   (0)
>> +#define CEC_TX_STATUS_ARB_LOST (1 << 0)
>> +#define CEC_TX_STATUS_RETRY_TIMEOUT(1 << 1)
>> +#define CEC_TX_STATUS_FEATURE_ABORT(1 << 2)
>> +#define CEC_TX_STATUS_REPLY_TIMEOUT(1 << 3)
>> +#define CEC_RX_STATUS_READY(0)
>>
>> The only two ones I could match with the Exynos CEC module status bits are
>> CEC_TX_STATUS_OK and  CEC_TX_STATUS_RETRY_TIMEOUT.
>>
>> The status bits in Exynos HW are:
>> - Tx_Error
>> - Tx_Done
>> - Tx_Transferring
>> - Tx_Running
>> - Tx_Bytes_Transferred
>>
>> - Tx_Wait
>> - Tx_Sending_Status_Bit
>> - Tx_Sending_Hdr_Blk
>> - Tx_Sending_Data_Blk
>> - Tx_Latest_Initiator
>>
>> - Tx_Wait_SFT_Succ
>> - Tx_Wait_SFT_New
>> - Tx_Wait_SFT_Retran
>> - Tx_Retrans_Cnt
>> - Tx_ACK_Failed
>
> So are these all intermediate states? And every transfer always ends with 
> Tx_Done or
> Tx_Error state?

Yes, the Exynos CEC module has a pretty low level status indicator.

> It does look that way...
>
> Regards,
>
> Hans
>

Best wishes,
Kamil

[snip]
--
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

[GIT PULL FOR v4.4] Split the vb2 code into a v4l2 and core part

[Hans Verkuil]

The following changes since commit efe98010b80ec4516b2779e1b4e4a8ce16bf89fe:

  [media] DocBook: Fix remaining issues with VB2 core documentation (2015-10-05 
09:12:56 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git vb2-split

for you to fetch changes up to d9b227c16a31f9cd9296376e7cf39f2e460bf3ce:

  media: videobuf2: Move v4l2-specific stuff to videobuf2-v4l2 (2015-10-12 
14:37:23 +0200)


Junghak Sung (4):
  media: videobuf2: Change queue_setup argument
  media: videobuf2: Replace v4l2-specific data with vb2 data.
  media: videobuf2: Prepare to divide videobuf2
  media: videobuf2: Move v4l2-specific stuff to videobuf2-v4l2

 Documentation/video4linux/v4l2-pci-skeleton.c|4 +-
 drivers/input/touchscreen/sur40.c|3 +-
 drivers/media/dvb-frontends/rtl2832_sdr.c|2 +-
 drivers/media/pci/cobalt/cobalt-v4l2.c   |4 +-
 drivers/media/pci/cx23885/cx23885-417.c  |2 +-
 drivers/media/pci/cx23885/cx23885-dvb.c  |2 +-
 drivers/media/pci/cx23885/cx23885-vbi.c  |2 +-
 drivers/media/pci/cx23885/cx23885-video.c|2 +-
 drivers/media/pci/cx25821/cx25821-video.c|3 +-
 drivers/media/pci/cx88/cx88-blackbird.c  |2 +-
 drivers/media/pci/cx88/cx88-dvb.c|2 +-
 drivers/media/pci/cx88/cx88-vbi.c|2 +-
 drivers/media/pci/cx88/cx88-video.c  |2 +-
 drivers/media/pci/dt3155/dt3155.c|3 +-
 drivers/media/pci/netup_unidvb/netup_unidvb_core.c   |2 +-
 drivers/media/pci/saa7134/saa7134-ts.c   |2 +-
 drivers/media/pci/saa7134/saa7134-vbi.c  |2 +-
 drivers/media/pci/saa7134/saa7134-video.c|2 +-
 drivers/media/pci/saa7134/saa7134.h  |2 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c   |2 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2.c   |2 +-
 drivers/media/pci/sta2x11/sta2x11_vip.c  |2 +-
 drivers/media/pci/tw68/tw68-video.c  |3 +-
 drivers/media/platform/am437x/am437x-vpfe.c  |3 +-
 drivers/media/platform/blackfin/bfin_capture.c   |3 +-
 drivers/media/platform/coda/coda-common.c|3 +-
 drivers/media/platform/davinci/vpbe_display.c|3 +-
 drivers/media/platform/davinci/vpif_capture.c|3 +-
 drivers/media/platform/davinci/vpif_display.c|3 +-
 drivers/media/platform/exynos-gsc/gsc-m2m.c  |2 +-
 drivers/media/platform/exynos4-is/fimc-capture.c |3 +-
 drivers/media/platform/exynos4-is/fimc-isp-video.c   |3 +-
 drivers/media/platform/exynos4-is/fimc-lite.c|3 +-
 drivers/media/platform/exynos4-is/fimc-m2m.c |2 +-
 drivers/media/platform/m2m-deinterlace.c |2 +-
 drivers/media/platform/marvell-ccic/mcam-core.c  |3 +-
 drivers/media/platform/mx2_emmaprp.c |2 +-
 drivers/media/platform/omap3isp/ispvideo.c   |2 +-
 drivers/media/platform/rcar_jpu.c|3 +-
 drivers/media/platform/s3c-camif/camif-capture.c |3 +-
 drivers/media/platform/s5p-g2d/g2d.c |2 +-
 drivers/media/platform/s5p-jpeg/jpeg-core.c  |2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |2 +-
 drivers/media/platform/s5p-tv/mixer_video.c  |2 +-
 drivers/media/platform/sh_veu.c  |3 +-
 drivers/media/platform/sh_vou.c  |3 +-
 drivers/media/platform/soc_camera/atmel-isi.c|2 +-
 drivers/media/platform/soc_camera/mx2_camera.c   |3 +-
 drivers/media/platform/soc_camera/mx3_camera.c   |3 +-
 drivers/media/platform/soc_camera/rcar_vin.c |3 +-
 drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c |6 +-
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c|3 +-
 drivers/media/platform/ti-vpe/vpe.c  |2 +-
 drivers/media/platform/vim2m.c   |3 +-
 drivers/media/platform/vivid/vivid-sdr-cap.c |2 +-
 drivers/media/platform/vivid/vivid-vbi-cap.c |7 +-
 drivers/media/platform/vivid/vivid-vbi-out.c |2 +-
 drivers/media/platform/vivid/vivid-vid-cap.c |3 +-
 drivers/media/platform/vivid/vivid-vid-out.c |3 +-
 drivers/media/platform/vsp1/vsp1_video.c |3 +-
 drivers/media/platform/xilinx/xilinx-dma.c   |3 +-
 

Re: [PATCHv9 07/15] cec: add HDMI CEC framework

[Hans Verkuil]

On 10/06/2015 07:06 PM, Russell King - ARM Linux wrote:
> On Mon, Sep 07, 2015 at 03:44:36PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> The added HDMI CEC framework provides a generic kernel interface for
>> HDMI CEC devices.
>>
>> Signed-off-by: Hans Verkuil 
>> [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil]
>> [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil]
>> [k.deb...@samsung.com: change kthread handling when setting logical
>> address]
>> [k.deb...@samsung.com: code cleanup and fixes]
>> [k.deb...@samsung.com: add missing CEC commands to match spec]
>> [k.deb...@samsung.com: add RC framework support]
>> [k.deb...@samsung.com: move and edit documentation]
>> [k.deb...@samsung.com: add vendor id reporting]
>> [k.deb...@samsung.com: add possibility to clear assigned logical
>> addresses]
>> [k.deb...@samsung.com: documentation fixes, clenaup and expansion]
>> [k.deb...@samsung.com: reorder of API structs and add reserved fields]
>> [k.deb...@samsung.com: fix handling of events and fix 32/64bit timespec
>> problem]
>> [k.deb...@samsung.com: add cec.h to include/uapi/linux/Kbuild]
>> [k.deb...@samsung.com: add sequence number handling]
>> [k.deb...@samsung.com: add passthrough mode]
>> [k.deb...@samsung.com: fix CEC defines, add missing CEC 2.0 commands]
>> minor additions]
>> Signed-off-by: Kamil Debski 
>> Signed-off-by: Hans Verkuil 
> 
> I don't see much in the way of support for source devices in this:
> how do we handle hotplug of the sink, and how to do we configure the
> physical address?

The source device driver should call cec_enable(false) if the hotplug
goes down and cec_enable(true) when the EDID has been read and the physical
address has been retrieved and configured in the cec adapter.

This however assumes that the source driver is the one controlling the
CEC hardware. This is the case for the cobalt driver, but not apparently
for the exynos hardware. In that case userspace will have to handle this:
disable the CEC adapter when the hotplug disappears, set the physical address
and enable the CEC adapter when a new EDID is read.

Such drivers have the CEC_CAP_STATE and CEC_CAP_PHYS_ADDR caps set. I.e.
they expect that userspace does this.

This is also something that USB CEC dongles will do, although I don't have
a driver for that.

> Surely you aren't proposing that drivers should write directly to
> adap->phys_addr without calling some notification function that the
> physical address has changed?

Userspace is informed through CEC_EVENT_STATE_CHANGE when the adapter is
enabled/disabled. When the adapter is enabled and CEC_CAP_PHYS_ADDR is
not set (i.e. the kernel takes care of this), then calling CEC_ADAP_G_PHYS_ADDR
returns the new physical address.
 
> Please can you give some guidance on how a HDMI source bridge driver
> should deal with these issues.  Thanks.
> 

The cec.txt file will give more information about the kernel internals.
All I need is time (ha!) to update that file since the current version
is completely outdated (as mentioned in the cover letter).

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Current status of MC patches?

[Mauro Carvalho Chehab]

Em Mon, 12 Oct 2015 15:08:33 +0200
Hans Verkuil  escreveu:

> Hi Mauro,
> 
> Can you give an update of the current status of the MC work? To be honest,
> I've lost track.
> 
> In particular, is there anything I and/or others need to review before you
> can start merging patches?

Basically, we're still waiting for Laurent and Sakari's review.

> This is also relevant for the workshop agenda. I plan to put any MC topics
> at the end of the workshop. As you mentioned in a mail exchange with Shuah,
> as long as these patches aren't merged there is not all that much point in
> discussing future work.

Yep. There's no sense to even discuss MC at the workshop while the
current work is not reviewed, as the other MC topic for discussion
is related to dynamic support, to be added after the MC next gen
support for G_TOPOLOGY.

Regards,
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

[renesas-drivers:topic/gen3-modemr-syscon-v1 14/41] drivers/media/i2c/tc358743.c:1786:22: error: too few arguments to function 'devm_gpiod_get'

[kbuild test robot]

tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
topic/gen3-modemr-syscon-v1
head:   dbe77a0e3216be44aeb55396d415b56f1df25bf3
commit: cf154c485cd1d565e67bf9762f8538ea794ab27e [14/41] Merge remote-tracking 
branch 'media-next/master' into base
config: x86_64-allmodconfig (attached as .config)
reproduce:
git checkout cf154c485cd1d565e67bf9762f8538ea794ab27e
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/i2c/tc358743.c: In function 'tc358743_probe_of':
>> drivers/media/i2c/tc358743.c:1786:22: error: too few arguments to function 
>> 'devm_gpiod_get'
 state->reset_gpio = devm_gpiod_get(dev, "reset");
 ^
   In file included from drivers/media/i2c/tc358743.c:34:0:
   include/linux/gpio/consumer.h:73:32: note: declared here
struct gpio_desc *__must_check devm_gpiod_get(struct device *dev,
   ^

vim +/devm_gpiod_get +1786 drivers/media/i2c/tc358743.c

25614824 Philipp Zabel 2015-07-17  1770  * them based on link frequency 
and resolution.
25614824 Philipp Zabel 2015-07-17  1771  */
25614824 Philipp Zabel 2015-07-17  1772 if (bps_pr_lane != 59400U)
25614824 Philipp Zabel 2015-07-17  1773 dev_warn(dev, "untested 
bps per lane: %u bps\n", bps_pr_lane);
25614824 Philipp Zabel 2015-07-17  1774 state->pdata.lineinitcnt = 
0xe80;
25614824 Philipp Zabel 2015-07-17  1775 state->pdata.lptxtimecnt = 
0x003;
25614824 Philipp Zabel 2015-07-17  1776 /* tclk-preparecnt: 3, 
tclk-zerocnt: 20 */
25614824 Philipp Zabel 2015-07-17  1777 state->pdata.tclk_headercnt = 
0x1403;
25614824 Philipp Zabel 2015-07-17  1778 state->pdata.tclk_trailcnt = 
0x00;
25614824 Philipp Zabel 2015-07-17  1779 /* ths-preparecnt: 3, 
ths-zerocnt: 1 */
25614824 Philipp Zabel 2015-07-17  1780 state->pdata.ths_headercnt = 
0x0103;
25614824 Philipp Zabel 2015-07-17  1781 state->pdata.twakeup = 0x4882;
25614824 Philipp Zabel 2015-07-17  1782 state->pdata.tclk_postcnt = 
0x008;
25614824 Philipp Zabel 2015-07-17  1783 state->pdata.ths_trailcnt = 0x2;
25614824 Philipp Zabel 2015-07-17  1784 state->pdata.hstxvregcnt = 0;
25614824 Philipp Zabel 2015-07-17  1785  
25614824 Philipp Zabel 2015-07-17 @1786 state->reset_gpio = 
devm_gpiod_get(dev, "reset");
25614824 Philipp Zabel 2015-07-17  1787 if (IS_ERR(state->reset_gpio)) {
25614824 Philipp Zabel 2015-07-17  1788 dev_err(dev, "failed to 
get reset gpio\n");
25614824 Philipp Zabel 2015-07-17  1789 ret = 
PTR_ERR(state->reset_gpio);
25614824 Philipp Zabel 2015-07-17  1790 goto disable_clk;
25614824 Philipp Zabel 2015-07-17  1791 }
25614824 Philipp Zabel 2015-07-17  1792  
25614824 Philipp Zabel 2015-07-17  1793 tc358743_gpio_reset(state);
25614824 Philipp Zabel 2015-07-17  1794  

:: The code at line 1786 was first introduced by commit
:: 25614824685247e00b786032a504f10bfab347b1 [media] tc358743: support probe 
from device tree

:: TO: Philipp Zabel 
:: CC: Mauro Carvalho Chehab 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Tony Lindgren]

* Tony Lindgren  [150914 09:37]:
> * Suman Anna  [150914 09:33]:
> > Hi Tony,
> > 
> > On 09/03/2015 05:34 PM, Suman Anna wrote:
> > > Hi Sakari,
> > > 
> > > On 07/16/2015 07:58 AM, Tony Lindgren wrote:
> > >> * Laurent Pinchart  [150716 05:57]:
> > >>> The OMAP3 ISP is now fully supported in DT, remove its instantiation
> > >>> from C code.
> > >>
> > >> Please feel to queue this along with the second patch in this series,
> > >> this should not cause any merge conflicts:
> > >>
> > >> Acked-by: Tony Lindgren 
> > > 
> > > Just wondering if you have already queued this, I see the v4l changes in
> > > linux-next, but not this patch. Also, can you confirm if this series is
> > > making it into 4.3?
> > > 
> > 
> > This patch is not in 4.3-rc1, can you pick this up for the next merge
> > window? I am gonna send out some additional cleanup patches (removing
> > legacy mailbox and iommu pieces) on top on this patch. The second patch
> > in this series did make it.
> 
> OK tagging this one for next, will apply once I'm done with fixes.

Applying into omap-for-v4.4/cleanup finally thanks.

Tony
--
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] media: videobuf2-dc: set properly dma_max_segment_size

[Laurent Pinchart]

On Thursday 13 August 2015 16:53:56 Lars-Peter Clausen wrote:
> On 08/13/2015 03:49 PM, Marek Szyprowski wrote:
> > On 2015-08-13 14:40, Lars-Peter Clausen wrote:
> >> On 08/12/2015 11:58 AM, Marek Szyprowski wrote:
> >>> If device has no DMA max_seg_size set, we assume that there is no limit
> >>> and it is safe to force it to use DMA_BIT_MASK(32) as max_seg_size to
> >>> let DMA-mapping API always create contiguous mappings in DMA address
> >>> space. This is essential for all devices, which use dma-contig
> >>> videobuf2 memory allocator.
> >>> 
> >>> Signed-off-by: Marek Szyprowski 
> >>> ---
> >>> Changelog:
> >>> v2:
> >>> - set max segment size only if a new dma params structure has been
> >>> 
> >>>allocated, as suggested by Laurent Pinchart
> >>> 
> >>> ---
> >>> 
> >>>   drivers/media/v4l2-core/videobuf2-dma-contig.c | 15 +++
> >>>   1 file changed, 15 insertions(+)
> >>> 
> >>> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >>> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >>> index 94c1e64..455e925 100644
> >>> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >>> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >>> @@ -862,6 +862,21 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
> >>>   void *vb2_dma_contig_init_ctx(struct device *dev)
> >>>   {
> >>>   struct vb2_dc_conf *conf;
> >>> +int err;
> >>> +
> >>> +/*
> >>> + * if device has no max_seg_size set, we assume that there is no
> >>> limit
> >>> + * and force it to DMA_BIT_MASK(32) to always use contiguous
> >>> mappings
> >>> + * in DMA address space
> >>> + */
> >>> +if (!dev->dma_parms) {
> >>> +dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL);
> >>> +if (!dev->dma_parms)
> >>> +return ERR_PTR(-ENOMEM);
> >>> +err = dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
> >>> +if (err)
> >>> +return ERR_PTR(err);
> >>> +}
> >> 
> >> I'm not sure if this is such a good idea. The DMA provider is responsible
> >> for setting this up. We shouldn't be overwriting this here on the DMA
> >> consumer side. This will just mask the bug that the provider didn't setup
> >> this correctly and might cause bugs on its own if it is not correct. It
> >> will lead to conflicts with DMA providers that have multiple consumers
> >> (e.g. shared DMA core). And also the current assumption is that if a
> >> driver doesn't set this up explicitly the maximum segement size is
> >> 65536.
> >
> > The problem is that there is no good place for changing this extremely low
> > default value. V4L2 media devices, which use videobuf2-dc expects to get
> > buffers mapped contiguous in the DMA/IO address space. Initially I wanted
> > to have a code for setting dma max segment size directly in the dma-
> > mapping subsystem. This however causeed problems in the other places, as
> > mentioned in the following mail:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305913
> > .html
>
> And the same reasoning in that reply still applies here. Try to fix the DMA
> provider drivers to setup the correct value.

Would it make sense to create a helper functions that drivers could use ? I 
expect all drivers that require contiguous memory buffers larger than 64kB to 
be broken if they don't set the maximum segment size, which very few of them 
do.

-- 
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

videobuf2-core.c:undefined reference to `__tracepoint_vb2_buf_queue'

[kbuild test robot]

Hi Philipp,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   25cb62b76430a91cc6195f902e61c2cb84ade622
commit: 2091f5181c66b3617a977e79843aba10e087be6c [media] videobuf2: add trace 
events
date:   3 months ago
config: i386-randconfig-x0-10131131 (attached as .config)
reproduce:
git checkout 2091f5181c66b3617a977e79843aba10e087be6c
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `sur40_vidioc_querycap':
   sur40.c:(.text+0x1ba910): undefined reference to `video_devdata'
   drivers/built-in.o: In function `sur40_poll':
   sur40.c:(.text+0x1bb0b2): undefined reference to `v4l2_get_timestamp'
   drivers/built-in.o: In function `sur40_probe':
   sur40.c:(.text+0x1bb67b): undefined reference to `v4l2_device_register'
   sur40.c:(.text+0x1bb69b): undefined reference to `v4l2_device_unregister'
   sur40.c:(.text+0x1bb86e): undefined reference to `video_device_release_empty'
   sur40.c:(.text+0x1bb896): undefined reference to `__video_register_device'
   sur40.c:(.text+0x1bb920): undefined reference to `video_unregister_device'
   drivers/built-in.o: In function `sur40_disconnect':
   sur40.c:(.text+0x1bb949): undefined reference to `video_unregister_device'
   sur40.c:(.text+0x1bb951): undefined reference to `v4l2_device_unregister'
   drivers/built-in.o: In function `__enqueue_in_driver':
>> videobuf2-core.c:(.text+0x1be4d0): undefined reference to 
>> `__tracepoint_vb2_buf_queue'
   drivers/built-in.o: In function `vb2_buffer_done':
>> (.text+0x1bef80): undefined reference to `__tracepoint_vb2_buf_done'
   drivers/built-in.o: In function `vb2_fop_mmap':
   (.text+0x1bf2cf): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_internal_dqbuf':
>> videobuf2-core.c:(.text+0x1bff38): undefined reference to 
>> `__tracepoint_vb2_dqbuf'
   drivers/built-in.o: In function `vb2_ioctl_querybuf':
   (.text+0x1c053c): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_create_bufs':
   (.text+0x1c15f9): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_reqbufs':
   (.text+0x1c23c9): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_streamoff':
   (.text+0x1c25b9): undefined reference to `video_devdata'
   drivers/built-in.o: In function `_vb2_fop_release':
   (.text+0x1c26d9): undefined reference to `video_devdata'
   drivers/built-in.o: In function `_vb2_fop_release':
   (.text+0x1c2702): undefined reference to `v4l2_fh_release'
   drivers/built-in.o: In function `vb2_fop_release':
   (.text+0x1c275c): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_streamon':
   (.text+0x1c29d9): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_prepare_buf':
   (.text+0x1c2b39): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_internal_qbuf':
>> videobuf2-core.c:(.text+0x1c2cf8): undefined reference to 
>> `__tracepoint_vb2_qbuf'
   drivers/built-in.o: In function `vb2_poll':
   (.text+0x1c32b8): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_poll':
   (.text+0x1c3449): undefined reference to `v4l2_event_pending'
   drivers/built-in.o: In function `vb2_fop_poll':
   (.text+0x1c362b): undefined reference to `video_devdata'
   drivers/built-in.o: In function `__vb2_perform_fileio':
   videobuf2-core.c:(.text+0x1c3e07): undefined reference to 
`v4l2_get_timestamp'
   drivers/built-in.o: In function `vb2_fop_write':
   (.text+0x1c412d): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_fop_read':
   (.text+0x1c425d): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_thread':
   videobuf2-core.c:(.text+0x1c45e7): undefined reference to 
`v4l2_get_timestamp'
   drivers/built-in.o: In function `vb2_ioctl_qbuf':
   (.text+0x1c4709): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_dqbuf':
   (.text+0x1c48af): undefined reference to `video_devdata'
   drivers/built-in.o: In function `vb2_ioctl_expbuf':
   (.text+0x1c4bc9): undefined reference to `video_devdata'
   drivers/built-in.o:(.rodata+0x2a7b0): undefined reference to `video_ioctl2'
   drivers/built-in.o:(.rodata+0x2a7bc): undefined reference to `v4l2_fh_open'
   drivers/built-in.o:(__jump_table+0x4dc): undefined reference to 
`__tracepoint_vb2_buf_queue'
   drivers/built-in.o:(__jump_table+0x4e8): undefined reference to 
`__tracepoint_vb2_buf_done'
   drivers/built-in.o:(__jump_table+0x4f4): undefined reference to 
`__tracepoint_vb2_dqbuf'
   drivers/built-in.o:(__jump_table+0x500): undefined reference to 
`__tracepoint_vb2_qbuf'

---
0-DAY kernel test infrastructureOpen Source Technology Center

cron job: media_tree daily build: OK

[Hans Verkuil]

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:   Tue Oct 13 04:00:16 CEST 2015
git branch: test
git hash:   efe98010b80ec4516b2779e1b4e4a8ce16bf89fe
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0-51-ga53cea2
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:4.0.0-3.slh.1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: 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-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: OK
linux-2.6.33.7-i686: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-rc1-i686: OK
linux-2.6.32.27-x86_64: OK
linux-2.6.33.7-x86_64: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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

Unexpected Luck

[Christine McCarthy]

Contact Monica Torres via email: monicatorres...@gmail.com for your winnings of 
€1,000,000.00.

--
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