linux-stable.git/arch/arm/boot, branch linux-4.8.y

ARM: dts: imx7d: fix LCDIF clock assignment

2016-12-15T16:50:36+00:00

commit 4b707fa00a80b19b80bc8df6f1cbf4bdd9c91402 upstream.

The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them
separately:

Clock      Clock Root              Description
apb_clk    MAIN_AXI_CLK_ROOT       AXI clock
pix_clk    LCDIF_PIXEL_CLK_ROOT    Pixel clock
ipg_clk_s  MAIN_AXI_CLK_ROOT       Peripheral access clock

All of them are switched by a single gate, which is part of the
IMX7D_LCDIF_PIXEL_ROOT_CLK clock. Hence using that clock also for
the AXI bus clock (clock-name "axi") makes sure the gate gets
enabled when accessing registers.

There seem to be no separate AXI display clock, and the clock is
optional. Hence remove the dummy clock.

This fixes kernel freezes when starting the X-Server (which
disables/re-enables the display controller).

Fixes: e8ed73f691bd ("ARM: dts: imx7d: add lcdif support")
Signed-off-by: Stefan Agner 
Reviewed-by: Fabio Estevam 
Acked-by: Shawn Guo 
Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: orion5x: fix number of sata port for linkstation ls-gl

2016-12-15T16:50:36+00:00

commit 038ccb3e8cee52e07dc118ff99f47eaebc1d0746 upstream.

Bug report from Debian [0] shows there's minor changed model of
Linkstation LS-GL that uses the 2nd SATA port of the SoC.
So it's necessary to enable two SATA ports, though for that specific
model only the 2nd one is used.

[0] https://bugs.debian.org/845611

Fixes: b1742ffa9ddb ("ARM: dts: orion5x: add device tree for buffalo linkstation ls-gl")
Reported-by: Ryan Tandy 
Tested-by: Ryan Tandy 
Signed-off-by: Roger Shimizu 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: imx53-qsb: Fix regulator constraints

2016-11-26T08:56:55+00:00

commit e3c9d9d6ebfeeeee29c6240e1b5978d40d31d21f upstream.

Since commit fa93fd4ecc9c ("regulator: core: Ensure we are at least in
bounds for our constraints") the imx53-qsb board populated with a Dialog
DA9053 PMIC fails to boot:

LDO3: Bringing 3300000uV into 1800000-1800000uV

The LDO3 voltage constraints passed in the device tree do not match
the valid range according to the datasheet, so fix this accordingly to
allow the board booting again.

While at it, fix the other voltage constraints as well.

Signed-off-by: Fabio Estevam 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: fix the SD card on the Snowball

2016-11-10T15:38:51+00:00

commit 1b283eea6228880b765bc40fe4e555416437ce58 upstream.

This fixes a very annoying regression on the Snowball SD card
that has been around for a while. It turns out that the device
tree does not configure the direction pins properly, nor sets
up the pins for the voltage converter properly at boot. Unless
all things are correctly set up, the feedback clock will not
work, and makes the driver spew messages in the console (but
it works, very slowly):

root@Ux500:/ mount /dev/mmcblk0p2 /mnt/
[    9.953460] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[    9.960296] mmcblk0: error -110 sending status command, retrying
[    9.966461] mmcblk0: error -110 sending status command, retrying
[    9.972534] mmcblk0: error -110 sending status command, aborting

Fix this by rectifying the device tree to correspond to that of
the Ux500 HREF boards plus the DAT31DIR setting that is unique for
the Snowball, and things start working smoothly. Add in the SDR12
and SDR25 modes which this host can do without any problems.

I don't know if this has ever been correct, sadly. It works after
this patch.

Reported-by: Daniel Lezcano 
Cc: Ulf Hansson 
Signed-off-by: Linus Walleij 
Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: omap3: overo: add missing unit name for lcd35 display

2016-10-31T11:02:15+00:00

commit 0b965a13ad81fa895e534d1f50b355ff8b0b3ed3 upstream.

Commit b8d368caa8dc ("ARM: dts: omap3: overo: remove unneded unit names
in display nodes") removed the unit names for all Overo display nodes
that didn't have a reg property.

But the display in arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi does
have a reg property so the correct fix was to make the unit name match
the value of the reg property, instead of removing it.

This patch fixes the following DTC warning for boards using this dtsi:

"ocp/spi@48098000/display has a reg or ranges property, but no unit name"

Fixes: b8d368caa8dc ("ARM: dts: omap3: overo: remove unneded unit names in display nodes")
Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: fix RealView EB SMSC ethernet version

2016-10-31T11:02:15+00:00

commit c4ad72560df11961d3e57fb0fadfe88a9863c9ad upstream.

The ethernet version in the earlier RealView EB variants is
LAN91C111 and not LAN9118 according to ARM DUI 0303E
"RealView Emulation Baseboard User Guide" page 3-57.

Make sure that this is used for the base variant of the board.

As the DT bindings for LAN91C111 does not specify any power
supplies, these need to be deleted from the DTS file.

Fixes: 2440d29d2ae2 ("ARM: dts: realview: support all the RealView EB board variants")
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: NSP: Correct RAM amount for BCM958625HR board

2016-10-31T11:02:15+00:00

commit c53beb47f621e4a56f31af9f86470041655516c7 upstream.

The BCM958625HR board has 2GB of RAM available.  Increase the amount
from 512MB to 2GB and add the device type to the memory entry.

Fixes: 9a4865d42fe5 ("ARM: dts: NSP: Specify RAM amount for BCM958625HR board")
Signed-off-by: Jon Mason 
Signed-off-by: Florian Fainelli 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: sun9i: Add missing #interrupt-cells to R_PIO pinctrl device node

2016-10-31T11:02:14+00:00

commit 06ad11be7a9e13499ff8e55e46f09d22f9ee6fc0 upstream.

The R_PIO device node is missing #interrupt-cells, which causes
interrupt parsing to fail to match it as a valid interrupt controller.

Add #interrupt-cells to it. Also remove the unnecesary #address-cells
and #size-cells.

Fixes: 1ac56a6da9e1 ("ARM: dts: sun9i: Add A80 R_PIO pin controller device
		      node")
Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: MSM8660 remove flags from SPMI/MPP IRQs

2016-10-16T16:03:40+00:00

commit dcf5907e0e09a160a57160729f920add5df8e358 upstream.

The Qualcomm SPMI GPIO and MPP lines are problematic: the
are fetched from the main MFD driver with platform_get_irq()
which means that at this point they will all be assigned the
flags set up for the interrupts in the device tree.

That is problematic since these are flagged as rising edge
and an this point the interrupt descriptor is assigned a
rising edge, while the only thing the GPIO/MPP drivers really
do is issue irq_get_irqchip_state() on the line to read it
out and to provide a .to_irq() helper for *other* IRQ
consumers.

If another device tree node tries to flag the same IRQ
for use as something else than rising edge, the kernel
irqdomain core will protest like this:

  type mismatch, failed to map hwirq-NN for !

Which is what happens when the device tree defines two
contradictory flags for the same interrupt line.

To work around this and alleviate the problem, assign 0
as flag for the interrupts taken by the PM GPIO and MPP
drivers. This will lead to the flag being unset, and a
second consumer requesting rising, falling, both or level
interrupts will be respected. This is what the qcom-pm*.dtsi
files already do.

Switched to using the symbolic name IRQ_TYPE_NONE so that
we get this more readable.

This misconfiguration was caused by a copy/pasting the
APQ8064 set-up, the latter has been fixed in a separate
patch.

Tested with one of the SPMI GPIOs: after this I can
successfully request one of these GPIOs as falling edge
from the device tree.

Fixes: 0840ea9e4457 ("ARM: dts: add GPIO and MPP to MSM8660 PMIC")
Cc: Srinivas Kandagatla 
Cc: Stephen Boyd 
Cc: Björn Andersson 
Cc: Ivan T. Ivanov 
Cc: John Stultz 
Cc: Andy Gross 
Signed-off-by: Linus Walleij 
Signed-off-by: Andy Gross 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: MSM8064 remove flags from SPMI/MPP IRQs

2016-10-16T16:03:40+00:00

commit ca88696e8b73a9fa2b1de445747e9235c3a7bd50 upstream.

The Qualcomm PMIC GPIO and MPP lines are problematic: the
are fetched from the main MFD driver with platform_get_irq()
which means that at this point they will all be assigned the
flags set up for the interrupts in the device tree.

That is problematic since these are flagged as rising edge
and an this point the interrupt descriptor is assigned a
rising edge, while the only thing the GPIO/MPP drivers really
do is issue irq_get_irqchip_state() on the line to read it
out and to provide a .to_irq() helper for *other* IRQ
consumers.

If another device tree node tries to flag the same IRQ
for use as something else than rising edge, the kernel
irqdomain core will protest like this:

  type mismatch, failed to map hwirq-NN for !

Which is what happens when the device tree defines two
contradictory flags for the same interrupt line.

To work around this and alleviate the problem, assign 0
as flag for the interrupts taken by the PM GPIO and MPP
drivers. This will lead to the flag being unset, and a
second consumer requesting rising, falling, both or level
interrupts will be respected. This is what the qcom-pm*.dtsi
files already do.

Switched to using the symbolic name IRQ_TYPE_NONE so that
we get this more readable.

Fixes: bce360469676 ("ARM: dts: apq8064: add pm8921 mpp support")
Fixes: 874443fe9e33 ("ARM: dts: apq8064: Add pm8921 mfd and its gpio node")
Cc: Srinivas Kandagatla 
Cc: Stephen Boyd 
Cc: Björn Andersson 
Cc: Ivan T. Ivanov 
Cc: John Stultz 
Cc: Andy Gross 
Signed-off-by: Linus Walleij 
Signed-off-by: Andy Gross 
Signed-off-by: Greg Kroah-Hartman