- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/23366270/attachment.html>
On 2014?09?19? 21:04, David Herrmann wrote:
> Hi
>
> On Fri, Sep 19, 2014 at 7:47 AM, Mark yao wrote:
> [snip]
>> +static int rockchip_drm_bind(struct device *dev)
>> +{
>> + return drm_platform_init(&rockchip_drm_driver,
>> to_platform_device(dev));
> Please avoid drm_platform_*() usage. W
On 2014?09?20? 08:03, Rob Clark wrote:
> On Fri, Sep 19, 2014 at 1:47 AM, Mark yao wrote:
>> diff --git a/include/uapi/drm/rockchip_drm.h
>> b/include/uapi/drm/rockchip_drm.h
>> new file mode 100644
>> index 000..8f8e60e
>> --- /dev/null
>> +++ b/include/uapi/drm/rockchip_drm.h
>> @@ -0,0 +1,
vel/attachments/20140922/ea5b0b59/attachment.html>
pci=nomsi. radeon.msi
only affects the radeon driver.
--
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/20140922/f0cff01f/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/a4d80c62/attachment.html>
comment #34) ?
With quirks like in comment #34 and in grub options.
--
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/20140922/0499a8a6/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/20140922/35011488/attachment.html>
st any patch you can throw at me.
Cheers!
Alexandre
--
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/20140922/9c5a0abe/attachment.html>
drops are due to VRAM thrashing and not directly related
to the GPU faults.
--
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/attachment
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/0e6a7ff9/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/9a086f22/attachment.html>
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/c2a167aa/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=51381
JM changed:
What|Removed |Added
CC||jack.martin-foe6a6ea at yopmai
|
On Sat, Sep 20, 2014 at 8:57 PM, Javier Martinez Canillas
wrote:
> [adding Kukjin as cc]
>
> Hello Ajay,
>
> On Sat, Sep 20, 2014 at 1:22 PM, Ajay kumar wrote:
>>> Generally speaking, I sense that we have different views of how display
>>> devices and drivers are structured. You say "If some XYZ
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/3c0f/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/de1def54/attachment-0001.html>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/c5d05345/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/20140922/a4c9dace/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/aea160df/attachment.html>
Hi Sean,
On 09/19/2014 09:53 PM, Sean Paul wrote:
> Per NVidia, this clock rate should be around 70MHz in
> order to properly sample reads on data lane 0. In order
> to achieve this rate, we need to reparent the clock from
> clk_m which can only achieve 12MHz. Add parent_lp to the
> dts bindings a
it. Also, day by day the number of
> > platforms using drm_bridge is increasing.
>
> That's exactly why I'd like to use the component framework now, as the
> conversion will become more complex as time goes by.
No it won't. If we ever do decide that component framework is a better
fit then the conversion may be more work but it would still be largely
mechanical.
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/20140922/46145549/attachment.sig>
ndpoints nodes.
Also it won't be very difficult to extend the binding in a backwards
compatible way if that becomes necessary.
One thing that I'd like to see in this binding, though, is how to hook
up the bridge to a panel. However I'm still catching up on mail after
vacation, so perhaps this has already been discussed further down the
thread.
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/20140922/43bffc1f/attachment-0001.sig>
he scenario will always remain the same for this bridge. There will
always be an input signal and a translation to some output signal along
with some parameters to control how that translation happens. More
complicated scenarios will likely need to be represented differently at
a higher level than the bridge.
> If you now create ps8622 bindings that do not
> support those graphs, the no one else using ps8622 can use
> ports/endpoint graphs either.
That's not true. The binding can easily be extended in a backwards-
compatible way later on (should it really prove necessary).
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/20140922/03fac86b/attachment.sig>
perties are about the bridge. "use-external-pwm" means that
> > the bridge uses an external PWM, which, if I understood correctly, is
> > not what the property is about.
> >
> > "disable-bridge-pwm" is ok, but the "bridge" there is extra. The
> > properties are about the bridge, so it's implicit.
> Ok. I will use "disable-pwm".
Why is this even necessary? According to the datasheet this device has
circuitry for backlight control. If so, I'd expect it to expose either a
backlight device or a PWM device. That way unless somebody is using the
backlight/PWM exposed by the bridge the bridge can simply disable PWM.
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/20140922/2f2c81d0/attachment.sig>
with --enable-debug.
Thanks,
Christian.
--
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/20140922/0bb55101/attachment.html>
ore
complicated graph is irrelevant. What matters is that you get a phandle
to the bridge. The job of the operating system is to give drivers a way
to resolve that phandle to some object and provide an API to access that
object.
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/20140922/16b2b0d3/attachment.sig>
Hi Thierry,
On Mon, Sep 22, 2014 at 1:40 PM, Thierry Reding
wrote:
> On Thu, Sep 18, 2014 at 11:20:40AM +0530, Ajay kumar wrote:
>> Hi Tomi,
>>
>> On Wed, Sep 17, 2014 at 9:52 PM, Tomi Valkeinen
>> wrote:
>> > On 17/09/14 17:29, Ajay kumar wrote:
>> >> Hi Tomi,
>> >>
>> >> Thanks for your 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/20140922/20632d5e/attachment.html>
pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/d5d059d4/attachment.sig>
Hey,
Op 18-09-14 om 22:07 schreef Ted Percival:
> Hi, I noticed a regression in the next-20140903 kernel that was not
> present in next-20140902. When Xorg starts up, the display is garbled
> (or contains old image bits) and I see a page fault in the kernel log. X
> is not usable in this state - t
-
> 2.1.0.rc2.206.gedb03e5
>
-- 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/20140922/c32e4b6f/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=77181
Barto changed:
What|Removed |Added
CC||mister.freeman at laposte.net
--- Comment #8 from
yte order).
Please attach the exact changes you've made to get to that point.
--
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/attachmen
Am Freitag, den 19.09.2014, 15:53 -0400 schrieb Sean Paul:
> Per NVidia, this clock rate should be around 70MHz in
> order to properly sample reads on data lane 0. In order
> to achieve this rate, we need to reparent the clock from
> clk_m which can only achieve 12MHz. Add parent_lp to the
> dts bi
This fixes a regression introduced by "drm/nouveau: rework to new fence
interface"
(commit 29ba89b2371d466).
The fence sequence should not be reset after creation, the old value is used
instead.
On destruction the final value is written, to prevent another source of
accidental
wraparound in cas
Hi David,
On Fri, 19 Sep 2014 15:10:02 +0200
David Herrmann wrote:
> Hi
>
> On Mon, Sep 8, 2014 at 10:43 AM, Boris BREZILLON
> wrote:
> [snip]
> > +static int atmel_hlcdc_dc_drm_probe(struct platform_device *pdev)
> > +{
> > + int ret;
> > +
> > + ret = dma_set_coherent_mask(&pdev-
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 exynos_drm tests regarding your
component support update.
The patch is based as usual on the latest exynos
/archives/dri-devel/attachments/20140922/fa1798c0/attachment.sig>
.5 Test: Fill 300
x 300px AA Trapezoid.
Attached dmesg
--
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/20140922/8b40c275/attachment.html>
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/52721289/attachment.sig>
On Mon, Sep 22, 2014 at 4:39 PM, Thierry Reding
wrote:
>
> On Tue, Sep 02, 2014 at 10:56:46AM +0800, Daniel Kurtz wrote:
> > There are several different models of N116BGE. According to the commit
> > that added innolux_n116bge_mode [0], this N116BGE is for the eDP variety.
> >
> > [0] commit 0a22
if both can co-exist or not. Is there anything
> we can do with bootargs instead of CONFIG?
I think the issue is that simplefb will register as console but the
display driver is probably reconfiguring the display hardware and then
registering a new console, so you'd end up with just a blank screen.
Typically the simplefb device tree nodes will be added by the bootloader
so you might be able to prevent the bootloader from adding it. Ideally,
though, the solution would be to do a proper hand-off from simplefb to
DRM/KMS so that you can have a seemless transition. Somewhere in the
middle would be to make simplefb unload when loading the DRM/KMS driver.
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/20140922/884bea4c/attachment.sig>
klight = <&ps8622>;
...
};
Or:
backlight: ... {
compatible = "pwm-backlight";
...
};
panel {
...
backlight = <&backlight>;
...
};
What you did in v6 of this series was look up a backlight device and
then not use it. That seemed unnecessary. Looking at v6 again the reason
for getting a phandle to the backlight was so that the device itself did
not expose its own backlight controlling circuitry if an external one
was being used. But since the bridge has no business controlling the
backlight, having the backlight phandle in the bridge is not correct.
So I think what you could do in the driver instead is always expose the
backlight device. If the panel used a different backlight, the PS8622's
internal on simply wouldn't be accessed. It would still be possible to
control the backlight in sysfs, but that shouldn't be a problem (only
root can access it).
That said, I have no strong objections to the boolean property if you
feel like it's really necessary.
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/20140922/97c79653/attachment.sig>
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/20140922/a626bb6a/attachment.sig>
On Fri, Sep 19, 2014 at 06:31:25PM -0300, Gustavo Padovan wrote:
> 2014-09-19 Ville Syrj?l? :
>
> > On Thu, Sep 18, 2014 at 04:43:16PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > After some refactor intel_primary_plane_setplane() does the same
> > > as intel_pipe_set_ba
-
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/20140922/bd50e789/attachment.html>
On Mon, Sep 22, 2014 at 4:11 PM, Thierry Reding
wrote:
> On Mon, Sep 22, 2014 at 02:01:38PM +0530, Ajay kumar wrote:
>> Hi Thierry,
>>
>> On Mon, Sep 22, 2014 at 1:40 PM, Thierry Reding
>> wrote:
>> > On Thu, Sep 18, 2014 at 11:20:40AM +0530, Ajay kumar wrote:
>> >> Hi Tomi,
>> >>
>> >> On Wed, S
turn
backlight on or off?
> > What you did in v6 of this series was look up a backlight device and
> > then not use it. That seemed unnecessary. Looking at v6 again the reason
> > for getting a phandle to the backlight was so that the device itself did
> > not expose its own backlight controlling circuitry if an external one
> > was being used. But since the bridge has no business controlling the
> > backlight, having the backlight phandle in the bridge is not correct.
> >
> > So I think what you could do in the driver instead is always expose the
> > backlight device. If the panel used a different backlight, the PS8622's
> > internal on simply wouldn't be accessed. It would still be possible to
> > control the backlight in sysfs, but that shouldn't be a problem (only
> > root can access it)
> That would be like simple exposing a feature which cannot be used
> by the user, ideally which "should not be" used by the user.
And it won't be used unless they access the sysfs files directly. There
are a lot of cases where we expose functionality that cannot be
meaningfully used by the user. For example, a GPIO may not be routed to
anything on a board, yet we don't explicitly hide any specific GPIOs
from users.
> > That said, I have no strong objections to the boolean property if you
> > feel like it's really necessary.
> Won't you think having a boolean property for an optional
> feature of the device, is better than all these?
Like I said, I'm indifferent on the matter. I don't think it's necessary
to hide the backlight device, but if you want to, please feel free to do
so.
Another alternative would be not to expose it at all and not have the
boolean property since you don't seem to have a way to test it in the
first place (or at least there's no device support upstream where it's
needed).
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/20140922/e3c23680/attachment.sig>
ou 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/20140922/d90baf26/attachment.html>
5f8b3.
--
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/20140922/f204f89e/attachment-0001.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/13d6d5bb/attachment.html>
On Mon, Sep 22, 2014 at 5:05 PM, Thierry Reding
wrote:
> On Mon, Sep 22, 2014 at 04:53:22PM +0530, Ajay kumar wrote:
>> On Mon, Sep 22, 2014 at 4:11 PM, Thierry Reding
>> wrote:
>> > On Mon, Sep 22, 2014 at 02:01:38PM +0530, Ajay kumar wrote:
>> >> Hi Thierry,
>> >>
>> >> On Mon, Sep 22, 2014 at
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/540310b3/attachment.html>
EBUG flag.
--
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/20140922/15b111b0/attachment.html>
http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/5d23a064/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/9bf6fed3/attachment-0001.html>
your output.
--
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/20140922/4d63bf1e/attachment.html>
the bad Tahiti ever tested them.
--
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/20140922/c156679b/attachment.html>
e
stripping:
options=('!strip' 'debug')
--
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/20140922/868b85fd/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83651
--- Comment #6 from Alex Deucher ---
The lid issue is more semantic. The display is still connected even when the
lid is closed so it should still report as connected. It's up to the desktop
environment to decide what to do when they get a lid e
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/98c60f33/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/3d23fd14/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=84981
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
https://bugzilla.kernel.org/show_bug.cgi?id=84981
--- Comment #2 from Apostolos B. ---
Created attachment 151281
--> https://bugzilla.kernel.org/attachment.cgi?id=151281&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
The IC register offset is at +0x2 relative to the control module
registers on all IPUv3 versions. This patch fixes wrong values for
i.MX51 and i.MX53.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driv
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/c1599069/attachment.html>
ng wrong here.
--
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/20140922/acb3f029/attachment.html>
my kernel ?
Sure.
--
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/20140922/6560bef6/attachment.html>
milar
behaviour, how can I achieve this goal?
--
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/20140922/858e9dc0/attachment.html>
eedesktop.org/archives/dri-devel/attachments/20140922/7376882d/attachment.html>
rubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/41c07685/attachment.html>
L attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/62c0f3ac/attachment-0001.html>
The return value is not used by callers of this function
nor by uses of the DRM_ERROR macro so change the function
to return void.
Signed-off-by: Joe Perches
---
This change is associated to a desire to eventually
change printk to return void.
No x86 change in output size for drm_drv.o
drivers
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/c9369250/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/a14f6392/attachment.html>
aviour in
open-sorce driver. Alex said he can provide some patches for me to start with,
let's see if it will cover these demands.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<htt
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/71a114fd/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/85606c5d/attachment.html>
On Mon, 8 Sep 2014 10:43:36 +0200
Boris BREZILLON wrote:
> The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
> at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
> controller device.
>
> This display controller supports at least one primary plane and migh
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/e3c25788/attachment.html>
;) I'll try it later and let you know.
--
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/20140922/25d242b7/attachment.html>
On Tue, Sep 16, 2014 at 09:43:50 -0400, Josh Boyer wrote:
> On Fri, Sep 5, 2014 at 1:19 PM, Josh Boyer
> wrote:
> > The userspace drm.h include doesn't prefix the drm directory. This can lead
> > to compile failures as /usr/include/drm/ isn't in the standard gcc include
> > paths. Fix it to be
Adding proper people and mailing lists..
The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
appropriate, but hopefully somebody does. The fact that it makes
things work certainly argues fairly convincingly for it, but I want
On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
> Adding proper people and mailing lists..
>
> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> appropriate, but hopefully somebody does. The fact that it makes
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/c5352328/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/881b40ba/attachment.html>
ation]
--
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/20140922/4ec9ff20/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #39 from Alex Deucher ---
Thanks. I've added a quirk for your system.
--
You are receiving this mail because:
You are watching the assignee of the bug.
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/943ccb56/attachment.html>
On Tue, 2014-09-23 at 04:20 +0700, C Bergstr?m wrote:
> For clarity - My testing and the patch is required when the Intel driver
> isn't being used at all. After I finish some other testing I can see if
> bumblebee and intel driver + this patch will play nicely.
>
> How is a laptop with dual VGA c
On Mon, Sep 22, 2014 at 5:54 PM, Alex Williamson
wrote:
> On Tue, 2014-09-23 at 04:20 +0700, C Bergstr?m wrote:
>> For clarity - My testing and the patch is required when the Intel driver
>> isn't being used at all. After I finish some other testing I can see if
>> bumblebee and intel driver + thi
From: Gustavo Padovan
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
v2: take Vi
From: Gustavo Padovan
Now that universal planes are in place we don't need this plane unref on
failures.
Suggested-by: Ville Syrj?l?
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/
From: Gustavo Padovan
Move checks inside intel_crtc_cursor_set_obj() to
intel_check_cursor_plane(), we only use they there so move them out to
make the merge of intel_crtc_cursor_set_obj() into
intel_check_cursor_plane() easier.
This is another step toward the atomic modesetting support and unif
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 intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
and merge both
From: Daniel Stone
Start the work of splitting the intel_crtc_page_flip() for later use
by the atomic modesetting API.
Signed-off-by: Daniel Stone
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 51 ++--
1 file changed, 37 insertions(+
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 | 20 +---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
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 comments:
- get the right arguments for update_plane()
- use drm_crt
From: Gustavo Padovan
Take out the pin_fb code so commit phase can't fail anymore.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display
1 - 100 of 123 matches
Mail list logo
