The H3 and H5 have never been converted to the new convention we want to
have for the pinctrl nodes.
Convert them.
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Some nodes still have pinctrl-names entry, yet they don't have any pinctrl
group anymore. Drop them.
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
i.MX fixes for 5.1:
- Correct phy mode setting of imx6dl-yapp4 board to fix a problem
caused by commit 5ecdd77c61 ("net: dsa: qca8k: disable delay
for RGMII mode").
- Add a missing of_node_put call to fix leaked reference detected by
coccinelle in imx51 machine code.
- Fix imx6q cpuidle driver bug which causes that CPU might not wake up
at expected time.
- Increase reset duration of Ethernet phy Micrel KSZ9031RNX to fix
transmission timeouts error seen on imx6qdl-phytec-pfla02 board.
- Correct SPDX License Identifier style for imx6ull-pinfunc-snvs.h.
- Fix 'bus-witdh' typos in imx6qdl-icore-rqs.dtsi.
- Correct pseudo PHY address of switch device for imx6dl-yapp4 board.
- Update PWM driver options in imx defconfig files due to the change
on driver part.
* tag 'imx-fixes-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: imx_v4_v5_defconfig: enable PWM driver
ARM: imx_v6_v7_defconfig: continue compiling the pwm driver
ARM: dts: imx6dl-yapp4: Use correct pseudo PHY address for the switch
ARM: dts: imx6qdl: Fix typo in imx6qdl-icore-rqs.dtsi
ARM: dts: imx6ull: Use the correct style for SPDX License Identifier
ARM: dts: pfla02: increase phy reset duration
ARM: imx6q: cpuidle: fix bug that CPU might not wake up at expected time
ARM: imx51: fix a leaked reference by adding missing of_node_put
ARM: dts: imx6dl-yapp4: Use rgmii-id phy mode on the cpu port
This pull request contains Broadcom ARM-based SoCs Device Tree fixes for
5.1, please pull the following:
- Helen fixes the HDMI hot-pug detect GPIO polarity for the Rasperry Pi
model B revision 2
* tag 'arm-soc/for-5.1/devicetree-fixes' of https://github.com/Broadcom/stblinux:
ARM: dts: bcm283x: Fix hdmi hpd gpio pull
The SPI DT bindings are for historical reasons a pitfall,
the ability to flag a GPIO line as active high/low with
the second cell flags was introduced later so the SPI
subsystem will only accept the bool flag spi-cs-high
to indicate that the line is active high.
It worked by mistake, but the mistake was corrected
in another commit.
The comment in the DTS file was also misleading: this
CS is indeed active high.
Fixes: cffbb02daf ("ARM: dts: nomadik: Augment NHK15 panel setting")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
They are pointless. As dtc points out:
Warning (avoid_unnecessary_addr_size):
/gpio-keys:
unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Let's remove them.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
They are pointless. As dtc points out:
Warning (avoid_unnecessary_addr_size):
/mipi@ff960000:
unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Let's remove them.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The device tree compiler yells like this:
Warning (unit_address_vs_reg):
/gpu-opp-table/opp@100000000:
node has a unit name, but no reg property
Let's match the cpu opp node names and use a dash.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The vdd_logic rail controls the voltage supplied to misc logic on
rk3288, including the voltage supplied to the memory controller. The
vcc logic is implemented by a PWM regulator.
Right now there are no consumers of vdd_logic on veyron but if anyone
ever wants to try to add DDR Freq they'd need it.
Note that in the downstream Chrome OS kernel the PWM regulator has
a voltage table with these points:
1350000 0%
1300000 10%
1250000 20%
1200000 31%
1150000 41%
1125000 46%
1100000 52%
1050000 62%
1000000 72%
950000 83%
The DDR Freq driver in the downstream kernel only uses some of those
points, namely:
DDR3: 1200000, 1150000, 1100000, 1050000
LPDDR: 1150000, 1100000, 1050000
When adapting the downstream kernel to upstream I have opted to switch
to using the "continuous" mode of the PWM regulator driver. This was
the only way I could get the upstream driver to achieve _exactly_ the
same voltages as the downstream driver could. Specifically note that
the old driver in downstream Chrome OS 3.14 _didn't_ have the
DIV_ROUND_CLOSEST_ULL() in the Rockchip PLL driver. That means if I
use the same (downstream) table I might end up with a duty cycle
that's 1 larger than was used downstream, leading to a slightly
different voltage. Due to the way the rounding worked I couldn't even
just adjust the "percent" by 1 for a given voltage level--certain duty
cycles just aren't achievable with the upstream math for voltage
tables.
Using continuous mode you can achieve the exact same duty cycle by
simply adjusting the voltage you use by a tad bit. The voltages that
are equivalent to the ones used in the downstream kernel's table are:
1350000, 1304472, 1255691, 1200407, 1154878,
1128862, 1099593, 1050813, 1005285, 950000
Note that the top/bottom voltage is exactly the same just due to the
way that continuous mode is calculated and the fact that I used those
as anchors. I didn't make any attempt to do the resistor math (as was
done on rk3399-gru).
If anyone ever gets DDRFreq working on veyron upstream they should
thus adjust the voltage specified in the DDRFreq operating points
slightly (as per the above) to obtain the existing/tested values. AKA
you'd use:
DDR3: 1200407, 1154878, 1099593, 1050813
LPDDR: 1154878, 1099593, 1050813
A few other notes:
- The "period" here (1994) is different than the "period" downstream
(2000) for similar reasons: there's a DIV_ROUND_CLOSEST_ULL() that
wasn't downstream. With 1994 upstream comes up with the same value
(0x94) to program into the hardware that downstream put there. As
far as I can tell 0x94 actually means 1993.27.
- The duty cycle unit of 0x94 was picked by just matching the period
which nicely allows us to insert 0x7b as that value to program into
the hardware for 950mV. The 0x7b was found by observing what the
downstream kernel calculated (not that the system can actually run
with vdd_log at 950 mV).
- The downstream kernel can also be seen to program a different value
into the CTRL field. Upstream achieves 0x0b and downstream 0x1b.
This is because the upstream commit bc834d7b07 ("pwm: rockchip:
Move the configuration of polarity") fixed a bug by adding "ctrl &=
~PWM_POLARITY_MASK". Downstream accidentally left bit 4 set.
Luckily this bit doesn't matter--it's only used when the PWM goes
inactive (AKA if it's in oneshot mode or is disabled) and we don't
do that for the PWM regulator.
I measured the voltage of vdd_log while adjusting it and found that
with the upstream kernel voltage difference between requested and
actual was 9.2 mV at 950 mV and 13.4 mV at 1350 mV with in-between
voltages consistently showing ~1% error. This error is likely
expected as voltage can be seen to sag a bit when more load is put on
the rail.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
When the rk3288-jerry device tree was first submitted we left out the
dvs-gpios because I pointed out that the property "dvs-gpios" wasn't
yet supported upstream [1]. Soon after that the property was added in
commit bad47ad2ee ("regulator: rk808: fixed the overshoot when
adjust voltage"). ...but we forgot to go back and add the property to
the jerry device tree file. Let's do so now.
NOTE: without this patch, jerry is likely still stable (thanks to the
fallback of making many small jumps in the rk808 regulator code) but
it'll take quite a bit longer to make voltage transitions.
[1] https://lore.kernel.org/linux-arm-kernel/CAD=FV=WwFgjzbk9xF5TU_ie6UnHQMyrZ176D4+jJTWWOoaKC2Q@mail.gmail.com/
Fixes: f3ee390e4e ("ARM: dts: rockchip: add veyron-jerry board")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
As far as I can tell/remember rev10 was originally created to support
making a SKU of jerry that had a different LCD. rev11-rev15 were
added to give some wiggle room for future builds. Downstream has a
separate device tree for rev10-rev15 (compared to rev3-rev7) with the
expectation that differences relating to the LCD would be accounted
for there but nothing was ever added to the rev10-rev15 making it
identical to the rev3-rev7 one.
It's likely nothing actually shipped with rev10-rev15 but they are
listed in the downstream kernel's device tree and it seems like it
should add a little safety if we match them here just in case
something actually shipped with one of these revisions and that device
will break if we don't claim support.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This patch adds HDMI video output support to the iwg23s board
from iWave. Due to a problem with the bootloader not dealing
with the configuration of one of the pins correctly, we have
to use a gpio-hog for the interrupt line to make sure the pin
is configured as GPIO-input when requesting the interrupt.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Commit d027521497 ("ARM: dts: sun8i-a23-a33: Move NAND controller device
node to sort by address") moved the NAND controller node around, but
dropped the default muxing in the process.
Reintroduce it.
Fixes: d027521497 ("ARM: dts: sun8i-a23-a33: Move NAND controller device node to sort by address")
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Correctly map the regulators used by tlv320aic3106.
Both 1.8V and 3.3V for the codec is derived from VBAT via fixed regulators.
Cc: <Stable@vger.kernel.org> # v4.14+
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Correctly map the regulators used by tlv320aic3106.
Both 1.8V and 3.3V for the codec is derived from VBAT via fixed regulators.
Cc: <Stable@vger.kernel.org> # v4.14+
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
After switching to the new FSL QSPI driver the properties
'fsl,qspi-has-second-chip' and 'big-endian' are not used anymore.
The driver now uses the 'reg' property to determine the bus and
the chipselect. The endianness is selected by the driver depending
on which SoC is used.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Even though the ChipIdea USB controller binding[1] doesn't specify the
properties that reference a PHY as required, the Linux driver
requires[2] such a reference.
The clock situation is like on i.MX53: The USB controller is clocked
from IMX5_CLK_USBOH3_GATE and the PHY from IMX5_CLK_USB_PHY1_GATE.
[1]: Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
[2]: Search for EINVAL in drivers/usb/chipidea/ci_hdrc_imx.c
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The switch is accessible through pseudo PHY which is located at 0x10.
Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
Fixes: 87489ec3a7 ("ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa boards")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
It can be seen that 0xffb40000 < 0xffc01000, thus efuse comes first.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The device tree binding already lists compatible strings for these two
SoCs. Add a device node for them.
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The 'max-brightness' property is not a valid one as per
Documentation/devicetree/bindings/leds/leds-gpio.txt, so remove it.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add MMDC1 compatible string which is missing, and also set
it to be disabled by default, as most of the platforms ONLY
use single channel MMDC0, if dual MMDC channels are used, it
can be enabled in board dts file.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Node name should be generic, so use "memory-controller"
instead of "mmdc" for MMDC node name, also remove "mmdc"
label for platforms with single MMDC node.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
i.MX7ULP has a MMDC module to control DDR, it reuses
i.MX6Q's MMDC module, add support for it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The name of CODEC input widget to which microphone is connected through
the "Headphone" jack is "IN12" not "IN1". This fixes microphone support
on Odroid XU3.
Cc: <stable@vger.kernel.org> # v4.14+
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
The imx6q Technical reference manual shows the interrupt is
available to wake from sleep using the power button. The driver
has been available for quite some time, and other variants of the
i.MX6 have it enabled, so this implements it much like the others.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Now that the backlight driver is upstream, we can properly manage the
backlight from the panel.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Increase the reset duration to ensure correct phy functionality. The
reset duration is taken from barebox commit 52fdd510de ("ARM: dts:
pfla02: use long enough reset for ethernet phy"):
Use a longer reset time for ethernet phy Micrel KSZ9031RNX. Otherwise a
small percentage of modules have 'transmission timeouts' errors like
barebox@Phytec phyFLEX-i.MX6 Quad Carrier-Board:/ ifup eth0
warning: No MAC address set. Using random address 7e:94:4d:02:f8:f3
eth0: 1000Mbps full duplex link detected
eth0: transmission timeout
T eth0: transmission timeout
T eth0: transmission timeout
T eth0: transmission timeout
T eth0: transmission timeout
Cc: Stefan Christ <s.christ@phytec.de>
Cc: Christian Hemp <c.hemp@phytec.de>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Fixes: 3180f95666 ("ARM: dts: Phytec imx6q pfla02 and pbab01 support")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
PMIC swbst regulator is used for the MikroBUS socket (pin +5V).
We have to set the regulator to "boot-on" and "always-on"
to output a voltage of 5V on this socket.
Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The PVDD_APIO_1V8 (LDO2) and PVDD_ABB_1V8 (LDO8) regulators were turned
off by Linux kernel as unused. However they supply critical parts of
SoC so they should be always on:
1. PVDD_APIO_1V8 supplies SYS pins (gpx[0-3], PSHOLD), HDMI level shift,
RTC, VDD1_12 (DRAM internal 1.8 V logic), pull-up for PMIC interrupt
lines, TTL/UARTR level shift, reset pins and SW-TACT1 button.
It also supplies unused blocks like VDDQ_SRAM (for SROM controller) and
VDDQ_GPIO (gpm7, gpy7).
The LDO2 cannot be turned off (S2MPS11 keeps it on anyway) so
marking it "always-on" only reflects its real status.
2. PVDD_ABB_1V8 supplies Adaptive Body Bias Generator for ARM cores,
memory and Mali (G3D).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Describe properly the MMC0 node (with attached embedded MMC memory) on
Arndale Octa by:
1. Adding the regulator for host interface (although it still has to be
"always-on" so the board with Linaro U-Boot will boot properly);
2. Using "non-removable" instead of "broken-cd" property, because eMMC
is embedded into the board;
3. Adding support for HS200 v1.8 to indicate such support in host
controller although this has no practical effect (embedded memory does
not support it).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
The Exynos5420's Mobile Storage Host supports SD cards in UHS-I standard
(SD specification v3.0), with 1.8 V signaling in SD UHS DDR50. Adjust
the regulator and add necessary capability properties. Change the SDR
and DDR timings to match values in Insignal v3.4 Android kernel.
Tested with SD UHS-I card in SD UHS DDR50 mode.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Although on the schematics of Insignal Arndale Octa board the
PVDD_MIFS_1V1 (ldo23) and PVDD_G3DS_1V0 (ldo27) are marked as 1.2 V, the
vendor v3.4 Android kernel sets them lower. Also name suggests that
they should work on 1.1 V and 1.0 V respectively, not 1.2 V.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Add missing audio routing entry for the capture stream, this change
is required to fix audio recording on Odroid XU3/XU3-Lite.
Fixes: 885b005d23 ("ARM: dts: exynos: Add support for secondary DAI to Odroid XU3")
Cc: stable@vger.kernel.org
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Arndale Octa (Exynos5420) has two ADC pins (AIN0 and AIN1) exposed on
CON6 header pins. Add ADC node to DTS file to enable it.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Use rgmii-id phy mode for the CPU port (MAC0) of the QCA8334 switch
to add delays to both Tx and Rx clock.
It worked with the rgmii mode before because the qca8k driver
(incorrectly) enabled delays in that mode and rgmii-id was not
implemented at all.
Commit 5ecdd77c61 ("net: dsa: qca8k: disable delay for RGMII mode")
removed the delays from the RGMII mode and hence broke the networking.
To fix the problem, commit a968b5e9d5 ("net: dsa: qca8k: Enable delay
for RGMII_ID mode") was introduced.
Now the correct phy mode is available so use it.
Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
