i/linux/videodev2.h
> index c3d4e490ce7c..26ecac19722a 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -1944,9 +1944,27 @@ struct v4l2_query_ext_ctrl {
> __u32elems;
> __u32nr_of_dims;
> __u32dims[V4L2_CTRL_MAX_DIMS];
> - __u32reserved[32];
> + __u32fraction_bits;
u8 would suffice. Not that we'd be short of space but still...
> + __u32reserved[31];
> };
>
> +static inline __s64 v4l2_fp_compose(__s64 i, __s64 f, unsigned int
> fraction_bits)
> +{
> + return (i << fraction_bits) + f;
> +}
> +
> +static inline __s64 v4l2_fp_integer(__s64 v, unsigned int fraction_bits)
> +{
> + return v / (1LL << fraction_bits);
Why not just:
return v >> fraction_bits;
I'd use macros so you could use whatever control types with this without
casting. E.g.
#define V4L2_FP_INTEGER(v, fraction_bits) ((v) >> fraction_bits)
A more generic way to expose this could be to have base and exponent, the
base being 2 in this case. Just an idea. This would of course be a little
bit more difficult to use.
> +}
> +
> +static inline __s64 v4l2_fp_fraction(__s64 v, unsigned int fraction_bits)
> +{
> + __u64 mask = (1ULL << fraction_bits) - 1;
> +
> + return v < 0 ? -((-v) & mask) : (v & mask);
> +}
> +
> /* Used in the VIDIOC_QUERYMENU ioctl for querying menu items */
> struct v4l2_querymenu {
> __u32 id;
--
Kind regards,
Sakari Ailus
I'd prefer to have a way to express the meaning of
the control value, be it a Q number or something else, and do that
independently of the type of the control.
>
> In the case of this particular series the control type is really a fixed point
> value with a documented unit (Hz). It really is not something you want to
> use type INTEGER64 for.
>
> >
> >> Note that V4L2_CTRL_TYPE_FIXED_POINT is a Q31.32 format. By setting
> >> min/max/step you can easily map that to just about any QN.M format where
> >> N <= 31 and M <= 32.
> >>
> >> In the case of dw100 it is a bit different in that it is quite specialized
> >> and it had to fit in 16 bits.
--
Regards,
Sakari Ailus
his needs to be documented, too.
>
> All data in the buffer are the samples, the 'samplerate', 'sampleformat'
> 'channels' I list here is try to describe the samples.
> I was confused how to write this document, so I list the characters.
The layout of this data in memory needs to be documented. I think a
reference to ALSA documentation would be the best.
--
Regards,
Sakari Ailus
dths: 1 4
> +:header-rows: 1
> +:stub-columns: 0
> +
> +* - Field
> + - Description
> +* - u32 samplerate;
> + - which is the number of times per second that samples are taken.
> +* - u32 sampleformat;
> + - which determines the number of possible digital values that can be
> used to represent each sample
80 characters (or less) per line, please.
Which values could this field have and what do they signify?
> +* - u32 channels;
> + - channel number for each sample.
I suppose the rest of the buffer would be samples? This should be
documented. I think there are also different ways the data could be
arrangeed and this needs to be documented, too.
--
Kind regards,
Sakari Ailus
ibute__ ((packed));
>
> +/**
> + * struct v4l2_audio_format - audio data format definition
> + * @rate:sample rate
> + * @format: sample format
> + * @channels:channel numbers
> + * @buffersize: maximum size in bytes required for data
> + */
> +struct v4l2_audio_format {
> + __u32 rate;
> + __u32 format;
> + __u32 channels;
> + __u32 buffersize;
> +} __attribute__ ((packed));
> +
> /**
> * struct v4l2_format - stream data format
> * @type:enum v4l2_buf_type; type of the data stream
> @@ -2412,6 +2429,7 @@ struct v4l2_meta_format {
> * @win: definition of an overlaid image
> * @vbi: raw VBI capture or output parameters
> * @sliced: sliced VBI capture or output parameters
> + * @audio: definition of an audio format
> * @raw_data:placeholder for future extensions and custom formats
> * @fmt: union of @pix, @pix_mp, @win, @vbi, @sliced, @sdr, @meta
> * and @raw_data
> @@ -2426,6 +2444,7 @@ struct v4l2_format {
> struct v4l2_sliced_vbi_format sliced; /*
> V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
> struct v4l2_sdr_format sdr; /*
> V4L2_BUF_TYPE_SDR_CAPTURE */
> struct v4l2_meta_format meta;/*
> V4L2_BUF_TYPE_META_CAPTURE */
> + struct v4l2_audio_formataudio; /*
> V4L2_BUF_TYPE_AUDIO_CAPTURE */
> __u8raw_data[200]; /* user-defined */
> } fmt;
> };
> --
> 2.34.1
>
--
Sakari Ailus
ameter from GUP altogether.
>
> Acked-by: David Hildenbrand
> Acked-by: Dennis Dalessandro (for
> qib)
> Signed-off-by: Lorenzo Stoakes
Acked-by: Sakari Ailus # drivers/media
--
Sakari Ailus
rns zero on success, therefore >= 0 is
not needed. I'd just use !fwnode_property_match_string(...).
For both patches:
Reviewed-by: Sakari Ailus
> +}
> +
> int fwnode_property_get_reference_args(const struct fwnode_handle *fwnode,
> const char *prop, const char *nargs_prop,
> unsigned int nargs, unsigned int index,
--
Regards,
Sakari Ailus
On Tue, Apr 14, 2020 at 03:13:23PM +0200, Christoph Hellwig wrote:
> Just use vmap instead of messing with vmalloc internals.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Peter Zijlstra (Intel)
Thanks!
Acked-by: Sakari Ailus
--
Sakari Ailus
