Re: [PATCH v3 1/4] iio: adc: rockchip_saradc: reset saradc controller before programming it

[Jonathan Cameron]

On 22/08/16 18:19, Heiko Stuebner wrote:
> Am Sonntag, 21. August 2016, 21:01:19 CEST schrieb Jonathan Cameron:
>> Something in here got it blocked by the lists. I'm guessing it
>> was the characters my email client didn't like so trying again
>> with them dropped.
>>
>> Jonathan
>>
>> On 21/08/16 20:11, Jonathan Cameron wrote:
>>> On 15/08/16 19:10, Caesar Wang wrote:
>>>>> On 27/07/16 15:24, Caesar Wang wrote:
>>>>>> SARADC controller needs to be reset before programming it, otherwise
>>>>>> it will not function properly.
>>>>>>
>>>>>> Signed-off-by: Caesar Wang <wxt@xxxxxxxxxxxxxx>
>>>>>> Cc: Jonathan Cameron <jic23@xxxxxxxxxx>
>>>>>> Cc: Heiko Stuebner <heiko@xxxxxxxxx>
>>>>>> Cc: Rob Herring <robh+dt@xxxxxxxxxx>
>>>>>> Cc: linux-iio@xxxxxxxxxxxxxxx
>>>>>> Cc: linux-rockchip@xxxxxxxxxxxxxxxxxxx
>>>>>> Tested-by: Guenter Roeck <linux@xxxxxxxxxxxx>
>>>>>
>>>>> Hi
>>>>>
>>>>> Patch is fine (I'll fix up the wording issue) however...
>>>>>
>>>>> I'm not clear on the severity of the issue. Is this something
>>>>> we should be pushing for stable?
>>>>
>>>> I think that should be pushing for stable, since the common isssue for
>>>> the ADC is initially enabled on loader, and only disabled after the
>>>> first read.
>>>>
>>>> cat /sys/class/hwmon/hwmon1/device/temp1_input
>>>> cat: /sys/class/hwmon/hwmon1/device/temp1_input: Connection timed out
>>>>
>>>> The kernel log shows:
>>>>
>>>> [ 32.209451] read channel() error: -110
>>>> ..
>>>>
>>>> Also, for my experience. Some other reasons caused the adc (controller)
>>>> glitch for the kernel side.> 
>>> Fine.  So now the only question is who is handling it. The
>>> fix is useless (I think) without the dts changes to support it.
>>> Normally we'd route the dts and driver changes separately as it
>>> should not matter, but here I think I'd prefer it if the whole
>>> thing went via rockchip -> arm-soc tree so it goes in together.
>>>
>>> Hence (with wording fixed)
>>>
>>> Acked-by: Jonathan Cameron <jic23@xxxxxxxxxx>
>>> Cc: <Stable@xxxxxxxxxxxxxxx>
>>> (for the driver patch).
>>>
>>> If people want me to take it via IIO then I'll need acks for
>>> the dts changes with explicit agreement that they can be marked
>>> for stable. Would image Heiko, these would come from you.
> 
> I don't know how the armsoc people feel about routing other subsystem changes 
> through armsoc, but I think small dts changes coming through driver trees is 
> the more common case, so personally I'd think patches 1,3 and 4 could go 
> through the iio tree.
> 
> Patch 2 of course isn't material for stable, as it adds new functionality, so 
> I'd pick that up directly, especially as we see numerous rk3399 changes, so 
> that would be prone to conflict.
Absolutely.  This one applied to the fixes-togreg branch of iio.git

Thanks,

Jonathan
> 
> 
> Heiko
>