On 21/03/17 18:41, Daniel Vetter wrote:
> The trouble here is that it does multiple atomic commits under one
> drm_modeset_lock_all, which breaks the behind-the-scenes acquire
> context magic that function pulls off. It's much better to have one
> overall atomic commit. That we still have multiple
On 27/03/17 09:40, Daniel Vetter wrote:
> On Mon, Mar 27, 2017 at 09:28:07AM +0300, Tomi Valkeinen wrote:
>> On 25/03/17 23:22, Daniel Vetter wrote:
>>> On Fri, Mar 24, 2017 at 11:40:47AM +0200, Tomi Valkeinen wrote:
From: Peter Ujfalusi
Add fbdev emulation only for the first DRM co
On Mon, Mar 27, 2017 at 10:15:12AM +0300, Tomi Valkeinen wrote:
> On 21/03/17 18:41, Daniel Vetter wrote:
> > The trouble here is that it does multiple atomic commits under one
> > drm_modeset_lock_all, which breaks the behind-the-scenes acquire
> > context magic that function pulls off. It's much
On Mon, Mar 27, 2017 at 10:25:46AM +0300, Tomi Valkeinen wrote:
> On 27/03/17 09:40, Daniel Vetter wrote:
> > On Mon, Mar 27, 2017 at 09:28:07AM +0300, Tomi Valkeinen wrote:
> >> On 25/03/17 23:22, Daniel Vetter wrote:
> >>> On Fri, Mar 24, 2017 at 11:40:47AM +0200, Tomi Valkeinen wrote:
> Fro
Exynos DRM on ARM architecture creates its own DMA-IOMMU mapping, shared
between all devices that builds the Exynos DRM subsystem. Thus, the
default DMA-IOMMU mapping structure created by platform init code can be
released to avoid leaking resources, because after exynos_iommu_attach()
the default
Op 27-03-17 om 08:38 schreef Daniel Vetter:
> On Wed, Mar 22, 2017 at 03:30:49PM -0700, Dhinakaran Pandiyan wrote:
>> 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
>> b
On Mon, Mar 27, 2017 at 10:28:42AM +0200, Maarten Lankhorst wrote:
> Op 27-03-17 om 08:38 schreef Daniel Vetter:
> > On Wed, Mar 22, 2017 at 03:30:49PM -0700, Dhinakaran Pandiyan wrote:
> >> From: "Pandiyan, Dhinakaran"
> >>
> >> It is necessary to track states for objects other than connector, cr
Op 27-03-17 om 10:31 schreef Daniel Vetter:
> On Mon, Mar 27, 2017 at 10:28:42AM +0200, Maarten Lankhorst wrote:
>> Op 27-03-17 om 08:38 schreef Daniel Vetter:
>>> On Wed, Mar 22, 2017 at 03:30:49PM -0700, Dhinakaran Pandiyan wrote:
From: "Pandiyan, Dhinakaran"
It is necessary to tr
On 03/27/2017 08:28 AM, Daniel Vetter wrote:
> We discussed this quickly on irc, transcribing.
>
> On Mon, Mar 27, 2017 at 5:01 AM, Michel Dänzer wrote:
>> Strictly speaking, the (virtual) hardware is too limited to support the
>> legacy KMS cursor API. AFAIR e.g. weston at least used to make use
I wanted to get Sean Paul to run the drm-misc show for a bit, for
training reasons and to increase the bus factor. And then realized
there's no docs about what maintainers are doing.
Fix that.
v2: Add backmerges and taking the blame.
Signed-off-by: Daniel Vetter
---
drm-misc.rst | 36 +
Inspired by Jani's efforts to clean this up and structure it better.
Signed-off-by: Daniel Vetter
---
dim.rst | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/dim.rst b/dim.rst
index 2f8fda8c42a7..be541d80ec7e 100644
--- a/dim.rst
+++ b/dim.rst
@@ -283,7
It's kinda beyond just drm-intel nowadays ...
Idea from Jani on irc.
Signed-off-by: Daniel Vetter
---
dim.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dim.rst b/dim.rst
index be541d80ec7e..87a8906aad8d 100644
--- a/dim.rst
+++ b/dim.rst
@@ -2,9 +2,9 @@
dim
==
On Fri, Mar 17, 2017 at 11:34:45AM +0800, Chen-Yu Tsai wrote:
> On Thu, Mar 16, 2017 at 1:37 AM, Rob Herring wrote:
> > On Tue, Mar 07, 2017 at 09:56:26AM +0100, Maxime Ripard wrote:
> >> The Allwinner Timings Controller has two, mutually exclusive, channels.
> >> When the binding has been introdu
On Mon, Mar 27, 2017 at 10:45:45AM +0200, Daniel Vetter wrote:
> Inspired by Jani's efforts to clean this up and structure it better.
>
> Signed-off-by: Daniel Vetter
Forgot to add in the commit message: This adds the doc for
update-next-continue.
-Daniel
> ---
> dim.rst | 20 ++---
The property is used by the driver but is missing from the DT bindings.
Document it.
Reported-by: Geert Uytterhoeven
Signed-off-by: Laurent Pinchart
---
Documentation/devicetree/bindings/display/renesas,du.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bin
Hi Geert,
On Thursday 23 Mar 2017 16:10:56 Geert Uytterhoeven wrote:
> On Mon, Sep 14, 2015 at 12:50 AM, Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart
> >
> >
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >
> > +int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
>
Also unify/merge with the existing stuff.
I was a bit torn where to put this, but in the end I decided to put
all the ioctl/sysfs/debugfs stuff into drm-uapi.rst. That means we
have a bit a split with the other uapi related stuff used internally,
like drm_file.[hc], but I think overall this makes
Hi Laurent,
On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart
wrote:
> The property is used by the driver but is missing from the DT bindings.
> Document it.
>
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/display/renesas,du.txt
On Fri, Mar 24, 2017 at 11:42:53AM +0100, Philipp Zabel wrote:
> On Fri, 2017-03-24 at 10:24 +, Martyn Welch wrote:
> [...]
> > > Could you move to v4.9 or v4.10 and check if the four patches in
> > > https://git.pengutronix.de/cgit/pza/linux/tag/?id=v4.9-ipu-dp-plane-fix
> > > or
> > > https:/
A malicious caller could otherwise hand over handles to other objects
causing all sorts of interesting problems.
Testing done: Ran a Fedora 25 desktop using both Xorg and
gnome-shell/Wayland.
Cc:
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence
Previously, when a surface was opened using a legacy (non prime) handle,
it was verified to have been created by a client in the same master realm.
Relax this so that opening is also allowed recursively if the client
already has the surface open.
This works around a regression in svga mesa where o
On 03/27/2017 03:26 PM, Andrey Ryabinin wrote:
> [+CC drm folks, see the following threads:
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_201703232349.BGB95898.QHLVFFOMtFOOJS-40I-2Dlove.SAKURA.ne.jp&d=DwIC-g&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMC
On 26/01/17 14:37, Martin Peres wrote:
Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending co
https://bugs.freedesktop.org/show_bug.cgi?id=98629
Brian Paul changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
On Wed, Mar 22, 2017 at 10:50:46PM +0100, Daniel Vetter wrote:
> Yes the help text is unhelpful, but atomic drivers should never use
> this. Just grab the lock without context or anything.
>
> Also an aside: Checking ->active like this doesn't protect against
> nonblocking commits, this is rather
I've been contributing to vga_switcheroo for the past two years and by
now am fairly familiar with it, so danvet suggested that I add myself
as reviewer.
While at it, add missing file pattern for vga_switcheroo.h + vgaarb.h
to the DRM and DRM-MISC sections such that get_maintainer.pl returns
dri-d
Hi Daniel,
On 23-03-2017 11:00, Daniel Vetter wrote:
> On Thu, Mar 23, 2017 at 10:44:16AM +, Jose Abreu wrote:
>> Hi Daniel,
>>
>>
>> On 23-03-2017 07:22, Daniel Vetter wrote:
>>> On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote:
We can't expect userspace to have full support f
This adds support for the Winstar Display Co. WF35LTIACD 3.5" QVGA TFT
LCD panel, which can be supported by the simple panel driver.
Acked-by: Rob Herring
Signed-off-by: Richard Genoud
---
Changes since v2:
Remove status, reg and unit-addresses from example
Changes since v1:
Add power-supply p
Thomas Hellstrom wrote:
> So to summarize. Yes, the drm callers can be fixed up, but IMO requiring
> vfree() to be non-atomic is IMO not a good idea if avoidable.
I agree.
I don't know about drm code. But I can find AppArmor code doing
kvfree() from dfa_free() from aa_dfa_free_kref() from kref_pu
The display backend has an interrupt line. Add it to the device tree
binding.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
b/Docum
從我的 iPad 傳送
> Ander Conselvan De Oliveira 於 2017年3月14日 下午9:53 寫道：
>
>> On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
>>
>> 從我的 iPad 傳送
>>
Ville Syrjälä 於 2017年3月7日 上午2:34 寫道：
On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
從我的 iPad 傳送
>> V
2017-03-24 16:58 GMT+01:00 Rob Herring :
> On Mon, Mar 20, 2017 at 02:32:22PM +0100, Richard Genoud wrote:
>> This adds support for the Winstar Display Co. WF35LTIACD 3.5" QVGA TFT
>> LCD panel, which can be supported by the simple panel driver.
>>
>> Signed-off-by: Richard Genoud
>> ---
>>
>> Cha
On Mon, Mar 27, 2017 at 04:26:02PM +0300, Andrey Ryabinin wrote:
> [+CC drm folks, see the following threads:
>
> http://lkml.kernel.org/r/201703232349.bgb95898.qhlvffomtfo...@i-love.sakura.ne.jp
>
> http://lkml.kernel.org/r/1490352808-7187-1-git-send-email-penguin-ker...@i-love.sakur
> On Tue, Mar 21, 2017 at 5:00 PM, Stephen Rothwell
wrote:
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_gem_shrinker.c
>
> between commit:
>
> 3d3d18f086cd ("drm/i915: Avoid rcu_barrier() from reclaim paths
(shrinker)")
>
> from the d
The display backend on sun5i shares the same interrupt line as the
display frontend. Add it.
Signed-off-by: Chen-Yu Tsai
---
This won't directly apply to old releases. We may want to backport
them though?
---
arch/arm/boot/dts/sun5i.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch
Hello there,
linux-4.11-rc4/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c:1319]: (style) Redundant
condition: If 'EXPR == 0', the comparison 'EXPR != 1' is always true.
Source code is
if ((HDCP_STATE_INACTIVE != hdcp_ctrl->hdcp_state) ||
(HDCP_STATE_NO_AKSV == hdcp_ctrl->hdcp_state)) {
Sugg
Hi Maxime,
As promised, here is the patch adding the interrupt line for the display
backend to the sun5i shared dtsi, and another one adding it to the device
tree bindings.
The display backend has an undocumented (in the user manual) interrupt
that, according to vendor code, is raised when the cu
On 03/27/2017 05:29 PM, Tetsuo Handa wrote:
> Thomas Hellstrom wrote:
>> So to summarize. Yes, the drm callers can be fixed up, but IMO requiring
>> vfree() to be non-atomic is IMO not a good idea if avoidable.
>
> I agree.
>
> I don't know about drm code. But I can find AppArmor code doing
> k
On Sat, 25 Mar 2017, Shashank Sharma wrote:
> This patch adds description about 'scdc' variable in drm_hdmi_info
> structure, to fix this warning during doc-build.
>
> "drm_connector.h:140: warning: No description found for parameter 'scdc'"
Did you actually run 'make htmldocs' with this? The ope
On Mon, 27 Mar 2017, Jani Nikula wrote:
> On Sat, 25 Mar 2017, Shashank Sharma wrote:
>> This patch adds description about 'scdc' variable in drm_hdmi_info
>> structure, to fix this warning during doc-build.
>>
>> "drm_connector.h:140: warning: No description found for parameter 'scdc'"
>
> Did y
On Wednesday, March 22, 2017 10:50:40 PM EDT Daniel Vetter wrote:
> This is just prep work to get an acquire ctx into every place where we
> call ->update_plane or ->disable_plane.
>
> v2: Keep the hidden acquire_ctx pointers valid while transitioning.
>
> Signed-off-by: Daniel Vetter
> ---
> d
This series enables atomic mode set on vmwgfx. Developed in
collaboration with Thomas Hellstrom and the VMWare Graphics
Team.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Create and Add CRTC state. We currently do not track any properties
or custom states so we can technically use the DRM helpers. Creating
this code just to make potential future additions easier.
Most of the new code will be compiled but not enabled until
plane/connector state handling code is al
Universal support is prerequisite for atomic mode set.
Explicitly create planes for the cursor and the primary FB. With
a functional cursor plane, the DRM will no longer use the legacy
cursor_set2 and cursor_move entry points.
Signed-off-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
Reviewe
Add connector handling functions. Start tracking is_implicity in
the connector state. Eventually, this field should be tracked
exclusively in a connector state.
Now that plane and connector states have been created, we can also
activate the code that use CRTC state.
Signed-off-by: Sinclair Yeh
Add plane state handling functions.
We have to keep track of a few plane states so we cannot use the
DRM helper for this.
Created vmw_plane_state along with functions to reset, duplicate,
and destroty it.
Signed-off-by: Sinclair Yeh
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmw
Atomic mode set requires us to refactor existing vmw_stdu_crtc_set_config
code into sections that check the validity of the new mode, and sections
that actually program the hardware state.
vmw_du_crtc_atomic_check() takes CRTC-related checking code. In a later
patch, vmw_du_primary_plane_atomic_c
Refactor previous FB and cursor plane update code into their
atomic counterparts: check, update, prepare, cleanup, and disable.
These helpers won't be called until we flip on the atomic support
flag or set drm_crtc_funcs->set_config to using the atomic
helper.
v2:
* Removed unnecessary pinning of
1. When unsetting a mode, num_connector should be set to zero
2. The pixel_format field needs to be initialized as newer DRM internal
functions checks this field
3. Take the drm_modeset_lock_all() because vmw_fb_kms_detach() can
change current mode
Signed-off-by: Sinclair Yeh
Reviewed-
This connects the main state object check and commit function.
Signed-off-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 66 +
1 file changed, 66 insertions(+)
diff --git a/drivers/gp
Since the link between connector and encoder is always fixed in our case,
just return the one encoder.
These helpers won't be called until we flip on the atomic support
flag or set drm_crtc_funcs->set_config to using the atomic
helper.
Signed-off-by: Sinclair Yeh
Reviewed-by: Thomas Hellstrom
-
Switch over to using internal atomic API for mode set.
This removes the legacy set_config API, replacing it with
drm_atomic_helper_set_config(). The DRM helper will use various
vmwgfx-specific atomic functions to set a mode.
DRIVER_ATOMIC capability flag is not yet set, so the user mode
will sti
Switch over to internal atomic API. This completes the atomic
internal atomic switch for all the Display Units.
Signed-off-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 103 ++---
drivers/gpu/drm/vmwgfx/vm
https://bugs.freedesktop.org/show_bug.cgi?id=100398
--- Comment #1 from Alex Deucher ---
Is this still an issue with the latest drm-next-4.12-wip branch? I just a
squashed in a fix for this.
--
You are receiving this mail because:
You are the assignee for the bug.__
We can no longer make the assumption that vmw_stdu_update_st() will
be called when there's a valid display surface attached. So
instead of using display_srf for width and height, make a record of
these paremeters when the screen target is first defined.
Signed-off-by: Sinclair Yeh
Reviewed-by: T
These are a collection of patches currently queued for vmwgfx-next
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Pinning fbdev's FB at the start of VRAM prevents X from pinning
its FB. Since for ldu, the fb would be pinned anyway during a
mode set, just skip pinning it in fbdev.
This is not the best solution, but since ldu is not used much
anymore, it seems like a reasonable workaround.
Signed-off-by: Sinc
vmw_ldu_crtc_helper_commit() is not called if
drm_atomic_crtc_needs_modeset() decides nothing related to CRTC timing has
changed.
So a better place for this code is in vmw_ldu_primary_plane_atomic_update()
since we will need to update ld->fb every time the FB is updated.
Signed-off-by: Sinclair Y
From: Thomas Hellstrom
The callbacks we need to provide to many resources are very similar, so
provide a simple resource type with a number of helpers for these
callbacks.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/Makefile | 3 +-
d
From: Thomas Hellstrom
Instead of providing an ioctl for each handle type, provide a single
handle_close ioctl, and reuse the UNREF_DMABUF ioctl.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
include/uapi/drm/vmwgfx_drm.h | 24
1 file changed, 24 inser
From: Thomas Hellstrom
Provide and document a reference implementation.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 254 ---
drivers/gpu/drm/vmwgfx/vmwgf
From: Øyvind A. Holm
This reverts commit 2d8e60e8b074 ("drm/vmwgfx: Replace numeric
parameter like 0444 with macro")
The commit belongs to the series of 1285 patches sent to LKML on
2016-08-02, it changes the representation of file permissions from the
octal value "0600" to "S_IRUSR | S_IWUSR".
Most of the display servers today use a single surface to represent the
entire desktop even if it's stretched across multiple screens.
For vmwgfx with STDU, the maximum surface size is limited to the
maximum texture size on the host. On a 2D VM, this limits our
ability to support configurations w
The scanout surface size is the smaller of max texture size and
max STDU size.
Signed-off-by: Sinclair Yeh
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +++
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 16 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |
https://bugs.freedesktop.org/show_bug.cgi?id=100424
Bug ID: 100424
Summary: X hang (in kernel) after some event in Serious Sam
Fusion using radv. 4.9/and-staging-4.9
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=100424
--- Comment #1 from Darren Salt ---
I'm aware (via IRC) that 4.11-rc3 should be fine. However, as I'm using
amd-staging-4.9 for its HDMI audio support, this isn't an option.
--
You are receiving this mail because:
You are the assignee for the
On 03/26/2017 09:05 PM, Ayaka wrote:
從我的 iPad 傳送
Ander Conselvan De Oliveira 於 2017年3月14日 下午9:53 寫道：
On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
從我的 iPad 傳送
Ville Syrjälä 於 2017年3月7日 上午2:34 寫道：
On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
從我的 iPad 傳送
Ville Syrjälä 於
https://bugs.freedesktop.org/show_bug.cgi?id=100390
--- Comment #6 from Samuel Pitoiset ---
The game requests a 4.1 compatibility profile which is unsupported by Mesa and
it crashes because it doesn't check the return value of
glXCreateContextAttribsARB.
I'm investigating in order to know if it'
Until now, we've had to limit Raspberry Pi to 256MB of CMA memory to
keep from triggering the hardware addressing bug between of the tile
binner of the tile alloc memory (where the top 4 bits come from the
tile state data array's address).
To work around that and allow more memory to be reserved f
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.12-wip
head: ba92d1fc68425bbff454195c1a7bf07ec9b650d0
commit: 7b6a92ae5cf029e021246cb79c8613b19e4554d4 [208/266] drm/amdgpu: Add GMC
9.0 support (v2)
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3)
https://bugs.freedesktop.org/show_bug.cgi?id=100398
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #2 from
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.12-wip
head: ba92d1fc68425bbff454195c1a7bf07ec9b650d0
commit: 8ddf606557a311b7a4b4b5ad0578e52d2e7d5728 [211/266] drm/amdgpu: add
vega10 interrupt handler
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0
https://bugs.freedesktop.org/show_bug.cgi?id=100390
--- Comment #7 from Samuel Pitoiset ---
Okay, the game uses ARB_texture_buffer_object which is only exposed with a core
profile for some reasons. I'm able to run the game with some hacky changes but
it fails to render correctly at some point.
U
https://bugs.freedesktop.org/show_bug.cgi?id=98924
--- Comment #3 from Jeroen Bollen ---
I can confirm this bug also.
Hardware:
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Opal
XT [Radeon R7 M265] (rev 81)
Subsystem: Hewlett-Packard Company Device 814f
https://bugs.freedesktop.org/show_bug.cgi?id=100400
--- Comment #6 from Samuel Pitoiset ---
Thanks for this very nice report. :)
I can reproduce the issue with mesa/LLVM from today.
--
You are receiving this mail because:
You are the assignee for the bug.___
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.12-wip
head: ba92d1fc68425bbff454195c1a7bf07ec9b650d0
commit: 0e14c5d6baef9140a24d83f5cf53bb59a1952e87 [198/266] drm/amdgpu: add NGG
parameters
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian
On Wednesday, March 22, 2017 10:50:52 PM EDT Daniel Vetter wrote:
> No need to grab both plane and crtc locks at the same time, we can do
> them one after the other. If userspace races it'll get what it
> deserves either way.
>
> This removes another user of drm_modeset_lock_crtc. There's only one
Patches 2-5, 9-12, 14-19: Reviewed-by: Harry Wentland
Patches 1,13: Questions in response to those patches
Patches 6-8: Acked-by: Harry Wentland
Looks like a nice cleanup.
Harry
On Wednesday, March 22, 2017 10:50:39 PM EDT Daniel Vetter wrote:
> Hi all,
>
> This is something I kinda had on
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.
Also don't enable any InfoFrame that is not p
On Thu, Dec 15, 2016 at 6:24 PM, Laurent Pinchart
wrote:
> From: Sakari Ailus
>
> The struct vb2_dc_buf contains two struct sg_table fields: sgt_base and
> dma_sgt. The former is used by DMA-BUF buffers whereas the latter is used
> by USERPTR.
>
> Unify the two, leaving dma_sgt.
I think this pat
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.
Also don't enable any AVI or Vendor InfoFrame
HDMI 3D mode support, round two. Revisions include no longer dealing
with audio InfoFrames, passing infoframe data to NVKM as bags of bytes
rather than as data pre-packed for the hardware, more-normal return
value checking for drm_hdmi_*_infoframe_from_display_mode() results,
Frame-Packing mode su
* Frame-packing modes add an extra vtotal raster lines to each
frame above and beyond what the basic mode description calls for.
Account for this during scaler configuration (possibly a bit of a
hack), during CRTC configuration (clearly not a hack), and when
checking that a mode is vaild for a gi
On Thu, Dec 15, 2016 at 6:24 PM, Laurent Pinchart
wrote:
> From: Sakari Ailus
>
> The cache synchronisation may be a time consuming operation and thus not
> best performed in an interrupt which is a typical context for
> vb2_buffer_done() calls. This may consume up to tens of ms on some
> machine
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic"?) InfoFrame.
Also don't enable any InfoFrame that is not p
The nouveau driver, in the Linux 3.7 days, used to try and set the
AVI InfoFrame based on the selected display mode. These days, it
uses a fixed set of InfoFrames. Start to correct that, by
providing a mechanism whereby InfoFrame data may be passed to the
NVKM functions that do the actual configu
On Mon, 2017-03-27 at 10:35 +0200, Maarten Lankhorst wrote:
> Op 27-03-17 om 10:31 schreef Daniel Vetter:
> > On Mon, Mar 27, 2017 at 10:28:42AM +0200, Maarten Lankhorst wrote:
> >> Op 27-03-17 om 08:38 schreef Daniel Vetter:
> >>> On Wed, Mar 22, 2017 at 03:30:49PM -0700, Dhinakaran Pandiyan wrote
Enable stereoscopic output for HDMI and DisplayPort connectors on
NV50+ (G80+) hardware. We do not enable stereoscopy on older
hardware in case there is some older board that still has HDMI
output but for which we have no logic for setting the Vendor
InfoFrame.
With this, I get an obvious 3D outp
HDMI InfoFrames are passed to NVKM as bags of bytes, but the
hardware needs them to be packed into words. Rather than having
four (or more) copies of the packing logic introduce a single copy
now, in a central place.
We currently need these for AVI and Vendor InfoFrames, but we may
also expect to
Now that we have mechanism by which to pass mode-dependent HDMI
InfoFrames to the low-level hardware driver, it is incumbent upon
us to do so.
Signed-off-by: Alastair Bridgewater
---
drivers/gpu/drm/nouveau/nv50_display.c | 30 +-
1 file changed, 29 insertions(+), 1 d
Now that we have the InfoFrame data being provided, for the most
part, program the hardware to use it.
While we're here, and since the functionality will come in handy
for supporting 3D stereoscopy, implement setting the Vendor
("generic") InfoFrame.
Also don't enable any AVI or Vendor InfoFrame
On Thu, Dec 15, 2016 at 6:24 PM, Laurent Pinchart
wrote:
> From: Samu Onkalo
>
> The user may request to the driver (vb2) to skip the cache maintenance
> operations in case the buffer does not need cache synchronisation, e.g. in
> cases where the buffer is passed between hardware blocks without i
* drm_mode_set_crtcinfo() does compensation for interlace and
doublescan timing effects already, so do it first and use the
compensated figures instead of the constant "vscan / ilace" terms
that we had before.
* Also prefer using the mode->crtc_* fields generally instead of
the non-crtc_-prefi
Hi Alastair,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.11-rc4 next-20170327]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Alastair-Bridgewater/Enable-HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=100400
Michel Dänzer changed:
What|Removed |Added
Attachment #130461|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=100400
--- Comment #7 from Michel Dänzer ---
valgrind might give more information.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=100424
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Vulkan/radeon
Versio
https://bugs.freedesktop.org/show_bug.cgi?id=100395
--- Comment #1 from Michel Dänzer ---
So this doesn't happen with amdgpu.dc=0?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.free
https://bugs.freedesktop.org/show_bug.cgi?id=100392
Michel Dänzer changed:
What|Removed |Added
Attachment #130456|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=100392
--- Comment #2 from Michel Dänzer ---
Please attach the dmesg output from when the problem occurs.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
1 - 100 of 114 matches
Mail list logo
