On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote:
> dma_map_resource() is the right API (thought its current implementation
> is fill with x86 assumptions). So i would argue that arch can decide to
> implement it or simply return dma error address which trigger fallback
> path into the
On 29/03/18 17:44, Sebastian Reichel wrote:
>> * omap_fb.c:326: condition 0 is always false
>> * omap_fb.c:326: condition 0 is always false
>> * omap_fb.c:327: condition connector!=from is always false
>
> Looks like list_for_each_entry_from() is not properly understood
> by the static chec
On Thu, Mar 29, 2018 at 10:25:52AM -0600, Logan Gunthorpe wrote:
>
>
> On 29/03/18 10:10 AM, Christian König wrote:
> > Why not? I mean the dma_map_resource() function is for P2P while other
> > dma_map_* functions are only for system memory.
>
> Oh, hmm, I wasn't aware dma_map_resource was exc
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #10 from MirceaKitsune ---
Created attachment 138438
--> https://bugs.freedesktop.org/attachment.cgi?id=138438&action=edit
Screenshot of the Blender window glitching
I should add another detail to the discussion. I know this may b
On Mon, Mar 26, 2018 at 10:30:23AM +0300, Joonas Lahtinen wrote:
> Quoting Matt Roper (2018-03-23 17:46:16)
> > On Fri, Mar 23, 2018 at 02:15:38PM +0200, Joonas Lahtinen wrote:
> > > Quoting Matt Roper (2018-03-17 02:08:57)
> > > > This is the fourth iteration of the work previously posted here:
>
https://bugs.freedesktop.org/show_bug.cgi?id=102553
Stefano Cipriani changed:
What|Removed |Added
CC||cip9...@gmail.com
--- Comment #12 fr
On Thu, Mar 29, 2018 at 01:51:43PM +0200, Takashi Iwai wrote:
> On Thu, 29 Mar 2018 13:46:26 +0200, Lukas Wunner wrote:
> > The system sleep PM ops azx_suspend() and azx_resume() were previously
> > called by vga_switcheroo, but commit 07f4f97d7b4b ("vga_switcheroo: Use
> > device link for HDA cont
Am Donnerstag, den 29.03.2018, 22:36 +0530 schrieb Nayan Deshmukh:
> Move it with the scheduler code. This is mostly a straight forward
> rename with no code change except for updating the TRACE_INCLUDE_PATH
>
> Signed-off-by: Nayan Deshmukh
> Suggested-by: Christian König
Acked-by: Lucas Stach
https://bugs.freedesktop.org/show_bug.cgi?id=104825
--- Comment #16 from mlen ---
I'll test it on saturday, I don't have access to that machine at the moment
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailin
Am Donnerstag, den 29.03.2018, 22:36 +0530 schrieb Nayan Deshmukh:
> this patch also effect the amdgpu and etnaviv drivers which
> use the function drm_sched_entity_init
>
> Signed-off-by: Nayan Deshmukh
> Suggested-by: Christian König
Acked-by: Lucas Stach
> ---
> drivers/gpu/drm/amd/amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=105680
--- Comment #4 from Jose Roberto de Souza ---
This one is not related to memory, it is because the resolution is bigger than
the resolution that hardware track can handle, so there is not fix for those.
You can run this tests with "--use-small-m
Patches #2 and #3 are Reviewed-by: Christian König
as well.
If Lucas has no objections I'm going to pull those into
amd-staging-drm-next next week.
Regards,
Christian.
Am 29.03.2018 um 19:06 schrieb Nayan Deshmukh:
The series is based on drm-next. The 2nd patch also affects
amdgpu and etna
Am 29.03.2018 um 18:25 schrieb Logan Gunthorpe:
On 29/03/18 10:10 AM, Christian König wrote:
Why not? I mean the dma_map_resource() function is for P2P while other
dma_map_* functions are only for system memory.
Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping
P2P. Though i
On Thu, Mar 29, 2018 at 8:56 PM, Alex Deucher wrote:
> On Tue, Mar 27, 2018 at 1:29 PM, Nayan Deshmukh
> wrote:
>> On Tue, Mar 27, 2018 at 1:47 PM, Daniel Vetter wrote:
>>> On Mon, Mar 26, 2018 at 08:51:14PM +0530, Nayan Deshmukh wrote:
Signed-off-by: Nayan Deshmukh
>>>
>>> You might want
There is no @kernel parameter anymore and document the
@guilty parameter
Signed-off-by: Nayan Deshmukh
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/dr
this patch also effect the amdgpu and etnaviv drivers which
use the function drm_sched_entity_init
Signed-off-by: Nayan Deshmukh
Suggested-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgp
Move it with the scheduler code. This is mostly a straight forward
rename with no code change except for updating the TRACE_INCLUDE_PATH
Signed-off-by: Nayan Deshmukh
Suggested-by: Christian König
---
drivers/gpu/drm/scheduler/gpu_scheduler.c| 2 +-
{include/drm => drive
The series is based on drm-next. The 2nd patch also affects
amdgpu and etnaviv drivers.
Nayan Deshmukh (3):
drm/scheduler: fix param documentation
drm/scheduler: remove unused parameter
drm/scheduler: move the tracepoints file from the include directory
drivers/gpu/drm/amd/amdgpu/amdgpu_ct
Quoting Ville Syrjälä (2018-03-29 17:14:05)
> On Thu, Mar 29, 2018 at 05:01:13PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjala (2018-03-29 16:50:23)
> > > From: Ville Syrjälä
> > >
> > > Having the EDID available is often very beneficial for bug analysis,
> > > even when the EDID itself is
On Mon, Mar 26, 2018 at 10:28:06PM +0200, Daniel Vetter wrote:
> On Thu, Mar 22, 2018 at 05:22:52PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > drm_atomic_helper_shutdown() needs to release the reference held by
> > plane->fb, so we want to use drm_atomic_clean_old_fb() in
> > drm
On Thu, Mar 29, 2018 at 05:01:13PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-03-29 16:50:23)
> > From: Ville Syrjälä
> >
> > Having the EDID available is often very beneficial for bug analysis,
> > even when the EDID itself is valid and not the direct cause of the
> > bug. So let's
Am 29.03.2018 um 17:45 schrieb Logan Gunthorpe:
On 29/03/18 05:44 AM, Christian König wrote:
Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe:
On 28/03/18 01:44 PM, Christian König wrote:
Well, isn't that exactly what dma_map_resource() is good for? As far as
I can see it makes sure IOMMU is aw
https://bugs.freedesktop.org/show_bug.cgi?id=104825
--- Comment #15 from Andrey Grodzovsky ---
(In reply to mlen from comment #3)
> I tested amd-staging-drm-next with HEAD at
> f1367d12f5fabb04789c7772594887434c8d9e8b. This time the unbind succeeded,
> but there are still some errors logged and k
Quoting Ville Syrjala (2018-03-29 16:50:23)
> From: Ville Syrjälä
>
> Having the EDID available is often very beneficial for bug analysis,
> even when the EDID itself is valid and not the direct cause of the
> bug. So let's dump the EDID to dmesg even when it's valid. This
> should also give us a
From: Ville Syrjälä
Having the EDID available is often very beneficial for bug analysis,
even when the EDID itself is valid and not the direct cause of the
bug. So let's dump the EDID to dmesg even when it's valid. This
should also give us a better historical record of EDIDs for later
analysis.
On Thu, Mar 29, 2018 at 10:04:33AM -0500, Rob Herring wrote:
> On Mon, Mar 19, 2018 at 1:19 AM, wrote:
> > On 2018-03-18 18:19, Rob Herring wrote:
> >>
> >> On Wed, Mar 14, 2018 at 11:21:37AM +0530, Sravanthi Kollukuduru wrote:
> >>>
> >>> Remove DT entries of hw block offsets and other target sp
On Tue, Mar 27, 2018 at 1:29 PM, Nayan Deshmukh
wrote:
> On Tue, Mar 27, 2018 at 1:47 PM, Daniel Vetter wrote:
>> On Mon, Mar 26, 2018 at 08:51:14PM +0530, Nayan Deshmukh wrote:
>>> Signed-off-by: Nayan Deshmukh
>>
>> You might want to add a kerneldoc page in Documentation/gpu/scheduler.rst,
>>
From: Gustavo Padovan
Add support for async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.
v6: add missing drm_atomic_set_fb_for_plane() in
vc4_plane_atomic_async_update() (Boris Brezillon)
"Mao, David" writes:
> Hi Keith,
> If I read the patch correctly, the plane has been interpreted as the same as
> connector, and the stackIndex is the index of connector of current device.
> Is it by intentional?
> If the hardware don't have underlay/overlay supported, is it better to
> always r
On Mon, Mar 19, 2018 at 1:19 AM, wrote:
> On 2018-03-18 18:19, Rob Herring wrote:
>>
>> On Wed, Mar 14, 2018 at 11:21:37AM +0530, Sravanthi Kollukuduru wrote:
>>>
>>> Remove DT entries of hw block offsets and other target specific catalog
>>> information for SDM845.
>>
>>
>> That is clear from th
On Thu, Mar 29, 2018 at 03:59:24PM +0530, Sravanthi Kollukuduru wrote:
> Currently, the downstream driver depends on the DT file for the
> hardware block offsets and other target specific catalog information.
> To align the driver with the upstream DT design, this information is now
> removed from
On Thu, Mar 29, 2018 at 07:39:08PM +0530, Ramalingam C wrote:
> In both HDMI and DP, device count is represented by 6:0 bits of a
> register(BInfo/Bstatus)
>
> So macro for bitmasking the device_count is fixed(0x3F->0x7F).
>
Reviewed-by: Sean Paul
> Signed-off-by: Ramalingam C
> cc: Sean Pau
On Thu, Mar 29, 2018 at 07:39:06PM +0530, Ramalingam C wrote:
> In case of V prime mismatch, DP HDCP spec mandates the re-read of
> Vprime atleast twice.
>
> This patch needed for DP HDCP1.4 CTS Test: 1B-05.
>
> v2:
> Moved the V' validation into a function for retry. [Sean Paul]
>
> Signed-of
Sorry, didn't mean to drop the lists here. re-adding.
On Wed, Mar 28, 2018 at 4:05 PM, Alex Deucher wrote:
> On Wed, Mar 28, 2018 at 3:53 PM, Logan Gunthorpe wrote:
>>
>>
>> On 28/03/18 01:44 PM, Christian König wrote:
>>> Well, isn't that exactly what dma_map_resource() is good for? As far as
>
On Thu, Mar 29, 2018 at 07:39:05PM +0530, Ramalingam C wrote:
> As per DP spec when R0 mismatch is detected, HDCP source supported
> re-read the R0 atleast twice.
>
> And For HDMI and DP minimum wait required for the R0 availability is
> 100mSec. So this patch changes the wait time to 100mSec but
On Thu, Mar 29, 2018 at 07:39:07PM +0530, Ramalingam C wrote:
> HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
> is enabled. Using the I915 power well infrastruture, above requirement
> is verified.
>
> This patch enables the hdcp initialization for HSW, BDW, and BXT.
>
>
On Thursday 29 March 2018 07:39 PM, Ramalingam C wrote:
First two patches needed for below DP HDCP compliance tests
1A-06 and 1B-05
Third patch fixes the HDCP1.4 Key loadability check. where as fourth
one fixes the downstream device count read.
Fix for HDMI HDCP1.4 CTS tests: 1A-04 and
In both HDMI and DP, device count is represented by 6:0 bits of a
register(BInfo/Bstatus)
So macro for bitmasking the device_count is fixed(0x3F->0x7F).
Signed-off-by: Ramalingam C
cc: Sean Paul
---
include/drm/drm_hdcp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/incl
First two patches needed for below DP HDCP compliance tests
1A-06 and 1B-05
Third patch fixes the HDCP1.4 Key loadability check. where as fourth
one fixes the downstream device count read.
Fix for HDMI HDCP1.4 CTS tests: 1A-04 and 1A-07a are functional.
But the change from v2, as thinking
HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
is enabled. Using the I915 power well infrastruture, above requirement
is verified.
This patch enables the hdcp initialization for HSW, BDW, and BXT.
v2:
Choose the PW# based on the platform.
Signed-off-by: Ramalingam C
R
In case of V prime mismatch, DP HDCP spec mandates the re-read of
Vprime atleast twice.
This patch needed for DP HDCP1.4 CTS Test: 1B-05.
v2:
Moved the V' validation into a function for retry. [Sean Paul]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 113 +++
As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.
And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.
This
https://bugs.freedesktop.org/show_bug.cgi?id=105300
--- Comment #11 from tempel.jul...@gmail.com ---
One of the recent changes in drm-next-4.17-wip has also introduced this issue
for the old legacy DC.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=105680
--- Comment #3 from Jani Saarinen ---
>From Tomi:
"SKL-6770hq BIOS settings
Graphics minimum memory 64MB -> 256MB,
Graphics mem aperture 256MB -> 1024MB
Hopefully helps.
--
You are receiving this mail because:
You are the assignee for the b
Hi Oleksandr,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20180329]
[cannot apply to v4.16-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
https://bugs.freedesktop.org/show_bug.cgi?id=105177
--- Comment #21 from Reimar Imhof ---
Btw.: There is a new bug showing up with a 4.16.0-rc7 kernel (I did not test
rc1 to rc6): The screen flickers. I can't tell you whats triggers such a
flicker but it does.
That bug is still around with the dr
https://bugs.freedesktop.org/show_bug.cgi?id=105177
--- Comment #20 from Reimar Imhof ---
I've tried drm-next-4.17-wip.
What I've seen is the same as described with the initial bug description:
When monitor is connected via hdmi I get wrong colors. This appears during boot
before the gui (x.org)
On 29 March 2018 at 13:31, Sebastian Reichel
wrote:
> Hi,
>
> On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote:
>> On 29 March 2018 at 11:40, Tomi Valkeinen wrote:
>> > omap_framebuffer_get_next_connector() is not used, remove it.
>> >
>> Seems to have been unused for a few years now.
From: Oleksandr Andrushchenko
Hello!
When using Xen PV DRM frontend driver then on backend side one will need
to do copying of display buffers' contents (filled by the
frontend's user-space) into buffers allocated at the backend side.
Taking into account the size of display buffers and frames pe
From: Oleksandr Andrushchenko
Introduce Xen zero-copy helper DRM driver, add user-space API of the driver:
1. DRM_IOCTL_XEN_ZCOPY_DUMB_FROM_REFS
This will create a DRM dumb buffer from grant references provided
by the frontend. The intended usage is:
- Frontend
- creates a dumb/display buff
在 2018/3/29 16:59, Christian König 写道:
Am 29.03.2018 um 10:37 schrieb zhoucm1:
On 2018年03月28日 16:13, zhoucm1 wrote:
On 2018年03月27日 21:44, Christian König wrote:
How about we update the LRU only when we need to re-validate at
least one BO?
I tried this just now, performance still isn't
On 29/03/18 15:31, Sebastian Reichel wrote:
> Hi,
>
> On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote:
>> On 29 March 2018 at 11:40, Tomi Valkeinen wrote:
>>> omap_framebuffer_get_next_connector() is not used, remove it.
>>>
>> Seems to have been unused for a few years now.
>> Namely
On 2018-03-29 13:18, Tomi Valkeinen wrote:
> On 22/03/18 15:42, Peter Ujfalusi wrote:
>> From: Tomi Valkeinen
>>
>> Errata i878 says that MPU should not be used to access RAM and DMM at
>> the same time. As it's not possible to prevent MPU accessing RAM, we
>> need to access DMM via a proxy.
>>
On 29/03/18 13:58, Emil Velikov wrote:
> On 29 March 2018 at 11:40, Tomi Valkeinen wrote:
>> audio_config function for both HDMI4 and HDMI5 return uninitialized
>> value as the error code if the display is not currently enabled. For
>> some reason this has not caused any issues.
>>
> Doubt many pe
On Thu, 29 Mar 2018 13:46:26 +0200,
Lukas Wunner wrote:
>
> The system sleep PM ops azx_suspend() and azx_resume() were previously
> called by vga_switcheroo, but commit 07f4f97d7b4b ("vga_switcheroo: Use
> device link for HDA controller") removed their invocation.
>
> Unfortunately the commit ne
Hi Laurent,
Thank you for another patch :D
On 26/02/18 21:45, Laurent Pinchart wrote:
> In order to make the vsp1_du_setup_lif() easier to read, and for
> symmetry with the DRM pipeline input setup, move the pipeline output
> setup code to a separate function.
>
> Signed-off-by: Laurent Pinchart
The system sleep PM ops azx_suspend() and azx_resume() were previously
called by vga_switcheroo, but commit 07f4f97d7b4b ("vga_switcheroo: Use
device link for HDA controller") removed their invocation.
Unfortunately the commit neglected to update the #ifdef surrounding the
two functions, so if CON
Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe:
On 28/03/18 01:44 PM, Christian König wrote:
Well, isn't that exactly what dma_map_resource() is good for? As far as
I can see it makes sure IOMMU is aware of the access route and
translates a CPU address into a PCI Bus address.
I'm using that wit
Hi Laurent,
Thank you for the patch,
On 26/02/18 21:45, Laurent Pinchart wrote:
> When disabling a DRM plane, the corresponding RPF is only marked as
> removed from the pipeline in the atomic update handler, with the actual
> removal happening when configuring the pipeline at atomic commit time.
Am 29.03.2018 um 08:57 schrieb Daniel Vetter:
On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote:
Add a peer2peer flag noting that the importer can deal with device
resources which are not backed by pages.
Signed-off-by: Christian König
Um strictly speaking they all should, but t
On 03/28/2018 06:09 PM, Daniel Vetter wrote:
On Wed, Mar 28, 2018 at 10:38:35AM +0300, Oleksandr Andrushchenko wrote:
From: Noralf Trønnes
Use srcu to protect drm_device.unplugged in a race free manner.
Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
sections preventing acce
On 03/28/18 16:35, Emil Velikov wrote:
> On 28 March 2018 at 11:27, Laszlo Ersek wrote:
>> On 03/28/18 03:24, Emil Velikov wrote:
>>> Gents, can someone double-check this please? Just in case.
>>
>> I guess I should test whether this series regresses the use case
>> described in c2cbc38b97; is th
On 29 March 2018 at 11:40, Tomi Valkeinen wrote:
> tiler_reserve_2d allocates memory but does not check if it got the
> memory. Add the check and return ENOMEM on failure.
>
> Signed-off-by: Tomi Valkeinen
It's funny when the function call (kzalloc here) is just outside the context ;-)
Reviewed-
On 29 March 2018 at 11:40, Tomi Valkeinen wrote:
> omap_framebuffer_get_next_connector() is not used, remove it.
>
Seems to have been unused for a few years now.
Namely since commit 5a35876e2830511cb8110667fc426c6a6165a593
Reviewed-by: Emil Velikov
-Emil
On 29 March 2018 at 11:40, Tomi Valkeinen wrote:
> audio_config function for both HDMI4 and HDMI5 return uninitialized
> value as the error code if the display is not currently enabled. For
> some reason this has not caused any issues.
>
Doubt many people try hdmi audio with disabled display ;-)
audio_config function for both HDMI4 and HDMI5 return uninitialized
value as the error code if the display is not currently enabled. For
some reason this has not caused any issues.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 2 +-
drivers/gpu/drm/omapdrm/dss/hdmi5.c |
tiler_reserve_2d allocates memory but does not check if it got the
memory. Add the check and return ENOMEM on failure.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/dri
omap_framebuffer_get_next_connector() is not used, remove it.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_fb.c | 27 ---
drivers/gpu/drm/omapdrm/omap_fb.h | 2 --
2 files changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drive
Currently, the downstream driver depends on the DT file for the
hardware block offsets and other target specific catalog information.
To align the driver with the upstream DT design, this information is now
removed from the DT file and added in the driver source.
Change-Id: I63a366d7d7a26939ee1c20
This patch series aims at adding the target specific hardware
catalog information in driver source.
As a result, the current logic of dt based parsing is removed.
The DT clean up patch corresponding to this driver change will
be posted separately.
[V2]
* Addressed Rob Herring's comment to updat
On 22/03/18 15:42, Peter Ujfalusi wrote:
> From: Tomi Valkeinen
>
> Errata i878 says that MPU should not be used to access RAM and DMM at
> the same time. As it's not possible to prevent MPU accessing RAM, we
> need to access DMM via a proxy.
>
> This patch changes DMM driver to access DMM regis
Hi Vladimir,
On Tue, Mar 27, 2018 at 02:03:25PM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/27/2018 01:10 PM, jacopo mondi wrote:
> > Hi Vladimir,
> >
> > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> >> Hi Jacopo,
> >>
> >> On 03/27/2018 11:57 AM, jacopo mondi
On 27/03/18 11:23, Daniel Vetter wrote:
> - None of the list walkings where protected.
>
> - Switch to a mutex since the list walking could potentially take a
> very long time.
>
> Only thing we need to be careful with here is that while we walk the
> list we cant unreference any gem objects, s
On 28/03/18 14:41, Daniel Vetter wrote:
> The only thing that omap_gem_free_object does that might need the
> magic protection of struct_mutex (of keeping all objects alive if that
> lock is held, even if the last reference is gone) is the mm_list
> manipulation.
>
> But that is already protected
On 03/29/2018 12:22 PM, Oleksandr Andrushchenko wrote:
Changes since v4:
For your convenience I am attaching diff between v4..v5
diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst
index 8188e03c9d23..009d942386c5 100644
--- a/Documentation/gpu/xen-front.rst
+++ b/Docu
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
X
From: Oleksandr Andrushchenko
Hello!
Boris/Daniel, I put your R-b tags, so please do let me know if this is not
acceptable, so I remove the tags.
This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io/displif
Am 29.03.2018 um 10:37 schrieb zhoucm1:
On 2018年03月28日 16:13, zhoucm1 wrote:
On 2018年03月27日 21:44, Christian König wrote:
How about we update the LRU only when we need to re-validate at
least one BO?
I tried this just now, performance still isn't stable, sometime drop
to 28fps by accide
On Tue, Mar 27, 2018 at 10:24:17AM +0200, Paul Kocialkowski wrote:
> Hi,
>
> On Fri, 2018-03-23 at 11:06 +0100, Maxime Ripard wrote:
> > On Wed, Mar 21, 2018 at 04:28:59PM +0100, Paul Kocialkowski wrote:
> > > In order to check whether the frontend supports a specific format,
> > > an
> > > explic
https://bugs.freedesktop.org/show_bug.cgi?id=105680
Marta Löfstedt changed:
What|Removed |Added
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org
On 2018年03月28日 16:13, zhoucm1 wrote:
On 2018年03月27日 21:44, Christian König wrote:
How about we update the LRU only when we need to re-validate at least
one BO?
I tried this just now, performance still isn't stable, sometime drop
to 28fps by accident.
I also tried to check num_evictions,
On Tue, Mar 27, 2018 at 10:08:48AM +0200, Paul Kocialkowski wrote:
> On Fri, 2018-03-23 at 11:03 +0100, Maxime Ripard wrote:
> > On Wed, Mar 21, 2018 at 04:28:58PM +0100, Paul Kocialkowski wrote:
> > > In order to check whether the backend supports a specific format, an
> > > explicit list and a re
On 03/29/2018 10:17 AM, Daniel Vetter wrote:
On Wed, Mar 28, 2018 at 01:29:46PM +0300, Oleksandr Andrushchenko wrote:
Hi, Daniel!
I just noticed I have missed one change in the patch:
the below must be static.
On 03/28/2018 10:42 AM, Daniel Vetter wrote:
+enum drm_mode_status display_mode_val
Fixes: d7f404c8b4b6 ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Fengguang Wu
---
xen_drm_front_kms.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 54504
:
https://github.com/0day-ci/linux/commits/Oleksandr-Andrushchenko/drm-xen-front-Add-support-for-Xen-PV-display-frontend/20180329-090744
base: git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF
On Thu, Mar 29, 2018 at 9:35 AM, Philippe CORNU wrote:
> Hi Daniel,
>
> On 03/27/2018 05:51 PM, Daniel Vetter wrote:
>> On Mon, Feb 26, 2018 at 01:16:04PM +0100, Philippe Cornu wrote:
>>> This patch clarifies the adjusted_mode documentation
>>> for a bridge directly connected to a crtc.
>>>
>>> Si
https://bugs.freedesktop.org/show_bug.cgi?id=105797
Timothy Arceri changed:
What|Removed |Added
Blocks||102625
Referenced Bugs:
https://bugs
Hi Daniel,
On 03/27/2018 05:51 PM, Daniel Vetter wrote:
> On Mon, Feb 26, 2018 at 01:16:04PM +0100, Philippe Cornu wrote:
>> This patch clarifies the adjusted_mode documentation
>> for a bridge directly connected to a crtc.
>>
>> Signed-off-by: Philippe Cornu
>> ---
>> This patch is linked to the
https://bugs.freedesktop.org/show_bug.cgi?id=102625
Timothy Arceri changed:
What|Removed |Added
Depends on||105797
Referenced Bugs:
https://bugs
https://bugs.freedesktop.org/show_bug.cgi?id=102625
Timothy Arceri changed:
What|Removed |Added
Resolution|NOTOURBUG |---
Status|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=102625
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=105797
--- Comment #2 from Timothy Arceri ---
Seems like another game running on this engine was fixed after a release with a
newer version of the engine. See bug #102625
--
You are receiving this mail because:
You are the assignee for the bug.__
On Wed, Mar 28, 2018 at 04:11:39PM +0100, Emil Velikov wrote:
> On 28 March 2018 at 15:49, Chris Wilson wrote:
> > Quoting Emil Velikov (2018-03-28 02:24:48)
> >> From: Deepak Sharma
> >>
> >> Modify vgem_init to take platform dev as parent in drm_dev_init.
> >> This will make drm device availabl
On Wed, Mar 28, 2018 at 01:29:46PM +0300, Oleksandr Andrushchenko wrote:
> Hi, Daniel!
>
> I just noticed I have missed one change in the patch:
> the below must be static.
>
> On 03/28/2018 10:42 AM, Daniel Vetter wrote:
> > +enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
> > +
On Wed, Mar 28, 2018 at 02:25:12PM +0200, Boris Brezillon wrote:
> On Wed, 28 Mar 2018 14:22:36 +0200
> Daniel Vetter wrote:
>
> > On Wed, Mar 28, 2018 at 09:34:54AM +0200, Boris Brezillon wrote:
> > > Hi Peter,
> > >
> > > On Mon, 26 Mar 2018 09:35:02 +0200
> > > Peter Rosin wrote:
> > >
>
Hi Kieran,
On Wednesday, 28 March 2018 17:43:13 EEST Kieran Bingham wrote:
> On 26/02/18 21:45, Laurent Pinchart wrote:
> > The DRM pipeline setup code used at atomic commit time is similar to the
> > setup code used when enabling the pipeline. Move it to a separate
> > function in order to share
Hi Kieran,
On Wednesday, 28 March 2018 17:10:10 EEST Kieran Bingham wrote:
> On 26/02/18 21:45, Laurent Pinchart wrote:
> > The DRM pipeline handling code uses the entity's pipe list head to check
> > whether the entity is already included in a pipeline. This method is a
> > bit fragile in the sen
97 matches
Mail list logo
