On Tue, Sep 22, 2015 at 02:55:09PM +0200, Andrzej Hajda wrote:
> Hi,
>
> I have posted the same patch yesterday [1].
>
> http://permalink.gmane.org/gmane.comp.video.dri.devel/136945
>
We seem to be sending duplicates. I sent another duplicate today.
Could you CC kernel-janitors on static chec
Den 27.09.2015 18:08, skrev Emil Velikov:
> Hi all,
>
> On 27 September 2015 at 14:09, Noralf Trønnes wrote:
>> Den 24.09.2015 14:27, skrev Tomi Valkeinen:
>>> Hi all,
>>>
>>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>>> new Linux display drivers should be done on
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150929/db34e56c/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=105051
--- Comment #4 from Tim Sammut ---
(In reply to Alex Deucher from comment #1)
> Radeon hardware supports 256 levels of brightness (0-255). The backlight
> integer property max_brightness is thus set to RADEON_MAX_BL_LEVEL (0xff).
> It sounds li
https://bugzilla.kernel.org/show_bug.cgi?id=105051
--- Comment #5 from Tim Sammut ---
(In reply to Robert Abraham from comment #2)
> But i also have a radeon_bl entry in /sys/class/backlight which has the
> correct values.
> But no matter which value i echo into
> /sys/class/backlight/radeon_bl/b
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_audio.c
between commit:
51e1d83cab99 ("drm/i915: Call audio pin/ELD notify function")
from Linus' tree and commit:
b8abe859c9d6 ("drm/i915: Always call the adjusted mode 'adjusted_mode'"
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commit:
721a09f7393d ("drm/i915: Add primary plane to mask if it's visible")
from Linus' tree and commit:
bd0335b29903 ("drm/i915: Add primary plane to mask if it's vis
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_audio.c
between commit:
b8abe859c9d6 ("drm/i915: Always call the adjusted mode 'adjusted_mode'")
from the drm-intel tree and commit:
9e5a3b529e84 ("drm: Remove the 'mode' argument from dr
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/63f3c6e2/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/cb458cbe/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=105111
--- Comment #5 from fin4478 at hotmail.com ---
(In reply to Alex Deucher from comment #4)
> Does the open driver work with kernel 4.1.6?
amdgpu does not exist in kernel 4.1.6, it came to kernel in version 4.2 or
something. And integrated graphics
Ok, anyways it was sounding like a good idea.
Will do the changes accordingly.
Regards
Shashank
-Original Message-
From: Roper, Matthew D
Sent: Tuesday, September 29, 2015 3:13 AM
To: Sharma, Shashank
Cc: Daniel Vetter; Bish, Jim; Bradford, Robert; Smith, Gary K; dri-devel at
lists.fre
https://bugzilla.kernel.org/show_bug.cgi?id=105111
--- Comment #6 from Michel Dänzer ---
(In reply to fin4478 from comment #5)
> amdgpu does not exist in kernel 4.1.6, [...]
The radeon driver (CONFIG_DRM_RADEON) supports your GPU. The CIK support in
amdgpu is experimental and not intended for e
https://bugzilla.kernel.org/show_bug.cgi?id=105111
--- Comment #7 from fin4478 at hotmail.com ---
(In reply to Michel Dänzer from comment #6)
> (In reply to fin4478 from comment #5)
> > amdgpu does not exist in kernel 4.1.6, [...]
>
> The radeon driver (CONFIG_DRM_RADEON) supports your GPU. The
On Mon, Sep 28, 2015 at 01:52:31PM -0700, Bernie Thompson wrote:
> On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven
> wrote:
> > The smallest of these (udl) still counts in at ca. 2800 LoC,
>
> Note udlfb.c, the original fbdev driver that I helped write and that the
> udl DRM driver was base
On Tue, Sep 29, 2015 at 12:51:38AM +0200, Noralf Trønnes wrote:
>
> Den 27.09.2015 18:08, skrev Emil Velikov:
> >Hi all,
> >
> >On 27 September 2015 at 14:09, Noralf Trønnes wrote:
> >>Den 24.09.2015 14:27, skrev Tomi Valkeinen:
> >>>Hi all,
> >>>
> >>>fbdev is (more or less) maintained, but it
This removes the last depency of radeon for dev->struct_mutex!
Also the locking scheme for hyperz/cmask owners seems a bit unsound,
there's no protection in the preclose handler (and that never did hold
dev->struct_mutex while being called). So grab the same lock there,
too.
There's also all the
On Tue, 29 Sep 2015, Rasmus Villemoes wrote:
> ->stolen->start has type u64 aka unsigned long long; relying on the
> difference (effectively cast to int) for sorting is wrong.
>
> It wouldn't be a problem in practice if the values compared are always
> within INT_MAX of each other (so that the dif
With atomic drivers we need to make sure that (at least in general)
property reads hold the right locks. But the legacy dpms property is
special and can be read locklessly. Since userspace loves to just
randomly look at that all the time (like with "status") do that.
To make it clear that we play
On Tue, Sep 29, 2015 at 09:30:49AM +0200, Daniel Vetter wrote:
> This removes the last depency of radeon for dev->struct_mutex!
>
> Also the locking scheme for hyperz/cmask owners seems a bit unsound,
> there's no protection in the preclose handler (and that never did hold
> dev->struct_mutex whil
On Tue, Sep 29, 2015 at 10:37:30AM +0300, Jani Nikula wrote:
> On Tue, 29 Sep 2015, Rasmus Villemoes wrote:
> > ->stolen->start has type u64 aka unsigned long long; relying on the
> > difference (effectively cast to int) for sorting is wrong.
> >
> > It wouldn't be a problem in practice if the val
On Mon, Sep 28, 2015 at 04:54:15PM -0700, Rafael Antognolli wrote:
> This new test makes some basic testing on the proposed drm_dp_aux_dev
> interface. If the feature is enabled and the drm_dp_aux_dev class is
> present, it will check for available DP aux channels and test them for:
> - basic
On Tue, 29 Sep 2015, Rafael Antognolli wrote:
> This new test makes some basic testing on the proposed drm_dp_aux_dev
> interface. If the feature is enabled and the drm_dp_aux_dev class is
> present, it will check for available DP aux channels and test them for:
> - basic seek to 0 and read
With atomic drivers we need to make sure that (at least in general)
property reads hold the right locks. But the legacy dpms property is
special and can be read locklessly. Since userspace loves to just
randomly look at that all the time (like with "status") do that.
To make it clear that we play
For documentation and paranoia.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_sysfs.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 615b7e667320..7506de0a75b4 100644
--- a/drivers/gpu/drm/drm
We chase pointers/lists without taking the locks protecting them,
which isn't that good.
Fix it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_sysfs.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_s
This goes all the way back to the original KMS commit aeons ago
commit f453ba0460742ad027ae0c4c7d61e62817b3e7ef
Author: Dave Airlie
Date: Fri Nov 7 14:05:41 2008 -0800
DRM: add mode setting support
But it seems to be completely unused. Only i915 and nouveau even
register these properties,
t regards,
Christian.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/43e26d95/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=105111
Christian König changed:
What|Removed |Added
CC||deathsimple at vodafone.de
--- Commen
Hi Vladimir,
Thank you for the patches.
I will integrate them in the next drm/sti pull request that should be sent by
next week.
BR
Vincent
> -Original Message-
> From: Vladimir Zapolskiy [mailto:vladimir_zapolskiy at mentor.com]
> Sent: lundi 21 septembre 2015 17:51
> To: Benjamin Gaig
On Mo, 2015-09-28 at 14:36 +0200, Daniel Vetter wrote:
> On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > As Daniel mentioned, the connector+encoder+crtc combination is one of
> > > those simplifications that would make sense if more such drivers are
> > > added.
Hi Gerd,
On Tuesday 29 September 2015 10:23:23 Gerd Hoffmann wrote:
> On Mo, 2015-09-28 at 14:36 +0200, Daniel Vetter wrote:
> > On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > As Daniel mentioned, the connector+encoder+crtc combination is one of
> > > >
On 09/29/2015 05:28 PM, Sjoerd Simons wrote:
> When doing the initial setup both the hclk and the aclk need to be
> enabled otherwise the board will simply hang. This only occurs when
> building the vop driver as a module, when its built-in the initial setup
> happens to run before the clock fram
Hi Sjoerd
We double check this problem, yes, board will hang if aclk is disabled
when setting vop register.
Acked-by: Mark Yao
Thanks for this fix.
On 2015å¹´09æ29æ¥ 17:28, Sjoerd Simons wrote:
> When doing the initial setup both the hclk and the aclk need to be
> enabled otherwise
yet more variables verses what others may be running it with.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/f3621f61/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=105051
--- Comment #6 from Robert Abraham ---
commit
4eebd5a4e72697aac25a8a57d3f888a9d5f80370
breaks the backlight for me.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Tue, Sep 29, 2015 at 04:50:36PM +0800, Jiang Liu wrote:
> So could you please help to apply the attached debug patch to gather
> more information about the regression?
Sure, just did.
I'm sending you a full s/r cycle attempt caught over serial in a private
message.
Thanks.
--
Regards/Gruss,
hierry Reding2013-11-28 700 ssize_t (*transfer)(struct
drm_dp_aux *aux,
c197db75 Thierry Reding2013-11-28 701 struct
drm_dp_aux_msg *msg);
e9cf6194 Todd Previte 2014-11-04 702 unsigned i2c_nack_count,
i2c_defer_count;
c197db75 Thierry Reding2013-11-28 @703 };
c197db75 Thierry Reding2013-11-28 704
c197db75 Thierry Reding2013-11-28 705 ssize_t drm_dp_dpcd_read(struct
drm_dp_aux *aux, unsigned int offset,
c197db75 Thierry Reding2013-11-28 706 void *buffer,
size_t size);
c197db75 Thierry Reding2013-11-28 707 ssize_t drm_dp_dpcd_write(struct
drm_dp_aux *aux, unsigned int offset,
c197db75 Thierry Reding2013-11-28 708void *buffer,
size_t size);
c197db75 Thierry Reding2013-11-28 709
c197db75 Thierry Reding2013-11-28 710 /**
c197db75 Thierry Reding2013-11-28 711 * drm_dp_dpcd_readb() - read a
single byte from the DPCD
:: The code at line 703 was first introduced by commit
:: c197db75ff5c1d4f015c7668a3715e230a5d7e27 drm/dp: Add AUX channel
infrastructure
:: TO: Thierry Reding
:: CC: Thierry Reding
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6062 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/c948814c/attachment-0001.obj>
*dev)
> if (!pin || !pci_has_managed_irq(dev))
> return;
>
> + /* Keep IOAPIC pin configuration when suspending */
> + if (dev->dev.power.is_prepared)
> + return;
> +#ifdef CONFIG_PM
> + if (dev->dev.power.runtime_status == RPM_SUSPENDING)
> + return;
> +#endif
> +
> entry = acpi_pci_irq_lookup(dev, pin);
> if (!entry)
> return;
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-Gather-debug-info.patch
Type: text/x-patch
Size: 4983 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/c2df64ff/attachment-0001.bin>
Thank you Shashank!
Annie Matheson
> On Sep 28, 2015, at 9:29 PM, Sharma, Shashank
> wrote:
>
> Ok, anyways it was sounding like a good idea.
> Will do the changes accordingly.
>
> Regards
> Shashank
> -Original Message-
> From: Roper, Matthew D
> Sent: Tuesday, September 29, 2015
When doing the initial setup both the hclk and the aclk need to be
enabled otherwise the board will simply hang. This only occurs when
building the vop driver as a module, when its built-in the initial setup
happens to run before the clock framework shuts of unused clocks
(including the aclk).
Whi
ives/dri-devel/attachments/20150929/9ada56cf/attachment.html>
On 09/29/2015 05:55 PM, Yakir Yang wrote:
>
>
> On 09/29/2015 05:28 PM, Sjoerd Simons wrote:
>> When doing the initial setup both the hclk and the aclk need to be
>> enabled otherwise the board will simply hang. This only occurs when
>> building the vop driver as a module, when its built-in the i
es, I'm loosing interest myself in trying to
> > get them merged, especially ones which are getting on for being 2 years
> > old.
>
> I'm still very interested to see at least the "gpu: imx: fix support for
> interlaced modes" and "gpu: imx: simplify sync polarity setting" merged.
> May I take them into the imx-drm tree separately?
The "gpu: imx:" patches sound like they are standalone, so taking them
through the imx-drm tree would be the easiest.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/8b2a31bc/attachment.sig>
l is ok after Alt-Tab the bring back a reduced window.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/271195a3/attachment.html>
org.log
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/90bbb2ce/attachment.html>
tachments/20150929/c14adf29/attachment-0001.html>
On Thu, Jul 09, 2015 at 12:21:06PM -0400, Alex Deucher wrote:
> From: Chunming Zhou
>
> This implements the cgs interface for allocating
> GPU memory.
>
> Reviewed-by: Jammy Zhou
I don't see that review anywhere on a m-l ... where is it?
I stumbled over this patch because it adds a new dev->s
On Tue, 2015-09-29 at 18:58 +0800, Yakir Yang wrote:
>
> On 09/29/2015 05:55 PM, Yakir Yang wrote:
> >
> >
> > On 09/29/2015 05:28 PM, Sjoerd Simons wrote:
> > > When doing the initial setup both the hclk and the aclk need to
> > > be
> > > enabled otherwise the board will simply hang. This only
On 29.09.2015 13:40, Daniel Vetter wrote:
> On Thu, Jul 09, 2015 at 12:21:06PM -0400, Alex Deucher wrote:
>> From: Chunming Zhou
>>
>> This implements the cgs interface for allocating
>> GPU memory.
>>
>> Reviewed-by: Jammy Zhou
> I don't see that review anywhere on a m-l ... where is it?
Jammy
Hi Rafael,
On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> This is useful to determine which connector owns this AUX channel.
WTF? I posted a patch in August which does exactly that:
http://lists.freedesktop.org/archives/dri-devel/2015-August/088172.html
Can also be pulled i
On Thu, Sep 24, 2015 at 5:57 PM, Sudip Mukherjee
wrote:
> On Wed, Sep 09, 2015 at 06:20:40PM +0530, Sudip Mukherjee wrote:
>> If backing->stolen is true then we were freeing backing by calling
>> psb_gtt_free_range() but we called it again after unlocking the mutex.
>> Lets make it NULL after free
On Tue, 29 Sep 2015, Daniel Vetter wrote:
> With atomic drivers we need to make sure that (at least in general)
> property reads hold the right locks. But the legacy dpms property is
> special and can be read locklessly. Since userspace loves to just
> randomly look at that all the time (like with
On Mon, 28 Sep 2015, Jens Axboe wrote:
> Hi,
>
> Running 4.3-rc on a new laptop, and I notice that I get these whenever
> powertop --auto-tune is run:
>
> [14954.927920] [ cut here ]
> [14954.927926] WARNING: CPU: 1 PID: 14297 at drivers/gpu/drm/drm_atomic.c:889
> drm_atom
Hi Daniel,
Thank you for the patch.
On Monday 28 September 2015 21:46:35 Daniel Vetter wrote:
> ->load is deprecated, bus functions are deprecated and everyone
> should use drm_dev_alloc®ister.
>
> So update the .tmpl (and pull a bunch of the overview docs into the
> sourcecode to increase chanc
On 09/25/15 18:50, Arnaud Pouliquen wrote:
> Hello Jyri,
>
> Yes using or not DRM bridge we should be able to have a common
> implementation
>
> Please find,my answer belows
>
> BR,
> Arnaud
>
> On 09/25/2015 04:11 PM, Jyri Sarha wrote:
>> Despite my earlier comment this implementation and the rela
On Tue, Sep 29, 2015 at 04:28:15PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Monday 28 September 2015 21:46:35 Daniel Vetter wrote:
> > ->load is deprecated, bus functions are deprecated and everyone
> > should use drm_dev_alloc®ister.
> >
> > So update the
On Mon, Sep 28, 2015 at 04:45:36PM -0700, Rafael Antognolli wrote:
> This module is heavily based on i2c-dev. Once loaded, it provides one
> dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
>
> It's possible to know which connector owns this aux channel by looking
> at the re
est infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 23761 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/d423ad00/attachment-0001.obj>
On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote:
> Hi Rafael,
>
> On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> > This is useful to determine which connector owns this AUX channel.
>
> WTF? I posted a patch in August which does exactly that:
> http://lists.free
On Tue, Sep 29, 2015 at 02:39:49PM +0200, Christian König wrote:
> On 29.09.2015 13:40, Daniel Vetter wrote:
> >On Thu, Jul 09, 2015 at 12:21:06PM -0400, Alex Deucher wrote:
> >>From: Chunming Zhou
> >>
> >>This implements the cgs interface for allocating
> >>GPU memory.
> >>
> >>Reviewed-by: Jam
On Tue, Sep 29, 2015 at 10:55:39PM +0800, kbuild test robot wrote:
> Hi Robert,
>
> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please
> ignore]
>
> config: i386-defconfig (attached as .config)
> reproduce:
> git checkout a1d59679ae8f3e7e7659e9723ae3fc69af2532e6
> # s
Hi Daniel,
On Tue, Sep 29, 2015 at 05:04:03PM +0200, Daniel Vetter wrote:
> On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote:
> > On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> > > This is useful to determine which connector owns this AUX channel.
> >
> > WTF? I
On Tue, Sep 29, 2015 at 01:07:25PM +0200, Thierry Reding wrote:
> On Fri, Sep 25, 2015 at 10:29:51AM +0200, Philipp Zabel wrote:
> > Am Montag, den 21.09.2015, 15:15 +0100 schrieb Russell King - ARM Linux:
> > > On Mon, Sep 21, 2015 at 11:51:06AM +0200, Thierry Reding wrote:
> > > > On Wed, Sep 16,
completely struct_mutex free with the goal to untangle the
> last hold-outs of that lock in the drm core.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-amdgpu-cgs-remove-import_gpu_mem.patch
Type: text/x-patch
Size: 3760 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/1e0f0d74/attachment-0001.bin>
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150929/e113cc07/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=105051
--- Comment #7 from Alex Deucher ---
Perhaps the radeon driver should just not attempt to register a backlight
interface on Macs since they seem to use the gmux for backlight control. Some
one with more knowledge of mac hw should probably commen
On Tue, Sep 29, 2015 at 10:53:02AM +0300, Jani Nikula wrote:
> On Tue, 29 Sep 2015, Rafael Antognolli wrote:
> > This new test makes some basic testing on the proposed drm_dp_aux_dev
> > interface. If the feature is enabled and the drm_dp_aux_dev class is
> > present, it will check for available D
On Tue, Sep 29, 2015 at 05:27:33PM +0200, Lukas Wunner wrote:
> Hi Daniel,
>
> On Tue, Sep 29, 2015 at 05:04:03PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote:
> > > On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> > > > This is u
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.
Cc: Chris Wilson
Signed-off-by: Robert Bragg
Signed-off-by: Zhenyu
Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_pe
On 09/29/2015 01:56 AM, Daniel Vetter wrote:
> With atomic drivers we need to make sure that (at least in general)
> property reads hold the right locks. But the legacy dpms property is
> special and can be read locklessly. Since userspace loves to just
> randomly look at that all the time (like wi
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl comparable to perf_event_open
that opens a file descriptor for an event source.
Based on our initial experience aiming to use the core perf
infrastructure, this interface is inspired by perf, but focused on
exposing metrics about work running on Gen graph
OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a
Adds a static OA unit, MUX + B Counter configuration for basic '3D'
metrics on Haswell. This is autogenerated from an internal XML
description of metric sets.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_drv.h| 5 ++
drivers/gpu/drm/i
The minimal sampling period is now configurable via a
dev.i915.oa_event_min_timer_exponent sysctl parameter.
Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.
Signed-off-by: Rob
Maybe line 294 should become an unlock and should be moved under 295?
julia
On Tue, 29 Sep 2015, kbuild test robot wrote:
> CC: kbuild-all at 01.org
> In-Reply-To: <1443513993-5228-2-git-send-email-daniel.vetter at ffwll.ch>
> TO: Daniel Vetter
> CC: DRI Development
> CC: Daniel Vetter , Intel
After some recent progress enabling the Observation Architecture unit
for Gen8+, we can hopefully paint a fairly complete picture of the
requirements for supporting the unit from Haswell to Skylake and so
I'm looking again at the challenges in upstreaming this work.
Considering this, it looked lik
On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote:
> Hi Rafael,
>
> On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> > This is useful to determine which connector owns this AUX channel.
>
> WTF? I posted a patch in August which does exactly that:
> http://lists.free
On Fri, Sep 25, 2015 at 7:36 AM, Dan Carpenter
wrote:
> The "i" variable should be signed or it leads to a crash in the error
> handling code.
>
> Fixes: 1d263474c441 ('drm/amdgpu: unwind properly in amdgpu_cs_parser_init()')
> Signed-off-by: Dan Carpenter
Applied. thanks!
Alex
>
> diff --gi
Here are my queued changes for the Armada DRM driver, for the upcoming
4.4 merge window.
These changes are about updating the driver to some of the more recent
DRM APIs, and removing the non-component support now that has
stabilised. This results in all of armada_output and armada_slave
being rem
Our vblank event code belongs in armada_crtc.c rather than the core of
the driver. Move it there.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 46 ++--
drivers/gpu/drm/armada/armada_crtc.h | 17 +
drivers/gpu/drm/armada/armad
It is not necessary to write dplane->ctrl0 under the CRTC spinlock, as
this is only accessed under process context where the DRM locks will
protect us instead.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
Convert the overlay plane to use the generic armada plane worker
infrastructure which is shared with the primary plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 48 +
drivers/gpu/drm/armada/armada_crtc.h| 20 ++
dri
Introduce a generic armada_plane struct which will eventually be used
for both the primary and overlay planes.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.h| 5 +
drivers/gpu/drm/armada/armada_overlay.c | 17 +
2 files changed, 14 insertions(+), 8
Both the CRTC and overlay frames have their own wait queues. It would
make more sense if these were part of the plane - the primary plane for
the CRTC and overlay plane for the overlay.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 22 ++
drivers/
Move the locking for armada_drm_vbl_event_remove() into itself, which
makes this function symmetrical with armada_drm_vbl_event_add().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 2 ++
drivers/gpu/drm/armada/armada_overlay.c | 2 --
2 files changed, 2 insertions(+),
Use the new drm_universal_plane_init() rather than the legacy
drm_plane_init().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/ar
We can do better with armada_drm_crtc_complete_frame_work() - we can
avoid taking the event lock unless a call to drm_send_vblank_event()
is required, and using cmpxchg() and xchg(), we can eliminate the
locking around dcrtc->frame_work entirely.
Signed-off-by: Russell King
---
drivers/gpu/drm/a
Rather than using a spinlock, use xchg() to atomically update
dplane->old_fb. This allows us to eliminate dplane->lock.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm
Use drm_plane_force_disable() to disable the overlay plane on a mode_set
rather than coding this ourselves.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
Move the write to clear the DMA enable bit, and augment it with clearing
the graphics enable bit for the primary plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 12 ++--
drivers/gpu/drm/armada/armada_overlay.c | 1 -
2 files changed, 10 insertions(+), 3
We have two identical places in the overlay code which retire the drm
framebuffer. Factor these out into a common function.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 37 +++--
1 file changed, 17 insertions(+), 20 deletions(-)
diff --g
Include an _ovl infix into the overlay identifiers to separate them from
the primary plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_overlay.c | 55 ++---
1 file changed, 30 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/armada/armad
Use drm_primary_helper_create_plane() to create our primary plane, and
register the CRTC with drm_crtc_init_with_planes(). This enables the
primary plane to be initialised with the supported format information.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 34 ++
Add a plane work implementation, and move the CRTC framebuffer flip
work to it for the primary plane. The idea is to have a common
plane work implementation for both the primary and overlay planes.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 102 --
Allocate our own primary plane as an armada_plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
inde
Move the wakeup for the frame wait into the armada plane work, to
ensure that it is woken up every time we run a work.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
Provide a common helper to disable either the overlay or the primary
plane.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 33 +++--
drivers/gpu/drm/armada/armada_crtc.h| 3 +++
drivers/gpu/drm/armada/armada_overlay.c | 7 +--
3 fi
Now that the transition of TDA998x to the component helpers is complete,
remove the non-componentised support from the Armada DRM driver. All
outputs are expected to use the component helpers from now on.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/Kconfig | 9 ---
drivers/
1 - 100 of 136 matches
Mail list logo
