From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9ABDFC4708D for ; Sat, 3 Dec 2022 12:25:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229512AbiLCMZn (ORCPT ); Sat, 3 Dec 2022 07:25:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229481AbiLCMZm (ORCPT ); Sat, 3 Dec 2022 07:25:42 -0500 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28B2D1D644 for ; Sat, 3 Dec 2022 04:25:41 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id g7so11410339lfv.5 for ; Sat, 03 Dec 2022 04:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=SwSyqwMrqrfu5+iUWNYzC2nuUqa64qi42sFtQj9PwvI=; b=VCyv+3d27kBLhKGX9jxgmtiPVmQF6JwKORk4eVgQheDTEH8w3JTBpwh5FwFoMRqhm0 x2djCBEv/3/dxW3LwYBvBaEMz03x1g7hCbf3xyyRAPOCU/XkRfRo2HynDlw3P/hs64UH xQvQd01q8HK27q5fAM7uSOIuMX3jgeWkO38TM+4FeTZmmOWg6Hwj+lmBL2U+kYXB9SQq kZZVjP0W1ZWoKaxwfV0Um1wQC+wI6F3tpCeNleiMMqmEpecZh5AgxTLy+JpqFzYQsHTb niMlUBZEgjgQBQ7crZ0wFwd6gxah8hiAuOcXjRualZbz6azICQls5tSQDpdU7AgZjv/w cPGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SwSyqwMrqrfu5+iUWNYzC2nuUqa64qi42sFtQj9PwvI=; b=WHTmGKza7swCt5a7PgEgDTxV9FY8C+uQJQwnk49RhaSFVqntAqM/alT7X8agbcHDq5 szZIf9N+zB0kPvLIy+Si8zr5gKN4Qa3AoZbkZOM10kRsB+/u4JXnmbbKvrzH6ZTiYQK8 4MzfNNjSX3XtGDdg0j56HbpJTajJwh3goxNBOJKsJBwK3n2FicjhOHApeJPY5N5M/KkM 4qAO3kbRVvcYri7rBqOQLfBjVPI61yRGFfgRXJzvYQ+blf1w//FNUoipz0g9H3fyQ4rw +u1rCSiGn1IXWTZ+jwMJZjf3em9fv1blYiiskgPvJI7gXiIjKsbVvNnu0gqULa/2TI2Q O6nA== X-Gm-Message-State: ANoB5pkCrQTTg4FNhk7ziXKmmpTca8MitOrqwiRMyY7aC6pFCetpzZSS p9MmdwlSOkCvS5dyTiY1crA7+A== X-Google-Smtp-Source: AA0mqf5DFmukO5xtLWbUtNv4B2+qvLLV4rqxjVHTkkEEzcDCtp/Waa2l/ufMTOfMZro9HbxdJX8BOw== X-Received: by 2002:a05:6512:a93:b0:4a2:6337:872d with SMTP id m19-20020a0565120a9300b004a26337872dmr19950566lfu.35.1670070339102; Sat, 03 Dec 2022 04:25:39 -0800 (PST) Received: from [192.168.0.20] (088156142067.dynamic-2-waw-k-3-2-0.vectranet.pl. [88.156.142.67]) by smtp.gmail.com with ESMTPSA id u11-20020a2e9b0b000000b0027712379ec8sm854541lji.28.2022.12.03.04.25.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Dec 2022 04:25:38 -0800 (PST) Message-ID: Date: Sat, 3 Dec 2022 13:25:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v2 2/3] dt-bindings: leds: add dt schema for worldsemi,ws2812b-spi Content-Language: en-US To: Chuanhong Guo Cc: linux-leds@vger.kernel.org, Pavel Machek , Rob Herring , Krzysztof Kozlowski , Stanislav Jakubek , Linus Walleij , Shawn Guo , Johan Hovold , Bjorn Andersson , Marijn Suijten , Sven Schwermer , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list References: <20221202034240.455831-1-gch981213@gmail.com> <20221202034240.455831-3-gch981213@gmail.com> <783fd2ff-cf7a-d820-6be7-9863e1786349@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 03/12/2022 13:11, Chuanhong Guo wrote: > Hi! > > On Sat, Dec 3, 2022 at 6:52 PM Krzysztof Kozlowski > wrote: >> >> On 02/12/2022 13:55, Chuanhong Guo wrote: >>>>> + >>>>> + default-brightness: >>>>> + description: >>>>> + The default brightness that should be applied to the LED by the operating >>>>> + system on start-up. The brightness should not exceed the brightness the >>>>> + LED can provide. >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + minimum: 0 >>>>> + maximum: 255 >>>>> + default: 0 >>>>> + >>>>> + default-intensity: >>>>> + description: | >>>>> + An array of 3 integer specifying the default intensity of each color >>>>> + components in this LED. <255 255 255> if unspecified. >>>>> + $ref: /schemas/types.yaml#/definitions/uint32-array >>>> >>>> I am still not convinced these two properties are correct. Why this LED >>>> is special and defines default brightness and intensity and other LEDs >>>> do not? You explained you are doing it for user-space which is usually >>>> not a valid reason for changes specific to one binding. Either all >>>> bindings should support it or none. >>> >>> There's already a default-state for simple LEDs without brightness >>> control so I think it makes sense to add default-brightness for LEDs >>> with brightness control and default-intensity for colored LEDs. >>> The default-state seems to be implemented in various LED drivers, >>> so I implemented these two properties in my LED driver. >>> There's nothing device-specific about these two properties. >> >> default-state has a bit different purpose - to prevent any >> glitches/changes when probing driver. > > OK. I didn't know that property is used in this way. > I can live without them. I'll drop it in the next version. > >> >>>> >>>>> + maxItems: 3 >>>>> + items: >>>>> + minimum: 0 >>>>> + maximum: 255 >>>>> + >>>>> + reg: >>>>> + description: | >>>>> + Which LED this node represents. The reg of the first LED on the chain >>>>> + is 0. >>>>> + maxItems: 1 >>>>> + >>>>> + required: >>>>> + - reg >>>>> + - color >>>>> + - function >>>>> + >>>>> +required: >>>>> + - compatible >>>>> + >>>>> +additionalProperties: false >>>>> + >>>>> +examples: >>>>> + - | >>>>> + #include >>>>> + spi { >>>>> + #address-cells = <1>; >>>>> + #size-cells = <0>; >>>>> + >>>>> + leds@0 { >>>> >>>> git grep leds@ -- Documentation/devicetree/ | wc -l >>>> 1 >>>> git grep led@ -- Documentation/devicetree/ | wc -l >>>> 165 >>>> >>>> so rather not the first one ("leds"). >>> >>> As you can see, this node describes a chain of LEDs, not >>> a single LED, so the plural form is more appropriate than >>> the singular form. >>> >>>> >>>> There is also: >>>> git grep led-controller@ -- Documentation/devicetree/ | wc -l >>>> 30 >>> >>> This also isn't appropriate. WS2812B is a single LED package >>> of 3 diodes and a microcontroller. If we treat every package >>> as a LED, the SPI MOSI is connected directly to the LED >>> packages themselves with no controller in between. >>> If we treat the microcontroller as a led-controller, every >>> LED contains its own controller, instead of one controller >>> controlling all LEDs, and the parent node still shouldn't >>> be called a led-controller. >>> >>> Here's a picture of the WS2812B LED package: >>> https://cdn-shop.adafruit.com/970x728/1655-00.jpg >>> and a chain of them: >>> https://cdn-shop.adafruit.com/970x728/1463-00.jpg >> >> Then your bindings and DTS do not represent the hardware. > > How should this hardware be represented, then? > > The connection can be: > > SPI-MOSI---LED1---LED2---LED3---...---LEDN > > or > > SPI-MOSI---Tri-state signal gate---LED1---LED2---LED3---...---LEDN > SPI-CS-----| I would look at it this as either of: 1. serially linked separate LED controllers (so multiple device nodes) 2. one LED controller handling the entire LED system of many sub-controllers. For the (2) I proposed the name led-controller. If you think this is not (2), then looks like (1) and you should have many devices... which probably is not doable on itself. And how to call this entire set of separate LED controllers? Heh, can be also some controller, like led-controller. Best regards, Krzysztof