Re: [Intel-gfx] [PATCH v5 08/13] drm/omapdrm: Use regular fbdev I/O helpers

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 + drivers/gpu/drm

Re: [Intel-gfx] [PATCH 16/22] drm/tilcdc: Use drm_mode_copy()

(, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Jyri Sarha Cc: Tomi Valkeinen Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/ti

Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core

. That would be silly. This also means I'm happy to put any other volunteer's name in the M: line, but otherwise git log says I'm the one who's stuck with this. Acked-by: Tomi Valkeinen Tomi

Re: [Intel-gfx] [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default

Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Jernej Skrabec Cc: Jyri Sarha Cc: Tomi Valkeinen Cc: linux-arm-ker...@lists.infradead.org Cc: linux-m...@vger.kernel.org Cc: linux-media...@lists.infradead.org Cc: linux-amlo...@lists.infradead.org Cc: linux-rockc...@lists.infradead.org Cc: linux-s

Re: [Intel-gfx] [PATCH 09/11] drm/omap: Follow implicit fencing in prepare_fb

On 21/05/2021 12:09, Daniel Vetter wrote: I guess no one ever tried running omap together with lima or panfrost, not even sure that's possible. Anyway for consistency, fix this. Signed-off-by: Daniel Vetter Cc: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_plane.c | 3 +++ 1 file changed

Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree

On 18/03/2021 03:02, Stephen Rothwell wrote: Hi all, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/omapdrm/dss/dsi.c between commit: 690911544275 ("drm/omap: dsi: fix unsigned expression compared with zero") from the drm-misc-fixes tree and commit:

Re: [Intel-gfx] [PATCH] fbcon: Disable accelerated scrolling

> - Fix typo in comment (Jiri) > - add a todo entry for the cleanup (Thomas) > > v3: Remove more unused variables (0day) > > Reviewed-by: Thomas Zimmermann > Reviewed-by: Greg Kroah-Hartman > Acked-by: Sam Ravnborg > Cc: Jiri Slaby > Cc: Bartlomiej Zolnierkiewicz

Re: [Intel-gfx] [PATCH 13/65] drm/omapdrm: Annotate dma-fence critical section in commit path

there wasn't a modeset done on a given crtc. > > For a bit more clarity pull the hw_done() call out of the if/else, > that way it's a bit clearer flow. But happy to shuffle this around as > is seen fit. > > Signed-off-by: Daniel Vetter > Cc: Tomi Valkeinen > --- >

Re: [Intel-gfx] [PATCH 10/20] drm/omapdrm: Introduce GEM object functions

_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 pgoff); > void oma

Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree

Hi Stephen, On 23/04/2020 06:17, Stephen Rothwell wrote: > Hi all, > > On Tue, 21 Apr 2020 09:10:25 +0300 Tomi Valkeinen > wrote: >> >> On 21/04/2020 04:52, Stephen Rothwell wrote: >>> >>> Today's linux-next merge of the drm-misc tree got a conflict

Re: [Intel-gfx] [PATCH 25/59] drm/tidss: Delete tidss->saved_state

On 15/04/2020 10:40, Daniel Vetter wrote: Not used anymore since the switch to suspend/resume helpers. Tested-by: Jyri Sarha Acked-by: Sam Ravnborg Signed-off-by: Daniel Vetter Cc: Jyri Sarha Cc: Tomi Valkeinen --- drivers/gpu/drm/tidss/tidss_drv.h | 2 -- 1 file changed, 2 deletions

Re: [Intel-gfx] [PATCH 23/59] drm/tidss: Use devm_drm_dev_alloc

On 15/04/2020 10:39, Daniel Vetter wrote: Already using devm_drm_dev_init, so very simple replacment. Tested-by: Jyri Sarha Acked-by: Sam Ravnborg Signed-off-by: Daniel Vetter Cc: Jyri Sarha Cc: Tomi Valkeinen --- drivers/gpu/drm/tidss/tidss_drv.c | 15 --- 1 file changed, 4

Re: [Intel-gfx] [PATCH 24/59] drm/tidss: Don't use drm_device->dev_private

On 15/04/2020 10:39, Daniel Vetter wrote: Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. Tested-by: Jyri Sarha Acked-by: Sam Ravnborg Signed-off-by: Daniel Vetter Cc: Jyri Sarha Cc: Tomi Valkeinen --- drivers/gpu/drm/tidss

Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree

Hi, On 21/04/2020 04:52, Stephen Rothwell wrote: Hi all, Today's linux-next merge of the drm-misc tree got a conflict in:he drm-misc tree with the drm-misc-fixes tree drivers/gpu/drm/tidss/tidss_encoder.c between commit: 9da67433f64e ("drm/tidss: fix crash related to accessing freed

Re: [Intel-gfx] [PATCH 07/15] drm/omapdrm: Drop dma_buf->k(un)map

impossible to buy a chip with tegra host1x and ompadrm on the same > SoC, there's no problem here. > > Signed-off-by: Daniel Vetter > Cc: Tomi Valkeinen > --- > drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 - > 1 file changed, 21 deletions(-) We're u

Re: [Intel-gfx] [PULL] drm-misc-next

Hi, On 18/10/2019 23:11, Sean Paul wrote: On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen wrote: Hi Sean, On 17/10/2019 22:26, Sean Paul wrote: concern for those. The omap OMAP_BO_MEM_* changes though I don't think have really reached non-TI eyes. There's no link in the commit message

Re: [Intel-gfx] [PULL] drm-misc-next

Hi Sean, On 17/10/2019 22:26, Sean Paul wrote: concern for those. The omap OMAP_BO_MEM_* changes though I don't think have really reached non-TI eyes. There's no link in the commit message to a UAPI implementation and the only reference I could find is libkmsxx which can set them through the

Re: [Intel-gfx] [PATCH 4/5] drm/omapdrm: Substitute format_is_yuv() with format->is_yuv

Hi, On 18/07/18 13:17, Ville Syrjälä wrote: > On Tue, Jul 17, 2018 at 06:13:45PM +0100, Ayan Kumar Halder wrote: >> drm_format_info table has a field 'is_yuv' to denote if the format >> is yuv or not. The driver is expected to use this instead of >> having a function for the same purpose. >> >>

Re: [Intel-gfx] [PATCH 11/13] drm/omapdrm: Nuke omap_framebuffer_get_next_connector()

On 09/04/18 11:41, Daniel Vetter wrote: > On Fri, Apr 06, 2018 at 09:10:43AM +0300, Tomi Valkeinen wrote: >> On 05/04/18 19:50, Daniel Vetter wrote: >>> On Thu, Apr 05, 2018 at 06:13:58PM +0300, Ville Syrjala wrote: >>>> From: Ville Syrjälä

Re: [Intel-gfx] [PATCH 11/13] drm/omapdrm: Nuke omap_framebuffer_get_next_connector()

gt;> deprecate for atomic drivers. As omap_framebuffer_get_next_connector() >> is unused just nuke the entire function. >> >> Cc: Tomi Valkeinen <tomi.valkei...@ti.com> >> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com> > > Yeah was slightly worried how to fix up this one

Re: [Intel-gfx] [PATCH 1/8] drm/omap: Simplify the rotation-on-crtc hack

On 31/07/17 14:48, Laurent Pinchart wrote: >>> The comment about read lock is only valid when the plane is bound to the >>> crtc. In general this is not always the case. You can only peak at >>> plane->state when crtc->state->plane_mask & BIT(drm_plane_index(plane)) >>> is true. >>> >>> I think

Re: [Intel-gfx] [PATCH] drm/atomic: Introduce drm_atomic_helper_shutdown

On 28/03/17 17:22, Daniel Vetter wrote: >> This is a bit related to the other annoyance, which is that we don't >> reset properties when a DRM app quits. I think the state of the HW >> should be restored to exactly the same state as it was (including >> turning off the crtcs). I'm planning to

Re: [Intel-gfx] [PATCH] drm/atomic: Introduce drm_atomic_helper_shutdown

On 27/03/17 10:43, Daniel Vetter wrote: > With atomic we've stopped killing the entire CRTC when you the last > userspace reference for the framebuffer on the primary plane disappears, > but just shut down the primary plane. Assuming the driver can do that, we > fall back to full CRTC shutdown if

Re: [Intel-gfx] [PATCH] drm/atomic: Introduce drm_atomic_helper_shutdown

..@linux.intel.com> > Cc: Noralf Trønnes <nor...@tronnes.org> > Cc: Ben Skeggs <bske...@redhat.com> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> Tested-by: Tomi Valkeinen <tomi.valkei...@ti.com> As a side note, I find it a bit odd that when f

Re: [Intel-gfx] [PATCH 08/19] drm/tilcdc: Drop calls to modeset_lock_crtc

On 22/03/17 23:50, Daniel Vetter wrote: > Again this is an internal helper, not the official way to lock a crtc. > > Cc: Jyri Sarha <jsa...@ti.com> > Cc: Tomi Valkeinen <tomi.valkei...@ti.com> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > --- >

Re: [Intel-gfx] [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

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 <j...@perches.com> For omap: Acked-by: Tomi Valkeinen

Re: [Intel-gfx] [PATCH v2 3/4] video: Add new aspect ratios for HDMI 2.0

mi_picture_aspect { > HDMI_PICTURE_ASPECT_NONE, > HDMI_PICTURE_ASPECT_4_3, > HDMI_PICTURE_ASPECT_16_9, > + HDMI_PICTURE_ASPECT_64_27, > + HDMI_PICTURE_ASPECT_256_135, > HDMI_PICTURE_ASPECT_RESERVED, > }; > > Acked-by: Tomi Valkeinen <tomi.

Re: [Intel-gfx] [PATCH v2 07/15] drm/omap: Use per-plane rotation property

On 06/10/16 13:30, Ville Syrjälä wrote: > On Thu, Oct 06, 2016 at 12:59:17PM +0300, Tomi Valkeinen wrote: >> >> On 26/09/16 19:30, ville.syrj...@linux.intel.com wrote: >>> From: Ville Syrjälä <ville.syrj...@linux.intel.com> >>> >>> The global mod

Re: [Intel-gfx] [PATCH v2 07/15] drm/omap: Use per-plane rotation property

handling right. > Might work, or migth not. > > v2: Drop the BIT() > Don't create rotation property twice for each primary plane > > Cc: Tomi Valkeinen <tomi.valkei...@ti.com> > Cc: Rob Clark <robdcl...@gmail.com> > Signed-off-by: Ville Syrjälä <ville.

Re: [Intel-gfx] [PATCH 07/15] drm/omap: Use per-plane rotation property

On 12/08/16 19:04, Ville Syrjälä wrote: > On Thu, Aug 11, 2016 at 04:33:32PM +0300, Ville Syrjälä wrote: >> On Thu, Aug 11, 2016 at 02:32:44PM +0300, Tomi Valkeinen wrote: >>> Hi, >>> >>> On 22/07/16 16:43, ville.syrj...@linux.intel.com wrote:

Re: [Intel-gfx] [PATCH 07/15] drm/omap: Use per-plane rotation property

Hi, On 22/07/16 16:43, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The global mode_config.rotation_property is going away, switch over to > per-plane rotation_property. > > Not sure I got the annoying crtc rotation_property handling right. >

Re: [Intel-gfx] [PATCH 16/22] drm/omap: Nuke close hooks

Hi Daniel, On 11/01/16 23:41, Daniel Vetter wrote: > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c > b/drivers/gpu/drm/omapdrm/omap_drv.c > index dfafdb602ad2..603a65498b40 100644 > --- a/drivers/gpu/drm/omapdrm/omap_drv.c > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c > @@ -175,17 +175,6 @@

Re: [Intel-gfx] [PATCH 20/22] drm/tilcdc: Nuke preclose hook

On 12/01/16 17:12, Daniel Vetter wrote: > Different approaches to the same problem: > > - omap just unlinks the event from fpriv and still process it normally. > But then before sending it out it checks whether the fpriv is still > there or not and either sends it, or deletes the event

Re: [Intel-gfx] [PATCH 16/22] drm/omap: Nuke close hooks

tc.c | 13 +--- > drivers/gpu/drm/omapdrm/omap_drv.c | 41 > - > drivers/gpu/drm/omapdrm/omap_drv.h | 1 - > 3 files changed, 1 insertion(+), 54 deletions(-) Acked-by: Tomi Valkeinen <tomi.valkei...@ti.com> Tomi signature.asc Descript

Re: [Intel-gfx] [PATCH 20/22] drm/tilcdc: Nuke preclose hook

On 11/01/16 23:41, Daniel Vetter wrote: > Again since the drm core takes care of event unlinking/disarming this > is now just needless code. > > v2: Fixup misplaced hunks. > > Cc: Rob Clark > Acked-by: Daniel Stone > Reviewed-by: Alex Deucher

Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

On 25/08/15 16:45, Daniel Vetter wrote: > When the usual fbcon legacy options are enabled we have > ->register_framebuffer > ->fb notifier chain calls into fbcon > ->fbcon sets up console on new fbi > ->fbi->set_par > ->drm_fb_helper_set_par exercises full kms api > > And

Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

On 01/09/15 17:34, Rob Clark wrote: > I hadn't had a chance to look at it further yet.. I think Daniel > claimed it worked for him, but he was probably on intel-next, where I > was on drm-next at the time which seemed to be having some unrelated > i915 issues (when I was trying to debug atomic

Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

t;> >> Usual tactic to debug that is to temporarily remove those console_lock >> calls to be able to capture backtraces. I'm fed up writing this patch >> and recompiling kernels. Hence this patch here to add an unsafe, >> kernel-taining option to do this at runtime. >> >

Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

On 01/09/15 17:34, Rob Clark wrote: > On Tue, Sep 1, 2015 at 6:32 AM, Tomi Valkeinen <tomi.valkei...@ti.com> wrote: >> >> >> On 25/08/15 22:24, Rob Clark wrote: >>> On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter <daniel.vet...@ffwll.ch> >>&

Re: [Intel-gfx] [PATCH 2/6] drm/atomic: pass old crtc state to atomic_begin/flush.

Hi, On 21/07/15 14:28, Maarten Lankhorst wrote: In intel it's useful to keep track of some state changes with old crtc state vs new state, for example to disable initial planes or when a modeset's prevented during fastboot. Cc: dri-de...@lists.freedesktop.org Signed-off-by: Maarten

Re: [Intel-gfx] [PATCH 1/2] video/fbdev: Always built-in video= cmdline parsing

what exactly applies. - Only compile this when needed. Cc: Geert Uytterhoeven ge...@linux-m68k.org Cc: Plagniol-Villard plagn...@jcrosoft.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-fb...@vger.kernel.org Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch -- I prefer if we

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console

Hi, On 06/06/14 18:20, Daniel Vetter wrote: Tomi/Jean can you please ack merging this through drm-intel trees? It just exports the vga and dummy consoles so that i915 can do what it needs to do. Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc Description: OpenPGP

Re: [Intel-gfx] [PATCH] fbcon: Avoid corrupting active workqueue entries

Hi, On 2013-12-17 16:27, Chris Wilson wrote: We attempt to reschedule an active work which can itself corrupt the workqueue lists, and we may then free the work item whilst the task is still pending. Both of these may lead to a system deadlock and an unresponsive machine without any outputs