On 19/11/30 10:07PM, Mohammad Rasim wrote:
> On 19/11/30 07:57PM, Martin Blumenstingl wrote:
> > On Sat, Nov 30, 2019 at 6:47 PM Mohammad Rasim
> > <mohammad.rasim96@xxxxxxxxx> wrote:
> > >
> > > On 19/11/30 02:59PM, Martin Blumenstingl wrote:
> > > > Hi Mohammad,
> > > >
> > > > this patch should be third in the series.
> > > > the currently missing patch for the dt-bindings should be patch two.
> > > > you can take the following commit as an example:
> > > > effdd8a6b6ecb30b088f36ed0a1fb67cdc7610a9 ("dt-bindings: arm: amlogic:
> > > > add SEI Robotics SEI610 bindings")
> > > >
> > > > On Sat, Nov 30, 2019 at 12:58 PM Mohammad Rasim
> > > > <mohammad.rasim96@xxxxxxxxx> wrote:
> > > > >
> > > > > This patch adds support for the Videostrong KII Pro tv box which is
> > > > > based on the gxbb-p201 reference design
> > > > >
> > > > > The device tree includes a new compatible for bluetooth "brcm,bcm4335a0"
> > > > > which was merged recently into torvalds tree
> > > > >
> > > > > Signed-off-by: Mohammad Rasim <mohammad.rasim96@xxxxxxxxx>
> > > > > ---
> > > > > arch/arm64/boot/dts/amlogic/Makefile | 1 +
> > > > > .../boot/dts/amlogic/meson-gxbb-kii-pro.dts | 76 +++++++++++++++++++
> > > > > 2 files changed, 77 insertions(+)
> > > > > create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
> > > > > index 84afecba9ec0..a795a170dcab 100644
> > > > > --- a/arch/arm64/boot/dts/amlogic/Makefile
> > > > > +++ b/arch/arm64/boot/dts/amlogic/Makefile
> > > > > @@ -6,6 +6,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
> > > > > dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
> > > > > dtb-$(CONFIG_ARCH_MESON) += meson-g12b-s922x-khadas-vim3.dtb
> > > > > dtb-$(CONFIG_ARCH_MESON) += meson-g12b-odroid-n2.dtb
> > > > > +dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-kii-pro.dtb
> > > > > dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-nanopi-k2.dtb
> > > > > dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-nexbox-a95x.dtb
> > > > > dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-odroidc2.dtb
> > > > > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
> > > > > new file mode 100644
> > > > > index 000000000000..5d120e6ca338
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-kii-pro.dts
> > > > > @@ -0,0 +1,76 @@
> > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > > +/*
> > > > > + * Copyright (c) 2019 Mohammad Rasim <mohammad.rasim96@xxxxxxxxx>
> > > > > + */
> > > > > +
> > > > > +/dts-v1/;
> > > > > +
> > > > > +#include "meson-gxbb-p20x.dtsi"
> > > > > +
> > > > > +#include <dt-bindings/gpio/gpio.h>
> > > > > +#include <dt-bindings/input/input.h>
> > > > > +/ {
> > > > > + compatible = "videostrong,kii-pro", "amlogic,p201", "amlogic,s905", "amlogic,meson-gxbb";
> > > > > + model = "Videostrong KII Pro";
> > > > > +
> > > > > + leds {
> > > > > + compatible = "gpio-leds";
> > > > > + red {
> > > > > + label = "status";
> > > > this property seems to be deprecated now, see
> > > > Documentation/devicetree/bindings/leds/common.txt
> > > > but I'm not sure whether Kevin has made a decision yet when to not
> > > > accept "label" properties here anymore
> > > OK, I will remove the deprecated property
> > > but I'm not sure what should I choose as a function, LED_FUNCTION_STATUS
> > > or LED_FUNCTION_ACTIVITY ?
> > I haven't used function and color myself but I believe it works like
> > this (untested):
> > - add an #include <dt-bindings/leds/common.h> next to the other
> > #includes (keep alphabetical ordering). this include file also
> > contains all the #defines for color and function
> > - add a color property, for example: color = <LED_COLOR_ID_RED>;
> > - add a function property, for example: function = <LED_FUNCTION_STATUS>;
> > - test, debug and fix potential issues ;)
> Yes, I've already tested it but I'm just not sure what should be in the
> function property, LED_FUNCTION_STATUS and LED_FUNCTION_ACTIVITY both
> seem like good choices,
> in my tests this property was prepended to the label
Scratch that, I was confused because i changed the node name, the labled
is generated from the color property and the node name.
although my question regarding userspace usage still applies.
> So the following:
>
> status {
> gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>;
> default-state = "off";
> color = <LED_COLOR_ID_RED>;
> function = LED_FUNCTION_STATUS;
> };
> resulted in a led labeled red:status
> [root@alarm ~]# ls /sys/class/leds/
> input1::capslock input1::numlock input1::scrolllock red:status
>
> if this property only used to lable the led then LED_FUNCTION_STATUS is
> ok, but maybe this is used by userspace to trigger the led ?!
>
> Regards
> >
> >
> > Martin
