scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/ef30b608/attachment.html>
On 10 October 2016 at 19:35, Haixia Shi wrote:
> The AUO t215hvn01 is a 21.5" 1920x1080 panel.
>
> v2: fix alphabetical order
>
Thanks for this and dropping the CHOMIUM/Reviewed-on tags.
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1575,6 +1602,
On Mon, Oct 10, 2016 at 06:10:42PM +0200, Daniel Vetter wrote:
> On Mon, Oct 10, 2016 at 6:04 PM, Ville Syrjälä
> wrote:
> > On Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
> >> Signed-off-by: Jani Nikula
> >>
> >> ---
> >>
> >> I needed this for some stuff that turned out to be a
On Mon, Oct 10, 2016 at 6:30 PM, Ville Syrjälä
wrote:
>> You can't hotplug CRTCs, like you can't hotplug anything else than
>> connectors. And for connectors we have an ida to make sure you never
>> end up with duplicated indizes. So I think we're safe.
>
> Except in i915 we don't abort the driv
On Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
>
> ---
>
> I needed this for some stuff that turned out to be a dead end. But this
> seems to be the right thing to do anyway.
> ---
> include/drm/drm_crtc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 de
Signed-off-by: Jani Nikula
---
I needed this for some stuff that turned out to be a dead end. But this
seems to be the right thing to do anyway.
---
include/drm/drm_crtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6
On Mon, Oct 10, 2016 at 6:04 PM, Ville Syrjälä
wrote:
> On Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
>> Signed-off-by: Jani Nikula
>>
>> ---
>>
>> I needed this for some stuff that turned out to be a dead end. But this
>> seems to be the right thing to do anyway.
>> ---
>> incl
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161010/7a128a79/attachment-0001.html>
From: Ville Syrjälä
We don't want all planes to be added to the state whenever a
plane with fixed zpos gets enabled/disabled. This is true
especially for eg. cursor planes on i915, as we want cursor
updates to go through w/o throttling. Same holds for drivers
that don't support zpos at all (i91
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/de432b11/attachment.html>
On Mon, Oct 10, 2016 at 05:50:56PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> We don't want all planes to be added to the state whenever a
> plane with fixed zpos gets enabled/disabled. This is true
> especially for eg. cursor planes on i915, as we want cursor
> u
On Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
>
> ---
>
> I needed this for some stuff that turned out to be a dead end. But this
> seems to be the right thing to do anyway.
Applied to drm-misc. There's also the connector and plane versions of
this, c
On Sun, Oct 09, 2016 at 03:49:10PM +0800, Shawn Guo wrote:
> On Mon, Oct 03, 2016 at 12:44:29PM -0500, Rob Herring wrote:
> > > +Example:
> > > +
> > > +vou: vou at 144 {
> > > + compatible = "zte,zx296718-vou";
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + reg = <0x144 0
On Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
Plus equivalents in drm_plane.h, drm_encoder.h ...
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Mon, Oct 10, 2016 at 03:14:22PM +0200, Daniel Vetter wrote:
> On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä
> wrote:
> >> I think the
> >> proper way is to keep track of a per-plane zpos changed (or compute
> >> that ad-hoc, we have both states). And only grab more planes if a zpos
> >> valu
The AUO t215hvn01 is a 21.5" 1920x1080 panel.
Link to spec: http://www.udmgroup.com/ftp/T215HVN01.0.pdf
v2: fix alphabetical order
v3: remove minor revision suffix ".0" and add link to spec
Signed-off-by: Haixia Shi
Tested-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
Cc: Emil Velikov
Cc:
On Mon, Oct 10, 2016 at 02:46:35PM +0200, Daniel Vetter wrote:
> On Mon, Oct 10, 2016 at 2:19 PM, wrote:
> > From: Ville Syrjälä
> >
> > We don't want all planes to be added to the state whenever a
> > plane with fixed zpos gets enabled/disabled. This is true
> > especially for eg. cursor plan
On Mon, Oct 10, 2016 at 3:32 PM, Ville Syrjälä
wrote:
> On Mon, Oct 10, 2016 at 03:14:22PM +0200, Daniel Vetter wrote:
>> On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä
>> wrote:
>> >> I think the
>> >> proper way is to keep track of a per-plane zpos changed (or compute
>> >> that ad-hoc, we
To make sure we don't place anything there which might confuse
the FE prefetcher. This gets rid of another case of FE MMU faults
when the address space gets crowded before triggering the reaper.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 3 ++-
1 file changed, 2 inser
If the GPU is done with one user command stream the buffers referenced
by this command stream may go away and get unmapped from the MMU. If
the write caches are still dirty at this point later evictions will run
into MMU faults, killing the GPU.
Make sure the write caches are flushed before signal
From: Ville Syrjälä
We don't want all planes to be added to the state whenever a
plane with fixed zpos gets enabled/disabled. This is true
especially for eg. cursor planes on i915, as we want cursor
updates to go through w/o throttling. Same holds for drivers
that don't support zpos at all (i91
ri-devel/attachments/20161010/57604e2b/attachment.html>
Am Mittwoch, den 05.10.2016, 21:45 +0530 schrieb Sumit Semwal:
> Hi Lucas,
>
> On 23 September 2016 at 18:25, Daniel Vetter wrote:
> > On Mon, Aug 29, 2016 at 08:08:25AM +0100, Chris Wilson wrote:
> >> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> >> timeout of 0 becomes
On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä
wrote:
>> I think the
>> proper way is to keep track of a per-plane zpos changed (or compute
>> that ad-hoc, we have both states). And only grab more planes if a zpos
>> value changed.
>
> Doesn't work with normalized zpos. The plane's actual zpos m
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161010/b6a0e6de/attachment-0001.html>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/1b038c82/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/d2364e66/attachment.html>
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/c205e4bc/attachment.html>
ably this problem doesn't performance impact, frame rate is the same as for
radeon.
--
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/atta
On 10/10/2016 12:45 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Monday 10 Oct 2016 11:05:10 Archit Taneja wrote:
>> On 10/07/2016 02:44 PM, Maxime Ripard wrote:
>>> On Fri, Oct 07, 2016 at 10:27:31AM +0530, Archit Taneja wrote:
>
> [snip]
>
If no one has any more objections within the ne
On Fri, Oct 07, 2016 at 10:42:17AM -0400, Rob Clark wrote:
> probably should keep the discussion on github (USAGE.md was updated a
> bit more and merged into https://github.com/cubanismo/allocator so
> look there for the latest)..
>
> but briefly:
>
> 1) my expectation is if the user is implement
Before accessing the u/v offset(aka, u/vbo for IPUv3) of the old plane state's
relevant fb, we should make sure the fb is in YU12 or YV12 pixel format(which
are the two YUV pixel formats we support only), otherwise, we are likely to
trigger BUG_ON() in drm_plane_state_to_u/vbo() since the fb's pixe
We added active plane reconfiguration support by forcing a full modeset
operation. So, looking at old_plane_state->fb to determine whether we need
to set u/v offset(aka, u/vbo for IPUv3) in ipu_plane_atomic_set_base()
or not is no more correct. Instead, we should do that only when we don't
need m
We added active plane reconfiguration support by forcing a full modeset
operation. So, looking at old_plane_state->fb to determine whether we need to
switch EBA buffer(for hardware double buffering) in ipu_plane_atomic_set_base()
or not is no more correct. Instead, we should do that only when we
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/bcf3b2ca/attachment-0001.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161010/dee597f8/attachment-0001.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/8970703a/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161010/47f457fb/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161010/a0a23026/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/b8b6d44f/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161010/d5d64b27/attachment.html>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/2ca6a4b1/attachment-0001.html>
On Mon, Oct 10, 2016 at 2:19 PM, wrote:
> From: Ville Syrjälä
>
> We don't want all planes to be added to the state whenever a
> plane with fixed zpos gets enabled/disabled. This is true
> especially for eg. cursor planes on i915, as we want cursor
> updates to go through w/o throttling. Same
loading game and benchmark (60s), i had to trim the log
because didn't fit :)
--
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/atta
On Mon, Oct 10, 2016 at 2:35 PM, Haixia Shi wrote:
> The AUO t215hvn01 is a 21.5" 1920x1080 panel.
>
> v2: fix alphabetical order
>
> Signed-off-by: Haixia Shi
> Tested-by: Haixia Shi
> Reviewed-by: Stéphane Marchesin
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/panel/panel-simple.c | 3
ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/3c2b2770/attachment.html>
y :)
I don't see any performance regression.
--
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/20161010/bceb50dc/attachment.html>
I don't know if it's performance impact, probably not, works really fast.
--
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
On 6 October 2016 at 16:21, Tomeu Vizoso wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
>
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
>
> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
> start a
act, frame rate is the same as for
radeon.
--
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/20161010/bdfe5968/attachment.html>
Adding Benjamin Gaignard to CC in case he wants to comment on the
usage of the registration functions, as suggested by Daniel Vetter.
Regards,
Tomeu
On 6 October 2016 at 17:21, Tomeu Vizoso wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
>
> dr
ubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/bbae90ab/attachment.html>
On Mon, 10 Oct 2016 10:28:31 +0200,
Jani Nikula wrote:
>
> On Mon, 10 Oct 2016, "Sun, Jing A" wrote:
> > Dear Maintainers,
> >
> > Please kindly review my patch as below. It's based on the mainline branch.
> >
> > From b401009f79883ac5e9d41525c9d54b800ece2e22 Mon Sep 17 00:00:00 2001
> > From: Ji
fixed.
--
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/20161010/b880cdd4/attachment.html>
The AUO t215hvn01 is a 21.5" 1920x1080 panel.
v2: fix alphabetical order
Signed-off-by: Haixia Shi
Tested-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
---
drivers/gpu/drm/panel/panel-simple.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/dr
The AUO t215hvn01 is a 21.5" 1920x1080 panel.
Signed-off-by: Haixia Shi
Reviewed-on: https://chromium-review.googlesource.com/394328
Tested-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
---
drivers/gpu/drm/panel/panel-simple.c | 30 ++
1 file changed, 30 insertion
On Mon, 10 Oct 2016, "Sun, Jing A" wrote:
> Dear Maintainers,
>
> Please kindly review my patch as below. It's based on the mainline branch.
>
> From b401009f79883ac5e9d41525c9d54b800ece2e22 Mon Sep 17 00:00:00 2001
> From: Jing SUN
> Date: Mon, 10 Oct 2016 14:06:54 +0800
> Subject: [PATCH 1/1] d
On Sun, Oct 09, 2016 at 08:28:19PM +0300, Grazvydas Ignotas wrote:
> When DisplayPort AUX channel i2c adapter is registered, drm_connector's
> kdev member is used as a parent, so we get sysfs structure like:
> /drm/card1/card1-DP-2/i2c-12
> Because of that, there is a problem when drm core (and n
On Sun, Oct 09, 2016 at 08:07:00PM +0300, Grazvydas Ignotas wrote:
> There is no late_unregister(), it looks like the comment meant
> late_register(). Also fix a typo while at it.
>
> Signed-off-by: Grazvydas Ignotas
Applied to drm-misc, thanks.
-Daniel
> ---
> include/drm/drm_connector.h | 4
On Fri, Oct 07, 2016 at 09:27:41AM +0200, Christophe JAILLET wrote:
> We should use 'ida_simple_remove()' instead of 'ida_remove()' when freeing
> resources allocated with 'ida_simple_get()'.
>
> Signed-off-by: Christophe JAILLET
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm
On 10/07/2016 02:44 PM, Maxime Ripard wrote:
> On Fri, Oct 07, 2016 at 10:27:31AM +0530, Archit Taneja wrote:
>>
>>
>> On 10/07/2016 02:34 AM, Laurent Pinchart wrote:
>>> Hi Sean,
>>>
>>> On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
On Thu, Oct 6, 2016 at 1:27 PM, Laurent Pinchart wrote
Hi Patrik,
I am using the gma500 driver of the latest stable kernel, 4.8.1. My hardware
is Atom N2600 processor integrated graphics controller, PCI PID: 0x0be1.
Output is LVDS. The system starts with framebuffer console enabled. Later in
the boot process I unbind the console with the following c
On 09/29/16 19:43, Bartosz Golaszewski wrote:
> Some architectures don't use the common clock framework and don't
> implement all the clk interfaces for every clock. This is the case
> for da850-lcdk where clk_set_rate() only works for PLL0 and PLL1.
>
> Trying to set the clock rate for the LCDC c
sounded like it could be similar to my problem but it didn't help.
--
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/20161010/
The underscores variant frees the pointers inside, while the
no-underscores variant calls underscores and then frees the struct.
Signed-off-by: Eric Anholt
Fixes: d8dbf44f13b9 ("drm/vc4: Make the CRTCs cooperate on allocating display
lists.")
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/vc
application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/65bef188/attachment.sig>
Hi Archit,
On Monday 10 Oct 2016 11:05:10 Archit Taneja wrote:
> On 10/07/2016 02:44 PM, Maxime Ripard wrote:
> > On Fri, Oct 07, 2016 at 10:27:31AM +0530, Archit Taneja wrote:
[snip]
> >> If no one has any more objections within the next day, I'll pull in
> >> Maxime's v5 RGB to VGA bridge driv
On 10/03/16 18:45, Bartosz Golaszewski wrote:
> Due to some potential tweaks for the da850 LCDC (for example: the
> required memory bandwith settings) we need a separate compatible
> for the IP present on the da850 boards.
>
> Suggested-by: Sekhar Nori
> Signed-off-by: Bartosz Golaszewski
Thank
On Fri, Oct 07, 2016 at 12:06:25AM +0800, Chen-Yu Tsai wrote:
> The A31's display pipeline has 2 frontends, 2 backends, and 2 TCONs. It
> also has new display enhancement blocks, such as the DRC (Dynamic Range
> Controller), the DEU (Display Enhancement Unit), and the CMU (Color
> Management Unit).
On Fri, Oct 07, 2016 at 12:06:21AM +0800, Chen-Yu Tsai wrote:
> The A31 and A31s also have the DRC as part of the display pipeline.
> As we know virtually nothing about them, just add compatible strings
> for both SoCs to the stub driver.
>
> Signed-off-by: Chen-Yu Tsai
> ---
> Documentation/dev
SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interfac
Hi Laurent,
Thanks for review.
On 07.10.2016 16:58, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch.
>
> On Friday 07 Oct 2016 09:02:42 Andrzej Hajda wrote:
>> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
>> It is controlled via I2C bus. Its interaction with other
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/5d803573/attachment.html>
oltage_control(hwmgr)) {
> tmp_result = smu7_enable_voltage_control(hwmgr);
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/0af7d6a6/attachment.sig>
On 07.10.2016 16:44, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch.
>
> On Friday 07 Oct 2016 09:02:41 Andrzej Hajda wrote:
>> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
>> via I2C bus.
>>
>> Signed-off-by: Andrzej Hajda
>> Acked-by: Rob Herring
On Mon, 2016-10-10 at 01:46 +0200, Patrik Jakobsson wrote:
> On Mon, Oct 10, 2016 at 1:07 AM, Shyam Saini
> wrote:
> >
> > Replace explicit computation of vma page count by a call to
> > vma_pages()
> Hi, I already have this patch in the "queue" from:
> Muhammad Falak R Wani
>
> Will include th
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/c1554b7a/attachment.html>
Replace explicit computation of vma page count by a call to
vma_pages()
Signed-off-by: Shyam Saini
---
drivers/gpu/drm/gma500/framebuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 3a44e
On Mon, Oct 10, 2016 at 1:07 AM, Shyam Saini wrote:
> Replace explicit computation of vma page count by a call to
> vma_pages()
Hi, I already have this patch in the "queue" from:
Muhammad Falak R Wani
Will include that one when I get around to sending out a PR.
Thanks
Patrik
>
> Signed-off-by
l/attachments/20161010/667e5c5b/attachment-0001.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161010/7bd4970b/attachment.html>
|--- |FIXED
--
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/20161010/95cd4f6e/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161010/5ca80808/attachment.html>
83 matches
Mail list logo
