Am 15.05.2018 um 21:42 schrieb Alex Deucher:
On Tue, May 15, 2018 at 3:31 PM, Andrey Grodzovsky
wrote:
Follwoing change 75fbed2 we need to skip KIQ ring when iterating
amdgpu_ctx's scheduler entites.
Signed-off-by: Andrey Grodzovsky
Typo in the title: realted -> related
Typo in the descripti
I suppose you wanted to respond on the list, so I have added back all
recipients.
On 16.05.2018 06:39, spa...@codeaurora.org wrote:
> On 2018-05-15 19:23, Andrzej Hajda wrote:
>> On 15.05.2018 07:52, Sandeep Panda wrote:
>>> Add support for TI's sn65dsi86 dsi2edp bridge chip.
>>> The chip converts
Hi Ville,
On 15/05/2018 17:35, Ville Syrjälä wrote:
> On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
>> This patchs adds the cec_notifier feature to the intel_hdmi part
>> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
>> between each HDMI ports.
>> T
On 16/05/2018 09:31, Neil Armstrong wrote:
> Hi Ville,
>
> On 15/05/2018 17:35, Ville Syrjälä wrote:
>> On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
>>> This patchs adds the cec_notifier feature to the intel_hdmi part
>>> of the i915 DRM driver. It uses the HDMI DRM connector na
Hi Enric,
On 15/05/2018 18:40, Enric Balletbo Serra wrote:
> Hi Neil,
>
> I suspect that this patch will conflict with some patches that will be
> queued for 4.18 that also introduces new devices, well, for now I
> don't see these merged in the Lee's tree.
Indeed, I found your patches, I'll reba
Hi Hans,
On 15/05/2018 17:28, Hans Verkuil wrote:
> On 05/15/2018 04:42 PM, Neil Armstrong wrote:
>> The EC can expose a CEC bus, this patch adds the CEC related definitions
>> needed by the cros-ec-cec driver.
>> Having a 16 byte mkbp event size makes it possible to send CEC
>> messages from the
On Wed, May 16, 2018 at 12:20 AM, Jagan Teki wrote:
> On Wed, May 16, 2018 at 12:12 PM, Chen-Yu Tsai wrote:
>> On Mon, May 14, 2018 at 11:03 AM, Jagan Teki
>> wrote:
>>> On Thu, Apr 19, 2018 at 3:02 PM, Chen-Yu Tsai wrote:
This panel is marketed as Banana Pi 7" LCD display. On the back is
https://bugs.freedesktop.org/show_bug.cgi?id=104598
Michel Dänzer changed:
What|Removed |Added
Version|DRI git |git
Product|DRI
https://bugs.freedesktop.org/show_bug.cgi?id=106519
--- Comment #10 from Christian König ---
Please provide the output of vainfo.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freed
On Wed, May 16, 2018 at 9:53 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function
> 'init_user_pages':
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_
Until now, the drm-intel commit access have been handed out ad hoc,
without transparency, consistency, or fairness. With pressure to add
more committers, this is no longer tenable, if it ever was. Document the
requirements and expectations around becoming a drm-intel committer.
The drm-intel maint
Hello!
On 5/16/2018 10:54 AM, Simon Horman wrote:
Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.
Signed-off-by: Ulrich Hecht
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/dri
https://bugs.freedesktop.org/show_bug.cgi?id=106404
Michel Dänzer changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
Boris Brezillon writes:
> Having a device with a status property != "okay" in the DT is a valid
> use case, and we should not prevent the registration of the DRM device
> when the DSI device connected to the DSI controller is disabled.
>
> Consider the ENODEV return code as a valid result and do
On Tue, May 15, 2018 at 01:09:59PM +0200, Peter Rosin wrote:
> On 2018-05-15 12:22, Daniel Vetter wrote:
> > On Mon, May 14, 2018 at 10:40 PM, Peter Rosin wrote:
> >> On 2018-05-14 18:28, Daniel Vetter wrote:
> >>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
> On 2018-05-10 1
Hi Laurent,
Thanks for the fix.
On 15/05/18 18:47, Laurent Pinchart wrote:
> Commit 75a07f399cd4 ("drm: rcar-du: Zero-out sg_tables when duplicating
> plane state") introduced a reference to the alpha field of struct
> rcar_du_vsp_plane_state that got removed in commit 301a9b8d5456
> ("drm/rcar-d
On Tue, May 15, 2018 at 01:16:30PM +0100, Chris Wilson wrote:
> Quoting Ezequiel Garcia (2018-05-14 22:28:31)
> > On Mon, 2018-05-14 at 18:48 +0200, Daniel Vetter wrote:
> > > On Fri, May 11, 2018 at 08:27:41AM +0100, Chris Wilson wrote:
> > > > Quoting Ezequiel Garcia (2018-05-09 21:14:49)
> > > >
On Tue, May 15, 2018 at 10:37:36PM +0200, Philippe Cornu wrote:
> Minor fixes detected with "scripts/checkpatch.pl --strict"
>
> Signed-off-by: Philippe Cornu
> ---
> Detected when merging "drm: clarify adjusted_mode documentation for bridges"
Acked-by: Daniel Vetter
>
> include/drm/drm_bridg
On Wed, May 16, 2018 at 12:07:12AM -0300, Rodrigo Siqueira wrote:
> This commit adds a single and simple virtual encoder to VKMS.
>
> Signed-off-by: Rodrigo Siqueira
Doesn't this break bisection, i.e. between patch 1&2 vkms looks broken
(because the encoder is missing)?
If so probably better to
On Wed, May 16, 2018 at 12:06:54AM -0300, Rodrigo Siqueira wrote:
> This commit adds the essential infrastructure for managing CRTCs which
> is composed of: a new data struct for output data information, a
> function for basic modeset initialization, and the operation to create
> planes. Due to the
On Wed, May 16, 2018 at 07:43:44AM +0200, Christoph Hellwig wrote:
> And streamline the code in vgem_fault with early returns so that it is
> a little bit more readable.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 51 +++--
> 1 file
On Wed, 2018-05-16 at 12:15 +0200, Peter Rosin wrote:
> The .of_node member is going away.
>
> Signed-off-by: Peter Rosin
Acked-by: Philipp Zabel
regards
Philipp
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/
Am Mittwoch, den 16.05.2018, 11:42 +0200 schrieb Daniel Vetter:
> On Tue, May 15, 2018 at 01:16:30PM +0100, Chris Wilson wrote:
> > Quoting Ezequiel Garcia (2018-05-14 22:28:31)
> > > On Mon, 2018-05-14 at 18:48 +0200, Daniel Vetter wrote:
> > > > On Fri, May 11, 2018 at 08:27:41AM +0100, Chris Wil
On Tue, May 15, 2018 at 6:04 PM, Ayan Kumar Halder wrote:
> malidp_pm_suspend_late checks if the runtime status is not suspended
> and if so, invokes malidp_runtime_pm_suspend which disables the
> display engine/core interrupts and the clocks. It sets the runtime status
> as suspended.
>
> The dif
Can you please elaborate more, maybe give an example - I don't
understand yet the problematic scenario.
Andrey
On 05/16/2018 02:50 AM, Christian König wrote:
No, that spinlock is indeed incorrect. I
See even when we protect the spsc queue with a spinlock that doesn't
make it correct. It can
drm_sched_fence_create() assigns a sequence number to the fence it creates.
Now drm_sched_fence_create() is called by drm_sched_job_init() to
initialize the jobs we want to push on the scheduler queue.
When you now call drm_sched_entity_push_job() without a protecting lock
it can happen that
So are you saying that you expect this to be already in code for any
usage of drm_sched_fence_create and drm_sched_entity_push_job ?
lock()
drm_sched_fence_create()
... (some code)
drm_sched_entity_push_job()
unlock()
Andrey
On 05/16/2018 07:23 AM, Christian König wrote:
drm_sched_fence_
Yes, exactly.
For normal user space command submission we should have tons of locks
guaranteeing that (e.g. just the VM lock should do).
For kernel moves we have the mutex for the GTT windows which protects it.
The could be problems with the UVD/VCE queues to cleanup the handles
when an appl
tree: git://people.freedesktop.org/~gabbayo/linux private
head: da8a916b6b6da1142232a310ac78571701655dba
commit: da8a916b6b6da1142232a310ac78571701655dba [43/43] drm/amdgpu:
conditionally compile amdgpu's amdkfd files
reproduce:
# apt-get install sparse
git checkout da8a916b6b6
Fixes: da8a916b6b6d ("drm/amdgpu: conditionally compile amdgpu's amdkfd files")
Signed-off-by: Fengguang Wu
---
amdgpu_amdkfd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 93
Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König:
> Yes, exactly.
>
> For normal user space command submission we should have tons of
> locks
> guaranteeing that (e.g. just the VM lock should do).
>
> For kernel moves we have the mutex for the GTT windows which protects
> it.
>
https://bugs.freedesktop.org/show_bug.cgi?id=105990
Chris Wilson changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
Am 16.05.2018 um 14:28 schrieb Lucas Stach:
Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König:
Yes, exactly.
For normal user space command submission we should have tons of
locks
guaranteeing that (e.g. just the VM lock should do).
For kernel moves we have the mutex for the GTT
On Wed, May 16, 2018 at 11:53:03AM +0200, Daniel Vetter wrote:
> Reviewed-by: Daniel Vetter
>
> Want me to merge this through drm-misc or plan to pick it up yourself?
For now I just want a honest discussion if people really actually
want the vm_fault_t change with the whole picture in place.
___
On Wed, May 16, 2018 at 04:23:47AM -0700, Matthew Wilcox wrote:
> On Wed, May 16, 2018 at 07:43:34AM +0200, Christoph Hellwig wrote:
> > this series tries to actually turn vm_fault_t into a type that can be
> > typechecked and checks the fallout instead of sprinkling random
> > annotations without
On Wed, May 16, 2018 at 04:28:13AM -0700, Matthew Wilcox wrote:
> On Wed, May 16, 2018 at 07:43:48AM +0200, Christoph Hellwig wrote:
> > Switch vm_fault_t to point to an unsigned int with __bіtwise annotations.
> > This both catches any old ->fault or ->page_mkwrite instance with plain
> > compiler
Am Mittwoch, den 16.05.2018, 14:32 +0200 schrieb Christian König:
> Am 16.05.2018 um 14:28 schrieb Lucas Stach:
> > Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König:
> > > Yes, exactly.
> > >
> > > For normal user space command submission we should have tons of
> > > locks
> > > gu
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/scheduler/sched_fence.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_fence.c
b/drivers/gpu/drm/scheduler/sched_fence.c
index 69aab086b913..786b47f15783 100644
--- a/drivers/gpu/drm/sche
We need a commit message here, something like: "That got missed while
moving the files outside of amdgpu.".
Am 16.05.2018 um 15:03 schrieb Nayan Deshmukh:
Signed-off-by: Nayan Deshmukh
Apart from the commit message the patch is Reviewed-by: Christian König
.
Christian.
---
drivers/gpu
Am 16.05.2018 um 15:00 schrieb Lucas Stach:
Am Mittwoch, den 16.05.2018, 14:32 +0200 schrieb Christian König:
Am 16.05.2018 um 14:28 schrieb Lucas Stach:
Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König:
Yes, exactly.
For normal user space command submission we should have ton
Thanks Alexander for the review. Sorry for the delay in addressing the
review comments
On Wednesday 04 April 2018 11:42 AM, Usyskin, Alexander wrote:
-Original Message-
From: C, Ramalingam
Sent: Tuesday, April 03, 2018 16:57
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesk
Am Mittwoch, den 16.05.2018, 15:10 +0200 schrieb Christian König:
> Am 16.05.2018 um 15:00 schrieb Lucas Stach:
> > Am Mittwoch, den 16.05.2018, 14:32 +0200 schrieb Christian König:
> > > Am 16.05.2018 um 14:28 schrieb Lucas Stach:
> > > > Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian
That got missed while moving the files outside of amdgpu.
Signed-off-by: Nayan Deshmukh
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_fence.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_fence.c
b/drivers/gpu/drm/s
There is a comment here which says that DIV_ROUND_UP() and that's where
the problem comes from. Say you pick:
args->bpp = UINT_MAX - 7;
args->width = 4;
args->height = 1;
The integer overflow in DIV_ROUND_UP() means "cpp" is UINT_MAX / 8 and
because of how we picked args-
On Wed, May 16, 2018 at 09:40:17AM +0200, Neil Armstrong wrote:
> On 16/05/2018 09:31, Neil Armstrong wrote:
> > Hi Ville,
> >
> > On 15/05/2018 17:35, Ville Syrjälä wrote:
> >> On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
> >>> This patchs adds the cec_notifier feature to the i
On Wed, 09 May 2018, Jani Nikula wrote:
> On Wed, 09 May 2018, Colin King wrote:
>> From: Colin Ian King
>>
>> Trivial fix to spelling mistakes in WARN warning message text and
>> in comments:
>>
>> "seqeuncer", "seqeuencer" -> "sequencer"
>>
>> Signed-off-by: Colin Ian King
>
> Reviewed-by: Ja
On 05/16/2018 09:16 AM, Lucas Stach wrote:
Am Mittwoch, den 16.05.2018, 15:10 +0200 schrieb Christian König:
Am 16.05.2018 um 15:00 schrieb Lucas Stach:
Am Mittwoch, den 16.05.2018, 14:32 +0200 schrieb Christian König:
Am 16.05.2018 um 14:28 schrieb Lucas Stach:
Am Mittwoch, den 16.05.2018,
Quoting Dan Carpenter (2018-05-16 15:00:26)
> There is a comment here which says that DIV_ROUND_UP() and that's where
> the problem comes from. Say you pick:
>
> args->bpp = UINT_MAX - 7;
> args->width = 4;
> args->height = 1;
>
> The integer overflow in DIV_ROUND_UP() me
Hi Daniel,
Thanks for the feedback :)
You can find my comments below:
On 05/16, Daniel Vetter wrote:
> On Wed, May 16, 2018 at 12:06:54AM -0300, Rodrigo Siqueira wrote:
> > This commit adds the essential infrastructure for managing CRTCs which
> > is composed of: a new data struct for output dat
On Wed, May 16, 2018 at 03:26:07PM +0100, Chris Wilson wrote:
> Quoting Dan Carpenter (2018-05-16 15:00:26)
> > There is a comment here which says that DIV_ROUND_UP() and that's where
> > the problem comes from. Say you pick:
> >
> > args->bpp = UINT_MAX - 7;
> > args->width = 4;
Quoting Dan Carpenter (2018-05-16 15:52:57)
> On Wed, May 16, 2018 at 03:26:07PM +0100, Chris Wilson wrote:
> > Quoting Dan Carpenter (2018-05-16 15:00:26)
> > > There is a comment here which says that DIV_ROUND_UP() and that's where
> > > the problem comes from. Say you pick:
> > >
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=105284
--- Comment #13 from burak ---
(In reply to Harry Wentland from comment #12)
> Hi burak,
>
> your stack is different. See dce110_opp_program_regamma_pwl vs
> dce110_stream_encoder_update_hdmi_info_packets on the stack.
>
> Can you open a new t
On Tuesday 03 April 2018 09:00 PM, Daniel Vetter wrote:
On Tue, Apr 03, 2018 at 07:27:18PM +0530, Ramalingam C wrote:
Notifier Chain is defined to inform all its clients about the mei
client device state change. Routine is defined for the clients to
register and unregister for the notification
https://bugs.freedesktop.org/show_bug.cgi?id=106544
Bug ID: 106544
Summary: Boot error:
gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132
generic_reg_update_ex+0x108/0x150 [amdgpu]
dce110_stream_encoder_update_hdmi
https://bugs.freedesktop.org/show_bug.cgi?id=106544
--- Comment #1 from burak ---
Created attachment 139595
--> https://bugs.freedesktop.org/attachment.cgi?id=139595&action=edit
xorg.log
--
You are receiving this mail because:
You are the assignee for the bug._
On Wednesday 09 May 2018 03:38 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chro
On Wed, May 16, 2018 at 03:56:55PM +0100, Chris Wilson wrote:
> Quoting Dan Carpenter (2018-05-16 15:52:57)
> > On Wed, May 16, 2018 at 03:26:07PM +0100, Chris Wilson wrote:
> > > Quoting Dan Carpenter (2018-05-16 15:00:26)
> > > > There is a comment here which says that DIV_ROUND_UP() and that's w
Quoting Dan Carpenter (2018-05-16 16:15:54)
> On Wed, May 16, 2018 at 03:56:55PM +0100, Chris Wilson wrote:
> > Quoting Dan Carpenter (2018-05-16 15:52:57)
> > > On Wed, May 16, 2018 at 03:26:07PM +0100, Chris Wilson wrote:
> > > > Quoting Dan Carpenter (2018-05-16 15:00:26)
> > > > > There is a co
On Wednesday 04 April 2018 12:15 PM, Usyskin, Alexander wrote:
-Original Message-
From: C, Ramalingam
Sent: Tuesday, April 03, 2018 16:57
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...
This spinlock is superfluous, any call to drm_sched_entity_push_job
should already be under a lock together with matching drm_sched_job_init
to match the order of insertion into queue with job's fence seqence
number.
v2:
Improve patch description.
Add functions documentation describing the locking
On Wednesday 09 May 2018 03:43 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chro
On Wed, May 16, 2018 at 4:51 PM, Rodrigo Siqueira
wrote:
> Hi Daniel,
>
> Thanks for the feedback :)
>
> You can find my comments below:
>
> On 05/16, Daniel Vetter wrote:
>> On Wed, May 16, 2018 at 12:06:54AM -0300, Rodrigo Siqueira wrote:
>> > This commit adds the essential infrastructure for ma
On Wed, May 16, 2018 at 5:40 PM, Daniel Vetter wrote:
> On Wed, May 16, 2018 at 4:51 PM, Rodrigo Siqueira
> wrote:
>> Hi Daniel,
>>
>> Thanks for the feedback :)
>>
>> You can find my comments below:
>>
>> On 05/16, Daniel Vetter wrote:
>>> On Wed, May 16, 2018 at 12:06:54AM -0300, Rodrigo Siquei
Btw, I've looked at this some more and I'm 99% sure there is no way to
exploit it. The "if (PAGE_ALIGN(size) == 0)" prevents the integer
overflow in __vgem_gem_create() that I was worried about.
regards,
dan carpenter
___
dri-devel mailing list
dri-de
Now I got it! I will split the patch and apply your suggestions :)
Thanks
On 05/16, Daniel Vetter wrote:
> On Wed, May 16, 2018 at 5:40 PM, Daniel Vetter wrote:
> > On Wed, May 16, 2018 at 4:51 PM, Rodrigo Siqueira
> > wrote:
> >> Hi Daniel,
> >>
> >> Thanks for the feedback :)
> >>
> >> You can
On Wednesday 09 May 2018 03:46 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chro
On Wed, May 16, 2018 at 05:00:26PM +0300, Dan Carpenter wrote:
> There is a comment here which says that DIV_ROUND_UP() and that's where
> the problem comes from. Say you pick:
>
> args->bpp = UINT_MAX - 7;
> args->width = 4;
> args->height = 1;
>
> The integer overflow in DIV_
https://bugs.freedesktop.org/show_bug.cgi?id=106519
--- Comment #11 from mikhail.v.gavri...@gmail.com ---
(In reply to Christian König from comment #10)
> Please provide the output of vainfo.
$ vainfo
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to
On Wednesday 09 May 2018 03:58 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chro
On Wednesday 09 May 2018 04:01 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chro
On Wednesday 09 May 2018 04:06 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chro
On Wednesday 09 May 2018 04:29 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chro
On Wednesday 09 May 2018 07:20 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chro
On Wednesday 09 May 2018 04:34 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chro
On Wednesday 09 May 2018 07:25 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chro
On Wednesday 09 May 2018 07:32 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chro
tree: git://people.freedesktop.org/~gabbayo/linux private
head: 9508d7f3767467f58c0df9680de93fb2fca66bc3
commit: 9508d7f3767467f58c0df9680de93fb2fca66bc3 [2/2] drm/amdgpu:
conditionally compile amdgpu's amdkfd files
config: x86_64-fedora-25 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1
On 05/16/2018 04:06 PM, Ulrich Hecht wrote:
Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.
Signed-off-by: Ulrich Hecht
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/d
>
> On Fri, Apr 06, 2018 at 10:35:00PM +0300, Ville Syrjälä wrote:
> > On Fri, Apr 06, 2018 at 07:14:51PM +, Deepak Singh Rawat wrote:
> > > This makes sense once we got rid of plane->fb
> > >
> > > Will this go to drm-next?
> >
> > The plan is to push to drm-misc-next once we get all
> > the
On Wed, May 16, 2018 at 06:22:56AM -0700, Matthew Wilcox wrote:
> Perhaps you should try being less of an arsehole if you don't want to
> get yelled at? I don't mind when you're an arsehole towards me, but I
> do mind when you're an arsehole towards newcomers. How are we supposed
> to attract and
On Wed, May 16, 2018 at 08:08:29AM -0700, Darrick J. Wong wrote:
> Uh, we're changing function signatures /and/ redefinining vm_fault_t?
> All in the same 90K patch?
>
> I /was/ expecting a series of "convert X and all callers/users"
> patches followed by a trivial one to switch the definition
Am Di., 8. Mai 2018 um 16:30 Uhr schrieb Lucas Stach :
> This replaces the repetitive GPL-2.0 license text in code and header files
> with the SPDX tags. Generated hardware headers aren't changed, as any
changes
> there need to be done in the upstream rnndb repository.
> Signed-off-by: Lucas Sta
On 2018-05-14 10:05 PM, Manasi Navare wrote:
> This patch defines a new header file for all the DSC 1.2 structures
> and creates a structure for PPS infoframe which will be used to send
> picture parameter set secondary data packet for display stream compression.
> All the PPS infoframe syntax elem
On 2018-05-14 10:05 PM, Manasi Navare wrote:
> From: Gaurav K Singh
>
> This defines all the DSC parameters as per the VESA DSC spec
> that will be required for DSC encoder/decoder
>
> v2: Define this struct in DRM (From Manasi)
> * Changed the data types to u8/u16 instead of unsigned longs (Man
Hi Ville,
On 16/05/2018 16:07, Ville Syrjälä wrote:
> On Wed, May 16, 2018 at 09:40:17AM +0200, Neil Armstrong wrote:
>> On 16/05/2018 09:31, Neil Armstrong wrote:
>>> Hi Ville,
>>>
>>> On 15/05/2018 17:35, Ville Syrjälä wrote:
On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
>
Hi Dave,
A few more fixes this week, one going to stable.
drm-misc-fixes-2018-05-16:
- core: Fix regression in dev node offsets (Haneen)
- vc4: Fix memory leak on driver close (Eric)
- dumb-buffers: Prevent overflow in DIV_ROUND_UP() (Dan)
Cc: Haneen Mohammed
Cc: Eric Anholt
Cc: Dan Carpenter
https://bugs.freedesktop.org/show_bug.cgi?id=106547
Bug ID: 106547
Summary: *ERROR* ring sdma0 timeout while watching video, Raven
Ridge
Product: DRI
Version: unspecified
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=106547
--- Comment #1 from ojab ---
Created attachment 139600
--> https://bugs.freedesktop.org/attachment.cgi?id=139600&action=edit
dmesg
dmesg can be found in the attached file, I've cut unrelated (lots of BTRFS
info/hardpss/etc) stuff.
Kernel is t
https://bugs.freedesktop.org/show_bug.cgi?id=106547
--- Comment #2 from ojab ---
Created attachment 139601
--> https://bugs.freedesktop.org/attachment.cgi?id=139601&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
Hi, Dave,
A single fix for a recent regression.
The following changes since commit 13f149d47392782baafd96d54d4e65f3b5ca342f:
drm/vmwgfx: Fix a buffer object leak (2018-04-26 09:59:30 +0200)
are available in the Git repository at:
git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-4.17
On Wed, May 16, 2018 at 02:14:56PM -0400, Harry Wentland wrote:
> On 2018-05-14 10:05 PM, Manasi Navare wrote:
> > This patch defines a new header file for all the DSC 1.2 structures
> > and creates a structure for PPS infoframe which will be used to send
> > picture parameter set secondary data pa
https://bugs.freedesktop.org/show_bug.cgi?id=106194
Leo Li changed:
What|Removed |Added
Attachment #139205|0 |1
is obsolete|
On 2018-05-14 10:05 PM, Manasi Navare wrote:
> VESA Display Stream Compression is a specification for visually losless
> video compression over display links. The DSC standard also defines
> a picture parameter set (PPS) which encoder must communicate to decoders.
> This is done by encapsulating PP
On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on fir
+ Kishon
Hi,
On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of
This series of patches add a centralized initialization mechanism, a
single CRTC with a plane, an encoder, and extra module information.
Changes in v2:
- Remove unused definitions
- Improve file names
- Improve code separation
- Remove unnecessary formats
Rodrigo Siqueira (3):
drm/vkms: Ad
Initialize minimum and maximum width and height of the frame buffers
with default values.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_drv.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
i
Add the following additional information: authors and description in
Kconfig.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/Kconfig | 8 ++--
drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers
This commit adds the essential infrastructure for around CRTCs which
is composed of: a new data struct for output data information, a
function for creating planes, and a simple encoder attached to the
connector. Finally, due to the introduction of a new initialization
function, connectors were move
https://bugzilla.kernel.org/show_bug.cgi?id=199567
--- Comment #3 from Ant (untaintablean...@hotmail.co.uk) ---
Sorry for the delay. OK, so lots of news:
I did see a patch in amd-staging-drm-next
354ee4815f52219fcd97d91269917261aac0518a ("drm/amd/display: Fix bug that causes
black screen") that
1 - 100 of 112 matches
Mail list logo
