On 03/23/2014 09:03 PM, Russell King - ARM Linux wrote:
> On Sun, Mar 23, 2014 at 07:12:05PM +0100, Sebastian Hesselbarth wrote:
>> On 03/23/2014 11:19 AM, Jean-Francois Moine wrote:
>>> On Fri, 21 Mar 2014 14:37:52 +0100
>>> Sebastian Hesselbarth wrote:
> Required properties;
> - - c
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/b2c237d8/attachment.html>
turning -EINVAL
--
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/20140323/bfac4a4f/attachment.html>
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/b931f1ad/attachment-0001.html>
Hi Bjorn,
On Fri, Mar 21, 2014 at 12:42:33PM -0600, Bjorn Helgaas wrote:
> On Thu, Mar 20, 2014 at 8:09 PM, Fengguang Wu
> wrote:
> > // CC Stephane for RAPL related bug
> >
> > Bjorn, sorry this bug report is mis-titled. The only new bug that show
> > up in aa11fc58dc is on rapl_pmu_init. And i
On Sun, Mar 23, 2014 at 09:39:16AM -0700, Linus Torvalds wrote:
> On Sun, Mar 23, 2014 at 5:15 AM, Andreas Mohr wrote:
> >
> > which did end up flawless on 3.12.0-rc2+, too
> > (but failed to improve the issue on 3.14.0-rc7+).
> >
> > So, for all intents and purposes, drm infrastructure seems unav
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #15 from Tom Yan ---
(In reply to Tom Yan from comment #14)
> The problem with DisplayPort seems to related to DPMS. All I need to do to
> get back the display is to make sure that there is a state change after the
> monitor is turned
https://bugzilla.kernel.org/show_bug.cgi?id=71461
--- Comment #14 from Tom Yan ---
The problem with DisplayPort seems to related to DPMS. All I need to do to get
back the display is to make sure that there is a state change after the monitor
is turned on again.
--
You are receiving this mail be
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/dc117215/attachment.html>
On Sun, Mar 23, 2014 at 07:12:05PM +0100, Sebastian Hesselbarth wrote:
> On 03/23/2014 11:19 AM, Jean-Francois Moine wrote:
>> On Fri, 21 Mar 2014 14:37:52 +0100
>> Sebastian Hesselbarth wrote:
Required properties;
- - compatible: must be "nxp,tda998x"
+ - compatible: may be "n
On 03/23/2014 11:19 AM, Jean-Francois Moine wrote:
> On Fri, 21 Mar 2014 14:37:52 +0100
> Sebastian Hesselbarth wrote:
>>>Required properties;
>>> - - compatible: must be "nxp,tda998x"
>>> + - compatible: may be "nxp,tda9989", "nxp,tda19988" or "nxp,tda19989"
>>
>> There is a "DT is ABI" pol
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/c7cddb33/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/6d37bf2c/attachment.html>
The tda998x driver accepts only 3 chips from the TDA998x family.
To avoid confusion with the other TDA998x chips, this patch changes
the driver compatible string to "nxp,tda9989".
As the previous compatible string is not actually used in any DT,
no compatibility is offered.
Signed-off-by: Jean-F
On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote:
> On Monday 10 March 2014 12:38:42 Alex Deucher wrote:
> > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote:
> > > Hi,
> > >
> > > I recently added a R7 260X to my system. While the card works with 3.13
> > > its supposed work much better
On Monday 10 March 2014 13:29:41 Ed Tomlinson wrote:
> On Monday 10 March 2014 12:38:42 Alex Deucher wrote:
> > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote:
> > > Hi,
> > >
> > > I recently added a R7 260X to my system. While the card works with 3.13
> > > its supposed work much better
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/7df722bf/attachment-0001.html>
* actually having one.
> */
> out:
> + mutex_unlock(&dev->mode_config.mutex);
> drm_sysfs_connector_add(connector);
> return;
>
> failed_find:
> + mutex_unlock(&dev->mode_config.mutex);
> if (lvds_priv->ddc_bus)
> psb_intel_i2c_destroy(lvds_priv->ddc_bus);
> failed_ddc:
> --
> 1.8.1.4
>
>
Looks good.
Acked-by: Patrik Jakobsson
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/55feefe8/attachment.html>
Hi,
On Sun, Mar 23, 2014 at 12:43:17AM +0100, Andreas Mohr wrote:
> Hi,
>
> now testing 3.14-rc7 here (r128 hardware rather than MGA),
> and I seem to still be experiencing the same or very similar crash as you
> here:
I decided to do some more experimentation:
I added a
Section "Module"
On Fri, 21 Mar 2014 14:37:52 +0100
Sebastian Hesselbarth wrote:
> > Required properties;
> > - - compatible: must be "nxp,tda998x"
> > + - compatible: may be "nxp,tda9989", "nxp,tda19988" or "nxp,tda19989"
>
> There is a "DT is ABI" policy and although there is no mainline Linux
> user of
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/fb02309e/attachment-0001.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/fd6ed78e/attachment.html>
chives/dri-devel/attachments/20140323/15f8d81a/attachment.html>
This will allow the nouveau module to only include support for
nv04-nv50, nv50-nvc0, nvc0+ cards individually (or in any combination).
Only compiling one of the card types at a time reduces the size of the
nouveau module, from 1.3M to 700-800K, depending on the type (including
symbols/etc). It sho
On Sun, Mar 23, 2014 at 5:15 AM, Andreas Mohr wrote:
>
> which did end up flawless on 3.12.0-rc2+, too
> (but failed to improve the issue on 3.14.0-rc7+).
>
> So, for all intents and purposes, drm infrastructure seems unavoidably
> (neither dri disable nor libdrm upgrade helps) affected.
> Does an
On Sat, Mar 22, 2014 at 7:45 AM, Ben Widawsky wrote:
> On Thu, Mar 20, 2014 at 11:31:26AM +1000, Dave Airlie wrote:
>> On Tue, Mar 11, 2014 at 8:30 PM, Daniel Vetter
>> wrote:
>> > There's not really any value in stating that no locking is needed. And
>> > even if the comment is useful, a check
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/1e2a36f9/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/9ed6857b/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140323/01950214/attachment-0001.html>
Hi,
now testing 3.14-rc7 here (r128 hardware rather than MGA),
and I seem to still be experiencing the same or very similar crash as you here:
agpgart-intel :00:00.0: AGP 2.0 bridge
agpgart-intel :00:00.0: putting AGP V2 device into 4x mode
pci :01:00.0: putting AGP V2 device into 4x
or :01:00.0 on
minor 0
--
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/20140323/877ef440/attachment.html>
I get
after I load the radeon module.
This card is an MSI R9 270X Gaming 4G.
--
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/atta
32 matches
Mail list logo
