ia your tree? I'm fine either ways, but
> > perhaps drm-misc would be a bit neater.
> >
>
> Either way works for me. Whatever is easier for you.
>
Thanks, will take these and Christian's patches through the drm-misc tree,
hopefully today. (returning from LPC and just landed at my home city, 4am
here, but will hope to push these today! )
> Alex
Best,
Sumit.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/0b3ce2ec/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 27103 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/ef204d48/attachment-0001.gz>
2016-11-07 Christian König :
> Am 07.11.2016 um 02:10 schrieb Gustavo Padovan:
> > Hi Alex,
> >
> > 2016-11-04 Alex Deucher :
> >
> > > From: Junwei Zhang
> > >
> > > v2: agd: rebase and squash in all the previous optimizations and
> > > changes so everything compiles.
> > > v3: squash in Sla
Hi Russell
> > > This is wrong. If platform is NULL, PTR_ERR() will return zero, which
> > > will be interpreted as success. Please, avoid using IS_ERR_OR_NULL(),
> > > it leads to exactly this kind of cockup - and it's unnecessary here
> > > because platform_device_register_full() does not ret
2016-11-07 Alex Deucher :
> From: Christian König
>
> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
>
> Otherwise signaling might never be activated on the fences. This can
> result in infinite waiting with hardware which has unreliable interrupts.
>
> v2: still return one whe
External clients which import our bo's wait only
for exclusive dmabuf-fences, not on shared ones,
ditto for bo's which we import from external
providers and write to.
Therefore attach exclusive fences on prime shared buffers
if our exported buffer gets imported by an external
client, or if we impo
From: Kuninori Morimoto
Current dw-hdmi is supporting sound via AHB bus, but it has
I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
This HDMI I2S is supported by using ALSA SoC common HDMI encoder
driver.
Tested-by: Jose Abreu
Signed-off-by: Kuninori Morimoto
---
v3 -> v4
ving this mail because:
>
>- You are on the CC list for the bug.
>
>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/ec4b5e0c/attachment.html>
Hi all,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the tip tree got a conflict in:
drivers/gpu/drm/i915/i915_gem_shrinker.c
between commits:
1233e2db199d ("drm/i915: Move object backing storage manipulation to its own
On 23.08.2016 07:57, Daniel Vetter wrote:
> On Mon, Aug 22, 2016 at 11:17:34PM +0100, Jamie Lentin wrote:
>> Lift configuration command from udlfb. This appears to be essential for
>> at least a Rextron VCUD-60, without which no URB communication occurs.
>>
>> Signed-off-by: Jamie Lentin
>> ---
>>
From: Dave Airlie
Thou shall not send control msg from the stack,
does that mean I can send it from the RO memory area?
Reported-by: poma
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ud
> [drm:udl_driver_load [udl]] *ERROR* Selecting channel failed
> udl 1-2:1.0: fb1: udldrmfb frame buffer device
> [drm] Initialized udl on minor 1
> usbcore: registered new interface driver udl
>
>
> Is this expected WARN?
I've just posted a patch in theory to fix it, please test if oyu have time.
From: Dave Airlie
Thou shall not send control msg from the stack,
does that mean I can send it from the RO memory area?
and it looks like the answer is no, so here's
v2 which kmemdups.
Reported-by: poma
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_main.c | 16 +++-
1 fil
On 8 November 2016 at 16:40, Dave Airlie wrote:
>> [drm:udl_driver_load [udl]] *ERROR* Selecting channel failed
>> udl 1-2:1.0: fb1: udldrmfb frame buffer device
>> [drm] Initialized udl on minor 1
>> usbcore: registered new interface driver udl
>>
>>
>> Is this expected WARN?
>
> I've just posted
From: Gustavo Padovan
Hi,
This is yet another version of the DRM fences patches. Please refer
to the cover letter[1] in a previous version to check for more details.
In v7 we now have split most of the out_fences code into
prepare_crtc_signaling() and unprepare_crtc_signaling() with improved er
From: Gustavo Padovan
There is now a new property called IN_FENCE_FD attached to every plane
state that receives sync_file fds from userspace via the atomic commit
IOCTL.
The fd is then translated to a fence (that may be a fence_array
subclass or just a normal fence) and then used by DRM to fenc
From: Gustavo Padovan
Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init()
From: Gustavo Padovan
Support DRM out-fences by creating a sync_file with a fence for each CRTC
that sets the OUT_FENCE_PTR property.
We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
the sync_file fd back to userspace.
The sync_file and fd are allocated/created before com
On 07/11/16 11:25 PM, Bridgman, John wrote:
>> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>> Of Michel Dänzer
>> Sent: Monday, November 07, 2016 2:24 AM
>> On 07/11/16 03:56 AM, Sandeep wrote:
>>>
>>> I was wondering when DRM_AMDGPU_CIK would be turned on by defa
On 08.11.2016 07:39, Dave Airlie wrote:
> From: Dave Airlie
>
> Thou shall not send control msg from the stack,
> does that mean I can send it from the RO memory area?
>
> Reported-by: poma
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/udl/udl_main.c | 8
> 1 file changed, 4 in
Am 08.11.2016 um 04:15 schrieb Mario Kleiner:
> External clients which import our bo's wait only
> for exclusive dmabuf-fences, not on shared ones,
> ditto for bo's which we import from external
> providers and write to.
>
> Therefore attach exclusive fences on prime shared buffers
> if our exporte
Add FB modifiers to allow user-space to specify that a surface is in one
of the two tiling formats supported by Tegra chips, and add support in
the tegradrm driver to handle them properly. This is necessary for the
display controller to directly display buffers generated by the GPU.
This feature i
Am 08.11.2016 um 06:49 schrieb Ravikant Bijendra Sharma:
> From: Ravikant B Sharma
>
> Replace direct comparisons to NULL i.e.
> 'x == NULL' with '!x'. As per coding standard.
>
> Signed-off-by: Ravikant B Sharma
Please stop CCing random people who contributed to the driver in the
past on somet
lt;https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/5eace3d2/attachment.html>
On 08.11.2016 07:47, Dave Airlie wrote:
> From: Dave Airlie
>
> Thou shall not send control msg from the stack,
> does that mean I can send it from the RO memory area?
>
> and it looks like the answer is no, so here's
> v2 which kmemdups.
>
> Reported-by: poma
> Signed-off-by: Dave Airlie
> --
On Thu, Nov 03, 2016 at 02:52:00PM -0400, Rob Clark wrote:
> On Sun, Aug 14, 2016 at 8:02 PM, Eric Engestrom wrote:
> > Signed-off-by: Eric Engestrom
> > ---
> >
> > I moved the main bits to be the first diffs, shouldn't affect anything
> > when applying the patch, but I wanted to ask:
> > I don'
On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote:
> Op 01-11-16 om 14:09 schreef Ville Syrjälä:
> > On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote:
> >> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
> >> replace the old for_each_xxx_in_st
On Thu, Nov 03, 2016 at 05:32:42PM +0200, Ville Syrjälä wrote:
> On Mon, Oct 17, 2016 at 02:37:04PM +0200, Maarten Lankhorst wrote:
> > This kills another dereference of connector->state. connector_mask
> > holds all unchanged connectors at least and any changed connectors
> > are already in stat
On Thu, Nov 03, 2016 at 06:22:05PM +0200, Ville Syrjälä wrote:
> This thing could use a commit message I think. Could at least lay out
> the basic rules on the foo->state/foo_state vs. old_state/new_state
> replacements. Might help someone understand it who doesn't know so much
> about the curren
On Tue, Oct 18, 2016 at 10:29:38AM +0200, Maxime Ripard wrote:
> Create overscan profiles reducing the displayed zone.
>
> For each TV standard (PAL and NTSC so far), we create 4 more reduced modes
> by steps of 5% that the user will be able to select.
>
> Signed-off-by: Maxime Ripard
tbh I thi
On Tue, Nov 8, 2016 at 8:50 AM, Alexandre Courbot
wrote:
> Add FB modifiers to allow user-space to specify that a surface is in one
> of the two tiling formats supported by Tegra chips, and add support in
> the tegradrm driver to handle them properly. This is necessary for the
> display controlle
They are not used outside of their respective source file
Signed-off-by: Christophe Fergeau
Acked-by: Frediano Ziglio
---
drivers/gpu/drm/qxl/qxl_cmd.c | 2 +-
drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
3 files changed, 3 insertions(+), 6 deletion
It's always returning 0, and it's always ignored.
Signed-off-by: Christophe Fergeau
Acked-by: Frediano Ziglio
---
drivers/gpu/drm/qxl/qxl_drv.h | 2 +-
drivers/gpu/drm/qxl/qxl_gem.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/g
qxl_crtc_set_from_monitors_config() is defined in qxl_drv.h but never
implemented.
Signed-off-by: Christophe Fergeau
Acked-by: Frediano Ziglio
---
drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
in
The use of drm_cvt_mode() in qxl_add_monitors_config_modes() means that
the resolutions we are going to present to user-space are going to be
rounded down to a multiple of 8. In the QXL arbitrary resolution case,
this is not useful.
This commit forces the actual width/height that was requested by t
The message has to be terminated by a newline as it's not going to get
added automatically.
Signed-off-by: Christophe Fergeau
Acked-by: Frediano Ziglio
---
drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu
qdev->gem.objects was initialized directly in qxl_device_init() rather
than going through qxl_gem_init(), and qxl_gem_fini() was never called.
Signed-off-by: Christophe Fergeau
---
drivers/gpu/drm/qxl/qxl_kms.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
When the QXL driver receives a QXL_INTERRUPT_CLIENT_MONITORS_CONFIG interrupt,
we currently always notify userspace that there was some hotplug event.
However, gnome-shell/mutter is reacting to this event by attempting a
resolution change, which it does by issueing drmModeRmFB, drmModeAddFB,
and t
Hey,
Here is what should hopefully be the final version of this series, only change
since v3 is that I made sure to keep "PATCH" in the subject line, and I added
missing Acked-by/Signed-of-by annotations to the logs.
Christophe
On Mon, Oct 31, 2016 at 12:09:23AM +, Russell King - ARM Linux wrote:
> On Mon, Oct 24, 2016 at 08:53:04AM +0200, Daniel Vetter wrote:
> > On Mon, Oct 24, 2016 at 11:58:00AM +0530, Archit Taneja wrote:
> > > On 10/22/2016 03:25 PM, Russell King - ARM Linux wrote:
> > > > Looking at drm_bridge_d
On 11/08/2016 06:07 PM, Erik Faye-Lund wrote:
> On Tue, Nov 8, 2016 at 8:50 AM, Alexandre Courbot
> wrote:
>> Add FB modifiers to allow user-space to specify that a surface is in one
>> of the two tiling formats supported by Tegra chips, and add support in
>> the tegradrm driver to handle them pr
On Mon, Oct 31, 2016 at 08:58:43AM +, Russell King - ARM Linux wrote:
> On Mon, Oct 24, 2016 at 10:24:42PM +0200, Daniel Vetter wrote:
> > On Mon, Oct 24, 2016 at 4:52 PM, Brian Starkey
> > wrote:
> > >>
> > >>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> > >>> b/drivers/gpu/drm/i2c/tda9
On Mon, Nov 07, 2016 at 12:55:30PM -0500, Alex Deucher wrote:
> On Sun, Nov 6, 2016 at 8:07 PM, Gustavo Padovan
> wrote:
> > Hi Christian,
> >
> > 2016-10-20 Christian König :
> >
> >> From: Christian König
> >>
> >> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
> >>
> >> Other
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/7b3e1c20/attachment.html>
On Mon, Oct 31, 2016 at 09:08:06AM +, Chris Wilson wrote:
> We can use the kernel's stack tracer and depot to record the allocation
> site of every drm_mm user. Then on shutdown, as well as warning that
> allocated nodes still reside with the drm_mm range manager, we can
> display who allocated
On Sat, Oct 29, 2016 at 07:42:14PM +0100, Chris Wilson wrote:
> A frequent issue that arises on shutdown is the drm_mm range manager
> complaining of a leak. To aide debugging those, drm can now track the
> allocation callsite and print those for the leaks.
>
> Signed-off-by: Chris Wilson
Makes
On Mon, Oct 31, 2016 at 07:59:56PM +0800, Rongrong Zou wrote:
> Add obvious description to drm_framebuffer_unregister_private()
> to explain it is deprecated.
>
> Signed-off-by: Rongrong Zou
> ---
> drivers/gpu/drm/drm_framebuffer.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/
On Mon, Oct 31, 2016 at 10:36:46AM -0700, Stefan Agner wrote:
> The kernel-doc references drm_atomic_commit_planes() which does not
> exist. The functions name is drm_atomic_helper_commit_planes().
>
> Signed-off-by: Stefan Agner
Thanks a lot for fixing this, applied to drm-misc.
-Daniel
> ---
> When the QXL driver receives a QXL_INTERRUPT_CLIENT_MONITORS_CONFIG
> interrupt,
> we currently always notify userspace that there was some hotplug event.
>
> However, gnome-shell/mutter is reacting to this event by attempting a
> resolution change, which it does by issueing drmModeRmFB, drmMod
On Tue, Nov 01, 2016 at 11:49:45AM +0800, Jiang Biao wrote:
> psb_gtt_remove is only used in this file, and make it static to
> eliminate missing-prototypes compiling warning.
>
> Signed-off-by: Jiang Biao
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/gma500/gtt.c | 2 +-
> 1 f
On Wed, Nov 02, 2016 at 10:27:44AM -0400, Rob Clark wrote:
> drm-hwc + android tries to create an fb for the wallpaper layer, which
> is larger than the screen resolution, and potentially larger than
> mode_config->max_{width,height}. But the plane src_w/src_h is within
> the max limits, so it is
On Fri, Nov 04, 2016 at 05:58:55PM -0400, Theodore Ts'o wrote:
> On Fri, Nov 04, 2016 at 01:38:25PM -0700, Linus Torvalds wrote:
> > On Wed, Nov 2, 2016 at 5:31 PM, Dave Airlie wrote:
> > >
> > > There are a set of fixes for an oops we've been seeing around MST
> > > display unplug,
> >
> > Side
On Fri, Nov 04, 2016 at 08:29:11AM +0100, Andrzej Hajda wrote:
> On 03.11.2016 13:53, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > All the VICs apart from 58 and 59 have the word "Hz" included in the
> > comment. Include it for 59 and 59 as well.
> >
> > Cc: Shashank S
On Thu, Nov 03, 2016 at 04:10:01PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Existing userspace expected the mode flags to match the xrandr
> definitions 1:1, and even adding new flags in he previously unused
> bits is likely to break existing userspace. Add a co
Am 07.11.2016 um 20:20 schrieb Mario Kleiner:
> On 11/07/2016 08:55 AM, Christian König wrote:
>> Am 07.11.2016 um 04:29 schrieb Michel Dänzer:
>> Also, I think we should set bo->prime_exported (prime_shared?) in
>> amdgpu_gem_prime_import_sg_table as well, so that we'll also set
>> exclusive fen
On Mon, Nov 07, 2016 at 07:38:25PM +0200, Jani Nikula wrote:
> On Mon, 07 Nov 2016, Eric Engestrom wrote:
> > On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote:
> >> On Mon, 07 Nov 2016, Eric Engestrom wrote:
> >> > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
> >> >
> >> > drm: make
On Sat, Nov 05, 2016 at 10:52:01AM -0400, Rob Clark wrote:
> It is kind of a pointless restriction. If userspace does silly things
> like using crtcA's cursor plane on crtcB, and then setcursor on crtcA,
> it will end up with the overlay disabled on crtcB. But userspace is
> allowed to shoot itse
On Mon, Nov 07, 2016 at 07:03:33PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Some of the members of struct drm_plane had extra comments so for these
> add inline kernel comment to consolidate all documentation in one place.
>
> Signed-off-by: Gustavo Padovan
For in-line kerneld
On Tue, Nov 08, 2016 at 04:50:42PM +0900, Alexandre Courbot wrote:
> Add FB modifiers to allow user-space to specify that a surface is in one
> of the two tiling formats supported by Tegra chips, and add support in
> the tegradrm driver to handle them properly. This is necessary for the
> display c
On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> This is yet another version of the DRM fences patches. Please refer
> to the cover letter[1] in a previous version to check for more details.
Explicit fencing is not a superset of the implicit f
On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> FIXME: Add owner of second tree to To:
>Add author(s)/SOB of conflicting commits.
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_gem_shrinker.c
>
> between co
lt;https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/9e61cd6c/attachment.html>
On Mon, 7 Nov 2016 21:05:05 +0100
Maxime Ripard wrote:
> Hi,
>
> On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > On Sun, 23 Oct 2016 09:33:16 +0800
> > Chen-Yu Tsai wrote:
> >
> > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine
> > > wrote:
> > > > This patch
On Tue, Nov 08, 2016 at 03:54:48PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> There is now a new property called IN_FENCE_FD attached to every plane
> state that receives sync_file fds from userspace via the atomic commit
> IOCTL.
>
> The fd is then translated to a fence (that may
On 1 November 2016 at 18:47, Mauro Santos wrote:
> On 01-11-2016 18:13, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> Parsing config sysfs file wakes up the device. The latter of which may
>> be slow and isn't required to begin with.
>>
>> Reading through config is/was required since the revisi
[Dropping Jammy since his email bounces]
On 1 November 2016 at 15:47, Alex Deucher wrote:
> On Tue, Nov 1, 2016 at 11:42 AM, Emil Velikov
> wrote:
>> From: Emil Velikov
>>
>> Currently the revision isn't available via sysfs/libudev thus if one
>> wants to know the value they need to read throu
On Tue, Nov 08, 2016 at 10:59:43AM +, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 10:25:52AM +0100, Daniel Vetter wrote:
> > Hm, I entirely missed that part of the troubles. Anyway, if you all agree
> > on a patch I certainly won't block it, feel free to merge through suitable
> >
t value.
That could still break existing use-cases, but it would at least allow
basic hand-over.
Also, if leaving the GPIO configured as-is causes glitches or other
issues, then these are observable with the current code as well, until
the panel driver takes over and disables everything.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/e0f3dae7/attachment.sig>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/47509cee/attachment.html>
On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Hi,
> >
> > This is yet another version of the DRM fences patches. Please refer
> > to the cover letter[1] in a previous version to c
n-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 33705 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/953192f4/attachment-0001.gz>
On 03.11.2016 13:53, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> CEA-861 specifies that the vertical front porch may vary by one or two
> lines for specific VICs. Up to now we've only considered a mode to match
> the VIC if it matched the shortest possible vertical front po
On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> > On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Hi,
> > >
> > > This is yet another version of the DRM fence
ROR("OA exponent would exceed the
> max sampling frequency (sysctl dev.i915.oa_max_sample_rate) %uHz without
> root privileges\n",
> > + i915_oa_max_sample_rate);
> > return -EACCES;
> > }
> >
> > @@ -1481,6 +1511,15 @@ static struct ctl_table oa_table[] = {
> >.extra1 = &zero,
> >.extra2 = &one,
> >},
> > + {
> > + .procname = "oa_max_sample_rate",
> > + .data = &i915_oa_max_sample_rate,
> > + .maxlen = sizeof(i915_oa_max_sample_rate),
> > + .mode = 0644,
> > + .proc_handler = proc_dointvec_minmax,
> > + .extra1 = &zero,
> > + .extra2 = &oa_sample_rate_hard_limit,
> > + },
> > {}
> > };
> >
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/367f6684/attachment-0001.html>
0day found that stackdepot.h doesn't get automatically included on all
architectures, so remember to add our #include.
Reported-by: kbuild test robot
Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/dr
Hi Dave,
Here is the list of fixes that I have for drm/mali-dp. They've been on the
mailing
lists for a while and merged into linux-next for a few weeks, but due to
holiday and
travel to Linux Plumbers I did not send the pull request earlier. I don't know
if
these patches can be pulled into v4.
On Tue, Nov 08, 2016 at 11:45:51AM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> > > On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> > > > From: Gustavo Padovan
> >
Am 08.11.2016 um 12:45 schrieb Chris Wilson:
> On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
>> On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
>>> On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
From: Gustavo Padovan
Hi,
Thi
Am 08.11.2016 um 12:56 schrieb Chris Wilson:
> 0day found that stackdepot.h doesn't get automatically included on all
> architectures, so remember to add our #include.
>
> Reported-by: kbuild test robot
> Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on
> shutdown")
> Signed-o
On Tue, Nov 08, 2016 at 11:56:01AM +, Chris Wilson wrote:
> 0day found that stackdepot.h doesn't get automatically included on all
> architectures, so remember to add our #include.
>
> Reported-by: kbuild test robot
> Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on
> shu
On Tue, Nov 08, 2016 at 12:26:19PM +, Liviu Dudau wrote:
> Hi Dave,
>
> Here is the list of fixes that I have for drm/mali-dp. They've been on the
> mailing
> lists for a while and merged into linux-next for a few weeks, but due to
> holiday and
> travel to Linux Plumbers I did not send the
This v2 patch bumps the command parser version so it can be referenced in
corresponding i-g-t gem_exec_parse changes.
--- >8 ---
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mes
On Tue, Nov 08, 2016 at 01:44:34PM +0100, Christian König wrote:
> Am 08.11.2016 um 12:45 schrieb Chris Wilson:
> > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> > > > On Tue, Nov 08, 2016 at 03:54:47PM +0900, G
On Tue, Nov 08, 2016 at 01:43:40PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 11:45:51AM +, Chris Wilson wrote:
> > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> > > > On Tue, Nov 08, 2016 at 03:54
The only user was i915, which is now gone.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
Acked-by: Dave Airlie #irc
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 26 --
include/drm/drm_edid.h | 1 -
2 files changed, 27 dele
On Tue, Nov 08, 2016 at 12:43:55PM +0100, Andrzej Hajda wrote:
> On 03.11.2016 13:53, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > CEA-861 specifies that the vertical front porch may vary by one or two
> > lines for specific VICs. Up to now we've only considered a mode
On Tue, Nov 08, 2016 at 01:46:15PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 11:56:01AM +, Chris Wilson wrote:
> > 0day found that stackdepot.h doesn't get automatically included on all
> > architectures, so remember to add our #include.
> >
> > Reported-by: kbuild test robot
> >
On Tue, Nov 08, 2016 at 03:54:50PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Support DRM out-fences by creating a sync_file with a fence for each CRTC
> that sets the OUT_FENCE_PTR property.
>
> We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
> the sync_fi
On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> This is yet another version of the DRM fences patches. Please refer
> to the cover letter[1] in a previous version to check for more details.
>
> In v7 we now have split most of the out_fences c
DRM_DEBUG_MM is only valid if the DRM.ko is builtin as currently
depot_save_stack is not exported.
Fixes: 5c7fcf2db027 ("drm/i915: Enable drm_mm debug when enabling
DRM_I915_DEBUG")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 2 +-
1 file changed, 1 insertion(+), 1 dele
I misread the kbuild result thinking that we had missed the include
(which we had for completeness anyway), what kbuild was actually warning
me about was that depot_save_stack was not exported.
Temporarily fix this by only selecting STACKDEPOT iff drm.ko is builtin
Reported-by: kbuild test robot
Hi Russell,
On 08/11/16 12:24, Russell King - ARM Linux wrote:
> As no one responded to the previous round, I'm not spending soo much
> time writing up a description of these changes again. It's also been
> quite a long time, so I've forgotten all the details of the changes,
> so I'll do my best.
bug.
>
>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/337c2123/attachment.html>
r
>> hours without blanking.
>>
>> --
>> You are receiving this mail because:
>>
>>- You are on the CC list for the bug.
>>
>>
--
You are receiving this mail because:
You are the assignee for the bug.
------ n
On Tue, Nov 08, 2016 at 01:49:55PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 12:26:19PM +, Liviu Dudau wrote:
> > Hi Dave,
> >
> > Here is the list of fixes that I have for drm/mali-dp. They've been on the
> > mailing
> > lists for a while and merged into linux-next for a few week
It's possible for CVAL to get set whilst we are in config mode. If this
happens, afer we leave config mode the HW will latch whatever
configuration is in the registers at the next vsync. Most likely this
will be a partial configuration, as we'll be racing against the ongoing
atomic_commit.
To avoi
A recent bugfix replaced an out-of-bounds access with direct
use of unintialized data:
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c: In function
'smu7_patch_limits_vddc':
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2033:6: error: 'vddc' may be
used uninitialized in this function [-Werro
The newly introduced LED handling for nouveau fails to link when the
driver is built-in but the LED subsystem is a loadable module:
drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend':
tvnv17.c:(.text.nouveau_do_suspend+0x10): undefined reference to
`nouveau_led_suspend'
drivers/g
The newly added assert_kernel_context_is_current introduces a warning
when built with W=1:
drivers/gpu/drm/i915/i915_gem.c: In function
âassert_kernel_context_is_currentâ:
drivers/gpu/drm/i915/i915_gem.c:4417:63: error: suggest braces around empty
body in an âelseâ statement [-Werror=emp
..
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/650e3675/attachment.html>
1 - 100 of 182 matches
Mail list logo
