From: Hans Verkuil <hverkuil@xs4all.nl>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>
Subject: Re: [RFC PATCH] v4l2-ioctl: fill in the description for VIDIOC_ENUM_FMT
Date: Mon, 23 Mar 2015 07:52:13 -0700 [thread overview]
Message-ID: <5510289D.5040107@xs4all.nl> (raw)
In-Reply-To: <2791463.SXeInvhsda@avalon>
On 03/22/2015 01:38 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Friday 20 March 2015 13:17:19 Hans Verkuil wrote:
>> The descriptions used in drivers for the formats returned with ENUM_FMT
>> are all over the place.
>>
>> So instead allow the core to fill in the description and flags. This
>> allows drivers to drop the description and flags.
>>
>> If the format is not found in the list, and if the description field is
>> filled in, then just return but call WARN_ONCE to let developers know
>> that this list needs to be extended.
>>
>> Based on an earlier patch from Philipp Zabel:
>> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/814
>> 11
>>
>> But this patch moves the code into the core and away from drivers.
>>
>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>> Cc: Philipp Zabel <p.zabel@pengutronix.de>
>
> I have a similar patch in one of my git trees, although I'm not sure exactly
> where I've put it :-) It at least means that I like the idea.
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> I wonder whether the big switch statement could be optimized though,
> especially given that there's two of them, one for the description, and one
> for the flags. You could store the information in an array and lookup the
> entry based on the pixelcode, that would at least get rid of one switch
> statement. Further optimization would be possible by using some kind of hash
> table, but I'm not sure if it's worth it.
The gcc compiler is quite smart when optimizing a switch statement, it
certainly produces code that is faster than a table lookup. I'll take a
look at the gcc output, but I expect it to be either O(log N) comparisons,
or possibly even O(1) if it is smart enough to create a perfect hash for this.
Regards,
Hans
next prev parent reply other threads:[~2015-03-23 14:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 12:17 [RFC PATCH] v4l2-ioctl: fill in the description for VIDIOC_ENUM_FMT Hans Verkuil
2015-03-22 12:03 ` Sakari Ailus
2015-03-22 20:38 ` Laurent Pinchart
2015-03-23 14:52 ` Hans Verkuil [this message]
2015-03-23 9:24 ` Philipp Zabel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5510289D.5040107@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.