URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/68d36db8/attachment.html>
n.lo
CCLD libradeon.la
but radeonsi_dri.so is not changed after make install.
--
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/20141007/d8cc516c/attachment.html>
ment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/4f8b7778/attachment.sig>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/ac5bb72c/attachment.html>
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/20141007/11964679/attachment-0001.html>
s noticeable StructurizeCFG problem is
fixed.
--
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/20141007/840a0fca/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=85421
--- Comment #1 from Hin-Tak Leung ---
Created attachment 152841
--> https://bugzilla.kernel.org/attachment.cgi?id=152841&action=edit
var log message, another crash, 4 days later.
same description as last, from stalled to reboot. This time it ha
https://bugzilla.kernel.org/show_bug.cgi?id=71051
--- Comment #14 from Hin-Tak Leung ---
(In reply to Hin-Tak Leung from comment #13)
... attachment 150801 [details] going
> upstream ... cik_ring_test/radeon_dp_link_train_cr
> error issue looked at.
To answer my own question, attachment 150801 i
ttachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/b2240501/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/2b2f5f5e/attachment.html>
On Wed, Sep 24, 2014 at 02:20:32PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> After some refactor intel_primary_plane_setplane() does the same
> as intel_pipe_set_base() so we can get rid of it and replace the calls
> with intel_primary_plane_setplane().
>
> v2: take Ville's comme
Hi Tomi,
On Tuesday 07 October 2014 11:25:56 Tomi Valkeinen wrote:
> On 07/10/14 10:23, Laurent Pinchart wrote:
> >> You mean the bridge driver would somehow take a peek into panel1 and
> >> panel2 nodes, looking for bridge specific properties? Sounds somewhat
> >> fragile to me... How would the b
The translation from the X driver to the KMS one typo'ed a couple
of array indices, causing the HW cursor to look weird (blocky with
leaking edge colors). This fixes it.
Signed-off-by: Benjamin Herrenschmidt
---
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 1
On Wed, Sep 24, 2014 at 02:20:31PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Use the macros makes the code cleaner and it also checks for a NULL fb.
>
> Signed-off-by: Gustavo Padovan
Reviewed-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 8 +++-
> 1 fi
On Wed, Sep 24, 2014 at 02:20:30PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> take out pin_fb code so the commit phase can't fail anymore.
Yeah making commit() void is a good step. For patches 8 and 9:
Reviewed-by: Ville Syrj?l?
>
> Signed-off-by: Gustavo Padovan
> ---
> driv
On Wed, Sep 24, 2014 at 02:20:27PM -0300, Gustavo Padovan wrote:
> From: Daniel Stone
>
> Start the work of splitting the intel_crtc_page_flip() for later use
> by the atomic modesetting API.
At this time this doesn't really do anything so I don't see much point
in applying it, for now at least.
On Wed, Sep 24, 2014 at 02:20:28PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> We need to get hdisplay and vdisplay in a few places so create a
> helper to make our job easier.
>
> Suggested-by: Ville Syrj?l?
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/drm_crtc.c
https://bugzilla.kernel.org/show_bug.cgi?id=85791
--- Comment #2 from Alexander Mezin ---
Also, everything works fine with proprietary driver + bumblebee.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=85791
--- Comment #1 from Alexander Mezin ---
Created attachment 152801
--> https://bugzilla.kernel.org/attachment.cgi?id=152801&action=edit
Xorg.0.log (crash)
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=85791
Bug ID: 85791
Summary: nouveau: errors on boot, can't use discrete gpu
Product: Drivers
Version: 2.5
Kernel Version: 3.16.4, 3.14.20
Hardware: All
OS: Linux
Tr
On Tue, Oct 07, 2014 at 05:47:52PM +0300, Ville Syrj?l? wrote:
> On Wed, Sep 24, 2014 at 02:20:25PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Move check inside intel_crtc_cursor_set_obj() to
> > intel_check_cursor_plane(), we only use it there so move them out to
> > make th
On Wed, Sep 24, 2014 at 02:20:26PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Merge it into the plane update_plane() callback and make other
> users use the update_plane() functions instead.
>
> The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
> so we fold
Hi Ajay,
On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote:
> On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote:
> > On 20/09/14 14:22, Ajay kumar wrote:
> >> Well, I am okay with using video ports to describe the relationship
> >> between the encoder, bridge and the panel.
> >> But, its jus
On Wed, Sep 24, 2014 at 02:20:25PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Move check inside intel_crtc_cursor_set_obj() to
> intel_check_cursor_plane(), we only use it there so move them out to
> make the merge of intel_crtc_cursor_set_obj() into
> intel_check_cursor_plane() ea
.
--
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/20141007/46737024/attachment-0001.html>
Hi Inki,
Another gently ping :)
Andrzej
On 09/22/2014 11:30 AM, Andrzej Hajda wrote:
> All KMS objects are destroyed by drm_mode_config_cleanup in proper order
> so component drivers should not care about it.
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi Inki,
>
> This is another spin-off of exyn
On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote:
> On 20/09/14 14:22, Ajay kumar wrote:
>
>> Well, I am okay with using video ports to describe the relationship
>> between the encoder, bridge and the panel.
>> But, its just that I need to make use of 2 functions when phandle
>> does it using
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/20141007/974386aa/attachment.html>
Hi Lee,
On 07/10/2014 14:22, Lee Jones :
> On Tue, 07 Oct 2014, Thierry Reding wrote:
>> On Tue, Oct 07, 2014 at 01:41:12PM +0200, Boris Brezillon wrote:
>>> On Tue, 7 Oct 2014 12:38:14 +0100
>>> Lee Jones wrote:
>>>
On Tue, 07 Oct 2014, Thierry Reding wrote:
> On Tue, Oct 07, 2014
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/7fdf262c/attachment.html>
> >> That said, Nicolas Ferre (Cc'ing) at some point requested this to become
> >> a select (or at least for the DRM driver, but I guess the same applies
> >> to PWM) on the grounds that a depends on will make it more difficult to
> >> enable the driver.
> >
> > It's not that much more difficult.
Hi Inki,
Gently ping.
Andrzej
On 09/19/2014 02:57 PM, Andrzej Hajda wrote:
> Initialization of vblank with MAX_CRTC caused attempts
> to disabling vblanks for non-existing crtcs in case
> drm used fewer crtcs. The patch fixes it.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exyno
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/8386c64c/attachment.html>
>
> I did try more clean/rebuild cycles including single thread but am currently
> still bad.
I'm also seeing this behavior while bisecting a different bug on a 7950...
Probably related...
--
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/20141007/1f964dc2/attachment-0001.html>
ut won't
really solve it. Anyway a patch going this approach is attached, please test.
--
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/20141007/4c687b68/attachment.html>
The implmentation is simple in the extreme: we only want to wait for
events if the device was opened in blocking mode, otherwise we grab what
is available and report an error if there was none.
Signed-off-by: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_fops.c | 12
The patch replaces accesses to display->ctx pointer by container_of
construct. It will allow to remove ctx field in the future.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/
The patch removes redundant encoder field from private DSI context.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi
The patch replaces multiple evaluation of device address
with local variable.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 40 -
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
exynos_dsi_display is used by internal Exynos DRM framework for
representing pair encoder->connecter. As it should be mapped 1:1 to dsi
private context it seems more reasonable to embed it directly
in that context. As a result further code simplification will be possible.
Moreover it will be possib
Hi Inki,
Many Exynos DRM drivers uses global variables to represent associated devices
in Exynos DRM internal framework. It is quite confusing, it adds data
duplication
and finally it does not allow to handle more than one device in system.
It seems better to embed such structures in private cont
ld also take the PWM driver through your tree.
> > > >
> > > > Probably better to deal with that via Kconfig.
> > >
> > > Do you have any suggestions? The PWM driver currently selects the
> > > MFD_ATMEL_HLCDC symbol, which as I understand will cause a Kconfig error
> > > if the latter isn't defined.
> >
> > s/select/depends on/ for the desired effect.
> >
>
> Don't forget the atmel-hlcdc.h header file which is referenced by both
> the DRM and the PWM drivers.
The depends on will prevent the PWM driver from being built until MFD
becomes available, so the missing header file shouldn't be a problem.
That said, Nicolas Ferre (Cc'ing) at some point requested this to become
a select (or at least for the DRM driver, but I guess the same applies
to PWM) on the grounds that a depends on will make it more difficult to
enable the driver.
So we have two options here: 1) turn the select into a depends on here
and allow the dependency to be resolved that way, or 2) solve the
dependency by making sure the MFD part is merged first (either by
pulling the MFD tree into the PWM and DRM trees or waiting for a full
cycle for the MFD changes to land).
I don't mind either way.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/81a2d6db/attachment-0001.sig>
On Tue, 7 Oct 2014 12:38:14 +0100
Lee Jones wrote:
> On Tue, 07 Oct 2014, Thierry Reding wrote:
>
> > On Tue, Oct 07, 2014 at 11:17:43AM +0100, Lee Jones wrote:
> > > On Tue, 07 Oct 2014, Thierry Reding wrote:
> > >
> > > > On Tue, Oct 07, 2014 at 10:59:32AM +0100, Lee Jones wrote:
> > > > > On
9 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/b99ad208/attachment.sig>
On Tue, 07 Oct 2014, Thierry Reding wrote:
> On Tue, Oct 07, 2014 at 01:41:12PM +0200, Boris Brezillon wrote:
> > On Tue, 7 Oct 2014 12:38:14 +0100
> > Lee Jones wrote:
> >
> > > On Tue, 07 Oct 2014, Thierry Reding wrote:
> > >
> > > > On Tue, Oct 07, 2014 at 11:17:43AM +0100, Lee Jones wrote:
>
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/20141007/5fdcfd59/attachment.html>
kernel is around 2m5s
If I wiggle the window around while it's loading/stuck = 1m23s
--
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-d
dn't planned on it. What do you need that for?
> >
> > Because the PWM driver depends on this series. But if you prefer you
> > could also take the PWM driver through your tree.
>
> Probably better to deal with that via Kconfig.
Do you have any suggestions? The PWM driver currently selects the
MFD_ATMEL_HLCDC symbol, which as I understand will cause a Kconfig error
if the latter isn't defined.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/ba7b27d6/attachment.sig>
On Tue, 07 Oct 2014, Lee Jones wrote:
> On Tue, 07 Oct 2014, Boris Brezillon wrote:
>
> > On Tue, 7 Oct 2014 12:38:14 +0100
> > Lee Jones wrote:
> >
> > > On Tue, 07 Oct 2014, Thierry Reding wrote:
> > >
> > > > On Tue, Oct 07, 2014 at 11:17:43AM +0100, Lee Jones wrote:
> > > > > On Tue, 07 Oc
On Tue, 07 Oct 2014, Boris Brezillon wrote:
> On Tue, 7 Oct 2014 12:38:14 +0100
> Lee Jones wrote:
>
> > On Tue, 07 Oct 2014, Thierry Reding wrote:
> >
> > > On Tue, Oct 07, 2014 at 11:17:43AM +0100, Lee Jones wrote:
> > > > On Tue, 07 Oct 2014, Thierry Reding wrote:
> > > >
> > > > > On Tue,
This patch allows framebuffers for cirrus to be created with
32bpp pixel formats provided that they do not violate certain
restrictions of the cirrus hardware.
Signed-off-by: Zach Reizner
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 2 ++
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 4 +++-
drivers/
On Tue, 07 Oct 2014, Thierry Reding wrote:
> On Tue, Oct 07, 2014 at 11:17:43AM +0100, Lee Jones wrote:
> > On Tue, 07 Oct 2014, Thierry Reding wrote:
> >
> > > On Tue, Oct 07, 2014 at 10:59:32AM +0100, Lee Jones wrote:
> > > > On Tue, 07 Oct 2014, Thierry Reding wrote:
> > > >
> > > > > On Tue,
On Tue, 7 Oct 2014 14:13:51 +0100
Chris Wilson wrote:
> The implmentation is simple in the extreme: we only want to wait for
> events if the device was opened in blocking mode, otherwise we grab
> what is available and report an error if there was none.
>
> Signed-off-by: Chris Wilson
> Cc: dr
into the PWM tree?
>
> I hadn't planned on it. What do you need that for?
Because the PWM driver depends on this series. But if you prefer you
could also take the PWM driver through your tree.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/a16b0f8f/attachment.sig>
m_prime_vmap,
>> +.gem_prime_vunmap = rockchip_gem_prime_vunmap,
>> +.fops = &rockchip_drm_driver_fops,
>> +.name = DRIVER_NAME,
>> +.desc = DRIVER_DESC,
>> +.date = DRIVER_DATE,
>> +.major = DRIVER_MAJOR,
>> +.minor = DRIVER_MINOR,
>> +};
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int rockchip_drm_suspend(struct drm_device *dev, pm_message_t state)
>> +{
>> +struct drm_connector *connector;
>> +
>> +drm_modeset_lock_all(dev);
>> +list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
>> +int old_dpms = connector->dpms;
>> +
>> +if (connector->funcs->dpms)
>> +connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
>> +
>> +/* Set the old mode back to the connector for resume */
>> +connector->dpms = old_dpms;
>> +}
>> +drm_modeset_unlock_all(dev);
>> +
>> +return 0;
>> +}
>> +
>> +static int rockchip_drm_resume(struct drm_device *dev)
>> +{
>> +struct drm_connector *connector;
>> +
>> +drm_modeset_lock_all(dev);
>> +list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
>> +if (connector->funcs->dpms)
>> +connector->funcs->dpms(connector, connector->dpms);
>> +}
>> +drm_modeset_unlock_all(dev);
>> +
>> +drm_helper_resume_force_mode(dev);
>> +
>> +return 0;
>> +}
>> +
>> +static int rockchip_drm_sys_suspend(struct device *dev)
>> +{
>> +struct drm_device *drm_dev = dev_get_drvdata(dev);
>> +pm_message_t message;
>> +
>> +if (pm_runtime_suspended(dev))
>> +return 0;
>> +
>> +message.event = PM_EVENT_SUSPEND;
>> +
>> +return rockchip_drm_suspend(drm_dev, message);
> drm_dev can be NULL here, it can happen when system is suspended
> before all components are bound. It can also contain invalid pointer
> if after successfull drm initialization de-initialization happens for
> some reason.
>
> Some workaround is to check for null here and set drvdata to null on
> master unbind. But I guess it should be protected somehow to avoid races
> in accessing drvdata.
So, can I use the way that check for null here and set drvdata to null
on master unbind?
I don't know which way is better to protect somehow.
-Mark.
>
>> +}
>> +
>> +static int rockchip_drm_sys_resume(struct device *dev)
>> +{
>> +struct drm_device *drm_dev = dev_get_drvdata(dev);
>> +
>> +if (!pm_runtime_suspended(dev))
>> +return 0;
>> +
>> +return rockchip_drm_resume(drm_dev);
> Ditto.
>
> Regards
> Andrzej
>
>
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/f96a5f1b/attachment-0001.html>
/atmel-hlcdc.c
> > create mode 100644 include/linux/mfd/atmel-hlcdc.h
>
> Applied for v3.19.
Will you provide a stable branch that I can pull into the PWM tree?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/1eb414f7/attachment.sig>
tal signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/8a2adba1/attachment.sig>
On Tue, 07 Oct 2014, Thierry Reding wrote:
> On Tue, Oct 07, 2014 at 10:59:32AM +0100, Lee Jones wrote:
> > On Tue, 07 Oct 2014, Thierry Reding wrote:
> >
> > > On Tue, Oct 07, 2014 at 10:44:27AM +0100, Lee Jones wrote:
> > > > On Mon, 06 Oct 2014, Boris Brezillon wrote:
> > > >
> > > > > The HL
g/archives/dri-devel/attachments/20141007/52519c98/attachment.html>
On Tue, 07 Oct 2014, Thierry Reding wrote:
> On Tue, Oct 07, 2014 at 10:44:27AM +0100, Lee Jones wrote:
> > On Mon, 06 Oct 2014, Boris Brezillon wrote:
> >
> > > The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
> > > family or sama5d3 family) exposes 2 subdevices:
> > > - a
On Mon, 06 Oct 2014, Boris Brezillon wrote:
> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
> family or sama5d3 family) exposes 2 subdevices:
> - a display controller (controlled by a DRM driver)
> - a PWM chip
>
> This patch adds documentation for atmel-hlcdc DT binding
On Mon, 06 Oct 2014, Boris Brezillon wrote:
> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
> family or sama5d3 family) exposes 2 subdevices:
> - a display controller (controlled by a DRM driver)
> - a PWM chip
>
> The MFD device provides a regmap and several clocks (tho
ttachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/3e99185a/attachment.html>
Hi Tomi,
On Tuesday 07 October 2014 10:06:10 Tomi Valkeinen wrote:
> On 06/10/14 17:40, Laurent Pinchart wrote:
> >> But seriously speaking, I was thinking about this. I'd really like to
> >> have a generic video-mux node, that would still somehow allow us to have
> >> device specific configuratio
ts.freedesktop.org/archives/dri-devel/attachments/20141007/9f88495c/attachment.html>
at would solve the
> problem neatly.
You mean the bridge driver would somehow take a peek into panel1 and
panel2 nodes, looking for bridge specific properties? Sounds somewhat
fragile to me... How would the bridge driver know a property is for the
bridge?
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/20141007/fbf33773/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=82711
--- Comment #11 from Mike Cloaked ---
Created attachment 152771
--> https://bugzilla.kernel.org/attachment.cgi?id=152771&action=edit
systemd journal showing kernel oops with kernel 3.16.4
With the latest kernel linux 3.16.4-1 and the packages a
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/be01c191/attachment-0001.html>
ame" mesa can also be bad.
I did try more clean/rebuild cycles including single thread but am currently
still bad.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http:/
On 10/07/2014 05:56 AM, Mark yao wrote:
> On 2014?09?30? 21:31, Andrzej Hajda wrote:
>> Hi Mark,
> Hi Andrzej,
> Sorry for replying late, I have a vacation before.
> Thanks for your review.
>> On 09/30/2014 03:03 PM, Mark Yao wrote:
>>> From: Mark yao
>>>
(...)
>>> +#ifdef CONFIG_PM_SLEEP
p://lists.freedesktop.org/archives/dri-devel/attachments/20141007/4e5b61f4/attachment.html>
--
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/20141007/ac161611/attachment.html>
t-frame-pointer though? Can you get another
profile with Mesa and libdrm built with that?
--
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-d
s like there was another regression in Mesa then, can one of you bisect
that?
--
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
74 matches
Mail list logo
