Ping.
On 2013-02-18 16:09, Tomi Valkeinen wrote:
Hi Steffen,
On 2013-01-25 11:01, Steffen Trumtrar wrote:
+/* VESA display monitor timing parameters */
+#define VESA_DMT_HSYNC_LOW BIT(0)
+#define VESA_DMT_HSYNC_HIGH BIT(1)
+#define VESA_DMT_VSYNC_LOW BIT(2
On 2013-02-27 18:05, Steffen Trumtrar wrote:
Ah, sorry. Forgot to answer this.
On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote:
Ping.
On 2013-02-18 16:09, Tomi Valkeinen wrote:
Hi Steffen,
On 2013-01-25 11:01, Steffen Trumtrar wrote:
+/* VESA display monitor timing
On 2013-03-05 16:17, Archit Taneja wrote:
The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
output.
- the TV manager can suppport DPI, but the omapdss driver doesn't
, 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 tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers
to
DISPLAY_FLAGS_*.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/gpu/drm/drm_modes.c | 12 ++--
drivers/video/fbmon.c |8
drivers/video/of_display_timing.c | 19 +--
drivers/video
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 tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
are very common, and there
shouldn't be any misunderstanding about their meaning.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/gpu/drm/drm_modes.c | 18 +-
drivers/video/fbmon.c | 24
-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/videomode.c | 18 +-
include/video/display_timing.h | 25 -
2 files changed, 9 insertions(+), 34 deletions(-)
diff --git a/drivers/video
On 2013-03-12 08:07, Archit Taneja wrote:
On Monday 11 March 2013 05:58 PM, Tomi Valkeinen wrote:
On 2013-03-05 16:17, Archit Taneja wrote:
The support outputs struct for overlay managers is incorrect for
OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove
On 2013-03-12 15:06, 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 ops
On 2013-03-12 14:57, Archit Taneja wrote:
We could also use the recommended channel way for omapdrm, I can't
figure out what's the better approach at the moment.
Hmm, I think it'd be safer to use the recommended channel from omapdss
for now. The current omapdss code doesn't really let you
Hi,
On 2013-03-12 15:37, Laurent Pinchart wrote:
Hi Tomi,
Thanks for the patch.
On Tuesday 12 March 2013 12:19:38 Tomi Valkeinen wrote:
Structs videomode and display_timing have rather long field names for
the timing values. Nothing wrong with that as such, but this patch
changes them
On 2013-03-12 16:01, Archit Taneja wrote:
On Tuesday 12 March 2013 07:07 PM, Tomi Valkeinen wrote:
So, I don't disagree with you. But I don't quite understand why we could
not use the fixed channels for now? They should work in all the boards
we have, right? Or is there something with DRM
On 2013-03-12 16:38, Archit Taneja wrote:
memcmp on two structs is often not a good idea. There could be padding
bytes there, with uninitialized data. I'm not sure if that's the case
here, though, but it could well change any time (perhaps even depending
on compiler version).
I saw usage
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 following players around:
omapdss - omapdss handles the DSS (display subsystem) hardware. omapdss
doesn't do any buffer management or expose any userspace
On 2013-03-12 17:01, Archit Taneja wrote:
So, what I'm saying is that we should stick to output-dispc_channel. We
iterate through all the panels, and by using output-dispc_channel, we
get the manager for an output, and map that manager to a crtc, and make
sure the number of unique managers we
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 12 March 2013 12:19:38 Tomi Valkeinen wrote:
Structs videomode and display_timing have
On 2013-03-18 22:46, Rob Clark wrote:
On Wed, Mar 13, 2013 at 4:57 AM, Tomi Valkeinen to...@iki.fi 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 following players around:
omapdss - omapdss
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
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..
Well,
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: simplify videomode Kconfig
, 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 tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
Acked
to
DISPLAY_FLAGS_*.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/gpu/drm/drm_modes.c | 12 ++--
drivers/video/fbmon.c |8
drivers/video/of_display_timing.c | 19 +--
drivers/video
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 tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/videomode.c | 18 +-
include/video/display_timing.h | 25 -
2 files changed, 9 insertions(+), 34 deletions(-)
diff --git a/drivers/video
a given
display_timing to videomode.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c |2 +-
drivers/video/of_videomode.c |2 +-
drivers/video/videomode.c | 25
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 ops
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.
On 2013-03-26 15:45, Archit Taneja wrote:
Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come
because
some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase
the
DSI PLL
On 2013-03-26 15:45, Archit Taneja wrote:
These are misc fixes and improvements within omapdrm and omapdss. The fixes
do the
following:
- Make omapdrm smarter to choose the right overlay managers as it's crtcs.
This
makes sure that omapdrm is functional for OMAP platforms with
On 2013-03-27 08:58, Tomi Valkeinen wrote:
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
Hi Dave,
On 2013-03-13 10:57, 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 following players around:
omapdss - omapdss handles the DSS (display subsystem) hardware
a fb reference in omap_plane_update()
drm/omap: Fix and improve crtc and overlay manager correlation
Lars-Peter Clausen (1):
OMAPDSS: nec-nl8048 panel: Use dev_pm_ops
Sachin Kamat (1):
OMAPDSS: DSI: Use devm_clk_get()
Tomi Valkeinen (38):
OMAPDSS: add fields to panels
On 2013-04-18 11:37, Christoph Fritz wrote:
Hi Tomi
On Mon, 2013-04-15 at 13:57 +0300, Tomi Valkeinen wrote:
Tomi Valkeinen (38):
OMAPDSS: add fields to panels' platform data
OMAPDSS: DSI: remove DSI DISPC clk divisors from dssdev
OMAPDSS: HDMI: remove HDMI clk divisors
On 2013-04-18 12:09, Tomi Valkeinen wrote:
On 2013-04-18 11:37, Christoph Fritz wrote:
With linux-next this patch breaks compiling here because DPI now depends
on DSI - but my omap3 board here doesn't use DSI at all:
drivers/video/omap2/dss/dpi.c: In function ‘dpi_calc_pll_cb’:
drivers
On 2013-04-18 13:13, Christoph Fritz wrote:
On Thu, 2013-04-18 at 12:21 +0300, Tomi Valkeinen wrote:
On 2013-04-18 12:09, Tomi Valkeinen wrote:
On 2013-04-18 11:37, Christoph Fritz wrote:
With linux-next this patch breaks compiling here because DPI now depends
on DSI - but my omap3 board
Hi Dave,
On 2013-04-18 12:21, Tomi Valkeinen wrote:
On 2013-04-18 12:09, Tomi Valkeinen wrote:
On 2013-04-18 11:37, Christoph Fritz wrote:
With linux-next this patch breaks compiling here because DPI now depends
on DSI - but my omap3 board here doesn't use DSI at all:
drivers/video/omap2
for 3.10:
* Compilation fix when DSI is disabled in Kconfig
* Basic deferred probe support to fix DT boot
Tomi Valkeinen (17):
OMAPDSS: DPI: fix compilation if DSI not compiled in
OMAPDSS: Makefile: move omapfb after
Move the allocation of display_timing memory from of_get_display_timing() to
of_get_display_timings(). This allows us to use of_get_display_timing()
in a way that doesn't require dynamic memory allocation.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt
creates a new function:
int of_get_display_timing(struct device_node *np, const char *name,
struct display_timing *dt);
which can be used to parse a single display timing entry from the given
node name.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Steffen Trumtrar s.trumt
On 16/05/13 16:11, Artem Bityutskiy wrote:
On Thu, 2013-05-16 at 18:25 +0530, Viresh Kumar wrote:
On 16 May 2013 17:27, Artem Bityutskiy dedeki...@gmail.com wrote:
On Thu, 2013-05-16 at 13:15 +0200, Wolfram Sang wrote:
Despite various architectures and platform dependencies, I managed to
Hi,
I did some testing with omapdrm on v3.10-rc1. Here are some issues I
encountered.
For most of them I don't have any idea where to even start looking for a
problem,
so I hope that you may have some ideas.
dispc_runtime_get/put used in irq context
=
On 05/06/13 13:43, Rob Clark wrote:
On Wed, Jun 5, 2013 at 4:59 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
I did some testing with omapdrm on v3.10-rc1. Here are some issues I
encountered.
For most of them I don't have any idea where to even start looking for a
problem,
so I
On 05/06/13 13:57, Rob Clark wrote:
1) drmOpen(omap) will try to modprobe omap, not omapdrm so we
need to rename the .ko
Has something been changed that broke that? Or was omapdrm just a
badly chosen name from the start? If drmOpen(omapdrm) works now,
doesn't changing the module name break
On 05/06/13 14:52, Rob Clark wrote:
On Wed, Jun 5, 2013 at 7:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 05/06/13 13:57, Rob Clark wrote:
1) drmOpen(omap) will try to modprobe omap, not omapdrm so we
need to rename the .ko
Has something been changed that broke that? Or was omapdrm
On 15/06/13 15:20, Rob Clark wrote:
On Thu, Jun 13, 2013 at 6:31 AM, Paul Bolle pebo...@tiscali.nl wrote:
On Wed, 2013-03-13 at 20:48 +0100, Paul Bolle wrote:
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested. Perhaps the first test that people with access to the relevant
hardware
Hi,
On 09/08/13 20:14, Laurent Pinchart wrote:
MIPI DBI is a configurable-width parallel display bus that transmits
commands and data.
Add a new DBI Linux bus type that implements the usual bus
infrastructure (including devices and drivers (un)registration and
matching, and bus
Hi,
On 09/08/13 20:14, Laurent Pinchart wrote:
The Common Display Framework (CDF) splits display devices in entities
that interact through an abstract API. Each entity is managed by its own
driver independently of the other entities, with the framework
orchestrating interactions.
This
v3 concepts with Alexandre Courbot (NVidia) and Tomasz
Figa (Samsung).
- Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me.
- Linaro for inviting me to Linaro Connect Europe 2013, the discussions we had
there greatly helped moving CDF forward.
- And of course
On 06/09/13 17:09, Laurent Pinchart wrote:
Hi Tomi,
On Monday 26 August 2013 14:10:50 Tomi Valkeinen wrote:
On 09/08/13 20:14, Laurent Pinchart wrote:
MIPI DBI is a configurable-width parallel display bus that transmits
commands and data.
Add a new DBI Linux bus type that implements
On 06/09/13 18:43, Tomi Valkeinen wrote:
On 06/09/13 17:09, Laurent Pinchart wrote:
Hi Tomi,
On Monday 26 August 2013 14:10:50 Tomi Valkeinen wrote:
On 09/08/13 20:14, Laurent Pinchart wrote:
MIPI DBI is a configurable-width parallel display bus that transmits
commands and data.
Add a new
On 09/09/13 17:17, Rob Clark wrote:
On Mon, Sep 9, 2013 at 8:12 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 21/08/13 15:22, Rob Clark wrote:
And just to be clear, part of my negative experience about this is the
omapdss/omapdrm split. I just see cfd outside of drm as encouraging
On 21/08/13 15:22, Rob Clark wrote:
And just to be clear, part of my negative experience about this is the
omapdss/omapdrm split. I just see cfd outside of drm as encouraging
others to make the same mistake.
Feel free to disagree, but I think the omapdss/omapdrm split is a bit
different
On 18/09/13 16:17, Archit Taneja wrote:
On Wednesday 18 September 2013 06:11 PM, Tomi Valkeinen wrote:
On 18/09/13 14:08, Archit Taneja wrote:
Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI)
that require
regulators. The output's connect op tries to get a regulator which
On 19/09/13 11:49, Archit Taneja wrote:
omapdrm established connections for omap_dss_device devices when probed. It
should also be responsible to disconnect the devices. Keeping the devices
connected can prevent the panel driver modules from unloading, it can also
cause problems when omapdrm
On 25/09/13 14:51, Andrzej Hajda wrote:
of_display_timings_exist is implemented incorrectly.
It tries to find property instead of node.
The function is not used anyway so the patch removes it.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park
On 25/09/13 14:51, Andrzej Hajda wrote:
of_get_display_timing(s) use of_find_node_by_name
to get child node, this is incorrect, of_get_child_by_name
should be used instead. The patch fixes it.
Small typo is also corrected.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by:
On 09/08/13 20:14, Laurent Pinchart wrote:
Hi everybody,
Here's the third RFC of the Common Display Framework.
Hi,
I've been trying to adapt the latest CDF RFC for OMAP. I'm trying to gather
some notes here about what I've discovered or how I see things. Some of these I
have mentioned
Hi Andrzej,
On 02/10/13 15:23, Andrzej Hajda wrote:
Using Linux buses for DBI/DSI
=
I still don't see how it would work. I've covered this multiple times in
previous posts so I'm not going into more details now.
I implemented DSI (just command mode for now) as
On 09/10/13 17:08, Andrzej Hajda wrote:
As I have adopted existing internal driver for MIPI-DSI bus, I did not
take too much
care for DT. You are right, 'bta-timeout' is a configuration parameter
(however its
minimal value is determined by characteristic of the DSI-slave). On the
other
On 11/10/13 14:19, Andrzej Hajda wrote:
On 10/11/2013 08:37 AM, Tomi Valkeinen wrote:
The minimum bta-timeout should be deducable from the DSI bus speed,
shouldn't it? Thus there's no need to define it anywhere.
Hmm, specification says This specified period shall be longer then
the maximum
On 11/10/13 17:16, Andrzej Hajda wrote:
Picture size, content and format is the same on input and on output of DSI.
The same bits which enters DSI appears on the output. Internally bits
order can
be different but practically you are configuring DSI master and slave
with the same format.
Hi,
On 27/01/17 12:04, Jyri Sarha wrote:
> I hit these two problems while tracking scaling related problems with
> omapdrm on DSS5 HW.
>
> Jyri Sarha (2):
> Revert "drm: omapdrm: Let the DRM core skip plane commit on inactive
> CRTCs"
> drm/omapdrm: Move commit_modeset_enables() before
rm-next.
Thanks for the series. I've attached a patch for omapdrm, in case you're
sending v4 and want to include it in the series.
Tomi
From b03a468fdaf2b329a940f3980871c27bd8d0caa6 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkei...@ti.com>
Date: Wed, 8 Feb 2017 13:26:00 +0200
Subje
On 08/02/17 13:25, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
>
> On Tuesday 07 Feb 2017 16:41:20 Jyri Sarha wrote:
>> Let's disable all scaling that requires horizontal decimation with
>> higher factor than 4, until we have better estimates of what we can
>> and can not do.
On 07/02/17 16:41, Jyri Sarha wrote:
> Let's disable all scaling that requires horizontal decimation with
> higher factor than 4, until we have better estimates of what we can
> and can not do. However, 1 byte per pixel color format appear to work
> Ok with all decimation factors.
>
> When
On 28/01/17 18:17, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
>
> On Friday 27 Jan 2017 12:04:55 Jyri Sarha wrote:
>> Move drm_atomic_helper_commit_modeset_enables() call to before
>> drm_atomic_helper_commit_planes() call and have a
>> omap_atomic_wait_for_completion() call
On 28/01/17 18:11, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
>
> On Friday 27 Jan 2017 12:04:54 Jyri Sarha wrote:
>> This reverts commit dadf4659d0608e034b6633f30300c2eff2dafb4c.
>>
>> If planes are not disabled when the they are not on any crtc anymore
>> they will remain
t;
> ---
> drivers/gpu/drm/omapdrm/omap_debugfs.c | 9 -
> drivers/gpu/drm/omapdrm/omap_drv.c | 1 -
> drivers/gpu/drm/omapdrm/omap_drv.h | 1 -
> 3 files changed, 11 deletions(-)
Reviewed-by: Tomi Valkeinen <tomi.valkei...@ti.com>
Tomi
sign
Hi Dave,
Please pull these omapdrm fixes for v4.11.
Tomi
The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442:
Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux
into drm-next (2017-02-10 10:13:30 +1000)
are available in the git repository at:
On 08/02/17 16:08, Jyri Sarha wrote:
> Let's disable all scaling that requires horizontal decimation with
> higher factor than 4, until we have better estimates of what we can
> and can not do. However, NV12 color format appears to work Ok with
> all decimation factors.
>
> When decimating
On 24/10/16 12:47, Bartosz Golaszewski wrote:
> 2016-10-24 11:25 GMT+02:00 Jyri Sarha :
>> On 10/24/16 11:43, Bartosz Golaszewski wrote:
>>> Revision 1 of the IP doesn't work if we don't load the palette (even
>>> if it's not used, which is the case for the RGB565 format).
>>>
>>> Add a function
On 31/08/16 20:17, Jyri Sarha wrote:
> Remove double gamma table write in omap_crtc_atomic_flush().
> Fixes commit 492a426a2fc53
> ("drm/omapdrm: Implement gamma_lut atomic crtc properties")
>
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/omapdrm/omap_crtc.c | 13 -
> 1 file
On 31/08/16 16:14, Jyri Sarha wrote:
> Write DMA base and ceiling address with a single instruction, if
> available. This should make it more unlikely that LCDC would fetch the
> DMA addresses in the middle of an update. Having bad combination of
> addresses in dma base and ceiling (e.g base >
On 31/08/16 16:14, Jyri Sarha wrote:
> Add "blue-and-red-wiring"-device tree property and update devicetree
> binding document. The red and blue components are reversed between 24
> and 16 bit modes on am335x LCDC output pins. To get 24 RGB format the
> red and blue wires has to be crossed and
sed and this in turn causes 16 colors output
> to be in BGR format. With straight wiring the 16 color is RGB and 24
> bit is BGR. These patches try to deal with the issue in reasonable
> manner.
>
> For more details see section 3.1.1 in AM335x Silicon Errata:
> http://www.ti.com
Only minor fixes and cleanups here.
Andrew F. Davis (1):
drm/omap: remove unneeded conversions to bool
Jyri Sarha (1):
drm/omapdrm: Remove double gamma table write in omap_crtc_atomic_flush()
Tomi Valkeinen (3
On 06/09/16 11:19, Jyri Sarha wrote:
> Take mode config lock while updating the crtc clock rate. To avoid a
> race in tilcdc_crtc_update_clk(), we do not want the mode to change
> while we update crtc clock.
>
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 5 +
>
On 06/09/16 11:19, Jyri Sarha wrote:
> Add mutex to protect crtc enable and disable routines. The
> tilcdc_crtc_disable() function waits for frame done interrupt, the
> internal data will get out of sync, should another enable arrive while
> waiting for the interrupt.
Why doesn't the per-crtc
On 06/09/16 11:19, Jyri Sarha wrote:
> Add tilcdc_crtc_set_clk() and cleanup cpufreq_transition(). The new
> tilcdc_crtc_set_clk() is used in tilcdc_crtc_mode_set_nofb() instead
> tilcdc_crtc_update_clk(). New tilcdc_crtc_update_clk() is implemented
> using tilcdc_crtc_set_clk() for
On 06/09/16 11:19, Jyri Sarha wrote:
> +static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct tilcdc_drm_private *priv = dev->dev_private;
> + struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> + const unsigned clkdiv
Chen wrote:
> This reverts commit 2ab9f5879162499e1c4e48613287e3f59e593c4f.
>
> The of_get_next_parent will drop refcount on the passed node, so the reverted
> patch is wrong, thanks for Tomi Valkeinen points it.
>
> Cc: Tomi Valkeinen
> Signed-off-by: Peter Chen
>
On 06/09/16 23:59, Jyri Sarha wrote:
> WARN if CRTC is touched without CRTC lock. The crtc functions should
> not be called simultaneously from multiple threads. Having the DRM
> CRTC lock should take care of that.
>
> tilcdc_crtc_destroy() has to take the CRTC lock befor calling
>
m
> tilcdc_unload()
> drm/tilcdc: Take CRTC lock when calling tilcdc_crtc_disable()
> drm/tilcdc: WARN if CRTC is touched without CRTC lock
>
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 91
> +++-
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 12 ++---
> drivers/gpu/drm/tilcdc
Hi,
On 13/09/16 11:47, Vikas Patil wrote:
> Dear All,
>
> I also see some of the encoder driver are at
> "drivers/gpu/drm/omapdrm/displays/". I am confused about which driver
> I should consider for reference for adv7393 driver development.
>
> Do I need to use
>
Hi Dave,
Ping on this. This one is already in drm-next, so one can just
cherry-pick it: 5a78ff7bf7e25191144b550961001bbf6c734da4
Tomi
On 06/09/16 15:18, Tomi Valkeinen wrote:
> Hi Dave,
>
> Can you pick this for drm-fixes? The bug is causing scary looking stack
> dumps when loa
On 13/09/16 16:13, Vikas Patil wrote:
> Thanks Tomi for quick comment.
>
> I am thinking to base adv7393 driver on
> "drivers\gpu\drm\omapdrm\displays\encoder-tc358768.c" as I don't think
> any similar to adv7393 chip driver available. Could you please comment
> if this will help to get adv
On 08/09/16 17:44, Laurent Pinchart wrote:
> Various pieces of information about DRM formats (number of planes, color
> depth, chroma subsampling, ...) are scattered across different helper
> functions in the DRM core. Callers of those functions often need to
> access more than a single parameter
drm_fourcc.c | 186
> +--
> 1 file changed, 37 insertions(+), 149 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenP
On 08/09/16 17:44, Laurent Pinchart wrote:
> Replace calls to the drm_format_*() helper functions with direct use of
> the drm_format_info structure. This improves efficiency by removing
> duplicate lookups.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 23
On 15/09/16 01:22, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the review.
>
> On Wednesday 14 Sep 2016 14:49:26 Tomi Valkeinen wrote:
>> On 08/09/16 17:44, Laurent Pinchart wrote:
>>> Various pieces of information about DRM formats (number of planes, color
; Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_fourcc.c | 32
> drivers/gpu/drm/drm_framebuffer.c | 2 +-
> include/drm/drm_fourcc.h | 1 +
> 3 files changed, 26 insertions(+), 9 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
format instead of computing the number of
> bits per pixels first.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Tomi Valkeinen
> ---
> Changes since v3:
>
> - Removed DRM_FORMAT_ARGB support
> - Fixed coding style
> - Renamed min_pitch to pitch
> -
; 3 files changed, 15 insertions(+), 34 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://list
On 15/09/16 12:44, Vikas Patil wrote:
> On Wed, Sep 14, 2016 at 3:04 PM, Tomi Valkeinen
> wrote:
>>
>>
>> On 13/09/16 16:13, Vikas Patil wrote:
>>> Thanks Tomi for quick comment.
>>>
>>> I am thinking to base adv7393 driver on
>>>
On 01/09/16 14:22, Peter Ujfalusi wrote:
> In preparation to move the stack to use the generic videmode
> struct for display timing information.
I really don't like the description to depend on the subject =).
Tomi
-- next part --
A non-text attachment was scrubbed...
On 01/09/16 14:23, Peter Ujfalusi wrote:
> By using a pointer to the omap_vode_timings struct we can unwrap lines to
s/vode/mode/
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP
On 01/09/16 14:23, Peter Ujfalusi wrote:
> Remove the interlace member and add display_flags to omap_video_timings to
> configure the interlace mode.
>
> Signed-off-by: Peter Ujfalusi
> ---
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index
On 01/09/16 14:23, Peter Ujfalusi wrote:
> Instead of passing the omap_video_timings structure's members individually,
> use the pointer to the struct.
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 38
> ++---
> 1 file changed,
On 16/09/16 02:30, Laurent Pinchart wrote:
> I've checked the existing code that this patch series is replacing, and the
> [ARGB]{4} formats are currently reported as having a depth of 32. I'm not
> sure why that's the case, but I'd rather not touch it in this patch. If this
> is a bug we
101 - 200 of 3394 matches
Mail list logo
