Remove the ldb clocks from the ldb node. Those clocks were added
upstream and they are needed for the DRM imx-ldb driver. Since we are
using the fbdev ldb driver for imx6qp, those clocks are not compatible
with our fbdev driver.
Fixes: 78241a88958a ("ARM: dts: add dts file for imx6qp")
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Since the DCSS is not fully powered off when a suspend/blank occurs, the
next time we resume/unblank, the DCSS->DSI pipeline cannot be fully
re-initialized. In order to fix this issue, we should also not
completely power off the DSI too. Just configure it to stop
transmitting, by powering off the PHY.
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Update the register settings for PRG values to be more accurate,
depending on the timing used.
Also, update the init function to make sure the PHY is powered OFF in
this stage, and the power_on function to correctly power ON the PHY
according to the specification: assert PD_PLL, wait for LOCK, assert
PD_DPHY.
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Currently, the DSI panel init sequence is made in the prepare function,
right after the reset pin is asserted. This implies that at this moment,
the DSI host needs to be enabled. If the DSI host is enabled during
panel prepare, there will be DSI signal on the DSI lanes during the
panel reset, which is wrong.
In order to fix this, the init sequence was moved from prepare to
enable, while the reset sequence is made in prepare. Also, the DSI host
intialization has to be updated in such a way that the host won't send
DSI signals on the lanes between the prepare and enable of the panel.
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Currently, the DSI panel init sequence is made in the prepare function,
right after the reset pin is asserted. This implies that at this moment,
the DSI host needs to be enabled. If the DSI host is enabled during
panel prepare, there will be DSI signal on the DSI lanes during the
panel reset, which is wrong.
In order to not to have any signal on the DSI data lanes during reset,
the reset sequence must be separated from the init sequence, so move the
init into enable function and leave the reset into the prepare function.
Also:
- removed the calls to panel_disable and panel_unprepare from
panel_remove, since the panel should be already disabled when this call
is made
- fixed the call ordering to panel_disable and panel_unprepare from
rad_panel_shutdown function
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
This patch was cherry picked from
https://patchwork.kernel.org/patch/10155143/
When virtio-rpmsg device is provided via virtio-mmio transport, the
dma_alloc_coherent() (called by rpmsg_probe()) fails on ARM/ARM64
systems because "vdev->dev.parent->parent" device is used as parameter
to dma_alloc_coherent().
The "vdev->dev.parent->parent" device represents underlying remoteproc
platform device when virtio-rpmsg device is provided via
virtio-remoteproc
transport. When virtio-rpmsg device is provided via virtio-mmio
transport,
the "vdev->dev.parent->parent" device represents the parent device of
virtio-mmio platform device and dma_alloc_coherent() fails for this
device
because generally there is no corresponding platform device and dma_ops
are not setup for "vdev->dev.parent->parent".
This patch fixes dma_alloc_coherent() usage in rpmsg_probe() by trying
dma_alloc_coherent() with "vdev->dev.parent" device when it fails with
"vdev->dev.parent->parent" device.
Fixes: b5ab5e24e9 ("remoteproc: maintain a generic child device for
Signed-off-by: Anup Patel <anup@brainfault.org>
Signed-off-by: Adriana Reus <adriana.reus@nxp.com>
Support using PSCI to handle Power stuff on imx7d.
i.MX7 LPSR mode not implemented now.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
A specific node for OCRAM mapping in optee as been added in
the device tree. These dedicated optee device trees can be
removed.
Signed-off-by: Clement Faure <clement.faure@nxp.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
This node will be used by the OCRAM driver in optee to:
* Get the OCRAM start address for power management in optee.
* Add an entry that will overwrite ocrams nodes and dynamically reduce
the OCRAM available for mmio-sram in Linux.
That way we do not touch the legacy Linux boot and remove the dedicated
optee device tree.
Signed-off-by: Clement Faure <clement.faure@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
This change affects all i.MX 6 with PL310 L2 Cache controller.
When Linux runs in Non-secure World the PL310 has already
been initialized by the ARM secure World running OP-TEE os.
However, in order to have a proper Linux Initialization all the
L2 cache ways have been locked by the secure world.
This patch unlock all the ways during pl310 initialization.
Signed-off-by: Cedric Neveux <cedric.neveux@nxp.com>
MX8 chips does not have GC355. So no need to build the drivers
Signed-off-by : Xianzhong Li <xianzhong.li@nxp.com>
Reviewed-by : Prabhu Sundararaj <prabhu.sundararaj@nxp.com>
Currently, the code checks if RGB supports 10-bit when it should
actually check that YUV420 supports 10-bit.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
(cherry picked from commit 4064f377b0425fd7ec2c3ed15410ae7fad4077b5)
When YUV420 is used, we need to check that the deep color mode actually
supports the bit depth required. Currently, the code checks the RGB bit
depth.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
(cherry picked from commit 5ac33861906cb7be660cc5c0a0f494194a81275a)
The drm_parse_ycbcr420_deep_color_info() is called only for HDMI 2.0,
however the DC masks were incorrectly set. These were set according
to HDMI 1.4 specification.
This patch will set the deep color depth masks to the HDMI 2.x specs
(see Table 10-6 in HDMI 2.x specs for field descriptions).
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
(cherry picked from commit e3a1cac6fdd88f4391180d89d5881748214a1b4f)
Currently, the maximum upscale ratio is 1:7. However, DCSS can support
upscale ratios up to 1:16, even though the RM states the maximum upscale
ratio is 1:8.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
(cherry picked from commit 361a057ceec0676be069b2150ee533b7ad11227a)
With new bindings the PU regulator is fetched much later, after
imx_gpc_probe is complete. So hack the imx_pgc_power_domain_probe
function to check for fsl,ldo-bypass at this point.
This issue only actually affects imx6qp because on other SOCs with a
vddpu regulator is it disabled on boot and settings are copied from
vddsoc on first enable, see commit 64dd7300a334 ("MLK-11407-3:
regulator: anatop: force vddpu to use same voltage level as vddsoc")
On imx6qp however disabling the PU regulator is not allowed because of
hardware errata.
Fixes: 94e8d6daea9a ("MLK-11407-1 soc: imx: gpc: enable PU bypass")
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
Low power idle exit latency is much longer than declared, in the
milisecond range.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
The current code for deciding which CPU runs the complete lpi flow is
too complicated. Since all enter/exit code now runs under the same lock
we can just use a single non-atomic counter of cpus inside lpi.
Another variable is used to make num_online_cpus() available to ASM code
but idle code can treat it as a constant.
Unlike on imx_4.9.y num_online_cpus is fetched every time idle is
entered becuase hotplug notifiers are gone.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
The GPC will wake us on peripheral interrupts but not IPIs. So check
them manually by reading the GIC's GICD_SPENDSGIR* registers and
aborting idle if something is pending.
We do this only for the last cpu and after taking the required locks.
We know that at this stage the other cpu is in WFI itself or waiting for
the imx_pen_lock and can't trigger any additional IPIs. This means that
the check is not racy.
This fixes occasional lost IPIs causing tasks to get stuck in the
TASK_WAKING 'W' state for long periods. This eventually manifested as
rcu stalls.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
This makes the code much easier to reason about. In particular it o
makes sure the imx7d cpuidle driver respects the requirements for
cpu_cluster_pm_enter/exit:
* cpu_cluster_pm_enter must be called after cpu_pm_enter has been called
on all cpus in the power domain, and before cpu_pm_exit has been called
on any cpu in the power domain.
* cpu_cluster_pm_exit must be called after cpu_pm_enter has been called
on all cpus in the power domain, and before cpu_pm_exit has been called
on any cpu in the power domain.
This fixes interrupts sometimes getting "stuck" because of improper
save/restore of GIC DIST registers.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
GPC will stop ARM clock if both CPUs are in idle and CPU_CLK_ON_LPM is
set in GPC_LPCR_A7_BSC. Make sure that doesn't happen when cpu1 enters
state2 and cpu0 enters state0 because the default arm WFI state is not
marked with CPUIDLE_FLAG_TIMER_STOP and it can result in arch_sys_timer
being stopped unexpectedly.
It is possible to reproduce incorrect behavior by explicitly disabling
other idle states for cpu0/cpu1 and timing how much sleep calls take on
cpu0. Ocassionaly something like "sleep 1" will take 3-4 seconds to
complete.
Make sure that both CPUs are in the same idle state before entering
WAIT.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
For standby mode, RBC workaround is NOT necessary as ARM platform
is NOT powered down;
Correct GIC register offset(0x1000) for disabling distributor.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Enable memory power down for i.MX7D TO1.1 to save power, TO1.0
has issue of entering DSM by mistake, so it is disabled as a
solution, now that this issue is fixed on TO1.1, enable it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Same as low power idle, during GPC shutting down ARM core,
interrupts must be hold until the process done, apply RBC
workaround and disable GIC during GPC powering down ARM
core.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
i.MX7D TO1.1 only supports DDR3 running at max frequency of 400MHz,
update busfreq driver accordingly.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Enable DDR auto self-refresh for i.MX7D, when doing DDR
frequency scale or suspend/resume, DDR self-refresh will
be disabled, this is incorrect for saving power, enable it
for all these scenarios.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
For low power idle with ARM power gated, per hardware requirement,
there must be no interrupt coming during the power down
process of ARM core, so RBC counter is enabled to hold interrupts
and GIC must be disabled at the moment;
The hardware design team recommends ~240us is required during ARM
core power down, so we update the RBC counter value to 8(~240us);
Update GPC SCU and CPU power up/down timing according to design
team's recommendation.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Design team recommend to put SCU/C0/C1 in same power up slot
to avoid reset timing issue of debug mode, adjust the power
up slot and timing per their requirement.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
When only single core online for i.MX7D, the secondary core wfi
flag should be set to make sure low power idle can be entered when
last core enters wfi. Otherwise, DDR/CCM/ANATOP will NOT enter
low power mode as the secondary core wfi flag is always clear;
Make sure the last power up slot do the ack for single core case.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Since upstream removed cpu hotplug notifiers skip this part.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
ARM does NOT execute one instruction every cycle, the bus bandwidth,
cache status etc. would impacts the instruction execution time, so we
can NOT just calculate the delay time by ARM frequency, this patch
adjusts loop number to get a ~20us delay, measured via GPIO pin.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Per design team's suggestion, when enter/exit DDR PADs low power
mode, ~10us delay is necessary to make sure signal stable enough
for DDR operation, so add ~20us delay(10us margin) and adjust
latency value of low power idle.
Optimize enter/exit self-refresh flow of DDRC according to
design team's suggestion.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
To fix the i.MX6SX probe second chip error issue, add a dedicate AHB
read lut entry, The patch also remove the read length parameter for lut
preparation, which can be ignored.
For the MICRON DDR read, constrain the dummy to up to 8 clock cycles.
Signed-off-by: Han Xu <han.xu@nxp.com>
there are 2 test failed on 8QXP FB. CL151757 fixed bug #20196,
for image objects using host ptr, set the cacheable flag correctly.
merged CL151774 fix build error cause by CL151757.
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
When pm is running power ON to OFF (not broadcast), gckCOMMAND_Stall is called for synchronization.
But it does not blocks more events.
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
When power ON to other mode with broadcast (SUSPEND_BROADCAST,
IDLE_BROADCAST, OFF_BROADCAST), command->powerSemaphore is acquired after check idle.
code sequence:
check commit atom
check idle
>>> at this point, other thread may have new commits at this
>>> point.
Acquire command->powerSemaphore
... do clock off
This can cause unexpected interrupts after clock OFF or power
OFF.
To fix: try to acquire powerSemaphore before check commit atom,
abort when failure, because command commit is in progress.
fix bug #19216, #19230.
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
When pm (SetPowerManagementState) is running power ON to
SUSPEND_BROADCAST, it only checks wait-link FE, but not Async FE. Clock
can be off when read AsyncFE Acknowledge register and other.
pm thread:
...
check commit atom ok
>> check idle OK
(former stopIsr before cl144673 is here)
set GPU clock off
...
isr:
gcmkONERROR(ReadRegister(AQ_INTR_ACKNOWLEDGE_Address));
gckEVENT_Interrupt
>>> here, at this point, all interrupt comes, check idle in
>>> pm thread can pass.
gcmkONERROR(ReadRegister(AQ_INTR_ACKNOWLEDGE_EX_Address));
gckFE_UpdateAvaiable -> ReadRegister(GCREG_FE_ASYNC_STATUS_Address)
If gcmkONERROR(ReadRegister(AQ_INTR_ACKNOWLEDGE_EX_Address))
fail of clock off, then gckHARDWARE_Interrupt fails. In isrRoutine, it
won't wake up threadRoutine. Then it's stuck!
ReadRegister(GCREG_FE_ASYNC_STATUS_Address) failure can cause
unexpected behavior, too.
Former stopIsr (free_irq, before cl144673) can remove isr before
GPU clock off. So the issue is hidden.
To fix:
1. We should return success when either FE or AsyncFE reports
correct interrupts, so that isr can wake up threadRoutine for either FE.
That means, only need return ERROR when both FEs reports ERROR.
2. Add check for status of
ReadRegister(GCREG_FE_ASYNC_STATUS_Address).
Fix bug #19216, #19230.
merged BUG#19216 BUG#19230 CL152073 add missing part for CL151955
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
Dump the error info only when there is an error. If the gcdALLOC_ON_FAULT is not enabled, still need to check
the HW status to decide whether to dump the exception info or not
Signed-off-by: Ella Feng <ella.feng@nxp.com>
Reviewed-by: Xianzhong Li <xianzhong.li@nxp.com>
codec_clk is now part of private_data.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Cosmin-Gabriel Samoila <cosmin.samoila@nxp.com>
Upstream refactored GPC power domains to have a nested pgc node, this
means that the pu power domain needs to be referenced differently.
This fixes warnings like these:
OF: /soc/gpu@00130000: could not get #power-domain-cells for
/soc/aips-bus@02000000/gpc@020dc000
This warning probably also means that GPU power management is not done
correctly.
Old bindings are still used on imx6s*
Fixes: 0a9a9a732f88 ("MGS-3705-1 gpu: dts: enable gpu devices for imx6")
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Xianzhong <xianzhong.li@nxp.com>
Some HDR TVs have multiple HDMI ports but only one of them is HDMI 2.0
compliant, hence HDR capable. The rest are HDMI 1.4.
The HDMI 1.4 ports' supported colorimetry is only REC.709 and REC.601.
However, the supported EOTF in HDR metadata block can be BT.2084 which
should be matched with REC.2020.
This patch makes sure that BT2084 is used only if colorimetry supports
REC.2020. Otherwise, REC.709 will be used.
Additionally, change a message from info to debug. No need for it to
show up all the time.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
In certain conditions, i.e. YUV mode, pixel_depth variable will be used
uninitialized. This can lead to unpredictable behavior.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
The following commit:
44b460cfe5 ("drm: imx: remove struct imx_drm_crtc and
imx_drm_crtc_helper_funcs")
removed some functions from imx-drm-core. As a consequence,
the CRTC ports were not detected properly.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
set GPU baseAddress with 256M on IMX6Q and iMX6QP,
add reserved cma in DTB to support different size,
the default cma size is 320M on all imx6 boards.
integrated patches from imx_4.9.y:
1.MGS-955 GPU:Integrate GPU module
commit: 73183c14a20d4f1d02317f80db3d90b3be1546fc
2.MGS-1211 gpu: add GPU for 6sl,6sx,6dl
commit: 80a8994c47cbb97fb31ef0efab92ddb29002448e
3.MGS-1087 gpu: Move the GPU reserved memory to DTS file
commit: ea0111da6892b52c790da607a3d91140d1ebf936
4.MGS-2540 [#ccc] Need set baseAddress with RAM start address on IMX6Q
commit: de838d99d9264884cbaaa601ab323a70b62634d9
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
Since the drm_bridge_attach function now supports chained bridges, there
is no need for nwl_dsi_add_bridge and nwl_dsi_del_bridge functions, so
remove them.
Now, we can pass the existent bridge to drm_bridge_attach.
This fixes a bug created during kernel 4.14 rebase process.
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
The nwl_dsi-imx which is the platform driver for the NortWest Logic DSI
host controller found on IMX platforms handles the DSI host as a bridge.
Since the drm_bridge_attach function now supports chained bridges, there
is no need for nwl_dsi_add_bridge and nwl_dsi_del_bridge functions.
Just pass the existent bridge to drm_bridge_attach.
This fixes a bug created during kernel 4.14 rebase process.
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
