ons,
successfully? I mean, I'm back on this current build of mesa, and it's just a
mess.
--
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/
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/79b31175/attachment.html>
Allows userspace to detect shared fences are supported.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_drm.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Dave, can you include this in drm-next? It should allow me to optimize
nouveau's vdpau decoding a bit.
di
Dave,
On 03 Sep 08:08 AM, Johannes Pointner wrote:
> 2014-09-02 14:51 GMT+02:00 Ezequiel Garcia :
> > Dave,
> >
> > I'm resending this, hoping it can be pushed for v3.18. The patchset was
> > ready for v3.17, but it got no maintainer feedback or review. Maybe it fell
> > through some crack?
> >
>
On 15 September 2014 17:50, Ezequiel Garcia
wrote:
> Dave,
>
> On 03 Sep 08:08 AM, Johannes Pointner wrote:
>> 2014-09-02 14:51 GMT+02:00 Ezequiel Garcia > vanguardiasur.com.ar>:
>> > Dave,
>> >
>> > I'm resending this, hoping it can be pushed for v3.18. The patchset was
>> > ready for v3.17, but
he assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/fde6d031/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/b56bcc06/attachment.html>
On Sun, Sep 14, 2014 at 12:36:43PM +0200, Christian K?nig wrote:
> Yeah, right. Providing the fd to reassign to a fence would indeed reduce the
> create/close overhead.
>
> But it would still be more overhead than for example a simple on demand
> growing ring buffer which then uses 64bit sequence
On Sat, Sep 13, 2014 at 06:25:54PM +0200, Mario Kleiner wrote:
> The current drm-next misses Ville's original Patch 14/19, the one i first
> objected, then objected to my objection. It is needed to avoid actual
> regressions. Attached a trivially rebased (v2) of Ville's patch to go on top
> of drm-
Hi Dave,
Here's the updated topic/core-stuff pull request with the two patches
already merged into drm-fixes dropped.
Cheers, Daniel
The following changes since commit edbaae5a5cab89de0e64b8c03ebd9a8d5d266550:
Merge tag 'topic/vblank-rework-2014-09-12' of
git://anongit.freedesktop.org/drm-i
On Fri, Sep 12, 2014 at 07:49:25PM -0400, Rodrigo Vivi wrote:
> In some cases like when PSR just got enabled the panel need more vblank
> times to calculate CRC. I figured that out with the new PSR test cases
> facing some cases that I had a green screen but a blank CRC. Even with
> 2 vblank waits
Hi Dave,
Could you please pull the following changes for v3.18 ?
Commit "drm/rcar-du: Use struct videomode in platform data" touches board code
in arch/arm/mach-shmobile. There is, to the best of my knowledge, no risk of
conflict for v3.18. Simon, are you fine with getting those changes merged
on dmesg question as soon as
i'm home.
--
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/20140915/017bd1ff/attachment.html>
Hi Dave,
The following changes since commit 98faa78ce7f1f986e11e7805d31b409782a6d2d4:
Merge tag 'topic/drm-header-rework-2014-09-12' of
git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-13 07:01:49
+1000)
are available in the git repository at:
git://linuxtv.org/pinchartl/fbd
happening.
--
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/20140915/2556e768/attachment.html>
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/093aca8d/attachment.html>
is 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/20140915/67ecc8af/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/f3fee2c0/attachment-0001.html>
On Mon, Sep 15, 2014 at 12:31:54PM +0300, Laurent Pinchart wrote:
> Hi Dave,
>
> The following changes since commit 98faa78ce7f1f986e11e7805d31b409782a6d2d4:
>
> Merge tag 'topic/drm-header-rework-2014-09-12' of
> git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-13 07:01:49
> +1
On Sat, 13 Sep 2014, Rodrigo Vivi wrote:
> In some cases like when PSR just got enabled the panel need more vblank
> times to calculate CRC. I figured that out with the new PSR test cases
> facing some cases that I had a green screen but a blank CRC. Even with
> 2 vblank waits on kernel + 2 vblank
Android-x86 4.0-r1 (32 bit) have problems with x86_64 kernel when he
trying to use a radeon kms. The following change correct a problem:
drivers/gpu/drm/radeon_kms.c (function radeon_info_ioctl):
- value_ptr = (uint32_t *)((unsigned long)info->value);
+ value_ptr = (uint32_t *)((unsigned)info->va
Hi Daniel,
On Monday 15 September 2014 11:44:23 Daniel Vetter wrote:
> On Mon, Sep 15, 2014 at 12:31:54PM +0300, Laurent Pinchart wrote:
> > Hi Dave,
> >
> > The following changes since commit
98faa78ce7f1f986e11e7805d31b409782a6d2d4:
> > Merge tag 'topic/drm-header-rework-2014-09-12' of
> >
Bunch of things amiss:
- Updating crtc->cursor_x/y was done without any locking. Spotted by
David Herrmann.
- Dereferencing crtc->cursor->fb was using the wrong lock, should take
the crtc lock.
- Grabbing _all_ modeset locks torpedoes the reason why we added
fine-grained locks originally: Cur
Am 15.09.2014 um 12:09 schrieb Sergey Korshunoff:
> Android-x86 4.0-r1 (32 bit) have problems with x86_64 kernel when he
> trying to use a radeon kms. The following change correct a problem:
>
> drivers/gpu/drm/radeon_kms.c (function radeon_info_ioctl):
>
> - value_ptr = (uint32_t *)((unsigned long
This replicates what we've done in i915 in
commit 31e4b89acbd7b19c9a8557e6e660a583a0b97daa
Author: Damien Lespiau
Date: Mon Aug 18 13:51:00 2014 +0100
drm/i915: Print the pipe on which the vblank wait times out
to make sure that when we switch i915 to drm_wait_one_vblank that the
debug ou
On Mon, Sep 15, 2014 at 02:29:52PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Monday 15 September 2014 11:44:23 Daniel Vetter wrote:
> > On Mon, Sep 15, 2014 at 12:31:54PM +0300, Laurent Pinchart wrote:
> > > Hi Dave,
> > >
> > > The following changes since commit
> 98faa78ce7f1f986e11e7
On Mon, Sep 15, 2014 at 02:05:56PM +0200, Daniel Vetter wrote:
> This replicates what we've done in i915 in
>
> commit 31e4b89acbd7b19c9a8557e6e660a583a0b97daa
> Author: Damien Lespiau
> Date: Mon Aug 18 13:51:00 2014 +0100
>
> drm/i915: Print the pipe on which the vblank wait times out
>
On Fri, Sep 12, 2014 at 01:48:34PM +0100, Lionel Landwerlin wrote:
> This is getting bigger than expected. Adding the locking that Chris
> suggested on IRC.
>
> Thanks for taking time to review Chris.
I'm happy with this series,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Sour
On Mon, Sep 15, 2014 at 02:12:25PM +0100, Chris Wilson wrote:
> On Fri, Sep 12, 2014 at 01:48:34PM +0100, Lionel Landwerlin wrote:
> > This is getting bigger than expected. Adding the locking that Chris
> > suggested on IRC.
> >
> > Thanks for taking time to review Chris.
>
> I'm happy with this
Hi all,
So I've tried to figure out a way how to clear up our irq setup mess, but
instead only managed to get sidetracked on a spinlock usage review.
Review highly welcome.
Cheers, Daniel
Daniel Vetter (11):
drm/i915: Clarify event_lock locking, process context
drm/i915: Clarify event_lock
It's good practice to use the more specific versions for irq save
spinlocks both as executable documentation and to enforce saner
design. The _irqsave version really should only be used if the calling
context is unknown and there's a good reason to call a function from
all kinds of places.
This is
Now we tackle the functions also called from interrupt handlers.
- intel_check_page_flip is exclusively called from irq handlers, so a
plain spin_lock is all we need. In i915_irq.c we have the convention
to give all such functions an _irq_handler postfix, but that would
look strange and als
i915_capture_error_state can be called from all kinds of contexts, so
needs the full irqsave dance. But the other two places to grab and
release the error state are only called from process context. So
simplify them to the plaine _irq spinlock versions to clarify the
locking semantics.
Cc: Mika Ku
->detect callbacks are only ever called from process context, and
there's no fancy nesting going on here. So plain _irq spinlock
variants is what we want.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_tv.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a
Work functions are in process context, so plain _irq spinlock variants
is all we need.
The hpd reenable work didn't follow the _work/_work_func postfix
naming scheme, so adjust that while at it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 28
All the interrupt setup/teardown hooks are always run from plain
process context. So again just the _irq variant is good enough.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 42 ++---
1 file changed, 18 insertions(+), 24 deletions(-)
dif
Grab bag for all the special cases:
- i9xx_check_fifo_underruns is only called from crtc_enable hooks,
i.e. process context.
- i915_enable_asle_pipestat is only called from interrupt postinstall
hooks. So again process context.
- gen8_irq_power_well_post_enable is called from the runtime pm cod
irq handlers always run with interrupts locally disabled, so
plain spinlocks is all we need. I've also reviewed again that they
all follow the _irq_handler postfix convention.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 15 ++-
1 file changed, 6 insertions(+),
Originally the irq safe spinlock was required because of asle
interrupts. But since
commit 7bd688cd66db93f6430f6e2b3145ee5686daa315
Author: Jani Nikula
Date: Fri Nov 8 16:48:56 2013 +0200
drm/i915: handle backlight through chip specific functions
there's no need for this any more. So swit
The ->queue_flip callback is always called from process context, so
plain _irq spinlock variants are enough.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/driv
Only one place looked in need of a bit of polish: hsw_restore_lcpll.
It's used by the runtime pm code and hence is always called from
process context. No irq flag saving required.
Another thing I've stumbled over is that we might need to add a
raw forcewake_get/put helpers which don't grab a runti
Hi Dave,
So final feature pull request for 3.18. QA isn't really done yet with the
manul testing, but this help up a week of soaking so should be fairly
ok-ish. And I think holding up merging doesn't really help anyone,
especially since I want to rebase my 3.19 queue on top of drm-next with
all th
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/a61f38b8/attachment.html>
radeon-info-compat.patch
Type: application/octet-stream
Size: 2589 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/ba28c872/attachment.obj>
Hi Sean,
On Monday 18 August 2014 16:29:24 Sean Cross wrote:
> Hi,
>
> We've got an IT6251 LVDS -> eDP bridge chip we're hanging off of a
> dual-lane LVDS port on an i.MX6. We have a driver we're using
> internally that's little more than a series of register pokes to boot
> the chip, but I'd li
Hi Sergey,
that probably works, but a compat function is the wrong approach here.
The definition of the field was always 64bit and when userspace fails to
properly set the upper 32bits than userspace needs to get fixed, not the
kernel.
Can you try to figure out where the random bits in the upp
https://bugzilla.kernel.org/show_bug.cgi?id=83461
kb at spatium.org changed:
What|Removed |Added
Regression|No |Yes
--- Comment #2 from kb at spatium.
Hi Ajay,
Thank you for the patch.
I think we're moving in the right direction, but we're not there yet.
On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
> This patch tries to seperate drm_bridge implementation
> into 2 parts, a drm part and a non_drm part.
>
> A set of helper functions are d
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/004b9d21/attachment-0001.html>
Pageflipping currently causes some inconsistencies that lead to
crashes. Just run an app that causes a CRTC pageflip in a raw X session
and check that it exits cleanly and can be restarted - you'll see
crashes like:
Unable to handle kernel NULL pointer dereference at virtual address 0334
PC i
On 15 Sep 05:59 PM, Dave Airlie wrote:
> On 15 September 2014 17:50, Ezequiel Garcia
> wrote:
> > Dave,
> >
> > On 03 Sep 08:08 AM, Johannes Pointner wrote:
> >> 2014-09-02 14:51 GMT+02:00 Ezequiel Garcia >> vanguardiasur.com.ar>:
> >> > Dave,
> >> >
> >> > I'm resending this, hoping it can be pu
https://bugzilla.kernel.org/show_bug.cgi?id=83461
--- Comment #3 from Alex Deucher ---
Can you try it to be sure to at least narrow down what the problem might be?
--
You are receiving this mail because:
You are watching the assignee of the bug.
fine, but Denys problem will appear
again...
--
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/20140915/4848bcff/attachment.html>
he bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/fe06a764/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/c7d6b43e/attachment.html>
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/df89c51c/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/13f828d0/attachment.html>
In some cases like when PSR just got enabled the panel need more vblank
times to calculate CRC. I figured that out with the new PSR test cases
facing some cases that I had a green screen but a blank CRC. Even with
2 vblank waits on kernel + 2 vblank waits on test case.
So let's give up to 6 vblank
g) it behaves just like Chrome
(hangs).
--
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/20140915/aa96016c/attachment-0001.html>
+ };
> + };
> +};
>
Looks good to me.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/2aca4f4a/attachment.sig>
Now that we have moved to generic phy based bindings,
we don't need to have any code related to older dptx-phy.
Nobody is using this dptx-phy anymore, so removing the
same.
Signed-off-by: Vivek Gautam
Cc: Jingoo Han
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 58 +++-
These patches are based on 'for-next' branch of kgene's linux-samsung tree.
Refactoring the exynos-dp-video phy to use pmu-system-controller handle
and access the register using mfd-syscon and regmap.
Simultaneously, removing the support for older dptx-phy, since it's obsolete
now and noone uses i
DP PHY now require pmu-system-controller to handle PMU register
to control PHY's power isolation. Adding the same to dp-phy
node.
Signed-off-by: Vivek Gautam
Cc: Jingoo Han
---
arch/arm/boot/dts/exynos5250.dtsi |2 +-
arch/arm/boot/dts/exynos5420.dtsi |4 ++--
2 files changed, 3 inserti
On Sun, 14 Sep 2014 18:40:13 +0200
Fabian Frederick wrote:
> Small patchset using container_of instead of casting on first structure
> member address.
Why. Container_of is useful for random offsets but its just convoluting
and confusing code which is designed with the fields intentionally at th
The Patch is PASSED by Lenovo side.
Tested-by: Steven You2 Liang
-Original Message-
From: YC Chen [mailto:yc_c...@aspeedtech.com]
Sent: Thursday, August 28, 2014 5:11 PM
To: dri-devel at lists.freedesktop.org
Cc: Kuo-Hsiang Chou; airlied at redhat.com; eich at suse.com; YC Chen
Subject:
Currently the DP_PHY_ENABLE register is mapped in the driver,
and accessed to control power to the PHY.
With mfd-syscon and regmap interface available at our disposal,
it's wise to use that instead of using a 'reg' property for the
controller and allocating a memory resource for that.
To facilitat
> On 15 September 2014 at 01:13 One Thousand Gnomes lxorguk.ukuu.org.uk>
> wrote:
>
>
> On Sun, 14 Sep 2014 18:40:13 +0200
> Fabian Frederick wrote:
>
> > Small patchset using container_of instead of casting on first structure
> > member address.
>
> Why. Container_of is useful for random offse
67 matches
Mail list logo
