On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang wrote:
> > Since acpi_evaluate_object() returns acpi_status and not plain int,
> > ACPI_FAILURE() should be used for checking its return value. Also
> > add some detailed debug info when a
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #22 from Hohahiu ---
What does the order of GPUs in /sys/kernel/debug/vgaswitcheroo/switch mean?
Sometimes it is like this (dGPU is powered off):
0:IGD:+:Pwr::00:02.0
1:DIS: :DynOff::01:00.0
In other case it is like that (and d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://lists.freedesktop.org/archives/dri-devel/attachments/20140124/841733ff/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140124/d4bf02e8/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140124/31395922/attachment-0001.html>
|uvd video playback |uvd video playback with SB
--
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/20140124/e4c8e
We don't have to turn backlight on/off every time a blanking
or unblanking event comes because the backlight status may
have already been what we want. Another thought is that one
backlight device may be shared by multiple framebuffers. We
don't hope blanking one of the framebuffers may turn the
ba
We don't have to update the state and fb_blank properties of
a backlight device every time a blanking or unblanking event
comes because they may have already been what we want. Another
thought is that one backlight device may be shared by multiple
framebuffers. The backlight driver should take the
We don't have to update a backlight status every time a
blanking or unblanking event comes because the backlight
status may have already been what we want. Another thought
is that one backlight device may be shared by multiple
framebuffers. We don't hope blanking one of the framebuffers
may turn th
Hi Daniel,
On Thursday 23 January 2014 14:46:40 Daniel Vetter wrote:
> On Thu, Jan 23, 2014 at 01:56:51PM +0100, Laurent Pinchart wrote:
> > > > >
> > > > >
> > > > > Drivers must first validate the requested frame buffer
> > > > > parameters passed
> > > > >
> >
Hi Daniel,
Thank you for the patch.
One last round of nitpicking (including a typo fix, which gives me an excuse
for a couple more comments :-)).
On Thursday 23 January 2014 14:50:25 Daniel Vetter wrote:
> - This is _not_ a generic interface to create gem objects, but just an
> interface to m
Built drm next yesterday was running drm fixes from a couple of weeks
ago previously, card is rv790.
Have powered up twice since and both times seen logged -
[drm:rv770_dpm_set_power_state] *ERROR*
rv770_restrict_performance_levels_before_switch failed
Today was 79 sec after boot, though I don
3/ddx&glamor-8 days
old/xserver-1.15/gnome3
--
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/20140124/8a5327c8/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140124/5113bb23/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140124/cd975c81/attachment.html>
to the bug report fix the problem?
--
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/20140124/c34a1747/attachment.html>
I forgot to mention: please, could someone commit this for me? :)
Thanks!
On 23/01/2014 15:50, Robert Millan wrote:
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki wrote:
> On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
>> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang
>> wrote:
>> > Since acpi_evaluate_object() returns acpi_status and not plain int,
>> > ACPI_FAILURE() should be used for che
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #6 from Alex Deucher ---
Does reverting:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4573388c92ee60b4ed72b8d95b73df861189988c
help?
--
You are receiving this mail because:
You are watching the assignee o
g that commit fix the problem?
--
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/20140124/a7f899a2/attachment.html>
On Fri, Jan 24, 2014 at 8:36 AM, Rafael J. Wysocki wrote:
> On Friday, January 24, 2014 07:54:29 AM Bjorn Helgaas wrote:
>> On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki
>> wrote:
>> > On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
>> >> On Wed, Jan 22, 2014 at 8:42 PM, Yiji
Am 23.01.2014 18:46, schrieb Alex Deucher:
> On Thu, Jan 23, 2014 at 8:24 AM, Christian K?nig
> wrote:
>> From: Christian K?nig
>>
>> Otherwise we allocate a new VMID on nearly every submit.
> I wonder if this fix would allow us to fix up this:
> http://git.kernel.org/cgit/linux/kernel/git/torval
On Fri, Jan 24, 2014 at 10:52 AM, Christian K?nig
wrote:
> Am 23.01.2014 18:46, schrieb Alex Deucher:
>
>> On Thu, Jan 23, 2014 at 8:24 AM, Christian K?nig
>> wrote:
>>>
>>> From: Christian K?nig
>>>
>>> Otherwise we allocate a new VMID on nearly every submit.
>>
>> I wonder if this fix would al
On Thursday, January 23, 2014 6:28 PM, Liu Ying wrote:
> On 01/23/2014 01:44 PM, Jingoo Han wrote:
> > On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote:
> >> On Mon, 20 Jan 2014, Liu Ying wrote:
> >>> We don't have to turn backlight on/off everytime a blanking
> >>> or unblanking event co
On 01/22/2014 12:46 PM, Jean-Francois Moine wrote:
> On Wed, 22 Jan 2014 11:19:53 +0100
> Jean-Francois Moine wrote:
>
>> As both I2S and S/PDIF may be used for HDMI output in the Cubox,
>> I wrote a tda998x CODEC which gets the audio ports from the DT and
>> dynamically sets these ports and the a
On 01/21/2014 09:15 PM, Mark Brown wrote:
> On Wed, Jan 15, 2014 at 01:27:21PM +0200, Jyri Sarha wrote:
>> On 12/31/2013 03:25 PM, Mark Brown wrote:
>
support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
The 8 least significant bits are ignored.
>
>>> Where does this cons
On Friday, January 24, 2014 3:05 PM, Liu Ying wrote:
>
> We don't have to turn backlight on/off every time a blanking
> or unblanking event comes because the backlight status may
> have already been what we want. Another thought is that one
> backlight device may be shared by multiple framebuffers
On Friday, January 24, 2014 07:54:29 AM Bjorn Helgaas wrote:
> On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki
> wrote:
> > On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
> >> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang
> >> wrote:
> >> > Since acpi_evaluate_object() returns
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140124/136ca751/attachment.html>
* David Herrmann wrote:
> Hi
>
> On Thu, Jan 23, 2014 at 6:14 PM, Ingo Molnar wrote:
> >
> > * David Herrmann wrote:
> >
> >> >> +#ifdef CONFIG_X86_SYSFB
> >> >> +# include
> >> >> +#endif
> >> >
> >> > I guess a single space is sufficient?
> >> >
> >> > Better yet, I'd include sysfb.h unco
On Fri, Jan 24, 2014 at 12:08:36PM +0100, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Thursday 23 January 2014 14:46:40 Daniel Vetter wrote:
> > On Thu, Jan 23, 2014 at 01:56:51PM +0100, Laurent Pinchart wrote:
> > > > > >
> > > > > >
> > > > > > Drivers must first validat
On Fri, Jan 24, 2014 at 12:13:11PM +0100, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> One last round of nitpicking (including a typo fix, which gives me an excuse
> for a couple more comments :-)).
>
> On Thursday 23 January 2014 14:50:25 Daniel Vetter wrote:
> > - Thi
On Fri, 24 Jan 2014 14:57:09 +0200
Jyri Sarha wrote:
> Could you give me a link to a git repo with your tda998x codec code so I
> could prepare to use that too?
I have no git repo. Instead, here is the source.
It goes into sound/soc/codecs and is selected with CONFIG_OF and
CONFIG_DRM_I2C_NXP_
- This is _not_ a generic interface to create gem objects, but just an
interface to make early boot services (like boot splash) with a
generic KMS userspace driver possible. Hence it's better to move
the documentation for this from the GEM section to the KMS section,
next to the creation of
On Fri, Jan 24, 2014 at 3:23 AM, Raymond Yau
wrote:
>
>>
>> >> And I have a question: how to assure the audio/gfx client find its
>> >> right peer?
>> >> On a x86 platform, there can be an integrated GPU and an discrete GPU.
>> >> So there can be two audio controllers and two GPUs.
>> >> We need t
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140124/7aa17b03/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140124/cc4cb247/attachment.html>
Am 24.01.2014 17:58, schrieb Daniel Vetter:
Just two typos ('said' my spellchecker...;-)
Regards,
Dieter
> - This is _not_ a generic interface to create gem objects, but just an
> interface to make early boot services (like boot splash) with a
> generic KMS userspace driver possible. Hen
Prevent runtime suspend of non-PX GPUs. Runtime suspend is
not what we want in those cases.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140124/f407f076/attachment.html>
On Fri, Jan 24, 2014 at 9:43 AM, Robert Millan wrote:
>
> I forgot to mention: please, could someone commit this for me? :)
>
> Thanks!
Committed.
Alex
>
> On 23/01/2014 15:50, Robert Millan wrote:
>>
>>
>>
>> ___
>> dri-devel mailing list
>> dri-deve
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140124/5e6aac81/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140124/b98c1dc9/attachment-0001.html>
On 01/22/14 23:27, Russell King - ARM Linux wrote:
> On Sun, Jan 19, 2014 at 07:58:43PM +0100, Jean-Francois Moine wrote:
>> This patch adds the optional treatment of the tda998x IRQ.
>>
>> The interrupt function is used to know the display connection status
>> without polling and to speedup readin
On Friday, January 24, 2014 08:25:23 AM Bjorn Helgaas wrote:
> On Fri, Jan 24, 2014 at 8:36 AM, Rafael J. Wysocki
> wrote:
> > On Friday, January 24, 2014 07:54:29 AM Bjorn Helgaas wrote:
> >> On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki
> >> wrote:
> >> > On Thursday, January 23, 2014 11
On Fri, Jan 24, 2014 at 06:29:12PM +0100, Sebastian Hesselbarth wrote:
> On 01/22/14 23:27, Russell King - ARM Linux wrote:
>> On Sun, Jan 19, 2014 at 07:58:43PM +0100, Jean-Francois Moine wrote:
>>> This patch adds the optional treatment of the tda998x IRQ.
>>>
>>> The interrupt function is used t
46 matches
Mail list logo
