On 07/03/2017 04:27 PM, Inki Dae wrote:
This patch moves drm_bridge_add call into probe.
This change is required by DSI driver so that
the brige can be bound at DSI driver's probe.
Suggested-by: Andrzej Hajda
Signed-off-by: Inki Dae
Reviewed-by: Hoegeun Kwon
Best regards,
Hoegeun
___
Hi Inki,
Could you check this patch? :D
Best regards,
Hoegeun
On 06/21/2017 07:51 PM, Hoegeun Kwon wrote:
Remove the error handling of bridge_node because the bridge_node is
optional.
For example, In case of Exynos SoC, a bridge device such as mDNIe and
MIC could be placed between Display Con
https://bugs.freedesktop.org/show_bug.cgi?id=100399
--- Comment #5 from Michel Dänzer ---
(In reply to jimijames.bove from comment #4)
> Before I switched to AMD, I was passing an NVidia GPU (GTX 660) into my
> virtual machine, and I could unbind and rebind it between nouveau and
> vfio-pci as mu
https://bugs.freedesktop.org/show_bug.cgi?id=101518
Martin Peres changed:
What|Removed |Added
CC||manasi.d.nav...@intel.com
--- Comment #5
https://bugs.freedesktop.org/show_bug.cgi?id=101518
--- Comment #6 from Martin Peres ---
*** Bug 101519 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=100399
--- Comment #6 from jimijames.b...@gmail.com ---
(In reply to Michel Dänzer from comment #5)
> (In reply to jimijames.bove from comment #4)
> > Before I switched to AMD, I was passing an NVidia GPU (GTX 660) into my
> > virtual machine, and I cou
https://bugs.freedesktop.org/show_bug.cgi?id=100399
--- Comment #7 from jimijames.b...@gmail.com ---
(In reply to jimijames.bove from comment #6)
> Well, sort of. That option is what allows me to bind the card to amdgpu
> without X crashing (even though I've been told in the past that I shouldn't
https://bugs.freedesktop.org/show_bug.cgi?id=100399
--- Comment #8 from Michel Dänzer ---
Make sure nothing else (e.g. gdm in Wayland mode) is using the GPU you're
trying to unbind either. Something like
sudo lsof /dev/dri/*
shows which process is using which GPU device(s).
--
You are receiv
https://bugs.freedesktop.org/show_bug.cgi?id=100399
--- Comment #9 from jimijames.b...@gmail.com ---
(In reply to Michel Dänzer from comment #8)
> Make sure nothing else (e.g. gdm in Wayland mode) is using the GPU you're
> trying to unbind either. Something like
>
> sudo lsof /dev/dri/*
>
> sho
This patch moves drm_bridge_add call into probe.
It doesn't need to call drm_bridge_add call every time
bind callback is called.
Changelog v2
- moved drm_bridge_remove call into remove callback.
- corrected description.
Suggested-by: Andrzej Hajda
Reviewed-by: Andrzej Hajda
Signed-off-by: Inki
Hi Ville,
On Tuesday 04 Jul 2017 15:44:02 Ville Syrjälä wrote:
> On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote:
> > On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote:
> >> From: Ville Syrjälä
> >>
> >> Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
On 07/03/2017 02:12 PM, Inki Dae wrote:
This patch removes unnecessary checking of return value.
Ps. this patch depends on below one,
http://www.spinics.net/lists/dri-devel/msg145687.html
Will this one^ go via the exynos pull req or drm-misc? If there won't
be any conflicts, we could
On 07/03/2017 02:12 PM, Inki Dae wrote:
This patch removes unnecessary checking of return value.
Can I get an ack from the maintainers to get this pulled in
via drm-misc?
Thanks,
Archit
Signed-off-by: Inki Dae
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 6 +-
1 file changed, 1 inser
2017년 07월 05일 18:00에 Archit Taneja 이(가) 쓴 글:
>
>
> On 07/03/2017 02:12 PM, Inki Dae wrote:
>> This patch removes unnecessary checking of return value.
>>
>> Ps. this patch depends on below one,
>> http://www.spinics.net/lists/dri-devel/msg145687.html
>
> Will this one^ go via the exynos pu
On 07/05/2017 02:35 PM, Inki Dae wrote:
2017년 07월 05일 18:00에 Archit Taneja 이(가) 쓴 글:
On 07/03/2017 02:12 PM, Inki Dae wrote:
This patch removes unnecessary checking of return value.
Ps. this patch depends on below one,
http://www.spinics.net/lists/dri-devel/msg145687.html
Will thi
On 04.07.2017 18:30, Philippe CORNU wrote:
> This patch adds Orise Tech otm8009a 3.97" 480x800 TFT LCD
> panel driver (MIPI-DSI video mode). The panel backlight is
> managed through the DSI link. This panel driver is used in
> several STM32 boards.
>
> Signed-off-by: Philippe CORNU
> ---
> driver
On 4 July 2017 at 07:40, Chih-Wei Huang wrote:
> 2017-06-12 17:50 GMT+08:00 Michel Dänzer :
>> From: Xiaojie Yuan
>>
>> v2: fix an off by one error and leading white spaces
>> v3: use thread safe strtok_r(); initialize len before calling getline();
>> change printf() to drmMsg(); add initial
On 07/05/2017 05:18 PM, Inki Dae wrote:
This patch moves drm_bridge_add call into probe.
It doesn't need to call drm_bridge_add call every time
bind callback is called.
Changelog v2
- moved drm_bridge_remove call into remove callback.
- corrected description.
Suggested-by: Andrzej Hajda
Revie
On 30 June 2017 at 20:24, Samuel Li wrote:
Commit message should explain why we want this - aka "Will be reused
in radeon with a later commit"
> Change-Id: Iac1c4870253e8b8860a61b7cf175e7a25cc95921
> Signed-off-by: Samuel Li
> ---
> Makefile.sources | 10 +-
> amdgpu/Makefile.am
On Sun, Jul 2, 2017 at 3:40 PM, Laurent Pinchart
wrote:
> On some R-Car SoCs a single VSP can serve multiple DU channels through
> multiple LIF instances in the VSP. The current DT bindings don't support
> specifying that kind of SoC integration scheme. Extend them with a VSP
> channel index.
>
>
On Tue, Jul 4, 2017 at 11:27 PM, Rajendra Nayak wrote:
>
>
> On 07/04/2017 11:21 PM, Rob Clark wrote:
>> The goal here is to support inheriting a display setup by bootloader,
>> although there may also be some non-display related use-cases.
>>
>> Rough idea is to add a flag for clks and power doma
Op 04-07-17 om 17:18 schreef Daniel Vetter:
> We could probably hit this already with our current async fbdev init,
> but it's much easier to hit this with the new deferred fbdev setup
> that I'm working on polishing.
>
> Cc: Maarten Lankhorst
> Reported-by: Maarten Lankhorst
> Signed-off-by: Dan
On Wed, Jul 05, 2017 at 08:48:40AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 7/4/2017 9:26 PM, Ville Syrjälä wrote:
> > On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote:
> >> YCBCR420 modes are supported only on HDMI 2.0 capable sources.
> >> This patch adds a
Regards
Shashank
On 7/5/2017 3:46 PM, Ville Syrjälä wrote:
On Wed, Jul 05, 2017 at 08:48:40AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 7/4/2017 9:26 PM, Ville Syrjälä wrote:
On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote:
YCBCR420 modes are supported only on HD
2017-07-05 17:35 GMT+08:00 Emil Velikov :
> On 4 July 2017 at 07:40, Chih-Wei Huang wrote:
>>
>> Unfortunately this patch breaks Android build
>> since the two macros are not defined.
>>
>> Anyone is working on a fix?
>> If not, I'll try to provide one.
>>
> Please send a patch. I doubt many of th
Hi Samuel,
On 30 June 2017 at 20:25, Samuel Li wrote:
> Change-Id: I24b6624789d1a9dc0fd3a446b0e6f21ed5183ff2
> Signed-off-by: Samuel Li
> ---
> radeon/Makefile.am | 6 +++
> radeon/Makefile.sources | 6 ++-
> radeon/radeon_asic_id.c | 106
>
On 5 July 2017 at 11:44, Chih-Wei Huang wrote:
> 2017-07-05 17:35 GMT+08:00 Emil Velikov :
>> On 4 July 2017 at 07:40, Chih-Wei Huang wrote:
>>>
>>> Unfortunately this patch breaks Android build
>>> since the two macros are not defined.
>>>
>>> Anyone is working on a fix?
>>> If not, I'll try to
On 5 July 2017 at 10:14, Archit Taneja wrote:
>
>
> On 07/05/2017 02:35 PM, Inki Dae wrote:
>>
>>
>>
>> 2017년 07월 05일 18:00에 Archit Taneja 이(가) 쓴 글:
>>>
>>>
>>>
>>> On 07/03/2017 02:12 PM, Inki Dae wrote:
This patch removes unnecessary checking of return value.
Ps. this patch d
https://bugs.freedesktop.org/show_bug.cgi?id=101695
--- Comment #1 from Christoph Haag ---
https://cgit.freedesktop.org/mesa/mesa/commit/?id=156832ee2b22118f29ca93bf1b4cb4de3b329f3e
works for me.
--
You are receiving this mail because:
You are the assignee for the bug.__
Op 04-07-17 om 17:18 schreef Daniel Vetter:
> FB helper code falls back to a 1024x768 mode if no outputs are connected
> or don't report back any modes upon initialization. This can be annoying
> because outputs that are added to FB helper later on can't be used with
> FB helper if they don't suppo
On Wed, Jul 05, 2017 at 03:49:51PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 7/5/2017 3:46 PM, Ville Syrjälä wrote:
> > On Wed, Jul 05, 2017 at 08:48:40AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 7/4/2017 9:26 PM, Ville Syrjälä wrote:
On Wed, Jul 05, 2017 at 11:46:14AM +0300, Laurent Pinchart wrote:
> Hi Ville,
>
> On Tuesday 04 Jul 2017 15:44:02 Ville Syrjälä wrote:
> > On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote:
> > > On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote:
> > >> From: Ville Syrjälä
> >
https://bugs.freedesktop.org/show_bug.cgi?id=100306
--- Comment #31 from MirceaKitsune ---
Created attachment 132448
--> https://bugs.freedesktop.org/attachment.cgi?id=132448&action=edit
Screenshot of "top"
Lots of important new information on this freeze, which was of course ported to
the lat
https://bugs.freedesktop.org/show_bug.cgi?id=101695
Gregor Münch changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=101695
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mai
https://bugzilla.kernel.org/show_bug.cgi?id=196273
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugs.freedesktop.org/show_bug.cgi?id=101685
--- Comment #1 from Sylvain BERTRAND ---
I was wrong, it's worse: linux 4.12 amdgpu and radeon do random crash dota2 the
same way (in libparticles). Both 4.12 modules are _significantly_ faster than
the stable 4.11 radeon while not crashing.
--
https://bugs.freedesktop.org/show_bug.cgi?id=101685
--- Comment #2 from Alex Deucher ---
Is this a regression? If so, did you also change the mesa version you are
using?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri
The last user of these (i915.ko) no longer does. We can slim down the
core GEM object by removing the unused 8 bytes.
Signed-off-by: Chris Wilson
---
include/drm/drm_gem.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 663d
https://bugs.freedesktop.org/show_bug.cgi?id=101596
Matias N. Goldberg changed:
What|Removed |Added
CC||dark_syl...@yahoo.com.ar
--- Comme
This commit adds support for waiting on or signaling DRM syncobjs as
part of execbuf. It does so by hijacking the currently unused cliprects
pointer to instead point to an array of i915_gem_exec_fence structs
which containe a DRM syncobj and a flags parameter which specifies
whether to wait on it
https://bugs.freedesktop.org/show_bug.cgi?id=101685
--- Comment #3 from Sylvain BERTRAND ---
Same mesa binaries from up-to-date "beta" steamos: 17.1.2.
As far as I tested it, I cannot even play one dota2 game without the game
program randomly crashing in dota2 libparticles (radeon or amdgpu).
-
Quoting Jason Ekstrand (2017-07-05 18:21:22)
> This commit adds support for waiting on or signaling DRM syncobjs as
> part of execbuf. It does so by hijacking the currently unused cliprects
> pointer to instead point to an array of i915_gem_exec_fence structs
> which containe a DRM syncobj and a f
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #9 from Sebastian Parborg ---
Thanks for fixing it, the patch seems to work nicely for me too.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel maili
https://bugs.freedesktop.org/show_bug.cgi?id=100306
--- Comment #32 from MirceaKitsune ---
Thought I'd also post another detail that might be useful, I'm not sure how
much it relates to the freeze but better be safe than sorry; I have the
following two environment variables added to my ~/.profile
On Wed, Jul 5, 2017 at 10:37 AM, Chris Wilson
wrote:
> Quoting Jason Ekstrand (2017-07-05 18:21:22)
> > This commit adds support for waiting on or signaling DRM syncobjs as
> > part of execbuf. It does so by hijacking the currently unused cliprects
> > pointer to instead point to an array of i91
Hi Dave,
Fixes for 4.13:
- Various fixes for Raven
- Various fixes for Vega10
- Stability fixes for KIQ
- Fix reloading the driver
- Fix S3 on vega10
- Misc other fixes
The following changes since commit 12d016626f99f48edbf5b006625b4e8c0de1eec7:
Merge tag 'drm-amdkfd-next-2017-06-25' of
git:/
https://bugs.freedesktop.org/show_bug.cgi?id=101319
Andy Furniss changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Quoting Jason Ekstrand (2017-07-05 19:32:21)
> On Wed, Jul 5, 2017 at 10:37 AM, Chris Wilson
> wrote:
>
> Quoting Jason Ekstrand (2017-07-05 18:21:22)
> > This commit adds support for waiting on or signaling DRM syncobjs as
> > part of execbuf. It does so by hijacking the currently
https://bugs.freedesktop.org/show_bug.cgi?id=100577
--- Comment #9 from Andy Furniss ---
Can't reproduce this on current amd-staging-4.11 will keep trying and close
soon if OK.
One nit I notice is I may not be comparing like with like as current and some
older 4.11s I still have around all seem
https://bugs.freedesktop.org/show_bug.cgi?id=100577
--- Comment #10 from Andy Furniss ---
(In reply to Andy Furniss from comment #9)
> One nit I notice is I may not be comparing like with like as current and
> some older 4.11s I still have around all seem to peg memory clock high. 3.7s
Ugh, not
On Wed, Jul 5, 2017 at 11:42 AM, Chris Wilson
wrote:
> Quoting Jason Ekstrand (2017-07-05 19:32:21)
> > On Wed, Jul 5, 2017 at 10:37 AM, Chris Wilson
> wrote:
> >
> > Quoting Jason Ekstrand (2017-07-05 18:21:22)
> > > This commit adds support for waiting on or signaling DRM syncobjs
> as
https://bugs.freedesktop.org/show_bug.cgi?id=100577
--- Comment #11 from Alex Deucher ---
(In reply to Andy Furniss from comment #10)
> Ugh, not 3.7s, I mean amd-staging-4.9s didn't peg memclk high. I don't still
> have all the 4.11s I've ever built so don't know when this started for them.
What
https://bugs.freedesktop.org/show_bug.cgi?id=100577
--- Comment #12 from Andy Furniss ---
Hmm, so I just booted back into current staging to get a dmesg and xrandr and
ended up noticing 2 more issues.
My monitor is 1920x1080 and can do 120Hz but pref and used by default is 60Hz.
Issue 1 - I can
https://bugs.freedesktop.org/show_bug.cgi?id=100577
--- Comment #13 from Andy Furniss ---
Created attachment 132465
--> https://bugs.freedesktop.org/attachment.cgi?id=132465&action=edit
dmesg on current staging memclk is stuck high + some errors
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=100577
--- Comment #14 from Andy Furniss ---
Created attachment 132466
--> https://bugs.freedesktop.org/attachment.cgi?id=132466&action=edit
xrandr --verbose higher clocks missing
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=100577
--- Comment #15 from Andy Furniss ---
It seems the errors in the dmesg are created when I do xrandr --verbose.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel m
the drm_file parameter is unused, so remove it.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 ++
drivers/gpu/drm/drm_syncobj.c | 8 +++-
include/drm/drm_syncobj.h | 3 +--
3 files changed, 6 insertions(+), 11 deletions(
On Wed, Jul 05, 2017 at 12:08:15PM +0200, Maarten Lankhorst wrote:
> Op 04-07-17 om 17:18 schreef Daniel Vetter:
> > We could probably hit this already with our current async fbdev init,
> > but it's much easier to hit this with the new deferred fbdev setup
> > that I'm working on polishing.
> >
>
On Wed, Jul 05, 2017 at 04:49:00PM +0100, Chris Wilson wrote:
> The last user of these (i915.ko) no longer does. We can slim down the
> core GEM object by removing the unused 8 bytes.
>
> Signed-off-by: Chris Wilson
Time to celebrate!
Applied, thanks.
-Daniel
> ---
> include/drm/drm_gem.h | 1
On Wed, Jul 05, 2017 at 10:09:21AM +0200, Peter Rosin wrote:
> On 2017-07-05 08:08, Daniel Vetter wrote:
> > On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote:
> >> Hi!
> >>
> >> While trying to get CLUT support for the atmel_hlcdc driver, and
> >> specifically for the emulated fbdev inte
https://bugs.freedesktop.org/show_bug.cgi?id=100577
--- Comment #16 from Andy Furniss ---
Created attachment 132467
--> https://bugs.freedesktop.org/attachment.cgi?id=132467&action=edit
xrandr --verbose on 4.14-wip showing all modes
This is xrandr on 4.14-wip - the higher modes are shown, thou
https://bugs.freedesktop.org/show_bug.cgi?id=101656
Rafael Antognolli changed:
What|Removed |Added
QA Contact|mesa-dev@lists.freedesktop. |
|org
This commit adds support for waiting on or signaling DRM syncobjs as
part of execbuf. It does so by hijacking the currently unused cliprects
pointer to instead point to an array of i915_gem_exec_fence structs
which containe a DRM syncobj and a flags parameter which specifies
whether to wait on it
On Wed, Jul 5, 2017 at 2:13 PM, Jason Ekstrand wrote:
> This commit adds support for waiting on or signaling DRM syncobjs as
> part of execbuf. It does so by hijacking the currently unused cliprects
> pointer to instead point to an array of i915_gem_exec_fence structs
> which containe a DRM sync
https://bugs.freedesktop.org/show_bug.cgi?id=92715
--- Comment #27 from Armando Antonio ---
The following test fail on IVB with latest configuration
Testlist
igt@gem_reset_stats@reset-count-bsd
igt@gem_reset_stats@reset-count-blt
Graphic Sta
https://bugs.freedesktop.org/show_bug.cgi?id=92715
Armando Antonio changed:
What|Removed |Added
Summary|[IGT] |[IGT]
|[BYT-M/KBL/BS
On Wed, Jul 5, 2017 at 1:12 PM, Chris Wilson
wrote:
> the drm_file parameter is unused, so remove it.
>
> Signed-off-by: Chris Wilson
> Cc: Dave Airlie
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 ++
> drivers/gpu/drm/drm_syncobj.c | 8 +++-
> include/drm/drm_syncobj.h
> - above all, as-is make check will fail
Right, I did not check that.
> - keeping the radeon API symmetrical to the amdgpu one would a good idea
The issue is Radeon does not have a struct similar to amdgpu_device_handle.
I think the current radeon API is simpler. Maybe a follow up change
Place drm_event_vblank in a new union that includes that and a bare
drm_event structure. This will allow new members of that union to be
added in the future without changing code related to the existing vbl
event type.
Assignments to the crtc_id field are now done when the event is
allocated, rath
These provide crtc-id based functions instead of pipe-number, while
also offering higher resolution time (ns) and wider frame count (64)
as required by the Vulkan API.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_internal.h | 6 ++
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/dr
This modifies the datatypes used by the vblank code to provide both 64
bits of vblank count and to increase the resolution of the vblank
timestamp from microseconds to nanoseconds.
The driver interfaces have also been changed to return 64-bits of
vblank count; fortunately all of the code necessary
This patch series provides a new interface which fixes three issues
with the current VBLANK_WAIT ioctl:
1) CRTC indices to select a target.
2) 32-bits of count resolution.
3) Microsecond time resolution.
The first makes it quite difficult to use this interface from a leased
DRM device; without
This allows an application to discover what display resources are
available before requesting a lease from the X server.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_ioctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioc
drm_mode_create_lease
Creates a lease for a list of drm mode objects, returning an
fd for the new drm_master and a 64-bit identifier for the lessee
drm_mode_list_lesees
List the identifiers of the lessees for a master file
drm_mode_get_lease
List the leased obje
This provides new data structures to hold "lease" information about
drm mode setting objects, and provides for creating new drm_masters
which have access to a subset of the available drm resources.
An 'owner' is a drm_master which is not leasing the objects from
another drm_master, and hence 'owns
Here's a third version of my DRM mode object leases series. Since v2:
* Add revocation. This allows leases to be effectively revoked by
removing all of the objects they have access to. The lease itself
hangs around as it's hanging off a file.
* Allow non-master files to lo
This will allow __drm_mode_object_file to be extended to perform
access control checks based on the file in use.
Suggested-by: Daniel Vetter
Signed-off-by: Keith Packard
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16
drivers/gpu/drm/amd/amdgpu/dce_virtual.c
Separate out lease debugging from the core.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_drv.c | 3 ++-
include/drm/drmP.h| 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b5c6bb46a425..b65308a278ca
Attempts to modify un-leased objects are rejected with an error.
Information returned about unleased objects is modified to make them
appear unusable and/or disconnected.
Changes for v2 as suggested by Daniel Vetter :
With the change in the __drm_mode_object_find API to pass the
file_priv along,
Patch pushed to libdrm master.
On Fri, Jun 30, 2017 at 2:28 PM, Rodrigo Vivi wrote:
> No functional change. Just organizing the code
> so it gets clear for future platforms.
>
> Paulo deserves credits becuase he was the one
> that just noticed this IS_9XX was in the wrong position
> after CNL pat
> +/**
> + * Lease mode resources, creating another drm_master.
> + */
> +struct drm_mode_create_lease {
> + /** Pointer to array of object ids (__u32) */
> + __u64 object_ids;
> + /** Number of object ids */
> + __u32 object_count;
> + /** flags for new FD (O_CLOEXEC,
On 2017-07-05 08:21, Daniel Vetter wrote:
> On Tue, Jul 04, 2017 at 12:37:01PM +0200, Peter Rosin wrote:
>> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
>> completely obsolete.
>>
>> Signed-off-by: Peter Rosin
>> ---
>> drivers/gpu/drm/drm_fb_helper.c | 165
>> +++
The driver stores lut values from the fbdev interface, and is able
to give them back, but does not appear to do anything with these
lut values. The generic fb helpers have replaced this function,
and may even have made the driver work for the C8 mode from the
fbdev interface. But that is untested.
On 07/04/2017 11:21 PM, Rob Clark wrote:
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
>
> Rough idea is to add a flag for clks and power domains that might
> already be enabled when kernel starts, and mak
https://bugs.freedesktop.org/show_bug.cgi?id=101596
--- Comment #10 from Michel Dänzer ---
Please send the patch to the mesa-dev mailing list for review.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing li
On 2017-07-05 08:08, Daniel Vetter wrote:
> On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote:
>> Hi!
>>
>> While trying to get CLUT support for the atmel_hlcdc driver, and
>> specifically for the emulated fbdev interface, I received some
>> push-back that my feeble in-driver attempts sho
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 remaining time back
to userspace.
v3: return to absolute timeouts.
v4: absolute
From: Dave Airlie
This adds kernel semaphore support to the command submission
interface in what should be a backwards compatible manner,
it adds a new command submission API.
Signed-off-by: Dave Airlie
---
amdgpu/amdgpu.h| 29 -
amdgpu/amdgpu_cs.c | 118 ++
2017년 07월 05일 00:18에 Daniel Vetter 이(가) 쓴 글:
> From: Thierry Reding
>
> The FB helper core now supports deferred setup, so the driver's custom
> implementation can be removed.
Reviewed-by: Inki Dae
Tested-by: Inki Dae
Thanks,
Inki Dae
>
> v2: Drop NULL check, drm_fb_helper_hotplug_event h
Dave Airlie writes:
> I think this needs a pad ^.
> And this.
Yup. Thanks!
>> +struct drm_mode_revoke_lease {
>> + /** Unique ID of lessee
>> +*/
>> + __u32 lessee_id;
>
> And this.
None of the other bare 32-bit ioctl structures are padded; I think
that's probably fine as
On Wed, Jul 5, 2017 at 7:50 PM, Peter Rosin wrote:
>>> +retry:
>>> +ret = drm_modeset_lock_all_ctx(dev, &ctx);
>>
>> With atomic you don't need to grab locks, this is done behind the scenes
>> (as long as you handle the retry/backoff correctly). See the kerneldoc for
>> the various drm_atomic_
92 matches
Mail list logo
