Hi Thomas,
On Fri, Feb 18, 2022 at 9:14 AM Thomas Zimmermann wrote:
> Am 17.02.22 um 17:12 schrieb Geert Uytterhoeven:
> > On Thu, Feb 17, 2022 at 3:57 PM Thomas Zimmermann
> > wrote:
> >> Am 15.02.22 um 17:52 schrieb Geert Uytterhoeven:
> >>> Add support for color-indexed frame buffer formats
Am 17.02.22 um 21:37 schrieb Sam Ravnborg:
Hi Geert,
On Tue, Feb 15, 2022 at 05:52:18PM +0100, Geert Uytterhoeven wrote:
Hi all,
A long outstanding issue with the DRM subsystem has been the lack of
support for low-color displays, as used typically on older desktop
systems and small e
On Fri, Feb 18, 2022 at 3:46 PM Christian König
wrote:
>
> Am 18.02.22 um 04:08 schrieb Qiang Yu:
> > On Thu, Feb 17, 2022 at 8:22 PM Christian König
> > wrote:
> >> Am 17.02.22 um 11:58 schrieb Qiang Yu:
> >>> On Thu, Feb 17, 2022 at 6:39 PM Christian König
> >>> wrote:
>
> Am 17.02.2
On Fri, Feb 18, 2022 at 2:36 PM Rex Nie wrote:
>
> innolux,n140hca-eac is a eDP-based LCD panel. This panel has 1920x1080
> resolution in 14-inch TFT panel.
>
> Signed-off-by: Rex Nie
> ---
> .../display/panel/innolux,n140hca-eac.yaml| 43 +++
> drivers/gpu/drm/panel/panel-ed
Hello Thomas,
On 2/17/22 11:34, Thomas Zimmermann wrote:
> Improve the performance of sys_fillrect() by using word-aligned
> 32/64-bit mov instructions. While the code tried to implement this,
> the compiler failed to create fast instructions. The resulting
> binary instructions were even slower t
On 17/02/2022 15:53, Andi Shyti wrote:
Hi Tvrtko,
Now tiles have their own sysfs interfaces under the gt/
directory. Because RC6 is a property that can be configured on a
tile basis, then each tile should have its own interface
The new sysfs structure will have a similar layout for the 4 til
Hi Hsin-Yi,
Got it, thanks
On Fri, 18 Feb 2022 at 17:01, Hsin-Yi Wang wrote:
> On Fri, Feb 18, 2022 at 2:36 PM Rex Nie wrote:
> >
> > innolux,n140hca-eac is a eDP-based LCD panel. This panel has 1920x1080
> > resolution in 14-inch TFT panel.
> >
> > Signed-off-by: Rex Nie
> > ---
> > .../dis
Hi Tvrtko,
> > > > Now tiles have their own sysfs interfaces under the gt/
> > > > directory. Because RC6 is a property that can be configured on a
> > > > tile basis, then each tile should have its own interface
> > > >
> > > > The new sysfs structure will have a similar layout for the 4 tile
>
Hello Thomas,
On 2/17/22 11:34, Thomas Zimmermann wrote:
> Improve the performance of sys_imageblit() by manually unrolling
> the inner blitting loop and moving some invariants out. The compiler
> failed to do this automatically. The resulting binary code was even
> slower than the cfb_imageblit()
Am 18.02.22 um 09:58 schrieb Qiang Yu:
On Fri, Feb 18, 2022 at 3:46 PM Christian König
wrote:
Am 18.02.22 um 04:08 schrieb Qiang Yu:
On Thu, Feb 17, 2022 at 8:22 PM Christian König
wrote:
Am 17.02.22 um 11:58 schrieb Qiang Yu:
On Thu, Feb 17, 2022 at 6:39 PM Christian König
wrote:
Am 17.0
On 2/17/22 21:19, Thierry Reding wrote:
From: Thierry Reding
The Video Image Composer (VIC) 4.0 can be found on NVIDIA Tegra210 SoCs.
It uses a different class (B0B6) that is slightly incompatible with the
class found on earlier generations.
Signed-off-by: Thierry Reding
---
tests/tegra/mes
On 2/17/22 21:16, Thierry Reding wrote:
...
Reviewed-by: Mikko Perttunen
Left one cosmetic comment in the VIC4.0 patch, but overall looks OK. I
think it would be fine to have some basic tests in libdrm as well.
Cheers,
Mikko
Since switch to simpledrm VESA graphic modes are no longer available
with legacy BIOS.
The x86 realmode boot code enables the VESA graphic modes when option
FB_BOOT_VESA_SUPPORT is enabled.
To enable use of VESA modes with simpledrm in legacy BIOS boot mode drop
dependency of BOOT_VESA_SUPPORT on
Hi Thomas,
On Thu, Feb 17, 2022 at 11:34:04AM +0100, Thomas Zimmermann wrote:
> Improve the performance of sys_fillrect() by using word-aligned
> 32/64-bit mov instructions. While the code tried to implement this,
> the compiler failed to create fast instructions. The resulting
> binary instructio
From: Daocai Nie
Add support for the 14" innolux,n140hca-eac eDP panel.
Signed-off-by: Daocai Nie
---
drivers/gpu/drm/panel/panel-edp.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index f
From: Daocai Nie
Add support for InnoLux n140hca-eac display panel. It is a 14" eDP panel
with 1920x1080 display resolution.
Signed-off-by: Daocai Nie
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicet
Hi Michal
Am 18.02.22 um 10:33 schrieb Michal Suchanek:
Since switch to simpledrm VESA graphic modes are no longer available
with legacy BIOS.
The x86 realmode boot code enables the VESA graphic modes when option
FB_BOOT_VESA_SUPPORT is enabled.
To enable use of VESA modes with simpledrm in le
Add hsi...@chromium.org to cc list
On Fri, 18 Feb 2022 at 17:44, Rex Nie wrote:
> From: Daocai Nie
>
> Add support for the 14" innolux,n140hca-eac eDP panel.
>
> Signed-off-by: Daocai Nie
> ---
> drivers/gpu/drm/panel/panel-edp.c | 26 ++
> 1 file changed, 26 insertion
From: Ville Syrjälä
I might be taking this a bit too far, but the lack of
consistency in our methods to copy drm_display_mode
structs around is bugging me.
The main worry is the embedded list head, which if
clobbered could lead to list corruption. I'd also
prefer to make sure even the valid list
From: Ville Syrjälä
Add a variant of drm_mode_copy() that explicitly clears out
the list head of the destination mode. Helpful to guarantee
we don't have stack garbage left in there for on-stack modes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 17 +
include
From: Ville Syrjälä
These on stack copies of the modes appear to be pointless.
Just look at the originals directly.
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Alex Deucher
Cc: amd-...@lists.freedesktop.org
Cc: Nikola Cornij
Cc: Aurabindo Pillai
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M =
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head.
Cc: Xinliang Liu
Cc: Tian Tao
Cc: John Stultz
Cc: Xinwei Kong
Cc: Chen Feng
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +-
1 file chang
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
This on stack middle man mode looks entirely pointless.
Just duplicate the original mode directly.
Cc: Rob Clark
Cc: Sean Paul
Cc: Abhinav Kumar
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/msm/dp/
From: Ville Syrjälä
Replace the hand rolled drm_mode_duplicate() with the
real thing.
@is_dup@
@@
drm_mode_duplicate(...)
{ ... }
@depends on !is_dup@
expression dev, oldmode;
identifier newmode;
@@
- newmode = drm_mode_create(dev);
+ newmode = drm_mode_duplicate(dev, oldmode);
...
- drm_mode
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M =
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M = E;
+ struct drm_display_mode M;
@@
identifier decl.M;
e
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
Replace the hand rolled drm_mode_duplicate() with the
real thing.
@is_dup@
@@
drm_mode_duplicate(...)
{ ... }
@depends on !is_dup@
expression dev, oldmode;
identifier newmode;
@@
- newmode = drm_mode_create(dev);
+ newmode = drm_mode_duplicate(dev, oldmode);
...
- drm_mode
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M =
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M =
On Tue, Feb 01, 2022 at 04:11:24PM +0530, Ramalingam C wrote:
From: Abdiel Janulgue
A portion of device memory is reserved for Flat CCS so usable
device memory will be reduced by size of Flat CCS. Size of
Flat CCS is specified in “XEHPSDV_FLAT_CCS_BASE_ADDR”.
So to get effective device memory w
Hi Rudi,
On Wed, Feb 16, 2022 at 09:22:28PM +, Rudi Heitbaum wrote:
> Without DRM_GEM_CMA_HELPER i.MX8MQ DCSS won't build. This needs to be
> there.
>
> Signed-off-by: Rudi Heitbaum
Reviewed-by: Laurentiu Palcu
...and pushed to drm-misc-fixes.
Thanks,
laurentiu
> ---
> drivers/gpu/drm/i
Hello,
On Fri, Feb 18, 2022 at 10:57:33AM +0100, Thomas Zimmermann wrote:
> Hi Michal
>
> Am 18.02.22 um 10:33 schrieb Michal Suchanek:
> > Since switch to simpledrm VESA graphic modes are no longer available
> > with legacy BIOS.
> >
> > The x86 realmode boot code enables the VESA graphic modes
On 17.02.2022 16:38, Eric Dumazet wrote:
On Thu, Feb 17, 2022 at 6:05 AM Andrzej Hajda wrote:
To improve readibility of ref_tracker printing following changes
have been performed:
- added display name for ref_tracker_dir,
- stack trace is printed indented, in the same printk call,
- total nu
Hi Thomas,
On Thu, Feb 17, 2022 at 11:34:05AM +0100, Thomas Zimmermann wrote:
> Improve the performance of sys_imageblit() by manually unrolling
> the inner blitting loop and moving some invariants out. The compiler
> failed to do this automatically. The resulting binary code was even
> slower tha
On Fri, Feb 18, 2022 at 5:27 PM Christian König
wrote:
>
> Am 18.02.22 um 09:58 schrieb Qiang Yu:
> > On Fri, Feb 18, 2022 at 3:46 PM Christian König
> > wrote:
> >> Am 18.02.22 um 04:08 schrieb Qiang Yu:
> >>> On Thu, Feb 17, 2022 at 8:22 PM Christian König
> >>> wrote:
> Am 17.02.22 um 11
On Fri, Feb 18, 2022 at 02:08:18AM -0800, Lucas De Marchi wrote:
On Tue, Feb 01, 2022 at 04:11:24PM +0530, Ramalingam C wrote:
From: Abdiel Janulgue
A portion of device memory is reserved for Flat CCS so usable
device memory will be reduced by size of Flat CCS. Size of
Flat CCS is specified in
Am 18.02.22 um 11:16 schrieb Qiang Yu:
[SNIP]
If amdgpu_vm_ready() use evicting flag, it's still not equivalent to check
vm idle: true -> vm idle, false -> vm may be idle or busy.
Yeah, but why should that be relevant?
The amdgpu_vm_ready() return if we can do page table updates or not. If
the
Hi
Am 18.02.22 um 11:08 schrieb Michal Suchánek:
Hello,
On Fri, Feb 18, 2022 at 10:57:33AM +0100, Thomas Zimmermann wrote:
Hi Michal
Am 18.02.22 um 10:33 schrieb Michal Suchanek:
Since switch to simpledrm VESA graphic modes are no longer available
with legacy BIOS.
The x86 realmode boot cod
Add support for the 14" innolux,n140hca-eac eDP panel.
Signed-off-by: Rex Nie
---
drivers/gpu/drm/panel/panel-edp.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index f7bfcf63d48e..f5f9c9cb2
Add support for InnoLux n140hca-eac display panel. It is a 14" eDP panel
with 1920x1080 display resolution.
Signed-off-by: Rex Nie
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/p
On 17.02.2022 16:13, Eric Dumazet wrote:
On Thu, Feb 17, 2022 at 6:05 AM Andrzej Hajda wrote:
Library can be called in non-sleeping context, so it should not use
__GFP_NOFAIL. Instead it should calmly handle allocation fails, for
this __GFP_NOWARN has been added as well.
Your commit changel
On 17.02.2022 15:48, Ville Syrjälä wrote:
On Thu, Feb 17, 2022 at 03:04:38PM +0100, Andrzej Hajda wrote:
-static noinline depot_stack_handle_t
+static intel_wakeref_t
track_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm)
{
- depot_stack_handle_t stack, *stacks;
- unsign
Hi,
Sorry for jumping in in the middle of the thread I did
not notice this thread before.
On 2/16/22 13:00, Emil Velikov wrote:
> On Tue, 15 Feb 2022 at 16:37, Simon Ser wrote:
>>
>> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov
>> wrote:
>>
>>> On Tue, 15 Feb 2022 at 13:55, Simon Ser
Quoting Andi Shyti (2022-02-17 17:53:58)
> Hi Tvrtko,
>
> > > Now tiles have their own sysfs interfaces under the gt/
> > > directory. Because RC6 is a property that can be configured on a
> > > tile basis, then each tile should have its own interface
> > >
> > > The new sysfs structure will have
Since switch to simplefb/simpledrm VESA graphic modes are no longer
available with legacy BIOS.
The x86 realmode boot code enables the VESA graphic modes when option
FB_BOOT_VESA_SUPPORT is enabled.
To enable use of VESA modes with simpledrm in legacy BIOS boot mode drop
dependency of BOOT_VESA_S
On 17.02.2022 16:23, Eric Dumazet wrote:
On Thu, Feb 17, 2022 at 6:05 AM Andrzej Hajda wrote:
In cases references are taken alternately on multiple exec paths leak
report can grow substantially, sorting and grouping leaks by stack_handle
allows to compact it.
Signed-off-by: Andrzej Hajda
R
Daniel any estimation when you will have time to take a closer look?
Or could anybody else take another look at this?
Thanks,
Christian.
Am 11.02.22 um 13:49 schrieb Christian König:
Hi guys,
by now that should be a rather well known set of changes.
The basic idea is that instead of the fixe
On 18.02.2022 11:03, Ville Syrjala wrote:
From: Ville Syrjälä
Add a variant of drm_mode_copy() that explicitly clears out
the list head of the destination mode. Helpful to guarantee
we don't have stack garbage left in there for on-stack modes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu
The new bits of proposed uAPI for the upcoming small BAR support.
--
2.34.1
Add an entry for the new uapi needed for small BAR on DG2+.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 153 +
We already completed the steps for this.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_gem_lmem.rst | 22 --
Documentation/gpu/
On 18.02.2022 11:03, Ville Syrjala wrote:
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the
- Some DPU versions support inline rot90. It is supported only for
limited amount of UBWC formats.
- There are two versions of inline rotators, v1 (present on sm8250 and
sm7250) and v2 (sc7280). These versions differ in the list of supported
formats and in the scaler possibilities.
Changes in RFC:
Hi
Am 18.02.22 um 11:51 schrieb Michal Suchanek:
Since switch to simplefb/simpledrm VESA graphic modes are no longer
available with legacy BIOS.
The x86 realmode boot code enables the VESA graphic modes when option
FB_BOOT_VESA_SUPPORT is enabled.
To enable use of VESA modes with simpledrm in
On Friday, February 18th, 2022 at 11:38, Hans de Goede
wrote:
> What I'm reading in the above is that it is being considered to allow
> changing the panel-orientation value after the connector has been made
> available to userspace; and let userspace know about this through a uevent.
>
> I belie
On Fri, 2022-02-18 at 12:03 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the hand rolled drm_mode_duplicate() with the
> real thing.
>
> @is_dup@
> @@
> drm_mode_duplicate(...)
> { ... }
>
> @depends on !is_dup@
> expression dev, oldmode;
> identifier newmode;
> @@
> - newmode
Hi Ville,
On Fri, Feb 18, 2022 at 12:04:01PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the hand rolled drm_mode_duplicate() with the
> real thing.
>
> @is_dup@
> @@
> drm_mode_duplicate(...)
> { ... }
>
> @depends on !is_dup@
> expression dev, oldmode;
> identifier newmode;
Hi,
On 2/18/22 12:39, Simon Ser wrote:
> On Friday, February 18th, 2022 at 11:38, Hans de Goede
> wrote:
>
>> What I'm reading in the above is that it is being considered to allow
>> changing the panel-orientation value after the connector has been made
>> available to userspace; and let usersp
On Fri, Feb 18, 2022 at 12:22:44PM +0100, Andrzej Hajda wrote:
>
>
> On 18.02.2022 11:03, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add a variant of drm_mode_copy() that explicitly clears out
> > the list head of the destination mode. Helpful to guarantee
> > we don't have stack garba
On Fri, Feb 18, 2022 at 12:36:10PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 18.02.22 um 11:51 schrieb Michal Suchanek:
> > Since switch to simplefb/simpledrm VESA graphic modes are no longer
> > available with legacy BIOS.
> >
> > The x86 realmode boot code enables the VESA graphic modes when
On Friday, February 18th, 2022 at 12:54, Hans de Goede
wrote:
> On 2/18/22 12:39, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 11:38, Hans de Goede
> > wrote:
> >
> >> What I'm reading in the above is that it is being considered to allow
> >> changing the panel-orientation value afte
On 18.02.2022 12:56, Ville Syrjälä wrote:
On Fri, Feb 18, 2022 at 12:22:44PM +0100, Andrzej Hajda wrote:
On 18.02.2022 11:03, Ville Syrjala wrote:
From: Ville Syrjälä
Add a variant of drm_mode_copy() that explicitly clears out
the list head of the destination mode. Helpful to guarantee
we
On Fri, 2022-02-18 at 15:57 +0800, David Gow wrote:
>
> Note that, while this does build again, it still segfaults on startup,
> so more work remains to be done.
That's probably just a lot more stuff getting included somehow?
> They are:
> - CONFIG_VFIO_PCI: Needs ioport_map/ioport_unmap.
> - CO
Hi Dan,
Thank you for catching this. I will look into it and post a patch.
Regards,
David
-Original Message-
From: Dan Carpenter
Sent: Friday, February 18, 2022 2:30 AM
To: Yat Sin, David
Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [bug report] drm/amdkf
Hi,
On 16.02.2022 17:59, Dave Stevenson wrote:
Hi All
Hopefully I've cc'ed all those that have bashed this problem around previously,
or are otherwise linked to DRM bridges.
There have been numerous discussions around how DSI support is currently broken
as it doesn't support initialising the P
On 2022-02-17 at 20:57:35 -0800, Jordan Justen wrote:
> Robert Beckett writes:
>
> > From: Matthew Auld
> >
> > On discrete platforms like DG2, we need to support a minimum page size
> > of 64K when dealing with device local-memory. This is quite tricky for
> > various reasons, so try to documen
Hi Sam
Am 18.02.22 um 11:14 schrieb Sam Ravnborg:
Hi Thomas,
On Thu, Feb 17, 2022 at 11:34:05AM +0100, Thomas Zimmermann wrote:
Improve the performance of sys_imageblit() by manually unrolling
the inner blitting loop and moving some invariants out. The compiler
failed to do this automatically.
18.02.2022 00:37, Thierry Reding пишет:
> On Thu, Feb 17, 2022 at 11:02:53PM +0300, Dmitry Osipenko wrote:
>> 17.02.2022 22:16, Thierry Reding пишет:
>>> From: Thierry Reding
>>>
>>> Hi all,
>>>
>>> this is the userspace part of the kernel patches that were recently
>>> merged into drm-next:
>>>
>
this series is built around the DisplayPort driver. The dpi/dpintf
driver and the added helper functions are required for the DisplayPort
driver to work.
Changes from v7:
As requested from CK Hu, I've split the DP driver into multiple patches
with initial support for eDP, then DP and finally Audi
From: Markus Schneider-Pargmann
DP_INTF is similar to DPI but does not have the exact same feature set
or register layouts.
DP_INTF is the sink of the display pipeline that is connected to the
DisplayPort controller and encoder unit. It takes the same clocks as
DPI.
Signed-off-by: Markus Schnei
From: Markus Schneider-Pargmann
This controller is present on several mediatek hardware. Currently
mt8195 and mt8395 have this controller without a functional difference,
so only one compatible field is added.
The controller can have two forms, as a normal display port and as an
embedded display
Add flexibility by moving the dpi limits to the board config
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_d
From: Markus Schneider-Pargmann
Similar to HDMI, DP uses audio infoframes as well which are structured
very similar to the HDMI ones.
This patch adds a helper function to pack the HDMI audio infoframe for
DP, called hdmi_audio_infoframe_pack_for_dp().
hdmi_audio_infoframe_pack_only() is split in
Hi,
On Thu, Feb 10, 2022 at 4:04 PM Bjorn Andersson
wrote:
>
> > +&mdss_edp {
> > + status = "okay";
> > +
> > + vdda-1p2-supply = <&vreg_l6b_1p2>;
> > + vdda-0p9-supply = <&vreg_l10c_0p8>;
> > + /delete-property/ pinctrl-names;
> > + /delete-property/ pinctrl-0;
>
> If the fi
Add flexibility by moving the dimension mask to board config
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 8c
Add flexibility by moving the dimension mask to the board config
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek
From: Markus Schneider-Pargmann
This patch adds two helper functions that extract the frequency and word
length from a struct cea_sad.
For these helper functions new defines are added that help translate the
'freq' and 'byte2' fields into real numbers.
Signed-off-by: Markus Schneider-Pargmann
Adds a bit of flexibility to support boards without CK/DE pol support
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek
Add flexibility by moving the swap shift value to board config
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 0d3acd0
From: Markus Schneider-Pargmann
This is a new driver that supports the integrated DisplayPort phy for
mediatek SoCs, especially the mt8195. The phy is integrated into the
DisplayPort controller and will be created by the mtk-dp driver. This
driver expects a struct regmap to be able to work on the
dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- Some features/functional components are not available for dpintf
which are now excluded from code
From: Markus Schneider-Pargmann
This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
It supports the mt8195, the embedded DisplayPort units. It offers
hot-plug-detection and DisplayPort 1.4 with up to 4 lanes.
The driver creates a child device for the phy. The child device will
nev
From: Jitao Shi
Implement the DP HDP debounce described in DP 1.4a 3.3.
Signed-off-by: Jitao Shi
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dp.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu
Adds a bit of flexibility to support boards without swap_input support
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dp
Add flexibility by moving the yuv422 en bit to board config
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index ec221e24e0
This patch adds External DisplayPort support to the mt8195 eDP driver.
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dp.c | 87 +++
1 file changed, 64 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm
Add flexibility by moving the csc_enable bit to board config
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index fcf88dcd8
From: Jitao Shi
DP 1.4a Section 2.8.7.1.5.6.1:
A DP Source device shall retry at least seven times upon receiving
AUX_DEFER before giving up the AUX transaction.
Aux should retry to send msg whether how many bytes.
Signed-off-by: Jitao Shi
Signed-off-by: Guillaume Ranquet
---
drivers/gpu/drm
1 - 100 of 235 matches
Mail list logo
