Re: [PATCH v2 5/5] i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery

[Grygorii Strashko]

On 07/07/2015 05:13 PM, Wolfram Sang wrote:
> On Tue, Jul 07, 2015 at 03:48:52PM +0200, Uwe Kleine-KÃnig wrote:

>> On Tue, Jul 07, 2015 at 03:37:49PM +0200, Jan LÃbbe wrote:
>>> On Mi, 2014-11-26 at 19:05 +0200, Grygorii Strashko wrote:
>>>> On 11/26/2014 06:04 PM, Uwe Kleine-KÃnig wrote:
>>>>> On Wed, Nov 26, 2014 at 03:59:53PM +0200, Grygorii Strashko wrote:
>>>>>> Having a board where the I2C bus locks up occasionally made it clear
>>>>>> that the bus recovery in the i2c-davinci driver will only work on
>>>>>> some boards, because on regular boards, this will only toggle GPIO
>>>>>> lines that aren't muxed to the actual pins.
>>>>>>
>>>>>> The I2C controller on SoCs like da850 (and da830), Keystone 2 has the
>>>>>> built-in capability to bit-bang its lines by using the ICPFUNC registers
>>>>>> of the i2c controller.
>>>>>> Implement the suggested procedure by toggling SCL and checking SDA using
>>>>>> the ICPFUNC registers of the I2C controller when present. Allow platforms
>>>>>> to indicate the presence of the ICPFUNC registers with a has_pfunc platform
>>>>>> data flag and add optional DT property "ti,has-pfunc" to indicate
>>>>>> the same in DT.
>>>>> On what does it depend if this pfunc stuff works or not? Only the SoC,
>>>>> or also on some board specific properties?
>>>>
>>>> SoC / set of SoCs. Also, similar feature is supported by OMAP and AM335x/AM437x SoCs
>>>> using I2C_SYSTEST register.
>>>>
>>>>> Given the former using the
>>>>> compatible string to detect its availability would be better. (In this
>>>>> case also sorry, didn't consider this case when requesting the property
>>>>> in the last round.)
>>>
>>> I only stumbled across this after it was merged, with the additional
>> I also wonder how it came to the Reviewed-by tag for me. The last thing
>> that I said about the patch was "On what does it depend if this pfunc
>> stuff works or not? Only the SoC, or also on some board specific
>> properties?" (see above) and "the patch looks ok". IMHO this hardly
>> justifies to add the Reviewed-by tag for the next round. :-(
> 
> That needs to be discussed with Grygorii. I can't verify the correctness
> of tags for every patch, although I do try to keep an eye on it...
> 

Regarding "the patch looks ok" - sincerely sorry!
This is not the first time I've treated "looks good.." as Reviewed-by and I got no complaints before :(
Will take it into account.


Regarding technical comments:
OK. Seems I missed smth. or understood wrongly.
So, I'll say what's people usually saying here - Sorry for that :(
But, to be honest I don't feel guilty, because:
- v4 of these patches was merged finally
- that v4 missed >2 kernel releases
- you were added in "TO:" for all versions of these patches.

-- 
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/