Fixes commit 6b97462b64 ("MLK-18690-3: hdp api: Remove
info frame API function")
The info frame API is removed, so the maximum of state->tmp
is 8.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
It takes 33 milliseconds to scanout a frame when display refresh rate
is 30fps, and 42 milliseconds for 24fps. So, if we wait for framegen
frame index moving, 30 milliseconds timeout value is not enough to
cover all reasonable display refresh rates. 50 milliseconds should not
be a bad choice.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit 8564546882)
For framebuffer linear pixel formats, we calculate the buffer address
with an offset to do framebuffer start point x/y cropping. This way,
the src_x/y seen by fetchunit(including prefetch engine, if used) can
be zero. The reason why it still works with the existing nonzero
settings is very likely that the fetchunit or prefetch engine may
discard the initial invalid pixels by looking at the correct buffer
address, frame stride, frame width and frame height. However, it
would be good to correct the mistake in driver.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit 8847a9b7c2)
There are prefetch engine fixups embedded in the updated i.MX8QM silicons.
So, prefetch engines in all i.MX8 variants should be the same. Let's
remove has_prefetech_fixup from devtypes which is no more needed.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit 875c31a70f)
With the updated i.MX8QM silicon, prg1/10 may be shared bewteen
dpr1/3_channel1 and dpr1/3_channel2 respectively with appropriate
mux configurations in SCU firmware. If prg1/10 are attached to
dpr1/3_channel2, then they act as the auxiliary prg to process
chroma pixels for SC_R_DC_0/1_BLIT1. Otherwise, they act as the
primary prg to process RGB pixels for SC_R_DC_0/1_BLIT0.
Let's reflect this update in the device tree file.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit dab218c3c4)
The pixel link validation and sync ctrl enablement should be the last
step to enable the display pipeline which involves the HDP encoder.
So, let's move the pixel link operations from initialization stage to
enc->enable/disable. Also, the pixel_link_init/deinit hooks are replaced
with pixel_link_validate/invalidate and pixel_link_sync_ctrl_enable/disable,
since the display controller driver has already initialized the pixel link
at the driver probe stage.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit cb234bc95e)
The pixel link MST address is set by the display controller driver,
so let's remove the redundant setting from the hdp driver.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit f0f0a1970f)
The framegen driver knows the encoder type, so it may set pixel link
MST address according to the type. The MST address for the TMDS encoder
is special, while the address is zero for other encoders.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit fb3e63cce0)
When TMDS encoder is used, the encoder would provide framegen display clock
directly via clk_bypass. So, we don't have to set clk_disp rate. This
should work with or without pixel combiner(pixel combiner would combine
two framegens' output to drive high pixel rate displays via TMDS encoder
only currently).
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit 4b710fe10f)
This patch adds SC_C_SYNC_CTRL into enum sc_ctrl_e to sync with SCU
firmware commit <1db854d7d521> (SCF-151: Added new SC_C_SYNC_CTRL to
control both control signals at the same time.).
Signed-off-by: Liu Ying <victor.liu@nxp.com>
(cherry picked from commit 9e4a5892da)
For add flexcan node in dtsi and xen doesn't support can, add "delete
flexcan node" for DomUs now.
Change interrupt-parent to gic, for xen does not support "wu"
interrupt controller.
Signed-off-by: Xiaoning Wang <xiaoning.wang@nxp.com>
This patch adds device tree support for i.MX8QXP DDR3L validation
board, it ONLY has 1GB memory, so CMA size needs to be reduced
when including the i.MX8QXP LPDDR4 ARM2 board device tree file.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Bai Ping <ping.bai@nxp.com>
(cherry picked from commit 3005f91cef3057aa6eeb168415ec42e57fc993f9)
On the long read routine, there was a bug when the driver was parsing
the value from RX_PAYLOAD register.
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
By default, imx8qm b0 silicon set the IO voltage to 2.5v, but the arm2
board is designed as 1.8v voltage for enet IO, so force the IO voltage
to 1.8 by setting COMP_CTL_GPIO_1V8_3V3 pins like:
For ENET0: SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB
For ENET1: SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETA
The pin setting:
1.8V/3.3V : bit4=0, bit[30]=1, bit[2:0]=000
2.5V : bit4=1, bit[30]=1, bit[2:0]=010
For 2.5v IO timing test, HW board need to do some rework:
- Force PHY work at 2.5v mode
- Supply 2.5v voltage to VDD_ENETx
Tested-by: Sandor Yu <Sandor.yu@nxp.com>
Tested-by: Jason Liu <jason.hui.liu@nxp.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
The IMX_DMATYPE_SAI(24) performance is not enough to support high
sample rate/channels of audio case, there is a lot of underrun and
the sound is noise, the reason is that with this script, sdma copy data
through a long path (SDMA->pl301_audio -> pl301_display -> … ->
pl301_wakeup -> AIPS1 -> SPBA2 -> SAI).
The IMX_DMATYPE_SSI_SP(2) performance is better, which go through a shorter
path (SDMA -> SPBA2 -> SAI).
So we switch to use the IMX_DMATYPE_SSI_SP script, then 384k/32b/16c is
supported well.
Cloned from commit d5b70e9232 ("MLK-18643: ARM64: dts: imx8mm: change the
sdma script for SAI").
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
(cherry picked from commit 390620091748db98216c2f95fe95fb4ac3284564)
The existing implementation calculates mclk rate as function
of audio sample rate multiplied to multiplier taken from Table 5.
However this is not accurate for Manual Setting Mode - tables 3 & 4 from
AK4458 RM defines rate (LRCK/FS) and frame width (MCLK/16fs..1152fs) ranges
as parameters to calculate mclk frequency. Aside of this - adjust
bclk:mclk ratio from machine driver as function of "compatible" id.
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
(cherry picked from commit 527b8b7032dcb75c14bb2790330ab96743d83b16)
Similar to DSD512 case we need a PCM pinctrl state option to map SAI BCLK
to codec MCLK pin. Given that bitclock rate is function of slots number and
slot width - pass bclk rate as parameter value from SAI driver.
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
(cherry picked from commit 826caeae32713cff7ad50de8ebc9915de975edd9)
Comparing to 4.9 kernel, the generic irq chip core of 4.14 kernel
imposes more strict check on !irqd_irq_masked(&desc->irq_data) when
it tries to unmask an irq via unmask_irq(). For irq chips without
implementing ->irq_enable() and ->irq_disable() callbacks, like the
DPU irq chip, the IRQ_DISABLE_UNLAZY flag has to be set to irq status,
otherwise, irqs cannot be enabled again after disablement(due to things
like system power management).
Signed-off-by: Liu Ying <victor.liu@nxp.com>
When switching from a 10-bit to an 8-bit color depth, the PHY pixel engine
simply stops functioning correctly 90% of the time. This results in the
HDMI sink not detecting any signal.
This patch will reset the PHY pixel engine after the pipe clocks are ON,
in the bridge enable callback. This will make the pixel engine work
correctly when BPC changes. Resetting the pixel engine before all the pipe
clocks are on, produces no results.
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
(cherry picked from commit 72246ac9ccfa2074f4f575292af10d19a58c95c4)
To support lowest power mode for suspend, if no wakeup source
from non-secure partition is enabled, IRQSTEER can be powered
off when suspend, so non-secure linux OS needs to pass WU
irqchip wakeup source info to ATF, as MU is always enabled
as wakeup source, and it is a system level resource, so no
need to have it in WU domain.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Bai Ping <ping.bai@nxp.com>
(cherry picked from commit d45b2fd47417cc1c4e03616007271e07834cf415)
Refine dma-buf metadata setting to support framebuffer compression
Change-Id: Ia0ab9224d789c4b620e33a6f1c28483025a136ce
Signed-off-by: Richard Liu <xuegang.liu@nxp.com>
This patch adds line 0 PAD wakeup support, it is missed previously,
also protect the PAD wakeup interrupt handle with spin lock to
avoid possible race condition of GPIO interrupt arriving during
PAD wakeup interrupt handling.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
(cherry picked from commit db842471137ef2758de6192f8f400e4b56da5d01)
4K@50 does not currently work. This patch will enable the scambler for
VIC96@50Hz.
Signed-off-by: Oliver Brown <oliver.brown@nxp.com>
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
(cherry picked from commit 0f13947a2fb72673b19c9f154eb202a9be916c4f)
Select gpio PAD wakeup for those i.MX8 platforms with
system controller present.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Bai Ping <ping.bai@nxp.com>
(cherry picked from commit 61f3cc34747e5c8db1578c8aba5bd9592533cede)
This patch enables gpio pin's pad wakeup function which
is supported by SCFW, with pad wakeup enabled, GPIO's
power is no need to be enabled after suspend, hence
save a sub-system's power.
To enable pad wakeup, dtb needs to provide pad wakeup
number for each gpio port, and each pin has to provide
<pin_id, type, line>, they should be inside each gpio node,
this is for calling SCFW APIs to enable/disable pad wakeup,
example of adding GPIO4_22 pad wakeup in dtb:
gpio4: gpio@5d0c0000 {
compatible = "fsl,imx8qm-gpio", "fsl,imx35-gpio";
reg = <0x0 0x5d0c0000 0x0 0x10000>;
interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
power-domains = <&pd_lsio_gpio4>;
interrupt-controller;
#interrupt-cells = <2>;
/* total pad wakeup number in gpio4 */
pad-wakeup-num = <1>;
/* SC_P_USDHC1_CD_B, SC_PAD_WAKEUP_LOW_LVL, LINE 22 */
pad-wakeup = <27 4 22>;
};
Pad wakeup will be enabled after GPIO port suspend, and
once any pad wakes up system, gpio driver will get the
wakeup line and handles the event during noirq resume
phase.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Bai Ping <ping.bai@nxp.com>
(cherry picked from commit 1c7ffe9bf3a115031cec8c759a4cd0e09146de09)
Add PAD wakeup support for i.MX8 platforms with system
controller present, with PAD wakeup feature enabled,
the corresponding resource's power is no need to be
kept enabled when linux suspend, thus save a sub-system's
power consumption.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Bai Ping <ping.bai@nxp.com>
(cherry picked from commit 3b5d781273b22461de9aaea337f9da9b2fdb643e)
Improving the PHY timing parameters by using linear interpolation for the linear parameters.
For, the non-linear parameters, use more frequency steps to improve the accuracy.
Signed-off-by: Oliver Brown <oliver.brown@nxp.com>
Allow PLL switch for playback stream only and remove
PLL switch guard with regard to capture stream as the
clock for capture stream is provided externally.
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
(cherry picked from commit c8213da5fbcd370acb4d764bef5df5981a517c11)
While investigating MLK-18894 ran a large number of suspend iterations
on imx6qp-sdb with rc2 kernel. After ~6 hours it hung while suspending
devices and sysrq-T showed the following trace for rtcwake:
The gckHARDWARE_SetPowerManagementState function seems hung waiting for
gckHARDWARE_QueryIdle. Inside the gckHARDWARE_QueryIdle there is a check
which looks like this:
rtcwake D 0 7090 561 0x00000001
[<809d5fc8>] (__schedule) from [<809d6380>] (schedule+0x48/0xb0)
[<809d6380>] (schedule) from [<809d9d3c>] (schedule_hrtimeout_range_clock+0xc8/0x13c)
[<809d9d3c>] (schedule_hrtimeout_range_clock) from [<809d9df0>] (schedule_hrtimeout+0x20/0x28)
[<809d9df0>] (schedule_hrtimeout) from [<807168c4>] (gckOS_Delay.part.3+0x64/0x6c)
[<807168c4>] (gckOS_Delay.part.3) from [<8071813c>] (gckOS_Delay+0x18/0x20)
[<8071813c>] (gckOS_Delay) from [<8073f08c>] (gckHARDWARE_SetPowerManagementState+0x838/0xb70)
[<8073f08c>] (gckHARDWARE_SetPowerManagementState) from [<8071df18>] (gpu_suspend+0x74/0xe4)
[<8071df18>] (gpu_suspend) from [<804fb9e8>] (dpm_run_callback+0x3c/0xdc)
/* Test if address is inside the last WAIT/LINK sequence. */
if ((address >= Hardware->lastWaitLink)
&& (address <= Hardware->lastWaitLink + 16)
Stepping through using the debugger (screenshot attached) this function
seems to return non-idle with both address lastWaitLink and being equal
to 0xFFFFFFF0. As far as I can tell the intention seems to be that the
check should pass but 0xFFFFFFF0 + 16 overflows back to zero so the
second part of the check fails because 0xFFFFFFF0 is not less than or
equal to 0.
Adding some prints to GPU code it seems that it's normal for these
values to be >0xFFFFe000. When they (randomly) hit 0xFFFFFFF0 exactly
the idle check will incorrectly fail and suspend will hang.
Actually, it is wrong when address reach to Hardware->lastWaitLink + 16,
because the address shall be either Hardware->lastWaitLink(wait command)
or Hardware->lastWaitLink + 8 (link command).
Fix the end address offset with 8 or 16 (extra 8 bytes for L2 flush).
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
Below description copied from RM:
"RX_THRESHOLD. This field defines the FIFO threshold that triggers
a RX DMA/INT request.A RX DMA/INT request is issued when the number
of data entries in the RXFIFO is greater than RX_THRESHOLD."
Then, the RX_THRESHOLD of ECSPIx_DMAREG should be set as 'wml-1',
otherwise, the last 'wml' number of data in rxfifo will never be pulled
out.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Han Xu <han.xu@nxp.com>
Upstreaming code already support dynamically adjust watermark with
the transfer count, so in case 'wml=1', tx wml will be set to 0
after divided by 2, which cause tx dma never start.Actually, don't
need promise tx_wml=rx_wml/2 any more, because the max wml for tx/rx
is half of fifo size and sdma script have already check the data count
in RXFIFO, if more than half of rxfifo data remain in rxfifo, tx dma
will never start transfer next 'watermark'(the max count maybe the half
of fifo size) data until the data in rxfifo less than half of rxfifo.
So never any data loss happen. Remove 'wml/2'.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Han Xu <han.xu@nxp.com>
This patch will allow userspace to rotate planes by setting the
'rotation' property. Generally, 0 and 180 rotations are allowed for
pretty much all 8-bit xRGB and 2-plane YUV420 formats. 90/270 rotations
can be performed only for non-compressed tiled GPU xRGB formats. Tiled
YUV420 formats do not allow rotations at all because these formats need
DTRC for de-tiling and DTRC has no rotation support.
For more info, consult the DPR Features chapter in the reference manual.
Test example:
modetest -M imx-drm -w 27:rotation:4 -w 32:rotation:33 -w 27:alpha:30 -s
42@31:3840x2160-60@XR24 -P 32@31:3840x2160@NV21
The above will perform:
* 180 degree rotation of primary plane (XR24);
* vertical flip of first overlay plane (rotate-0 | reflect-y);
* set primary plane alpha to 30;
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@nxp.com>
support for encoder
- Add level and profile for h264 encoder, level is mapped like level 5.1
to uLevel 51 for firmware except 1b to uLevel 14
- Add check for the function enc_mem_alloc() to ensure buffers are
allocated once to prevent memory leak
- modify streamoff() streamon() update_yuv_addr() and report_stream_done()
function to enable loop for encoder
Signed-off-by: Huang Chaofan <chaofan.huang@nxp.com>
For some eMMC, after switch to HS400ES mode, it need to config the strobe
dll target dealy even if the clock is 50MHZ or 25MHz, otherwise will meet
CMD index/crc error when send CMD13 to check the switch status. Take
imx8MM-EVK board as example, without this patch, it will meet:
[ 2.473915] IRQ status 0x000a8001
[ 2.473930] the mmc send status get -84
[ 2.473934] mmc2: mmc_select_hs400es failed, error -84
[ 2.473938] mmc2: error -84 whilst initialising MMC card
And we also meet some customer require to let eMMC work at 80MHz HS400ES
mode, so here remove the 100MHz limitation for Strobe DLL target delay
setting.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Commit 7103962dbc would return success even though we
don't have a OPP array (i.e., i.MX6). This patch completes that
in de-register part.
Signed-off-by: Marius Vlad <marius-cristian.vlad@nxp.com>
Add delay time and retry to make sure the Power state was changed.
Signed-off-by Yong Gan <yong.gan@ncp.com>
(cherry picked from commit 59a836f35807f5c09c98cf3be318ac49526bcf69)
Due to HW board design, FEC2 depend on FEC1's MII bus. But FEC1's PHY
locates on adapter PHY board that may not connect with sabreauto board.
And FEC1 depend on MAX732X to select 1.8v IO voltage, MAX732X chip is
also installed on adapter board.
In such case, MAX732X expander gpio chip is not registered, and pinctrl
driver cannot detect the gpio chip and return deferred_probe, FEC1 driver
also do defer probe and never has chance to get probed. so its MII bus is
also not regisgered. Then FEC2 also cannot work without MII bus.
To avoid FEC1 depends on MAX732X, move the output IO setting to max732x
driver by setting the default value.
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
In imx8mm-evk DTS both AUDIO PLL rates are configured, so SPDIF1
pll8k and pll11k clocks can be set accordingly.
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
(cherry picked from commit 4ee8ed7f91ebc96ee398ec1382fac738d79cfe6c)
