While the USB PHY Device Tree mandates that the name of the ID detect pin
should be usb0_id_det-gpios, a significant number of device tree use
usb0_id_det-gpio instead.
This was functional because the GPIO framework falls back to the gpio
suffix that is legacy, but we should fix this.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Jernej Skrabec <jernej.skrabec@siol.net>
Link: https://lore.kernel.org/r/20210114113538.1233933-12-maxime@cerno.tech
Pull devicetree fixes from Rob Herring:
- Cleanups on properties with standard unit suffixes
- Fix overwriting dma_range_map if there's no 'dma-ranges' property
- Fix a bug when creating a /chosen node from ARM ATAGs
- Add missing properties for TI j721e USB binding
- Several doc reference updates due to DT schema conversions
* tag 'devicetree-fixes-for-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
dt-bindings: Cleanup standard unit properties
of/device: Update dma_range_map only when dev has valid dma-ranges
ARM: zImage: atags_to_fdt: Fix node names on added root nodes
dt-bindings: usb: j721e: add ranges and dma-coherent props
dt-bindings:iio:adc: update adc.yaml reference
dt-bindings: memory: mediatek: update mediatek,smi-larb.yaml references
dt-bindings: display: mediatek: update mediatek,dpi.yaml reference
ASoC: audio-graph-card: update audio-graph-card.yaml reference
This adds a "HPA1" prefix to the amplifiers on both audio cards, this is
done in order to get more consistency for userspace running on RDU2 and
RDU3, where we have two amplifiers on a single card device in the "Zest"
configuration.
Also adjust the card names to the new standard expected by userspace.
Signed-off-by: Cory Tusar <cory.tusar@zii.aero>
[adjusted commit message]
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The ALERT signaling happens on the falling edge of the signal, as rising
edge doesn't really have any notion, as it may happen much later (due to
shared IRQ line) or too early if the chip resolves the fault itself. So
only trigger the IRQ on the edge we are actually interested in.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
To use the reduced reporting mode the threshold values need to be set
explicitly. Configure the threshold to be less than 0.5% of the full
touchscreen range. This seems to be a good compromise between system
load and input accurancy.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The current 25 Ohm drive-strength is much too strong, resulting in
significant overshoot of the signal. Reduce the drive-strength to
75 Ohm to get rid of those issues.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Enable the i.MX6 WDOG1 internal watchdog for warm reboots. This allows
to issue emergency restarts without clearing the RAM, so collecting oops
logs from ramoops pstore in barebox becomes feasible.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
ARM: tegra: Device tree changes for v5.12-rc1
Fixes the pinmux configuration for the eMMC on the Ouya to fix issues
with certain bootloaders.
* tag 'tegra-for-5.12-arm-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
ARM: tegra: ouya: Fix eMMC on specific bootloaders
Link: https://lore.kernel.org/r/20210129193254.3610492-3-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Ouya fails to detect the eMMC module when booted via certain bootloaders.
Fastboot and hard-kexec bootloaders fail while u-boot does not. It was
discovered that the issue manifests if the sdmmc4 alternate configuration
clock pin is input disabled.
Ouya uses sdmmc4 in the primary pin configuration. It is unknown why this
occurs, though it is likely related to other eMMC limitations experienced
on Ouya.
For now, fix it by enabling input on cam_mclk_pcc0.
Fixes: d7195ac5c9 ("ARM: tegra: Add device-tree for Ouya")
Reported-by: Matt Merhar <mattmerhar@protonmail.com>
Tested-by: Matt Merhar <mattmerhar@protonmail.com>
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Devicetree changes for omaps for v5.12 merge window
This includes the following earlier patches that were considered too
late for v5.11 as discussed between Arnd and me on freenode #armlinux
in December:
- More updates to use cpsw switchdev driver
- Enable gta04 PMIC power management
- Updates for dra7 for ECC support, 1.8GHz speed and keep the
ldo0 regulator always on as specified in the data manual
And then we have the new devicetree changes:
- Configure the original Amazon Echo to for audio
- Configure missing thermal interrupt for omap4430
- Configure mapphone devices for passive thermal cooling, and add
1.2GHz mode.
- Correct omap4430 sgx clock rate to use the runtime Android kernel
value, the earlier value was for a lower power operating point
- Drop turbo mode for 1GHz omap3 variants as we now have passive
cooling configured
- Update email address for Javier
- Add new MYIR Tech Limited board support
* tag 'omap-for-v5.12/dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: am335x-myirtech-*: Add DT for AM335X MYIR Tech Limited board
ARM: dts: omap3-igep: Change email address in copyright notice
ARM: dts: omap36xx: Remove turbo mode for 1GHz variants
ARM: dts: omap443x: Correct sgx clock to 307.2MHz as used on motorola vendor kernel
ARM: dts: motorola-mapphone: Add 1.2GHz OPP
ARM: dts: motorola-mapphone: Configure lower temperature passive cooling
ARM: dts: Configure missing thermal interrupt for 4430
ARM: dts: omap3-echo: Add speaker sound card support
ARM: dts: dra71-evm: mark ldo0 regulator as always on
ARM: dts: dra76x: add support for OPP_PLUS
ARM: dts: am574x-idk: add support for EMIF1 ECC
ARM: dts: omap3-gta04: fix twl4030-power settings
ARM: dts: am335x-evm/evmsk/icev2: switch to new cpsw switch drv
ARM: dts: am33xx-l4: add dt node for new cpsw switchdev driver
Link: https://lore.kernel.org/r/pull-1611845066-809577@atomide.com-2
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Split up the pins for each fan. This is needed in order to control them
Fixes: ced8025b56 ("ARM: dts: armada388-helios4")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Newer Linksys boards might come with a Winbond W29N02GV which can be
configured in different ways. Make sure we configure it the same way
as the older chips so everything keeps working.
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
usbphyc is a 48Mhz clock provider: the clock can be used as clock source
for USB OTG. Add #clock-cells property to usbphyc node to reflect this
capability.
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Add SDA/SCL pinmux lines for I2C6 on STM32MP1.
This support adds both in default and sleep states.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Increase the SmartEEE Tw parameter for Atheros PHYs to stop gigabit
links from sporadically dropping. Jon Nettleton found that a value
of 23 was the minimum to give a stable link, but testing with the
Com Express 7 module shows 24 is the minimum - so 23 may still be on
the margins. Use 24 instead for consistency across SolidRun platforms.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Fixes for omaps for v5.11-rc cycle
The recent changes to switch SoCs to boot with ti-sysc interconnect
target module driver and genpd caused few regressions:
- The omap_prm reset driver needs to clear any reset bits deasserted by
the bootloader or kexec boot for the three reset bit cases. Otherwise
we can have an oops with accelerators starting to boot with potentially
unconfigured MMU for example
- Custom kernel configs are not automatically selecting simple-pm-bus
driver that we now need to probe interconnects so we need to select it
always
- We are not passing legacy platform data in auxdata with simple-pm-bus
like we do for simple-bus. We need to pass auxdata to simple-pm-bus so
it can pass it to of_platform_populate()
Then recent RCU changes started causing splats for cpuidle44xx that now
need RCU_NONIDLE added to the calls in several places
And then we have few device specific fixes:
- We need to remove legacy spi-cs-hig for gta04 display to work, and
set the gpio to active low
- Omap1 specific ohci-omap needs to call gpio_free()
- Droid4 needs to use padconf interrupt for the slider as the edge
gpio interrupts may be lost for deeper idle states
* tag 'omap-for-v5.11/fixes-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: omap4-droid4: Fix lost keypad slide interrupts for droid4
drivers: bus: simple-pm-bus: Fix compatibility with simple-bus for auxdata
ARM: OMAP2+: Fix booting for am335x after moving to simple-pm-bus
ARM: OMAP2+: Fix suspcious RCU usage splats for omap_enter_idle_coupled
ARM: dts; gta04: SPI panel chip select is active low
soc: ti: omap-prm: Fix boot time errors for rst_map_012 bits 0 and 1
ARM: OMAP1: OSK: fix ohci-omap breakage
DTS: ARM: gta04: remove legacy spi-cs-high to make display work again
Link: https://lore.kernel.org/r/pull-1611818709-243493@atomide.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This patch adds basic support for MYIR Tech MYC-AM335X CPU Module:
- Up to 1GHz TI AM335X Series ARM Cortex-A8 Processors
- Up to 512MB DDR3 SDRAM
- Up to 512MB Nand Flash
and MYD-AM335X Development Board:
- MYC-AM335X CPU Module as Controller Board
- Serial ports, 4 x USB Host, OTG, 2 x Gigabit Ethernet, CAN, RS485,
TF, Audio
- Supports HDMI and LCD Display
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Tony Lindgren <tony@atomide.com>
I've switched employer a long time ago and the mentioned email address no
longer exists. Use my personal address to prevent the issue in the future.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Previously, the 1GHz variants were marked as a turbo,
because that variant has reduced thermal operating range.
Now that the thermal throttling is in place, it should be
safe to remove the turbo-mode from the 1GHz variants, because
the CPU will automatically slow if the thermal limit is reached.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The Android vendor kernel uses 307.2MHz or a divider ratio of /5 while active
153600000 or /10 is only used when the sgx core is inactive.
Signed-off-by: Carl Philipp Klemm <philipp@uvos.xyz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The omap4430 HS HIGH performance devces support 1.2GHz opp, lower speed
variants do not. However for mapphone devices Motorola seems to have
decided that this does not really matter for the SoC variants they have
tested to use, and decided to clock all devices, including the ones with
STANDARD performance chips at 1.2GHz upon release of the 3.0.8 vendor
kernel shiped with Android 4.0. Therefore it seems safe to do the same,
but let's only do it for Motorola devices as the others have not been
tested.
Note that we prevent overheating with the passive cooling device
cpu_alert0 configured in the dts file that starts lowering the speed as
needed.
This also removes the "failed to find current OPP for freq 1200000000"
warning.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Carl Philipp Klemm <philipp@uvos.xyz>
[tony@atomide.com: made motorola specific, updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
The current cooling device temperature is too high at 100C as we have a
battery on the device right next to the SoC as pointed out by Carl Philipp
Klemm <philipp@uvos.xyz>. Let's configure the max temperature to 80C.
As we only have a tshut interrupt and no talert interrupt on 4430, we have
a passive cooling device configured for 4430. However, we want the poll
interval to be 10 seconds instead of 1 second for power management. The
value of 10 seconds seems like plenty of time to notice the temperature
increase above the 75C temperatures. Having the bandgap temperature change
seems to take several tens of seconds because of heat dissipation above
75C range as monitored with a full CPU load.
Cc: Carl Philipp Klemm <philipp@uvos.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Suggested-by: Carl Philipp Klemm <philipp@uvos.xyz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We have gpio_86 wired internally to the bandgap thermal shutdown
interrupt on 4430 like we have it on 4460 according to the TRM.
This can be found easily by searching for TSHUT.
For some reason the thermal shutdown interrupt was never added
for 4430, let's add it. I believe this is needed for the thermal
shutdown interrupt handler ti_bandgap_tshut_irq_handler() to call
orderly_poweroff().
Fixes: aa9bb4bb88 ("arm: dts: add omap4430 thermal data")
Cc: Carl Philipp Klemm <philipp@uvos.xyz>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This adds audio playback to the first generation Amazon Echo
Signed-off-by: André Hentschel <nerv@dawncrow.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The "amba" bus nodes wrapping all the DMA-330 nodes serve no useful
purpose, and certainly bear no relation at all to the actual underlying
interconnect topology. They appear to be cargo-cult copying from a
design misstep in the very early days of FDT adoption on ARM, which was
righted with the "arm,primecell" compatible, and the last trace of the
idea finally purged by commit 2ef7d5f342 ("ARM, ARM64: dts: drop
"arm,amba-bus" in favor of "simple-bus"").
As such, they can simply be removed and the DMA-330 nodes fitted into
the normal sort order.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/e682edd25133bde2ed8198138febc90071530a51.1611186142.git.robin.murphy@arm.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Fix checkpatch warning:
WARNING: please, no spaces at the start of a line
Signed-off-by: Stanislav Jakubek <stano.jakubek@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
The vendor kernel uses the following thermal-zone settings:
<= 70°C:
- CPU frequency limited to 1.488GHz
- GPU limited to 511MHz and 2 cores (pixel processors)
<= 80°C:
- CPU frequency limited to 1.2GHz
- GPU limited to 435MHz and 2 cores (pixel processors)
<= 90°C:
- CPU frequency limited to 0.804GHz
- GPU limited to 328MHz and 1 core (pixel processor)
Add simplified thermal configuration which is taken from the
GXBB/GXL/GXM SoC family (which uses the same manufacturing process and
has the same maximum junction temperature of 125°C). With this the
thermal framework will try to keep the SoC temperature at or below 80°C
which is identical to the vendor kernel (with the exception of one CPU
frequency step from 1.488GHz to 1.536GHz).
The number of GPU cores are not taken into account as this is not
supported.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20201221181306.904272-5-martin.blumenstingl@googlemail.com
The vendor kernel uses the following thermal-zone settings:
<= 70°C:
- CPU frequency limited to 1.608GHz
- GPU limited to 511MHz and 5 cores (pixel processors)
<= 80°C:
- CPU frequency limited to 1.2GHz
- GPU limited to 435MHz and 4 cores (pixel processors)
<= 90°C:
- CPU frequency limited to 0.804GHz
- GPU limited to 328MHz and 3 cores (pixel processors)
Add simplified thermal configuration which is taken from the
GXBB/GXL/GXM SoC family (which uses the same manufacturing process and
has the same maximum junction temperature of 125°C). With this the
thermal framework will try to keep the SoC temperature at or below 80°C
which is identical to the vendor kernel (with the exception of one GPU
pixel processor).
The number of GPU cores are not taken into account as this is not
supported.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20201221181306.904272-4-martin.blumenstingl@googlemail.com
