On Thu, Dec 05, 2013 at 05:37:01PM +1100, dt.ta...@gmail.com wrote:
> From: Daniel Tang
>
> The device tree binding chosen for the nspire-usb driver was inappropriate and
> should be renamed to lsi,zevio-usb.
>
> References to nspire have been replaced with zevio (the SoC name)
>
> Signed-off-b
> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Thursday, November 28, 2013 2:08 PM
> To: Lu Jingchang-B35083
> Cc: Mark Rutland; devicetree@vger.kernel.org; Wang Huan-B18965; linux-
> ker...@vger.kernel.org; shawn@linaro.org; linux-arm-
> ker...@lists.in
On Thu, Dec 05, 2013 at 04:43:38PM +0100, Denis Carikli wrote:
> Without that patch, a user can't select the imxfb driver when the i.MX25
> and/or
> the i.MX27 device tree board are selected and that no boards that selects
> IMX_HAVE_PLATFORM_IMX_FB are compiled in.
>
> Cc: Rob Herring
> Cc:
On Thu, Dec 05, 2013 at 04:43:37PM +0100, Denis Carikli wrote:
> pwmr has to be set to get the imxfb backlight work,
> though pwmr was only configurable trough the platform data.
>
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Stephen Warren
> Cc: Ian Campbell
> Cc: devicetree@v
On Friday 06 December 2013 05:03 AM, Stephen Warren wrote:
On 12/05/2013 03:44 AM, Laxman Dewangan wrote:
This patch series convert dts files of all Tegra's platforms to use the pinctron
dt-binding macro for better readability.
I think this series looks fine now; I'll apply soon pending what ha
On Friday 06 December 2013 05:00 AM, Stephen Warren wrote:
On 12/05/2013 03:57 AM, Laxman Dewangan wrote:
From: Ashwini Ghuge
This adds a driver for the Tegra124 pinmux, and required
parameterization data for Tegra124.
The driver uses the common Tegra pincontrol driver utility
functions to im
On Friday 06 December 2013 04:47 AM, Stephen Warren wrote:
On 12/05/2013 03:57 AM, Laxman Dewangan wrote:
This device tree binding document describes the Tegra124 pincontrol
DT bindings. This document lists all valid properties, names, mux
options of Tegra124 pins.
Is this a repost of what Ashw
On Friday 06 December 2013 04:49 AM, Stephen Warren wrote:
On 12/05/2013 04:16 PM, Stephen Warren wrote:
On 12/05/2013 03:57 AM, Laxman Dewangan wrote:
The tegra124 pinmux controller is identical to tegra114 with
removing some of existing pins from T114 and adding new pins.
I already sent this
Add device tree support for exynos5250 and 5420 SoCs and use syscon regmap
interface
to configure AUTOMATIC_WDT_RESET_DISABLE and MASK_WDT_RESET_REQUEST registers
of PMU
to mask/unmask enable/disable of watchdog in probe and s2r scenarios.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Dou
This patch adds pmusysreg node to exynos5250 and exynos5420 dtsi files to
handle PMU register accesses in a centralized way using syscon driver
Signed-off-by: Leela Krishna Amudala
Reviewed-by: Tomasz Figa
Reviewed-by: Doug Anderson
Tested-by: Doug Anderson
---
Documentation/devicetree/bindin
In Exynos5 series SoCs, PMU has registers to enable/disable mask/unmask
watchdog timer which is not the case with s3c series SoCs so, there is a
need to have different compatible names for watchdog to handle these pmu
registers access.
Hence this patch removes watchdog node from Exynos5.dtsi commo
This patchset does the following things
- Adds pmusysreg device node to exynos5.dtsi file
- Adds watchdog DT nodes to Exynos5250 and 5420
- Uses syscon regmap interface to configure pmu registers
to mask/unmask enable/disable of watchdog.
This patch set is
Hi,
On Thursday 05 December 2013 05:59 PM, Kamil Debski wrote:
> Previously the of_phy_get function took a struct device * and
> was declared static. It was impossible to call it from
> another driver and thus it was impossible to get phy defined
It was never intended to be called from other driv
On Fri, Dec 6, 2013 at 12:19 AM, Sonny Rao wrote:
> On Thu, Dec 5, 2013 at 2:06 AM, Yuvaraj Kumar C D
> wrote:
>> Commits 64c138a ("ARM: dts: Move fifo-depth property from exynos5250
>> board dts") and 0c3de788 ("ARM: dts: change status property of dwmmc
>> nodes for exynos5250") missed out hand
Linus,
Please pull. Just some binding documentation updates and DT maintainers
updates.
Rob
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/k
On Fri, Dec 06, 2013 at 11:38:51AM +1100, James Cameron wrote:
> On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote:
> > pxa2xx-uart was a separate uart platform driver. It was declaring
> > the same device names and numbers as 8250 driver. As a result,
> > it was impossible to use 825
On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote:
> pxa2xx-uart was a separate uart platform driver. It was declaring
> the same device names and numbers as 8250 driver. As a result,
> it was impossible to use 8250 driver on PXA SoCs.
>
> Upon closer examination pxa2xx-uart turned o
>
> Hi,
>
> On 05/12/2013, at 7:49 PM, Peter Chen wrote:
>
> > On Thu, Dec 05, 2013 at 04:44:13PM +1100, Daniel Tang wrote:
> >> Hi,
> >>
> >> On 05/12/2013, at 12:44 AM, Peter Chen
> wrote:
> >>
> >>>
> >>> lsi is vendor name, what are zevio and nspire?
> >>> Usually, the compatible string
Hello guys,
My apologies for too messy messages.
Would you please refer to the patch-set with 'PATCH RESEND v5'?
Thanks.
Milo
On 12/06/2013 11:08 AM, Milo Kim wrote:
LP3943 is an integrated device capable of driving 16 output channels.
It can be used for GPIO expander and PWM generators.
LP3
LP3943 has 16 output pins which can be used as GPIO expander and PWM generator.
* Regmap I2C interface for R/W LP3943 registers
* Atomic operations for output pin assignment
The driver should check whether requested pin is available or not.
If the pin is already used, pin request returns as a
Bindings for LP3943 MFD, GPIO and PWM controller are added.
Cc: devicetree@vger.kernel.org
Cc: Lee Jones
Cc: Linus Walleij
Cc: Samuel Ortiz
Signed-off-by: Milo Kim
Acked-by: Thierry Reding
---
.../devicetree/bindings/gpio/gpio-lp3943.txt | 37 +
Documentation/devicetree/b
This is the other of the LP3943 MFD driver.
LP3943 can be used as a PWM generator, up to 2 channels.
* Two PWM generators supported
* Supported PWM operations
request, free, config, enable and disable
* Pin assignment
A driver data, 'pin_used' is checked when a PWM is requested.
If the out
This is one of LP3943 MFD driver.
LP3943 is configurable as a GPIO expander, up to 16 GPIOs.
* Application note: how to configure LP3943 as a GPIO expander
http://www.ti.com/lit/an/snva287a/snva287a.pdf
* Supported GPIO controller operations
request, free, direction_input, direction_output, g
LP3943 is an integrated device capable of driving 16 output channels.
It can be used for GPIO expander and PWM generators.
LP3493 registers are controlled via the I2C interface.
This patch-set consists of four parts - MFD, GPIO, PWM and documents.
Update from v4 to v5:
Add Thierry's ACK for the
Bindings for LP3943 MFD, GPIO and PWM controller are added.
Cc: devicetree@vger.kernel.org
Cc: Lee Jones
Cc: Linus Walleij
Cc: Samuel Ortiz
Signed-off-by: Milo Kim
Acked-by: Thierry Reding
---
.../devicetree/bindings/gpio/gpio-lp3943.txt | 37 +
Documentation/devicetree/b
This adds initial documentation for the pinctrl-msm8x74 driver.
Signed-off-by: Bjorn Andersson
---
.../bindings/pinctrl/qcom,msm8x74-pinctrl.txt | 92 ++
1 file changed, 92 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,msm8x74-pinctrl.
Add initial definition of parameters for pinctrl-msm for the msm8x74
platform.
Signed-off-by: Bjorn Andersson
---
drivers/pinctrl/Kconfig | 4 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-msm8x74.c | 636 ++
3 files changed,
This adds a pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block.
Signed-off-by: Bjorn Andersson
---
drivers/pinctrl/Kconfig |6 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-msm.c | 1028 +
drivers/pinctrl/
Bindings for LP3943 MFD, GPIO and PWM controller are added.
Cc: devicetree@vger.kernel.org
Cc: Lee Jones
Cc: Linus Walleij
Cc: Samuel Ortiz
Signed-off-by: Milo Kim
Acked-by: Thierry Reding
---
.../devicetree/bindings/gpio/gpio-lp3943.txt | 37 +
Documentation/devicetree/b
This series adds a pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in recent Qualcomm SoCs (8x60 and newer).
It designed with both v2 and v3 of the block in mind and comes with initial
definitions for the 8x74 SoCs.
This should be filled in with more data and definitio
This is the other of the LP3943 MFD driver.
LP3943 can be used as a PWM generator, up to 2 channels.
* Two PWM generators supported
* Supported PWM operations
request, free, config, enable and disable
* Pin assignment
A driver data, 'pin_used' is checked when a PWM is requested.
If the out
This is one of LP3943 MFD driver.
LP3943 is configurable as a GPIO expander, up to 16 GPIOs.
* Application note: how to configure LP3943 as a GPIO expander
http://www.ti.com/lit/an/snva287a/snva287a.pdf
* Supported GPIO controller operations
request, free, direction_input, direction_output, g
LP3943 has 16 output pins which can be used as GPIO expander and PWM generator.
* Regmap I2C interface for R/W LP3943 registers
* Atomic operations for output pin assignment
The driver should check whether requested pin is available or not.
If the pin is already used, pin request returns as a
LP3943 is an integrated device capable of driving 16 output channels.
It can be used for GPIO expander and PWM generators.
LP3493 registers are controlled via the I2C interface.
This patch-set consists of four parts - MFD, GPIO, PWM and documents.
Update from v4 to v5:
Add Thierry's ACK for the
On Friday 08 November 2013, Zhangfei Gao wrote:
> Add dw_mmc-k3.c for k3v2, support sd/emmc
>
> Signed-off-by: Zhangfei Gao
> Tested-by: Zhigang Wang
We are currently having the exact same discussion problem on the altera
version of dw_mmc: It seems that all this driver does in addition to the
From: Tony Lindgren
Date: Tue, 3 Dec 2013 15:13:02 -0800
> When booted with device tree, we may still have platform data passed
> as auxdata. For am3517 this is needed for passing the interrupt_enable
> and interrupt_disable callbacks that access the omap system control module
> registers. These
On Tue 03 Dec 00:50 PST 2013, Linus Walleij wrote:
> On Sun, Nov 24, 2013 at 12:38 AM, Bjorn Andersson
> wrote:
>
> > This adds a pinctrl, pinmux, pinconf and gpiolib driver for the
> > Qualcomm TLMM block.
> >
> > Signed-off-by: Bjorn Andersson
>
> Overall this is looking *very* good, using e
On Thursday 05 December 2013, Dinh Nguyen wrote:
> Perhaps Seungwon and Chris might have an opinion on this:
>
> From the Synopsys databook for this IP, using the SDMMC_CMD_USE_HOLD_REG
> is not recommended for SDR104, SDR50 and DDR50 speed modes. For other
> speeds, SDR12, and SDR25, it would be
From: Florian Fainelli
Date: Thu, 5 Dec 2013 15:53:41 -0800
> 2013/12/5 Sergei Shtylyov :
>>>
>>> + /* Set phydev->supported based on the "max-speed" property
>>> +* if present */
>>
>>
>>Preferred multi-line comment style is this:
>>
>> /*
>> * bla
>> * bla
>> */
>
> All ot
On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote:
> pxa2xx-uart was a separate uart platform driver. It was declaring
> the same device names and numbers as 8250 driver. As a result,
> it was impossible to use 8250 driver on PXA SoCs.
>
> Upon closer examination pxa2xx-uart turned o
Move the power GPIO handling from the board code into
the driver. This is a dependency for device tree support.
Signed-off-by: Sebastian Reichel
Reviewed-by: Pavel Machek
---
arch/arm/mach-omap2/board-omap3pandora.c | 2 ++
arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++
driv
This patch adds support for requesting the regulator powering
the vio pin.
Signed-off-by: Sebastian Reichel
Reviewed-by: Pavel Machek
---
drivers/net/wireless/ti/wl1251/spi.c| 19 +--
drivers/net/wireless/ti/wl1251/wl1251.h | 2 ++
2 files changed, 19 insertions(+), 2 delet
Add device tree binding documentation for Texas Instrument's wl1251
wireless lan chip. For now only the SPI binding is documented.
Signed-off-by: Sebastian Reichel
---
.../devicetree/bindings/net/wireless/ti,wl1251.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 10
From: Luciano Coelho
Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251. Change the platform data built-in
block and board files accordingly.
Signed-off-by: Luciano Coelho
Acked-by: Tony Lindgren
Reviewed-by: Felipe Balbi
Reviewed-by: Seba
Add device tree support for the spi variant of wl1251.
Signed-off-by: Sebastian Reichel
---
drivers/net/wireless/ti/wl1251/spi.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ti/wl1251/spi.c
b/drivers/net/wireless/ti/wl1251/spi
Hi,
The following patchset adds device tree support to
the spi variant of the wl1251 driver.
Changes since v1 [0]:
* Added some Reviewed-By: Pavel Machek
* Splitted DT binding documentation into its own patch
* Added ti, prefix to power-gpio
* Renamed ti,use-eeprom to ti,wl1251-has-eeprom
*
On Thu, Dec 05, 2013 at 04:02:53PM -0800, Greg Kroah-Hartman wrote:
> On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote:
> > pxa2xx-uart was a separate uart platform driver. It was declaring
> > the same device names and numbers as 8250 driver. As a result,
> > it was impossible to us
On Thu, 2013-12-05 at 15:53 -0800, Florian Fainelli wrote:
> 2013/12/5 Sergei Shtylyov :
> >>
> >> + /* Set phydev->supported based on the "max-speed" property
> >> +* if present */
[]
> All other comments in this file are:
>
> /* bla
> * bla
> */
>
> which is why I used the same
On Fri, Dec 06, 2013 at 03:28:37AM +0400, Sergei Ianovich wrote:
> pxa2xx-uart was a separate uart platform driver. It was declaring
> the same device names and numbers as 8250 driver. As a result,
> it was impossible to use 8250 driver on PXA SoCs.
>
> Upon closer examination pxa2xx-uart turned o
2013/12/5 Sergei Shtylyov :
>>
>> + /* Set phydev->supported based on the "max-speed" property
>> +* if present */
>
>
>Preferred multi-line comment style is this:
>
> /*
> * bla
> * bla
> */
All other comments in this file are:
/* bla
* bla
*/
which is why I used the same
On 12/03/2013 02:29 AM, Linus Walleij wrote:
...
> So I guess what you're after is a kind of hog that will be pushed
> aside and ignored if a struct device with an associated state appears
> that will use the same pin?
That probably would be useful. Perhaps we should just make all hogs not
exclusi
Hello.
On 12/06/2013 01:52 AM, Florian Fainelli wrote:
From: Florian Fainelli
The "max-speed" property is defined per the ePAPR specification to
express the maximum speed a PHY supports. Use that property, if present
to set the phydev->supported features which properly restricts the PHY
wit
Hello.
On 12/06/2013 01:52 AM, Florian Fainelli wrote:
From: Florian Fainelli
If irq_of_parse_and_map fails to find an interrupt line for a given PHY,
we will force the PHY interrupt to be PHY_POLL, completely overriding
the previous value that the MDIO bus may have set for us (e.g:
PHY_IGN
On 12/05/2013 03:44 AM, Laxman Dewangan wrote:
> This patch series convert dts files of all Tegra's platforms to use the
> pinctron
> dt-binding macro for better readability.
I think this series looks fine now; I'll apply soon pending what happens
with the DMA/reset/ binding rework.
There are qu
On 12/05/2013 03:57 AM, Laxman Dewangan wrote:
> From: Ashwini Ghuge
>
> This adds a driver for the Tegra124 pinmux, and required
> parameterization data for Tegra124.
>
> The driver uses the common Tegra pincontrol driver utility
> functions to implement the majority of the driver.
>
> This dr
pxa2xx-uart was a separate uart platform driver. It was declaring
the same device names and numbers as 8250 driver. As a result,
it was impossible to use 8250 driver on PXA SoCs.
Upon closer examination pxa2xx-uart turned out to be a clone of
8250_core driver.
Signed-off-by: Sergei Ianovich
CC:
On 12/05/2013 04:16 PM, Stephen Warren wrote:
> On 12/05/2013 03:57 AM, Laxman Dewangan wrote:
>> The tegra124 pinmux controller is identical to tegra114 with
>> removing some of existing pins from T114 and adding new pins.
>
> I already sent this patch.
Oh, I do notice one difference between the
On 12/05/2013 03:57 AM, Laxman Dewangan wrote:
> The pincontrol driver for Tegra124 is build through config
> PINCTRL_TEGRA124. Select this config option whenever Tegra124
> SoC is enabled.
I already sent this patch too.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
t
On 12/05/2013 03:57 AM, Laxman Dewangan wrote:
> This device tree binding document describes the Tegra124 pincontrol
> DT bindings. This document lists all valid properties, names, mux
> options of Tegra124 pins.
Is this a repost of what Ashwini sent a few weeks back, or V2? If V2,
it'd be useful
On 12/05/2013 03:57 AM, Laxman Dewangan wrote:
> The tegra124 pinmux controller is identical to tegra114 with
> removing some of existing pins from T114 and adding new pins.
I already sent this patch.
> diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
> + pinmux
Add devicetree binding documentation for TSC2005 touchscreen.
Signed-off-by: Sebastian Reichel
---
.../bindings/input/touchscreen/tsc2005.txt | 49 ++
1 file changed, 49 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
This adds DT support to the tsc2005 touchscreen
driver.
Signed-off-by: Sebastian Reichel
---
drivers/input/touchscreen/tsc2005.c | 95 ++---
1 file changed, 78 insertions(+), 17 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchs
Hi,
This adds device tree support for the tsc2005 touchscreen
controller, which is currently only used by the Nokia N900
board.
The patch does not update the reset pin handling for platform
data based probe to avoid merge conflicts (Tony will remove
the Nokia N900 boardcode in 3.14). The platform
From: Florian Fainelli
Since commit 779d835e ("net: of_mdio: scan mdiobus for PHYs without reg
property") we have two foreach loops which do pretty much the same
thing. Factor the PHY device registration in a function helper:
of_mdiobus_register_phy() which takes care of the details and allows fo
From: Florian Fainelli
Use the PHY_MAX_ADDR constant for checking if a MDIO bus address is
valid instead of using a plain "32".
Signed-off-by: Florian Fainelli
---
drivers/of/of_mdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio
From: Florian Fainelli
The "max-speed" property is defined per the ePAPR specification to
express the maximum speed a PHY supports. Use that property, if present
to set the phydev->supported features which properly restricts the PHY
within the range of defined speeds.
Signed-off-by: Florian Fain
From: Florian Fainelli
The 'max-speed' property is optional but defined in the ePAPR
specification and now supported by the Linux Device Tree parsing
infrastructure.
Signed-off-by: Florian Fainelli
---
Documentation/devicetree/bindings/net/phy.txt | 1 +
1 file changed, 1 insertion(+)
diff --
From: Florian Fainelli
If irq_of_parse_and_map fails to find an interrupt line for a given PHY,
we will force the PHY interrupt to be PHY_POLL, completely overriding
the previous value that the MDIO bus may have set for us (e.g:
PHY_IGNORE_INTERRUPT). In case of failure, just restore the previous
Hi all,
This patchset contains a few improvements to the MDIO device tree parsing
code such as refactoring and parsing the "max-speed" property which is
defined in the ePAPR specification.
Thanks!
Florian Fainelli (7):
net: of_mdio: factor PHY registration from of_mdiobus_register
net: of_md
From: Florian Fainelli
The ARC emac driver was the only in-tree to parse a PHY device
'max-speed' property but yet failed to do it correctly because
'max-speed' is supposed to set a PHY device supported features, not the
advertising features as it was done.
Now that of_mdiobus_register() takes c
From: Florian Fainelli
Breakdown the PHY_*_FEATURES into per speed defines such that we can
easily re-use them individually.
Signed-off-by: Florian Fainelli
---
include/linux/phy.h | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/include/linux/phy.h
On Thu, Dec 5, 2013 at 4:53 PM, delicious quinoa
wrote:
> On Thu, Dec 5, 2013 at 10:54 AM, Jamie Iles wrote:
>> Hi Alan,
>>
>> One minor comment below, otherwise looks great!
>>
>> Signed-off-by: Jamie Iles
>>
>> Thanks,
>>
>> Jamie
>>
>> On Tue, Dec 03, 2013 at 10:41:16AM -0600, Alan Tull wrote
On Wed, Dec 4, 2013 at 5:56 AM, Mark Rutland wrote:
> On Tue, Dec 03, 2013 at 04:41:16PM +, Alan Tull wrote:
>> From: Jamie Iles
>>
>> The Synopsys DesignWare block is used in some ARM devices (picoxcell)
>> and can be configured to provide multiple banks of GPIO pins.
>>
>> Signed-off-by: Al
On Thu, Dec 5, 2013 at 10:54 AM, Jamie Iles wrote:
> Hi Alan,
>
> One minor comment below, otherwise looks great!
>
> Signed-off-by: Jamie Iles
>
> Thanks,
>
> Jamie
>
> On Tue, Dec 03, 2013 at 10:41:16AM -0600, Alan Tull wrote:
>> diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.
The sdio1 interface pins are routed to an unpopulated daughter card
connector on the bcm28155-ap board. Thus there is no need to mark
this interface as enabled.
Signed-off-by: Tim Kryger
Reviewed-by: Matt Porter
---
arch/arm/boot/dts/bcm28155-ap.dts | 5 -
1 file changed, 5 deletions(-)
d
On Thu, 2013-12-05 at 22:08 +0100, Arnd Bergmann wrote:
> On Thursday 05 December 2013, dingu...@altera.com wrote:
> > From: Dinh Nguyen
> >
> > Re-use the "rockchip,rk2928-dw-mshc" binding that will support SD/MMC on
> > Altera's SOCFPGA platform.
> >
> > Signed-off-by: Dinh Nguyen
> > ---
> >
The board schematic states that the "SD_CARD_DET_N gets pulled to GND
when card is inserted" so the polarity has been updated to active low.
Polarity is now specified with a GPIO define instead of a magic number.
Signed-off-by: Tim Kryger
Reviewed-by: Matt Porter
---
arch/arm/boot/dts/bcm28155
On Wed, Dec 04, 2013 at 11:34:32AM +0100, Thierry Reding wrote:
> On Wed, Sep 25, 2013 at 01:22:55PM +0900, Milo Kim wrote:
> > mfd: add LP3943 MFD driver
> > gpio: add LP3943 I2C GPIO expander driver
> > pwm: add LP3943 PWM driver
> > Documentation: add LP3943 DT bindings and document
>
On Thursday 05 December 2013, dingu...@altera.com wrote:
> From: Dinh Nguyen
>
> Re-use the "rockchip,rk2928-dw-mshc" binding that will support SD/MMC on
> Altera's SOCFPGA platform.
>
> Signed-off-by: Dinh Nguyen
> ---
> v3: Re-use "rockchip,rk2928-dw-mshc" binding
> v3: none
> v2: none
> ---
On Thursday 05 December 2013, dingu...@altera.com wrote:
> From: Dinh Nguyen
>
> Populate the .prepare function in the clk-ops for the "sdmmc_clk" that
> represents
> the "ciu" clock for the SD/MMC driver. The prepare function will handle
> setting
> the correct clock-phase for the CIU clock of
On Thursday, December 05, 2013 at 07:28:09 PM, Denis Carikli wrote:
> Cc: Dan Carpenter
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Stephen Warren
> Cc: Ian Campbell
> Cc: devicetree@vger.kernel.org
> Cc: Greg Kroah-Hartman
> Cc: driverdev-de...@linuxdriverproject.org
> Cc: D
On Thursday, December 05, 2013 at 07:28:07 PM, Denis Carikli wrote:
[...]
Can you please explain the correction here ? Why is it needed ? What was the
problem ?
Thanks!
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to
This series declares the clocks present on bcm11351 (aka bcm281xx) SoCs
to be fixed at the rates configured by development bootloaders and then
updates the Kona drivers to make use of clock calls where appropriate.
Changes in v4:
- Rebased on v3.13-rc2
- DT binding documents now say "phandle +
The frequency for the Kona timer can either be specified through the
device tree or determined by checking the rate of the clock specified
in the device tree. Update the documentation to reflect both ways.
Signed-off-by: Tim Kryger
Reviewed-by: Matt Porter
---
Documentation/devicetree/bindings
When an clock is specified in the device tree, enable it and use it to
determine the external clock frequency.
Signed-off-by: Tim Kryger
Reviewed-by: Markus Mayer
Reviewed-by: Matt Porter
---
drivers/clocksource/bcm_kona_timer.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletion
Enable the external clock needed by the host controller during the
probe and disable it during the remove.
Signed-off-by: Tim Kryger
Reviewed-by: Markus Mayer
Reviewed-by: Matt Porter
---
drivers/mmc/host/sdhci-bcm-kona.c | 37 +++--
1 file changed, 35 insertion
The frequency property in "snps,dw-apb-uart" entries are no longer
required if the rate of the external clock can be determined using the
clk api (see e302cd9 serial: 8250_dw: add support for clk api).
This patch replaces the frequency property in the UART nodes of
bcm11351.dtsi with references to
Declare clocks that are enabled and configured by bootloaders as fixed
rate clocks in the DTS such that device drivers may use standard clock
function calls.
Signed-off-by: Tim Kryger
Reviewed-by: Markus Mayer
Reviewed-by: Matt Porter
---
arch/arm/boot/dts/bcm11351.dtsi | 97 ++
Specify the external clock label in each SDHCI node.
Signed-off-by: Tim Kryger
Reviewed-by: Markus Mayer
Reviewed-by: Matt Porter
---
arch/arm/boot/dts/bcm11351.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index
The Kona SDHCI block requires a clock that must be specified in the
device tree. Update the documentation to reflect this requirement.
Signed-off-by: Tim Kryger
Reviewed-by: Matt Porter
---
Documentation/devicetree/bindings/mmc/kona-sdhci.txt | 4
1 file changed, 4 insertions(+)
diff --g
Specify the external clock label in the timer node.
Signed-off-by: Tim Kryger
Reviewed-by: Markus Mayer
Reviewed-by: Matt Porter
---
arch/arm/boot/dts/bcm11351.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.
Tomasz,
On Thu, Dec 5, 2013 at 10:59 AM, Tomasz Figa wrote:
> On Thursday 05 of December 2013 10:35:20 Doug Anderson wrote:
>> Tomasz,
>>
>> On Thu, Dec 5, 2013 at 10:30 AM, Tomasz Figa wrote:
>> >> I'd vote for using "pmu-system-registers". We end up using the
>> >> "syscon" subsystem but real
On Thu, 5 Dec 2013, Kamil Debski wrote:
> Change the phy provider used from the old usb phy specific to a new one
> using the generic phy framework.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Kyungmin Park
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @
On Thursday 05 of December 2013 10:35:20 Doug Anderson wrote:
> Tomasz,
>
> On Thu, Dec 5, 2013 at 10:30 AM, Tomasz Figa wrote:
> >> I'd vote for using "pmu-system-registers". We end up using the
> >> "syscon" subsystem but really we're describing pmu registers.
> >>
> >> I'd even say that you d
On Thu, Dec 5, 2013 at 2:06 AM, Yuvaraj Kumar C D wrote:
> Commits 64c138a ("ARM: dts: Move fifo-depth property from exynos5250
> board dts") and 0c3de788 ("ARM: dts: change status property of dwmmc
> nodes for exynos5250") missed out handling the exynos5250 snow dts file.
> Delete the fifo-depth
* Sourav Poddar [131128 02:10]:
> On Thursday 28 November 2013 02:58 PM, Peter Ujfalusi wrote:
> >Since in DT booted kernel dummy regulators are no longer supported we need
> >to provide valid phandle for the regulator needed by the backlight.
> >On the board VBAT is used to power the LCD backligh
Tomasz,
On Thu, Dec 5, 2013 at 10:30 AM, Tomasz Figa wrote:
>> I'd vote for using "pmu-system-registers". We end up using the
>> "syscon" subsystem but really we're describing pmu registers.
>>
>> I'd even say that you don't need to formally specify the "name" in the
>> bindings (though I'm not
On Thursday 05 of December 2013 10:26:18 Doug Anderson wrote:
> Leela Krishna,
>
> On Mon, Dec 2, 2013 at 11:49 AM, Tomasz Figa wrote:
> > On Monday 02 of December 2013 10:50:14 Olof Johansson wrote:
> >> Hi,
> >>
> >> On Wed, Nov 27, 2013 at 8:34 PM, Leela Krishna Amudala
> >> wrote:
> >> > Thi
Cc: Dan Carpenter
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: devicetree@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: driverdev-de...@linuxdriverproject.org
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: Sascha Hauer
Cc: Shawn Guo
Cc: li
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: devicetree@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: driverdev-de...@linuxdriverproj
1 - 100 of 198 matches
Mail list logo
