+1
I like the interface ver. :)
On 9/6/24 10:40 AM, Steven Price wrote:
The version number output when loading the firmware is actually the
interface version not the version of the firmware itself. Update the
message to make this clearer.
However, the firmware binary has a git SHA embedded int
On 9/5/24 10:08 PM, Liviu Dudau wrote:
On Thu, Sep 05, 2024 at 06:45:28PM +0200, Boris Brezillon wrote:
On Thu, 5 Sep 2024 16:51:44 +0100
Steven Price wrote:
The firmware binary has a git SHA embedded into it which can be used to
identify which firmware binary is being loaded. Output this
On 7/23/24 5:06 PM, Boris Brezillon wrote:
Hi Steve,
On Mon, 15 Jul 2024 10:12:16 +0100
Steven Price wrote:
I note it also shows that the "panthor_regs.rs" would ideally be shared.
For arm64 we have been moving to generating system register descriptions
from a text source (see arch/arm64/t
We did discuss this, but I've come to the conclusion that's the wrong
approach. Converting is going to need to track kernel closely as there
are lots of dependencies with the various rust abstractions needed. If
we just copy over the C driver, that's an invitation to diverge and
accumulate tech
From: Carsten Haitzler
In a few places (core drm + AMD kfd driver), the ioctl handling uses a
temporary 128 byte buffer on the stack to copy to/from user. ioctl data
can have structs with types of much larger sizes than a byte and a
system may require alignment of types in these. At the same
On 6/11/24 5:17 PM, T.J. Mercier wrote:
On Tue, Jun 11, 2024 at 2:35 AM wrote:
From: Carsten Haitzler
In a few places (core drm + AMD kfd driver), the ioctl handling uses a
temporary 128 byte buffer on the stack to copy to/from user. ioctl data
can have structs with types of much larger
From: Carsten Haitzler
In a few places (core drm + AMD kfd driver), the ioctl handling uses a
temporary 128 byte buffer on the stack to copy to/from user. ioctl data
can have structs with types of much larger sizes than a byte and a
system may require alignment of types in these. At the same
h 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
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’:
drivers/gpu/drm/arm/display/komeda/komeda_km
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.
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 HDM
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
gt; linearly controlling 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, Ka
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 co
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
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
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
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 58a2428
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 58a2428
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
drm
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.
Reporte
can't see the justification for
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 us
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
drivers/gpu/drm/arm/display/komeda/komeda
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 to an
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 with
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 bett
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
47 matches
Mail list logo
