| Message ID | 1511850838-32621-1-git-send-email-andy.yan@rock-chips.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Philipp Tomsich |
| Headers | show |
| Series | Support driving rv1108 evb board to bootrom download mode by adc key | expand |
> 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@rock-chips.com> > --- > > arch/arm/mach-rockchip/boot_mode.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
+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@rock-chips.com> > Acked-by: Philipp Tomsich <philipp.tomsich@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(). > > - 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; > } >
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@rock-chips.com> >> Acked-by: Philipp Tomsich <philipp.tomsich@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. 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. > >> >> - 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; >> } >> > > >
> On 29 Nov 2017, at 07:34, Andy Yan <andy.yan@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@rock-chips.com> >>> Acked-by: Philipp Tomsich <philipp.tomsich@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: ptomsich@android:~/u-boot-rockchip$ git status On branch master Your branch is up-to-date with 'origin/master'. ptomsich@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; >>> }
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@theobroma-systems.com> wrote: > > >> On 29 Nov 2017, at 07:34, Andy Yan <andy.yan@rock-chips.com <mailto:andy.yan@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@rock-chips.com <mailto:andy.yan@rock-chips.com>> >>>> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com <mailto:philipp.tomsich@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: > ptomsich@android:~/u-boot-rockchip$ git status > On branch master > Your branch is up-to-date with 'origin/master'. > ptomsich@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; >>>> } >
[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@theobroma-systems.com <mailto:philipp.tomsich@theobroma-systems.com>> wrote: > > >> On 29 Nov 2017, at 07:34, Andy Yan <andy.yan@rock-chips.com <mailto:andy.yan@rock-chips.com> <mailto:andy.yan@rock-chips.com <mailto:andy.yan@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@rock-chips.com <mailto:andy.yan@rock-chips.com> <mailto:andy.yan@rock-chips.com <mailto:andy.yan@rock-chips.com>>> >>>> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com <mailto:philipp.tomsich@theobroma-systems.com> <mailto:philipp.tomsich@theobroma-systems.com <mailto:philipp.tomsich@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: > ptomsich@android:~/u-boot-rockchip$ git status > On branch master > Your branch is up-to-date with 'origin/master'. > ptomsich@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; >>>> } >
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@theobroma-systems.com >> <mailto:philipp.tomsich@theobroma-systems.com>> wrote: >> >> >>> On 29 Nov 2017, at 07:34, Andy Yan <andy.yan@rock-chips.com >>> <mailto:andy.yan@rock-chips.com><mailto:andy.yan@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@rock-chips.com >>>>> <mailto:andy.yan@rock-chips.com><mailto:andy.yan@rock-chips.com>> >>>>> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com >>>>> <mailto:philipp.tomsich@theobroma-systems.com><mailto:philipp.tomsich@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@android:~/u-boot-rockchip$ git status >> On branch master >> Your branch is up-to-date with 'origin/master'. >> ptomsich@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@lists.denx.de <mailto:U-Boot@lists.denx.de> > https://lists.denx.de/listinfo/u-boot
Hi Philipp, On 29 November 2017 at 02:53, Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com> 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@theobroma-systems.com> wrote: > > > On 29 Nov 2017, at 07:34, Andy Yan <andy.yan@rock-chips.com > <mailto:andy.yan@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@rock-chips.com > <mailto:andy.yan@rock-chips.com>> > Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com > <mailto:philipp.tomsich@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: > ptomsich@android:~/u-boot-rockchip$ git status > On branch master > Your branch is up-to-date with 'origin/master'. > ptomsich@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. I agree that we should do this with a generic driver if that is what Linux does. We should try to avoid creating migration work for the next person. It does not seem that hard to do? > > > > - 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; > } Regards, Simon
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]; + } - 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; }
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@rock-chips.com> --- arch/arm/mach-rockchip/boot_mode.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)