This patch adds a drm bridge driver for i.MX8qm LVDS display bridge(LDB)
which is officially named as pixel mapper. The LDB has two channels.
Each of them supports up to 30bpp parallel input color format and can
map the input to VESA or JEIDA standards. The two channels can be used
simultaneously, either in dual mode or split mode. In dual mode, the
two channels output identical data. In split mode, channel0 outputs
odd pixels and channel1 outputs even pixels. This patch supports the
LDB single mode and split mode.
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # Colibri iMX8X, LT170410-2WHC, LP156WF1
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220611141421.718743-13-victor.liu@nxp.com
This patch adds a drm bridge driver for i.MX8qxp LVDS display bridge(LDB)
which is officially named as pixel mapper. The LDB has two channels.
Each of them supports up to 24bpp parallel input color format and can map
the input to VESA or JEIDA standards. The two channels cannot be used
simultaneously, that is to say, the user should pick one of them to use.
Two LDB channels from two LDB instances can work together in LDB split
mode to support a dual link LVDS display. The channel indexes have to be
different. Channel0 outputs odd pixels and channel1 outputs even pixels.
This patch supports the LDB single mode and split mode.
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # Colibri iMX8X, LT170410-2WHC, LP156WF1
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220611141421.718743-12-victor.liu@nxp.com
This patch adds a drm bridge driver for i.MX8qm/qxp pixel combiner.
The pixel combiner takes two output streams from a single display
controller and manipulates the two streams to support a number
of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured
as either one screen, two screens, or virtual screens. The pixel
combiner is also responsible for generating some of the control signals
for the pixel link output channel. For now, the driver only supports
the bypass mode.
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # Colibri iMX8X, LT170410-2WHC, LP156WF1
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220611141421.718743-5-victor.liu@nxp.com
The user may use the fbcon=vc:<n1>-<n2> option to tell fbcon to take
over the given range (n1...n2) of consoles. The value for n1 and n2
needs to be a positive number and up to (MAX_NR_CONSOLES - 1).
The given values were not fully checked against those boundaries yet.
To fix the issue, convert first_fb_vc and last_fb_vc to unsigned
integers and check them against the upper boundary, and make sure that
first_fb_vc is smaller than last_fb_vc.
Cc: stable@vger.kernel.org # v4.19+
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Helge Deller <deller@gmx.de>
Link: https://patchwork.freedesktop.org/patch/msgid/YpkYRMojilrtZIgM@p100
There is no need to directly skip over to the SCROLL_REDRAW case while
the logo is still shown.
When using DRM, this change has no effect because the code will reach
the SCROLL_REDRAW case immediately anyway.
But if you run an accelerated fbdev driver and have
FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION enabled, console scrolling is
slowed down by factors so that it feels as if you use a 9600 baud
terminal.
So, drop those unnecessary checks and speed up fbdev console
acceleration during bootup.
Cc: stable@vger.kernel.org # v5.10+
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Helge Deller <deller@gmx.de>
Link: https://patchwork.freedesktop.org/patch/msgid/YpkYxk7wsBPx3po+@p100
Since the driver already needs to support multiple sets of ops, we can
drop the mid-layer used by the A83T and H3 PHYs. They share only a small
amount of code; factor this out as sun8i_hdmi_phy_set_polarity.
For clarity, this commit keeps the existing function order.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220615045543.62813-6-samuel@sholland.org
The driver uses crypto hash functions so it needs to select CRYPTO_HASH.
This fixes build errors:
drivers/gpu/drm/bridge/ite-it6505.o: in function `it6505_hdcp_wait_ksv_list':
ite-it6505.c:(.text+0x4c26): undefined reference to `crypto_alloc_shash'
ite-it6505.c:(.text+0x4c6d): undefined reference to `crypto_shash_digest'
ite-it6505.c:(.text+0x4c7d): undefined reference to `crypto_destroy_tfm'
ite-it6505.c:(.text+0x4d69): undefined reference to `crypto_destroy_tfm'
Fixes: b5c84a9edc ("drm/bridge: add it6505 driver")
Signed-off-by: Zheng Bin <zhengbin13@huawei.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/20220613150653.1310029-1-zhengbin13@huawei.com
While parsing the DT, the anx7625 driver checks for the presence of a
panel bridge on endpoint 1. If it is missing, pdata->panel_bridge stores
the error pointer and the function returns successfully without first
cleaning that variable. This is an issue since other functions later
check for the presence of a panel bridge by testing the trueness of that
variable.
In order to ensure proper behavior, zero out pdata->panel_bridge before
returning when no panel bridge is found.
Fixes: 9e82ea0fb1 ("drm/bridge: anx7625: switch to devm_drm_of_get_bridge")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220613163705.1531721-1-nfraprado@collabora.com
This reverts commit fa0e256450. The kernel
test robot reported that attempting to build the vesafb driver fails on
some architectures, because these don't define a `struct screen_info`.
This leads to linking errors, for example on parisc with allyesconfig:
hppa-linux-ld: drivers/video/fbdev/vesafb.o: in function `vesafb_probe':
>> (.text+0x738): undefined reference to `screen_info'
>> hppa-linux-ld: (.text+0x73c): undefined reference to `screen_info'
hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init':
>> (.init.text+0x28): undefined reference to `screen_info'
>> hppa-linux-ld: (.init.text+0x30): undefined reference to `screen_info'
hppa-linux-ld: (.init.text+0x78): undefined reference to `screen_info'
The goal of commit fa0e256450 ("fbdev: vesafb: Allow to be built if
COMPILE_TEST is enabled") was to have more build coverage for the driver
but it wrongly assumed that all architectures would define a screen_info.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20220610085450.1341880-1-javierm@redhat.com
The CTA Data Block Collection is valid only for CTA extension version
3. In versions 1 and 2, it is a reserved block, which we ignore.
The DTD start offset (byte 2, or d in CTA-861 spec), which determines
the CTA Data Block Collection size, is specified slightly differently
for different versions:
Version 1:
d = offset for the byte following the reserved data block. If no
data is provided in the reserved data block, then d=4. If no DTDs
are provided, then d=0
Version 2:
d = offset for the byte following the reserved data block. If no
data is provided in the reserved data block, then d=4. If d=0, then
no detailed timing descriptors are provided, and no data is provided
in the reserved data block.
Version 3:
d = offset for the byte following the data block collection. If no
data is provided in the data block collection, then d=4. If d=0,
then no detailed timing descriptors are provided, and no data is
provided in the data block collection.
Ever since commit 9e50b9d55e ("drm: edid: Add some bounds checking"),
we've interpreted 0 to mean there are no DTDs but it's all Data
Blocks. Per the spec, Data Blocks are only valid for version 3, where we
should interpret 0 to mean there are no data blocks.
Follow the spec (and hope the EDIDs follow it too).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2a4c94417f024cbafc5d4ca0a74e4617fc4325d1.1654674560.git.jani.nikula@intel.com
Currently, the memory to the composition frame is being allocated using
the kzmalloc. This comes with the limitation of maximum size of one
page size(which in the x86_64 is 4Kb and 4MB for default and hugepage
respectively).
Somes test of igt (e.g. kms_plane@pixel-format) uses more than 4MB when
testing some pixel formats like ARGB16161616 and the following error were
showing up when running kms_plane@plane-panning-bottom-right*:
[drm:vkms_composer_worker [vkms]] *ERROR* Cannot allocate memory for
output frame.
This problem is addessed by allocating the memory using kvzalloc that
circunvents this limitation.
V5: Improve the commit message and drop the debugging issues in VKMS
TO-DO(Melissa Wen).
Reviewed-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Igor Torrente <igormtorrente@gmail.com>
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220404204515.42144-2-igormtorrente@gmail.com
Pull x86 platform driver fixes from Hans de Goede:
"Highlights:
- Fix hp-wmi regression on HP Omen laptops introduced in 5.18
- Several hardware-id additions
- A couple of other tiny fixes"
* tag 'platform-drivers-x86-v5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86/intel: hid: Add Surface Go to VGBS allow list
platform/x86: hp-wmi: Use zero insize parameter only when supported
platform/x86: hp-wmi: Resolve WMI query failures on some devices
platform/x86: gigabyte-wmi: Add support for B450M DS3H-CF
platform/x86: gigabyte-wmi: Add Z690M AORUS ELITE AX DDR4 support
platform/x86: barco-p50-gpio: Add check for platform_driver_register
platform/x86/intel: pmc: Support Intel Raptorlake P
platform/x86/intel: Fix pmt_crashlog array reference
platform/mellanox: Add static in struct declaration.
platform/mellanox: Spelling s/platfom/platform/
