If the component driver fails to bind, or is unbound, the driver data
for the top-level platform device points to a freed drm_device. If the
system is then suspended, the driver passes this dangling pointer to
drm_mode_config_helper_suspend(), which crashes.
Fix this by only setting the driver data while the platform driver holds
a reference to the drm_device.
Fixes: 624b4b48d9 ("drm: sun4i: Add support for suspending the display driver")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220615054254.16352-1-samuel@sholland.org
commit 6de79dd3a9 ("drm/bridge: display-connector: add ddc-en gpio
support") added a consumer for this GPIO in the HDMI connector device.
This new consumer conflicts with the pre-existing GPIO consumer in the
sun8i HDMI controller driver, which prevents the driver from probing:
[ 4.983358] display-connector connector: GPIO lookup for consumer ddc-en
[ 4.983364] display-connector connector: using device tree for GPIO lookup
[ 4.983392] gpio-226 (ddc-en): gpiod_request: status -16
[ 4.983399] sun8i-dw-hdmi 6000000.hdmi: Couldn't get ddc-en gpio
[ 4.983618] sun4i-drm display-engine: failed to bind 6000000.hdmi (ops sun8i_dw_hdmi_ops [sun8i_drm_hdmi]): -16
[ 4.984082] sun4i-drm display-engine: Couldn't bind all pipelines components
[ 4.984171] sun4i-drm display-engine: adev bind failed: -16
[ 4.984179] sun8i-dw-hdmi: probe of 6000000.hdmi failed with error -16
Both drivers have the same behavior: they leave the GPIO active for the
life of the device. Let's take advantage of the new implementation, and
drop the now-obsolete code from the HDMI controller driver.
Fixes: 6de79dd3a9 ("drm/bridge: display-connector: add ddc-en gpio support")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220614073100.11550-1-samuel@sholland.org
Recent Allwinner SoCs support >4 GiB of DRAM, so those variants of the
DMA engine support >32 bit physical addresses. This is accomplished by
placing the high bits in the "para" word in the DMA descriptor.
DMA descriptors themselves can be located at >32 bit addresses by
putting the high bits in the LSBs of the descriptor address register,
taking advantage of the required DMA descriptor alignment. However,
support for this is not really necessary, so we can avoid the
complication by allocating them from the DMA_32 zone.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20220424172759.33383-4-samuel@sholland.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Not all of these drivers are needed on every ARCH_SUNXI platform. In
particular, the ARCH_SUNXI symbol will be reused for the Allwinner D1,
a RISC-V SoC which contains none of these irqchips.
Introduce Kconfig symbols so we can select only the drivers actually
used by a particular set of platforms. This also lets us move the
irqchip driver dependencies to a more appropriate location.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220509034941.30704-1-samuel@sholland.org
The R329 and D1 SoCs each contain an LRADC with a programming interface
compatible to earlier LRADCs. However, the LRADC now has its own clock
gate and reset line, instead of being always active.
To support this, add clock/reset properties to the binding, and require
them for the variant in the new SoCs.
Acked-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20220414002349.24332-1-samuel@sholland.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
commit b4bdc4fbf8 ("soc: sunxi: Deal with the MBUS DMA offsets in a
central place") added a platform device notifier that sets the DMA
offset for all of the display engine frontend and backend devices.
The code applying the offset to DMA buffer physical addresses was then
removed from the backend driver in commit 756668ba68 ("drm/sun4i:
backend: Remove the MBUS quirks"), but the code subtracting PHYS_OFFSET
was left in the frontend driver.
As a result, the offset was applied twice in the frontend driver. This
likely went unnoticed because it only affects specific configurations
(scaling or certain pixel formats) where the frontend is used, on boards
with both one of these older SoCs and more than 1 GB of DRAM.
In addition, the references to PHYS_OFFSET prevent compiling the driver
on architectures where PHYS_OFFSET is not defined.
Fixes: b4bdc4fbf8 ("soc: sunxi: Deal with the MBUS DMA offsets in a central place")
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-4-samuel@sholland.org
D1 has a TCON TOP, so its quirks are similar to those for the R40 TCONs.
While there are some register changes, the part of the TCON TV supported
by the driver matches the R40 quirks, so that quirks structure can be
reused. D1 has the first supported TCON LCD with a TCON TOP, so the TCON
LCD needs a new quirks structure.
D1's TCON LCD hardware supports LVDS; in fact it provides dual-link LVDS
from a single TCON. However, it comes with a brand new LVDS PHY. Since
this PHY has not been tested, leave out LVDS driver support for now.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-14-samuel@sholland.org
So far, the binding and driver have relied on the fact that the H6
clocks are both a prefix and a subset of the R40 clocks. This allows
them to share the clocks/clock-names items and the clock-output-names
order between the hardware variants.
However, the D1 hardware has TCON TV0 and DSI, but no TCON TV1. This
cannot be supported by the existing scheme because it puts a gap in the
middle of the item lists. To prepare for adding D1 support, use separate
lists for variants with different combinations of clocks.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-2-samuel@sholland.org
Because some newer hardware variants have multiple possible parents for
the RTC's timekeeping clock, this driver models it as a "rtc-32k" clock.
However, it does not add any consumer for this clock. This causes the
common clock framework to disable it, preventing RTC time access.
Since the RTC's timekeeping clock should always be enabled, regardless
of which drivers are loaded, let's mark this clock as critical instead
of adding a consumer in the RTC driver.
Fixes: d91612d7f0 ("clk: sunxi-ng: Add support for the sun6i RTC clocks")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20220411050100.40964-1-samuel@sholland.org
This commit fixes two issues with the muxed interrupt handler. First,
the OTG port has the "bvalid" interrupt enabled, not "linestate". Since
only the linestate interrupt was handled, and not the bvalid interrupt,
plugging in a cable to the OTG port caused an interrupt storm.
Second, the return values from the individual port IRQ handlers need to
be OR-ed together. Otherwise, the lack of an interrupt from the last
port would cause the handler to erroneously return IRQ_NONE.
Fixes: ed2b5a8e6b ("phy: phy-rockchip-inno-usb2: support muxed interrupts")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Tested-by: Michael Riesch <michael.riesch@wolfvision.net>
Link: https://lore.kernel.org/r/20220414032258.40984-2-samuel@sholland.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The RISC-V PLIC binding uses interrupts-extended to specify its parent
domain(s). That binding does not allow the interrupt-parent property to
appear in the irqchip node. This prevents of_irq_init from properly
detecting the irqchip hierarchy.
If no interrupt-parent property is present in the enclosing bus or root
node, then desc->interrupt_parent will be NULL for both the per-CPU
RISC-V INTC (the actual root domain) and the RISC-V PLIC. Similarly, if
the bus or root node specifies `interrupt-parent = <&plic>`, then
of_irq_init will hit the `desc->interrupt_parent == np` check, and again
all parents will be NULL. So things happen to work today for some boards
due to Makefile ordering.
However, things break when another irqchip ("foo") is stacked on top of
the PLIC. The bus or root node will have `interrupt-parent = <&foo>`,
since that is what all of the other peripherals need. When of_irq_init
runs, it will try to find the PLIC's parent domain. of_irq_find_parent
will fall back to using the interrupt-parent property of the PLIC's
parent node (i.e. the bus or root node), and of_irq_init will see "foo"
as the PLIC's parent domain. But this is wrong, because "foo" is
actually the PLIC's child domain!
So of_irq_init wrongly attempts to init the stacked irqchip before the
PLIC. This fails and breaks booting.
Fix this by using the first node referenced by interrupts-extended as
the parent when that property is present. This allows of_irq_init to see
the relationship between the PLIC and the per-CPU RISC-V INTC, and thus
only the RISC-V INTC is (correctly) considered a root domain.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220412051529.6293-1-samuel@sholland.org
The RTC power domain in sun6i and newer SoCs manages the 16 MHz RC
oscillator (called "IOSC" or "osc16M") and the optional 32 kHz crystal
oscillator (called "LOSC" or "osc32k"). Starting with the H6, this power
domain also handles the 24 MHz DCXO (called variously "HOSC", "dcxo24M",
or "osc24M") as well. The H6 also adds a calibration circuit for IOSC.
Later SoCs introduce further variations on the design:
- H616 adds an additional mux for the 32 kHz fanout source.
- R329 adds an additional mux for the RTC timekeeping clock, a clock
for the SPI bus between power domains inside the RTC, and removes the
IOSC calibration functionality.
Take advantage of the CCU framework to handle this increased complexity.
This driver is intended to be a drop-in replacement for the existing RTC
clock provider. So some runtime adjustment of the clock parents is
needed, both to handle hardware differences, and to support the old
binding which omitted some of the input clocks.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220203021736.13434-6-samuel@sholland.org
This driver supports several chip variants which all share the same I2C
register interface. Since the chip will turn off and become inaccessible
under conditions outside of software control (e.g. upon button press or
input voltage removal), some special handling is needed to delay the
initialization of the IC until it is accessible.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Some Injoinic power bank ICs feature an I2C interface which allows
monitoring and controlling the battery charger and boost converter.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This driver, like several others, uses a chained IRQ for each GPIO bank,
and forwards .irq_set_wake to the GPIO bank's upstream IRQ. As a result,
a call to irq_set_irq_wake() needs to lock both the upstream and
downstream irq_desc's. Lockdep considers this to be a possible deadlock
when the irq_desc's share lockdep classes, which they do by default:
============================================
WARNING: possible recursive locking detected
5.17.0-rc3-00394-gc849047c2473 #1 Not tainted
--------------------------------------------
init/307 is trying to acquire lock:
c2dfe27c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0
but task is already holding lock:
c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&irq_desc_lock_class);
lock(&irq_desc_lock_class);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by init/307:
#0: c1f29f18 (system_transition_mutex){+.+.}-{3:3}, at: __do_sys_reboot+0x90/0x23c
#1: c20f7760 (&dev->mutex){....}-{3:3}, at: device_shutdown+0xf4/0x224
#2: c2e804d8 (&dev->mutex){....}-{3:3}, at: device_shutdown+0x104/0x224
#3: c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0
stack backtrace:
CPU: 0 PID: 307 Comm: init Not tainted 5.17.0-rc3-00394-gc849047c2473 #1
Hardware name: Allwinner sun8i Family
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x68/0x90
dump_stack_lvl from __lock_acquire+0x1680/0x31a0
__lock_acquire from lock_acquire+0x148/0x3dc
lock_acquire from _raw_spin_lock_irqsave+0x50/0x6c
_raw_spin_lock_irqsave from __irq_get_desc_lock+0x58/0xa0
__irq_get_desc_lock from irq_set_irq_wake+0x2c/0x19c
irq_set_irq_wake from irq_set_irq_wake+0x13c/0x19c
[tail call from sunxi_pinctrl_irq_set_wake]
irq_set_irq_wake from gpio_keys_suspend+0x80/0x1a4
gpio_keys_suspend from gpio_keys_shutdown+0x10/0x2c
gpio_keys_shutdown from device_shutdown+0x180/0x224
device_shutdown from __do_sys_reboot+0x134/0x23c
__do_sys_reboot from ret_fast_syscall+0x0/0x1c
However, this can never deadlock because the upstream and downstream
IRQs are never the same (nor do they even involve the same irqchip).
Silence this erroneous lockdep splat by applying what appears to be the
usual fix of moving the GPIO IRQs to separate lockdep classes.
Fixes: a59c99d9ea ("pinctrl: sunxi: Forward calls to irq_set_irq_wake")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20220216040037.22730-1-samuel@sholland.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This driver, like several others, uses a chained IRQ for each GPIO bank,
and forwards .irq_set_wake to the GPIO bank's upstream IRQ. As a result,
a call to irq_set_irq_wake() needs to lock both the upstream and
downstream irq_desc's. Lockdep considers this to be a possible deadlock
when the irq_desc's share lockdep classes, which they do by default:
============================================
WARNING: possible recursive locking detected
5.17.0-rc3-00394-gc849047c2473 #1 Not tainted
--------------------------------------------
init/307 is trying to acquire lock:
c2dfe27c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0
but task is already holding lock:
c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&irq_desc_lock_class);
lock(&irq_desc_lock_class);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by init/307:
#0: c1f29f18 (system_transition_mutex){+.+.}-{3:3}, at: __do_sys_reboot+0x90/0x23c
#1: c20f7760 (&dev->mutex){....}-{3:3}, at: device_shutdown+0xf4/0x224
#2: c2e804d8 (&dev->mutex){....}-{3:3}, at: device_shutdown+0x104/0x224
#3: c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0
stack backtrace:
CPU: 0 PID: 307 Comm: init Not tainted 5.17.0-rc3-00394-gc849047c2473 #1
Hardware name: Allwinner sun8i Family
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x68/0x90
dump_stack_lvl from __lock_acquire+0x1680/0x31a0
__lock_acquire from lock_acquire+0x148/0x3dc
lock_acquire from _raw_spin_lock_irqsave+0x50/0x6c
_raw_spin_lock_irqsave from __irq_get_desc_lock+0x58/0xa0
__irq_get_desc_lock from irq_set_irq_wake+0x2c/0x19c
irq_set_irq_wake from irq_set_irq_wake+0x13c/0x19c
[tail call from sunxi_pinctrl_irq_set_wake]
irq_set_irq_wake from gpio_keys_suspend+0x80/0x1a4
gpio_keys_suspend from gpio_keys_shutdown+0x10/0x2c
gpio_keys_shutdown from device_shutdown+0x180/0x224
device_shutdown from __do_sys_reboot+0x134/0x23c
__do_sys_reboot from ret_fast_syscall+0x0/0x1c
However, this can never deadlock because the upstream and downstream
IRQs are never the same (nor do they even involve the same irqchip).
Silence this erroneous lockdep splat by applying what appears to be the
usual fix of moving the GPIO IRQs to separate lockdep classes.
Fixes: a59c99d9ea ("pinctrl: sunxi: Forward calls to irq_set_irq_wake")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20220216040037.22730-1-samuel@sholland.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Basic programmable non-PD Type-C port controllers do not need the full
TCPM library, but they share the same devicetree binding and the same
typec_capability structure. Factor out a helper for parsing those
properties which map to fields in struct typec_capability, so the code
can be shared between TCPM and basic non-TCPM drivers.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20220214050118.61015-4-samuel@sholland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With v2 hardware, an IRQ can be configured to trigger on both edges via
a bit in the int_bothedge register. Currently, the driver sets this bit
when changing the trigger type to IRQ_TYPE_EDGE_BOTH, but fails to reset
this bit if the trigger type is later changed to something else. This
causes spurious IRQs, and when using gpio-keys with wakeup-event-action
set to EV_ACT_(DE)ASSERTED, those IRQs translate into spurious wakeups.
Fixes: 3bcbd1a85b ("gpio/rockchip: support next version gpio controller")
Reported-by: Guillaume Savaton <guillaume@baierouge.fr>
Tested-by: Guillaume Savaton <guillaume@baierouge.fr>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
H6 and newer variants of the RTC hardware have a bus clock gate in the
PRCM CCU. This was not known at the time H6 support was added, so it was
not included in the H6 RTC binding, nor in the H6 PRCM CCU driver. Now
that this clock gate is documented, it is included in the A100 and D1
PRCM CCU drivers. Therefore, the RTC driver needs to have a consumer for
the clock gate to prevent Linux from disabling it.
Patch-changes: 3
- New patch for compatibility with new CCU drivers
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220203021736.13434-4-samuel@sholland.org
These new RTC variants all have a single alarm, like the R40 variant.
For the new SoCs, start requiring a complete list of input clocks. The
H616 has three required clocks. The R329 also has three required clocks
(but one is different), plus an optional crystal oscillator input. The
D1 RTC is identical to the one in the R329.
And since these new SoCs will have a well-defined output clock order as
well, they do not need the clock-output-names property.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220203021736.13434-3-samuel@sholland.org
The PineNote is a tablet from Pine64 based on the RK3566 SoC, featuring
4G/128G of storage, a 10.3" electrophoretic display (EPD) with two-color
frontlight, both EMR and capacitive digitizers, dual-band wireless,
quad-channel digital microphones, and stereo speakers.
There are two existing variants of the board. v1.1 was contained in some
early samples, and v1.2 was sold as the "PineNote Developer Edition".
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20220130053803.43660-3-samuel@sholland.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This adds a new set of quirks to set the right RX channel map. Since
that is the only change to the register layout, reuse the H6 regmap
config by extending its last register. R329 support is added by its
compatible string. D1 uses R329 as its fallback compatible, so no
additional code change is needed for it.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220203020116.12279-4-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
H6 expands the number of channels in each direction to 16, so the slot
number fields need to be expanded from 3 to 4 bits each.
R329/D1 expand that further by allowing each of the 16 slots to map to
any of 4 data pins. For TX, the configuration of each pin is
independent, so there is a copy of the mapping registers for each pin.
For RX, each of the 16 slots can map to only one pin, so the registers
were changed to add the pin selection inline with the channel mapping.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220203020116.12279-3-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This driver works by adjusting the divider on the DRAM controller's
module clock. Thus there is no fixed set of OPPs, only "full speed" down
to "quarter speed" (or whatever the maximum divider is on that variant).
It makes use of the MDFS hardware in the MBUS, in "DFS" mode, which
takes care of updating registers during the critical section while DRAM
is inaccessible.
This driver should support several sunxi SoCs, starting with the A33,
which have a DesignWare DDR3 controller with merged PHY register space
and the matching MBUS register layout (so not A63 or later). However,
the driver has only been tested on the A64/H5, so those are the only
compatibles enabled for now.
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
This allows changing the volume of each digital input/output
independently, and provides the only "master volume" for the DAC.
(The ADC also has a gain control on the analog side.)
While the hardware supports digital gain up to +72dB, the controls here
are limited to +24dB maximum, as any gain above that level makes volume
sliders difficult to use, and is extremely likely to cause clipping.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20211118033645.43524-1-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The MBUS provides more than address translation and bandwidth control.
It also provides a PMU to measure bandwidth usage by certain masters,
and it provides notification via IRQ when they are active or idle.
The MBUS is also tightly integrated with the DRAM controller to provide
a Memory Dynamic Frequency Scaling (MDFS) feature. In view of this, the
MBUS binding needs to represent the hardware resources needed for MDFS,
which include the clocks and MMIO range of the adjacent DRAM controller.
Add the additional resources for the H3 and A64 compatibles, and a new
example showing how they are used.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20211118031841.42315-3-samuel@sholland.org
Referencing parents with clk_hw pointers is more efficient and removes
the dependency on global clock names. clk_parent_data is needed when
some parent clocks are provided from another driver. Add macros for
declaring muxes that take advantage of these.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20211119043545.4010-5-samuel@sholland.org
Referencing parents with clk_hw pointers is more efficient and removes
the dependency on global clock names. clk_parent_data is needed when
some parent clocks are provided from another driver. Add macros for
declaring dividers that take advantage of these.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20211119043545.4010-4-samuel@sholland.org
Referencing parents with clk_hw pointers is more efficient and removes
the dependency on global clock names. clk_parent_data is needed when
some parent clocks are provided from another driver. Add macros for
declaring dividers that take advantage of these.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20211119043545.4010-3-samuel@sholland.org
Like the individual CCU drivers, it can be beneficial for memory
consumption of cross-platform configurations to only load the CCU core
on the relevant platform. For example, a generic arm64 kernel sees the
following improvement when building the CCU core and drivers as modules:
before:
text data bss dec hex filename
13882360 5251670 360800 19494830 12977ae vmlinux
after:
text data bss dec hex filename
13734787 5086442 360800 19182029 124b1cd vmlinux
So the result is a 390KB total reduction in kernel image size.
The one early clock provider (sun5i) requires the core to be built in.
Now that loading the MMC driver will trigger loading the CCU core, the
MMC timing mode functions do not need a compile-time fallback.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20211119033338.25486-5-samuel@sholland.org
The PRCM CCU drivers depend on clocks provided by other CCU drivers. For
example, the sun8i-r-ccu driver uses the "pll-periph" clock provided by
the SoC's main CCU.
However, sun8i-r-ccu is an early OF clock provider, and many of the
main CCUs (e.g. sun50i-a64-ccu) use platform drivers. This means that
the consumer clocks will be orphaned until the supplier driver is bound.
This can be avoided by converting the remaining CCUs to use platform
drivers. Then fw_devlink will ensure the drivers are bound in the
optimal order.
The sun5i CCU is the only one which actually needs to be an early clock
provider, because it provides the clock for the system timer. That one
is left alone.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20211119033338.25486-4-samuel@sholland.org
While it is useful to build all of the CCU drivers at once, only 1-3 of
them will be loaded at a time, or possibly none of them if the kernel is
booted on a non-sunxi platform. These CCU drivers are relatively large;
32-bit drivers have 30-50k of data each, while the 64-bit ones are
50-75k due to the increased pointer overhead. About half of that data
comes from relocations. Let's allow the user to build these drivers as
modules so only the necessary data is loaded.
As a first step, convert the CCUs that are already platform drivers.
When the drivers are built as modules, normally the file name becomes
the module name. However, the current file names are inconsistent with
the <platform>-<peripheral> name used everywhere else: the devicetree
bindings, the platform driver names, and the Kconfig symbols. Use
Makfile logic to rename the modules so they follow the usual pattern.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20211119033338.25486-3-samuel@sholland.org
For the individual CCU drivers to be built as modules, the ops structs,
helper functions, and callback registration functions must be exported.
These symbols are intended for use only by the adjacent CCU drivers, so
export them into the SUNXI_CCU namespace.
of_sunxi_ccu_probe is not exported because it is only used by built-in
OF clock providers.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20211119033338.25486-2-samuel@sholland.org
Since commit ea572f8160 ("PM / devfreq: Change return type of
devfreq_set_freq_table()"), all devfreq devices are expected to have a
valid freq_table. The devfreq core unconditionally dereferences
freq_table in the sysfs code and in get_freq_range().
Therefore, we need to ensure that freq_table is both non-null and
non-empty (length is > 0). If either check fails, replace the table
using set_freq_table() or return the error.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
D1 keeps the same register layout and clock sources as the R329, but it
adds a key field which must be set to update the watchdog's "CFG" and
"MODE" registers. Therefore it is not backward-compatible.
Similarly to the R329, the D1 has three watchdog instances, and only one
of them has the "soft reset" registers. So that instance needs an extra
compatible string.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210902225750.29313-3-samuel@sholland.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
On existing SoCs, the watchdog has a single clock input: HOSC (OSC24M)
divided by 750. However, starting with R329, LOSC (OSC32k) is added as
an alternative clock source, with a bit to switch between them.
Since 24 MHz / 750 == 32 kHz, not 32.768 kHz, the hardware adjusts the
cycle counts to keep the timeouts independent of the clock source. This
keeps the programming interface backward-compatible.
Furthermore, the R329 has two watchdogs: one for use by the ARM CPUs
at 0x20000a0, and a second one for use by the DSPs at 0x7020400. The
first of these adds two more new registers, to allow software to
immediately assert the SoC reset signal. Add an additional "-reset"
suffix to signify the presence of this feature.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20210902225750.29313-2-samuel@sholland.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Some SoCs have an RTC supported by this RTC driver, but do not have an
early clock provider declared here. Currently, this prevents the RTC
driver from probing, because it expects a global struct to already be
allocated. Fix probing the driver by copying the missing pieces from the
clock provider setup function, replacing them with the devm variants.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210928080335.36706-7-samuel@sholland.org
The CCU drivers are not really designed to be unbound. Unbinding a SoC's
main CCU is especially pointless, as very few of the peripherals on the
SoC will work without it. Let's avoid any potential problems by removing
the bind/unbind attributes from sysfs for these drivers.
This change is not applied to the "secondary" CCUs (DE, USB) as those
could reasonably be unbound without making the system useless.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210901050526.45673-3-samuel@sholland.org
Currently, unbinding a CCU driver unmaps the device's MMIO region, while
leaving its clocks/resets and their providers registered. This can cause
a page fault later when some clock operation tries to perform MMIO. Fix
this by separating the CCU initialization from the memory allocation,
and then using a devres callback to unregister the clocks and resets.
This also fixes a memory leak of the `struct ccu_reset`, and uses the
correct owner (the specific platform driver) for the clocks and resets.
Early OF clock providers are never unregistered, and limited error
handling is possible, so they are mostly unchanged. The error reporting
is made more consistent by moving the message inside of_sunxi_ccu_probe.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210901050526.45673-2-samuel@sholland.org
The CCUs for all other 32-bit SoCs have a dependency on a specific
MACH_SUNxI symbol. This effectively hides these drivers when building
an ARCH=arm64 kernel. However, the A83T CCU still shows up because it
is missing this dependency. Let's add it for consistency.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210902230200.29574-1-samuel@sholland.org
Samuel Holland