For imx8mq-evk board, B4 board change touch/mipi-hdmi connected i2c bus
from i2c1 to i2c3. The default dual-display dts file is for the B4
board.
This patch adds a new dts file to also support dual-display on B3 (or
lower) boards.
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Check the return value of .brcmf_fil_iovar_data_get() to fix
the coverity issue of "error handling issue".
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Init the wlfc_mode variable before it is used to fix
coverity issue of "Uninitialized variable".
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Configure imx8qm/qxp pin as RTC 32KHz clock output as the
low power clock source for some WIFI chip.
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
i.MX7ULP SoC revision is available from B0, the SIM_JTAG_ID
register bit[31:28] indicates SoC revision as below:
4b'0001 B0
4b'0010 B1
This register is NOT available on A0, tested on B1 chip
as below:
root@imx7ulpevk:~# cat /sys/devices/soc0/revision
2.1
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Bai Ping <ping.bai@nxp.com>
Tested-by: Ye Li <ye.li@nxp.com>
Unlike i.MX6qdl and i.MX53 LDB variants, the i.MX8 LDB variants(i.MX8qxp
and i.MX8qm) in existence don't have frontend mux, thus, we should split
the logic to program the ch0/1_mode for variants w/wo the mux. It turns
out LDB_CH0_MODE_EN_TO_DI0 can be used for channel0 in both LDB single
mode and LDB split mode for the i.MX8 LDB variants. However, based on
test results, for i.MX8qm LDB channel1, LDB_CH1_MODE_EN_TO_DI1 has to be
used in single mode, while, i.MX8qxp may work with LDB_CH1_MODE_EN_TO_DI0
or LDB_CH1_MODE_EN_TO_DI1. With LDB_CH1_MODE_EN_TO_DI0, i.MX8qm LDB
channel1 would output wrong image in single mode(it looks like color
is wrong based on test results). The i.MX8 LDB variants channel1 mode
can still be LDB_CH1_MODE_EN_TO_DI0 in split mode(the patch doesn't
touch this). In essence, this patch fixes the channel1 single mode for
i.MX8qm LDB by correcting the ch1_mode, while all other features
should work as before. Note that due to hardware issue, we didn't test
the channel1 single mode for i.MX8qm. We need to populate several
resistors to enable the connectors driven by channel1 in single mode
for either ARM2 platform or MEK board. Tests are done with IT6263
LVDS to HDMI transmitter driven by LDB0 channel1 after r206, r207, r208
and r209 are populated on the i.MX8qm MEK board.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
This patch fixes coverity issues as below:
1. resource leak
2. possible case of division by zero.
Fix#1 by kfree the resource before return error;
Fix#2 by adding zero check before registering delay timer.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Bai Ping <ping.bai@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.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
(cherry picked from commit d5b70e9232218c419f7f6f843249e4bba84156b6)
Because reset and pwn pin of gpio1 are not configurated for ov5640,
so it leads to read ov5640 register fail.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
With cpu-idle enabled, we observe that DSI panel display is NOT
working on i.MX8QXP MEK board, still under debugging, since cpu-idle
ONLY saves ~15mA in runtime, it is NOT valuable enough compare to
whole system, so disable it for now until everything is stable enough.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Nitin Garg <nitin.garg@nxp.com>
Implemented system suspend resume functions to call hwvad enable/disable
then do runtime_force_suspend/resume.
Since hwvad can run independently, when user calls enable/disable, we
will have to increment/decrement usage counter by calling
runtime_*_sync but to avoid doing this when disable/enable is called
from system_suspend/resume since we called pm_runtime functions - this
is why we have added the sync parameter in enable/disable_hwvad.
However, we ignore the busy flag because the module wasn't designed to
work with arecord and hwvad in parralel and we only print a warning.
Since hwvad and recording share the same clock and initialization
procedures require module to be disabled, the busy flag will be set
when having both features enabled.
Signed-off-by: Cosmin-Gabriel Samoila <cosmin.samoila@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
We must find a way to no longer touch resources after they are
cleand up.
Now, after a stress test we get the following crash:
[ 2156.863772] fsl-dsp 596e8000.dsp: xf_pool_alloc failed
[ 2156.869337] Unable to handle kernel NULL pointer dereference at
virtual address 00000060
[ 2157.148594] [<ffff000008d8839c>] _raw_spin_lock+0x14/0x48
[ 2157.153995] [<ffff000008b3e0b8>] xf_cmd_send_recv_complete+0x40/0xf0
[ 2157.160354] [<ffff000008b3e470>] xf_close+0x40/0x88
[ 2157.165239] [<ffff000008b3f7a4>] xaf_comp_delete+0x5c/0x70
[ 2157.170730] [<ffff000008b40530>] dsp_platform_compr_free+0xa0/0xe8
[ 2157.176917] [<ffff000008b287fc>] soc_compr_free_fe+0x144/0x1a0
[ 2157.182754] [<ffff000008b11b24>] snd_compr_free+0x64/0x98
This happens because:
1) dsp_platform_process work handler waits in a loop for
messages to arrive.
2) when cplay process finishes it cleans up most of the
resources.
3) when another cplay process starts it reinitializes the
resources including queues for example.
4) a message will be generated and kernel will crash because
dsp_platform_process uses the older queues.
A solution for this is to make sure dsp_platform_process work loop
is stopped at cleanup time.
We use is_active state and signal dsp_platform_process handler to
finish because we are on the cleanup path.
While at it replace cancel_work with cancel_work sync to be sure
that work handler ends before going on with the rest of the cleanup.
Reviewed-by: Cosmin-Gabriel Samoila <cosmin.samoila@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
The alogrithm ecb(arc4) was registered by the CAAM for all
the platforms however the hardware capability for this algo
is no more present (No CHA).
So we skip its registration.
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
- When OPTEE OS is present and if it support the busfreq
for the running the i.MX, the busfreq is executed in
the OPTEE OS by calling a specific SMC function
- Only a WFE function is copied into the OCRAM to
synchronize all Cores in multi-core devices
- OPTEE OS add a DT property 'busfreq=1' in the 'firmware/optee'
node to indicate the busfreq support
Signed-off-by: Cedric Neveux <cedric.neveux@nxp.com>
According to Hardware test result, when config the usdhc pad io drive
strength to high, there are some overshoot on the clock/data signal
when sd/emmc work at SDR104/HS400/HS200 mode. When change the usdhc
data/cmd/clk pad io strength to low, can't see any overshoot, and
data transfer can also work well and pass the stress test.
So change all the usdhc pad io drive strength to low.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
In order to support 44kHz and 48kHz sample rate together, we need to
reconfigure the parent clock of mclk.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Revert "MLK-17344-2: ARM64: dts: add constraint-rate for hdmi of imx8qm"
This reverts commit 86dbbb61cf.
On imx8qm B0 fix the DPLL jitter issue for HDMI module, so the constraint
for sample rate should be removed
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
There is two methods to select different mode for camera sensor, one
is setting mode by VIDIOC_S_PARM ioctl and the other is automatic
selection through resolution. If resolution match one of camera sensor
supported, driver will select the corresponding mode. If not, driver
will select the max resolution supported by sensor and use ISI to
resize to the target resolution.
This patch is for ov10635 camera sensor
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
(cherry picked from commit 21680ebeebbd2deb0430e0e2df82e3b5ec95c08d)
There is two methods to select different mode for camera sensor, one
is setting mode by VIDIOC_S_PARM ioctl and the other is automatic
selection through resolution. If resolution match one of camera sensor
supported, driver will select the corresponding mode. If not, driver
will select the max resolution supported by sensor and use ISI to
resize to the target resolution.
This patch is for parallel interface of ov5640 sensor
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
(cherry picked from commit 8eb46dab84dd589ba0e6f997e28fa9ff3bbbcd63)
There is two methods to select different mode for camera sensor, one
is setting mode by VIDIOC_S_PARM ioctl and the other is automatic
selection through resolution. If resolution match one of camera sensor
supported, driver will select the corresponding mode. If not, driver
will select the max resolution supported by sensor and use ISI to
resize to the target resolution.
This patch is for mipi interface of ov5640 sensor
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
(cherry picked from commit 4c560890906f7df33e68a65372f60778cb1406b7)
According to V4L2 doc, RGB24 and BGR24 should have three bytes
for each pixel rather than four, so correct it.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
(cherry picked from commit 3694f7ffe2443d86ae740f12393edc007c997a98)
Initialize SCL_IMG_CFG to source image width and height when
scale disabled
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
(cherry picked from commit 506b32bb9ad6a3f596510e401b0e8fa16ca8b659)
Return error code when user try to do upscale since isi don't support.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
(cherry picked from commit 59949e29dcd996c50cae43bc5ff3f89907761c1b)
When ISI channel0 is used to recevice camera data, it can
not be used to mem2mem. So return -EBUSY error code when
user try to use them at the same time.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
(cherry picked from commit c6d5bf866819deaaf4900ae47d575c5a36d30a66)
Power off some resource of ISI can't really hardware reset
ISI, because all eight ISI channels share one hardware reset.
For example, if we enable ISI channel 0 and 1 in dts and only
power off and on channel0 domain, it will not really reset and
the value of channel0 register will not change.
Hardware reset was introduced for fixing ISI can't receive data
from CI_PI after system boot in QXP A0 and this is fixed in new
version QXP B0, so remove HW reset in driver.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
(cherry picked from commit df9da83f82c94ca578303b45c60fb17da2d9d1aa)
Because ISI can't restore to default state after software
reset, the status value of exit will be maintained. If not
cleared, ISI will triggle fake interrupt after enableing irq,
but there is not ready for data.
Signed-off-by: Guoniu.Zhou <guoniu.zhou@nxp.com>
(cherry picked from commit 932af3df1745f5afb0b9433d3355b2e24b177f4e)
Robin Gong