On 12/30/2022 1:54 PM, Herbert Xu wrote:
> On Fri, Dec 23, 2022 at 05:45:24PM +0530, Rijo Thomas wrote:
>>
>>> dma_alloc_coherent memory is just as contiguous as __get_free_pages, and
>>> calling dma_alloc_coherent from a guest does not guarantee that the memory
>>> is
>>> contiguous in host me
On 1/4/2023 3:48 AM, Mario Limonciello wrote:
Simplifies the code so that all SDMA versions will get the firmware
name from `amdgpu_ucode_ip_version_decode`.
Signed-off-by: Mario Limonciello
---
v3->v4:
* Move out of IP discovery and instead simplify early_init
v2->v3:
* Fix dGPU naming
On 1/4/2023 3:48 AM, Mario Limonciello wrote:
All microcode runs a basic validation after it's been loaded. Each
IP block as part of init will run both.
Introduce a wrapper for request_firmware and amdgpu_ucode_validate.
This wrapper will also remap any error codes from request_firmware
to -E
On Tue, Jan 3, 2023 at 5:11 PM Maíra Canal wrote:
>
> On 1/3/23 19:46, Rob Clark wrote:
> > drive-by thought/concern, what are the odds that there is some wayland
> > compositor out there that creates an fb for every window surface, even
> > if it later decides to composite on the GPU because the
Hi Michel,
Thanks for your thoughts. I'll give my attempt at weighing my and your
options, with the caveat that I'm still not much of a DRM expert.
On Tue, Jan 03, 2023 at 07:04:00PM +0100, Michel Dänzer wrote:
> On 12/21/22 23:02, Brian Norris wrote:
> > So how to fix this?
> >
> > 1. ignore it
On 12/22/2022 7:08 PM, Dmitry Baryshkov wrote:
On 23/12/2022 00:14, Jessica Zhang wrote:
Loosen the requirements for atomic and legacy commit so that, in cases
where solid fill planes is enabled (and FB_ID is NULL), the commit can
still go through.
In addition, add framebuffer NULL checks in
On 1/3/23 19:46, Rob Clark wrote:
drive-by thought/concern, what are the odds that there is some wayland
compositor out there that creates an fb for every window surface, even
if it later decides to composite on the GPU because the display does
not support the format? It seems like there is a no
On 12/22/2022 7:12 PM, Dmitry Baryshkov wrote:
On 23/12/2022 00:14, Jessica Zhang wrote:
Initialize and use the color_fill properties for planes in DPU driver. In
addition, relax framebuffer requirements within atomic commit path and
add checks for NULL framebuffers. Finally, drop DPU_PLANE_C
On Tue, Jan 03, 2023 at 03:48:36PM -0800, Kees Cook wrote:
> Zero-length arrays are deprecated[1] and are being replaced with
> flexible array members in support of the ongoing efforts to tighten the
> FORTIFY_SOURCE routines on memcpy(), correctly instrument array indexing
> with UBSAN_BOUNDS, and
On Fri, Dec 23, 2022 at 02:10:14AM +, Bryan O'Donoghue wrote:
> Add the list of current compats absent the deprecated qcm2290 to the list
> of dsi compats listed here.
>
> Several MDSS yaml files exist which document the dsi sub-node.
> For each existing SoC MDSS yaml, provide the right dsi co
From: Rob Clark
gem_context_register() makes the context visible to userspace, and which
point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
So we need to ensure that nothing uses the ctx ptr after this. And we
need to ensure that adding the ctx to the xarray is the *last* th
Zero-length arrays are deprecated[1] and are being replaced with
flexible array members in support of the ongoing efforts to tighten the
FORTIFY_SOURCE routines on memcpy(), correctly instrument array indexing
with UBSAN_BOUNDS, and to globally enable -fstrict-flex-arrays=3.
Replace zero-length ar
On Tuesday, January 3rd, 2023 at 23:46, Rob Clark wrote:
> drive-by thought/concern, what are the odds that there is some wayland
> compositor out there that creates an fb for every window surface, even
> if it later decides to composite on the GPU because the display does
> not support the forma
On Fri, Dec 23, 2022 at 10:28:07AM -0800, Lucas De Marchi wrote:
> On Fri, Dec 23, 2022 at 09:02:35AM +, Tvrtko Ursulin wrote:
> >
> > On 22/12/2022 15:55, Lucas De Marchi wrote:
> > > On Thu, Dec 22, 2022 at 10:27:00AM +, Tvrtko Ursulin wrote:
> > > >
> > > > On 22/12/2022 08:25, Lucas D
drive-by thought/concern, what are the odds that there is some wayland
compositor out there that creates an fb for every window surface, even
if it later decides to composite on the GPU because the display does
not support the format? It seems like there is a non-zero chance of
breaking userspace.
Now that IP version decoding is used, a number of case statements
can be combined.
Signed-off-by: Mario Limonciello
---
v3->v4:
* New patch
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
The `amdgpu_ucode_load` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
Signed-off-by: Mario Limonciello
---
v3->v4:
* New patch
---
drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 5 +
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 5
This will ensure that the microcode is available before the firmware
framebuffer has been destroyed.
Signed-off-by: Mario Limonciello
---
v3->v4:
* new patch
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gp
The `amdgpu_ucode_load` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
Signed-off-by: Mario Limonciello
---
v3->v4:
* New patch
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 42 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp
Simplifies the code so that all PSP versions will get the firmware
name from `amdgpu_ucode_ip_version_decode` and then use this filename
to load microcode as part of the early_init process.
Any failures will cause the driver to fail to probe before the firmware
framebuffer has been removed.
Signe
If DMUB is required for an ASIC, ensure that the microcode is available
and validates during early_init.
Any failures will cause the driver to fail to probe before the firmware
framebuffer has been removed.
Signed-off-by: Mario Limonciello
---
v3->v4:
* New patch
---
.../gpu/drm/amd/display/am
No need to crash the kernel. AMDGPU will now fail to probe.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index a
Several IP versions duplicate code and can't use the common helpers.
Move this code into a single function so that the helpers can be used.
Signed-off-by: Mario Limonciello
---
v3->v4:
* New patch
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 120 ++--
drivers/gpu/drm/amd/am
Simplifies the code so that GFX10 will get the firmware
name from `amdgpu_ucode_ip_version_decode` and then use this filename
to load microcode as part of the early_init process.
Any failures will cause the driver to fail to probe before the firmware
framebuffer has been removed.
Signed-off-by: M
The `amdgpu_ucode_load` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
Signed-off-by: Mario Limonciello
---
v3->v4:
* New patch
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 35 ++
1 file changed, 8 insertions(+), 27 d
If GFX11 microcode is required but not available during early init, the
firmware framebuffer will have already been released and the screen will
freeze.
Move the request for GFX11 microcode into the early_init phase
so that if it's not available, driver init will fail.
Signed-off-by: Mario Limonc
The `amdgpu_ucode_load` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
Signed-off-by: Mario Limonciello
---
v3->v4:
* New patch
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 23 ---
1 file changed, 4 insertions(+), 19 dele
Add an early_init phase to MES for fetching and validating microcode
from the filesystem.
If MES microcode is required but not available during early init, the
firmware framebuffer will have already been released and the screen will
freeze.
Move the request for MES microcode into the early_init p
If GFX9 microcode is required but not available during early init, the
firmware framebuffer will have already been released and the screen will
freeze.
Signed-off-by: Mario Limonciello
---
v3->v4:
* Move microcode load phase to early init
v2->v3:
* Fix issues found on real hardware where num_gf
The `amdgpu_ucode_load` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
Signed-off-by: Mario Limonciello
---
v3->v4:
* new patch
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 43 +--
1 file changed, 8 insertions(+), 35 d
The `amdgpu_ucode_load` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
Signed-off-by: Mario Limonciello
---
v3->v4:
* New patch
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --g
`amdgpu_mes_init` already sets `adev->mes.adev`, so there is no need
to also set it in the IP specific versions.
Signed-off-by: Mario Limonciello
---
v4:
* New patch
---
drivers/gpu/drm/amd/amdgpu/mes_v10_1.c | 1 -
drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 1 -
2 files changed, 2 deletions(-)
The `amdgpu_ucode_load` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
Signed-off-by: Mario Limonciello
---
v3->v4:
* New patch
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-
When firmware is missing we get failures at every step.
```
[3.855086] amdgpu :04:00.0: Direct firmware load for
amdgpu/green_sardine_sdma.bin failed with error -2
[3.855087] [drm:amdgpu_sdma_init_microcode [amdgpu]] *ERROR* SDMA: Failed
to init firmware "amdgpu/green_sardine_sdma.bin
Simplifies the code so that all VCN versions will get the firmware
name from `amdgpu_ucode_ip_version_decode` and then use this filename
to load microcode as part of the early_init process.
Signed-off-by: Mario Limonciello
---
v3->v4:
* Move out of IP discovery and introduce early_init phase for
Simplifies the code so that all SDMA versions will get the firmware
name from `amdgpu_ucode_ip_version_decode`.
Signed-off-by: Mario Limonciello
---
v3->v4:
* Move out of IP discovery and instead simplify early_init
v2->v3:
* Fix dGPU naming scheme
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
The `amdgpu_ucode_load` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
Signed-off-by: Mario Limonciello
---
v3->v4:
* New patch
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --
All microcode runs a basic validation after it's been loaded. Each
IP block as part of init will run both.
Introduce a wrapper for request_firmware and amdgpu_ucode_validate.
This wrapper will also remap any error codes from request_firmware
to -ENODEV. This is so that early_init will fail if fir
This will allow other parts of the driver that currently special
case firmware file names to before IP version style naming to just
have a single call to `amdgpu_ucode_ip_version_decode`.
Signed-off-by: Mario Limonciello
Acked-by: Christian König
---
v3->v4:
* No changes
v2->v3:
* Fixes for GF
The special case for the one dGPU has been moved into
`amdgpu_ucode_ip_version_decode`, so simplify this code.
Reviewed-by: Alex Deucher
Signed-off-by: Mario Limonciello
Acked-by: Christian König
---
v3->v4:
* No changes
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 12 ++--
1
Remove the special casing from SMU v11 code. No intended functional
changes.
Signed-off-by: Mario Limonciello
Acked-by: Christian König
---
v3->v4:
* No changes
---
.../gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c| 35 ++-
1 file changed, 3 insertions(+), 32 deletions(-)
diff --
Removing the firmware framebuffer from the driver means that even
if the driver doesn't support the IP blocks in a GPU it will no
longer be functional after the driver fails to initialize.
This change will ensure that unsupported IP blocks at least cause
the driver to work with the EFI framebuffer
One of the first thing that KMS drivers do during initialization is
destroy the system firmware framebuffer by means of
`drm_aperture_remove_conflicting_pci_framebuffers`
This means that if for any reason the GPU failed to probe the user
will be stuck with at best a screen frozen at the last thing
Hi Thomas,
On 1/2/23 08:29, Thomas Zimmermann wrote:
Fix the color-format selection of the single-probe helper. Go
through all user-specified values and test each for compatibility
with the driver. If none is supported, use the driver-provided
default. This guarantees that the console is always
On Fri, Dec 23, 2022 at 9:23 AM xurui wrote:
>
> HPD signals on DVI ports can be fired off before the pins required for
> DDC probing actually make contact, due to the pins for HPD making
> contact first. This results in a HPD signal being asserted but DDC
> probing failing, resulting in hotpluggi
Hi Chris.
On Tue, Jan 03, 2023 at 01:07:06PM -0600, Chris Morgan wrote:
> From: Chris Morgan
>
> Support Magnachip D53E6EA8966 based panels such as the Samsung
> AMS495QA01 panel as found on the Anbernic RG503. Note this driver
> supports only the AMS495QA01 today which receives video signals vi
On Tue, Jan 03, 2023 at 03:49:26PM +0100, Maxime Ripard wrote:
> Hi Daniel, Dave,
>
> Here's the drm-misc-next-fixes leftovers.
>
> Maxime
>
> drm-misc-next-fixes-2023-01-03:
> The drm-misc-next-fixes leftovers. It addresses a bug in drm/scheduler
> ending up causing a lockup, and reduces the st
On Mon, Dec 19, 2022 at 05:10:02PM +0100, Andrzej Hajda wrote:
> On 19.12.2022 11:13, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > As the logic for selecting the register and corresponsing values grew, the
>
> corresponding
>
> > code become a bit unsightly. Consolidate by storing the
Hi Chris.
On Tue, Jan 03, 2023 at 01:07:04PM -0600, Chris Morgan wrote:
> From: Chris Morgan
>
> Add helper function to find DSI host for devices where DSI panel is not
> a minor of a DSI bus (such as the Samsung AMS495QA01 panel or the
> official Raspberry Pi touchscreen display).
>
> Signed-o
On 12/28, Melissa Wen wrote:
> On 12/27, Maíra Canal wrote:
> > As v3d_submit_tfu_ioctl() performs the same steps as
> > drm_gem_object_lookup(),
> > replace the open-code implementation in v3d with its DRM core equivalent.
> >
> > Signed-off-by: Maíra Canal
> > ---
> > drivers/gpu/drm/v3d/v3d_
From: Chris Morgan
Support Magnachip D53E6EA8966 based panels such as the Samsung
AMS495QA01 panel as found on the Anbernic RG503. Note this driver
supports only the AMS495QA01 today which receives video signals via DSI,
however it receives commands via 3-wire SPI using DBI.
Signed-off-by: Chris
From: Chris Morgan
Add Samsung AMS495QA01 panel to RG503.
Signed-off-by: Chris Morgan
Signed-off-by: Maya Matuszczyk
---
.../dts/rockchip/rk3566-anbernic-rg503.dts| 55 +++
1 file changed, 55 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-anbernic-rg503.dt
From: Chris Morgan
Add helper function to find DSI host for devices where DSI panel is not
a minor of a DSI bus (such as the Samsung AMS495QA01 panel or the
official Raspberry Pi touchscreen display).
Signed-off-by: Chris Morgan
Signed-off-by: Maya Matuszczyk
Reviewed-by: Linus Walleij
---
d
From: Chris Morgan
Add documentation for Samsung AMS495QA01 panel (with Magnachip
D53E6EA8966 controller IC).
Signed-off-by: Chris Morgan
Signed-off-by: Maya Matuszczyk
---
.../display/panel/samsung,ams495qa01.yaml | 57 +++
1 file changed, 57 insertions(+)
create mode 10
From: Chris Morgan
Add the Magnachip D53E6EA8966 panel IC controller for display panels
such as the Samsung AMS495QA01 panel as found on the Anbernic RG503.
This panel uses DSI to receive video signals, but 3-wire SPI to receive
command signals using DBI.
Changes since V6:
- Fixed a trivial err
From: Mario Limonciello
[ Upstream commit c573e240609ff781a0246c0c8c8351abd0475287 ]
On desktop APUs amdgpu doesn't create a native backlight device
as no eDP panels are found. However if the BIOS has reported
backlight control methods in the ACPI tables then an acpi_video0
backlight device wil
Nice!
Reviewed-by: Simon Ser
Hi Neil,
On Tue, Jan 03, 2023 at 03:22:28PM +0100, Neil Armstrong wrote:
> Add support for the 1080x2400 Visionox VTDR6130 AMOLED DSI panel
> found on the Qualcomm SM8550 MTP board.
>
> By default the the panel is configured to work with DSI compressed
> streams, but can work in uncompressed vide
On 12/21/22 23:02, Brian Norris wrote:
> Hi Mark, Sean, (and dri-devel)
>
> On Wed, Dec 14, 2022 at 07:04:37PM -0800, Brian Norris wrote:
>> On Tue, Dec 13, 2022 at 04:51:11PM +, Mark Brown wrote:
>>> On Tue, Dec 13, 2022 at 05:56:30AM -0800, KernelCI bot wrote:
>>>
>>> The KernelCI bisection
Hi Neil,
On Tue, Jan 03, 2023 at 03:22:27PM +0100, Neil Armstrong wrote:
> Document the 1080x2400 Visionox VTDR6130 AMOLED DSI Panel bindings.
>
> Signed-off-by: Neil Armstrong
> ---
> .../bindings/display/panel/visionox,vtdr6130.yaml | 53
> ++
> 1 file changed, 53 insert
Pushed, thanks!
Hi Krzysztof/Dmitry,
Would you please review this patch.
Thanks,
On 12/27/2022 9:44 AM, Kuogee Hsieh wrote:
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be
On 03/01/2023 4:15 pm, Maxime Ripard wrote:
Hi Robin,
On Tue, Jan 03, 2023 at 01:01:07PM +, Robin Murphy wrote:
Hi Sean,
On 22/12/2022 11:37 pm, Sean Anderson wrote:
Convert users of component_match_add_release with component_release_of
and component_compare_of to component_match_add_of.
On 03/01/2023 15:39, Simon Ser wrote:
On Tuesday, January 3rd, 2023 at 16:37, Tvrtko Ursulin
wrote:
On 23/12/2022 11:26, Simon Ser wrote:
Reviewed-by: Simon Ser cont...@emersion.fr
Thanks - adding some drm-misc maintainers to consider pulling the patch in.
I can push the patches if yo
On 1/3/23 11:15, Maxime Ripard wrote:
> Hi Robin,
>
> On Tue, Jan 03, 2023 at 01:01:07PM +, Robin Murphy wrote:
>> Hi Sean,
>>
>> On 22/12/2022 11:37 pm, Sean Anderson wrote:
>> > Convert users of component_match_add_release with component_release_of
>> > and component_compare_of to component
Am 2023-01-03 um 11:05 schrieb Waiman Long:
On 1/3/23 10:39, Felix Kuehling wrote:
The regression point doesn't make sense. The kernel config doesn't
enable CONFIG_DRM_AMDGPU, so there is no way that a change in AMDGPU
could have caused this regression.
I agree. It is likely a pre-existing
On Tue, Jan 03, 2023 at 07:09:20PM +0300, Alexey Lukyachuk wrote:
> On Tue, 3 Jan 2023 07:46:40 -0500
> Rodrigo Vivi wrote:
>
> > On Mon, Jan 02, 2023 at 04:56:49PM +0300, Alexey Lukyachuk wrote:
> > > On Tue, 27 Dec 2022 20:40:03 +0300
> > > Alexey Lukyachuk wrote:
> > >
> > > > On Tue, 27 Dec
Hi Robin,
On Tue, Jan 03, 2023 at 01:01:07PM +, Robin Murphy wrote:
> Hi Sean,
>
> On 22/12/2022 11:37 pm, Sean Anderson wrote:
> > Convert users of component_match_add_release with component_release_of
> > and component_compare_of to component_match_add_of.
> >
> > Signed-off-by: Sean Ander
On Tue, 3 Jan 2023 07:46:40 -0500
Rodrigo Vivi wrote:
> On Mon, Jan 02, 2023 at 04:56:49PM +0300, Alexey Lukyachuk wrote:
> > On Tue, 27 Dec 2022 20:40:03 +0300
> > Alexey Lukyachuk wrote:
> >
> > > On Tue, 27 Dec 2022 11:39:25 -0500
> > > Rodrigo Vivi wrote:
> > >
> > > > On Sun, Dec 25, 202
On 1/3/23 10:39, Felix Kuehling wrote:
The regression point doesn't make sense. The kernel config doesn't
enable CONFIG_DRM_AMDGPU, so there is no way that a change in AMDGPU
could have caused this regression.
I agree. It is likely a pre-existing problem or caused by another commit
that got t
Fix another oops reproducible when rebooting the board with the Adreno
GPU wokring in the headless mode (e.g. iMX platforms).
Unable to handle kernel NULL pointer dereference at virtual address
when read
[] *pgd=74936831, *pte=, *ppte=
Internal error: Oops: 17 [#1
The regression point doesn't make sense. The kernel config doesn't
enable CONFIG_DRM_AMDGPU, so there is no way that a change in AMDGPU
could have caused this regression.
Regards,
Felix
Am 2022-12-29 um 01:26 schrieb syzbot:
syzbot has found a reproducer for the following issue on:
HEAD c
On Tuesday, January 3rd, 2023 at 16:37, Tvrtko Ursulin
wrote:
> On 23/12/2022 11:26, Simon Ser wrote:
>
> > Reviewed-by: Simon Ser cont...@emersion.fr
>
> Thanks - adding some drm-misc maintainers to consider pulling the patch in.
I can push the patches if you don't have commit rights.
On 23/12/2022 11:26, Simon Ser wrote:
Reviewed-by: Simon Ser
Thanks - adding some drm-misc maintainers to consider pulling the patch in.
Regards,
Tvrtko
From: Sean Paul
Add a paragraph explaining that the default behavior for areas which
are not covered by planes or where planes are blending with the CRTC
background, is black.
This is alluded to in the "pixel blend mode" property docs, but not
called out explicitly.
Signed-off-by: Sean Paul
--
Hi Daniel, Dave,
Here's the drm-misc-next-fixes leftovers.
Maxime
drm-misc-next-fixes-2023-01-03:
The drm-misc-next-fixes leftovers. It addresses a bug in drm/scheduler
ending up causing a lockup, and reduces the stack usage of some drm/mm
kunit tests.
The following changes since commit b02897e5
> > For one thing, setting that up would be a lot of up front infrastructure
> > work. I'm not sure how to even pull that off when Xe is still
> > out-of-tree and i915 development plunges on upstream as ever.
> >
> > For another, realistically, the overlap between supported platforms is
> > going
Add support for the 1080x2400 Visionox VTDR6130 AMOLED DSI panel
found on the Qualcomm SM8550 MTP board.
By default the the panel is configured to work with DSI compressed
streams, but can work in uncompressed video mode since 1080x2400 in
RGB888 fits in the 4 DSI lanes bandwidth.
While display c
Document the 1080x2400 Visionox VTDR6130 AMOLED DSI Panel bindings.
Signed-off-by: Neil Armstrong
---
.../bindings/display/panel/visionox,vtdr6130.yaml | 53 ++
1 file changed, 53 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.
tions(+)
---
base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
change-id: 20230103-topic-sm8550-upstream-vtdr6130-panel-f81dad976abd
Best regards,
--
Neil Armstrong
Hi,
On Tue, 3 Jan 2023 13:02:15 +
Tvrtko Ursulin wrote:
> On 02/01/2023 07:30, Boris Brezillon wrote:
> > On Fri, 30 Dec 2022 12:55:08 +0100
> > Boris Brezillon wrote:
> >
> >> On Fri, 30 Dec 2022 11:20:42 +0100
> >> Boris Brezillon wrote:
> >>
> >>> Hello Matthew,
> >>>
> >>> On Thu,
On Tue, Jan 3, 2023 at 5:10 AM Lazar, Lijo wrote:
>
>
>
> On 12/28/2022 10:00 PM, Mario Limonciello wrote:
> > One of the first thing that KMS drivers do during initialization is
> > destroy the system firmware framebuffer by means of
> > `drm_aperture_remove_conflicting_pci_framebuffers`
> >
> >
Am 03.01.23 um 14:59 schrieb Maíra Canal:
Currently, drm_gem_fb_create() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on drm_gem_fb_create().
Moreover
On Fri, 30 Dec 2022 08:27:58 +0100,
Zheng Wang wrote:
>
> Here is a function call chain.
> nvkm_vmm_pfn_map->nvkm_vmm_pfn_split_merge->nvkm_vmm_node_split
> If nvkm_vma_tail return NULL in nvkm_vmm_node_split, it will
> finally invoke nvkm_vmm_node_merge->nvkm_vmm_node_delete, which
> will free th
Currently, drm_gem_fb_create() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on drm_gem_fb_create().
Moreover, note that this check is only valid for atomi
Hi,
On Mon, 02 Jan 2023 13:42:46 +0200
Jani Nikula wrote:
> On Mon, 02 Jan 2023, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 22.12.22 um 23:21 schrieb Matthew Brost:
> >> Hello,
> >>
> >> This is a submission for Xe, a new driver for Intel GPUs that supports both
> >> integrated and discrete
Am 20.12.22 um 10:32 schrieb Javier Martinez Canillas:
[adding Kirti Wankhede and k...@vger.kernel.org to Cc list]
On 12/19/22 17:05, Thomas Zimmermann wrote:
Generic fbdev drivers use the apertures field in struct fb_info to
control ownership of the framebuffer memory and graphics device. Do
On Mon, Dec 26, 2022 at 12:50:23PM -0300, Maíra Canal wrote:
> Replace the use of drm_debugfs_create_files() with the new
> drm_debugfs_add_files() function, which center the debugfs files
> management on the drm_device instead of drm_minor. Moreover, remove the
> debugfs_init hook and add the debu
On Tue, 03 Jan 2023, Rodrigo Vivi wrote:
> On Mon, Jan 02, 2023 at 04:56:49PM +0300, Alexey Lukyachuk wrote:
>> On Tue, 27 Dec 2022 20:40:03 +0300
>> Alexey Lukyachuk wrote:
>>
>> > On Tue, 27 Dec 2022 11:39:25 -0500
>> > Rodrigo Vivi wrote:
>> >
>> > > On Sun, Dec 25, 2022 at 09:55:08PM +0300
Hi,
thanks for the follow-up patch.
Am 03.01.23 um 13:53 schrieb Maíra Canal:
Currently, drm_gem_fb_create() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid forma
On 02/01/2023 07:30, Boris Brezillon wrote:
On Fri, 30 Dec 2022 12:55:08 +0100
Boris Brezillon wrote:
On Fri, 30 Dec 2022 11:20:42 +0100
Boris Brezillon wrote:
Hello Matthew,
On Thu, 22 Dec 2022 14:21:11 -0800
Matthew Brost wrote:
In XE, the new Intel GPU driver, a choice has made
Hi Sean,
On 22/12/2022 11:37 pm, Sean Anderson wrote:
Convert users of component_match_add_release with component_release_of
and component_compare_of to component_match_add_of.
Signed-off-by: Sean Anderson
Acked-by: Mark Brown
---
Changes in v2:
- Split off from helper addition
drivers/io
Currently, drm_gem_fb_create() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on drm_gem_fb_create().
Moreover, note that this check is only valid for atomi
On Mon, Jan 02, 2023 at 04:56:49PM +0300, Alexey Lukyachuk wrote:
> On Tue, 27 Dec 2022 20:40:03 +0300
> Alexey Lukyachuk wrote:
>
> > On Tue, 27 Dec 2022 11:39:25 -0500
> > Rodrigo Vivi wrote:
> >
> > > On Sun, Dec 25, 2022 at 09:55:08PM +0300, Alexey Lukyanchuk wrote:
> > > > dell wyse 3040 d
Hello!
Why is this revert for revert coming for 6.1 but reverted again for 6.1.2?
My GPU is not working correctly again!
https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.2
It seems like somebody made a mistake and pick up the wrong patch for the
stable channel.
Regards!
On Sat, Nov 19
On 22/12/2022 22:21, Matthew Brost wrote:
Hello,
This is a submission for Xe, a new driver for Intel GPUs that supports both
integrated and discrete platforms starting with Tiger Lake (first platform with
Intel Xe Architecture). The intention of this new driver is to have a fresh base
to work
https://bugzilla.kernel.org/show_bug.cgi?id=172421
Eduard Bloch (bl...@debian.org) changed:
What|Removed |Added
CC||bl...@debian.org
--- Co
Il 03/01/23 07:46, Aradhya Bhatia ha scritto:
Dual-link LVDS interfaces have 2 links, with even pixels traveling on
one link, and odd pixels on the other. These panels are also generic in
nature, with no documented constraints, much like their single-link
counterparts, "panel-lvds".
Add a new co
On 03/01/2023 12:02, Aradhya Bhatia wrote:
> But this is throwing an error. I am confused what else could be done.
> Can you please suggest what might be a more accurate check here?
>
>>
>>> + required:
>>> +- dual-lvds-odd-pixels
>>> +then:
>>> + prop
Hi Krzysztof,
Thank you for reviewing the patches!
On 03-Jan-23 14:02, Krzysztof Kozlowski wrote:
On 03/01/2023 07:46, Aradhya Bhatia wrote:
Dual-link LVDS interfaces have 2 links, with even pixels traveling on
one link, and odd pixels on the other. These panels are also generic in
nature, wit
1 - 100 of 133 matches
Mail list logo
