the configuration and wait for the hardware to respond.
Add the Komeda specific implementation for atomic_commit_hw_done() that
flushes and waits for flip done before calling
drm_atomic_helper_commit_hw_done().
The fix was prompted by a patch from Carsten Haitzler where he was trying to
solve the same
On 7/8/22 17:07, Liviu Dudau wrote:
On Mon, Jun 06, 2022 at 12:47:13PM +0100, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
If something has already set up the DPU before the komeda driver comes
up, it will fail to init because it was just writing to the SRST bit in
the GCU
On 7/11/22 11:13, Liviu Dudau wrote:
On Fri, Jul 08, 2022 at 07:03:37PM +0100, Carsten Haitzler wrote:
On 7/8/22 17:02, Liviu Dudau wrote:
On Mon, Jun 06, 2022 at 12:47:14PM +0100, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Hi Carsten,
Sometimes there is an extra
On 7/14/22 13:20, Robin Murphy wrote:
On 2022-07-11 11:13, Liviu Dudau wrote:
[...]
But nothing worrying. It does work, though doesn't compile due to:
drivers/gpu/drm/arm/display/komeda/komeda_kms.c: In function
‘komeda_kms_atomic_commit_hw_done’:
On 7/8/22 17:02, Liviu Dudau wrote:
On Mon, Jun 06, 2022 at 12:47:14PM +0100, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Hi Carsten,
Sometimes there is an extra dcm crtc state in the pipeline whose
penting vblank event has not been handled yet. We would previously
On 7/8/22 17:07, Liviu Dudau wrote:
On Mon, Jun 06, 2022 at 12:47:13PM +0100, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
If something has already set up the DPU before the komeda driver comes
up, it will fail to init because it was just writing to the SRST bit in
the GCU
From: Carsten Haitzler
Sometimes there is an extra dcm crtc state in the pipeline whose
penting vblank event has not been handled yet. We would previously
throw this out and the vblank event never triggers leading to hard
lockups higher up the stack where an expected vlank event never comes
back
From: Carsten Haitzler
If something has already set up the DPU before the komeda driver comes
up, it will fail to init because it was just writing to the SRST bit in
the GCU control register and ignoring others. This resulted in TBU
bringup stalling and init failing. By writing completely we
From: Carsten Haitzler
The komeda driver doesn't come up with a visible text (FB) mode VT by
default as it was missing legacy FB support. It's useful to have a
working text VT on a system for debug and general usability, so enable
it. You can always toggle CONFIG_FRAMEBUFFER_CONSOLE.
Signed-off
That seems sensible to me. It matches the kind of DT content I know
works. It's certainly more detailed now.
On 5/6/22 15:05, Andre Przywara wrote:
The Arm Komeda (aka Mali-D71) is a display controller that scans out a
framebuffer and hands a signal to a digital encoder to generate a DVI
or
On Mon, 11 Apr 2022 12:27:37 +0200 Hans de Goede said:
> Hi,
>
> On 4/7/22 20:58, Carsten Haitzler wrote:
> > On Thu, 7 Apr 2022 17:38:59 +0200 Hans de Goede said:
> >
> > Below you covered our usual /sys/class/backlight device friends... what
> > about DDC
electrical power or setting perceived brightness.
>
> Regards,
>
> Hans
>
>
> 1) The need to be able to map the backlight device to a specific display
> has become clear once more with the recent proposal to add DDCDI support:
> https://lore.kernel.org/lkml/20220403230850.2986-1-yusisameri...@gmail.com/
>
> 2)
> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
> Note this proposal included a method for userspace to be able to tell the
> kernel if the native/acpi_video/vendor backlight device should be used, but
> this has been solved in the kernel for years now:
> https://www.spinics.net/lists/linux-acpi/msg50526.html An initial
> implementation of this proposal is available here:
> https://cgit.freedesktop.org/~mperes/linux/log/?h=backlight
>
--
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com
This makes sense given the other patches in your series, but it seems as
yet no one has anything to say about this. I don't have anything
specific to comment on other than it seems to make the correct changes
to komeda given the rest.
Reviewed-by: Carsten Haitzler
On 1/11/22 10:18, Kandpal
Seems fine.
Reviewed-by: Carsten Haitzler
On 12/15/21 00:59, Javier Martinez Canillas wrote:
According to disable Documentation/admin-guide/kernel-parameters.txt, this
parameter can be used to disable kernel modesetting.
DRM drivers will not perform display-mode changes or accelerated
Seems fine.
Reviewed-by: Carsten Haitzler
On 12/15/21 00:59, Javier Martinez Canillas wrote:
According to disable Documentation/admin-guide/kernel-parameters.txt, this
parameter can be used to disable kernel modesetting.
DRM drivers will not perform display-mode changes or accelerated
Seems fine to me.
Reviewed-by: Carsten Haitzler
On 12/15/21 00:59, Javier Martinez Canillas wrote:
According to disable Documentation/admin-guide/kernel-parameters.txt, this
parameter can be used to disable kernel modesetting.
DRM drivers will not perform display-mode changes or accelerated
I sent an updated patch with the Fixes:
On 1/24/22 16:13, Steven Price wrote:
On 24/01/2022 15:13, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
Signed-off-by: Carsten Haitzler
To add the context
From: Carsten Haitzler
Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
Fixes: 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option")
Signed-off-by: Carsten Haitzler
---
drivers/gpu/drm/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
Sorry - I meant disregard THIS one - following patch is right.
On 1/24/22 14:58, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
Signed-off-by: Carsten Haitzler
---
drivers/gpu/drm/arm/Kconfig | 1 +
1
Sorry - noise. Ignore this one. Following one is fixed.
On 1/24/22 15:13, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
Signed-off-by: Carsten Haitzler
---
drivers/gpu/drm/arm/Kconfig | 1 +
1 file
From: Carsten Haitzler
Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
Signed-off-by: Carsten Haitzler
---
drivers/gpu/drm/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index 58a242871b28
From: Carsten Haitzler
Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
Signed-off-by: Carsten Haitzler
---
drivers/gpu/drm/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index 58a242871b28
On 12/3/21 13:08, Liviu Dudau wrote:
On Fri, Dec 03, 2021 at 10:28:15AM +, Steven Price wrote:
While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
On 12/3/21 14:15, Carsten Haitzler wrote:
On 12/3/21 10:09, Liviu Dudau wrote:
If drm_universal_plane_init() fails early we jump to the common
cleanup code
that calls komeda_plane_destroy() which in turn could access the
uninitalised
drm_plane and crash. Return early if an error is detected
On 12/3/21 10:09, Liviu Dudau wrote:
If drm_universal_plane_init() fails early we jump to the common cleanup code
that calls komeda_plane_destroy() which in turn could access the uninitalised
drm_plane and crash. Return early if an error is detected without going through
the common code.
or
more than that. If this is the case along with the above you have given, then I
see no reason for it to not be used by everyone other than the usual user
complaint of "too many dependencies (of a compositor)". :)
I'd definitely consider using it.
> What do you think? Could a
On 3/30/21 2:25 AM, Tian Tao wrote:
Fix the following coccicheck warning:
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING:
use scnprintf or sprintf
On 3/12/21 10:55 AM, Brian Starkey wrote:
(Adding back James again - did you use get_maintainer.pl?)
On Thu, Mar 11, 2021 at 12:08:46PM +, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
When setting up a readback connector that writes data back to memory
rather than
From: Carsten Haitzler
When setting up a readback connector that writes data back to memory
rather than to an actual output device (HDMI etc.), rounding was set
to round. As the DPU uses a higher internal number of bits when generating
a color value, this round-down back to 8bit ended up
On 3/9/21 11:36 AM, Brian Starkey wrote:
Hi Carsten, (+James for komeda)
Thanks for typing this up.
On Fri, Mar 05, 2021 at 04:38:53PM +, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
When setting up a readback conenctor that writes data back to memory
s/readback
From: Carsten Haitzler
When setting up a readback conenctor that writes data back to memory
rather than to an actual output device (HDMI etc.), rounding was ses
to round-down. As the DPU uses a higher internal number of bits when
generating a color value, this round-down back to 8bit ended up
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is buried inside the
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses
On 1/20/21 3:44 PM, Steven Price wrote:
Sent a new patch to list with updates as discussed.
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried/buried/
dp_for_each_set_bit
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is buried inside the
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses
On 1/21/21 4:40 PM, Steven Price wrote:
On 21/01/2021 12:22, Carsten Haitzler wrote:
On 1/20/21 3:44 PM, Steven Price wrote:
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried
On 1/20/21 3:44 PM, Steven Price wrote:
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried/buried/
Yup. typo not spotted by me. Thanks. Also - i spotted an accidental
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds
From: Carsten Haitzler
KASAN found this problem. find_first_bit() expects to look at a
pointer pointing to a long, but we look at a u32 - this is going to be
an issue with endianess but, KSAN already flags this as out-of-bounds
stack reads. This fixes it by just importing inot a local long
From: Carsten Haitzler
komeda_component_get_old_state() technically can return a NULL
pointer. komeda_compiz_set_input() even warns when this happens, but
then proceeeds to use that NULL pointer tocompare memory content there
agains the new sate to see if it changed. In this case, it's better
From: Carsten Haitzler
ret is not actually read after this (only written in one case then
returned), so this assign line is useless. This removes that assignment.
Signed-off-by: Carsten Haitzler
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 1 -
1 file changed, 1 deletion(-)
diff
40 matches
Mail list logo
