On 21/09/16 09:56 PM, Daniel Vetter wrote:
> On Wed, Sep 21, 2016 at 1:19 PM, Christian König
> wrote:
>> Am 21.09.2016 um 13:04 schrieb Daniel Vetter:
>>> On Wed, Sep 21, 2016 at 12:30 PM, Christian König
>>> wrote:
Am 21.09.2016 um 11:56 schrieb Michel Dänzer:
>
>
> Looks li
On 21/09/16 07:30 PM, Christian König wrote:
> Am 21.09.2016 um 11:56 schrieb Michel Dänzer:
>>
>> FWIW, we seem to have the same issue with radeon vs. amdgpu: radeon only
>> seems to wait for exclusive fences, so e.g. running Xorg on amdgpu and
>> using PRIME slave scanout on radeon leaves artif
On 22/09/16 12:21 AM, Christian König wrote:
> Am 21.09.2016 um 17:13 schrieb Michel Dänzer:
>> On 21/09/16 07:30 PM, Christian König wrote:
>>> Am 21.09.2016 um 11:56 schrieb Michel Dänzer:
FWIW, we seem to have the same issue with radeon vs. amdgpu: radeon
only
seems to wait fo
On 22/09/16 12:15 AM, Christian König wrote:
> Am 21.09.2016 um 17:07 schrieb Michel Dänzer:
>> On 21/09/16 09:56 PM, Daniel Vetter wrote:
>>> On Wed, Sep 21, 2016 at 1:19 PM, Christian König
>>> wrote:
We use multiple writers without implicit syncing between processes
in the
>>>
ons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachme
is mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/4ac90695/attachment.html>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/30ee4a0c/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/c58593bb/attachment.html>
ave
posted a few? If so, I will upload one early next week (I will be away over the
weekend).
--
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/cc2625bf/attachment.html>
Hey
On Wed, Sep 21, 2016 at 4:59 PM, Tom Gundersen wrote:
> There are many reasons other than ENOMEM that drm_dev_init() can
> fail. Return ERR_PTR rather than NULL to be able to distinguish
> these in the caller.
>
> Signed-off-by: Tom Gundersen
> ---
Reviewed-by: David Herrmann
Thanks
David
On Thu, Sep 22, 2016 at 1:22 PM, Sean Paul wrote:
> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
> wrote:
>> On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
>>> Actually, could you please hold off picking this up? We need to make
>>> changes in mali-dp and hdlcd or thi
engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/42771ce4/attachm
> Guys, please stop accepting patches from Markus!
I would appreciate a bit more explanation for this request.
> Markus, you always introduce bugs.
I find the wording "always" exaggerated.
It can also happen that I make another programming mistake occasionally.
> I have asked you over and ov
--- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/3161331e/attachment.html>
On Thu, Sep 22, 2016 at 2:44 PM, Christian König
wrote:
>> - explicit fencing: Userspace passes around distinct fence objects for
>> any work going on on the gpu. The kernel doesn't insert any stall of
>> it's own (except for moving buffer objects around ofc). This is what
>> Android. This also s
On Thu, Sep 22, 2016 at 12:55 PM, Christian König
wrote:
> Am 22.09.2016 um 08:36 schrieb Daniel Vetter:
>>
>> On Wed, Sep 21, 2016 at 06:23:35PM +0200, Christian König wrote:
>>>
>>> For a quick workaround I suggest to just serialize all accesses to BO
>>> shared
>>> with different drivers, but
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/139d1073/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/64d40334/attachment-0001.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/e179e6fd/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/216afa6d/attachment.html>
2016-09-22 Christian König :
> Am 22.09.2016 um 09:44 schrieb Gustavo Padovan:
> > Hi Christian,
> >
> > 2016-09-21 Christian König :
> >
> > > Am 21.09.2016 um 13:36 schrieb Gustavo Padovan:
> > > > From: Gustavo Padovan
> > > >
> > > > If the fences in the fence_array signal on the fence_a
https://bugzilla.kernel.org/show_bug.cgi?id=172421
--- Comment #11 from Elmar Stellnberger ---
For the R5 230 long time experience is already available. I am successfully
using this card at least since February 2016 at a TMDS of 297Mhz and these
cards are doing very well on basis of everyday us
Am 22.09.2016 um 15:05 schrieb Daniel Vetter:
> On Thu, Sep 22, 2016 at 2:44 PM, Christian König
> wrote:
>>> - explicit fencing: Userspace passes around distinct fence objects for
>>> any work going on on the gpu. The kernel doesn't insert any stall of
>>> it's own (except for moving buffer obje
Am 22.09.2016 um 08:36 schrieb Daniel Vetter:
> On Wed, Sep 21, 2016 at 06:23:35PM +0200, Christian König wrote:
>> For a quick workaround I suggest to just serialize all accesses to BO shared
>> with different drivers, but essentially I think it is a perfectly valid
>> requirement to have multipl
Am 22.09.2016 um 14:26 schrieb Daniel Vetter:
> On Thu, Sep 22, 2016 at 12:55 PM, Christian König
> wrote:
>> Am 22.09.2016 um 08:36 schrieb Daniel Vetter:
>>> On Wed, Sep 21, 2016 at 06:23:35PM +0200, Christian König wrote:
For a quick workaround I suggest to just serialize all accesses to
On Wed, Sep 21, 2016 at 1:59 AM, Daniel Vetter
wrote:
> We removed it in
>
> commit 6ab10b76ff6252bd9be0849c40f5865e39a29961
> Author: Daniel Vetter
> Date: Fri Aug 12 22:48:45 2016 +0200
>
> drm/kms: Nuke dirty_info property
>
> Reviewed-by: Sean Paul
> Signed-off-by: Daniel Vetter
Di
On 19.09.2016 23:12, Daniel Vetter wrote:
> On Mon, Sep 19, 2016 at 8:27 PM, poma wrote:
>> @@ -122,14 +126,14 @@ int udl_handle_damage(struct udl_framebuffer *fb, int
>> x, int y,
>> return 0;
>> cmd = urb->transfer_buffer;
>>
>> - for (i = y; i < height ; i++) {
>>
ls fences on their own.
Regards,
Christian.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/3a486b47/attachment-0001.html>
On Wed, Sep 21, 2016 at 04:59:19PM +0200, Tom Gundersen wrote:
> There are many reasons other than ENOMEM that drm_dev_init() can
> fail. Return ERR_PTR rather than NULL to be able to distinguish
> these in the caller.
>
> Signed-off-by: Tom Gundersen
Looks good to me :)
Assuming you fixed all t
On Thu, Sep 22, 2016 at 5:09 AM, Russell King - ARM Linux
wrote:
> On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
>> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
>> wrote:
>> > On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
>> >> Actually, could you please
On Thu, Sep 22, 2016 at 01:28:37PM +0200, Daniel Vetter wrote:
>On Thu, Sep 22, 2016 at 1:22 PM, Sean Paul wrote:
>> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
>> wrote:
>>> On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
Actually, could you please hold off pick
>> For the next pile of driver patches _please_ talk with driver maintainers
>> before starting to create&submit patches.
Did the software development discussion start a bit here?
Would you like to support an other "talking style" on a conference
like in Berlin next month?
>> Like I said I won'
Hi Daniel,
On Thursday 22 Sep 2016 07:31:24 Daniel Vetter wrote:
> On Wed, Sep 21, 2016 at 3:59 PM, Laurent Pinchart wrote:
> > On Wednesday 21 Sep 2016 14:46:07 Daniel Vetter wrote:
> >> On Wed, Sep 21, 2016 at 2:39 PM, Laurent Pinchart wrote:
> > @@ -82,7 +82,7 @@ int amdgpu_align_pitch(stru
Am 22.09.2016 um 09:44 schrieb Gustavo Padovan:
> Hi Christian,
>
> 2016-09-21 Christian König :
>
>> Am 21.09.2016 um 13:36 schrieb Gustavo Padovan:
>>> From: Gustavo Padovan
>>>
>>> If the fences in the fence_array signal on the fence_array does not have
>>> signalling enabled num_pending will
On Wed, Sep 21, 2016 at 4:12 AM, Chris Wilson
wrote:
> On Wed, Sep 21, 2016 at 10:20:19AM +0300, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> When merging sync_files there is a case when we can end up with only one
>> fence in the merged sync_file: when all fences belong to the same
>>
On Wed, Sep 21, 2016 at 7:59 AM, Tom Gundersen wrote:
> If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
> as kstrdup() returns NULL. Instead check for this explicitly and
> return -EINVAL if no name is provided.
>
> Signed-off-by: Tom Gundersen
Thanks, applied to -misc
Sean
From: Markus Elfring
Date: Thu, 22 Sep 2016 08:08:08 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (4):
Use kmalloc_array() in qxl_device_init()
Move three assignments in qxl_device_init()
Improve a size determination in qxl_driver_
On 21.09.2016 00:07, Tobias Jakobi wrote:
> Hello,
>
> I'm currently facing the following problem.
>
> I want to use a devfreq device in one of the Exynos sub drivers, namely
> the G2D sub driver. My current approach is to use
> devfreq_get_devfreq_by_phandle() in g2d_probe(). But at the G2D probin
https://bugzilla.kernel.org/show_bug.cgi?id=172421
--- Comment #12 from Elmar Stellnberger ---
Today I approached to try out the dual-link feature of the DVI-port. First I
had verified with AOC that my u2868pqu monitor in deed supports dual-link over
DVI. Then I connected the DVI output of my R
On Thursday 22 Sep 2016 08:45:01 Daniel Vetter wrote:
> On Wed, Sep 21, 2016 at 06:35:59PM +0200, SF Markus Elfring wrote:
> > From: Markus Elfring
> > Date: Wed, 21 Sep 2016 18:28:38 +0200
> >
> > Several update suggestions were taken into account
> > from static source code analysis.
>
> For t
On Wed, Sep 21, 2016 at 7:59 AM, Tom Gundersen wrote:
> There are many reasons other than ENOMEM that drm_dev_init() can
> fail. Return ERR_PTR rather than NULL to be able to distinguish
> these in the caller.
>
> Signed-off-by: Tom Gundersen
Thanks, applied to -misc
Sean
> ---
> drivers/gpu
The imx_drm_bind function causes a warning in linux-next when
CONFIG_DRM_FBDEV_EMULATION is not set:
drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
drivers/gpu/drm/imx/imx-drm-core.c:441:1: error: label 'err_unbind' defined but
not used [-Werror=unused-label]
I don't understand
On Tue, Sep 20, 2016 at 06:23:33PM +0530, Sumit Semwal wrote:
> Hi Baoyou,
>
> On 20 September 2016 at 16:43, Gustavo Padovan wrote:
> > 2016-09-18 Baoyou Xie :
> >
> >> We get 1 warning when building kernel with W=1:
> >> drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for
> >>
Hey Andrzej,
Andrzej Hajda wrote:
> On 21.09.2016 00:07, Tobias Jakobi wrote:
>> Hello,
>>
>> I'm currently facing the following problem.
>>
>> I want to use a devfreq device in one of the Exynos sub drivers, namely
>> the G2D sub driver. My current approach is to use
>> devfreq_get_devfreq_by_ph
On Wed, Sep 21, 2016 at 3:59 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Wednesday 21 Sep 2016 14:46:07 Daniel Vetter wrote:
>> On Wed, Sep 21, 2016 at 2:39 PM, Laurent Pinchart wrote:
>> >> > @@ -82,7 +82,7 @@ int amdgpu_align_pitch(struct amdgpu_device *adev,
>> >> > int width, int bpp, bool
Am 22.09.2016 um 13:16 schrieb Gustavo Padovan:
> 2016-09-22 Christian König :
>
>> Dropping the rest of the patch, cause that really doesn't make sense any
>> more.
>>
>> Am 22.09.2016 um 12:40 schrieb Gustavo Padovan:
E.g. for example it is illegal to do something like
> "while(!fence_i
Am 22.09.2016 um 16:11 schrieb Christian König:
> Am 22.09.2016 um 13:16 schrieb Gustavo Padovan:
>> 2016-09-22 Christian König :
>>
>>> Dropping the rest of the patch, cause that really doesn't make sense
>>> any
>>> more.
>>>
>>> Am 22.09.2016 um 12:40 schrieb Gustavo Padovan:
> E.g. for e
Hi Sean,
On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
>On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
> wrote:
>> On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
>>> Actually, could you please hold off picking this up? We need to make
>>> changes in mali-dp
Thanks Russell, it's most appreciated.
On Wed, Sep 21, 2016 at 05:28:03PM +0100, Russell King - ARM Linux wrote:
>On Wed, Sep 21, 2016 at 09:57:38AM +0100, Brian Starkey wrote:
>> Hi Russell,
>>
>> Are you in a position to be able to test this now?
>
>Normally, I'd say no, because I'd normally wai
2016-09-22 Christian König :
> Dropping the rest of the patch, cause that really doesn't make sense any
> more.
>
> Am 22.09.2016 um 12:40 schrieb Gustavo Padovan:
> > > E.g. for example it is illegal to do something like
> > > >"while(!fence_is_signaled(f)) sleep();" without enabling signaling
https://bugzilla.kernel.org/show_bug.cgi?id=172421
Christian König changed:
What|Removed |Added
CC||deathsimple at vodafone.de
--- Commen
This one is actually a bug fix... But finding bug fixes in this series
is like looking for kernels of edible corn in piles of monkey poop.
Also, classic "One Err" bug.
regards,
dan carpenter
On Thu, Sep 22, 2016 at 11:47 AM, Eric Engestrom
wrote:
> On Wed, Sep 21, 2016 at 04:59:19PM +0200, Tom Gundersen wrote:
>> There are many reasons other than ENOMEM that drm_dev_init() can
>> fail. Return ERR_PTR rather than NULL to be able to distinguish
>> these in the caller.
>>
>> Signed-off-b
On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
wrote:
> On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
>> Actually, could you please hold off picking this up? We need to make
>> changes in mali-dp and hdlcd or this will mess up their registration.
>> I will send those pa
On Thu, Sep 22, 2016 at 8:28 AM, Emil Velikov
wrote:
> On 21 September 2016 at 15:59, Tom Gundersen wrote:
>> If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
>> as kstrdup() returns NULL. Instead check for this explicitly and
>> return -EINVAL if no name is provided.
>>
>> Sig
Hi Christian,
2016-09-21 Christian König :
> Am 21.09.2016 um 13:36 schrieb Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > If the fences in the fence_array signal on the fence_array does not have
> > signalling enabled num_pending will not be updated accordingly.
> >
> > So when signaling
On Wed, Sep 21, 2016 at 04:59:18PM +0200, Tom Gundersen wrote:
> If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
> as kstrdup() returns NULL. Instead check for this explicitly and
> return -EINVAL if no name is provided.
>
> Signed-off-by: Tom Gundersen
Reviewed-by: Daniel Vet
On 2016å¹´09æ21æ¥ 19:36, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> If the fences in the fence_array signal on the fence_array does not have
> signalling enabled num_pending will not be updated accordingly.
>
> So when signaling is disabled check the signal of every fence with
> fence
Guys, please stop accepting patches from Markus!
Markus, you always introduce bugs. I have asked you over and over to
stop sending "cleanup patches" because you are not careful. If you
restricted yourself to fixing bugs only then you would maybe fix more
bugs than you introduce but as it you are
Currently we use a linear walk to lookup a handle and return a dma-buf,
and vice versa. A long overdue TODO task is to convert that to a
hashtable. Since the initial implementation of dma-buf/prime, we now
have resizeable hashtables we can use (and now a future task is to RCU
enable the lookup!).
From: Markus Elfring
Date: Thu, 22 Sep 2016 10:06:50 +0200
The of_node_put() function was called in some cases
by the tilcdc_convert_slave_node() function during error handling
even if the passed variable contained a null pointer.
* Adjust jump targets according to the Linux coding style convent
From: Markus Elfring
Date: Thu, 22 Sep 2016 09:05:14 +0200
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
From: Markus Elfring
Date: Thu, 22 Sep 2016 10:25:43 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (4):
Use kmalloc_array()
Return directly after a failed kfree_table_init() in
tilcdc_convert_slave_node()
Less function calls in til
On Wed, Sep 21, 2016 at 06:23:35PM +0200, Christian König wrote:
> For a quick workaround I suggest to just serialize all accesses to BO shared
> with different drivers, but essentially I think it is a perfectly valid
> requirement to have multiple writers to one BO.
It is, but it's not possible
From: Markus Elfring
Date: Thu, 22 Sep 2016 09:29:23 +0200
Return directly after a memory allocation failed in this function
at the beginning.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
From: Markus Elfring
Date: Thu, 22 Sep 2016 10:15:36 +0200
Four local variables will be set to an appropriate pointer a bit later.
Thus omit the explicit initialisation which became unnecessary with
a previous update step.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/tilcdc/tilcdc_slave_c
Hello,
here's v2 of this patchset. I've added two other 'cosmetic' patches as well.
Anyway, I have fixed up the second patch and integrated Andrzej's suggestions.
First patch is unmodified except for the Reviewed-By tag.
With best wishes,
Tobias
Tobias Jakobi (4):
drm/exynos: mixer: convert
The mixer context struct already has a 'flags' field, so
we can use it to store the 'interlace', 'vp_enabled' and
'has_sclk' booleans.
We use the non-atomic helper functions to access these bits.
Reviewed-by: Andrzej Hajda
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c |
Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
in mixer_cfg_layer().
Trigger this via atomic flush.
Changes in v2:
- issue mixer_cfg_layer() in mixer_disable()
- rename fields as suggested by Andrzej
- added docu to mixer context struct
- simplify mixer_win_reset() as well
Signed-of
es/dri-devel/attachments/20160922/b11f88f8/attachment.html>
A simple while loop should do the same here.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c3dad66..4f39d6b 100644
Apply some 'make-up' in g2d_probe().
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 73cd83f..410d170 100644
--- a
On Wed, Sep 21, 2016 at 04:59:19PM +0200, Tom Gundersen wrote:
> There are many reasons other than ENOMEM that drm_dev_init() can
> fail. Return ERR_PTR rather than NULL to be able to distinguish
> these in the caller.
>
> Signed-off-by: Tom Gundersen
Reviewed-by: Daniel Vetter
> ---
> driver
On 21 September 2016 at 15:59, Tom Gundersen wrote:
> If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
> as kstrdup() returns NULL. Instead check for this explicitly and
> return -EINVAL if no name is provided.
>
> Signed-off-by: Tom Gundersen
> ---
> drivers/gpu/drm/drm_drv.c
Hi,
Changes since v1:
- separated the code changes from the omap/drm videomode conversion patches
- the DT bindings document is now explicitly states that the drive edge is
referring to the pixel clock
Since we have several panels under omapdrm/displays/ where the data drive edge
is set to be d
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/d
There are display panels which demands that the sync signal is driven on
different edge than the pixel data.
With the syncclk-active property we can specify the clk edge to be used to
drive the sync signal. When the property is missing it indicates that the
sync is driven on the same edge as the pi
On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
> wrote:
> > On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
> >> Actually, could you please hold off picking this up? We need to make
> >> changes in mali-dp and h
Use 'vm' to refer to a struct videomode instead of 'p', 't', 'timings' or
something else.
The code will be easier to follow if we use consistent names.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 26 ++---
drivers/gpu/drm/omapdrm/displays/connector-dv
In preparation to move the stack to use the generic videmode struct for
display timing information rename the hfp member to hfront_porch.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
driv
In preparation to move the stack to use the generic videmode struct for
display timing information rename the x_res member to hactive.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
dri
Remove the interlace member and add display_flags to omap_video_timings to
configure the interlace mode.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 2 --
drivers/gpu/drm/omapdrm/dss/dis
In preparation to move the stack to use the generic videmode struct for
display timing information use display_flags for h/vsync level.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 3 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 4 +--
drive
In preparation to move the stack to use the generic videmode struct for
display timing information rename the vsw member to vsync_len.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c
Hi,
Changes since v1:
- separated the patches from the sync drive edge selection series [1]
- commit messages updated as per Tomi's comments
- other comments from Tomi for patch 10 (was 13) and 11 (was 14) addressed also
The following series will convert the omapdrm stack to use the generic videm
omap_video_timings struct have the same members as struct videomode, but
their types are different. As first step change the types of the
omap_video_timings struct members to match their counterpart in
struct videomode to catch any type cast related issues.
Signed-off-by: Peter Ujfalusi
---
driv
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/
In preparation to move the stack to use the generic videmode struct for
display timing information use display_flags for DE level.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 4 ++--
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 2 +-
...
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, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu
On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
> Actually, could you please hold off picking this up? We need to make
> changes in mali-dp and hdlcd or this will mess up their registration.
> I will send those patches later today, but better if this all goes in
> together (whenever
According to the datasheet of the panel, both data, DEN and sync signals
are expected to be driven on the falling edge of the DOTCLK.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/
On Thu, Sep 22, 2016 at 05:32:35AM -0700, Sean Paul wrote:
> On Thu, Sep 22, 2016 at 5:09 AM, Russell King - ARM Linux
> wrote:
> > On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
> >> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
> >> wrote:
> >> > On Thu, Sep 22, 2016 at
In preparation to move the stack to use the generic videmode struct for
display timing information rename the vbp member to vback_porch.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c| 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c
In preparation to move the stack to use the generic videmode struct for
display timing information rename the y_res member to vactive.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c
In preparation to move the stack to use the generic videmode struct for
display timing information rename the hbp member to hback_porch.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c| 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
In preparation to move the stack to use the generic videmode struct for
display timing information use display_flags for pixel data edge.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 3 +--
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
Hi Tomi,
Now with the adv7393 driver in place, I was getting following error.
After debugging found out that this is due to the â.interlace= trueâ
in display timings
âdrivers\gpu\drm\omapdrm\displays\connector-analog-tv.câ.
[ 14.564872] [drm:drm_helper_probe_single_connector_modes_mer
The sync can be - and for some panels it must be - driven on different edge
then the data.
Signed-off-by: Peter Ujfalusi
CC: Rob Herring
CC: Mark Rutland
CC: devicetree at vger.kernel.org
---
include/video/display_timing.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/video/d
Configure the DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE flags according to the
binding document.
If the syncclk-active is present in DT, configure the flags accordingly, if
it is omitted it means that the SYNC edge is following the pixdata
configuration.
Signed-off-by: Peter Ujfalusi
CC: Rob Herring
CC
---
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160922/28e3d06f/attachment.html>
1 - 100 of 156 matches
Mail list logo
