https://bugzilla.kernel.org/show_bug.cgi?id=178421
Kevin changed:
What|Removed |Added
CC||kvbevsauce at gmail.com
--- Comment #2 from Kevi
https://bugzilla.kernel.org/show_bug.cgi?id=83531
Kevin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
dr);
> >>^
> >> ../include/drm/drmP.h:201:43: note: in definition of macro 'DRM_ERROR'
> >> drm_printk(KERN_ERR, DRM_UT_NONE, fmt, ##__VA_ARGS__)
> >> ^
> >
Hi Linus,
Second part of the fixes for rc2, main one being some vmwgfx fixes,
also some armada, etnaviv and fsl-dcu fixes.
There is a pretty large regression in -rc1 that affects radeon/amdgpu/nouveau
and possibly other ttm using drivers with real VRAM on PAT systems, this was
due to a change in
On 10/19/2016 07:55 PM, Laurent Pinchart wrote:
> The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be
> controlled through a power save pin, and requires a power supply.
> However, on most boards where the device is used neither the power save
> signal nor the power supply are co
On 10/19/2016 07:55 PM, Laurent Pinchart wrote:
> The LVDS encoder driver is a DRM bridge driver that supports the
> parallel to LVDS encoders that don't require any configuration. The
> driver thus doesn't interact with the device, but creates an LVDS
> connector for the panel and exposes its si
today and this weekend to see if other
problems are solved too, will write info asap. Big thanks for all help so far.
--
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/20161021/15cb48e4/attachment.html>
On Thu, Oct 20, 2016 at 9:29 PM, Philipp Zabel
wrote:
> Am Donnerstag, den 20.10.2016, 16:51 +0800 schrieb Ying Liu:
>> >> Does the clip thing potentially change the user's request by force?
>> >> For example, the user request an unreasonable big resolution.
>> >
>> > The user is allowed to ask f
submit_context() should return negative error codes and zero on success
but by mistake we made it a bool. I've changed it to int. Also I made
it static because this isn't referenced in any other files.
This doesn't affect runtime because the return is eventually propogated
to elsp_mmio_write() w
Am Freitag, den 21.10.2016, 13:45 +0800 schrieb Ying Liu:
> On Thu, Oct 20, 2016 at 9:29 PM, Philipp Zabel
> wrote:
> > Am Donnerstag, den 20.10.2016, 16:51 +0800 schrieb Ying Liu:
> >> >> Does the clip thing potentially change the user's request by force?
> >> >> For example, the user request an
If we know which connector was plugged/unplugged or
connected/disconnected, we can pass that information along to userspace
inside the uevent to reduce the amount of work userspace has to perform
after the event (i.e. instead of looking over all connectors, it can
just reprobe the affected one).
S
ll, should hit linux-next very soon.
thanks
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc:
On Fri, Oct 21, 2016 at 11:06:01AM +0300, Dan Carpenter wrote:
> submit_context() should return negative error codes and zero on success
> but by mistake we made it a bool. I've changed it to int. Also I made
> it static because this isn't referenced in any other files.
>
> This doesn't affect r
On Fri, Oct 21, 2016 at 4:18 PM, Philipp Zabel
wrote:
> Am Freitag, den 21.10.2016, 13:45 +0800 schrieb Ying Liu:
>> On Thu, Oct 20, 2016 at 9:29 PM, Philipp Zabel
>> wrote:
>> > Am Donnerstag, den 20.10.2016, 16:51 +0800 schrieb Ying Liu:
>> >> >> Does the clip thing potentially change the use
Hi Rob,
On Thu, Oct 20, 2016 at 04:17:14PM -0400, Rob Clark wrote:
>When you have a mix of planes that can scale and those that cannot
>scale, userspace really wants to have some hint to know which planes
>can definitely not scale so it knows to assign them to unscaled layers.
>I don't think it is
If we know which connector was plugged/unplugged or
connected/disconnected, we can pass that information along to userspace
inside the uevent to reduce the amount of work userspace has to perform
after the event (i.e. instead of looking over all connectors, it can
just reprobe the affected one).
v
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/09458b88/attachment.sig>
On Fri, 21 Oct 2016, Chris Wilson wrote:
> If we know which connector was plugged/unplugged or
> connected/disconnected, we can pass that information along to userspace
> inside the uevent to reduce the amount of work userspace has to perform
> after the event (i.e. instead of looking over all con
14114/
--
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/20161021/73df223e/attachment.html>
On Fri, Oct 21, 2016 at 10:14:21AM +0100, Chris Wilson wrote:
> If we know which connector was plugged/unplugged or
> connected/disconnected, we can pass that information along to userspace
> inside the uevent to reduce the amount of work userspace has to perform
> after the event (i.e. instead of
On Thu, Oct 20, 2016 at 10:19:02PM +0100, Robert Bragg wrote:
> @@ -1333,6 +1333,9 @@ int i915_cmd_parser_get_version(struct drm_i915_private
> *dev_priv)
>* 5. GPGPU dispatch compute indirect registers.
>* 6. TIMESTAMP register and Haswell CS GPR registers
>* 7. Allow MI_L
mething similar for AM335x too. And perhaps for
other SoCs too (AM4 comes to my mind).
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/20161021/4f710899/attachment.sig>
On Fri, Oct 21, 2016 at 12:46:53PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 21, 2016 at 10:14:21AM +0100, Chris Wilson wrote:
> > If we know which connector was plugged/unplugged or
> > connected/disconnected, we can pass that information along to userspace
> > inside the uevent to reduce the am
Hi Archit,
On Friday 21 Oct 2016 10:51:59 Archit Taneja wrote:
> On 10/19/2016 07:55 PM, Laurent Pinchart wrote:
> > The LVDS encoder driver is a DRM bridge driver that supports the
> > parallel to LVDS encoders that don't require any configuration. The
> > driver thus doesn't interact with the de
Hi Archit,
On Friday 21 Oct 2016 10:43:34 Archit Taneja wrote:
> On 10/19/2016 07:55 PM, Laurent Pinchart wrote:
> > The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be
> > controlled through a power save pin, and requires a power supply.
> > However, on most boards where the devi
On 10/21/2016 03:52 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Friday 21 Oct 2016 10:43:34 Archit Taneja wrote:
>> On 10/19/2016 07:55 PM, Laurent Pinchart wrote:
>>> The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be
>>> controlled through a power save pin, and requires a
Hi Gustavo,
On Thu, Oct 20, 2016 at 06:30:17PM -0200, Gustavo Padovan wrote:
>Hi Brian,
>
>2016-10-20 Brian Starkey :
>
>> Hi Gustavo,
>>
>> I notice your branch has the sync_file refcount change in, but this
>> doesn't seem to take account for that. Will you be dropping that
>> change to match th
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/d6517c9c/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/99ca608e/attachment.html>
On Thu, Oct 20, 2016 at 04:44:49PM +0300, Jani Nikula wrote:
> On Thu, 20 Oct 2016, Andrzej Hajda wrote:
> > Hi Jani,
> >
> > Forgive me late response.
> >
> > On 12.10.2016 16:28, Jani Nikula wrote:
> >> On Wed, 12 Oct 2016, Emil Velikov wrote:
> >>> On 11 October 2016 at 10:33, Jani Nikula
>
On Thu, Oct 20, 2016 at 10:45:34PM +0530, Sumit Semwal wrote:
> Hi Chris,
>
> Thanks for the patch!
>
> On 20 October 2016 at 17:38, Gustavo Padovan wrote:
> > 2016-10-20 Chris Wilson :
> >
> >> I plan to usurp the short name of struct fence for a core kernel struct,
> >> and so I need to rename
On Thu, Oct 20, 2016 at 05:09:52PM +0300, Nicolae Rosia wrote:
> Hi,
>
> On Thu, Oct 20, 2016 at 3:57 PM, David Weinehall wrote:
> >> > I get an udev event for unplugging, but there's no event generated for
> >> > plugging the monitor back in.
> >>
> >> Does it work on non-RT? Does it work on v4.
On Thu, Oct 20, 2016 at 05:00:35PM +0200, Takashi Iwai wrote:
> On Thu, 20 Oct 2016 16:56:04 +0200,
> Ville Syrjälä wrote:
> >
> > On Thu, Oct 20, 2016 at 04:39:52PM +0200, Takashi Iwai wrote:
> > > Since 4.7 kernel, we've seen the error messages like
> > >
> > > kernel: [TTM] Buffer eviction
fix that. Thanks!
Zhi, could you double check error path for elsp write?
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/8409966d/attachment.sig>
On Fri, Oct 21, 2016 at 09:58:45AM +0100, Brian Starkey wrote:
> Hi Rob,
>
> On Thu, Oct 20, 2016 at 04:17:14PM -0400, Rob Clark wrote:
> > When you have a mix of planes that can scale and those that cannot
> > scale, userspace really wants to have some hint to know which planes
> > can definitely
On Fri, Oct 21, 2016 at 10:14:21AM +0100, Chris Wilson wrote:
> If we know which connector was plugged/unplugged or
> connected/disconnected, we can pass that information along to userspace
> inside the uevent to reduce the amount of work userspace has to perform
> after the event (i.e. instead of
On Fri, 21 Oct 2016 14:30:32 +0200,
Daniel Vetter wrote:
>
> On Thu, Oct 20, 2016 at 05:00:35PM +0200, Takashi Iwai wrote:
> > On Thu, 20 Oct 2016 16:56:04 +0200,
> > Ville Syrjälä wrote:
> > >
> > > On Thu, Oct 20, 2016 at 04:39:52PM +0200, Takashi Iwai wrote:
> > > > Since 4.7 kernel, we've s
On Thu, Oct 20, 2016 at 12:50:02PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> There is now a new property called FENCE_FD attached to every plane
> state that receives the sync_file fd from userspace via the atomic commit
> IOCTL.
>
> The fd is then translated to a fence (that may
On Thu, Oct 20, 2016 at 05:05:30PM +0200, Takashi Iwai wrote:
> Since 4.7 kernel, we've seen the error messages like
>
> kernel: [TTM] Buffer eviction failed
> kernel: qxl :00:02.0: object_init failed for (4026540032, 0x0001)
> kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to
On Thu, Oct 20, 2016 at 12:50:03PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> If the event gets canceled we also need to put away the fence
> reference it holds.
>
> Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
I've broken my local dim scripts right now, so can't
On Thu, Oct 20, 2016 at 12:50:04PM -0200, Gustavo Padovan wrote:
> 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
On Thu, Oct 20, 2016 at 10:15:20PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 20, 2016 at 07:34:44PM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 20, 2016 at 01:55:38PM -0200, Gustavo Padovan wrote:
> > > 2016-10-20 Ville Syrjälä :
> > >
> > > > On Thu, Oct 20, 2016 at 12:50:05PM -0200, Gustav
On Fri, Oct 21, 2016 at 02:48:49PM +0200, Takashi Iwai wrote:
> On Fri, 21 Oct 2016 14:30:32 +0200,
> Daniel Vetter wrote:
> >
> > On Thu, Oct 20, 2016 at 05:00:35PM +0200, Takashi Iwai wrote:
> > > On Thu, 20 Oct 2016 16:56:04 +0200,
> > > Ville Syrjälä wrote:
> > > >
> > > > On Thu, Oct 20, 2
iving 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/20161021/da7aa9ff/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/5e9efde8/attachment.html>
On Fri, Oct 21, 2016 at 11:55:52AM +0100, Brian Starkey wrote:
> On Thu, Oct 20, 2016 at 06:30:17PM -0200, Gustavo Padovan wrote:
> > 2016-10-20 Brian Starkey :
> > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > > index 657a33a..b898604 100644
> > > > --- a/include/drm/drm_c
On Fri, Oct 21, 2016 at 4:58 AM, Brian Starkey wrote:
> Hi Rob,
>
> On Thu, Oct 20, 2016 at 04:17:14PM -0400, Rob Clark wrote:
>>
>> When you have a mix of planes that can scale and those that cannot
>> scale, userspace really wants to have some hint to know which planes
>> can definitely not scal
On Thu, Oct 20, 2016 at 12:50:01PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> Currently the Linux Kernel only have an implicit fencing mechanism, through
> reservation objects, in which the fences are attached directly to buffers
> operations and userspace is unaware of w
2016-10-21 Daniel Vetter :
> On Thu, Oct 20, 2016 at 10:15:20PM +0300, Ville Syrjälä wrote:
> > On Thu, Oct 20, 2016 at 07:34:44PM +0300, Ville Syrjälä wrote:
> > > On Thu, Oct 20, 2016 at 01:55:38PM -0200, Gustavo Padovan wrote:
> > > > 2016-10-20 Ville Syrjälä :
> > > >
> > > > > On Thu,
On Fri, Oct 21, 2016 at 02:45:41PM +0200, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 10:14:21AM +0100, Chris Wilson wrote:
> > If we know which connector was plugged/unplugged or
> > connected/disconnected, we can pass that information along to userspace
> > inside the uevent to reduce the amou
Hello,
On Fri, Oct 21, 2016 at 3:27 PM, Daniel Vetter wrote:
> So yeah, "upgrade" is very likely is.
I see...
i915.disable_power_well=0 seems to do the trick.
Is it safe to use? The kernel gets tainted because of this.
Regards,
Nicolae
On Fri, Oct 21, 2016 at 8:35 AM, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 09:58:45AM +0100, Brian Starkey wrote:
>> Hi Rob,
>>
>> On Thu, Oct 20, 2016 at 04:17:14PM -0400, Rob Clark wrote:
>> > When you have a mix of planes that can scale and those that cannot
>> > scale, userspace really wa
On Fri, Oct 21, 2016 at 02:30:32PM +0200, Daniel Vetter wrote:
> On Thu, Oct 20, 2016 at 05:00:35PM +0200, Takashi Iwai wrote:
> > On Thu, 20 Oct 2016 16:56:04 +0200,
> > Ville Syrjälä wrote:
> > >
> > > On Thu, Oct 20, 2016 at 04:39:52PM +0200, Takashi Iwai wrote:
> > > > Since 4.7 kernel, we'v
plication/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/edfcd1cb/attachment.sig>
After hotplug notification, userspace has to reprobe all connectors to
detect any changes. This can be expensive (some outputs may require time
consuming load detection, some outputs may simply be slow to respond)
and not all outputs need to be checked everytime. The kernel is usually
in a very goo
We have reached the era where monitor bandwidths now exceed 31bits in
frequency calculations, though as we stored them in kHz units we are
safe from overflow in the modelines for some time.
[ 48.723720] UBSAN: Undefined behaviour in
../drivers/gpu/drm/drm_modes.c:325:49
[ 48.726943] signed in
On Fri, Oct 21, 2016 at 10:15 AM, Chris Wilson
wrote:
> We have reached the era where monitor bandwidths now exceed 31bits in
> frequency calculations, though as we stored them in kHz units we are
> safe from overflow in the modelines for some time.
>
> [ 48.723720] UBSAN: Undefined behaviour i
On Fri, Oct 21, 2016 at 04:27:38PM +0800, Zhenyu Wang wrote:
> On 2016.10.21 11:06:01 +0300, Dan Carpenter wrote:
> > submit_context() should return negative error codes and zero on success
> > but by mistake we made it a bool. I've changed it to int. Also I made
> > it static because this isn't
On 10/21/2016 04:05 PM, Krzysztof Kozlowski wrote:
> The samsung,power-domain property is obsolete since commit 0da658704136
> ("ARM: dts: convert to generic power domain bindings for exynos DT").
> Replace it with generic one.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Sylwester Nawroc
On Wed, Oct 19, 2016 at 1:48 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> fence referencing was out of balance. It was not taking any ref to the
> fence at creating time, but it was putting a reference when freeing the
> sync file.
>
> This patch fixes the balancing issue by getting a r
Two functions in the newly added gvt render code are obviously
broken, as they reference a variable without initialization and
don't reference another variable at all:
drivers/gpu/drm/i915/gvt/render.c: In function âintel_gvt_load_render_mmioâ:
drivers/gpu/drm/i915/gvt/render.c:148:13: error:
On 10/21/2016 11:36 AM, Sylwester Nawrocki wrote:
> On 10/21/2016 04:05 PM, Krzysztof Kozlowski wrote:
>> The samsung,power-domain property is obsolete since commit 0da658704136
>> ("ARM: dts: convert to generic power domain bindings for exynos DT").
>> Replace it with generic one.
>>
>> Signed-off
The newly added gvt code produces lots of serious warnings and errors
when either built on 32-bit x86, or built with ACPI disabled, e.g.
drivers/gpu/drm/i915/gvt/gtt.c: In function âread_pte64â:
drivers/gpu/drm/i915/gvt/gtt.c:277:2: error: left shift count >= width of type
[-Werror]
drivers/g
https://bugzilla.kernel.org/show_bug.cgi?id=178281
--- Comment #9 from fin4478 at hotmail.com ---
Now when I am playing TR 2013 with wine-1.9.21 (Staging) csmt enabled, gaming
will will hang my machine when having fast actions. 10-20 minutes gaming is
possible without rebooting.
Using 64-bit ubunt
Hi,
Sorry, I hit another couple of bugs that originated from my hastebin
patch - see below.
On Thu, Oct 20, 2016 at 12:50:05PM -0200, 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.
s approach seems to have been working well for quite a long time now.
- Robert
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/2f58bebf/attachment.html>
On Tue, Sep 27, 2016 at 01:22:48PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 27, 2016 at 12:54:46PM +0300, Joonas Lahtinen wrote:
> > On ma, 2016-09-26 at 19:30 +0300, ville.syrjala at linux.intel.com wrote:
> > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > >
> > >
On Mon, Sep 26, 2016 at 07:30:53PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> 0 isn't a valid rotation property value, so let's set the initial value
> of the property to BIT(DRM_ROTATE_0) instead.
>
> In the same vein, we must always have at leat one angle as pa
On Tue, Sep 27, 2016 at 12:58:49PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-09-26 at 19:30 +0300, ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrjälä
> >
> > On certain platforms not all planes support the same set of
> > rotations/reflections, so let's use the per-plane proper
Hi Dave,
Misc bug fixes for radeon and amdgpu.
The following changes since commit 26beaee9bb07be20cc641c1251152e280e80f54e:
Merge branch 'drm-etnaviv-fixes' of git://git.pengutronix.de/lst/linux into
drm-fixes (2016-10-21 13:27:55 +1000)
are available in the git repository at:
git://peopl
On Fri, Oct 21, 2016 at 06:26:54PM +0200, Daniel Vetter wrote:
> On Mon, Sep 26, 2016 at 07:30:53PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > 0 isn't a valid rotation property value, so let's set the initial value
> > of the property to BIT(DRM_ROTATE_0)
On Fri, Oct 21, 2016 at 02:42:12PM +0100, Chris Wilson wrote:
> After hotplug notification, userspace has to reprobe all connectors to
> detect any changes. This can be expensive (some outputs may require time
> consuming load detection, some outputs may simply be slow to respond)
> and not all out
From: Rob Herring
Fixes crashes in Mesa on platform device, which expected *device to
have a device when 0 was returned.
(code from a paste by Rob, commit message by anholt)
Signed-off-by: Eric Anholt
---
xf86drm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
in
Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).
Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.
Signed-off-by: Bartosz Golaszewski
---
drivers/
On Fri, Oct 21, 2016 at 02:42:12PM +0100, Chris Wilson wrote:
> After hotplug notification, userspace has to reprobe all connectors to
> detect any changes. This can be expensive (some outputs may require time
> consuming load detection, some outputs may simply be slow to respond)
> and not all out
On Fri, Oct 21, 2016 at 1:12 PM, Eric Anholt wrote:
> From: Rob Herring
>
> Fixes crashes in Mesa on platform device, which expected *device to
> have a device when 0 was returned.
>
> (code from a paste by Rob, commit message by anholt)
>
> Signed-off-by: Eric Anholt
Reviewed-by: Alex Deucher
glxgears was spamming this 12 times at startup because of Mesa's
probing of the DRM device code, which doesn't support platform
devices.
Signed-off-by: Eric Anholt
---
xf86drm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 9b52889e4cef..52add5e441d7 100644
---
On 21 October 2016 at 18:12, Eric Anholt wrote:
> From: Rob Herring
>
> Fixes crashes in Mesa on platform device, which expected *device to
> have a device when 0 was returned.
>
> (code from a paste by Rob, commit message by anholt)
>
> Signed-off-by: Eric Anholt
Reviewed-by: Emil Velikov
Tha
On Fri, Oct 21, 2016 at 1:12 PM, Eric Anholt wrote:
> glxgears was spamming this 12 times at startup because of Mesa's
> probing of the DRM device code, which doesn't support platform
> devices.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Alex Deucher
> ---
> xf86drm.c | 2 --
> 1 file change
On Thu, 20 Oct 2016 16:56:44 +0530
Archit Taneja wrote:
> > Please show _technically_ how this would work. I want to see code or
> > pseudo-code illustrating how a "foreign" DRM encoder could be used with
> > either dw-hdmi or tda998x, because right now I can't see any way that
> > could work.
>
On Fri, Oct 21, 2016 at 04:21:53PM +0300, Nicolae Rosia wrote:
> Hello,
>
> On Fri, Oct 21, 2016 at 3:27 PM, Daniel Vetter wrote:
> > So yeah, "upgrade" is very likely is.
> I see...
>
> i915.disable_power_well=0 seems to do the trick.
> Is it safe to use? The kernel gets tainted because of this
On Fri, Oct 21, 2016 at 01:57:28PM +0100, Chris Wilson wrote:
> On Fri, Oct 21, 2016 at 02:30:32PM +0200, Daniel Vetter wrote:
> > On Thu, Oct 20, 2016 at 05:00:35PM +0200, Takashi Iwai wrote:
> > > On Thu, 20 Oct 2016 16:56:04 +0200,
> > > Ville Syrjälä wrote:
> > > >
> > > > On Thu, Oct 20, 20
n be cleaned up.
>
> > + dev_priv->perf.oa.oa_buffer.addr = i915_gem_object_pin_map(bo,
> map);
> > + if (IS_ERR(dev_priv->perf.oa.oa_buffer.addr)) {
> > + ret = PTR_ERR(dev_priv->perf.oa.oa_buffer.addr);
> > + goto err_unpin;
> > + }
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
Thanks,
- Robert
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/f35d133f/attachment.html>
On Fri, Oct 21, 2016 at 09:26:22AM -0400, Rob Clark wrote:
> On Fri, Oct 21, 2016 at 8:35 AM, Daniel Vetter wrote:
> > On Fri, Oct 21, 2016 at 09:58:45AM +0100, Brian Starkey wrote:
> >> Hi Rob,
> >>
> >> On Thu, Oct 20, 2016 at 04:17:14PM -0400, Rob Clark wrote:
> >> > When you have a mix of plan
On Fri, Oct 21, 2016 at 10:22:04AM -0400, Alex Deucher wrote:
> On Fri, Oct 21, 2016 at 10:15 AM, Chris Wilson
> wrote:
> > We have reached the era where monitor bandwidths now exceed 31bits in
> > frequency calculations, though as we stored them in kHz units we are
> > safe from overflow in the
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.
v2:
Make sure to initialize ->specific_ctx_id when opening, withou
On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
(sorry, I lost your original mail)
> >>> DRM bridges indeed don't create encoders. That task is left to the display
> >>> driver. The reason is the same as above: bridges can be chained (including
> >>> with an internal
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/e60cc92d/attachment.html>
From: Ville Syrjälä
Remainder of the patches from the per-plane rotation series [1]. Rebased
and also Rob's r-b picked up from [2].
[1] https://lists.freedesktop.org/archives/dri-devel/2016-September/119451.html
[2] https://lists.freedesktop.org/archives/dri-devel/2016-September/119468.html
V
From: Ville Syrjälä
The global mode_config.rotation_property is going away, switch over to
per-plane rotation_property.
v2: Drop the BIT()
Cc: Rob Clark
Cc: Jilai Wang
Cc: Archit Taneja
Signed-off-by: Ville Syrjälä
Reviewed-by: Rob Clark
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |
From: Ville Syrjälä
Since the hardware can apparently do both X and Y reflection, we
can advertize also 180 degree rotation as thats just X+Y reflection.
v2: Drop the BIT()
Cc: Rob Clark
Cc: Jilai Wang
Cc: Archit Taneja
Signed-off-by: Ville Syrjälä
Reviewed-by: Rob Clark
---
drivers/g
From: Ville Syrjälä
Using == to check for 180 degree rotation only works as long as the
reflection bits aren't set. That will change soon enough for CHV, so
let's stop doing things the wrong way.
v2: Drop the BIT()
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
Reviewed-by: Joonas
From: Ville Syrjälä
The primary and sprite planes on CHV pipe B support horizontal
mirroring. Expose it to the world.
Sadly the hardware ignores the mirror bit when the rotate bit is
set, so we'll have to reject the 180+X case.
v2: Drop the BIT()
v3: Pass dev_priv instead of dev to IS_CHERRYV
From: Ville Syrjälä
Move the plane control register rotation setup away from the
coordinate munging code. This will result in neater looking
code once we add reflection support for CHV.
v2: Drop the BIT(), drop some usless parens,
Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
Rev
From: Ville Syrjälä
Now that all drivers have been converted over to the per-plane rotation
property, we can just nuke the global rotation property.
v2: Rebase due to BIT(),__builtin_ffs() & co.
Deal with superfluous code shuffling
Signed-off-by: Ville Syrjälä
Reviewed-by: Joonas Lahti
Hi all,
So here's all the bits I think we need for:
- split out drm-misc.git repo
- rolling model in drm-misc to avoid the merge window, like for drm-intel
branches.
- split out rerere stuff into a shared drm-tip.git repo
- sharing .git metadata using git worktrees.
Conversion howto:
1. Update
Just maybe a bit more visibility, the scripts are growing.
Signed-off-by: Daniel Vetter
---
TODO | 27 +++
dim | 17 -
qf | 11 ---
3 files changed, 27 insertions(+), 28 deletions(-)
create mode 100644 TODO
diff --git a/TODO b/TODO
new file mo
Exits script to annoy people roughly every 100th time ...
Also switch to the magic @{upstream} reference, in case the remote is
not called origin (which is pretty normal in case of using git
worktree).
Signed-off-by: Daniel Vetter
---
dim | 6 +-
1 file changed, 5 insertions(+), 1 deletion(
Signed-off-by: Daniel Vetter
---
dim | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/dim b/dim
index 192d6ee10838..2601bb7dbbad 100755
--- a/dim
+++ b/dim
@@ -102,12 +102,17 @@ DRY=
FORCE=
HELP=
+function echoerr
+{
+ echo "$@" >&2
+}
+
function
If available by default. This saves quite a pile of disk-space that
imo making it the default is justified.
Note that this will break the rebuild-nightly script for now,
follow-up patches will fix that.
Signed-off-by: Daniel Vetter
---
dim | 23 ---
1 file changed, 16 insert
1 - 100 of 135 matches
Mail list logo
