* v9 EL15203000 @ 2019-09-18 10:52 Oleh Kravchenko 2019-09-18 10:52 ` [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 Oleh Kravchenko 2019-09-18 10:52 ` [PATCH v9 2/2] leds: add LED driver for EL15203000 board Oleh Kravchenko 0 siblings, 2 replies; 9+ messages in thread From: Oleh Kravchenko @ 2019-09-18 10:52 UTC (permalink / raw) To: devicetree, linux-leds, jacek.anaszewski, pavel [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 [PATCH v9 2/2] leds: add LED driver for EL15203000 board Changes what was made: - updated Documentation/devicetree/bindings/leds/leds-el15203000.txt after code review from Dan Murphy. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 2019-09-18 10:52 v9 EL15203000 Oleh Kravchenko @ 2019-09-18 10:52 ` Oleh Kravchenko 2019-09-18 21:02 ` Jacek Anaszewski 2019-09-18 10:52 ` [PATCH v9 2/2] leds: add LED driver for EL15203000 board Oleh Kravchenko 1 sibling, 1 reply; 9+ messages in thread From: Oleh Kravchenko @ 2019-09-18 10:52 UTC (permalink / raw) To: devicetree, linux-leds, jacek.anaszewski, pavel; +Cc: Oleh Kravchenko Add documentation and example for dt-bindings EL15203000. LED board (aka RED LED board) from Crane Merchandising Systems. Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua> --- .../bindings/leds/leds-el15203000.txt | 147 ++++++++++++++++++ 1 file changed, 147 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-el15203000.txt diff --git a/Documentation/devicetree/bindings/leds/leds-el15203000.txt b/Documentation/devicetree/bindings/leds/leds-el15203000.txt new file mode 100644 index 000000000000..4a9b29cc9f46 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-el15203000.txt @@ -0,0 +1,147 @@ +Crane Merchandising System - EL15203000 LED driver +-------------------------------------------------- + +This LED Board (aka RED LEDs board) is widely used in +coffee vending machines produced by Crane Merchandising Systems. +The board manages 3 LEDs and supports predefined blinking patterns +for specific leds. + +Vending area LED encoded with symbol 'V' (hex code 0x56). +Doesn't have any hardware blinking pattern. + +Screen light tube LED which surrounds vending machine screen and +encoded with symbol 'S' (hex code 0x53). Supports blinking breathing pattern: + + ^ + | +Max >_____***___________** + | * * * + | * * * + | * * * + | * * * +Min >*___________***______ + | + +------^------^------> time (sec) + 0 4 8 + + +Water Pipe LED actually consists from 5 LEDs +that exposed by protocol like one LED. Supports next patterns: + +- cascade pattern + + ^ + | +LED0 >*****____________________*****____________________***** + | +LED1 >_____*****____________________*****____________________ + | +LED2 >__________*****____________________*****_______________ + | +LED3 >_______________*****____________________*****__________ + | +LED4 >____________________*****____________________*****_____ + | + +----^----^----^----^----^----^----^----^----^----^----> time (sec) + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 + +- inversed cascade pattern + + ^ + | +LED0 >_____********************_____********************_____ + | +LED1 >*****_____********************_____******************** + | +LED2 >**********_____********************_____*************** + | +LED3 >***************_____********************_____********** + | +LED4 >********************_____********************_____***** + | + +----^----^----^----^----^----^----^----^----^----^----> time (sec) + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 + +- bounce pattern + + ^ + | +LED0 >*****________________________________________*****_____ + | +LED1 >_____*****______________________________*****_____***** + | +LED2 >__________*****____________________*****_______________ + | +LED3 >_______________*****__________*****____________________ + | +LED4 >____________________**********_________________________ + | + +----^----^----^----^----^----^----^----^----^----^----> time (sec) + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 + +- inversed bounce pattern + + ^ + | +LED0 >_____****************************************_____***** + | +LED1 >*****_____******************************_____*****_____ + | +LED2 >**********_____********************_____*************** + | +LED3 >***************_____**********_____******************** + | +LED4 >********************__________************************* + | + +----^----^----^----^----^----^----^----^----^----^----> time (sec) + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 + +Required properties: +- compatible : "crane,el15203000" +- #address-cells : must be 1 +- #size-cells : must be 0 + +Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt +apply. In particular, "reg" and "spi-max-frequency" properties must be given. + +Optional LED sub-node properties: +- function: + see Documentation/devicetree/bindings/leds/common.txt +- color: + see Documentation/devicetree/bindings/leds/common.txt +- label: + see Documentation/devicetree/bindings/leds/common.txt (deprecated) + +Example +------- + +#include <dt-bindings/leds/common.h> + +led-controller@0 { + compatible = "crane,el15203000"; + reg = <0>; + spi-max-frequency = <50000>; + #address-cells = <1>; + #size-cells = <0>; + + /* water pipe */ + led@50 { + reg = <0x50>; + function = "pipe"; + color = <LED_COLOR_ID_RED>; + }; + + /* screen frame */ + led@53 { + reg = <0x53>; + function = "screen"; + color = <LED_COLOR_ID_RED>; + }; + + /* vending area */ + led@56 { + reg = <0x56>; + function = "vend"; + color = <LED_COLOR_ID_RED>; + }; +}; -- 2.21.0 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 2019-09-18 10:52 ` [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 Oleh Kravchenko @ 2019-09-18 21:02 ` Jacek Anaszewski 2019-09-18 21:17 ` Oleh Kravchenko 0 siblings, 1 reply; 9+ messages in thread From: Jacek Anaszewski @ 2019-09-18 21:02 UTC (permalink / raw) To: Oleh Kravchenko, devicetree, linux-leds, pavel; +Cc: Rob Herring Hi Oleh, Thank you for the update. I have some comments below. Please take a look. On 9/18/19 12:52 PM, Oleh Kravchenko wrote: > Add documentation and example for dt-bindings EL15203000. > LED board (aka RED LED board) from Crane Merchandising Systems. > > Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua> > --- > .../bindings/leds/leds-el15203000.txt | 147 ++++++++++++++++++ > 1 file changed, 147 insertions(+) > create mode 100644 Documentation/devicetree/bindings/leds/leds-el15203000.txt > > diff --git a/Documentation/devicetree/bindings/leds/leds-el15203000.txt b/Documentation/devicetree/bindings/leds/leds-el15203000.txt > new file mode 100644 > index 000000000000..4a9b29cc9f46 > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/leds-el15203000.txt > @@ -0,0 +1,147 @@ > +Crane Merchandising System - EL15203000 LED driver > +-------------------------------------------------- > + > +This LED Board (aka RED LEDs board) is widely used in > +coffee vending machines produced by Crane Merchandising Systems. > +The board manages 3 LEDs and supports predefined blinking patterns > +for specific leds. > + > +Vending area LED encoded with symbol 'V' (hex code 0x56). > +Doesn't have any hardware blinking pattern. > + > +Screen light tube LED which surrounds vending machine screen and > +encoded with symbol 'S' (hex code 0x53). Supports blinking breathing pattern: > + > + ^ > + | > +Max >_____***___________** > + | * * * > + | * * * > + | * * * > + | * * * > +Min >*___________***______ > + | > + +------^------^------> time (sec) > + 0 4 8 > + > + > +Water Pipe LED actually consists from 5 LEDs "(hex code 0x50)" is here missing if you want to be consistent. > +that exposed by protocol like one LED. Supports next patterns: > + > +- cascade pattern > + > + ^ > + | > +LED0 >*****____________________*****____________________***** > + | > +LED1 >_____*****____________________*****____________________ > + | > +LED2 >__________*****____________________*****_______________ > + | > +LED3 >_______________*****____________________*****__________ > + | > +LED4 >____________________*****____________________*****_____ > + | > + +----^----^----^----^----^----^----^----^----^----^----> time (sec) > + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 > + > +- inversed cascade pattern > + > + ^ > + | > +LED0 >_____********************_____********************_____ > + | > +LED1 >*****_____********************_____******************** > + | > +LED2 >**********_____********************_____*************** > + | > +LED3 >***************_____********************_____********** > + | > +LED4 >********************_____********************_____***** > + | > + +----^----^----^----^----^----^----^----^----^----^----> time (sec) > + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 > + > +- bounce pattern > + > + ^ > + | > +LED0 >*****________________________________________*****_____ > + | > +LED1 >_____*****______________________________*****_____***** > + | > +LED2 >__________*****____________________*****_______________ > + | > +LED3 >_______________*****__________*****____________________ > + | > +LED4 >____________________**********_________________________ > + | > + +----^----^----^----^----^----^----^----^----^----^----> time (sec) > + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 > + > +- inversed bounce pattern > + > + ^ > + | > +LED0 >_____****************************************_____***** > + | > +LED1 >*****_____******************************_____*****_____ > + | > +LED2 >**********_____********************_____*************** > + | > +LED3 >***************_____**********_____******************** > + | > +LED4 >********************__________************************* > + | > + +----^----^----^----^----^----^----^----^----^----^----> time (sec) > + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 Regarding this ASCII art - I presume you wanted to follow Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt. It was added to bindings because we support 'pattern' value for linux,default-trigger, which in turn looks for 'led-pattern' property, whose format needs to be documented in the LED bindings. leds-trigger-pattern.txt documents only common syntax for software pattern engine. Currently we don't have a means to setup hw_pattern for the pattern trigger from DT, which is obvious omission and your patch just brings it to light. That said, I propose to fix it alongside and introduce led-hw-pattern property. When present, ledtrig-pattern would setup the pattern using pattern_set op, similarly as if it was set via sysfs hw_pattern file. Only in this case placing the pattern depiction here would be justified. Otherwise, it would have to land in the ABI documentation. > + > +Required properties: > +- compatible : "crane,el15203000" > +- #address-cells : must be 1 > +- #size-cells : must be 0 > + > +Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt > +apply. In particular, "reg" and "spi-max-frequency" properties must be given. > + > +Optional LED sub-node properties: > +- function: > + see Documentation/devicetree/bindings/leds/common.txt > +- color: > + see Documentation/devicetree/bindings/leds/common.txt > +- label: > + see Documentation/devicetree/bindings/leds/common.txt (deprecated) > + > +Example > +------- > + > +#include <dt-bindings/leds/common.h> > + > +led-controller@0 { > + compatible = "crane,el15203000"; > + reg = <0>; > + spi-max-frequency = <50000>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + /* water pipe */ > + led@50 { > + reg = <0x50>; > + function = "pipe"; > + color = <LED_COLOR_ID_RED>; > + }; > + > + /* screen frame */ > + led@53 { > + reg = <0x53>; > + function = "screen"; > + color = <LED_COLOR_ID_RED>; > + }; > + > + /* vending area */ > + led@56 { > + reg = <0x56>; > + function = "vend"; > + color = <LED_COLOR_ID_RED>; > + }; > +}; > -- Best regards, Jacek Anaszewski ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 2019-09-18 21:02 ` Jacek Anaszewski @ 2019-09-18 21:17 ` Oleh Kravchenko 2019-09-18 21:28 ` Jacek Anaszewski 2019-10-13 12:11 ` Pavel Machek 0 siblings, 2 replies; 9+ messages in thread From: Oleh Kravchenko @ 2019-09-18 21:17 UTC (permalink / raw) To: Jacek Anaszewski, devicetree, linux-leds, pavel; +Cc: Rob Herring Hello Jacek, 19.09.19 00:02, Jacek Anaszewski пише: > Hi Oleh, > > Thank you for the update. > > I have some comments below. Please take a look. > > On 9/18/19 12:52 PM, Oleh Kravchenko wrote: >> Add documentation and example for dt-bindings EL15203000. >> LED board (aka RED LED board) from Crane Merchandising Systems. >> >> Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua> >> --- >> .../bindings/leds/leds-el15203000.txt | 147 ++++++++++++++++++ >> 1 file changed, 147 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/leds/leds-el15203000.txt >> >> diff --git a/Documentation/devicetree/bindings/leds/leds-el15203000.txt b/Documentation/devicetree/bindings/leds/leds-el15203000.txt >> new file mode 100644 >> index 000000000000..4a9b29cc9f46 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/leds/leds-el15203000.txt >> @@ -0,0 +1,147 @@ >> +Crane Merchandising System - EL15203000 LED driver >> +-------------------------------------------------- >> + >> +This LED Board (aka RED LEDs board) is widely used in >> +coffee vending machines produced by Crane Merchandising Systems. >> +The board manages 3 LEDs and supports predefined blinking patterns >> +for specific leds. >> + >> +Vending area LED encoded with symbol 'V' (hex code 0x56). >> +Doesn't have any hardware blinking pattern. >> + >> +Screen light tube LED which surrounds vending machine screen and >> +encoded with symbol 'S' (hex code 0x53). Supports blinking breathing pattern: >> + >> + ^ >> + | >> +Max >_____***___________** >> + | * * * >> + | * * * >> + | * * * >> + | * * * >> +Min >*___________***______ >> + | >> + +------^------^------> time (sec) >> + 0 4 8 >> + >> + >> +Water Pipe LED actually consists from 5 LEDs > > "(hex code 0x50)" is here missing if you want to be consistent. > >> +that exposed by protocol like one LED. Supports next patterns: >> + >> +- cascade pattern >> + >> + ^ >> + | >> +LED0 >*****____________________*****____________________***** >> + | >> +LED1 >_____*****____________________*****____________________ >> + | >> +LED2 >__________*****____________________*****_______________ >> + | >> +LED3 >_______________*****____________________*****__________ >> + | >> +LED4 >____________________*****____________________*****_____ >> + | >> + +----^----^----^----^----^----^----^----^----^----^----> time (sec) >> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 >> + >> +- inversed cascade pattern >> + >> + ^ >> + | >> +LED0 >_____********************_____********************_____ >> + | >> +LED1 >*****_____********************_____******************** >> + | >> +LED2 >**********_____********************_____*************** >> + | >> +LED3 >***************_____********************_____********** >> + | >> +LED4 >********************_____********************_____***** >> + | >> + +----^----^----^----^----^----^----^----^----^----^----> time (sec) >> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 >> + >> +- bounce pattern >> + >> + ^ >> + | >> +LED0 >*****________________________________________*****_____ >> + | >> +LED1 >_____*****______________________________*****_____***** >> + | >> +LED2 >__________*****____________________*****_______________ >> + | >> +LED3 >_______________*****__________*****____________________ >> + | >> +LED4 >____________________**********_________________________ >> + | >> + +----^----^----^----^----^----^----^----^----^----^----> time (sec) >> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 >> + >> +- inversed bounce pattern >> + >> + ^ >> + | >> +LED0 >_____****************************************_____***** >> + | >> +LED1 >*****_____******************************_____*****_____ >> + | >> +LED2 >**********_____********************_____*************** >> + | >> +LED3 >***************_____**********_____******************** >> + | >> +LED4 >********************__________************************* >> + | >> + +----^----^----^----^----^----^----^----^----^----^----> time (sec) >> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 > > Regarding this ASCII art - I presume you wanted to follow > Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt. > > It was added to bindings because we support 'pattern' value > for linux,default-trigger, which in turn looks for 'led-pattern' > property, whose format needs to be documented in the LED bindings. > > leds-trigger-pattern.txt documents only common syntax for software > pattern engine. Currently we don't have a means to setup hw_pattern > for the pattern trigger from DT, which is obvious omission and your > patch just brings it to light. > > That said, I propose to fix it alongside and introduce led-hw-pattern > property. When present, ledtrig-pattern would setup the pattern > using pattern_set op, similarly as if it was set via sysfs hw_pattern > file. > > Only in this case placing the pattern depiction here would be justified. > Otherwise, it would have to land in the ABI documentation. You are okay, if I move it to Documentation/ABI/testing/sysfs-class-led-driver-el15203000 ? -- Best regards, Oleh Kravchenko ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 2019-09-18 21:17 ` Oleh Kravchenko @ 2019-09-18 21:28 ` Jacek Anaszewski 2019-10-13 12:11 ` Pavel Machek 1 sibling, 0 replies; 9+ messages in thread From: Jacek Anaszewski @ 2019-09-18 21:28 UTC (permalink / raw) To: Oleh Kravchenko, devicetree, linux-leds, pavel; +Cc: Rob Herring On 9/18/19 11:17 PM, Oleh Kravchenko wrote: > Hello Jacek, > > 19.09.19 00:02, Jacek Anaszewski пише: >> Hi Oleh, >> >> Thank you for the update. >> >> I have some comments below. Please take a look. >> >> On 9/18/19 12:52 PM, Oleh Kravchenko wrote: >>> Add documentation and example for dt-bindings EL15203000. >>> LED board (aka RED LED board) from Crane Merchandising Systems. >>> >>> Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua> >>> --- >>> .../bindings/leds/leds-el15203000.txt | 147 ++++++++++++++++++ >>> 1 file changed, 147 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/leds/leds-el15203000.txt >>> >>> diff --git a/Documentation/devicetree/bindings/leds/leds-el15203000.txt b/Documentation/devicetree/bindings/leds/leds-el15203000.txt >>> new file mode 100644 >>> index 000000000000..4a9b29cc9f46 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/leds/leds-el15203000.txt >>> @@ -0,0 +1,147 @@ >>> +Crane Merchandising System - EL15203000 LED driver >>> +-------------------------------------------------- >>> + >>> +This LED Board (aka RED LEDs board) is widely used in >>> +coffee vending machines produced by Crane Merchandising Systems. >>> +The board manages 3 LEDs and supports predefined blinking patterns >>> +for specific leds. >>> + >>> +Vending area LED encoded with symbol 'V' (hex code 0x56). >>> +Doesn't have any hardware blinking pattern. >>> + >>> +Screen light tube LED which surrounds vending machine screen and >>> +encoded with symbol 'S' (hex code 0x53). Supports blinking breathing pattern: >>> + >>> + ^ >>> + | >>> +Max >_____***___________** >>> + | * * * >>> + | * * * >>> + | * * * >>> + | * * * >>> +Min >*___________***______ >>> + | >>> + +------^------^------> time (sec) >>> + 0 4 8 >>> + >>> + >>> +Water Pipe LED actually consists from 5 LEDs >> >> "(hex code 0x50)" is here missing if you want to be consistent. >> >>> +that exposed by protocol like one LED. Supports next patterns: >>> + >>> +- cascade pattern >>> + >>> + ^ >>> + | >>> +LED0 >*****____________________*****____________________***** >>> + | >>> +LED1 >_____*****____________________*****____________________ >>> + | >>> +LED2 >__________*****____________________*****_______________ >>> + | >>> +LED3 >_______________*****____________________*****__________ >>> + | >>> +LED4 >____________________*****____________________*****_____ >>> + | >>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec) >>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 >>> + >>> +- inversed cascade pattern >>> + >>> + ^ >>> + | >>> +LED0 >_____********************_____********************_____ >>> + | >>> +LED1 >*****_____********************_____******************** >>> + | >>> +LED2 >**********_____********************_____*************** >>> + | >>> +LED3 >***************_____********************_____********** >>> + | >>> +LED4 >********************_____********************_____***** >>> + | >>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec) >>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 >>> + >>> +- bounce pattern >>> + >>> + ^ >>> + | >>> +LED0 >*****________________________________________*****_____ >>> + | >>> +LED1 >_____*****______________________________*****_____***** >>> + | >>> +LED2 >__________*****____________________*****_______________ >>> + | >>> +LED3 >_______________*****__________*****____________________ >>> + | >>> +LED4 >____________________**********_________________________ >>> + | >>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec) >>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 >>> + >>> +- inversed bounce pattern >>> + >>> + ^ >>> + | >>> +LED0 >_____****************************************_____***** >>> + | >>> +LED1 >*****_____******************************_____*****_____ >>> + | >>> +LED2 >**********_____********************_____*************** >>> + | >>> +LED3 >***************_____**********_____******************** >>> + | >>> +LED4 >********************__________************************* >>> + | >>> + +----^----^----^----^----^----^----^----^----^----^----> time (sec) >>> + 0 0.8 1.6 2.4 3.2 4 4.8 5.6 6.4 7.2 8 >> >> Regarding this ASCII art - I presume you wanted to follow >> Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt. >> >> It was added to bindings because we support 'pattern' value >> for linux,default-trigger, which in turn looks for 'led-pattern' >> property, whose format needs to be documented in the LED bindings. >> >> leds-trigger-pattern.txt documents only common syntax for software >> pattern engine. Currently we don't have a means to setup hw_pattern >> for the pattern trigger from DT, which is obvious omission and your >> patch just brings it to light. >> >> That said, I propose to fix it alongside and introduce led-hw-pattern >> property. When present, ledtrig-pattern would setup the pattern >> using pattern_set op, similarly as if it was set via sysfs hw_pattern >> file. >> >> Only in this case placing the pattern depiction here would be justified. >> Otherwise, it would have to land in the ABI documentation. > > You are okay, if I move it to Documentation/ABI/testing/sysfs-class-led-driver-el15203000 ? > Yes, we can cover led-hw-pattern property later. -- Best regards, Jacek Anaszewski ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 2019-09-18 21:17 ` Oleh Kravchenko 2019-09-18 21:28 ` Jacek Anaszewski @ 2019-10-13 12:11 ` Pavel Machek 2019-10-13 16:47 ` Jacek Anaszewski 1 sibling, 1 reply; 9+ messages in thread From: Pavel Machek @ 2019-10-13 12:11 UTC (permalink / raw) To: Oleh Kravchenko; +Cc: Jacek Anaszewski, devicetree, linux-leds, Rob Herring [-- Attachment #1: Type: text/plain, Size: 1423 bytes --] Hi! > > Regarding this ASCII art - I presume you wanted to follow > > Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt. > > > > It was added to bindings because we support 'pattern' value > > for linux,default-trigger, which in turn looks for 'led-pattern' > > property, whose format needs to be documented in the LED bindings. > > > > leds-trigger-pattern.txt documents only common syntax for software > > pattern engine. Currently we don't have a means to setup hw_pattern > > for the pattern trigger from DT, which is obvious omission and your > > patch just brings it to light. > > > > That said, I propose to fix it alongside and introduce led-hw-pattern > > property. When present, ledtrig-pattern would setup the pattern > > using pattern_set op, similarly as if it was set via sysfs hw_pattern > > file. > > > > Only in this case placing the pattern depiction here would be justified. > > Otherwise, it would have to land in the ABI documentation. > > You are okay, if I move it to Documentation/ABI/testing/sysfs-class-led-driver-el15203000 ? I don't see if this got a reply. Yes, Documentation/ABI/testing/sysfs-class-led-driver-el15203000 sounds like a right place for the sysfs description. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 2019-10-13 12:11 ` Pavel Machek @ 2019-10-13 16:47 ` Jacek Anaszewski 2019-10-13 17:29 ` Oleh Kravchenko 0 siblings, 1 reply; 9+ messages in thread From: Jacek Anaszewski @ 2019-10-13 16:47 UTC (permalink / raw) To: Pavel Machek, Oleh Kravchenko; +Cc: devicetree, linux-leds, Rob Herring Hi Pavel. On 10/13/19 2:11 PM, Pavel Machek wrote: > Hi! > >>> Regarding this ASCII art - I presume you wanted to follow >>> Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt. >>> >>> It was added to bindings because we support 'pattern' value >>> for linux,default-trigger, which in turn looks for 'led-pattern' >>> property, whose format needs to be documented in the LED bindings. >>> >>> leds-trigger-pattern.txt documents only common syntax for software >>> pattern engine. Currently we don't have a means to setup hw_pattern >>> for the pattern trigger from DT, which is obvious omission and your >>> patch just brings it to light. >>> >>> That said, I propose to fix it alongside and introduce led-hw-pattern >>> property. When present, ledtrig-pattern would setup the pattern >>> using pattern_set op, similarly as if it was set via sysfs hw_pattern >>> file. >>> >>> Only in this case placing the pattern depiction here would be justified. >>> Otherwise, it would have to land in the ABI documentation. >> >> You are okay, if I move it to Documentation/ABI/testing/sysfs-class-led-driver-el15203000 ? > > I don't see if this got a reply. Yes, > Documentation/ABI/testing/sysfs-class-led-driver-el15203000 sounds > like a right place for the sysfs description. There was no explicit reply because Oleh sent the update with this change before I managed to respond. And the patch is already in the for-next branch with the file in the discussed location. So the reply was in the form of my later confirmation that the patch was applied. -- Best regards, Jacek Anaszewski ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 2019-10-13 16:47 ` Jacek Anaszewski @ 2019-10-13 17:29 ` Oleh Kravchenko 0 siblings, 0 replies; 9+ messages in thread From: Oleh Kravchenko @ 2019-10-13 17:29 UTC (permalink / raw) To: Jacek Anaszewski, Pavel Machek; +Cc: devicetree, linux-leds, Rob Herring [-- Attachment #1.1: Type: text/plain, Size: 1772 bytes --] Hello Pavel, 13.10.19 19:47, Jacek Anaszewski пише: > Hi Pavel. > > On 10/13/19 2:11 PM, Pavel Machek wrote: >> Hi! >> >>>> Regarding this ASCII art - I presume you wanted to follow >>>> Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt. >>>> >>>> It was added to bindings because we support 'pattern' value >>>> for linux,default-trigger, which in turn looks for 'led-pattern' >>>> property, whose format needs to be documented in the LED bindings. >>>> >>>> leds-trigger-pattern.txt documents only common syntax for software >>>> pattern engine. Currently we don't have a means to setup hw_pattern >>>> for the pattern trigger from DT, which is obvious omission and your >>>> patch just brings it to light. >>>> >>>> That said, I propose to fix it alongside and introduce led-hw-pattern >>>> property. When present, ledtrig-pattern would setup the pattern >>>> using pattern_set op, similarly as if it was set via sysfs hw_pattern >>>> file. >>>> >>>> Only in this case placing the pattern depiction here would be justified. >>>> Otherwise, it would have to land in the ABI documentation. >>> >>> You are okay, if I move it to Documentation/ABI/testing/sysfs-class-led-driver-el15203000 ? >> >> I don't see if this got a reply. Yes, >> Documentation/ABI/testing/sysfs-class-led-driver-el15203000 sounds >> like a right place for the sysfs description. > > There was no explicit reply because Oleh sent the update with this > change before I managed to respond. And the patch is already in the > for-next branch with the file in the discussed location. So the reply > was in the form of my later confirmation that the patch was applied. > Anyway thanks for reply. -- Best regards, Oleh Kravchenko [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v9 2/2] leds: add LED driver for EL15203000 board 2019-09-18 10:52 v9 EL15203000 Oleh Kravchenko 2019-09-18 10:52 ` [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 Oleh Kravchenko @ 2019-09-18 10:52 ` Oleh Kravchenko 1 sibling, 0 replies; 9+ messages in thread From: Oleh Kravchenko @ 2019-09-18 10:52 UTC (permalink / raw) To: devicetree, linux-leds, jacek.anaszewski, pavel Cc: Oleh Kravchenko, Dan Murphy This patch adds a LED class driver for the LEDs found on the Crane Merchandising System EL15203000 LEDs board (aka RED LEDs board). Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua> Reviewed-by: Dan Murphy <dmurphy@ti.com> --- .../testing/sysfs-class-led-driver-el15203000 | 32 ++ drivers/leds/Kconfig | 13 + drivers/leds/Makefile | 1 + drivers/leds/leds-el15203000.c | 357 ++++++++++++++++++ 4 files changed, 403 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-el15203000 create mode 100644 drivers/leds/leds-el15203000.c diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 b/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 new file mode 100644 index 000000000000..5e9cbf49da59 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-driver-el15203000 @@ -0,0 +1,32 @@ +What: /sys/class/leds/<led>/hw_pattern +Date: September 2019 +KernelVersion: 5.5 +Description: + Specify a hardware pattern for the EL15203000 LED. + The LEDs board supports only predefined patterns by firmware + for specific LEDs. + + Breathing mode for Screen frame light tube: + "0 4000 1 4000" + + Cascade mode for Pipe LED: + "1 800 2 800 4 800 8 800 16 800" + + Inverted cascade mode for Pipe LED: + "30 800 29 800 27 800 23 800 15 800" + + Bounce mode for Pipe LED: + "1 800 2 800 4 800 8 800 16 800 16 800 8 800 4 800 2 800 1 800" + + Inverted bounce mode for Pipe LED: + "30 800 29 800 27 800 23 800 15 800 15 800 23 800 27 800 29 800 30 800" + +What: /sys/class/leds/<led>/repeat +Date: September 2019 +KernelVersion: 5.5 +Description: + EL15203000 supports only indefinitely patterns, + so this file should always store -1. + + For more info, please see: + Documentation/ABI/testing/sysfs-class-led-trigger-pattern diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index 1988de1d64c0..6e7703fd03d0 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -132,6 +132,19 @@ config LEDS_CR0014114 To compile this driver as a module, choose M here: the module will be called leds-cr0014114. +config LEDS_EL15203000 + tristate "LED Support for Crane EL15203000" + depends on LEDS_CLASS + depends on SPI + depends on OF + help + This option enables support for EL15203000 LED Board + (aka RED LED board) which is widely used in coffee vending + machines produced by Crane Merchandising Systems. + + To compile this driver as a module, choose M here: the module + will be called leds-el15203000. + config LEDS_LM3530 tristate "LCD Backlight driver for LM3530" depends on LEDS_CLASS diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index 41fb073a39c1..2da39e896ce8 100644 --- a/drivers/leds/Makefile +++ b/drivers/leds/Makefile @@ -89,6 +89,7 @@ obj-$(CONFIG_LEDS_LM36274) += leds-lm36274.o # LED SPI Drivers obj-$(CONFIG_LEDS_CR0014114) += leds-cr0014114.o obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o +obj-$(CONFIG_LEDS_EL15203000) += leds-el15203000.o # LED Userspace Drivers obj-$(CONFIG_LEDS_USER) += uleds.o diff --git a/drivers/leds/leds-el15203000.c b/drivers/leds/leds-el15203000.c new file mode 100644 index 000000000000..298b13e4807a --- /dev/null +++ b/drivers/leds/leds-el15203000.c @@ -0,0 +1,357 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (c) 2019 Crane Merchandising Systems. All rights reserved. +// Copyright (C) 2019 Oleh Kravchenko <oleg@kaa.org.ua> + +#include <linux/delay.h> +#include <linux/leds.h> +#include <linux/module.h> +#include <linux/of_device.h> +#include <linux/spi/spi.h> + +/* + * EL15203000 SPI protocol description: + * +-----+---------+ + * | LED | COMMAND | + * +-----+---------+ + * | 1 | 1 | + * +-----+---------+ + * (*) LEDs MCU board expects 20 msec delay per byte. + * + * LEDs: + * +----------+--------------+-------------------------------------------+ + * | ID | NAME | DESCRIPTION | + * +----------+--------------+-------------------------------------------+ + * | 'P' 0x50 | Pipe | Consists from 5 LEDs, controlled by board | + * +----------+--------------+-------------------------------------------+ + * | 'S' 0x53 | Screen frame | Light tube around the screen | + * +----------+--------------+-------------------------------------------+ + * | 'V' 0x56 | Vending area | Highlights a cup of coffee | + * +----------+--------------+-------------------------------------------+ + * + * COMMAND: + * +----------+-----------------+--------------+--------------+ + * | VALUES | PIPE | SCREEN FRAME | VENDING AREA | + * +----------+-----------------+--------------+--------------+ + * | '0' 0x30 | Off | + * +----------+-----------------------------------------------+ + * | '1' 0x31 | On | + * +----------+-----------------+--------------+--------------+ + * | '2' 0x32 | Cascade | Breathing | + * +----------+-----------------+--------------+ + * | '3' 0x33 | Inverse cascade | + * +----------+-----------------+ + * | '4' 0x34 | Bounce | + * +----------+-----------------+ + * | '5' 0x35 | Inverse bounce | + * +----------+-----------------+ + */ + +/* EL15203000 default settings */ +#define EL_FW_DELAY_USEC 20000ul +#define EL_PATTERN_DELAY_MSEC 800u +#define EL_PATTERN_LEN 10u +#define EL_PATTERN_HALF_LEN (EL_PATTERN_LEN / 2) + +enum el15203000_command { + /* for all LEDs */ + EL_OFF = '0', + EL_ON = '1', + + /* for Screen LED */ + EL_SCREEN_BREATHING = '2', + + /* for Pipe LED */ + EL_PIPE_CASCADE = '2', + EL_PIPE_INV_CASCADE = '3', + EL_PIPE_BOUNCE = '4', + EL_PIPE_INV_BOUNCE = '5', +}; + +struct el15203000_led { + struct el15203000 *priv; + struct led_classdev ldev; + u32 reg; +}; + +struct el15203000 { + struct device *dev; + struct mutex lock; + struct spi_device *spi; + unsigned long delay; + size_t count; + struct el15203000_led leds[]; +}; + +static int el15203000_cmd(struct el15203000_led *led, u8 brightness) +{ + int ret; + u8 cmd[2]; + size_t i; + + mutex_lock(&led->priv->lock); + + dev_dbg(led->priv->dev, "Set brightness of 0x%02x(%c) to 0x%02x(%c)", + led->reg, led->reg, brightness, brightness); + + /* to avoid SPI mistiming with firmware we should wait some time */ + if (time_after(led->priv->delay, jiffies)) { + dev_dbg(led->priv->dev, "Wait %luus to sync", + EL_FW_DELAY_USEC); + + usleep_range(EL_FW_DELAY_USEC, + EL_FW_DELAY_USEC + 1); + } + + cmd[0] = led->reg; + cmd[1] = brightness; + + for (i = 0; i < ARRAY_SIZE(cmd); i++) { + if (i) + usleep_range(EL_FW_DELAY_USEC, + EL_FW_DELAY_USEC + 1); + + ret = spi_write(led->priv->spi, &cmd[i], sizeof(cmd[i])); + if (ret) { + dev_err(led->priv->dev, + "spi_write() error %d", ret); + break; + } + } + + led->priv->delay = jiffies + usecs_to_jiffies(EL_FW_DELAY_USEC); + + mutex_unlock(&led->priv->lock); + + return ret; +} + +static int el15203000_set_blocking(struct led_classdev *ldev, + enum led_brightness brightness) +{ + struct el15203000_led *led = container_of(ldev, + struct el15203000_led, + ldev); + + return el15203000_cmd(led, brightness == LED_OFF ? EL_OFF : EL_ON); +} + +static int el15203000_pattern_set_S(struct led_classdev *ldev, + struct led_pattern *pattern, + u32 len, int repeat) +{ + struct el15203000_led *led = container_of(ldev, + struct el15203000_led, + ldev); + + if (repeat > 0 || len != 2 || + pattern[0].delta_t != 4000 || pattern[0].brightness != 0 || + pattern[1].delta_t != 4000 || pattern[1].brightness != 1) + return -EINVAL; + + dev_dbg(led->priv->dev, "Breathing mode for 0x%02x(%c)", + led->reg, led->reg); + + return el15203000_cmd(led, EL_SCREEN_BREATHING); +} + +static bool is_cascade(const struct led_pattern *pattern, u32 len, + bool inv, bool right) +{ + int val, t; + u32 i; + + if (len != EL_PATTERN_HALF_LEN) + return false; + + val = right ? BIT(4) : BIT(0); + + for (i = 0; i < len; i++) { + t = inv ? ~val & GENMASK(4, 0) : val; + + if (pattern[i].delta_t != EL_PATTERN_DELAY_MSEC || + pattern[i].brightness != t) + return false; + + val = right ? val >> 1 : val << 1; + } + + return true; +} + +static bool is_bounce(const struct led_pattern *pattern, u32 len, bool inv) +{ + if (len != EL_PATTERN_LEN) + return false; + + return is_cascade(pattern, EL_PATTERN_HALF_LEN, inv, false) && + is_cascade(pattern + EL_PATTERN_HALF_LEN, + EL_PATTERN_HALF_LEN, inv, true); +} + +static int el15203000_pattern_set_P(struct led_classdev *ldev, + struct led_pattern *pattern, + u32 len, int repeat) +{ + u8 cmd; + struct el15203000_led *led = container_of(ldev, + struct el15203000_led, + ldev); + + if (repeat > 0) + return -EINVAL; + + if (is_cascade(pattern, len, false, false)) { + dev_dbg(led->priv->dev, "Cascade mode for 0x%02x(%c)", + led->reg, led->reg); + + cmd = EL_PIPE_CASCADE; + } else if (is_cascade(pattern, len, true, false)) { + dev_dbg(led->priv->dev, "Inverse cascade mode for 0x%02x(%c)", + led->reg, led->reg); + + cmd = EL_PIPE_INV_CASCADE; + } else if (is_bounce(pattern, len, false)) { + dev_dbg(led->priv->dev, "Bounce mode for 0x%02x(%c)", + led->reg, led->reg); + + cmd = EL_PIPE_BOUNCE; + } else if (is_bounce(pattern, len, true)) { + dev_dbg(led->priv->dev, "Inverse bounce mode for 0x%02x(%c)", + led->reg, led->reg); + + cmd = EL_PIPE_INV_BOUNCE; + } else { + dev_err(led->priv->dev, "Invalid hw_pattern for 0x%02x(%c)!", + led->reg, led->reg); + + return -EINVAL; + } + + return el15203000_cmd(led, cmd); +} + +static int el15203000_pattern_clear(struct led_classdev *ldev) +{ + struct el15203000_led *led = container_of(ldev, + struct el15203000_led, + ldev); + + return el15203000_cmd(led, EL_OFF); +} + +static int el15203000_probe_dt(struct el15203000 *priv) +{ + struct el15203000_led *led = priv->leds; + struct fwnode_handle *child; + int ret; + + device_for_each_child_node(priv->dev, child) { + struct led_init_data init_data = {}; + + ret = fwnode_property_read_u32(child, "reg", &led->reg); + if (ret) { + dev_err(priv->dev, "LED without ID number"); + fwnode_handle_put(child); + + break; + } + + if (led->reg > U8_MAX) { + dev_err(priv->dev, "LED value %d is invalid", led->reg); + fwnode_handle_put(child); + + return -EINVAL; + } + + fwnode_property_read_string(child, "linux,default-trigger", + &led->ldev.default_trigger); + + led->priv = priv; + led->ldev.max_brightness = LED_ON; + led->ldev.brightness_set_blocking = el15203000_set_blocking; + + if (led->reg == 'S') { + led->ldev.pattern_set = el15203000_pattern_set_S; + led->ldev.pattern_clear = el15203000_pattern_clear; + } else if (led->reg == 'P') { + led->ldev.pattern_set = el15203000_pattern_set_P; + led->ldev.pattern_clear = el15203000_pattern_clear; + } + + init_data.fwnode = child; + ret = devm_led_classdev_register_ext(priv->dev, &led->ldev, + &init_data); + if (ret) { + dev_err(priv->dev, + "failed to register LED device %s, err %d", + led->ldev.name, ret); + fwnode_handle_put(child); + + break; + } + + led++; + } + + return ret; +} + +static int el15203000_probe(struct spi_device *spi) +{ + struct el15203000 *priv; + size_t count; + + count = device_get_child_node_count(&spi->dev); + if (!count) { + dev_err(&spi->dev, "LEDs are not defined in device tree!"); + return -ENODEV; + } + + priv = devm_kzalloc(&spi->dev, struct_size(priv, leds, count), + GFP_KERNEL); + if (!priv) + return -ENOMEM; + + mutex_init(&priv->lock); + priv->count = count; + priv->dev = &spi->dev; + priv->spi = spi; + priv->delay = jiffies - + usecs_to_jiffies(EL_FW_DELAY_USEC); + + spi_set_drvdata(spi, priv); + + return el15203000_probe_dt(priv); +} + +static int el15203000_remove(struct spi_device *spi) +{ + struct el15203000 *priv = spi_get_drvdata(spi); + + mutex_destroy(&priv->lock); + + return 0; +} + +static const struct of_device_id el15203000_dt_ids[] = { + { .compatible = "crane,el15203000", }, + {}, +}; + +MODULE_DEVICE_TABLE(of, el15203000_dt_ids); + +static struct spi_driver el15203000_driver = { + .probe = el15203000_probe, + .remove = el15203000_remove, + .driver = { + .name = KBUILD_MODNAME, + .of_match_table = el15203000_dt_ids, + }, +}; + +module_spi_driver(el15203000_driver); + +MODULE_AUTHOR("Oleh Kravchenko <oleg@kaa.org.ua>"); +MODULE_DESCRIPTION("el15203000 LED driver"); +MODULE_LICENSE("GPL v2"); +MODULE_ALIAS("spi:el15203000"); -- 2.21.0 ^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-10-13 17:29 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-09-18 10:52 v9 EL15203000 Oleh Kravchenko 2019-09-18 10:52 ` [PATCH v9 1/2] dt-bindings: Add docs for EL15203000 Oleh Kravchenko 2019-09-18 21:02 ` Jacek Anaszewski 2019-09-18 21:17 ` Oleh Kravchenko 2019-09-18 21:28 ` Jacek Anaszewski 2019-10-13 12:11 ` Pavel Machek 2019-10-13 16:47 ` Jacek Anaszewski 2019-10-13 17:29 ` Oleh Kravchenko 2019-09-18 10:52 ` [PATCH v9 2/2] leds: add LED driver for EL15203000 board Oleh Kravchenko
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.