On 07.09.2024 09:00, He Lugang wrote:
> Use devm_add_action_or_reset() to release resources in case of failure,
> because the cleanup function will be automatically called.
>
> Signed-off-by: He Lugang
> ---
> drivers/gpu/drm/gud/gud_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(
On 8/16/24 14:23, Thomas Zimmermann wrote:
> Call drm_client_setup() to run the kernel's default client setup
> for DRM. Set fbdev_probe in struct drm_driver, so that the client
> setup can start the common fbdev client.
>
> Signed-off-by: Thomas Zimmermann
&
On 8/16/24 14:23, Thomas Zimmermann wrote:
> Call drm_client_setup() to run the kernel's default client setup
> for DRM. Set fbdev_probe in struct drm_driver, so that the client
> setup can start the common fbdev client.
>
> Signed-off-by: Thomas Zimmermann
&
On 8/16/24 14:22, Thomas Zimmermann wrote:
> Call drm_client_setup() to run the kernel's default client setup
> for DRM. Set fbdev_probe in struct drm_driver, so that the client
> setup can start the common fbdev client.
>
> Signed-off-by: Thomas Zimmermann
&
On 8/16/24 14:22, Thomas Zimmermann wrote:
> Call drm_client_setup() to run the kernel's default client setup
> for DRM. Set fbdev_probe in struct drm_driver, so that the client
> setup can start the common fbdev client.
>
> Signed-off-by: Thomas Zimmermann
&
On 8/16/24 14:22, Thomas Zimmermann wrote:
> Call drm_client_setup() to run the kernel's default client setup
> for DRM. Set fbdev_probe in struct drm_driver, so that the client
> setup can start the common fbdev client.
>
> Signed-off-by: Thomas Zimmermann
&
On 6/4/24 15:20, Noralf Trønnes via B4 Relay wrote:
> Hi,
>
> In this version I've fixed up a commit message that I had forgotten to
> write before sending and improved a struct member name.
>
> See version 1 of the patchset for the full cover letter.
>
>
Hi,
In this version I've fixed up a commit message that I had forgotten to
write before sending and improved a struct member name.
See version 1 of the patchset for the full cover letter.
Signed-off-by: Noralf Trønnes
---
Changes in v4:
- Expand the commit message (Dmitry
From: Noralf Trønnes
MIPI DCS write/set commands have 8 bit parameters except for the
write_memory commands where it depends on the pixel format.
drm_mipi_dbi does currently only support RGB565 which is 16-bit and it
has to make sure that the pixels enters the SPI bus in big endian format
since
From: Noralf Trønnes
mipi_dbi_machine_little_endian() should really have been called
mipi_dbi_framebuffer_little_endian() because that's the function it
performs. When I added support for these SPI displays I thought that the
framebuffers on big endian machines were also big endian, but I
From: Noralf Trønnes
DRM_FORMAT_RGB888 is 24 bits per pixel and it would be natural to send it
on the SPI bus using a 24 bits per word transfer. The problem with this
is that not all SPI controllers support 24 bpw.
Since DRM_FORMAT_RGB888 is stored in memory as little endian and the SPI
bus is
From: Noralf Trønnes
The MIPI DBI 2.0 specification (2005) lists only two pixel formats for
the Type C Interface (SPI) and that is 3-bits/pixel RGB111 with
2 options for bit layout.
For Type A and B (parallel) the following formats are listed: RGB332,
RGB444, RGB565, RGB666 and RGB888 (some
From: Noralf Trønnes
Add support for these pixel format property values:
- r5g6b5, RGB565
- b6x2g6x2r6x2, BGR666
BGR666 is presented to userspace as RGB888. The 2 LSB in each color
are discarded by the controller. The pixel is sent on the wire using
8 bits per word (little endian) so the
From: Noralf Trønnes
DRM_FORMAT_RGB888 is 24 bits per pixel and it would be natural to send it
on the SPI bus using a 24 bits per word transfer. The problem with this
is that not all SPI controllers support 24 bpw.
Since DRM_FORMAT_RGB888 is stored in memory as little endian and the SPI
bus is
From: Noralf Trønnes
This prepares for supporting other pixel formats than RGB565.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_mipi_dbi.c | 14 ++
include/drm/drm_mipi_dbi.h | 5 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
From: Noralf Trønnes
The MIPI DBI 2.0 specification (2005) lists only two pixel formats for
the Type C Interface (SPI) and that is 3-bits/pixel RGB111 with
2 options for bit layout.
For Type A and B (parallel) the following formats are listed: RGB332,
RGB444, RGB565, RGB666 and RGB888 (some
From: Noralf Trønnes
mipi_dbi_machine_little_endian() should really have been called
mipi_dbi_framebuffer_little_endian() because that's the function it
performs. When I added support for these SPI displays I thought that the
framebuffers on big endian machines were also big endian, but I
coded for RGB565.
See version 1 of the patchset for the full cover letter.
Signed-off-by: Noralf Trønnes
---
Changes in v3:
- Added r-b's to patch 1 and 5
- Link to v2:
https://lore.kernel.org/r/20240512-panel-mipi-dbi-rgb666-v2-0-49dd26632...@tronnes.org
Changes in v2:
- binding: Use '
From: Noralf Trønnes
Add support for these pixel format property values:
- r5g6b5, RGB565
- b6x2g6x2r6x2, BGR666
BGR666 is presented to userspace as RGB888. The 2 LSB in each color
are discarded by the controller. The pixel is sent on the wire using
8 bits per word (little endian) so the
From: Noralf Trønnes
This prepares for supporting other pixel formats than RGB565.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_mipi_dbi.c | 14 ++
include/drm/drm_mipi_dbi.h | 5 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
From: Noralf Trønnes
Add support for these pixel format property values:
- r5g6b5, RGB565
- b6x2g6x2r6x2, BGR666
BGR666 is presented to userspace as RGB888. The 2 LSB in each color
are discarded by the controller. The pixel is sent on the wire using
8 bits per word (little endian) so the
From: Noralf Trønnes
DRM_FORMAT_RGB888 is 24 bits per pixel and it would be natural to send it
on the SPI bus using a 24 bits per word transfer. The problem with this
is that not all SPI controllers support 24 bpw.
Since DRM_FORMAT_RGB888 is stored in memory as little endian and the SPI
bus is
From: Noralf Trønnes
The MIPI DBI 2.0 specification (2005) lists only two pixel formats for
the Type C Interface (SPI) and that is 3-bits/pixel RGB111 with
2 options for bit layout.
For Type A and B (parallel) the following formats are listed: RGB332,
RGB444, RGB565, RGB666 and RGB888 (some
From: Noralf Trønnes
mipi_dbi_machine_little_endian() should really have been called
mipi_dbi_framebuffer_little_endian() because that's the function it
performs. When I added support for these SPI displays I thought that the
framebuffers on big endian machines were also big endian, but I
From: Noralf Trønnes
DRM_FORMAT_RGB888 is 24 bits per pixel and it would be natural to send it
on the SPI bus using a 24 bits per word transfer. The problem with this
is that not all SPI controllers support 24 bpw.
Since DRM_FORMAT_RGB888 is stored in memory as little endian and the SPI
bus is
From: Noralf Trønnes
This prepares for supporting other pixel formats than RGB565.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_mipi_dbi.c | 14 ++
include/drm/drm_mipi_dbi.h | 5 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
From: Noralf Trønnes
Add support for these pixel format property values:
- r5g6b5, RGB565
- b6x2g6x2r6x2, BGR666
BGR666 is presented to userspace as RGB888. The 2 LSB in each color
are discarded by the controller. The pixel is sent on the wire using
8 bits per word (little endian) so the
From: Noralf Trønnes
mipi_dbi_machine_little_endian() should really have been called
mipi_dbi_framebuffer_little_endian() because that's the function it
performs. When I added support for these SPI displays I thought that the
framebuffers on big endian machines were also big endian, but I
From: Noralf Trønnes
The MIPI DBI 2.0 specification (2005) lists only two pixel formats for
the Type C Interface (SPI) and that is 3-bits/pixel RGB111 with
2 options for bit layout.
For Type A and B (parallel) the following formats are listed: RGB332,
RGB444, RGB565, RGB666 and RGB888 (some
On 4/24/24 08:45, Krzysztof Kozlowski wrote:
> On 27/03/2024 18:48, Krzysztof Kozlowski wrote:
>> Core in spi_register_driver() already sets the .owner, so driver
>> does not need to.
>>
>> Signed-off-by: Krzysztof Kozlowski
>> ---
>> drivers/gpu/drm/tiny/ili9225.c | 1 -
>> 1 file changed, 1
On 4/26/24 09:28, Jani Nikula wrote:
> On Thu, 25 Apr 2024, Noralf Trønnes wrote:
>> On 4/22/24 14:10, Jani Nikula wrote:
>>> Never include where a forward declaration will suffice.
>>>
>>> Reviewed-by: Andrzej Hajda
>>>
On 4/22/24 14:10, Jani Nikula wrote:
> Never include where a forward declaration will suffice.
>
> Reviewed-by: Andrzej Hajda
> Acked-by: Maxime Ripard
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20240410141434.157908-2-jani.nik...@intel.com
> Signed-off-by: Jani Nikula
> ---
>
On 4/16/24 15:22, Jani Nikula wrote:
> Prefer struct drm_edid based functions over struct edid.
>
> Signed-off-by: Jani Nikula
>
> ---
>
Thanks,
Reviewed-by: Noralf Trønnes
y: Thomas Zimmermann
> Cc: "Noralf Trønnes"
> ---
> drivers/gpu/drm/tiny/mi0283qt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: Noralf Trønnes
On 3/12/24 16:45, Thomas Zimmermann wrote:
> Implement fbdev emulation with fbdev-shmem. Avoids the overhead of
> fbdev-generic's additional shadow buffering. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: "Noralf Trønnes"
> ---
Acked-by: Noralf Trønnes
; Signed-off-by: Thomas Zimmermann
> Cc: "Noralf Trønnes"
> ---
> drivers/gpu/drm/tiny/panel-mipi-dbi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: Noralf Trønnes
mas Zimmermann
> Cc: "Noralf Trønnes"
> ---
> drivers/gpu/drm/tiny/repaper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: Noralf Trønnes
On 12/8/23 17:00, Andy Shevchenko wrote:
> Included authors and latest (non-white-space) contributors to the drivers
> in question along with relevant mailing list and respective (active in the
> area) maintainers.
>
> I already had risen the question in times when 4th (sic!) driver for the sam
On 10/10/23 11:25, Maxime Ripard wrote:
>
>
> On Tue, Oct 10, 2023 at 10:55:09AM +0200, Thomas Zimmermann wrote:
So if I understand correctly, drm_panic would pre-allocate a plane/commit,
and use that when a panic occurs ?
>>>
>>> And have it checked already, yes. We would only wait
On 10/3/23 16:22, Jocelyn Falempe wrote:
> Add support for the drm_panic module, which displays a message to
> the screen when a kernel panic occurs.
>
> Signed-off-by: Jocelyn Falempe
> ---
> drivers/gpu/drm/mgag200/mgag200_drv.c | 24
> 1 file changed, 24 insertions
On 10/3/23 16:22, Jocelyn Falempe wrote:
> This module displays a user friendly message when a kernel panic
> occurs. It currently doesn't contain any debug information,
> but that can be added later.
>
> v2
> * Use get_scanout_buffer() instead of the drm client API.
> (Thomas Zimmermann)
>
On 10/5/23 11:04, Thomas Zimmermann wrote:
> DRM's format-conversion helpers require temporary memory. Pass the
> buffer from the caller and keep it allocated over several calls. Allow
> the caller to preallocate the buffer memory.
>
> The motivation for this patchset is the recent work on a DR
On 10/6/23 16:35, Maxime Ripard wrote:
> Hi Jocelyn,
>
> On Thu, Oct 05, 2023 at 11:16:15AM +0200, Jocelyn Falempe wrote:
>> On 05/10/2023 10:18, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Tue, Oct 03, 2023 at 04:22:45PM +0200, Jocelyn Falempe wrote:
diff --git a/include/drm/drm_drv.h b/inclu
e.
>
> Images in the format-helper tests are small. The tests preallocate
> a static page for the temporary buffer. Unloading the module releases
> the memory.
>
> v3:
> * store buffer in shadow-plane state (Javier, Maxime)
> * replace ARRAY_SIZE() with sizeof
he scanout buffer. The shadow plane provides the
> necessary state and manages the conversion's intermediate buffer memory.
>
> Signed-off-by: Thomas Zimmermann
> ---
Acked-by: Noralf Trønnes
ars all fields in struct drm_format_conv_state and installs a DRM
> + * release action for the buffer. The buffer will be empty with no
> + * preallocated resources.
You forgot to remove the release action note in this version.
With that fixed:
Acked-by: Noralf Trønnes
Hi,
On 9/15/23 10:28, Jocelyn Falempe wrote:
> This introduces a new drm panic handler, which displays a message when a
> panic occurs.
> So when fbcon is disabled, you can still see a kernel panic.
>
> This is one of the missing feature, when disabling VT/fbcon in the kernel:
> https://www.redd
On 8/16/23 21:55, Justin Stitt wrote:
> When building with clang 18 I see the following warning:
> | drivers/gpu/drm/tiny/repaper.c:952:11: warning: cast to smaller
> integer
> | type 'enum repaper_model' from 'const void *'
> [-Wvoid-pointer-to-enum-cast]
> | 952 |
On 7/24/23 08:56, Otto Pflüger wrote:
> When multiple displays are connected to the same SPI bus, the data/command
> switch is sometimes considered part of the bus and is shared among the
> displays.
>
> This series adds the GPIO_FLAGS_BIT_NONEXCLUSIVE flag for this GPIO and
> SPI bus locking t
On 7/20/23 12:26, Otto Pflüger wrote:
> Multiple displays may be connected to the same bus and share a D/C GPIO,
> so the display driver needs exclusive access to the bus to ensure that
> it can control the D/C GPIO safely.
>
> Signed-off-by: Otto Pflüger
> ---
> drivers/gpu/drm/drm_mipi_dbi.
On 7/20/23 12:26, Otto Pflüger wrote:
> Displays that are connected to the same SPI bus may share the D/C GPIO.
> Use GPIOD_FLAGS_BIT_NONEXCLUSIVE to allow access to the same GPIO for
> multiple panel-mipi-dbi instances. Exclusive access to the GPIO during
> transfers is ensured by the locking i
On 7/20/23 12:26, Otto Pflüger wrote:
> Multiple displays may be connected to the same bus and share a D/C GPIO,
> so the display driver needs exclusive access to the bus to ensure that
> it can control the D/C GPIO safely.
>
> Signed-off-by: Otto Pflüger
> ---
Reviewed-by: Noralf Trønnes
On 6/27/23 16:43, Julia Lawall wrote:
> Use vmalloc_array and vcalloc to protect against
> multiplication overflows.
>
> The changes were done using the following Coccinelle
> semantic patch:
>
> //
> @initialize:ocaml@
> @@
>
> let rename alloc =
> match alloc with
> "vmalloc" -> "vma
er-free boot.
>
> Signed-off-by: Leonard Göhrs
> Acked-by: Conor Dooley
> Reviewed-by: Rob Herring
> ---
Reviewed-by: Noralf Trønnes
> .../devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
> a/Docum
cked-by: Conor Dooley
> ---
Normally I would take this trough drm-misc-next but -rc6 is the cutoff
so if I do that it won't make it to 6.5. If the other patches make it to
6.5 the dtb checks will fail. I'm okay with the patches going through
another tree if that's
On 6/7/23 13:55, Leonard Göhrs wrote:
> Some MIPI DBI panels support a three wire mode (clock, chip select,
> bidirectional data) that can be used to ask the panel if it is already set
> up by e.g. the bootloader and can thus skip the initialization.
> This enables a flicker-free boot.
>
> Sign
On 3/2/23 13:01, Simon Ser wrote:
> On Tuesday, February 28th, 2023 at 16:16, Peter Stuge wrote:
>
>> Simon Ser wrote:
>>
> Would it be possible to set the PATH connector property based on the
> USB port used by gud?
Sadly not really easily.
The physical topology un
Hi Simon,
On 2/28/23 12:36, Simon Ser wrote:
> Hi Noralf,
>
> Would it be possible to set the PATH connector property based on the
> USB port used by gud?
>
> This would give user-space a persistent identifier for the connector:
> if the user plugs in a USB display on a given port, the PATH woul
On 1/5/23 13:57, Fabio Estevam wrote:
> Hi Noralf,
>
> On Fri, Dec 16, 2022 at 9:30 AM Noralf Trønnes wrote:
>
>> There is a DRM driver that can be used with all of these controllers:
>> drivers/gpu/drm/tiny/panel-mipi-dbi.c. It uses a firmware file for the
>>
les directly on gud_probe(),
> before drm_dev_register().
>
> Signed-off-by: Maíra Canal
> ---
Acked-by: Noralf Trønnes
Den 16.12.2022 12.54, skrev Fabio Estevam:
> Hi,
>
> Does anyone know if the Crystalfontz CFAF240320X0-020T display is
> supported in Linux?
>
> https://www.crystalfontz.com/product/cfaf240320x0020t-2inch-240x320-color-tft
>
> It uses a Sitronix ST7789V controller.
>
> For the ST7789V, there
Den 01.12.2022 17.02, skrev Otto Pflüger:
> As stated in
> Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yml,
> the MIPI DBI specification defines two power supplies, one for powering
> the panel and one for the I/O voltage. The panel-mipi-dbi driver
> currently only suppor
Den 08.12.2022 09.15, skrev Thomas Zimmermann:
> Hi
>
> Am 07.12.22 um 20:51 schrieb Noralf Trønnes via B4 Submission Endpoint:
>> From: Noralf Trønnes
>>
>> Add missing vmalloc.h include.
>>
>> Fixes: c17d048609bf ("drm/gud: Use the shadow plan
From: Noralf Trønnes
Add missing vmalloc.h include.
Fixes: c17d048609bf ("drm/gud: Use the shadow plane helper")
Reported-by: kernel test robot
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_pipe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/gud/
Den 30.11.2022 20.26, skrev Noralf Trønnes via B4 Submission Endpoint:
> Hi,
>
> I have started to look at igt for testing and want to use CRC tests. To
> implement support for this I need to move away from the simple kms
> helper.
>
> When looking around for examples
Den 01.12.2022 17.02, skrev Otto Pflüger:
> Add documentation for the new io-supply property, which specifies the
> regulator for the I/O voltage supply on platforms where the panel
> panel power and I/O supplies are separate.
>
> Signed-off-by: Otto Pflüger
> ---
Reviewed-by: Noralf Trønnes
Signed-off-by: Otto Pflüger
> ---
Reviewed-by: Noralf Trønnes
w. Add a new io_regulator property to
> the mipi_dbi_dev struct which can be set by the panel driver along
> with the regulator property.
>
> Signed-off-by: Otto Pflüger
> ---
Thanks for fixing this, I'll apply the patches in a few days.
Reviewed-by: Noralf Trønnes
Tested-by: Javier Martinez Canillas
> Tested-by: Noralf Trønnes # drm/tiny/mi0283qt
> ---
Reviewed-by: Noralf Trønnes
Tested-by: Javier Martinez Canillas
> Tested-by: Noralf Trønnes # drm/tiny/mi0283qt
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 85 ++
> drivers/gpu/drm/tiny/ili9225.c | 5 ++
> drivers/gpu/drm/tiny/st7586.c | 5 ++
> include/drm/drm_mipi_dbi.h
Den 02.12.2022 12.50, skrev Thomas Zimmermann:
>
>>>
>>> You use drm_gem_fb_vmap() in the other places but here you access the
>>> object directly (and in the next hunk), but again not so important since
>>> it goes away in a later patch.
>>
>> I'll update this patch to use drm_gem_fb_vmap() co
Den 02.12.2022 12.27, skrev Thomas Zimmermann:
> Hi
>
> Am 25.11.22 um 18:39 schrieb Noralf Trønnes:
>>
>>
>> Den 21.11.2022 11.45, skrev Thomas Zimmermann:
>>> Move the vmap/vunmap blocks from the inner fb_dirty helpers into the
>>> MIPI DBI upd
Den 01.12.2022 15.16, skrev Konstantin Ryabitsev:
> On Thu, Dec 01, 2022 at 02:34:41PM +0100, Javier Martinez Canillas wrote:
Konstantin,
Can you add a rule in b4 to exclude sta...@vger.kernel.org
(sta...@kernel.org as well?) from getting the whole patchset?
>>>
>>> sta...@ke
Den 01.12.2022 13.12, skrev Greg KH:
> On Thu, Dec 01, 2022 at 11:00:44AM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 01.12.2022 06.55, skrev Greg KH:
>>> On Wed, Nov 30, 2022 at 08:26:48PM +0100, Noralf Trønnes via B4 Submission
>>> Endpoint wrote:
>&
Den 01.12.2022 06.55, skrev Greg KH:
> On Wed, Nov 30, 2022 at 08:26:48PM +0100, Noralf Trønnes via B4 Submission
> Endpoint wrote:
>> Hi,
>>
>> I have started to look at igt for testing and want to use CRC tests. To
>> implement support for this I need to
From: Noralf Trønnes
gud has a module parameter that controls whether framebuffer flushing
happens synchronously during the commit or asynchronously in a worker.
GNOME before version 3.38 handled all displays in the same rendering loop.
This lead to gud slowing down the refresh rate for a
From: Noralf Trønnes
In preparation for inlining synchronous flushing split out the part of
gud_flush_work() that can be shared by the sync and async code paths.
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud
From: Noralf Trønnes
In preparation for moving to the shadow plane helper prepare the
framebuffer for CPU access as early as possible.
v2:
- Use src as variable name for iosys_map (Thomas)
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_pipe.c
From: Noralf Trønnes
UBSAN complains about invalid value for bool:
[ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1
[ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device
[ 101.213426] usbcore: registered new interface driver gud
[ 101.989431
From: Noralf Trønnes
Use the shadow plane helper to take care of mapping the framebuffer for
CPU access. The synchronous flushing is now done inline without the use of
a worker. The async path now uses a shadow buffer to hold framebuffer
changes and it doesn't read the framebuffer b
From: Noralf Trønnes
If a framebuffer flush fails the driver will do one retry by requeing the
worker. Currently the worker is used even for synchronous flushing, but a
later patch will inline it, so this needs to change. Thinking about how to
solve this I came to the conclusion that this retry
tategy.
Noralf.
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Noralf Trønnes
---
Changes in v2:
- Drop patch (Thomas):
drm/gem: shadow_fb_access: Prepare imported buffers for CPU access
- Use src as variable name for iosys_map (Thomas)
- Prepare imp
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Use the buffer mappings provided by shadow-plane helpers. As the
> mappings are established while the commit can still fail, errors
> are now reported correctly to callers.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Noralf Trønnes
Den 28.11.2022 13.10, skrev Thomas Zimmermann:
> Hi
>
> Am 25.11.22 um 18:48 schrieb Noralf Trønnes:
>>
>>
>> Den 21.11.2022 11.45, skrev Thomas Zimmermann:
>>> Introduce struct drm_mipi_dbi_plane_state that contains state related to
>>> MIP
rce code.
>
> Patch 8 simplifies drm_dev_enter() and _exit(). It's not strictly
> needed, but streamlines the driver code and make sense overall.
>
> Testing is welcome, as I don't have any hardware to test these
> changes myself.
>
Tested-by: Noralf Trønnes
e in order to make the code more readable, the other
*_fb_dirty call sites (*_enable) are already protected.
Reviewed-by: Noralf Trønnes
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Introduce struct drm_mipi_dbi_plane_state that contains state related to
> MIPI DBI. It currently only inherits from struct drm_shadow_plane_state,
> so that MIPI DBI drivers can use the vmap'ed GEM-buffer memory. Implement
> state helpers, the {b
t;
> -static void st7586_fb_dirty(struct drm_framebuffer *fb, struct drm_rect
> *rect)
> +static void st7586_fb_dirty(struct iosys_map *src, struct drm_framebuffer
> *fb,
> + struct drm_rect *rect)
> {
> struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi
l.
At least hx8357d managed to update the display mode variable name,
ili9163 didn't. It's not unlikely that I reviewed these drivers...
But that has nothing to do with this patch:
Reviewed-by: Noralf Trønnes
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> MIPI DBI drivers validate each mode against their native resolution.
> Add this test to st7586.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Noralf Trønnes
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> MIPI DBI drivers validate each mode against their native resolution.
> Add this test to ili9225.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Noralf Trønnes
elpers and remove . No functional changes.
>
> Simple-KMS drivers that implement the prepare_fb callback should call
> drm_gem_plane_helper_prepare_fb() directly.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Noralf Trønnes
solution for these NTSC and PAL modes, but AIUI this is part of a
grander plan to support devices with other timings.
Acked-by: Noralf Trønnes
SC-443" },
> + { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" },
> + { DRM_MODE_TV_MODE_PAL, "PAL" },
> + { DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
> + { DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
> + { DRM_MODE_TV_MODE_SECAM, "SECAM
Den 23.11.2022 09.22, skrev Javier Martinez Canillas:
> Hello Noralf,
>
> On 11/22/22 21:58, Noralf Trønnes via B4 Submission Endpoint wrote:
>> From: Noralf Trønnes
>>
>> Complete the shadow fb access functions by also preparing imported buffers
>> for CPU ac
Den 23.11.2022 11.38, skrev Thomas Zimmermann:
> Hi
>
> Am 22.11.22 um 21:58 schrieb Noralf Trønnes via B4 Submission Endpoint:
>> From: Noralf Trønnes
>>
>> Use the shadow plane helper to take care of preparing the framebuffer for
>> CPU access. The synchr
Den 23.11.2022 09.39, skrev Thomas Zimmermann:
> (cc: danvet)
>
> Hi
>
> Am 22.11.22 um 21:58 schrieb Noralf Trønnes via B4 Submission Endpoint:
>> From: Noralf Trønnes
>>
>> Complete the shadow fb access functions by also preparing imported
>> buffers
Den 22.11.2022 20.22, skrev Noralf Trønnes:
>
>
> Den 22.11.2022 19.50, skrev Konstantin Ryabitsev:
>> On Tue, Nov 22, 2022 at 06:42:19PM +0100, Noralf Trønnes wrote:
>>> The first thing that strikes me is that everyone mentioned in one of the
>>> patches
From: Noralf Trønnes
Use the shadow plane helper to take care of preparing the framebuffer for
CPU access. The synchronous flushing is now done inline without the use of
a worker. The async path now uses a shadow buffer to hold framebuffer
changes and it doesn't read the framebuffer b
From: Noralf Trønnes
In preparation for inlining synchronous flushing split out the part of
gud_flush_work() that can be shared by the sync and async code paths.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_pipe.c | 72 +++---
1 file changed
1 - 100 of 1121 matches
Mail list logo
