Due to hardware timeout the session may be released before the remaining
task is alll finished. So mpp_free_task could run after mpp_dev_release.
Then the session used in mpp_free_task could be invalid and crash the
thread.
So we attach session to the mpp_taskqueue and let the work thread to
destroy and release session later.
NOTE: the session is created in mpp_dev_open and attached to
corresponding taskqueue on client init. So when we release the session in
mpp_dev_release if the session is not attached to certain taskqueue just
release it immediately.
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Change-Id: I9d4b2358154522e6bcde6e688592c0058781529a
when only one vp(crtc) is registered to drm, all the
plane->possible_crtc will be force set to this crtc.
this make current hwc think that all these planes can be
assigned to this crtc, but the mirror plane(rk3566 feature)
cant't be activated on the same crtc with source plane.
So if some boards only use one vp(crtc), don't register
mirror plane.
Change-Id: Ib25246cf44a0fc4caf98e7c6d21ebba18f1a6c88
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
VOP will do a dither logic transform when output is not P888,
this will make send wrong cmd.
Change-Id: Id289d90f029be457269d039d68f43a7cf1867eb2
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
This reverts commit bcd00049f4
Fixed by commit bba5e44c03
("drm/rockchip: vop2: Move Primary window to head and Cluster to tail")
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: Id7f0ce15fcbc7cf0edb9c74ee5ca7f6ee2f2d20a
The kthread has less context switch overhead comparing to workqueue.
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Change-Id: I509d8cd86c0966a2bfee8cb8459753368050b2b3
We need two vsync cycle when move a window from
on vp to another: the port_mux take effect in
first vsync, than enable the window at second
vsync.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Change-Id: I87c1ac0803081ecb201d9218d40fdea89424fbd8
This make primary win register first to get the lower zpos.
Also hide the cluster win to the tail, give it a lower chance to
be found by some tradional display sorftware(etc X11).
Change-Id: I20e4885c6b18d7eec6ecc32fbf1ac5620fbb8a30
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
A registered vp(crtc) need a primary plane, some
linux style display software(X11/weston) want more
overlay plane, so we don't register unused vp to
same some plane for overlay.
Change-Id: I66846af7364d1a20f38f35d65ed3fe34b7f280ab
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
for example:
Use CLuster0 as cursor win for vp0.
&vp0 {
cursor-win-id = <ROCKCHIP_VOP2_CLUSTER0>;
};
Change-Id: I10f7921928fbf7ff803c55a95cbce62df658fbed
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
1.adjust panel power on/off sequence
2.remove EPD_OVERLAY_WHITE mode
3.use another way to draw white Lines
Signed-off-by: Zorro Liu <lyx@rock-chips.com>
Change-Id: I4787b0cd4a1f0f0f8cac310afa06d3d1db6dae9b
In preparation to enable building SCMI as a single module, let us move
the SCMI protocol registration call into the driver. This enables us
to also add unregistration of the SCMI protocols.
The main reason for this is to keep it simple instead of maintaining
it as separate modules and dealing with all possible initcall races
and deferred probe handling. We can move it as separate modules if
needed in future.
Link: https://lore.kernel.org/r/20200907195046.56615-4-sudeep.holla@arm.com
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
(cherry picked from commit 1eaf18e35a)
Conflicts:
drivers/firmware/arm_scmi/driver.c
drivers/firmware/arm_scmi/system.c
Fixes: 5730f8b50f ("UPSTREAM: firmware: arm_scmi: Move scmi protocols registration into the driver")
Change-Id: I0509be2a8614d3f98bad8d19e57d75e6371008a4
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Now that scmi bus provides option to create named scmi device, let us
create the default devices with names. This will help to add names for
matching to respective drivers and eventually to add multiple devices
and drivers per protocol.
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
(cherry picked from commit 9c5c463f2a)
Conflicts:
drivers/firmware/arm_scmi/driver.c
Add missing reset devname.
Fixes: b430ea6fd1 ("UPSTREAM: firmware: arm_scmi: Add names to scmi devices created")
Change-Id: I2ba7edb8b3e6483e2a8d6ce3a33dce41d432c7b5
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
The scmi bus now has support to match the driver with devices not only
based on their protocol id but also based on their device name if one is
available. This was added to cater the need to support multiple devices
and drivers for the same protocol.
Let us add the name "reset" to scmi_device_id table in the driver so
that in matches only with device with the same name and protocol id
SCMI_PROTOCOL_RESET.
Change-Id: Iccebdc2ed032db23d5b4e86462ce33534a23924c
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
(cherry picked from commit 34ce3c5e69)
scmi_reset_data->handle needs to be initialised at probe, so that it
can be later used to access scmi reset protocol APIs using the same.
Since it was tested with a module that obtained handle elsewhere,
it was missed easily. Add the missing scmi_reset_data->handle
initialisation to fix the issue.
Change-Id: Id4a398dc0bede531e384301067a71327f1d78821
Fixes: c8ae9c2da1 ("reset: Add support for resets provided by SCMI")
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Reported-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
(cherry picked from commit 61423712db)
On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset and system
control. System Control and Management Interface(SCMI) Message Protocol
is defined for the communication between the Application Cores(AP)
and the SCP.
Adds support for the resets provided using SCMI protocol for performing
reset management of various devices present on the SoC. Various reset
functionalities are achieved by the means of different ARM SCMI device
operations provided by the ARM SCMI framework.
Change-Id: I7cadc2be170ed8029e3db92aeda8249bbb7c4e88
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
(cherry picked from commit c8ae9c2da1)
In order to avoid querying the individual protocol versions multiple
time with more that one device created for each protocol, we can simple
store the copy in the protocol specific private data and use them whenever
required.
Change-Id: I80e3b6177ffe99deb74c2e6dccf705b73f2163a8
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
(cherry picked from commit b55b06b794)
SCMIv2.0 adds a new Reset Management Protocol to manage various reset
states a given device or domain can enter. Device(s) that can be
collectively reset through a common reset signal constitute a reset
domain for the firmware.
A reset domain can be reset autonomously or explicitly through assertion
and de-assertion of the signal. When autonomous reset is chosen, the
firmware is responsible for taking the necessary steps to reset the
domain and to subsequently bring it out of reset. When explicit reset is
chosen, the caller has to specifically assert and then de-assert the
reset signal by issuing two separate RESET commands.
Add the basic SCMI reset infrastructure that can be used by Linux
reset controller driver.
Change-Id: I78f79b81852d31dc3026ba06ca66f36a2aa60df2
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
(cherry picked from commit 95a15d80aa)
Instead of type-casting the {tx,rx}.buf all over the place while
accessing them to read/write __le{32,64} from/to the firmware, let's
use the existing {get,put}_unaligned_le{32,64} accessors to hide all
the type cast ugliness.
Change-Id: I5cbb01ad87d985fc759cdd5d33a63beb8c790c4c
Suggested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit aa90ac45bc)
CLOCK_PROTOCOL_ATTRIBUTES provides attributes to indicate the maximum
number of pending asynchronous clock rate changes supported by the
platform. If it's non-zero, then we should be able to use asynchronous
clock rate set for any clocks until the maximum limit is reached.
Tracking the current count of pending asynchronous clock set rate
requests, we can decide if the incoming/new request for clock set rate
can be handled asynchronously or not until the maximum limit is
reached.
Change-Id: I958da7f1990ef773e26f182b59af26c5717ebd61
Cc: linux-clk@vger.kernel.org
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 2bc06ffa06)
CLOCK_PROTOCOL_ATTRIBUTES provides attributes to indicate the maximum
number of pending asynchronous clock rate changes supported by the
platform. If it's non-zero, then we should be able to use asynchronous
clock rate set for any clocks until the maximum limit is reached.
In order to add that support, let's drop the config flag passed to
clk_ops->rate_set and handle the asynchronous requests dynamically.
Change-Id: I1f6b5947638f3dad041d163bfb44936a3c484da9
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit d0aba11614)
SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor
supports asynchronous read. We can read that flag and use asynchronous
reads for any sensors with that attribute set.
Let's use the new scmi_do_xfer_with_response to support asynchronous
sensor reads.
Change-Id: I8066cecb9565d5f40c42accbebc8ced2747d5dba
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit d09aac0eb1)
SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor
supports asynchronous read. Ideally we should be able to read that flag
and use asynchronous reads for any sensors with that attribute set.
In order to add that support, let's drop the async flag passed to
sensor_ops->reading_get and dynamically switch between sync and async
flags based on the attributes as provided by the firmware.
Change-Id: I000cae002b0fc85dcf09a3d35bd273685d6960b7
Cc: linux-hwmon@vger.kernel.org
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 6a55331c87)
Looks like more code developed during the draft versions of the
specification slipped through and they don't match the final
released version. This seem to have happened only with sensor
protocol.
Renaming few command and function names here to match exactly with
the released version of SCMI specification for ease of maintenance.
Change-Id: Idbaaa32e46e4d515c0fcb57f376f5f5b581e311b
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 9eefa43a1a)
If the SCMI firmware implementation is reporting values in a scale that
is different from the HWMON units, we need to scale up or down the value
according to how far apart they are.
Change-Id: I2e4819d00262d2c17cde293cbd27786d82a3b9df
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
[sudeep.holla: added check of scale = 0 for early exit in scmi_hwmon_scale]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit ac778e6263)
In preparation for dealing with scales within the SCMI HWMON driver,
fetch and store the sensor unit scale into the scmi_sensor_info
structure. In order to simplify computations for upper layer, take care
of sign extending the scale to a full 8-bit signed value.
Change-Id: If1a3907268e7fd5b511c313d429d2d801a52996a
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
[sudeep.holla: update bitfield values as per specification]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 0b673b6486)
Make it easier to identify regulator consumers when consumer device
uses more than one supply.
Before:
regulator ena use open bypass voltage current min max
-----------------------------------------------------------------------------------
regulator-dummy 1 0 2 0 0mV 0mA 0mV 0mV
1-0010 0mV 0mV
1-0010 0mV 0mV
After:
regulator ena use open bypass voltage current min max
-----------------------------------------------------------------------------------
regulator-dummy 1 0 2 0 0mV 0mA 0mV 0mV
1-0010-vccio 0mV 0mV
1-0010-vcc33 0mV 0mV
Change-Id: I69aea6bf17fb8665a1a2ae9434ddc74c61a1a6b6
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/731a4b299c6ae0ee9d8995157600a3477f21a36c.1585959068.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
(cherry picked from commit 6b576eb035)
Reference from hardware design, the vcc_lcdc0_n and vcc_lcdc1_n
regulators are controlled by GPIO.
Add enable pin for vcc_lcdc regulators, also add min and max voltage
make the regulators have voltage values.
Change-Id: Id3bdaa7f5612c28c1a82d22ef8ceb1c72f0fb405
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Add min/max voltage for usb regulators, also add vin-supply for them.
From rk3568-evb1 hardware design, the power tree about usb is
DC12V
-> VCC5V0_USB(controlled by EXT_EN from PMIC)
-> VCC5V0_HOST(controlled by GPIO0_A6)
-> VCC5V0_OTG(controlled by GPIO0_A5)
The EXT_EN from PMIC RK809 is designed for device power off to cut off
the usb 5.0v power, during system on, it keeps always on.
Change-Id: I21e431b4b41022b101b6db92b0769d096679b67c
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
The pcie supply design is (rk3566 evb2 example)
DC12V
-> VCC12V_PCIE(controlled by GPIO0_C2_H)
-> VCC3V3_PCIE(controlled by GPIO0_C2_H)
-> VCC5V0_SYS
-> VCC3V3_PI6C(controlled by GPIO0_C2_H)
The pci phy driver only want to enable or disable the VCC3V3_PCIE power.
Suggested from pcie owner to ignore the VCC12V_PCIE and VCC3V3_PI6C, so
the dts only need to add regulator node for VCC3V3_PCIE.
Most of time we keep the regulator name same as the hardware design, so
the dts node is
vcc3v3_pcie: gpio-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc3v3_pcie";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
enable-active-high;
gpio = <&gpio0 RK_PB7 GPIO_ACTIVE_HIGH>;
vin-supply = <&dc_12v>;
};
The regulator type is "regulator-fixed" since its voltage always be
3.3v, min and max should be 3300000 make the regulator has a voltage
value.
The regulator can be enabled or disabled by regulator_enable or
regulator_disable function, so make the GPIO0_B7 as "ena_pin" for the
regulator.
The regulator is supplied by DCIN_12V, so add the vin-supply.
Change-Id: Iaf70abe9c9e06504af067dc0e3d60b775557c026
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
cur frame end and next frame start irq will
togeter if v-blank is short. to handle sof
event later if this happens.
Change-Id: If45300c8f640a6516624c4952e4f124afd7a9952
Signed-off-by: Cai YiWei <cyw@rock-chips.com>
