All TI_ST users have been migrated to the new serdev based HCILL
bluetooth driver. That driver is initialized from DT and does not
need any platform quirks.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Suman Anna <s-anna@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Suman Anna <s-anna@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Keerthy <j-keerthy@ti.com>
Cc: Suman Anna <s-anna@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Suman Anna <s-anna@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.
As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.
Cc: Ankur Tyagi <ankur.tyagi@gallagher.com>
Cc: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The omap44xx_sha0_hwmod and omap44xx_l3_main_2__des objects are
not exported so make them static to avoid the following warnings:
arch/arm/mach-omap2/omap_hwmod_44xx_data.c:793:19: warning: symbol 'omap44xx_sha0_hwmod' was not declared. Should it be static?
arch/arm/mach-omap2/omap_hwmod_44xx_data.c:977:26: warning: symbol 'omap44xx_l3_main_2__des' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The prm_{save,restore}_context functions are not exported
so make them static to avoid the following warnings:
arch/arm/mach-omap2/prm44xx.c:748:6: warning: symbol 'prm_save_context' was not declared. Should it be static?
arch/arm/mach-omap2/prm44xx.c:759:6: warning: symbol 'prm_restore_context' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The dra7xx_sha0_hwmod object is not exported outside of
omap_hwmod_7xx_data. so make it static to avoid the
following warning:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c:686:19: warning: symbol 'dra7xx_sha0_hwmod' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Do not export am43xx_control_{save,restore}_context to avoid
the foloowing warnings:
arch/arm/mach-omap2/control.c:687:6: warning: symbol 'am43xx_control_save_context' was not declared. Should it be static?
arch/arm/mach-omap2/control.c:701:6: warning: symbol 'am43xx_control_restore_context' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Looks like the i2c timings in high-speed mode do not work properly to
allow us to clear I2C_DISABLE bits for PRM_VOLTCTRL register and the
device reboots if I2C_DISABLE bits are cleared.
Let's configure the voltage controller i2c for low-speed mode as done in
the Motorola Mapphone Android Linux kernel. This saves us about 7mW of
power during retention compared to the high-speed values.
Let's also change the low-speed warning to pr_info about relying on the
bootloader configured low-speed values like we currently do.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The OMAP3 ISP IOMMU does not have any reset lines, so it didn't
need any pdata previously. The OMAP IOMMU driver now requires the
platform data ops for device_enable/idle on all the IOMMU devices
after commit db8918f61d ("iommu/omap: streamline enable/disable
through runtime pm callbacks") to enable/disable the clocks properly
and maintain the reference count and the omap_hwmod state machine.
So, add these callbacks through iommu pdata quirks for the OMAP3
ISP IOMMU.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The OMAP IOMMU driver requires the device_enable/idle platform
data ops on all the IOMMU devices to be able to enable and disable
the clocks after commit db8918f61d ("iommu/omap: streamline
enable/disable through runtime pm callbacks"). Plug in these
pdata ops for all the existing IOMMUs through pdata quirks to
maintain functionality.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Similar to existing omap3_vc_set_pmic_signaling(), let's add omap4
specific omap4_vc_set_pmic_signaling(). This allows the configured
devices to enable voltage controller for retention later on during
init.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Fix sparse warnings:
arch/arm/mach-omap2/pmic-cpcap.c:29:15: warning: symbol 'omap_cpcap_vsel_to_uv' was not declared. Should it be static?
arch/arm/mach-omap2/pmic-cpcap.c:43:15: warning: symbol 'omap_cpcap_uv_to_vsel' was not declared. Should it be static?
arch/arm/mach-omap2/pmic-cpcap.c:93:15: warning: symbol 'omap_max8952_vsel_to_uv' was not declared. Should it be static?
arch/arm/mach-omap2/pmic-cpcap.c:107:15: warning: symbol 'omap_max8952_uv_to_vsel' was not declared. Should it be static?
arch/arm/mach-omap2/pmic-cpcap.c:140:15: warning: symbol 'omap_fan535503_vsel_to_uv' was not declared. Should it be static?
arch/arm/mach-omap2/pmic-cpcap.c:155:15: warning: symbol 'omap_fan535508_vsel_to_uv' was not declared. Should it be static?
arch/arm/mach-omap2/pmic-cpcap.c:173:15: warning: symbol 'omap_fan535503_uv_to_vsel' was not declared. Should it be static?
arch/arm/mach-omap2/pmic-cpcap.c:192:15: warning: symbol 'omap_fan535508_uv_to_vsel' was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can make clkdm_clk_enable() usable for clkdm_hwmod_enable() by
dropping the unused clock check, and drop _clkdm_clk_hwmod_enable().
And we can make clkdm_hwmod_disable() call clkdm_hwmod_disable() and drop
the duplicate code in clkdm_hwmod_disable().
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We're missing initializing the PRM_VOLTCTRL register for voltage
controller. Let's add omap4_vc_init_pmic_signaling() similar to what we
have for omap3 and enable voltage control for retention.
This brings down droid4 power consumption with mainline kernel to somewhere
between 40 and 50mW from about 70 to 80 mW for the whole device when
running idle with LCD and backlight off, WLAN connected, and USB and modem
modules unloaded.
Mostly just rmmod of omap2430, ohci-platform and phy-mapphone-mdm6600 are
needed to idle USB and shut down the modem. And after that measuring idle
power consumption can be done with reading sysfs entry periodically
for /sys/class/power_supply/battery/power_avg. Then rmmod of phy-cpcap-usb
will save few more mW, but will disable the debug UART.
Note that sometimes CM_L4PER_UART1_CLKCTRL at 0x4a009540 does not idle
properly after unloading of phy-mapphone-mdm6600.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit f74297dd93 ("ARM: OMAP2+: Make sure LOGICRETSTATE bits are not
cleared") disabled oswr (open switch retention) for per and core domains
as various GPIO related issues were noticed if the bootloader had
configured the bits for LOGICRETSTATE for per and core domains.
With the recent gpio-omap fixes, mostly related to commit e6818d29ea
("gpio: gpio-omap: configure edge detection for level IRQs for idle
wakeup"), things now behave for enabling core oswr for omap4.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit f74297dd93 ("ARM: OMAP2+: Make sure LOGICRETSTATE bits are not
cleared") disabled oswr (open switch retention) for per and core domains
as various GPIO related issues were noticed if the bootloader had
configured the bits for LOGICRETSTATE for per and core domains.
With the recent gpio-omap fixes, mostly related to commit e6818d29ea
("gpio: gpio-omap: configure edge detection for level IRQs for idle
wakeup"), things now behave for enabling per oswr for omap4.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
We can configure voltage controller for cpcap with the data available in
Motorola Mapphone Android Linux kernel. Let's add it so we can have droid4
behave the same way for voltage controller as other omap4 devices and save
some power when idle.
Note that we're now using high-speed i2c mode, looks like the Motorola
kernel had a typo using 0x200 instead of 200 for the timings which may
caused it to not work properly.
Also note that in the long run, this should just become dts data for a
voltage controller device driver. But let's get things working first to
make it possible to test further changes easily.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The current operating points in the mainline kernel are out of date for
at least omap4430. Let's use the values from Motorola Mapphone Linux
Android kernel as presumably those have been verified.
Note that these are only used by voltage controller, they do not enable
any new operating points for cpufreq. Looking at the recent omap3 cpufreq
related patches posted, that's a totally separate series of patches.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
In general we want to see a quiet dmesg output with no errors or warnings
unless something is really wrong and needs attention. We currently see
these bogus warnings on boot:
twl: not initialized
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
...
Let's avoid these by checking if a device tree node for cpcap PMIC exists.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The wkup domain is always on and does not have logic off setting. This
got accidentally added by commit f74297dd93 ("ARM: OMAP2+: Make sure
LOGICRETSTATE bits are not cleared") but is harmless.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
After commit 32d174ed1b ("ARM: OMAP4: MPUSS PM: remove unnecessary
shim functions for powerdomain control") this is no longer used.
The code continues execution after context restore on the same CPU,
so we can just use pm_info->pwrdm.
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add initial PRM (Power and Reset Management) driver for TI OMAP class
SoCs. Initially this driver only supports reset control, but can be
extended to support rest of the functionality, like powerdomain
control, PRCM irq support etc.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Commit 0ed266d7ae ("clk: ti: omap3: cleanup unnecessary clock aliases")
removed old omap3 clock framework aliases but caused omap3-rom-rng to
stop working with clock not found error.
Based on discussions on the mailing list it was requested by Tero Kristo
that it would be best to fix this issue by probing omap3-rom-rng using
device tree to provide a proper clk property. The other option would be
to add back the missing clock alias, but that does not help moving things
forward with removing old legacy platform_data.
Let's also add a proper device tree binding and keep it together with
the fix.
Cc: devicetree@vger.kernel.org
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Adam Ford <aford173@gmail.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Fixes: 0ed266d7ae ("clk: ti: omap3: cleanup unnecessary clock aliases")
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In general we should check for GP device instead of HS device unless
the other options such as EMU are also checked. Otherwise omap3-rom-rng
won't probe on few of the old n900 macro boards still in service in
automated build and boot test systems.
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Adam Ford <aford173@gmail.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Fixes for omaps for v5.4-rc cycle
Here are fixes for omaps to deal with few regressions, and to fix
more boot time errors and warnings:
- The recent ti-sysc interconnect target module driver changes had
incorrect clock bits for both clocks and dts that cause warnings
- For omap3-gta04, gpio changes caused the LCD to break a while back,
and after discussing things the right fix is to set spi-cs-high
- Recent omapdrm changes to use generic panels caused tfp410 to be
disabled as we now must enable the generic support for it in
defconfig
- Recent omapdrm and backlight changes also finally made droid4 LCD
to work, so let's enable it in the defconfig it can be used out
of the box. This is not strictly a fix, but we still also have the
older CONFIG_MFD_TI_LMU options available so this cuts down the
confusion for trying to guess which display and which backlight
is needed
- Recent ti-sysc interconnect target module changes need the gpio
module disabled on some boards, but this now needs to happen at
the module level, not at the gpio driver level
- Recent changes to probe system timers with ti-sysc caused warnings
about mismatch in syconfig registers, so let's configure the option
for RESET_STATUS as available in the TRMs
- Recent changes to probe LCDC with ti-sysc caused warnings about
mismatch in sysconfig registers, so let's configure the missing
idlemodes for both platform data and dts as documented in TRMs
- Since we moved mach-omap2 to probe with device tree, we've been
getting voltage controller warnings. Turns out this code is no
longer needed, so let's just remove omap2_set_init_voltage() to
get rid of the pointless warnings
- Configure am4372 dispc memory bandwidth to avoid underflow errors
* tag 'omap-for-v5.4/fixes-rc1-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: am4372: Set memory bandwidth limit for DISPC
ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage()
ARM: OMAP2+: Add missing LCDC midlemode for am335x
ARM: OMAP2+: Fix missing reset done flag for am3 and am43
ARM: dts: Fix gpio0 flags for am335x-icev2
ARM: omap2plus_defconfig: Enable more droid4 devices as loadable modules
ARM: omap2plus_defconfig: Enable DRM_TI_TFP410
DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again
ARM: dts: Fix wrong clocks for dra7 mcasp
clk: ti: dra7: Fix mcasp8 clock bits
Link: https://lore.kernel.org/r/pull-1570040410-308159@atomide.com
Signed-off-by: Olof Johansson <olof@lixom.net>
Pull ARM SoC fixes from Olof Johansson:
"A few fixes that have trickled in through the merge window:
- Video fixes for OMAP due to panel-dpi driver removal
- Clock fixes for OMAP that broke no-idle quirks + nfsroot on DRA7
- Fixing arch version on ASpeed ast2500
- Two fixes for reset handling on ARM SCMI"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
ARM: aspeed: ast2500 is ARMv6K
reset: reset-scmi: add missing handle initialisation
firmware: arm_scmi: reset: fix reset_state assignment in scmi_domain_reset
bus: ti-sysc: Remove unpaired sysc_clkdm_deny_idle()
ARM: dts: logicpd-som-lv: Fix i2c2 and i2c3 Pin mux
ARM: dts: am3517-evm: Fix missing video
ARM: dts: logicpd-torpedo-baseboard: Fix missing video
ARM: omap2plus_defconfig: Fix missing video
bus: ti-sysc: Fix handling of invalid clocks
bus: ti-sysc: Fix clock handling for no-idle quirks
This code is currently unable to find the dts opp tables as ti-cpufreq
needs to set them up first based on speed binning.
We stopped initializing the opp tables with platform code years ago for
device tree based booting with commit 92d51856d7 ("ARM: OMAP3+: do not
register non-dt OPP tables for device tree boot"), and all of mach-omap2
is now booting using device tree.
We currently get the following errors on init:
omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu
omap2_set_init_voltage: unable to set vdd_mpu
omap2_set_init_voltage: unable to find boot up OPP for vdd_core
omap2_set_init_voltage: unable to set vdd_core
omap2_set_init_voltage: unable to find boot up OPP for vdd_iva
omap2_set_init_voltage: unable to set vdd_iva
Let's just drop the unused code. Nowadays ti-cpufreq should be used to
to initialize things properly.
Cc: Adam Ford <aford173@gmail.com>
Cc: André Roth <neolynx@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
Signed-off-by: Tony Lindgren <tony@atomide.com>
TRM "Table 13-34. SYSCONFIG Register Field Descriptions" lists both
standbymode and idlemode that should be just the sidle and midle
registers where midle is currently unconfigured for lcdc_sysc. As
the dts data has been generated based on lcdc_sysc, we now have an
empty "ti,sysc-midle" property.
And so we currently get a warning for lcdc because of a difference
with dts provided configuration compared to the legacy platform
data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
the platform data without configuring the modes.
Let's fix the issue by adding the missing midlemode to lcdc_sysc,
and configuring the "ti,sysc-midle" property based on the TRM
values.
Fixes: f711c575cf ("ARM: dts: am335x: Add l4 interconnect hierarchy and ti-sysc data")
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Robert Nelson <robertcnelson@gmail.com>
Cc: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
For ti,sysc-omap4 compatible devices with no sysstatus register, we do have
reset done status available in the SOFTRESET bit that clears when the reset
is done. This is documented for example in am437x TRM for DMTIMER_TIOCP_CFG
register. The am335x TRM just says that SOFTRESET bit value 1 means reset is
ongoing, but it behaves the same way clearing after reset is done.
With the ti-sysc driver handling this automatically based on no sysstatus
register defined, we see warnings if SYSC_HAS_RESET_STATUS is missing in the
legacy platform data:
ti-sysc 48042000.target-module: sysc_flags 00000222 != 00000022
ti-sysc 48044000.target-module: sysc_flags 00000222 != 00000022
ti-sysc 48046000.target-module: sysc_flags 00000222 != 00000022
...
Let's fix these warnings by adding SYSC_HAS_RESET_STATUS. Let's also
remove the useless parentheses while at it.
If it turns out we do have ti,sysc-omap4 compatible devices without a
working SOFTRESET bit we can set up additional quirk handling for it.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Pull ARM SoC late updates from Arnd Bergmann:
"This is some material that we picked up into our tree late or that had
complex inter-depondencies. The fact that there are these
interdependencies tends to meant that these are often actually the
most interesting new additions:
- The new Aspeed AST2600 baseboard management controller is added,
this is a Cortex-A7 based follow-up to the ARM11 based AST2500 and
had some dependencies on other device drivers.
- After many years, support for the MMP2 based OLPC XO-1.75 finally
makes it into the kernel.
- The Armada 3720 based Turris Mox open source router platform is a
late addition and it follows some preparatory work across multiple
branches.
- The OMAP2+ platform had some large-scale cleanup involving driver
changes and DT changes, here we finish it off, dropping a lot of
the now-unused platform data.
- The TI K3 platform that got added for 5.3 gains a lot more support
for individual bits on the SoC, this part just came late for the
merge window"
[ This pull request itself wasn't actually sent late at all by Arnd, but
I waited on the branches that it used to be pulled first, so it ends
up being merged much later than the other ARM SoC pull requests this
merge window - Linus ]
* tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (57 commits)
ARM: dts: dir685: Drop spi-cpol from the display
ARM: dts: aspeed: Add AST2600 pinmux nodes
ARM: dts: aspeed: Add AST2600 and EVB
ARM: exynos: Enable support for ARM architected timers
ARM: samsung: Fix system restart on S3C6410
ARM: dts: mmp2: add OLPC XO 1.75 machine
ARM: dts: mmp2: rename the USB PHY node
ARM: dts: mmp2: specify reg-shift for the UARTs
ARM: dts: mmp2: add camera interfaces
ARM: dts: mmp2: fix the SPI nodes
ARM: dts: mmp2: trivial whitespace fix
arm64: dts: marvell: add DTS for Turris Mox
dt-bindings: marvell: document Turris Mox compatible
arm64: dts: marvell: armada-37xx: add SPI CS1 pinctrl
arm64: dts: ti: k3-j721e-main: Fix gic-its node unit-address
arm64: dts: ti: k3-am65-main: Fix gic-its node unit-address
arm64: dts: ti: k3-j721e-main: Add hwspinlock node
arm64: dts: ti: k3-am65-main: Add hwspinlock node
arm64: dts: k3-j721e: Add gpio-keys on common processor board
dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
...
Pull media updates from Mauro Carvalho Chehab:
- a new sensor driver for ov5675
- a new platform driver for Allwinner A10 sensor interface
- some new remote controller keymaps
- some cosmetic changes at V4L2 core in order to avoid #ifdefs and to
merge two core modules into one
- removal of bcm2048 radio driver from staging
- removal of davinci_vpfe video driver from staging
- regression fix since Kernel 5.1 at the legacy VideoBuffer version 1
core
- added some documentation for remote controller protocols
- pixel format documentation was split on two files
- lots of other driver improvements and cleanups
* tag 'media/v5.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (321 commits)
media: videobuf-core.c: poll_wait needs a non-NULL buf pointer
media: sun4i: Make sun4i_csi_formats static
media: imx: remove unused including <linux/version.h>
media: stm32-dcmi: Delete an unnecessary of_node_put() call in dcmi_probe()
media: pvrusb2: qctrl.flag will be uninitlaized if cx2341x_ctrl_query() returns error code
media: em28xx: Fix exception handling in em28xx_alloc_urbs()
media: don't do a 31 bit shift on a signed int
media: use the BIT() macro
media: ov9650: add a sanity check
media: aspeed-video: address a protential usage of an unitialized var
media: vicodec: make life easier for static analyzers
media: remove include stdarg.h from some drivers
v4l2-core: fix coding style for the two new c files
media: v4l2-core: Remove BUG() from i2c and spi helpers
media: v4l2-core: introduce a helper to unregister a i2c subdev
media: v4l2-core: introduce a helper to unregister a spi subdev
media: v4l2-core: move i2c helpers out of v4l2-common.c
media: v4l2-core: move spi helpers out of v4l2-common.c
media: v4l2-core: Module re-organization
media: usbvision: Remove dead code
...
Pull ARM SoC platform updates from Arnd Bergmann:
"The main change this time around is a cleanup of some of the oldest
platforms based on the XScale and ARM9 CPU cores, which are between 10
and 20 years old.
The Kendin/Micrel/Microchip KS8695, Winbond/Nuvoton W90x900 and Intel
IOP33x/IOP13xx platforms are removed after we determined that nobody
is using them any more.
The TI Davinci and NXP LPC32xx platforms on the other hand are still
in active use and are converted to the ARCH_MULTIPLATFORM build,
meaning that we can compile a kernel that works on these along with
most other ARMv5 platforms. Changes toward that goal are also merged
for IOP32x, but additional work is needed to complete this. Patches
for the remaining ARMv5 platforms have started but need more work and
some testing.
Support for the new ASpeed AST2600 gets added, this is based on the
Cortex-A7 ARMv7 core, and is a newer version of the existing ARMv5 and
ARMv6 chips in the same family.
Other changes include a cleanup of the ST-Ericsson ux500 platform and
the move of the TI Davinci platform to a new clocksource driver"
[ The changes had marked INTEL_IOP_ADMA and USB_LPC32XX as being
buildable on other platforms through COMPILE_TEST, but that causes new
warnings that I most definitely do not want to see during the merge
window as that could hide other issues.
So the COMPILE_TEST option got disabled for them again - Linus ]
* tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (61 commits)
ARM: multi_v5_defconfig: make DaVinci part of the ARM v5 multiplatform build
ARM: davinci: support multiplatform build for ARM v5
arm64: exynos: Enable exynos-chipid driver
ARM: OMAP2+: Delete an unnecessary kfree() call in omap_hsmmc_pdata_init()
ARM: OMAP2+: move platform-specific asm-offset.h to arch/arm/mach-omap2
ARM: davinci: dm646x: Fix a typo in the comment
ARM: davinci: dm646x: switch to using the clocksource driver
ARM: davinci: dm644x: switch to using the clocksource driver
ARM: aspeed: Enable SMP boot
ARM: aspeed: Add ASPEED AST2600 architecture
ARM: aspeed: Select timer in each SoC
dt-bindings: arm: cpus: Add ASPEED SMP
ARM: imx: stop adjusting ar8031 phy tx delay
mailmap: map old company name to new one @microchip.com
MAINTAINERS: at91: remove the TC entry
MAINTAINERS: at91: Collect all pinctrl/gpio drivers in same entry
ARM: at91: move platform-specific asm-offset.h to arch/arm/mach-at91
MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers
ARM: s3c64xx: squash samsung_usb_phy.h into setup-usb-phy.c
ARM: debug-ll: Add support for r7s9210
...
We can currently get "Unable to handle kernel paging request at
virtual address" for invalid clocks with dts node but no driver:
(__clk_get_hw) from [<c0138ebc>] (ti_sysc_find_one_clockdomain+0x18/0x34)
(ti_sysc_find_one_clockdomain) from [<c0138f0c>] (ti_sysc_clkdm_init+0x34/0xdc)
(ti_sysc_clkdm_init) from [<c0584660>] (sysc_probe+0xa50/0x10e8)
(sysc_probe) from [<c065c6ac>] (platform_drv_probe+0x58/0xa8)
Let's add IS_ERR checks to ti_sysc_clkdm_init() as And let's start treating
clk_get() with -ENOENT as a proper error. If the clock name is specified
in device tree we must succeed with clk_get() to continue. For modules with
no clock names specified in device tree we will just ignore the clocks.
Fixes: 2b2f7def05 ("bus: ti-sysc: Add support for missing clockdomain handling")
Acked-by: Roger Quadros <rogerq@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
