HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/530ee842/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/bb0718da/attachment.html>
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/2d56a105/attachment.html>
ves/dri-devel/attachments/20140821/9881c978/attachment-0001.html>
.org/archives/dri-devel/attachments/20140821/e44840e4/attachment.html>
on HD 7950 with kernel 3.16.
--
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/20140821/fd5658ed/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/c20139c9/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/66e60121/attachment.html>
Hi Dave -
Display fixes from Ville and Imre, all cc: stable.
BR,
Jani.
The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-f
ER postpones DP initialization by
> approximately 1.5 second. Is there a good way to handle that? As it
> stands, this isn't usable.
How much is 1.5 seconds compared to the overall boot time of the device?
What exactly is causing this 1.5 second delay?
This really is a fundamental issue with deferred probing and the issue
has come up several times in the past. A couple of possible solutions
have been proposed, with the latest being here[0] I think. That ended in
a bit of a debacle, unfortunately, but on of the outcomes was that a lot
of the ordering problems could be fixed by using phandle references to
track dependencies. I'm not aware of anyone working on that right now,
presumably because everyone is busy getting features merged rather than
optimizing boot speed.
Thierry
[0]: https://lkml.org/lkml/2014/5/12/452
-- 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/20140821/3dbf9f8c/attachment-0001.sig>
On Thu, Aug 21, 2014 at 12:36 AM, Thierry Reding
wrote:
> On Tue, Aug 19, 2014 at 09:02:39PM -0700, St?phane Marchesin wrote:
>> On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding
>> wrote:
>> > On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote:
>> >> Hi Thierry,
>> >>
>> >> On Tue, Apr 22,
Hi Ludovic,
On Thu, 21 Aug 2014 10:16:19 +0200
Ludovic Desroches wrote:
> Hi Boris,
>
> You can add
>
> Tested-by: Ludovic Desroches
Thanks for testing this driver.
>
> Only one issue but not related to your patches, you can't display
> quickly the bootup logo since the panel detection tak
me: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/5a32aeba/attachment.sig>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140821/6e2c8c64/attachment.html>
vel/attachments/20140821/86bedf40/attachment.html>
On Tue, Aug 19, 2014 at 05:10:51PM +0800, Y.C. Chen wrote:
> From: "Y.C. Chen"
>
> ---
> drivers/gpu/drm/ast/ast_mode.c | 27 +-
> drivers/gpu/drm/ast/ast_tables.h | 42
> ++--
> 2 files changed, 41 insertions(+), 28 deletions(-)
>
On Thu, Aug 21, 2014 at 1:55 PM, St?phane Marchesin
wrote:
> On Thu, Aug 21, 2014 at 12:36 AM, Thierry Reding
> wrote:
>> On Tue, Aug 19, 2014 at 09:02:39PM -0700, St?phane Marchesin wrote:
>>> On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding
>>> wrote:
>>> > On Tue, Apr 22, 2014 at 08:33:23PM +0
DRM/KMS to hotplug panels. Theoretically this should be
possible already but it comes at a cost. If I'm not mistaken that's what
Boris implemented for the Atmel HLCDC driver. However if the panel isn't
available at DRM driver ->load() time, then it relies on the hotplugging
mechanism to detect the panel later on, which can itself introduce more
delays. I suspect this could be improved in various ways, but one of the
more complicated issues is that it causes problems when you want to use
the framebuffer console. The issue is that the fbdev helper code is set
up very early and if no outputs with valid modes are found it will
default to a 1024x768 resolution for the framebuffer console. At the
same time it will prevent any outputs that are hotplugged later on to
increase the resolution again. This works fine for monitors which
usually support a number of different modes (1024x768 being standard
enough that probably every monitor in existence supports it). But for
panels this won't work, since they usually support only a single mode.
There are a number of ways that this could be solved I guess. One would
be to defer fbdev creation itself until all outputs have been detected.
This could prove difficult because it may not always be possible to
determine which outputs to wait for. Another solution would be to allow
the framebuffer console to be resized, but I've been told in the past
that it's impractical if not impossible.
Of course if you don't need a framebuffer console (you could use kmscon
or none at all), then things should work for you if you simply consider
the panel as hotpluggable monitor.
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/20140821/aa7bdfa1/attachment.sig>
have a set of fixes, we can consider
backporting them to stable branches, but they have to be on master first.
--
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/
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/1ee732a5/attachment-0001.html>
; What exactly is causing this 1.5 second delay?
> >
> > A regulator isn't ready, and then drm_panel returns defer. Then the
> > whole drm driver init is deferred.
> >
> >>
> >> This really is a fundamental issue with deferred probing and the issue
> >> has come up several times in the past. A couple of possible solutions
> >> have been proposed, with the latest being here[0] I think. That ended in
> >> a bit of a debacle, unfortunately, but on of the outcomes was that a lot
> >> of the ordering problems could be fixed by using phandle references to
> >> track dependencies. I'm not aware of anyone working on that right now,
> >> presumably because everyone is busy getting features merged rather than
> >> optimizing boot speed.
> >
> > Yes, I don't believe boot time ordering will ever happen upstream, but
> > then the current implementation with EPROBE_DEFER isn't usable either.
> > Any ideas? ATM it seems like the only way out is to just write my
> > own dt format for the panel and ignore drm_panel.
> Something like this:
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/gpu/drm/exynos/exynos_dp_core.c
>
> With this way also, we would expect the regulator to come up early(before
> drm).
Well, that's pretty much what St?phane proposed. You don't use DRM panel
at all and instead rely on some "platform data" to get the information
that you need. You're basically throwing everything we've been working
towards with DT for the past three years out the door. Also as soon as
you encounter the first device that's not covered by lcd_vdd, vcd_led
regulators and lcd_en, led_en GPIOs you have a problem. There's also no
reuse across SoCs whatsoever.
Really, we should be finding ways to fix problems, not work around them
in every driver because the real fixes look too daunting at the moment.
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/20140821/8d527603/attachment.sig>
On Thu, 21 Aug 2014 11:04:07 +0200
Thierry Reding wrote:
> On Thu, Aug 21, 2014 at 10:37:06AM +0200, Boris BREZILLON wrote:
> > Hi Ludovic,
> >
> > On Thu, 21 Aug 2014 10:16:19 +0200
> > Ludovic Desroches wrote:
> >
> > > Hi Boris,
> > >
> > > You can add
> > >
> > > Tested-by: Ludovic Desro
On Thu, 21 Aug 2014 11:41:59 +0200
Boris BREZILLON wrote:
> On Thu, 21 Aug 2014 11:04:07 +0200
> Thierry Reding wrote:
>
> > On Thu, Aug 21, 2014 at 10:37:06AM +0200, Boris BREZILLON wrote:
> > > Hi Ludovic,
> > >
> > > On Thu, 21 Aug 2014 10:16:19 +0200
> > > Ludovic Desroches wrote:
> > >
other way around (the panel needs to refer to the
output by phandle).
> > That
> > will still cause some delay before everything gets set up, but hopefully
> > less than what you're seeing now. There's also another thread where this
> > is being discussed because deferred probing is causing "unacceptable"
> > delays as well.
>
> Could you point this thread out to me please ?
I Cc'ed you on it.
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/20140821/b2a2b1e8/attachment-0001.sig>
Just noticed two other things:
On Tue, Aug 19, 2014 at 05:10:51PM +0800, Y.C. Chen wrote:
> --- a/drivers/gpu/drm/ast/ast_tables.h
> +++ b/drivers/gpu/drm/ast/ast_tables.h
> @@ -72,6 +72,7 @@
> static struct ast_vbios_dclk_info dclk_table[] = {
> {0x2C, 0xE7, 0x03},
On 08/21/2014 11:41 AM, Boris BREZILLON wrote:
> On Thu, 21 Aug 2014 11:04:07 +0200
> Thierry Reding wrote:
>
>> On Thu, Aug 21, 2014 at 10:37:06AM +0200, Boris BREZILLON wrote:
>>> Hi Ludovic,
>>>
>>> On Thu, 21 Aug 2014 10:16:19 +0200
>>> Ludovic Desroches wrote:
>>>
Hi Boris,
Y
On 08/21/2014 11:52 AM, Thierry Reding wrote:
> On Thu, Aug 21, 2014 at 11:41:59AM +0200, Boris BREZILLON wrote:
>> On Thu, 21 Aug 2014 11:04:07 +0200
>> Thierry Reding wrote:
>>
>>> On Thu, Aug 21, 2014 at 10:37:06AM +0200, Boris BREZILLON wrote:
Hi Ludovic,
On Thu, 21 Aug 2014 10:
On Thu, 21 Aug 2014 11:52:03 +0200
Thierry Reding wrote:
> On Thu, Aug 21, 2014 at 11:41:59AM +0200, Boris BREZILLON wrote:
> > On Thu, 21 Aug 2014 11:04:07 +0200
> > Thierry Reding wrote:
> >
> > > On Thu, Aug 21, 2014 at 10:37:06AM +0200, Boris BREZILLON wrote:
> > > > Hi Ludovic,
> > > >
>
?
> > You also can't be using the
> > current device tree bindings because they all assume a dependency from
> > the display controller/output to the panel. For hotplugging you'd need
> > the dependency the other way around (the panel needs to refer to the
> > output by phandle).
>
> Here [1] is a proposal for notification support in the drm_panel
> infrastructure (which is not that complicated), and here [2] is how
> I use it in my atmel-hlcdc driver to generate hotplug events.
>
> Let me know if you want me to submit a proper patch series...
>
> Best Regards,
>
> Boris
>
> [1]http://code.bulix.org/scq4g3-86804
> [2]http://code.bulix.org/7dg501-86805
Those look interesting. Any chance you could look into how to do the
same without resorting to notifiers?
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/20140821/076454eb/attachment-0001.sig>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140821/1d92516b/attachment.html>
does not make thing worse than before.
> And I do not see a problem with phandles, ie in DT they point both ways,
> according to binding advices at the time, but in the code it is display
> controller/encoder which is looking for the panel.
That works because it's DSI. And we have attach/detach callbacks for
DSI. We don't have those for regular panels, so we'd need to find a way
to add that.
The way that this currently works is that an encoder/connector driver
looks up the panel and attaches it to itself. If you allow panels to be
hotpluggable, then they have no knowledge about what they are connected
to, so there needs to be a way to inject that knowledge so that they can
attach to a connector.
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/20140821/2c3db61d/attachment.sig>
On Thu, 21 Aug 2014 15:16:08 +0200
Thierry Reding wrote:
> On Thu, Aug 21, 2014 at 03:06:00PM +0200, Boris BREZILLON wrote:
> > On Thu, 21 Aug 2014 11:52:03 +0200
> > Thierry Reding wrote:
> >
> > > On Thu, Aug 21, 2014 at 11:41:59AM +0200, Boris BREZILLON wrote:
> > > > On Thu, 21 Aug 2014 11:
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140821/0ec09ae3/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140821/59453c5e/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/38366305/attachment.html>
|--- |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/20140821/696bdac4/attachment.html>
lls back to the framebuffer.
It seems like the driver/module just doesn't recognize the chipset!
sean
--
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
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/fdea5884/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/d839181f/attachment.html>
On Thu, 21 Aug 2014 15:16:08 +0200
Thierry Reding wrote:
> On Thu, Aug 21, 2014 at 03:06:00PM +0200, Boris BREZILLON wrote:
> > On Thu, 21 Aug 2014 11:52:03 +0200
> > Thierry Reding wrote:
> >
> > > On Thu, Aug 21, 2014 at 11:41:59AM +0200, Boris BREZILLON wrote:
> > > > On Thu, 21 Aug 2014 11:
On 08/21/2014 03:21 PM, Thierry Reding wrote:
> On Thu, Aug 21, 2014 at 12:32:43PM +0200, Andrzej Hajda wrote:
>> On 08/21/2014 11:52 AM, Thierry Reding wrote:
>>> On Thu, Aug 21, 2014 at 11:41:59AM +0200, Boris BREZILLON wrote:
On Thu, 21 Aug 2014 11:04:07 +0200
Thierry Reding wrote:
>>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/8e02cada/attachment.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/ac2d03a1/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82721
Alan changed:
What|Removed |Added
Assignee|other_other at kernel-bugs.osd |drivers_video-dri at
kernel-bu
On Thu, 21 Aug 2014 17:04:34 +0200
Andrzej Hajda wrote:
> On 08/21/2014 03:21 PM, Thierry Reding wrote:
> > On Thu, Aug 21, 2014 at 12:32:43PM +0200, Andrzej Hajda wrote:
> >> On 08/21/2014 11:52 AM, Thierry Reding wrote:
> >>> On Thu, Aug 21, 2014 at 11:41:59AM +0200, Boris BREZILLON wrote:
> >>
https://bugzilla.kernel.org/show_bug.cgi?id=82681
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Oth
https://bugzilla.kernel.org/show_bug.cgi?id=82551
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vid
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/e600ad7e/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/dc8072e1/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/7f19ceb6/attachment.html>
On 08/21/2014 05:30 PM, Boris BREZILLON wrote:
> On Thu, 21 Aug 2014 17:04:34 +0200
> Andrzej Hajda wrote:
>
>> On 08/21/2014 03:21 PM, Thierry Reding wrote:
>>> On Thu, Aug 21, 2014 at 12:32:43PM +0200, Andrzej Hajda wrote:
On 08/21/2014 11:52 AM, Thierry Reding wrote:
> On Thu, Aug 21,
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/c5746f6a/attachment.html>
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=82912
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 1 +
include/drm/drm_pciids.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
include/drm/drm_pciids.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 3a9281b..b75b9a5 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -176,6 +1
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
include/drm/drm_pciids.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index b75b9a5..e973540 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -165,8
https://bugzilla.kernel.org/show_bug.cgi?id=82681
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
https://bugzilla.kernel.org/show_bug.cgi?id=82551
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/d11a87c2/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82721
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
https://bugzilla.kernel.org/show_bug.cgi?id=82681
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Boris,
On Thursday 21 August 2014 15:06:00 Boris BREZILLON wrote:
> On Thu, 21 Aug 2014 11:52:03 +0200 Thierry Reding wrote:
> > On Thu, Aug 21, 2014 at 11:41:59AM +0200, Boris BREZILLON wrote:
> >> On Thu, 21 Aug 2014 11:04:07 +0200 Thierry Reding wrote:
> >>> On Thu, Aug 21, 2014 at 10:37:06A
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/e9ed2eb7/attachment.html>
Hi Laurent,
On Thu, 21 Aug 2014 19:08:53 +0200
Laurent Pinchart wrote:
[...]
> > >>
> > >> While this could be acceptable when all drivers are statically linked
> > >> in the kernel, it might be problematic when you're using modules,
> > >> meaning that you won't be able to display anything on
https://bugzilla.kernel.org/show_bug.cgi?id=77261
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
ecting.
--
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/20140821/8fe93ef3/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82551
--- Comment #3 from Javier Fernandez ---
those are in a bug i opened to Canonical Launchpad (im not sure which is the
responsible group)
https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1357821
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=82551
--- Comment #4 from Javier Fernandez ---
also, this problem only happens using the open source ati driver. It works OK
with fglrx
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=82071
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Hello,
Triggered this while fuzzing v3.17-rc1-51-g372b1db with Trinity.
Tommi
[drm:drm_mode_legacy_fb_format] *ERROR* bad bpp, assuming x8r8g8b8 pixel format
divide error: [#1] SMP DEBUG_PAGEALLOC
CPU: 0 PID: 2854 Comm: trinity-c7 Not tainted 3.17.0-rc1+ #14
Hardware name: Bochs Bochs, BIO
.
--
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/20140821/fcbe4953/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82551
--- Comment #5 from Alex Deucher ---
If it works with 3.13 can you use git to bisect what change between 3.13 and
3.14 caused the regression?
--
You are receiving this mail because:
You are watching the assignee of the bug.
the atombios is
probably different.
--
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/20140821/3ce0f254/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/f0288ab6/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/36c9289d/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/3f620a2d/attachment-0001.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/45088440/attachment.html>
ttachments/20140821/7dbb07f2/attachment.html>
)
OS|All |Linux (All)
--
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/20140821/45bbcf10/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/7061708f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82551
--- Comment #6 from Javier Fernandez ---
ugh... i dont have enough skills for playing with kernel :S
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Thu, 21 August 2014 Andreas Noever wrote:
> dmesg with your patches and vga_set_default_device commented out
> (after "vgaarb: Boot video device...") as otherwise the system won't
> boot.
Do you know more precisely where your system hangs when it does not boot?
That's the part I can't find in
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/1d3c06ab/attachment.html>
On Thu, Aug 21, 2014 at 4:34 PM, Bruno Pr?mont
wrote:
> A second step would then be to tune vgaarb's initial selection.
> Bjorn, is it possible to verify which I/O ports are decoded by a PCI
> device at the time of adding it to vgaarb? If so, how? I would like to
> check for legacy VGA I/O range
Hi Egbert,
Thanks for your comment!! I will try to modify it and test in-house first.
Regards,
Y.C. Chen
-Original Message-
From: Egbert Eich [mailto:e...@freedesktop.org]
Sent: Thursday, August 21, 2014 5:06 PM
To: YC Chen
Cc: dri-devel at lists.freedesktop.org
Subject: Re: [PATCH] Fix
Make of_device_id array const, because all OF functions handle it as const.
Signed-off-by: Kiran Padwal
---
drivers/gpu/drm/sti/sti_hda.c |2 +-
drivers/gpu/drm/sti/sti_hdmi.c |2 +-
drivers/gpu/drm/sti/sti_tvout.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --gi
Hi Boris,
You can add
Tested-by: Ludovic Desroches
Only one issue but not related to your patches, you can't display
quickly the bootup logo since the panel detection takes too much
time.
Regards
Ludovic
On Tue, Jul 22, 2014 at 03:11:24PM +0200, Boris BREZILLON wrote:
> Hello,
>
> This patc
Make of_device_id array const, because all OF functions handle it as const.
Signed-off-by: Kiran Padwal
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
drivers/gpu/drm/exynos/exynos_hdmi.c|2 +-
drivers/gpu/drm/exynos/exynos_mixer.c |2 +-
3 files changed, 3 insertions(+), 3
&l);
> + pr_info("vgaarb: PCI:%s, bridge PCI:%s
> PCI_BRIDGE_CONTROL=%04x\n", pci_name(pdev), pci_name(bridge), (unsigned
> int)l);
> if (!(l & PCI_BRIDGE_CTL_VGA)) {
> vgadev->owns = 0;
> break;
-- next part --
A non-text attachment was scrubbed...
Name: dmesg
Type: application/octet-stream
Size: 110603 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/57cc82d7/attachment-0001.obj>
;s a lot more sensible, yes.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140821/3dd63faa/attachment.sig>
Make of_device_id array const, because all OF functions handle it as const.
Signed-off-by: Kiran Padwal
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c|4 ++--
drivers/gpu/drm/tilcdc/tilcdc_panel.c |4 ++--
drivers/gpu/drm/tilcdc/tilcdc_slave.c |4 ++--
drivers/gpu/drm/tilcdc/tilcdc_tf
90 matches
Mail list logo
