on to 640x480, which is
inconvenient, and breaks the anaconda installer.
So when no EDID is present, set 1024x768 as preferred resolution.
Fixes: fae7d186403e ("drm/probe-helper: Default to 640x480 if no EDID on DP")
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c | 26
On 23/06/2023 10:28, Thomas Zimmermann wrote:
Am 17.05.23 um 15:41 schrieb Tom Rix:
smatch reports
drivers/gpu/drm/mgag200/mgag200_drv.c:23:5: warning: symbol
'mgag200_modeset' was not declared. Should it be static?
This variable is only used in its defining file, so it should be static
This patch was already sent by Tom Rix last month:
https://patchwork.freedesktop.org/series/117881/
I can push it to drm-misc-next, if Thomas is ok.
Best regards,
--
Jocelyn
On 21/06/2023 21:11, Sui Jingfeng wrote:
drivers/gpu/drm/mgag200/mgag200_drv.c:23:5: warning: symbol
On 31/05/2023 09:08, Thomas Zimmermann wrote:
Hi
Am 30.05.23 um 16:26 schrieb Jocelyn Falempe:
I've contributed to these two drivers, fixing bugs and performance
issues.
Thanks for the work you're doing.
Signed-off-by: Jocelyn Falempe
Acked-by: Thomas Zimmermann
Applied to drm
to be done in the same place
and affect each other.
Tested on AST1100 and AST2300.
I've also tested (remotely) on AST2600
For the whole series:
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe
Thomas Zimmermann (14):
drm/ast: Fix DRAM init on AST2200
drm/ast: Remove vga2_clone
On 15/06/2023 16:24, Thomas Zimmermann wrote:
Hi Jocelyn
Am 31.05.23 um 11:21 schrieb Jocelyn Falempe:
Even if the transfer is not faster, it brings significant
improvement in latencies and CPU usage.
CPU usage drops from 100% of one core to 3% when continuously
refreshing the screen.
I
4 => pitch / 16
scale:
16bit:
scale = (1 << bppshift) - 1 => 1
24bit:
scale = ((1 << bppshift) * 3) - 1 => 2
32bit:
scale = (1 << bppshift) - 1 => 3
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 63 +++---
1 file change
Register irq, and enable the softrap irq.
This patch has no functional impact since softrap
irq can't be triggered without DMA.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 38 +++
drivers/gpu/drm/mgag200/mgag200_reg.h | 3 +++
2 files
to make sure,
the DMA transfer is a multiple of 32bits. The padded bytes won't be
drawn on the screen, so they don't need to be initialized.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/Makefile | 3 +-
drivers/gpu/drm/mgag200/mgag200_dma.c | 237
From: Thomas Zimmermann
Register constants are upper case. Fix MGAREG_Status accordingly.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Gerd Hoffmann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +++---
drivers/gpu/drm/mgag200/mgag200_reg.h | 2 +-
2 files changed, 4 insertions(+), 4
uld always work.
- Fix the warning reported by the kernel test bot.
Signed-off-by: Jocelyn Falempe
I've contributed to these two drivers, fixing bugs and performance
issues.
Signed-off-by: Jocelyn Falempe
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 250518fc70ff..92a991643b36 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6398,6
On 09/05/2023 11:49, Jocelyn Falempe wrote:
On 08/05/2023 10:04, Thomas Zimmermann wrote:
Hi Jocelyn
Am 05.05.23 um 14:43 schrieb Jocelyn Falempe:
[cut]
+ /* pad each line to 32bits boundaries see section 4.5.7 of G200
Specification */
+ int width_padded = round_up(width * cpp, 4
@@ -20,7 +20,7 @@
#include "mgag200_drv.h"
-int mgag200_modeset = -1;
+static int mgag200_modeset = -1;
MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
module_param_named(modeset, mgag200_modeset, int, 0400);
It looks good to me,
Reviewed-by: Jocelyn Falempe
--
Jocelyn
On 11/05/2023 14:26, Thomas Zimmermann wrote:
Hi
Am 10.05.23 um 15:10 schrieb Jocelyn Falempe:
When mgag200 switched from simple KMS to regular atomic helpers,
the initialization of the gamma settings was lost.
This leads to a black screen, if the bios/uefi doesn't use the same
pixel color
/show_bug.cgi?id=2171155
Fixes: 1baf9127c482 ("drm/mgag200: Replace simple-KMS with regular atomic
helpers")
Cc:
Tested-by: Phil Oester
Reviewed-by: Thomas Zimmermann
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 5 +
1 file changed, 5 insertion
On 10/05/2023 11:15, Thomas Zimmermann wrote:
Hi,
oh great! Thank you for fixing this bug. And sorry that I broke it.
Am 10.05.23 um 10:54 schrieb Jocelyn Falempe:
When mgag200 switched from simple KMS to regular atomic helpers,
the initialization of the gamma settings was lost.
This leads
ag200: Replace simple-KMS with regular atomic
helpers")
Tested-by: Phil Oester
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mo
On 08/05/2023 10:04, Thomas Zimmermann wrote:
Hi Jocelyn
Am 05.05.23 um 14:43 schrieb Jocelyn Falempe:
Even if the transfer is not faster, it brings significant
improvement in latencies and CPU usage.
I think I shot down this patch already. I don't want to maintain the
extra code for DMA
On 08/05/2023 09:44, Thomas Zimmermann wrote:
Hi
Am 05.05.23 um 14:43 schrieb Jocelyn Falempe:
Now that the driver handles only 16, 24 and 32-bit framebuffer,
it can be simplified.
I think it should say that the driver never really handled 8-bit colors.
Or at least I'm not aware of.
Ok I
Register irq, and enable the softrap irq.
This patch has no functional impact since softrap
irq can't be triggered without DMA.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 41 +++
drivers/gpu/drm/mgag200/mgag200_drv.h | 3 ++
drivers/gpu
to make sure,
the DMA transfer is a multiple of 32bits. The padded bytes won't be
drawn on the screen, so they don't need to be initialized.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/Makefile | 3 +-
drivers/gpu/drm/mgag200/mgag200_dma.c | 114 +
drivers
files changed, 362 insertions(+), 56 deletions(-)
Signed-off-by: Jocelyn Falempe
base-commit: 457391b0380335d5 (tag: v6.3)
From: Thomas Zimmermann
Register constants are upper case. Fix MGAREG_Status accordingly.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Gerd Hoffmann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +++---
drivers/gpu/drm/mgag200/mgag200_reg.h | 2 +-
2 files changed, 4 insertions(+), 4
3 / 16 => pitch / 16
32bit: (bppshift = 2)
offset = width >> (4 - bppshift) => width / 4 => pitch / 16
scale:
16bit:
scale = (1 << bppshift) - 1 => 1
24bit:
scale = ((1 << bppshift) * 3) - 1 => 2
32bit:
scale = (1 << bppshift) - 1 => 3
Signed-off-by: Jo
On 25/04/2023 17:03, Thomas Zimmermann wrote:
(cc'ing dri-devel, Jocelyn and Sam)
Hi Phil,
I've put dri-devel into cc, which is the developer's mailing list. It's
the first time I hear about this bug.
Thanks for pointing this to me, I will take a look at it.
--
Jocelyn
Am 25.04.23 um
On 13/04/2023 21:29, Thomas Zimmermann wrote:
Hi
Am 12.04.23 um 15:39 schrieb Jocelyn Falempe:
The bandwidth between system memory and VRAM is very limited
on G200.
So when using a 32bit framebuffer on system memory, convert it to 24bit
when copying the frame to the VRAM, this allows to go 33
On 12/04/2023 17:13, Javier Martinez Canillas wrote:
Jocelyn Falempe writes:
The bandwidth between system memory and VRAM is very limited
on G200.
So when using a 32bit framebuffer on system memory, convert it to 24bit
when copying the frame to the VRAM, this allows to go 33% faster
on my Dell T310:
1280x1024 32bits: ~125ms to transfert a single frame.
1280x1024 24bits: ~95ms
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 28 --
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mgag200
3 / 16 => pitch / 16
32bit: (bppshift = 2)
offset = width >> (4 - bppshift) => width / 4 => pitch / 16
scale:
16bit:
scale = (1 << bppshift) - 1 => 1
24bit:
scale = ((1 << bppshift) * 3) - 1 => 2
32bit:
scale = (1 << bppshift) - 1 => 3
Signed-off-by: Jo
The bandwidth between system memory and VRAM is very limited
on G200.
So when using a 32bit framebuffer on system memory, convert it to 24bit
when copying the frame to the VRAM, this allows to go 33% faster.
Converting the format on the fly is negligible, even on low end CPU.
[PATCH 1/2]
On 10/02/2023 01:33, Jammy Huang wrote:
On 2023/2/9 下午 05:55, Thomas Zimmermann wrote:
Am 09.02.23 um 10:44 schrieb Jocelyn Falempe:
During the driver conversion to shmem, the start address for the
scanout buffer was set to the base PCI address.
In most cases it works because only the lower
: f2fa5a99ca81 ("drm/ast: Convert ast to SHMEM")
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c7443317c747..66a4a41c3
can see in ast_set_cursor_base() that only the lower 26 bits are used.
--
Jocelyn
Best regard
Thomas
On 2023/2/9 下午 05:12, Jocelyn Falempe wrote:
During the driver conversion to shmem, the start address for the
scanout buffer was set to the base PCI address.
In most cases it works because
set = st->vram_fb_available - size;
On 2023/2/9 下午 05:12, Jocelyn Falempe wrote:
During the driver conversion to shmem, the start address for the
scanout buffer was set to the base PCI address.
In most cases it works because only the lower 24bits are used, and
due to alignment it was almost always 0
is displayed on the BMC.
With shmem, the primary plane is always at offset 0 in GPU memory.
Tested on a sr645 affected by this bug.
Fixes: f2fa5a99ca81 ("drm/ast: Convert ast to SHMEM")
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c | 3 ++-
1 file changed, 2 insert
On 07/02/2023 12:36, Jocelyn Falempe wrote:
On 07/02/2023 12:17, Thomas Zimmermann wrote:
Hi
I was wondering if this start address is not an offset in the GPU
memory, and in this case the primary plane offset should always be 0 ?
I think it's the case, so I will send a v2 shortly.
Best
On 07/02/2023 12:17, Thomas Zimmermann wrote:
Hi
Am 07.02.23 um 11:53 schrieb Jocelyn Falempe:
During the driver conversion to shmem, there is a missing page shift when
computing the start address in GPU memory.
This leads to graphic garbage when connecting to the remote BMC,
depending
nvert ast to SHMEM")
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c7443317c747..d75e4a7611b3 100644
--- a/drivers/gpu/drm/ast/ast_mo
On 12/01/2023 16:56, Nathan Chancellor wrote:
Hi Jocelyn,
On Thu, Jan 12, 2023 at 11:08:17AM +0100, Jocelyn Falempe wrote:
This patch does also solve a kernel crash when reading
/sys/class/drm/card1/gt/gt0/* on a skylake machine:
https://bugzilla.redhat.com/show_bug.cgi?id=2154880
Hi,
This patch does also solve a kernel crash when reading
/sys/class/drm/card1/gt/gt0/* on a skylake machine:
https://bugzilla.redhat.com/show_bug.cgi?id=2154880
Do you think it can be backported to stable releases ?
Conflicts are trivial on top of v6.0 at least.
Thanks,
--
Jocelyn
On
not a problem in ast's x86-based systems.
The error report is at [1].
Reported-by: kernel test robot
Signed-off-by: Thomas Zimmermann
Fixes: f2fa5a99ca81 ("drm/ast: Convert ast to SHMEM")
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
L
3.10.22 um 15:28 schrieb Jocelyn Falempe:
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);
Tested on G200_SE_A rev 42
Thi
rm/mgag200: Store values (not bits) in struct
mgag200_pll_values")
Cc: sta...@vger.kernel.org
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_g200se.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_g200se.c
b/drivers/g
On 13/10/2022 12:36, Ville Syrjälä wrote:
On Thu, Oct 13, 2022 at 11:05:19AM +0200, Thomas Zimmermann wrote:
Hi
Am 13.10.22 um 10:29 schrieb Jocelyn Falempe:
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous c
On 13/10/2022 11:05, Thomas Zimmermann wrote:
Hi
Am 13.10.22 um 10:29 schrieb Jocelyn Falempe:
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pix
with
commit 85397f6bc4ff ("drm/mgag200: Initialize each model in separate
function") but can be easily backported before this commit.
Fixes: 2dd040946ecf ("drm/mgag200: Store values (not bits) in struct
mgag200_pll_values")
Cc: sta...@vger.kernel.org
Signed-off-by: Jocelyn Fale
Thanks a lot for your series. This solves a big performance impact when
using Gnome/Wayland on some Aspeed chip, with BMC.
This also remove the need for "shadowFB" workaround in userspace.
With the small change in patch 8, and the two typo's,
the whole series is
Reviewed-by: Jocel
On 10/10/2022 12:36, Thomas Zimmermann wrote:
Replace GEM VRAM helpers with GEM SHMEM helpers in ast. Avoids OOM
errors when allocating video memory. Also adds support for dma-buf
functionality.
Aspeed display hardware supports display resolutions of FullHD and
more at 32-bit pixel depth. But
On 10/10/2022 12:36, Thomas Zimmermann wrote:
Hold I/O-register lock in atomic_commit_tail to protect all pipeline
updates at once. Protects modesetting against concurrent EDID reads.
Complex modesetting operations involve mode changes and plane updates.
These steps used to be protected
On 11/10/2022 16:59, Thomas Zimmermann wrote:
Hi
Am 11.10.22 um 16:21 schrieb Jocelyn Falempe:
On 10/10/2022 12:36, Thomas Zimmermann wrote:
Some AST-based BMCs stop display output for up to 5 seconds after
reprogramming the scanout address. As the address is fixed, avoid
re-setting
On 10/10/2022 12:36, Thomas Zimmermann wrote:
Some AST-based BMCs stop display output for up to 5 seconds after
reprogramming the scanout address. As the address is fixed, avoid
re-setting the address' value.
Reported-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm
On 30/09/2022 12:45, Thomas Zimmermann wrote:
Hi,
looks good to me. Let's wait until next week before landing the patch,
so that others can comment on it.
applied to drm-misc-next
Thanks,
--
Jocelyn
Best regards
Thomas
Am 30.09.22 um 11:47 schrieb Jocelyn Falempe:
The current ast
e format
changes.
remove rgb888 format that is not used.
Signed-off-by: Jocelyn Falempe
Tested-by: Thomas Zimmermann
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 87 +++---
1 file changed, 70 insertions(+), 17 deletions(-)
diff --git a
another review below. I'm sorry for the incorrect reply earlier.
No problem, without proper hardware to test, and good documentation,
it's hard to guess right what the hardware will do at first attempt.
Am 30.09.22 um 08:54 schrieb Jocelyn Falempe:
The current ast driver only supports
VGA output. But when activating "Night Light"
in Gnome, ast_crtc_load_lut() is called.
v2: use the same functions as mgag200.
handle 16bits color mode.
v3: Check gamma_lut size in atomic check.
Signed-off-by: Jocelyn Falempe
Tested-by: Thomas Zimmermann
Reviewed-by: Thomas Zimmerma
On 29/09/2022 17:27, Thomas Zimmermann wrote:
Hi
Am 29.09.22 um 15:20 schrieb Jocelyn Falempe:
The current ast driver only supports legacy gamma interface.
This also fixes a Gnome3/Wayland error which incorrectly adds
gamma to atomic commit:
"Page flip discarded: CRTC property (GAMM
VGA output. But when activating "Night Light"
in Gnome, ast_crtc_load_lut() is called.
v2: use the same functions as mgag200.
handle 16bits color mode.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c | 94 --
1 file changed,
VGA output. But when activating "Night Light"
in Gnome, ast_crtc_load_lut() is called.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c | 35 +-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode
affected.
I think it may have a performance penalty, I will try to measure it.
Reviewed-by: Jocelyn Falempe
--
Jocelyn
Reported-by: Wang Yugui
Signed-off-by: Thomas Zimmermann
Tested-by: Wang Yugui
Fixes: 73f54d5d9682 ("drm/mgag200: Remove special case for G200SE with <2 MiB")
std=gnu11 to compile your code
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/dcn32_fpu.c:982:11: error:
unused variable 'i' [-Werror=unused-variable]
uint32_t i = 0;
Fixes: f5b9c1ffabce ("drm/amd/display: Re-initialize viewport after pipe merge")
Signed-off-by: Jocelyn Falempe
-
On 28/07/2022 20:31, Thomas Zimmermann wrote:
Hi Jocelyn
Am 28.07.22 um 17:09 schrieb Jocelyn Falempe:
On 28/07/2022 14:40, Thomas Zimmermann wrote:
Drop simple-KMS in favor of regular atomic helpers. Makes the code
more modular and hence better to adapt to per-model requirements.
The simple
-by: Thomas Zimmermann
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 8 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 382 +++--
2 files changed, 233 insertions(+), 157 deletions(-)
diff --git
) was done only when
enabling/disabling display.
With this patch, it will be done for each frame, which will negatively
impact performances.
--
Jocelyn
Signed-off-by: Thomas Zimmermann
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe
Acked-by: Sam Ravnborg
---
drivers/gpu/drm
the same.
I've read the whole serie, and it's good overall.
I agree with Sam about the duplication of the DAC-registers setup, but
that can be solved later.
I have also tested this patchset on a G200eW, and have seen no regression.
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe
.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
Fixes: ce19021fd99a ("drm/mgag200: Move PCI-option setup into model-specific
code")
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/mgag200/mgag200
On 28/06/2022 10:43, Thomas Zimmermann wrote:
Hi
Am 27.06.22 um 19:25 schrieb Linus Torvalds:
On Mon, Jun 27, 2022 at 1:02 AM Javier Martinez Canillas
wrote:
The flag was dropped because it was causing drivers that requested their
memory resource with pci_request_region() to fail with
On 27/06/2022 09:39, Thomas Zimmermann wrote:
Am 27.06.22 um 09:31 schrieb Jocelyn Falempe:
On 23/06/2022 10:21, Jocelyn Falempe wrote:
On 22/06/2022 20:34, Lyude Paul wrote:
Some small nitpicks:
On Wed, 2022-06-22 at 14:48 +0200, Jocelyn Falempe wrote:
With an AST2600, the screen
On 23/06/2022 10:21, Jocelyn Falempe wrote:
On 22/06/2022 20:34, Lyude Paul wrote:
Some small nitpicks:
On Wed, 2022-06-22 at 14:48 +0200, Jocelyn Falempe wrote:
With an AST2600, the screen is garbage when going out of suspend.
This is because color settings are lost, and not restored
insertions(+), 12 deletions(-)
base-commit: 822a8442835012ce405080cb40f6317ef1e854ac
the whole serie looks good to me,
Acked-by Jocelyn Falempe
On 22/06/2022 20:34, Lyude Paul wrote:
Some small nitpicks:
On Wed, 2022-06-22 at 14:48 +0200, Jocelyn Falempe wrote:
With an AST2600, the screen is garbage when going out of suspend.
This is because color settings are lost, and not restored on resume.
Force the color settings on DPMS_ON
://www.aspeedtech.com/support_driver/
Signed-off-by: Jocelyn Falempe
Tested-by: Venkat Tadikonda
---
drivers/gpu/drm/ast/ast_mode.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 3eb9afecd9d4..cdddcb5c4439
On 09/06/2022 04:32, Kuo-Hsiang Chou wrote:
Hi Jocelyn Falempe,
-Original Message-
From: Jocelyn Falempe [mailto:jfale...@redhat.com]
Sent: Wednesday, June 08, 2022 9:17 PM
To: Kuo-Hsiang Chou ; Thomas Zimmermann
; airl...@redhat.com; airl...@linux.ie; dan...@ffwll.ch;
regressi
On 08/06/2022 10:09, Kuo-Hsiang Chou wrote:
Hi Thomas
Thanks for your suggestions!
I answer each revision inline that followed by [KH]:.
Thanks for reviewing this.
Regards,
Kuo-Hsiang Chou
-Original Message-
From: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
Sent:
T2600 in the AST2500 branches reverts back to the original
settings. The exception are cases where AST2600 meanwhile got its own
branch.
Reported-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
Suggested-by: Jocelyn Falempe
Fixes: f9bd00e0ea9d ("drm/ast: Create chip AST2600")
Cc: K
with G200 and G200EV hardware.
Thanks for this refactoring.
I've also tested this patchset on a G200eW, and have seen no regression.
For the whole series:
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe
Thomas Zimmermann (10):
drm/mgag200: Remove special case for G200SE with <2
On 01/06/2022 12:33, Thomas Zimmermann wrote:
Hi Jocelyn,
thanks for reporting this bug.
Am 01.06.22 um 11:33 schrieb Jocelyn Falempe:
Hi,
I've found a regression in the ast driver, for AST2600 hardware.
before the upstream commit f9bd00e0ea9d
https://git.kernel.org/pub/scm/linux/kernel/git
Hi,
I've found a regression in the ast driver, for AST2600 hardware.
before the upstream commit f9bd00e0ea9d
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f9bd00e0ea9d9b04140aa969a9a13ad3597a1e4e
The ast driver handled AST 2600 chip like an AST 2500.
After this
://drm.pages.freedesktop.org/maintainer-tools/commit-access.html
for how to do that.
I pushed the patches with the requested changes to drm-misc-next last
Thursday.
Thanks a lot for your help.
--
Jocelyn
Best regards
Thomas
Am 04.05.22 um 15:40 schrieb Jocelyn Falempe:
mgag200: Improve damage handling
I pushed it to drm-misc-next.
Thanks,
--
Jocelyn
t to %p4cc for 4cc and %zu for size_t
- rebased to drm-misc-next.
Signed-off-by: Jocelyn Falempe
Tested-by: Thomas Zimmermann
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 127 -
1 file changed, 83 insertions(+), 44 deletions(-)
diff --git
...
} else if (mdev->type == G200_ER) {
return 55000;
}
/* No bandwidth defined */
return 0;
}
then in mgag200_mode_config_mode_valid()
int g200_bandwidth = mgag200_get_bandwidth_kbps(mdev);
if (g200_bandwidth && mgag200_calculate_mode_band
On 12/05/2022 10:52, Thomas Zimmermann wrote:
Hi
Am 11.05.22 um 17:28 schrieb Jocelyn Falempe:
Add support for atomic update of gamma lut.
With this patch the "Night light" feature of gnome3
is working properly on mgag200.
v2:
- Add a default linear gamma function
- renamed
for 16bits gamma
- remove legacy function mga_crtc_load_lut()
- can't remove the call to drm_mode_crtc_set_gamma_size()
because it doesn't work with userspace.
- other small refactors
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 125 ---
On 09/05/2022 18:04, Michel Dänzer wrote:
On 2022-05-09 16:22, Thomas Zimmermann wrote:
It might also make sense to adjust the starting value of the lut table such
that its final entry is used for the final entry in the HW palette. For typical
gamma ramps ~2, the curve is fairly flat for
Jocelyn Falempe:
Add support for atomic update of gamma lut.
With this patch the "Night light" feature of gnome3
is working properly on mgag200.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 46 ++
1 file changed, 46 insertion
Add support for atomic update of gamma lut.
With this patch the "Night light" feature of gnome3
is working properly on mgag200.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 46 ++
1 file changed, 46 insertions(+)
diff --git a/d
initialization on I2C-
related errors.
Reviewed-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_i2c.c | 13 -
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 --
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers
://drm.pages.freedesktop.org/maintainer-tools/commit-access.html
for how to do that.
Thanks for your reviews.
I created the issue to get commit access :
https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/433
Best regards,
--
Jocelyn
Best regards
Thomas
Am 04.05.22 um 15:40 schrieb Jocelyn Falempe
Some MGA200 hardware are broken, and can't use a start address > 0
v2: Warn if startaddr is not 0, and hw doesn't support it.
(instead of removing MGAG200_FLAG_HW_BUG_NO_STARTADD)
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 3 +++
1 file changed, 3 inserti
When there are multiple damage clips, previous code merged them into one
big rectangle. As the Matrox memory is very slow, it's faster to copy each
damage clip.
Signed-off-by: Jocelyn Falempe
Reviewed-by: Lyude Paul
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c
.
With this patch, gnome/wayland becomes usable on Matrox GPU.
Suggested-by: Jonas Ådahl
Signed-off-by: Jocelyn Falempe
Reviewed-by: Lyude Paul
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mgag200
if startaddr is not 0, and hw doesn't
support it. (instead of removing the unused flag).
Thanks,
--
Jocelyn
Jocelyn Falempe (3):
mgag200: Add FB_DAMAGE_CLIPS support
mgag200: Optimize damage clips
mgag200: Warn once if trying to set start address on broken hardware.
drivers/gpu/drm
v2 for it anyway.
It looks good to me,
Reviewed-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 6 ++
drivers/gpu/drm/mgag200/mgag200_drv.h | 1 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 14 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/mgag
On 04/05/2022 12:16, Thomas Zimmermann wrote:
Hi
Am 26.04.22 um 18:41 schrieb Jocelyn Falempe:
This function writes some pattern to video memory, to check for conflict.
In case of conflicts, it returns a random memory capacity (offset of the
conflict).
Using devm_arch_io_reserve_memtype_wc
On 04/05/2022 12:12, Thomas Zimmermann wrote:
Hi
Am 26.04.22 um 18:41 schrieb Jocelyn Falempe:
The flag MGAG200_FLAG_HW_BUG_NO_STARTADD is no more used, because
the framebuffer is now always at offset 0.
Oh, well. I remember that thing. It took us a long time to find and fix
this problem
On 04/05/2022 12:04, Thomas Zimmermann wrote:
Hi
Am 26.04.22 um 18:41 schrieb Jocelyn Falempe:
when there are multiple damage clips, previous code merged them into one
big rectangle. As the Matrox memory is very slow, it's faster to copy
each
damage clip.
Signed-off-by: Jocelyn Falempe
, as it is video memory, the user will
notice it easily. So there is no need for this function.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mm.c | 50
1 file changed, 7 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/mgag200
The flag MGAG200_FLAG_HW_BUG_NO_STARTADD is no more used, because
the framebuffer is now always at offset 0.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 3 +--
drivers/gpu/drm/mgag200/mgag200_drv.h | 3 ---
2 files changed, 1 insertion(+), 5 deletions(-)
diff
when there are multiple damage clips, previous code merged them into one
big rectangle. As the Matrox memory is very slow, it's faster to copy each
damage clip.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 15 ++-
1 file changed, 10 insertions(+), 5
401 - 500 of 519 matches
Mail list logo
