Hi, Dirk,
On 05/04/2018 12:15 AM, Dirk Hohndel (VMware) wrote:
This is licensed under GPL-2.0.
Signed-off-by: Dirk Hohndel (VMware)
---
drivers/gpu/drm/vmwgfx/Kconfig| 1 +
.../vmwgfx/device_include/vmware_pack_begin.h | 25 +--
.../vmwgfx/device_include/vm
On Friday 27 April 2018 03:11 AM, Laurent Pinchart wrote:
Hi Peter,
Thank you for the patch.
On Friday, 27 April 2018 00:36:44 EEST Peter Rosin wrote:
Could perhaps prevent some confusion.
queued to drm-misc-next
Thanks,
Archit
Signed-off-by: Peter Rosin
Reviewed-by: Laurent Pinchar
On Friday 27 April 2018 03:46 AM, Laurent Pinchart wrote:
Hi Jia-Ju,
Thank you for the patch.
On Wednesday, 11 April 2018 11:33:42 EEST Jia-Ju Bai wrote:
adv7511_probe() is never called in atomic context.
This function is only set as ".probe" in struct i2c_driver.
Despite never getting call
https://bugs.freedesktop.org/show_bug.cgi?id=106259
--- Comment #2 from James Harvey ---
Hi Christian, thanks for taking the time to look at this.
I'm seeing this issue on the mainline linux-4.17 release candidates. I skipped
testing rc1, ran the bisect after seeing this on rc2, then tested
htt
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #189 from tkdestroyer2+bugs-freedesk...@gmail.com ---
I tried what chris suggested, and it worked up until the point at which some X
session closes (right after login or after exiting basic xterm test session),
where the system locks u
On 4 May 2018 at 10:29, Dave Airlie wrote:
> On 4 May 2018 at 10:19, Dave Airlie wrote:
>> On 2 May 2018 at 17:03, Jani Nikula wrote:
>>>
>>> Hi Dave -
>>>
>>> drm-intel-next-2018-04-13:
>>> First drm/i915 feature batch heading for v4.18:
>>>
>>> - drm-next backmerge to fix build (Rodrigo)
>>> -
On 4 May 2018 at 10:19, Dave Airlie wrote:
> On 2 May 2018 at 17:03, Jani Nikula wrote:
>>
>> Hi Dave -
>>
>> drm-intel-next-2018-04-13:
>> First drm/i915 feature batch heading for v4.18:
>>
>> - drm-next backmerge to fix build (Rodrigo)
>> - GPU documentation improvements (Kevin)
>> - GuC and Hu
On 2 May 2018 at 17:03, Jani Nikula wrote:
>
> Hi Dave -
>
> drm-intel-next-2018-04-13:
> First drm/i915 feature batch heading for v4.18:
>
> - drm-next backmerge to fix build (Rodrigo)
> - GPU documentation improvements (Kevin)
> - GuC and HuC refactoring, host/GuC communication, logging, fixes,
On 3 May 2018 at 23:45, Daniel Vetter wrote:
> On Thu, May 3, 2018 at 2:06 PM, Laurent Pinchart
> wrote:
>> Hi Dave,
>>
>> Ping ?
>
> Not aware of any crc core work going on in drm, so has my ack. Worst
> case we do a topic branch or something like that (since I guess you'll
> do a pull request a
https://bugs.freedesktop.org/show_bug.cgi?id=106177
--- Comment #3 from gr...@sub.red ---
At least I had the same behaviour, value not "sticky" and no impact on actual
clock.
I noticed it when I tested 4.17-rc2, actually wanted to test the "wattman"
functionality. Then noticed, it doesn't work on
https://bugs.freedesktop.org/show_bug.cgi?id=106177
--- Comment #2 from Christoph Haag ---
I just tried 4.16.7 and overclocking still works on the 4.16 version.
And I think on 4.17rc3 it still doesn't work.
Do you mean on 4.16.6 overclocking does not work for you? Then it's probably
not the same
https://bugs.freedesktop.org/show_bug.cgi?id=91880
chrisg_...@hotmail.com changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|RE
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #25 from Francisco Pina Martins ---
I have submitted the bug to kernel bugzilla as you have suggested:
https://bugzilla.kernel.org/show_bug.cgi?id=199613
Is there anything else I can do here to help track the eventual problem with
A
https://bugs.freedesktop.org/show_bug.cgi?id=98324
--- Comment #11 from Darren Salt ---
Created attachment 139326
--> https://bugs.freedesktop.org/attachment.cgi?id=139326&action=edit
Bad EDID output (4.17-rc3 + DC)
Once this happens (after VESA blanking long enough for the problem monitor to
https://bugs.freedesktop.org/show_bug.cgi?id=98324
--- Comment #10 from Darren Salt ---
Created attachment 139325
--> https://bugs.freedesktop.org/attachment.cgi?id=139325&action=edit
Good EDID output (4.17-rc3 + DC)
--
You are receiving this mail because:
You are the assignee for the bug.___
On Thu, May 03, 2018 at 11:16:55AM -0400, Sean Paul wrote:
> On Thu, May 03, 2018 at 11:31:07AM +0200, Daniel Vetter wrote:
> > It's going away.
> >
> > v2: Try harder to find them all.
> >
> > Signed-off-by: Daniel Vetter
>
> Still
> Reviewed-by: Sean Paul
Ok, this compiled better, both rema
On Thu, May 03, 2018 at 03:12:55PM -0400, Sean Paul wrote:
> On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
> > On Thu, May 3, 2018 at 5:04 PM, Sean Paul wrote:
> > > Hey all,
> > > Apologies for the direct ping. I've harvested your emails from drm_hwc
> > > git logs,
> > > and di
On Thu, May 03, 2018 at 09:41:19PM +0300, Andy Shevchenko wrote:
> The new helper returns index of the matching string in an array.
> We are going to use it here.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 7 +++
> 1
On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
> On Thu, May 3, 2018 at 5:04 PM, Sean Paul wrote:
> > Hey all,
> > Apologies for the direct ping. I've harvested your emails from drm_hwc git
> > logs,
> > and didn't want to leave anyone out. The good news is that your email
> > ad
On Thu, May 3, 2018 at 5:04 PM, Sean Paul wrote:
> Hey all,
> Apologies for the direct ping. I've harvested your emails from drm_hwc git
> logs,
> and didn't want to leave anyone out. The good news is that your email address
> will forever be remembered in the annals of drm_hwcomposer!
>
> Anyway
https://bugs.freedesktop.org/show_bug.cgi?id=106177
gr...@sub.red changed:
What|Removed |Added
CC||gr...@sub.red
--- Comment #1 from gr...@
https://bugs.freedesktop.org/show_bug.cgi?id=106306
--- Comment #1 from gr...@sub.red ---
Overdrive doesn't work either with current stable kernel (4.16.6). Clock
remains stable (as seen in amdgpu_pm_info) and reading the value gives 0:
> echo 5 | sudo tee /sys/class/drm/card0/device/pp_sclk_od
5
https://bugs.freedesktop.org/show_bug.cgi?id=106306
gr...@sub.red changed:
What|Removed |Added
Summary|amdgpu CIK power management |amdgpu CIK power management
https://bugs.freedesktop.org/show_bug.cgi?id=106245
--- Comment #2 from ojab ---
Yep, works fine with `mem_encrypt=off amd_iommu=off`
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.f
https://bugs.freedesktop.org/show_bug.cgi?id=106259
Christian König changed:
What|Removed |Added
CC||ckoenig.leichtzumerken@gmai
On Thu, May 3, 2018 at 11:40 AM, Boris Brezillon
wrote:
> The device might be described in the device tree but not connected to
> the I2C bus. Update the status property so that the DRM panel logic
> returns -ENODEV when someone tries to get the panel attached to this
> DT node.
>
> Signed-off-by:
Quoting Leon Romanovsky (2018-05-03 16:36:55)
> From: Leon Romanovsky
>
> The macro u64_to_ptr() and function ptr_to_u64() are useful enough
> to be part of general header, so move them there and allow RDMA
> subsystem reuse them.
>
> Signed-off-by: Leon Romanovsky
Feel free to merge this thro
DT nodes might be present in the DT but with a status property set to
"disabled" or "fail". In this case, we should not return -EPROBE_DEFER
when the caller ask for a drm_panel instance. Return -ENODEV instead.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_panel.c | 9 +++--
1 file
The device might be described in the device tree but not connected to
the I2C bus. Update the status property so that the DRM panel logic
returns -ENODEV when someone tries to get the panel attached to this
DT node.
Signed-off-by: Boris Brezillon
---
.../gpu/drm/panel/panel-raspberrypi-touchscre
There's no point searching for a drm_bridge or drm_panel if the OF node
we're pointing has a status property that is not "okay" or "ok". Just
return -ENODEV in this case.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_of.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/
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 not expose the
DSI encoder/connecto
Right now, the DRM panel logic returns NULL when a panel pointing to
the passed OF node is not present in the list of registered panels.
Most drivers interpret this NULL value as -EPROBE_DEFER, but we are
about to modify the semantic of of_drm_find_panel() and let the
framework return -ENODEV when
Hello,
This is a new attempt at fixing the "panel is missing" issue (described
in this thread [1]). I lost track of Eric's proposal, but I recently
proposed to address this problem through a new ->detect() hook in the
panel_funcs interface [2], which was rejected.
So here is a new version based o
of_node_put(panel) is not called when of_drm_find_panel(panel) returns
NULL, thus leaking the reference we hold on panel.
Fixes: 9be7d864cf07 ("drm/tegra: Implement panel support")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/tegra/output.c | 3 +--
1 file changed, 1 insertion(+), 2 d
On Sat, Apr 28, 2018 at 08:21:59AM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if
On Thu, May 3, 2018 at 12:48 PM, Dirk Hohndel wrote:
> But if you do the same analysis for header files...
>
> hohndel@rrmbpvm:~/src/linux[VMware-license-cleanup]
> $ git grep SPDX | grep \.h: | cut -d: -f2 | sort | grep ^// | wc
> 5491098 14823
> hohndel@rrmbpvm:~/src/linux[VMware-lice
Quoting Daniel Vetter (2018-05-03 15:25:50)
> @@ -560,7 +567,7 @@ dma_fence_init(struct dma_fence *fence, const struct
> dma_fence_ops *ops,
>spinlock_t *lock, u64 context, unsigned seqno)
> {
> BUG_ON(!lock);
> - BUG_ON(!ops || !ops->wait || !ops->enable_signaling |
Quoting Colin King (2018-05-03 16:45:10)
> From: Colin Ian King
>
> Trivial fix to spelling mistake in pr_err error message
>
> Signed-off-by: Colin Ian King
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
From: Colin Ian King
Trivial fix to spelling mistake in pr_err error message
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c
b/drivers/gpu/drm/i915/selftes
On Thu, May 03, 2018 at 10:30:35AM -0500, Rob Herring wrote:
> On Thu, May 3, 2018 at 9:45 AM, Sean Paul wrote:
> > On Thu, May 03, 2018 at 09:39:31AM -0500, Rob Herring wrote:
> >> On Thu, May 3, 2018 at 9:32 AM, Sean Paul wrote:
> >> > On Thu, May 03, 2018 at 09:14:41AM -0500, Rob Herring wrote
On Thu, May 03, 2018 at 11:31:07AM +0200, Daniel Vetter wrote:
> It's going away.
>
> v2: Try harder to find them all.
>
> Signed-off-by: Daniel Vetter
Still
Reviewed-by: Sean Paul
> Cc: Rob Clark
> Cc: Jordan Crouse
> Cc: Nicolas Dechesne
> Cc: Archit Taneja
> Cc: Bjorn Andersson
> Cc:
Hey all,
Apologies for the direct ping. I've harvested your emails from drm_hwc git logs,
and didn't want to leave anyone out. The good news is that your email address
will forever be remembered in the annals of drm_hwcomposer!
Anyways, back to the point.
Now that we have our shiny freedesktop gi
On Thu, May 03, 2018 at 01:41:52PM +0300, Ville Syrjälä wrote:
> On Thu, May 03, 2018 at 08:35:30AM +0200, Daniel Vetter wrote:
> > On Wed, May 02, 2018 at 09:32:47PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Clear the old_state and new_state pointers for every object in
>
On Thu, May 03, 2018 at 09:39:31AM -0500, Rob Herring wrote:
> On Thu, May 3, 2018 at 9:32 AM, Sean Paul wrote:
> > On Thu, May 03, 2018 at 09:14:41AM -0500, Rob Herring wrote:
> >> On Thu, May 3, 2018 at 8:47 AM, Sean Paul wrote:
> >> > On Wed, May 02, 2018 at 04:56:29PM -0700, Alistair Strachan
On Thu, May 03, 2018 at 04:04:31PM +0200, Linus Walleij wrote:
> Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
> Added a second module using the builtin_platform_driver() call,
> which works fine as long as you do not try to build the PL111
> driver as a module, because a module
On Thu, May 03, 2018 at 09:14:41AM -0500, Rob Herring wrote:
> On Thu, May 3, 2018 at 8:47 AM, Sean Paul wrote:
> > On Wed, May 02, 2018 at 04:56:29PM -0700, Alistair Strachan wrote:
> >> Use of the sw_sync API is not allowed any more. Until drm_hwcomposer is
> >> weaned off of sw_sync, build our
On Thu, May 03, 2018 at 04:15:17PM +0200, Daniel Vetter wrote:
> Jani spotted this when reviewing my earlier patch to remove the driver
> internal usage of this field in
>
> commit 3cf91adaa594e8933af1727942ac560e5c7bc70e
> Author: Daniel Vetter
> Date: Wed Apr 25 19:42:52 2018 +0200
>
> b
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 7 ---
1 fil
- Intro section that links to how this is exposed to userspace.
- Lots more hyperlinks.
- Minor clarifications and style polish
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
Documentation/driver-api/dma-
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Colin Ian King
Cc: Daniel Vetter
Cc: Mika Kuoppala
Cc: intel-...@lists
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Also remove the ->signaled callback, vgem can't peek ahead with a
fastpath, returning false is the default implementation.
Signed-off-by: Daniel Vetter
Cc: Kees Cook
Cc: Cihangir Akturk
Cc: Sean Pa
dma_fence_default_wait is the default now.
Signed-off-by: Daniel Vetter
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fenc
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_fence.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_fence.c b
The trivial enable_signaling implementation matches the default code.
v2: Fix up commit message to match patch better (Eric).
Cc: Eric Anholt
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
drivers/gpu/drm/msm/msm_fence.c | 7 ---
1 file changed, 7 deletions(-)
diff
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Acked-by: Lucas Stach
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 ---
Noticed while I was typing docs. Entirely unused.
v2: Remove reference in @timeline_value_str too. While at it clarify
why timeline_value_str has a fence parameter - we don't have an
explicit timeline structure unfortunately.
Cc: Eric Anholt
Reviewed-by: Eric Anholt
Reviewed-by: Christian König
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
---
drivers/gpu/drm/drm_crtc.c | 7 ---
drivers/g
Hi all,
Resending the entire pile because I shrugged of some CI noise which wasn't
noise. Silly me :-/
Besides the BUG_ON that also Chris spotted just minor changes, which I did
send out individually already.
As always, feedback very much welcome.
Thanks, Daniel
Daniel Vetter (15):
dma-fence
When this was introduced in
commit a519435a96597d8cd96123246fea4ae5a6c90b02
Author: Christian König
Date: Tue Oct 20 16:34:16 2015 +0200
dma-buf/fence: add fence_wait_any_timeout function v2
there was a restriction added that this only works if the dma-fence
uses the dma_fence_default_wai
dma_fence_default_wait is the default now.
Reviewed-by: Christian König
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: Monk Liu
Cc: pding
Cc: Andrey Grodzovsky
Cc: Evan Quan
Cc: Daniel Vetter
Cc: Kees Cook
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 2
Almost everyone uses dma_fence_default_wait.
v2: Also remove the BUG_ON(!ops->wait) (Chris).
Reviewed-by: Christian König (v1)
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dm
Many drivers have a trivial implementation for ->enable_signaling.
Let's make it optional by assuming that signalling is already
available when the callback isn't present.
Reviewed-by: Christian König
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel
Jani spotted this when reviewing my earlier patch to remove the driver
internal usage of this field in
commit 3cf91adaa594e8933af1727942ac560e5c7bc70e
Author: Daniel Vetter
Date: Wed Apr 25 19:42:52 2018 +0200
backlight: Nuke BL_CORE_DRIVER1
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
On Thu, May 3, 2018 at 3:43 PM, Daniel Vetter wrote:
> On Thu, May 03, 2018 at 03:40:53PM +0200, Linus Walleij wrote:
>> Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
>> Added a second module using the builtin_platform_driver() call,
>> which works fine as long as you do not try
Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
Added a second module using the builtin_platform_driver() call,
which works fine as long as you do not try to build the PL111
driver as a module, because a module can only have one initcall
and cause the following build bug:
(...) mu
For the series,
Reviewed-by: Benoit Parrot
Tomi Valkeinen wrote on Wed [2018-May-02 12:11:55
+0300]:
> Hi,
>
> This series has some minor fixes found by a static analysis tool, and one for
> missing linefeeds. As far as I know, we have never hit any of those errors.
>
> Tomi
>
> Tomi Valk
Hi Thierry,
Thanks for your review, I'll fix the other things you pointed out.
On Thu, Apr 26, 2018 at 05:07:12PM +0200, Thierry Reding wrote:
> > +static int ili9881c_send_cmd_data(struct ili9881c *ctx, u8 cmd, u8 data)
> > +{
> > + u8 buf[2] = { cmd, data };
> > + int ret;
> > +
> > + ret
On Wed, May 02, 2018 at 04:56:29PM -0700, Alistair Strachan wrote:
> Use of the sw_sync API is not allowed any more. Until drm_hwcomposer is
> weaned off of sw_sync, build our own copy.
I don't think it is used any longer. AFAICT, with 2 seconds of grep, it's
referenced in drmcompositorworker.cpp,
On Thu, May 3, 2018 at 2:06 PM, Laurent Pinchart
wrote:
> Hi Dave,
>
> Ping ?
Not aware of any crc core work going on in drm, so has my ack. Worst
case we do a topic branch or something like that (since I guess you'll
do a pull request anyway on the v4l side). Acked-by: me.
-Daniel
>
> On Saturd
Hi Laurent,
On 03/05/18 12:13, Laurent Pinchart wrote:
> Hi Kieran,
>>> + } else {
>>> + vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_Y, mem.addr[0]);
>>> + vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADDR_C0, mem.addr[1]);
>>> + vsp1_rpf_write(rpf, dlb, VI6_RPF_SRCM_ADD
Am Freitag, den 27.04.2018, 08:17 +0200 schrieb Daniel Vetter:
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> > Signed-off-by: Daniel Vetter
> > Cc: Lucas Stach
> > Cc: Russell King
> > Cc: Christian Gmeiner
> Cc: etna...@lists.freedesk
On Thu, May 03, 2018 at 03:40:53PM +0200, Linus Walleij wrote:
> Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
> Added a second module using the builtin_platform_driver() call,
> which works fine as long as you do not try to build the PL111
> driver as a module, because a module
Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
Added a second module using the builtin_platform_driver() call,
which works fine as long as you do not try to build the PL111
driver as a module, because a module can only have one initcall
and cause the following build bug:
(...) mu
On Thu, May 03, 2018 at 01:22:16PM +0200, Maarten Lankhorst wrote:
> We want to add more DRM selftests, and there's not much point in
> having a Kconfig option for every single one of them, so make
> a generic one.
>
> Signed-off-by: Maarten Lankhorst
Seems like a reasonable idea.
Reviewed-by:
From: Leon Romanovsky
The macro u64_to_ptr() and function ptr_to_u64() are useful enough
to be part of general header, so move them there and allow RDMA
subsystem reuse them.
Signed-off-by: Leon Romanovsky
---
drivers/gpu/drm/i915/i915_utils.h | 12 ++--
include/linux/kernel.h
The VSP1 devices define their specific capabilities through features
marked in their device info structure. Various parts of the code read
this info structure to infer if the features are available.
Wrap this into a more readable vsp1_feature(vsp1, f) macro to ensure
that usage is consistent throu
Use the newly exposed VSP1 interface to enable interlaced frame support
through the VSP1 lif pipelines.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/r
Calculate the top and bottom fields for the interlaced frames and
utilise the extended display list command feature to implement the
auto-field operations. This allows the DU to update the VSP2 registers
dynamically based upon the currently processing field.
Signed-off-by: Kieran Bingham
---
v3:
VSPD and VSP-DL devices can provide extended display lists supporting
extended command display list objects.
These extended commands require their own dma memory areas for a header
and body specific to the command type.
Implement a command pool to allocate all necessary memory in a single
DMA all
Header mode display lists are now supported on all WPF outputs. To
support extended headers and auto-fld capabilities for interlaced mode
handling only header mode display lists can be used.
Disable the headerless display list configuration, and remove the dead
code.
Signed-off-by: Kieran Bingham
Extended display list headers allow pre and post command lists to be
executed by the VSP pipeline. This provides the base support for
features such as AUTO_FLD (for interlaced support) and AUTO_DISP (for
supporting continuous camera preview pipelines.
Signed-off-by: Kieran Bingham
---
v2:
- re
The vsp1 reference in the vsp1_dl_body structure is not used.
Remove it.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index ec6fc21fabe0.
The use of the packed attribute can cause a performance penalty for
all accesses to the struct members, as the compiler will assume that the
structure has the potential to have an unaligned base.
These structures are all correctly aligned and contain no holes, thus
the attribute is redundant and n
If there is an error allocating a display list within a DLM object
the existing display lists are not free'd, and neither is the DL body
pool.
Use the existing vsp1_dlm_destroy() function to clean up on error.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 4 +++-
1 f
The Gen3 R-Car DU devices make use of the VSP to handle frame processing.
In this series we implement support for handling interlaced pipelines by using
the auto-fld feature of the VSP hardware.
The implementation is preceded by some cleanup work and refactoring, through
patches 1 to 6. These are
On Thu, May 03, 2018 at 01:22:17PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/Kconfig | 1 +
> drivers/gpu/drm/selftests/Makefile| 2 +-
> .../gpu/drm/selftests/drm_helper_selftests.h | 9 +
> drivers/gpu/drm
The pixel format is 'unsupported'. Fix the small debug message which
incorrectly declares this.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/pla
Both vsp1_dl_list_commit() and __vsp1_dl_list_put() walk the display
list chain referencing the nodes as children, when in reality they are
siblings.
Update the terminology to 'dl_next' to be consistent with the
vsp1_video_pipeline_run() usage.
Signed-off-by: Kieran Bingham
---
drivers/media/pl
On Thu, May 03, 2018 at 01:22:15PM +0200, Maarten Lankhorst wrote:
> With the previous patch drm_atomic_helper_check_plane_state correctly
> calculates clipping and the xf86-video-intel ddx is fixed to fall back
> to GPU correctly when SetPlane fails, we can remove the hack where
> we try to pan/zo
On Thu, May 03, 2018 at 01:55:03PM +0300, Ville Syrjälä wrote:
> On Thu, May 03, 2018 at 11:24:59AM +0200, Daniel Vetter wrote:
> > On Thu, May 03, 2018 at 11:19:32AM +0530, Satendra Singh Thakur wrote:
> > > In the func drm_atomic_set_crtc_for_plane, with the current code,
> > > if crtc of the pla
On 2018-05-02 12:11, Tomi Valkeinen wrote:
> Hi,
>
> This series has some minor fixes found by a static analysis tool, and one for
> missing linefeeds. As far as I know, we have never hit any of those errors.
To all:
Reviewed-by: Peter Ujfalusi
>
> Tomi
>
> Tomi Valkeinen (4):
> drm/oma
On Thu, May 03, 2018 at 01:22:14PM +0200, Maarten Lankhorst wrote:
> Instead of relying on a scale which may increase rounding errors,
> clip src by doing: src * (dst - clip) / dst and rounding the result
> away from 1, so the new coordinates get closer to 1. We won't need
> to fix up with a magic
On Thu, May 03, 2018 at 01:22:13PM +0200, Maarten Lankhorst wrote:
> When calculating limits we want to be as pessimistic as possible,
> so we have to explicitly say whether we want to round up or down
> to accurately calculate whether we are below min_scale or above
> max_scale.
>
> Signed-off-by
Am 03.05.2018 um 15:03 schrieb Fabio Estevam:
On Wed, May 2, 2018 at 10:46 AM, Thomas Hellstrom wrote:
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 7c2485fe88d8..ea4d59eb8966 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/g
Hi,
On Wed, May 02, 2018 at 09:20:30AM +0200, Paul Kocialkowski wrote:
> Le vendredi 09 septembre 2016 à 16:35 +0200, Maxime Ripard a écrit :
> > On Wed, Sep 07, 2016 at 12:01:56AM +0800, Chen-Yu Tsai wrote:
> > > Hi,
> > >
> > > On Tue, Sep 6, 2016 at 10:46 PM, Maxime Ripard
> > > wrote:
> > >
On Wed, May 2, 2018 at 10:46 AM, Thomas Hellstrom wrote:
> diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
> b/drivers/gpu/drm/ttm/ttm_agp_backend.c
> index 7c2485fe88d8..ea4d59eb8966 100644
> --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
> +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
> @@ -1,3
On Wed, May 02, 2018 at 11:25:35PM +0200, Dirk Hohndel wrote:
> On Wed, May 02, 2018 at 04:33:30PM -0400, Sean Paul wrote:
> > > > diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
> > > > b/drivers/gpu/drm/ttm/ttm_agp_backend.c
> > > > index 7c2485fe88d8..ea4d59eb8966 100644
> > > > --- a/driver
On Thu, 2018-05-03 at 10:46 +, Lisovskiy, Stanislav wrote:
> On Thu, 2018-05-03 at 13:18 +0300, Jani Nikula wrote:
> > On Wed, 02 May 2018, StanLis wrote:
> > > From: Stanislav Lisovskiy
> > >
> > >
> > > diff --git a/Documentation/gpu/kms-properties.csv
> > > b/Documentation/gpu/kms-proper
On Thu, May 3, 2018 at 8:00 AM, Daniel Mack wrote:
> This regression stems from 0e08270a1f01 ("drm/msm: Separate locking of
> buffer resources from struct_mutex").
>
> Signed-off-by: Daniel Mack
> Cc: Sushmita Susheelendra
> Cc: Rob Clark
> Fixes: 0e08270a1f01 ("drm/msm: Separate locking of buf
1 - 100 of 168 matches
Mail list logo
