by: Thomas Zimmermann
---
drivers/gpu/drm/tidss/tidss_drv.c | 15 +--
drivers/gpu/drm/tidss/tidss_drv.h | 2 ++
drivers/gpu/drm/tidss/tidss_irq.c | 27 ---
drivers/gpu/drm/tidss/tidss_irq.h | 4 +---
4 files changed, 32 insertions(+), 16 deletions(-)
Reviewe
> struct drm_gem_object *omap_gem_prime_import(struct drm_device *dev,
> struct dma_buf *buffer);
>
> -vm_fault_t omap_gem_fault(struct vm_fault *vmf);
> int omap_gem_roll(struct drm_gem_object *obj, u32 roll);
> void omap_gem_cpu_sync_page(struct drm_gem_object *obj, int
On 28/02/17 14:55, Joe Perches wrote:
> Use a more common logging style.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
>
> Signed-off-by: Joe Perches
For omap:
Acked-by: Tomi Valkeinen
Tomi
signature.asc
Desc
e nice to have a review from Tomi since he pushed the bridge
chains debugfs.
Apart that it looks fine:
Reviewed-by: Neil Armstrong
This change does more than move the code to per-encoder debugfs file: it
changes the formatting, adding textual representations for the flags,
and drops the use of drm_printer.
I'd prefer to have such changes separately, but as it's a small patch I
guess it's fine-ish. But they should at least be mentioned in the patch
description.
With that addressed:
Reviewed-by: Tomi Valkeinen
Tomi
Hi,
On 29/04/2022 21:51, Dmitry Baryshkov wrote:
From all the drivers using drm_bridge_connector only iMX/dcss and OMAP
DRM driver do a proper work of calling
drm_bridge_connector_en/disable_hpd() in right places. Rather than
teaching each and every driver how to properly handle
drm_bridge_conn
On 29/04/2022 21:51, Dmitry Baryshkov wrote:
Now as all drivers stopped calling drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() it is safe to remove them complelely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 25 --
On 24/10/2022 18:39, Dmitry Baryshkov wrote:
Intruct two drm_connector_helper_funcs: enable_hpd() and disable_hpd().
"Introduce"?
They are called by drm_kms_helper_poll_enable() and
drm_kms_helper_poll_disable() (and thus drm_kms_helper_poll_init() and
drm_kms_helper_poll_fini()) respectively
deletions(-)
For the series:
Reviewed-by: Tomi Valkeinen
This fixes the issue (WARN for "Hot plug detection already enabled")
introduced by 09077bc3116581f4d1cb961ec359ad56586e370b, which you revert
in the third patch. You could mention this, maybe as a fixes tag and a
mention in the description.
Tomi
lts
in calling bridge->funcs->hpd_enable() before the rest of the pipeline
was set up properly.
For the series:
Reviewed-by: Tomi Valkeinen
I've been using this series in my local branch for quite a while to fix
the HPD issues. Works for me.
I still think the "fix" aspect
On 05/01/2023 14:31, Dmitry Baryshkov wrote:
On 04/01/2023 11:05, Neil Armstrong wrote:
On 04/01/2023 08:29, Tomi Valkeinen wrote:
On 28/12/2022 23:58, Dmitry Baryshkov wrote:
On 02/11/2022 20:06, Dmitry Baryshkov wrote:
From all the drivers using drm_bridge_connector only iMX/dcss and
OMAP
on,
we can eventually remove DRM's wrapper functions entirely.
v4:
* use initializer macros for struct fb_ops
v2:
* use FB_SYS_HELPERS option
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/Kconfig | 1 +
On 08/06/2023 19:26, Laurent Pinchart wrote:
Hi Doug,
On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König wrote:
On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
this patch series adapts the platform drivers below dri
On 19/01/2025 16:59, Sui Jingfeng wrote:
But userspace must be able to continue allocating YUV buffers through
CREATE_DUMB.
I think, allocating YUV buffers through CREATE_DUMB interface is just
an *abuse* and *misuse* of this API for now.
Take the NV12 format as an example, NV12 is YUV420 pla
Hi,
On 19/01/2025 13:29, Sui Jingfeng wrote:
Hi,
On 2025/1/16 18:35, Dmitry Baryshkov wrote:
On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote:
On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
wrote:
On 16/01/2025 10:09, Thomas Zimmermann wrote:
Am 15.01.25 um 15:20
Hi,
On 20/01/2025 09:49, Thomas Zimmermann wrote:
Hi
Am 16.01.25 um 11:03 schrieb Tomi Valkeinen:
[...]
Aligning video= and dumb buffers almost sounds like going backwards.
video= parameter is bad,
Who told you that? Video= is still the way to specify an initial display
mode to the kernel
Hi,
On 09/01/2025 16:57, Thomas Zimmermann wrote:
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch to a multiple of 8.
Signed-off-by: Thomas Zimmermann
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 15 +++
1 file
Hi,
On 15/01/2025 13:37, Thomas Zimmermann wrote:
Hi
Am 15.01.25 um 11:58 schrieb Tomi Valkeinen:
[...]
These are all good points. Did you read my discussion with Andy on
patch 2? I think it resolves all the points you have. The current
CREATE_DUMB
I had missed the discussion, and
Hi,
On 15/01/2025 14:34, Thomas Zimmermann wrote:
Hi
Am 15.01.25 um 13:06 schrieb Tomi Valkeinen:
Hi,
On 15/01/2025 13:37, Thomas Zimmermann wrote:
Hi
Am 15.01.25 um 11:58 schrieb Tomi Valkeinen:
[...]
These are all good points. Did you read my discussion with Andy on
patch 2? I think
Hi,
On 15/01/2025 12:26, Thomas Zimmermann wrote:
Hi
Am 15.01.25 um 11:13 schrieb Tomi Valkeinen:
Hi!
On 09/01/2025 16:57, Thomas Zimmermann wrote:
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed
Hi,
On 16/01/2025 11:38, Laurent Pinchart wrote:
On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
On Wed, Jan 15, 2025 at 02:34:26PM +, Daniel Stone wrote:
On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
No disagreement there, we need CREATE_DUMB2.
My point is that
Hi,
On 16/01/2025 10:09, Thomas Zimmermann wrote:
Hi
Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
[...]
My point is that we have the current UAPI, and we have userspace using
it, but we don't have clear rules what the ioctl does with specific
parameters, and we don't document
Hi,
On 16/01/2025 12:17, Geert Uytterhoeven wrote:
On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
wrote:
On 16/01/2025 10:09, Thomas Zimmermann wrote:
Am 15.01.25 um 15:20 schrieb Tomi Valkeinen:
[...]
My point is that we have the current UAPI, and we have userspace using
it, but we don&#
On 15/01/2025 15:45, Thomas Zimmermann wrote:
Hi
Am 15.01.25 um 14:33 schrieb Tomi Valkeinen:
[...]
Yeah, there are constrains in the scanline and buffer alignments and
orientation. And if we say that bpp==12 means NV12, it will be a
problem for all other cases where bpp==12 makes sense.
I
Hi!
On 09/01/2025 16:57, Thomas Zimmermann wrote:
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. Align the pitch according to hardware requirements.
Signed-off-by: Thomas Zimmermann
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
---
drivers/gpu/drm/xlnx
Hi,
On 20/02/2025 12:05, Thomas Zimmermann wrote:
Hi
Am 20.02.25 um 10:18 schrieb Tomi Valkeinen:
[...]
+ * Color modes of 10, 12, 15, 30 and 64 are only supported for use by
+ * legacy user space. Please don't use them in new code. Other modes
+ * are not support.
+ *
+ * Do not attem
Hi,
On 18/02/2025 16:23, Thomas Zimmermann wrote:
Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
scanline pitch and allocation size. Implementations of struct
drm_driver.dumb_create can call the new helper for their size
computations.
There is currently quite a bit of code dup
Hi,
On 21/02/2025 11:19, Thomas Zimmermann wrote:
Hi
Am 20.02.25 um 11:53 schrieb Tomi Valkeinen:
Hi,
On 20/02/2025 12:05, Thomas Zimmermann wrote:
Hi
Am 20.02.25 um 10:18 schrieb Tomi Valkeinen:
[...]
+ * Color modes of 10, 12, 15, 30 and 64 are only supported for use by
+ * legacy user
27 matches
Mail list logo
