On 29.04.2019 10:05, Hans Verkuil wrote:
> On 4/27/19 4:50 PM, Maciej S. Szmigiero wrote:
>> cx25840 driver g_std operation queries the currently detected video signal,
>> however this is what querystd operation should do, so let's rename the
>> handler.
>>
>> None of the existing cx25840 driver users ever called the g_std operation,
>> one of them calls querystd on each of its subdevs but then the result is
>> only used to implement VIDIOC_QUERYSTD (as it should).
>>
>> Signed-off-by: Maciej S. Szmigiero <mail@xxxxxxxxxxxxxxxxxxxxx>
>> ---
>> drivers/media/i2c/cx25840/cx25840-core.c | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/i2c/cx25840/cx25840-core.c b/drivers/media/i2c/cx25840/cx25840-core.c
>> index 0bf30222cf93..2bcaf239b0d2 100644
>> --- a/drivers/media/i2c/cx25840/cx25840-core.c
>> +++ b/drivers/media/i2c/cx25840/cx25840-core.c
>> @@ -1772,7 +1772,7 @@ static int cx25840_s_stream(struct v4l2_subdev *sd, int enable)
>> }
>>
>> /* Query the current detected video format */
>> -static int cx25840_g_std(struct v4l2_subdev *sd, v4l2_std_id *std)
>> +static int cx25840_querystd(struct v4l2_subdev *sd, v4l2_std_id *std)
>> {
>> struct i2c_client *client = v4l2_get_subdevdata(sd);
>>
>> @@ -1800,8 +1800,9 @@ static int cx25840_g_std(struct v4l2_subdev *sd, v4l2_std_id *std)
>> u32 fmt = (cx25840_read4(client, 0x40c) >> 8) & 0xf;
>> *std = stds[ fmt ];
>>
>> - v4l_dbg(1, cx25840_debug, client, "g_std fmt = %x, v4l2_std_id = 0x%x\n",
>> - fmt, (unsigned int)stds[ fmt ]);
>> + v4l_dbg(1, cx25840_debug, client,
>> + "querystd fmt = %x, v4l2_std_id = 0x%x\n",
>> + fmt, (unsigned int)stds[fmt]);
>>
>> return 0;
>> }
>> @@ -5081,7 +5082,7 @@ static const struct v4l2_subdev_audio_ops cx25840_audio_ops = {
>>
>> static const struct v4l2_subdev_video_ops cx25840_video_ops = {
>> .s_std = cx25840_s_std,
>> - .g_std = cx25840_g_std,
>> + .querystd = cx25840_querystd,
>> .s_routing = cx25840_s_video_routing,
>> .s_stream = cx25840_s_stream,
>> .g_input_status = cx25840_g_input_status,
>>
>
> Hmm, you are right, g_std really implements querystd. I wondered why this wasn't
> noticed before, and it appears that no bridge driver ever calls the g_std op of the
> cx25840 driver. It's all handled inside the bridge driver itself.
>
> Can you add a new cx25840_g_std() op here that just returns state->std?
>
> That would make much more sense.
>
> You also need to use g_std in patch 6/7 (see my comments there)
Will do, but a small comment here:
Currently, when somebody passes a set of multiple standards to s_std,
let's say V4L2_STD_ALL the chip isn't configured for "every standard
possible".
It is set for a specific, single standard from this set of standards.
There is a "if" tree at the begging of set_v4lstd() that implements,
effectively, a list of priorities when selecting a single standard
from a set of multiple.
That's why I think the incoming standard should be selected upfront
according to this priority list in s_std handler and only this
effective value should be set in state->std so g_std actually
returns what the device is set for.
> Regards,
>
> Hans
>
Thanks,
Maciej
