We're moving all uses of ddc_bus to drm_connector where they belong.
The initialization of the gma_i2c_chan for Oaktrail is a bit backwards
so it required improvements. Also cleanup the error handling in
oaktrail_lvds_init(). Since this is the last user of
gma_encoder->ddc_bus we can remove it.
Signed-off-by: Patrik Jakobsson <[email protected]>
Acked-by: Thomas Zimmermann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The kernel test robot reports a compile warning due the ssd130x_spi_table
variable being defined but not used. This happen when ssd130x-spi driver
is built-in instead of being built as a module, i.e:
CC drivers/gpu/drm/solomon/ssd130x-spi.o
AR drivers/base/firmware_loader/built-in.a
AR drivers/base/built-in.a
CC kernel/trace/trace.o
drivers/gpu/drm/solomon/ssd130x-spi.c:155:35: warning: ‘ssd130x_spi_table’ defined but not used [-Wunused-const-variable=]
155 | static const struct spi_device_id ssd130x_spi_table[] = {
| ^~~~~~~~~~~~~~~~~
The driver shouldn't need a SPI device ID table and only have an OF device
ID table, but the former is needed to workaround an issue in the SPI core.
This always reports a MODALIAS of the form "spi:<device>" even for devices
registered through Device Trees.
But the table is only needed when the driver built as a module to populate
the .ko alias info. It's not needed when the driver is built-in the kernel.
Fixes: 74373977d2 ("drm/solomon: Add SSD130x OLED displays SPI support")
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
There were two different approaches getting used in this driver to
allocate vram:
1. VRAM allocation from PCI region for Gen1
2. VRAM alloaction from MMIO region for Gen2
First approach limilts the vram to PCI BAR size, which is 64 MB in most
legacy systems. This limits the maximum resolution to be restricted to
64 MB size, and with recent conclusion on fbdev issue its concluded to have
similar allocation strategy for both Gen1 and Gen2. This patch unifies
the Gen1 and Gen2 vram allocation strategy.
Signed-off-by: Saurabh Sengar <[email protected]>
Reviewed-by: Deepak Rawat <[email protected]>
Signed-off-by: Deepak Rawat <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Introduce a dma_fence_unwrap_merge() macro which allows to unwrap fences
which potentially can be containers as well and then merge them back
together into a flat dma_fence_array.
v2: rename the function, add some more comments about how the wrapper is
used, move filtering of signaled fences into the unwrap iterator,
add complex selftest which covers more cases.
v3: fix signaled fence filtering once more
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
In __spi_validate, there's a validation that no partial transfers
are accepted (xfer->len % w_size must be zero). When
max_chunk is not a multiple of bpw (e.g. max_chunk = 65535,
bpw = 16), the transfer will be rejected.
This patch aligns max_chunk to 2 bytes (the maximum value of bpw is 16),
so that no partial transfer will occur.
Fixes: d23d4d4dac ("drm/tinydrm: Move tinydrm_spi_transfer()")
Signed-off-by: Yunhao Tian <[email protected]>
Signed-off-by: Noralf Trønnes <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Add the features, issues, and GPU ID for Mali-G57, a first-generation
Valhall GPU. Other first- and second-generation Valhall GPUs should be
similar.
v2: Split out issue list for r0p0 from newer Natt GPUs, as TTRX_3485 was
fixed in r0p1. Unfortunately, MT8192 has a r0p0, so we do need to handle
TTRX_3485.
Reviewed-by: Steven Price <[email protected]>
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
L2_MMU_CONFIG is an implementation-defined register. Different Mali GPUs
define slightly different MAX_READS and MAX_WRITES fields, which
throttle outstanding reads and writes when set to non-zero values. When
left as zero, reads and writes are not throttled.
Both kbase and panfrost always zero these registers. Per discussion with
Steven Price, there are two reasons these quirks may be used:
1. Simulating slower memory subsystems. This use case is only of
interest to system-on-chip designers; it is not relevant to mainline.
2. Working around broken memory subsystems. Hopefully we never see this
case in mainline. If we do, we'll need to set this register based on
an SoC-compatible, rather than generally matching on the GPU model.
To the best of our knowledge, these fields are zero at reset, so the
write is not necessary. Let's remove the write to aid porting to new
Mali GPUs, which have different layouts for the L2_MMU_CONFIG register.
Suggested-by: Steven Price <[email protected]>
Reviewed-by: Steven Price <[email protected]>
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Add the HW_FEATURE_CLEAN_ONLY_SAFE bit based on kbase. When I actually
tried to port the logic from kbase, trivial jobs raised Data Invalid
Faults, so this may depend on other coherency details. It's still useful
to have the bit to record the feature bit when adding new models.
Reviewed-by: Steven Price <[email protected]>
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
TTRX_3485 requires the infamous "dummy job" workaround. I have this
workaround implemented in a local branch, but I have not yet hit a case
that requires it so I cannot test whether the implementation is correct.
In the mean time, add the quirk bit so we can document which platforms
may need it in the future.
Reviewed-by: Steven Price <[email protected]>
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
From the kernel's perspective, (pre-CSF, "Job Manager") Valhall is more
or less compatible with Bifrost, although they differ to userspace. Add
a compatible for Valhall to the existing Bifrost bindings documentation.
As the first SoC with a Valhall GPU receiving mainline support, add a
specific compatible for the MediaTek MT8192, which instantiates a
Mali-G57.
v2: Change compatible to arm,mali-valhall-jm (Daniel Stone).
CC: [email protected]
Reviewed-by: Rob Herring <[email protected]>
Reviewed-by: Steven Price <[email protected]>
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The code from [1] sets SYS_CTRL_1 to different values depending on the
desired clock phase (0, 1/4, 1/2 or 3/4). A clock phase of 0 aligns the
positive edge of the clock with the pixel data while other values delay
the clock by a fraction of the clock period. A clock phase of 1/2 aligns
the negative edge of the clock with the pixel data.
The driver currently hard codes SYS_CTRL_1 to 0x88 which corresponds to
aligning the positive edge of the clock with the pixel data. This won't
work correctly for panels that require aligning the negative edge of the
clock with the pixel data.
Adjust the clock phase to 0 if DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE is
present in bus_flags, otherwise adjust the clock phase to 1/2 as
appropriate for DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE.
[1] https://github.com/tdjastrzebski/ICN6211-Configurator
Signed-off-by: Jonathan Liu <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
ADV7511_REG_CEC_RX_FRAME_HDR[] and ADV7511_REG_CEC_RX_FRAME_LEN[]
are only used inside adv7511_cec.c.
Move their definitions to this file to avoid the following build
warnings when CONFIG_DRM_I2C_ADV7511_CEC is not selected:
drivers/gpu/drm/bridge/adv7511/adv7511.h:229:17: warning: 'ADV7511_REG_CEC_RX_FRAME_HDR' defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/bridge/adv7511/adv7511.h:235:17: warning: 'ADV7511_REG_CEC_RX_FRAME_LEN' defined but not used [-Wunused-const-variable=]
Reported-by: kernel test robot <[email protected]>
Fixes: ab0af093bf ("drm: bridge: adv7511: use non-legacy mode for CEC RX")
Signed-off-by: Fabio Estevam <[email protected]>
Reviewed-by: Alvin Šipraga <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
If CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20=y && CONFIG_DRM_DISPLAY_HELPER=m,
bulding fails:
drivers/gpu/drm/panel/panel-samsung-atna33xc20.o: In function `atana33xc20_probe':
panel-samsung-atna33xc20.c:(.text+0x744): undefined reference to
`drm_panel_dp_aux_backlight'
make: *** [vmlinux] Error 1
Let CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20 select DRM_DISPLAY_DP_HELPER and
CONFIG_DRM_DISPLAY_HELPER to fix this error.
Fixes: 32ce3b3203 ("drm/panel: atna33xc20: Introduce the Samsung ATNA33XC20 panel")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Gao Chao <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
This reverts commit 7328736d27.
This patch depends on the patches just aplied to the media tree, and will
not build without them, which leaves drm-misc-next in a broken state.
Let's revert the two latter patches until rc1 has been branched,
and rc1 has been backmerged into drm-misc-next.
Signed-off-by: Robert Foss <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
This reverts commit a77c2af099.
This patch depends on the patches just aplied to the media tree, and will
not build without them, which leaves drm-misc-next in a broken state.
Let's revert the two latter patches until rc1 has been branched,
and rc1 has been backmerged into drm-misc-next.
Signed-off-by: Robert Foss <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The SPI core always reports a "MODALIAS=spi:<foo>", even if the device was
registered via OF. This means that the st7735r.ko module won't autoload if
a DT has a node with a compatible "okaya,rh128128t" string.
In that case, kmod expects a "MODALIAS=of:N*T*Cokaya,rh128128t" uevent but
instead will get a "MODALIAS=spi:rh128128t", which is not present in the
list of aliases:
$ modinfo drivers/gpu/drm/tiny/st7735r.ko | grep alias
alias: of:N*T*Cokaya,rh128128tC*
alias: of:N*T*Cokaya,rh128128t
alias: of:N*T*Cjianda,jd-t18003-t01C*
alias: of:N*T*Cjianda,jd-t18003-t01
alias: spi:jd-t18003-t01
To workaround this issue, add in the SPI table an entry for that device.
Fixes: d1d511d516 ("drm: tiny: st7735r: Add support for Okaya RH128128T")
Signed-off-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Acked-by: David Lechner <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
In commit 19cf41b64e ("lontium-lt9611: check a different
register bit for HDMI sensing"), the bit flag used to detect
HDMI cable connect was switched from BIT(2) to BIT(0) to improve
compatibility with some monitors that didn't seem to set BIT(2).
However, with that change, I've seen occasional issues where the
detection failed, because BIT(2) was set, but not BIT(0).
Unfortunately, as I understand it, the bits and their function
was never clearly documented. So lets instead check both
(BIT(2) | BIT(0)) when checking the register.
Cc: Yongqin Liu <[email protected]>
Cc: Amit Pundir <[email protected]>
Cc: Peter Collingbourne <[email protected]>
Cc: Vinod Koul <[email protected]>
Cc: Bjorn Andersson <[email protected]>
Cc: Robert Foss <[email protected]>
Cc: [email protected]
Fixes: 19cf41b64e ("lontium-lt9611: check a different register bit for HDMI sensing")
Signed-off-by: John Stultz <[email protected]>
Reviewed-by: Robert Foss <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Patrik Jakobsson