[U-Boot] [U-Boot, 1/3] rockchip: boot mode: parse adc channel from dts

Andy Yan andy.yan at rock-chips.com
Wed Nov 29 10:14:20 UTC 2017


Hi PHilipp:


On 2017年11月29日 17:53, Dr. Philipp Tomsich wrote:
> [Getting Simon's email-address right, helps…]
>
> Simon,
>
> could you comment on this one from a general U-Boot architecture and 
> DM-maintainer perspective?
>
> Thanks,
> Philipp.
>
>> On 29 Nov 2017, at 10:50, Dr. Philipp Tomsich 
>> <philipp.tomsich at theobroma-systems.com 
>> <mailto:philipp.tomsich at theobroma-systems.com>> wrote:
>>
>>
>>> On 29 Nov 2017, at 07:34, Andy Yan <andy.yan at rock-chips.com 
>>> <mailto:andy.yan at rock-chips.com><mailto:andy.yan at rock-chips.com>> wrote:
>>>
>>> Hi Philipp:
>>>
>>>
>>> On 2017年11月28日 21:59, Philipp Tomsich wrote:
>>>> +sjg
>>>>
>>>> On Tue, 28 Nov 2017, Andy Yan wrote:
>>>>
>>>>> Most the current rockchip based boards use adc channel
>>>>> 1 detect the download key, but there are also some
>>>>> boards like rv1108 based plaform use adc channel 0.
>>>>> So we parse the adc channel from dts if we can get
>>>>> it, otherwise we use the channel 1 as default.
>>>>>
>>>>> Signed-off-by: Andy Yan <andy.yan at rock-chips.com 
>>>>> <mailto:andy.yan at rock-chips.com><mailto:andy.yan at rock-chips.com>>
>>>>> Acked-by: Philipp Tomsich <philipp.tomsich at theobroma-systems.com 
>>>>> <mailto:philipp.tomsich at theobroma-systems.com><mailto:philipp.tomsich at theobroma-systems.com>>
>>>>> ---
>>>>>
>>>>> arch/arm/mach-rockchip/boot_mode.c | 15 ++++++++++++++-
>>>>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-rockchip/boot_mode.c 
>>>>> b/arch/arm/mach-rockchip/boot_mode.c
>>>>> index 942849f..49dfd39 100644
>>>>> --- a/arch/arm/mach-rockchip/boot_mode.c
>>>>> +++ b/arch/arm/mach-rockchip/boot_mode.c
>>>>> @@ -8,6 +8,9 @@
>>>>> #include <adc.h>
>>>>> #include <asm/io.h>
>>>>> #include <asm/arch/boot_mode.h>
>>>>> +#include <fdtdec.h>
>>>>> +
>>>>> +DECLARE_GLOBAL_DATA_PTR;
>>>>>
>>>>> void set_back_to_bootrom_dnl_flag(void)
>>>>> {
>>>>> @@ -26,9 +29,19 @@ void set_back_to_bootrom_dnl_flag(void)
>>>>>
>>>>> __weak int rockchip_dnl_key_pressed(void)
>>>>> {
>>>>> +    const void *blob = gd->fdt_blob;
>>>>>    unsigned int val;
>>>>> +    int channel = 1;
>>>>> +    int node;
>>>>> +    u32 chns[2];
>>>>> +
>>>>> +    node = fdt_node_offset_by_compatible(blob, 0, "adc-keys");
>>>>> +    if (node >= 0) {
>>>>> +        if (!fdtdec_get_int_array(blob, node, "io-channels", 
>>>>> chns, 2))
>>>>> +            channel = chns[1];
>>>>> +    }
>>>>
>>>> The driver for 'adc-keys' should be a driver in drivers/input that 
>>>> can then be retrieved via DM and queried using keyboard_getc().
>>>
>>>    Yes, if there is an exiting adc-keys driver, we will use it here 
>>> with no doubts, but there is not now. I just need  to check the button
>>> down event once, no up or other things needed, so I call the adc api 
>>> directly. I grep all the u-boot project, and found all other boards
>>> handle this kind of button status check by call device specific api 
>>> directly, rather than use the api from input subsystem. So I think
>>> this is a acceptable way.
>>
>> Which other boards did you find that used the “adc-keys” node this way?
>> My grep shows only a few sunxi DTS referring to it:

     I not only mean adc-keys, actually  many boards want to detect key 
status:
  board/samsung/common/misc.c, detected by pmic
  board/qualcomm/dragonboard410c/dragonboard410c.c, detected by gpio
  board/boundary/nitrogen6x/nitrogen6x.c, detected by gpio
board/nokia/rx51/rx51.c, detected by a chip named twl4030
  board/timll/devkit8000/devkit8000.c, detected by gpio

>> board/timll/devkit8000/devkit8000.c 
>> ptomsich at android:~/u-boot-rockchip$ git status
>> On branch master
>> Your branch is up-to-date with 'origin/master'.
>> ptomsich at android:~/u-boot-rockchip$ git grep adc-keys
>> arch/arm/dts/sun4i-a10.dtsi:                    compatible = 
>> "allwinner,sun4i-a10-lradc-keys";
>> arch/arm/dts/sun5i-gr8.dtsi:                    compatible = 
>> "allwinner,sun4i-a10-lradc-keys";
>> arch/arm/dts/sun5i.dtsi:                        compatible = 
>> "allwinner,sun4i-a10-lradc-keys";
>> arch/arm/dts/sun6i-a31.dtsi:                    compatible = 
>> "allwinner,sun4i-a10-lradc-keys";
>> arch/arm/dts/sun7i-a20.dtsi:                    compatible = 
>> "allwinner,sun4i-a10-lradc-keys";
>> arch/arm/dts/sun8i-a23-a33.dtsi:                        compatible = 
>> "allwinner,sun4i-a10-lradc-keys";
>>
>>
>>>      Would you please consider taking this patch if there is no 
>>> other problems. And when there is a adc-keys driver in the future, I 
>>> can move
>>> it to input based api, or I will write a adc-keys driver when my 
>>> workloads is not so heavy as now.
>>
>> The problem is that if we go ahead with this as-is, there never be a 
>> driver for the "adc-keys” created ...
>> Let’s see what for Simon’s input is, before we make a final decision.
>>
>>>>
>>>>>
>>>>> -    if (adc_channel_single_shot("saradc", 1, &val)) {
>>>>> +    if (adc_channel_single_shot("saradc", channel, &val)) {
>>>>>        pr_err("%s: adc_channel_single_shot fail!\n", __func__);
>>>>>        return false;
>>>>>    }
>>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de <mailto:U-Boot at lists.denx.de>
> https://lists.denx.de/listinfo/u-boot 



More information about the U-Boot mailing list