On Thu, May 25, 2017 at 5:01 AM, Shawn Guo wrote:
> On Wed, May 24, 2017 at 04:52:11PM +0200, Daniel Vetter wrote:
>> It again looks all cargo-culted for no good reasons.
>
> drm_vblank_cleanup() is called to release the resources allocated by
> drm_vblank_init(). I think that's the reason, no?
On Fri, May 26, 2017 at 7:52 AM, Christoph Hellwig wrote:
> On Fri, May 26, 2017 at 10:30:09AM +0800, jeffy wrote:
>> Hi sean,
>>
>> On 05/25/2017 11:30 PM, Sean Paul wrote:
>> > On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
>> > > The system would crash when trying to alloc zero siz
On Thu, May 25, 2017 at 1:09 AM, Patrik Jakobsson
wrote:
> On Wed, May 24, 2017 at 9:52 PM, Daniel Vetter wrote:
>> On Wed, May 24, 2017 at 6:57 PM, Patrik Jakobsson
>> wrote:
>>> Hi Dave and Daniel,
>>>
>>> We had a little mishap this morning when I had pushed a fix for gma500
>>> into drm-misc
On Thu, May 25, 2017 at 7:37 AM, Lukas Wunner wrote:
> On Wed, May 24, 2017 at 11:28:12AM +0200, Daniel Vetter wrote:
>> We can't check this when applying (since r-b/a-b tags often get added
>> afterwards), but we can check this when pushing. This only looks at
>> patches authored by the pusher.
>
On Thu, May 25, 2017 at 7:44 PM, Sean Paul wrote:
> The pull is noisy
> because it includes -rc2.
dim has you covered for this, in case you've rolled forward but Dave
hasn't yet, you can regenerate against linus upstream branch for a
cleaner pull (but still warn Dave ofc):
$ dim pull-request drm
On 26 May 2017 at 15:30, Lukas Wunner wrote:
> On Thu, May 25, 2017 at 01:44:04PM -0400, Sean Paul wrote:
>> The pull is noisy because it includes -rc2.
>
> Looks like I've caused another fine mess by fast-forwarding -fixes. :-(
>
> I followed the docs in drm-misc.rst which say:
>
> * Fast-forward
On Fri, May 26, 2017 at 10:30:09AM +0800, jeffy wrote:
> Hi sean,
>
> On 05/25/2017 11:30 PM, Sean Paul wrote:
> > On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
> > > The system would crash when trying to alloc zero sized gem buffer:
> > > [6.712435] Unable to handle kernel NULL
On Thu, May 25, 2017 at 01:44:04PM -0400, Sean Paul wrote:
> The pull is noisy because it includes -rc2.
Looks like I've caused another fine mess by fast-forwarding -fixes. :-(
I followed the docs in drm-misc.rst which say:
* Fast-forward (when possible) `-fixes` to each released -rc kernel tag,
On 25 May 2017 at 18:30, Chris Wilson wrote:
> On Wed, May 24, 2017 at 05:06:11PM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> Sync objects are new toplevel drm object, that contain a
>> pointer to a fence. This fence can be updated via command
>> submission ioctls via drivers.
>>
>> Ther
Hi Linus,
Not a whole lot happening here, a set of amdgpu fixes and one core
deadlock fix, and some misc drivers fixes.
Dave.
The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:
Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)
are available in the git repository at:
gi
On 05/25/2017 07:49 PM, Jose Abreu wrote:
Now that we have a callback to check if bridge supports a given mode
we can use it in Analogix bridge so that we restrict the number of
probbed modes to the ones we can actually display.
Also, there is no need to use mode_fixup() callback as mode_valid
On 05/25/2017 07:49 PM, Jose Abreu wrote:
Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.
Reviewed-by: Archit Taneja
Signed-off-by: Jose Abreu
Reviewed-by: Daniel Vetter
Cc: Carlos Palminha
Cc: Ville Syrjälä
Cc: Dave Airlie
Cc: A
On 05/26/2017 09:46 AM, Archit Taneja wrote:
Hi,
On 05/25/2017 05:04 AM, Kuninori Morimoto wrote:
Hi Mark
Cc: DRM maintainer
ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device incl
Hi,
On 05/25/2017 05:04 AM, Kuninori Morimoto wrote:
Hi Mark
Cc: DRM maintainer
ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.
As far as I
On 19 May 2017 at 19:33, Inki Dae wrote:
> Hi Dave,
>
>a little bit big cleanups but this fixes some timeout issue
>at wait-for-vblank, fixups to dt broken issue and trivial cleanups.
>
>Please kindly let me know if there is any problem.
Can we make this smaller, if I'd been happy for
Hi sean,
On 05/25/2017 11:30 PM, Sean Paul wrote:
On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
The system would crash when trying to alloc zero sized gem buffer:
[6.712435] Unable to handle kernel NULL pointer dereference at virtual address
0010 <--ZERO_SIZE_PTR
...
[
https://bugzilla.kernel.org/show_bug.cgi?id=194761
--- Comment #20 from Michel Dänzer (mic...@daenzer.net) ---
Flora, why did you add me to Cc? I get notifications via the dri-devel mailing
list.
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
Now that we have a callback to check if crtc supports a given mode
we can use it in malidp so that we restrict the number of probbed
modes to the ones we can actually display.
Also, remove the mode_fixup() callback as this is no longer needed
because mode_valid() will be called before.
NOTE: Not
Now that we have a callback to check if bridge supports a given mode
we can use it in Analogix bridge so that we restrict the number of
probbed modes to the ones we can actually display.
Also, there is no need to use mode_fixup() callback as mode_valid()
will handle the mode validation.
NOTE: Onl
Now that we have a callback to check if crtc supports a given mode
we can use it in atmel-hlcdc so that we restrict the number of probbed
modes to the ones we can actually display.
Also, remove the mode_fixup() callback as this is no longer needed
because mode_valid() will be called before.
NOTE:
This changes the connector probe helper function to use the new
encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
helper callbacks to validate the modes.
The new callbacks are optional so the behaviour remains the same
if they are not implemented. If they are, then the code loops
Now that we have a callback to check if crtc supports a given mode
we can use it in arcpgu so that we restrict the number of probbed
modes to the ones we can actually display.
This is specially useful because arcpgu crtc is responsible to set
a clock value in the commit() stage but unfortunatelly
Add a new helper to call crtc->mode_valid, connector->mode_valid
and encoder->mode_valid callbacks.
Suggested-by: Ville Syrjälä
Signed-off-by: Jose Abreu
Reviewed-by: Daniel Vetter
Reviewed-by: Andrzej Hajda
Cc: Carlos Palminha
Cc: Dave Airlie
Changes v2->v3:
- Move helpers to drm_p
Hi, Jani, just relized you are in i915 team. :)
> > +menu "Intel GVT-g graphics virtualization host support"
> > + depends on DRM_I915
> > + depends on 64BIT
> > +
> > config DRM_I915_GVT
> > -bool "Enable Intel GVT-g graphics virtualization host support"
> > -depends on DRM_I
NOTE: In this version I just did a rebase onto today's drm-next and
added the tags we've collected plus the changelog plus the missing
maintainers that I forgot to cc in previous version :/
This series is a follow up from the discussion at [1]. We start by
introducing crtc->mode_valid(), encoder->
Now that we have a callback to check if bridge supports a given mode
we can use it in Synopsys Designware HDMI bridge so that we restrict
the number of probbed modes to the ones we can actually display.
Also, there is no need to use mode_fixup() callback as mode_valid()
will handle the mode valida
This patches makes use of the new mode_valid() callbacks introduced
previously to validate the full video pipeline when modesetting.
This calls the connector->mode_valid(), encoder->mode_valid(),
bridge->mode_valid() and crtc->mode_valid() so that we can
make sure that the mode will be accepted in
Now that we have a callback to check if crtc and encoder supports a
given mode we can use it in vc4 so that we restrict the number of
probbed modes to the ones we can actually display.
Also, remove the mode_fixup() calls as these are no longer needed
because mode_valid() will be called before.
NO
Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.
Signed-off-by: Jose Abreu
Reviewed-by: Daniel Vetter
Cc: Carlos Palminha
Cc: Ville Syrjälä
Cc: Dave Airlie
Cc: Andrzej Hajda
Cc: Archit Taneja
Cc: Laurent Pinchart
---
drivers/gpu/drm/dr
2017년 05월 26일 10:02에 Hoegeun Kwon 이(가) 쓴 글:
> Since bridge node is referenced during in the probe, it should be
> released on removal.
>
> Suggested-by: Andrzej Hajda
> Signed-off-by: Hoegeun Kwon
> ---
> Hi Inki,
>
> This patch seems to have been forgotten... :)
Yeah, forgot this. Merged.
Since bridge node is referenced during in the probe, it should be
released on removal.
Suggested-by: Andrzej Hajda
Signed-off-by: Hoegeun Kwon
---
Hi Inki,
This patch seems to have been forgotten... :)
Changes for V2:
- Checked for rebase 4.12-rc2
Best regards,
Hoegeun
drivers/gpu/drm/exyn
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
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
After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.
Cc: Rob Clark
Cc: Archit Taneja
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
1 f
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.
v4: add missing atomic async commit call to msm_atomic_commit(Archit Taneja)
v3: move si
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.
v3: move size checks back to drivers (Ville Syrjälä)
v2: move fb setting to core and use new state (Eri
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.
v3:
- set correct vma to new state for cleanup
- move size checks back to driv
From: Gustavo Padovan
Hi,
Resending to include intel-gfx@ and get the patches picked up by CI.
New version of the patches after the comments from Archit. Full details
and the previous discussion can be found here:
https://www.spinics.net/lists/dri-devel/msg141337.html
I'm not including the uA
2017-05-25 Chris Wilson :
> On Thu, May 25, 2017 at 01:41:33AM -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 b
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #38 from intermedi...@hotmail.com ---
[ 12.980953] amdgpu :01:00.0: fb0: amdgpudrmfb frame buffer device
[ 12.982746] [drm:.gfx_v6_0_ring_test_ib [amdgpu]] *ERROR* amdgpu: ib test
failed (scratch(0x2140)=0xCAFEDEAD)
[ 12.982
Hi Dave,
A handful of fixes for you this week, nothing overly complex. The pull is noisy
because it includes -rc2.
Due to some process miscommunications, Lukas fast-forwarded -fixes and merged
the radeon patch without R-b. Patrik also merged the gma500 patch directly
without review. Daniel has add
On Thu, May 25, 2017 at 1:25 PM, Jordan Crouse wrote:
> On Mon, May 08, 2017 at 02:35:06PM -0600, Jordan Crouse wrote:
>> -#define rbmemptr(adreno_gpu, member) \
>> +#define _sizeof(member) \
>> + sizeof(((struct adreno_rbmemptrs *) 0)->member[0])
>> +
>> +#define _base(adreno_gpu, member) \
Hi Dave,
A bunch of bug fixes:
- Fix display flickering on some chips at high refresh rates
- suspend/resume fix
- hotplug fix
- a couple of segfault fixes for certain cases
The following changes since commit d51aff16e821a755c242e14168f5d4601199eafd:
Merge branch 'for-upstream/hdlcd' of git://
On Mon, May 08, 2017 at 02:35:06PM -0600, Jordan Crouse wrote:
> -#define rbmemptr(adreno_gpu, member) \
> +#define _sizeof(member) \
> + sizeof(((struct adreno_rbmemptrs *) 0)->member[0])
> +
> +#define _base(adreno_gpu, member) \
> ((adreno_gpu)->memptrs_iova + offsetof(struct adreno_
https://bugs.freedesktop.org/show_bug.cgi?id=101190
Bug ID: 101190
Summary: building gallium/R600 fails due to missing amdgpu.h
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=101189
Bug ID: 101189
Summary: Latest git fails to compile with radeon
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
Am 25.05.2017 um 10:47 schrieb Chris Wilson:
On Wed, May 24, 2017 at 05:06:12PM +1000, Dave Airlie wrote:
From: Dave Airlie
This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.
v2: a
On 05/25/2017 05:30 PM, Mike Lothian wrote:
> Hi
>
> Sorry if this is off topic, I've got a Skylake Dell laptop with a USB-C
> connector and no displayport
>
> Which USB-C -> HDMI-2.0 connector do you recommend for stuff just working
> based on your testing?
>
> I've been putting off buying o
On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
> The system would crash when trying to alloc zero sized gem buffer:
> [6.712435] Unable to handle kernel NULL pointer dereference at virtual
> address 0010 <--ZERO_SIZE_PTR
> ...
> [6.757502] PC is at sg_alloc_table_from_page
Hi
Sorry if this is off topic, I've got a Skylake Dell laptop with a USB-C
connector and no displayport
Which USB-C -> HDMI-2.0 connector do you recommend for stuff just working
based on your testing?
I've been putting off buying one until I knew 4K@60Hz would work, CEC would
be nice to have too
From: Hans Verkuil
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is create
From: Hans Verkuil
Simplifies setting the physical address to CEC_PHYS_ADDR_INVALID.
Signed-off-by: Hans Verkuil
---
include/media/cec.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/media/cec.h b/include/media/cec.h
index 9989cdb58bd8..6123a5eec540 100644
--- a/include/medi
From: Hans Verkuil
This function simplifies the integration of CEC in DRM drivers.
Signed-off-by: Hans Verkuil
---
drivers/media/cec/cec-adap.c | 14 ++
include/media/cec.h | 9 +
2 files changed, 23 insertions(+)
diff --git a/drivers/media/cec/cec-adap.c b/drive
From: Hans Verkuil
Add a new capability CEC_CAP_NEEDS_HPD. If this capability is set
then the hardware can only use CEC if the HDMI Hotplug Detect pin
is high. Such hardware cannot handle the corner case in the CEC specification
where it is possible to transmit messages even if no hotplug signal
From: Hans Verkuil
Implement support for this DisplayPort feature.
The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the p
From: Clint Taylor
Adding DPCD register definitions from the DP 1.3 specification for CEC
over AUX support.
V2: Add DP_ prefix to all defines.
V3: missed prefixes from the ESI1 defines
Cc: Jani Nikula
Reviewed-by: Jani Nikula
Signed-off-by: Clint Taylor
Signed-off-by: Jani Nikula
Link:
ht
From: Hans Verkuil
Document the new CEC_CAP_NEEDS_HPD capability.
Signed-off-by: Hans Verkuil
---
Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
b/Documentation/media/uapi/ce
From: Hans Verkuil
This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
protocol.
This patch series is based on v4.12-rc2.
The first four patches add support for a new CEC capability which is
needed for these devices and for two helper functions.
Then the DP CEC registers
https://bugzilla.kernel.org/show_bug.cgi?id=195737
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugs.freedesktop.org/show_bug.cgi?id=101182
--- Comment #3 from Christoph Haag ---
Can this be done asynchronously in the driver so it doesn't impact the
rendering of 3D applications?
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=101182
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=101185
Bug ID: 101185
Summary: System hang during piglit tests
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Hi Philippe,
Thanks a lot for creating a bridge driver for this.
Copying some Hisilicon and Rockchip folks so that they can consider adapting to
this.
Some comments below.
On 05/19/2017 08:50 PM, Philippe CORNU wrote:
Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
Ro
https://bugs.freedesktop.org/show_bug.cgi?id=99349
--- Comment #6 from Gert Wollny ---
The actual instruction failing is
MUL TEMP[11], CONST[26], CONST[23]
i.e. the multiplication of two constants.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=98874
Matthias Nagel changed:
What|Removed |Added
Summary|Desktop suddenly freezes, |amdgpu:
|login via ss
https://bugzilla.kernel.org/show_bug.cgi?id=195737
beta990 (francois5...@gmail.com) changed:
What|Removed |Added
Kernel Version|4.10.13 |4.11.2
--
You are rec
https://bugzilla.kernel.org/show_bug.cgi?id=195737
--- Comment #7 from beta990 (francois5...@gmail.com) ---
Sorry for the delay. I've added the requested logs and provided a photo of what
is happening on my screen atm. when using AMDGPU.
Thanks and please let me know if more info is needed. :)
-
https://bugzilla.kernel.org/show_bug.cgi?id=195737
--- Comment #6 from beta990 (francois5...@gmail.com) ---
Created attachment 256717
--> https://bugzilla.kernel.org/attachment.cgi?id=256717&action=edit
Screen
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugzilla.kernel.org/show_bug.cgi?id=195737
--- Comment #5 from beta990 (francois5...@gmail.com) ---
Created attachment 256715
--> https://bugzilla.kernel.org/attachment.cgi?id=256715&action=edit
Xorg-log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=195737
--- Comment #4 from beta990 (francois5...@gmail.com) ---
Created attachment 256713
--> https://bugzilla.kernel.org/attachment.cgi?id=256713&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
On Wed, May 24, 2017 at 05:06:13PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This interface allows importing the fence from a sync_file into
> an existing drm sync object, or exporting the fence attached to
> an existing drm sync object into a new sync file object.
>
> This should only b
On Wed, May 24, 2017 at 05:06:12PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This interface will allow sync object to be used to back
> Vulkan fences. This API is pretty much the vulkan fence waiting
> API, and I've ported the code from amdgpu.
>
> v2: accept relative timeout, pass remai
On Wed, May 24, 2017 at 05:06:11PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Sync objects are new toplevel drm object, that contain a
> pointer to a fence. This fence can be updated via command
> submission ioctls via drivers.
>
> There is also a generic wait obj API modelled on the vulk
On 2017-05-24 07:51, Daniel Vetter wrote:
> Again cleanup before irq disabling doesn't really stop the races,
> so just drop it. Proper fix would be to put drm_atomic_helper_shutdown
> before everything gets cleaned up.
Hm, I already use the non-atomic drm_crtc_force_disable_all before, I
think th
https://bugs.freedesktop.org/show_bug.cgi?id=99349
--- Comment #5 from Gert Wollny ---
Adding yet more debugging output, and so far it seems that there is only one
operation failing: a multiplication of two operands with a write mask of 0xF
(see log below).
I also tested gzdoom like the poster
On 2017-05-24 07:51, Daniel Vetter wrote:
> Pull a (much shorter) overview into drm_irq.c, and instead put the
> callback documentation into in-line comments in drm_drv.h.
Looks good and just found all I needed to know to fix IRQ registration
in fsl dcu.
Reviewed-by: Stefan Agner
>
> Signed-of
https://bugs.freedesktop.org/show_bug.cgi?id=101182
--- Comment #1 from Christoph Haag ---
Created attachment 131501
--> https://bugs.freedesktop.org/attachment.cgi?id=131501&action=edit
screenshot showing the stuttering in the HUD
--
You are receiving this mail because:
You are the assignee
77 matches
Mail list logo
