drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

[Valentin Rothberg]

On Thu, Apr 09, 2015 at 02:54:29PM -0400, Rob Clark wrote:
> On Thu, Apr 9, 2015 at 2:12 PM, Paul Bolle  wrote:
> > On Thu, 2015-04-09 at 19:07 +0200, Greg KH wrote:
> >> I really don't understand.  Why is this code in the kernel tree if it
> >> can't be built?  How does anyone use this?  By taking it and copying it
> >> where?  If it can't be built, and no one can update it, and of course
> >> not run it, why is it here?  What good is this code doing sitting here?
> >
> > The Erlangen bot (courtesy of Valentin, Stefan, and Andreas) has taken
> > over what I've been doing for quite some time, but doing it much more
> > thoroughly. And my experience tells me that the reports they'll send in
> > will trigger more discussions like this one.
> >
> > A lesson I learned from my daily checks for Kconfig oddities is that
> > people go to great lengths defending unbuildable code. (Do a web search
> > for ATHEROS_AR231X to find a discussion that dragged on for over three
> > years!) Personally I stopped caring after someone insisted on having a
> > file in the tree that was in no way connected to the build system: not a
> > single line in any of the Makefiles pointed at it. So, as far as I'm
> > concerned, if people can't point at a patch pending, somehow, somewhere,
> > that would make their code buildable one might as well delete the code.
> >
> > I really think it's as simple as that.
> >
> 
> In the example you reference, sure it is as simple as that.  But here
> we are not talking about files that aren't even referenced by build
> system.  We are talking about a driver which does build and run on
> upstream kernel, and which has a few small #ifdef blocks to simplify
> backporting to downstream kernels (which we still do need to use for
> some generations and some devices)
> 
> Sure, I'd love never to have to deal with a downstream kernel.  But
> really.. I didn't create the downstream mess in the arm/android
> ecosystem, I'm just trying to cope with it as best as possible.. don't
> hate the player, hate the game :-P

I really understand your point.  But I also see conflicting interests.

The goal of static analysis tools such as Paul's scripts, undertaker or
scripts/checkkconfigsymbols.py is to detect and ideally avoid certain
kind of bugs.  Having to deal with intentional dead code or entirely
dead files makes such analysis quite challenging.  The main issue for
the tools is that as soon as there is a CONFIG_ prefixed identifier, it
will be treated as a Kconfig variable.  Strictly speaking, it's
violating the Kconfig naming convention for the upstream case.

Then there is another issue maintaining the code, studying the code,
making any kind of analysis.  How should people know which code is meant
for upstream, downstream or other streams?  Currently I am working on
detecting deprecated functions, data types, etc.  If there were too many
of such downstream #ifdefs, it would inherently complicate affords.

So I try to discourage such cases for the aforementioned reasons.  But
that's just my humble opinion and for sure my own interests : )

In any case, thank you a lot for taking the time explain everything in
such nice detail.  I learned a lot!

Kind regards,
 Valentin

> 
> BR,
> -R
> 
> >
> > Paul Bolle
> >

drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

[Paul Bolle]

On Thu, 2015-04-09 at 14:54 -0400, Rob Clark wrote:
> We are talking about a driver which does build and run on
> upstream kernel, and which has a few small #ifdef blocks to simplify
> backporting to downstream kernels (which we still do need to use for
> some generations and some devices)

This has comes up before too. My thoughts are basically that since it's
just a few blocks of code (I think we're discussing less than 200 lines
of code split over nine files here) it's hard to see why it would be
such a burden to carry those blocks in a separate tree until everything
can be submitted in actual working condition.


Paul Bolle

libva decoding performance regression with kernel 4.0-rc

[Olivier Crête]

Hello,

Using an Atom E3845 board, we had a pretty bad performance regression
when upgrading to 4.0-rc6 from 3.19. With the help of git bisect, I
traced it back to commit 78a42377. Reverting this commit and subsequent
related commits (b9ffd80, 71745376, etc) fixes the performance
regression for me.

Without those patches, I can play 8-9 1080p MPEG2 streams, after them,
it's down to 5-6.

I tested using a libdrm checkout from Feb 16, and the latest git master
of libva, libva-intel-driver and gst-plugins-vaapi. The "identity
drop-probability=1" is to prevent anything from being displayed, so it's
purely decoding performance.

Pure decode, single stream not displayed:
time gst-launch-1.0 filesrc 
location=18Mbps_CBR_MPEG2_Main-High_1920x1080p_16x9_29-97fps.m2t ! tsdemux ! 
mpegvideoparse ! vaapidecode ! identity drop-probability=1 ! vaapisink

With kernel 3.18.0-rc7-01052-g493018d
real0m11.429s
user0m6.516s
sys 0m1.640s

With kernel 3.18.0-rc7-01053-g78a4237
real0m12.694s
user0m6.744s
sys 0m2.680s


8 simultaneous streams displayed:
time gst-launch-1.0 filesrc 
location=18Mbps_CBR_MPEG2_Main-High_1920x1080p_16x9_29-97fps.m2t ! tsdemux ! 
mpegvideoparse ! vaapidecode ! vaapisink sync=0 \
  filesrc location=18Mbps_CBR_MPEG2_Main-High_1920x1080p_16x9_29-97fps.m2t ! 
tsdemux ! mpegvideoparse ! vaapidecode ! vaapisink sync=0 \
  filesrc location=18Mbps_CBR_MPEG2_Main-High_1920x1080p_16x9_29-97fps.m2t ! 
tsdemux ! mpegvideoparse ! vaapidecode ! vaapisink sync=0 \
  filesrc location=18Mbps_CBR_MPEG2_Main-High_1920x1080p_16x9_29-97fps.m2t ! 
tsdemux ! mpegvideoparse ! vaapidecode ! vaapisink sync=0 \
  filesrc location=18Mbps_CBR_MPEG2_Main-High_1920x1080p_16x9_29-97fps.m2t ! 
tsdemux ! mpegvideoparse ! vaapidecode ! vaapisink sync=0 \
  filesrc location=18Mbps_CBR_MPEG2_Main-High_1920x1080p_16x9_29-97fps.m2t ! 
tsdemux ! mpegvideoparse ! vaapidecode ! vaapisink sync=0 \
  filesrc location=18Mbps_CBR_MPEG2_Main-High_1920x1080p_16x9_29-97fps.m2t ! 
tsdemux ! mpegvideoparse ! vaapidecode ! vaapisink sync=0 \
  filesrc location=18Mbps_CBR_MPEG2_Main-High_1920x1080p_16x9_29-97fps.m2t ! 
tsdemux ! mpegvideoparse ! vaapidecode ! vaapisink sync=0

With kernel 3.18.0-rc7-01052-g493018d
real2m45.317s
user1m21.296s
sys 0m51.080s

With kernel 3.18.0-rc7-01053-g78a4237
real3m1.275s
user1m24.336s
sys 1m38.360s


-- 
Olivier Crête
olivier.crete at collabora.com

[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89971

--- Comment #2 from Adrian Gabor  ---
Created attachment 115001
  --> https://bugs.freedesktop.org/attachment.cgi?id=115001=edit
log file (journalctl -b)

-- 
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/20150409/813ff122/attachment.html>

[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89971

Ilia Mirkin  changed:

   What|Removed |Added

 Attachment #114999|text/plain  |image/jpeg
  mime type||

-- 
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/20150409/01fe0966/attachment.html>

[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89971

--- Comment #1 from Adrian Gabor  ---
Created attachment 115000
  --> https://bugs.freedesktop.org/attachment.cgi?id=115000=edit
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/20150409/39d5df2b/attachment.html>

[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89971

Bug ID: 89971
   Summary: HDMI out *not* working with radeon (mobile 8550g)
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adrianovidiugabor at gmail.com

Created attachment 114999
  --> https://bugs.freedesktop.org/attachment.cgi?id=114999=edit
screen's content

Hi all.

If I'm connecting my laptop's HDMI out to my TV I get a black screen with
garbage on top (see attached pic). This is with mirror mode on. If making the
second screen primary, the pc blocks and I have to restart it. It won't unblock
even if I disconnect the cable.

If switching to one of the virtual consoles, everything works correctly as it
should, so the problem seems to be related somehow to the display server. 

The Tv is recognized correctly by xrandr.

Specs: Asus laptop, with AMD A8-5550M, Radeon 8550G(Aruba)/8670M(Hainan), OS
ArchLinux(x64) Xorg-xerver 1.17, kernel 3.19.3, Mesa-git, xf86-ati-git,
llvm-svn.

This doesn't seem to be a regression (experienced it with older versions of the
kernel and userspace components) and it's reproducible on another machine. 

HDMI out works on Windows and ChromeOS.
Didn't try Catalyst on Linux.

-- 
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/20150409/1a2e91fc/attachment-0001.html>

[Bug 96361] [Bisected, radeon]Non-infinite boot loop since v3.13

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96361

--- Comment #4 from Alex Deucher  ---
forcing dpm=1 enables additional debugging output not present when the
parameter is not explicitly set.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

[Paul Bolle]

On Thu, 2015-04-09 at 19:07 +0200, Greg KH wrote:
> I really don't understand.  Why is this code in the kernel tree if it
> can't be built?  How does anyone use this?  By taking it and copying it
> where?  If it can't be built, and no one can update it, and of course
> not run it, why is it here?  What good is this code doing sitting here?

The Erlangen bot (courtesy of Valentin, Stefan, and Andreas) has taken
over what I've been doing for quite some time, but doing it much more
thoroughly. And my experience tells me that the reports they'll send in
will trigger more discussions like this one.

A lesson I learned from my daily checks for Kconfig oddities is that
people go to great lengths defending unbuildable code. (Do a web search
for ATHEROS_AR231X to find a discussion that dragged on for over three
years!) Personally I stopped caring after someone insisted on having a
file in the tree that was in no way connected to the build system: not a
single line in any of the Makefiles pointed at it. So, as far as I'm
concerned, if people can't point at a patch pending, somehow, somewhere,
that would make their code buildable one might as well delete the code.

I really think it's as simple as that.


Paul Bolle

[Bug 96361] [Bisected, radeon]Non-infinite boot loop since v3.13

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96361

--- Comment #3 from servuswiegehtz at yahoo.de ---
bug is only present with radeon.dpm=1 (default?), with radeon.dpm=0 there are
no issues

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 05/45] drm.h: include stdlib.h in userspace

[Mikko Rapeli]

On Thu, Apr 09, 2015 at 05:00:48PM +0100, Emil Velikov wrote:
> Hi Mikko
> 
> Pardon for the late response,
> 
> On 21 March 2015 at 12:17, Mikko Rapeli  wrote:
> > On Fri, Mar 20, 2015 at 08:25:40PM +, Emil Velikov wrote:
> >> On 23 February 2015 at 10:35, Mikko Rapeli  wrote:
> >> > On Mon, Feb 23, 2015 at 10:26:58AM +, Emil Velikov wrote:
> >> >> On 16/02/15 23:05, Mikko Rapeli wrote:
> >> >> > Fixes  compilation error:
> >> >> >
> >> >> > drm/drm.h:132:2: error: unknown type name ‘size_t’
> >> >> >
> >> >> Hi Mikko,
> >> >>
> >> >> Can you let us know how you're getting these (series-wise) errors ? I've
> >> >> been meaning to sync the uapi/drm and libdrm headers and would be nice
> >> >> to have an extra step to test things.
> >> >
> >> > This should have everything needed to reproduce these compile errors,
> >> > though some of the errors hide behind other errors and fixes:
> >> >
> >> > https://lkml.org/lkml/2015/2/16/525
> >> >
> >> Thanks for the link Mikko.
> >>
> >> Afaict the general consensus seems to be that one should avoid using
> >> stdint's uint8_t, but stick to __u8 and friends. Did you had the
> >> chance to roll out another series that does so ?
> >
> > Yes, new series with these changes is on the way. I'm trying to follow up to
> > all other review comments as well and get down to 100% compiling uapi
> > headers; 35 failures to go...
> >
> Glad to hear that it's getting there. Might be a bit slower than
> expected but we'll get there :-) Can you please Cc me on the next
> iteration ?

Yes will Cc you too, and sorry life is getting on the way of this work. Draft
version is visible at

https://github.com/torvalds/linux/compare/master...mcfrisk:headers_test_v03

-Mikko

drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

[Greg KH]

On Thu, Apr 09, 2015 at 10:50:58AM -0400, Rob Clark wrote:
> On Thu, Apr 9, 2015 at 10:20 AM, Greg KH  
> wrote:
> > On Thu, Apr 09, 2015 at 09:49:58AM -0400, Rob Clark wrote:
> >> On Thu, Apr 9, 2015 at 7:22 AM, Valentin Rothberg
> >>  wrote:
> >> > Hi Hai,
> >> >
> >> > your commit d5af49c92a8a ("drm/msm/mdp5: Enable DSI connector in msm drm
> >> > driver") in today's Linux next tree adds an #ifdef with 
> >> > CONFIG_MSM_BUS_SCALING
> >> > as condition.  MSM_BUS_SCALING is not defined in Kconfig, so the code in 
> >> > this
> >> > #ifdef block won't be compiled at its current state.
> >> >
> >> > I saw some references on this Kconfig option in other files; is there a
> >> > reason for the absence of MSM_BUS_SCALING?
> >>
> >> right now, it is something that only exists in downstream kernels (for
> >> example, android device kernels).. but in those kernels it is
> >> mandatory to use, as by default the memory/bus is downclocked and the
> >> display would underflow if we did not request sufficient bandwidth.
> >>
> >> It only exists right now in the upstream kernel to simplify
> >> backporting to various device kernels
> >
> > That's crazy.  You are asking upstream to maintain code in order to just
> > make out of tree crap easier to maintain, which you don't have any plan
> > to ever upstream?  That causes havoc on static analysis tools and
> > prevents anyone from ever being able to even change the code for new api
> > changes and test build it.
> 
> Hey, don't blame me for the downstream kernels.  But at various points
> in time I've had to backport drm/msm to various device kernels in
> order to work on the userspace/mesa end of things.  (And, well, there
> are other crazy folks out there who want to get open source graphics
> drivers working on various phones/tablets.)  It was a choice to make
> my life easier.  You know, because reverse engineering a gpu is a walk
> in the park..

I really don't understand.  Why is this code in the kernel tree if it
can't be built?  How does anyone use this?  By taking it and copying it
where?  If it can't be built, and no one can update it, and of course
not run it, why is it here?  What good is this code doing sitting here?

confused,

greg k-h

[Bug 96361] [Bisected, radeon]Non-infinite boot loop since v3.13

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96361

--- Comment #2 from servuswiegehtz at yahoo.de ---
Created attachment 173691
  --> https://bugzilla.kernel.org/attachment.cgi?id=173691=edit
dmesg output

dmesg output with radeon.dpm=1
(in this case the pc managed to boot to linux, as mentioned there is no log
when it fails, or is journalctl --boot=-1 the wrong way to get the previous
log? (systemd))

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Valve games for Mesa/DRI developers

[Daniel Stone]

Hi,
At Collabora (my lovely dayjob), we've been working with Valve on
SteamOS. Valve are keen to give back to the community, and we've been
discussing ways they can help do that, including providing free access
to Valve games on Steam to Debian developers last year.

We're happy to say that this has been extended to Mesa developers as
well, to say thanks for all the great work. If you have 25 commits or
more (an arbitrary number) to Mesa[0] in the past five years, please
drop me an email (with 'Steam' in the subject) with your freedesktop
username and Steam username. We can then get you access to all past
and future Valve-produced games available on Steam[1].

Thanks for all the great work, and enjoy.

Cheers,
Daniel

[0]: Or DRI-type stuff in the kernel too.
[1]: Currently this looks like
https://store.steampowered.com/search/?snr=1_4_4__12=#category1=998=Valve_order=ASC=1

[PATCH 01/14] drm: Adding drm helper function drm_plane_from_index().

[Chandra Konduru]

Adding drm helper function to return plane pointer from index where
index is a returned by drm_plane_index.

v2:
-avoided nested loop by adding loop count (Daniel)

v3:
-updated patch header prefix to 'drm' (Matt)

v4:
-fixed a kerneldoc issue (kbuild-internal)

Cc: dri-devel at lists.freedesktop.org

Signed-off-by: Chandra Konduru 
---
 drivers/gpu/drm/drm_crtc.c |   23 +++
 include/drm/drm_crtc.h |1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d576a4d..ad4d9ae 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1289,6 +1289,29 @@ unsigned int drm_plane_index(struct drm_plane *plane)
 EXPORT_SYMBOL(drm_plane_index);

 /**
+ * drm_plane_from_index - find the registered plane at an index
+ * @dev: DRM device
+ * @idx: index of registered plane to find for
+ *
+ * Given a plane index, return the registered plane from DRM device's
+ * list of planes with matching index.
+ */
+struct drm_plane *
+drm_plane_from_index(struct drm_device *dev, int idx)
+{
+   struct drm_plane *plane;
+   unsigned int i = 0;
+
+   list_for_each_entry(plane, >mode_config.plane_list, head) {
+   if (i == idx)
+   return plane;
+   i++;
+   }
+   return NULL;
+}
+EXPORT_SYMBOL(drm_plane_from_index);
+
+/**
  * drm_plane_force_disable - Forcibly disable a plane
  * @plane: plane to disable
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7b5c661..6b30036 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1264,6 +1264,7 @@ extern int drm_plane_init(struct drm_device *dev,
  bool is_primary);
 extern void drm_plane_cleanup(struct drm_plane *plane);
 extern unsigned int drm_plane_index(struct drm_plane *plane);
+extern struct drm_plane * drm_plane_from_index(struct drm_device *dev, int 
idx);
 extern void drm_plane_force_disable(struct drm_plane *plane);
 extern int drm_plane_check_pixel_format(const struct drm_plane *plane,
u32 format);
-- 
1.7.9.5

[PATCH 05/45] drm.h: include stdlib.h in userspace

[Emil Velikov]

Hi Mikko

Pardon for the late response,

On 21 March 2015 at 12:17, Mikko Rapeli  wrote:
> On Fri, Mar 20, 2015 at 08:25:40PM +, Emil Velikov wrote:
>> On 23 February 2015 at 10:35, Mikko Rapeli  wrote:
>> > On Mon, Feb 23, 2015 at 10:26:58AM +, Emil Velikov wrote:
>> >> On 16/02/15 23:05, Mikko Rapeli wrote:
>> >> > Fixes  compilation error:
>> >> >
>> >> > drm/drm.h:132:2: error: unknown type name ‘size_t’
>> >> >
>> >> Hi Mikko,
>> >>
>> >> Can you let us know how you're getting these (series-wise) errors ? I've
>> >> been meaning to sync the uapi/drm and libdrm headers and would be nice
>> >> to have an extra step to test things.
>> >
>> > This should have everything needed to reproduce these compile errors,
>> > though some of the errors hide behind other errors and fixes:
>> >
>> > https://lkml.org/lkml/2015/2/16/525
>> >
>> Thanks for the link Mikko.
>>
>> Afaict the general consensus seems to be that one should avoid using
>> stdint's uint8_t, but stick to __u8 and friends. Did you had the
>> chance to roll out another series that does so ?
>
> Yes, new series with these changes is on the way. I'm trying to follow up to
> all other review comments as well and get down to 100% compiling uapi
> headers; 35 failures to go...
>
Glad to hear that it's getting there. Might be a bit slower than
expected but we'll get there :-) Can you please Cc me on the next
iteration ?

>> That aside I'm not 100% sure that doing the UAPI split, as is, was the
>> perfect solution. Afaik drm used to live as an out of tree userspace
>> library(libdrm). Not sure at which point the major restructuring took
>> part, but one is certain - libdrm remains the only authoritative
>> sources of the headers. It's possible that some buggy programs pull
>> the UAPI headers while linking against the library, but I'd say that
>> won't end up well in the long term. Additionally since the UAPI split
>> the `make update-headers' target used to sync libdrm's headers have
>> been broken leading people to copy misc. hunks and/or files. Leading
>> to greater chance of things going sour.
>>
>> All that said, I will need to gather some opinions for drm developers
>> and maintainers if the idea of part revering 718dcedd7e8(UAPI:
>> (Scripted) Disintegrate include/drm) will be the way forward.
>
> Ok, I'll follow what is available in Linus' tree (or -next, not shure which
> one I should track for these changes).
>
After discussing (more like annoying) our DRM maintainer we got to the
conclusion that the headers will stay exposed to userspace. So any and
all of your work will be greatly appreciated.

Thanks
Emil

[PATCH v2] drm/msm: Fix a couple of 64-bit build warnings

[Thierry Reding]

From: Thierry Reding <tred...@nvidia.com>

Avoid casts from pointers to fixed-size integers to prevent the compiler
from warning. Print virtual memory addresses using %p instead. Also turn
a couple of %d/%x specifiers into %zu/%zd/%zx to avoid further warnings
due to mismatched format strings.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- print physical addresses using %pa (fixes another warning that started
  to appear in next-20150409)

 drivers/gpu/drm/msm/edp/edp_aux.c |  4 ++--
 drivers/gpu/drm/msm/msm_drv.c | 10 +-
 drivers/gpu/drm/msm/msm_gem.c |  2 +-
 drivers/gpu/drm/msm/msm_iommu.c   |  4 ++--
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/edp/edp_aux.c 
b/drivers/gpu/drm/msm/edp/edp_aux.c
index 5f5a84f6074c..208f9d47f82e 100644
--- a/drivers/gpu/drm/msm/edp/edp_aux.c
+++ b/drivers/gpu/drm/msm/edp/edp_aux.c
@@ -132,7 +132,7 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct 
drm_dp_aux_msg *msg)
/* msg sanity check */
if ((native && (msg->size > AUX_CMD_NATIVE_MAX)) ||
(msg->size > AUX_CMD_I2C_MAX)) {
-   pr_err("%s: invalid msg: size(%d), request(%x)\n",
+   pr_err("%s: invalid msg: size(%zu), request(%x)\n",
__func__, msg->size, msg->request);
return -EINVAL;
}
@@ -155,7 +155,7 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct 
drm_dp_aux_msg *msg)
 */
edp_write(aux->base + REG_EDP_AUX_TRANS_CTRL, 0);
msm_edp_aux_ctrl(aux, 1);
-   pr_err("%s: aux timeout, %d\n", __func__, ret);
+   pr_err("%s: aux timeout, %zd\n", __func__, ret);
goto unlock_exit;
}
DBG("completion");
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 47f4dd407671..cc5dc5299b8d 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -94,7 +94,7 @@ void __iomem *msm_ioremap(struct platform_device *pdev, const 
char *name,
}

if (reglog)
-   printk(KERN_DEBUG "IO:region %s %08x %08lx\n", dbgname, 
(u32)ptr, size);
+   printk(KERN_DEBUG "IO:region %s %p %08lx\n", dbgname, ptr, 
size);

return ptr;
 }
@@ -102,7 +102,7 @@ void __iomem *msm_ioremap(struct platform_device *pdev, 
const char *name,
 void msm_writel(u32 data, void __iomem *addr)
 {
if (reglog)
-   printk(KERN_DEBUG "IO:W %08x %08x\n", (u32)addr, data);
+   printk(KERN_DEBUG "IO:W %p %08x\n", addr, data);
writel(data, addr);
 }

@@ -110,7 +110,7 @@ u32 msm_readl(const void __iomem *addr)
 {
u32 val = readl(addr);
if (reglog)
-   printk(KERN_ERR "IO:R %08x %08x\n", (u32)addr, val);
+   printk(KERN_ERR "IO:R %p %08x\n", addr, val);
return val;
 }

@@ -177,7 +177,7 @@ static int get_mdp_ver(struct platform_device *pdev)
const struct of_device_id *match;
match = of_match_node(match_types, dev->of_node);
if (match)
-   return (int)match->data;
+   return (int)(unsigned long)match->data;
 #endif
return 4;
 }
@@ -216,7 +216,7 @@ static int msm_init_vram(struct drm_device *dev)
if (ret)
return ret;
size = r.end - r.start;
-   DRM_INFO("using VRAM carveout: %lx@%08x\n", size, r.start);
+   DRM_INFO("using VRAM carveout: %lx@%pa\n", size, );
} else
 #endif

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 479d8af72bcb..52839769eb6c 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -483,7 +483,7 @@ void msm_gem_describe(struct drm_gem_object *obj, struct 
seq_file *m)
uint64_t off = drm_vma_node_start(>vma_node);

WARN_ON(!mutex_is_locked(>struct_mutex));
-   seq_printf(m, "%08x: %c(r=%u,w=%u) %2d (%2d) %08llx %p %d\n",
+   seq_printf(m, "%08x: %c(r=%u,w=%u) %2d (%2d) %08llx %p %zu\n",
msm_obj->flags, is_active(msm_obj) ? 'A' : 'I',
msm_obj->read_fence, msm_obj->write_fence,
obj->name, obj->refcount.refcount.counter,
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 7acdaa5688b7..7ac2f1997e4a 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -60,7 +60,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint32_t iova,
u32 pa = sg_phys(sg) - sg->offset;
size_t bytes = sg->length + sg->offset;

-   VERB("map[%d]: %08x %08x(%x)", i, iova, pa, bytes);
+ 

[PATCH 6/6] drm/msm: gem: Use drm_clflush_*() functions

[Thierry Reding]

From: Thierry Reding 

Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.

Cc: Rob Clark 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/msm/Kconfig   | 1 +
 drivers/gpu/drm/msm/msm_gem.c | 9 +
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 0a6f6764a37c..5da7fe793e89 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -5,6 +5,7 @@ config DRM_MSM
depends on ARCH_QCOM || (ARM && COMPILE_TEST)
depends on OF && COMMON_CLK
select REGULATOR
+   select DRM_CACHE
select DRM_KMS_HELPER
select DRM_PANEL
select SHMEM
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 52839769eb6c..ce265085fc57 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -101,8 +101,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
 * because display controller, GPU, etc. are not coherent:
 */
if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
-   dma_map_sg(dev->dev, msm_obj->sgt->sgl,
-   msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
+   drm_clflush_sg(msm_obj->sgt);
}

return msm_obj->pages;
@@ -113,12 +112,6 @@ static void put_pages(struct drm_gem_object *obj)
struct msm_gem_object *msm_obj = to_msm_bo(obj);

if (msm_obj->pages) {
-   /* For non-cached buffers, ensure the new pages are clean
-* because display controller, GPU, etc. are not coherent:
-*/
-   if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
-   dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
-   msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
sg_free_table(msm_obj->sgt);
kfree(msm_obj->sgt);

-- 
2.3.2

[PATCH 5/6] drm/armada: gem: Use drm_clflush_*() functions

[Thierry Reding]

From: Thierry Reding 

Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.

Cc: Russell King 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/armada/Kconfig  |  1 +
 drivers/gpu/drm/armada/armada_gem.c | 13 ++---
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index 50ae88ad4d76..7b7070128a05 100644
--- a/drivers/gpu/drm/armada/Kconfig
+++ b/drivers/gpu/drm/armada/Kconfig
@@ -4,6 +4,7 @@ config DRM_ARMADA
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+   select DRM_CACHE
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
help
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 580e10acaa3a..c2d4414031ab 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -453,19 +453,14 @@ armada_gem_prime_map_dma_buf(struct dma_buf_attachment 
*attach,
sg_set_page(sg, page, PAGE_SIZE, 0);
}

-   if (dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir) == 0) {
-   num = sgt->nents;
-   goto release;
-   }
+   drm_clflush_sg(sgt);
} else if (dobj->page) {
/* Single contiguous page */
if (sg_alloc_table(sgt, 1, GFP_KERNEL))
goto free_sgt;

sg_set_page(sgt->sgl, dobj->page, dobj->obj.size, 0);
-
-   if (dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir) == 0)
-   goto free_table;
+   drm_clflush_sg(sgt);
} else if (dobj->linear) {
/* Single contiguous physical region - no struct page */
if (sg_alloc_table(sgt, 1, GFP_KERNEL))
@@ -480,7 +475,6 @@ armada_gem_prime_map_dma_buf(struct dma_buf_attachment 
*attach,
  release:
for_each_sg(sgt->sgl, sg, num, i)
page_cache_release(sg_page(sg));
- free_table:
sg_free_table(sgt);
  free_sgt:
kfree(sgt);
@@ -494,9 +488,6 @@ static void armada_gem_prime_unmap_dma_buf(struct 
dma_buf_attachment *attach,
struct armada_gem_object *dobj = drm_to_armada_gem(obj);
int i;

-   if (!dobj->linear)
-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
-
if (dobj->obj.filp) {
struct scatterlist *sg;
for_each_sg(sgt->sgl, sg, sgt->nents, i)
-- 
2.3.2

[PATCH 4/6] drm/tegra: gem: Use drm_clflush_*() functions

[Thierry Reding]

From: Thierry Reding 

Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/Kconfig |  1 +
 drivers/gpu/drm/tegra/gem.c   | 42 +++---
 2 files changed, 12 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 74d9d621453d..4901f20f99a1 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -4,6 +4,7 @@ config DRM_TEGRA
depends on COMMON_CLK
depends on DRM
depends on RESET_CONTROLLER
+   select DRM_CACHE
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 499f86739786..11e97a46e63d 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -203,48 +203,28 @@ static void tegra_bo_free(struct drm_device *drm, struct 
tegra_bo *bo)

 static int tegra_bo_get_pages(struct drm_device *drm, struct tegra_bo *bo)
 {
-   struct scatterlist *s;
-   struct sg_table *sgt;
-   unsigned int i;
-
bo->pages = drm_gem_get_pages(>gem);
if (IS_ERR(bo->pages))
return PTR_ERR(bo->pages);

bo->num_pages = bo->gem.size >> PAGE_SHIFT;

-   sgt = drm_prime_pages_to_sg(bo->pages, bo->num_pages);
-   if (IS_ERR(sgt))
-   goto put_pages;
+   bo->sgt = drm_prime_pages_to_sg(bo->pages, bo->num_pages);
+   if (IS_ERR(bo->sgt)) {
+   drm_gem_put_pages(>gem, bo->pages, false, false);
+   return PTR_ERR(bo->sgt);
+   }

-#ifndef CONFIG_ARM64
/*
-* Fake up the SG table so that dma_map_sg() can be used to flush the
-* pages associated with it. Note that this relies on the fact that
-* the DMA API doesn't hook into IOMMU on Tegra, therefore mapping is
-* only cache maintenance.
-*
-* TODO: Replace this by drm_clflash_sg() once it can be implemented
-* without relying on symbols that are not exported.
+* Pages allocated by shmemfs are marked dirty but not flushed on
+* ARMv7 and ARMv8. Since this memory is used to back framebuffers,
+* however, they must be forced out of caches to avoid corruption
+* on screen later on as the result of dirty cache-lines being
+* flushed.
 */
-   for_each_sg(sgt->sgl, s, sgt->nents, i)
-   sg_dma_address(s) = sg_phys(s);
-
-   if (dma_map_sg(drm->dev, sgt->sgl, sgt->nents, DMA_TO_DEVICE) == 0)
-   goto release_sgt;
-#endif
-
-   bo->sgt = sgt;
+   drm_clflush_sg(bo->sgt);

return 0;
-
-release_sgt:
-   sg_free_table(sgt);
-   kfree(sgt);
-   sgt = ERR_PTR(-ENOMEM);
-put_pages:
-   drm_gem_put_pages(>gem, bo->pages, false, false);
-   return PTR_ERR(sgt);
 }

 static int tegra_bo_alloc(struct drm_device *drm, struct tegra_bo *bo)
-- 
2.3.2

[PATCH 3/6] drm/cache: Implement drm_clflush_*() for 64-bit ARM

[Thierry Reding]

From: Thierry Reding 

Add implementations for drm_clflush_*() on 64-bit ARM. This shares a lot
of code with the 32-bit ARM implementation.

Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_cache.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 200d86c3d72d..0c3072b4cdc9 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -102,6 +102,17 @@ static void drm_clflush_page(struct page *page)
 }
 #endif

+#if defined(CONFIG_ARM64)
+static void drm_clflush_page(struct page *page)
+{
+   void *virt;
+
+   virt = kmap_atomic(page);
+   __dma_flush_range(virt, virt + PAGE_SIZE);
+   kunmap_atomic(virt);
+}
+#endif
+
 void
 drm_clflush_pages(struct page *pages[], unsigned long num_pages)
 {
@@ -129,7 +140,7 @@ drm_clflush_pages(struct page *pages[], unsigned long 
num_pages)
   (unsigned long)page_virtual + PAGE_SIZE);
kunmap_atomic(page_virtual);
}
-#elif defined(CONFIG_ARM)
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
unsigned long i;

for (i = 0; i < num_pages; i++)
@@ -158,7 +169,7 @@ drm_clflush_sg(struct sg_table *st)

if (wbinvd_on_all_cpus())
printk(KERN_ERR "Timed out waiting for cache flush.\n");
-#elif defined(CONFIG_ARM)
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
struct sg_page_iter sg_iter;

for_each_sg_page(st->sgl, _iter, st->nents, 0)
-- 
2.3.2

[PATCH 2/6] drm/cache: Implement drm_clflush_*() for ARM

[Thierry Reding]

From: Thierry Reding 

Add implementations for drm_clflush_*() on ARM by borrowing code from
the DMA mapping API implementation. Unfortunately ARM doesn't export an
API to flush caches on a page by page basis, so this replicates most of
the code.

Reviewed-by: Rob Clark 
Tested-by: Rob Clark 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_cache.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 9a62d7a53553..200d86c3d72d 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -67,6 +67,41 @@ static void drm_cache_flush_clflush(struct page *pages[],
 }
 #endif

+#if defined(CONFIG_ARM)
+
+#include 
+#include 
+#include 
+#include 
+
+static void drm_clflush_page(struct page *page)
+{
+   enum dma_data_direction dir = DMA_TO_DEVICE;
+   phys_addr_t phys = page_to_phys(page);
+   size_t size = PAGE_SIZE;
+   void *virt;
+
+   if (PageHighMem(page)) {
+   if (cache_is_vipt_nonaliasing()) {
+   virt = kmap_atomic(page);
+   dmac_map_area(virt, size, dir);
+   kunmap_atomic(virt);
+   } else {
+   virt = kmap_high_get(page);
+   if (virt) {
+   dmac_map_area(virt, size, dir);
+   kunmap_high(page);
+   }
+   }
+   } else {
+   virt = page_address(page);
+   dmac_map_area(virt, size, dir);
+   }
+
+   outer_flush_range(phys, phys + PAGE_SIZE);
+}
+#endif
+
 void
 drm_clflush_pages(struct page *pages[], unsigned long num_pages)
 {
@@ -94,6 +129,11 @@ drm_clflush_pages(struct page *pages[], unsigned long 
num_pages)
   (unsigned long)page_virtual + PAGE_SIZE);
kunmap_atomic(page_virtual);
}
+#elif defined(CONFIG_ARM)
+   unsigned long i;
+
+   for (i = 0; i < num_pages; i++)
+   drm_clflush_page(pages[i]);
 #else
printk(KERN_ERR "Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
@@ -118,6 +158,11 @@ drm_clflush_sg(struct sg_table *st)

if (wbinvd_on_all_cpus())
printk(KERN_ERR "Timed out waiting for cache flush.\n");
+#elif defined(CONFIG_ARM)
+   struct sg_page_iter sg_iter;
+
+   for_each_sg_page(st->sgl, _iter, st->nents, 0)
+   drm_clflush_page(sg_page_iter_page(_iter));
 #else
printk(KERN_ERR "Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
-- 
2.3.2

[PATCH 1/6] drm/cache: Build-in drm_clflush_*() functions

[Thierry Reding]

From: Thierry Reding 

Irrespective of whether or not the DRM core is built as a module, build
the cache flush functions into the kernel. This is required because the
implementation may require functions that shouldn't be exported to most
drivers. DRM is somewhat of a special case here because it requires the
cache maintenance functions to properly flush pages backed by shmemfs.
These pages are directly given to display hardware for scanout, so they
must be purged from any caches to avoid visual corruption on screen.

To achieve this, add a new boolean Kconfig symbol that drivers can
select if they use any of these functions. drm_cache.c is then built if
and only if this symbol is selected. TTM and the i915 driver already use
these functions, so make them select DRM_CACHE.

Suggested-by: Arnd Bergmann 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/Kconfig  | 5 +
 drivers/gpu/drm/Makefile | 3 ++-
 drivers/gpu/drm/i915/Kconfig | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 47f2ce81b412..25bffdb89304 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -21,6 +21,10 @@ menuconfig DRM
  details.  You should also select and configure AGP
  (/dev/agpgart) support if it is available for your platform.

+config DRM_CACHE
+   bool
+   depends on DRM
+
 config DRM_MIPI_DSI
bool
depends on DRM
@@ -55,6 +59,7 @@ config DRM_LOAD_EDID_FIRMWARE
 config DRM_TTM
tristate
depends on DRM
+   select DRM_CACHE
help
  GPU memory management subsystem for devices with multiple
  GPU memory types. Will be enabled automatically if a device driver
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7d4944e1a60c..1ad54a0e4467 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -4,7 +4,7 @@

 ccflags-y := -Iinclude/drm

-drm-y   := drm_auth.o drm_bufs.o drm_cache.o \
+drm-y   := drm_auth.o drm_bufs.o \
drm_context.o drm_dma.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
@@ -33,6 +33,7 @@ obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
 CFLAGS_drm_trace_points.o := -I$(src)

 obj-$(CONFIG_DRM)  += drm.o
+obj-$(CONFIG_DRM_CACHE) += drm_cache.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
 obj-$(CONFIG_DRM_TTM)  += ttm/
 obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 74acca9bcd9d..237be03e8a7c 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -10,6 +10,7 @@ config DRM_I915
# the shmem_readpage() which depends upon tmpfs
select SHMEM
select TMPFS
+   select DRM_CACHE
select DRM_KMS_HELPER
select DRM_PANEL
select DRM_MIPI_DSI
-- 
2.3.2

[PATCH] drm/exynos: use drm_plane_force_disable

[Gustavo Padovan]

Hi Joonyoung,

2015-04-09 Joonyoung Shim :

> Don't call directly disable callback of plane helper, we need to
> disconnect the plane from the fb and crtc after disable callback.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c| 5 +
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c | 2 +-
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 519c569..50c830e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -48,7 +48,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
>  {
>   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>   struct drm_plane *plane;
> - int ret;
>  
>   if (!exynos_crtc->enabled)
>   return;
> @@ -69,9 +68,7 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
>   if (plane->crtc != crtc)
>   continue;
>  
> - ret = plane->funcs->disable_plane(plane);
> - if (ret)
> - DRM_ERROR("Failed to disable plane %d\n", ret);
> + drm_plane_force_disable(plane);
>   }

Which tree did you based this code? I've removed all this code in atomic.
These two pieces of code makes no sense in atomic modesetting, disable would
be called from the drm atomic core there.

Gustavo

drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

[Rob Clark]

On Thu, Apr 9, 2015 at 3:44 PM, Valentin Rothberg
 wrote:
> On Thu, Apr 09, 2015 at 02:54:29PM -0400, Rob Clark wrote:
>> On Thu, Apr 9, 2015 at 2:12 PM, Paul Bolle  wrote:
>> > On Thu, 2015-04-09 at 19:07 +0200, Greg KH wrote:
>> >> I really don't understand.  Why is this code in the kernel tree if it
>> >> can't be built?  How does anyone use this?  By taking it and copying it
>> >> where?  If it can't be built, and no one can update it, and of course
>> >> not run it, why is it here?  What good is this code doing sitting here?
>> >
>> > The Erlangen bot (courtesy of Valentin, Stefan, and Andreas) has taken
>> > over what I've been doing for quite some time, but doing it much more
>> > thoroughly. And my experience tells me that the reports they'll send in
>> > will trigger more discussions like this one.
>> >
>> > A lesson I learned from my daily checks for Kconfig oddities is that
>> > people go to great lengths defending unbuildable code. (Do a web search
>> > for ATHEROS_AR231X to find a discussion that dragged on for over three
>> > years!) Personally I stopped caring after someone insisted on having a
>> > file in the tree that was in no way connected to the build system: not a
>> > single line in any of the Makefiles pointed at it. So, as far as I'm
>> > concerned, if people can't point at a patch pending, somehow, somewhere,
>> > that would make their code buildable one might as well delete the code.
>> >
>> > I really think it's as simple as that.
>> >
>>
>> In the example you reference, sure it is as simple as that.  But here
>> we are not talking about files that aren't even referenced by build
>> system.  We are talking about a driver which does build and run on
>> upstream kernel, and which has a few small #ifdef blocks to simplify
>> backporting to downstream kernels (which we still do need to use for
>> some generations and some devices)
>>
>> Sure, I'd love never to have to deal with a downstream kernel.  But
>> really.. I didn't create the downstream mess in the arm/android
>> ecosystem, I'm just trying to cope with it as best as possible.. don't
>> hate the player, hate the game :-P
>
> I really understand your point.  But I also see conflicting interests.
>
> The goal of static analysis tools such as Paul's scripts, undertaker or
> scripts/checkkconfigsymbols.py is to detect and ideally avoid certain
> kind of bugs.  Having to deal with intentional dead code or entirely
> dead files makes such analysis quite challenging.  The main issue for
> the tools is that as soon as there is a CONFIG_ prefixed identifier, it
> will be treated as a Kconfig variable.  Strictly speaking, it's
> violating the Kconfig naming convention for the upstream case.
>
> Then there is another issue maintaining the code, studying the code,
> making any kind of analysis.  How should people know which code is meant
> for upstream, downstream or other streams?  Currently I am working on
> detecting deprecated functions, data types, etc.  If there were too many
> of such downstream #ifdefs, it would inherently complicate affords.

Hmm, admittedly, I hadn't really considered the static analysis case
before today..

If at all possible, I would like to keep those, at least for the time
being, since it is one less thing for me to mess up on backports.

Not sure if a comment tag could help make things clear (for humans and
tools), ie.

#ifdef CONFIG_FOO
/* downstream bonghits */
...
#endif

no idea if that would be trivial or difficult to implement?  If the
latter, I can drop those parts of the code.  But if at all possible,
I'm always a fan of giving myself less things to screw up.

> So I try to discourage such cases for the aforementioned reasons.  But
> that's just my humble opinion and for sure my own interests : )
>
> In any case, thank you a lot for taking the time explain everything in
> such nice detail.  I learned a lot!

No problem, and thanks for your work

BR,
-R

> Kind regards,
>  Valentin
>
>>
>> BR,
>> -R
>>
>> >
>> > Paul Bolle
>> >

drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

[Greg KH]

On Thu, Apr 09, 2015 at 09:49:58AM -0400, Rob Clark wrote:
> On Thu, Apr 9, 2015 at 7:22 AM, Valentin Rothberg
>  wrote:
> > Hi Hai,
> >
> > your commit d5af49c92a8a ("drm/msm/mdp5: Enable DSI connector in msm drm
> > driver") in today's Linux next tree adds an #ifdef with 
> > CONFIG_MSM_BUS_SCALING
> > as condition.  MSM_BUS_SCALING is not defined in Kconfig, so the code in 
> > this
> > #ifdef block won't be compiled at its current state.
> >
> > I saw some references on this Kconfig option in other files; is there a
> > reason for the absence of MSM_BUS_SCALING?
> 
> right now, it is something that only exists in downstream kernels (for
> example, android device kernels).. but in those kernels it is
> mandatory to use, as by default the memory/bus is downclocked and the
> display would underflow if we did not request sufficient bandwidth.
> 
> It only exists right now in the upstream kernel to simplify
> backporting to various device kernels

That's crazy.  You are asking upstream to maintain code in order to just
make out of tree crap easier to maintain, which you don't have any plan
to ever upstream?  That causes havoc on static analysis tools and
prevents anyone from ever being able to even change the code for new api
changes and test build it.

If this was in a subsystem that I maintain, I'd delete it tomorrow.  But
in the end, it's up to David to decide if he wants to waste the cycles
or not.

Ick ick ick.

greg k-h

[PATCH -v3 00/11] drm/exynos: Add atomic modesetting support

[Joonyoung Shim]

Hi,

On 04/09/2015 12:14 AM, Inki Dae wrote:
> On 2015년 04월 08일 03:39, Gustavo Padovan wrote:
>> Hi Inki,
>>
>> 2015-04-07 Inki Dae :
>>
>>> On 2015년 04월 07일 00:44, Inki Dae wrote:
 2015-04-06 19:46 GMT+09:00 Inki Dae :
> On 2015년 04월 04일 03:09, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> Hi,
>>
>> Here goes the full support for atomic modesetting on exynos. I've
>> split the patches in the various phases of atomic support.
>>
>> These patches sits on top of the clean up patches I've sent yesterday
>> to this mailing list[1].
>>
>> v2: fixes comments by Joonyoung
>> - remove unused var in patch 09
>> - use ->disable instead of outdated ->dpms in hdmi code
>> - remove WARN_ON from crtc enable/disable
>>
>> v3: fixes comment by Joonyoung
>>   - move the removal of drm_helper_disable_unused_functions() to
>>   separated patch
>
> With this patch series, Kernel booting is halted at end of kernel
> booting. I tested this patch series on Trats2 board based on Exynos4412 
> SoC.
>
> Below is a part of full booting logs, which was halted,
> [1.992015] exynos-drm-ipp exynos-drm-ipp: drm ipp registered
> successfully.
> [1.993009] exynos-drm exynos-drm: bound exynos-drm-vidi (ops
> vidi_component_ops)
> [1.993036] exynos-drm exynos-drm: bound 11c0.fimd (ops
> fimd_component_ops)
> [1.993385] exynos-drm exynos-drm: bound 11c8.dsi (ops
> exynos_dsi_component_ops)
> [1.993390] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [1.993393] [drm] No driver support for vblank timestamp query.
> [1.993442] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> [2.043358] WARNING: CPU: 2 PID: 1209 at drivers/clk/clk.c:898
> clk_unprepare+0x24/0x2c()
> [2.051412] Modules linked in:
> [2.054422] CPU: 2 PID: 1209 Comm: kworker/2:1 Tainted: GW
> 4.0.0-rc6-00526-gc49d7de-dirty #1278
> [2.064337] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [2.070428] Workqueue: pm pm_runtime_work>
>
> After that, I tested it again without FIMD and the booting is ok. So I
> guess that this atomic feature has a bug to FIMD driver.
>

 More information,

 The reason the booting is halted is that a deadlock occurs at fbcon
 module when register_framebuffer() is called.

 Below are our test results,
 - with only cleanup series, FIMD and HDMI work well.
 - with cleanup and atomic series, HDMI works well but FIMD doesn't
 work - a deadlock occurs.

 Could anyone test it with the atomic series on trats2 board? You can
 test it on top of exynos-drm-next-todo branch which contains all
 relevant patches,
 https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-todo

 Anyway, we will continue to take a look at the this issue why the
 deadlock occurs.
>>>
>>> In addition,
>>>
>>> I added some codes temporarily to fbmem module which mitigates the
>>> deadlock issue. After that, I see below panic log,
>>>
>>> [3.254840] Unable to handle kernel NULL pointer dereference at
>>> virtual address 00a4
>>> [3.262870] pgd = c0004000
>>> [3.265539] [00a4] *pgd=
>>> [3.269102] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>>> [3.274392] Modules linked in:
>>> [3.277435] CPU: 2 PID: 1 Comm: swapper/0 Tainted: GW
>>> 4.0.0-rc6-00526-gc49d7de-dirty #1308
>>> [3.286892] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> [3.292970] task: ee878000 ti: ee88 task.ti: ee88
>>> [3.298356] PC is at exynos_plane_atomic_update+0x24/0x1d4
>>> [3.303824] LR is at drm_atomic_helper_commit_planes+0xa4/0x18c
>>> [3.309723] pc : []lr : []psr: 6113
>>> [3.309723] sp : ee881b38  ip : 0020  fp : 
>>> [3.321179] r10: c04cfc00  r9 : 0008  r8 : eebfb9c0
>>> [3.326387] r7 : 0002  r6 :   r5 :   r4 : ee925308
>>> [3.332897] r3 : ee329fc0  r2 :   r1 :   r0 : ee925308
>>> [3.339409] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
>>> Segment kernel
>>> [3.346699] Control: 10c5387d  Table: 4000404a  DAC: 0015
>>> [3.352427] Process swapper/0 (pid: 1, stack limit = 0xee880210)
>>> [3.358416] Stack: (0xee881b38 to 0xee882000)
>>> [3.362757] 1b20:
>>>c0726794 0008
>>> [3.370919] 1b40: 0002 ee925308  ee329e00 0002
>>> eebfb9c0 0008 c04cfc00
>>> [3.379078] 1b60:  c0265308 0008  ee329e00
>>> ee0a8000 0008 
>>> [3.387237] 1b80:  c0267304 ee329e00 ee8efe00 ee914c00
>>> 0002  0002
>>> [3.395396] 1ba0:  c026609c c0265ef0  ee914c00
>>> 0028 ee8eff00 0001
>>> [

[PATCH libdrm 11/24] intel: remove the drm_mm* symbol workarounds

[Emil Velikov]

Humble ping.

Eric, can you please confirm if this and the follow up patch look ok.

Thanks
Emil

On 1 April 2015 at 17:15, Emil Velikov  wrote:
> Added with commit 57b4c4c32d3(Move the renaming of mm.c symbols to
> symbol duplication/collision with ones that are available elsewhere.
>
> As the public/private symbols of libdrm are properly annotated neither
> one of the symbols will end up in the global name-space, thus should no
> longer be required.
>
> Eric,
> Does this sound correct, or there is something more subtle in there ?
>
> Cc: Eric Anholt 
> Signed-off-by: Emil Velikov 
> ---
>  intel/mm.h | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/intel/mm.h b/intel/mm.h
> index 8a5235b..a6ee102 100644
> --- a/intel/mm.h
> +++ b/intel/mm.h
> @@ -38,16 +38,6 @@ struct mem_block {
> unsigned int reserved:1;
>  };
>
> -/* Rename the variables in the drm copy of this code so that it doesn't
> - * conflict with mesa or whoever else has copied it around.
> - */
> -#define mmInit drm_mmInit
> -#define mmAllocMem drm_mmAllocMem
> -#define mmFreeMem drm_mmFreeMem
> -#define mmFindBlock drm_mmFindBlock
> -#define mmDestroy drm_mmDestroy
> -#define mmDumpMemInfo drm_mmDumpMemInfo
> -
>  /**
>   * input: total size in bytes
>   * return: a heap pointer if OK, NULL if error
> --
> 2.3.1
>

[PATCH] drm/exynos: use drm_plane_force_disable

[Joonyoung Shim]

Don't call directly disable callback of plane helper, we need to
disconnect the plane from the fb and crtc after disable callback.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 5 +
 drivers/gpu/drm/exynos/exynos_drm_encoder.c | 2 +-
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 519c569..50c830e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -48,7 +48,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_plane *plane;
-   int ret;

if (!exynos_crtc->enabled)
return;
@@ -69,9 +68,7 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
if (plane->crtc != crtc)
continue;

-   ret = plane->funcs->disable_plane(plane);
-   if (ret)
-   DRM_ERROR("Failed to disable plane %d\n", ret);
+   drm_plane_force_disable(plane);
}
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 0648ba4..3ca266d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -90,7 +90,7 @@ static void exynos_drm_encoder_disable(struct drm_encoder 
*encoder)
/* all planes connected to this encoder should be also disabled. */
drm_for_each_legacy_plane(plane, >mode_config.plane_list) {
if (plane->crtc && (plane->crtc == encoder->crtc))
-   plane->funcs->disable_plane(plane);
+   drm_plane_force_disable(plane);
}
 }

-- 
1.9.1

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #15 from George Cheban  ---
My steps: 

#yum install git -y
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ git clone http://github.com/ignatenkobrain/kernel-package.git
$ cd linux
$ git bisect start
$ git bisect bad v3.19
$ git bisect good v3.12
$ git bisect bad (few times, until I get "1st bad commit")
$ git show HEAD 

= all logs in attachment 

What did I have to do?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

[Rob Clark]

On Thu, Apr 9, 2015 at 2:12 PM, Paul Bolle  wrote:
> On Thu, 2015-04-09 at 19:07 +0200, Greg KH wrote:
>> I really don't understand.  Why is this code in the kernel tree if it
>> can't be built?  How does anyone use this?  By taking it and copying it
>> where?  If it can't be built, and no one can update it, and of course
>> not run it, why is it here?  What good is this code doing sitting here?
>
> The Erlangen bot (courtesy of Valentin, Stefan, and Andreas) has taken
> over what I've been doing for quite some time, but doing it much more
> thoroughly. And my experience tells me that the reports they'll send in
> will trigger more discussions like this one.
>
> A lesson I learned from my daily checks for Kconfig oddities is that
> people go to great lengths defending unbuildable code. (Do a web search
> for ATHEROS_AR231X to find a discussion that dragged on for over three
> years!) Personally I stopped caring after someone insisted on having a
> file in the tree that was in no way connected to the build system: not a
> single line in any of the Makefiles pointed at it. So, as far as I'm
> concerned, if people can't point at a patch pending, somehow, somewhere,
> that would make their code buildable one might as well delete the code.
>
> I really think it's as simple as that.
>

In the example you reference, sure it is as simple as that.  But here
we are not talking about files that aren't even referenced by build
system.  We are talking about a driver which does build and run on
upstream kernel, and which has a few small #ifdef blocks to simplify
backporting to downstream kernels (which we still do need to use for
some generations and some devices)

Sure, I'd love never to have to deal with a downstream kernel.  But
really.. I didn't create the downstream mess in the arm/android
ecosystem, I'm just trying to cope with it as best as possible.. don't
hate the player, hate the game :-P

BR,
-R

>
> Paul Bolle
>

[Bug 89968] 10.5 garbled screen with Enlightenment E19.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89968

Bug ID: 89968
   Summary: 10.5 garbled screen with Enlightenment E19.
   Product: Mesa
   Version: 10.5
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: barz621 at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

As the title suggests. Happens on 10.5.1 and 10.5.2. If i revert back to 10.4.6
it works fine.

Barts 6850 r600g on arch linux. Won't be able to bisect this. And didn't find
anything interesting in the logs when it first occured.

-- 
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/20150409/ede52daa/attachment.html>

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #14 from Alex Deucher  ---
You need to take it to completion and test each commit before marking it bad or
good.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #13 from George Cheban  ---
Created attachment 173671
  --> https://bugzilla.kernel.org/attachment.cgi?id=173671=edit
"bisect bad" copy from terminal

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #12 from George Cheban  ---
Created attachment 173661
  --> https://bugzilla.kernel.org/attachment.cgi?id=173661=edit
bisect log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #11 from George Cheban  ---
Created attachment 173651
  --> https://bugzilla.kernel.org/attachment.cgi?id=173651=edit
Head = output of 1st bad commit

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2] drm/msm: Fix a couple of 64-bit build warnings

[Rob Clark]

On Thu, Apr 9, 2015 at 10:39 AM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> Avoid casts from pointers to fixed-size integers to prevent the compiler
> from warning. Print virtual memory addresses using %p instead. Also turn
> a couple of %d/%x specifiers into %zu/%zd/%zx to avoid further warnings
> due to mismatched format strings.
>
> Signed-off-by: Thierry Reding 

Thanks Thierry, I can include this when I send a -fixes pull.  Or if
you prefer I'm fine with this going in sooner via another tree..

Reviewed-by: Rob Clark 

> ---
> Changes in v2:
> - print physical addresses using %pa (fixes another warning that started
>   to appear in next-20150409)
>
>  drivers/gpu/drm/msm/edp/edp_aux.c |  4 ++--
>  drivers/gpu/drm/msm/msm_drv.c | 10 +-
>  drivers/gpu/drm/msm/msm_gem.c |  2 +-
>  drivers/gpu/drm/msm/msm_iommu.c   |  4 ++--
>  4 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/edp/edp_aux.c 
> b/drivers/gpu/drm/msm/edp/edp_aux.c
> index 5f5a84f6074c..208f9d47f82e 100644
> --- a/drivers/gpu/drm/msm/edp/edp_aux.c
> +++ b/drivers/gpu/drm/msm/edp/edp_aux.c
> @@ -132,7 +132,7 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, 
> struct drm_dp_aux_msg *msg)
> /* msg sanity check */
> if ((native && (msg->size > AUX_CMD_NATIVE_MAX)) ||
> (msg->size > AUX_CMD_I2C_MAX)) {
> -   pr_err("%s: invalid msg: size(%d), request(%x)\n",
> +   pr_err("%s: invalid msg: size(%zu), request(%x)\n",
> __func__, msg->size, msg->request);
> return -EINVAL;
> }
> @@ -155,7 +155,7 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, 
> struct drm_dp_aux_msg *msg)
>  */
> edp_write(aux->base + REG_EDP_AUX_TRANS_CTRL, 0);
> msm_edp_aux_ctrl(aux, 1);
> -   pr_err("%s: aux timeout, %d\n", __func__, ret);
> +   pr_err("%s: aux timeout, %zd\n", __func__, ret);
> goto unlock_exit;
> }
> DBG("completion");
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 47f4dd407671..cc5dc5299b8d 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -94,7 +94,7 @@ void __iomem *msm_ioremap(struct platform_device *pdev, 
> const char *name,
> }
>
> if (reglog)
> -   printk(KERN_DEBUG "IO:region %s %08x %08lx\n", dbgname, 
> (u32)ptr, size);
> +   printk(KERN_DEBUG "IO:region %s %p %08lx\n", dbgname, ptr, 
> size);
>
> return ptr;
>  }
> @@ -102,7 +102,7 @@ void __iomem *msm_ioremap(struct platform_device *pdev, 
> const char *name,
>  void msm_writel(u32 data, void __iomem *addr)
>  {
> if (reglog)
> -   printk(KERN_DEBUG "IO:W %08x %08x\n", (u32)addr, data);
> +   printk(KERN_DEBUG "IO:W %p %08x\n", addr, data);
> writel(data, addr);
>  }
>
> @@ -110,7 +110,7 @@ u32 msm_readl(const void __iomem *addr)
>  {
> u32 val = readl(addr);
> if (reglog)
> -   printk(KERN_ERR "IO:R %08x %08x\n", (u32)addr, val);
> +   printk(KERN_ERR "IO:R %p %08x\n", addr, val);
> return val;
>  }
>
> @@ -177,7 +177,7 @@ static int get_mdp_ver(struct platform_device *pdev)
> const struct of_device_id *match;
> match = of_match_node(match_types, dev->of_node);
> if (match)
> -   return (int)match->data;
> +   return (int)(unsigned long)match->data;
>  #endif
> return 4;
>  }
> @@ -216,7 +216,7 @@ static int msm_init_vram(struct drm_device *dev)
> if (ret)
> return ret;
> size = r.end - r.start;
> -   DRM_INFO("using VRAM carveout: %lx@%08x\n", size, r.start);
> +   DRM_INFO("using VRAM carveout: %lx@%pa\n", size, );
> } else
>  #endif
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 479d8af72bcb..52839769eb6c 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -483,7 +483,7 @@ void msm_gem_describe(struct drm_gem_object *obj, struct 
> seq_file *m)
> uint64_t off = drm_vma_node_start(>vma_node);
>
> WARN_ON(!mutex_is_locked(>struct_mutex));
> -   seq_printf(m, "%08x: %c(r=%u,w=%u) %2d (%2d) %08llx %p %d\n",
> +   seq_printf(m, "%08x: %c(r=%u,w=%u) %2d (%2d)

drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

[Rob Clark]

On Thu, Apr 9, 2015 at 1:07 PM, Greg KH  wrote:
> On Thu, Apr 09, 2015 at 10:50:58AM -0400, Rob Clark wrote:
>> On Thu, Apr 9, 2015 at 10:20 AM, Greg KH  
>> wrote:
>> > On Thu, Apr 09, 2015 at 09:49:58AM -0400, Rob Clark wrote:
>> >> On Thu, Apr 9, 2015 at 7:22 AM, Valentin Rothberg
>> >>  wrote:
>> >> > Hi Hai,
>> >> >
>> >> > your commit d5af49c92a8a ("drm/msm/mdp5: Enable DSI connector in msm drm
>> >> > driver") in today's Linux next tree adds an #ifdef with 
>> >> > CONFIG_MSM_BUS_SCALING
>> >> > as condition.  MSM_BUS_SCALING is not defined in Kconfig, so the code 
>> >> > in this
>> >> > #ifdef block won't be compiled at its current state.
>> >> >
>> >> > I saw some references on this Kconfig option in other files; is there a
>> >> > reason for the absence of MSM_BUS_SCALING?
>> >>
>> >> right now, it is something that only exists in downstream kernels (for
>> >> example, android device kernels).. but in those kernels it is
>> >> mandatory to use, as by default the memory/bus is downclocked and the
>> >> display would underflow if we did not request sufficient bandwidth.
>> >>
>> >> It only exists right now in the upstream kernel to simplify
>> >> backporting to various device kernels
>> >
>> > That's crazy.  You are asking upstream to maintain code in order to just
>> > make out of tree crap easier to maintain, which you don't have any plan
>> > to ever upstream?  That causes havoc on static analysis tools and
>> > prevents anyone from ever being able to even change the code for new api
>> > changes and test build it.
>>
>> Hey, don't blame me for the downstream kernels.  But at various points
>> in time I've had to backport drm/msm to various device kernels in
>> order to work on the userspace/mesa end of things.  (And, well, there
>> are other crazy folks out there who want to get open source graphics
>> drivers working on various phones/tablets.)  It was a choice to make
>> my life easier.  You know, because reverse engineering a gpu is a walk
>> in the park..
>
> I really don't understand.  Why is this code in the kernel tree if it
> can't be built?  How does anyone use this?  By taking it and copying it
> where?  If it can't be built, and no one can update it, and of course
> not run it, why is it here?  What good is this code doing sitting here?
>

For devices where I cannot run an upstream kernel yet, I backport
latest upstream drm (mostly 'cp -r' with as little changes as
possible, cherrypicking other dependencies outside of drm) to the
device kernel.  Basically that lets me develop against upstream drm in
parallel with the kernel-msm folks (hopefully) getting their pieces
upstream.

If I had to wait for all the clocks/regulators/gpio/etc drivers that I
depend on to land upstream, I'd pretty much only be able to start when
a given SoC was already a bit old (and add to that 6-12mos or so to
get mesa into mesa into good shape on a new gpu generation, by the
time the end user gets something usable the device would already be
obsolete)

Ideally we get to the point where I don't need to do this.. downstream
vendor kernels are generally a PITA.. but for the time being, it seems
like the most practical way for me to do things.

BR,
-R


> confused,
>
> greg k-h

[PATCH] drm: bridge: Allow daisy chaining of bridges

[Archit Taneja]

Hi,

On 04/09/2015 12:54 PM, Jani Nikula wrote:
> On Thu, 09 Apr 2015, Archit Taneja  wrote:
>> Allow drm_bridge objects to link to each other in order to form an encoder
>> chain. The requirement for creating a chain of bridges comes because the
>> MSM drm driver uses up its encoder and bridge objects for blocks within
>> the SoC itself. There isn't anything left to use if the SoC display output
>> is connected to an external encoder IC. Having an additional bridge
>> connected to the existing bridge helps here. In general, it is possible for
>> platforms to have  multiple devices between the encoder and the
>> connector/panel that require some sort of configuration.
>>
>> We create drm bridge helper functions corresponding to each op in
>> 'drm_bridge_funcs'. These helpers call the corresponding 'drm_bridge_funcs'
>> op for the entire chain of bridges. These helpers are used internally by
>> drm_atomic_helper.c and drm_crtc_helper.c.
>>
>> The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of the
>> bridge closet to the encoder, and proceed until the last bridge in the chain
>> is enabled. The same holds for drm_bridge_mode_set/mode_fixup helpers. The
>> drm_bridge_disable/post_disable helpers disable the last bridge in the chain
>> first, and proceed until the first bridge in the chain is disabled.
>>
>> drm_bridge_attach() remains the same. As before, the driver calling this
>> function should make sure it has set the links correctly. The order in which
>> the bridges are connected to each other determines the order in which the
>> calls are made. One requirement is that every bridge in the chain should 
>> point
>> the parent encoder object. This is required since bridge drivers expect a
>> valid encoder pointer in drm_bridge. For example, consider a chain where an
>> encoder's output is connected to bridge1, and bridge1's output is connected 
>> to
>> bridge2:
>>
>>  /* Like before, attach bridge to an encoder */
>>  bridge1->encoder = encoder;
>>  ret = drm_bridge_attach(dev, bridge1);
>>  ..
>>
>>  /*
>>   * set the first bridge's 'next' bridge to bridge2, set its encoder
>>   * as bridge1's encoder
>>   */
>>  bridge1->next = bridge2
>>  bridge2->encoder = bridge1->encoder;
>>  ret = drm_bridge_attach(dev, bridge2);
>>
>>  ...
>>  ...
>>
>> This method of bridge chaining isn't intrusive and existing drivers that use
>> drm_bridge will behave the same way as before. The bridge helpers also cleans
>> up the atomic and crtc helper files a bit.
>>
>> Signed-off-by: Archit Taneja 
>> ---
>>   drivers/gpu/drm/drm_atomic_helper.c | 29 ++--
>>   drivers/gpu/drm/drm_bridge.c| 68 
>> +
>>   drivers/gpu/drm/drm_crtc_helper.c   | 54 +++--
>>   include/drm/drm_crtc.h  | 14 
>>   4 files changed, 112 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 7e3a52b..0b4574e 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -287,14 +287,11 @@ mode_fixup(struct drm_atomic_state *state)
>>  encoder = conn_state->best_encoder;
>>  funcs = encoder->helper_private;
>>
>> -if (encoder->bridge && encoder->bridge->funcs->mode_fixup) {
>> -ret = encoder->bridge->funcs->mode_fixup(
>> -encoder->bridge, _state->mode,
>> -_state->adjusted_mode);
>> -if (!ret) {
>> -DRM_DEBUG_KMS("Bridge fixup failed\n");
>> -return -EINVAL;
>> -}
>> +ret = drm_bridge_mode_fixup(encoder->bridge, _state->mode,
>> +_state->adjusted_mode);
>> +if (!ret) {
>> +DRM_DEBUG_KMS("Bridge fixup failed\n");
>> +return -EINVAL;
>>  }
>>
>>  if (funcs->atomic_check) {
>> @@ -607,8 +604,7 @@ disable_outputs(struct drm_device *dev, struct 
>> drm_atomic_state *old_state)
>>   * Each encoder has at most one connector (since we always steal
>>   * it away), so we won't call call disable hooks twice.
>>   */
>> -if (encoder->bridge)
>> -encoder->bridge->funcs->disable(encoder->bridge);
>> +drm_bridge_disable(encoder->bridge);
>>
>>  /* Right function depends upon target state. */
>>  if (connector->state->crtc && funcs->prepare)
>> @@ -618,8 +614,7 @@ disable_outputs(struct drm_device *dev, struct 
>> drm_atomic_state *old_state)
>>  else
>>  funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
>>
>> -if (encoder->bridge)
>> -

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #10 from Alex Deucher  ---
Git is a source management tool that provides a relatively easy method to track
down regressions.  See some example howtos:
http://git-scm.com/docs/git-bisect
https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 88364] Xorg hangs after videocard switching

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=88364

--- Comment #9 from Alex Deucher  ---
Can you attach a full dmesg output (i.e., I want to see the bootup output, not
the hang stuff)?  Also does booting with either radeon.runpm=0 or radoen.dpm=0
on the kernel command line in grub help?

-- 
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/20150409/bc7ef118/attachment.html>

drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

[Valentin Rothberg]

Hi Hai,

your commit d5af49c92a8a ("drm/msm/mdp5: Enable DSI connector in msm drm
driver") in today's Linux next tree adds an #ifdef with CONFIG_MSM_BUS_SCALING
as condition.  MSM_BUS_SCALING is not defined in Kconfig, so the code in this
#ifdef block won't be compiled at its current state.

I saw some references on this Kconfig option in other files; is there a
reason for the absence of MSM_BUS_SCALING?

I found this issue with ./scripts/checkkconfigsymbols.py by diffing yesterday's
and today's next tree.

Kind regards,
 Valentin

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #9 from George Cheban  ---
(In reply to Alex Deucher from comment #5)
> Please just attach these logs to the bug directly rather than pasting inline
> or providing links to 3rd party sites that may go away.  Any chance you
> could bisect to see what change caused the regression?

Sorry, it's the first time I'm posting bug report here. All outputs are in
attachment. 

Don't think, I understood correctly you phrase 
>Any chance you could bisect to see what change caused the regression?

Can you explain what else I need to do?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #8 from George Cheban  ---
Created attachment 173641
  --> https://bugzilla.kernel.org/attachment.cgi?id=173641=edit
Xorg with kernel 3.19

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #7 from George Cheban  ---
Created attachment 173631
  --> https://bugzilla.kernel.org/attachment.cgi?id=173631=edit
journalctl output

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #6 from George Cheban  ---
Created attachment 173621
  --> https://bugzilla.kernel.org/attachment.cgi?id=173621=edit
dmesg output

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #5 from Alex Deucher  ---
Please just attach these logs to the bug directly rather than pasting inline or
providing links to 3rd party sites that may go away.  Any chance you could
bisect to see what change caused the regression?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 96361] [Bisected, radeon]Non-infinite boot loop since v3.13

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96361

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Please attach your dmesg output with radeon.dpm=1 on the kernel command line in
grub.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Mesa-dev] st_TexSubImage: unaligned memcpy performance

[Vasilis Liaskovitis]

type=, type at entry=5121, pixels=,
pixels at entry=0x0, packing=, packing at entry=0x77f69180) 
at
../../../../src/mesa/main/texstore.c:4171
#7  0x72c3acaa in st_TexSubImage (ctx=0x77f4d010,
dims=, texImage=0x7c8690, xoffset=0, yoffset=0, zoffset=0,
width=1024, height=1024, depth=1, format=32993, type=5121,
pixels=0x0, unpack=0x77f69180) at
../../../../src/mesa/state_tracker/st_cb_texture.c:787
#8  0x72bce83d in texsubimage (ctx=0x77f4d010, dims=dims at entry=2,
target=3553, level=0, xoffset=0, yoffset=0, zoffset=zoffset at entry=0,
width=1024, height=1024, depth=depth at entry=1,
format=format at entry=32993, type=type at entry=5121, pixels=pixels at 
entry=0x0)
at ../../../../src/mesa/main/teximage.c:3445
#9  0x72bd259c in _mesa_TexSubImage2D (target=,
level=, xoffset=, yoffset=,
width=, height=,
format=32993, type=5121, pixels=0x0) at
../../../../src/mesa/main/teximage.c:3483


pixels pointer in st_texSubImage is 0x0 here, maybe because it's an
internal pbo to texture transfer?
srcAddr in memcpy_texture() is 0x7fffeeecd000 which looks sufficiently
aligned, but maybe this is not the correct pointer to look at.

could there also be a CPU stall/sync issue when mapping a pbo buffer?

Similar pbounpack/memcpy performance discussed a bit here recently with no
conclusion:
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel=2015-01-01

thanks,

- Vasilis




>
> Cheers,
> Daniel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150409/876e926a/attachment.html>

[Bug 89965] CAYMAN DRI_PRIME The Cave error: radeon: The kernel rejected CS

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89965

Bug ID: 89965
   Summary: CAYMAN DRI_PRIME The Cave error: radeon: The kernel
rejected CS
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: frederic.romagne at gmail.com

Created attachment 114980
  --> https://bugs.freedesktop.org/attachment.cgi?id=114980=edit
dmesg after the error

When running The Cave through steam, using DRI_PRIME=1 steam
The games freezes and corrupts the steam window. While I close the game, I
cannot run anything with DRI_PRIME anymore, a message is spammed in the
terminal:

radeon: The kernel rejected CS, see dmesg for more information.

I have a fresh git xf86-video-ati xf86-video-intel mesa and libdrm on
kernel-3.19.3

Radeon 9650 and intel ivybridge 2500

-- 
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/20150409/ad5a7d0e/attachment.html>

[PATCH] drm: bridge: Allow daisy chaining of bridges

[Archit Taneja]

Allow drm_bridge objects to link to each other in order to form an encoder
chain. The requirement for creating a chain of bridges comes because the
MSM drm driver uses up its encoder and bridge objects for blocks within
the SoC itself. There isn't anything left to use if the SoC display output
is connected to an external encoder IC. Having an additional bridge
connected to the existing bridge helps here. In general, it is possible for
platforms to have  multiple devices between the encoder and the
connector/panel that require some sort of configuration.

We create drm bridge helper functions corresponding to each op in
'drm_bridge_funcs'. These helpers call the corresponding 'drm_bridge_funcs'
op for the entire chain of bridges. These helpers are used internally by
drm_atomic_helper.c and drm_crtc_helper.c.

The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of the
bridge closet to the encoder, and proceed until the last bridge in the chain
is enabled. The same holds for drm_bridge_mode_set/mode_fixup helpers. The
drm_bridge_disable/post_disable helpers disable the last bridge in the chain
first, and proceed until the first bridge in the chain is disabled.

drm_bridge_attach() remains the same. As before, the driver calling this
function should make sure it has set the links correctly. The order in which
the bridges are connected to each other determines the order in which the
calls are made. One requirement is that every bridge in the chain should point
the parent encoder object. This is required since bridge drivers expect a
valid encoder pointer in drm_bridge. For example, consider a chain where an
encoder's output is connected to bridge1, and bridge1's output is connected to
bridge2:

/* Like before, attach bridge to an encoder */
bridge1->encoder = encoder;
ret = drm_bridge_attach(dev, bridge1);
..

/*
 * set the first bridge's 'next' bridge to bridge2, set its encoder
 * as bridge1's encoder
 */
bridge1->next = bridge2
bridge2->encoder = bridge1->encoder;
ret = drm_bridge_attach(dev, bridge2);

...
...

This method of bridge chaining isn't intrusive and existing drivers that use
drm_bridge will behave the same way as before. The bridge helpers also cleans
up the atomic and crtc helper files a bit.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/drm_atomic_helper.c | 29 ++--
 drivers/gpu/drm/drm_bridge.c| 68 +
 drivers/gpu/drm/drm_crtc_helper.c   | 54 +++--
 include/drm/drm_crtc.h  | 14 
 4 files changed, 112 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 7e3a52b..0b4574e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -287,14 +287,11 @@ mode_fixup(struct drm_atomic_state *state)
encoder = conn_state->best_encoder;
funcs = encoder->helper_private;

-   if (encoder->bridge && encoder->bridge->funcs->mode_fixup) {
-   ret = encoder->bridge->funcs->mode_fixup(
-   encoder->bridge, _state->mode,
-   _state->adjusted_mode);
-   if (!ret) {
-   DRM_DEBUG_KMS("Bridge fixup failed\n");
-   return -EINVAL;
-   }
+   ret = drm_bridge_mode_fixup(encoder->bridge, _state->mode,
+   _state->adjusted_mode);
+   if (!ret) {
+   DRM_DEBUG_KMS("Bridge fixup failed\n");
+   return -EINVAL;
}

if (funcs->atomic_check) {
@@ -607,8 +604,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
 * Each encoder has at most one connector (since we always steal
 * it away), so we won't call call disable hooks twice.
 */
-   if (encoder->bridge)
-   encoder->bridge->funcs->disable(encoder->bridge);
+   drm_bridge_disable(encoder->bridge);

/* Right function depends upon target state. */
if (connector->state->crtc && funcs->prepare)
@@ -618,8 +614,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
else
funcs->dpms(encoder, DRM_MODE_DPMS_OFF);

-   if (encoder->bridge)
-   encoder->bridge->funcs->post_disable(encoder->bridge);
+   drm_bridge_post_disable(encoder->bridge);
}

for (i = 0; i < ncrtcs; i++) {
@@ -761,9 +756,7 @@ crtc_set_mode(struct drm_device *dev, struct 
drm_atomic_state *old_state)
 */
funcs->mode_set(encoder, 

drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

[Rob Clark]

On Thu, Apr 9, 2015 at 10:20 AM, Greg KH  wrote:
> On Thu, Apr 09, 2015 at 09:49:58AM -0400, Rob Clark wrote:
>> On Thu, Apr 9, 2015 at 7:22 AM, Valentin Rothberg
>>  wrote:
>> > Hi Hai,
>> >
>> > your commit d5af49c92a8a ("drm/msm/mdp5: Enable DSI connector in msm drm
>> > driver") in today's Linux next tree adds an #ifdef with 
>> > CONFIG_MSM_BUS_SCALING
>> > as condition.  MSM_BUS_SCALING is not defined in Kconfig, so the code in 
>> > this
>> > #ifdef block won't be compiled at its current state.
>> >
>> > I saw some references on this Kconfig option in other files; is there a
>> > reason for the absence of MSM_BUS_SCALING?
>>
>> right now, it is something that only exists in downstream kernels (for
>> example, android device kernels).. but in those kernels it is
>> mandatory to use, as by default the memory/bus is downclocked and the
>> display would underflow if we did not request sufficient bandwidth.
>>
>> It only exists right now in the upstream kernel to simplify
>> backporting to various device kernels
>
> That's crazy.  You are asking upstream to maintain code in order to just
> make out of tree crap easier to maintain, which you don't have any plan
> to ever upstream?  That causes havoc on static analysis tools and
> prevents anyone from ever being able to even change the code for new api
> changes and test build it.

Hey, don't blame me for the downstream kernels.  But at various points
in time I've had to backport drm/msm to various device kernels in
order to work on the userspace/mesa end of things.  (And, well, there
are other crazy folks out there who want to get open source graphics
drivers working on various phones/tablets.)  It was a choice to make
my life easier.  You know, because reverse engineering a gpu is a walk
in the park..

BR,
-R


> If this was in a subsystem that I maintain, I'd delete it tomorrow.  But
> in the end, it's up to David to decide if he wants to waste the cycles
> or not.
>
> Ick ick ick.
>
> greg k-h

[PATCH] drm/tegra: Remove unused .mode_set and .mode_set_base CRTC helpers

[Thierry Reding]

On Fri, Apr 03, 2015 at 04:53:41PM +0300, Laurent Pinchart wrote:
> Hi Thierry,
> 
> Ping ?

I thought I had already replied to the original post, but apparently I
didn't. I had been carrying that same patch for a while already but had
not sent it to Dave because it didn't seem material for after -rc1. The
patch has gone in for v4.1-rc1 now.

Thanks,
Thierry

> On Friday 20 February 2015 13:43:56 Laurent Pinchart wrote:
> > The two CRTC helper operations are called only for non-atomic mode
> > setting, by either the drm_crtc_helper_set_config() helper or the
> > drm_helper_resume_force_mode() helper. As the driver has switched to
> > atomic mode setting and neither of those helpers is used, the operations
> > are not used anymore. Remove them.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at 
> > ideasonboard.com>
> > ---
> >  drivers/gpu/drm/tegra/dc.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > Hi Thierry,
> > 
> > I stumbled on this while trying to understand the atomic mode setting code
> > paths. Could you please test the patch ?
> > 
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > index 3aaa84ae2681..4476d6a35a0f 100644
> > --- a/drivers/gpu/drm/tegra/dc.c
> > +++ b/drivers/gpu/drm/tegra/dc.c
> > @@ -1327,9 +1327,7 @@ static void tegra_crtc_atomic_flush(struct drm_crtc
> > *crtc) static const struct drm_crtc_helper_funcs tegra_crtc_helper_funcs =
> > { .disable = tegra_crtc_disable,
> > .mode_fixup = tegra_crtc_mode_fixup,
> > -   .mode_set = drm_helper_crtc_mode_set,
> > .mode_set_nofb = tegra_crtc_mode_set_nofb,
> > -   .mode_set_base = drm_helper_crtc_mode_set_base,
> > .prepare = tegra_crtc_prepare,
> > .commit = tegra_crtc_commit,
> > .atomic_check = tegra_crtc_atomic_check,
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
------ 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/20150409/2ee08b52/attachment.sig>

[PATCH] drm/exynos/fimc: fix runtime pm support

[Marek Szyprowski]

Once pm_runtime_set_active() gets called, the kernel assumes that given
device has already enabled runtime pm and will call pm_runtime_suspend()
without matching pm_runtime_resume(). In case of DRM FIMC IPP driver,
this will result in calling clk_disable() without respective call to
clk_enable(). This patch removes call to pm_runtime_set_active() to
ensure that pm_runtime_suspend/resume calls will match.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 842d6b8dc3c4..2a652359af64 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1745,7 +1745,6 @@ static int fimc_probe(struct platform_device *pdev)
spin_lock_init(>lock);
platform_set_drvdata(pdev, ctx);

-   pm_runtime_set_active(dev);
pm_runtime_enable(dev);

ret = exynos_drm_ippdrv_register(ippdrv);
-- 
1.9.2

[PATCH RFC v9 11/20] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver

[Thierry Reding]

On Thu, Feb 12, 2015 at 02:01:34PM +0800, Liu Ying wrote:
[...]
> diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c 
> b/drivers/gpu/drm/bridge/dw_mipi_dsi.c
[...]
> +struct dw_mipi_dsi {
> + struct mipi_dsi_host dsi_host;
> + struct drm_connector connector;
> + struct drm_encoder *encoder;
> + struct drm_bridge *bridge;
> + struct drm_panel *panel;
> + struct device *dev;
> +
> + void __iomem *base;
> +
> + struct clk *pllref_clk;
> + struct clk *cfg_clk;
> + struct clk *pclk;
> +
> + unsigned int lane_mbps; /* per lane */
> + u32 channel;
> + u32 lanes;
> + u32 format;
> + struct drm_display_mode *mode;
> +
> + const struct dw_mipi_dsi_plat_data *pdata;
> +
> + bool enabled;
> +};

While reviewing this I kept thinking whether this is really the right
architectural design. This driver is a MIPI DSI host, a connector and
a bridge, all in one. But it seems to me like it should really be an
encoder/connector and a MIPI DSI host. Why the need for a bridge? The
bridge abstraction targets blocks outside of the SoC, but it is my
understanding that these DesignWare IP blocks are designed into SoCs.

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/20150409/26414472/attachment-0001.sig>

[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=88152

--- Comment #36 from Arthur Marsh  ---
With the first post- 4.0.0-rc7 drm update, I am no longer seeing the error, but
have been unable to git-bisect to find the commit that fixed the problem.

-- 
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/20150409/a28305d0/attachment.html>

[PATCH] drm: bridge: Allow daisy chaining of bridges

[Jani Nikula]

On Thu, 09 Apr 2015, Archit Taneja  wrote:
> Allow drm_bridge objects to link to each other in order to form an encoder
> chain. The requirement for creating a chain of bridges comes because the
> MSM drm driver uses up its encoder and bridge objects for blocks within
> the SoC itself. There isn't anything left to use if the SoC display output
> is connected to an external encoder IC. Having an additional bridge
> connected to the existing bridge helps here. In general, it is possible for
> platforms to have  multiple devices between the encoder and the
> connector/panel that require some sort of configuration.
>
> We create drm bridge helper functions corresponding to each op in
> 'drm_bridge_funcs'. These helpers call the corresponding 'drm_bridge_funcs'
> op for the entire chain of bridges. These helpers are used internally by
> drm_atomic_helper.c and drm_crtc_helper.c.
>
> The drm_bridge_enable/pre_enable helpers execute enable/pre_enable ops of the
> bridge closet to the encoder, and proceed until the last bridge in the chain
> is enabled. The same holds for drm_bridge_mode_set/mode_fixup helpers. The
> drm_bridge_disable/post_disable helpers disable the last bridge in the chain
> first, and proceed until the first bridge in the chain is disabled.
>
> drm_bridge_attach() remains the same. As before, the driver calling this
> function should make sure it has set the links correctly. The order in which
> the bridges are connected to each other determines the order in which the
> calls are made. One requirement is that every bridge in the chain should point
> the parent encoder object. This is required since bridge drivers expect a
> valid encoder pointer in drm_bridge. For example, consider a chain where an
> encoder's output is connected to bridge1, and bridge1's output is connected to
> bridge2:
>
>   /* Like before, attach bridge to an encoder */
>   bridge1->encoder = encoder;
>   ret = drm_bridge_attach(dev, bridge1);
>   ..
>
>   /*
>* set the first bridge's 'next' bridge to bridge2, set its encoder
>* as bridge1's encoder
>*/
>   bridge1->next = bridge2
>   bridge2->encoder = bridge1->encoder;
>   ret = drm_bridge_attach(dev, bridge2);
>
>   ...
>   ...
>
> This method of bridge chaining isn't intrusive and existing drivers that use
> drm_bridge will behave the same way as before. The bridge helpers also cleans
> up the atomic and crtc helper files a bit.
>
> Signed-off-by: Archit Taneja 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 29 ++--
>  drivers/gpu/drm/drm_bridge.c| 68 
> +
>  drivers/gpu/drm/drm_crtc_helper.c   | 54 +++--
>  include/drm/drm_crtc.h  | 14 
>  4 files changed, 112 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 7e3a52b..0b4574e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -287,14 +287,11 @@ mode_fixup(struct drm_atomic_state *state)
>   encoder = conn_state->best_encoder;
>   funcs = encoder->helper_private;
>  
> - if (encoder->bridge && encoder->bridge->funcs->mode_fixup) {
> - ret = encoder->bridge->funcs->mode_fixup(
> - encoder->bridge, _state->mode,
> - _state->adjusted_mode);
> - if (!ret) {
> - DRM_DEBUG_KMS("Bridge fixup failed\n");
> - return -EINVAL;
> - }
> + ret = drm_bridge_mode_fixup(encoder->bridge, _state->mode,
> + _state->adjusted_mode);
> + if (!ret) {
> + DRM_DEBUG_KMS("Bridge fixup failed\n");
> + return -EINVAL;
>   }
>  
>   if (funcs->atomic_check) {
> @@ -607,8 +604,7 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>* Each encoder has at most one connector (since we always steal
>* it away), so we won't call call disable hooks twice.
>*/
> - if (encoder->bridge)
> - encoder->bridge->funcs->disable(encoder->bridge);
> + drm_bridge_disable(encoder->bridge);
>  
>   /* Right function depends upon target state. */
>   if (connector->state->crtc && funcs->prepare)
> @@ -618,8 +614,7 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>   else
>   funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
>  
> - if (encoder->bridge)
> - encoder->bridge->funcs->post_disable(encoder->bridge);
> + drm_bridge_post_disable(encoder->bridge);
>   }
>  
>   for (i = 0; i < ncrtcs; i++) 

[PATCH RFC v9 15/20] drm: panel: Add support for Himax HX8369A MIPI DSI panel

[Thierry Reding]

n -ENOMEM;
> +
> + ctx->dev = dev;
> +
> + if (of_id) {
> + ctx->pd = of_id->data;
> + } else {
> + dev_err(dev, "cannot find compatible device\n");
> + return -ENODEV;
> + }

You should move this check up, before the allocation so that you can
avoid it if not needed. Then again, I don't see a case where of_id would
actually be NULL, so you might as well just skip the check. If somebody
really added an entry with NULL data, they'll realize their mistake soon
enough.

> + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(ctx->reset_gpio)) {
> + dev_info(dev, "cannot get reset-gpios %ld\n",
> +  PTR_ERR(ctx->reset_gpio));

This should be dev_err(). Also the message is confusing because it could
produce something like:

"cannot get reset-gpios -517"

and it isn't immediately obvious if -517 is a bogus GPIO number or an
error code. A better error message would be, in my opinion:

"cannot get reset GPIO: %ld\n"

> + for (i = 0; i < 4; i++) {
> + ctx->bs_gpio[i] = devm_gpiod_get_index_optional(dev, "bs", i,
> + GPIOD_OUT_HIGH);
> + if (!IS_ERR_OR_NULL(ctx->bs_gpio[i])) {
> + dev_dbg(dev, "bs%d-gpio is configured\n", i);
> + } else if (IS_ERR(ctx->bs_gpio[i])) {
> + dev_info(dev, "failed to get bs%d-gpio\n", i);

Should be dev_err() here, too. Also the names are somewhat confusing
because they refer to a non-existing DT property. Perhaps it'd be better
to name them after what the datasheet has. If the datasheet names them
BS[0..3] for example, maybe make the error message:

dev_err(dev, "failed to get BS[%u] GPIO: %ld\n", i,
PTR_ERR(ctx->bs_gpio[i]));

> + return PTR_ERR(ctx->bs_gpio[i]);
> + }
> + }

You don't seem to be using these GPIOs either. I understand that you're
only supporting a single mode, but maybe it'd be better to check that
the chip is properly connected by matching the BS to the MIPI DSI video
mode enum value.

> + ret = hx8369a_power_on(ctx);
> + if (ret < 0) {
> + dev_err(dev, "cannot power on\n");
> + return ret;
> + }

Why power on here? Can't you postpone that until the panel is actually
used (for example in ->prepare())?

> +static struct mipi_dsi_driver hx8369a_dsi_driver = {
> + .probe = hx8369a_dsi_probe,
> + .remove = hx8369a_dsi_remove,
> + .driver = {
> + .name = "panel-hx8369a-dsi",

Are there variants of hx8369a that don't use DSI as their control
interface? If not, I'd simply omit the -dsi suffix.

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/20150409/1e4cd885/attachment.sig>

drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING

[Rob Clark]

On Thu, Apr 9, 2015 at 7:22 AM, Valentin Rothberg
 wrote:
> Hi Hai,
>
> your commit d5af49c92a8a ("drm/msm/mdp5: Enable DSI connector in msm drm
> driver") in today's Linux next tree adds an #ifdef with CONFIG_MSM_BUS_SCALING
> as condition.  MSM_BUS_SCALING is not defined in Kconfig, so the code in this
> #ifdef block won't be compiled at its current state.
>
> I saw some references on this Kconfig option in other files; is there a
> reason for the absence of MSM_BUS_SCALING?

right now, it is something that only exists in downstream kernels (for
example, android device kernels).. but in those kernels it is
mandatory to use, as by default the memory/bus is downclocked and the
display would underflow if we did not request sufficient bandwidth.

It only exists right now in the upstream kernel to simplify
backporting to various device kernels

BR,
-R

> I found this issue with ./scripts/checkkconfigsymbols.py by diffing 
> yesterday's
> and today's next tree.
>
> Kind regards,
>  Valentin

[PATCH RFC v9 14/20] Documentation: dt-bindings: Add bindings for Himax HX8369A DRM panel driver

[Thierry Reding]

On Thu, Feb 12, 2015 at 02:01:37PM +0800, Liu Ying wrote:
> This patch adds device tree bindings for Himax HX8369A DRM panel driver.
> 
> Signed-off-by: Liu Ying 
> ---
> v8->v9:
>  * Rebase onto the imx-drm/next branch of Philipp Zabel's open git repository.
> 
> v7->v8:
>  * None.
> 
> v6->v7:
>  * None.
> 
> v5->v6:
>  * None.
> 
> v4->v5:
>  * Merge the bs[3:0]-gpios properties into one property - bs-gpios.
>This addresses Andrzej Hajda's comment.
> 
> v3->v4:
>  * Newly introduced in v4.  This is separated from the relevant driver patch
>in v3 to address Stefan Wahren's comment.
> 
>  .../devicetree/bindings/panel/himax,hx8369a.txt| 39 
> ++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/panel/himax,hx8369a.txt
> 
> diff --git a/Documentation/devicetree/bindings/panel/himax,hx8369a.txt 
> b/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
> new file mode 100644
> index 000..3a44b70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
> @@ -0,0 +1,39 @@
> +Himax HX8369A WVGA 16.7M color TFT single chip driver with internal GRAM
> +
> +Himax HX8369A is a WVGA resolution driving controller.
> +It is designed to provide a single chip solution that combines a source
> +driver and power supply circuits to drive a TFT dot matrix LCD with
> +480RGBx864 dots at the maximum.
> +
> +The HX8369A supports several interface modes, including MPU MIPI DBI Type
> +A/B mode, MIPI DPI/DBI Type C mode, MIPI DSI video mode, MIPI DSI command
> +mode and MDDI mode. The interface mode is selected by the external hardware
> +pins BS[3:0].
> +
> +Currently, only the MIPI DSI video mode is supported.

This doesn't make much sense. The binding is supposed to describe the
hardware, so saying "only video mode is supported" is weird. Perhaps if
you have no way to test other modes you could reword as:

This version of the device tree binding only specifies MIPI DSI
video mode.

Then again, would the device tree content be different based on the
video mode?

> +Required properties:
> +  - compatible: should be a panel's compatible string

I don't understand this. If this chip isn't a panel, why should the
compatible string contain the panel's compatible string? Is this some
kind of bridge chip that can drive different panels? I guess I'll see
when I look at the driver.

Anyway, if it isn't a panel it shouldn't have the panel's compatible
string.

> +  - reg: the virtual channel number of a DSI peripheral, as described in [1]
> +  - reset-gpios: a GPIO spec for the reset pin, as described in [2]
> +
> +Optional properties:
> +  - vdd1-supply: I/O and interface power supply
> +  - vdd2-supply: analog power supply
> +  - vdd3-supply: logic power supply
> +  - dsi-vcc-supply: DSI and MDDI power supply
> +  - vpp-supply: OTP programming voltage
> +  - bs-gpios: a GPIO spec for the pins BS[3:0], as described in [2]
> +
> +[1] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
> +[2] Documentation/devicetree/bindings/gpio/gpio.txt
> +
> +Example:
> + panel {
> + compatible = "truly,tft480800-16-e-dsi";
> + reg = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_mipi_panel>;
> + reset-gpios = < 11 GPIO_ACTIVE_LOW>;
> + bs-gpios = <0>, <0>, < 14 GPIO_ACTIVE_HIGH>, <0>;
> + };

Again this doesn't make sense. You're mixing two things here: the HIMAX
chip that is presumably a bridge and the panel connected to 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/20150409/f0033d97/attachment.sig>

[PATCH RFC v9 09/20] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format

[Thierry Reding]

On Thu, Feb 12, 2015 at 02:01:32PM +0800, Liu Ying wrote:
> Signed-off-by: Liu Ying 
> ---
> v8->v9:
>  * Rebase onto the imx-drm/next branch of Philipp Zabel's open git repository.
> 
> v7->v8:
>  * None.
> 
> v6->v7:
>  * None.
> 
> v5->v6:
>  * Address the over 80 characters in one line warning reported by the
>checkpatch.pl script.
> 
> v4->v5:
>  * None.
> 
> v3->v4:
>  * None.
> 
> v2->v3:
>  * None.
> 
> v1->v2:
>  * Thierry Reding suggested that the mipi_dsi_pixel_format_to_bpp() function
>could be placed at the common DRM MIPI DSI driver.
>This patch is newly added.
> 
>  include/drm/drm_mipi_dsi.h | 14 ++
>  1 file changed, 14 insertions(+)

Acked-by: Thierry Reding 
-- 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/20150409/547f26a9/attachment-0001.sig>

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #4 from George Cheban  ---
This is journalctl -k -b -1
http://rghost.ru/6Hry6jGDX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #3 from George Cheban  ---
I did it :)
Uploaded dmesg with 3.19 kernel because it's to long. 
http://rghost.ru/6YHmyhLtF

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 96351] System hangs up after update to any kernel newer than 3.12*

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=96351

--- Comment #2 from George Cheban  ---
As I understand, I need to show you all output of $dmesg, or only dmesg | grep
VGA?

Do I need to log in with 3.19 kernel for dmesg output? If so, I don't have
enough time to do this, because, when I start terminal, system hangs up
immediately. 


This is Xorg log:

[27.072] 
X.Org X Server 1.14.4
Release Date: 2013-10-31
[27.073] X Protocol Version 11, Revision 0
[27.073] Build Operating System:  2.6.32-358.14.1.el6.x86_64 
[27.073] Current Operating System: Linux localhost.localdomain
3.19.3-100.fc20.i686 #1 SMP Fri Mar 27 17:30:08 UTC 2015 i686
[27.073] Kernel command line: BOOT_IMAGE=/vmlinuz-3.19.3-100.fc20.i686
root=/dev/mapper/rfremix-root ro rd.lvm.lv=rfremix/root
vconsole.font=latarcyrheb-sun16 rd.lvm.lv=rfremix/swap rhgb quiet
[27.073] Build Date: 21 November 2013  05:41:17AM
[27.073] Build ID: xorg-x11-server 1.14.4-5.fc20 
[27.073] Current version of pixman: 0.30.0
[27.073] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[27.073] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[27.073] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Apr  9 10:23:16
2015
[27.255] (==) Using config directory: "/etc/X11/xorg.conf.d"
[27.255] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[27.258] (==) No Layout section.  Using the first Screen section.
[27.258] (==) No screen section available. Using defaults.
[27.258] (**) |-->Screen "Default Screen Section" (0)
[27.258] (**) |   |-->Monitor ""
[27.258] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[27.258] (==) Automatically adding devices
[27.258] (==) Automatically enabling devices
[27.258] (==) Automatically adding GPU devices
[27.258] (==) FontPath set to:
catalogue:/etc/X11/fontpath.d,
built-ins
[27.258] (==) ModulePath set to "/usr/lib/xorg/modules"
[27.258] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[27.258] (II) Loader magic: 0x826b6a0
[27.258] (II) Module ABI versions:
[27.258] X.Org ANSI C Emulation: 0.4
[27.258] X.Org Video Driver: 14.1
[27.258] X.Org XInput driver : 19.2
[27.258] X.Org Server Extension : 7.0
[27.259] (II) xfree86: Adding drm device (/dev/dri/card0)
[27.262] (--) PCI:*(0:1:0:0) 1002:9480:1025:027e rev 0, Mem @
0xc000/268435456, 0xd020/65536, I/O @ 0x2000/256, BIOS @
0x/131072
[27.262] Initializing built-in extension Generic Event Extension
[27.262] Initializing built-in extension SHAPE
[27.262] Initializing built-in extension MIT-SHM
[27.262] Initializing built-in extension XInputExtension
[27.262] Initializing built-in extension XTEST
[27.262] Initializing built-in extension BIG-REQUESTS
[27.262] Initializing built-in extension SYNC
[27.262] Initializing built-in extension XKEYBOARD
[27.262] Initializing built-in extension XC-MISC
[27.262] Initializing built-in extension XINERAMA
[27.262] Initializing built-in extension XFIXES
[27.262] Initializing built-in extension RENDER
[27.262] Initializing built-in extension RANDR
[27.262] Initializing built-in extension COMPOSITE
[27.262] Initializing built-in extension DAMAGE
[27.262] Initializing built-in extension MIT-SCREEN-SAVER
[27.262] Initializing built-in extension DOUBLE-BUFFER
[27.262] Initializing built-in extension RECORD
[27.262] Initializing built-in extension DPMS
[27.262] Initializing built-in extension X-Resource
[27.262] Initializing built-in extension XVideo
[27.262] Initializing built-in extension XVideo-MotionCompensation
[27.262] Initializing built-in extension SELinux
[27.262] Initializing built-in extension XFree86-VidModeExtension
[27.262] Initializing built-in extension XFree86-DGA
[27.262] Initializing built-in extension XFree86-DRI
[27.262] Initializing built-in extension DRI2
[27.262] (II) "glx" will be loaded by default.
[27.262] (WW) "xwayland" is not to be loaded by default. Skipping.
[27.262] (II) LoadModule: "dri2"
[27.263] (II) Module "dri2" already built-in
[27.263] (II) LoadModule: "glamoregl"
[27.263] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[27.267] (II) Module glamoregl: vendor="X.Org Foundation"
[27.267] compiled for 1.14.3, module version = 0.5.1
[27.267] ABI class: X.Org ANSI C Emulation, version 0.4
[27.267] (II) LoadModule: "glx"
[27.267] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[27.267] (II) Module glx: vendor="X.Org 

[Bug 89944] GPU crash in Civilization 5

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89944

--- Comment #4 from qaridarium  ---
I think I do have the same problem.

http://www.phoronix.com/forums/showthread.php?116700-HD7850-radeon-oibaf-ppa-Zivilisation-5-crash

I do have a hd7850 and I use the oibaf PPA to run the GIT code

-- 
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/20150409/d5834682/attachment.html>

[PATCH -v3 00/11] drm/exynos: Add atomic modesetting support

[Inki Dae]

On 2015년 04월 08일 03:39, Gustavo Padovan wrote:
> Hi Inki,
> 
> 2015-04-07 Inki Dae :
> 
>> On 2015년 04월 07일 00:44, Inki Dae wrote:
>>> 2015-04-06 19:46 GMT+09:00 Inki Dae :
 On 2015년 04월 04일 03:09, Gustavo Padovan wrote:
> From: Gustavo Padovan 
>
> Hi,
>
> Here goes the full support for atomic modesetting on exynos. I've
> split the patches in the various phases of atomic support.
>
> These patches sits on top of the clean up patches I've sent yesterday
> to this mailing list[1].
>
> v2: fixes comments by Joonyoung
> - remove unused var in patch 09
> - use ->disable instead of outdated ->dpms in hdmi code
> - remove WARN_ON from crtc enable/disable
>
> v3: fixes comment by Joonyoung
>   - move the removal of drm_helper_disable_unused_functions() to
>   separated patch

 With this patch series, Kernel booting is halted at end of kernel
 booting. I tested this patch series on Trats2 board based on Exynos4412 
 SoC.

 Below is a part of full booting logs, which was halted,
 [1.992015] exynos-drm-ipp exynos-drm-ipp: drm ipp registered
 successfully.
 [1.993009] exynos-drm exynos-drm: bound exynos-drm-vidi (ops
 vidi_component_ops)
 [1.993036] exynos-drm exynos-drm: bound 11c0.fimd (ops
 fimd_component_ops)
 [1.993385] exynos-drm exynos-drm: bound 11c8.dsi (ops
 exynos_dsi_component_ops)
 [1.993390] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
 [1.993393] [drm] No driver support for vblank timestamp query.
 [1.993442] [drm] Initialized exynos 1.0.0 20110530 on minor 0
 [2.043358] WARNING: CPU: 2 PID: 1209 at drivers/clk/clk.c:898
 clk_unprepare+0x24/0x2c()
 [2.051412] Modules linked in:
 [2.054422] CPU: 2 PID: 1209 Comm: kworker/2:1 Tainted: GW
 4.0.0-rc6-00526-gc49d7de-dirty #1278
 [2.064337] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
 [2.070428] Workqueue: pm pm_runtime_work>

 After that, I tested it again without FIMD and the booting is ok. So I
 guess that this atomic feature has a bug to FIMD driver.

>>>
>>> More information,
>>>
>>> The reason the booting is halted is that a deadlock occurs at fbcon
>>> module when register_framebuffer() is called.
>>>
>>> Below are our test results,
>>> - with only cleanup series, FIMD and HDMI work well.
>>> - with cleanup and atomic series, HDMI works well but FIMD doesn't
>>> work - a deadlock occurs.
>>>
>>> Could anyone test it with the atomic series on trats2 board? You can
>>> test it on top of exynos-drm-next-todo branch which contains all
>>> relevant patches,
>>> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-todo
>>>
>>> Anyway, we will continue to take a look at the this issue why the
>>> deadlock occurs.
>>
>> In addition,
>>
>> I added some codes temporarily to fbmem module which mitigates the
>> deadlock issue. After that, I see below panic log,
>>
>> [3.254840] Unable to handle kernel NULL pointer dereference at
>> virtual address 00a4
>> [3.262870] pgd = c0004000
>> [3.265539] [00a4] *pgd=
>> [3.269102] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>> [3.274392] Modules linked in:
>> [3.277435] CPU: 2 PID: 1 Comm: swapper/0 Tainted: GW
>> 4.0.0-rc6-00526-gc49d7de-dirty #1308
>> [3.286892] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [3.292970] task: ee878000 ti: ee88 task.ti: ee88
>> [3.298356] PC is at exynos_plane_atomic_update+0x24/0x1d4
>> [3.303824] LR is at drm_atomic_helper_commit_planes+0xa4/0x18c
>> [3.309723] pc : []lr : []psr: 6113
>> [3.309723] sp : ee881b38  ip : 0020  fp : 
>> [3.321179] r10: c04cfc00  r9 : 0008  r8 : eebfb9c0
>> [3.326387] r7 : 0002  r6 :   r5 :   r4 : ee925308
>> [3.332897] r3 : ee329fc0  r2 :   r1 :   r0 : ee925308
>> [3.339409] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
>> Segment kernel
>> [3.346699] Control: 10c5387d  Table: 4000404a  DAC: 0015
>> [3.352427] Process swapper/0 (pid: 1, stack limit = 0xee880210)
>> [3.358416] Stack: (0xee881b38 to 0xee882000)
>> [3.362757] 1b20:
>>c0726794 0008
>> [3.370919] 1b40: 0002 ee925308  ee329e00 0002
>> eebfb9c0 0008 c04cfc00
>> [3.379078] 1b60:  c0265308 0008  ee329e00
>> ee0a8000 0008 
>> [3.387237] 1b80:  c0267304 ee329e00 ee8efe00 ee914c00
>> 0002  0002
>> [3.395396] 1ba0:  c026609c c0265ef0  ee914c00
>> 0028 ee8eff00 0001
>> [3.403555] 1bc0:  c06c8380  c02770d0 ee8efe00
>>  0028 ee8eff00
>> [3.411714] 1be0: 0001 c0267a2c ee0a8000 c0286214