On Wed, Dec 09, 2015 at 06:49:43PM +0100, Gregory CLEMENT wrote:
> With device tree it is no more possible to reset the PHY at board
> level. Furthermore, doing in the driver allow to power down the PHY when
> the network interface is no more used.
>
> The patch introduces a new optional property
> This additional patch is in conjunction with my PMU (already merged)
> and clock driver patch sets.
Hi Russell
Please could you respond to my comment about the clock patch.
http://www.spinics.net/lists/devicetree/msg104464.html
Thanks
Andrew
--
To unsubscribe from this list: send the
> Signed-off-by: Sebastian Hesselbarth
Given Benoit comment
Acked-by: Andrew Lunn
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Nov 28, 2015 at 12:14:08PM +0100, Sebastian Hesselbarth wrote:
> The NAND device found on Lenovo ix4-300d uses 4-bit BCH ECC protection.
> Add the corresponding properties to the NAND node.
>
> Signed-off-by: Sebastian Hesselbarth
Acked-by: Andrew Lunn
f-by: Sebastian Hesselbarth
Acked-by: Andrew Lunn
Andrew
> ---
> Cc: Jason Cooper
> Cc: Andrew Lunn
> Cc: Gregory Clement
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: Russell Ki
a
partitions node.
Acked-by: Andrew Lunn
Thanks
Andrew
> ---
> Cc: Jason Cooper
> Cc: Andrew Lunn
> Cc: Gregory Clement
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: Russell King
> Cc: Be
On Sat, Nov 28, 2015 at 12:14:05PM +0100, Sebastian Hesselbarth wrote:
> Current NAND node has an additional flash partition for the whole
> flash overlapping with real partitions. Remove this partition as
> the whole flash is already represented by the NAND device itself.
If i remember correctly,
> > +Marvell Dove has a 2GHz PLL, which feeds into a set of dividers to provide
> > +high speed clocks for a number of peripherals. These dividers are part of
> > +the PMU, and thus this node should be a child of the PMU node.
>
> It seems a bit strange to just be documenting these clocks. What a
On Thu, Nov 26, 2015 at 10:23:32PM +, Russell King wrote:
> Add the Dove divider clocks to the Dove dtsi file.
>
> Signed-off-by: Russell King
Acked-by: Andrew Lunn
Andrew
> ---
> arch/arm/boot/dts/dove.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
Hi Russell
> +static int dove_calc_divider(const struct dove_clk *dc, unsigned long rate,
> + unsigned long parent_rate, bool set)
> +{
> + unsigned int divider, max;
> +
> + divider = DIV_ROUND_CLOSEST(parent_rate, rate);
> +
> + if (dc->divider_table) {
> +
/devicetree/bindings/clock/dove-divider-clock.txt
> new file mode 100644
> index ..0c602de279e5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/dove-divider-clock.txt
> @@ -0,0 +1,28 @@
> +PLl divider based Dove clocks
Nit pick. It would be nice if the s
On Thu, Nov 19, 2015 at 06:52:57PM +0200, Vladimir Zapolskiy wrote:
> On 19.11.2015 16:18, Andrew Lunn wrote:
> >>> #ifdef CONFIG_OF
> >>> +static void select_assert(void *context)
> >>> +{
> >>> + struct eeprom_93xx46_dev *edev = context;
&g
> > #ifdef CONFIG_OF
> > +static void select_assert(void *context)
> > +{
> > + struct eeprom_93xx46_dev *edev = context;
> > +
> > + gpiod_set_value_cansleep(gpio_to_desc(edev->pdata->select_gpio), 1);
>
> I would suggest to use gpio_set_value()
Could you explain why?
Maybe this gpio is on
On Wed, Nov 04, 2015 at 10:25:07PM +, Luka Perkov wrote:
> Based on dts files from OpenWrt.
Hi Luka
Thanks for spending the time to submit these upstream.
It looks like a lot of the same comments apply to these files, so i
won't keep repeat them.
One thing i did notice is that turning off t
> + chosen {
> + bootargs = "console=ttyS0,115200n8 earlyprintk root=/dev/sda1
> rootdelay=10";
It is not normal to specify the root device. Is this really required?
And rootdelay is also unusual.
> + stdout-path = &uart0;
> + };
> +
> + ocp@f100 {
> +
Hi Luka
> "lacie,netspace_mini_v2"
> "lacie,netspace_v2"
> "linksys,ea4500"
> +"linksys,ea3500"
Other way around please, to keep the sorted order.
> + chosen {
> + bootargs = "console=ttyS0,115200n8 earlyprintk";
stdout = ...
> +&nand {
> + status = "okay";
> + pinct
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 82d2ac9..264f8ba 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -124,6 +12
On Tue, Oct 20, 2015 at 03:27:15AM +, Chris Packham wrote:
> Hi,
>
> We currently have several boards based around the 88f6281 (kirkwood) ARM
> CPU.
>
> The boards all share a kernel image (currently 3.16 based but we're in
> the process of moving to 4.3). We use the machine id (and some ot
On Sat, Oct 10, 2015 at 12:10:39AM +0200, Arnaud Ebalard wrote:
>
> This cosmetic patch reorder nodes under internal-regs by increasing
> address order, as epxected.
expected.
Gregory, can you fix that as you commit?
Acked-by: Andrew Lunn
Andrew
>
> Signed-off-by:
ternal RTC as disabled in individual .dts
> files of those devices.
>
> Reported-by: TuxOholic
> Signed-off-by: Arnaud Ebalard
Acked-by: Andrew Lunn
Thanks Arnaud
Andrew
> ---
> arch/arm/boot/dts/armada-370-netgear-rn102.dts | 6 ++
> arch/arm/boot/dts/arm
> Thanks for testing. Please could you confirm whether the same behaviour
> is observed without the patches, just to make absolutely sure that isn't
> a regression.
So i tested this now.
I have two FEC interfaces. One i my main access interface, and the
second is used by DSA to access switches.
On Thu, Sep 24, 2015 at 03:15:54PM -0700, David Miller wrote:
> From: Andrew Lunn
> Date: Thu, 24 Sep 2015 23:57:31 +0200
>
> > I built the FEC driver as a module, and it won't unload:
> >
> > kernel:unregister_netdevice: waiting for eth1 to b
;ve not tried a fully module
build, DSA has issues with that.
Tested-by: Andrew Lunn
Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> TLC591xx is quite simple HW, and the code doing the HW programming
> should be identical for a pwm and for a led driver. I don't see either a
> pwm or a led driver being somehow superior. They are very similar simple
> drivers, implementing a different interface. Whether the interface works
> for
> > Hi Tomi
> >
> > Our discussions were going around in circles, no progress being made.
> > The subsystem maintainer is ultimately the one who needs to decide,
> > bar Linus himself. Bryan Wu has seen all the discussions, and
> > ultimately decided the driver was O.K, despite any unresolved issu
On Mon, Aug 17, 2015 at 03:11:48PM +0300, Tomi Valkeinen wrote:
> Hi Andrew, (and Brian),
>
> On 18/03/15 00:08, Andrew Lunn wrote:
> > This patchset is a driver for the TI tlc59116 16 Channel i2c LED
> > driver and tlc59108 8 Channel i2c LED driver. This driver is u
Hi Srinivas
The AT24 eeprom driver contains the comment:
/*
* Export the EEPROM bytes through sysfs, since that's convenient.
* By default, onl
On Wed, Jul 15, 2015 at 07:58:59PM +0100, Russell King - ARM Linux wrote:
> What it says in the subject. Not hopeful of a successful outcome, so I'm
> not going to bother wasting time writing stuff here.
Hi Gregory
I took at look at Russell's patches. I rebased them onto -rc1. There
were a few m
Signed-off-by: Andrew Lunn
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 80339192c93e..c400c95abc67 100644
--- a
> > > What it requires is that for each user port, you can configure what
> > > cpu port it should use. Marvell devices have this ability, and at a
> > > first look, it seems like SF2 does as well, but i will leave Florian
> > > to answer definitively.
> >
> > That's right, such configuration happ
On Fri, May 29, 2015 at 11:49:54AM -0700, Mathieu Olivari wrote:
> On Fri, May 29, 2015 at 04:00:01AM +0200, Andrew Lunn wrote:
> > FYI:
> >
> > I have patches which allow DSA to use two cpu interfaces. Seems to
> > work on my DIR665 with a Marvell Switch.
> >
On Fri, May 29, 2015 at 10:36:49AM -0700, Mathieu Olivari wrote:
> Alternatively, we could have something similar to what happens for the phy
> in the wireless subsystems. Wireless PHYs are not registered as net_device
> but they can still be listed, queried or configured through netlink.
It is a
> Fair enough, are there other global "things" besides counters that could
> deserve adding maybe some sort of global/master net_device to help query
> switch-wide information?
This was discussed a while back. I like the current abstraction, all
interfaces are real interfaces you can send and rece
On Thu, May 28, 2015 at 06:58:14PM -0700, Florian Fainelli wrote:
> Le 05/28/15 18:42, Mathieu Olivari a écrit :
> > All switch registers can now be dumped using regmap/debugfs.
> >
> > \# cat /sys/kernel/debug/regmap//registers
> > : 1302
> > 0004: ...
> > ...
>
> ethtool has a register
> +static int ar8xxx_set_pad_ctrl(struct dsa_switch *ds, int port, int mode)
> +{
> + int reg;
> +
> + switch (port) {
> + case 0:
> + reg = AR8327_REG_PORT0_PAD_CTRL;
> + break;
> + case 6:
> + reg = AR8327_REG_PORT6_PAD_CTRL;
> + bre
On Thu, May 28, 2015 at 06:42:15PM -0700, Mathieu Olivari wrote:
> This patch set adds initial support for AR8xxx switches using the DSA
> subsystem. It currently supports QCA8337 switch, and can be extended to
> other hardware in the same family.
>
> This switch was already discussed in the follo
1
>(Handled via userspace dns320l-daemon)
>
> Signed-off-by: Andrew Andrianov
> Acked-by: Sebastian Hesselbarth
Acked-by: Andrew Lunn
Andrew
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/armada-370-dlink-dns327l.dts
> --- a/Documentation/devicetree/bindings/spi/spi-orion.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-orion.txt
> @@ -1,7 +1,13 @@
> Marvell Orion SPI device
>
> Required properties:
> -- compatible : should be "marvell,orion-spi" or "marvell,armada-370-spi".
> +- compatible : should be
On Tue, May 26, 2015 at 11:22:45AM +0200, Imre Kaloz wrote:
> On Tue, 26 May 2015 10:59:36 +0200, Boris Brezillon
> wrote:
>
>
>
> >>As the crypto engine really depend on the SoC itself and not of
> >>the board,
> >>what about updating the dts of the other board using an Armada XP?
> >
> >But t
t; > upstream, the powertables (calibration data) will end up in the board
> > specific files, tho.
>
> it seems that you missed my comment about removing bootargs and just using
> stdout-path = "serial0:115200n8";
>
> If you agree and if there is no remark about
On Mon, Apr 20, 2015 at 11:06:09AM +0200, Jacek Anaszewski wrote:
> Hi Andrew,
>
> Very nice driver.
Thanks. I just hope it gets accepted into this merge window.
> I have one question below.
>
> On 03/17/2015 11:08 PM, Andrew Lunn wrote:
> >The TLC59116 is an I2C b
On Thu, Apr 16, 2015 at 04:40:37PM +0900, Masahiro Yamada wrote:
> Initial device trees for UniPhier SoCs: PH1-sLD3, PH1-LD4, PH1-Pro4,
> and PH1-sLD8.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/arm/boot/dts/Makefile | 5 ++
> arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
On Sun, Apr 12, 2015 at 06:41:31PM +0300, Andrew wrote:
> Andrew Lunn ?? 12.04.2015 17:58:
> >>Okay, got it.
> >>I'll file a bug about this issue to the the bugzilla. However
> >>something
> >>tells me it might not be cpuidle, but D-link. This o
> Okay, got it.
> I'll file a bug about this issue to the the bugzilla. However something
> tells me it might not be cpuidle, but D-link. This one's sounds nasty
> and it has been around since 3.16.x. How could it go unnoticed?
> Unfortunately I have no other armada-370 hardware to test it.
Hi And
> > + internal-regs {
> > + serial@12000 {
> > + status = "okay";
> > + };
> > +
> > + serial@12100 {
> > + status = "okay";
> > + };
>
> Are both serial ports usab
On Sat, Apr 11, 2015 at 11:29:20PM +0300, Andrew Andrianov wrote:
> Signed-off-by: Andrew Andrianov
> ---
> arch/arm/boot/dts/Makefile |1 +
> arch/arm/boot/dts/armada-370-dlink-dns327l.dts | 309
>
> 2 files changed, 310 insertions(+)
> create
> When power button is pressed to turn the NAS off, weltrend signals
> the SoC by driving mpp63 line low. Apparently right now pinctrl assumes
> that this line can only work as 'gpo' that screws up gpio-buttons driver.
> Since without gpio-buttons, mpp63 works as input properly via sysfs
> interf
On Thu, Apr 09, 2015 at 04:58:41PM +0200, Boris Brezillon wrote:
> Hello,
>
> This is an attempt to replace the mv_cesa driver by a new one to address
> some limitations of the existing driver.
> >From a performance and CPU load point of view the most important
> limitation is the lack of DMA supp
On Tue, Mar 17, 2015 at 11:08:25PM +0100, Andrew Lunn wrote:
> This patchset is a driver for the TI tlc59116 16 Channel i2c LED
> driver and tlc59108 8 Channel i2c LED driver. This driver is used on
> the Belkin WRT1900AC access point and the C code is derived from code
> Belkin co
on, making them suitable for use as
GPOs.
This is based on a driver from Belkin, but has been extensively
rewritten and extended to support both 08 and 16 versions.
Signed-off-by: Andrew Lunn
Tested-by: Imre Kaloz
Cc: matthew.fathe...@belkin.com
---
drivers/leds/Kconfig | 8
-cells
Added select REGMAP_I2C
Sorted #includes into alphabetic order
Added missing MODULE_DEVICE_TABLE(of, ...)
Check return value of regmap_write()
Simplified tlc59116_set_mode()
Andrew Lunn (2):
leds: tlc59116: Document binding for the TI 16 Channel i2c LED driver
Document the binding for the TLC591xx LED driver.
Signed-off-by: Andrew Lunn
Tested-by: Imre Kaloz
Cc: matthew.fathe...@belkin.com
---
.../devicetree/bindings/leds/leds-tlc591xx.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree
> Sorry if I was unclear. My question was not _whether_ to fix this
> for earlycon, but rather _how_.
>
> IOW, is the ':' character accepted as a path terminator for
> 1. all nodes, so fix this in fdt_path_offset();
> 2. only chosen nodes;
> 3. unique to stdout-path, so fix this in early_init_dt_s
On Thu, Feb 26, 2015 at 06:55:22AM -0500, Peter Hurley wrote:
> On 11/27/2014 12:56 PM, Leif Lindholm wrote:
> > Support specifying console options (like with console=ttyXN,)
> > by appending them to the stdout-path property after a separating ':'.
> >
> > Example:
> > stdout-path = "uart0
> > > + pinctrl@18000 {
> > > + uart0_pins: uart0-pins {
> > > + marvell,pins = "mpp0", "mpp1";
> > > + marvell,function = "ua0";
> > > + };
> > > +
> > > +
> Both "dev" and "m" are already used by many of the existing pinctrl DT
> bindings for Marvell platforms, so I'm not sure documenting them
> specifically in the Armada 39x pinctrl DT binding document makes a lot
> of sense. Where should we document them, then? In the generic
> 'marvell,mvebu-pinct
On Thu, Feb 19, 2015 at 05:08:28PM +, Srinivas Kandagatla wrote:
> From: Maxime Ripard
>
> Up until now, EEPROM drivers were stored in drivers/misc, where they all had
> to
> duplicate pretty much the same code to register a sysfs file, allow in-kernel
> users to access the content of the de
4x LAN)
> - 128MB NAND flash
> - 256MB RAM
>
> Signed-off-by: Imre Kaloz
Hi Imre
This looks good now.
Acked-by: Andrew Lunn
I want to test this, and add a Tested-by:, and add support for the
switch, but i don't have time for this at the moment.
Andrew
--
To unsubs
Hi Russell
Thanks for posting these. Lets try to get them merged.
> There are a few things which are missing from this driver, such sa the
> DT binding documentation. This will follow once people are happy with
> the first four patches, in particular where to locate the PMU driver
> in the kerne
On Mon, Feb 09, 2015 at 01:50:37PM +0200, Tomi Valkeinen wrote:
> On 06/02/15 05:10, Andrew Lunn wrote:
> > On Tue, Jan 27, 2015 at 02:59:19PM +0100, Andrew Lunn wrote:
> >> This patchset is a driver for the TI tlc59116 16 Channel i2c LED
> >> driver and tlc59108 8 C
On Sat, Feb 07, 2015 at 08:59:46PM +0100, Gordon Bos wrote:
> Hi Andrew,
>
> There is a difference, and apparently it somewhere got solved:
>
> From running kernel 3.17.1
>
> ~ # dmesg | grep spi
>
> Running an upgraded kernel 3.18.5 with the same DT blob
>
> ~ # dmesg | grep spi
>
On Sat, Feb 07, 2015 at 07:22:13PM +0100, Gordon Bos wrote:
> Hi Andrew,
>
> I may be mistaken here, but this here references the driver that is
> to be used, or not?
>
> |compatible = "st,m25p16";
Nope, that is the device, not the driver.
The driver has a list of devices it is cap
On Sat, Feb 07, 2015 at 06:15:12PM +0100, Gordon Bos wrote:
> Hi Andrew,
>
> Unsure how it can work for you, but this is the corresponding entry
> from the Excito release:
>
> ---
> |/*
> * 2048KB SPI Flash on Boot Devic
On Sat, Feb 07, 2015 at 04:04:59PM +0100, Gordon Bos wrote:
> Hi,
>
> I've had some further discussion on this with another B3 owner.
> According to an old patch that Excito corporation built for kernel
> version 2.6 the flash memory is in fact a ||Numonyx MP25P16
> The driver however must be m25p
On Sat, Feb 07, 2015 at 04:04:59PM +0100, Gordon Bos wrote:
> Hi,
>
> I've had some further discussion on this with another B3 owner.
> According to an old patch that Excito corporation built for kernel
> version 2.6 the flash memory is in fact a ||Numonyx MP25P16
> The driver however must be m25p
On Fri, Feb 06, 2015 at 04:57:55PM +0100, Thomas Petazzoni wrote:
> This commit adds the Device Tree files for the Armada 39x family of
> processors, as well as one Armada 398 Development Board.
>
> Like for other Marvell EBU families, a common armada-39x.dtsi contains
> the description of the com
On Fri, Feb 06, 2015 at 04:57:49PM +0100, Thomas Petazzoni wrote:
> This commit adds the Device Tree binding documentation to describe the
> pin-muxing controller of the Marvell Armada 39x processors. Two
> variants are supported for the moment: the 88F6920 (Armada 390) and
> 88F6928 (Armada 398).
On Tue, Jan 27, 2015 at 02:59:19PM +0100, Andrew Lunn wrote:
> This patchset is a driver for the TI tlc59116 16 Channel i2c LED
> driver and tlc59108 8 Channel i2c LED driver. This driver is used on
> the Belkin WRT1900AC access point and the C code is derived from code
> Belkin co
on, making them suitable for use as
GPOs.
This is based on a driver from Belkin, but has been extensively
rewritten and extended to support both 08 and 16 versions.
Signed-off-by: Andrew Lunn
Cc: matthew.fathe...@belkin.com
---
drivers/leds/Kconfig | 8 ++
drivers/leds/Makefile
-cells
Added select REGMAP_I2C
Sorted #includes into alphabetic order
Added missing MODULE_DEVICE_TABLE(of, ...)
Check return value of regmap_write()
Simplified tlc59116_set_mode()
Andrew Lunn (2):
leds: tlc59116: Document binding for the TI 16 Channel i2c LED driver
Document the binding for the TLC591xx LED driver.
Signed-off-by: Andrew Lunn
Cc: matthew.fathe...@belkin.com
---
.../devicetree/bindings/leds/leds-tlc591xx.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds
On Mon, Jan 19, 2015 at 06:15:01PM +0100, Imre Kaloz wrote:
> The Linksys WRT1900AC (Mamba) is a router that has
>
> - 2 mini-PCIe slots with Marvell 88W8864 radios
> - 1 USB 3.0 port
> - 1 USB 2.0/eSATAp port
> - 2 Ethernet interfaces connected to a 88E6172 switch (1x WAN + 4x LAN)
> - 128MB NAND
On Mon, Jan 26, 2015 at 01:32:40PM +0200, Tomi Valkeinen wrote:
> On 22/01/15 00:29, Andrew Lunn wrote:
> > The TLC59116 is an I2C bus controlled 16-channel LED driver. The
> > TLC59108 is an I2C bus controlled 8-channel LED driver, which is very
> > similar to the TLC59116
> So... To me it's still slightly unclear when should one write a PWM
> driver and when a LED driver. But I would say that as the TLC591xx
> outputs a PWM signal, it should be a PWM driver. Then the different
> users of this PWM signal could be made on top of that (LED, backlight, GPO).
>
> What w
> >>>+
> >>>+power {
> >>>+label = "mamba:white:power";
> >>
> >>Please replace this mamba with wrt1900ac. It is a property of the
> >>device, not the board. Another device using the mamba board may use it
> >>differently.
> >>
> >
> >See above.
>
> The LED should be named by t
on, making them suitable for use as
GPOs.
This is based on a driver from Belkin, but has been extensively
rewritten and extended to support both 08 and 16 versions.
Signed-off-by: Andrew Lunn
Cc: matthew.fathe...@belkin.com
---
drivers/leds/Kconfig | 8 ++
drivers/leds/Makefile
Document the binding for the TLC591xx LED driver.
Signed-off-by: Andrew Lunn
Cc: matthew.fathe...@belkin.com
---
.../devicetree/bindings/leds/leds-tlc591xx.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds
Sorted #includes into alphabetic order
Added missing MODULE_DEVICE_TABLE(of, ...)
Check return value of regmap_write()
Simplified tlc59116_set_mode()
Andrew Lunn (2):
leds: tlc59116: Document binding for the TI 16 Channel i2c LED driver
leds: tlc59116: Driver for the TI 16
> >
> >It would be nice to document the jumper and pinout here.
> >
> >>+ serial@12000 {
> >>+ status = "okay";
> >>+ };
>
> Do you mean serial console pinout?
Yes. Looking at
https://github.com/Chadster766/McWRT/wiki/Linksys-WRT1900A
on, making them suitable for use as
GPOs.
This is based on a driver from Belkin, but has been extensively
rewritten and extended to support both 08 and 16 versions.
Signed-off-by: Andrew Lunn
Cc: matthew.fathe...@belkin.com
---
drivers/leds/Kconfig | 8 ++
drivers/leds/Makefile
MODULE_DEVICE_TABLE(of, ...)
Check return value of regmap_write()
Simplified tlc59116_set_mode()
Andrew Lunn (2):
leds: tlc59116: Document binding for the TI 16 Channel i2c LED driver
leds: tlc59116: Driver for the TI 16 Channel i2c LED driver
.../devicetree/bindings/leds/leds
Document the binding for the TLC591xx LED driver.
Signed-off-by: Andrew Lunn
Cc: matthew.fathe...@belkin.com
---
.../devicetree/bindings/leds/leds-tlc591xx.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds
> Right. TLC591xx has the constant output mode which should be used for
> GPIO. Perhaps that mode could be always used when the brightness is
> turned to maximum. I haven't read the spec carefully enough to know if
> there are some downsides.
The original Belkin code did use that mode for full bri
> I'm not familiar with the LED/PWM frameworks, so I want to summarize our
> use case and how I guess this should be done:
>
> We use the TLC59108 to provide backlight to a LCD, but in addition to
> that, it is used as a GPIO expander (or GPO, as it cannot do input). In
> your earlier patch versio
On Mon, Jan 19, 2015 at 08:40:25PM +0100, Paul Bolle wrote:
> The Kconfig symbol DEBUG_MVEBU_UART_ALTERNATE was renamed to
> DEBUG_MVEBU_UART0_ALTERNATE. And the symbol DEBUG_MVEBU_UART1_ALTERNATE
> was added to allow UART1 as a DEBUG_LL target. Make the comment at the
> top of this DTS reflect tho
On Mon, Jan 19, 2015 at 06:15:01PM +0100, Imre Kaloz wrote:
> The Linksys WRT1900AC (Mamba) is a router that has
>
> - 2 mini-PCIe slots with Marvell 88W8864 radios
> - 1 USB 3.0 port
> - 1 USB 2.0/eSATAp port
> - 2 Ethernet interfaces connected to a 88E6172 switch (1x WAN + 4x LAN)
> - 128MB NAND
On Mon, Jan 19, 2015 at 09:54:13AM -0500, Tejun Heo wrote:
> On Fri, Jan 16, 2015 at 08:58:18AM +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 15-01-15 15:09, Gregory CLEMENT wrote:
> > >The current implementation of the libahci allows using one PHY per
> > >port but we still have one single regul
On Fri, Jan 16, 2015 at 04:52:12PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 15/01/15 01:15, Andrew Lunn wrote:
> > This patchset is a driver for the TI tlc59116 16 Channel i2c LED
> > driver. This driver is used on the Belkin WRT1900AC access point and
> > the C code
> I understand that period of TLC chip cannot be changed and hence cannot
> fully implement PWM interface.
O.K, so that is agreed.
> But, suppose I want to control brightness
> of an LCD screen, with your current design, my LCD driver can never can do
> something like:
> pwm_get(chip);
>
On Fri, Jan 16, 2015 at 04:52:12PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 15/01/15 01:15, Andrew Lunn wrote:
> > This patchset is a driver for the TI tlc59116 16 Channel i2c LED
> > driver. This driver is used on the Belkin WRT1900AC access point and
> > the C code
The TLC59116 is an I2C bus controlled 16-channel LED driver. Each LED
output has its own 8-bit fixed-frequency PWM controller to control the
brightness of the LED.
This is based on a driver from Belkin, but has been extensively
rewritten.
Signed-off-by: Andrew Lunn
Cc: matthew.fathe
Document the binding for the TLC59116 LED driver.
Signed-off-by: Andrew Lunn
Cc: matthew.fathe...@belkin.com
---
.../devicetree/bindings/leds/leds-tlc59116.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds
#gpio-cells
Added select REGMAP_I2C
Sorted #includes into alphabetic order
Added missing MODULE_DEVICE_TABLE(of, ...)
Check return value of regmap_write()
Simplified tlc59116_set_mode()
Andrew Lunn (2):
leds: tlc59116: Document binding for the TI 16 Channel i2c LED
On Tue, Jan 13, 2015 at 09:49:29PM -0700, Christoph Junghans wrote:
> The pogoplug differs from the SheevaPlug only by a
> few details, but especially in the led assignments.
> This patch was tested under Gentoo Linux and is
> based on dts files from Arch Linux ARM and OpenWrt.
>
> Suggested-by: F
> Can you update that one without that gpio thing in the example? And if
> there is no objection from others, I will take it.
Hi Bryan
v2 of the patch has the #gpio-cells removed.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majo
On Tue, Jan 13, 2015 at 10:55:23AM -0800, Bryan Wu wrote:
> On Fri, Jan 9, 2015 at 2:45 PM, Andrew Lunn wrote:
> > The TLC59116 is an I2C bus controlled 16-channel LED driver. Each LED
> > output has its own 8-bit fixed-frequency PWM controller to control the
> >
On Mon, Jan 12, 2015 at 11:13:11PM -0700, Christoph Junghans wrote:
> From: Christoph Junghans
>
> The pogoplug differs from the SheevaPlug only by a
> few details, but especially in the led assignments.
> This patch was tested under Gentoo Linux and is
> based on dts files from Arch Linux ARM an
On Mon, Jan 12, 2015 at 06:22:12PM -0700, Christoph Junghans wrote:
> The pogoplug differs from the SheevaPlug only by a
> few details, but especially in the led assignments.
> This patch was tested under Gentoo Linux and is
> based on dts files from Arch Linux ARM and OpenWrt.
Hi Christoph
I jus
On Sun, Jan 11, 2015 at 11:11:01PM -0700, Christoph Junghans wrote:
> The pogoplug differs from the SheevaPlug only by a
> few details, but especially in the led assignments.
> This patch was tested under Gentoo Linux.
> A version of this patch was included in Arch Linux
> on Arm since Jun 2014:
>
On Mon, Jan 12, 2015 at 10:33:56AM +0100, Paul Bolle wrote:
> Maxime,
>
> Your commit d91125ddf962 ("ARM: mvebu: Rename DEBUG_LL to indicate UART
> index") is included in today's linux-next (ie, next-20150112). So is the
> related commit bd920490047a ("ARM: mvebu: Add UART1 as DEBUG_LL possible
>
1 - 100 of 352 matches
Mail list logo
