The comment blocks at the beginning of each file have a one-line
summary description of the file that includes the file name. While the
description is useful, the file name only creates opportunities for
mistakes (as seen in rcar_du_vsp.c) without any added value. Drop it.
Reported-by: Biju Das <biju.das.jz@bp.renesas.com>
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
When the CMM is enabled, the HDSE offset is further adjusted to
compensate for consumed pixels.
Explain this further, with an extra comment at the point the offset is
adjusted.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
usbnet_write_cmd_async() mixed up which buffers
need to be freed in which error case.
v2: add Fixes tag
v3: fix uninitialized buf pointer
Fixes: 877bd862f3 ("usbnet: introduce usbnet 3 command helpers")
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20220705125351.17309-1-oneukum@suse.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
To avoid preventing the display from coming up before the rootfs is
mounted, without resorting to packing fw in the initrd, the GPU has
this limbo state where the device is probed, but we aren't ready to
start sending commands to it. This is particularly problematic for
a6xx, since the GMU (which requires fw to be loaded) is the one that
is controlling the power/clk/icc votes.
So defer enabling runpm until we are ready to call gpu->hw_init(),
as that is a point where we know we have all the needed fw and are
ready to start sending commands to the coproc's.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/489337/
Link: https://lore.kernel.org/r/20220613182036.2567963-1-robdclark@gmail.com
Change msm_kms_init_aspace() to use generic function
device_iommu_mapped() instead of the fwnode-specific interface
dev_iommu_fwspec_get(). While we are at it, stop referencing
platform_bus_type directly and use the bus of the IOMMU device.
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489703/
Link: https://lore.kernel.org/r/20220616081106.350262-6-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
On Qualcomm platforms the IOMMU can be specified either for the MDP/DPU
device or for its parent MDSS device depending on the actual platform.
Check both of them, since that is how both DPU and MDP5 drivers work.
Co-developed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/489699/
Link: https://lore.kernel.org/r/20220616081106.350262-4-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Both error-capture and relay-logging mechanism use the GuC
log infrastructure. That means the KMD must send a log flush
complete notification back to GuC after reading the data out.
This call is currently being sent synchronously.
However, synchronous H2Gs cause problems when the system is
backed up. There is no need for this to be synchronous. The
KMD wasn't even looking at the return status from it. So make
it asynchronous and then there is no issue about time outs.
Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220607002314.1451656-2-alan.previn.teres.alexis@intel.com
JSP is based on ICP and we don't really need to differentiate
between the two. So let's just delcare JSP to be ICP.
The only slight change here is for Wa_14011294188 which we
used to apply for JSP but now we'll only apply to MCC. This
should be fine since the issue being dealt with was introduced
in TGP and inherited into MCC. JSP being derived from ICP
should not need this workaround.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220630150600.24611-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
This will allow the trace event to know the full size of the data
intended to be copied and silence read overflow checks.
Reported-by: John Garry <john.garry@huawei.com>
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Fixups for OpenRISC found during recent testing:
- An OpenRISC irqchip fix to stop acking level interrupts which was
causing issues on SMP platforms.
- A comment typo fix in our unwinder code.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE2cRzVK74bBA6Je/xw7McLV5mJ+QFAmLFiUMACgkQw7McLV5m
J+RIvRAAg3Aru9TPDSqL5/NS2AF+sJAJLBuG0FXNSvVl5xSKsZZ/cVcFHx2vK0U3
UMoVnmKTuNIFF47HnkOZ6yCseM06OYWzQREyS203zvVqUjjR1tVfz0uX9p9gGxio
wFai3YNBH923dfLE9M2BpGvpKVWbD5zrZlCu+3Br1kfFxZ+B0PQECqZlXhrqIKx0
7IRrV3N/lPfvZY45/cROofQNaGG71Z/DhdHy6XL/CMCeAyRcSJCM5kcWmjPKGefO
ZYjaypid78EQwf0hDGMrP/BmBmErYxIrbUoqKslPhLifYfdK0EaNE7nQqKENu99G
igXNhn5akoBIxczakTTlK69R9DecYsu4gzRfEaqsBwpJXS4Ndq2MdN1cozZTB0Zp
lAkFFXR0EqwxSaF8qF7FhStRj+luT+dl3BKJqwQPYoohNEC4Z8VCm9VZJJpkLt2N
hX+SD/wLUg1Yay7orSdAD/R7M9lypFgV3fpjtjtJcZR5EE70R69Rp6h7cci7XaM+
pe9lMeTRQsqiNq2QZHPFN7RVLMs+pgwEJdUOmXsrEC+arpQCEMnREsnHOeSQxckx
DZf7wMkx2c4VcSRaxmkIKfz6iWnqscOkkBkzrakcPBoBMs5kv1VXRqBlOxwtkt00
m8seJg+n9agg7kynIqARqffEJESTy2RQhjuvQVw3nkKGQvsmays=
=Uug/
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of https://github.com/openrisc/linux
Pull OpenRISC fixes from Stafford Horne:
"Fixups for OpenRISC found during recent testing:
- An OpenRISC irqchip fix to stop acking level interrupts which was
causing issues on SMP platforms
- A comment typo fix in our unwinder code"
* tag 'for-linus' of https://github.com/openrisc/linux:
openrisc: unwinder: Fix grammar issue in comment
irqchip: or1k-pic: Undefine mask_ack for level triggered hardware
This became largish as it includes the pending ASoC fixes.
Almost all changes are device-specific small fixes, while many of
them are coverage for mixer issues that were detected by selftest.
In addition, usual suspects for HD/USB-audio are there.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmLEV6wOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8Z9Q/6AwD3QAU78BQLKVp7I2poW35BGSKkidhBRQkP
hWA4TKh/4itD1xnoKqKVDFZCkB6Had8GduHwCq7IymA6n13Zn27GwnoTOstkbwBF
VyYnMEFA0nXVQTjdgoGPtyphOd3Oqh345/NGzwaaAh3f0IQUr4mqmekxNF/GVff6
QPgQsx0UAVmX31vj0jFxVC/J9QyRT4SHFNtY9m8/OG/t9QbGew/EiSAgtdoVGRK8
tvJq8mqaJBO0RbeYInsND5WjpbuAOPrXQ/XT56/J13YaamK+nxr13cIMXAERzrEn
TR3m2ZZrUp5zidbyZsj9Kck8Cxk6UH6W5QvkENC+3UTHZmg9ovlq9x7RuaeIHBjF
5Q4QR9Aw7L6IEOi0QmDWBhpsShKtB0g2ImTOyUu5Xi9Wo4XLSFXBJ5bCulrBl34X
io3SMZVv3F4uR+7mgm8W8VhOlJlqlUd7cIu84cWBdsPx8FVtNEe+CKFgvdYOMOV4
Pej/dSlUjwELbCB0yP2Vk4OrsBd/Gu1LGh21+ZLKE5i1h/IkNHTyRumVqCN2Dibt
r6jMwPqyCJB6eDg1MRiBZlnnIrb3zytt6Gm7SOoA4aLGY4FkPlOUE+bjFkVANpfp
TR+V2uR0pm3uh2jomSk+sP/3HItf54eyEwollr/aPC8jHn38x1Dm6BLZMvN7MITI
C/syO54=
=v73C
-----END PGP SIGNATURE-----
Merge tag 'sound-5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"This became largish as it includes the pending ASoC fixes.
Almost all changes are device-specific small fixes, while many of them
are coverage for mixer issues that were detected by selftest. In
addition, usual suspects for HD/USB-audio are there"
* tag 'sound-5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (43 commits)
ALSA: cs46xx: Fix missing snd_card_free() call at probe error
ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0)
ALSA: usb-audio: Add quirk for Fiero SC-01
ALSA: hda/realtek: Add quirk for Clevo L140PU
ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices
ASoC: madera: Fix event generation for rate controls
ASoC: madera: Fix event generation for OUT1 demux
ASoC: cs47l15: Fix event generation for low power mux control
ASoC: cs35l41: Add ASP TX3/4 source to register patch
ASoC: dapm: Initialise kcontrol data for mux/demux controls
ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error
ASoC: cs35l41: Correct some control names
ASoC: wm5110: Fix DRE control
ASoC: wm_adsp: Fix event for preloader
MAINTAINERS: update ASoC Qualcomm maintainer email-id
ASoC: rockchip: i2s: switch BCLK to GPIO
ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4 and S5 states
ASoC: SOF: pm: add definitions for S4 and S5 states
ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2
ASoC: SOF: Intel: hda: Fix compressed stream position tracking
...
- Gracefully handle failure to request MMIO resources in the GICv3 driver
- Make a static key static in the Apple AIC driver
- Fix the Xilinx intc driver dependency on OF_ADDRESS
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAmK+9tgPHG1hekBrZXJu
ZWwub3JnAAoJECPQ0LrRPXpDPQUP+wZR+sOzF9lLGtf3fgygJmOmkhWZhDi9t/B/
hrcStY3eHuK1Qnu7Y4oOzskEK2IFH0LKjyo6cDIgPuJi+64pGq827gQsJld0+XDQ
U3iiz24FNzKAHYDy+adQmlG935O0Mzm71hxSso7XQie8AktaCwjFLR4q1H0yeaC4
IZ2rRtEPbJCsqapcyR2I7SkZ0n1BfzIR57lpmxhRZ3iG8PJuhgVH1FX/jvs96jit
N6RcK1mfB8n2vdg6tK9mqHbLmcbWUY+LUcGglh04o+mvth2wjPXv42/0Ci9I4VMs
AkaapWBVvzKs3Aq9vwXX8iW1JScnJdFFgOvVzqkZN17KWOusIThW3uh3KzWjEC3b
lztuSZFoPkGnXXpEYFX1ZHvVrSt+4ChgMPAfpKBbu+WScjm+rR6CTBzTerSdjWkb
Rhai/TqYGj0b93zqiB/qJUEOqwZk/9Hu8Jc5+GzvYWQKG1kwTKDvYqYCKO0uOriW
mLaStAkKdA+p12mzHl7CX4qWfa2Tj1Ekwhb1OO1CLyGIqolH+Bf4F38EAOOO5ECs
A0AiHn5/IGWEf0kn+iFRPrv0+iYhZhLsBhsQkMgcF/F96meXJB1rcuEJr14915GR
765UvzQ4sggw3fY1A0085ccpOa+5Zl9iJa5nFntQ1H1vUwpBEvQTVLM0rukQVlhN
z4mKX0aP
=YqtL
-----END PGP SIGNATURE-----
Merge tag 'irqchip-fixes-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent
Pull irqchip fixes from Marc Zygnier:
- Gracefully handle failure to request MMIO resources in the GICv3 driver
- Make a static key static in the Apple AIC driver
- Fix the Xilinx intc driver dependency on OF_ADDRESS
Link: https://lore.kernel.org/all/20220701133531.1545319-1-maz@kernel.org
The conditional block for variants with a second clock should have set
minItems, not maxItems, which was already 2. Since clock-names requires
two items, this typo should not have caused any problems.
Fixes: edd14218bd ("dt-bindings: dmaengine: Convert Allwinner A31 and A64 DMA to a schema")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220702031903.21703-1-samuel@sholland.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Follow the lead of MDP5 driver and check both DPU and MDSS devices for
the IOMMU specifiers.
Historically DPU devices had IOMMU specified in the MDSS device tree
node, but as some of MDP5 devices are being converted to the supported
by the DPU driver, the driver should adapt and check both devices.
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489696/
Link: https://lore.kernel.org/r/20220616081106.350262-2-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
The restriction to 4G was strictly to work around 64b math bug in some
versions of SQE firmware. This appears to be fixed in a650+ SQE fw, so
allow a larger address space size on these devices.
Also, add a modparam override for debugging and igt.
v2: Send the right version of the patch (ie. the one that actually
compiles)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/487601/
Link: https://lore.kernel.org/r/20220529180428.2577832-1-robdclark@gmail.com
Leading spaces are not something checkpatch likes, and it says so when
they are present. Use tabs consistently to indent function body and
unwrap a 83-char-long line, as 100 is cool nowadays.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/487592/
Link: https://lore.kernel.org/r/20220528160353.157870-4-konrad.dybcio@somainline.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
There are various SKUs of A619, ranging from 565 MHz to 850 MHz, depending
on the bin. Add support for distinguishing them, so that proper frequency
ranges can be applied, depending on the HW.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/487590/
Link: https://lore.kernel.org/r/20220528160353.157870-3-konrad.dybcio@somainline.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device". Unfortunately the current a6xx_gpu_busy() grabs a
reference to the GMU's "struct device".
The fact that we were grabbing the wrong reference was easily seen to
cause crashes that happen if we change the GPU's pm_runtime usage to
not use autosuspend. It's also believed to cause some long tail GPU
crashes even with autosuspend.
We could look at changing it so that we do pm_runtime_get_if_in_use()
on the GPU's "struct device", but then we run into a different
problem. pm_runtime_get_if_in_use() will return 0 for the GPU's
"struct device" the whole time when we're in the "autosuspend
delay". That is, when we drop the last reference to the GPU but we're
waiting a period before actually suspending then we'll think the GPU
is off. One reason that's bad is that if the GPU didn't actually turn
off then the cycle counter doesn't lose state and that throws off all
of our calculations.
Let's change the code to keep track of the suspend state of
devfreq. msm_devfreq_suspend() is always called before we actually
suspend the GPU and msm_devfreq_resume() after we resume it. This
means we can use the suspended state to know if we're powered or not.
NOTE: one might wonder when exactly our status function is called when
devfreq is supposed to be disabled. The stack crawl I captured was:
msm_devfreq_get_dev_status
devfreq_simple_ondemand_func
devfreq_update_target
qos_notifier_call
qos_max_notifier_call
blocking_notifier_call_chain
pm_qos_update_target
freq_qos_apply
apply_constraint
__dev_pm_qos_update_request
dev_pm_qos_update_request
msm_devfreq_idle_work
Fixes: eadf79286a ("drm/msm: Check for powered down HW in the devfreq callbacks")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/489124/
Link: https://lore.kernel.org/r/20220610124639.v4.1.Ie846c5352bc307ee4248d7cab998ab3016b85d06@changeid
Signed-off-by: Rob Clark <robdclark@chromium.org>
If CONFIG_OF is not enabled, default of_get_display_timing() returns an
errno, so include the header.
Fixes: 422b67e0b3 ("videomode: provide dummy inline functions for !CONFIG_OF")
Suggested-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Helge Deller <deller@gmx.de>
Move away from the deprecated enable/disable operations in
drm_bridge_funcs and enable atomic use.
v3:
- Drop use of DRM_BRIDGE_STATE_OPS
v2:
- fix build (kernel test robot <lkp@intel.com>)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220703202724.9553-2-sam@ravnborg.org
Image.dx gets wrong value because of missing '()'.
If xres == logo->width and n == 1, image.dx = -16.
Signed-off-by: Guiling Deng <greens9@163.com>
Fixes: 3d8b1933eb ("fbdev: fbmem: add config option to center the bootup logo")
Cc: stable@vger.kernel.org # v5.0+
Signed-off-by: Helge Deller <deller@gmx.de>
Dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- 4 pixels for one iteration for dp_intf while dpi is 1 pixel for one
iteration.
- Input of dp_intf is two pixels per iteration.
- Some register contents differ slightly between the two components.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220705102530.1344-6-rex-bc.chen@mediatek.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
The quantity of output for one iteration could be different for dpi and
dp_intf. For dp_intf, it's 4 pixels for one iteration it's 1 pixel for one
iteration for dpi. Therefore, we add a new config "pixels_per_iter" to
control quantity of transferred pixels per iteration.
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220705102530.1344-5-rex-bc.chen@mediatek.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
MediaTek dpi supports direct connection to dpi panels while dp_intf does
not support. Therefore, add a config "support_direct_pin" to control this.
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220705102530.1344-3-rex-bc.chen@mediatek.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Dp_intf supports YUV422 as output format. In MT8195 Chrome project,
YUV422 output format is used for 4K resolution.
To support this, it is also needed to support color format transfer.
Color format transfer is a new feature for both dpi and dpintf of MT8195.
The input format could be RGB888 and output format for dp_intf should be
YUV422. Therefore, we add a mtk_dpi_matrix_sel() helper to update the
DPI_MATRIX_SET register depending on the color format.
Signed-off-by: Guillaume Ranquet <granquet@baylibre.com>
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220705102530.1344-2-rex-bc.chen@mediatek.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
When LVDS dual link is used, we have to enable the LDB_CTRL_SPLIT_MODE bit.
Fixes: 463db5c2ed ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge")
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Marek Vasut <marex@denx.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220701065634.4027537-3-victor.liu@nxp.com
Link: https://patchwork.freedesktop.org/patch/msgid/20220701065634.4027537-4-victor.liu@nxp.com
With LVDS dual link, up to 160MHz mode clock rate is supported.
With LVDS single link, up to 80MHz mode clock rate is supported.
Fix mode clock rate validation by swapping the maximum mode clock
rates of the two link modes.
Fixes: 463db5c2ed ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge")
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Marek Vasut <marex@denx.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220701065634.4027537-2-victor.liu@nxp.com
Laurent Pinchart
Kieran Bingham
Oliver Neukum
Rob Clark
Dmitry Baryshkov
Geert Uytterhoeven
Alan Previn
Randy Dunlap
Ville Syrjälä
Keith Busch
Linus Torvalds
Thomas Gleixner
Samuel Holland
Konrad Dybcio
Douglas Anderson
Hsin-Yi Wang
Sam Ravnborg
Guiling Deng
Guillaume Ranquet
Bo-Chen Chen
Liu Ying