-Original Message-
From: Intel-xe On Behalf Of Thomas
Zimmermann
Sent: Tuesday, October 8, 2024 4:59 AM
To: sim...@ffwll.ch; airl...@gmail.com; javi...@redhat.com; jfale...@redhat.com
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
intel-...@lists.freedesktop.org; int
-Original Message-
From: Intel-xe On Behalf Of Thomas
Zimmermann
Sent: Tuesday, October 8, 2024 4:59 AM
To: sim...@ffwll.ch; airl...@gmail.com; javi...@redhat.com; jfale...@redhat.com
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
intel-...@lists.freedesktop.org; int
-Original Message-
From: Intel-gfx On Behalf Of Thomas
Zimmermann
Sent: Tuesday, October 8, 2024 5:00 AM
To: sim...@ffwll.ch; airl...@gmail.com; javi...@redhat.com; jfale...@redhat.com
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
intel-...@lists.freedesktop.org; in
-Original Message-
From: Intel-xe On Behalf Of Thomas
Zimmermann
Sent: Tuesday, October 8, 2024 5:00 AM
To: sim...@ffwll.ch; airl...@gmail.com; javi...@redhat.com; jfale...@redhat.com
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
intel-...@lists.freedesktop.org; int
On Tue, Oct 8, 2024 at 9:30 AM Aleksandrs Vinarskis
wrote:
>
> Introduce low-res IPS and OLED panels for mentioned device.
>
> SHP panel's timings were picked experimentally, without this patch or with
> `delay_200_500_e50` panel sometimes fails to boot/stays black on startup.
>
> LGD panel's timi
The `if (!snapshot->copy)` evaluates to True only when `snapshot->copy`
is Null. Thus, derefrencing `snapshot->copy` inside this if block is
equivalent to Null pointer derefrencing.
The `if` condition is now changed to evaluate to true only when
`snapshot->copy` is not Null.
This issue was reported
-Original Message-
From: Intel-xe On Behalf Of Thomas
Zimmermann
Sent: Tuesday, October 8, 2024 4:59 AM
To: sim...@ffwll.ch; airl...@gmail.com; javi...@redhat.com; jfale...@redhat.com
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
intel-...@lists.freedesktop.org; int
On 10/8/24 12:07 PM, Isaac Scott wrote:
On Mon, 2024-10-07 at 20:06 +0200, Marek Vasut wrote:
On 10/7/24 7:01 PM, Isaac Scott wrote:
Hi Marek,
Hi,
On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
On 6/24/24 11:19 AM, Alexander Stein wrote:
Am Freitag, 31. Mai 2024, 22:27:21 CEST schr
On Fri, Sep 27, 2024, at 7:06 PM, Mario Limonciello wrote:
> From: Mario Limonciello
>
> Some manufacturers have intentionally put an EDID that differs from
> the EDID on the internal panel on laptops.
>
> Attempt to fetch this EDID if it exists and prefer it over the EDID
> that is provided by th
Hi,
On Tue, Oct 8, 2024 at 12:30 AM Aleksandrs Vinarskis
wrote:
>
> Introduce low-res IPS and OLED panels for mentioned device.
>
> SHP panel's timings were picked experimentally, without this patch or with
> `delay_200_500_e50` panel sometimes fails to boot/stays black on startup.
>
> LGD panel'
Hi,
On Mon, Oct 07, 2024 at 06:10:47PM GMT, Louis Chauvet wrote:
> From: Arthur Grillo
>
> Create KUnit tests to test the conversion between YUV and RGB. Test each
> conversion and range combination with some common colors.
>
> The code used to compute the expected result can be found in commen
…
> Note that ignore pixel alpha bit is not supported if the SoC is not
> supported the blend_modes.
supporting the blending modes?
> So it will break the original setting of XRGB foramt for the
format?
> Signed-off-by: Jason-JH.Lin
Hi,
On 01/10/2024 09:37, neil.armstr...@linaro.org wrote:
Hi,
On 30/09/2024 21:19, Jessica Zhang wrote:
On 9/30/2024 7:17 AM, neil.armstr...@linaro.org wrote:
On 25/09/2024 00:59, Jessica Zhang wrote:
When running igt-test on QRD8650, I get:
# IGT_FRAME_DUMP_PATH=$PWD FRAME_PNG_FILE_N
…
> Fix the SoC degradation problem by this sreies.
series?
Regards,
Markus
Il 08/10/24 09:41, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Mon, 2024-10-07 at 11:31 +0200, AngeloGioacchino Del Regno wrote:
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configurati
Reviewed-by: Jacek Lawrynowicz
On 10/4/2024 6:40 PM, Jeffrey Hugo wrote:
> The ipc_router channel allows AF_QIPCRTR clients and services to
> communicate with the AIC100 device. The ipc_router MHI transport layer
> expects the channel to be named exactly "IPCR".
>
> Reviewed-by: Carl Vanderlip
Am 03.10.24 um 14:43 schrieb Pierre-Eric Pelloux-Prayer:
This will allow to use flexible array to store the process name and
other information.
This also means that process name will be determined once and for all,
instead of at each submit.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
driv
Am 03.10.24 um 14:43 schrieb Pierre-Eric Pelloux-Prayer:
And rename it process_desc, since it will soon contain more than
just the process_name.
Signed-off-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
drivers/g
On Mon, 2024-10-07 at 22:09 +0100, Maciej W. Rozycki wrote:
> On Mon, 7 Oct 2024, Niklas Schnelle wrote:
>
> > diff --git a/drivers/tty/serial/8250/8250_pci.c
> > b/drivers/tty/serial/8250/8250_pci.c
> > index
> > 6709b6a5f3011db38acc58dc7223158fe4fcf72e..6a638feb44e443a1998980dd037748f227ec1bc8
On 9/10/24 13:19, Tomi Valkeinen wrote:
Add the two DMA channels used for the DisplayPort audio to the
zynqmp_dpsub node.
Signed-off-by: Tomi Valkeinen
---
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts
On Tue, Oct 08, 2024 at 10:00:57AM GMT, Neil Armstrong wrote:
> Hi,
>
> On 01/10/2024 09:37, neil.armstr...@linaro.org wrote:
> > Hi,
> >
> > On 30/09/2024 21:19, Jessica Zhang wrote:
> > >
> > >
> > > On 9/30/2024 7:17 AM, neil.armstr...@linaro.org wrote:
> > > > On 25/09/2024 00:59, Jessica Z
…
> pre-multiplied is supported in the current platform.
…
format would be?
Regards,
Markus
Am 03.10.24 um 14:43 schrieb Pierre-Eric Pelloux-Prayer:
If a drm_file name is set append it to the process name.
This information is useful with the virtio/native-context driver: this
allows the guest applications identifier to visible in amdgpu's output.
The output in amdgpu_vm_info/amdgpu_ge
Hi guys,
I've pushed the first two patches to drm-misc-next.
@Alex any objections to merge the amdgpu changes through drm-misc-next
as well?
Thanks,
Christian.
Am 03.10.24 um 14:43 schrieb Pierre-Eric Pelloux-Prayer:
v5 of this series which is adding a new ioctl to let userspace associate
a
Some SoCs do not support the ignore_pixl_alpha flag, which breaks the
XRGB format. Some SoCs do not support pre-multiplied pixel formats
and extending configuration of OVL pre-multiplied color formats,
such as MT8173.
Fix the SoC degradation problem by this series.
Tested-by: Chen-Yu Tsai
--
Refine the comment for ignore_pixel_alpha flag and move it to
if(state->fb) statement to make it less conditional.
Signed-off-by: Jason-JH.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +-
1 file changed, 9 inse
Since some SoCs support premultiplied pixel formats but some do not,
the blend_modes parameter is added to mtk_plane_init(), which is
obtained from the mtk_ddp_comp_get_blend_modes function implemented
in different blending supported components.
The blending supported components can use driver dat
OVL_CON_CLRFMT_MAN is a configuration for extending color format
settings of DISP_REG_OVL_CON(n).
It will change some of the original color format settings.
Take the settings of (3 << 12) for example.
- If OVL_CON_CLRFMT_MAN = 0 means OVL_CON_CLRFMT_RGBA.
- If OVL_CON_CLRFMT_MAN = 1 means OVL_
Since we changed MACROs to be consistent with DRM input color format
naming, the comment for ovl_fmt_conver() is no longer needed.
Fixes: 9f428b95ac89 ("drm/mediatek: Add new color format MACROs in OVL")
Signed-off-by: Jason-JH.Lin
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c
OVL_CON_AEN is for alpha blending enable.
For the SoC that is supported the blend_modes, OVL_CON_AEN will always
enabled to use constant alpha and then use the ignore_pixel_alpha bit
to do the alpha blending for XRGB format.
Note that ignore pixel alpha bit is not supported if the SoC is not
su
In the mtk_dsi driver, its DSI host attach callback calls
devm_drm_of_get_bridge() to get the next bridge. If that next bridge is
a panel bridge, a panel_bridge object is allocated and managed by the
panel device.
Later, if the attach callback fails with -EPROBE_DEFER from subsequent
component_add
Op 03-10-2024 om 18:12 schreef Antonino Maniscalco:
Add trace points corresponding to preemption being triggered and being
completed for latency measurement purposes.
Reviewed-by: Akhil P Oommen
Tested-by: Rob Clark
Tested-by: Neil Armstrong # on SM8650-QRD
Tested-by: Neil Armstrong # on SM8
-Original Message-
From: Intel-xe On Behalf Of Thomas
Zimmermann
Sent: Tuesday, October 8, 2024 4:59 AM
To: sim...@ffwll.ch; airl...@gmail.com; javi...@redhat.com; jfale...@redhat.com
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
intel-...@lists.freedesktop.org; int
Convert device tree binding doc zii,rave-sp-eeprom.txt to yaml format.
Additional changes:
- Add ref to nvme.yaml.
- Add reg property.
- Remove mfd at example.
Signed-off-by: Frank Li
---
.../bindings/nvmem/zii,rave-sp-eeprom.txt | 40
.../bindings/nvmem/zii,rave-sp-eep
Convert device binding doc zii,rave-sp-wdt.txt to yaml format.
Additional changes:
- Ref to watchdog.yaml.
- Remove mfd node in example.
- Remove eeprom part in example.
Signed-off-by: Frank Li
---
.../bindings/watchdog/zii,rave-sp-wdt.txt | 39 --
.../bindings/watchdog/
Convert device binding doc zii,rave-sp.txt to yaml format.
Additional change:
- ref to other zii yaml files.
- remove rave-sp-hwmon and rave-sp-leds.
Signed-off-by: Frank Li
---
.../devicetree/bindings/mfd/zii,rave-sp.txt| 39 --
.../devicetree/bindings/mfd/zii,rave-sp.yaml
Greetings!
On kernel v6.12-rc I get no X and dmesg (via netconsole) shows this at loading
radeon drm:
[...]
[drm] PCIE GART of 512M enabled (table at 0x0004).
radeon :01:00.0: WB enabled
radeon :01:00.0: fence driver on ring 0 use gpu addr 0x0800
radeon :01:00
.../bindings/watchdog/zii,rave-sp-wdt.yaml | 47
10 files changed, 236 insertions(+), 163 deletions(-)
---
base-commit: ba5c58f259ba6a60856db98052e0c79729acfe99
change-id: 20241008-zii_yaml-7b4802029873
Best regards,
---
Frank Li
Convert device tree binding doc zii,rave-sp-pwrbutton.txt to yaml format.
Additional changes:
- add ref to input.yaml.
- remove mfd node in example.
Signed-off-by: Frank Li
---
.../bindings/input/zii,rave-sp-pwrbutton.txt | 22 -
.../bindings/input/zii,rave-sp-pwrbutton.yaml
Convert device tree binding doc zii,rave-sp-backlight.txt to yaml format.
Additional Changes:
- Remove mfd parent node at example.
- Ref to backlight's common.yaml
Signed-off-by: Frank Li
---
.../leds/backlight/zii,rave-sp-backlight.txt | 23 --
.../leds/backlight/zii,rave-sp-b
Hi Dave,
On 10/8/24 13:44, Dave Stevenson wrote:
Commit 24c5ed3ddf27 ("drm/vc4: Introduce generation number enum")
incorrectly swapped a check of hvs->vc4->is_vc5 to
hvs->vc4->gen == VC4_GEN_4 in vc4_hvs_lut_load, hence breaking
loading the gamma look up table on Pi0-3.
Correct that conditional
Hi Dave,
On 10/8/24 13:44, Dave Stevenson wrote:
Commit 92c17d16476c ("drm/vc4: hvs: Ignore atomic_flush if we're disabled")
added a path which returned early without having called drm_dev_exit.
Ensure all paths call drm_dev_exit.
Fixes: 92c17d16476c ("drm/vc4: hvs: Ignore atomic_flush if we'r
Hi Dave,
On 10/8/24 13:44, Dave Stevenson wrote:
Commit 52efe364d196 ("drm/vc4: hvs: Don't write gamma luts on 2711")
added a return path to vc4_hvs_lut_load that had called
drm_dev_enter, but not drm_dev_exit.
Ensure we call drm_dev_exit.
Fixes: 52efe364d196 ("drm/vc4: hvs: Don't write gamma
Hi Baihan，
At 2024-10-01 15:26:23, "shiyongbang" wrote:
>From: baihan li
>
>Add dp aux read/write functions. They are basic functions
> and will be used later.
>
>Signed-off-by: baihan li
>---
> drivers/gpu/drm/hisilicon/hibmc/Makefile | 3 +-
> drivers/gpu/drm/hisilicon/hibmc/dp/dp_aux.c
We already have of_graph_get_next_endpoint(), but it is not
intuitive to use in some case.
(X) node {
(Y) ports {
(P0)port@0 { endpoint { remote-endpoint = ...; };};
(P10) port@1 { endpoint { remote-endpoint = ...; };
(P11)
We have endpoint base functions
- of_graph_get_next_endpoint()
- of_graph_get_endpoint_count()
- for_each_endpoint_of_node()
Here, for_each_endpoint_of_node() loop finds each endpoints
ports {
port@0 {
(1) endpoint {...};
Hi Rob, Saravana, Tomi, Laurent, Sakari, Mark
This is v7 patch-set
Current Of-graph has "endpoint base" for loop, but doesn't have
"port base" loop. "endpoint base" loop only is not enough.
This patch-set add new "port base" for loop, and use it.
v6 -> v7
- based on latest linus/master
Current of_graph_get_next_endpoint() can be replaced by using
new of_graph_get_next_port().
Signed-off-by: Kuninori Morimoto
---
drivers/of/property.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index bf15b
Current test-component.c is using for_each_endpoint_of_node()
for parsing "port", because there was no "port" base loop before.
It has been assuming 1 port has 1 endpoint here.
But now we can use "port" base loop (= for_each_of_graph_port()).
Let's replace for_each function from "endpoint" base to
Now we can use new port related functions for port parsing. Use it.
Signed-off-by: Kuninori Morimoto
Acked-by: Mark Brown
---
sound/soc/generic/audio-graph-card2.c | 104 --
1 file changed, 48 insertions(+), 56 deletions(-)
diff --git a/sound/soc/generic/audio-graph-car
Now we can use new port related functions for port parsing. Use it.
Signed-off-by: Kuninori Morimoto
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 3 ++-
drivers/gpu/drm/omapdrm/dss/sdi.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/d
Now we can use new port related functions for port parsing. Use it.
Signed-off-by: Kuninori Morimoto
Reviewed-by: Tomi Valkeinen
---
drivers/media/platform/xilinx/xilinx-tpg.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/xilinx/xilin
Now we can use new port related functions for port parsing. Use it.
Signed-off-by: Kuninori Morimoto
---
drivers/video/fbdev/omap2/omapfb/dss/dpi.c| 3 +-
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 66 ---
drivers/video/fbdev/omap2/omapfb/dss/dss.c| 20 +++---
drive
Now we can use new port related functions for port parsing. Use it.
Signed-off-by: Kuninori Morimoto
Acked-by: Mark Brown
---
sound/soc/generic/audio-graph-card.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/generic/audio-graph-card.c
b/sound/soc/generic/audio-
If DSC is enabled, the only case is with 2 DSC engines so far. More
usage case will be added, such as 4 DSC in 4:4:2 topoplogy.
So get real number of DSCs to decide whether DSC merge is needed.
Signed-off-by: Jun Nie
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 2 ++
drivers/gpu/drm/msm/dis
If DSC is enabled, the only case is with 2 DSC engines so far. And
DSC in all pipes are configured by default.
More usage case will be added, such as 4 DSC in 4:4:2 topoplogy.
Pipe number is extended in future to support quad-pipe. But only
some of 4 pipes are used in non quad-pipe. So number of D
Only 2 DSC engines are allowed, or no DSC is involved currently.
We need 4 DSC in quad-pipe topology in future. So let's only configure
DSC engines in use, instread of maximum number of DSC engines.
Signed-off-by: Jun Nie
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 -
1 file
Hi
Am 09.10.24 um 02:40 schrieb Maíra Canal:
Currently, when booting the RPi 4B, we get a NULL pointer dereference:
[7.642883] Unable to handle kernel NULL pointer dereference at virtual
address 0038
[7.642926] Mem abort info:
[7.642938] ESR = 0x9644
[
On 08.10.2024 18:44, Dave Stevenson wrote:
> Commit 92c17d16476c ("drm/vc4: hvs: Ignore atomic_flush if we're disabled")
> added a path which returned early without having called drm_dev_exit.
>
> Ensure all paths call drm_dev_exit.
>
> Fixes: 92c17d16476c ("drm/vc4: hvs: Ignore atomic_flush if we'
On 08.10.2024 18:44, Dave Stevenson wrote:
> Commit 52efe364d196 ("drm/vc4: hvs: Don't write gamma luts on 2711")
> added a return path to vc4_hvs_lut_load that had called
> drm_dev_enter, but not drm_dev_exit.
>
> Ensure we call drm_dev_exit.
>
> Fixes: 52efe364d196 ("drm/vc4: hvs: Don't write gam
On 08.10.2024 18:44, Dave Stevenson wrote:
> Commit 24c5ed3ddf27 ("drm/vc4: Introduce generation number enum")
> incorrectly swapped a check of hvs->vc4->is_vc5 to
> hvs->vc4->gen == VC4_GEN_4 in vc4_hvs_lut_load, hence breaking
> loading the gamma look up table on Pi0-3.
>
> Correct that condition
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
include/drm/drm_file.h:400: warning: Function parameter or struct member
'client_name_lock' not described in 'drm_file'
include/drm/drm_file.h:400: warning: Excess struct member 'name_lock'
descr
On Wed, Oct 09, 2024 at 12:03:21AM +0200, Erhard Furtner wrote:
> Greetings!
>
> On kernel v6.12-rc I get no X and dmesg (via netconsole) shows this at
> loading radeon drm:
>
> [...]
> [drm] PCIE GART of 512M enabled (table at 0x0004).
> radeon :01:00.0: WB enabled
> radeon
On 10/8/2024 11:05, Mark Pearson wrote:
For the series, we tested at Lenovo and it fixed a couple of different issues
we had seen and reported on different HW models.
- issue with setting 1600 x 1200 on Z16 G2
- issue with frequency setting being incorrect on T14 G4 AMD with OLED panels
I d
If a pmu is unregistered while there's an active event, perf will still
access the pmu via event->pmu, even after the event is destroyed. This
makes it difficult for drivers like i915 that can be unbound from the
HW.
BUG: KASAN: use-after-free in exclusive_event_destroy+0xd8/0xf0
R
Allow to unregister the PMU from perf with active events. When driver is
being accessed perf keeps a reference that when released triggers the
device cleanup.
Signed-off-by: Lucas De Marchi
---
kernel/events/dummy_pmu.c | 56 ---
1 file changed, 41 insertions(
When unregistering the PMU, disable the currently active events. This
allows userspace to see the change and possibly reacting on it, like
reopening the fd. With perf-stat, "" starts to be printed:
$ stat -e dummy_pmu_0/test-event-1/ -I1000
1.001227905 12 dummy
Simple dummy module that mimics what can be done with drivers to
bind/unbind them from the bus, which should trigger resource release.
This is mostly based on how i915 and (pending changes for) xe drivers
are interacting with perf pmu. A few differences due to not having
backing hardware or for si
v2 of my attempt at fixing how i915 interacts with perf events.
v1 -
https://lore.kernel.org/all/20240722210648.80892-1-lucas.demar...@intel.com/
>From other people:
1)
https://lore.kernel.org/lkml/20240115170120.662220-1-tvrtko.ursu...@linux.intel.com/
2)
https://lore.kernel.org/all/202402131
It's not needed to hold the mutex to free the percpu variables stored in
pmu. Move them outside of the mutex protection in preparation for
possibly allowing them to live longer, according to the lifecycle of the
object owning/containing the pmu.
Signed-off-by: Lucas De Marchi
---
kernel/events/c
mentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.yaml:
Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241008-zii_yaml-v1-2-d06ba7e26...@nxp.com
The base for the series is generally the latest rc1. A diffe
bindings/nvmem/zii,rave-sp-eeprom.yaml:
Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241008-zii_yaml-v1-3-d06ba7e26...@nxp.com
The base for the series is generally the latest rc1. A different dependency
shou
tion/devicetree/bindings/watchdog/zii,rave-sp-wdt.yaml:
Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241008-zii_yaml-v1-4-d06ba7e26...@nxp.com
The base for the series is generally the latest rc1. A different dependency
shou
i,rave-sp-pwrbutton.yaml:
Documentation/devicetree/bindings/mfd/zii,rave-sp.yaml
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241008-zii_yaml-v1-1-d06ba7e26...@nxp.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* pat
On Sat, 2024-10-05 at 04:14 +, Matthew Brost wrote:
> On Fri, Oct 04, 2024 at 04:28:29PM +0200, Thomas Hellström wrote:
> > On Wed, 2024-10-02 at 14:54 +0200, Thomas Hellström wrote:
> > > On Wed, 2024-10-02 at 14:45 +0200, Christian König wrote:
> > > > Am 02.10.24 um 14:24 schrieb Thomas Hell
>> …
>>> pre-multiplied is supported in the current platform.
>> …
>>
>> format would be?
…
> blend_modes is the driver data that describes the supported blend mode
> in current platform no matter format would be any one.
>
> This sentence is describing mtk_ovl_fmt_convert() will c
---
Changes in v8:
- Don't remove "depends on !S390" for SERIAL_8250
- Link to v7:
https://lore.kernel.org/r/20241008-b4-has_ioport-v7-0-8624c09a4...@linux.ibm.com
Changes in v7:
- Renamed serial_8250_need_ioport() helper to
serial_8250_warn_need_ioport() and move it to 8250_p
With all subsystems and drivers either declaring their dependence on
HAS_IOPORT or fencing I/O port specific code sections we can finally
make inb()/outb() and friends compile-time dependent on HAS_IOPORT as
suggested by Linus in the linked mail. The main benefit of this is that
on platforms such a
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them unconditionally. Some 8250 serial drivers support
MMIO only use, so fence only the parts requiring I/O ports and print an
error message if
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. As hexagon does not support I/O port access it also
the GENERIC_IOMAP mechanism of dynamically choosing between I/O port and
MMIO access doesn't work so don't select it.
Reviewed-by: Brian Cain
Co-developed-by:
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them. In the bochs driver there is optional MMIO support
detected at runtime, warn if this isn't taken when HAS_IOPORT is not
defined.
There is
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them.
Co-developed-by: Arnd Bergmann
Signed-off-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
drivers/bluetooth/Kconfig | 6 +++---
On Tue, Oct 08, 2024 at 08:46:01AM +0200, Christian König wrote:
Hi Sasha,
Am 04.10.24 um 20:17 schrieb Sasha Levin:
From: Christian König
[ Upstream commit 7181faaa4703705939580abffaf9cb5d6b50dbb7 ]
This was only used as workaround for recovering the page tables after
VRAM was lost and is n
6.11-stable review patch. If anyone has any objections, please let me know.
--
From: Tvrtko Ursulin
commit 087913e0ba2b3b9d7ccbafb2acf5dab9e35ae1d5 upstream.
Entities run queue can change during drm_sched_entity_push_job() so make
sure to update the score consistently.
Signed
6.11-stable review patch. If anyone has any objections, please let me know.
--
From: Tvrtko Ursulin
commit 4286cc2c953983d44d248c9de1c81d3a9643345c upstream.
Without the locking amdgpu currently can race between
amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sch
6.11-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 upstream.
FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI
should only use UAPI types. Hence replace struct d
6.11-stable review patch. If anyone has any objections, please let me know.
--
From: Tvrtko Ursulin
commit cbc8764e29c2318229261a679b2aafd0f9072885 upstream.
Since drm_sched_entity_modify_sched() can modify the entities run queue,
lets make sure to only dereference the pointer
6.11-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit ad604f0a4c040dcb8faf44dc72db25e457c28076 upstream.
The sysfb framebuffer handling only operates on graphics devices
that provide the system's firmware framebuffer. If
On Thu, Oct 03, 2024 at 03:23:22PM +0300, Raag Jadav wrote:
> On Tue, Oct 01, 2024 at 02:20:29PM +0200, Michal Wajdeczko wrote:
> > On 30.09.2024 09:38, Raag Jadav wrote:
> > >
> > > +/**
> > > + * enum drm_wedge_recovery - Recovery method for wedged device in order
> > > of
> > > + * severity.
On 10/3/24 13:00, Harry Wentland wrote:
> Debugging LUT math is much easier when we can unit test
...
> diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_test.c
> b/drivers/gpu/drm/vkms/tests/vkms_color_test.c
> new file mode 100644
> index ..efe139978860
> --- /dev/null
> +++ b/drive
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/gpu/drm/ to use .remove(),
with the eventual goal to drop struct platform_driver::remove_new(). A
Fixes:
include/uapi/drm/drm_mode.h:869:
warning: Function parameter or struct member
'width' not described in 'drm_plane_size_hint'
include/uapi/drm/drm_mode.h:869:
warning: Function parameter or struct member
'height' not described in 'drm_plane_size_hint'
Signed-off-by: Sunil Khatri
Cc: Ville
include/drm/display/drm_dp_helper.h:127: warning:
Function parameter or struct member 'target_rr_divider'
not described in 'drm_dp_as_sdp'
Signed-off-by: Sunil Khatri
Cc: Mitul Golani
Cc: Arun R Murthy
Cc: Suraj Kandpal
---
include/drm/display/drm_dp_helper.h | 1 +
1 file changed, 1 insertio
The system and GPU MMU page size might differ, which becomes a
problem for FW sections that need to be mapped at explicit address
since our PAGE_SIZE alignment might cover a VA range that's
expected to be used for another section.
Make sure we never map more than we need.
Fixes: 2718d91816ee ("dr
1 - 100 of 201 matches
Mail list logo
