[PATCH] drm/i2c/tda9950.c: set MAX_RETRIES for errors only

[Daniel Vetter]

Hi Russell,

On Thu, Sep 13, 2018 at 3:48 PM, Russell King - ARM Linux
<linux at armlinux.org.uk> wrote:
> On Thu, Sep 13, 2018 at 03:33:20PM +0200, Hans Verkuil wrote:
>> On 09/13/18 15:16, Daniel Vetter wrote:
>> > On Thu, Sep 13, 2018 at 10:33:35AM +0100, Russell King - ARM Linux wrote:
>> >> Hi Hans,
>> >>
>> >> I'll pick it up in due course.
>> >>
>> >> Thanks.
>> >>
>> >> On Tue, Sep 11, 2018 at 08:41:59AM +0200, Hans Verkuil wrote:
>> >>> Russell (or someone else), can you Ack this patch? I'd like to get this
>> >>> for 4.20.
>> >>>
>> >>> Thanks!
>> >>>
>> >>>   Hans
>> >>>
>> >>> On 08/27/2018 02:28 PM, Hans Verkuil wrote:
>> >>>> The CEC_TX_STATUS_MAX_RETRIES should be set for errors only to
>> >>>> prevent the CEC framework from retrying the transmit. If the
>> >>>> transmit was successful, then don't set this flag.
>> >>>>
>> >>>> Found by running 'cec-compliance -A' on a beaglebone box.
>> >>>>
>> >>>> Signed-off-by: Hans Verkuil <hans.verkuil at cisco.com>
>> >
>> > Since the tda driver is now a brideg one, would make sense to maintain it
>> > as part of drm-misc? Hans could push directly then.
>>
>> It isn't yet part of drm-misc? It would make sense IMHO.
>>
>> And 'due course' is too vague since this should be merged for 4.20.
>
> Given that we are at 4.19-rc3, and you are talking about it being merged
> during the _next_ merge window, there is plenty of time remaining that
> waiting another week or two for me to pick it up is not a problem.
>
> In any case, my plan is to merge it for 4.19 since it appears to be a
> bug fix, albiet a minor one.

Thanks for handling tdaxxxx.c in an efficient manner.

And to clarify: drm-misc is just an option that's out there, and
you're obviously very much welcome to join (commit rights included
ofc). I do personally think it's great to have an informal group
maintainership like in drm-misc where people can easily jump in&out of
helping out with specific drivers, but it's by no means mandatory.
There's lots of options to effectively and efficiently collaborate.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch