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
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
--
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>
p://lists.freedesktop.org/archives/dri-devel/attachments/20141007/4e5b61f4/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
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
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:/
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>
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
/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>
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>
ts.freedesktop.org/archives/dri-devel/attachments/20141007/9f88495c/attachment.html>
ttachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/3e99185a/attachment.html>
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
g/archives/dri-devel/attachments/20141007/52519c98/attachment.html>
tal signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/8a2adba1/attachment.sig>
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
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>
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
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>
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 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
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 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
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, 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
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>
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
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
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
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 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/
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
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
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
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>
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
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>
>
> 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>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/8386c64c/attachment.html>
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
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: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
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
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/7fdf262c/attachment.html>
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
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>
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: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: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
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
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
.
--
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>
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
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
--- 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.
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
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/2b2f5f5e/attachment.html>
ttachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/b2240501/attachment.html>
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
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
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>
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>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/ac5bb72c/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>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141007/68d36db8/attachment.html>
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, 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,
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, 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:
>
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
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/
> >> 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.
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>
74 matches
Mail list logo
