[PATCH 2/4] drm/omapdrm: Add gamma table support to DSS dispc

On 20/05/16 16:14, Jyri Sarha wrote: > On 05/20/16 15:51, Tomi Valkeinen wrote: >>> +u32 dispc_mgr_gamma_size(enum omap_channel channel) >>>> +{ >>>> + const struct dispc_gamma_desc *gdesc = _desc[channel].gamma; >>>> + >>>> + if (

[PATCH 3/4] drm/omapdrm: Work-a-round for errata i734 (LCD1 Gamma) in DSS dispc

On 23/05/16 12:50, Jyri Sarha wrote: > On 05/20/16 16:21, Tomi Valkeinen wrote: >>>> + >>>> +static int dispc_errata_i734_wa_init(void) >>>> +{ >>>> + size_t buff_size = i734.ovli.width * i734.ovli.height * >> "buf_size" wo

[PATCH v2 2/3] drm/omapdrm: Work-a-round for errata i734 (LCD1 Gamma) in DSS dispc

On 23/05/16 17:41, Jyri Sarha wrote: > Work-a-round for errata i734 in DSS dispc I think it's "workaround" =). > - LCD1 Gamma Correction Is Not Working When GFX Pipe Is Disabled > > For gamma tables to work on LCD1 the GFX plane has to be used at least > once after DSS HW has come out of

[PATCH v3 3/3] drm/omapdrm: Implement gamma_lut atomic crtc property

Hi, On 24/05/16 12:16, Jyri Sarha wrote: > Implement gamma_lut atomic crtc property, set crtc gamma size to 256 > for all crtcs and use drm_atomic_helper_legacy_gamma_set() as > gamma_set func. The tv-out crtc has 1024 element gamma table (with > 10bit precision) in HW, but current Xorg server

[PATCH v3 3/3] drm/omapdrm: Implement gamma_lut atomic crtc property

On 24/05/16 12:16, Jyri Sarha wrote: > Implement gamma_lut atomic crtc property, set crtc gamma size to 256 > for all crtcs and use drm_atomic_helper_legacy_gamma_set() as > gamma_set func. The tv-out crtc has 1024 element gamma table (with > 10bit precision) in HW, but current Xorg server does

[PATCH v4 5/7] drm/omapdrm: Use drm_crtc_enable_color_mgmt() to enable gamma properties

On 25/05/16 23:43, Jyri Sarha wrote: > Use new drm_crtc_enable_color_mgmt() to enable gamma lut properties. You could move the color-mgmt patches to the beginning of the series, and add the omapdrm ones on top of those. > Signed-off-by: Jyri Sarha > --- > drivers/gpu/drm/omapdrm/omap_crtc.c |

[PATCH v5 1/4] drm: drm_helper_crtc_enable_color_mgmt() => drm_crtc_enable_color_mgmt()

Hi Jyri, Daniel, On 26/05/16 11:35, Jyri Sarha wrote: > Add drm_crtc_enable_color_mgmt(), remove drm_helper_crtc_enable_color_mgmt() > and update drm/i915-driver (the only user of the old function). > > The new function is more flexible. It allows driver to enable only the > features it has

[PATCH v5 0/4] drm/omapdrm: gamma table support + drm_crtc_enable_color_mgmt()

get rid of the old drm_helper_crtc_enable_color_mgmt(). I > have not tested the change to i915 driver, only compiled it, but > functionally it should be exactly the same. Tested the v4, which should be identical to this one, on Panda, and works fine. This version looks good too: Reviewed-by

[PATCH v5 0/4] drm/omapdrm: gamma table support + drm_crtc_enable_color_mgmt()

On 26/05/16 13:17, Daniel Vetter wrote: > On Thu, May 26, 2016 at 11:35:44AM +0300, Jyri Sarha wrote: >> Implements gamma tables for OMAP4, OMAP5, and dra7xx SoCs and adds a >> workaround for errata that may break LCD1 channel if gamma tables >> are in use. >> >> Also adds new

[PATCH 00/26] fb/drm: omapdss: Clean up the headers and separate the two stack

Hi Peter, Tony, On 30/05/16 14:42, Peter Ujfalusi wrote: > Hi, > > omapfb is deprecated. It will not receive new features, only bug fixes. On > the. > other hand omapdrm is in active development and the fact that both > implementation (omapfb and omapdrm) is using the same header file >

[PATCH 0/4] drm: fix two atomic modesetting issues on v4.7-rc1

These fix two atomic modesetting issues on v4.7-rc1. The last one is a bit of an RFC. Tomi Tomi Valkeinen (4): drm: add missing drm_mode_set_crtcinfo call drm/sti: remove extra mode fixup drm: make drm_atomic_set_mode_prop_for_crtc() more reliable drm: fix fb refcount issue with atomic

[PATCH 1/4] drm: add missing drm_mode_set_crtcinfo call

setting the crtc related fields. drm_mode_set_crtcinfo() is removed from the legacy drm_mode_setcrtc() as that is no longer needed. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/drm_crtc.c | 2 -- drivers/gpu/drm/drm_modes.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a

[PATCH 2/4] drm/sti: remove extra mode fixup

Commit 652353e6e561c2aeeac62df183f721f6f9b5b45f ("drm/sti: set CRTC modesetting parameters") added a hack to avoid warnings related to setting mode with atomic API. With the previous patch, the hack should no longer be necessary. Signed-off-by: Tomi Valkeinen Cc: Benjamin Gaignard C

[PATCH 3/4] drm: make drm_atomic_set_mode_prop_for_crtc() more reliable

wrong length. - construct drm_display_mode first in an initialized local variable, and copy it to state->mode only when we know the call has succeeded. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/drm_atomic.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) d

[PATCH 4/4] drm: fix fb refcount issue with atomic modesetting

ng on here. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/drm_crtc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 06b6e2173697..0e3cc66aa8b7 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/

[PATCH v4.1 14/22] drm: omapdrm: Keep vblank interrupt enabled while CRTC is active

drivers/gpu/drm/omapdrm/omap_crtc.c | 79 > - > drivers/gpu/drm/omapdrm/omap_drv.h | 1 + > drivers/gpu/drm/omapdrm/omap_irq.c | 4 +- > 3 files changed, 37 insertions(+), 47 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- next part ---

[PATCH v4.1 22/22] drm: omapdrm: Perform initialization/cleanup at probe/remove time

/omap_drv.c | 211 > +++---- > 2 files changed, 105 insertions(+), 108 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819

[PATCH] fbdev: remove current maintainer

On 19/12/16 15:34, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Thursday, December 15, 2016 12:12:52 PM Andrew Morton wrote: >> On Thu, 8 Dec 2016 10:34:12 +0200 Tomi Valkeinen >> wrote: >> >>> Remove Tomi Valkeinen from fbdev maintainer and mark fbde

[PATCH 01/21] drm/tilcdc: disable console switching during pm operations

On 04/02/16 11:30, Jyri Sarha wrote: > From: Darren Etheridge > > The default behavior of consoles during power management operations is: On > entry to suspend a new console is allocated and switched to. On resume the > original console is restored. > > However this isn't the observed

[PATCH RFC] drm/atomic: Fall back to legacy call back in *_connector_dpms()

On 12/02/16 17:34, Daniel Vetter wrote: > On Fri, Feb 12, 2016 at 05:17:19PM +0200, Jyri Sarha wrote: >> Fall back to legacy drm_helper_connector_dpms() call back in >> drm_atomic_helper_connector_dpms() if DRIVER_ATOMIC feature is not >> present. >> >> Calling drm_atomic_helper_connector_dpms()

[PATCHv2 20/31] drm/omap: HDMI: Fix HSW value

On 29/02/16 23:55, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Friday 26 February 2016 11:36:08 Tomi Valkeinen wrote: >> On OMAP4 and OMAP5 ES1.0 the HDMI_WP_VIDEO_TIMING_H:HSW field is >> set directly to the HSW value. On

[PATCH 0/3] drm/omap: patches for v4.6 part 3

Hi, A few more patches for omapdrm for 4.6. These are based on the "drm/omap: patches for v4.6 part 2" series sent earlier. Tomi Laurent Pinchart (1): drm/omap: gem: Fix omap_gem_new() error path Tomi Valkeinen (2): drm/omap: remove -Werror from Makefile drm/omap: no need

[PATCH 1/3] drm/omap: remove -Werror from Makefile

Having -Werror in the omapdrm Makefile makes development and debugging a PITA. Let's remove it. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/Makefile b/drivers/gpu/drm/omapdrm

[PATCH 2/3] drm/omap: gem: Fix omap_gem_new() error path

ed-off-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_gem.c | 34 ++ 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c index 9ac30560e9b1..cc36a8

[PATCH 3/3] drm/omap: no need to select OMAP2_DSS

omapdss driver now depends on omapdrm, so we no longer should select OMAP2_DSS from omapdrm's Kconfig. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig index

[PATCH 1/3] drm/omap: remove -Werror from Makefile

On 03/03/16 20:44, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Thursday 03 March 2016 16:01:16 Tomi Valkeinen wrote: >> Having -Werror in the omapdrm Makefile makes development and debugging a >> PITA. Let's remove it. > > Well, shou

[GIT PULL] omapdrm changes for 4.6

in omap_gem_fault() Tomi Valkeinen (67): drm/omap: HDMI: change enable/disable to avoid sync-losts HACK: drm/omap: always use blocking DMM fill drm/omap: add dmm_read() and dmm_write() wrappers drm/omap: add define for DISPC_IRQ_WBUNCOMPLETEERROR drm/omap: use dma_mapping_error

[PATCH 01/42] drm/omap: fix suspend/resume handling

On 07/03/16 09:52, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Monday 22 February 2016 19:10:07 Tomi Valkeinen wrote: >> For legacy reasons omapdss handles system suspend/resume via PM notifier >> callback, where the driver disab

[PATCH 05/42] drm/omap: panel-dsi-cm: remove pdata support

On 07/03/16 10:04, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > On Monday 22 February 2016 19:10:11 Tomi Valkeinen wrote: >> We no longer have any boards that require the platform data support from >> the panel, so we can remove the related code. &

[PATCH 07/42] drm/omap: connector-dvi: remove pdata support

On 07/03/16 10:16, Laurent Pinchart wrote: >> @@ -319,17 +279,12 @@ static int dvic_probe(struct platform_device *pdev) >> >> platform_set_drvdata(pdev, ddata); >> >> -if (dev_get_platdata(>dev)) { >> -r = dvic_probe_pdata(pdev); >> -if (r) >> -

[PATCH 14/42] drm/omap, omapfb: move exported dispc function declarations to omapdrm/omapfb

On 07/03/16 10:42, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Monday 22 February 2016 19:10:20 Tomi Valkeinen wrote: >> omapdrm and omapfb still share the same include/video/omapdss.h. We need >> to change that so that we can proceed with

[PATCH 17/42] drm/omap: Add dispc_mgr_get_supported_outputs()

On 07/03/16 10:47, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Monday 22 February 2016 19:10:23 Tomi Valkeinen wrote: >> We are removing the use of the 'struct omap_overlay_manager' from >> omapdrm, and one part of that is

[PATCH 40/42] drm/omap: remove last uses of omap_overlay_manager

On 07/03/16 11:01, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Monday 22 February 2016 19:10:46 Tomi Valkeinen wrote: >> We have now removed all uses of 'struct omap_overlay_manager', so we can >> now remove the last places where it is s

[PATCH 18/42] drm/omap: remove crtc->mgr field

On 07/03/16 10:52, Laurent Pinchart wrote: > Hi Tomi, > > Thank you for the patch. > > On Monday 22 February 2016 19:10:24 Tomi Valkeinen wrote: >> In order to remove uses of 'struct omap_overlay_manager' from omapdrm, >> this patch removes the crtc->mgr field. &

[PATCH 00/23] Nokia N950 display support

On 08/03/16 22:45, Sebastian Reichel wrote: > Hi, > > On Tue, Mar 08, 2016 at 08:39:08PM +0200, Aaro Koskinen wrote: >> On Tue, Mar 08, 2016 at 05:39:32PM +0100, Sebastian Reichel wrote: >>> This series adds support for the Nokia N950 display. >>> Since the panel is using DSI command mode, it

[PATCH 00/23] Nokia N950 display support

On 09/03/16 18:19, Emil Velikov wrote: > Hi Sebastian, > > On 8 March 2016 at 16:39, Sebastian Reichel wrote: > >> arch/arm/boot/dts/omap3-n950-n9.dtsi| 72 + >> arch/arm/boot/dts/omap3-n950.dts| 71 + > Just a friendly reminder that updating

[PATCH] drm/omap: fix panel/encoder probes

The recent changes which removed platform data support from panels & encoders had a few mistakes, causing probes of DVI connector and DSI command mode panels to fail every time due to missing '!'. Fix the if()s. Signed-off-by: Tomi Valkeinen Reported-by: Laurent Pinchart --- Hi Dave, Can

omap4: how to get the HDMI core IRQ?

Hi Hans, On 24/03/16 23:20, Hans Verkuil wrote: > Hi Tomi, > > I hope you (or someone else on this list) can help me find the problem in > this code. > > I am working on a kernel framework for HDMI CEC (see > https://lwn.net/Articles/680942/). > In order to get as much experience with

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

On 09/09/14 13:43, Rob Clark wrote: > Although, I wonder if some waitqueue scheme would be a bit more sane.. > ie. end of apply_worker, if there is nothing more queued up, signal > the event that _flush() is waiting on. Maybe, but we would still need either the separate apply_lock, or unlock the

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

On 08/09/14 16:31, Daniel Vetter wrote: > On Mon, Sep 08, 2014 at 04:03:18PM +0300, Tomi Valkeinen wrote: >> 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

[PATCH 03/16] video: Add DT binding documentation for VGA connector

Hi, On 27/08/14 19:41, Laurent Pinchart wrote: > The VGA connector is described by a single input port and an optional > DDC bus. > > Cc: devicetree at vger.kernel.org > Cc: linux-fbdev at vger.kernel.org > Signed-off-by: Laurent Pinchart > --- >

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 17/09/14 17:29, Ajay kumar wrote: > Hi Tomi, > > Thanks for your comments. > > On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen > wrote: >> On 27/08/14 17:39, Ajay Kumar wrote: >>> Add documentation for DT properties supported by ps8622/ps8625 >>&

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 27/08/14 17:39, Ajay Kumar wrote: > Add documentation for DT properties supported by ps8622/ps8625 > eDP-LVDS converter. > > Signed-off-by: Ajay Kumar > --- > .../devicetree/bindings/video/bridge/ps8622.txt| 20 > > 1 file changed, 20 insertions(+) > create mode

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 18/09/14 08:50, Ajay kumar wrote: >>> Why do we need a complex graph when it can be handled using a simple >>> phandle? >> >> Maybe in your case you can handle it with simple phandle. Can you >> guarantee that it's enough for everyone, on all platforms? > Yes, as of now exynos5420-peach-pit

[PATCH v3 1/5] clk: ti: add "ti, gpio-gate-clock" controlled clock

On 16/09/14 23:40, Jyri Sarha wrote: > The added ti,gpio-gate-clock is a basic clock that can be enabled and > disabled trough a gpio output. The DT binding document for the clock > is also added. For EPROBE_DEFER handling the registering of the clock > has to be delayed until of_clk_get() call

[alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio

On 17/09/14 10:51, Jyri Sarha wrote: > On 09/17/2014 04:06 AM, Dave Airlie wrote: >> On 17 September 2014 06:40, Jyri Sarha wrote: >>> Changes since v2: >>> - Change compatible property from "ti,gpio-clock" to >>> "ti,gpio-gate-clock" >>> - Some minor cleanups >>> >>> The code has a functional

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 19/09/14 16:59, Ajay kumar wrote: > I am not really able to understand, what's stopping us from using this > bridge on a board with "complex" display connections. To use ps8622 driver, > one needs to "attach" it to the DRM framework. For this, the DRM driver Remember that when we talk about

[PATCH v3 1/5] clk: ti: add "ti, gpio-gate-clock" controlled clock

On 19/09/14 16:12, Nishanth Menon wrote: > On 09/19/2014 08:07 AM, Tomi Valkeinen wrote: >> On 16/09/14 23:40, Jyri Sarha wrote: >>> The added ti,gpio-gate-clock is a basic clock that can be enabled and >>> disabled trough a gpio output. The DT binding document for

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 22/09/14 11:06, Thierry Reding wrote: >>> Why do we need a complex graph when it can be handled using a simple >>> phandle? >> >> Maybe in your case you can handle it with simple phandle. Can you >> guarantee that it's enough for everyone, on all platforms? > > Nobody can guarantee that. An

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 17:29, Thierry Reding wrote: >>> Trying to do this within the bridge's node directly has two flaws: >>> >>> 1) It violates the DT principle of describing hardware. The >>>device itself does not know anything about multiple streams >>>and deals only with a single

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 13:01, Thierry Reding wrote: > On Tue, Sep 23, 2014 at 12:40:24PM +0300, Tomi Valkeinen wrote: >> On 23/09/14 11:35, Thierry Reding wrote: >> >>> Well, a display controller is never going to attach to a panel directly. >> >> With parallel RGB, th

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 17:38, Thierry Reding wrote: > On Tue, Sep 23, 2014 at 03:09:44PM +0300, Tomi Valkeinen wrote: >> On 23/09/14 13:01, Thierry Reding wrote: >>> On Tue, Sep 23, 2014 at 12:40:24PM +0300, Tomi Valkeinen wrote: > [...] >>>> What exactly is a bridge and

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 22/09/14 10:54, Thierry Reding wrote: >> I wish all new display component bindings would use the video >> ports/endpoints to describe the connections. It will be very difficult >> to improve the display driver model later if we're missing such critical >> pieces from the DT bindings. > > I

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 20/09/14 18:27, Javier Martinez Canillas wrote: > I see that Documentation/devicetree/bindings/video/ti,omap-dss.txt > mentions that the Video Ports binding documentation is in > Documentation/devicetree/bindings/video/video-ports.txt but I don't > see that this file exists in the kernel [1].

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 09:21, Thierry Reding wrote: >> Well, I can write almost any kind of bindings, and then evidently my >> device would work. For me, on my board. > > Well, that's the whole problem with DT. For many devices we only have a > single setup to test against. And even when we have several

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 22/09/14 11:26, Thierry Reding wrote: > On Fri, Sep 19, 2014 at 05:28:37PM +0300, Tomi Valkeinen wrote: >> On 19/09/14 16:59, Ajay kumar wrote: >> >>> I am not really able to understand, what's stopping us from using this >>> bridge on a board with "compl

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 08:53, Thierry Reding wrote: >> Yes, it's true we need a mux there. But we still have the complication >> that for panel0 we may need different ps8622 settings than for panel1. > > Yes, and that's why the bridge should be querying the panel for the > information it needs to determine

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 09:04, Thierry Reding wrote: > I certainly agree that it's useful to have standard ways to describe at > least various aspects. For example I think it would be useful to add > standard properties for a bridge's connections, such as "bridge" or > "panel" to allow bridge chaining and

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 11:35, Thierry Reding wrote: > Well, a display controller is never going to attach to a panel directly. With parallel RGB, that (almost) happens. There's voltage level shifting probably in the middle, but I don't see anything else there. > But I agree that it would be nice to unify

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 12:28, Thierry Reding wrote: >> But, for example, let's say that the board is designed in a way that for >> panel0 the bridge needs to output a bit higher level voltages than for >> panel1. That's not a property of the panel, so it can't be queried from >> the panel. >> >> That

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 12:39, Thierry Reding wrote: > My point is that if you use plain phandles you usually have the > meta-data already. Referring to the above example, bridge0 knows that it > should look for a bridge with phandle , whereas bridge1 knows > that the device it is connected to is a panel.

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 12:53, Thierry Reding wrote: >> Yes, but in this case we know of existing boards that have complex >> setups. It's not theoretical. > > Complex setups involving /this particular/ bridge and binding are > theoretical at this point, however. Right, but this discussion, at least from

[PATCH 4/9] drm/omap: clear omap_obj->paddr in omap_gem_put_paddr()

Clear omap_obj's paddr when unmapping the memory, so that it's easier to catch bad use of the paddr. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c

[PATCH 5/9] drm/omap: add pin refcounting to omap_framebuffer

DSS. This patch fixes the issue by adding a simple pin_count, used to track the number of pins. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_fb.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c b/drivers/gpu/drm/omapdrm

[PATCH 0/9] drm/omap: misc fixes

(the three last ones). Tomi Tomi Valkeinen (9): drm/omap: fix encoder-crtc mapping drm/omap: page_flip: return -EBUSY if flip pending drm/omap: fix race issue with vsync irq and apply drm/omap: clear omap_obj->paddr in omap_gem_put_paddr() drm/omap: add pin refcounting to omap_framebuf

[PATCH 7/9] drm/omap: fix operation without fbdev

omapdrm should work fine even if fbdev is missing. The current driver crashes in that case, though, as it is missing checks for the fbdev. Add the checks so that we don't free fbdev or restore fbdev mode when there's no fbdev. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 17:41, Thierry Reding wrote: > On Tue, Sep 23, 2014 at 12:34:54PM +0200, Andrzej Hajda wrote: >> On 09/23/2014 12:10 PM, Thierry Reding wrote: >>> On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote: On 09/23/2014 10:35 AM, Thierry Reding wrote: >>> [...] > But I

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 17:58, Thierry Reding wrote: >> But if a panel driver controls its video source, it makes sense for the >> panel driver to get its video source in its probe, and that happens >> easiest if the panel has a link to the video source. > > That's an orthogonal problem. You speak about the

[PATCH 1/9] drm/omap: fix encoder-crtc mapping

required by the omapdss driver. This patch changes the omapdrm to use the omapdss driver's hardcoded overlay managers, which fixes the issue. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_drv.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm

[PATCH 6/9] drm/omap: add a comment why locking is missing

unpin_worker() calls omap_framebuffer_unpin() without any locks, which looks very suspicious. However, both pin and unpin are always called via the driver's private workqueue, so the access is synchronized that way. Add a comment to make this clear. Signed-off-by: Tomi Valkeinen --- drivers

[PATCH 8/9] drm/omap: fix error handling in omap_framebuffer_create()

this by just calling kfree() for the allocated fb when an error happens. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_fb.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c b/drivers/gpu/drm/omapdrm/omap_fb.c index

[PATCH 9/9] drm/omap: handle mismatching color format and buffer width

mismatch: 5120/3 = 1706.666... bytes. This causes bad colors and a tilt on the screen. Add a check into omapdrm to return an error if the user tries to use such a combination. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_fb.c | 8 1 file changed, 8 insertions(+) diff --git

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 23/09/14 17:45, Thierry Reding wrote: > On Tue, Sep 23, 2014 at 02:31:35PM +0300, Tomi Valkeinen wrote: >> On 23/09/14 12:39, Thierry Reding wrote: >> >>> My point is that if you use plain phandles you usually have the >>> meta-data already. Referring to

[PATCH 2/9] drm/omap: page_flip: return -EBUSY if flip pending

The DRM documentation says: "If a page flip is already pending, the page_flip operation must return -EBUSY." Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning -EBUSY. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +- 1 file changed, 1

[PATCH 3/9] drm/omap: fix race issue with vsync irq and apply

ing a new variable, 'go_bit_set' which is used to track the supposed state of GO bit and helps the apply worker and irq handler handle the job without a race. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_crtc.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deleti

[PATCH 10/10] drm/omap: fix TILER on OMAP5

() which can be used to get the caching mode to be used. Note that without write-combining the use of the TILER buffer with CPU is unusably slow. It's still good to have it operational for testing purposes. Signed-off-by: Tomi Valkeinen --- One more patch, which was left out from the series. Tomi

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

copyright notice from fb_mem.c, although I have no > idea what exactly applies. > - Only compile this when needed. > > Cc: Geert Uytterhoeven > Cc: Plagniol-Villard > Cc: Tomi Valkeinen > Cc: linux-fbdev at vger.kernel.org > Signed-off-by: Daniel Vetter > >

[PATCH] drm/omap: move rotation property to drm core mode_config

On 06/08/14 11:40, Daniel Vetter wrote: > This allows us to ditch the driver-private lastclose logic. > > Cc: Tomi Valkeinen > Cc: Rob Clark > Signed-off-by: Daniel Vetter > > -- > > Untested and atm only applies on top of drm-intel-nightly. I could give this a t

[PATCH] drm/omap: move rotation property to drm core mode_config

On 30/09/14 14:52, Daniel Vetter wrote: > On Tue, Sep 30, 2014 at 01:49:20PM +0200, Daniel Vetter wrote: >> On Tue, Sep 30, 2014 at 02:42:01PM +0300, Tomi Valkeinen wrote: >>> On 06/08/14 11:40, Daniel Vetter wrote: >>>> This allows us to ditch the driver-private

[GIT PULL] drm/omap: changes for 4.1

Oops, I missed cc'ing the dri-devel list. Tomi On 02/04/15 13:50, Tomi Valkeinen wrote: > Hi Dave, > > Please pull changes for omapdrm. These are based on drm-next branch as there > were a few patches in drm-next from Laurent needed by these omapdrm changes. > > Tomi

[PATCH 00/31] Convert omapdrm to the atomic updates API

Hi, On 16/04/15 01:09, Laurent Pinchart wrote: > Hello, > > This patch set converts the omapdrm to the atomic update API in 31 small(ish) > and hopefully reviewable steps. Thanks! I'll start reviewing the patches later this week. > The series is based on the latest drm/next branch and depends

[PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector

On 07/03/14 16:17, Philipp Zabel wrote: > Hi, > > Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen: >> analog; >> digital-single-link; >> digital-dual-link; >> >> My reasoning to the format I chose was basically that when a connector >&g

[PATCH 0/9] Doc/DT: DT bindings for various display components

Hi Rob, On 10/03/14 18:05, Rob Herring wrote: >> Russell's point was that these connector bindings are very generic, i.e. >> they are not for any particular chip from a particular vendor, but for >> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we >> shouldn't define such

[PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector

On 28/02/14 18:25, Philipp Zabel wrote: > dvi-connector { > compatible = "dvi-connector"; > ddc-i2c-bus = <>; > > port { > dvi_d_in: endpoint at 0 { > remote-endpoint = <_out>; > }; > dvi_a_in: endpoint at 1 { >

[PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector

On 10/03/14 23:45, Rob Herring wrote: > I like this proposal over the others. Although, would dual link be a I don't like inferring the information. With the above, you can't find out that the DVI connector has digital and analog support before all the drivers are loaded. > single endpoint or 2

[PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector

On 11/03/14 10:00, Geert Uytterhoeven wrote: > On Tue, Mar 11, 2014 at 7:39 AM, Tomi Valkeinen > wrote: >> On 10/03/14 23:45, Rob Herring wrote: >>> I like this proposal over the others. Although, would dual link be a >> >> I don't like inferring the informatio

[PATCH 0/9] Doc/DT: DT bindings for various display components

Hi Grant, On 28/02/14 14:20, Tomi Valkeinen wrote: > Hi, > > This series is a re-send of > http://article.gmane.org/gmane.linux.drivers.devicetree/61739 > > I'm cc'ing more people, and I want to clarify the contents of the series: > > While this has been developed

[PATCH 0/9] Doc/DT: DT bindings for various display components

Hi Grant, Ping. Are you fine with me proceeding with the current V4L2 port/endpoint bindings? Tomi On 12/03/14 10:15, Tomi Valkeinen wrote: > Hi Grant, > > On 28/02/14 14:20, Tomi Valkeinen wrote: >> Hi, >> >> This series is a re-send of

[PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel

On 17/03/14 16:22, Laurent Pinchart wrote: >> +Example >> +--- >> + >> +lcd0: display { >> +compatible = "tpo,taal", "panel-dsi-cm"; >> +label = "lcd0"; >> + >> +gpios = < 6 GPIO_ACTIVE_HIGH>;/* 102, reset */ > > If the panel uses a TE GPIO but no reset GPIO, do you plan to

[PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel

On 17/03/14 16:19, Laurent Pinchart wrote: >> +Generic MIPI DPI Panel >> +== >> + >> +Required properties: >> +- compatible: "panel-dpi" >> + >> +Optional properties: >> +- label: a symbolic name for the panel >> +- gpios: panel enable gpio and backlight enable gpio > > While

[PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel

On 18/03/14 08:41, Tomi Valkeinen wrote: > On 17/03/14 16:19, Laurent Pinchart wrote: > >>> +Generic MIPI DPI Panel >>> +== >>> + >>> +Required properties: >>> +- compatible: "panel-dpi" >>> + >>>

[PATCHv2 0/8] Doc/DT: DT bindings for various display components

/digital/dual-link * hdmi-connector: add connector type * split 'gpios' property to named gpios * use 'clocks' properties for OMAP DSS components * removed 'simple-bus' from OMAP DSS Core's compatible strings [1] http://article.gmane.org/gmane.linux.drivers.devicetree/63885 Tomi Tomi Valkeinen (8

[PATCHv2 3/8] Doc/DT: Add DT binding documentation for DVI Connector

Add DT binding documentation for DVI Connector. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/dvi-connector.txt| 35 ++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/dvi

[PATCHv2 5/8] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel

Add DT binding documentation for MIPI DSI Command Mode Panel. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/panel-dsi-cm.txt | 29 ++ 1 file changed, 29 insertions(+) create mode 100644 Documentation/devicetree/bindings

[PATCHv2 7/8] Doc/DT: Add DT binding documentation for TFP410 encoder

Add DT binding documentation for TFP410 encoder Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/ti,tfp410.txt| 41 ++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410

[PATCHv2 2/8] Doc/DT: Add DT binding documentation for Analog TV Connector

On 18/03/14 10:40, Geert Uytterhoeven wrote: > Hi Tomi, > > On Tue, Mar 18, 2014 at 9:15 AM, Tomi Valkeinen > wrote: >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt >> @@ -0,0 +1,25 @@ >> +Analog TV Connector >&

[PATCHv2 2/8] Doc/DT: Add DT binding documentation for Analog TV Connector

Add DT binding documentation for Analog TV Connector. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../bindings/video/analog-tv-connector.txt | 25 ++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/video

[PATCHv2 1/8] Doc/DT: Add DT binding documentation for OMAP DSS

Add device tree bindings for OMAP Display Subsystem for the following SoCs: OMAP2, OMAP3, OMAP4. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/ti,omap-dss.txt | 211 + .../devicetree/bindings/video/ti,omap2-dss.txt | 54

[PATCHv2 4/8] Doc/DT: Add DT binding documentation for HDMI Connector

Add DT binding documentation for HDMI Connector. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/hdmi-connector.txt | 28 ++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/hdmi

[PATCHv2 6/8] Doc/DT: Add DT binding documentation for Sony acx565akm panel

Add DT binding documentation for Sony acx565akm panel Signed-off-by: Tomi Valkeinen Reviewed-by: Sebastian Reichel Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/sony,acx565akm.txt | 30 ++ 1 file changed, 30 insertions(+) create mode 100644 Documentation

<    2   3   4   5   6   7   8   9   10   11   >