On Tue, 15 Mar 2022 at 00:23, Alex Deucher wrote:
>
> On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen wrote:
> >
> > On Thu, 10 Mar 2022 11:56:41 -0800
> > Rob Clark wrote:
> >
> > > For something like just notifying a compositor that a gpu crash
> > > happened, perhaps drm_event is more suitable
On Tuesday, March 15th, 2022 at 08:13, Dave Airlie wrote:
> Just one thing comes to mind reading this, racy PID reuse.
>
> process 1234 does something bad to GPU.
> process 1234 dies in parallel to sysfs notification being sent.
> other process 1234 reuses the pid
> new process 1234 gets destroye
Am 15.03.22 um 08:13 schrieb Dave Airlie:
On Tue, 15 Mar 2022 at 00:23, Alex Deucher wrote:
On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen wrote:
On Thu, 10 Mar 2022 11:56:41 -0800
Rob Clark wrote:
For something like just notifying a compositor that a gpu crash
happened, perhaps drm_event
Hi Tvrtko, Daniel,
>
> On 11/03/2022 09:39, Daniel Vetter wrote:
> > On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy
> > wrote:
> >>
> >> On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
> >> more framebuffers/scanout buffers results in only one that is mappable/
> >> fenceabl
On Tue, 15 Mar 2022 09:15:08 +1100 (AEDT)
Finn Thain wrote:
> Hi Geert,
>
> On Mon, 14 Mar 2022, Geert Uytterhoeven wrote:
>
> > On Mon, Mar 14, 2022 at 4:05 PM Pekka Paalanen wrote:
> >
> > > On Mon, 14 Mar 2022 14:30:18 +0100
> > > Geert Uytterhoeven wrote:
> > > > On Mon, Mar 7, 2022
Hi Geert,
On Mon, 14 Mar 2022, Geert Uytterhoeven wrote:
> On Mon, Mar 14, 2022 at 4:05 PM Pekka Paalanen wrote:
> > On Mon, 14 Mar 2022 14:30:18 +0100
> > Geert Uytterhoeven wrote:
> > > On Mon, Mar 7, 2022 at 9:53 PM Geert Uytterhoeven
> > > wrote:
> > > > Introduce fourcc codes for color-i
Hi Pekka,
On Tue, Mar 15, 2022 at 8:33 AM Pekka Paalanen wrote:
> On Tue, 15 Mar 2022 09:15:08 +1100 (AEDT)
> Finn Thain wrote:
> > On Mon, 14 Mar 2022, Geert Uytterhoeven wrote:
> > > On Mon, Mar 14, 2022 at 4:05 PM Pekka Paalanen
> > > wrote:
> > > > On Mon, 14 Mar 2022 14:30:18 +0100
> > >
On Tue, Mar 15, 2022 at 8:51 AM Geert Uytterhoeven wrote:
> > Also, when drm_fourcc.h is describing pixel formats, it needs to
> > consider only how a little-endian CPU accesses them. That's how pixel
> > data in memory is described. Display hardware plays no part in that.
> > It is the driver's j
From: T.J. Mercier
> Sent: 14 March 2022 23:45
>
> On Thu, Mar 10, 2022 at 11:33 AM Todd Kjos wrote:
> >
> > On Wed, Mar 9, 2022 at 8:52 AM T.J. Mercier wrote:
> > >
> > > The kernel interface should use types that the kernel defines instead of
> > > pid_t and uid_t, whose definiton is owned by
Dear Arunpravin,
Am 14.03.22 um 20:40 schrieb Arunpravin:
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Sign
On Tue, 15 Mar 2022 08:51:31 +0100
Geert Uytterhoeven wrote:
> Hi Pekka,
>
> On Tue, Mar 15, 2022 at 8:33 AM Pekka Paalanen wrote:
> > On Tue, 15 Mar 2022 09:15:08 +1100 (AEDT)
> > Finn Thain wrote:
> > > On Mon, 14 Mar 2022, Geert Uytterhoeven wrote:
> > > > On Mon, Mar 14, 2022 at 4:05 P
Fix a number of undefined references to drm_kms_helper.ko in
drm_dp_helper.ko:
arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
function `drm_dp_mst_duplicate_state':
drm_dp_mst_topology.c:(.text+0x2df0): undefined reference to
`__drm_atomic_helper_private_obj_duplicat
On Tue, 15 Mar 2022, Christoph Hellwig wrote:
> Just curious, what is the state of this seris? It would be good to
> have it ready early on for the next merge window as there is quite
> a backlog that depends on it.
Can't speak for the status of the series, but for drm the deadline for
changes h
On 15/03/22 1:49 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 14.03.22 um 20:40 schrieb Arunpravin:
>> handle a situation in the condition order-- == min_order,
>> when order = 0, leading to order = -1, it now won't exit
>> the loop. To avoid this problem, added a order check in
>> the s
Hi Pekka,
On Tue, Mar 15, 2022 at 9:46 AM Pekka Paalanen wrote:
> On Tue, 15 Mar 2022 08:51:31 +0100
> Geert Uytterhoeven wrote:
> > On Tue, Mar 15, 2022 at 8:33 AM Pekka Paalanen wrote:
> > > On Tue, 15 Mar 2022 09:15:08 +1100 (AEDT)
> > > Finn Thain wrote:
> > > > On Mon, 14 Mar 2022, Geert
I was actually testing it for almost two weeks, but still I met some hang and I
was trying to figure where the problem is as this is quite a big change. Let's
see if I can figure it out this week.
Thanks,
Zhi.
On 3/15/22 8:48 AM, Christoph Hellwig wrote:
> On Tue, Mar 15, 2022 at 10:46:53AM +02
Dear Arunpravin,
Am 15.03.22 um 10:01 schrieb Arunpravin:
On 15/03/22 1:49 pm, Paul Menzel wrote:
Am 14.03.22 um 20:40 schrieb Arunpravin:
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, add
upport-for-sc7280-target/20220315-124423
base: git://anongit.freedesktop.org/drm/drm drm-next
config: arm64-buildonly-randconfig-r002-20220313
(https://download.01.org/0day-ci/archive/20220315/202203151751.ov7gcuzi-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/ll
On Tue, 15 Mar 2022, Christoph Hellwig wrote:
> I know. I meant the next one, not the one ending now. And I don't
> want to miss another one.
Ok, good, thanks.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Hello YueHaibing,
Thanks for the patch.
On 3/12/22 07:34, YueHaibing wrote:
> WARNING: unmet direct dependencies detected for DRM_GEM_SHMEM_HELPER
> Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n]
> Selected by [m]:
> - DRM_SSD130X [=m] && HAS_IOMEM [=y] && DRM [=m]
>
> DRM_GEM_SHME
Remove the boilerplate of declaring a variable and using an if else
statement by using the ternary operator.
Signed-off-by: Paul Menzel
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/
On 15/03/2022 07:43, Vinod Polimera wrote:
- 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
On 15/03/2022 07:28, Kasireddy, Vivek wrote:
Hi Tvrtko, Daniel,
On 11/03/2022 09:39, Daniel Vetter wrote:
On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy wrote:
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that i
- 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:
On Tue, 15 Mar 2022 09:57:23 +0100
Geert Uytterhoeven wrote:
> Hi Pekka,
>
> On Tue, Mar 15, 2022 at 9:46 AM Pekka Paalanen wrote:
> > On Tue, 15 Mar 2022 08:51:31 +0100
> > Geert Uytterhoeven wrote:
> > > On Tue, Mar 15, 2022 at 8:33 AM Pekka Paalanen
> > > wrote:
> > > > On Tue, 15 Mar
On 14/03/2022 10:00, Rex-BC Chen wrote:
> Add aal binding for MT8183.
>
> Signed-off-by: Rex-BC Chen
> Acked-by: Rob Herring
> ---
> .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/d
On Sun, 13 Mar 2022, Lee Shawn C wrote:
> According to HDMI 2.1 spec.
>
> "The HDMI Forum EDID Extension Override Data Block (HF-EEODB)
> is utilized by Sink Devices to provide an alternate method to
> indicate an EDID Extension Block count larger than 1, while
> avoiding the need to present a VES
As the temporary buffer is no longer used to store 8-bit grayscale data,
its size can be reduced to the size needed to store the monochrome
bitmap data.
Fixes: 24c6bedefbe71de9 ("drm/repaper: Use format helper for xrgb to
monochrome conversion")
Signed-off-by: Geert Uytterhoeven
---
Untested
The rectangle update functions ssd130x_fb_blit_rect() and
ssd130x_update_rect() do not behave correctly when x1 != 0 or y1 !=
0, or when y1 or y2 are not aligned to display page boundaries.
E.g. when used as a text console, only the first line of text is shown
on the display.
1. The buffer passe
The conversion functions drm_fb_xrgb_to_mono() and
drm_fb_gray8_to_mono_line() do not behave correctly when the
horizontal boundaries of the clip rectangle are not multiples of 8:
a. When x1 % 8 != 0, the calculated pitch is not correct,
b. When x2 % 8 != 0, the pixel data for the last byte
Hi all,
This patch series contains fixes and improvements for the XRGB888 to
monochrome conversion in the DRM core, and for its users.
This has been tested on an Adafruit FeatherWing 128x32 OLED, connected
to an OrangeCrab ECP5 FPGA board running a 64 MHz VexRiscv RISC-V
softcore, using a
ssd130x_clear_screen() allocates a temporary buffer sized to hold one
byte per pixel, while it only needs to hold one bit per pixel.
ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one
byte per pixel for the whole frame buffer, while it only needs to hold
one bit per pixel for th
There is no "reversed" handling in drm_fb_xrgb_to_mono_reversed():
the function just converts from color to grayscale, and reduces the
number of grayscale levels from 256 to 2 (i.e. brightness 0-127 is
mapped to 0, 128-255 to 1). All "reversed" handling is done in the
repaper driver, where thi
|This seems more natural to me than the previous version. Acked-by:
Nirmoy Das |
Nirmoy
On 14/03/2022 12:28, Matthew Auld wrote:
On integrated it looks like the GGTT base should always 1:1 maps to
somewhere within DSM. On discrete the base seems to be pre-programmed with
a normal lmem address
On Mon, 14 Mar 2022 at 19:32, Arunpravin
wrote:
>
> handle instances when size is not aligned with the min_page_size.
> Unigine Heaven has allocation requests for example required pages
> are 161 and alignment request is 128. To allocate the left over
> 33 pages, continues the iteration to find th
On 14/03/2022 19:40, Arunpravin wrote:
handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC
Signed-off-by: Arunpravin
Hello Geert,
Thanks for your patch.
On 3/15/22 12:07, Geert Uytterhoeven wrote:
> There is no "reversed" handling in drm_fb_xrgb_to_mono_reversed():
> the function just converts from color to grayscale, and reduces the
> number of grayscale levels from 256 to 2 (i.e. brightness 0-127 is
> map
On Mon, Mar 14, 2022 at 03:59:06PM +0900, Byungchul Park wrote:
> On Sat, Mar 12, 2022 at 01:53:26AM +, Hyeonggon Yoo wrote:
> > On Fri, Mar 04, 2022 at 04:06:19PM +0900, Byungchul Park wrote:
> > > Hi Linus and folks,
> > >
> > > I've been developing a tool for detecting deadlock possibilitie
On 3/15/22 12:07, Geert Uytterhoeven wrote:
> The conversion functions drm_fb_xrgb_to_mono() and
> drm_fb_gray8_to_mono_line() do not behave correctly when the
> horizontal boundaries of the clip rectangle are not multiples of 8:
> a. When x1 % 8 != 0, the calculated pitch is not correct,
>
On 3/15/22 12:07, Geert Uytterhoeven wrote:
> The rectangle update functions ssd130x_fb_blit_rect() and
> ssd130x_update_rect() do not behave correctly when x1 != 0 or y1 !=
> 0, or when y1 or y2 are not aligned to display page boundaries.
> E.g. when used as a text console, only the first line of
On 3/15/22 12:07, Geert Uytterhoeven wrote:
> ssd130x_clear_screen() allocates a temporary buffer sized to hold one
> byte per pixel, while it only needs to hold one bit per pixel.
>
> ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one
> byte per pixel for the whole frame buffer
On Mon, 14 Mar 2022, Drew Davenport wrote:
> On Mon, Mar 14, 2022 at 10:40:47AM +0200, Jani Nikula wrote:
>> On Sun, 13 Mar 2022, Lee Shawn C wrote:
>> > drm_find_cea_extension() always look for a top level CEA block. Pass
>> > ext_index from caller then this function to search next available
>>
On 3/15/22 12:07, Geert Uytterhoeven wrote:
> As the temporary buffer is no longer used to store 8-bit grayscale data,
> its size can be reduced to the size needed to store the monochrome
> bitmap data.
>
> Fixes: 24c6bedefbe71de9 ("drm/repaper: Use format helper for xrgb to
> monochrome conv
Hi Andy,
On Tue, 15 Mar 2022 at 06:46, Andy Yan wrote:
> On 3/11/22 16:33, Sascha Hauer wrote:
> > The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB
> > board. Overlay support is tested with the modetest utility. AFBC support
> > on the cluster windows is tested with weston-simp
Greetings everyone,
Food for thought: Would it make sense to have the madvise ioctl as
generic DRM one?
Looking around - i915, msm & panfrost already have one and the virtio
implementation [below] seems as generic as it gets.
On Mon, 14 Mar 2022 at 22:44, Dmitry Osipenko
wrote:
> +#define VIRTG
On Mon, 14 Mar 2022 at 22:44, Dmitry Osipenko
wrote:
> Dmitry Osipenko (8):
> drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling
> drm/virtio: Check whether transferred 2D BO is shmem
> drm/virtio: Unlock GEM reservations in error code path
These three are legitimate fixes tha
Hi Javier,
On Tue, Mar 15, 2022 at 1:18 PM Javier Martinez Canillas
wrote:
> On 3/15/22 12:07, Geert Uytterhoeven wrote:
> > The conversion functions drm_fb_xrgb_to_mono() and
> > drm_fb_gray8_to_mono_line() do not behave correctly when the
> > horizontal boundaries of the clip rectangle are
Hi Javier,
On Tue, Mar 15, 2022 at 1:32 PM Javier Martinez Canillas
wrote:
> On 3/15/22 12:07, Geert Uytterhoeven wrote:
> > ssd130x_clear_screen() allocates a temporary buffer sized to hold one
> > byte per pixel, while it only needs to hold one bit per pixel.
> >
> > ssd130x_fb_blit_rect() allo
On 3/15/22 01:42, Dmitry Osipenko wrote:
> drm_gem_shmem_get_sg_table() never ever returned NULL on error. Correct
> the error handling to avoid crash on OOM.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/virtio/virtgpu_object.c | 6 --
> 1 file ch
On 3/15/22 15:47, Emil Velikov wrote:
> On Mon, 14 Mar 2022 at 22:44, Dmitry Osipenko
> wrote:
>
>> Dmitry Osipenko (8):
>> drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling
>> drm/virtio: Check whether transferred 2D BO is shmem
>> drm/virtio: Unlock GEM reservations in error
On Tue, Mar 15, 2022 at 12:07:03PM +0100, Geert Uytterhoeven wrote:
> There is no "reversed" handling in drm_fb_xrgb_to_mono_reversed():
> the function just converts from color to grayscale, and reduces the
> number of grayscale levels from 256 to 2 (i.e. brightness 0-127 is
> mapped to 0, 128-
Hi Andy,
On Tue, Mar 15, 2022 at 2:33 PM Andy Shevchenko
wrote:
> On Tue, Mar 15, 2022 at 12:07:03PM +0100, Geert Uytterhoeven wrote:
> > There is no "reversed" handling in drm_fb_xrgb_to_mono_reversed():
> > the function just converts from color to grayscale, and reduces the
> > number of gr
On Tue, Mar 15, 2022 at 12:07:04PM +0100, Geert Uytterhoeven wrote:
> The conversion functions drm_fb_xrgb_to_mono() and
> drm_fb_gray8_to_mono_line() do not behave correctly when the
> horizontal boundaries of the clip rectangle are not multiples of 8:
> a. When x1 % 8 != 0, the calculated p
On Tue, Mar 15, 2022 at 01:18:00PM +0100, Javier Martinez Canillas wrote:
> On 3/15/22 12:07, Geert Uytterhoeven wrote:
> > + for (i = 0; i < bits; i++, pixels--) {
>
> I think is worth to add a comment here explaining that the pixel is set to
> 1 for brightness > 127 and to 0 for brigh
On Mon, 14 Mar 2022 12:53:24 +0100, Julia Lawall wrote:
> Various spelling mistakes in comments.
> Detected with the help of Coccinelle.
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[21/30] spi: sun4i: fix typos in comments
commit: 20
On Tuesday, March 15, 2022 7:03 PM, Nikula, Jani wrote:
>On Sun, 13 Mar 2022, Lee Shawn C wrote:
>> According to HDMI 2.1 spec.
>>
>> "The HDMI Forum EDID Extension Override Data Block (HF-EEODB) is
>> utilized by Sink Devices to provide an alternate method to indicate an
>> EDID Extension Bloc
On Tue, Mar 15, 2022 at 12:07:06PM +0100, Geert Uytterhoeven wrote:
> ssd130x_clear_screen() allocates a temporary buffer sized to hold one
> byte per pixel, while it only needs to hold one bit per pixel.
>
> ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one
> byte per pixel fo
On Tue, Mar 15, 2022 at 12:07:07PM +0100, Geert Uytterhoeven wrote:
> As the temporary buffer is no longer used to store 8-bit grayscale data,
> its size can be reduced to the size needed to store the monochrome
> bitmap data.
bitmap API?
--
With Best Regards,
Andy Shevchenko
Hi Andy,
On Tue, Mar 15, 2022 at 2:50 PM Andy Shevchenko
wrote:
> On Tue, Mar 15, 2022 at 12:07:06PM +0100, Geert Uytterhoeven wrote:
> > ssd130x_clear_screen() allocates a temporary buffer sized to hold one
> > byte per pixel, while it only needs to hold one bit per pixel.
> >
> > ssd130x_fb_bli
On Mon, Mar 14, 2022 at 11:26 AM Pekka Paalanen wrote:
>
> On Mon, 14 Mar 2022 10:23:27 -0400
> Alex Deucher wrote:
>
> > On Fri, Mar 11, 2022 at 3:30 AM Pekka Paalanen wrote:
> > >
> > > On Thu, 10 Mar 2022 11:56:41 -0800
> > > Rob Clark wrote:
> > >
> > > > For something like just notifying a
On 15/03/22 4:56 pm, Matthew Auld wrote:
> On Mon, 14 Mar 2022 at 19:32, Arunpravin
> wrote:
>>
>> handle instances when size is not aligned with the min_page_size.
>> Unigine Heaven has allocation requests for example required pages
>> are 161 and alignment request is 128. To allocate the left
On Tuesday, March 15, 2022 8:33 PM, Nikula, Jani wrote:
>On Mon, 14 Mar 2022, Drew Davenport wrote:
>> On Mon, Mar 14, 2022 at 10:40:47AM +0200, Jani Nikula wrote:
>>> On Sun, 13 Mar 2022, Lee Shawn C wrote:
>>> > drm_find_cea_extension() always look for a top level CEA block.
>>> > Pass ext_in
On 15/03/22 2:35 pm, Paul Menzel wrote:
> Dear Arunpravin,
>
>
> Am 15.03.22 um 10:01 schrieb Arunpravin:
>
>> On 15/03/22 1:49 pm, Paul Menzel wrote:
>
>>> Am 14.03.22 um 20:40 schrieb Arunpravin:
handle a situation in the condition order-- == min_order,
when order = 0, leading to
Dear Arunpravin,
Am 15.03.22 um 16:42 schrieb Arunpravin:
On 15/03/22 2:35 pm, Paul Menzel wrote:
Am 15.03.22 um 10:01 schrieb Arunpravin:
On 15/03/22 1:49 pm, Paul Menzel wrote:
Am 14.03.22 um 20:40 schrieb Arunpravin:
handle a situation in the condition order-- == min_order,
when or
Applied. Thanks!
On Mon, Mar 14, 2022 at 8:01 AM Julia Lawall wrote:
>
> Various spelling mistakes in comments.
> Detected with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/gpu/drm/amd/pm/amdgpu_pm.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
Applied. Thanks!
Alex
On Mon, Mar 14, 2022 at 8:01 AM Julia Lawall wrote:
>
> Various spelling mistakes in comments.
> Detected with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |4 ++--
> 1 file changed, 2 insertions(+), 2 delet
Applied. Thanks!
On Mon, Mar 14, 2022 at 8:01 AM Julia Lawall wrote:
>
> Various spelling mistakes in comments.
> Detected with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/gpu/drm/amd/display/dc/bios/command_table.c |6 +++---
> 1 file changed, 3 insertions(+)
Applied. Thanks!
Alex
On Fri, Feb 18, 2022 at 11:28 AM Harry Wentland wrote:
>
>
>
> On 2022-02-18 05:03, Ville Syrjala wrote:
> > 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:
On Mon, 2022-03-14 at 19:08 -0700, Matt Roper wrote:
> From: John Harrison
>
> sseu_dev_info is already a pretty large structure which will likely
> continue to grow when future platforms increase potential DSS and EU
> counts. Let's switch the stack placement of this structure in debugfs
> with
On Mon, 2022-03-14 at 16:42 -0700, Matt Roper wrote:
> Add a new 'steering' node in each gt's debugfs directory that tells
> whether we're using explicit steering for various types of MCR ranges
> and, if so, what MMIO ranges it applies to.
>
> We're going to be transitioning away from implicit st
+Daniel for additional feedback!
On 2022-03-14 4:06 p.m., Michael Cheng wrote:
On 2022-03-08 10:58 a.m., Lucas De Marchi wrote:
On Tue, Feb 22, 2022 at 08:24:31PM +0100, Thomas Hellström (Intel)
wrote:
Hi, Michael,
On 2/22/22 18:26, Michael Cheng wrote:
This patch removes logic for wbinvd_
Add a new 'steering' node in each gt's debugfs directory that tells
whether we're using explicit steering for various types of MCR ranges
and, if so, what MMIO ranges it applies to.
We're going to be transitioning away from implicit steering, even for
slice/dss steering soon, so the information re
On Tue, Mar 15, 2022 at 03:21:05PM +, Lee, Shawn C wrote:
> On Tuesday, March 15, 2022 8:33 PM, Nikula, Jani
> wrote:
> >On Mon, 14 Mar 2022, Drew Davenport wrote:
> >> On Mon, Mar 14, 2022 at 10:40:47AM +0200, Jani Nikula wrote:
> >>> On Sun, 13 Mar 2022, Lee Shawn C wrote:
> >>> > drm_fin
On Mon, Mar 14, 2022 at 5:14 PM Uwe Kleine-König
wrote:
>
> Hello,
>
> this is another try to convince the relevant people that
> devm_clk_get_enabled() is a nice idea. Compared to v7 (back in May 2021) this
> series is rebased to v5.17-rc8 and converts quite some drivers that open code
> devm_clk
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 29 +++--
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 737ef3f4ab54..bb564b830c96 100644
--- a
Construct gem objects around stolen nodes.
This stops the abuse of interfaces and aids future patches that done use
drm nodes for stolen areas.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 72 --
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 6
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 385 ++---
drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 9 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 14 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.h| 7 +
4 files changed, 40 insertions(+),
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 55 ++
drivers/gpu/drm/i915/gem/i915_gem_region.h | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 84 ++
drivers/gpu/drm/i915/intel_memory_region.h | 6 ++
4 files changed, 136 in
RFC: do we want this to become a generic interface in
ttm_resource_manager_func?
RFC: would we prefer a different interface? e.g.
for_each_resource_in_range or for_each_bo_in_range
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 21 +
include/drm/
remove i915->mm.stolen
remove i915->mm.stolen_lock
they are no longer needed.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 --
drivers/gpu/drm/i915/gt/selftest_reset.c | 16 +---
drivers/gpu
RFC: should this become a generic interface in intel_memory_region_ops?
RFC: would we prefer an different interface? e.g. for_each_obj_in_range
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 19 +++
drivers/gpu/drm/i915/intel_region_ttm.h | 3 +++
2
Applied. Thanks!
Alex
On Fri, Feb 18, 2022 at 5:04 AM 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 whi
Applied. Thanks!
Alex
On Fri, Feb 18, 2022 at 11:32 AM Harry Wentland wrote:
>
>
>
> On 2022-02-18 05: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 desti
On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä
wrote:
>
> On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote:
> > drm: Add drm_mode_init()
> > drm/bridge: Use drm_mode_copy()
> > drm/imx: Use drm_mode_duplicate()
> > drm/panel: Use drm_mode_duplicate()
> > drm/vc4: Use drm_mode
Hi Javier
Am 08.03.22 um 18:51 schrieb Javier Martinez Canillas:
[...]
static struct drm_client_buffer *
-drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height,
u32 format)
+drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height,
u32 format,
There is a spelling mistake in a dev_error error message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
in
Hi Christophe,
On Fri, Mar 11, 2022 at 06:02:38PM +0100, Christophe Branchereau wrote:
> This driver supports the NewVision NV3052C based LCDs. Right now, it
> only supports the LeadTek LTK035C5444T 2.4" 640x480 TFT LCD panel, which
> can be found in the Anbernic RG-350M handheld console.
I had to
On Tue, Mar 15, 2022 at 09:45:59AM +0100, Thomas Zimmermann wrote:
> Fix a number of undefined references to drm_kms_helper.ko in
> drm_dp_helper.ko:
>
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_mst_duplicate_state':
> drm_dp_mst_topology.c:(.
There is a spelling mistake in a gvt_vgpu_err error message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 520a7e19
There is a spelling mistake in a nvdev_error error message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau
There are some vendor drivers for which the writeback encoder shares
hardware resources such as clocks and interrupts with the rest of the
display pipeline. In addition, there can be use-cases where the
writeback encoder could be a shared encoder between the physical display
path and the writeback
As part of this series, drm_writeback_connector_init() allows
passing possible_crtcs as a parameter so that the API can
internally create and setup the encoder.
Pass possible_crtcs parameter for drm_writeback_connector_init()
for komeda driver.
changes in v2:
- pass possible_crtcs parameter fo
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware, a
As part of this series, drm_writeback_connector_init() allows
passing possible_crtcs as a parameter so that the API can
internally create and setup the encoder.
Pass possible_crtcs parameter for drm_writeback_connector_init()
for vkms driver.
changes in v2:
- pass possible_crtcs parameter for
As part of this series, drm_writeback_connector_init() allows
passing possible_crtcs as a parameter so that the API can
internally create and setup the encoder.
Pass possible_crtcs parameter for drm_writeback_connector_init()
for malidp writeback driver.
changes in v2:
- pass possible_crtcs
As part of this series, drm_writeback_connector_init() allows
passing possible_crtcs as a parameter so that the API can
internally create and setup the encoder.
Pass possible_crtcs parameter for drm_writeback_connector_init()
for rcar-du writeback driver.
changes in v2:
- pass possible_crtcs pa
vc4 driver currently embeds the drm_encoder into struct vc4_txp
and later on uses container_of to retrieve the vc4_txp from
the drm_encoder.
Since drm_encoder has now been made a pointer inside
drm_writeback_connector, make vc4 driver use the new API
so that the embedded encoder model can be retai
Hi Laurent
Thank you for your inputs.
I liked all the suggestions, hence I have incorporated those and pushed
a v2.
Thanks
Abhinav
On 3/13/2022 7:50 AM, Laurent Pinchart wrote:
Hi Abhinav
On Fri, Mar 11, 2022 at 09:47:17AM -0800, Abhinav Kumar wrote:
On 3/10/2022 11:28 PM, Laurent Pincha
On Mon, Mar 14, 2022 at 04:42:02PM -0700, Matt Roper wrote:
From: Daniele Ceraolo Spurio
GuC has its own steering mechanism and can't use the default set by i915,
so we need to provide the steering information that the FW will need to
save/restore registers while processing an engine reset. The
On Mon, Mar 14, 2022 at 04:42:03PM -0700, Matt Roper wrote:
Upcoming patches will need to steer writes to multicast registers as
well as reading them.
Although the setting of the 'multicast' bit should only really matter
for write operations (reads always operate in a unicast manner and give
us
1 - 100 of 137 matches
Mail list logo
