On 28/04/17 12:29 AM, Jochen Rollwagen wrote:
>
> 2. I’ve recently stumbled across a register definition for (older)
> radeon GPU’s, what caught my eye was
>
> *CB:RB3D_COLORPITCH[0-3] · [R/W] · 32 bits · Access: 8/16/32 ·
> MMReg:0x4e38-0x4e44 *
[...]
> COLORENDIAN
>
>
>
> 20:19
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #8 from Timothy Arceri ---
The radeonsi backend already does this where possible. The glsl compiler front
end is not currently thread safe, there have been a couple of attempts at this
over the years but I don't think anyone is worki
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #7 from Shmerl ---
(In reply to Timothy Arceri from comment #6)
> its well know that compile times are not
> as good as we would like in Mesa, but this is an ongoing process.
Is there a plan to make compilation more parallelized whe
https://bugs.freedesktop.org/show_bug.cgi?id=100426
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #5 from Shmerl ---
Sorry, wrong description in the second attachment. It should say: apitrace of
Trine 3 (filled mesa cache).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #4 from Shmerl ---
Created attachment 13
--> https://bugs.freedesktop.org/attachment.cgi?id=13&action=edit
apitrace of Trine 3 (empty mesa cache)
A trace with already filled mesa cache, Mesa 17.1.0-devel (git-af73acca2b).
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #3 from Shmerl ---
Just for the reference, this is GOG, not Steam version, I don't know if they
differ.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-de
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #2 from Shmerl ---
Created attachment 131110
--> https://bugs.freedesktop.org/attachment.cgi?id=131110&action=edit
apitrace of Trine 3 (empty mesa cache)
This is a trace with empty mesa cache, Mesa 17.1.0-devel (git-af73acca2b). I
https://bugs.freedesktop.org/show_bug.cgi?id=100426
Timothy Arceri changed:
What|Removed |Added
CC||t_arc...@yahoo.com.au
--- Comment #1 f
On Tue, 2017-04-25 at 09:51 +0200, Maarten Lankhorst wrote:
> On 21-04-17 07:51, Dhinakaran Pandiyan wrote:
> > From: "Pandiyan, Dhinakaran"
> >
> > Use the added helpers to track MST link bandwidth for atomic modesets.
> > Link bw is acquired in the ->atomic_check() phase when CRTCs are being
> >
On 27/04/17 12:53 AM, Christoph Hellwig wrote:
> I think you'll need to follow the existing kmap semantics and never
> fail the iomem version either. Otherwise you'll have a special case
> that's almost never used that has a different error path.
>
> Again, wrong way. Suddenly making things fai
On 27/04/17 02:53 PM, Jason Gunthorpe wrote:
> blkfront is one of the drivers I looked at, and it appears to only be
> memcpying with the bvec_data pointer, so I wonder why it does not use
> sg_copy_X_buffer instead..
Yes, sort of...
But you'd potentially end up calling sg_copy_to_buffer multip
On Thu, 2017-04-27 at 19:24 +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 02:28:32PM +0200, Bastien Nocera wrote:
> > On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote:
> > >
> >
> >
> >
> > > > I've a patch for iio-sensor-proxy which fixes the rotation
> > > > under
> > > > Xorg /
This is super simple elimination of else branch and I should
probably even use unlikely in
if (ring->count_dw < count_dw) {
However, amdgpu_ring_write() has similar if condition, but does not
return after DRM_ERROR and it looks suspicious. On error, we still
adding v to ring and keeping c
On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> On 27/04/17 02:53 PM, Jason Gunthorpe wrote:
> > blkfront is one of the drivers I looked at, and it appears to only be
> > memcpying with the bvec_data pointer, so I wonder why it does not use
> > sg_copy_X_buffer instead..
>
> But
On 26/04/17 09:56 PM, Herbert Xu wrote:
> On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
>> Very straightforward conversion to the new function in the caam driver
>> and shash library.
>>
>> Signed-off-by: Logan Gunthorpe
>> Cc: Herbert Xu
>> Cc: "David S. Miller"
>> ---
>>
Hello there,
Since I’m on a big-endian system I’ve been following the discusssion and
have two (maybe not quite related, and possibly dumb) questions:
1.There’s been a similar discussion on mesa-dev concerning big-endian
and #ifdef’s, see
https://lists.freedesktop.org/archives/mesa-dev/2016
On 27/04/17 09:27 AM, Jason Gunthorpe wrote:
> On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote:
> How about first switching as many call sites as possible to use
> sg_copy_X_buffer instead of kmap?
Yeah, I could look at doing that first.
One problem is we might get more Naks o
On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote:
> > The main difficulty we
> > have now is that neither of those functions are expected to fail and we
> > need them to be able to in cases where the page doesn't map to system
> > RAM. This patch series is trying to address it for
On Thu, Apr 27, 2017 at 02:19:24PM -0600, Logan Gunthorpe wrote:
>
>
> On 26/04/17 01:37 AM, Roger Pau Monné wrote:
> > On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote:
> >> Straightforward conversion to the new helper, except due to the lack
> >> of error path, we have to use SG_
On Wed, Apr 26, 2017 at 12:11:33PM -0600, Logan Gunthorpe wrote:
> Ok, well for starters I think you are mistaken about kmap being able to
> fail. I'm having a hard time finding many users of that function that
> bother to check for an error when calling it.
A quick audit of the arch code shows yo
On 26/04/17 01:37 AM, Roger Pau Monné wrote:
> On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote:
>> Straightforward conversion to the new helper, except due to the lack
>> of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in
>> certain cases in the future.
>>
>> S
On 26/04/17 01:44 AM, Christoph Hellwig wrote:
> I think we'll at least need a draft of those to make sense of these
> patches. Otherwise they just look very clumsy.
Ok, what follows is a draft patch attempting to show where I'm thinking
of going with this. Obviously it will not compile because
On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
> Very straightforward conversion to the new function in the caam driver
> and shash library.
>
> Signed-off-by: Logan Gunthorpe
> Cc: Herbert Xu
> Cc: "David S. Miller"
> ---
> crypto/shash.c| 9 ++---
> driv
On 27/04/17 05:20 PM, Jason Gunthorpe wrote:
> It seems the most robust: test for iomem, and jump to a slow path
> copy, otherwise inline the kmap and memcpy
>
> Every place doing memcpy from sgl will need that pattern to be
> correct.
Ok, sounds like a good place to start to me. I'll see what
On Mon, 2017-04-24 at 11:53 -0400, Harry Wentland wrote:
> Patches 1-3: Reviewed-by: Harry Wentland
> Patch 4: Acked-by: Harry Wentland
>
> Harry
>
Thanks for the review.
-DK
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://list
On 27/04/17 04:11 PM, Jason Gunthorpe wrote:
> On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> Well, that is in the current form, with more users it would make sense
> to optimize for the single page case, eg by providing the existing
> call, providing a faster single-page-only
On Thu, Apr 27, 2017 at 05:03:45PM -0600, Logan Gunthorpe wrote:
>
>
> On 27/04/17 04:11 PM, Jason Gunthorpe wrote:
> > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> > Well, that is in the current form, with more users it would make sense
> > to optimize for the single page c
Hi Andrzej,
Thanks for your answer!
On 27-04-2017 11:05, Andrzej Hajda wrote:
> Hi Jose,
>
> On 26.04.2017 12:48, Jose Abreu wrote:
>> Some crtc's may have restrictions in the mode they can display. In
>> this patch a new callback (crtc->mode_valid()) is introduced that
>> is called at the same
From: "Pandiyan, Dhinakaran"
It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and cle
Jeffy Chen writes:
> We need to set vop config done after update line flag config, it's a
> new requirement for chips newer than rk3368.
>
> Since we would only use line flag irq for vact_end, let's move it to
> vop_crtc_enable.
>
> Signed-off-by: Jeffy Chen
>
> ---
>
> drivers/gpu/drm/rockchip
2017-04-26 Christian König :
> Am 26.04.2017 um 16:46 schrieb Andres Rodriguez:
> > When a timeout of zero is specified, the caller is only interested in
> > the fence status.
> >
> > In the current implementation, dma_fence_default_wait will always call
> > schedule_timeout() at least once for a
https://bugs.freedesktop.org/show_bug.cgi?id=96897
--- Comment #10 from M. Edward (Ed) Borasky ---
Created attachment 131104
--> https://bugs.freedesktop.org/attachment.cgi?id=131104&action=edit
clinfo for the system
Note: this bug is in Fedora's bugzilla as well -
https://bugzilla.redhat.com/
https://bugs.freedesktop.org/show_bug.cgi?id=96897
M. Edward (Ed) Borasky changed:
What|Removed |Added
CC||zn...@znmeb.net
--- Comment #9
Hi Ville,
2017-04-27 Ville Syrjälä :
> On Thu, Apr 27, 2017 at 12:15:15PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Add support to async updates of cursors by using the new atomic
> > interface for that. Basically what this commit does is do what
> > intel_legacy_cursor_up
https://bugs.freedesktop.org/show_bug.cgi?id=100239
--- Comment #3 from Bruno Jacquet (Xaapyks) ---
Hello,
I have the same problem on my RX 480 and current mesa git.
I produced an apitrace but it is ~734MiB and trimming seems to be corrupting
it, I might be doing something wrong.
How should I sh
Hi Ville,
2017-04-27 Ville Syrjälä :
> On Thu, Apr 27, 2017 at 12:15:13PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > In some cases, like cursor updates, it is interesting to update the
> > plane in an asynchronous fashion to avoid big delays. The current queued
> > update c
2017-04-27 Ville Syrjälä :
> On Thu, Apr 27, 2017 at 12:15:12PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Hi,
> >
> > Second take of Asynchronous Plane Updates over Atomic. Here I looked
> > to msm, vc4 and i915 to identify a common pattern to create atomic helpers
> > for
https://bugs.freedesktop.org/show_bug.cgi?id=100784
--- Comment #2 from Jon ---
LIBGL_ALWAYS_SOFTWARE=1 doesn't have the same behaviour.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@list
Eric Anholt writes:
> Many DRM drivers have common code to make a stub connector
> implementation that wraps a drm_panel. By wrapping the panel in a DRM
> bridge, all of the connector code (including calls during encoder
> enable/disable) goes away.
>
> Signed-off-by: Eric Anholt
> +/**
> + *
Many DRM drivers have common code to make a stub connector
implementation that wraps a drm_panel. By wrapping the panel in a DRM
bridge, all of the connector code (including calls during encoder
enable/disable) goes away.
Signed-off-by: Eric Anholt
---
Documentation/gpu/drm-kms-helpers.rst |
The newer version of the RPi panel driver is going to be a combination
of a bridge and a panel, but we should also support panels without a
bridge, so the panel-bridge layer lets us do that cleanly.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/Kconfig | 2 +-
drivers/gpu/drm/vc4/vc4_ds
https://bugs.freedesktop.org/show_bug.cgi?id=100802
--- Comment #2 from Timo Aaltonen ---
happens on debian stretch too with mesa 13.0.6
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@list
On Wed, Apr 26, 2017 at 02:28:32PM +0200, Bastien Nocera wrote:
> On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote:
> >
>
>
> > > I've a patch for iio-sensor-proxy which fixes the rotation under
> > > Xorg /
> > > Wayland when using a desktop environment which honors iio-sensor-
> > > prox
From: Christian König
Instead of the global statistics use the per context bytes moved counter.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 7 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 +
2 files changed, 2 insertions(+), 10 deletions(-)
di
From: Christian König
Instead of specifying interruptible and no_wait_gpu manually.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8
drivers/gpu/drm/nouveau/nouveau_bo.c| 6 --
drivers/gpu/drm/radeon/radeon_ttm.c | 8
drivers/gpu/
From: Christian König
Instead of passing down the parameters manually to every function.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 69 +++-
1 file changed, 30 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo
From: Christian König
This way we can finally use some more stats.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/
From: Christian König
Add some statistics how many bytes we have moved.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
include/drm/ttm/ttm_bo_api.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0c
From: Christian König
Give moving a BO into place an operation context to work with.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 9 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 3 ++-
drivers/g
From: Christian König
Extern is the default for function declerations anyway and this
solves a bunch of 80char per line issues.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_api.h | 135 ++-
1 file changed, 56 insertions(+), 79 deletions(-)
From: Christian König
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 5 ++---
include/drm/ttm/ttm_bo_api.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 04cbecc..7033
From: Christian König
Instead of passing the parameters manually.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 21 +++--
drivers/gpu/drm/nouveau/nouveau_bo.c| 27 ---
drivers/gpu/drm/qxl/qxl_ttm.c | 9 --
From: Christian König
Extern is the default for function declerations anyway.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_driver.h | 113 +++-
1 file changed, 54 insertions(+), 59 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/inc
From: Christian König
Instead of specifying if sleeping should be interruptible.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
drivers/gpu/drm/ttm/ttm_bo.c | 12 +---
include/drm/ttm/ttm_bo_api.h | 5 ++---
3 files
On Thu, Apr 27, 2017 at 12:15:12PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> Second take of Asynchronous Plane Updates over Atomic. Here I looked
> to msm, vc4 and i915 to identify a common pattern to create atomic helpers
> for async updates. So in patch 1 drm_atomic_asy
On Thu, Apr 27, 2017 at 12:15:15PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Add support to async updates of cursors by using the new atomic
> interface for that. Basically what this commit does is do what
> intel_legacy_cursor_update() did but through atomic.
>
> v2: move fb set
On Thu, Apr 27, 2017 at 12:15:13PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> In some cases, like cursor updates, it is interesting to update the
> plane in an asynchronous fashion to avoid big delays. The current queued
> update could be still waiting for a fence to signal and thu
From: Gustavo Padovan
Add support to 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.
v2: move fb setting to core and use new state (Eric Anholt)
Cc: Eric Anholt
Signed-off-by: Gustavo Pad
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.
v2: move fb setting to core and use new state (Eric Anholt)
Cc: Rob Clark
Signed-off-by
From: Gustavo Padovan
In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we
From: Gustavo Padovan
Short circuit the update path for cursors and use the drm async update
infrastructure.
v2: move fb setting to core and use new state (Eric Anholt)
Signed-off-by: Gustavo Padovan
---
I wrote this mostly for testing purposes, not sure if its something that
we actually need
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.
Cc: Rob Clark
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
1 file changed, 3 inse
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 1 insertion(+), 12
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.
v2: move fb setting to core and use new state (Eric Anholt)
Cc: Daniel Vetter
Signed-off-by:
From: Gustavo Padovan
Hi,
Second take of Asynchronous Plane Updates over Atomic. Here I looked
to msm, vc4 and i915 to identify a common pattern to create atomic helpers
for async updates. So in patch 1 drm_atomic_async_check() and
drm_atomic_helper_async_commit() are introduced along with drive
From: Gustavo Padovan
Use "non-blocking" and "blocking" instead of old names.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.
Hi Tobias and Nicolas,
On 2017-04-26 17:16, Tobias Jakobi wrote:
Nicolas Dufresne wrote:
Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
Hi Marek,
On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
Hi Laurent,
On 2017-04-20 12:25, Laurent Pinchart wrote:
Hi M
Hi Sakari,
On 2017-04-26 00:21, Sakari Ailus wrote:
Hi Marek,
On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
Hi Laurent,
On 2017-04-20 12:25, Laurent Pinchart wrote:
Hi Marek,
(CC'ing Sakari Ailus)
Thank you for the patches.
On Thursday 20 Apr 2017 11:13:36 Marek Szypro
https://bugs.freedesktop.org/show_bug.cgi?id=100802
--- Comment #1 from Timo Aaltonen ---
still there in 17.1-rc2
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https
Hi Dave, here's an assortment of drm/i915 and gvt fixes for
drm-next/v4.12.
BR,
Jani.
The following changes since commit ab6eb211b07a42a6346e284056422fd9a8576a99:
Merge tag 'drm/panel/for-4.12-rc1' of
git://anongit.freedesktop.org/tegra/linux into drm-next (2017-04-13 06:17:40
+1000)
are a
https://bugs.freedesktop.org/show_bug.cgi?id=100800
--- Comment #4 from abitt...@opensuse.org ---
Created attachment 131095
--> https://bugs.freedesktop.org/attachment.cgi?id=131095&action=edit
Xorg log when displayport monitor attached
Xorg log when displayport monitor attached
--
You are re
On Thu, Apr 27, 2017 at 03:00:29PM +0800, Mark yao wrote:
> On 2017年04月27日 14:54, Jeffy Chen wrote:
> > We need to set vop config done after update line flag config, it's a
> > new requirement for chips newer than rk3368.
> >
> > Since we would only use line flag irq for vact_end, let's move it to
https://bugs.freedesktop.org/show_bug.cgi?id=100800
--- Comment #3 from abitt...@opensuse.org ---
Created attachment 131091
--> https://bugs.freedesktop.org/attachment.cgi?id=131091&action=edit
dmesg -e output of affected system when booting it with displayport monitor
attached
dmesg -e output
https://bugs.freedesktop.org/show_bug.cgi?id=100800
--- Comment #2 from abitt...@opensuse.org ---
with the kernel
I have following [drm
loglines:
[ +0.011717] [drm] radeon kernel modesetting enabled.
[ +0.000540] [drm] initializing kernel modesetting (SUMO 0x1002:0x964A
0x1043:0x84C8 0x00).
[
On 21/04/17 00:33, Laurent Pinchart wrote:
> The display engine only reads from memory, there's no need to use
> bidirectional DMA mappings. Use DMA_TO_DEVICE instead.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_gem.c| 11 +--
> drivers/gpu/drm/omapdr
On 21/04/17 00:33, Laurent Pinchart wrote:
> Both coherent (uncached) and non-coherent (cached) buffers can have
> their pages mapped to the device through the DMA mapping API. Make sure
> to unmap any mapped page when freeing a buffer, regardless of its type.
>
> Signed-off-by: Laurent Pinchart
On 15/04/17 12:16, Laurent Pinchart wrote:
> The DRM core atomic helper now supports asynchronous commits natively.
> The custom omapdrm implementation isn't needed anymore, remove it.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 112
> +--
At the moment we have ovl_set_channel_out() to configure the output
channel of an overlay. It makes sense to have this configuration as part
of the reset of overlay configuration, and in DSS6+ we need the output
channel when doing the other overlay configuration.
This patch adds 'channel' paramete
ovl_enabled() is not used anywhere, so remove it.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 6 --
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
2 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/disp
Hi,
Here are a few cleanups, 64bit fixes and connector type improvement for
omapdrm.
Tomi
Tomi Valkeinen (6):
drm/omap: add new connector types
drm/omap: remove unused ovl_enabled()
drm/omap: remove ovl_set_channel_out
drm/omap: remove read_irqenable()
drm/omap: 64bit compile fixes
Define compat_ioctl in omapdriver_fops to make it possible to use 32bit
apps on 64bit platform.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index
We only use read_irqenable() to flush posted write. Instead of having a
separate function for this, do the flush implicitly in write_irqenable().
Thus we can remove read_irqenable().
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 9 +++--
drivers/gpu/drm/omapdrm/ds
Fix a few type issues that cause compile warnings on 64 bit ARM
compiler. The change should not affect 32bit platforms.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 +-
drivers/gpu/drm/omapdrm/omap_fb.c| 2 +-
drivers/gpu/drm/omapdrm/omap_gem.c | 2
We have been using DRM_MODE_CONNECTOR_Unknown for many of our outputs
because there has not been a proper connector type for them.
We now have connector type for DPI so let's take it into use. At the
same time, add better connector types for the remaining outputs too.
This patch sets the followin
Hi Jose,
On 26.04.2017 12:48, Jose Abreu wrote:
> Some crtc's may have restrictions in the mode they can display. In
> this patch a new callback (crtc->mode_valid()) is introduced that
> is called at the same stage of connector->mode_valid() callback.
>
> This shall be implemented if the crtc has
Presumably we can never actually hit this return, but static checkers
complain that we should unlock before we return.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
index 3a24788c3185..a7e55c422501 1
If vmalloc() fails then we need to a bit of cleanup before returning.
Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index b6a0806b06bf..a1c68e6a689e
https://bugs.freedesktop.org/show_bug.cgi?id=96897
--- Comment #8 from ricardo.riba...@gmail.com ---
With:
Device: AMD CARRIZO (DRM 3.9.0 / 4.10.0-qtec-standard, LLVM 4.0.1)
Driver version : 17.0.3 (Linux x64)
Compute units : 8
Clock frequency : 800 MHz
I am getting the same er
On Wed, Apr 26, 2017 at 02:12:27PM -0700, Laura Abbott wrote:
> Hi,
>
> This is v2 of my proposal to add dma_buf import functions for vgem.
> Big changes from v1:
>
> - A device is required for dma_buf attach to work. The existing vgem driver
> intentionally does not use one as it provides a good
On Wed, Apr 26, 2017 at 02:12:30PM -0700, Laura Abbott wrote:
> Enable the GEM dma-buf import interfaces in addition to the export
> interfaces. This lets vgem be used as a test source for other allocators
> (e.g. Ion).
>
> Signed-off-by: Laura Abbott
> ---
> v2: Don't require vgem allocated buff
On Mon, Apr 24, 2017 at 06:26:51PM +0800, icen...@aosc.io wrote:
> 在 2017-04-24 16:51，Maxime Ripard 写道：
> > Hi,
> >
> > On Sun, Apr 23, 2017 at 06:37:45PM +0800, Icenowy Zheng wrote:
> > > +static const struct of_device_id sunxi_de2_clk_ids[] = {
> > > + {
> > > + .compatible = "allwinner,
On 2017.04.25 10:05:12 +0100, Colin King wrote:
> From: Colin Ian King
>
> trivial fix to typo in WARN_ONCE message
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/h
On 2017年04月27日 14:54, Jeffy Chen wrote:
We need to set vop config done after update line flag config, it's a
new requirement for chips newer than rk3368.
Since we would only use line flag irq for vact_end, let's move it to
vop_crtc_enable.
Signed-off-by: Jeffy Chen
looks good for me:
Acked-
On 27/04/17 03:45 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> That is done using the RADEON_TILING_SWAP_{16,32}BIT flag mentioned in
>>> another thread?
>>
>> Right.
>>
>>
>>> What about dumb bos? You've mentioned the swap flag isn't used for
>>> those. Which implies they are in little endian byte or
95 matches
Mail list logo
