Add hscif{0|1|2} nodes to dtsi for HSCIF support on the
RZ/G1C (r8a77470) SoC.
Signed-off-by: Cao Van Dong <cv-dong@jinso.co.jp>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Even though upstream Linux doesn't yet go into deep enough suspend to
get DDR into self refresh, there is no harm in setting these pins up.
They'll only actually do something if we go into a deeper suspend but
leaving them configed always is fine.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The functions rk3288_config_bootdata() and rk3288_suspend_init() are
only called in the context of rockchip_suspend_init() which is already
marked __init. We can mark them __init too.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The value was determined with the following method:
- take CPUs 1-3 offline
- for each OPP
- set cpufreq min and max freq to OPP freq
- start dhrystone benchmark
- measure CPU power consumption during 10s
- calculate Cx for OPPx
- Cx = (Px - P1) / (Vx²fx - V1²f1) [1]
using the following units: mW / Ghz / V [2]
- C = avg(C2, ..., Cn)
[1] see commit 4daa001a17 ("arm64: dts: juno: Add cpu
dynamic-power-coefficient information")
[2] https://patchwork.kernel.org/patch/10493615/#22158551
FTR, these are the values for the different OPPs:
freq (kHz) mV Px (mW) Cx
126000 900 39
216000 900 66 370
312000 900 95 372
408000 900 122 363
600000 900 177 359
696000 950 230 363
816000 1000 297 361
1008000 1050 404 362
1200000 1100 528 362
1416000 1200 770 377
1512000 1300 984 385
1608000 1350 1156 394
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add GPIO D5 (BT_ENABLE_L) as reset-GPIO to the power sequence for the
Bluetooth/WiFi module. On devices with a Broadcom module the signal
needs to be asserted to use Bluetooth.
Note that BT_ENABLE_L is a misnomer in the schematics, the signal
actually is active-high.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Some veyron devices have a Bluetooth controller connected on UART0.
The UART needs to operate at a high speed, however setting the clock
rate at initialization has no practical effect. During initialization
user space adjusts the UART baudrate multiple times, which ends up
changing the SCLK rate. After a successful initiatalization the clk
is running at the desired speed (48MHz).
Remove the unnecessary clock rate configuration from the DT.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This patch adds a new property (power-supply) to panel otm8009a (orisetech)
on stm32mp157c-dk2 & regulator v3v3.
Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
This patch adds stpmic1 support on stm32mp157a dk1 board.
The STPMIC1 is a PMIC from STMicroelectronics. The STPMIC1 integrates 10
regulators, 3 power switches, a watchdog and an input for a power on key.
The DMAs are disabled because the PMIC generates a very few traffic and
DMA channels may lack for other usage.
Signed-off-by: Pascal Paillet <p.paillet@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
This patch adds stpmic1 support on stm32mp157c ed1 board.
The STPMIC1 is a PMIC from STMicroelectronics. The STPMIC1 integrates 10
regulators, 3 power switches, a watchdog and an input for a power on key.
The DMAs are disabled because the PMIC generates a very few traffic and
DMA channels may lack for other usage.
Signed-off-by: Pascal Paillet <p.paillet@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Add & enable stm32 factory-programmed memory. Describe temperature sensor
calibration cells. Non-volatile calibration data is made available by
stm32mp157c bootrom in bsec_dataX registers.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
This patch adds sdmmc1 support on stm32h743i eval board.
This board has an external driver to control signal direction polarity.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Update i.MX6DL automotive part's opp table according to i.MX6DL
automotive datasheet Rev.9, 11/2018, it adds 996MHz set-point
support as below:
LDO enabled(min value):
996MHz: VDDARM: 1.275V, VDDSOC: 1.175V;
792MHz: VDDARM: 1.150V, VDDSOC: 1.150V;
396MHz: VDDARM: 1.125V, VDDSOC: 1.150V;
Adding 25mV to cover board IR drop, for LDO enabled mode of 996MHz,
as the max value of LDO output can NOT exceed 1.3V, so 25mV is NOT
added for VDDARM.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The devicetree specification recommends using generic node names.
Some Zii dts files already follow such recommendation, but some don't,
so use generic node names for consistency among the Zii dts files.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Some USB peripherals draw more power, and the sourcing regulator
take a little time to turn on. This patch fixes an issue where
some devices occasionally do not get detected, because the power
isn't quite ready when communication starts, so we add a bit
of a delay.
Fixes: 1c207f911f ("ARM: dts: imx: Add support for Logic PD i.MX6QD EVM")
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The main 3.3V regulator sources a series of additional regulators.
This patch adds a small delay, so when the 3.3V regulator comes
on it delays a bit before the subsequent regulators can come on.
This reduces the inrush current a bit on the external DC power
supply to help prevent a situation where the sourcing power supply
cannot source enough current and overloads and the kit fails to
start.
Fixes: 1c207f911f ("ARM: dts: imx: Add support for Logic PD i.MX6QD EVM")
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The LCD power sequencer is very finicky. The backlight cannot
be driven until after the sequencer is done. Until now, the
regulators were marked with 'regulator-always-on' to make sure
it came up before the backlight. This patch allows the LCD
regulators to power down and prevent the backlight from being
used again until the sequencer is ready. This reduces
standby power consumption by ~100mW.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The original submission had functional audio out and was based
on reviewing other boards using the same wm8962 codec. However,
the Logic PD board uses an analog microphone which was being
disabled for a digital mic. This patch corrects that and
explicitly sets the gpio-cfg pins all to 0x0000 which allows the
analog microphone to capture audio.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The Kobo Aura is an e-book reader released in 2013.
With the devicetree in its current state, the kernel will boot and run
for about ten seconds. To solve this, the embedded controller needs to
be told that the system should stay powered on. This will be done in a
later patchset.
- The IOMUXC mode bits for the SD interfaces were taken from the
vendor's U-Boot fork.
- The bus width of the eMMC is 4 bits in the vendor kernel, but I
achieved better performance with 8 bits.
- The SDIO clock frequency for the WiFi chip is 25MHz in the vendor
kernel, but the WiFi chip (BCM43362) supports 50MHz, which works
reliably on this board and gives slightly better performance.
- The I2C pins' IOMUXC settings come from the vendor's U-Boot fork.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Commit 6d4cd041f0 ("net: phy: at803x: disable delay only for RGMII mode")
exposed an issue on imx DTS files using AR8031/AR8035 PHYs.
The end result is that the boards can no longer obtain an IP address
via UDHCP, for example.
Quoting Andrew Lunn:
"The problem here is, all the DTs were broken since day 0. However,
because the PHY driver was also broken, nobody noticed and it
worked. Now that the PHY driver has been fixed, all the bugs in the
DTs now become an issue"
To fix this problem, the phy-mode property needs to be "rgmii-id", which
has the following meaning as per
Documentation/devicetree/bindings/net/ethernet.txt:
"RGMII with internal RX and TX delays provided by the PHY, the MAC should
not add the RX or TX delays in this case)"
Tested on imx6-sabresd, imx6sx-sdb and imx7d-pico boards with
successfully restored networking.
Based on the initial submission from Steve Twiss for the
imx6qdl-sabresd.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Baruch Siach <baruch@tkos.co.il>
Tested-by: Soeren Moch <smoch@web.de>
Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Tested-by: Adam Thomson <Adam.Thomson@diasemi.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", the driver now accepts this name, use it here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", the driver now accepts this name, use it here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", the driver now accepts this name, use it here.
Note the GPIO polarity in the driver was ignored before and always
assumed to be active low, when all the DTs are fixed we will start
respecting the specified polarity. Switch polarity in DT to the
currently assumed one, this way when the driver changes the
behavior will not change.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
