To ease review and reuse rename INTF feature masks to contain base DPU
version since which this mask is used.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 8
.../drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h | 8
IRQ masks are rarely shared between different DPU revisions. Inline them
to the dpu_mdss_cfg intances and drop them from the dpu_hw_catalog.c
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 9 ++-
Enable DSPP and DSC hardware blocks on sc8180x platform.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 26 +--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
After fixing scaler version we are sure that sm8450 and sc8280xp vig
sblk's are duplicates of sm8250_vig_sblk and thus can be dropped.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 8
Mark DSPP_2 and DSPP_3 as used for LM_2 and LM_3
Fixes: 100d7ef6995d ("drm/msm/dpu: add support for SM8450")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Theoretically since sm8150 we should be using a single CTL for the
source split case, but since we do not support it for now, fallback to
DPU_CTL_SPLIT_DISPLAY.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 5 +++--
1 file changed, 3
For sm8150+ the DPU_CTL_SPLIT_DISPLAY should be replaced with
DPU_CTL_ACTIVE_CFG support (which supports having a single CTL for both
interfaces in a split). Add comments where this conversion is required.
Signed-off-by: Dmitry Baryshkov
---
Use defined name DEFAULT_DPU_OUTPUT_LINE_WIDTH instead of open coding
the value.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Duplicate sm8250 catalog entries to sc7180 to remove dependencies
between DPU instances.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
Duplicate sm8150 catalog entries to sc8180x to remove dependencies
between DPU instances.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 120 --
1 file changed, 110 insertions(+), 10 deletions(-)
diff --git
Duplicate sm8450 catalog entries to sm8550 to remove dependencies
between DPU instances.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 32 ++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git
Duplicate qcm2290 catalog entries to sm6115 to remove dependencies
between DPU instances.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 50 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 2 +-
2 files changed, 41 insertions(+), 11
Duplicate some of sm8150 catalog entries to remove dependencies between
DPU major generations.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 134 --
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 34 -
Duplicate some of sm8250 catalog entries to remove dependencies between
DPU major generations.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git
Duplicate some of sm8350 catalog entries to remove dependencies between
DPU major generations.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
Duplicate some of sdm845 catalog entries to remove dependencies between
DPU major generations.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 19 +++-
.../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 43 +--
Duplicate some of sc7180 catalog entries to remove dependencies between
DPU major generations.
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 130 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 131 +-
2 files changed, 131 insertions(+), 130 deletions(-)
create mode 100644
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 202 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 207 +-
2 files changed, 203 insertions(+), 206 deletions(-)
create mode 100644
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_5_0_sm8150.h| 193 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 186 +
2 files changed, 194 insertions(+), 185 deletions(-)
create mode 100644
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 147 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 143 +
2 files changed, 148 insertions(+), 142 deletions(-)
create mode 100644
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 188 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 190 +-
2 files changed, 190 insertions(+), 188 deletions(-)
create mode 100644
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h | 115 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 107 +---
2 files changed, 116 insertions(+), 106 deletions(-)
create mode 100644
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h | 107 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 105 +
2 files changed, 108 insertions(+), 104 deletions(-)
create mode 100644
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_7_0_sm8350.h| 174 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 174 +-
2 files changed, 175 insertions(+), 173 deletions(-)
create mode 100644
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_6_3_sm6115.h| 95 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 89 +
2 files changed, 97 insertions(+), 87 deletions(-)
create mode 100644
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 148 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 144 +
2 files changed, 150 insertions(+), 142 deletions(-)
create mode 100644
Reviewed-by: Konrad DYbcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 177 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 180 +-
2 files changed, 179 insertions(+), 178 deletions(-)
create mode 100644
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 194 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 187 +
2 files changed, 195 insertions(+), 186 deletions(-)
create mode 100644
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_8_1_sm8450.h| 202 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 203 +-
2 files changed, 204 insertions(+), 201 deletions(-)
create mode 100644
From: Konrad Dybcio
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x280) otherwise.
Signed-off-by: Konrad Dybcio
[DB: fixed some lengths, split the INTF changes away]
Signed-off-by:
UBWC and highest bank settings differ slightly between different DPU
units of the same generation, while the dpu_caps and dpu_mdp_cfg are
much more stable. To ease configuration reuse move ubwc_swizzle and
highest_bank_bit data to separate structure.
Reviewed-by: Konrad Dybcio
Reviewed-by:
Fix several leftover _pp strutures and mark them as const, making all hw
catalog fit into the rodata section.
Reviewed-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +++---
1 file changed, 3 insertions(+), 3
From: Konrad Dybcio
These blocks are of variable length on different SoCs. Set the
correct values where I was able to retrieve it from downstream
DTs and leave the old defaults (0x1c8) otherwise.
Signed-off-by: Konrad Dybcio
[DB: fixed some of lengths, split the INTF changes away]
DSC hw catalog data is not supposed to be changed, so mark it as const
data.
Reviewed-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 +-
On sm8450 platform the CTL_0 doesn't differ from the rest of CTL blocks,
so switch it to CTL_SC7280_MASK too.
Some background: original commit 100d7ef6995d ("drm/msm/dpu: add support
for SM8450") had all (relevant at that time) bit spelled individually.
Then commit 0e91bcbb0016 ("drm/msm/dpu: Add
This huge series attempts to restructure the DPU HW catalog into a
manageable and reviewable data set. In order to ease review and testing
I merged all the necessary fixes into this series. Also I cherry-picked
& slightly fixed Konrad's patch adding size to the SSPP and INTF macros.
First 6
Hi, Christian,
On 4/4/23 11:09, Christian König wrote:
Am 04.04.23 um 02:22 schrieb Matthew Brost:
From: Thomas Hellström
For long-running workloads, drivers either need to open-code completion
waits, invent their own synchronization primitives or internally use
dma-fences that do not obey
The Cadence Sierra PLL clock implements a mux with a set_parent hook,
but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
The Tegra sor pad clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The Mediatek cpumux clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The Versatile sp810 "timerclken" clock implements a mux with a
set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent
The UX500 sysctrl "set_parent" clocks implement a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change
The UX500 PRCMU "clkout" clock implements a mux with a set_parent hook,
but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
The Tegra periph nodiv clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
The Tegra super mux clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The Tegra BPMP mux clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The STM32 mux clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The SoCFGPA gate clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The Renesas r9a06g032 bitselect clock implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent
The PXA "CKEN" clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The iMX SCU mux clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The iMX fixup mux clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
There's a few reasons the kernel should not spam dmesg on bad
userspace ioctl input:
- at warning level it results in CI false positives
- it allows userspace to drown dmesg output, potentially hiding real
issues.
None of the other generic EINVAL checks report in the
FBIOPUT_VSCREENINFO ioctl
The iMX busy clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The Davinci DA8xxx cfgchip "clk48" clock implements a mux with a
set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent
The Davinci DA8xxx cfgchip mux clock implements a mux with a set_parent
hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change
The WM381x "clkout" clock implements a mux with a set_parent hook,
but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The Versaclock5 "clkout" clock implements a mux with a set_parent hook,
but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
The Versaclock5 mux clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
The STM32F4 mux clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The SI5341 clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The Qoriq mux clocks implement a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The lochnagar clocks implement a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The LKM04832 "CLKOUT" clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a
The K210 mux clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The K210 ACLK clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
From: Thierry Reding
On Wed, 1 Mar 2023 15:51:06 +0200, Mikko Perttunen wrote:
> From: Mikko Perttunen
>
> dma_fence_wait_timeout (along with a host of other jiffies-based
> timeouting functions) returns zero both in case of timeout and when
> the wait completes during the last jiffy before
From: Thierry Reding
On Mon, 28 Nov 2022 16:28:49 +, Diogo Ivo wrote:
> In cases where the DSI module is left on by the bootloader
> some panels may fail to initialize if the enable register is not cleared
> before the panel's initialization sequence is sent, so clear it if that
> is the
From: Thierry Reding
On Fri, 17 Sep 2021 10:07:41 +0800, Cai Huoqing wrote:
> When possible use dev_err_probe help to properly deal with the
> PROBE_DEFER error, the benefit is that DEFER issue will be logged
> in the devices_deferred debugfs file.
> And using dev_err_probe() can reduce code
From: Thierry Reding
On Wed, 22 Mar 2023 18:02:11 +0100, Uwe Kleine-König wrote:
> this series adapts the platform drivers below drivers/gpu/drm/tegra to
> use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing
From: Thierry Reding
On Fri, 17 Mar 2023 08:16:50 +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/tegra/dc.c: In function
> ‘tegra_crtc_calculate_memory_bandwidth’:
> drivers/gpu/drm/tegra/dc.c:2384:38: warning: variable ‘old_state’ set but
>
From: Thierry Reding
On Wed, 22 Mar 2023 11:39:15 +0100, Christian König wrote:
> This compile tests on x86 just perfectly fine.
>
> v2: fix missing include complained by kernel test robot
>
>
Applied, thanks!
[1/1] drm/tegra: allow compile test on !ARM v2
commit:
From: Thierry Reding
On Thu, 16 Sep 2021 15:37:21 +0800, Cai Huoqing wrote:
> Return dev_err_probe() directly, because the return value of
> dev_err_probe() is the appropriate error code, and it can
> reduce code size, simplify the code.
>
>
Applied, thanks!
[1/1] drm/tegra: plane: Improve
From: Thierry Reding
On Thu, 16 Sep 2021 18:56:40 +0800, Cai Huoqing wrote:
> When possible use dev_err_probe help to properly deal with the
> PROBE_DEFER error, the benefit is that DEFER issue will be logged
> in the devices_deferred debugfs file.
> And using dev_err_probe() can reduce code
From: Thierry Reding
Mikko has been involved as the primary author of the host1x driver and
has volunteered to help out with maintenance.
Signed-off-by: Thierry Reding
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
Samuel Čavoj writes:
Hello Samuel,
> On 2023-03-20 13:12, Javier Martinez Canillas wrote:
>> Samuel Čavoj writes:
>>
>> [...]
>>
>> This call to sysfb_disable() has been causing trouble with regard
>> to
>> VFIO. VFIO has been calling aperture_remove_conflicting_pci_devices
On Tue, Apr 04, 2023 at 01:36:52AM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Include the device and connector information in the SCDC
> debugs. Makes it easier to figure out who did what.
>
> v2: Rely on connector->ddc (Maxime)
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc:
On 4/4/23 05:11, Laurent Pinchart wrote:
Hi Marek,
Hi,
Thank you for the patch.
On Mon, Apr 03, 2023 at 09:02:42PM +0200, Marek Vasut wrote:
Do not generate the HS front and back porch gaps, the HSA gap and
EOT packet, as per "SN65DSI83 datasheet SLLSEC1I - SEPTEMBER 2012
- REVISED OCTOBER
On 4/4/23 04:30, Fabio Estevam wrote:
From: Jagan Teki
Samsung MIPI DSIM bridge can be found on Exynos and NXP's
i.MX8M Mini/Nano/Plus SoCs.
Convert exynos_dsim.txt to yaml.
Used the example node from exynos5433.dtsi instead of the one used in
the legacy exynos_dsim.txt.
Signed-off-by:
Hi
Am 03.04.23 um 17:07 schrieb Emil Velikov:
On Mon, 3 Apr 2023 at 15:50, Thomas Zimmermann wrote:
Hi
Am 03.04.23 um 16:27 schrieb Emil Velikov:
On Mon, 3 Apr 2023 at 11:41, Thomas Zimmermann wrote:
Move code from ad-hoc fbdev callbacks into DRM client functions
and remove the old
Hi
Am 04.04.23 um 12:55 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
Sorry, I just applied this patch and didn't see your email before...
Hi
Am 04.04.23 um 06:01 schrieb Sui Jingfeng:
EFI FB, VESA FB or VGA FB etc are belong to firmware based framebuffer
Javier Martinez Canillas writes:
[...]
>>> /*
>>> * Remove the device from the device hierarchy. This is the right thing
>>> -* to do for firmware-based DRM drivers, such as EFI, VESA or VGA. After
>>> +* to do for firmware-based fb drivers, such as EFI, VESA or VGA. After
>>
Thomas Zimmermann writes:
Hello Thomas,
Sorry, I just applied this patch and didn't see your email before...
> Hi
>
> Am 04.04.23 um 06:01 schrieb Sui Jingfeng:
>> EFI FB, VESA FB or VGA FB etc are belong to firmware based framebuffer
>> driver.
>
> No whitespaces at the beginning of the
Javier Martinez Canillas writes:
> Sui Jingfeng writes:
>
>> EFI FB, VESA FB or VGA FB etc are belong to firmware based framebuffer
>> driver.
>>
>> Signed-off-by: Sui Jingfeng
>> ---
>
> Reviewed-by: Javier Martinez Canillas
>
Pushed to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Move the register write to MTK_DP_AUX_P0_3690 to set the AUX reply mode
to function mtk_dp_initialize_aux_settings(), as this is effectively
part of the DPTX AUX setup sequence.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dp.c | 9 +
1 file changed, 5
For the eDP case we can support using aux-bus on MediaTek DP: this
gives us the possibility to declare our panel as generic "panel-edp"
which will automatically configure the timings and available modes
via the EDID that we read from it.
To do this, move the panel parsing at the end of the probe
In preparation for implementing support for aux-bus in this driver,
add a IRQ_NOAUTOEN flag to the event interrupt that we request at
probe time and manage the enablement of the ISR at bridge_attach
and detach time.
When aux-bus will be implemented, enabling the interrupt before
attaching the
Change logging from drm_{err,info}() to dev_{err,info}() in functions
mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be
essential to avoid getting NULL pointer kernel panics if any kind
of error happens during AUX transfers happening before the bridge
is attached.
This may
eDP panels are not removable: at PM resume, the cable will obviously
still be plugged in.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
In preparation for adding support for aux-bus, which will add a code
path that may fail after the drm_bridge_add() call, change that to
devm_drm_bridge_add() to simplify failure paths later.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dp.c | 2 +-
1 file changed,
If this is an eDP panel it's not removable, hence it's always connected:
as a shortcut, always return connector_status_connected in the .detect()
callback for eDP connector, avoiding a poweron, a check for sink count
and a poweroff.
Signed-off-by: AngeloGioacchino Del Regno
---
Everytime we run bridge detection and/or EDID read we run a poweron
and poweroff sequence for both the AUX and the panel; moreover, this
is also done when enabling the bridge in the .atomic_enable() callback.
Move this power on/off sequence to a new mtk_dp_aux_panel_poweron()
function as to
Changes in v3:
- Added DPTX AUX block initialization before trying to communicate
to stop relying on the bootloader keeping it initialized before
booting Linux.
- Fixed commit description for patch [09/09] and removed commented
out code (that slipped from dev phase.. sorry!).
This
Since eDP panels are not removable it is safe to cache the EDID:
this will avoid a relatively long read transaction at every PM
resume that is unnecessary only in the "special" case of eDP,
hence speeding it up a little, as from now on, as resume operation,
we will perform only link training.
Hi,
On 03/04/2023 20:40, Joshua Ashton wrote:
Hello all!
I would like to propose a new API for allowing processes to control
the priority of GPU queues similar to RLIMIT_NICE/RLIMIT_RTPRIO.
The main reason for this is for compositors such as Gamescope and
SteamVR vrcompositor to be able to
Hi
Am 04.04.23 um 06:01 schrieb Sui Jingfeng:
EFI FB, VESA FB or VGA FB etc are belong to firmware based framebuffer
driver.
No whitespaces at the beginning of the lines.
Signed-off-by: Sui Jingfeng
---
drivers/video/aperture.c | 8
1 file changed, 4 insertions(+), 4
On Fri, Mar 24, 2023 at 7:37 PM Christian König
wrote:
>
> Yeah, that one
>
> Thanks for the info, looks like this isn't fixed.
>
> Christian.
>
Hi,
glad to see that "BUG: KASAN: slab-use-after-free in
drm_sched_get_cleanup_job+0x47b/0x5c0" was fixed in 6.3-rc5.
For history it would be good to
The K210 PLL clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call to
The cdce706 "clkin" clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies,
change the parent of a clock. However, the most likely candidate to
trigger that parent change is a call
201 - 300 of 341 matches
Mail list logo
