[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f1ec3121-a8e7-a1c0-008a-ea4ae6028157@broadcom.com>
Date: Fri, 11 Jan 2019 13:28:45 -0800
From: Scott Branden <scott.branden@...adcom.com>
To: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
Sheetal Tigadoli <sheetal.tigadoli@...adcom.com>
Cc: Thierry Reding <thierry.reding@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Florian Fainelli <f.fainelli@...il.com>,
Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
bcm-kernel-feedback-list@...adcom.com, linux-pwm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Praveen Kumar B <praveen.b@...adcom.com>
Subject: Re: [PATCH 1/3] dt-bindings: pwm: kona: Add new compatible for new
version pwm-kona
Hi Uwe
On 2019-01-11 12:48 p.m., Uwe Kleine-König wrote:
> On Fri, Jan 11, 2019 at 10:51:14AM +0530, Sheetal Tigadoli wrote:
>> From: Praveen Kumar B <praveen.b@...adcom.com>
>>
>> Add new compatible string for new version of pwm-kona
>>
>> Signed-off-by: Praveen Kumar B <praveen.b@...adcom.com>
>> Reviewed-by: Ray Jui <ray.jui@...adcom.com>
>> Reviewed-by: Scott Branden <scott.branden@...adcom.com>
>> Signed-off-by: Sheetal Tigadoli <sheetal.tigadoli@...adcom.com>
>> ---
>> Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt
>> index 8eae9fe..d37f697 100644
>> --- a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt
>> +++ b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt
>> @@ -3,7 +3,7 @@ Broadcom Kona PWM controller device tree bindings
>> This controller has 6 channels.
>>
>> Required Properties :
>> -- compatible: should contain "brcm,kona-pwm"
>> +- compatible: should contain "brcm,kona-pwm" or "brcm,kona-pwm-v2"
> Is v2 used on a newer generation of kona SoCs? On i.MX these variants
> are usually named after the first SoC that came with the new variant. Is
> this sensible here, too?
It doesn't make as much sense here as different revs of the IP block are
picked up based on various decisions.
A new SoC could decide to use an old version.
>
> Best regards
> Uwe
>
Powered by blists - more mailing lists