All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Frank Schäfer" <fschaefer.oss@googlemail.com>
To: shuah.kh@samsung.com, m.chehab@samsung.com
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	shuahkhan@gmail.com
Subject: Re: [PATCH] media: em28xx-video - change em28xx_scaler_set() to use em28xx_reg_len()
Date: Sat, 22 Mar 2014 18:40:22 +0100	[thread overview]
Message-ID: <532DCB06.9040601@googlemail.com> (raw)
In-Reply-To: <532DAAD0.6060209@samsung.com>


Am 22.03.2014 16:22, schrieb Shuah Khan:
> On 03/22/2014 06:32 AM, Frank Schäfer wrote:
>>
>> Am 21.03.2014 22:04, schrieb Shuah Khan:
>>> Change em28xx_scaler_set() to use em28xx_reg_len() to get register
>>> lengths for EM28XX_R30_HSCALELOW and EM28XX_R32_VSCALELOW registers,
>>> instead of hard-coding the length. Moved em28xx_reg_len() definition
>>> for it to be visible to em28xx_scaler_set().
>>>
>>> Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
>>> ---
>>>   drivers/media/usb/em28xx/em28xx-video.c |   29
>>> ++++++++++++++++-------------
>>>   1 file changed, 16 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/media/usb/em28xx/em28xx-video.c
>>> b/drivers/media/usb/em28xx/em28xx-video.c
>>> index 19af6b3..f8a91de 100644
>>> --- a/drivers/media/usb/em28xx/em28xx-video.c
>>> +++ b/drivers/media/usb/em28xx/em28xx-video.c
>>> @@ -272,6 +272,18 @@ static void em28xx_capture_area_set(struct
>>> em28xx *dev, u8 hstart, u8 vstart,
>>>       }
>>>   }
>>>
>>> +static int em28xx_reg_len(int reg)
>>> +{
>>> +    switch (reg) {
>>> +    case EM28XX_R40_AC97LSB:
>>> +    case EM28XX_R30_HSCALELOW:
>>> +    case EM28XX_R32_VSCALELOW:
>>> +        return 2;
>>> +    default:
>>> +        return 1;
>>> +    }
>>> +}
>>> +
>>>   static int em28xx_scaler_set(struct em28xx *dev, u16 h, u16 v)
>>>   {
>>>       u8 mode;
>>> @@ -284,11 +296,13 @@ static int em28xx_scaler_set(struct em28xx
>>> *dev, u16 h, u16 v)
>>>
>>>           buf[0] = h;
>>>           buf[1] = h >> 8;
>>> -        em28xx_write_regs(dev, EM28XX_R30_HSCALELOW, (char *)buf, 2);
>>> +        em28xx_write_regs(dev, EM28XX_R30_HSCALELOW, (char *)buf,
>>> +                  em28xx_reg_len(EM28XX_R30_HSCALELOW));
>>>
>>>           buf[0] = v;
>>>           buf[1] = v >> 8;
>>> -        em28xx_write_regs(dev, EM28XX_R32_VSCALELOW, (char *)buf, 2);
>>> +        em28xx_write_regs(dev, EM28XX_R32_VSCALELOW, (char *)buf,
>>> +                  em28xx_reg_len(EM28XX_R32_VSCALELOW));
>> Hmm... registers 0x30 and 0x32 are always 2 bytes long.
>> So this change would needlessly complicate the code.
>>
>
> The reason I made the change is that em28xx_reg_len() is handling
> these two registers and I thought it would be good to make it
> consistent with other writes to these registers and not hard-code the
> length.

Well, almost all register writes use a hardcoded length (most of the
time it's 1). ;-)

>
> I think it would help with maintenance later by avoiding hard-coding
> the length and use the existing routine that returns the length for
> these registers.

Yes, if the length would be variable, then this would be a good idea.
But AFAIK the length is always 2.

>
> You are correct that it does add a function call in the code path. So
> if you think the trade-off isn't worth it, I am not going to argue
> with it :)

I'm more concerned about the fact that readers of the code could think
that this is a write with a variable length, while the length is
actually always the same.

em28xx_reg_len() is a somewhat dirty hack for vidioc_[g,s]_register
debugging ioctls only.
Btw, what happens when you try to compile the code with this patch
applied and CONFIG_VIDEO_ADV_DEBUG disabled ? ;-)

Anyway, I very much appreciate your efforts to improve the em28xx
driver. :-)
There's much to do !

Regards,
Frank

>
> -- Shuah
>


  reply	other threads:[~2014-03-22 17:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-21 21:04 [PATCH] media: em28xx-video - change em28xx_scaler_set() to use em28xx_reg_len() Shuah Khan
2014-03-22 12:32 ` Frank Schäfer
2014-03-22 15:22   ` Shuah Khan
2014-03-22 17:40     ` Frank Schäfer [this message]
2014-03-22 22:03       ` Shuah Khan

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=532DCB06.9040601@googlemail.com \
    --to=fschaefer.oss@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=shuah.kh@samsung.com \
    --cc=shuahkhan@gmail.com \
    /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.