user/sven/linux.git/Documentation/devicetree, branch v4.9.103

clk: meson: meson8b: add compatibles for Meson8 and Meson8m2

2018-04-13T17:48:28Z

[ Upstream commit 855f06a1009faabb0c6a3e9b49d115496d325856 ] The clock controller on Meson8, Meson8b and Meson8m2 is very similar based on the code from the Amlogic GPL kernel sources. Add separate compatibles for each SoC to make sure that we can easily implement all the small differences for each SoC later on. In general the Meson8 and Meson8m2 seem to be almost identical as they even share the same mach-meson8 directory in Amlogic's GPL kernel sources. The main clocks on Meson8, Meson8b and Meson8m2 are very similar, because they are all using the same PLL values, 90% of the clock gates are the same (the actual diffstat of the mach-meson8/clock.c and mach-meson8b/clock.c files is around 30 to 40 lines, when excluding all commented out code). The difference between the Meson8 and Meson8b clock gates seem to be: - Meson8 has AIU_PCLK, HDMI_RX, VCLK2_ENCT, VCLK2_ENCL, UART3, CSI_DIG_CLKIN gates which don't seem to be available on Meson8b - the gate on Meson8 for bit 7 seems to be named "_1200XXX" instead of "PERIPHS_TOP" (on Meson8b) - Meson8b has a SANA gate which doesn't seem to exist on Meson8 (or on Meson8 the same bit is used by the UART3 gate in Amlogic's GPL kernel sources) None of these gates is added for now, since it's unclear whether these definitions are actually correct (the VCLK2_ENCT gate for example is defined, but only used in some commented block). The main difference between all three SoCs seem to be the video (VPU) clocks. Apart from different supported clock rates (according to vpu.c in mach-meson8 and mach-meson8b from Amlogic's GPL kernel sources) the most notable difference is that Meson8m2 has a GP_PLL clock and a mux (probably the same as on the Meson GX SoCs) to support glitch-free (clock rate) switching. None of these VPU clocks are not supported by our mainline meson8b clock driver yet though. Signed-off-by: Martin Blumenstingl Acked-by: Rob Herring Acked-by: Kevin Hilman Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

dt-bindings: display: sun4i: Add allwinner,tcon-channel property

2018-04-13T17:48:15Z

[ Upstream commit 22662f12768f971809b478386d9cc4947d00497a ] The Allwinner Timings Controller has two, mutually exclusive, channels. When the binding has been introduced, it was assumed that there would be only a single user per channel in the system. While this is likely for the channel 0 which only connects to LCD displays, it turns out that the channel 1 can be connected to multiple controllers in the SoC (HDMI and TV encoders for example). And while the simultaneous use of HDMI and TV outputs cannot be achieved, switching from one to the other at runtime definitely sounds plausible. Add an extra property, allwinner,tcon-channel, to specify for a given endpoint which TCON channel it is connected to, while falling back to the previous mechanism if that property is missing. Acked-by: Chen-Yu Tsai Acked-by: Rob Herring Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

2018-04-08T10:12:59Z

commit 0ea66f76ba17a4b229caaadd77de694111b21769 upstream. GPIO7 is configured in POWERHOLD mode which has higher priority over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON bit is turned off. This property enables driver to over ride the POWERHOLD value to GPIO7 so as to turn off the PMIC in power off scenarios. Signed-off-by: Keerthy Acked-by: Rob Herring Signed-off-by: Linus Walleij Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

omapdrm: panel: fix compatible vendor string for td028ttec1

2018-03-24T10:00:25Z

[ Upstream commit c1b9d4c75cd549e08bd0596d7f9dcc20f7f6e8fa ] The vendor name was "toppoly" but other panels and the vendor list have defined it as "tpo". So let's fix it in driver and bindings. We keep the old definition in parallel to stay compatible with potential older DTB setup. Signed-off-by: H. Nikolaus Schaller Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

dt-bindings: mfd: axp20x: Add "xpowers,master-mode" property for AXP806 PMICs

2018-03-24T10:00:16Z

[ Upstream commit 8461cf20d17e0090e9236b73d25b31be4f7fadc5 ] commit b101829a029a ("mfd: axp20x: Fix AXP806 access errors on cold boot") was intended to fix the case where a board uses an AXP806 in slave mode, but the boot loader leaves it in master mode for lack of AXP806 support. But now the driver breaks on boards where the PMIC is operating in master mode. To let the device tree describe which mode of operation is needed, this patch introduces a new property "xpowers,master-mode". Fixes: 204ae2963e10 ("mfd: axp20x: Add bindings for AXP806 PMIC") Signed-off-by: Rask Ingemann Lambertsen Acked-by: Chen-Yu Tsai Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

arm: spear13xx: Fix dmas cells

2018-02-22T14:43:53Z

commit cdd10409914184c7eee5ae3e11beb890c9c16c61 upstream. The "dmas" cells for the designware DMA controller need to have only 3 properties apart from the phandle: request line, src master and destination master. But the commit 6e8887f60f60 updated it incorrectly while moving from platform code to DT. Fix it. Cc: stable@vger.kernel.org # v3.10+ Fixes: 6e8887f60f60 ("ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT") Reported-by: Arnd Bergmann Signed-off-by: Viresh Kumar Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman

dt-bindings: usb: fix reg-property port-number range

2017-12-14T08:28:23Z

[ Upstream commit f42ae7b0540937e00fe005812997f126aaac4bc2 ] The USB hub port-number range for USB 2.0 is 1-255 and not 1-31 which reflects an arbitrary limit set by the current Linux implementation. Note that for USB 3.1 hubs the valid range is 1-15. Increase the documented valid range in the binding to 255, which is the maximum allowed by the specifications. Signed-off-by: Johan Hovold Signed-off-by: Rob Herring Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

hwmon: (jc42) optionally try to disable the SMBUS timeout

2017-12-05T10:24:34Z

commit 68615eb01f82256c19e41967bfb3eef902f77033 upstream. With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver is not always capable of avoiding the 25-35 ms timeout as specified by the SMBUS protocol. This may cause silent corruption of the last bit of any transfer, e.g. a one is read instead of a zero if the sensor chip times out. This also affects the eeprom half of the nxp-se97 chip, where this silent corruption was originally noticed. Other I2C adapters probably suffer similar issues, e.g. bit-banging comes to mind as risky... The SMBUS register in the nxp chip is not a standard Jedec register, but it is not special to the nxp chips either, at least the atmel chips have the same mechanism. Therefore, do not special case this on the manufacturer, it is opt-in via the device property anyway. Signed-off-by: Peter Rosin Acked-by: Rob Herring Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

Revert "dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification"

2017-11-21T08:23:28Z

This reverts commit 852bf68b7a62195c3c0c63f3b11f3f30958fc220. As Ben pointed out, these drivers don't exist in <=4.9. Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Revert "dt-bindings: Add vendor prefix for LEGO"

2017-11-21T08:23:28Z

This reverts commit 04e13a5ec96db94c1cc8ce7b0b1e1b626e0c00c7. As Ben pointed out, these drivers don't exist in <=4.9. Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman