Thanks Sean,
On 3 September 2013 20:15, Sean Paul wrote:
> A few comments.
>
> On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
> wrote:
>> Exynos hdmiphy operations and configs are kept inside
>> the hdmi driver. Hdmiphy related code is tightly coupled
>> with hdmi IP driver.
>>
>> This patche mo
On Tue, 2013-09-03 at 19:50 +0200, Daniel Vetter wrote:
> On Tue, Sep 3, 2013 at 7:37 PM, Kamal Mostafa wrote:
> > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
> >
> > Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
> > ("drm/i915: quirk no PCH_PWM_ENABLE for
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
("drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight") so provide a
boot param to inhibit the quirk, or force it on.
i915.disable_pch_pwm can be set to
-1:
Hi Tomi,
On Monday 02 September 2013 11:42:00 Tomi Valkeinen wrote:
> On 09/08/13 20:14, Laurent Pinchart wrote:
> > The Common Display Framework (CDF) splits display devices in entities
> > that interact through an abstract API. Each entity is managed by its own
> > driver independently of the ot
Hi!
I was happily using X... and then screen froze. Mouse still
moves. Switching to text console still worked, good. It is first time
in a while, normally this machine works well.
i915_error_state is attached.
Any ideas?
Pavel
Ini
On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
>> The code expects non-VRAM mem nodes to have a pages list. If that's not
>> set, it will do a null deref down the line. Warn on that condition and
>> return an error.
>>
>> See https://bugs.freede
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> There are a lot of places that allocate multiples of 1000,
> but do not set alignment correctly and still require this
> alignment implicitly or explicitly.
This is wrong. Where are the places you think you need this?
Ben.
> ---
> dri
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> I was getting a order 4 allocation failure from kmalloc when testing some game
> after a few days uptime with some suspend/resumes. For big allocations vmalloc
> should be used instead.
I've picked up this patch with a minor modification
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> I don't see why the display engine would need write access to the entirety of
> vram, when read-only access is enough.
Meh, this really doesn't matter... We're doing the same setup as
nvidia do here, and I see no good reason not to.
>
>
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
wrote:
> This increases the chance slightly that recovery from lockup can happen
> succesfully.
I'd *really* love to see proof of this. When channels die, all
outstanding fences are marked as signalled. This should do absolutely
nothing...
>
>
Each dma-buf has an associated size and it's reasonable for userspace
to want to know what it is.
Since userspace already has an fd, expose the size using the
size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0);
idiom.
v2: Added Daniel's sugeested documentation, with minor fixups
Signed-off-by
On Fri, Aug 30, 2013 at 5:11 PM, Lucas Stach wrote:
> Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
>> On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin wrote:
>> > On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
>> >> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin
>> >> wrote:
>>
If gpu locks up with the rptr shortly beyond the wrap-around point in
the ringbuffer, because the rptr was not reset (but wptr is, by virtue
of resetting rb->cur), we could end up in a scenario where we think
there is not enough space in the ringbuffer for the next cmds. And
since the CP won't res
The userspace API already had everything needed to handle read vs write
synchronization. This patch actually bothers to hook it up properly, so
that we don't need to (for example) stall on userspace read access to a
buffer that gpu is also still reading.
Signed-off-by: Rob Clark
---
drivers/gpu
On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst
wrote:
> Op 15-07-13 08:05, Ben Skeggs schreef:
>> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
>> wrote:
>>> I have no idea what this bogus restriction on placement is, but it breaks
>>> decoding 1080p
>>> VDPAU at boot speed. With this
On Sat, Aug 24, 2013 at 3:03 AM, Ilia Mirkin wrote:
> i2c_bit_add_bus can call the pre_xfer function, which expects the func
> pointer to be set. Pass in func to the port creation logic so that it is
> set before i2c_bit_add_bus.
Merged, thanks!
Ben.
>
> See https://bugs.freedesktop.org/show_bug
Hi Daniel,
This morning after fetching the drm-intel-fixes tree, I have discovered
that you have just added a whole set of patches on top of Dave's drm tree
and made that the drm-intel-fixes tree. I understood that this tree was
for fixes to Linus' tree for the current release cycle. Given that
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #12 from Alexandre Demers ---
Created attachment 85157
--> https://bugs.freedesktop.org/attachment.cgi?id=85157&action=edit
Cayman 6950 XFX vbios
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #11 from Alexandre Demers ---
So, after getting out at different points from ni_dpm_set_power_state(), it
seems I can go down to ni_power_control_set_level() without problem. However,
if I move to the next call which is ret = ni_dpm_f
https://bugs.freedesktop.org/show_bug.cgi?id=68775
Shawn Starr changed:
What|Removed |Added
Attachment #84943|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=68775
--- Comment #2 from Shawn Starr ---
Created attachment 85154
--> https://bugs.freedesktop.org/attachment.cgi?id=85154&action=edit
GPU Reset information + userspace errors from reset
GPU Reset information + userspace errors from reset
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #100 from Alex Deucher ---
(In reply to comment #99)
> > Also, can you get a copy of the dmesg output from the driver after it loads?
> > Try booting into a non-X runlevel without loading radeon (either blacklist
> > it, or set radeon
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #101 from Alex Deucher ---
(In reply to comment #96)
> Not so fast fellas. Recently checked 3.11RC7 and DRM-Next (current). The
> result is the same: it still can't boot with my Radeon HD 2600 XT :(
Does disabling aspm help? `radeon
This provides a connector property to enable/disable hdmi
audio on the fly. The default is disabled, but you can select
auto (let the driver detect an audio capable monitor and enable it)
or enabled (force audio enabled). This also enables audio by
default so you no longer need a module parameter
On Tue, Sep 03, 2013 at 05:48:48PM +0300, Pasi Kärkkäinen wrote:
> > > Not it really isn't appropriate..
> > >
> > > You'd have to call call nouveau_vm_map_sg_table instead, the only
> > > place that doesn't handle that correctly
> > > is where it's not expected to be called.
>
On 08/30/2013 01:24 PM, Kumar Gala wrote:
>
> On Aug 30, 2013, at 10:25 AM, Thierry Reding wrote:
>
>> Add a driver for simple panels. Such panels can have a regulator that
>> provides the supply voltage and a separate GPIO to enable the panel.
>> Optionally the panels can have a backlight associ
On Tue, Sep 3, 2013 at 7:37 PM, Kamal Mostafa wrote:
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
>
> Some BIOS configurations of Dell XPS13 are adversely affected by e85843b
> ("drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight") so provide a
> boot param to inhibit the q
On 08/30/2013 09:25 AM, Thierry Reding wrote:
> Add a driver for simple panels. Such panels can have a regulator that
> provides the supply voltage and a separate GPIO to enable the panel.
> Optionally the panels can have a backlight associated with them so it
> can be enabled or disabled according
https://bugs.freedesktop.org/show_bug.cgi?id=68901
Priority: medium
Bug ID: 68901
Keywords: regression
Assignee: dri-devel@lists.freedesktop.org
Summary: wine/3DMark2001: shader generation fails
Severity: normal
Classification: Unc
https://bugs.freedesktop.org/show_bug.cgi?id=68857
--- Comment #1 from Tom Stellard ---
I'm having a little trouble figuring out the build system for this suite, could
you pick one of the failing examples and give instructions for how to build and
execute it?
Also, what version of Mesa and LLVM
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Exynos hdmiphy operations and configs are kept inside
> the hdmi driver. Hdmiphy related code is tightly coupled
> with hdmi IP driver.
>
> This patche moves hdmiphy related code to hdmiphy driver.
s/patche/patch
> It will h
On Tue, Sep 03, 2013 at 04:34:56PM +0200, Maarten Lankhorst wrote:
> Op 03-09-13 16:20, Pasi Kärkkäinen schreef:
> > On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote:
> >> Op 28-08-13 08:29, Pasi Kärkkäinen schreef:
> >>> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wr
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> hdmiphy is a dummy clock which actually controls the PMU bit
> to enable/disbale hdmiphy (before CCF). This clock is cleaned
s/disbale/disable/
> from the hdmi driver.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_h
Hi Lars-Peter,
(CC'ing Hans Verkuil and the dri-devel and linux-media mailing lists)
On Monday 02 September 2013 17:09:11 Lars-Peter Clausen wrote:
> On 09/02/2013 05:01 PM, Laurent Pinchart wrote:
> > On Monday 02 September 2013 16:43:25 Lars-Peter Clausen wrote:
> >> On 09/02/2013 04:15 PM, Lau
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Exynos5420 hdmiphy device is a platform device, unlike
> predecessor SoCs where it used to be a I2C device. This
> support is added to the hdmiphy driver.
>
Stuffing a platform driver in the same place as your i2c driver seems
weird. I think
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Before hdmiphy operation like config, start etc, hdmiphy
> bit in PMU block should be enabled. Earlier this happens
> in hdmi drvier through a dummy "hdmiphy" clock.
s/drvier/driver/
>
> Signed-off-by: Rahul Sharma
> ---
> .../devicetree/b
Hi,
I have not received any feedback on this patch.
It has been pending since the end of June (first post).
Can I get an estimate when it will be included/accepted?
Thanks,
Benoit
On Fri, Aug 23, 2013 at 11:13:56AM -0500, Benoit Parrot wrote:
> Add LCDC device node in DT for am33xx
> Add LCDC a
Op 03-09-13 16:20, Pasi Kärkkäinen schreef:
> On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote:
>> Op 28-08-13 08:29, Pasi Kärkkäinen schreef:
>>> On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote:
On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote
On Wed, Aug 28, 2013 at 09:44:15AM +0200, Maarten Lankhorst wrote:
> Op 28-08-13 08:29, Pasi Kärkkäinen schreef:
> > On Fri, Aug 23, 2013 at 11:20:42PM +0300, Pasi Kärkkäinen wrote:
> >> On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> >>> Op 22-08-13 02:10, Ilia Mirkin schreef:
https://bugzilla.kernel.org/show_bug.cgi?id=60827
--- Comment #3 from Alex Deucher ---
You might also try a newer kernel. It looks like the uvd ring that is failing
to resume properly. There are a number of fixes for suspend/resume related
problems with uvd in 3.11 (most of which should end up
https://bugzilla.kernel.org/show_bug.cgi?id=60827
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 from
Hi Dave,
The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b:
Linux 3.11-rc2 (2013-07-21 12:05:29 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/for-3.12-rc1
for you to fetch changes up to 03da0e7ba9e3a1fc700f60913f
Hello Alex Deucher,
This is a semi-automatic email about new static checker warnings.
The patch b530602fd462: "drm/radeon: add audio support for DCE6/8
GPUs (v12)" from Jul 31, 2013, leads to the following Smatch
complaint:
drivers/gpu/drm/radeon/dce6_afmt.c:91 dce6_afmt_select_pin()
43 matches
Mail list logo
