in" 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
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 b
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 wro
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
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
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
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 d
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
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
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 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
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
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
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
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
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
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
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
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
>>>&g
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
>&g
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
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
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
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
t; - 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_I2
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
>>
>&g
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
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
>>
>> The
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
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
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
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/bi
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
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
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
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;
>> +
>> +i
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_
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
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 amplif
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) {
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, 201
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
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
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
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:
>>>&
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
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
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 curren
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
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
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
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
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
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
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
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
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
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
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
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
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
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 +
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
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
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
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)
>>> + snprin
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
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-&
e
with the hardware.
Dan
>
> And maybe comment "don't copy this, its wrong" would be in order...
> > Best regards,
> Pavel
>
--
--
Dan Murphy
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
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
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
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
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.
>>
&g
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
&
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
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
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
>>
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
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 v
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
>>
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);
>>>> +
&
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 "suppo
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
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/bindi
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:
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.
>>
&g
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:
>>>
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
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 d
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/
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:
>
.
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
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 w
Jacek
On 05/16/2018 04:17 PM, Dan Murphy wrote:
>>>>
>>>>
>>>>>>> + if (!ret)
>>>>>>
>>>>>> if (ret) sounds more natural. And better just to split
>>>>>>
>>>>>>&g
/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
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
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
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 t
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
>>
401 - 500 of 2241 matches
Mail list logo
