Hi all,
There is something seriaously wrong with anongit.freedesktop.org this
morning. Fething trees from there takes an enormous amount of time -
so long that I had to abort the fetches ...
--
Cheers,
Stephen Rothwell
Hi Rob,
On Wed, 30 Nov 2016 17:49:24 -0500 Rob Clark wrote:
>
> yeah, {cgit,anongit}.fd.o have been having problems all day.. (the ssh
> git urls for folks who have push access work fine).. although it has
> worked for me a couple times today, given enough time.
>
> (not sure if we have github/e
30.11.2016, 17:28, "Jean-Francois Moine" :
> On Wed, 30 Nov 2016 10:20:21 +0200
> Laurent Pinchart wrote:
>
>> Â > Well, I don't see what this connector can be.
>> Â > May you give me a DT example?
>>
>> Â Sure.
>>
>> Â arch/arm/boot/dts/r8a7791-koelsch.dts
>>
>> Â Â Â Â Â Â Â Â Â /* HDMI encode
30.11.2016, 18:44, "Jean-Francois Moine" :
> On Wed, 30 Nov 2016 11:52:25 +0200
> Laurent Pinchart wrote:
>
>>  Hi Jean-François,
>>
>> Â On Wednesday 30 Nov 2016 10:27:57 Jean-Francois Moine wrote:
>> Â > On Wed, 30 Nov 2016 10:20:21 +0200 Laurent Pinchart wrote:
>> Â > >> Well, I don't see w
Hi Benjamin,
On Wednesday 30 Nov 2016 20:46:23 Benjamin Gaignard wrote:
> 2016-11-30 20:39 GMT+01:00 Laurent Pinchart:
> > On Wednesday 30 Nov 2016 20:34:17 Benjamin Gaignard wrote:
> >> If HAVE_ARCH_FB_UNMAPPED_AREA is set and get_fb_unmapped_area
> >> function not defined in platform architectur
On 01/12/16 04:46 AM, Benjamin Gaignard wrote:
> 2016-11-30 20:39 GMT+01:00 Laurent Pinchart ideasonboard.com>:
>> On Wednesday 30 Nov 2016 20:34:17 Benjamin Gaignard wrote:
>>> If HAVE_ARCH_FB_UNMAPPED_AREA is set and get_fb_unmapped_area
>>> function not defined in platform architecture let use
On 01/12/16 05:35 AM, Emil Velikov wrote:
> From: Emil Velikov
>
> Relative to the original version, here one can provide a flags bitmask.
> Currently only DRM_DEVICE_IGNORE_PCI_REVISION is supported.
>
> Implementation detail:
> If it's set, we will only parse the separate sysfs files and we wo
On 01/12/16 12:09 PM, Michel Dänzer wrote:
> On 01/12/16 05:35 AM, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> Relative to the original version, here one can provide a flags bitmask.
>> Currently only DRM_DEVICE_IGNORE_PCI_REVISION is supported.
>>
>> Implementation detail:
>> If it's set, we
Implement drmGetMinorNameForFD for systems without sysfs by
adapting drm_get_device_name_for_fd() from the Mesa loader.
v2: use type parameter to select dev name instead of always
using DRM_DEV_NAME
Signed-off-by: Jonathan Gray
---
xf86drm.c | 35 ++-
1 file
Implement drmParseSubsystemType for OpenBSD by always returning
DRM_BUS_PCI. No non-pci drm drivers are in the kernel and this is
unlikely to change anytime soon as the existing ones aren't permissively
licensed.
Signed-off-by: Jonathan Gray
---
xf86drm.c | 2 ++
1 file changed, 2 insertions(+)
Implement drmParsePciDeviceInfo for OpenBSD by using the new
DRM_IOCTL_GET_PCIINFO ioctl.
v2: adapt to drmParsePciDeviceInfo changes and use drmOpenMinor
Signed-off-by: Jonathan Gray
---
xf86drm.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/xf8
DRI devices on OpenBSD are not in their own directory. They reside in
/dev with a large number of statically generated /dev nodes.
Avoid stat'ing all of /dev on OpenBSD by implementing this custom path.
v2:
- use drmGetMinorType to get node type
- adapt to drmProcessPciDevice changes
-
Implement drmParsePciBusInfo for OpenBSD by using the new
DRM_IOCTL_GET_PCIINFO ioctl.
v2: use drmGetMinorType to get node type instead of always
using DRM_NODE_PRIMARY.
Signed-off-by: Jonathan Gray
---
xf86drm.c | 24
1 file changed, 24 insertions(+)
diff --git a/
On 11/30/2016 05:18 PM, Lucas Stach wrote:
> ASSR is an optional feature, so it's a valid operating condition for
> the display to reject ASSR enable. Demote the warning to the debug
> level.
Lgtm. Will pull it if Philipp or Andrey don't have any comments on it.
Thanks,
Archit
>
> Signed-off-b
CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1083 bytes
Desc: Digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161201/01788dcb/attachment.sig>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161201/ed1b5aa8/attachment.html>
On 30.11.2016 10:39, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wednesday 30 Nov 2016 10:26:24 Andrzej Hajda wrote:
>> On 30.11.2016 09:16, Laurent Pinchart wrote:
>>> On Wednesday 30 Nov 2016 09:11:56 Andrzej Hajda wrote:
On 29.11.2016 22:12, Jyri Sarha wrote:
> Store the module that pr
On Wed, Nov 30, 2016 at 02:19:18PM +0100, Benjamin Gaignard wrote:
> Some SoC without MMU have display driver where a drm/kms driver
> could be implemented.
> Before doing such kind of thing drm/kms must allow to use mmuless
> devices.
> This patch propose to remove MMU configuration flag and add s
On Wed, Nov 30, 2016 at 08:37:04PM +, Emil Velikov wrote:
> All of these 'tests' cover UMS functionality which is neither being
> worked on or actively maintained.
>
> The only cases where developers touch UMS code is to unwrap it from the
> KMS codepaths and ensure that those are secure.
>
>
On Wed, Nov 30, 2016 at 08:51:26PM +, Chris Wilson wrote:
> commit 202b52b7fbf7 ("drm: Track drm_mm nodes with an interval tree")
> introduced a requirement that the special drm_mm.head_node was
> initialised and marked as not being allocated. It is a very special node
> that has no side but ha
2016-12-01 7:56 GMT+01:00 Daniel Vetter :
> On Wed, Nov 30, 2016 at 02:19:18PM +0100, Benjamin Gaignard wrote:
>> Some SoC without MMU have display driver where a drm/kms driver
>> could be implemented.
>> Before doing such kind of thing drm/kms must allow to use mmuless
>> devices.
>> This patch p
There is no need to repeat information that printed by PCI core at boot time.
Besides that printing was potentially wrong since resource_size_t might be
bigger than 32 bits and there is a dedicated specifier for such type, i.e.
%pap. Someone can fix it and use even better approach, i.e. %pR.
Sign
On 30.11.2016 14:09, Daniel Vetter wrote:
> On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote:
>> On Wednesday 30 Nov 2016 11:55:20 Daniel Vetter wrote:
>>> Why exactly do you want to hotplug encoders? Or bridges fwiw ... since at
>>> least only making those hotpluggable will make th
On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote:
> On 30.11.2016 14:09, Daniel Vetter wrote:
> > On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote:
> >> On Wednesday 30 Nov 2016 11:55:20 Daniel Vetter wrote:
> >>> Why exactly do you want to hotplug encoders? Or bridges
2016-12-01 7:56 GMT+01:00 Daniel Vetter :
> On Wed, Nov 30, 2016 at 02:19:18PM +0100, Benjamin Gaignard wrote:
>> Some SoC without MMU have display driver where a drm/kms driver
>> could be implemented.
>> Before doing such kind of thing drm/kms must allow to use mmuless
>> devices.
>> This patch p
2016-12-01 2:13 GMT+01:00 Laurent Pinchart :
> Hi Benjamin,
>
> On Wednesday 30 Nov 2016 20:46:23 Benjamin Gaignard wrote:
>> 2016-11-30 20:39 GMT+01:00 Laurent Pinchart:
>> > On Wednesday 30 Nov 2016 20:34:17 Benjamin Gaignard wrote:
>> >> If HAVE_ARCH_FB_UNMAPPED_AREA is set and get_fb_unmapped_a
2016-12-01 3:31 GMT+01:00 Michel Dänzer :
> On 01/12/16 04:46 AM, Benjamin Gaignard wrote:
>> 2016-11-30 20:39 GMT+01:00 Laurent Pinchart > ideasonboard.com>:
>>> On Wednesday 30 Nov 2016 20:34:17 Benjamin Gaignard wrote:
If HAVE_ARCH_FB_UNMAPPED_AREA is set and get_fb_unmapped_area
func
On 30/11/16 06:07 PM, Daniel Vetter wrote:
> On Wed, Nov 30, 2016 at 05:30:02PM +0900, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> This is an attempt to make the previous fix a bit more robust going
>> forward.
>>
>> Signed-off-by: Michel Dänzer
>> ---
>> drivers/gpu/drm/drm_ioctl.c | 2
From: Michel Dänzer
This is an attempt to make the previous fix a bit more robust going
forward.
v2:
* Only allow DRM_CAP_TIMESTAMP_MONOTONIC with UMS drivers (Daniel
Vetter, Alex Deucher)
* Different logic to keep DRM_CAP_TIMESTAMP_MONOTONIC separate from
the other caps (Daniel Vetter)
Si
On 12/01/2016 07:21 AM, Robin H. Johnson wrote:
> On Wed, Nov 30, 2016 at 10:24:59PM +0100, Vlastimil Babka wrote:
>> [add more CC's]
>>
>> On 11/30/2016 09:19 PM, Robin H. Johnson wrote:
>> > Somewhere in the Radeon/DRM codebase, CMA page allocation has either
>> > regressed in the timeline of 4.5
On 12/01/2016 08:21 AM, Michal Hocko wrote:
> Forgot to CC Joonsoo. The email thread starts more or less here
> http://lkml.kernel.org/r/20161130092239.GD18437 at dhcp22.suse.cz
>
> On Thu 01-12-16 08:15:07, Michal Hocko wrote:
>> On Wed 30-11-16 20:19:03, Robin H. Johnson wrote:
>> [...]
>> > allo
ad92915a9
.
--
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/20161201/431aa127/attachment.html>
Am Donnerstag, den 01.12.2016, 09:56 +0530 schrieb Archit Taneja:
>
> On 11/30/2016 05:18 PM, Lucas Stach wrote:
> > ASSR is an optional feature, so it's a valid operating condition for
> > the display to reject ASSR enable. Demote the warning to the debug
> > level.
>
> Lgtm. Will pull it if Phi
On Thu, Dec 01, 2016 at 08:38:15AM +0100, Vlastimil Babka wrote:
> >> By default config this should not be used on x86.
> > What do you mean by that statement?
>
> I mean that the 16 mbytes for generic CMA area is not a default on x86:
>
> config CMA_SIZE_MBYTES
> int "Size in Mega Bytes
Ok, transition is over, old drm-intel-nightly and rerere-cache is removed.
I hope that's enough of a hint to everyone else who missed the memo ;-)
-Daniel
On Thu, Nov 24, 2016 at 11:48:47AM +0100, Daniel Vetter wrote:
> Hi all,
>
> So it's finally done, drm-misc is split out into a separate repo:
On Thu, Dec 01, 2016 at 08:21:11AM +0100, Benjamin Gaignard wrote:
> 2016-12-01 7:56 GMT+01:00 Daniel Vetter :
> > On Wed, Nov 30, 2016 at 02:19:18PM +0100, Benjamin Gaignard wrote:
> >> Some SoC without MMU have display driver where a drm/kms driver
> >> could be implemented.
> >> Before doing suc
https://bugzilla.kernel.org/show_bug.cgi?id=188621
--- Comment #2 from bianpan ---
Created attachment 246531
--> https://bugzilla.kernel.org/attachment.cgi?id=246531&action=edit
A patch to fix the bug
I created a patch to fix the bug. Please check whether it is suitable. Thanks!
--
You are r
Hi Daniel,
On Tue, 29 Nov 2016 21:14:10 +0100
Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 10:41:58AM -0800, Eric Anholt wrote:
> > From: Boris Brezillon
> >
> > Some generic TV connector properties are exposed in drm_mode_config, but
> > they are currently handled independently in each DRM
https://bugzilla.kernel.org/show_bug.cgi?id=188621
--- Comment #3 from Oded Gabbay ---
I'll take a look.
Thanks!
Oded
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi Benjamin,
On Thursday 01 Dec 2016 08:24:50 Benjamin Gaignard wrote:
> 2016-12-01 2:13 GMT+01:00 Laurent Pinchart:
> > On Wednesday 30 Nov 2016 20:46:23 Benjamin Gaignard wrote:
> >> 2016-11-30 20:39 GMT+01:00 Laurent Pinchart:
> >>> On Wednesday 30 Nov 2016 20:34:17 Benjamin Gaignard wrote:
> >
On Thursday 01 Dec 2016 08:27:58 Benjamin Gaignard wrote:
> 2016-12-01 3:31 GMT+01:00 Michel Dänzer :
> > On 01/12/16 04:46 AM, Benjamin Gaignard wrote:
> >> 2016-11-30 20:39 GMT+01:00 Laurent Pinchart:
> >>> On Wednesday 30 Nov 2016 20:34:17 Benjamin Gaignard wrote:
> If HAVE_ARCH_FB_UNMAPPE
and "dumb-hdmi-vga-bridge"
> drivers?)
It probably wouldn't be dumb, but yeah, it would definitely be a
bridge instead of the connector.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part -
happens again, which we can't do because of
the DT ABI.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- 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/20161201/edd95cf1/attachment.sig>
Hi Maxime,
On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote:
> On Wed, Nov 30, 2016 at 12:12:55PM +0200, Laurent Pinchart wrote:
> >> More, it is not sure that the bridge/DW code would work with Allwinner's
> >> SoCs.
> >
> > If it doesn't work and can't be made to work in a non-invasive way
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161201/7398f760/attachment.html>
Hello,
On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote:
[snip]
> The earlier Allwinner SoCs (with the old display engine), we had some
> SoCs with multiple instances of the display engine and TCON (the
> display engine roughly implementing the planes, the TCON the
> CRTC. Roughly.). However
Kernel engineering
http://free-electrons.com
-- 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/20161201/79cf80f8/attachment.sig>
Hi Dave, presumably final fixes for 4.9.
BR,
Jani.
The following changes since commit e5517c2a5a49ed5e99047008629f1cd60246ea0e:
Linux 4.9-rc7 (2016-11-27 13:08:04 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2016-12-01
fo
Hi.
I'm fine with that change.
Acked-by:Andrey Gusakov
On Thu, Dec 1, 2016 at 10:58 AM, Philipp Zabel
wrote:
> Am Donnerstag, den 01.12.2016, 09:56 +0530 schrieb Archit Taneja:
>>
>> On 11/30/2016 05:18 PM, Lucas Stach wrote:
>> > ASSR is an optional feature, so it's a valid operating conditi
Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
boards.
Reviewed-by: Laurent Pinchart
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 16
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 16
Add myself as maintainer for Amlogic DRM drivers.
Acked-by: Daniel Vetter
Acked-by: Laurent Pinchart
Signed-off-by: Neil Armstrong
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..b1ad45b 100644
--- a/MAINTAINERS
+++ b/MAINTA
On 12/01/16 at 04:00pm, Dave Young wrote:
> On 11/30/16 at 03:25pm, Ville Syrjälä wrote:
> > On Thu, Nov 24, 2016 at 05:03:20PM +0800, Dave Young wrote:
> > > On 11/24/16 at 10:53am, Jani Nikula wrote:
> > > > On Thu, 24 Nov 2016, Dave Young wrote:
> > > > > I see a lot of below warning:
> > > >
Reviewed-by: Laurent Pinchart
Signed-off-by: Neil Armstrong
---
.../bindings/display/amlogic,meson-vpu.txt | 112 +
1 file changed, 112 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
diff --git a/Documentation/devic
Forgot to CC Joonsoo. The email thread starts more or less here
http://lkml.kernel.org/r/20161130092239.GD18437 at dhcp22.suse.cz
On Thu 01-12-16 08:15:07, Michal Hocko wrote:
> On Wed 30-11-16 20:19:03, Robin H. Johnson wrote:
> [...]
> > alloc_contig_range: [83f2a3, 83f2a4) PFNs busy
>
> Huh, d
This a repost of the previous version at [3] with fixes, the following patches
will
be sent via a PULL Request once the DT maintainers acks the DT bindings.
The Amlogic maintainer will take the arm64 DT patches to avoid merges conflicts.
The Amlogic Meson SoCs embeds a Video Processing Unit able
On 11/30/16 at 03:25pm, Ville Syrjälä wrote:
> On Thu, Nov 24, 2016 at 05:03:20PM +0800, Dave Young wrote:
> > On 11/24/16 at 10:53am, Jani Nikula wrote:
> > > On Thu, 24 Nov 2016, Dave Young wrote:
> > > > I see a lot of below warning:
> > >
> > > No, we must not hide this under the carpet. Th
On Wed 30-11-16 20:19:03, Robin H. Johnson wrote:
[...]
> alloc_contig_range: [83f2a3, 83f2a4) PFNs busy
Huh, do I get it right that the request was for a _single_ page? Why do
we need CMA for that?
--
Michal Hocko
SUSE Labs
The Amlogic Meson Display controller is composed of several components :
DMC|---VPU (Video Processing Unit)|--HHI--|
| vd1 ___ __ | |
D |---| ||| |||
On 11/14/16 16:22, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add support for HDMI hotplug and EDID notifiers, which is used to convey
> information from HDMI drivers to their CEC and audio counterparts.
I realized that the name 'HDMI notifier' isn't the best: the same mechanism
can be used wit
g.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161201/1e39/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161201/777d7acb/attachment.html>
On Thursday 01 Dec 2016 09:55:20 Maxime Ripard wrote:
> On Thu, Dec 01, 2016 at 01:33:30AM +0800, Icenowy Zheng wrote:
> >>> hdmi-out {
> >>> compatible = "hdmi-connector";
> >>> type = "a";
> >>> /* I2C bus and GPIO references are made up
branch
of drm-intel.
Cheers,
Daniel
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161201/4e2e493a/attachment.html>
On Thu, 01 Dec 2016 12:41:20 +0200
Laurent Pinchart wrote:
> > > If a DVI connector instead of a HDMI connector is soldered, how
> > > should such a device tree be written?
> >
> > Use a dvi-connector instead :)
>
> The HDMI encoder DT node doesn't (and certainly shouldn't) report what type
>
On Thursday 01 Dec 2016 12:30:09 Jean-Francois Moine wrote:
> On Thu, 01 Dec 2016 12:41:20 +0200 Laurent Pinchart wrote:
> >>> If a DVI connector instead of a HDMI connector is soldered, how
> >>> should such a device tree be written?
> >>
> >> Use a dvi-connector instead :)
> >
> > The HDMI enco
https://bugzilla.kernel.org/show_bug.cgi?id=188321
Jani Nikula changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
e mesa git repository. I'll try to bisect in the next days.
--
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/20161201/d94f3567/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=107381
Bhaskar changed:
What|Removed |Added
CC||bha100710 at gmail.com
--- Comment #14 from Bh
https://bugzilla.kernel.org/show_bug.cgi?id=107381
--- Comment #15 from Stratos Zolotas ---
I'm on 4.8.10 and still is not fixed. I have two AMD GPUS (both Oland) and the
issue is appearing on both. So don't expect to see a fix on any released
kernel. Haven't tested any 4.9 pre-release yet.
01:0
e rest of the function then creates CRTCs, as far as I understand
> always
> up to num_crtcs. Can't we just use that value to compute possible_crtcs as (1
> << num_crtcs ) - 1 ?
Yes, I think you're correct. It's not exactly obvious from the code =).
I'll change the patch to use the calculated num-crtcs.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161201/8a3f93b0/attachment.sig>
On 01.12.2016 08:18, Daniel Vetter wrote:
> On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote:
>> On 30.11.2016 14:09, Daniel Vetter wrote:
>>> On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote:
On Wednesday 30 Nov 2016 11:55:20 Daniel Vetter wrote:
> Why exactly
For non-CRTC displays, the drm_atomic_helper_connector_dpms
will always set the connector back the old DPMS state
before returning. This makes it impossible to change
DPMS state.
fixes: 0853695c3ba46f97dfc0b5885f7b7e640ca212dd
Signed-off-by: Marta Lofstedt
---
drivers/gpu/drm/drm_atomic_helper.
On 1 December 2016 at 03:56, Michel Dänzer wrote:
> On 01/12/16 12:09 PM, Michel Dänzer wrote:
>> On 01/12/16 05:35 AM, Emil Velikov wrote:
>>> From: Emil Velikov
>>>
>>> Relative to the original version, here one can provide a flags bitmask.
>>> Currently only DRM_DEVICE_IGNORE_PCI_REVISION is
From: Nicolai Hähnle
v2: use resv->lock instead of resv->lock.base (Christian König)
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/vgem/vgem_fence.c |
From: Nicolai Hähnle
In the following scenario, thread #1 should back off its attempt to lock
ww1 and unlock ww2 (assuming the acquire context stamps are ordered
accordingly).
Thread #0 Thread #1
- -
successfully lo
From: Nicolai Hähnle
We will add a new field to struct mutex_waiter. This field must be
initialized for all waiters if any waiter uses the ww_use_ctx path.
So there is a trade-off: Keep ww_mutex locking without a context on the
faster non-use_ww_ctx path, at the cost of adding the initializati
From: Nicolai Hähnle
Add regular waiters in stamp order. Keep adding waiters that have no
context in FIFO order and take care not to starve them.
While adding our task as a waiter, back off if we detect that there is a
waiter with a lower stamp in front of us.
Make sure to call lock_contended
From: Nicolai Hähnle
The function will be re-used in subsequent patches.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
kernel/locking/mutex.c | 10 --
1 file ch
From: Nicolai Hähnle
While adding our task as a waiter, detect if another task should back off
because of us.
With this patch, we establish the invariant that the wait list contains
at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter
will be the first waiter with a context.
From: Nicolai Hähnle
The wait list is sorted by stamp order, and the only waiting task that may
have to back off is the first waiter with a context.
The regular slow path does not have to wake any other tasks at all, since
all other waiters that would have to back off were either woken up when
From: Nicolai Hähnle
Help catch cases where mutex_lock is used directly on w/w mutexes, which
otherwise result in the w/w tasks reading uninitialized data.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Sig
From: Nicolai Hähnle
Check the current owner's context once against our stamp. If our stamp is
lower, we continue to spin optimistically instead of backing off.
This is correct with respect to deadlock detection because while the
(owner, ww_ctx) pair may re-appear if the owner task manages to u
From: Nicolai Hähnle
Document the invariants we maintain for the wait list of ww_mutexes.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
Documentation/locking/ww-mutex-d
From: Nicolai Hähnle
Lock stealing is less beneficial for w/w mutexes since we may just end up
backing off if we stole from a thread with an earlier acquire stamp that
already holds another w/w mutex that we also need. So don't spin
optimistically unless we are sure that there is no other waiter
On Thu, Dec 01, 2016 at 03:30:01PM +0200, Marta Lofstedt wrote:
> For non-CRTC displays,
A connector not attached to a CRTC works. It is the active connectors
that were broken.
> the drm_atomic_helper_connector_dpms
> will always set the connector back the old DPMS state
> before returning. This
On Thu, Dec 01, 2016 at 03:06:44PM +0100, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> v2: use resv->lock instead of resv->lock.base (Christian König)
>
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: dri-devel at lists.free
On Thu, Dec 01, 2016 at 03:06:45PM +0100, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> In the following scenario, thread #1 should back off its attempt to lock
> ww1 and unlock ww2 (assuming the acquire context stamps are ordered
> accordingly).
>
> Thread #0 Thread #1
>
On Thu, Dec 01, 2016 at 03:06:46PM +0100, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> The function will be re-used in subsequent patches.
>
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: dri-devel at lists.freedesktop.org
>
On Thu, Dec 1, 2016 at 2:37 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> This is an attempt to make the previous fix a bit more robust going
> forward.
>
> v2:
> * Only allow DRM_CAP_TIMESTAMP_MONOTONIC with UMS drivers (Daniel
> Vetter, Alex Deucher)
> * Different logic to keep DRM_CAP
Hi Krzysztof,
Am Donnerstag, den 17.11.2016, 10:43 +0100 schrieb Krzysztof HaÅasa:
> Hi,
>
> The following GStreamer pipeline causes screen to become green with
> v4.9-rc4+:
>
> gst-launch-1.0 udpsrc uri=udp://239.1.2.2:5100 reuse=true
> caps="application/x-rtp,media=(string)video,clock-rate=(
Hi,
On 29-11-16 14:06, Hans de Goede wrote:
> p.s.
>
> I'm also trying to come up with some patches which properly
> integrate pwm-lpss with the i915 driver instead of it
> throwing a "Failed to own the pwm chip" error. But as soon
> as I hook up things so that pwm_get() returns the pwm-lpss
>
On Thu, Dec 01, 2016 at 02:22:18PM +0100, Andrzej Hajda wrote:
> On 01.12.2016 08:18, Daniel Vetter wrote:
> > On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote:
> >> On 30.11.2016 14:09, Daniel Vetter wrote:
> >>> On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote:
>
On Thu, Dec 01, 2016 at 02:18:04PM +, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 03:06:44PM +0100, Nicolai Hähnle wrote:
> > From: Nicolai Hähnle
> >
> > v2: use resv->lock instead of resv->lock.base (Christian König)
> >
> > Cc: Peter Zijlstra
> > Cc: Ingo Molnar
> > Cc: Maarten Lan
On Thu, Dec 1, 2016 at 2:37 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> This is an attempt to make the previous fix a bit more robust going
> forward.
It takes a bit of work to locate the "previous fix" now that it's gone
through drm-misc-fixes. Can you update with a proper reference to
On Thu, Dec 01, 2016 at 10:21:28AM -0500, Sean Paul wrote:
> On Thu, Dec 1, 2016 at 2:37 AM, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > This is an attempt to make the previous fix a bit more robust going
> > forward.
>
> It takes a bit of work to locate the "previous fix" now that it
On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
Once the i915 driver has successfully loaded, the panel can be disabled /
enabled without hitting this issue.
The getting stuck is caused by vlv_init_d
Note! This series is not yet ready and should not be used as is, it is
just an RFC.
The function documentation is missing and so are the modifications to
all affected drivers. I have added the modification patches for tilcdc
and ti-tfp410 to serve as an example and I have put them into separate
pa
Store the module that provides the bridge and adjust its reference
count accordingly. The bridge module unload should not be allowed
while the bridge is attached. To do this safely we need to add
reference counting to drm_bridge objects. This has impact to both
bridge drivers and the drivers using
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/bridge/ti-tfp410.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index b054ea3..f0c81dd 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
++
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_external.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 80184f0..31c6092 100644
--- a/drivers/gpu/drm/tilc
1 - 100 of 149 matches
Mail list logo
