Re: [PATCH v7 1/6] dt-bindings: ti-lmu: Remove LM3697
Jacek On 09/15/2018 03:00 PM, Jacek Anaszewski wrote: > Hi Pavel. > > On 09/14/2018 11:42 PM, Pavel Machek wrote: >> Hi! >> >>>> You may want to learn more about device tree and/or talk to the device >>>> tree maintainers. This is an old article. https://lwn.net/Articles/561462/ >>> >>> The article title is "Device trees as ABI". A device tree is defined >>> in the "*.dts" file that is then compiled to a dtb blob, which >>> constitutes the ABI. And this ABI should be kept backwards compatible. >>> >>> What is discussed here is a documentation of bindings, i.e. according >>> to ePAPR: "requirements for how specific types and classes of devices >>> are represented in the device tree". >>> >>> >From the bindings documented in the >>> Documentation/devicetree/bindings/mfd/ti-lmu.txt only >>> ti,lm3532-backlight is used in the mainline dts file >>> (arch/arm/boot/dts/omap4-droid4-xt894.dts). >>> >>> Having the above it seems that there is no risk of breaking any >>> users. >> >> DTBs and bindings are supposed to be portable between operating >> systems. You are right there are no _mainline_ _Linux_ users. > > No mainline users means no users we should care of. > Other people also don't care - see patch [0]. > >>>> NAK on this patch. I see that this binding has problems, but >>>> introducing different binding for subset of devices is _not_ a fix. >>>> >>>>>> What about the multi function devices? They should have same binding. >>>>> >>>>> The MFD devices defined are not in contention here only the SFD. >>>> >>>> I'd like to see common solutions for SFD and MFD, as the hardware is >>>> similar, and that includes the code. Having code that is easier to >>>> maintain is important, and having many drivers are harder to maintain >>>> than one driver. >>>> >>>> Milo's code looks better than yours in that regard. I disagree about >>>> Milo's code being "nightmare" to modify, and care about "easy to >>>> maintain" more than "binary size". >>> >>> Easy to maintain will be a dedicated LED class driver. >> >> You mean, 3 dedicated LED class drivers and 3 MFD drivers with LED >> parts? We'll need complex driver anyway, and I'd really like to have >> just one. > > In the LED subsystem we can wrap common functionalities > into a library object. MFD driver will be able to reuse it then. I am currently working on that code now. I expect a RFC on this this week. Dan > > [0] > https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/commit/?h=droid4-pending-v4.19=d774c7e447ac911e73a1b3c775e6d89f0422218c > -- -- Dan Murphy
Re: [PATCH v7 1/6] dt-bindings: ti-lmu: Remove LM3697
Pavel On 09/12/2018 04:49 PM, Pavel Machek wrote: > Hi! > >> On 09/11/2018 03:05 PM, Pavel Machek wrote: >>> On Tue 2018-09-11 12:08:20, Dan Murphy wrote: >>>> Remove support for the LM3697 LED device >>>> from the ti-lmu. The LM3697 will be supported >>>> via a stand alone LED driver. >>>> >>>> Signed-off-by: Dan Murphy >>> >>> I'd really like to see better explanation here. >>> >> >> I will update the commit message but >> >> How do I politely explain that the original implementation was wrong for >> certain devices? > > Implementation? Device tree is hardware description. Yes this hardware description is incorrect. The hardware description is describing a MFD but this LED driver (and a couple others) only perform 1 function and that is to drive a LED string. > >> How do I politely explain that this binding has information that >> does not exist? > > I don't understand this sentence. That was explained later on the issues with the binding. > >> Isn't code and documentation supposed to be pushed in stages >> together? > > Device tree is _not_ documentation. And yes, it is normally pushed > together. But that did not happen here, and bindings are already in. > Hmm.. Its not documentation but it is in the Documentation folder. And just because the bindings are in does not mean they cannot be changed. So someone hurried up and pushed the bindings that were not accurate and they were taken and now we are stuck with this implementation? That does not seem like progress. > Bindings are an ABI between bootloader and kernel. They should not be > changed lightly. > > Here I believe they should be fixed; not deleted. > I am fixing them. Removing devices that should not have been there to begin with. Also if they are not to be changed lightly then why is there so much churn in the staged patches. Looks like the compatible is changing with this patch and appears that it was not documented appropriately. According to the above statement this patch should be rejected because it is changing the ABI. https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/commit/?h=droid4-pending-v4.19=d774c7e447ac911e73a1b3c775e6d89f0422218c >> Unfortunately Milo left TI before he had a chance to finish upstreaming. > > Well -- I wanted to finish upstreaming. I still have those patches, > and they still look reasonably well. Better than > than? >> Some issues with the current binding: >> 1) The documentation referenced in the ti-lmu.txt does not exist but the >> binding was accepted. >> [1] ../leds/backlight/ti-lmu-backlight.txt >> [2] ../leds/leds-lm3633.txt >> [3] ../regulator/lm363x-regulator.txt >> >> 2) ramp-up-msec and ramp-down-msec are not explained or defined in this >> current binding. >> Looks to be defined in the staged code though. >> >> 3) The ramp-up-msec and ramp-down-msec are not the right node parameters >> the code shows ti,ramp-down-ms and ti,ramp-up-ms. Looking at the clean up >> of the binding >> in the staged commits the binding still does not match the code. >> >> https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/commit/?h=droid4-pending-v4.19=d774c7e447ac911e73a1b3c775e6d89f0422218c >> > > Bindings are authoritative. Of course, they can be fixed if really > neccessary, but normally code should be adapted to the bindings, not > the other way around. They should only be authoritative when they are correct. > > If slow ramping up/down is something that would be expected in other > chips, too, ti, prefix is not good idea. > Well if this is something expected for other chips shouldn't the LED framework be updated as opposed to creating a stub layer to do this? >> 4) The ramp rates ranges are incorrect for the LM3697 it should be from 0 -> >> 117400 ms >> >> 5) The children compatibles are not defined in this binding but appear to be >> removed in the staged code. >> >> 6) address-cells and size-cells are missing from the binding > > Yep, ok, so these should be fixed. Still the bindings should be fixed, > not removed and started over. > So once something is in the binding it can never be removed? >> I am attempting to clean this up for all the dedicated LED drivers. >> There is a lot of bloat with this driver to support a single LED driver that >> is a single function device. >> > > What about the multi function devices? They should have same binding. The MFD devices defined are not in contention here only the SFD. The only comment there is data section bloat that occurs in attempti
Re: [PATCH v6 1/2] dt-bindings: leds: Add bindings for lm3697 driver
Jacek On 09/11/2018 01:27 PM, Jacek Anaszewski wrote: > Dan, > > On 09/10/2018 09:51 PM, Dan Murphy wrote: >> Jacek >> >> On 09/10/2018 02:07 PM, Jacek Anaszewski wrote: >>> Dan, Pavel, >>> >>> On 09/10/2018 04:37 PM, Dan Murphy wrote: >>>> Jacek >>>> >>>> On 09/08/2018 02:53 PM, Jacek Anaszewski wrote: >>>>> Dan, >>>>> >>>>> On 09/07/2018 03:52 PM, Dan Murphy wrote: >>>>> [...] >>>>>>> >>>>>>>> And I think Jacek pointed out that the bindings references in this >>>>>>>> bindings >>>>>>>> don't even exist. >>>>>>>> >>>>>>>> I am thinking we need to deprecate this MFD driver and consolidate >>>>>>>> these drivers >>>>>>>> in the LED directory as we indicated before. I did not find any >>>>>>>> ti-lmu support >>>>>>>> code. >>>>>>>> >>>>>>>> ti-lmu common core code and then the LED children appending the >>>>>>>> feature differentiation. >>>>>>> >>>>>>>> Need some maintainer weigh in here. >>>>>>> >>>>>>> Hehe. I'm maintnainer. Fun. >>>>>> >>>>>> I know. I want to see if there was any other opinion. Especially for >>>>>> the LED driver. >>>>>> >>>>> [...] >>>>> >>>>> I have a question - is this lm3697 LED controller a cell of some MFD >>>>> device? Or is it a self-contained chip? >>>>> >>>> >>>> This is a self contained chip. And the LM3697 only function is a LED >>>> driver. >>>> It does not have any other special functions like the LM363X drivers for >>>> GPIO and Regulator support. >>> >>> This is an argument for merging it as a standalone LED class driver >>> then. It is even more justifiable, taking into account uncertainties >>> related to the proper way of adding the support for it to the existing >>> MFD driver, whereas the code reuse would be the only advantage of having >>> thus support in MFD subsystem. >>> >> >> Does the argument carry over to the other devices? > > If we want to be consequent - yes. > >> Like the LM3632 (part of the ti-lmu) has flash and torch and no other >> special functions >> so it would look like the lm3601x family with different register mappings. > > Yes, this is obvious candidate for LED class flash driver. > >> The LM3631 seems to also be just a LED driver with no extra functionality >> >> I could go buy an EVM and put together a driver for that device as well >> using the lm3601x as >> reference. > > I'm not going to encourage you to make this expense, but to put it > politically - I'd happily welcome those drivers in the LED subsystem ;-) > Understood. I am waiting on hardware to test. Dan -- -- Dan Murphy
Re: [PATCH v6 1/2] dt-bindings: leds: Add bindings for lm3697 driver
On 09/11/2018 03:55 PM, Pavel Machek wrote: > Hi! > >>>>>>>> And I think Jacek pointed out that the bindings references in this >>>>>>>> bindings >>>>>>>> don't even exist. >>>>>>>> >>>>>>>> I am thinking we need to deprecate this MFD driver and consolidate >>>>>>>> these drivers >>>>>>>> in the LED directory as we indicated before. I did not find any >>>>>>>> ti-lmu support >>>>>>>> code. >>>>>>>> >>>>>>>> ti-lmu common core code and then the LED children appending the >>>>>>>> feature differentiation. >>>>>>> >>>>>>>> Need some maintainer weigh in here. >>>>>>> >>>>>>> Hehe. I'm maintnainer. Fun. >>>>>> >>>>>> I know. I want to see if there was any other opinion. Especially for >>>>>> the LED driver. >>>>>> >>>>> [...] >>>>> >>>>> I have a question - is this lm3697 LED controller a cell of some MFD >>>>> device? Or is it a self-contained chip? >>>>> >>>> >>>> This is a self contained chip. And the LM3697 only function is a LED >>>> driver. >>>> It does not have any other special functions like the LM363X drivers for >>>> GPIO and Regulator support. >>> >>> This is an argument for merging it as a standalone LED class driver >>> then. It is even more justifiable, taking into account uncertainties >>> related to the proper way of adding the support for it to the existing >>> MFD driver, whereas the code reuse would be the only advantage of having >>> thus support in MFD subsystem. >> >> Does the argument carry over to the other devices? > > We really need something reasonable, that works for stand-alone LEDs, > and also works for LEDs that are part of MFD when the hardware is similar. I agree that LED drivers that have other functional blocks beyond driving a LED chain belongs in the MFD space. The amount of code that is similar is very small. And like I pointed out Droid 4 may be only one use case where it makes sense to combine all the LED code into a central place. But most customers will just want a LED specific driver to maintain. > >> Like the LM3632 (part of the ti-lmu) has flash and torch and no other >> special functions >> so it would look like the lm3601x family with different register mappings. >> >> The LM3631 seems to also be just a LED driver with no extra functionality >> >> I could go buy an EVM and put together a driver for that device as well >> using the lm3601x as >> reference. > > I do have hardware with lm3532. I can test patches, and I guess I can > port driver easily if it is obvious how to do that. I can get the LM3532 EVM. I wrote a similar driver for the original Droid 10 years ago. Upstreaming was not a priority for that company. Here is a reference to the LM3530 code from back in the day on Google OMAP kernel. https://android.googlesource.com/kernel/omap/+/android-omap-3.0/drivers/leds/leds-lm3530.c Otherwise I can create the LM3532 driver as well and look at the LM3530 Dan > > Pavel > -- -- Dan Murphy
Re: [PATCH v2] ARM: DTS: OMAP4: Add OMAP4 Blaze Tablet support
On 06/25/2013 06:32 AM, Ruslan Bilovol wrote: The OMAP4 Blaze Tablet is TI OMAP4 processor-based development platform in a tablet formfactor. The platform contains many of the features found in present-day handsets (such as audio, video, wireless functions and user interfaces) and in addition contains features for software development and test. Why do we want to send this upstream? What is the advantage to having this supported? I don't believe we need to add another community board. We have a SDP and Panda. Dan -- -- Dan Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] ARM:dts:omap4-panda:Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 40 +
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..2b516af 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,7 +16,7 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = "gpio-leds";
heartbeat {
label = "pandaboard::status1";
@@ -137,6 +137,20 @@
};
};
+_pmx_wkup {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..8d1ba03 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,43 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>;
};
+
+ {
+ compatible = "gpio-leds";
+ heartbeat {
+ label = "pandaboard::status1";
+ gpios = < 14 0>;
+ linux,default-trigger = "heartbeat";
+ };
+ mmc {
+ label = "pandaboard::status2";
+ gpios = < 8 0>;
+ linux,default-trigger = "gpio";
+ };
+};
+
+_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _gpio_pins
+ >;
+
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins = <
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
+_pmx_wkup {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM:dts:omap4-panda:Update the LED support for the panda DTS
NM
On 05/15/2013 12:29 AM, Nishanth Menon wrote:
> $subject - add a space?
> s/ARM:dts:omap4-panda:Update/ARM: dts: omap4-panda: Update/ ?
Will fix.
> On 09:17-20130514, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
>>
>> A1-A3 = gpio_wk7
> Thanks for fixing this - this is a key fix else, GPIO_7 which controls
> VSEL for VDD_MPU on PandaBoard-ES will create all kind of ruckus (change
> voltage on heartbeat)!
>> ES = gpio_110
>>
>> There is no change to LED D2
>>
>> Abstract away the pinmux and the LED definitions for the two boards into
>> the respective DTS files.
>>
>> Signed-off-by: Dan Murphy
>> ---
> [...]
>> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
>> b/arch/arm/boot/dts/omap4-panda-es.dts
>> index f1d8c21..8d1ba03 100644
>> --- a/arch/arm/boot/dts/omap4-panda-es.dts
>> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
>> @@ -34,3 +34,43 @@
>> 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>> >;
>> };
>> +
>> + {
>> +compatible = "gpio-leds";
>> +heartbeat {
>> +label = "pandaboard::status1";
>> +gpios = < 14 0>;
>> +linux,default-trigger = "heartbeat";
>> +};
>> +mmc {
>> +label = "pandaboard::status2";
>> + gpios = < 8 0>;
>> +linux,default-trigger = "gpio";
> mmc0?
Good point why would I call it mmc and then set the trigger to gpio.
Will fix it.
>> +};
>> +};
>> +
> Other that that,
> Tested-by: Nishanth Menon
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 40 +
2 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..2b516af 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,7 +16,7 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = "gpio-leds";
heartbeat {
label = "pandaboard::status1";
@@ -137,6 +137,20 @@
};
};
+_pmx_wkup {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..e6f696d 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,43 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>;
};
+
+ {
+ compatible = "gpio-leds";
+ heartbeat {
+ label = "pandaboard::status1";
+ gpios = < 14 0>;
+ linux,default-trigger = "heartbeat";
+ };
+ mmc {
+ label = "pandaboard::status2";
+ gpios = < 8 0>;
+ linux,default-trigger = "mmc0";
+ };
+};
+
+_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _gpio_pins
+ >;
+
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins = <
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
+_pmx_wkup {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 05/15/2013 12:05 PM, Nishanth Menon wrote:
> On 11:46-20130515, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
>>
>> A1-A3 = gpio_wk7
>> ES = gpio_110
>>
>> There is no change to LED D2
>>
>> Abstract away the pinmux and the LED definitions for the two boards into
>> the respective DTS files.
>>
>> Signed-off-by: Dan Murphy
>> ---
> nit: Giving patch history is a nice practise.
>> arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
>> arch/arm/boot/dts/omap4-panda-es.dts | 40
>> +
>> 2 files changed, 55 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> index 03bd60d..2b516af 100644
>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> @@ -16,7 +16,7 @@
>> reg = <0x8000 0x4000>; /* 1 GB */
>> };
>>
>> -leds {
>> +leds: leds {
>> compatible = "gpio-leds";
>> heartbeat {
>> label = "pandaboard::status1";
>> @@ -137,6 +137,20 @@
> I missed noticing this previously, Apologies on the same.
> Considering that drivers/leds/leds-gpio.c has ability to handle pinctrl,
> One better option might be to provide pinctrl phandle with leds -
> Couple of reasons why this might be good:
> a) one gets the following warning at boot:
> "leds-gpio leds.8: pins are not configured from the driver"
> b) you donot need to setup the pins by default at boot - it is not
> mandatory for the system functionality, instead we do it *if* the driver
> is enabled.
> Further, optionally, all you'd have to do in panda-es.dts is the following
> _wkgpio_pins {
> pinctrl-single,pins = <
> 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
> >;
> }
> Similarly for gpios override for panda-es.
I am not sure you really want to do this.
If I make the pinctrl part of the led structure then the only way the gpio_wk7
on a1-a3 to be configured is when
the CONFIG_LEDS_GPIO flag is set.
Do you really want that dependency? You did say it was a key fix
At least this way the pins are configured regardless of that flag.
>> };
>> };
>>
>> +_pmx_wkup {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <
>> +_wkgpio_pins
>> +>;
>> +
>> +led_wkgpio_pins: pinmux_leds_wkpins {
>> +pinctrl-single,pins = <
>> +0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
>> +0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
>> +>;
>> +};
>> +};
>> +
>> {
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
>> b/arch/arm/boot/dts/omap4-panda-es.dts
>> index f1d8c21..e6f696d 100644
>> --- a/arch/arm/boot/dts/omap4-panda-es.dts
>> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
>> @@ -34,3 +34,43 @@
>> 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>> >;
>> };
>> +
>> + {
>> +compatible = "gpio-leds";
>> +heartbeat {
>> +label = "pandaboard::status1";
>> +gpios = < 14 0>;
>> +linux,default-trigger = "heartbeat";
>> +};
>> +mmc {
>> +label = "pandaboard::status2";
>> +gpios = < 8 0>;
>> +linux,default-trigger = "mmc0";
>> +};
>> +};
>> +
>> +_pmx_core {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <
>> +_gpio_pins
>> +>;
>> +
>> +led_gpio_pins: gpio_led_pmx {
>> +pinctrl-single,pins = <
>> +0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
>> +>;
>> +};
>> +};
>> +
>> +_pmx_wkup {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <
>> +_wkgpio_pins
>> +>;
>> +
>> +led_wkgpio_pins: pinmux_leds_wkpins {
>> +pinctrl-single,pins = <
>> +0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
>> +>;
>> +};
>> +};
>> --
>> 1.7.5.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 05/16/2013 01:18 PM, Nishanth Menon wrote: > On Thu, May 16, 2013 at 10:35 AM, Dan Murphy wrote: >> I am not sure you really want to do this. >> If I make the pinctrl part of the led structure then the only way the >> gpio_wk7 on a1-a3 to be configured is when >> the CONFIG_LEDS_GPIO flag is set. >> >> Do you really want that dependency? You did say it was a key fix >> At least this way the pins are configured regardless of that flag. > That is better as the system will be left in the pinmux configuration > handed over from bootloader. So you want to depend on a boot loader to configure pins correctly for the kernel? Hmmm seems risky to me. > The point being, muxing up pins even when not needed(config switched > off) has no real benefit - in this case albeit, the default mux was > causing a bug. > pinctrl IMHO should be considered as any other resource, if it is not > mandatory for boot, and needed only for a device functionality when > probed, it should done there only. > > just my 2 cents. > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- -- Dan Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] ARM:dts:omap4-panda: Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
v5 - Provide pincrtl phandle to the gpio-led driver
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 -
arch/arm/boot/dts/omap4-panda-es.dts | 34 +
2 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..5fd59b3 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
heartbeat {
label = "pandaboard::status1";
gpios = < 7 0>;
@@ -137,6 +142,15 @@
};
};
+_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..08d2e38 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,37 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>;
};
+
+_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins = <
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
+_wkgpio_pins {
+ pinctrl-single,pins = <
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+};
+
+ {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _gpio_pins
+ _wkgpio_pins
+ >;
+
+ heartbeat {
+ label = "pandaboard::status1";
+ gpios = < 14 0>;
+ linux,default-trigger = "heartbeat";
+ };
+ mmc {
+ label = "pandaboard::status2";
+ gpios = < 8 0>;
+ linux,default-trigger = "mmc0";
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6] ARM:dts:omap4-panda: Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
Changes in this version:
- review comments incorporated.
Previous version of this patch was discussed in:
https://patchwork.kernel.org/patch/2582771/
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..5fd59b3 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
heartbeat {
label = "pandaboard::status1";
gpios = < 7 0>;
@@ -137,6 +142,15 @@
};
};
+_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..c968a3b 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>;
};
+
+_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins = <
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
+_wkgpio_pins {
+ pinctrl-single,pins = <
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+};
+
+ {
+ pinctrl-0 = <
+ _gpio_pins
+ _wkgpio_pins
+ >;
+
+ heartbeat {
+ gpios = < 14 0>;
+ };
+ mmc {
+ gpios = < 8 0>;
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 05/17/2013 11:15 AM, Nishanth Menon wrote:
> On 11:02-20130517, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
>>
>> A1-A3 = gpio_wk7
>> ES = gpio_110
>>
>> There is no change to LED D2
>>
>> Abstract away the pinmux and the LED definitions for the two boards into
>> the respective DTS files.
>>
>> Signed-off-by: Dan Murphy
>> ---
>> Changes in this version:
>> - review comments incorporated.
>> Previous version of this patch was discussed in:
>> https://patchwork.kernel.org/patch/2582771/
> one minor nit,
> $subject could do with space after the ':'
> otherwise, it looks fine to me. Will suggest waiting for further
> reviewers if they have an opinion prior to a new rev.
Thanks NM I will queue up this change locally and await further review prior to
sending v7.
>> arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
>> arch/arm/boot/dts/omap4-panda-es.dts | 28
>>
>> 2 files changed, 43 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> index 03bd60d..5fd59b3 100644
>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> @@ -16,8 +16,13 @@
>> reg = <0x8000 0x4000>; /* 1 GB */
>> };
>>
>> -leds {
>> +leds: leds {
>> compatible = "gpio-leds";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <
>> +_wkgpio_pins
>> +>;
>> +
>> heartbeat {
>> label = "pandaboard::status1";
>> gpios = < 7 0>;
>> @@ -137,6 +142,15 @@
>> };
>> };
>>
>> +_pmx_wkup {
>> +led_wkgpio_pins: pinmux_leds_wkpins {
>> +pinctrl-single,pins = <
>> +0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
>> +0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
>> +>;
>> +};
>> +};
>> +
>> {
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
>> b/arch/arm/boot/dts/omap4-panda-es.dts
>> index f1d8c21..c968a3b 100644
>> --- a/arch/arm/boot/dts/omap4-panda-es.dts
>> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
>> @@ -34,3 +34,31 @@
>> 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>> >;
>> };
>> +
>> +_pmx_core {
>> +led_gpio_pins: gpio_led_pmx {
>> +pinctrl-single,pins = <
>> +0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
>> +>;
>> +};
>> +};
>> +
>> +_wkgpio_pins {
>> +pinctrl-single,pins = <
>> +0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
>> +>;
>> +};
>> +
>> + {
>> +pinctrl-0 = <
>> +_gpio_pins
>> +_wkgpio_pins
>> +>;
>> +
>> +heartbeat {
>> +gpios = < 14 0>;
>> +};
>> +mmc {
>> +gpios = < 8 0>;
>> +};
>> +};
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix omap4 panda LED definitions
The LED GPIOs between the 4430 (a1-a4) and 4460 (es) panda boards are different. This patch abstracts the LED definitions into the respective board files. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: omap4-panda: Add LED support into the panda DTS files
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
Abstract away the pinmux and the LED definitions for the two boards.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/omap4-panda-es.dts | 33 +
arch/arm/boot/dts/omap4-panda.dts| 22 +-
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..42fdd86 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -31,3 +31,36 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>;
};
+
+ {
+ compatible = "gpio-leds";
+ heartbeat {
+ label = "pandaboard::status1";
+ gpios = < 14 0>;
+ linux,default-trigger = "heartbeat";
+ };
+ mmc {
+ label = "pandaboard::status2";
+ gpios = < 8 0>;
+ linux,default-trigger = "gpio";
+ };
+};
+
+_gpio_pins {
+ pinctrl-single,pins = <
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ >;
+};
+
+_pmx_wkup {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..465c4b0b8 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -19,7 +19,7 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds{
compatible = "gpio-leds";
heartbeat {
label = "pandaboard::status1";
@@ -67,6 +67,7 @@
_pins
_hdmi_pins
_pins
+ _gpio_pins
>;
twl6040_pins: pinmux_twl6040_pins {
@@ -110,6 +111,25 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
>;
};
+
+ led_gpio_pins: pinmux_leds_pins {
+ pinctrl-single,pins = <
+ >;
+ };
+};
+
+_pmx_wkup {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
};
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: omap4-panda: Add LED support into the panda DTS files
On 04/17/2013 02:18 PM, Jon Hunter wrote: On 04/17/2013 02:09 PM, Dan Murphy wrote: The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es are different. Abstract away the pinmux and the LED definitions for the two boards. Just a heads-up but you should base this upon Benoit's for_3.10 branch [1] as there is now a omap4-panda-common.dtsi where the led stuff currently resides. Cheers Jon [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts Thanks Jon. Will resend against Benoit's tree. Dan -- -- Dan Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] ARM:dts:omap4-panda:Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 22 ++-
arch/arm/boot/dts/omap4-panda-es.dts | 33 +
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..0c48f6b 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,7 +16,7 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = "gpio-leds";
heartbeat {
label = "pandaboard::status1";
@@ -64,6 +64,7 @@
_pins
_hdmi_pins
_pins
+ _gpio_pins
>;
twl6040_pins: pinmux_twl6040_pins {
@@ -135,6 +136,25 @@
0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
>;
};
+
+ led_gpio_pins: pinmux_leds_pins {
+ pinctrl-single,pins = <
+ >;
+ };
+};
+
+_pmx_wkup {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
};
{
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..565d37e 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,36 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>;
};
+
+ {
+ compatible = "gpio-leds";
+ heartbeat {
+ label = "pandaboard::status1";
+ gpios = < 14 0>;
+ linux,default-trigger = "heartbeat";
+ };
+ mmc {
+ label = "pandaboard::status2";
+ gpios = < 8 0>;
+ linux,default-trigger = "gpio";
+ };
+};
+
+_gpio_pins {
+ pinctrl-single,pins = <
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ >;
+};
+
+_pmx_wkup {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the panda DTS
On 04/18/2013 04:30 AM, Vincent Stehlé wrote:
On 04/17/2013 10:16 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
(..)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..0c48f6b 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
(..)
@@ -135,6 +136,25 @@
0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
>;
};
+
+ led_gpio_pins: pinmux_leds_pins {
+ pinctrl-single,pins = <
+ >;
+ };
+};
Hi,
FYI, there was a recent discussion precisely on this topic, where Tomy
suggested to remove the empty section:
http://marc.info/?l=linux-omap=136546635409232=2
Apart from that, I just tested your patch on top of Tomy's
omap-for-v3.10/dt branch and it is working fine for me on PandaBoards
EA3, A4 and ES.
Tested-by: Vincent Stehlé
Best regards,
V.
Thanks for testing Vincent
Is there a way to append the data to an already existing node?
I do not see a clean way.
Dan
--
------
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the panda DTS
Tony
On 05/08/2013 06:47 PM, Tony Lindgren wrote:
> * Dan Murphy [130418 11:35]:
>> On 04/18/2013 04:30 AM, Vincent Stehlé wrote:
>>> On 04/17/2013 10:16 PM, Dan Murphy wrote:
>>>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>>>> are different.
>>> (..)
>>>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
>>>> b/arch/arm/boot/dts/omap4-panda-common.dtsi
>>>> index 03bd60d..0c48f6b 100644
>>>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>>>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> (..)
>>>> @@ -135,6 +136,25 @@
>>>>0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
>>>> */
>>>>>;
>>>>};
>>>> +
>>>> + led_gpio_pins: pinmux_leds_pins {
>>>> + pinctrl-single,pins = <
>>>> + >;
>>>> + };
>>>> +};
>>> Hi,
>>>
>>> FYI, there was a recent discussion precisely on this topic, where Tomy
>>> suggested to remove the empty section:
>>> http://marc.info/?l=linux-omap=136546635409232=2
>>>
>>> Apart from that, I just tested your patch on top of Tomy's
>>> omap-for-v3.10/dt branch and it is working fine for me on PandaBoards
>>> EA3, A4 and ES.
>>>
>>> Tested-by: Vincent Stehlé
>>>
>>> Best regards,
>>>
>>> V.
>>>
>> Thanks for testing Vincent
>>
>> Is there a way to append the data to an already existing node?
>> I do not see a clean way.
> If you have something in omap4-panda-common.dtsi and the same entry
> in the omap4-panda-es.dts, the entries in omap4-panda-es.dts will
> override and append the entries in omap4-panda-common.dtsi.
>
> So I think you can avoid the empty entry that way.
>
> Regards,
>
> Tony
Thanks but the issue is the led entry would not appear in the common file so
there is nothing to override.
Can we cleanly append to omap4_pmx_core without overriding the whole node?
I don't want to recreate the pmx_core node in the es file.
Dan
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
On 10/07/2013 06:42 AM, Ming Lei wrote: > On Mon, Oct 7, 2013 at 1:31 AM, Dan Murphy wrote: >> On 10/06/2013 10:05 AM, Ming Lei wrote: >>> On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy wrote: >>>> If the smsc95xx does not have a valid MAC address stored within >>>> the eeprom then a random number is generated. The MAC can also >>>> be set by uBoot but the smsc95xx does not have a way to read this. >>>> >>>> Create the binding for the smsc95xx so that uBoot can set the MAC >>>> and the code can retrieve the MAC from the modified DTB file. >>> Suppose there are two smsc95xx usbnet devices connected to usb bus, and >>> one is built-in, another is hotplug device, can your patch handle the >>> situation >>> correctly? >> Look at this line in the patch below >> >> sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id); >> >> I am appending the dev ID of the device to the of_name here. As long as >> init_mac_address is called, the dev.id and the uBoot >> entry match then yes. > Currently, non-root-hub usb device is created and added into usb bus without > any platform(device tree) knowledge, so you can't expect the match here. That is correct. Platform/dev tree will have no concept of the PnP USB dongle therefore there should be no entry in either. I will need to test this issue with a PnP usb->ethernet dongle. Dan > Also not mention the two smsc95xx devices may attach to two different > usb host controllers(buses). > > Thanks, -- -- Dan Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
Ming On 10/07/2013 06:42 AM, Ming Lei wrote: > On Mon, Oct 7, 2013 at 1:31 AM, Dan Murphy wrote: >> On 10/06/2013 10:05 AM, Ming Lei wrote: >>> On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy wrote: >>>> If the smsc95xx does not have a valid MAC address stored within >>>> the eeprom then a random number is generated. The MAC can also >>>> be set by uBoot but the smsc95xx does not have a way to read this. >>>> >>>> Create the binding for the smsc95xx so that uBoot can set the MAC >>>> and the code can retrieve the MAC from the modified DTB file. >>> Suppose there are two smsc95xx usbnet devices connected to usb bus, and >>> one is built-in, another is hotplug device, can your patch handle the >>> situation >>> correctly? >> Look at this line in the patch below >> >> sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id); >> >> I am appending the dev ID of the device to the of_name here. As long as >> init_mac_address is called, the dev.id and the uBoot >> entry match then yes. > Currently, non-root-hub usb device is created and added into usb bus without > any platform(device tree) knowledge, so you can't expect the match here. > > Also not mention the two smsc95xx devices may attach to two different > usb host controllers(buses). > > Thanks, You are correct I don't expect a match for PnP devices only devices that are hard wired. After thinking of it I should move the OF code below the EEPROM code as the EEPROM should take preference over the DT code. I will need to post V2 for that. Dan -- -- Dan Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
On 10/10/2013 07:39 AM, Ming Lei wrote: > On Thu, Oct 10, 2013 at 8:08 PM, Dan Murphy wrote: >> You are correct I don't expect a match for PnP devices only devices that are >> hard wired. >> >> After thinking of it I should move the OF code below the EEPROM code as the >> EEPROM should take preference over the DT code. >> >> I will need to post V2 for that. > Your patch still doesn't deal with two smsc95xx devices built in > one board. Is there a board that has 2 built in smsc devices? This is all dependent on what the dev.id is of udev. > > The problem is a generic one, looks it is better to do it when OF supports > discoverable bus. > > > Thanks, -- -- Dan Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] ARM:dts:omap4-panda: Update the LED support for the panda DTS
On 05/17/2013 11:17 AM, Dan Murphy wrote:
> On 05/17/2013 11:15 AM, Nishanth Menon wrote:
>> On 11:02-20130517, Dan Murphy wrote:
>>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>>> are different.
>>>
>>> A1-A3 = gpio_wk7
>>> ES = gpio_110
>>>
>>> There is no change to LED D2
>>>
>>> Abstract away the pinmux and the LED definitions for the two boards into
>>> the respective DTS files.
>>>
>>> Signed-off-by: Dan Murphy
>>> ---
>>> Changes in this version:
>>> - review comments incorporated.
>>> Previous version of this patch was discussed in:
>>> https://patchwork.kernel.org/patch/2582771/
>> one minor nit,
>> $subject could do with space after the ':'
>> otherwise, it looks fine to me. Will suggest waiting for further
>> reviewers if they have an opinion prior to a new rev.
> Thanks NM I will queue up this change locally and await further review prior
> to sending v7.
>
>>> arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
>>> arch/arm/boot/dts/omap4-panda-es.dts | 28
>>>
>>> 2 files changed, 43 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> b/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> index 03bd60d..5fd59b3 100644
>>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
>>> @@ -16,8 +16,13 @@
>>> reg = <0x8000 0x4000>; /* 1 GB */
>>> };
>>>
>>> - leds {
>>> + leds: leds {
>>> compatible = "gpio-leds";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <
>>> + _wkgpio_pins
>>> + >;
>>> +
>>> heartbeat {
>>> label = "pandaboard::status1";
>>> gpios = < 7 0>;
>>> @@ -137,6 +142,15 @@
>>> };
>>> };
>>>
>>> +_pmx_wkup {
>>> + led_wkgpio_pins: pinmux_leds_wkpins {
>>> + pinctrl-single,pins = <
>>> + 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
>>> + 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
>>> + >;
>>> + };
>>> +};
>>> +
>>> {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_pins>;
>>> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
>>> b/arch/arm/boot/dts/omap4-panda-es.dts
>>> index f1d8c21..c968a3b 100644
>>> --- a/arch/arm/boot/dts/omap4-panda-es.dts
>>> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
>>> @@ -34,3 +34,31 @@
>>> 0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>>> >;
>>> };
>>> +
>>> +_pmx_core {
>>> + led_gpio_pins: gpio_led_pmx {
>>> + pinctrl-single,pins = <
>>> + 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
>>> + >;
>>> + };
>>> +};
>>> +
>>> +_wkgpio_pins {
>>> + pinctrl-single,pins = <
>>> + 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
>>> + >;
>>> +};
>>> +
>>> + {
>>> + pinctrl-0 = <
>>> + _gpio_pins
>>> + _wkgpio_pins
>>> + >;
>>> +
>>> + heartbeat {
>>> + gpios = < 14 0>;
>>> + };
>>> + mmc {
>>> + gpios = < 8 0>;
>>> + };
>>> +};
>
Any additional comments besides the headline?
If not I will post v7
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7] ARM: dts: omap4-panda: Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
v7 - Update headline to add spaces - https://patchwork.kernel.org/patch/2583661/
v6 - Review comments updated - https://patchwork.kernel.org/patch/2582771/
v5 - Provide pincrtl phandle to the gpio-led driver -
https://patchwork.kernel.org/patch/2573981/
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..5fd59b3 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
heartbeat {
label = "pandaboard::status1";
gpios = < 7 0>;
@@ -137,6 +142,15 @@
};
};
+_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..c968a3b 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>;
};
+
+_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins = <
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
+_wkgpio_pins {
+ pinctrl-single,pins = <
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+};
+
+ {
+ pinctrl-0 = <
+ _gpio_pins
+ _wkgpio_pins
+ >;
+
+ heartbeat {
+ gpios = < 14 0>;
+ };
+ mmc {
+ gpios = < 8 0>;
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] i2c: omap: correct usage of the interrupt enable register
On 05/31/2013 03:26 AM, Oleksandr Dmytryshyn wrote:
> If the i2c controller during suspend will generate an interrupt, it
> can lead to unpredictable behaviour in the kernel.
>
> Based on the logic of the kernel code interrupts from i2c should be
> prohibited during suspend. Kernel writes 0 to the I2C_IE register in
> the omap_i2c_runtime_suspend() function. In the other side kernel
> writes saved interrupt flags to the I2C_IE register in
> omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
> during suspend.
>
> This works for chips with version1 registers scheme. Interrupts are
> disabled during suspend. For chips with version2 scheme registers
> writting 0 to the I2C_IE register does nothing (because now the
> I2C_IRQENABLE_SET register is located at this address). This register
> is used to enable interrupts. For disabling interrupts
> I2C_IRQENABLE_CLR register should be used.
>
> Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
> addresses, the interrupt enabling procedure is unchanged.
>
> Change-Id: Ie49165990a4e7c67a4ccf2e4a66cd3b78f2e2b70
Remove this.
> Signed-off-by: Oleksandr Dmytryshyn
> ---
> drivers/i2c/busses/i2c-omap.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index e02f9e3..64c26f9 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -180,6 +180,8 @@ enum {
> #define I2C_OMAP_ERRATA_I207 (1 << 0)
> #define I2C_OMAP_ERRATA_I462 (1 << 1)
>
> +#define OMAP_I2C_IP_V2_INTERRUPTS_MASK 0x6FFF
> +
> struct omap_i2c_dev {
> spinlock_t lock; /* IRQ synchronization */
> struct device *dev;
> @@ -193,6 +195,7 @@ struct omap_i2c_dev {
> long latency);
> u32 speed; /* Speed of bus in kHz */
> u32 flags;
> + u16 scheme;
> u16 cmd_err;
> u8 *buf;
> u8 *regs;
> @@ -1082,7 +1085,7 @@ omap_i2c_probe(struct platform_device *pdev)
> int irq;
> int r;
> u32 rev;
> - u16 minor, major, scheme;
> + u16 minor, major;
>
> /* NOTE: driver uses the static register mapping */
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -1159,8 +1162,8 @@ omap_i2c_probe(struct platform_device *pdev)
>*/
> rev = __raw_readw(dev->base + 0x04);
>
> - scheme = OMAP_I2C_SCHEME(rev);
> - switch (scheme) {
> + dev->scheme = OMAP_I2C_SCHEME(rev);
> + switch (dev->scheme) {
> case OMAP_I2C_SCHEME_0:
> dev->regs = (u8 *)reg_map_ip_v1;
> dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG);
> @@ -1289,7 +1292,11 @@ static int omap_i2c_runtime_suspend(struct device *dev)
>
> _dev->iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
>
> - omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
> + if (_dev->scheme == OMAP_I2C_SCHEME_0)
> + omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
> + else
> + omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR,
> +OMAP_I2C_IP_V2_INTERRUPTS_MASK);
>
> if (_dev->rev < OMAP_I2C_OMAP1_REV_2) {
> omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7] ARM: dts: omap4-panda: Update the LED support for the panda DTS
Hi On 05/31/2013 09:06 AM, Benoit Cousson wrote: > Hi Dan, > > On 05/29/2013 01:20 PM, Dan Murphy wrote: >> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es >> are different. >> >> A1-A3 = gpio_wk7clean >> ES = gpio_110 >> >> There is no change to LED D2 >> >> Abstract away the pinmux and the LED definitions for the two boards into >> the respective DTS files. >> >> Signed-off-by: Dan Murphy > That patch was good... until Florian introduces some new constant to > improve the readability of the DTS [1]. > > Could you rebase on the lastest for_3.11/dts and use the macros for the > GPIO and pinctrl nodes? N/P working on it now Thanks > Thanks, > Benoit > > [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89684.html > -- -- Dan Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8] ARM: dts: omap4-panda: Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
v8 - Rebase to latest and use pinctrl macros -
https://patchwork.kernel.org/patch/2629351/
v7 - Update headline to add spaces - https://patchwork.kernel.org/patch/2583661/
v6 - Review comments updated - https://patchwork.kernel.org/patch/2582771/
v5 - Provide pincrtl phandle to the gpio-led driver -
https://patchwork.kernel.org/patch/2573981/
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index d5d144a..523a800 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
heartbeat {
label = "pandaboard::status1";
gpios = < 7 GPIO_ACTIVE_HIGH>;
@@ -157,6 +162,15 @@
};
};
+_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 OUTPUT |
MODE 3 */
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 OUTPUT |
MODE 3 */
+ >;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 5cfdf19..5551ec6 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e (PIN_INPUT | MUX_MODE0)/* hdmi_sda.hdmi_sda */
>;
};
+
+_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins = <
+ 0xb6 (PIN_OUTPUT | MUX_MODE3) /* gpio_110 OUTPUT |
MODE 3 */
+ >;
+ };
+};
+
+_wkgpio_pins {
+ pinctrl-single,pins = <
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+};
+
+ {
+ pinctrl-0 = <
+ _gpio_pins
+ _wkgpio_pins
+ >;
+
+ heartbeat {
+ gpios = < 14 0>;
+ };
+ mmc {
+ gpios = < 8 0>;
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8] ARM: dts: omap4-panda: Update the LED support for the panda DTS
On 05/31/2013 10:05 AM, Javier Martinez Canillas wrote:
> On Fri, May 31, 2013 at 4:48 PM, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
>>
>> A1-A3 = gpio_wk7
>> ES = gpio_110
>>
>> There is no change to LED D2
>>
>> Abstract away the pinmux and the LED definitions for the two boards into
>> the respective DTS files.
>>
>> Signed-off-by: Dan Murphy
>> ---
>> v8 - Rebase to latest and use pinctrl macros -
>> https://patchwork.kernel.org/patch/2629351/
>> v7 - Update headline to add spaces -
>> https://patchwork.kernel.org/patch/2583661/
>> v6 - Review comments updated - https://patchwork.kernel.org/patch/2582771/
>> v5 - Provide pincrtl phandle to the gpio-led driver -
>> https://patchwork.kernel.org/patch/2573981/
>>
>> arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
>> arch/arm/boot/dts/omap4-panda-es.dts | 28
>>
>> 2 files changed, 43 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> index d5d144a..523a800 100644
>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> @@ -16,8 +16,13 @@
>> reg = <0x8000 0x4000>; /* 1 GB */
>> };
>>
>> - leds {
>> + leds: leds {
>> compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <
>> + _wkgpio_pins
>> + >;
>> +
>> heartbeat {
>> label = "pandaboard::status1";
>> gpios = < 7 GPIO_ACTIVE_HIGH>;
>> @@ -157,6 +162,15 @@
>> };
>> };
>>
>> +_pmx_wkup {
>> + led_wkgpio_pins: pinmux_leds_wkpins {
>> + pinctrl-single,pins = <
>> + 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 OUTPUT |
>> MODE 3 */
>> + 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 OUTPUT |
>> MODE 3 */
> Hello Dan,
>
> The OUTPUT | MODE 3 in the comments were added so people shouldn't
> have to look at the TRM to find what each constant number meant. But
> now using the macros this is not needed anymore, so I don't think is
> necessary to keep that on the comments.
>
> Best regards,
> Javier
Yes you are correct sending update to remove the comments
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9] ARM: dts: omap4-panda: Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
v9 - Removed comments for mux config -
https://patchwork.kernel.org/patch/2644391/
v8 - Rebase to latest and use pinctrl macros -
https://patchwork.kernel.org/patch/2629351/
v7 - Update headline to add spaces - https://patchwork.kernel.org/patch/2583661/
v6 - Review comments updated - https://patchwork.kernel.org/patch/2582771/
v5 - Provide pincrtl phandle to the gpio-led driver -
https://patchwork.kernel.org/patch/2573981/
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index d5d144a..800fa4e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
heartbeat {
label = "pandaboard::status1";
gpios = < 7 GPIO_ACTIVE_HIGH>;
@@ -157,6 +162,15 @@
};
};
+_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 */
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
+ >;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 5cfdf19..0a7812f 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e (PIN_INPUT | MUX_MODE0)/* hdmi_sda.hdmi_sda */
>;
};
+
+_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins = <
+ 0xb6 (PIN_OUTPUT | MUX_MODE3) /* gpio_110 */
+ >;
+ };
+};
+
+_wkgpio_pins {
+ pinctrl-single,pins = <
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
+ >;
+};
+
+ {
+ pinctrl-0 = <
+ _gpio_pins
+ _wkgpio_pins
+ >;
+
+ heartbeat {
+ gpios = < 14 0>;
+ };
+ mmc {
+ gpios = < 8 0>;
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 1/2] ARM: dts: omap4-panda: Update the LED support for the panda DTS
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
v10 - Update gpio entries to use gpio macros -
https://patchwork.kernel.org/patch/2644561/
v9 - Removed comments for mux config -
https://patchwork.kernel.org/patch/2644391/
v8 - Rebase to latest and use pinctrl macros -
https://patchwork.kernel.org/patch/2629351/
v7 - Update headline to add spaces - https://patchwork.kernel.org/patch/2583661/
v6 - Review comments updated - https://patchwork.kernel.org/patch/2582771/
v5 - Provide pincrtl phandle to the gpio-led driver -
https://patchwork.kernel.org/patch/2573981/
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index d5d144a..800fa4e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
heartbeat {
label = "pandaboard::status1";
gpios = < 7 GPIO_ACTIVE_HIGH>;
@@ -157,6 +162,15 @@
};
};
+_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 */
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
+ >;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 5cfdf19..56c4354 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e (PIN_INPUT | MUX_MODE0)/* hdmi_sda.hdmi_sda */
>;
};
+
+_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins = <
+ 0xb6 (PIN_OUTPUT | MUX_MODE3) /* gpio_110 */
+ >;
+ };
+};
+
+_wkgpio_pins {
+ pinctrl-single,pins = <
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
+ >;
+};
+
+ {
+ pinctrl-0 = <
+ _gpio_pins
+ _wkgpio_pins
+ >;
+
+ heartbeat {
+ gpios = < 14 GPIO_ACTIVE_HIGH>;
+ };
+ mmc {
+ gpios = < 8 GPIO_ACTIVE_HIGH>;
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1] ARM: dts: omap4-panda: Update the twl6040 gpio to macro definition
Update the dt property ti,audpwron-gpio to use the gpio macro definition for GPIO_ACTIVE_HIGH. Signed-off-by: Dan Murphy --- arch/arm/boot/dts/omap4-panda-common.dtsi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 800fa4e..00cbaa5 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -190,7 +190,7 @@ /* IRQ# = 119 */ interrupts = ; /* IRQ_SYS_2N cascaded to gic */ interrupt-parent = <>; - ti,audpwron-gpio = < 31 0>; /* gpio line 127 */ + ti,audpwron-gpio = < 31 GPIO_ACTIVE_HIGH>; /* gpio line 127 */ vio-supply = <>; v2v1-supply = <>; -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TEMP PATCH 16/17] pci: host: pcie-dra7xx: use reset framework APIs to reset PCIe
On 05/06/2014 08:34 AM, Kishon Vijay Abraham I wrote:
> Get reset nodes from dt and use reset framework APIs to reset PCIe.
> This is needed since reset is handled by the SoC.
>
> Cc: Dan Murphy
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Documentation/devicetree/bindings/pci/ti-pci.txt |2 ++
> drivers/pci/host/pci-dra7xx.c| 10 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt
> b/Documentation/devicetree/bindings/pci/ti-pci.txt
> index 6cb6f09..cfb95c0 100644
> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> @@ -9,6 +9,8 @@ This node should have the properties described in
> "designware-pcie.txt".
> - phys : the phandle for the PHY device (used by generic PHY framework)
> - phy-names : the names of the PHY corresponding to the PHYs present in the
> *phy* phandle.
> + - resets: phandle used if reset is handled be soc
> + - reset-names: name given to the phandle
You should just refer to the ti,reset.txt document for this.
>
> Example:
> pcie@5100 {
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index a37c25c..17d64ee 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "pcie-designware.h"
> @@ -281,6 +282,7 @@ static int __init dra7xx_pcie_probe(struct
> platform_device *pdev)
> struct resource *res;
> struct dra7xx_pcie *dra7xx;
> struct device *dev = >dev;
> + struct reset_control *rstc;
>
> dra7xx = devm_kzalloc(>dev, sizeof(*dra7xx), GFP_KERNEL);
> if (!dra7xx)
> @@ -304,6 +306,14 @@ static int __init dra7xx_pcie_probe(struct
> platform_device *pdev)
> if (!base)
> return -ENOMEM;
>
> + rstc = devm_reset_control_get(dev, "reset");
> + if (IS_ERR(rstc))
> + return PTR_ERR(rstc);
> +
> + ret = reset_control_deassert(rstc);
> + if (ret)
> + return ret;
> +
> phy = devm_phy_get(dev, "pcie-phy");
> if (IS_ERR(phy))
> return PTR_ERR(phy);
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [TEMP PATCH 17/17] ARM: dts: dra7: Add *resets* property for PCIe dt node
On 05/06/2014 08:34 AM, Kishon Vijay Abraham I wrote:
> Added *resets* and *reset-names* properies for PCIe dt node.
> The documention for this node can be found @ ../bindings/pci/ti-pci.txt.
>
> Cc: Dan Murphy
> Signed-off-by: Kishon Vijay Abraham I
> ---
> arch/arm/boot/dts/dra7.dtsi |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 20b1a09..7bc0555 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1031,6 +1031,8 @@
> ti,hwmods = "pcie1";
> phys = <_phy>;
> phy-names = "pcie-phy";
> + resets = <_resets _reset>;
If you look @ v2 of the reset framework patchset your phandle should be
resets = <_resets _reset>;
If you call the device_reset phandle you will reset the SoC.
> + reset-names = "reset";
This needs to be more descriptive.
> };
>
> sata: sata@4a141100 {
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6] ASoC: tas2552: Support TI TAS2552 Amplifier
Support the TI TAS2552 Class D amplifier.
The TAS2552 is a high efficiency Class-D audio
power amplifier with advanced battery current
management and an integrated Class-G boost
The device constantly measures the
current and voltage across the load and provides a
digital stream of this information.
Signed-off-by: Dan Murphy
---
v6 - Addressed comments from v5 also added PLL algorithim instead of
hard coding PLL registers - https://patchwork.kernel.org/patch/4476001/
v5 - Consolidated dai_fmt call back to write serial control register
once - https://patchwork.kernel.org/patch/4474531/
v4 - Added pm_runtime support, removed magical numbers, added regulator
support, changed from legacy gpio to new gpiod calls, fixed default register
values, flipped on battery tracking support and
added suspend/resume support - https://patchwork.kernel.org/patch/4465611/
v3 - Updated bindings doc per comments, rearranged probe pdata vs
np check - https://patchwork.kernel.org/patch/4453481/
v2 - Address RFC comments- Added regmap, and snd_soc calls
removed debug code, address checkpatch errors
-https://patchwork.kernel.org/patch/4378281/
.../devicetree/bindings/sound/tas2552.txt | 25 +
include/sound/tas2552-plat.h | 25 +
sound/soc/codecs/Kconfig |5 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tas2552.c | 538
sound/soc/codecs/tas2552.h | 129 +
6 files changed, 724 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas2552.txt
create mode 100644 include/sound/tas2552-plat.h
create mode 100644 sound/soc/codecs/tas2552.c
create mode 100644 sound/soc/codecs/tas2552.h
diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt
b/Documentation/devicetree/bindings/sound/tas2552.txt
new file mode 100644
index 000..00223dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas2552.txt
@@ -0,0 +1,25 @@
+Texas Instruments - tas2552 Codec module
+
+The tas2552 serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - One of:
+"ti,tas2552" - TAS2552
+
+- reg - I2C slave address
+
+Optional properties:
+
+- enable-gpio - gpio pin to enable/disable the device
+
+Example:
+
+tas2552: tas2552@41 {
+ compatible = "ti,tas2552";
+ reg = <0x41>;
+ enable-gpio = < 2 GPIO_ACTIVE_HIGH>;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/TAS2552
diff --git a/include/sound/tas2552-plat.h b/include/sound/tas2552-plat.h
new file mode 100644
index 000..65e7627
--- /dev/null
+++ b/include/sound/tas2552-plat.h
@@ -0,0 +1,25 @@
+/*
+ * TAS2552 driver platform header
+ *
+ * Copyright (C) 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef TAS2552_PLAT_H
+#define TAS2552_PLAT_H
+
+struct tas2552_platform_data {
+ int enable_gpio;
+};
+
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0b9571c..cc09261 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -99,6 +99,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC32X4 if I2C
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TPA6130A2 if I2C
+ select SND_SOC_TAS2552 if I2C
select SND_SOC_TLV320DAC33 if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_TWL6040 if TWL6040_CORE
@@ -754,4 +755,8 @@ config SND_SOC_TPA6130A2
tristate "Texas Instruments TPA6130A2 headphone amplifier"
depends on I2C
+config SND_SOC_TAS2552
+ tristate "Texas Instruments TAS2552 Mono Audio amplifier"
+ depends on I2C
+
endmenu
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 1bd6e1c..33bc7228 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -162,6 +162,7 @@ snd-soc-wm-hubs-objs := wm_hubs.o
# Amp
snd-soc-max9877-objs := max9877.o
snd-soc-tpa6130a2-objs := tpa6130a2.o
+snd-soc-tas2552-objs := tas2552.o
obj-$(CONFIG_SND_SOC_88PM860X) += snd-soc-88pm860x.o
obj-$(CONFIG_SND_SOC_AB8500_CODEC) += snd-soc-ab8500-codec.o
@@ -325,3 +326,4 @@ obj-$(CONFIG_SND_SOC_WM_HUBS) += snd-soc-wm-hubs.o
# Amp
obj-$(CONFIG_SND_SOC_MAX9877) += snd-soc-max9877.o
obj-$(CONFIG_SND_SOC_TPA6130A2)+= snd-soc-tpa6130a2.o
+obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
diff --git a/sound/soc/co
[RFC PATCH] ASoC: tas2552: Support TI TAS2552 Amplifier
Support the TI TAS2552 Class D amplifier.
The TAS2552 is a high efficiency Class-D audio
power amplifier with advanced battery current
management and an integrated Class-G boost
The device constantly measures the
current and voltage across the load and provides a
digital stream of this information.
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/sound/tas2552.txt | 22 +
include/sound/tas2552-plat.h | 30 +
sound/soc/codecs/Kconfig |5 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tas2552.c | 631
sound/soc/codecs/tas2552.h | 79 +++
6 files changed, 769 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas2552.txt
create mode 100644 include/sound/tas2552-plat.h
create mode 100644 sound/soc/codecs/tas2552.c
create mode 100644 sound/soc/codecs/tas2552.h
diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt
b/Documentation/devicetree/bindings/sound/tas2552.txt
new file mode 100644
index 000..58e931b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas2552.txt
@@ -0,0 +1,22 @@
+Texas Instruments - tas2552 Codec module
+
+The tas2552 serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - "string" - One of:
+"ti,tas2552" - TAS2552
+
+- reg - - I2C slave address
+
+Optional properties:
+
+- power-gpio - gpio pin to enable/disable the device
+
+Example:
+
+tas2552: tas2552@41 {
+ compatible = "ti,tas2552";
+ reg = <0x41>;
+ power-gpio = < 2 GPIO_ACTIVE_HIGH>;
+};
diff --git a/include/sound/tas2552-plat.h b/include/sound/tas2552-plat.h
new file mode 100644
index 000..46d2732
--- /dev/null
+++ b/include/sound/tas2552-plat.h
@@ -0,0 +1,30 @@
+/*
+ * TAS2552 driver platform header
+ *
+ * Copyright (C) 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#ifndef TAS2552_PLAT_H
+#define TAS2552_PLAT_H
+
+struct tas2552_platform_data {
+ int power_gpio;
+};
+
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index cbfa1e1..06ff67e 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -99,6 +99,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC32X4 if I2C
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TPA6130A2 if I2C
+ select SND_SOC_TAS2552 if I2C
select SND_SOC_TLV320DAC33 if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_TWL6040 if TWL6040_CORE
@@ -746,4 +747,8 @@ config SND_SOC_TPA6130A2
tristate "Texas Instruments TPA6130A2 headphone amplifier"
depends on I2C
+config SND_SOC_TAS2552
+ tristate "Texas Instruments TAS2552 Mono Audio amplifier"
+ depends on I2C
+
endmenu
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index be3377b..ab33cd7 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -160,6 +160,7 @@ snd-soc-wm-hubs-objs := wm_hubs.o
# Amp
snd-soc-max9877-objs := max9877.o
snd-soc-tpa6130a2-objs := tpa6130a2.o
+snd-soc-tas2552-objs := tas2552.o
obj-$(CONFIG_SND_SOC_88PM860X) += snd-soc-88pm860x.o
obj-$(CONFIG_SND_SOC_AB8500_CODEC) += snd-soc-ab8500-codec.o
@@ -321,3 +322,4 @@ obj-$(CONFIG_SND_SOC_WM_HUBS) += snd-soc-wm-hubs.o
# Amp
obj-$(CONFIG_SND_SOC_MAX9877) += snd-soc-max9877.o
obj-$(CONFIG_SND_SOC_TPA6130A2)+= snd-soc-tpa6130a2.o
+obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
new file mode 100644
index 000..111eb0e
--- /dev/null
+++ b/sound/soc/codecs/tas2552.c
@@ -0,0 +1,631 @@
+/*
+ * ALSA SoC Texas Instruments TAS2552 Mono Audio Amplifier
+ *
+ * Copyright (C) 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR
Re: [RFC PATCH] ASoC: tas2552: Support TI TAS2552 Amplifier
Mark
Thanks for the comments
On 06/18/2014 01:44 PM, Mark Brown wrote:
> On Wed, Jun 18, 2014 at 12:45:46PM -0500, Dan Murphy wrote:
>
>> +static int tas2552_i2c_read(struct tas2552_data *tas_data, int reg)
>> +{
>> +int val;
>> +
>> +if (WARN_ON(!tas_data->tas2552_client))
>> +return -EINVAL;
>> +
>> +/* If powered off, return the cached value */
>> +mutex_lock(_data->mutex);
>> +if (tas_data->power_state) {
>> +val = i2c_smbus_read_byte_data(tas_data->tas2552_client, reg);
> Don't open code your I/O, use regmap like any other CODEC driver. This
> will remove a very large proportion of the code in the driver which
> replicates features of the regmap framework.
My initial implementation was with regmap but it gave me heart ache.
Which could have been wonky HW.
I will attempt regmap again and see if it was just a HW issue.
>
>> +static int tas2552_startup(struct snd_pcm_substream *substream,
>> + struct snd_soc_dai *dai)
>> +{
>> +struct snd_soc_codec *codec = dai->codec;
>> +struct tas2552_data *tas2552 = snd_soc_codec_get_drvdata(codec);
>> +
>> +tas2552_sw_shutdown(tas2552, 1);
>> +tas2552_power(tas2552, 1);
>> +/* Turn on Class D amplifier */
>> +tas2552_i2c_write(tas2552, TAS2552_CFG_2, 0x80);
>> +tas2552_sw_shutdown(tas2552, 0);
> I'd expect this to be done using DAPM.
Will take a look at it for V2.
>
>> +static const struct regmap_config tas2552_regmap_config = {
>> +.reg_bits = 8,
>> +.val_bits = 8,
>> +
>> +.max_register = TAS2552_MAX_REG,
>> +.reg_defaults = NULL,
>> +.num_reg_defaults = 0,
> No need to set things to zero or NULL in static variables, that's the
> default.
This was an artifact from my regmap implementation. This will be
populated when I re-implement the regmap code.
>> +dev = >dev;
>> +data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
>> +if (data == NULL) {
>> +dev_err(dev, "Can not allocate memory\n");
> No need to print an error, OOM messages are already quite noisy.
Will remove.
Dan
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] ASoC: tas2552: Support TI TAS2552 Amplifier
Mark
Thanks for the review
On 07/07/2014 03:08 AM, Mark Brown wrote:
> On Thu, Jul 03, 2014 at 11:24:35AM -0500, Dan Murphy wrote:
>
>> +static int tas2552_power(struct tas2552_data *data, u8 power)
>> +{
>> +int ret = 0;
>> +
>> +mutex_lock(>mutex);
>> +
>> +if (power) {
>> +if (data->enable_gpio)
>> +gpiod_set_value(data->enable_gpio, 1);
>> +
>> +data->power_state = 1;
>> +} else {
>> +if (data->enable_gpio)
>> +gpiod_set_value(data->enable_gpio, 0);
>> +
>> +data->power_state = 0;
>> +}
>> +
>> +mutex_unlock(>mutex);
>> +return ret;
>> +}
> I don't understand this function. It appears to be the only place where
> either power_state or mutex is used so it's just adding some wrapping
> around setting the GPIO value which doesn't seem like it's doing much.
> Why are we tracking power_state?
This function and mutex are artifacts from the development and probably can be
consolidated
into the runtime PM calls.
>
>> +static void tas2552_sw_shutdown(struct tas2552_data *tas_data, int
>> sw_shutdown)
>> +{
>> +u8 cfg1_reg = 0x0;
>> +
>> +if (sw_shutdown)
>> +cfg1_reg |= TAS2552_SWS_MASK;
>> +else
>> +cfg1_reg &= ~TAS2552_SWS_MASK;
>> +
>> +snd_soc_update_bits(tas_data->codec, TAS2552_CFG_1,
>> + TAS2552_SWS_MASK, cfg1_reg);
> Given that you're using _update_bits() clearing the bits in a register
> that was just initialised to zero doesn't make a huge amount of sense.
This was an artifact from RFC in which I was not using the snd_soc functions.
I can remove the initialization of the variable.
>
>> +default:
>> +dev_vdbg(codec->dev, "Substream sample rate is not found\n");
>> +return -EINVAL;
>> +}
> Better to print the rate.
OK
>
>> +pm_runtime_get_sync(codec->dev);
>> +
>> +snd_soc_update_bits(codec, TAS2552_CFG_3, TAS2552_WCLK_MASK, wclk_reg);
>> +
>> +pm_runtime_put(codec->dev);
> This seems really strange - why is the device being powered up to just
> set a bit and then potentially powered down immediately? I'd expect to
> just update the cache if the device is not active. You're also not
> checking that the power up worked.
I wanted to make sure that the device was on. I totally forgot that
the device was using regmap and the values are cached when the device
is not on.
I can remove the get/put around the update calls.
>
>> +
>> +static int tas2552_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt)
>> +{
>> +u8 serial_format;
>> +u8 serial_control_mask = 0x00;
>> +if (fmt & SND_SOC_DAIFMT_FORMAT_MASK)
>> +serial_control_mask |= TAS2552_DATA_FORMAT_MASK;
>> +if (serial_control_mask) {
>> +pm_runtime_get_sync(codec->dev);
>> +
>> +snd_soc_update_bits(codec, TAS2552_SER_CTRL_1,
>> serial_control_mask,
>> +serial_format);
>> +
>> +pm_runtime_put(codec->dev);
>> +}
> This seems broken - if the format mask ever gets set then it won't be
> cleared since we only do an update_bits() if the bit is being set. Why
> isn't the driver just doing an _update_bits()?
I do not understand what this statement means.
Are you saying snd_soc_update_bits will not clear the bit if the bit mask
is set appropriately?
>
> The comments about runtime PM also apply, they applies throughout the
> driver.
>
>> +static int tas2552_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id,
>> + unsigned int freq, int dir)
>> +{
>> +struct snd_soc_codec *codec = dai->codec;
>> +
>> +/* Fill in the PLL control registers for J & D
>> + * PLL_CLK = (.5 * freq * J.D) / 2^p
>> + * Need to fill in J and D here based on incoming freq
>> + */
>> +pm_runtime_get_sync(codec->dev);
>> +
>> +snd_soc_update_bits(codec, TAS2552_CFG_2, TAS2552_PLL_ENABLE, 0);
>> +
>> +snd_soc_write(codec, TAS2552_PLL_CTRL_1, 0x10);
>> +snd_soc_write(codec, TAS2552_PLL_CTRL_2, 0x00);
>> +snd_soc_write(codec, TAS2552_PLL_CTRL_3, 0x00);
>> +
>> +snd_soc_update_bits(codec, TAS2552_CFG_2, TAS2552_PLL_ENABLE,
>> +TAS2552_PLL_ENABLE);
>> +
>> +pm_runtime_put(codec->dev);
[PATCH v3] ASoC: tas2552: Support TI TAS2552 Amplifier
Support the TI TAS2552 Class D amplifier.
The TAS2552 is a high efficiency Class-D audio
power amplifier with advanced battery current
management and an integrated Class-G boost
The device constantly measures the
current and voltage across the load and provides a
digital stream of this information.
Signed-off-by: Dan Murphy
---
v3 - Updated bindings doc per comments, rearranged probe pdata vs
np check - https://patchwork.kernel.org/patch/4453481/
.../devicetree/bindings/sound/tas2552.txt | 22 +
include/sound/tas2552-plat.h | 25 ++
sound/soc/codecs/Kconfig |5 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tas2552.c | 463
sound/soc/codecs/tas2552.h | 75
6 files changed, 592 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas2552.txt
create mode 100644 include/sound/tas2552-plat.h
create mode 100644 sound/soc/codecs/tas2552.c
create mode 100644 sound/soc/codecs/tas2552.h
diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt
b/Documentation/devicetree/bindings/sound/tas2552.txt
new file mode 100644
index 000..ada8fd4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas2552.txt
@@ -0,0 +1,22 @@
+Texas Instruments - tas2552 Codec module
+
+The tas2552 serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - One of:
+"ti,tas2552" - TAS2552
+
+- reg - I2C slave address
+
+Optional properties:
+
+- power-gpio - gpio pin to enable/disable the device
+
+Example:
+
+tas2552: tas2552@41 {
+ compatible = "ti,tas2552";
+ reg = <0x41>;
+ enable-gpio = < 2 GPIO_ACTIVE_HIGH>;
+};
diff --git a/include/sound/tas2552-plat.h b/include/sound/tas2552-plat.h
new file mode 100644
index 000..65e7627
--- /dev/null
+++ b/include/sound/tas2552-plat.h
@@ -0,0 +1,25 @@
+/*
+ * TAS2552 driver platform header
+ *
+ * Copyright (C) 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef TAS2552_PLAT_H
+#define TAS2552_PLAT_H
+
+struct tas2552_platform_data {
+ int enable_gpio;
+};
+
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0b9571c..cc09261 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -99,6 +99,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC32X4 if I2C
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TPA6130A2 if I2C
+ select SND_SOC_TAS2552 if I2C
select SND_SOC_TLV320DAC33 if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_TWL6040 if TWL6040_CORE
@@ -754,4 +755,8 @@ config SND_SOC_TPA6130A2
tristate "Texas Instruments TPA6130A2 headphone amplifier"
depends on I2C
+config SND_SOC_TAS2552
+ tristate "Texas Instruments TAS2552 Mono Audio amplifier"
+ depends on I2C
+
endmenu
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 1bd6e1c..33bc7228 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -162,6 +162,7 @@ snd-soc-wm-hubs-objs := wm_hubs.o
# Amp
snd-soc-max9877-objs := max9877.o
snd-soc-tpa6130a2-objs := tpa6130a2.o
+snd-soc-tas2552-objs := tas2552.o
obj-$(CONFIG_SND_SOC_88PM860X) += snd-soc-88pm860x.o
obj-$(CONFIG_SND_SOC_AB8500_CODEC) += snd-soc-ab8500-codec.o
@@ -325,3 +326,4 @@ obj-$(CONFIG_SND_SOC_WM_HUBS) += snd-soc-wm-hubs.o
# Amp
obj-$(CONFIG_SND_SOC_MAX9877) += snd-soc-max9877.o
obj-$(CONFIG_SND_SOC_TPA6130A2)+= snd-soc-tpa6130a2.o
+obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
new file mode 100644
index 000..79b8212
--- /dev/null
+++ b/sound/soc/codecs/tas2552.c
@@ -0,0 +1,463 @@
+/*
+ * ALSA SoC Texas Instruments TAS2552 Mono Audio Amplifier
+ *
+ * Copyright (C) 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+
Re: [PATCH v3] ASoC: tas2552: Support TI TAS2552 Amplifier
Felipe
Thanks for the review
On 07/02/2014 09:10 AM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jul 02, 2014 at 08:30:52AM -0500, Dan Murphy wrote:
>> Support the TI TAS2552 Class D amplifier.
>>
>> The TAS2552 is a high efficiency Class-D audio
>> power amplifier with advanced battery current
>> management and an integrated Class-G boost
>> The device constantly measures the
>> current and voltage across the load and provides a
>> digital stream of this information.
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> v3 - Updated bindings doc per comments, rearranged probe pdata vs
>> np check - https://patchwork.kernel.org/patch/4453481/
>>
>> .../devicetree/bindings/sound/tas2552.txt | 22 +
>> include/sound/tas2552-plat.h | 25 ++
>> sound/soc/codecs/Kconfig |5 +
>> sound/soc/codecs/Makefile |2 +
>> sound/soc/codecs/tas2552.c | 463
>>
>> sound/soc/codecs/tas2552.h | 75
>> 6 files changed, 592 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/sound/tas2552.txt
>> create mode 100644 include/sound/tas2552-plat.h
>> create mode 100644 sound/soc/codecs/tas2552.c
>> create mode 100644 sound/soc/codecs/tas2552.h
>>
>> diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt
>> b/Documentation/devicetree/bindings/sound/tas2552.txt
>> new file mode 100644
>> index 000..ada8fd4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/tas2552.txt
>> @@ -0,0 +1,22 @@
>> +Texas Instruments - tas2552 Codec module
>> +
>> +The tas2552 serial control bus communicates through I2C protocols
>> +
>> +Required properties:
>> +
>> +- compatible - One of:
>> +"ti,tas2552" - TAS2552
>> +
>> +- reg - I2C slave address
>> +
>> +Optional properties:
>> +
>> +- power-gpio - gpio pin to enable/disable the device
>> +
>> +Example:
>> +
>> +tas2552: tas2552@41 {
>> +compatible = "ti,tas2552";
>> +reg = <0x41>;
>> +enable-gpio = < 2 GPIO_ACTIVE_HIGH>;
> you probably want to add:
>
> pvdd-supply = <>;
> vbat-supply = <>;
> avdd-supply = <>;
> iovdd-supply = <>;
>
> that way you can make sure to switch your regulators on from the driver.
> Since they must be all on, you can just grab them all with
> regulator_bulk_get() and enable them all with regulator_bulk_enable().
I could add this but I don't have a use case for this so I did not add the code.
The supplies I used were always-on so adding the regulators was not testable in
this
patchset.
I could add this but it would be untested.
> Also, I wonder if it makes sense to add a link to [1] here.
Any reference to documentation is a good reference as long as the URL is
going to always be available.
>
> [1] http://www.ti.com/product/TAS2552
>> +};
>> diff --git a/include/sound/tas2552-plat.h b/include/sound/tas2552-plat.h
>> new file mode 100644
>> index 000..65e7627
>> --- /dev/null
>> +++ b/include/sound/tas2552-plat.h
> platform-data is usually placed under include/linux/platform_data/
I can move it if others agree. There seems to be a mix of platform data
for sound drivers between sound and platform_data so it is up to the
maintainer if they want it moved.
I am OK with either location.
>
>> @@ -0,0 +1,25 @@
>> +/*
>> + * TAS2552 driver platform header
>> + *
>> + * Copyright (C) 2014 Texas Instruments Inc.
>> + *
>> + * Author: Dan Murphy
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but
>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + */
>> +
>> +#ifndef TAS2552_PLAT_H
>> +#define TAS2552_PLAT_H
>> +
>> +struct tas2552_platform_data {
>> +int enable_gpio;
>> +};
>> +
>> +#endif
>> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
>> index 0b9571c..cc09261 100644
>> --- a/sound/soc/codecs/Kconfig
>> +++ b/sound/soc/codecs/Kconfig
>> @@ -99,6 +99,7 @@ config SND_S
Re: [alsa-devel] [PATCH v3] ASoC: tas2552: Support TI TAS2552 Amplifier
Daniel
Thanks for the review
On 07/02/2014 08:47 AM, Daniel Mack wrote:
> Hi Dan,
>
> On 07/02/2014 03:30 PM, Dan Murphy wrote:
>> +if (np) {
>> +data->power_gpio = of_get_named_gpio(np, "enable-gpio", 0);
>> +} else if (pdata) {
>> +data->power_gpio = pdata->enable_gpio;
>> +} else {
>> +dev_err(dev, "Platform or dev tree data not set\n");
>> +return -ENODEV;
>> +}
> New code for GPIO handling should use the new gpiod interface.
> See include/linux/gpio/consumer.h, or the sta350 codec driver.
OK good catch. I will look into it.
Does the gpiod interface handle both pdata as well as dt?
> For that to work, you also need to rename the property to
> 'enable-gpios', even though there's only one.
I am looking for that restriction in the code. But don't see it.
Will dig some more here.
>
>
> Daniel
>
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ASoC: tas2552: Support TI TAS2552 Amplifier
On 07/02/2014 10:03 AM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jul 02, 2014 at 09:53:10AM -0500, Dan Murphy wrote:
>> Felipe
>> Thanks for the review
>>
>> On 07/02/2014 09:10 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Wed, Jul 02, 2014 at 08:30:52AM -0500, Dan Murphy wrote:
>>>> Support the TI TAS2552 Class D amplifier.
>>>>
>>>> The TAS2552 is a high efficiency Class-D audio
>>>> power amplifier with advanced battery current
>>>> management and an integrated Class-G boost
>>>> The device constantly measures the
>>>> current and voltage across the load and provides a
>>>> digital stream of this information.
>>>>
>>>> Signed-off-by: Dan Murphy
>>>> ---
>>>>
>>>> v3 - Updated bindings doc per comments, rearranged probe pdata vs
>>>> np check - https://patchwork.kernel.org/patch/4453481/
>>>>
>>>> .../devicetree/bindings/sound/tas2552.txt | 22 +
>>>> include/sound/tas2552-plat.h | 25 ++
>>>> sound/soc/codecs/Kconfig |5 +
>>>> sound/soc/codecs/Makefile |2 +
>>>> sound/soc/codecs/tas2552.c | 463
>>>>
>>>> sound/soc/codecs/tas2552.h | 75
>>>> 6 files changed, 592 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/sound/tas2552.txt
>>>> create mode 100644 include/sound/tas2552-plat.h
>>>> create mode 100644 sound/soc/codecs/tas2552.c
>>>> create mode 100644 sound/soc/codecs/tas2552.h
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt
>>>> b/Documentation/devicetree/bindings/sound/tas2552.txt
>>>> new file mode 100644
>>>> index 000..ada8fd4
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/sound/tas2552.txt
>>>> @@ -0,0 +1,22 @@
>>>> +Texas Instruments - tas2552 Codec module
>>>> +
>>>> +The tas2552 serial control bus communicates through I2C protocols
>>>> +
>>>> +Required properties:
>>>> +
>>>> +- compatible - One of:
>>>> +"ti,tas2552" - TAS2552
>>>> +
>>>> +- reg - I2C slave address
>>>> +
>>>> +Optional properties:
>>>> +
>>>> +- power-gpio - gpio pin to enable/disable the device
>>>> +
>>>> +Example:
>>>> +
>>>> +tas2552: tas2552@41 {
>>>> + compatible = "ti,tas2552";
>>>> + reg = <0x41>;
>>>> + enable-gpio = < 2 GPIO_ACTIVE_HIGH>;
>>> you probably want to add:
>>>
>>> pvdd-supply = <>;
>>> vbat-supply = <>;
>>> avdd-supply = <>;
>>> iovdd-supply = <>;
>>>
>>> that way you can make sure to switch your regulators on from the driver.
>>> Since they must be all on, you can just grab them all with
>>> regulator_bulk_get() and enable them all with regulator_bulk_enable().
>> I could add this but I don't have a use case for this so I did not add
>> the code.
> actually, you do. Right now you have a device which is powered by
> several different sources (fixed or not).
Does the regulator_enable *gaurantee* that the supplies will be turned on in
the following order?
1. VBAT,
2. IOVDD,
3. AVDD.
>
>> The supplies I used were always-on so adding the regulators was not
>> testable in this patchset.
> it _is_ testable. regulator_get()/regulator_enable() still works on
> fixed regulators.
I did not say i used fixed regulators. I indicated that the regulators
were always-on. So regulator_enable/disable would have no affect. right?
I mean you cannot turn off vbat right?
>
>>>> @@ -325,3 +326,4 @@ obj-$(CONFIG_SND_SOC_WM_HUBS) += snd-soc-wm-hubs.o
>>>> # Amp
>>>> obj-$(CONFIG_SND_SOC_MAX9877) += snd-soc-max9877.o
>>>> obj-$(CONFIG_SND_SOC_TPA6130A2) += snd-soc-tpa6130a2.o
>>>> +obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
>>>> diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
>>>> new file mode 100644
>>>> index 000..79b8212
>>>> --- /dev/null
>>>> +++ b/sound/soc/codecs/tas2552.c
>>>> @@ -0,0 +1,463 @@
>>>> +/*
>>>> + * ALSA
Re: [PATCH v3] ASoC: tas2552: Support TI TAS2552 Amplifier
Felipe
As always great feedback thanks!!!
On 07/02/2014 10:43 AM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jul 02, 2014 at 10:30:25AM -0500, Dan Murphy wrote:
>> On 07/02/2014 10:03 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Wed, Jul 02, 2014 at 09:53:10AM -0500, Dan Murphy wrote:
>>>> Felipe
>>>> Thanks for the review
>>>>
>>>> On 07/02/2014 09:10 AM, Felipe Balbi wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Jul 02, 2014 at 08:30:52AM -0500, Dan Murphy wrote:
>>>>>> Support the TI TAS2552 Class D amplifier.
>>>>>>
>>>>>> The TAS2552 is a high efficiency Class-D audio
>>>>>> power amplifier with advanced battery current
>>>>>> management and an integrated Class-G boost
>>>>>> The device constantly measures the
>>>>>> current and voltage across the load and provides a
>>>>>> digital stream of this information.
>>>>>>
>>>>>> Signed-off-by: Dan Murphy
>>>>>> ---
>>>>>>
>>>>>> v3 - Updated bindings doc per comments, rearranged probe pdata vs
>>>>>> np check - https://patchwork.kernel.org/patch/4453481/
>>>>>>
>>>>>> .../devicetree/bindings/sound/tas2552.txt | 22 +
>>>>>> include/sound/tas2552-plat.h | 25 ++
>>>>>> sound/soc/codecs/Kconfig |5 +
>>>>>> sound/soc/codecs/Makefile |2 +
>>>>>> sound/soc/codecs/tas2552.c | 463
>>>>>>
>>>>>> sound/soc/codecs/tas2552.h | 75
>>>>>> 6 files changed, 592 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/sound/tas2552.txt
>>>>>> create mode 100644 include/sound/tas2552-plat.h
>>>>>> create mode 100644 sound/soc/codecs/tas2552.c
>>>>>> create mode 100644 sound/soc/codecs/tas2552.h
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt
>>>>>> b/Documentation/devicetree/bindings/sound/tas2552.txt
>>>>>> new file mode 100644
>>>>>> index 000..ada8fd4
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/sound/tas2552.txt
>>>>>> @@ -0,0 +1,22 @@
>>>>>> +Texas Instruments - tas2552 Codec module
>>>>>> +
>>>>>> +The tas2552 serial control bus communicates through I2C protocols
>>>>>> +
>>>>>> +Required properties:
>>>>>> +
>>>>>> +- compatible - One of:
>>>>>> +"ti,tas2552" - TAS2552
>>>>>> +
>>>>>> +- reg - I2C slave address
>>>>>> +
>>>>>> +Optional properties:
>>>>>> +
>>>>>> +- power-gpio - gpio pin to enable/disable the device
>>>>>> +
>>>>>> +Example:
>>>>>> +
>>>>>> +tas2552: tas2552@41 {
>>>>>> +compatible = "ti,tas2552";
>>>>>> +reg = <0x41>;
>>>>>> +enable-gpio = < 2 GPIO_ACTIVE_HIGH>;
>>>>> you probably want to add:
>>>>>
>>>>> pvdd-supply = <>;
>>>>> vbat-supply = <>;
>>>>> avdd-supply = <>;
>>>>> iovdd-supply = <>;
>>>>>
>>>>> that way you can make sure to switch your regulators on from the driver.
>>>>> Since they must be all on, you can just grab them all with
>>>>> regulator_bulk_get() and enable them all with regulator_bulk_enable().
>>>> I could add this but I don't have a use case for this so I did not add
>>>> the code.
>>> actually, you do. Right now you have a device which is powered by
>>> several different sources (fixed or not).
>> Does the regulator_enable *gaurantee* that the supplies will be turned on in
>> the following order?
>>
>> 1. VBAT,
>> 2. IOVDD,
>> 3. AVDD.
> you can always regulator_enable() each one in the order you want.
Will add this then.
>
>>>> The supplies I used were always-on so adding the regulators was not
>>>> testa
[PATCH v4] ASoC: tas2552: Support TI TAS2552 Amplifier
Support the TI TAS2552 Class D amplifier.
The TAS2552 is a high efficiency Class-D audio
power amplifier with advanced battery current
management and an integrated Class-G boost
The device constantly measures the
current and voltage across the load and provides a
digital stream of this information.
Signed-off-by: Dan Murphy
---
v4 - Added pm_runtime support, removed magical numbers, added regulator
support, changed from legacy gpio to new gpiod calls, fixed default register
values, flipped on battery tracking support and
added suspend/resume support - https://patchwork.kernel.org/patch/4465611/
.../devicetree/bindings/sound/tas2552.txt | 25 +
include/sound/tas2552-plat.h | 25 +
sound/soc/codecs/Kconfig |5 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tas2552.c | 574
sound/soc/codecs/tas2552.h | 119
6 files changed, 750 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas2552.txt
create mode 100644 include/sound/tas2552-plat.h
create mode 100644 sound/soc/codecs/tas2552.c
create mode 100644 sound/soc/codecs/tas2552.h
diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt
b/Documentation/devicetree/bindings/sound/tas2552.txt
new file mode 100644
index 000..00223dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas2552.txt
@@ -0,0 +1,25 @@
+Texas Instruments - tas2552 Codec module
+
+The tas2552 serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - One of:
+"ti,tas2552" - TAS2552
+
+- reg - I2C slave address
+
+Optional properties:
+
+- enable-gpio - gpio pin to enable/disable the device
+
+Example:
+
+tas2552: tas2552@41 {
+ compatible = "ti,tas2552";
+ reg = <0x41>;
+ enable-gpio = < 2 GPIO_ACTIVE_HIGH>;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/TAS2552
diff --git a/include/sound/tas2552-plat.h b/include/sound/tas2552-plat.h
new file mode 100644
index 000..65e7627
--- /dev/null
+++ b/include/sound/tas2552-plat.h
@@ -0,0 +1,25 @@
+/*
+ * TAS2552 driver platform header
+ *
+ * Copyright (C) 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef TAS2552_PLAT_H
+#define TAS2552_PLAT_H
+
+struct tas2552_platform_data {
+ int enable_gpio;
+};
+
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0b9571c..cc09261 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -99,6 +99,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC32X4 if I2C
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TPA6130A2 if I2C
+ select SND_SOC_TAS2552 if I2C
select SND_SOC_TLV320DAC33 if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_TWL6040 if TWL6040_CORE
@@ -754,4 +755,8 @@ config SND_SOC_TPA6130A2
tristate "Texas Instruments TPA6130A2 headphone amplifier"
depends on I2C
+config SND_SOC_TAS2552
+ tristate "Texas Instruments TAS2552 Mono Audio amplifier"
+ depends on I2C
+
endmenu
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 1bd6e1c..33bc7228 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -162,6 +162,7 @@ snd-soc-wm-hubs-objs := wm_hubs.o
# Amp
snd-soc-max9877-objs := max9877.o
snd-soc-tpa6130a2-objs := tpa6130a2.o
+snd-soc-tas2552-objs := tas2552.o
obj-$(CONFIG_SND_SOC_88PM860X) += snd-soc-88pm860x.o
obj-$(CONFIG_SND_SOC_AB8500_CODEC) += snd-soc-ab8500-codec.o
@@ -325,3 +326,4 @@ obj-$(CONFIG_SND_SOC_WM_HUBS) += snd-soc-wm-hubs.o
# Amp
obj-$(CONFIG_SND_SOC_MAX9877) += snd-soc-max9877.o
obj-$(CONFIG_SND_SOC_TPA6130A2)+= snd-soc-tpa6130a2.o
+obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
new file mode 100644
index 000..6eab02f
--- /dev/null
+++ b/sound/soc/codecs/tas2552.c
@@ -0,0 +1,574 @@
+/*
+ * tas2552.c - ALSA SoC Texas Instruments TAS2552 Mono Audio Amplifier
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundat
Re: [PATCH v4] ASoC: tas2552: Support TI TAS2552 Amplifier
On 07/03/2014 09:52 AM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Jul 03, 2014 at 09:39:53AM -0500, Dan Murphy wrote:
>> +static int tas2552_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt)
>> +{
>> +u8 serial_format;
>> +struct snd_soc_codec *codec = dai->codec;
>> +
>> +switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
>> +case SND_SOC_DAIFMT_CBS_CFS:
>> +serial_format = 0x00;
>> +break;
>> +case SND_SOC_DAIFMT_CBS_CFM:
>> +serial_format = TAS2552_WORD_CLK_MASK;
>> +break;
>> +case SND_SOC_DAIFMT_CBM_CFS:
>> +serial_format = TAS2552_BIT_CLK_MASK;
>> +break;
>> +case SND_SOC_DAIFMT_CBM_CFM:
>> +serial_format = (TAS2552_BIT_CLK_MASK | TAS2552_WORD_CLK_MASK);
>> +break;
>> +default:
>> +return -EINVAL;
>> +}
>> +
>> +pm_runtime_get_sync(codec->dev);
>> +
>> +snd_soc_update_bits(codec, TAS2552_SER_CTRL_1,
>> +(TAS2552_BIT_CLK_MASK | TAS2552_WORD_CLK_MASK),
>> +serial_format);
>> +
>> +pm_runtime_put(codec->dev);
> I have a feeling it's better to just put at the end of the function.
> Remember your pm_runtime_put() will issue i2c transfers which can take a
> looong time ;-)
I thought about that but the next switch case could return if the format
mask is invalid which means the runtime calls would not be balanced.
So I decided to wrap the snd_soc calls with the pm_runtime calls to keep it
balanced.
Dan
>
> other than that, looks ok to me:
>
> Reviewed-by: Felipe Balbi
>
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] ASoC: tas2552: Support TI TAS2552 Amplifier
Hi
On 07/03/2014 10:06 AM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Jul 03, 2014 at 09:57:39AM -0500, Dan Murphy wrote:
>> On 07/03/2014 09:52 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Thu, Jul 03, 2014 at 09:39:53AM -0500, Dan Murphy wrote:
>>>> +static int tas2552_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt)
>>>> +{
>>>> + u8 serial_format;
>>>> + struct snd_soc_codec *codec = dai->codec;
>>>> +
>>>> + switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
>>>> + case SND_SOC_DAIFMT_CBS_CFS:
>>>> + serial_format = 0x00;
>>>> + break;
>>>> + case SND_SOC_DAIFMT_CBS_CFM:
>>>> + serial_format = TAS2552_WORD_CLK_MASK;
>>>> + break;
>>>> + case SND_SOC_DAIFMT_CBM_CFS:
>>>> + serial_format = TAS2552_BIT_CLK_MASK;
>>>> + break;
>>>> + case SND_SOC_DAIFMT_CBM_CFM:
>>>> + serial_format = (TAS2552_BIT_CLK_MASK | TAS2552_WORD_CLK_MASK);
>>>> + break;
>>>> + default:
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + pm_runtime_get_sync(codec->dev);
>>>> +
>>>> + snd_soc_update_bits(codec, TAS2552_SER_CTRL_1,
>>>> + (TAS2552_BIT_CLK_MASK | TAS2552_WORD_CLK_MASK),
>>>> + serial_format);
>>>> +
>>>> + pm_runtime_put(codec->dev);
>>> I have a feeling it's better to just put at the end of the function.
>>> Remember your pm_runtime_put() will issue i2c transfers which can take a
>>> looong time ;-)
>> I thought about that but the next switch case could return if the format
>> mask is invalid which means the runtime calls would not be balanced.
>>
>> So I decided to wrap the snd_soc calls with the pm_runtime calls to keep it
>> balanced.
> it looks like you can do both switch statements outside of the
> pm_runtime region and cache results on serial_format and do a single
> write to CTRL_1 register (?). If not, then just use two local variables.
>
Yeah I could probably consolidate these into a single call. And throw a debug
statement
in the default case to why the format was not set.
Dan
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] ASoC: tas2552: Support TI TAS2552 Amplifier
Support the TI TAS2552 Class D amplifier.
The TAS2552 is a high efficiency Class-D audio
power amplifier with advanced battery current
management and an integrated Class-G boost
The device constantly measures the
current and voltage across the load and provides a
digital stream of this information.
Signed-off-by: Dan Murphy
---
v5 - Consolidated dai_fmt call back to write serial control register
once - https://patchwork.kernel.org/patch/4474531/
.../devicetree/bindings/sound/tas2552.txt | 25 +
include/sound/tas2552-plat.h | 25 +
sound/soc/codecs/Kconfig |5 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tas2552.c | 576
sound/soc/codecs/tas2552.h | 120
6 files changed, 753 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas2552.txt
create mode 100644 include/sound/tas2552-plat.h
create mode 100644 sound/soc/codecs/tas2552.c
create mode 100644 sound/soc/codecs/tas2552.h
diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt
b/Documentation/devicetree/bindings/sound/tas2552.txt
new file mode 100644
index 000..00223dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas2552.txt
@@ -0,0 +1,25 @@
+Texas Instruments - tas2552 Codec module
+
+The tas2552 serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - One of:
+"ti,tas2552" - TAS2552
+
+- reg - I2C slave address
+
+Optional properties:
+
+- enable-gpio - gpio pin to enable/disable the device
+
+Example:
+
+tas2552: tas2552@41 {
+ compatible = "ti,tas2552";
+ reg = <0x41>;
+ enable-gpio = < 2 GPIO_ACTIVE_HIGH>;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/TAS2552
diff --git a/include/sound/tas2552-plat.h b/include/sound/tas2552-plat.h
new file mode 100644
index 000..65e7627
--- /dev/null
+++ b/include/sound/tas2552-plat.h
@@ -0,0 +1,25 @@
+/*
+ * TAS2552 driver platform header
+ *
+ * Copyright (C) 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef TAS2552_PLAT_H
+#define TAS2552_PLAT_H
+
+struct tas2552_platform_data {
+ int enable_gpio;
+};
+
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0b9571c..cc09261 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -99,6 +99,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC32X4 if I2C
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TPA6130A2 if I2C
+ select SND_SOC_TAS2552 if I2C
select SND_SOC_TLV320DAC33 if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_TWL6040 if TWL6040_CORE
@@ -754,4 +755,8 @@ config SND_SOC_TPA6130A2
tristate "Texas Instruments TPA6130A2 headphone amplifier"
depends on I2C
+config SND_SOC_TAS2552
+ tristate "Texas Instruments TAS2552 Mono Audio amplifier"
+ depends on I2C
+
endmenu
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 1bd6e1c..33bc7228 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -162,6 +162,7 @@ snd-soc-wm-hubs-objs := wm_hubs.o
# Amp
snd-soc-max9877-objs := max9877.o
snd-soc-tpa6130a2-objs := tpa6130a2.o
+snd-soc-tas2552-objs := tas2552.o
obj-$(CONFIG_SND_SOC_88PM860X) += snd-soc-88pm860x.o
obj-$(CONFIG_SND_SOC_AB8500_CODEC) += snd-soc-ab8500-codec.o
@@ -325,3 +326,4 @@ obj-$(CONFIG_SND_SOC_WM_HUBS) += snd-soc-wm-hubs.o
# Amp
obj-$(CONFIG_SND_SOC_MAX9877) += snd-soc-max9877.o
obj-$(CONFIG_SND_SOC_TPA6130A2)+= snd-soc-tpa6130a2.o
+obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
new file mode 100644
index 000..fe305d6
--- /dev/null
+++ b/sound/soc/codecs/tas2552.c
@@ -0,0 +1,576 @@
+/*
+ * tas2552.c - ALSA SoC Texas Instruments TAS2552 Mono Audio Amplifier
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILI
[PATCH v2] ASoC: tas2552: Support TI TAS2552 Amplifier
Support the TI TAS2552 Class D amplifier.
The TAS2552 is a high efficiency Class-D audio
power amplifier with advanced battery current
management and an integrated Class-G boost
The device constantly measures the
current and voltage across the load and provides a
digital stream of this information.
Signed-off-by: Dan Murphy
---
v2 - Address RFC comments- Added regmap, and snd_soc calls
removed debug code, address checkpatch errors
-https://patchwork.kernel.org/patch/4378281/
.../devicetree/bindings/sound/tas2552.txt | 22 +
include/sound/tas2552-plat.h | 25 ++
sound/soc/codecs/Kconfig |5 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tas2552.c | 462
sound/soc/codecs/tas2552.h | 75
6 files changed, 591 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas2552.txt
create mode 100644 include/sound/tas2552-plat.h
create mode 100644 sound/soc/codecs/tas2552.c
create mode 100644 sound/soc/codecs/tas2552.h
diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt
b/Documentation/devicetree/bindings/sound/tas2552.txt
new file mode 100644
index 000..58e931b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas2552.txt
@@ -0,0 +1,22 @@
+Texas Instruments - tas2552 Codec module
+
+The tas2552 serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - "string" - One of:
+"ti,tas2552" - TAS2552
+
+- reg - - I2C slave address
+
+Optional properties:
+
+- power-gpio - gpio pin to enable/disable the device
+
+Example:
+
+tas2552: tas2552@41 {
+ compatible = "ti,tas2552";
+ reg = <0x41>;
+ power-gpio = < 2 GPIO_ACTIVE_HIGH>;
+};
diff --git a/include/sound/tas2552-plat.h b/include/sound/tas2552-plat.h
new file mode 100644
index 000..c8120f2
--- /dev/null
+++ b/include/sound/tas2552-plat.h
@@ -0,0 +1,25 @@
+/*
+ * TAS2552 driver platform header
+ *
+ * Copyright (C) 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef TAS2552_PLAT_H
+#define TAS2552_PLAT_H
+
+struct tas2552_platform_data {
+ int power_gpio;
+};
+
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0b9571c..cc09261 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -99,6 +99,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC32X4 if I2C
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TPA6130A2 if I2C
+ select SND_SOC_TAS2552 if I2C
select SND_SOC_TLV320DAC33 if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_TWL6040 if TWL6040_CORE
@@ -754,4 +755,8 @@ config SND_SOC_TPA6130A2
tristate "Texas Instruments TPA6130A2 headphone amplifier"
depends on I2C
+config SND_SOC_TAS2552
+ tristate "Texas Instruments TAS2552 Mono Audio amplifier"
+ depends on I2C
+
endmenu
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 1bd6e1c..33bc7228 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -162,6 +162,7 @@ snd-soc-wm-hubs-objs := wm_hubs.o
# Amp
snd-soc-max9877-objs := max9877.o
snd-soc-tpa6130a2-objs := tpa6130a2.o
+snd-soc-tas2552-objs := tas2552.o
obj-$(CONFIG_SND_SOC_88PM860X) += snd-soc-88pm860x.o
obj-$(CONFIG_SND_SOC_AB8500_CODEC) += snd-soc-ab8500-codec.o
@@ -325,3 +326,4 @@ obj-$(CONFIG_SND_SOC_WM_HUBS) += snd-soc-wm-hubs.o
# Amp
obj-$(CONFIG_SND_SOC_MAX9877) += snd-soc-max9877.o
obj-$(CONFIG_SND_SOC_TPA6130A2)+= snd-soc-tpa6130a2.o
+obj-$(CONFIG_SND_SOC_TAS2552) += snd-soc-tas2552.o
diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
new file mode 100644
index 000..228d5bb
--- /dev/null
+++ b/sound/soc/codecs/tas2552.c
@@ -0,0 +1,462 @@
+/*
+ * ALSA SoC Texas Instruments TAS2552 Mono Audio Amplifier
+ *
+ * Copyright (C) 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for m
Re: [PATCH v2] ASoC: tas2552: Support TI TAS2552 Amplifier
Hi
On 06/30/2014 12:21 PM, Mark Rutland wrote:
> Hi,
>
> On Mon, Jun 30, 2014 at 06:10:59PM +0100, Dan Murphy wrote:
>> Support the TI TAS2552 Class D amplifier.
>>
>> The TAS2552 is a high efficiency Class-D audio
>> power amplifier with advanced battery current
>> management and an integrated Class-G boost
>> The device constantly measures the
>> current and voltage across the load and provides a
>> digital stream of this information.
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> v2 - Address RFC comments- Added regmap, and snd_soc calls
>> removed debug code, address checkpatch errors
>> -https://patchwork.kernel.org/patch/4378281/
>>
>> .../devicetree/bindings/sound/tas2552.txt | 22 +
>> include/sound/tas2552-plat.h | 25 ++
>> sound/soc/codecs/Kconfig |5 +
>> sound/soc/codecs/Makefile |2 +
>> sound/soc/codecs/tas2552.c | 462
>>
>> sound/soc/codecs/tas2552.h | 75
>> 6 files changed, 591 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/sound/tas2552.txt
>> create mode 100644 include/sound/tas2552-plat.h
>> create mode 100644 sound/soc/codecs/tas2552.c
>> create mode 100644 sound/soc/codecs/tas2552.h
>>
>> diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt
>> b/Documentation/devicetree/bindings/sound/tas2552.txt
>> new file mode 100644
>> index 000..58e931b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/tas2552.txt
>> @@ -0,0 +1,22 @@
>> +Texas Instruments - tas2552 Codec module
>> +
>> +The tas2552 serial control bus communicates through I2C protocols
>> +
>> +Required properties:
>> +
>> +- compatible - "string" - One of:
>> +"ti,tas2552" - TAS2552
> Drop the "string". The compatible list is a standard property and its
> type (string list) is well-known.
>
> You could change "One of:" to "should contain:", which will look less
> weird with a single entry.
>
>> +- reg - - I2C slave address
> Similarly to "string" we can get rid of here. i2c addresses are
> well-known to be described in a single u32 cell.
>
>> +
>> +Optional properties:
>> +
>> +- power-gpio - gpio pin to enable/disable the device
> The code below seems to look for "enable-gpio". Searching for
> "power-gpio" only hits in the line above and the example below. I assume
> the code is in error?
No this was PEBKAC I did not update the documentation when I wrote the
code.
>
>> +
>> +Example:
>> +
>> +tas2552: tas2552@41 {
>> + compatible = "ti,tas2552";
>> + reg = <0x41>;
>> + power-gpio = < 2 GPIO_ACTIVE_HIGH>;
>> +};
> [...]
>
>> + if (pdata) {
>> + data->power_gpio = pdata->power_gpio;
>> + } else if (np) {
>> + data->power_gpio = of_get_named_gpio(np, "enable-gpio", 0);
> Usually I see this logic the other way around, looking for DT data first
> then falling back to platform data if no DT information was present.
>
> Cheers,
> Mark.
Thanks for the review. I will take these changes into v3 after a good code
review soak time.
Dan
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7] ASoC: tas2552: Support TI TAS2552 Amplifier
Support the TI TAS2552 Class D amplifier.
The TAS2552 is a high efficiency Class-D audio
power amplifier with advanced battery current
management and an integrated Class-G boost
The device constantly measures the
current and voltage across the load and provides a
digital stream of this information.
Signed-off-by: Dan Murphy
---
v7 - Addressed pm_runtime comments, sorted and alphatized the Makefile
and Kconfg, removed "-codec", disable PLL at probe -
https://patchwork.kernel.org/patch/4535501/
v6 - Addressed comments from v5 also added PLL algorithim instead of
hard coding PLL registers - https://patchwork.kernel.org/patch/4476001/
v5 - Consolidated dai_fmt call back to write serial control register
once - https://patchwork.kernel.org/patch/4474531/
v4 - Added pm_runtime support, removed magical numbers, added regulator
support, changed from legacy gpio to new gpiod calls, fixed default register
values, flipped on battery tracking support and
added suspend/resume support - https://patchwork.kernel.org/patch/4465611/
v3 - Updated bindings doc per comments, rearranged probe pdata vs
np check - https://patchwork.kernel.org/patch/4453481/
v2 - Address RFC comments- Added regmap, and snd_soc calls
removed debug code, address checkpatch errors
-https://patchwork.kernel.org/patch/4378281/
.../devicetree/bindings/sound/tas2552.txt | 26 +
include/sound/tas2552-plat.h | 25 +
sound/soc/codecs/Kconfig |5 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/tas2552.c | 540
sound/soc/codecs/tas2552.h | 129 +
6 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas2552.txt
create mode 100644 include/sound/tas2552-plat.h
create mode 100644 sound/soc/codecs/tas2552.c
create mode 100644 sound/soc/codecs/tas2552.h
diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt
b/Documentation/devicetree/bindings/sound/tas2552.txt
new file mode 100644
index 000..55e2a0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tas2552.txt
@@ -0,0 +1,26 @@
+Texas Instruments - tas2552 Codec module
+
+The tas2552 serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible - One of:
+ "ti,tas2552" - TAS2552
+ - reg - I2C slave address
+ - supply-*: Required supply regulators are:
+ "vbat" battery voltage
+ "iovdd" I/O Voltage
+ "avdd" Analog DAC Voltage
+
+Optional properties:
+ - enable-gpio - gpio pin to enable/disable the device
+
+Example:
+
+tas2552: tas2552@41 {
+ compatible = "ti,tas2552";
+ reg = <0x41>;
+ enable-gpio = < 2 GPIO_ACTIVE_HIGH>;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/TAS2552
diff --git a/include/sound/tas2552-plat.h b/include/sound/tas2552-plat.h
new file mode 100644
index 000..65e7627
--- /dev/null
+++ b/include/sound/tas2552-plat.h
@@ -0,0 +1,25 @@
+/*
+ * TAS2552 driver platform header
+ *
+ * Copyright (C) 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef TAS2552_PLAT_H
+#define TAS2552_PLAT_H
+
+struct tas2552_platform_data {
+ int enable_gpio;
+};
+
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0b9571c..fbaa329 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -91,6 +91,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_STA350 if I2C
select SND_SOC_STA529 if I2C
select SND_SOC_STAC9766 if SND_SOC_AC97_BUS
+ select SND_SOC_TAS2552 if I2C
select SND_SOC_TAS5086 if I2C
select SND_SOC_TLV320AIC23_I2C if I2C
select SND_SOC_TLV320AIC23_SPI if SPI_MASTER
@@ -521,6 +522,10 @@ config SND_SOC_STA529
config SND_SOC_STAC9766
tristate
+config SND_SOC_TAS2552
+ tristate "Texas Instruments TAS2552 Mono Audio amplifier"
+ depends on I2C
+
config SND_SOC_TAS5086
tristate "Texas Instruments TAS5086 speaker amplifier"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 1bd6e1c..3f20ecd 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -162,6 +162,7 @@ snd-soc-wm-hubs-objs := wm_hubs.o
# Amp
snd-soc-max9877-objs :
[PATCH 2/2] ASoC: tas2552: Add DAPM calls for amp and PLL
Add DAPM calls to enable/disable the Class D amp.
Also add a DAPM call to turn off the PLL upon
the stream completing.
Signed-off-by: Dan Murphy
---
sound/soc/codecs/tas2552.c | 58 +++-
1 file changed, 41 insertions(+), 17 deletions(-)
diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
index a3ae394..3fdb173 100644
--- a/sound/soc/codecs/tas2552.c
+++ b/sound/soc/codecs/tas2552.c
@@ -78,6 +78,40 @@ struct tas2552_data {
unsigned int mclk;
};
+
+static int tas2552_pll_disable(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol, int event)
+{
+ if (event == SND_SOC_DAPM_POST_PMD)
+ snd_soc_update_bits(w->codec, TAS2552_CFG_2,
TAS2552_PLL_ENABLE, 0);
+
+ return 0;
+}
+
+static int tas2552_class_d_en(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol, int event)
+{
+ switch (event) {
+ case SND_SOC_DAPM_PRE_PMU:
+ snd_soc_update_bits(w->codec, TAS2552_CFG_2,
+TAS2552_CLASSD_EN_MASK,
TAS2552_CLASSD_EN_MASK);
+ break;
+ case SND_SOC_DAPM_POST_PMD:
+ snd_soc_update_bits(w->codec, TAS2552_CFG_2,
+TAS2552_CLASSD_EN_MASK, 0);
+ break;
+ }
+
+ return 0;
+}
+
+static const struct snd_soc_dapm_widget tas2552_dapm_widgets[] =
+{
+SND_SOC_DAPM_PRE("Class D Enable", tas2552_class_d_en),
+SND_SOC_DAPM_POST("Class D Disable", tas2552_class_d_en),
+SND_SOC_DAPM_POST("PLL Disable", tas2552_pll_disable),
+};
+
static void tas2552_sw_shutdown(struct tas2552_data *tas_data, int sw_shutdown)
{
u8 cfg1_reg;
@@ -101,10 +135,6 @@ static int tas2552_hw_params(struct snd_pcm_substream
*substream,
int d;
u8 p, j;
- /* Turn on Class D amplifier */
- snd_soc_update_bits(codec, TAS2552_CFG_2, TAS2552_CLASSD_EN_MASK,
- TAS2552_CLASSD_EN);
-
if (!tas2552->mclk)
return -EINVAL;
@@ -149,7 +179,6 @@ static int tas2552_hw_params(struct snd_pcm_substream
*substream,
snd_soc_update_bits(codec, TAS2552_CFG_2, TAS2552_PLL_ENABLE,
TAS2552_PLL_ENABLE);
-
return 0;
}
@@ -269,19 +298,10 @@ static const struct dev_pm_ops tas2552_pm = {
NULL)
};
-static void tas2552_shutdown(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
-{
- struct snd_soc_codec *codec = dai->codec;
-
- snd_soc_update_bits(codec, TAS2552_CFG_2, TAS2552_PLL_ENABLE, 0);
-}
-
static struct snd_soc_dai_ops tas2552_speaker_dai_ops = {
.hw_params = tas2552_hw_params,
.set_sysclk = tas2552_set_dai_sysclk,
.set_fmt= tas2552_set_dai_fmt,
- .shutdown = tas2552_shutdown,
.digital_mute = tas2552_mute,
};
@@ -321,6 +341,7 @@ static const struct reg_default tas2552_init_regs[] = {
static int tas2552_codec_probe(struct snd_soc_codec *codec)
{
struct tas2552_data *tas2552 = snd_soc_codec_get_drvdata(codec);
+ struct snd_soc_dapm_context *dapm = >dapm;
int ret;
tas2552->codec = codec;
@@ -362,9 +383,12 @@ static int tas2552_codec_probe(struct snd_soc_codec *codec)
goto patch_fail;
}
- snd_soc_write(codec, TAS2552_CFG_2, TAS2552_CLASSD_EN |
- TAS2552_BOOST_EN | TAS2552_APT_EN |
- TAS2552_LIM_EN);
+ snd_soc_write(codec, TAS2552_CFG_2, TAS2552_BOOST_EN |
+ TAS2552_APT_EN | TAS2552_LIM_EN);
+
+ snd_soc_dapm_new_controls(dapm, tas2552_dapm_widgets,
+ ARRAY_SIZE(tas2552_dapm_widgets));
+
return 0;
patch_fail:
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ASoC: tas2552: Fix PM sequencing
In the pm suspend/resume it is better
to disable the GPIO after the regmap_cache
setting calls so that if the call is interrupted
the new reg values will be cached and set on resume.
Also add pm_runtime_put in the remove call.
Signed-off-by: Dan Murphy
---
sound/soc/codecs/tas2552.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
index f0760af..a3ae394 100644
--- a/sound/soc/codecs/tas2552.c
+++ b/sound/soc/codecs/tas2552.c
@@ -239,12 +239,12 @@ static int tas2552_runtime_suspend(struct device *dev)
tas2552_sw_shutdown(tas2552, 0);
- if (tas2552->enable_gpio)
- gpiod_set_value(tas2552->enable_gpio, 0);
-
regcache_cache_only(tas2552->regmap, true);
regcache_mark_dirty(tas2552->regmap);
+ if (tas2552->enable_gpio)
+ gpiod_set_value(tas2552->enable_gpio, 0);
+
return 0;
}
@@ -382,6 +382,8 @@ static int tas2552_codec_remove(struct snd_soc_codec *codec)
{
struct tas2552_data *tas2552 = snd_soc_codec_get_drvdata(codec);
+ pm_runtime_put(codec->dev);
+
if (tas2552->enable_gpio)
gpiod_set_value(tas2552->enable_gpio, 0);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[v2] input: drv260x: Add TI drv260x haptics driver
Add the TI drv260x haptics/vibrator driver.
This device uses the input force feedback
to produce a wave form to driver an
ERM or LRA actuator device.
The initial driver supports the devices
real time playback mode. But the device
has additional wave patterns in ROM.
This functionality will be added in
future patchsets.
Product data sheet is located here:
http://www.ti.com/product/drv2605
Signed-off-by: Dan Murphy
---
v2 - Fixed binding doc and patch headline -
https://patchwork.kernel.org/patch/4619641/
.../devicetree/bindings/input/ti,drv260x.txt | 44 ++
drivers/input/misc/Kconfig |9 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/drv260x.c | 537
include/dt-bindings/input/ti-drv260x.h | 30 ++
include/linux/input/drv260x.h | 181 +++
6 files changed, 802 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
create mode 100644 drivers/input/misc/drv260x.c
create mode 100644 include/dt-bindings/input/ti-drv260x.h
create mode 100644 include/linux/input/drv260x.h
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt
b/Documentation/devicetree/bindings/input/ti,drv260x.txt
new file mode 100644
index 000..930429b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
@@ -0,0 +1,44 @@
+Texas Instruments - drv260x Haptics driver family
+
+The drv260x family serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible - One of:
+ "ti,drv2604" - DRV2604
+ "ti,drv2605" - DRV2605
+ "ti,drv2605l" - DRV2605L
+ - reg - I2C slave address
+ - mode - Power up mode of the chip (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_RTP_MODE - Real time playback mode
+ DRV260X_LRA_MODE - Linear Resonance Actuator mode
(Piezoelectric)
+ DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary
vibrator)
+ - library_sel - Library to use at power up (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_LIB_A - Pre-programmed Library
+ DRV260X_LIB_B - Pre-programmed Library
+ DRV260X_LIB_C - Pre-programmed Library
+ DRV260X_LIB_D - Pre-programmed Library
+ DRV260X_LIB_E - Pre-programmed Library
+ DRV260X_LIB_F - Pre-programmed Library
+
+Optional properties:
+ - enable-gpio - gpio pin to enable/disable the device.
+ - vib_rated_voltage - The rated voltage of the actuator. If this is not
+ set then the value will be
defaulted to 0x90 in the
+ driver.
+ - vib_overdrive_voltage - The overdrive voltage of the actuator.
+ If this is not set then
the value
+ will be defaulted to
0x90 in the driver.
+Example:
+
+drv2605l: drv2605l@5a {
+ compatible = "ti,drv2605l";
+ reg = <0x5a>;
+ enable-gpio = < 28 GPIO_ACTIVE_HIGH>;
+ mode = ;
+ library_sel = ;
+ vib_rated_voltage = <3200>;
+ vib_overdriver_voltage = <3200>;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/drv2605
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 2ff4425..99f6762 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -676,4 +676,13 @@ config INPUT_SOC_BUTTON_ARRAY
To compile this driver as a module, choose M here: the
module will be called soc_button_array.
+config INPUT_DRV260X_HAPTICS
+ tristate "TI DRV260X haptics support"
+ depends on INPUT && I2C
+ help
+ Say Y to enable support for the TI DRV260X haptics driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called drv260x-haptics.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 4955ad3..d8ef3c7 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)+= xen-kbdfront.o
obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR) += ideapad_slidebar.o
+obj-$(CONFIG_INPUT_DRV260X_HAPTICS)+= drv260x.o
diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
new file mode 100644
index 000..aadfd57
--- /dev/null
+++ b/drivers/input/misc/drv260x.c
@@ -0,0 +1,537 @@
+/*
+ * drv260x.c - DRV260X haptics driver family
+ *
+ * Author: Dan
[Patch v3] input: drv260x: Add TI drv260x haptics driver
Add the TI drv260x haptics/vibrator driver.
This device uses the input force feedback
to produce a wave form to driver an
ERM or LRA actuator device.
The initial driver supports the devices
real time playback mode. But the device
has additional wave patterns in ROM.
This functionality will be added in
future patchsets.
Product data sheet is located here:
http://www.ti.com/product/drv2605
Signed-off-by: Dan Murphy
---
v3 - Updated binding doc, changed to memless device, updated input alloc to
devm, removed mutex locking, add sanity checks for mode and library -
https://patchwork.kernel.org/patch/4635421/
v2 - Fixed binding doc and patch headline -
https://patchwork.kernel.org/patch/4619641/
.../devicetree/bindings/input/ti,drv260x.txt | 50 ++
drivers/input/misc/Kconfig |9 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/drv260x.c | 515
include/dt-bindings/input/ti-drv260x.h | 30 ++
include/linux/input/drv260x.h | 181 +++
6 files changed, 786 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
create mode 100644 drivers/input/misc/drv260x.c
create mode 100644 include/dt-bindings/input/ti-drv260x.h
create mode 100644 include/linux/input/drv260x.h
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt
b/Documentation/devicetree/bindings/input/ti,drv260x.txt
new file mode 100644
index 000..8e6970d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
@@ -0,0 +1,50 @@
+Texas Instruments - drv260x Haptics driver family
+
+The drv260x family serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible - One of:
+ "ti,drv2604" - DRV2604
+ "ti,drv2605" - DRV2605
+ "ti,drv2605l" - DRV2605L
+ - reg - I2C slave address
+ - supply- Required supply regulators are:
+ "vbat" - battery voltage
+ - mode - Power up mode of the chip (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_LRA_MODE - Linear Resonance Actuator mode
(Piezoelectric)
+ DRV260X_LRA_NO_CAL_MODE - This is a LRA Mode but there is no
calibration
+ sequence during init. And the device is
configured for real
+ time playback mode (RTP mode).
+ DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary
vibrator)
+ - library-sel - These are ROM based waveforms pre-programmed into the
IC.
+ This should be set to set the library to use at
power up.
+ (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_LIB_A - Pre-programmed Library
+ DRV260X_LIB_B - Pre-programmed Library
+ DRV260X_LIB_C - Pre-programmed Library
+ DRV260X_LIB_D - Pre-programmed Library
+ DRV260X_LIB_E - Pre-programmed Library
+ DRV260X_LIB_F - Pre-programmed Library
+
+Optional properties:
+ - enable-gpio - gpio pin to enable/disable the device.
+ - vib_rated_voltage - The rated voltage of the actuator in millivolts.
+ If this is not set then the value will be defaulted to
+ 3.2 v.
+ - vib_overdrive_voltage - The overdrive voltage of the actuator in
millivolts.
+ If this is not set then the value will be defaulted to
+ 3.2 v.
+Example:
+
+drv2605l: drv2605l@5a {
+ compatible = "ti,drv2605l";
+ reg = <0x5a>;
+ enable-gpio = < 28 GPIO_ACTIVE_HIGH>;
+ mode = ;
+ library-sel = ;
+ vib-rated-voltage = <3200>;
+ vib-overdriver-voltage = <3200>;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/drv2605
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 2ff4425..99f6762 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -676,4 +676,13 @@ config INPUT_SOC_BUTTON_ARRAY
To compile this driver as a module, choose M here: the
module will be called soc_button_array.
+config INPUT_DRV260X_HAPTICS
+ tristate "TI DRV260X haptics support"
+ depends on INPUT && I2C
+ help
+ Say Y to enable support for the TI DRV260X haptics driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called drv260x-haptics.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 4955ad3..d8ef3c7 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_IN
[Patch v4] input: drv260x: Add TI drv260x haptics driver
Add the TI drv260x haptics/vibrator driver.
This device uses the input force feedback
to produce a wave form to driver an
ERM or LRA actuator device.
The initial driver supports the devices
real time playback mode. But the device
has additional wave patterns in ROM.
This functionality will be added in
future patchsets.
Product data sheet is located here:
http://www.ti.com/product/drv2605
Signed-off-by: Dan Murphy
---
v4 - Convert regulator to devm, added error checking where required,
updated bindings doc, moved dt parsing to separate call and made platform
data the first data point, moved vibrator enable and mode programming from
play entry to worker thread, added user check and input mutex in suspend/resume
calls, moved platform data to individual file and into include platform-data
directory,
removed file names from file headers -
https://patchwork.kernel.org/patch/4642221/
v3 - Updated binding doc, changed to memless device, updated input alloc to
devm, removed mutex locking, add sanity checks for mode and library -
https://patchwork.kernel.org/patch/4635421/
v2 - Fixed binding doc and patch headline -
https://patchwork.kernel.org/patch/4619641/
.../devicetree/bindings/input/ti,drv260x.txt | 50 ++
drivers/input/misc/Kconfig |9 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/drv260x.c | 563
include/dt-bindings/input/ti-drv260x.h | 35 ++
include/linux/input/drv260x.h | 173 ++
include/linux/platform_data/drv260x-pdata.h| 29 +
7 files changed, 860 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
create mode 100644 drivers/input/misc/drv260x.c
create mode 100644 include/dt-bindings/input/ti-drv260x.h
create mode 100644 include/linux/input/drv260x.h
create mode 100644 include/linux/platform_data/drv260x-pdata.h
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt
b/Documentation/devicetree/bindings/input/ti,drv260x.txt
new file mode 100644
index 000..8e6970d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
@@ -0,0 +1,50 @@
+Texas Instruments - drv260x Haptics driver family
+
+The drv260x family serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible - One of:
+ "ti,drv2604" - DRV2604
+ "ti,drv2605" - DRV2605
+ "ti,drv2605l" - DRV2605L
+ - reg - I2C slave address
+ - supply- Required supply regulators are:
+ "vbat" - battery voltage
+ - mode - Power up mode of the chip (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_LRA_MODE - Linear Resonance Actuator mode
(Piezoelectric)
+ DRV260X_LRA_NO_CAL_MODE - This is a LRA Mode but there is no
calibration
+ sequence during init. And the device is
configured for real
+ time playback mode (RTP mode).
+ DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary
vibrator)
+ - library-sel - These are ROM based waveforms pre-programmed into the
IC.
+ This should be set to set the library to use at
power up.
+ (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_LIB_A - Pre-programmed Library
+ DRV260X_LIB_B - Pre-programmed Library
+ DRV260X_LIB_C - Pre-programmed Library
+ DRV260X_LIB_D - Pre-programmed Library
+ DRV260X_LIB_E - Pre-programmed Library
+ DRV260X_LIB_F - Pre-programmed Library
+
+Optional properties:
+ - enable-gpio - gpio pin to enable/disable the device.
+ - vib_rated_voltage - The rated voltage of the actuator in millivolts.
+ If this is not set then the value will be defaulted to
+ 3.2 v.
+ - vib_overdrive_voltage - The overdrive voltage of the actuator in
millivolts.
+ If this is not set then the value will be defaulted to
+ 3.2 v.
+Example:
+
+drv2605l: drv2605l@5a {
+ compatible = "ti,drv2605l";
+ reg = <0x5a>;
+ enable-gpio = < 28 GPIO_ACTIVE_HIGH>;
+ mode = ;
+ library-sel = ;
+ vib-rated-voltage = <3200>;
+ vib-overdriver-voltage = <3200>;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/drv2605
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 2ff4425..99f6762 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -676,4 +676,13 @@ config INPUT_SOC_BUTTON_ARRAY
To compile this driver as a module, choo
[PATCH] input: drv260x: Introduce TI drv260x haptics driver
Add the TI drv260x haptics/vibrator driver.
This device uses the input force feedback
to produce a wave form to driver an
ERM or LRA actuator device.
The initial driver supports the devices
real time playback mode. But the device
has additional wave patterns in ROM.
This functionality will be added in
future patchsets.
Product data sheet is located here:
http://www.ti.com/product/drv2605
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/input/ti,drv260x.txt | 44 ++
drivers/input/misc/Kconfig |9 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/drv260x.c | 537
include/dt-bindings/input/ti-drv260x.h | 30 ++
include/linux/input/drv260x.h | 181 +++
6 files changed, 802 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
create mode 100644 drivers/input/misc/drv260x.c
create mode 100644 include/dt-bindings/input/ti-drv260x.h
create mode 100644 include/linux/input/drv260x.h
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt
b/Documentation/devicetree/bindings/input/ti,drv260x.txt
new file mode 100644
index 000..0860661
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
@@ -0,0 +1,44 @@
+Texas Instruments - drv260x Haptics driver family
+
+The drv260x family serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible - One of:
+ "ti,drv2604" - DRV2604
+ "ti,drv2605" - DRV2605
+ "ti,drv2605l" - DRV2605L
+ - reg - I2C slave address
+ - mode - Power up mode of the chip (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_RTP_MODE - Real time playback mode
+ DRV260X_LRA_MODE - Linear Resonance Actuator mode
(Piezoelectric)
+ DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary
vibrator)
+ - library_sel - Library to use at power up (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_LIB_A - Pre-programmed Library
+ DRV260X_LIB_B - Pre-programmed Library
+ DRV260X_LIB_C - Pre-programmed Library
+ DRV260X_LIB_D - Pre-programmed Library
+ DRV260X_LIB_E - Pre-programmed Library
+ DRV260X_LIB_F - Pre-programmed Library
+
+Optional properties:
+ - enable-gpio - gpio pin to enable/disable the device.
+ - vib_rated_voltage - The rated voltage of the actuator. If this is not
+ set then the value will be
defaulted to 0x90 in the
+ driver.
+ - vib_overdrive_voltage - The overdrive voltage of the actuator.
+ If this is not set then
the value
+ will be defaulted to
0x90 in the driver.
+Example:
+
+drv2605l: drv2605l@41 {
+ compatible = "ti,drv2605l";
+ reg = <0x5a>;
+ enable-gpio = < 28 GPIO_ACTIVE_HIGH>; /* GPIO 60 */
+ mode = ;
+ library_sel = ;
+ vib_rated_voltage = <3200>;
+ vib_overdriver_voltage = <3200>;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/drv2605
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 2ff4425..99f6762 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -676,4 +676,13 @@ config INPUT_SOC_BUTTON_ARRAY
To compile this driver as a module, choose M here: the
module will be called soc_button_array.
+config INPUT_DRV260X_HAPTICS
+ tristate "TI DRV260X haptics support"
+ depends on INPUT && I2C
+ help
+ Say Y to enable support for the TI DRV260X haptics driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called drv260x-haptics.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 4955ad3..d8ef3c7 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)+= xen-kbdfront.o
obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR) += ideapad_slidebar.o
+obj-$(CONFIG_INPUT_DRV260X_HAPTICS)+= drv260x.o
diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
new file mode 100644
index 000..aadfd57
--- /dev/null
+++ b/drivers/input/misc/drv260x.c
@@ -0,0 +1,537 @@
+/*
+ * drv260x.c - DRV260X haptics driver family
+ *
+ * Author: Dan Murphy
+ *
+ * Copyright: (C) 2014 Texas Instruments, Inc.
+ *
+ *
[PATCH v5] input: drv260x: Add TI drv260x haptics driver
Add the TI drv260x haptics/vibrator driver.
This device uses the input force feedback
to produce a wave form to driver an
ERM or LRA actuator device.
The initial driver supports the devices
real time playback mode. But the device
has additional wave patterns in ROM.
This functionality will be added in
future patchsets.
Product data sheet is located here:
http://www.ti.com/product/drv2605
Signed-off-by: Dan Murphy
---
v5 - Move register defines to c file and rm header file, error check
init in probe, fixed identation, remove empty labels in probe
and just return on fail and removed the remove callback and function.
Did not factor out the suspend into a stop function. -
https://patchwork.kernel.org/patch/4649631/
v4 - Convert regulator to devm, added error checking where required,
updated bindings doc, moved dt parsing to separate call and made platform
data the first data point, moved vibrator enable and mode programming from
play entry to worker thread, added user check and input mutex in suspend/resume
calls, moved platform data to individual file and into include platform-data
directory,
removed file names from file headers -
https://patchwork.kernel.org/patch/4642221/
v3 - Updated binding doc, changed to memless device, updated input alloc to
devm, removed mutex locking, add sanity checks for mode and library -
https://patchwork.kernel.org/patch/4635421/
v2 - Fixed binding doc and patch headline -
https://patchwork.kernel.org/patch/4619641/
.../devicetree/bindings/input/ti,drv260x.txt | 50 ++
drivers/input/misc/Kconfig |9 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/drv260x.c | 697
include/dt-bindings/input/ti-drv260x.h | 35 +
include/linux/platform_data/drv260x-pdata.h| 29 +
6 files changed, 821 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
create mode 100644 drivers/input/misc/drv260x.c
create mode 100644 include/dt-bindings/input/ti-drv260x.h
create mode 100644 include/linux/platform_data/drv260x-pdata.h
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt
b/Documentation/devicetree/bindings/input/ti,drv260x.txt
new file mode 100644
index 000..8e6970d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
@@ -0,0 +1,50 @@
+Texas Instruments - drv260x Haptics driver family
+
+The drv260x family serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible - One of:
+ "ti,drv2604" - DRV2604
+ "ti,drv2605" - DRV2605
+ "ti,drv2605l" - DRV2605L
+ - reg - I2C slave address
+ - supply- Required supply regulators are:
+ "vbat" - battery voltage
+ - mode - Power up mode of the chip (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_LRA_MODE - Linear Resonance Actuator mode
(Piezoelectric)
+ DRV260X_LRA_NO_CAL_MODE - This is a LRA Mode but there is no
calibration
+ sequence during init. And the device is
configured for real
+ time playback mode (RTP mode).
+ DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary
vibrator)
+ - library-sel - These are ROM based waveforms pre-programmed into the
IC.
+ This should be set to set the library to use at
power up.
+ (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_LIB_A - Pre-programmed Library
+ DRV260X_LIB_B - Pre-programmed Library
+ DRV260X_LIB_C - Pre-programmed Library
+ DRV260X_LIB_D - Pre-programmed Library
+ DRV260X_LIB_E - Pre-programmed Library
+ DRV260X_LIB_F - Pre-programmed Library
+
+Optional properties:
+ - enable-gpio - gpio pin to enable/disable the device.
+ - vib_rated_voltage - The rated voltage of the actuator in millivolts.
+ If this is not set then the value will be defaulted to
+ 3.2 v.
+ - vib_overdrive_voltage - The overdrive voltage of the actuator in
millivolts.
+ If this is not set then the value will be defaulted to
+ 3.2 v.
+Example:
+
+drv2605l: drv2605l@5a {
+ compatible = "ti,drv2605l";
+ reg = <0x5a>;
+ enable-gpio = < 28 GPIO_ACTIVE_HIGH>;
+ mode = ;
+ library-sel = ;
+ vib-rated-voltage = <3200>;
+ vib-overdriver-voltage = <3200>;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/drv2605
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 2ff4425..99f676
[PATCH v2] ASoC: tas2552: Add DAPM calls for amp and PLL
Add DAPM calls to enable/disable the Class D amp.
Also add a DAPM call to turn off the PLL upon
the stream completing.
Signed-off-by: Dan Murphy
---
v2 - Added proper audio routing map for ClassD and PLL enable/disable -
https://patchwork.kernel.org/patch/4586831/
sound/soc/codecs/tas2552.c | 68 +++-
1 file changed, 48 insertions(+), 20 deletions(-)
diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
index 23b3296..1ed57a7 100644
--- a/sound/soc/codecs/tas2552.c
+++ b/sound/soc/codecs/tas2552.c
@@ -78,6 +78,43 @@ struct tas2552_data {
unsigned int mclk;
};
+/* Input mux controls */
+static const char *tas2552_input_texts[] = {
+ "Digital", "Analog"
+};
+
+static SOC_ENUM_SINGLE_DECL(tas2552_input_mux_enum, TAS2552_CFG_3, 7,
+ tas2552_input_texts);
+
+static const struct snd_kcontrol_new tas2552_input_mux_control[] = {
+ SOC_DAPM_ENUM("Input selection", tas2552_input_mux_enum)
+};
+
+static const struct snd_soc_dapm_widget tas2552_dapm_widgets[] =
+{
+ SND_SOC_DAPM_INPUT("IN"),
+
+ /* MUX Controls */
+ SND_SOC_DAPM_MUX("Input selection", SND_SOC_NOPM, 0, 0,
+ tas2552_input_mux_control),
+
+ SND_SOC_DAPM_AIF_IN("DAC IN", "DAC Playback", 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_DAC("DAC", NULL, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_OUT_DRV("ClassD", TAS2552_CFG_2, 7, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("PLL", TAS2552_CFG_2, 3, 0, NULL, 0),
+
+ SND_SOC_DAPM_OUTPUT("OUT")
+};
+
+static const struct snd_soc_dapm_route tas2552_audio_map[] = {
+ {"DAC", NULL, "DAC IN"},
+ {"Input selection", "Digital", "DAC"},
+ {"Input selection", "Analog", "IN"},
+ {"ClassD", NULL, "Input selection"},
+ {"OUT", NULL, "ClassD"},
+ {"ClassD", NULL, "PLL"},
+};
+
static void tas2552_sw_shutdown(struct tas2552_data *tas_data, int sw_shutdown)
{
u8 cfg1_reg;
@@ -101,10 +138,6 @@ static int tas2552_hw_params(struct snd_pcm_substream
*substream,
int d;
u8 p, j;
- /* Turn on Class D amplifier */
- snd_soc_update_bits(codec, TAS2552_CFG_2, TAS2552_CLASSD_EN_MASK,
- TAS2552_CLASSD_EN);
-
if (!tas2552->mclk)
return -EINVAL;
@@ -147,9 +180,6 @@ static int tas2552_hw_params(struct snd_pcm_substream
*substream,
}
- snd_soc_update_bits(codec, TAS2552_CFG_2, TAS2552_PLL_ENABLE,
- TAS2552_PLL_ENABLE);
-
return 0;
}
@@ -269,19 +299,10 @@ static const struct dev_pm_ops tas2552_pm = {
NULL)
};
-static void tas2552_shutdown(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
-{
- struct snd_soc_codec *codec = dai->codec;
-
- snd_soc_update_bits(codec, TAS2552_CFG_2, TAS2552_PLL_ENABLE, 0);
-}
-
static struct snd_soc_dai_ops tas2552_speaker_dai_ops = {
.hw_params = tas2552_hw_params,
.set_sysclk = tas2552_set_dai_sysclk,
.set_fmt= tas2552_set_dai_fmt,
- .shutdown = tas2552_shutdown,
.digital_mute = tas2552_mute,
};
@@ -294,7 +315,7 @@ static struct snd_soc_dai_driver tas2552_dai[] = {
{
.name = "tas2552-amplifier",
.playback = {
- .stream_name = "Speaker",
+ .stream_name = "Playback",
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_192000,
@@ -312,6 +333,7 @@ static DECLARE_TLV_DB_SCALE(dac_tlv, -7, 100, 24);
static const struct snd_kcontrol_new tas2552_snd_controls[] = {
SOC_SINGLE_TLV("Speaker Driver Playback Volume",
TAS2552_PGA_GAIN, 0, 0x1f, 1, dac_tlv),
+ SOC_DAPM_SINGLE("Playback AMP", SND_SOC_NOPM, 0, 1, 0),
};
static const struct reg_default tas2552_init_regs[] = {
@@ -321,6 +343,7 @@ static const struct reg_default tas2552_init_regs[] = {
static int tas2552_codec_probe(struct snd_soc_codec *codec)
{
struct tas2552_data *tas2552 = snd_soc_codec_get_drvdata(codec);
+ struct snd_soc_dapm_context *dapm = >dapm;
int ret;
tas2552->codec = codec;
@@ -362,9 +385,14 @@ static int tas2552_codec_probe(struct snd_soc_codec *codec)
goto patch_fail;
}
- snd_soc_write(codec, TAS2552_CFG_2, TAS2552_CLASSD_EN |
- TAS2552_BOOST_EN | TAS2552_APT_EN |
- TAS
[PATCH 1/2] doc: dt/bindings: input: introduce TI DRV2667 haptic driver description
DRV2667 is a haptic/vibrator driver for Linear Resonant Actuators.
Adding dt binding for this part
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/input/ti,drv2667.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,drv2667.txt
diff --git a/Documentation/devicetree/bindings/input/ti,drv2667.txt
b/Documentation/devicetree/bindings/input/ti,drv2667.txt
new file mode 100644
index 000..525216d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv2667.txt
@@ -0,0 +1,18 @@
+Texas Instruments - drv2667 Haptics driver
+
+The drv2667 uses serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible - "ti,drv2667" - DRV2667
+ - reg - I2C slave address
+ - vbat-supply - Required supply regulator
+
+Example:
+
+drv2667: drv2667@59 {
+ compatible = "ti,drv2667";
+ reg = <0x59>;
+};
+
+For more product information please see the link below:
+http://www.ti.com/product/drv2667
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
input: drv2667: add support for drv2667 haptic driver
Adding support for the TI DRV2667 haptic driver. This device driver a linear resonant actuator (LRA) based on user space requests to provide either a vibration or a haptic tactile response to an input. This device has the ability to store wave patterns in RAM and these patterns can be executed based on user input. For this initial series I added just the basic vibration pattern along that will continuously execute until the user indicates to stop. [PATCH 1/2] doc: dt/bindings: input: introduce TI DRV2667 haptic [PATCH 2/2] input: misc: Add support for the DRV2667 haptic driver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] input: misc: Add support for the DRV2667 haptic driver
Adding support for the DRV2667 haptic driver. This device has the ability to store vibration patterns in RAM and execute them once the GO bit is set. The initial driver sets a basic waveform in the first waveform sequence and will play the waveform when the GO bit is set and will continously play the waveform until the GO bit is unset. Data sheet is here: http://www.ti.com/product/drv2667 Signed-off-by: Dan Murphy --- drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile |1 + drivers/input/misc/drv2667.c | 500 ++ 3 files changed, 512 insertions(+) create mode 100644 drivers/input/misc/drv2667.c diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 41d0ae6..51891f6 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -687,4 +687,15 @@ config INPUT_DRV260X_HAPTICS To compile this driver as a module, choose M here: the module will be called drv260x-haptics. +config INPUT_DRV2667_HAPTICS + tristate "TI DRV2667 haptics support" + depends on INPUT && I2C + select INPUT_FF_MEMLESS + select REGMAP_I2C + help + Say Y to enable support for the TI DRV2667 haptics driver. + + To compile this driver as a module, choose M here: the + module will be called drv260x-haptics. + endif diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index cd4bc2d..e0cee17 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_INPUT_DA9052_ONKEY) += da9052_onkey.o obj-$(CONFIG_INPUT_DA9055_ONKEY) += da9055_onkey.o obj-$(CONFIG_INPUT_DM355EVM) += dm355evm_keys.o obj-$(CONFIG_INPUT_DRV260X_HAPTICS)+= drv260x.o +obj-$(CONFIG_INPUT_DRV2667_HAPTICS)+= drv2667.o obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o obj-$(CONFIG_INPUT_GPIO_BEEPER)+= gpio-beeper.o obj-$(CONFIG_INPUT_GPIO_TILT_POLLED) += gpio_tilt_polled.o diff --git a/drivers/input/misc/drv2667.c b/drivers/input/misc/drv2667.c new file mode 100644 index 000..0f43758 --- /dev/null +++ b/drivers/input/misc/drv2667.c @@ -0,0 +1,500 @@ +/* + * DRV2667 haptics driver family + * + * Author: Dan Murphy + * + * Copyright: (C) 2014 Texas Instruments, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +/* Contol registers */ +#define DRV2667_STATUS 0x00 +#define DRV2667_CTRL_1 0x01 +#define DRV2667_CTRL_2 0x02 +/* Waveform sequencer */ +#define DRV2667_WV_SEQ_0 0x03 +#define DRV2667_WV_SEQ_1 0x04 +#define DRV2667_WV_SEQ_2 0x05 +#define DRV2667_WV_SEQ_3 0x06 +#define DRV2667_WV_SEQ_4 0x07 +#define DRV2667_WV_SEQ_5 0x08 +#define DRV2667_WV_SEQ_6 0x09 +#define DRV2667_WV_SEQ_7 0x0A +#define DRV2667_FIFO 0x0B +#define DRV2667_PAGE 0xFF +#define DRV2667_MAX_REGDRV2667_PAGE + +#define DRV2667_PAGE_0 0x00 +#define DRV2667_PAGE_1 0x01 +#define DRV2667_PAGE_2 0x02 +#define DRV2667_PAGE_3 0x03 +#define DRV2667_PAGE_4 0x04 +#define DRV2667_PAGE_5 0x05 +#define DRV2667_PAGE_6 0x06 +#define DRV2667_PAGE_7 0x07 +#define DRV2667_PAGE_8 0x08 + +/* RAM fields */ +#define DRV2667_RAM_HDR_SZ 0x0 +/* RAM Header addresses */ +#define DRV2667_RAM_START_HI 0x01 +#define DRV2667_RAM_START_LO 0x02 +#define DRV2667_RAM_STOP_HI0x03 +#define DRV2667_RAM_STOP_LO0x04 +#define DRV2667_RAM_REPEAT_CT 0x05 +/* RAM data addresses */ +#define DRV2667_RAM_AMP0x06 +#define DRV2667_RAM_FREQ 0x07 +#define DRV2667_RAM_DURATION 0x08 +#define DRV2667_RAM_ENVELOPE 0x09 + +/* Control 1 Register */ +#define DRV2667_25_VPP_GAIN0x00 +#define DRV2667_50_VPP_GAIN0x01 +#define DRV2667_75_VPP_GAIN0x02 +#define DRV2667_100_VPP_GAIN 0x03 +#define DRV2667_DIGITAL_IN 0xfc +#define DRV2667_ANALOG_IN (1 << 2) + +/* Control 2 Register */ +#define DRV2667_GO (1 << 0) +#define DRV2667_STANDBY(1 << 6) +#define DRV2667_DEV_RST(1 << 7) + +/* RAM Envelope settings */ +#define DRV2667_NO_ENV 0x00 +#define DRV2667_32_MS_ENV 0x01 +#define DRV2667_64_MS_ENV 0x02 +#define DRV2667_96_MS_ENV 0x03 +#define DRV2667_128_MS_ENV
[PATCH] doc: dt/bindings: input: Fix drv260x binding document
Update the drv260x dt binding document:
- Change the node name to the devices function not the
device name.
- Add vbat-supply to the example.
- Fix indentation of the example.
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/input/ti,drv260x.txt | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt
b/Documentation/devicetree/bindings/input/ti,drv260x.txt
index a9c8519..214e25d 100644
--- a/Documentation/devicetree/bindings/input/ti,drv260x.txt
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
@@ -37,15 +37,16 @@ Optional properties:
3.2 v.
Example:
-drv2605l: drv2605l@5a {
- compatible = "ti,drv2605l";
- reg = <0x5a>;
- enable-gpio = < 28 GPIO_ACTIVE_HIGH>;
- mode = ;
- library-sel = ;
- vib-rated-mv = <3200>;
- vib-overdriver-mv = <3200>;
-};
+haptics:@5a {
+ compatible = "ti,drv2605l";
+ reg = <0x5a>;
+ vbat-supply = <>;
+ enable-gpio = < 28 GPIO_ACTIVE_HIGH>;
+ mode = ;
+ library-sel = ;
+ vib-rated-mv = <3200>;
+ vib-overdriver-mv = <3200>;
+}
For more product information please see the link below:
http://www.ti.com/product/drv2605
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] input: misc: drv260x: add check for ERM mode and LRA Libraries
Add a check to ensure that LRA libraries are not mixed with
the ERM mode.
If ERM mode and the Library is empty "OR" the
LRA library then exit.
As the LRA and empty libraries are not applicable for
the ERM actuator.
Signed-off-by: Dan Murphy
---
drivers/input/misc/drv260x.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index a7a19e6..d6a26a7 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -564,6 +564,14 @@ static int drv260x_probe(struct i2c_client *client,
return -EINVAL;
}
+ if (haptics->mode == DRV260X_ERM_MODE &&
+ haptics->library == DRV260X_LIB_EMPTY ||
+ haptics->library == DRV260X_LIB_LRA) {
+ dev_err(>dev,
+ "ERM Mode with LRA Library mismatch\n");
+ return -EINVAL;
+ }
+
haptics->regulator = devm_regulator_get(>dev, "vbat");
if (IS_ERR(haptics->regulator)) {
error = PTR_ERR(haptics->regulator);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] input: misc: drv260x remove defines not used
Removing some #defines that are not and should never be used pertaining to I2C. Removing: define DRV260X_ALLOWED_R_BYTES 25 define DRV260X_ALLOWED_W_BYTES 2 define DRV260X_MAX_RW_RETRIES 5 define DRV260X_I2C_RETRY_DELAY 10 Signed-off-by: Dan Murphy --- drivers/input/misc/drv260x.c |5 - 1 file changed, 5 deletions(-) diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c index e90e3b8..a7a19e6 100644 --- a/drivers/input/misc/drv260x.c +++ b/drivers/input/misc/drv260x.c @@ -66,11 +66,6 @@ #define DRV260X_LRA_RES_PERIOD 0x22 #define DRV260X_MAX_REG0x23 -#define DRV260X_ALLOWED_R_BYTES25 -#define DRV260X_ALLOWED_W_BYTES2 -#define DRV260X_MAX_RW_RETRIES 5 -#define DRV260X_I2C_RETRY_DELAY 10 - #define DRV260X_GO_BIT 0x01 /* Library Selection */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] doc: dt/bindings: input: Fix drv260x binding document
Update the drv260x dt binding document:
- Change the node name to the devices function not the
device name.
- Add vbat-supply to the example.
- Fix indentation of the example.
Signed-off-by: Dan Murphy
---
v2 - Address comments on indentation, node declaration, add vbat-supply,
removed description as it did not make sense -
https://patchwork.kernel.org/patch/4765141/
.../devicetree/bindings/input/ti,drv260x.txt | 23 ++--
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt
b/Documentation/devicetree/bindings/input/ti,drv260x.txt
index a9c8519..ee09c8f 100644
--- a/Documentation/devicetree/bindings/input/ti,drv260x.txt
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
@@ -1,6 +1,4 @@
-Texas Instruments - drv260x Haptics driver family
-
-The drv260x family serial control bus communicates through I2C protocols
+* Texas Instruments - drv260x Haptics driver family
Required properties:
- compatible - One of:
@@ -37,15 +35,16 @@ Optional properties:
3.2 v.
Example:
-drv2605l: drv2605l@5a {
- compatible = "ti,drv2605l";
- reg = <0x5a>;
- enable-gpio = < 28 GPIO_ACTIVE_HIGH>;
- mode = ;
- library-sel = ;
- vib-rated-mv = <3200>;
- vib-overdriver-mv = <3200>;
-};
+haptics: haptics@5a {
+ compatible = "ti,drv2605l";
+ reg = <0x5a>;
+ vbat-supply = <>;
+ enable-gpio = < 28 GPIO_ACTIVE_HIGH>;
+ mode = ;
+ library-sel = ;
+ vib-rated-mv = <3200>;
+ vib-overdriver-mv = <3200>;
+}
For more product information please see the link below:
http://www.ti.com/product/drv2605
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6] input: drv260x: Add TI drv260x haptics driver
Add the TI drv260x haptics/vibrator driver.
This device uses the input force feedback
to produce a wave form to driver an
ERM or LRA actuator device.
The initial driver supports the devices
real time playback mode. But the device
has additional wave patterns in ROM.
This functionality will be added in
future patchsets.
Product data sheet is located here:
http://www.ti.com/product/drv2605
Signed-off-by: Dan Murphy
---
v6 - Updated bindings doc to reflect correct pre-programmed library,
updated the vib-overdrive and rated voltage to add -mv, removed _ from
the same, add check to verify LRA libraries are only used in LRA mode,
and finally changed supply -> vbat-supply in binding doc -
https://patchwork.kernel.org/patch/4658661/
v5 - Move register defines to c file and rm header file, error check
init in probe, fixed identation, remove empty labels in probe
and just return on fail and removed the remove callback and function.
Did not factor out the suspend into a stop function. -
https://patchwork.kernel.org/patch/4649631/
v4 - Convert regulator to devm, added error checking where required,
updated bindings doc, moved dt parsing to separate call and made platform
data the first data point, moved vibrator enable and mode programming from
play entry to worker thread, added user check and input mutex in suspend/resume
calls, moved platform data to individual file and into include platform-data
directory,
removed file names from file headers -
https://patchwork.kernel.org/patch/4642221/
v3 - Updated binding doc, changed to memless device, updated input alloc to
devm, removed mutex locking, add sanity checks for mode and library -
https://patchwork.kernel.org/patch/4635421/
v2 - Fixed binding doc and patch headline -
https://patchwork.kernel.org/patch/4619641/
.../devicetree/bindings/input/ti,drv260x.txt | 51 ++
drivers/input/misc/Kconfig |9 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/drv260x.c | 704
include/dt-bindings/input/ti-drv260x.h | 36 +
include/linux/platform_data/drv260x-pdata.h| 29 +
6 files changed, 830 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
create mode 100644 drivers/input/misc/drv260x.c
create mode 100644 include/dt-bindings/input/ti-drv260x.h
create mode 100644 include/linux/platform_data/drv260x-pdata.h
diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt
b/Documentation/devicetree/bindings/input/ti,drv260x.txt
new file mode 100644
index 000..d54be15
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
@@ -0,0 +1,51 @@
+Texas Instruments - drv260x Haptics driver family
+
+The drv260x family serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible - One of:
+ "ti,drv2604" - DRV2604
+ "ti,drv2605" - DRV2605
+ "ti,drv2605l" - DRV2605L
+ - reg - I2C slave address
+ - vbat-supply- Required supply regulator
+ - mode - Power up mode of the chip (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_LRA_MODE - Linear Resonance Actuator mode
(Piezoelectric)
+ DRV260X_LRA_NO_CAL_MODE - This is a LRA Mode but there is no
calibration
+ sequence during init. And the device is
configured for real
+ time playback mode (RTP mode).
+ DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary
vibrator)
+ - library-sel - These are ROM based waveforms pre-programmed into the
IC.
+ This should be set to set the library to use at
power up.
+ (defined in
include/dt-bindings/input/ti-drv260x.h)
+ DRV260X_LIB_EMPTY - Do not use a pre-programmed library
+ DRV260X_ERM_LIB_A - Pre-programmed Library
+ DRV260X_ERM_LIB_B - Pre-programmed Library
+ DRV260X_ERM_LIB_C - Pre-programmed Library
+ DRV260X_ERM_LIB_D - Pre-programmed Library
+ DRV260X_ERM_LIB_E - Pre-programmed Library
+ DRV260X_ERM_LIB_F - Pre-programmed Library
+ DRV260X_LIB_LRA - Pre-programmed LRA Library
+
+Optional properties:
+ - enable-gpio - gpio pin to enable/disable the device.
+ - vib-rated-mv - The rated voltage of the actuator in millivolts.
+ If this is not set then the value will be defaulted to
+ 3.2 v.
+ - vib-overdrive-mv - The overdrive voltage of the actuator in
millivolts.
+ If this is not set then the value will be defaulted to
+ 3.2 v.
+Example:
+
+drv2605l: drv2605l@5a {
+ compatible = "ti,drv2605l";
+ reg =
Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Jacek
On 05/11/2018 06:56 AM, Dan Murphy wrote:
>>> + }
>>> +
>>> + if (led->strobe_node) {
>>> + ret = of_property_read_string(led->strobe_node, "label", );
>>> + if (!ret)
>>> + snprintf(led->strobe, sizeof(led->strobe),
>>> + "%s:%s", led->strobe_node->name, name);
>>> + else
>>> + snprintf(led->strobe, sizeof(led->strobe),
>>> + "%s::strobe", led->strobe_node->name);
>>> +
>>> + ret = of_property_read_u32(led->strobe_node,
>>> + "flash-max-microamp",
>>> + >strobe_current_max);
>>> + if (ret < 0) {
>>> + led->strobe_current_max = LM3601X_MIN_STROBE_I_MA;
>>> + dev_warn(>client->dev,
>>> + "flash-max-microamp DT property missing\n");
>>> + }
>>> +
>>> + ret = of_property_read_u32(led->strobe_node,
>>> + "flash-max-timeout-us",
>>> + >max_strobe_timeout);
>>> + if (ret < 0) {
>>> + led->max_strobe_timeout = strobe_timeouts[0].reg_val;
>>> + dev_warn(>client->dev,
>>> + "flash-max-timeout-us DT property missing\n");
>>> + }
>>
>> Common LED bindings state that flash-max-microamp and
>> flash-max-timeout-us properties are mandatory.
>
> OK.
OK I looked at the max776973 driver and well if the flash-max-microamp and
flash-max-timeout-us nodes are missing it sets a default value for each if the
node is not present.
So should we remove this code from the Max77693 driver too and fail probe as
being asked
in this driver?
Dan
>
>>
>>> +
>>> + lm3601x_init_flash_timeout(led);
>>>
>>
>
>
--
--
Dan Murphy
Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
Jacek
On 05/11/2018 03:27 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 05/11/2018 02:12 PM, Dan Murphy wrote:
>> Jacek
>>
>> Thanks for the review
>>
>> On 05/10/2018 03:17 PM, Jacek Anaszewski wrote:
>>> Hi Dan,
>>>
>>> On 05/10/2018 09:10 PM, Dan Murphy wrote:
>>>> On 05/10/2018 02:06 PM, Dan Murphy wrote:
>>>>> Pavel
>>>>>
>>>>> On 05/10/2018 01:54 PM, Pavel Machek wrote:
>>>>>> Hi!
>>>>>>
>>>>>>> Introduce the device tree bindings for the lm3601x
>>>>>>> family of LED torch, flash and IR drivers.
>>>>>>>
>>>>>>> Signed-off-by: Dan Murphy
>>>>>>
>>>>>> Better, thanks.
>>>>>>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>>>>>>> @@ -0,0 +1,50 @@
>>>>>>> +* Texas Instruments - lm3601x Single-LED Flash Driver
>>>>>>
>>>>>> Ok, so is it single-LED driver, or can it driver ir & white LEDs at
>>>>>> the same time?
>>>>>
>>>>> It is a single LED driver. It can drive a Torch white LED or IR LED
>>>>> indefinitely or if the driver
>>>>> is programmed to strobe mode the driver will drive the configured LED for
>>>>> the flash timeout specified.
>>>>>
>>>>> Basically a flash and a flash light. IR or White LED.
>>>>>
>>>>>
>>>>>>
>>>>>>> +Example:
>>>>>>> +led-controller@64 {
>>>>>>> + compatible = "ti,lm36010";
>>>>>>> + #address-cells = <1>;
>>>>>>> + #size-cells = <0>;
>>>>>>> + reg = <0x64>;
>>>>>>> +
>>>>>>> + led@0 {
>>>>>>> + reg = <0>;
>>>>>>> + label = "white:torch";
>>>>>>> + led-max-microamp = <1>;
>>>>>>> + };
>>>>>>> +
>>>>>>> + led@1 {
>>>>>>> + reg = <1>;
>>>>>>> + label = "white:flash";
>>>>>>> + flash-max-microamp = <1>;
>>>>>>> + flash-max-timeout-us = <800>;
>>>>>>> + };
>>>>>>
>>>>>> Is this realistic config? I'd expect flash to use more power than
>>>>>> torch, and would expect longer timeout than 0.8msec.
>>>>>
>>>>> Timeout in the spreadsheet is ms I will update this example and code
>>>>> Current in the spreadsheet is mA I will update this example and code
>>>>>
>>>>>>
>>>>>> Also.. if this is physically one white LED, it should not be
>>>>>> spread over reg = <0> and reg = <1>...
>>>>>
>>>>> If the torch LED and strobe LED are the same LED how do I expose them
>>>>> both to the user.
>>>>> It is up to consumer to configure the required interfaces they want to
>>>>> expose to the filesystem.
>>>
>>> LED flash class interface is prepared for it.
>>> led_clasdev_flash_register() internally calls led_classdev_register(),
>>> so there is brightness file available for torch related operations.
>>
>> Yes the flash class may handle this and expose the brightness node but the
>> HW has two different registers to set the
>> corresponding brightness so one set brightness node does not work.
>> There is no way to differentiate between the strobe brightness (register 4)
>> and the torch brightness (register 3).
>
> Hmm? There is brightness file (with brightness_set{_blocking} op) from
> LED class and flash_brightness file (with flash_brightness_set op) from
> LED class flash.
>
> I've only now realized that you're not using flash_brightness_set op for
> the "strobe_node" in your driver. I assume that you overlooked it.
> Please don't introduce "strobe_brightness" naming convention - we
> already have "flash_brightness" for that.
>
>> When the enable register is written the driver will read the corresponding
>> register and set
>> the current for the LED.
>>
>> This is why I separated out the strobe from the torch into 2 different LED
>> nodes.
>>
>> I ca
Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver
On 05/14/2018 03:05 PM, Jacek Anaszewski wrote:
> Hi Dan,
>
> On 05/14/2018 09:40 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 05/11/2018 06:56 AM, Dan Murphy wrote:
>>
>>
>>>>> + }
>>>>> +
>>>>> + if (led->strobe_node) {
>>>>> + ret = of_property_read_string(led->strobe_node, "label", );
>>>>> + if (!ret)
>>>>> + snprintf(led->strobe, sizeof(led->strobe),
>>>>> + "%s:%s", led->strobe_node->name, name);
>>>>> + else
>>>>> + snprintf(led->strobe, sizeof(led->strobe),
>>>>> + "%s::strobe", led->strobe_node->name);
>>>>> +
>>>>> + ret = of_property_read_u32(led->strobe_node,
>>>>> + "flash-max-microamp",
>>>>> + >strobe_current_max);
>>>>> + if (ret < 0) {
>>>>> + led->strobe_current_max = LM3601X_MIN_STROBE_I_MA;
>>>>> + dev_warn(>client->dev,
>>>>> + "flash-max-microamp DT property missing\n");
>>>>> + }
>>>>> +
>>>>> + ret = of_property_read_u32(led->strobe_node,
>>>>> + "flash-max-timeout-us",
>>>>> + >max_strobe_timeout);
>>>>> + if (ret < 0) {
>>>>> + led->max_strobe_timeout = strobe_timeouts[0].reg_val;
>>>>> + dev_warn(>client->dev,
>>>>> + "flash-max-timeout-us DT property missing\n");
>>>>> + }
>>>>
>>>> Common LED bindings state that flash-max-microamp and
>>>> flash-max-timeout-us properties are mandatory.
>>>
>>> OK.
>>
>> OK I looked at the max776973 driver and well if the flash-max-microamp and
>> flash-max-timeout-us nodes are missing it sets a default value for each if
>> the
>> node is not present.
>
> Ah, yes, this driver was being introduced as the first LED flash class driver
> and we were being iteratively adjusting LED common bindings
> according to the new findings, so some details could have been left
> out of sync.
>
>> So should we remove this code from the Max77693 driver too and fail probe as
>> being asked
>> in this driver?
>
> Yes, that would match what the bindings require.
Did you want me to remove it and submit? I don't have a board to verify but I
can definitely test out the probe and parse dt functionality.
Don't need HW for that.
Dan
>
--
--
Dan Murphy
Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Pavel On 05/14/2018 03:05 PM, Pavel Machek wrote: > Hi! > >>> OK. >> >> OK I looked at the max776973 driver and well if the flash-max-microamp and >> flash-max-timeout-us nodes are missing it sets a default value for each if >> the >> node is not present. >> >> So should we remove this code from the Max77693 driver too and fail probe as >> being asked >> in this driver? > > Well, modifying driver without access to the hardware is tricky > :-(. If it does something stupid (like using other than minimum values > for the flash-max-microamp/flash-max-timeout-us), it needs to be > fixed. Well we should be able to test the probe/parse dt node and reject the probe if the node is not present. That can be done without HW the setup is done pretty early in the probe without even attempting to communicate with the hardware. Dan > > And maybe comment "don't copy this, its wrong" would be in order... > > Best regards, > Pavel > -- -- Dan Murphy
Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver
On 05/14/2018 03:16 PM, Pavel Machek wrote: > On Mon 2018-05-14 15:13:34, Dan Murphy wrote: >> Pavel >> >> On 05/14/2018 03:05 PM, Pavel Machek wrote: >>> Hi! >>> >>>>> OK. >>>> >>>> OK I looked at the max776973 driver and well if the flash-max-microamp and >>>> flash-max-timeout-us nodes are missing it sets a default value for each if >>>> the >>>> node is not present. >>>> >>>> So should we remove this code from the Max77693 driver too and fail probe >>>> as being asked >>>> in this driver? >>> >>> Well, modifying driver without access to the hardware is tricky >>> :-(. If it does something stupid (like using other than minimum values >>> for the flash-max-microamp/flash-max-timeout-us), it needs to be >>> fixed. >> >> Well we should be able to test the probe/parse dt node and reject the probe >> if the node is not >> present. That can be done without HW the setup is done pretty early in the >> probe without even attempting to communicate >> with the hardware. >> > > Well, yes, you can do that. > > But if someone is actively using board with DT w/o flash-max-microamp, > you'll make them unhappy. > I grepped the dt directories and I did not find any upstream dt files configuring the max77693 with a flash led source. Unless Jacek can point out an upstream file I may have over looked. Unhappiness will come from not upstreaming your code ;) Dan > Best regards, > Pavel > -- -- Dan Murphy
[PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Introduce the family of LED devices that can
drive a torch, strobe or IR LED.
The LED driver can be configured with a strobe
timer to execute a strobe flash. The IR LED
brightness is controlled via the torch brightness
register.
The data sheet for each the LM36010 and LM36011
LED drivers can be found here:
http://www.ti.com/product/LM36010
http://www.ti.com/product/LM36011
Signed-off-by: Dan Murphy
---
v6 - This driver has been heavily modified from v5. There is no longer reading
of individual child nodes. There are too many changes to list here see -
https://patchwork.kernel.org/patch/10392123/
v5 - Fixed magic numbers, change reg cache type, added of_put_node to release
the dt node ref, and I did not change the remove function to leave the LED in
its
state on driver removal - https://patchwork.kernel.org/patch/10391741/
v4 - Fixed Cocci issue using ARRAY_SIZE -
https://patchwork.kernel.org/patch/10389259/
v3 - removed wildcard dt compatible, fixed copyright, fixed struct doc, removed
RO registers from default, added regmap volatile for FLAGS_REG, updated regmap
cache type,
fixed unlock and extra semi colon in strobe_set, removed unnecessary out label
in led register and fixed checking of the ret in brightness_set -
https://patchwork.kernel.org/patch/10386243/
v2 - Fixed kbuild issue and removed unused cdev_strobe -
https://patchwork.kernel.org/patch/10384585/
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3601x.c | 595
3 files changed, 605 insertions(+)
create mode 100644 drivers/leds/leds-lm3601x.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2c896c0e69e1..50ae536f343f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -145,6 +145,15 @@ config LEDS_LM3692X
This option enables support for the TI LM3692x family
of white LED string drivers used for backlighting.
+config LEDS_LM3601X
+ tristate "LED support for LM3601x Chips"
+ depends on LEDS_CLASS && I2C && OF
+ depends on LEDS_CLASS_FLASH
+ select REGMAP_I2C
+ help
+ This option enables support for the TI LM3601x family
+ of flash, torch and indicator classes.
+
config LEDS_LOCOMO
tristate "LED Support for Locomo device"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 91eca81cae82..b79807fe1b67 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
+obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c
new file mode 100644
index ..fa87da5d5159
--- /dev/null
+++ b/drivers/leds/leds-lm3601x.c
@@ -0,0 +1,595 @@
+// SPDX-License-Identifier: GPL-2.0
+// Flash and torch driver for Texas Instruments LM3601X LED
+// Flash driver chip family
+// Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LM3601X_LED_TORCH 0x0
+#define LM3601X_LED_IR 0x1
+
+/* Registers */
+#define LM3601X_ENABLE_REG 0x01
+#define LM3601X_CFG_REG0x02
+#define LM3601X_LED_FLASH_REG 0x03
+#define LM3601X_LED_TORCH_REG 0x04
+#define LM3601X_FLAGS_REG 0x05
+#define LM3601X_DEV_ID_REG 0x06
+
+#define LM3601X_SW_RESET BIT(7)
+
+/* Enable Mode bits */
+#define LM3601X_MODE_STANDBY 0x00
+#define LM3601X_MODE_IR_DRVBIT(0)
+#define LM3601X_MODE_TORCH BIT(1)
+#define LM3601X_MODE_STROBE(BIT(0) | BIT(1))
+#define LM3601X_STRB_ENBIT(2)
+#define LM3601X_STRB_LVL_TRIG ~BIT(3)
+#define LM3601X_STRB_EDGE_TRIG BIT(3)
+#define LM3601X_IVFM_ENBIT(4)
+
+#define LM36010_BOOST_LIMIT_19 ~BIT(5)
+#define LM36010_BOOST_LIMIT_28 BIT(5)
+#define LM36010_BOOST_FREQ_2MHZ~BIT(6)
+#define LM36010_BOOST_FREQ_4MHZBIT(6)
+#define LM36010_BOOST_MODE_NORM~BIT(7)
+#define LM36010_BOOST_MODE_PASSBIT(7)
+
+/* Flag Mask */
+#define LM3601X_FLASH_TIME_OUT BIT(0)
+#define LM3601X_UVLO_FAULT BIT(1)
+#define LM3601X_THERM_SHUTDOWN BIT(2)
+#define LM3601X_THERM_CURR BIT(3)
+#define LM36010_CURR_LIMIT BIT(4)
+#define LM3601X_SHORT_FAULTBIT(5)
+#define LM3601X_IVFM_TRIP BIT(6)
+#define LM36010_OVP_FAULT BIT(7)
+
+#define LM3601X_MIN_TORCH_I_UA 2400
+#define LM3601X_MIN_STROBE_I_MA11
+
+#define LM3601X_TIMEOUT_MASK 0x1e
+#define LM3601X_ENABLE_MASK0x03
+
+enum lm3601x_type {
+ CHIP_LM36010 = 0,
+ CHIP_LM36011,
+};
+
+/**
+ * struct
[PATCH v6 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Signed-off-by: Dan Murphy
---
v6 - Removed multiple led child nodes, fixed example to display micro ranges
for corresponding child nodes and added led-sources to define the current
driver -
https://patchwork.kernel.org/patch/10392121/
v5 - No changes - https://patchwork.kernel.org/patch/10391743/
v4 - Added " " around "=", changed strobe to flash on label, removed "support
and
register" comment and change ir lable to ir:torch - See v2 patchworks for
comments
v3 - Removed wildcard compatible - https://patchwork.kernel.org/patch/10386241/
v2 - No changes - https://patchwork.kernel.org/patch/10384587/
.../devicetree/bindings/leds/leds-lm3601x.txt | 47 +++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3601x.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
new file mode 100644
index ..27930a89e9a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
@@ -0,0 +1,47 @@
+* Texas Instruments - lm3601x Single-LED Flash Driver
+
+The LM3601X are ultra-small LED flash drivers that
+provide a high level of adjustability.
+
+Required properties:
+ - compatible : Can be one of the following
+ "ti,lm36010"
+ "ti,lm36011"
+ - reg : I2C slave address
+ - #address-cells : 1
+ - #size-cells : 0
+
+Required child properties:
+ - reg : 0
+ - led-sources: 0 - Indicates a IR mode
+ 1 - Indicates a Torch (white LED) mode
+
+Required properties for flash LED child nodes:
+ See Documentation/devicetree/bindings/leds/common.txt
+ - flash-max-microamp : Range from 11mA -> 1.5A
+ - flash-max-timeout-us : Range from 40ms -> 1600ms
+ - led-max-microamp : Range from 2.4mA -> 376mA
+
+Optional child properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+led-controller@64 {
+ compatible = "ti,lm36010";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x64>;
+
+ led@0 {
+ reg = <0>;
+ label = "white:torch";
+ led-max-microamp = <376000>;
+ flash-max-microamp = <150>;
+ flash-max-timeout-us = <160>;
+ led-sources = <1>;
+ };
+}
+
+For more product information please see the links below:
+http://www.ti.com/product/LM36010
+http://www.ti.com/product/LM36011
--
2.17.0.582.gccdcbd54c
Re: [PATCH v6 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
Jacek
On 05/15/2018 04:13 PM, Jacek Anaszewski wrote:
> Hi Dan,
>
> Thanks for the update.
>
> On 05/15/2018 05:43 PM, Dan Murphy wrote:
>> Introduce the device tree bindings for the lm3601x
>> family of LED torch, flash and IR drivers.
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> v6 - Removed multiple led child nodes, fixed example to display micro ranges
>> for corresponding child nodes and added led-sources to define the current
>> driver -
>> https://patchwork.kernel.org/patch/10392121/
>>
>> v5 - No changes - https://patchwork.kernel.org/patch/10391743/
>> v4 - Added " " around "=", changed strobe to flash on label, removed
>> "support and
>> register" comment and change ir lable to ir:torch - See v2 patchworks for
>> comments
>> v3 - Removed wildcard compatible -
>> https://patchwork.kernel.org/patch/10386241/
>> v2 - No changes - https://patchwork.kernel.org/patch/10384587/
>>
>> .../devicetree/bindings/leds/leds-lm3601x.txt | 47 +++
>> 1 file changed, 47 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>> b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>> new file mode 100644
>> index ..27930a89e9a5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>> @@ -0,0 +1,47 @@
>> +* Texas Instruments - lm3601x Single-LED Flash Driver
>> +
>> +The LM3601X are ultra-small LED flash drivers that
>> +provide a high level of adjustability.
>> +
>> +Required properties:
>> + - compatible : Can be one of the following
>> + "ti,lm36010"
>> + "ti,lm36011"
>> + - reg : I2C slave address
>> + - #address-cells : 1
>> + - #size-cells : 0
>> +
>> +Required child properties:
>> + - reg : 0
>> + - led-sources: 0 - Indicates a IR mode
>> + 1 - Indicates a Torch (white LED) mode
>
> You don't need led-sources at all. Please use reg as in
> the previous version. led-sources is useful for describing
> more complex arrangements. Here reg will do.
OK. Thought we would keep consistent with the max IC.
>
>> +
>> +Required properties for flash LED child nodes:
>> + See Documentation/devicetree/bindings/leds/common.txt
>> + - flash-max-microamp : Range from 11mA -> 1.5A
>> + - flash-max-timeout-us : Range from 40ms -> 1600ms
>> + - led-max-microamp : Range from 2.4mA -> 376mA
>
> Please give also a step in the format like below
> (taken from max77693):
>
> Valid values: 62500 - 100, step by 62500 (rounded down)
I would do this but the step is not linear. The step is 40ms from 40 -> 400.
after that the step goes to 200ms from 400->1600.
same with the current ranges.
Dan
>
>
>> +
>> +Optional child properties:
>> + - label : see Documentation/devicetree/bindings/leds/common.txt
>> +
>> +Example:
>> +led-controller@64 {
>> + compatible = "ti,lm36010";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0x64>;
>> +
>> + led@0 {
>> + reg = <0>;
>> + label = "white:torch";
>> + led-max-microamp = <376000>;
>> + flash-max-microamp = <150>;
>> + flash-max-timeout-us = <160>;
>> + led-sources = <1>;
>> + };
>> +}
>> +
>> +For more product information please see the links below:
>> +http://www.ti.com/product/LM36010
>> +http://www.ti.com/product/LM36011
>>
>
--
--
Dan Murphy
Re: [PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Jacek On 05/15/2018 04:24 PM, Jacek Anaszewski wrote: > Dan, > > Thanks for the update. Please refer to my comments below. > > On 05/15/2018 05:43 PM, Dan Murphy wrote: >> Introduce the family of LED devices that can >> drive a torch, strobe or IR LED. >> >> The LED driver can be configured with a strobe >> timer to execute a strobe flash. The IR LED >> brightness is controlled via the torch brightness >> register. >> >> The data sheet for each the LM36010 and LM36011 >> LED drivers can be found here: >> http://www.ti.com/product/LM36010 >> http://www.ti.com/product/LM36011 >> >> Signed-off-by: Dan Murphy >> --- >> >> v6 - This driver has been heavily modified from v5. There is no longer >> reading >> of individual child nodes. There are too many changes to list here see - >> https://patchwork.kernel.org/patch/10392123/ >> >> v5 - Fixed magic numbers, change reg cache type, added of_put_node to release >> the dt node ref, and I did not change the remove function to leave the LED >> in its >> state on driver removal - https://patchwork.kernel.org/patch/10391741/ >> v4 - Fixed Cocci issue using ARRAY_SIZE - >> https://patchwork.kernel.org/patch/10389259/ >> v3 - removed wildcard dt compatible, fixed copyright, fixed struct doc, >> removed >> RO registers from default, added regmap volatile for FLAGS_REG, updated >> regmap cache type, >> fixed unlock and extra semi colon in strobe_set, removed unnecessary out >> label >> in led register and fixed checking of the ret in brightness_set - >> https://patchwork.kernel.org/patch/10386243/ >> v2 - Fixed kbuild issue and removed unused cdev_strobe - >> https://patchwork.kernel.org/patch/10384585/ >> >> drivers/leds/Kconfig | 9 + >> drivers/leds/Makefile | 1 + >> drivers/leds/leds-lm3601x.c | 595 >> 3 files changed, 605 insertions(+) >> create mode 100644 drivers/leds/leds-lm3601x.c >> >> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig >> index 2c896c0e69e1..50ae536f343f 100644 >> --- a/drivers/leds/Kconfig >> +++ b/drivers/leds/Kconfig >> @@ -145,6 +145,15 @@ config LEDS_LM3692X >> This option enables support for the TI LM3692x family >> of white LED string drivers used for backlighting. >> +config LEDS_LM3601X >> + tristate "LED support for LM3601x Chips" >> + depends on LEDS_CLASS && I2C && OF >> + depends on LEDS_CLASS_FLASH >> + select REGMAP_I2C >> + help >> + This option enables support for the TI LM3601x family >> + of flash, torch and indicator classes. >> + >> config LEDS_LOCOMO >> tristate "LED Support for Locomo device" >> depends on LEDS_CLASS >> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile >> index 91eca81cae82..b79807fe1b67 100644 >> --- a/drivers/leds/Makefile >> +++ b/drivers/leds/Makefile >> @@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o >> obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o >> obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o >> obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o >> +obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o >> # LED SPI Drivers >> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o >> diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c >> new file mode 100644 >> index ..fa87da5d5159 >> --- /dev/null >> +++ b/drivers/leds/leds-lm3601x.c >> @@ -0,0 +1,595 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +// Flash and torch driver for Texas Instruments LM3601X LED >> +// Flash driver chip family >> +// Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define LM3601X_LED_TORCH 0x0 >> +#define LM3601X_LED_IR 0x1 >> + >> +/* Registers */ >> +#define LM3601X_ENABLE_REG 0x01 >> +#define LM3601X_CFG_REG 0x02 >> +#define LM3601X_LED_FLASH_REG 0x03 >> +#define LM3601X_LED_TORCH_REG 0x04 >> +#define LM3601X_FLAGS_REG 0x05 >> +#define LM3601X_DEV_ID_REG 0x06 >> + >> +#define LM3601X_SW_RESET BIT(7) >> + >> +/* Enable Mode bits */ >> +#define LM3601X_MODE_STANDBY 0x00 >> +#define LM3601X_MODE_IR_DRV BIT(0) >&g
Re: [PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Andy
Thanks for the review
On 05/15/2018 04:56 PM, Andy Shevchenko wrote:
> On Tue, May 15, 2018 at 6:43 PM, Dan Murphy wrote:
>> Introduce the family of LED devices that can
>> drive a torch, strobe or IR LED.
>>
>> The LED driver can be configured with a strobe
>> timer to execute a strobe flash. The IR LED
>> brightness is controlled via the torch brightness
>> register.
>>
>> The data sheet for each the LM36010 and LM36011
>> LED drivers can be found here:
>> http://www.ti.com/product/LM36010
>> http://www.ti.com/product/LM36011
>
>> + depends on LEDS_CLASS && I2C && OF
>
> What is OF specific in this driver?
as3645a_led_class_setup has a "of" dependency
>
>
>> +#define LM3601X_STRB_LVL_TRIG ~BIT(3)
>
>> +#define LM36010_BOOST_LIMIT_19 ~BIT(5)
>
>> +#define LM36010_BOOST_FREQ_2MHZ~BIT(6)
>
>> +#define LM36010_BOOST_MODE_NORM~BIT(7)
>
> These looks rather strange. Shouldn't be just 0:s?
I don't actually use these so I can just remove them
>
>> +struct lm3601x_led {
>> + struct mutex lock;
>> + struct regmap *regmap;
>> + struct i2c_client *client;
>
>> + struct device_node *led_node;
>
> Why do you need this?
I don't but I can store it locally. I was using the nodes in the register
functions in previous versions.
>
>> +};
>
>> +static const struct lm3601x_max_timeouts strobe_timeouts[] = {
>> + { 4, 0x00 },
>> + { 8, 0x01 },
>> + { 12, 0x02 },
>> + { 16, 0x03 },
>> + { 20, 0x04 },
>> + { 24, 0x05 },
>> + { 28, 0x06 },
>> + { 32, 0x07 },
>> + { 36, 0x08 },
>> + { 40, 0x09 },
>> + { 60, 0x0a },
>> + { 80, 0x0b },
>> + { 100, 0x0c },
>> + { 120, 0x0d },
>> + { 140, 0x0e },
>> + { 160, 0x0f },
>
> Huh?!
Please give comments that actually mean something other wise I will opt to
ignore them.
>
> strobe_timeout = (x + 1) * 40 * MSECS_IN_SEC;
Not sure what equation you are trying to point out here. But if you are trying
to apply
a timeout step you cannot do this with this part. As pointed out in the DT doc
the timeout
step is not linear.
>
>> +};
>
>> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
>> + int ret;
>> + int current_timeout;
>> + int reg_count;
>> + int i;
>> + int timeout_reg_val = 0;
>
> Better to put lines here in reversed xmas tree order (longest first).
I can do that, again this is a preference.
>
>> + reg_count = ARRAY_SIZE(strobe_timeouts);
>> + for (i = 0; i < reg_count; i++) {
>> + if (led->strobe_timeout > strobe_timeouts[i].timeout)
>> + continue;
>
> binary search?
>
> Check lib/bsearch.c (IIRC).
>
> But! See above the formula.
>
>> + brightness_val = (brightness/2);
>
> Spaces.
Not sure what this means checkpatch was clean
>
>> +static int lm3601x_register_leds(struct lm3601x_led *led)
>> +{
>
>
>> + int err = -ENODEV;
>
> Useless assignment.
This is an artifact from prior versions I can remove it
>
>> + err = led_classdev_flash_register(>client->dev,
>> + fled_cdev);
>> +
>> + return err;
>
> This is return led_...();
That is a preference. It does not have to be that way.
>
>> +}
>
>> + ret = of_property_read_string(led->led_node, "label", );
>
> device_property_...();
It can be if the maintainer is requesting this.
Is the trend to move to these functions?
Most drivers use the "of" calls.
>
>> + if (!ret)
>
> if (ret) sounds more natural. And better just to split
>
>> + snprintf(led->led_name, sizeof(led->led_name),
>> + "%s:%s", led->led_node->name, name);
>> + else
>> + snprintf(led->led_name, sizeof(led->led_name),
>> + "%s:torch", led->led_node->name);
>
> const char *tmp;
>
> ret = device_property_read_...();
> if (ret)
> tmp = ...
> sprintf(...);
>
>> + led = devm_kzalloc(>dev,
>> + sizeof(struct lm3601x_led), GFP_KERNEL);
>
> sizeof(*led) and one line in the result
>
>> +static const struct i2c_device_id lm3601x_id[] = {
>> + { "LM36010", CHIP_LM36010 },
>> + { "LM36011", CHIP_LM36011 },
>> + { },
>
> Terminators better w/o comma.
Looking at other drivers adding comma's on the sentinel is accepted. See the
as3645a driver
>
>> +};
>> +MODULE_DEVICE_TABLE(i2c, lm3601x_id);
>> +
>> +static const struct of_device_id of_lm3601x_leds_match[] = {
>> + { .compatible = "ti,lm36010", },
>> + { .compatible = "ti,lm36011", },
>> + {},
>
> Ditto.
See above
>
>> +};
>> +MODULE_DEVICE_TABLE(of, of_lm3601x_leds_match);
>
>
>
>
--
--
Dan Murphy
[PATCH 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Introduce the family of LED devices that can
drive a torch, strobe or IR LED.
The LED driver can be configured with a strobe
timer to execute a strobe flash. The IR LED
brightness is controlled via the torch brightness
register.
The data sheet for each the LM36010 and LM36011
LED drivers can be found here:
http://www.ti.com/product/LM36010
http://www.ti.com/product/LM36011
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3601x.c | 593
3 files changed, 603 insertions(+)
create mode 100644 drivers/leds/leds-lm3601x.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2c896c0e69e1..50ae536f343f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -145,6 +145,15 @@ config LEDS_LM3692X
This option enables support for the TI LM3692x family
of white LED string drivers used for backlighting.
+config LEDS_LM3601X
+ tristate "LED support for LM3601x Chips"
+ depends on LEDS_CLASS && I2C && OF
+ depends on LEDS_CLASS_FLASH
+ select REGMAP_I2C
+ help
+ This option enables support for the TI LM3601x family
+ of flash, torch and indicator classes.
+
config LEDS_LOCOMO
tristate "LED Support for Locomo device"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 91eca81cae82..b79807fe1b67 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
+obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c
new file mode 100644
index ..c386779e5dfa
--- /dev/null
+++ b/drivers/leds/leds-lm3601x.c
@@ -0,0 +1,593 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Flash and torch driver for Texas Instruments LM3601X LED
+ * Flash driver chip family
+ * Copyright (C) 2018 Texas Instruments
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LM3601X_LED_TORCH 0x0
+#define LM3601X_LED_STROBE 0x1
+#define LM3601X_LED_IR 0x2
+
+/* Registers */
+#define LM3601X_ENABLE_REG 0x01
+#define LM3601X_CFG_REG0x02
+#define LM3601X_LED_FLASH_REG 0x03
+#define LM3601X_LED_TORCH_REG 0x04
+#define LM3601X_FLAGS_REG 0x05
+#define LM3601X_DEV_ID_REG 0x06
+
+#define LM3601X_SW_RESET BIT(7)
+
+/* Enable Mode bits */
+#define LM3601X_MODE_STANDBY 0x00
+#define LM3601X_MODE_IR_DRVBIT(0)
+#define LM3601X_MODE_TORCH BIT(1)
+#define LM3601X_MODE_STROBE(BIT(0) | BIT(1))
+#define LM3601X_STRB_ENBIT(2)
+#define LM3601X_STRB_LVL_TRIG ~BIT(3)
+#define LM3601X_STRB_EDGE_TRIG BIT(3)
+#define LM3601X_IVFM_ENBIT(4)
+
+#define LM36010_BOOST_LIMIT_19 ~BIT(5)
+#define LM36010_BOOST_LIMIT_28 BIT(5)
+#define LM36010_BOOST_FREQ_2MHZ~BIT(6)
+#define LM36010_BOOST_FREQ_4MHZBIT(6)
+#define LM36010_BOOST_MODE_NORM~BIT(7)
+#define LM36010_BOOST_MODE_PASSBIT(7)
+
+/* Flag Mask */
+#define LM3601X_FLASH_TIME_OUT BIT(0)
+#define LM3601X_UVLO_FAULT BIT(1)
+#define LM3601X_THERM_SHUTDOWN BIT(2)
+#define LM3601X_THERM_CURR BIT(3)
+#define LM36010_CURR_LIMIT BIT(4)
+#define LM3601X_SHORT_FAULTBIT(5)
+#define LM3601X_IVFM_TRIP BIT(6)
+#define LM36010_OVP_FAULT BIT(7)
+
+#define LM3601X_MIN_TORCH_I_UA 2400
+#define LM3601X_MIN_STROBE_I_MA11
+
+enum lm3601x_type {
+ CHIP_LM36010 = 0,
+ CHIP_LM36011,
+};
+
+struct lm3601x_max_timeouts {
+ int timeout;
+ int reg_val;
+};
+
+/**
+ * struct lm3601x_led -
+ * @lock - Lock for reading/writing the device
+ * @regmap - Devices register map
+ * @client - Pointer to the I2C client
+ * @cdev_strobe - led class device pointer for the strobe
+ * @cdev_torch - led class device pointer for the torch
+ * @cdev_ir - led class device pointer for infrared
+ * @fled_cdev - flash led class device pointer
+ * @strobe_node - DT device node for the strobe
+ * @torch - LED label for the torch
+ * @strobe - LED label for the strobe
+ * @ir - LED label for the infrared
+ * @last_flag - last known flags register value
+ * @strobe_timeout - the timeout for the strobe
+ * @torch_current_max - maximum current for the torch
+ * @strobe_current_max - maximum current for the strobe
+ * @max_strobe_timeout - maximum timeout for the strobe
+ */
+struct lm3601x_led {
+ struct mutex lock;
+ struct regmap *regmap;
+ struct i2c_client *client;
+
+ struct led_classdev cdev_strobe;
+ struct led_classdev cde
[PATCH 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/leds/leds-lm3601x.txt | 51 +++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3601x.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
new file mode 100644
index ..38cdabf6ca7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
@@ -0,0 +1,51 @@
+* Texas Instruments - lm3601x Single-LED Flash Driver
+
+The LM3601X are ultra-small LED flash drivers that
+provides a high level of adjustability.
+
+Required properties:
+ - compatible : Can be one of the following
+ "ti,lm3601x"
+ "ti,lm36010"
+ "ti,lm36011"
+ - reg : I2C slave address
+ - #address-cells : 1
+ - #size-cells : 0
+
+Required child properties:
+ - reg : 0 - Indicates to support and register a torch interface
+ 1 - Indicates to support and register a strobe interface
+ 2 - Indicates to support and register an ir interface
+
+Optional child properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+led-controller@64 {
+ compatible = "ti,lm3601x";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x64>;
+
+ led@0 {
+ reg = <0>;
+ label = "white:torch";
+ led-max-microamp=<1>;
+ };
+
+ led@1 {
+ reg = <1>;
+ label = "white:strobe";
+ flash-max-microamp=<1>;
+ flash-max-timeout-us=<800>;
+ };
+
+ led@2 {
+ reg = <2>;
+ label = "invisible:ir";
+ };
+}
+
+For more product information please see the links below:
+http://www.ti.com/product/LM36010
+http://www.ti.com/product/LM36011
--
2.17.0.252.gfe0a9eaf3
Re: [PATCH v2 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
Pavel
Thanks for the review
On 05/10/2018 06:28 AM, Pavel Machek wrote:
> On Tue 2018-05-08 09:17:03, Dan Murphy wrote:
>> Introduce the device tree bindings for the lm3601x
>> family of LED torch, flash and IR drivers.
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> v2 - No changes - https://patchwork.kernel.org/patch/10384587/
>>
>> .../devicetree/bindings/leds/leds-lm3601x.txt | 51 +++
>> 1 file changed, 51 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>> b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>> new file mode 100644
>> index ..38cdabf6ca7e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>> @@ -0,0 +1,51 @@
>> +* Texas Instruments - lm3601x Single-LED Flash Driver
>> +
>> +The LM3601X are ultra-small LED flash drivers that
>> +provides a high level of adjustability.
>
> "provide".
Data sheet says provides.
It reads fine either way but I will change it.
>
>> +Required properties:
>> +- compatible : Can be one of the following
>> +"ti,lm3601x"
>> +"ti,lm36010"
>> +"ti,lm36011"
>> +- reg : I2C slave address
>> +- #address-cells : 1
>> +- #size-cells : 0
>> +
>> +Required child properties:
>> +- reg : 0 - Indicates to support and register a torch interface
>> +1 - Indicates to support and register a strobe interface
>> +2 - Indicates to support and register an ir interface
>
> I'd delete "to support and register" -- we are describing hardware here.
OK
>
>> +Optional child properties:
>> +- label : see Documentation/devicetree/bindings/leds/common.txt
>> +
>> +Example:
>> +led-controller@64 {
>> +compatible = "ti,lm3601x";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +reg = <0x64>;
>> +
>> +led@0 {
>> +reg = <0>;
>> +label = "white:torch";
>> +led-max-microamp=<1>;
>> +};
>> +
>> +led@1 {
>> +reg = <1>;
>> +label = "white:strobe";
>> +flash-max-microamp=<1>;
>> +flash-max-timeout-us=<800>;
>> +};
>> +
>> +led@2 {
>> +reg = <2>;
>> +label = "invisible:ir";
>> +};
>> +}
>
> Title says this is single-LED driver chip, but it controls three chips
> in this example?
3 chips? It technically controls 3 LED methods and only 2 LEDs. The torch can
be used as the strobe
and the IR is controlled independently.
>
> I'd put " " around "=" for consistency.
OK
>
> We use "flash" elsewhere, I'd replace "strobe" with that. Userspace
> would like consistency, too.
Labels are meant to be examples only not absolutes. I will change it to say
flash
but the label can be anything the customer wants it to be.
>
> What is the IR led good for? Taking videos in the dark?
Yes. That is one application.
And hunting ghosts ;)
>
> I guess for consistency, it is "ir:torch" :-).
OK
>
> Pavel
>
--
--
Dan Murphy
[PATCH v4 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Introduce the family of LED devices that can
drive a torch, strobe or IR LED.
The LED driver can be configured with a strobe
timer to execute a strobe flash. The IR LED
brightness is controlled via the torch brightness
register.
The data sheet for each the LM36010 and LM36011
LED drivers can be found here:
http://www.ti.com/product/LM36010
http://www.ti.com/product/LM36011
Signed-off-by: Dan Murphy
---
v4 - Fixed Cocci issue using ARRAY_SIZE -
https://patchwork.kernel.org/patch/10389259/
v3 - removed wildcard dt compatible, fixed copyright, fixed struct doc, removed
RO registers from default, added regmap volatile for FLAGS_REG, updated regmap
cache type,
fixed unlock and extra semi colon in strobe_set, removed unnecessary out label
in led register and fixed checking of the ret in brightness_set -
https://patchwork.kernel.org/patch/10386243/
v2 - Fixed kbuild issue and removed unused cdev_strobe -
https://patchwork.kernel.org/patch/10384585/
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3601x.c | 611
3 files changed, 621 insertions(+)
create mode 100644 drivers/leds/leds-lm3601x.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2c896c0e69e1..50ae536f343f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -145,6 +145,15 @@ config LEDS_LM3692X
This option enables support for the TI LM3692x family
of white LED string drivers used for backlighting.
+config LEDS_LM3601X
+ tristate "LED support for LM3601x Chips"
+ depends on LEDS_CLASS && I2C && OF
+ depends on LEDS_CLASS_FLASH
+ select REGMAP_I2C
+ help
+ This option enables support for the TI LM3601x family
+ of flash, torch and indicator classes.
+
config LEDS_LOCOMO
tristate "LED Support for Locomo device"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 91eca81cae82..b79807fe1b67 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
+obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c
new file mode 100644
index ..4104c259c65d
--- /dev/null
+++ b/drivers/leds/leds-lm3601x.c
@@ -0,0 +1,611 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Flash and torch driver for Texas Instruments LM3601X LED
+ * Flash driver chip family
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LM3601X_LED_TORCH 0x0
+#define LM3601X_LED_STROBE 0x1
+#define LM3601X_LED_IR 0x2
+
+/* Registers */
+#define LM3601X_ENABLE_REG 0x01
+#define LM3601X_CFG_REG0x02
+#define LM3601X_LED_FLASH_REG 0x03
+#define LM3601X_LED_TORCH_REG 0x04
+#define LM3601X_FLAGS_REG 0x05
+#define LM3601X_DEV_ID_REG 0x06
+
+#define LM3601X_SW_RESET BIT(7)
+
+/* Enable Mode bits */
+#define LM3601X_MODE_STANDBY 0x00
+#define LM3601X_MODE_IR_DRVBIT(0)
+#define LM3601X_MODE_TORCH BIT(1)
+#define LM3601X_MODE_STROBE(BIT(0) | BIT(1))
+#define LM3601X_STRB_ENBIT(2)
+#define LM3601X_STRB_LVL_TRIG ~BIT(3)
+#define LM3601X_STRB_EDGE_TRIG BIT(3)
+#define LM3601X_IVFM_ENBIT(4)
+
+#define LM36010_BOOST_LIMIT_19 ~BIT(5)
+#define LM36010_BOOST_LIMIT_28 BIT(5)
+#define LM36010_BOOST_FREQ_2MHZ~BIT(6)
+#define LM36010_BOOST_FREQ_4MHZBIT(6)
+#define LM36010_BOOST_MODE_NORM~BIT(7)
+#define LM36010_BOOST_MODE_PASSBIT(7)
+
+/* Flag Mask */
+#define LM3601X_FLASH_TIME_OUT BIT(0)
+#define LM3601X_UVLO_FAULT BIT(1)
+#define LM3601X_THERM_SHUTDOWN BIT(2)
+#define LM3601X_THERM_CURR BIT(3)
+#define LM36010_CURR_LIMIT BIT(4)
+#define LM3601X_SHORT_FAULTBIT(5)
+#define LM3601X_IVFM_TRIP BIT(6)
+#define LM36010_OVP_FAULT BIT(7)
+
+#define LM3601X_MIN_TORCH_I_UA 2400
+#define LM3601X_MIN_STROBE_I_MA11
+
+enum lm3601x_type {
+ CHIP_LM36010 = 0,
+ CHIP_LM36011,
+};
+
+/**
+ * struct lm3601x_max_timeouts -
+ * @timeout: timeout value in ms
+ * @regval: the value of the register to write
+ */
+struct lm3601x_max_timeouts {
+ int timeout;
+ int reg_val;
+};
+
+/**
+ * struct lm3601x_led -
+ * @lock: Lock for reading/writing the device
+ * @regmap: Devices register map
+ * @client: Pointer to the I2C client
+ * @cdev_torch: led class device pointer for the torch
+ * @cdev_ir: led class device pointer for infrared
+ * @fled_
[PATCH v4 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Signed-off-by: Dan Murphy
---
v4 - Added " " around "=", changed strobe to flash on label, removed "support
and
register" comment and change ir lable to ir:torch - See v2 patchworks for
comments
v3 - Removed wildcard compatible - https://patchwork.kernel.org/patch/10386241/
v2 - No changes - https://patchwork.kernel.org/patch/10384587/
.../devicetree/bindings/leds/leds-lm3601x.txt | 50 +++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3601x.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
new file mode 100644
index ..697e5e3a1d4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
@@ -0,0 +1,50 @@
+* Texas Instruments - lm3601x Single-LED Flash Driver
+
+The LM3601X are ultra-small LED flash drivers that
+provide a high level of adjustability.
+
+Required properties:
+ - compatible : Can be one of the following
+ "ti,lm36010"
+ "ti,lm36011"
+ - reg : I2C slave address
+ - #address-cells : 1
+ - #size-cells : 0
+
+Required child properties:
+ - reg : 0 - Indicates a torch interface
+ 1 - Indicates a flash interface
+ 2 - Indicates an infrared interface
+
+Optional child properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+led-controller@64 {
+ compatible = "ti,lm36010";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x64>;
+
+ led@0 {
+ reg = <0>;
+ label = "white:torch";
+ led-max-microamp = <1>;
+ };
+
+ led@1 {
+ reg = <1>;
+ label = "white:flash";
+ flash-max-microamp = <1>;
+ flash-max-timeout-us = <800>;
+ };
+
+ led@2 {
+ reg = <2>;
+ label = "ir:torch";
+ };
+}
+
+For more product information please see the links below:
+http://www.ti.com/product/LM36010
+http://www.ti.com/product/LM36011
--
2.17.0.582.gccdcbd54c
Re: [PATCH v4 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Andrew Thanks for the re-review On 05/10/2018 08:44 AM, Andrew F. Davis wrote: > On 05/10/2018 07:27 AM, Dan Murphy wrote: >> Introduce the family of LED devices that can >> drive a torch, strobe or IR LED. >> >> The LED driver can be configured with a strobe >> timer to execute a strobe flash. The IR LED >> brightness is controlled via the torch brightness >> register. >> >> The data sheet for each the LM36010 and LM36011 >> LED drivers can be found here: >> http://www.ti.com/product/LM36010 >> http://www.ti.com/product/LM36011 >> >> Signed-off-by: Dan Murphy >> --- >> >> v4 - Fixed Cocci issue using ARRAY_SIZE - >> https://patchwork.kernel.org/patch/10389259/ >> >> v3 - removed wildcard dt compatible, fixed copyright, fixed struct doc, >> removed >> RO registers from default, added regmap volatile for FLAGS_REG, updated >> regmap cache type, >> fixed unlock and extra semi colon in strobe_set, removed unnecessary out >> label >> in led register and fixed checking of the ret in brightness_set - >> https://patchwork.kernel.org/patch/10386243/ >> v2 - Fixed kbuild issue and removed unused cdev_strobe - >> https://patchwork.kernel.org/patch/10384585/ >> >> drivers/leds/Kconfig| 9 + >> drivers/leds/Makefile | 1 + >> drivers/leds/leds-lm3601x.c | 611 >> 3 files changed, 621 insertions(+) >> create mode 100644 drivers/leds/leds-lm3601x.c >> >> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig >> index 2c896c0e69e1..50ae536f343f 100644 >> --- a/drivers/leds/Kconfig >> +++ b/drivers/leds/Kconfig >> @@ -145,6 +145,15 @@ config LEDS_LM3692X >>This option enables support for the TI LM3692x family >>of white LED string drivers used for backlighting. >> >> +config LEDS_LM3601X >> +tristate "LED support for LM3601x Chips" >> +depends on LEDS_CLASS && I2C && OF >> +depends on LEDS_CLASS_FLASH >> +select REGMAP_I2C >> +help >> + This option enables support for the TI LM3601x family >> + of flash, torch and indicator classes. >> + >> config LEDS_LOCOMO >> tristate "LED Support for Locomo device" >> depends on LEDS_CLASS >> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile >> index 91eca81cae82..b79807fe1b67 100644 >> --- a/drivers/leds/Makefile >> +++ b/drivers/leds/Makefile >> @@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o >> obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o >> obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o >> obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o >> +obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o >> >> # LED SPI Drivers >> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o >> diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c >> new file mode 100644 >> index ..4104c259c65d >> --- /dev/null >> +++ b/drivers/leds/leds-lm3601x.c >> @@ -0,0 +1,611 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Flash and torch driver for Texas Instruments LM3601X LED >> + * Flash driver chip family >> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define LM3601X_LED_TORCH 0x0 >> +#define LM3601X_LED_STROBE 0x1 >> +#define LM3601X_LED_IR 0x2 >> + >> +/* Registers */ >> +#define LM3601X_ENABLE_REG 0x01 >> +#define LM3601X_CFG_REG 0x02 >> +#define LM3601X_LED_FLASH_REG 0x03 >> +#define LM3601X_LED_TORCH_REG 0x04 >> +#define LM3601X_FLAGS_REG 0x05 >> +#define LM3601X_DEV_ID_REG 0x06 >> + >> +#define LM3601X_SW_RESETBIT(7) >> + >> +/* Enable Mode bits */ >> +#define LM3601X_MODE_STANDBY0x00 >> +#define LM3601X_MODE_IR_DRV BIT(0) >> +#define LM3601X_MODE_TORCH BIT(1) >> +#define LM3601X_MODE_STROBE (BIT(0) | BIT(1)) >> +#define LM3601X_STRB_EN BIT(2) >> +#define LM3601X_STRB_LVL_TRIG ~BIT(3) >> +#define LM3601X_STRB_EDGE_TRIG BIT(3) >> +#define LM3601X_IVFM_EN BIT(4) >> + >> +#define LM36010_BOOST_LIMIT_19 ~BIT(5) >> +#define LM36010_BOOST_LIMIT_28 BIT(5) >> +#define LM36010_BOOST_
Re: [PATCH v4 2/2] leds: lm3601x: Introduce the lm3601x LED driver
On 05/10/2018 09:31 AM, Andrew F. Davis wrote:
> On 05/10/2018 09:04 AM, Dan Murphy wrote:
>
>>>> +static int lm3601x_remove(struct i2c_client *client)
>>>> +{
>>>> + struct lm3601x_led *led = i2c_get_clientdata(client);
>>>> +
>>>> + regmap_write(led->regmap, LM3601X_ENABLE_REG, 0);
>>>> +
>>>
>>>
>>> If probe doesn't enable this, remove shouldn't disable it. It can lead
>>> to odd cases if the driver is removed and added again.
>>
>> I want to make sure the LED is off and in standby mode. Maybe I will just
>> set it to
>> the default value instead.
>>
>
>
> Why? If you want to do this then implement PM controls and put it in
> standby mode there.
>
>
Implementing PM controls does not cause this line to be removed on a removal.
>>>
>>> Plus, removing the driver is not a command to disable the LED anyway.
>>
>> True but you don't want to leave any LEDs in the on state without a driver
>> to support it.
>> This could burn out the LED or the board if left on on max brightness
>>
>
>
> I disagree, we should not try to decide what the user wants here. We
> should only do what we are instructed to do, which for remove() is to
> cleanup what probe has done so the driver can be removed w/o leaking
> memory or device state.
So your OK with a causing a burn out of the device or LED or draining the
battery because the driver was
unloaded and there is not way to turn it off besides hard power cycling the
device. Because even a reboot
of the device will still leave the LED on throughout the boot until the driver
is reloaded.
I will let the maintainer weigh in on this issue.
>
>
>>
>> Dan
>>
--
--
Dan Murphy
[PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Signed-off-by: Dan Murphy
---
v5 - No changes - https://patchwork.kernel.org/patch/10391743/
v4 - Added " " around "=", changed strobe to flash on label, removed "support
and
register" comment and change ir lable to ir:torch - See v2 patchworks for
comments
v3 - Removed wildcard compatible - https://patchwork.kernel.org/patch/10386241/
v2 - No changes - https://patchwork.kernel.org/patch/10384587/
.../devicetree/bindings/leds/leds-lm3601x.txt | 50 +++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3601x.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
new file mode 100644
index ..697e5e3a1d4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
@@ -0,0 +1,50 @@
+* Texas Instruments - lm3601x Single-LED Flash Driver
+
+The LM3601X are ultra-small LED flash drivers that
+provide a high level of adjustability.
+
+Required properties:
+ - compatible : Can be one of the following
+ "ti,lm36010"
+ "ti,lm36011"
+ - reg : I2C slave address
+ - #address-cells : 1
+ - #size-cells : 0
+
+Required child properties:
+ - reg : 0 - Indicates a torch interface
+ 1 - Indicates a flash interface
+ 2 - Indicates an infrared interface
+
+Optional child properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+led-controller@64 {
+ compatible = "ti,lm36010";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x64>;
+
+ led@0 {
+ reg = <0>;
+ label = "white:torch";
+ led-max-microamp = <1>;
+ };
+
+ led@1 {
+ reg = <1>;
+ label = "white:flash";
+ flash-max-microamp = <1>;
+ flash-max-timeout-us = <800>;
+ };
+
+ led@2 {
+ reg = <2>;
+ label = "ir:torch";
+ };
+}
+
+For more product information please see the links below:
+http://www.ti.com/product/LM36010
+http://www.ti.com/product/LM36011
--
2.17.0.582.gccdcbd54c
[PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Introduce the family of LED devices that can
drive a torch, strobe or IR LED.
The LED driver can be configured with a strobe
timer to execute a strobe flash. The IR LED
brightness is controlled via the torch brightness
register.
The data sheet for each the LM36010 and LM36011
LED drivers can be found here:
http://www.ti.com/product/LM36010
http://www.ti.com/product/LM36011
Signed-off-by: Dan Murphy
---
v5 - Fixed magic numbers, change reg cache type, added of_put_node to release
the dt node ref, and I did not change the remove function to leave the LED in
its
state on driver removal - https://patchwork.kernel.org/patch/10391741/
v4 - Fixed Cocci issue using ARRAY_SIZE -
https://patchwork.kernel.org/patch/10389259/
v3 - removed wildcard dt compatible, fixed copyright, fixed struct doc, removed
RO registers from default, added regmap volatile for FLAGS_REG, updated regmap
cache type,
fixed unlock and extra semi colon in strobe_set, removed unnecessary out label
in led register and fixed checking of the ret in brightness_set -
https://patchwork.kernel.org/patch/10386243/
v2 - Fixed kbuild issue and removed unused cdev_strobe -
https://patchwork.kernel.org/patch/10384585/
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3601x.c | 622
3 files changed, 632 insertions(+)
create mode 100644 drivers/leds/leds-lm3601x.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2c896c0e69e1..50ae536f343f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -145,6 +145,15 @@ config LEDS_LM3692X
This option enables support for the TI LM3692x family
of white LED string drivers used for backlighting.
+config LEDS_LM3601X
+ tristate "LED support for LM3601x Chips"
+ depends on LEDS_CLASS && I2C && OF
+ depends on LEDS_CLASS_FLASH
+ select REGMAP_I2C
+ help
+ This option enables support for the TI LM3601x family
+ of flash, torch and indicator classes.
+
config LEDS_LOCOMO
tristate "LED Support for Locomo device"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 91eca81cae82..b79807fe1b67 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
+obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c
new file mode 100644
index ..3c00886fbc7a
--- /dev/null
+++ b/drivers/leds/leds-lm3601x.c
@@ -0,0 +1,622 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Flash and torch driver for Texas Instruments LM3601X LED
+ * Flash driver chip family
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LM3601X_LED_TORCH 0x0
+#define LM3601X_LED_STROBE 0x1
+#define LM3601X_LED_IR 0x2
+
+/* Registers */
+#define LM3601X_ENABLE_REG 0x01
+#define LM3601X_CFG_REG0x02
+#define LM3601X_LED_FLASH_REG 0x03
+#define LM3601X_LED_TORCH_REG 0x04
+#define LM3601X_FLAGS_REG 0x05
+#define LM3601X_DEV_ID_REG 0x06
+
+#define LM3601X_SW_RESET BIT(7)
+
+/* Enable Mode bits */
+#define LM3601X_MODE_STANDBY 0x00
+#define LM3601X_MODE_IR_DRVBIT(0)
+#define LM3601X_MODE_TORCH BIT(1)
+#define LM3601X_MODE_STROBE(BIT(0) | BIT(1))
+#define LM3601X_STRB_ENBIT(2)
+#define LM3601X_STRB_LVL_TRIG ~BIT(3)
+#define LM3601X_STRB_EDGE_TRIG BIT(3)
+#define LM3601X_IVFM_ENBIT(4)
+
+#define LM36010_BOOST_LIMIT_19 ~BIT(5)
+#define LM36010_BOOST_LIMIT_28 BIT(5)
+#define LM36010_BOOST_FREQ_2MHZ~BIT(6)
+#define LM36010_BOOST_FREQ_4MHZBIT(6)
+#define LM36010_BOOST_MODE_NORM~BIT(7)
+#define LM36010_BOOST_MODE_PASSBIT(7)
+
+/* Flag Mask */
+#define LM3601X_FLASH_TIME_OUT BIT(0)
+#define LM3601X_UVLO_FAULT BIT(1)
+#define LM3601X_THERM_SHUTDOWN BIT(2)
+#define LM3601X_THERM_CURR BIT(3)
+#define LM36010_CURR_LIMIT BIT(4)
+#define LM3601X_SHORT_FAULTBIT(5)
+#define LM3601X_IVFM_TRIP BIT(6)
+#define LM36010_OVP_FAULT BIT(7)
+
+#define LM3601X_MIN_TORCH_I_UA 2400
+#define LM3601X_MIN_STROBE_I_MA11
+
+#define LM3601X_TIMEOUT_MASK 0x1e
+#define LM3601X_ENABLE_MASK0x03
+
+enum lm3601x_type {
+ CHIP_LM36010 = 0,
+ CHIP_LM36011,
+};
+
+/**
+ * struct lm3601x_max_timeouts -
+ * @timeout: timeout value in ms
+ * @regval: the value of the register to write
+ */
+struct lm3601x_max_timeouts {
+
Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
Pavel
On 05/10/2018 01:54 PM, Pavel Machek wrote:
> Hi!
>
>> Introduce the device tree bindings for the lm3601x
>> family of LED torch, flash and IR drivers.
>>
>> Signed-off-by: Dan Murphy
>
> Better, thanks.
>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>> @@ -0,0 +1,50 @@
>> +* Texas Instruments - lm3601x Single-LED Flash Driver
>
> Ok, so is it single-LED driver, or can it driver ir & white LEDs at
> the same time?
It is a single LED driver. It can drive a Torch white LED or IR LED
indefinitely or if the driver
is programmed to strobe mode the driver will drive the configured LED for the
flash timeout specified.
Basically a flash and a flash light. IR or White LED.
>
>> +Example:
>> +led-controller@64 {
>> +compatible = "ti,lm36010";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +reg = <0x64>;
>> +
>> +led@0 {
>> +reg = <0>;
>> +label = "white:torch";
>> +led-max-microamp = <1>;
>> +};
>> +
>> +led@1 {
>> +reg = <1>;
>> +label = "white:flash";
>> +flash-max-microamp = <1>;
>> +flash-max-timeout-us = <800>;
>> +};
>
> Is this realistic config? I'd expect flash to use more power than
> torch, and would expect longer timeout than 0.8msec.
Timeout in the spreadsheet is ms I will update this example and code
Current in the spreadsheet is mA I will update this example and code
>
> Also.. if this is physically one white LED, it should not be
> spread over reg = <0> and reg = <1>...
If the torch LED and strobe LED are the same LED how do I expose them both to
the user.
It is up to consumer to configure the required interfaces they want to expose
to the filesystem.
Maybe they don't want the strobe feature and just want LED on/off and switch
between IR and White.
The IR is driven via a different output pin.
Dan
>
> Best regards,
> Pavel
>
--
--
Dan Murphy
Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
On 05/10/2018 02:06 PM, Dan Murphy wrote:
> Pavel
>
> On 05/10/2018 01:54 PM, Pavel Machek wrote:
>> Hi!
>>
>>> Introduce the device tree bindings for the lm3601x
>>> family of LED torch, flash and IR drivers.
>>>
>>> Signed-off-by: Dan Murphy
>>
>> Better, thanks.
>>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>>> @@ -0,0 +1,50 @@
>>> +* Texas Instruments - lm3601x Single-LED Flash Driver
>>
>> Ok, so is it single-LED driver, or can it driver ir & white LEDs at
>> the same time?
>
> It is a single LED driver. It can drive a Torch white LED or IR LED
> indefinitely or if the driver
> is programmed to strobe mode the driver will drive the configured LED for the
> flash timeout specified.
>
> Basically a flash and a flash light. IR or White LED.
>
>
>>
>>> +Example:
>>> +led-controller@64 {
>>> + compatible = "ti,lm36010";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0x64>;
>>> +
>>> + led@0 {
>>> + reg = <0>;
>>> + label = "white:torch";
>>> + led-max-microamp = <1>;
>>> + };
>>> +
>>> + led@1 {
>>> + reg = <1>;
>>> + label = "white:flash";
>>> + flash-max-microamp = <1>;
>>> + flash-max-timeout-us = <800>;
>>> + };
>>
>> Is this realistic config? I'd expect flash to use more power than
>> torch, and would expect longer timeout than 0.8msec.
>
> Timeout in the spreadsheet is ms I will update this example and code
> Current in the spreadsheet is mA I will update this example and code
>
>>
>> Also.. if this is physically one white LED, it should not be
>> spread over reg = <0> and reg = <1>...
>
> If the torch LED and strobe LED are the same LED how do I expose them both to
> the user.
> It is up to consumer to configure the required interfaces they want to expose
> to the filesystem.
>
> Maybe they don't want the strobe feature and just want LED on/off and switch
> between IR and White.
>
> The IR is driven via a different output pin.
Correction. There is only one LED drive pin. The mode selected determines how
the device will drive the
LED. So you may have one device to drive a Torch and another device to drive
the LED.
Strobe is available in either case but not always required if strobe is not
desired by the customer hence
why I have a separate DT node for it.
Dan
>
> Dan
>
>>
>> Best regards,
>> Pavel
>>
>
>
--
--
Dan Murphy
Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Jacek Thanks for the review On 05/10/2018 03:48 PM, Jacek Anaszewski wrote: > Hi Dan, > > Thank you for the patch. > > On 05/10/2018 07:47 PM, Dan Murphy wrote: >> Introduce the family of LED devices that can >> drive a torch, strobe or IR LED. >> >> The LED driver can be configured with a strobe >> timer to execute a strobe flash. The IR LED >> brightness is controlled via the torch brightness >> register. >> >> The data sheet for each the LM36010 and LM36011 >> LED drivers can be found here: >> http://www.ti.com/product/LM36010 >> http://www.ti.com/product/LM36011 >> >> Signed-off-by: Dan Murphy >> --- >> >> v5 - Fixed magic numbers, change reg cache type, added of_put_node to release >> the dt node ref, and I did not change the remove function to leave the LED >> in its >> state on driver removal - https://patchwork.kernel.org/patch/10391741/ >> >> v4 - Fixed Cocci issue using ARRAY_SIZE - >> https://patchwork.kernel.org/patch/10389259/ >> v3 - removed wildcard dt compatible, fixed copyright, fixed struct doc, >> removed >> RO registers from default, added regmap volatile for FLAGS_REG, updated >> regmap cache type, >> fixed unlock and extra semi colon in strobe_set, removed unnecessary out >> label >> in led register and fixed checking of the ret in brightness_set - >> https://patchwork.kernel.org/patch/10386243/ >> v2 - Fixed kbuild issue and removed unused cdev_strobe - >> https://patchwork.kernel.org/patch/10384585/ >> >> >> drivers/leds/Kconfig | 9 + >> drivers/leds/Makefile | 1 + >> drivers/leds/leds-lm3601x.c | 622 >> 3 files changed, 632 insertions(+) >> create mode 100644 drivers/leds/leds-lm3601x.c >> >> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig >> index 2c896c0e69e1..50ae536f343f 100644 >> --- a/drivers/leds/Kconfig >> +++ b/drivers/leds/Kconfig >> @@ -145,6 +145,15 @@ config LEDS_LM3692X >> This option enables support for the TI LM3692x family >> of white LED string drivers used for backlighting. >> +config LEDS_LM3601X >> + tristate "LED support for LM3601x Chips" >> + depends on LEDS_CLASS && I2C && OF >> + depends on LEDS_CLASS_FLASH >> + select REGMAP_I2C >> + help >> + This option enables support for the TI LM3601x family >> + of flash, torch and indicator classes. >> + >> config LEDS_LOCOMO >> tristate "LED Support for Locomo device" >> depends on LEDS_CLASS >> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile >> index 91eca81cae82..b79807fe1b67 100644 >> --- a/drivers/leds/Makefile >> +++ b/drivers/leds/Makefile >> @@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o >> obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o >> obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o >> obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o >> +obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o >> # LED SPI Drivers >> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o >> diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c >> new file mode 100644 >> index ..3c00886fbc7a >> --- /dev/null >> +++ b/drivers/leds/leds-lm3601x.c >> @@ -0,0 +1,622 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Flash and torch driver for Texas Instruments LM3601X LED >> + * Flash driver chip family >> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ >> + */ > > Please use uniform "//" comment style here. Is this a LEDs only requirement because I checked a few other files and this is how the license and header is presented. Unless I missed some new change to source code headers. And the documentation does not dictate any change to this. > >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define LM3601X_LED_TORCH 0x0 >> +#define LM3601X_LED_STROBE 0x1 >> +#define LM3601X_LED_IR 0x2 >> + >> +/* Registers */ >> +#define LM3601X_ENABLE_REG 0x01 >> +#define LM3601X_CFG_REG 0x02 >> +#define LM3601X_LED_FLASH_REG 0x03 >> +#define LM3601X_LED_TORCH_REG 0x04 >> +#define LM3601X_FLAGS_REG 0x05 >> +#define LM3601X_DEV_ID_REG 0x06 >> + >> +#define LM3601X_SW_RESET BIT(7) &
Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
Jacek
Thanks for the review
On 05/10/2018 03:17 PM, Jacek Anaszewski wrote:
> Hi Dan,
>
> On 05/10/2018 09:10 PM, Dan Murphy wrote:
>> On 05/10/2018 02:06 PM, Dan Murphy wrote:
>>> Pavel
>>>
>>> On 05/10/2018 01:54 PM, Pavel Machek wrote:
>>>> Hi!
>>>>
>>>>> Introduce the device tree bindings for the lm3601x
>>>>> family of LED torch, flash and IR drivers.
>>>>>
>>>>> Signed-off-by: Dan Murphy
>>>>
>>>> Better, thanks.
>>>>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
>>>>> @@ -0,0 +1,50 @@
>>>>> +* Texas Instruments - lm3601x Single-LED Flash Driver
>>>>
>>>> Ok, so is it single-LED driver, or can it driver ir & white LEDs at
>>>> the same time?
>>>
>>> It is a single LED driver. It can drive a Torch white LED or IR LED
>>> indefinitely or if the driver
>>> is programmed to strobe mode the driver will drive the configured LED for
>>> the flash timeout specified.
>>>
>>> Basically a flash and a flash light. IR or White LED.
>>>
>>>
>>>>
>>>>> +Example:
>>>>> +led-controller@64 {
>>>>> + compatible = "ti,lm36010";
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>> + reg = <0x64>;
>>>>> +
>>>>> + led@0 {
>>>>> + reg = <0>;
>>>>> + label = "white:torch";
>>>>> + led-max-microamp = <1>;
>>>>> + };
>>>>> +
>>>>> + led@1 {
>>>>> + reg = <1>;
>>>>> + label = "white:flash";
>>>>> + flash-max-microamp = <1>;
>>>>> + flash-max-timeout-us = <800>;
>>>>> + };
>>>>
>>>> Is this realistic config? I'd expect flash to use more power than
>>>> torch, and would expect longer timeout than 0.8msec.
>>>
>>> Timeout in the spreadsheet is ms I will update this example and code
>>> Current in the spreadsheet is mA I will update this example and code
>>>
>>>>
>>>> Also.. if this is physically one white LED, it should not be
>>>> spread over reg = <0> and reg = <1>...
>>>
>>> If the torch LED and strobe LED are the same LED how do I expose them both
>>> to the user.
>>> It is up to consumer to configure the required interfaces they want to
>>> expose to the filesystem.
>
> LED flash class interface is prepared for it.
> led_clasdev_flash_register() internally calls led_classdev_register(),
> so there is brightness file available for torch related operations.
Yes the flash class may handle this and expose the brightness node but the HW
has two different registers to set the
corresponding brightness so one set brightness node does not work.
There is no way to differentiate between the strobe brightness (register 4) and
the torch brightness (register 3).
When the enable register is written the driver will read the corresponding
register and set
the current for the LED.
This is why I separated out the strobe from the torch into 2 different LED
nodes.
I cannot seem to find the data sheet on line for the max77693 so I cannot
verify that the device only has
a single brightness register for both torch and strobe.
>
>>> Maybe they don't want the strobe feature and just want LED on/off and
>>> switch between IR and White.
>>>
>>> The IR is driven via a different output pin.
>>
>> Correction. There is only one LED drive pin. The mode selected determines
>> how the device will drive the
>> LED. So you may have one device to drive a Torch and another device to
>> drive the LED.
>
> But only one type of LED can be soldered on the board at a time, right?
> If yes, then this is clearly a DT related configuration, and only
> one child DT node should be defined for given board.
But see above. There is not a clean way to expose the torch/ir and strobe
separately.
Dan
>
>> Strobe is available in either case but not always required if strobe is not
>> desired by the customer hence
>> why I have a separate DT node for it.
>>
>> Dan
>>
>>>
>>> Dan
>>>
>>>>
>>>> Best regards,
>>>> Pavel
>>>>
>>>
>>>
>>
>>
>
--
--
Dan Murphy
[PATCH v3] net: phy: DP83TC811: Introduce support for the DP83TC811 phy
Add support for the DP83811 phy.
The DP83811 supports both rgmii and sgmii interfaces.
There are 2 part numbers for this the DP83TC811R does not
reliably support the SGMII interface but the DP83TC811S will.
There is not a way to differentiate these parts from the
hardware or register set. So this is controlled via the DT
to indicate which phy mode is required. Or the part can be
strapped to a certain interface.
Data sheet can be found here:
http://www.ti.com/product/DP83TC811S-Q1/description
http://www.ti.com/product/DP83TC811R-Q1/description
Signed-off-by: Dan Murphy
---
v3 - Variable length alignment - https://patchwork.kernel.org/patch/10389657/
v2 - Remove extra config_init in reset, update config_init call back function
fix a checkpatch alignment issue, add SGMII check in autoneg api -
https://patchwork.kernel.org/patch/10389323/
drivers/net/phy/Kconfig | 5 +
drivers/net/phy/Makefile| 1 +
drivers/net/phy/dp83tc811.c | 347
3 files changed, 353 insertions(+)
create mode 100644 drivers/net/phy/dp83tc811.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index bdfbabb86ee0..810140a9e114 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -285,6 +285,11 @@ config DP83822_PHY
---help---
Supports the DP83822 PHY.
+config DP83TC811_PHY
+ tristate "Texas Instruments DP83TC822 PHY"
+ ---help---
+ Supports the DP83TC822 PHY.
+
config DP83848_PHY
tristate "Texas Instruments DP83848 PHY"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 01acbcb2c798..00445b61a9a8 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_CORTINA_PHY) += cortina.o
obj-$(CONFIG_DAVICOM_PHY) += davicom.o
obj-$(CONFIG_DP83640_PHY) += dp83640.o
obj-$(CONFIG_DP83822_PHY) += dp83822.o
+obj-$(CONFIG_DP83TC811_PHY)+= dp83tc811.o
obj-$(CONFIG_DP83848_PHY) += dp83848.o
obj-$(CONFIG_DP83867_PHY) += dp83867.o
obj-$(CONFIG_FIXED_PHY)+= fixed_phy.o
diff --git a/drivers/net/phy/dp83tc811.c b/drivers/net/phy/dp83tc811.c
new file mode 100644
index ..081d99aa3985
--- /dev/null
+++ b/drivers/net/phy/dp83tc811.c
@@ -0,0 +1,347 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the Texas Instruments DP83TC811 PHY
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DP83TC811_PHY_ID 0x2000a253
+#define DP83811_DEVADDR0x1f
+
+#define MII_DP83811_SGMII_CTRL 0x09
+#define MII_DP83811_INT_STAT1 0x12
+#define MII_DP83811_INT_STAT2 0x13
+#define MII_DP83811_RESET_CTRL 0x1f
+
+#define DP83811_HW_RESET BIT(15)
+#define DP83811_SW_RESET BIT(14)
+
+/* INT_STAT1 bits */
+#define DP83811_RX_ERR_HF_INT_EN BIT(0)
+#define DP83811_MS_TRAINING_INT_EN BIT(1)
+#define DP83811_ANEG_COMPLETE_INT_EN BIT(2)
+#define DP83811_ESD_EVENT_INT_EN BIT(3)
+#define DP83811_WOL_INT_EN BIT(4)
+#define DP83811_LINK_STAT_INT_EN BIT(5)
+#define DP83811_ENERGY_DET_INT_EN BIT(6)
+#define DP83811_LINK_QUAL_INT_EN BIT(7)
+
+/* INT_STAT2 bits */
+#define DP83811_JABBER_DET_INT_EN BIT(0)
+#define DP83811_POLARITY_INT_ENBIT(1)
+#define DP83811_SLEEP_MODE_INT_EN BIT(2)
+#define DP83811_OVERTEMP_INT_ENBIT(3)
+#define DP83811_OVERVOLTAGE_INT_EN BIT(6)
+#define DP83811_UNDERVOLTAGE_INT_ENBIT(7)
+
+#define MII_DP83811_RXSOP1 0x04a5
+#define MII_DP83811_RXSOP2 0x04a6
+#define MII_DP83811_RXSOP3 0x04a7
+
+/* WoL Registers */
+#define MII_DP83811_WOL_CFG0x04a0
+#define MII_DP83811_WOL_STAT 0x04a1
+#define MII_DP83811_WOL_DA10x04a2
+#define MII_DP83811_WOL_DA20x04a3
+#define MII_DP83811_WOL_DA30x04a4
+
+/* WoL bits */
+#define DP83811_WOL_MAGIC_EN BIT(0)
+#define DP83811_WOL_SECURE_ON BIT(5)
+#define DP83811_WOL_EN BIT(7)
+#define DP83811_WOL_INDICATION_SEL BIT(8)
+#define DP83811_WOL_CLR_INDICATION BIT(11)
+
+/* SGMII CTRL bits */
+#define DP83811_TDR_AUTO BIT(8)
+#define DP83811_SGMII_EN BIT(12)
+#define DP83811_SGMII_AUTO_NEG_EN BIT(13)
+#define DP83811_SGMII_TX_ERR_DIS BIT(14)
+#define DP83811_SGMII_SOFT_RESET BIT(15)
+
+static int dp83811_ack_interrupt(struct phy_device *phydev)
+{
+ int err;
+
+ err = phy_read(phydev, MII_DP83811_INT_STAT1);
+ if (err < 0)
+ return err;
+
+ err = phy_read(phydev, MII_DP83811_INT_STAT2);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static int dp83811_set_wol(struct phy_device *phydev,
+ struct ethtool_wolinfo *wol)
+{
+ struct net_device *ndev = phydev->attached_dev;
+ con
Re: [PATCH v3] net: phy: DP83TC811: Introduce support for the DP83TC811 phy
Andrew On 05/11/2018 01:30 PM, Andrew Lunn wrote: > On Fri, May 11, 2018 at 01:08:19PM -0500, Dan Murphy wrote: >> Add support for the DP83811 phy. >> >> The DP83811 supports both rgmii and sgmii interfaces. >> There are 2 part numbers for this the DP83TC811R does not >> reliably support the SGMII interface but the DP83TC811S will. >> >> There is not a way to differentiate these parts from the >> hardware or register set. So this is controlled via the DT >> to indicate which phy mode is required. Or the part can be >> strapped to a certain interface. >> >> Data sheet can be found here: >> http://www.ti.com/product/DP83TC811S-Q1/description >> http://www.ti.com/product/DP83TC811R-Q1/description >> >> Signed-off-by: Dan Murphy > > Hi Dan > > It is normal to add any Reviewed-by, or Tested-by: tags you received, > so long as you don't make major changes. > Thanks for the reminder. I usually add them if I get them explicitly stated in the review. I have not seen any Reviewed-by or Tested-by tags in any of the replies for the patch. But I may have missed it. Dan > Andrew > -- -- Dan Murphy
Re: [PATCH v6 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
On 05/16/2018 03:10 PM, Jacek Anaszewski wrote: > Dan, > > On 05/15/2018 11:29 PM, Dan Murphy wrote: >> Jacek >> >> On 05/15/2018 04:13 PM, Jacek Anaszewski wrote: >>> Hi Dan, >>> >>> Thanks for the update. >>> >>> On 05/15/2018 05:43 PM, Dan Murphy wrote: >>>> Introduce the device tree bindings for the lm3601x >>>> family of LED torch, flash and IR drivers. >>>> >>>> Signed-off-by: Dan Murphy >>>> --- >>>> >>>> v6 - Removed multiple led child nodes, fixed example to display micro >>>> ranges >>>> for corresponding child nodes and added led-sources to define the current >>>> driver - >>>> https://patchwork.kernel.org/patch/10392121/ >>>> >>>> v5 - No changes - https://patchwork.kernel.org/patch/10391743/ >>>> v4 - Added " " around "=", changed strobe to flash on label, removed >>>> "support and >>>> register" comment and change ir lable to ir:torch - See v2 patchworks for >>>> comments >>>> v3 - Removed wildcard compatible - >>>> https://patchwork.kernel.org/patch/10386241/ >>>> v2 - No changes - https://patchwork.kernel.org/patch/10384587/ >>>> >>>> .../devicetree/bindings/leds/leds-lm3601x.txt | 47 +++ >>>> 1 file changed, 47 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/leds/leds-lm3601x.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt >>>> b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt >>>> new file mode 100644 >>>> index ..27930a89e9a5 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt >>>> @@ -0,0 +1,47 @@ >>>> +* Texas Instruments - lm3601x Single-LED Flash Driver >>>> + >>>> +The LM3601X are ultra-small LED flash drivers that >>>> +provide a high level of adjustability. >>>> + >>>> +Required properties: >>>> + - compatible : Can be one of the following >>>> + "ti,lm36010" >>>> + "ti,lm36011" >>>> + - reg : I2C slave address >>>> + - #address-cells : 1 >>>> + - #size-cells : 0 >>>> + >>>> +Required child properties: >>>> + - reg : 0 >>>> + - led-sources: 0 - Indicates a IR mode >>>> + 1 - Indicates a Torch (white LED) mode >>> >>> You don't need led-sources at all. Please use reg as in >>> the previous version. led-sources is useful for describing >>> more complex arrangements. Here reg will do. >> >> OK. Thought we would keep consistent with the max IC. >> >>> >>>> + >>>> +Required properties for flash LED child nodes: >>>> + See Documentation/devicetree/bindings/leds/common.txt >>>> + - flash-max-microamp : Range from 11mA -> 1.5A >>>> + - flash-max-timeout-us : Range from 40ms -> 1600ms >>>> + - led-max-microamp : Range from 2.4mA -> 376mA >>> >>> Please give also a step in the format like below >>> (taken from max77693): >>> >>> Valid values: 62500 - 100, step by 62500 (rounded down) >> >> I would do this but the step is not linear. The step is 40ms from 40 -> 400. >> after that the step goes to 200ms from 400->1600. >> >> same with the current ranges. > > If you're going to apply Andy's formula in the driver, then you can > present it also here. Anyway, please avoid using non-standard "->" > symbol in favor of "to" if you're using "from". > OK I will. I have not decided if I am going to apply the formula or not. I am still trying to process all the comments and determine what is preference and what is beneficial. > Or even better I propose to list allowed values - there are not > so many of them. > I will figure that out based on what I do with the driver. Been busy doing internal work today Dan -- -- Dan Murphy
Re: [PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Andy
The first response is to Jacek the rest are addressed to you
On 05/15/2018 05:24 PM, Andy Shevchenko wrote:
> On Wed, May 16, 2018 at 1:08 AM, Dan Murphy wrote:
>> On 05/15/2018 04:56 PM, Andy Shevchenko wrote:
>>> On Tue, May 15, 2018 at 6:43 PM, Dan Murphy wrote:
>
>>>> + depends on LEDS_CLASS && I2C && OF
>>>
>>> What is OF specific in this driver?
>>
>> as3645a_led_class_setup has a "of" dependency
>
> So what? Is it called from this driver or?
>
Jacek
Do you have a preference about the use of "of" calls over the device_property
calls?
I know Andy is pushing this for IoT and gave a good presentation on it last
year on
common mistakes. Not sure this is a "common mistake" but more of a overall
Linux compatibility issue
between x86 and ARM using two different configuration methods.
Since these lighting drivers are agnostic to the processor maybe we should
adopt that philosophy.
I have no problem being the example driver on that.
>
>>>> +static const struct lm3601x_max_timeouts strobe_timeouts[] = {
>>>> + { 4, 0x00 },
>>>> + { 8, 0x01 },
>>>> + { 12, 0x02 },
>>>> + { 16, 0x03 },
>>>> + { 20, 0x04 },
>>>> + { 24, 0x05 },
>>>> + { 28, 0x06 },
>>>> + { 32, 0x07 },
>>>> + { 36, 0x08 },
>>>> + { 40, 0x09 },
>>>> + { 60, 0x0a },
>>>> + { 80, 0x0b },
>>>> + { 100, 0x0c },
>>>> + { 120, 0x0d },
>>>> + { 140, 0x0e },
>>>> + { 160, 0x0f },
>>>
>>> Huh?!
>>
>> Please give comments that actually mean something other wise I will opt to
>> ignore them.
>
> I did below.
Sort of. "So what?" and "Huh" are not really a technical comments. I can tell
from your LVEE presentation that
you have a passion for making the kernel better. That is awesome but if we try
to make the code perfect everytime no code will
ever get merged. And we are human and we will miss coding issues and make
mistakes.
>
>>> strobe_timeout = (x + 1) * 40 * MSECS_IN_SEC;
>>
>> Not sure what equation you are trying to point out here. But if you are
>> trying to apply
>> a timeout step you cannot do this with this part. As pointed out in the DT
>> doc the timeout
>> step is not linear.
>
> Yeah, I know people are more than often too lazy to think.
Well this is why I put the table in. It is not laziness on my part as I try to
add clarity for
our newbies or productization engineers, translation/lookup tables are not as
bad as you think.
I am fully aware that this bloats the data section of the image and has
negative impacts
on IoT small memory foot print devices.
>
> if (x < 9)
> strobe_timeout = (x + 1) * 40 * MSECS_IN_SEC;
> else
> strobe_timeout = (400 + (x - 9) * 200) * MSECS_IN_SEC;
>
Not sure if this will produce the register value I am looking for. I have to
run through the
algorithim. The idea is to take in the timeout and get the reg value to
program.
If it yields the expected output, or with a modified equation, then I can pull
it in.
>>>> + brightness_val = (brightness/2);
>>>
>>> Spaces.
>>
>> Not sure what this means checkpatch was clean
>
> Even besides missed whispaces it has redundant parens.
>
> checkpatch is not a silver bullet to get your code clean and nice.
>
True but it is the tool many maintainers use (sometimes) to ensure clean and
nice.
I am still not see the extra spaces here but I do see the unneeded parens.
>>> This is return led_...();
>>
>> That is a preference. It does not have to be that way.
>
> What do you mean? We do not appreciate +LOCs for no (or even nagative!)
> benefit.
>
Again for non-IoT cases this would be fine but if we are striving to meet IoT
size
requirements I do understand your concern.
>>>> + ret = of_property_read_string(led->led_node, "label",
>>>> );
>>>
>>> device_property_...();
>>
>> It can be if the maintainer is requesting this.
>
> Jacek, if you need rationale behind this comment it's here: the driver
> has nothing DT specific and getting rid of OF centric programming
> allows to reuse the driver on non-DT platforms w/o touching a source
> code.
>
See below
>> Is the trend to move to these functions?
>
> See above.
See below
>
>> Most drivers use the &quo
Re: [PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Jacek and Andy
On 05/16/2018 04:02 PM, Jacek Anaszewski wrote:
> Hi Andy and Dan,
>
I will make all the changes then. I don't want to go through and ack each one.
Thanks for the guidance and the reviews.
It will take a couple days to find all the comments and get this all fixed up.
Dan
> On 05/16/2018 12:24 AM, Andy Shevchenko wrote:
>> On Wed, May 16, 2018 at 1:08 AM, Dan Murphy wrote:
>>> On 05/15/2018 04:56 PM, Andy Shevchenko wrote:
>>>> On Tue, May 15, 2018 at 6:43 PM, Dan Murphy wrote:
>>
>>>>> + depends on LEDS_CLASS && I2C && OF
>>>>
>>>> What is OF specific in this driver?
>>>
>>> as3645a_led_class_setup has a "of" dependency
>>
>> So what? Is it called from this driver or?
>>
>>
>>>>> +static const struct lm3601x_max_timeouts strobe_timeouts[] = {
>>>>> + { 4, 0x00 },
>>>>> + { 8, 0x01 },
>>>>> + { 12, 0x02 },
>>>>> + { 16, 0x03 },
>>>>> + { 20, 0x04 },
>>>>> + { 24, 0x05 },
>>>>> + { 28, 0x06 },
>>>>> + { 32, 0x07 },
>>>>> + { 36, 0x08 },
>>>>> + { 40, 0x09 },
>>>>> + { 60, 0x0a },
>>>>> + { 80, 0x0b },
>>>>> + { 100, 0x0c },
>>>>> + { 120, 0x0d },
>>>>> + { 140, 0x0e },
>>>>> + { 160, 0x0f },
>>>>
>>>> Huh?!
>>>
>>> Please give comments that actually mean something other wise I will opt to
>>> ignore them.
>>
>> I did below.
>>
>>>> strobe_timeout = (x + 1) * 40 * MSECS_IN_SEC;
>>>
>>> Not sure what equation you are trying to point out here. But if you are
>>> trying to apply
>>> a timeout step you cannot do this with this part. As pointed out in the DT
>>> doc the timeout
>>> step is not linear.
>>
>> Yeah, I know people are more than often too lazy to think.
>>
>> if (x < 9)
>> strobe_timeout = (x + 1) * 40 * MSECS_IN_SEC;
>> else
>> strobe_timeout = (400 + (x - 9) * 200) * MSECS_IN_SEC;
>>
>
> I like the idea.
>
>>>>> + brightness_val = (brightness/2);
>>>>
>>>> Spaces.
>>>
>>> Not sure what this means checkpatch was clean
>>
>> Even besides missed whispaces it has redundant parens.
>>
>> checkpatch is not a silver bullet to get your code clean and nice.
>>
>>>> This is return led_...();
>>>
>>> That is a preference. It does not have to be that way.
>
> I missed that. Dan, please follow Andy's advise.
>
>>
>> What do you mean? We do not appreciate +LOCs for no (or even nagative!)
>> benefit.
>>
>>>>> + ret = of_property_read_string(led->led_node, "label",
>>>>> );
>>>>
>>>> device_property_...();
>>>
>>> It can be if the maintainer is requesting this.
>>
>> Jacek, if you need rationale behind this comment it's here: the driver
>> has nothing DT specific and getting rid of OF centric programming
>> allows to reuse the driver on non-DT platforms w/o touching a source
>> code.
>
> It has an added value, so yes, let's use it as a standard approach
> from now on.
>
>>> Is the trend to move to these functions?
>>
>> See above.
>>
>>> Most drivers use the "of" calls.
>>
>> So what?
>>
>>
>>>>> + if (!ret)
>>>>
>>>> if (ret) sounds more natural. And better just to split
>>>>
>>>>> + snprintf(led->led_name, sizeof(led->led_name),
>>>>> + "%s:%s", led->led_node->name, name);
>>>>> + else
>>>>> + snprintf(led->led_name, sizeof(led->led_name),
>>>>> + "%s:torch", led->led_node->name);
>>>>
>>>> const char *tmp;
>>>>
>>>> ret = device_property_read_...();
>>>> if (ret)
>>>> tmp = ...
>>>> sprintf(...);
>
> We're no longer taking devicename section of a LED class device name
> from DT, so it will look differently anyway.
>
>> No comments on this?
>>
>>>>> + led = devm_kzalloc(>dev,
>>>>> + sizeof(struct lm3601x_led), GFP_KERNEL);
>>>>
>>>> sizeof(*led) and one line in the result
>>
>> And this?
>
> Ack.
>
>>
>>>>> + { },
>>>>
>>>> Terminators better w/o comma.
>>>
>>> Looking at other drivers adding comma's on the sentinel is accepted. See
>>> the as3645a driver
>>
>> So what?
>>
>> Terminator at compile time even better.
>>
>>>>> + {},
>>>>
>>>> Ditto.
>>>
>>> See above
>>
>> See above.
>>
>
--
--
Dan Murphy
Re: [PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Jacek and Andy
On 05/16/2018 04:13 PM, Dan Murphy wrote:
> Jacek and Andy
>
> On 05/16/2018 04:02 PM, Jacek Anaszewski wrote:
>> Hi Andy and Dan,
>>
>
> I will make all the changes then. I don't want to go through and ack each
> one.
>
Let me clarify. I will make all the change Jacek has guided on. There is still
a
terminator comma vs no comma comment that needs disposition at the end of this
file.
Dan
> Thanks for the guidance and the reviews.
>
> It will take a couple days to find all the comments and get this all fixed up.
>
> Dan
>
>> On 05/16/2018 12:24 AM, Andy Shevchenko wrote:
>>> On Wed, May 16, 2018 at 1:08 AM, Dan Murphy wrote:
>>>> On 05/15/2018 04:56 PM, Andy Shevchenko wrote:
>>>>> On Tue, May 15, 2018 at 6:43 PM, Dan Murphy wrote:
>>>
>>>>>> + depends on LEDS_CLASS && I2C && OF
>>>>>
>>>>> What is OF specific in this driver?
>>>>
>>>> as3645a_led_class_setup has a "of" dependency
>>>
>>> So what? Is it called from this driver or?
>>>
>>>
>>>>>> +static const struct lm3601x_max_timeouts strobe_timeouts[] = {
>>>>>> + { 4, 0x00 },
>>>>>> + { 8, 0x01 },
>>>>>> + { 12, 0x02 },
>>>>>> + { 16, 0x03 },
>>>>>> + { 20, 0x04 },
>>>>>> + { 24, 0x05 },
>>>>>> + { 28, 0x06 },
>>>>>> + { 32, 0x07 },
>>>>>> + { 36, 0x08 },
>>>>>> + { 40, 0x09 },
>>>>>> + { 60, 0x0a },
>>>>>> + { 80, 0x0b },
>>>>>> + { 100, 0x0c },
>>>>>> + { 120, 0x0d },
>>>>>> + { 140, 0x0e },
>>>>>> + { 160, 0x0f },
>>>>>
>>>>> Huh?!
>>>>
>>>> Please give comments that actually mean something other wise I will opt to
>>>> ignore them.
>>>
>>> I did below.
>>>
>>>>> strobe_timeout = (x + 1) * 40 * MSECS_IN_SEC;
>>>>
>>>> Not sure what equation you are trying to point out here. But if you are
>>>> trying to apply
>>>> a timeout step you cannot do this with this part. As pointed out in the
>>>> DT doc the timeout
>>>> step is not linear.
>>>
>>> Yeah, I know people are more than often too lazy to think.
>>>
>>> if (x < 9)
>>> strobe_timeout = (x + 1) * 40 * MSECS_IN_SEC;
>>> else
>>> strobe_timeout = (400 + (x - 9) * 200) * MSECS_IN_SEC;
>>>
>>
>> I like the idea.
>>
>>>>>> + brightness_val = (brightness/2);
>>>>>
>>>>> Spaces.
>>>>
>>>> Not sure what this means checkpatch was clean
>>>
>>> Even besides missed whispaces it has redundant parens.
>>>
>>> checkpatch is not a silver bullet to get your code clean and nice.
>>>
>>>>> This is return led_...();
>>>>
>>>> That is a preference. It does not have to be that way.
>>
>> I missed that. Dan, please follow Andy's advise.
>>
>>>
>>> What do you mean? We do not appreciate +LOCs for no (or even nagative!)
>>> benefit.
>>>
>>>>>> + ret = of_property_read_string(led->led_node, "label",
>>>>>> );
>>>>>
>>>>> device_property_...();
>>>>
>>>> It can be if the maintainer is requesting this.
>>>
>>> Jacek, if you need rationale behind this comment it's here: the driver
>>> has nothing DT specific and getting rid of OF centric programming
>>> allows to reuse the driver on non-DT platforms w/o touching a source
>>> code.
>>
>> It has an added value, so yes, let's use it as a standard approach
>> from now on.
>>
>>>> Is the trend to move to these functions?
>>>
>>> See above.
>>>
>>>> Most drivers use the "of" calls.
>>>
>>> So what?
>>>
>>>
>>>>>> + if (!ret)
>>>>>
>>>>> if (ret) sounds more natural. And better just to split
>>>>>
>>>>>> + snprintf(led->led_name, sizeof(led->led_name),
>>>>>> + "%s:%s", led->led_node->name, name);
>>>>>> + else
>>>>>> + snprintf(led->led_name, sizeof(led->led_name),
>>>>>> + "%s:torch", led->led_node->name);
>>>>>
>>>>> const char *tmp;
>>>>>
>>>>> ret = device_property_read_...();
>>>>> if (ret)
>>>>> tmp = ...
>>>>> sprintf(...);
>>
>> We're no longer taking devicename section of a LED class device name
>> from DT, so it will look differently anyway.
>>
>>> No comments on this?
>>>
>>>>>> + led = devm_kzalloc(>dev,
>>>>>> + sizeof(struct lm3601x_led), GFP_KERNEL);
>>>>>
>>>>> sizeof(*led) and one line in the result
>>>
>>> And this?
>>
>> Ack.
>>
>>>
>>>>>> + { },
>>>>>
>>>>> Terminators better w/o comma.
>>>>
>>>> Looking at other drivers adding comma's on the sentinel is accepted. See
>>>> the as3645a driver
>>>
>>> So what?
>>>
>>> Terminator at compile time even better.
>>>
>>>>>> + {},
>>>>>
>>>>> Ditto.
>>>>
>>>> See above
>>>
>>> See above.
>>>
>>
>
>
--
--
Dan Murphy
Re: [PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Jacek On 05/16/2018 04:17 PM, Dan Murphy wrote: >>>> >>>> >>>>>>> + if (!ret) >>>>>> >>>>>> if (ret) sounds more natural. And better just to split >>>>>> >>>>>>> + snprintf(led->led_name, sizeof(led->led_name), >>>>>>> + "%s:%s", led->led_node->name, name); >>>>>>> + else >>>>>>> + snprintf(led->led_name, sizeof(led->led_name), >>>>>>> + "%s:torch", led->led_node->name); >>>>>> >>>>>> const char *tmp; >>>>>> >>>>>> ret = device_property_read_...(); >>>>>> if (ret) >>>>>> tmp = ... >>>>>> sprintf(...); >>> >>> We're no longer taking devicename section of a LED class device name >>> from DT, so it will look differently anyway. >>> So in adding the device_property code I think we again are reaching the LED label issue. In ARM with DT we would take the parent device node name and append it to the label if the optional label property was not available. In migrating to the device_property APIs we don't or can't depend on that parent node anymore. So for the case where the label property does not exist should we use a hard coded name or should we try to use the name from a device_id table. This is how we did this for the leds-lp8860 driver. If the label did not exist we used the i2c_device_id table and pulled the string from there. Thoughts? -- -- Dan Murphy
[PATCH] net: phy: DP83811: Add support for the phy
Add support for the DP83811 phy by extending
the DP83822 driver to recognize the PHY IDs.
The DP83811 supports both rgmii and sgmii interfaces.
There are 2 part numbers for this the DP83811R does not
reliably support the SGMII interface but the DP83811S will.
There is not a way to differentiate these parts from the
hardware or register set. So this is controlled via the DT
to indicate which phy mode is required. Or the part can be
strapped to a certain interface.
Data sheet can be found here:
http://www.ti.com/product/DP83TC811S-Q1/description
http://www.ti.com/product/DP83TC811R-Q1/description
Signed-off-by: Dan Murphy
---
drivers/net/phy/dp83822.c | 42 ---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83822.c b/drivers/net/phy/dp83822.c
index 6e8a2a4f3a6e..5c379ff25dac 100644
--- a/drivers/net/phy/dp83822.c
+++ b/drivers/net/phy/dp83822.c
@@ -23,8 +23,10 @@
#include
#define DP83822_PHY_ID 0x2000a240
+#define DP83811_PHY_ID 0x2000a253
#define DP83822_DEVADDR0x1f
+#define MII_DP83811_SGMII_CTRL 0x09
#define MII_DP83822_PHYSCR 0x11
#define MII_DP83822_MISR1 0x12
#define MII_DP83822_MISR2 0x13
@@ -79,6 +81,13 @@
#define DP83822_WOL_INDICATION_SEL BIT(8)
#define DP83822_WOL_CLR_INDICATION BIT(11)
+/* DP83811 SGMII CTRL bits */
+#define DP83811_TDR_AUTO BIT(8)
+#define DP83811_SGMII_EN BIT(12)
+#define DP83811_SGMII_AUTO_NEG_EN BIT(13)
+#define DP83811_SGMII_TX_ERR_DIS BIT(14)
+#define DP83811_SGMII_SOFT_RESET BIT(15)
+
static int dp83822_ack_interrupt(struct phy_device *phydev)
{
int err;
@@ -267,6 +276,17 @@ static int dp83822_config_init(struct phy_device *phydev)
if (err < 0)
return err;
+ if ((phydev->interface == PHY_INTERFACE_MODE_SGMII &&
+phydev->phy_id == DP83811_PHY_ID)) {
+ value = phy_read(phydev, MII_DP83811_SGMII_CTRL);
+ if (!(value & DP83811_SGMII_EN)) {
+ err = phy_write(phydev, MII_DP83811_SGMII_CTRL,
+ (DP83811_SGMII_EN | value));
+ if (err < 0)
+ return err;
+ }
+ }
+
value = DP83822_WOL_MAGIC_EN | DP83822_WOL_SECURE_ON | DP83822_WOL_EN;
return phy_write_mmd(phydev, DP83822_DEVADDR, MII_DP83822_WOL_CFG,
@@ -328,15 +348,31 @@ static struct phy_driver dp83822_driver[] = {
.suspend = dp83822_suspend,
.resume = dp83822_resume,
},
+ {
+ .phy_id = DP83811_PHY_ID,
+ .phy_id_mask = 0xfff0,
+ .name = "TI DP83811",
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = genphy_config_init,
+ .soft_reset = dp83822_phy_reset,
+ .get_wol = dp83822_get_wol,
+ .set_wol = dp83822_set_wol,
+ .ack_interrupt = dp83822_ack_interrupt,
+ .config_intr = dp83822_config_intr,
+ .suspend = dp83822_suspend,
+ .resume = dp83822_resume,
+},
};
module_phy_driver(dp83822_driver);
static struct mdio_device_id __maybe_unused dp83822_tbl[] = {
- { DP83822_PHY_ID, 0xfff0 },
- { },
+ {DP83822_PHY_ID, 0xfff0},
+ {DP83811_PHY_ID, 0xfff0},
+ {}
};
MODULE_DEVICE_TABLE(mdio, dp83822_tbl);
-MODULE_DESCRIPTION("Texas Instruments DP83822 PHY driver");
+MODULE_DESCRIPTION("Texas Instruments DP83811/22 PHY driver");
MODULE_AUTHOR("Dan Murphy
[PATCH v2 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Introduce the family of LED devices that can
drive a torch, strobe or IR LED.
The LED driver can be configured with a strobe
timer to execute a strobe flash. The IR LED
brightness is controlled via the torch brightness
register.
The data sheet for each the LM36010 and LM36011
LED drivers can be found here:
http://www.ti.com/product/LM36010
http://www.ti.com/product/LM36011
Signed-off-by: Dan Murphy
---
v2 - Fixed kbuild issue and removed unused cdev_strobe -
https://patchwork.kernel.org/patch/10384585/
drivers/leds/Kconfig| 9 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3601x.c | 591
3 files changed, 601 insertions(+)
create mode 100644 drivers/leds/leds-lm3601x.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2c896c0e69e1..50ae536f343f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -145,6 +145,15 @@ config LEDS_LM3692X
This option enables support for the TI LM3692x family
of white LED string drivers used for backlighting.
+config LEDS_LM3601X
+ tristate "LED support for LM3601x Chips"
+ depends on LEDS_CLASS && I2C && OF
+ depends on LEDS_CLASS_FLASH
+ select REGMAP_I2C
+ help
+ This option enables support for the TI LM3601x family
+ of flash, torch and indicator classes.
+
config LEDS_LOCOMO
tristate "LED Support for Locomo device"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 91eca81cae82..b79807fe1b67 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o
+obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c
new file mode 100644
index ..2d7a4a2e541f
--- /dev/null
+++ b/drivers/leds/leds-lm3601x.c
@@ -0,0 +1,591 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Flash and torch driver for Texas Instruments LM3601X LED
+ * Flash driver chip family
+ * Copyright (C) 2018 Texas Instruments
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LM3601X_LED_TORCH 0x0
+#define LM3601X_LED_STROBE 0x1
+#define LM3601X_LED_IR 0x2
+
+/* Registers */
+#define LM3601X_ENABLE_REG 0x01
+#define LM3601X_CFG_REG0x02
+#define LM3601X_LED_FLASH_REG 0x03
+#define LM3601X_LED_TORCH_REG 0x04
+#define LM3601X_FLAGS_REG 0x05
+#define LM3601X_DEV_ID_REG 0x06
+
+#define LM3601X_SW_RESET BIT(7)
+
+/* Enable Mode bits */
+#define LM3601X_MODE_STANDBY 0x00
+#define LM3601X_MODE_IR_DRVBIT(0)
+#define LM3601X_MODE_TORCH BIT(1)
+#define LM3601X_MODE_STROBE(BIT(0) | BIT(1))
+#define LM3601X_STRB_ENBIT(2)
+#define LM3601X_STRB_LVL_TRIG ~BIT(3)
+#define LM3601X_STRB_EDGE_TRIG BIT(3)
+#define LM3601X_IVFM_ENBIT(4)
+
+#define LM36010_BOOST_LIMIT_19 ~BIT(5)
+#define LM36010_BOOST_LIMIT_28 BIT(5)
+#define LM36010_BOOST_FREQ_2MHZ~BIT(6)
+#define LM36010_BOOST_FREQ_4MHZBIT(6)
+#define LM36010_BOOST_MODE_NORM~BIT(7)
+#define LM36010_BOOST_MODE_PASSBIT(7)
+
+/* Flag Mask */
+#define LM3601X_FLASH_TIME_OUT BIT(0)
+#define LM3601X_UVLO_FAULT BIT(1)
+#define LM3601X_THERM_SHUTDOWN BIT(2)
+#define LM3601X_THERM_CURR BIT(3)
+#define LM36010_CURR_LIMIT BIT(4)
+#define LM3601X_SHORT_FAULTBIT(5)
+#define LM3601X_IVFM_TRIP BIT(6)
+#define LM36010_OVP_FAULT BIT(7)
+
+#define LM3601X_MIN_TORCH_I_UA 2400
+#define LM3601X_MIN_STROBE_I_MA11
+
+enum lm3601x_type {
+ CHIP_LM36010 = 0,
+ CHIP_LM36011,
+};
+
+struct lm3601x_max_timeouts {
+ int timeout;
+ int reg_val;
+};
+
+/**
+ * struct lm3601x_led -
+ * @lock - Lock for reading/writing the device
+ * @regmap - Devices register map
+ * @client - Pointer to the I2C client
+ * @cdev_torch - led class device pointer for the torch
+ * @cdev_ir - led class device pointer for infrared
+ * @fled_cdev - flash led class device pointer
+ * @strobe_node - DT device node for the strobe
+ * @torch - LED label for the torch
+ * @strobe - LED label for the strobe
+ * @ir - LED label for the infrared
+ * @last_flag - last known flags register value
+ * @strobe_timeout - the timeout for the strobe
+ * @torch_current_max - maximum current for the torch
+ * @strobe_current_max - maximum current for the strobe
+ * @max_strobe_timeout - maximum timeout for the strobe
+ */
+struct lm3601x_led {
+ struct mutex lock;
+ struct regmap *regmap;
+ struct i2c_client *client;
+
+ struct led
[PATCH v2 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Signed-off-by: Dan Murphy
---
v2 - No changes - https://patchwork.kernel.org/patch/10384587/
.../devicetree/bindings/leds/leds-lm3601x.txt | 51 +++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3601x.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
new file mode 100644
index ..38cdabf6ca7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt
@@ -0,0 +1,51 @@
+* Texas Instruments - lm3601x Single-LED Flash Driver
+
+The LM3601X are ultra-small LED flash drivers that
+provides a high level of adjustability.
+
+Required properties:
+ - compatible : Can be one of the following
+ "ti,lm3601x"
+ "ti,lm36010"
+ "ti,lm36011"
+ - reg : I2C slave address
+ - #address-cells : 1
+ - #size-cells : 0
+
+Required child properties:
+ - reg : 0 - Indicates to support and register a torch interface
+ 1 - Indicates to support and register a strobe interface
+ 2 - Indicates to support and register an ir interface
+
+Optional child properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+led-controller@64 {
+ compatible = "ti,lm3601x";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x64>;
+
+ led@0 {
+ reg = <0>;
+ label = "white:torch";
+ led-max-microamp=<1>;
+ };
+
+ led@1 {
+ reg = <1>;
+ label = "white:strobe";
+ flash-max-microamp=<1>;
+ flash-max-timeout-us=<800>;
+ };
+
+ led@2 {
+ reg = <2>;
+ label = "invisible:ir";
+ };
+}
+
+For more product information please see the links below:
+http://www.ti.com/product/LM36010
+http://www.ti.com/product/LM36011
--
2.17.0.252.gfe0a9eaf3
Re: [PATCH] net: phy: DP83811: Add support for the phy
All
On 05/08/2018 09:11 AM, Dan Murphy wrote:
> Add support for the DP83811 phy by extending
> the DP83822 driver to recognize the PHY IDs.
>
> The DP83811 supports both rgmii and sgmii interfaces.
> There are 2 part numbers for this the DP83811R does not
> reliably support the SGMII interface but the DP83811S will.
>
> There is not a way to differentiate these parts from the
> hardware or register set. So this is controlled via the DT
> to indicate which phy mode is required. Or the part can be
> strapped to a certain interface.
>
> Data sheet can be found here:
> http://www.ti.com/product/DP83TC811S-Q1/description
> http://www.ti.com/product/DP83TC811R-Q1/description
>
I am withdrawing this patch for comment.
Some of the future features have varying register definitions between the
DP83811
and DP83822
> Signed-off-by: Dan Murphy
> ---
> drivers/net/phy/dp83822.c | 42 ---
> 1 file changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/phy/dp83822.c b/drivers/net/phy/dp83822.c
> index 6e8a2a4f3a6e..5c379ff25dac 100644
> --- a/drivers/net/phy/dp83822.c
> +++ b/drivers/net/phy/dp83822.c
> @@ -23,8 +23,10 @@
> #include
>
> #define DP83822_PHY_ID 0x2000a240
> +#define DP83811_PHY_ID 0x2000a253
> #define DP83822_DEVADDR 0x1f
>
> +#define MII_DP83811_SGMII_CTRL 0x09
> #define MII_DP83822_PHYSCR 0x11
> #define MII_DP83822_MISR10x12
> #define MII_DP83822_MISR20x13
> @@ -79,6 +81,13 @@
> #define DP83822_WOL_INDICATION_SEL BIT(8)
> #define DP83822_WOL_CLR_INDICATION BIT(11)
>
> +/* DP83811 SGMII CTRL bits */
> +#define DP83811_TDR_AUTO BIT(8)
> +#define DP83811_SGMII_EN BIT(12)
> +#define DP83811_SGMII_AUTO_NEG_ENBIT(13)
> +#define DP83811_SGMII_TX_ERR_DIS BIT(14)
> +#define DP83811_SGMII_SOFT_RESET BIT(15)
> +
> static int dp83822_ack_interrupt(struct phy_device *phydev)
> {
> int err;
> @@ -267,6 +276,17 @@ static int dp83822_config_init(struct phy_device *phydev)
> if (err < 0)
> return err;
>
> + if ((phydev->interface == PHY_INTERFACE_MODE_SGMII &&
> + phydev->phy_id == DP83811_PHY_ID)) {
> + value = phy_read(phydev, MII_DP83811_SGMII_CTRL);
> + if (!(value & DP83811_SGMII_EN)) {
> + err = phy_write(phydev, MII_DP83811_SGMII_CTRL,
> + (DP83811_SGMII_EN | value));
> + if (err < 0)
> + return err;
> + }
> + }
> +
> value = DP83822_WOL_MAGIC_EN | DP83822_WOL_SECURE_ON | DP83822_WOL_EN;
>
> return phy_write_mmd(phydev, DP83822_DEVADDR, MII_DP83822_WOL_CFG,
> @@ -328,15 +348,31 @@ static struct phy_driver dp83822_driver[] = {
> .suspend = dp83822_suspend,
> .resume = dp83822_resume,
>},
> + {
> + .phy_id = DP83811_PHY_ID,
> + .phy_id_mask = 0xfff0,
> + .name = "TI DP83811",
> + .features = PHY_BASIC_FEATURES,
> + .flags = PHY_HAS_INTERRUPT,
> + .config_init = genphy_config_init,
> + .soft_reset = dp83822_phy_reset,
> + .get_wol = dp83822_get_wol,
> + .set_wol = dp83822_set_wol,
> + .ack_interrupt = dp83822_ack_interrupt,
> + .config_intr = dp83822_config_intr,
> + .suspend = dp83822_suspend,
> + .resume = dp83822_resume,
> + },
> };
> module_phy_driver(dp83822_driver);
>
> static struct mdio_device_id __maybe_unused dp83822_tbl[] = {
> - { DP83822_PHY_ID, 0xfffffff0 },
> - { },
> + {DP83822_PHY_ID, 0xfff0},
> + {DP83811_PHY_ID, 0xfff0},
> + {}
> };
> MODULE_DEVICE_TABLE(mdio, dp83822_tbl);
>
> -MODULE_DESCRIPTION("Texas Instruments DP83822 PHY driver");
> +MODULE_DESCRIPTION("Texas Instruments DP83811/22 PHY driver");
> MODULE_AUTHOR("Dan Murphy MODULE_LICENSE("GPL");
>
--
--
Dan Murphy
Re: [PATCH v2 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Andrew Thanks for the review On 05/08/2018 10:49 AM, Andrew F. Davis wrote: > On 05/08/2018 09:17 AM, Dan Murphy wrote: >> Introduce the family of LED devices that can >> drive a torch, strobe or IR LED. >> >> The LED driver can be configured with a strobe >> timer to execute a strobe flash. The IR LED >> brightness is controlled via the torch brightness >> register. >> >> The data sheet for each the LM36010 and LM36011 >> LED drivers can be found here: >> http://www.ti.com/product/LM36010 >> http://www.ti.com/product/LM36011 >> >> Signed-off-by: Dan Murphy >> --- >> >> v2 - Fixed kbuild issue and removed unused cdev_strobe - >> https://patchwork.kernel.org/patch/10384585/ >> >> drivers/leds/Kconfig| 9 + >> drivers/leds/Makefile | 1 + >> drivers/leds/leds-lm3601x.c | 591 >> 3 files changed, 601 insertions(+) >> create mode 100644 drivers/leds/leds-lm3601x.c >> >> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig >> index 2c896c0e69e1..50ae536f343f 100644 >> --- a/drivers/leds/Kconfig >> +++ b/drivers/leds/Kconfig >> @@ -145,6 +145,15 @@ config LEDS_LM3692X >>This option enables support for the TI LM3692x family >>of white LED string drivers used for backlighting. >> >> +config LEDS_LM3601X >> +tristate "LED support for LM3601x Chips" >> +depends on LEDS_CLASS && I2C && OF >> +depends on LEDS_CLASS_FLASH >> +select REGMAP_I2C >> +help >> + This option enables support for the TI LM3601x family >> + of flash, torch and indicator classes. >> + >> config LEDS_LOCOMO >> tristate "LED Support for Locomo device" >> depends on LEDS_CLASS >> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile >> index 91eca81cae82..b79807fe1b67 100644 >> --- a/drivers/leds/Makefile >> +++ b/drivers/leds/Makefile >> @@ -76,6 +76,7 @@ obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o >> obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o >> obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o >> obj-$(CONFIG_LEDS_LM3692X) += leds-lm3692x.o >> +obj-$(CONFIG_LEDS_LM3601X) += leds-lm3601x.o >> >> # LED SPI Drivers >> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o >> diff --git a/drivers/leds/leds-lm3601x.c b/drivers/leds/leds-lm3601x.c >> new file mode 100644 >> index ..2d7a4a2e541f >> --- /dev/null >> +++ b/drivers/leds/leds-lm3601x.c >> @@ -0,0 +1,591 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Flash and torch driver for Texas Instruments LM3601X LED >> + * Flash driver chip family >> + * Copyright (C) 2018 Texas Instruments > > > Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ OK > > >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define LM3601X_LED_TORCH 0x0 >> +#define LM3601X_LED_STROBE 0x1 >> +#define LM3601X_LED_IR 0x2 >> + >> +/* Registers */ >> +#define LM3601X_ENABLE_REG 0x01 >> +#define LM3601X_CFG_REG 0x02 >> +#define LM3601X_LED_FLASH_REG 0x03 >> +#define LM3601X_LED_TORCH_REG 0x04 >> +#define LM3601X_FLAGS_REG 0x05 >> +#define LM3601X_DEV_ID_REG 0x06 >> + >> +#define LM3601X_SW_RESETBIT(7) >> + >> +/* Enable Mode bits */ >> +#define LM3601X_MODE_STANDBY0x00 >> +#define LM3601X_MODE_IR_DRV BIT(0) >> +#define LM3601X_MODE_TORCH BIT(1) >> +#define LM3601X_MODE_STROBE (BIT(0) | BIT(1)) >> +#define LM3601X_STRB_EN BIT(2) >> +#define LM3601X_STRB_LVL_TRIG ~BIT(3) >> +#define LM3601X_STRB_EDGE_TRIG BIT(3) >> +#define LM3601X_IVFM_EN BIT(4) >> + >> +#define LM36010_BOOST_LIMIT_19 ~BIT(5) >> +#define LM36010_BOOST_LIMIT_28 BIT(5) >> +#define LM36010_BOOST_FREQ_2MHZ ~BIT(6) >> +#define LM36010_BOOST_FREQ_4MHZ BIT(6) >> +#define LM36010_BOOST_MODE_NORM ~BIT(7) >> +#define LM36010_BOOST_MODE_PASS BIT(7) >> + >> +/* Flag Mask */ >> +#define LM3601X_FLASH_TIME_OUT BIT(0) >> +#define LM3601X_UVLO_FAULT BIT(1) >> +#define LM3601X_THERM_SHUTDOWN BIT(2) >> +#define LM3601X_THERM_CURR BIT(3) >> +#define LM36010_CURR_LIMIT BIT(4) >> +#define LM360
