[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue

On 03/09/14 17:27, Daniel Vetter wrote: > On Wed, Sep 03, 2014 at 02:55:08PM +0300, Tomi Valkeinen wrote: >> omap_crtc_flush() is used to wait for scheduled work to be done for the >> give crtc. However, it's not quite right at the moment. >> >> omap_crtc_flush() does wa

[PATCH 4/9] drm/omap: make modesetting synchronous

On 03/09/14 17:25, Daniel Vetter wrote: > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote: >> Currently modesetting is not done synchronously, but it queues work that >> is done later. In theory this is fine, but the driver doesn't handle it >> at

[PATCH 8/9] drm/omap: fix preclose to wait for scheduled work

On 03/09/14 17:32, Daniel Vetter wrote: > On Wed, Sep 03, 2014 at 02:55:09PM +0300, Tomi Valkeinen wrote: >> We already wait for all scheduled work to be done on the driver's unload >> function. However, I think we need to wait on preclose() also, so that >> when an applicatio

[PATCH] omap2+: add drm device

On Mon, 2012-06-11 at 09:51 -0500, Gross, Andy wrote: > Tomi, > > > So at this point, are you OK with deferring a split of the DMM until > it necessary to do so (if ever)? I'd like to get this patch in so > that people have a working omapdrm device when they enable the config > options. Yes,

[PATCH] staging: drm/omap: add rotation properties

On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote: > From: Rob Clark > > Use tiled buffers for rotated/reflected scanout, with CRTC and plane > properties as the interface for userspace to configure rotation. > > Signed-off-by: Rob Clark > +/* this should probably be in drm-core to

[PATCH] omap2+: add drm device

On Mon, 2012-03-05 at 10:54 -0600, Rob Clark wrote: > From: Andy Gross > > Register OMAP DRM/KMS platform device, and reserve a CMA region for > the device to use for buffer allocation. DMM is split into a > separate device using hwmod. > > Signed-off-by: Andy Gross > Signed-off-by: Rob Clark

[PATCH] omap2+: add drm device

On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote: > On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen > wrote: > > Can there be more than one omapdrm device? I guess not. If so, the id > > should be -1. > > in the past, we have used multiple devices (using the plat

[PATCH] omap2+: add drm device

On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote: > On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen > wrote: > > On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote: > >> On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen > >> wrote: > > > >> > Ca

[PATCH] omap2+: add drm device

On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote: > > > On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen > wrote: > > > I have to say I don't know much about DMM, but my > understanding is that > DMM is a bigger entity, of

[PATCH] omap2+: add drm device

On Wed, 2012-03-07 at 07:06 -0600, Rob Clark wrote: > On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen > wrote: > > Hmm, why does the drm core care about it? > > Because it is the one generating the bus-id.. see > drivers/gpu/drm/drm_platform.c drm_platform_set_busid() &g

[PATCH] omap2+: add drm device

On Wed, 2012-03-07 at 09:59 -0600, Gross, Andy wrote: > On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen > wrote: > > > > Does this "DMM has become synonymous" mean that people just started > > calling TILER DMM, and thus the name has stuck, or are there technic

[PATCH] omap2+: add drm device

Hi, On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote: > From: Andy Gross > > Register OMAP DRM/KMS platform device, and reserve a CMA region for > the device to use for buffer allocation. DMM is split into a > separate device using hwmod. What's the diff with this and the previous one? I

[PATCH] omap2+: add drm device

On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote: > On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen > wrote: > > Hi, > > > > On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote: > >> From: Andy Gross > >> > >> Register OMAP DRM/KMS platform d

[PATCH] omap2+: add drm device

On Wed, 2012-03-14 at 08:16 -0500, Rob Clark wrote: > On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen > wrote: > > On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote: > >> On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen > >> wrote: > >> > Hi, >

[PATCH] omap2+: add drm device

On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote: > > Well, as I said, it's not an issue for me and from my side it can be > > improved later. > > yeah, when CMA is actually merged, there are a few other things I'd > like to do to, incl converting omapfb over to use CMA and remove >

[PATCH] omap2+: add drm device

On Thu, 2012-03-15 at 07:32 -0500, Rob Clark wrote: > On Thu, Mar 15, 2012 at 3:46 AM, Tomi Valkeinen > wrote: > > On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote: > > > >> > Well, as I said, it's not an issue for me and from my side it can be > >> >

[PATCH] omap2+: add drm device

Hi, On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote: > Register OMAP DRM/KMS platform device. DMM is split into a > separate device using hwmod. > > Signed-off-by: Andy Gross > +static int __init omap_init_drm(void) > +{ > + struct omap_hwmod *oh = NULL; > + struct

[PATCH] omap2+: add drm device

On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote: > On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen > wrote: > > Hi, > > > > On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote: > >> Register OMAP DRM/KMS platform device. DMM is split into a

[PATCH] omap2+: add drm device

On Thu, 2012-05-24 at 10:05 +0300, Tomi Valkeinen wrote: > On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote: > > On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen > > wrote: > > > Hi, > > > > > > On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote: &g

[PATCH] omap2+: add drm device

On Thu, 2012-05-24 at 02:35 -0600, Rob Clark wrote: > On Thu, May 24, 2012 at 1:05 AM, Tomi Valkeinen > wrote: > > On Thu, 2012-05-24 at 00:27 -0600, Clark, Rob wrote: > >> On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen >> ti.com> wrote: > >> > Hi,

[PATCH] omap2+: add drm device

On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote: > but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss > v4l2 camera working w/ tiler buffers on my pandaboard, for example. > > Maybe fbdev is an exception to the rule because it has no way for > userspace to pass it a buffer

[PATCH] omap2+: add drm device

On Thu, 2012-05-24 at 10:09 -0500, Gross, Andy wrote: > On Thu, May 24, 2012 at 7:13 AM, Tomi Valkeinen > wrote: > > On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote: > > > >> but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss > >> v4l2 c

[PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

On 2012-11-05 16:21, Rob Clark wrote: > On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: >>>> But even then, choosing the manager is not easy, as whoever chooses the >>>> >>manager needs to observe all the possible displays used at the same >>>> >>

[PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

On 2012-11-06 16:40, Rob Clark wrote: > I mean, similar to how we handle the subdev for dmm.. the > omap_drm_init() does the platform_driver_register() for the dmm device > before the platform_driver_register() for omapdrm itself, so we know > if there is a dmm device, the driver gets probed

[PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

On 2012-11-07 16:32, Rob Clark wrote: > On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen > wrote: >> Hotplugging is not some abstract future scenario, we already have >> hardware that could use it. For example, omap3 SDP board has a >> switchable output to DVI or LCD pan

[PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

On 2012-11-07 21:18, Rob Clark wrote: > On Wed, Nov 7, 2012 at 9:13 AM, Tomi Valkeinen > wrote: >> On 2012-11-07 16:32, Rob Clark wrote: >>> On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen >>> wrote: >> >>>> Hotplugging is not some abstrac

[PATCH] drm/omap: use omapdss low level API

On 2012-11-16 14:19, Greg KH wrote: > On Thu, Nov 15, 2012 at 06:00:58PM -0600, Rob Clark wrote: >> This patch changes the omapdrm KMS to bypass the omapdss "compat" >> layer and use the core omapdss API directly. This solves some layering >> issues that would cause unpin confusion vs GO bit

[PATCH v12 1/6] video: add display_timing and videomode

Hi, On 2012-11-20 17:54, Steffen Trumtrar wrote: > Add display_timing structure and the according helper functions. This allows > the description of a display via its supported timing parameters. > > Every timing parameter can be specified as a single value or a range > . > > Also, add helper

[PATCH v12 2/6] video: add of helper for videomode

On 2012-11-20 17:54, Steffen Trumtrar wrote: > +timings subnode > +--- > + > +required properties: > + - hactive, vactive: Display resolution > + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters > + in pixels > + vfront-porch, vback-porch, vsync-len:

[PATCH v12 3/6] fbmon: add videomode helpers

On 2012-11-20 17:54, Steffen Trumtrar wrote: > diff --git a/include/linux/fb.h b/include/linux/fb.h > index c7a9571..920cbe3 100644 > --- a/include/linux/fb.h > +++ b/include/linux/fb.h > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include No need for this, just add "struct

[PATCH v12 4/6] fbmon: add of_videomode helpers

On 2012-11-20 17:54, Steffen Trumtrar wrote: > Add helper to get fb_videomode from devicetree. > > Signed-off-by: Steffen Trumtrar > Reviewed-by: Thierry Reding > Acked-by: Thierry Reding > Tested-by: Thierry Reding > Tested-by: Philipp Zabel > Reviewed-by: Laurent Pinchart > --- >

[PATCH v12 5/6] drm_modes: add videomode helpers

On 2012-11-20 17:54, Steffen Trumtrar wrote: > Add conversion from videomode to drm_display_mode > > Signed-off-by: Steffen Trumtrar > Reviewed-by: Thierry Reding > Acked-by: Thierry Reding > Tested-by: Thierry Reding > Tested-by: Philipp Zabel > Reviewed-by: Laurent Pinchart > --- >

[PATCH v12 6/6] drm_modes: add of_videomode helpers

On 2012-11-20 17:54, Steffen Trumtrar wrote: > Add helper to get drm_display_mode from devicetree. > > Signed-off-by: Steffen Trumtrar > Reviewed-by: Thierry Reding > Acked-by: Thierry Reding > Tested-by: Thierry Reding > Tested-by: Philipp Zabel > Reviewed-by: Laurent Pinchart > --- >

[PATCH v12 1/6] video: add display_timing and videomode

On 2012-11-21 18:11, Steffen Trumtrar wrote: > Hi, > > On Wed, Nov 21, 2012 at 01:37:08PM +0200, Tomi Valkeinen wrote: >>> +#include >> >> What is this needed for? u32? I don't see it defined in types.h >> > > Yes, u32. What would be the right head

[PATCH v12 4/6] fbmon: add of_videomode helpers

On 2012-11-21 18:24, Steffen Trumtrar wrote: > On Wed, Nov 21, 2012 at 02:49:30PM +0200, Tomi Valkeinen wrote: >>> @@ -715,6 +717,11 @@ extern void fb_destroy_modedb(struct fb_videomode >>> *modedb); >>> extern int fb_find_mode_cvt(struct fb_videomode *

[RFC v2 0/5] Common Display Framework

Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: > From: Laurent Pinchart > > Hi everybody, > > Here's the second RFC of what was previously known as the Generic Panel > Framework. Nice work! Thanks for working on this. I was doing some testing

[RFC v2 0/5] Common Display Framework

On 2012-11-23 21:56, Thierry Reding wrote: > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: > [...] >> Display entities are accessed by driver using notifiers. Any driver can >> register a display entity notifier with the CDF, which then calls the >> notifier >> when a matching

[PATCHv15 2/7] video: add display_timing and videomode

On 2012-11-26 11:07, Steffen Trumtrar wrote: > +/* > + * Subsystem independent description of a videomode. > + * Can be generated from struct display_timing. > + */ > +struct videomode { > + u32 pixelclock; /* pixelclock in Hz */ I don't know if this is of any importance, but the

[PATCHv15 3/7] video: add of helper for display timings/videomode

Hi, On 2012-11-26 11:07, Steffen Trumtrar wrote: > This adds support for reading display timings from DT into a struct > display_timings. The of_display_timing implementation supports multiple > subnodes. All children are read into an array, that can be queried. > > If no native mode is

[PATCHv15 3/7] video: add of helper for display timings/videomode

On 2012-11-26 18:10, Steffen Trumtrar wrote: > Hi, > > On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote: >>> +optional properties: >>> + - hsync-active: hsync pulse is active low/high/ignored >>> + - vsync-active: vsync pulse is active low/

[RFC v2 2/5] video: panel: Add DPI panel support

Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: > +static void panel_dpi_release(struct display_entity *entity) > +{ > + struct panel_dpi *panel = to_panel_dpi(entity); > + > + kfree(panel); > +} > + > +static int panel_dpi_remove(struct platform_device *pdev) > +{ > + struct

[RFC v2 1/5] video: Add generic display entity core

Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: > +/** > + * display_entity_get_modes - Get video modes supported by the display entity > + * @entity The display entity > + * @modes: Pointer to an array of modes > + * > + * Fill the modes argument with a pointer to an array of video modes. The

[RFC v2 3/5] video: display: Add MIPI DBI bus support

Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: > From: Laurent Pinchart > > Signed-off-by: Laurent Pinchart > --- > drivers/video/display/Kconfig|4 + > drivers/video/display/Makefile |1 + >

[PATCH 1/2 v6] of: add helper to parse display timings

Hi, On Thu, 2012-10-04 at 19:59 +0200, Steffen Trumtrar wrote: > Signed-off-by: Steffen Trumtrar > --- > .../devicetree/bindings/video/display-timings.txt | 222 > > drivers/of/Kconfig |5 + > drivers/of/Makefile

[PATCH 1/2 v6] of: add helper to parse display timings

On Mon, 2012-10-08 at 10:07 +0300, Tomi Valkeinen wrote: > Hi, > I don't see you setting disp->default_timing to OF_DEFAULT_TIMING in > case there's no default_timing found. > > Or, at least I presume OF_DEFAULT_TIMING is meant to mark non-existing > default timing. The n

[PATCH 2/2 v6] of: add generic videomode description

On Thu, 2012-10-04 at 19:59 +0200, Steffen Trumtrar wrote: > Get videomode from devicetree in a format appropriate for the > backend. drm_display_mode and fb_videomode are supported atm. > Uses the display signal timings from of_display_timings > > Signed-off-by: Steffen Trumtrar > --- >

[PATCH 1/2 v6] of: add helper to parse display timings

On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote: > In general, I might be misunderstanding something, but don't we have to > distinguish between 2 types of information about display timings: (1) is > defined by the display controller requirements, is known to the display >

[PATCH 1/2 v6] of: add helper to parse display timings

On Mon, 2012-10-08 at 14:04 +0200, Laurent Pinchart wrote: > Hi Tomi, > > On Monday 08 October 2012 12:01:18 Tomi Valkeinen wrote: > > On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote: > > > In general, I might be misunderstanding something, but don't we h

[PATCH/RFC v3 00/19] Common Display Framework

On 17/10/13 10:48, Andrzej Hajda wrote: > The main function of DSI is to transport pixels from one IP to another IP > and this function IMO should not be modeled by display entity. > "Power, clocks, etc" will be performed via control bus according to > panel demands. > If 'DSI chip' has

[RFR 2/2] drm/panel: Add simple panel support

On 17/10/13 11:53, Thierry Reding wrote: > I keep wondering why we absolutely must have compatibility between CDF > and this simple panel binding. DT content is supposed to concern itself > with the description of hardware only. What about the following isn't an > accurate description of the

[RFR 2/2] drm/panel: Add simple panel support

On 17/10/13 14:02, Laurent Pinchart wrote: >> Okay, so if I understand correctly, translating those bindings to panel >> nodes would look somewhat like this: >> >> dc: display-controller { >> ports { >> port at 0 { >>

[RFR 2/2] drm/panel: Add simple panel support

On 17/10/13 14:05, Thierry Reding wrote: >> That's quite similar to how my current out-of-mainline OMAP DSS DT >> bindings work. The difference is that I have a reference from the panel >> node to the video source (dsi-controller), instead of the other way >> around. I just find it more natural.

[RFR 2/2] drm/panel: Add simple panel support

On 17/10/13 14:51, Laurent Pinchart wrote: >> I'm not sure if there's a specific need for the port or endpoint nodes >> in cases like the above. Even if we have common properties describing >> the endpoint, I guess they could just be in the parent node. >> >> panel { >> remote = <>; >>

[RFR 2/2] drm/panel: Add simple panel support

On 17/10/13 15:17, Laurent Pinchart wrote: > Hi Tomi, > > On Thursday 17 October 2013 14:59:41 Tomi Valkeinen wrote: >> On 17/10/13 14:51, Laurent Pinchart wrote: >>>> I'm not sure if there's a specific need for the port or endpoint nodes >>>> in cases

[PATCH/RFC v3 00/19] Common Display Framework

On 17/10/13 15:26, Andrzej Hajda wrote: > I am not sure what exactly the encoder performs, if this is only image > transport from dispc to panel CDF pipeline in both cases should look like: > dispc > panel > The only difference is that panels will be connected via different Linux bus >

[PATCH v2 0/2] drm: omap: Fix omapdrm probe and module insertion/removal issues

is removed > > drivers/gpu/drm/omapdrm/omap_crtc.c| 5 +++ > drivers/gpu/drm/omapdrm/omap_drv.c | 77 > -- > drivers/gpu/drm/omapdrm/omap_drv.h | 1 + > drivers/gpu/drm/omapdrm/omap_encoder.c | 3 ++ > 4 files changed, 6

[PATCH] drm/omap: fix (un)registering irqs inside an irq handler

dispc_runtime_get/put, and using those functions in interrupt context. Thus we can make dispc again non-irq-safe, allowing proper PM. Signed-off-by: Tomi Valkeinen Cc: Rob Clark --- drivers/gpu/drm/omapdrm/omap_crtc.c | 6 +++--- drivers/gpu/drm/omapdrm/omap_drv.h | 2 ++ drivers/gpu/drm

[RFR 2/2] drm/panel: Add simple panel support

On 24/10/13 13:40, Laurent Pinchart wrote: >> panel { >> remote = <>; >> common-video-property = ; >> }; >> >> panel { >> port { >> endpoint { >> remote = <>; >> common-video-property = ; >> }; >> }; >> }; >

[PATCH 2/2] simplefb: use write-combined remapping

On 2013-10-30 09:49, David Herrmann wrote: > Hi Tomi > > Ping? Thanks, queued this and the 1/2 patch for 3.13. Tomi > > Thanks > David > > On Wed, Oct 2, 2013 at 4:58 PM, David Herrmann > wrote: >> Framebuffers shouldn't be cached and it is usually very uncommon to read >> them.

[PATCH 1/4] drm/omap: fix output enable/disable sequence

: - When enabling a display, we'll wait for the first vsync. - When disabling a display, we'll wait for framedone if available, or odd and even vsyncs. These changes make sure the output is fully enabled or disabled at the end of the function. Signed-off-by: Tomi Valkeinen Reported-by: Sanjay Singh

[PATCH 4/4] drm/omap: fix race issue when unloading omapdrm

adds a omap_crtc_flush() function which waits until the crtc has finished with its apply queue and page flips. The function utilizes a simple polling while-loop, as the performance is not an issue here. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_crtc.c | 19

[PATCH 2/4] drm/omap: fix uninit order in pdev_remove()

the uninitialize order so that the omapdrm pdev is removed first. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index bf39fcc49e0f

[PATCH 3/4] drm/omap: fix DMM driver (un)registration

be registered, simplifying the unregister path as we don't need to keep the state whether we registered the DMM driver or not. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_drv.c | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm

[PATCH 3/4] drm/omap: fix DMM driver (un)registration

On 02/04/14 17:14, Rob Clark wrote: > On Wed, Apr 2, 2014 at 8:37 AM, Tomi Valkeinen > wrote: >> At the moment the DMM driver is never unregistered, even if it's >> registered in the omapdrm module's init function. This means we'll get >> errors when reloading the o

[PATCH 3/3] OMAPDSS: HDMI: fix interlace output

The HDMI output video format's yres needs to be divided by two for interlace. Fix it. Signed-off-by: Tomi Valkeinen --- drivers/video/omap2/dss/hdmi_wp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/omap2/dss/hdmi_wp.c b/drivers/video/omap2/dss/hdmi_wp.c index

[PATCH 2/3] drm/omap: fix enabling/disabling of video pipeline

On 03/04/14 17:58, Rob Clark wrote: > On Thu, Apr 3, 2014 at 9:45 AM, Tomi Valkeinen > wrote: >> At the moment the omap_crtc_pre_apply() handles the enabling, disabling >> and configuring of encoders and panels separately from the CRTC (i.e. >> the overlay manager). >

[PATCH 1/3] drm/omap: fix missing disable for unused encoder

When an encoder is no longer connected to a crtc, the driver will leave the encoder enabled. This patch adds code to track the encoder used for a crtc, and when the encoder changes, the old one is disabled. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_crtc.c | 6 ++ 1

[PATCH 2/3] drm/omap: fix enabling/disabling of video pipeline

ode to setup and enable/disable the crtc to omap_crtc_enable. and omap_crtc_disable(). Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_crtc.c | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c b/drivers/gpu/

[PATCH] drm/omap: fix plane rotation

On 08/04/14 01:12, Rob Clark wrote: > On Mon, Apr 7, 2014 at 5:41 PM, Grazvydas Ignotas > wrote: >> Gra?vydas >> >> >> On Mon, Apr 7, 2014 at 8:17 PM, Rob Clark wrote: >>> On Mon, Apr 7, 2014 at 6:32 AM, Grazvydas Ignotas >>> wrote: On Sun, Apr 6, 2014 at 12:45 AM, Rob Clark wrote:

Possible fb ref count issue with drm_plane_force_disable()

Hi, I've been debugging omapdrm issues on top of the latest drm mainline changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting a drm application, or unloading the modules. The setup is very basic, just a single crtc with the crtc's primary plane. What seems to happen is: -

Possible fb ref count issue with drm_plane_force_disable()

On 11/04/14 09:31, Archit Taneja wrote: > Hi, > > On Thursday 10 April 2014 05:17 PM, Tomi Valkeinen wrote: >> Hi, >> >> I've been debugging omapdrm issues on top of the latest drm mainline >> changes. Sometimes a drm_framebuffer ref count drops to -1 w

Possible fb ref count issue with drm_plane_force_disable()

On 11/04/14 09:57, Archit Taneja wrote: > Yes, I meant our driver should call drm_framebuffer_remove() only when > we are know that the fb reference omapdrm had taken(the one in > update_pin), has a corresponding fb unref called(in unpin_worker). > > Isn't that something omapdrm should take care

[PATCH 01/18] drm/omap: fix up pdev_remove

Hi, On 12/04/14 00:35, Daniel Vetter wrote: > Dave accidentally merged the wrong version of the patch in > > commit fd3c02531461924853db65f2664db361b53a70d3 > Author: Daniel Vetter > Date: Wed Dec 11 11:34:26 2013 +0100 > > drm/omap: call drm_put_dev directly in ->remove > > which did

[PATCH 1/4] drm/omap: fix missing unref to fb's buf object

omap_fbdev_create() takes a reference to the fb's gem object with omap_gem_get_paddr(). However, it never releases it with omap_gem_put_paddr(). This patch adds the missing omap_gem_put_paddr() to omap_fbdev_free(). Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_fbdev.c | 3

[PATCH 6/6] drm/omap: protect omap_crtc's event with event_lock spinlock

On 11/04/14 10:23, Archit Taneja wrote: > The vblank_cb callback and the page_flip ioctl can occur together in different > CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when > sending the vblank event and updating omap_crtc->event and omap_crtc->od_fb. > > Use the same

Possible fb ref count issue with drm_plane_force_disable()

On 11/04/14 14:50, Ville Syrj?l? wrote: >> So the explicit unref done by drm_plane_force_disable() seems a bit out >> of place. I can't figure out which drm_framebuffer_reference() would be >> the matching one for the unref done by drm_plane_force_disable(). >> >> Any ideas what ref is that? Or

[PATCH 2/4] drm/omap: print warning when rotating non-TILER fb

Print a warning when the user tries to rotate a non-TILER framebuffer. Also set the rotation to 0, to avoid constant flood of the warnings in case of page flipping. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_fb.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH 4/4] drm/omap: remove warn from debugfs

is used. So, presuming the removal of locks is ok, we can also remove the WARN. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_gem.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c index c8d972763889

[PATCH 4/6] drm/omap: Allow allocation of larger buffers

On 14/04/14 13:18, Archit Taneja wrote: > On Monday 14 April 2014 02:55 PM, Tomi Valkeinen wrote: >> On 11/04/14 10:23, Archit Taneja wrote: >>> The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers >>> which are >>> greater than what is

[PATCH 4/6] drm/omap: Allow allocation of larger buffers

On 11/04/14 10:23, Archit Taneja wrote: > The drm ioctl DRM_IOCTL_MODE_ADDFB2 doesn't let us allocate buffers which are > greater than what is specified in the driver through dev->mode_config. > > Create helpers for DISPC which return the max manager width and height > supported > by the device.

[PATCH 3/4] drm/omap: remove extra plane->destroy from crtc destroy

>funcs->destroy(omap_crtc->plane) Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_crtc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c b/drivers/gpu/drm/omapdrm/omap_crtc.c index f59ef9359e66..b3a7529845b9 100644 --- a/drivers/

Possible fb ref count issue with drm_plane_force_disable()

On 15/04/14 13:29, Andrzej Hajda wrote: > I have experienced similar problem with exynos_drm. I have found that > in exynos_drm_crtc_mode_set there is line: > > plane->fb = crtc->primary->fb; > > without drm_framebuffer_reference. > In result drm_framebuffer_remove dereferences it twice:

Possible fb ref count issue with drm_plane_force_disable()

On 14/04/14 11:43, Tomi Valkeinen wrote: > On 11/04/14 14:50, Ville Syrj?l? wrote: > >>> So the explicit unref done by drm_plane_force_disable() seems a bit out >>> of place. I can't figure out which drm_framebuffer_reference() would be >>> th

[PATCH 0/6] drm/omap: Misc fixes

Hi, On 11/04/14 10:23, Archit Taneja wrote: > These are based over Tomi's 3.15/omapdrm-fixes branch. > > Archit Taneja (5): > drm/omap: gem sync: wait on correct events > drm/omap: Fix crash when using LCD3 overlay manager > drm/omap: Allow allocation of larger buffers > drm/omap: Use

Possible fb ref count issue with drm_plane_force_disable()

On 15/04/14 13:10, Rob Clark wrote: > so, what triggers this is that previously drm_framebuffer_remove() did > not process private planes. But now the fb shows up attached to a > plane as well, the crtc's primary plane. > > I suspect there is some way in omap_crtc that I must have assumed the >

Possible fb ref count issue with drm_plane_force_disable()

On 15/04/14 15:24, Rob Clark wrote: > probably split out omap_plane_mode_set_internal(), call that directly > from update_plane() for plane operations. And then do the refcnt > dance in the new omap_plane_mode_set() which calls _internal().. We don't actually need that. This did the trick:

[PATCH 01/18] drm/omap: fix up pdev_remove

On 16/04/14 11:15, Daniel Vetter wrote: > I don't mind how this is getting fixed, I just don't like when regression > caused by my patches are left lingering too long ;-) > > Have you merged your patch for 3.14-rc already so that I can drop this one > here? Did you mean 3.15-rc? It's on my

[GIT PULL] omapdrm fixes for 3.15

rotation Subhajit Paul (1): drm/omap: Fix memory leak in omap_gem_op_async Tomi Valkeinen (11): drm/omap: fix output enable/disable sequence drm/omap: fix uninit order in pdev_remove() drm/omap: fix DMM driver (un)registration drm/omap: fix race issue when unloading

[PATCH 5/5] videomode: rename fields

On 2013-03-18 10:00, Daniel Vetter wrote: > On Tue, Mar 12, 2013 at 03:40:14PM +0200, Tomi Valkeinen wrote: >> Hi, >> >> On 2013-03-12 15:37, Laurent Pinchart wrote: >>> Hi Tomi, >>> >>> Thanks for the patch. >>> >>> On Tuesday 1

How to manage OMAP display drivers in the future

On 2013-03-18 22:46, Rob Clark wrote: > On Wed, Mar 13, 2013 at 4:57 AM, Tomi Valkeinen wrote: >> Hi Dave, >> >> I'm writing this mail to get some ideas how we should manage OMAP's >> display drivers in the future. >> >> As a short intro, we have the

[PATCH v2 3/4] drm/omap: Make fixed resolution panels work

On 2013-03-19 08:45, Archit Taneja wrote: > I was trying to come up with a macro which could add default ops to the > omap_dss_driver. It isn't straight forward as I thought, because you > need to choose either the default op, or the panel driver's op if it > exists. For example, I can't create a

[PATCH 1/4] drm/tilcdc: Fix an incorrect condition

Hi, On 2013-03-25 15:36, Rob Clark wrote: > sorry, was offline for a while (moving), and missed the last email.. > > I would guess that Tomi would send pull-req for tilcdc and omapdrm. > Well I suppose I could do it if Tomi can't, although my > pandas/beagles/beaglebones are not unpacked yet..

[PATCHv2 0/5] videomode patches

Hi, Here's a v2 of the videomode series. The changes compared to v1: * Dropped "videomode: rename fields", as it received only negative comments * New patch: "videomode: videomode_from_timing work" Patches 1-4 are unchanged. Tomi Tomi Valkeinen (5): videomode: simpli

[PATCHv2 1/5] videomode: simplify videomode Kconfig and Makefile

, and display_timing in itself is not really useful, so both would be included in any case. * CONFIG_VIDEOMODE is a bit vague name, and CONFIG_VIDEOMODE_HELPERS describes better what's included. Signed-off-by: Tomi Valkeinen Cc: Steffen Trumtrar Acked-by: Laurent Pinchart --- drivers/gpu/drm

[PATCHv2 3/5] videomode: create enum for videomode's display flags

Instead of having plain defines for the videomode's flags, add an enum for the flags. This makes the flags clearer to use, as the enum tells which values can be used with the flags field. Signed-off-by: Tomi Valkeinen Cc: Steffen Trumtrar --- include/video/display_timing.h | 28

[PATCHv2 2/5] videomode: combine videomode dmt_flags and data_flags

to DISPLAY_FLAGS_*. Signed-off-by: Tomi Valkeinen Cc: Steffen Trumtrar --- drivers/gpu/drm/drm_modes.c | 12 ++-- drivers/video/fbmon.c |8 drivers/video/of_display_timing.c | 19 +-- drivers/video/videomode.c |3 +-- include/video

[PATCHv2 4/5] videomode: remove timing_entry_index

-off-by: Tomi Valkeinen Cc: Steffen Trumtrar --- drivers/video/videomode.c | 18 +- include/video/display_timing.h | 25 - 2 files changed, 9 insertions(+), 34 deletions(-) diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c index

[PATCHv2 5/5] videomode: videomode_from_timing work

a given display_timing to videomode. Signed-off-by: Tomi Valkeinen Cc: Steffen Trumtrar --- drivers/gpu/drm/tilcdc/tilcdc_panel.c |2 +- drivers/video/of_videomode.c |2 +- drivers/video/videomode.c | 25 - include/video/videomode.h

[PATCH v3 3/8] drm/omap: Make fixed resolution panels work

On 2013-03-26 15:45, Archit Taneja wrote: > The omapdrm driver requires omapdss panel drivers to expose ops like detect, > set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI > and SDI drivers. At some places, there are no checks to see if the panel > driver > has these

[PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers

On 2013-03-26 15:45, Archit Taneja wrote: > Each version of OMAP has a limitation on the maximum pixel clock frequency > supported by an overlay manager. This limit isn't checked by omapdss. Add > dispc feats for lcd and tv managers and check whether the target timings can > be supported or not. >

<    4   5   6   7   8   9   10   11   12   13   >