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
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
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 have
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
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
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 have
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
omas 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
ned-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
immermann
> 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
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
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
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
t; 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() (Jani)
>
anout 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
ll 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:
>
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
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
> ---
>
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
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" ->
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 preferred. Let
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.
>
>
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
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
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,
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
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
-by: Javier Martinez Canillas
> Tested-by: Noralf Trønnes # drm/tiny/mi0283qt
> ---
Reviewed-by: Noralf Trønnes
-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 | 16
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()
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
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?
>>>
>>>
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:
&g
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
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 behind
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
: 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 imported buffer for CPU
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 # drm/tiny
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
gt; + struct drm_rect *rect)
> {
> struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(fb->dev);
> struct mipi_dbi *dbi = >dbi;
> @@ -125,7 +124,7 @@ static void st7586_fb_dirty(struct drm_framebuffer *fb,
> struct drm_rect *re
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
s 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
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
> + { 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 behind
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
From: Noralf Trønnes
In preparation for moving to the shadow plane helper prepare the
framebuffer for CPU access as early as possible.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/gud/gud_pipe.c | 67 +-
1 file changed, 33 insertions(+), 34
From: Noralf Trønnes
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 I came across Thomas' nice shadow
helper and thought, yes this is perfect for drm/gud. So
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
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
From: Noralf Trønnes
Complete the shadow fb access functions by also preparing imported buffers
for CPU access. Update the affected drivers that currently use
drm_gem_fb_begin_cpu_access().
Through this change the following SHMEM drivers will now also make sure
their imported buffers
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 get the entire patchset, even sta...@vger.kernel.org (cc'ed in a
>> fi
Den 22.11.2022 16.51, skrev Konstantin Ryabitsev:
> On Mon, Nov 21, 2022 at 07:13:28PM +0100, Noralf Trønnes wrote:
>>> Otherwise, you might consider using:
>>> https://b4.docs.kernel.org/en/latest/contributor/send.html#authenticating-with-the-web-submission-endp
Den 21.11.2022 16.19, skrev Maxime Ripard:
> On Mon, Nov 21, 2022 at 12:48:52PM +0100, Noralf Trønnes wrote:
>> A couple of years ago my email provider blocked me from using git
>> send-email with their smtp server. So I switched to the one my ISP
>> provides. Now m
Den 21.11.2022 18.06, skrev Simon Ser:
> On Monday, November 21st, 2022 at 18:02, Simon Ser
> wrote:
>
>> On Monday, November 21st, 2022 at 17:52, Noralf Trønnes nor...@tronnes.org
>> wrote:
>>
>>> Den 21.11.2022 14.33, skrev Simon Ser:
>>>
>&
Den 21.11.2022 14.33, skrev Simon Ser:
> I think you can apply for a linux.dev mailbox [1].
>
Yeah you're right, I didn't know about that possibility.
But it depends on whether or not I can just use their smtp server and
keep my current email address. This looks like what's the problem with
Den 21.11.2022 13.41, skrev Thomas Zimmermann:
> Hi
>
> Am 21.11.22 um 13:27 schrieb Noralf Trønnes:
>>
>>
>> Den 21.11.2022 11.45, skrev Thomas Zimmermann:
>>> Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
>>> drivers vmap/vunm
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
> drivers vmap/vunmap GEM buffer memory during the atomic commit.
> Shadow-plane helpers automate this process.
>
> Patches 1 to 4 prepare the MIPI code for the change and simplify
Hi
A couple of years ago my email provider blocked me from using git
send-email with their smtp server. So I switched to the one my ISP
provides. Now my ISP have outsourced their email service so the first 3
emails gets through and the rest looks like it ends up in a tar pit or
something, 18
Den 17.11.2022 10.28, skrev Maxime Ripard:
> That file is included directly, so we can't use any MODULE macro. Let's
> leave a comment to avoid any future mistake.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Noralf Trønnes
Den 12.11.2022 20.42, skrev Robert Swindells:
> Contributors to these files are:
>
> Noralf Trønnes
Acked-by: Noralf Trønnes
> Liu Zixian
> Dave Airlie
> Thomas Zimmermann
> Lucas De Marchi
> Gerd Hoffmann
> Rob Herring
> Jakub Kicinski
> Ma
Den 14.11.2022 14.00, skrev Maxime Ripard:
> KMS supports a number of named modes already, but it's never been
> documented anywhere, let's fix that.
>
> Signed-off-by: Maxime Ripard
>
> ---
Reviewed-by: Noralf Trønnes
t.c | 54
> +
> 2 files changed, 56 insertions(+)
>
This needs an entry in modedb.rst so people know named modes exist, with
that:
Reviewed-by: Noralf Trønnes
roper mode, and we
> thus can use the usual matching algo on timings, and can simply drop the
> name match.
>
> Suggested-by: Noralf Trønnes
> Signed-off-by: Maxime Ripard
>
> ---
Reviewed-by: Noralf Trønnes
; drm_display_mode we mean when passing a named mode.
>
> Tested-by: Mateusz Kwiatkowski
> Signed-off-by: Maxime Ripard
>
> ---
Reviewed-by: Noralf Trønnes
1 - 100 of 2448 matches
Mail list logo
