Hi all,
I see this brand new warning when booting here.
Top commit is v4.10-rc5-107-g883af14e67e8 from Linus' master.
[2.209255] [drm] Initialized
[2.210636] [drm] Memory usable by graphics device = 2048M
[2.210732] [drm] Replacing VGA console driver
[2.211517] Console: switching
Ping?
regards,
dan carpenter
On Wed, Nov 30, 2016 at 10:18:41PM +0300, Dan Carpenter wrote:
> Hello Monk Liu,
>
> The patch 9d8f086cd059: "drm/amdgpu: fix memleak in pptable_init"
> from May 30, 2016, leads to the following static checker warning:
>
> drivers/gpu/drm/amd/amdgpu/../powerpl
This one still needs to be fixed as well.
regards,
dan carpenter
On Tue, Dec 13, 2016 at 01:34:17PM +0300, Dan Carpenter wrote:
> Hello Alex Deucher,
>
> The patch a2e73f56fa62: "drm/amdgpu: Add support for CIK parts" from
> Apr 20, 2015, leads to the following static checker warning:
>
>
What can we do to fix this one?
regards,
dan carpenter
On Wed, Nov 30, 2016 at 10:19:21PM +0300, Dan Carpenter wrote:
> Hello Monk Liu,
>
> The patch 482587e3145e: "drm/amdgpu: impl late_fini for amdgpu_pp_ip"
> from May 19, 2016, leads to the following static checker warning:
>
> drivers
> -Original Message-
> From: Cheng, Tony
> Sent: Monday, January 23, 2017 2:49 PM
> To: Daniel Vetter; Grodzovsky, Andrey
> Cc: Deucher, Alexander; nouv...@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> daniel.vet...@intel.com; dc_upstream
> S
On Wed, Jan 25, 2017 at 01:54:32PM +0100, Daniel Vetter wrote:
> On Wed, Jan 25, 2017 at 06:10:57PM +0900, Michel Dänzer wrote:
> > On 25/01/17 05:33 PM, Markus Trippelsdorf wrote:
> > > On 2017.01.23 at 09:38 +1000, Dave Airlie wrote:
> > >>
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #58 from Vladislav Egorov ---
Correction - in fact I only tested radeon+radeonsi pair. I will try
amdgpu+radeonsi later.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99544
Dmitry Eremin-Solenikov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|N
Hi Sean,
Thanks for reviewing the patches.
On Mon, Jan 23, 2017 at 10:19:01AM -0500, Sean Paul wrote:
> On Fri, Jan 20, 2017 at 12:24:56AM +0800, Shawn Guo wrote:
> > From: Shawn Guo
> >
> > It adds interlace mode support in VOU TIMING_CTRL and channel control
> > block, so that VOU driver gets
https://bugs.freedesktop.org/show_bug.cgi?id=99544
--- Comment #2 from Michel Dänzer ---
Sounds like bug 99333. Make sure your xserver-xorg-core package is version
2:1.19.1-1 or newer.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #57 from Vladislav Egorov ---
Simple way to reproduce the bug - launch the game, then go to "Options" menu
and get multi-second (>5s) freeze.
I've tried to launch Rocket League on several GPUs. Graphics settings were the
same everywh
https://bugs.freedesktop.org/show_bug.cgi?id=99544
Dmitry Eremin-Solenikov changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
Vers
https://bugs.freedesktop.org/show_bug.cgi?id=99544
--- Comment #1 from Dmitry Eremin-Solenikov ---
Created attachment 129156
--> https://bugs.freedesktop.org/attachment.cgi?id=129156&action=edit
VDPAU application backtrace (MPlayer)
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=99544
Bug ID: 99544
Summary: GL and VDPAU hangs on r600 (HD7650M)
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
From: "Y.C. Chen"
The original ast driver will access some BMC configuration through P2A bridge
that can be disabled since AST2300 and after.
It will cause system hanged if P2A bridge is disabled.
Here is the update to fix it.
Signed-off-by: Y.C. Chen
---
drivers/gpu/drm/ast/ast_drv.h | 1 +
https://bugs.freedesktop.org/show_bug.cgi?id=98784
--- Comment #15 from Michel Dänzer ---
Thanks for raising the issue with Croteam.
(In reply to Germano Massullo from comment #14)
> I've just double checked and we definately set GL_DRAW_FRAMEBUFFER to 0
> (default back buffer) before clear.
Wh
https://bugs.freedesktop.org/show_bug.cgi?id=99418
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote:
> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
> >On 01/25/2017 09:21 AM, Michel Dänzer wrote:
> >>From: Michel Dänzer
> >>
> >>The current caching state may not be tt_cached, even though the
> >>placement contains TTM_PL_FLAG_CA
On 01/25/2017 03:35 PM, Arnd Bergmann wrote:
> I ran into a couple of build problems on ARM, these are the changes that
> should be folded into the original patch that changed all the ->fault()
> prototypes
>
> Fixes: mmtom ("mm, fs: reduce fault, page_mkwrite, and pfn_mkwrite to take
> only vmf"
On 01/24/2017 10:21 PM, Daniel Vetter wrote:
> Hi Dave,
>
> Still waiting for your testing results on this one here ...
It's definitely stable with that patch applied. No more crashes.
But, it's also definitely having difficulty re-probing to find the
monitor that's attached to the dock in some
From: Laurent Pinchart
Register live sources for VSPD0 and VSPD1 and configure the plane source
at plane setup time to source frames from memory or from the VSP1.
[Sergei: ported to the modern kernel.]
Signed-off-by: Laurent Pinchart
Signed-off-by: Sergei Shtylyov
---
Changes in version 3:
-
Hello.
Here's the set of 3 patches against the 'drm-next' branch of David Airlie's
'linux.git' repo. This is a port of Laurent's DRM/DU live source patches to the
recent kernel, see [1] for the version 2 of the patchset (including a Laurent's
big blurb :-)). For the patch #3 to work one absolut
From: Laurent Pinchart
Introduce a new live source flag for framebuffers. When a framebuffer is
created with that flag set, a live source is associated with the
framebuffer instead of buffer objects. The framebuffer can then be used
with a plane to connect it with the live source.
[Sergei: porte
On Wed, 2017-01-25 at 06:43 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:30PM -0800, Dhinakaran Pandiyan wrote:
> > The avail_slots member in the MST topology manager is never updated to
> > reflect the available vcpi slots. The check is effectively against
> > total_slots. So, let's
On Wed, 2017-01-25 at 07:18 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:35PM -0800, Dhinakaran Pandiyan wrote:
> > Having a ->atomic_release callback is useful to release shared resources
> > that get allocated in compute_config().
> >
> > Suggested-by: Daniel Vetter
> > Signed-of
From: Laurent Pinchart
Live sources represent a hardware connection between a video stream
source and a CRTC, going through a plane. The kernel API lets driver
register live sources, and the userspace API lets applications enumerate
them.
[Sergei: ported to the modern kernel.]
Signed-off-by: La
On Wed, 2017-01-25 at 07:16 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:36PM -0800, Dhinakaran Pandiyan wrote:
> > Implement the ->atomic_release() callback to release the shared link
> > bandwidth that was originally acquired during compute_config()
> >
> > Signed-off-by: Dhinakar
On Wed, 2017-01-25 at 07:15 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:37PM -0800, Dhinakaran Pandiyan wrote:
> > 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
> > enabled with drm_a
On Wed, 2017-01-25 at 10:31 +1000, Dave Airlie wrote:
> On 25 January 2017 at 09:49, Dhinakaran Pandiyan
> wrote:
> > drm_dp_mst_allocate_vcpi() apart from setting up the vcpi structure,
> > also finds if there are enough slots available. This check is a duplicate
> > of that implemented in drm_dp
On Wed, 2017-01-25 at 06:59 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:32PM -0800, Dhinakaran Pandiyan wrote:
> > 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_atomi
On 01/25/2017 03:53 AM, Alex Williamson wrote:
> Per the ABI specification[1], each mdev_supported_types entry should
> have an available_instances, with an "s", not available_instance.
>
> [1] Documentation/ABI/testing/sysfs-bus-vfio-mdev
>
> Signed-off-by: Alex Williamson
> ---
>
> This shoul
On Wed, Jan 25, 2017 at 7:26 AM, Daniel Vetter wrote:
> Returning 0 for an on-chip gpu doesn't change anything at all.
>
> Cc: Patrik Jakobsson
> Signed-off-by: Daniel Vetter
Acked-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/gma500/psb_drv.c | 6 --
> 1 file changed, 6 deletions(-)
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=99542
Bug ID: 99542
Summary: vdpau logging errors since gallium/radeon: adjust the
rule for using the LINEAR_ALIGNED layout
Product: Mesa
Version: git
Hardware: Other
On 2017-01-25 05:46 PM, Alex Deucher wrote:
> On Wed, Jan 25, 2017 at 1:32 PM, Harry Wentland
> wrote:
>> You mean rebase dal/dc on drm-next with these patches?
>
> This is a core MST fix, so it would be good to get upstream for all drivers.
>
Ignore my previous message. Somehow I though this
On Wed, Jan 25, 2017 at 1:32 PM, Harry Wentland wrote:
> You mean rebase dal/dc on drm-next with these patches?
This is a core MST fix, so it would be good to get upstream for all drivers.
>
> I'll see if I find some time today or tomorrow to do that. We'll
> probably need that anyways for our a
I ran into a couple of build problems on ARM, these are the changes that
should be folded into the original patch that changed all the ->fault()
prototypes
Fixes: mmtom ("mm, fs: reduce fault, page_mkwrite, and pfn_mkwrite to take only
vmf")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/arma
On 2017-01-25 12:59 AM, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:32PM -0800, Dhinakaran Pandiyan wrote:
>> 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
Hi Dave,
Just a few small fixes.
The following changes since commit 932790109f62aa52bdb4bb62aa66653c0b51bc75:
Merge tag 'drm-qemu-20170110' of git://git.kraxel.org/linux into drm-fixes
(2017-01-23 09:25:53 +1000)
are available in the git repository at:
git://people.freedesktop.org/~agd5f/
https://bugs.freedesktop.org/show_bug.cgi?id=87976
Alex Deucher changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi Linus,
One of the connector fixes was missing some prereqs, we have an
alternate driver fix that should work that I'll send tomorrow.
Today is a holiday here so quickly smashing this out.
Dave.
The following changes since commit 932790109f62aa52bdb4bb62aa66653c0b51bc75:
Merge tag 'drm-qem
> So the plan (again with Wolfram's ack) is for all these patches
> including the i2c-designware ones to go upstream through the drm-intel
> tree, to avoid an intermediate state were things don't work.
Yes. I'd just like to pull in an immutable branch into my i2c/for-next
once this series is acce
https://bugs.freedesktop.org/show_bug.cgi?id=97961
Vedran Miletić changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=97917
Vedran Miletić changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99540
Vedran Miletić changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |ved...@miletic.net
|.
https://bugs.freedesktop.org/show_bug.cgi?id=99540
Bug ID: 99540
Summary: Make CP2K OpenCL GPU support work on Clover and
RadeonSI (requires parts of OpenCL 1.2)
Product: Mesa
Version: git
Hardware: Other
OS
https://bugs.freedesktop.org/show_bug.cgi?id=99539
Vedran Miletić changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |ved...@miletic.net
|.
https://bugs.freedesktop.org/show_bug.cgi?id=99539
Bug ID: 99539
Summary: Make LAMMPS GPU support work on Clover and RadeonSI
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=87976
--- Comment #2 from Damien Hilloulin ---
Can be closed now :)
Sorry for just remembering now.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-de
You mean rebase dal/dc on drm-next with these patches?
I'll see if I find some time today or tomorrow to do that. We'll
probably need that anyways for our atomic rework.
Do you still rebase amd-staging on drm-next?
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
looks a few
https://bugs.freedesktop.org/show_bug.cgi?id=99524
--- Comment #3 from wwa <10dma...@gmail.com> ---
Yes, "possible fix" patch fixes the problem, tested with 4.9.5.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
2017-01-25 Daniel Vetter :
> On Wed, Jan 25, 2017 at 10:57:17AM -0200, Gustavo Padovan wrote:
> > Hi Daniel,
> >
> > 2017-01-25 Daniel Vetter :
> >
> > > There was a bit of mix-up between initialization and registering.
> > >
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/
On Wed, Jan 25, 2017 at 09:36:36AM +0100, Maarten Lankhorst wrote:
> Op 25-01-17 om 09:09 schreef Thomas Hellstrom:
> > On 01/25/2017 05:54 AM, Daniel Vetter wrote:
> >> On Tue, Jan 24, 2017 at 01:44:54PM -0800, Matt Roper wrote:
> >>> On Wed, Jan 11, 2017 at 05:15:47PM +0100, Daniel Vetter wrote:
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> No point in documenting these, they only confuse.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
> include/drm/drm_drv.h | 13 -
> 2 files
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> i915, nouveau (ever since merged to upstream) and radeon all lack ums
> support in upstream. No point keeping the ums vgaarb support around.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_irq.c | 2
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> Use the same trick we used for i915 when we still had ums support:
> Just initialize the agp support unconditionally in the driver load
> function.
>
> Unfortunately that means we need to export drm_agp_init again, but I
> think that's a less
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> With that the drm_pci_device_is_agp function becomes trivial, so
> inline that too. And while at it, move the drm_pci_agp_destroy
> declaration into drm-internal.h, since it's not used by drivers.
>
> Cc: Alex Deucher
> Cc: Ben Skeggs
> Sig
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> It's only for a device quirk, and we might as well do that in the load
> callback.
>
> Signed-off-by: Daniel Vetter
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/mga/mga_dma.c | 20 +++-
> drivers/gpu/drm/mga/mga_drv.c |
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #56 from Grazvydas Ignotas ---
Is the async I/O thread doing a lot of memory allocations?
If so, perhaps the malloc implementation is slowed down by having large amount
of small allocs/frees from shader compiles and/or fragmentation
On Wed, Jan 25, 2017 at 1:26 AM, Daniel Vetter wrote:
> The function operates on modes, not CRTCs. Also move it into
> drm_modes.[hc]. Spotted while reviewing CRTC docs.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> drivers/
From: Rob Clark
Perhaps some newer versions of gcc are more clever about this.
drivers/gpu/drm/nouveau/nvkm/subdev/top/gk104.c: In function
'gk104_top_oneinit':
include/linux/device.h:1164:45: error: 'inst' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
#define dev_i
On Wed, Jan 25, 2017 at 12:16 PM, Krzysztof Nowicki
wrote:
> Hi,
>
> On środa, 15 czerwca 2016 14:14:01 CET wrote:
>> On 15 June 2016 at 13:49, Dave Airlie wrote:
>> > Excuse me for top posting.
>> >
>> > So I finally got back to this patch, still don't like it.
>> >
>> > Apart from the doing 3
Hi,
On środa, 15 czerwca 2016 14:14:01 CET wrote:
> On 15 June 2016 at 13:49, Dave Airlie wrote:
> > Excuse me for top posting.
> >
> > So I finally got back to this patch, still don't like it.
> >
> > Apart from the doing 3 things in once which is just annoying, current
> > userspace for tile
https://bugs.freedesktop.org/show_bug.cgi?id=99524
--- Comment #2 from Alex Deucher ---
Created attachment 129145
--> https://bugs.freedesktop.org/attachment.cgi?id=129145&action=edit
possible fix
Does the attached patch help?
--
You are receiving this mail because:
You are the assignee for
https://bugzilla.kernel.org/show_bug.cgi?id=192271
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 from
https://bugs.freedesktop.org/show_bug.cgi?id=99130
--- Comment #21 from Chris Wilson ---
I kept the bug around in case we wanted to dig deeper into what the slowdown
actually was. If it's below the level of care, lets close and move on.
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #55 from Timothee Besset ---
Rocket League uses an async I/O thread to stream in content in the background.
That thread works off of a queue and only does disk reads and decompression (it
doesn't issue any OpenGL calls for instance, t
https://bugs.freedesktop.org/show_bug.cgi?id=99130
--- Comment #20 from Dorota Czaplejewicz
---
I just realized the patch was merged. Should this bug be considered fixed now?
--
You are receiving this mail because:
You are the assignee for the bug.__
On Wed, Jan 25, 2017 at 07:20:45AM -0800, Dave Hansen wrote:
> On 01/24/2017 10:21 PM, Daniel Vetter wrote:
> > Hi Dave,
> >
> > Still waiting for your testing results on this one here ...
>
> It's definitely stable with that patch applied. No more crashes.
>
> But, it's also definitely having
On Wed, Jan 25, 2017 at 02:26:09PM +, Eric Engestrom wrote:
> On Wednesday, 2017-01-25 07:26:57 +0100, Daniel Vetter wrote:
> > After going through all the trouble of splitting out parts from
> > drm_crtc.[hc] and then properly documenting each I've entirely
> > forgotten to show the same TLC f
On Wed, Jan 25, 2017 at 10:57:17AM -0200, Gustavo Padovan wrote:
> Hi Daniel,
>
> 2017-01-25 Daniel Vetter :
>
> > There was a bit of mix-up between initialization and registering.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_connector.c | 9 -
> > 1 file change
On Tue, Jan 24, 2017 at 09:20:49PM -0800, Ben Widawsky wrote:
> Originally based off of a patch by Kristian.
>
> This new ioctl extends DRM_IOCTL_MODE_GETPLANE, by returning information
> about the modifiers that will work with each format.
>
> It's modified from Kristian's patch in that the modi
On Wed, Jan 25, 2017 at 10:55:21AM -0200, Gustavo Padovan wrote:
> Otherwise looks good:
Fixed up all and applied
> Reviewed-by: Gustavo Padovan
and thanks for your review.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
__
On Wed, Jan 25, 2017 at 10:48:53AM -0200, Gustavo Padovan wrote:
> Otherwise looks good to me:
Nice catches, fixed them all and applied it.
>
> Rewiewed-by: Gustavo Padovan
Thanks for your review.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
__
https://bugs.freedesktop.org/show_bug.cgi?id=99130
--- Comment #19 from Dorota Czaplejewicz
---
Should this be turned into a patch for igt or should I try to identify the
underlying issue causing the slowness?
--
You are receiving this mail because:
You are the assignee for the bug.___
Thanks.
Reviewed-by: Rex Zhu
Best Regards
Rex
From: Colin King
Sent: Wednesday, January 25, 2017 8:07 PM
To: Deucher, Alexander; Koenig, Christian; David Airlie; Wang, Ken; Daenzer,
Michel; Zhu, Rex; amd-...@lists.freedesktop.org; dri-devel@lists.freedeskto
On Wed, Jan 25, 2017 at 7:07 AM, Colin King wrote:
> From: Colin Ian King
>
> _SMU7_CLOCK_POWER_GATING_H_ is being used as a header guard, followed by
> a #define of a different macro. Define _SMU7_CLOCK_POWER_GATING_H_ instead
> to fix this.
>
> Signed-off-by: Colin Ian King
Thanks for the pa
On Wednesday, 2017-01-25 07:26:57 +0100, Daniel Vetter wrote:
> After going through all the trouble of splitting out parts from
> drm_crtc.[hc] and then properly documenting each I've entirely
> forgotten to show the same TLC for CRTCs themselves!
>
> Let's make amends asap.
>
> Signed-off-by: Da
On Mon, Jan 23, 2017 at 10:15:16AM +0100, Andrzej Hajda wrote:
> On 20.01.2017 14:55, Ville Syrjälä wrote:
> > On Fri, Jan 20, 2017 at 07:52:24AM +0100, Andrzej Hajda wrote:
> >> In case of interlace mode irq is generated for odd and even fields, but
> >> vblank should be signaled only for the last
On Wednesday, 2017-01-25 07:26:45 +0100, Daniel Vetter wrote:
> I just learned that &struct_name.member_name works and looks pretty
> even. It doesn't (yet) link to the member directly though, which would
> be really good for big structures or vfunc tables (where the
> per-member kerneldoc tends to
Hi Daniel,
2017-01-25 Daniel Vetter :
> Returning 0 for an on-chip gpu doesn't change anything at all.
>
> Cc: Patrik Jakobsson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/gma500/psb_drv.c | 6 --
> 1 file changed, 6 deletions(-)
Reviewed-by: Gustavo Padovan
Hi Daniel,
2017-01-25 Daniel Vetter :
> There was a bit of mix-up between initialization and registering.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_connector.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c
Hi Daniel,
2017-01-25 Daniel Vetter :
> I just learned that &struct_name.member_name works and looks pretty
> even. It doesn't (yet) link to the member directly though, which would
> be really good for big structures or vfunc tables (where the
> per-member kerneldoc tends to be long).
>
> Also s
On Wed, Jan 25, 2017 at 06:10:57PM +0900, Michel Dänzer wrote:
> On 25/01/17 05:33 PM, Markus Trippelsdorf wrote:
> > On 2017.01.23 at 09:38 +1000, Dave Airlie wrote:
> >>
> >> Alex Deucher (8):
> >> drm/radeon/si: load special
Hi Daniel,
2017-01-25 Daniel Vetter :
> I just learned that &struct_name.member_name works and looks pretty
> even. It doesn't (yet) link to the member directly though, which would
> be really good for big structures or vfunc tables (where the
> per-member kerneldoc tends to be long).
>
> Also s
Hi Daniel,
2017-01-25 Daniel Vetter :
> I just learned that &struct_name.member_name works and looks pretty
> even. It doesn't (yet) link to the member directly though, which would
> be really good for big structures or vfunc tables (where the
> per-member kerneldoc tends to be long).
>
> Also s
On Wed, Jan 25, 2017 at 10:10:44AM +, Chris Wilson wrote:
> drivers/gpu/drm/sti/sti_plane.c:76:33: error: ‘struct drm_framebuffer’
> has no member named ‘pixel_format’; did you mean ‘format’?
>
> I didn't look to hard at the casting to a char * and just did a
> mechanical transformation of s/p
On Wed, Jan 25, 2017 at 03:03:42PM +0530, Archit Taneja wrote:
>
>
> On 01/25/2017 11:56 AM, Daniel Vetter wrote:
> > I just learned that &struct_name.member_name works and looks pretty
> > even. It doesn't (yet) link to the member directly though, which would
> > be really good for big structure
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #26 from lei.p...@gmail.com ---
(In reply to Michel Dänzer from comment #25)
> So maybe it actually depends on whether mutter uses DRI3 or DRI2? You can
> test this by enabling DRI3 on the server side but (re-)starting mutter with
>
>
On Wed, Jan 25, 2017 at 10:10:44AM +, Chris Wilson wrote:
> drivers/gpu/drm/sti/sti_plane.c:76:33: error: ‘struct drm_framebuffer’
> has no member named ‘pixel_format’; did you mean ‘format’?
>
> I didn't look to hard at the casting to a char * and just did a
> mechanical transformation of s/p
From: Colin Ian King
_SMU7_CLOCK_POWER_GATING_H_ is being used as a header guard, followed by
a #define of a different macro. Define _SMU7_CLOCK_POWER_GATING_H_ instead
to fix this.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.h | 2 +-
1 file ch
https://bugs.freedesktop.org/show_bug.cgi?id=99524
--- Comment #1 from Peter Bowey ---
I also have this problem:
Kernel 4.9.5 and 4.9.4 both fail on restart or shutdown (same symptoms).
Kernel 4.8.16 and earlier are OK.
Video card:
Advanced Micro Devices, Inc. [AMD/ATI] Redwood XT GL [FirePro
On Wed, Jan 25, 2017 at 9:30 AM, Lucas Stach wrote:
> Kernel 4.10 just moves the fence attach to the plane state. It has
> nothing to do with the used commit function. The issue going away if you
> change that on kernel 4.9 is a red herring.
>
> In any case, can you try the attached patch? It's a
Am Mittwoch, den 25.01.2017, 09:20 -0200 schrieb Fabio Estevam:
> Hi Lucas,
>
> On Wed, Jan 25, 2017 at 8:43 AM, Lucas Stach wrote:
>
> > This only fixes the issue, as with this change we never attach fences to
> > the plane state. I've looked into this issue a bit and if I'm not
> > mistaken, t
This was somehow lost between v3 and the merged version in Maarten's
patch merged as:
commit f2d580b9a8149735cbc4b59c4a8df60173658140
Author: Maarten Lankhorst
Date: Wed May 4 14:38:26 2016 +0200
drm/core: Do not preserve framebuffer on rmfb, v4.
This introduces a slight behavioral change
Hi Lucas,
On Wed, Jan 25, 2017 at 8:43 AM, Lucas Stach wrote:
> This only fixes the issue, as with this change we never attach fences to
> the plane state. I've looked into this issue a bit and if I'm not
> mistaken, this should still be reproducible with 4.10-rc. Correct?
I could not reproduce
Hi Chris,
Thank for the patch.
Acked-by: Vincent Abriou
Vincent
On 01/25/2017 11:10 AM, Chris Wilson wrote:
> drivers/gpu/drm/sti/sti_plane.c:76:33: error: ‘struct drm_framebuffer’
> has no member named ‘pixel_format’; did you mean ‘format’?
>
> I didn't look to hard at the casting to a char *
Am Sonntag, den 22.01.2017, 23:10 -0200 schrieb Fabio Estevam:
> On Sun, Jan 22, 2017 at 12:26 PM, Fabio Estevam wrote:
> > On Sat, Jan 21, 2017 at 2:40 PM, Fabio Estevam wrote:
> >> Hi,
> >>
> >> Stopping kmscube application on mx6q through CTRL + C sometimes leads
> >> to the following kernel w
https://bugs.freedesktop.org/show_bug.cgi?id=98784
--- Comment #14 from Germano Massullo ---
With the permission of Dean Sekulic of Croteam, I attach here his replies to my
e-mail message:
===
I've just double checked and we definately set GL_DRAW_FRAMEBUFFER to 0
(default back buffe
drivers/gpu/drm/sti/sti_plane.c:76:33: error: ‘struct drm_framebuffer’
has no member named ‘pixel_format’; did you mean ‘format’?
I didn't look to hard at the casting to a char * and just did a
mechanical transformation of s/pixel_format/format->format/ as given in
commit 438b74a5497c ("drm: Nuke
Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
On 01/25/2017 09:21 AM, Michel Dänzer wrote:
From: Michel Dänzer
The current caching state may not be tt_cached, even though the
placement contains TTM_PL_FLAG_CACHED, because placement can contain
multiple caching flags. Trying to swap out such
1 - 100 of 110 matches
Mail list logo
