[Bug 92228] Missing ground in SotA and missing map in 7 days to die

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

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

--- Comment #1 from Daniel Scharrer  ---
Sounds like this could be a duplicate of bug #92122.

There is a patch on the mailing list waiting for review:
https://patchwork.freedesktop.org/patch/60540/

-- 
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/20151001/9bd17c71/attachment.html>

[Bug 92228] Missing ground in SotA and missing map in 7 days to die

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

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

Bug ID: 92228
   Summary: Missing ground in SotA and missing map in 7 days to
die
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: bellamorte42 at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Both are Unity 5 games but I wasn't having this issue until I loaded the mesa
git code.  The ground in Shroud of the Avatar no longer renders at all but
objects are fine.  Objects and characters that move (whether on their own or by
panning the camera) have their images saved where the ground textures should
be.  In 7 days to die the map pops up but the terrain does not display, it's
just an empty box with the player marker in the center.

-- 
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/20151001/fc0ad2b1/attachment.html>

[RFC v2 1/4] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding

[Daniel Kurtz]

On Thu, Oct 1, 2015 at 8:58 PM, Rob Herring  wrote:
> On Thu, Oct 1, 2015 at 3:59 AM, Philipp Zabel  
> wrote:
>> Am Mittwoch, den 30.09.2015, 12:13 -0500 schrieb Rob Herring:
>>> On Mon, Sep 21, 2015 at 3:11 AM, Philipp Zabel  
>>> wrote:
>>> > Note how the display-subsystem node overlaps the larb node. Is that
>>> > acceptable?
>>>
>>> Given what the graph looks like, perhaps. However, do you really need
>>> a container node? It only serves to provide a list of nodes (e.g. all
>>> the children) to include as components. There are other ways to
>>> determine this list. You could find all nodes just searching
>>> compatible strings for each component. You just need to bind the drm
>>> driver to some other DT node. Is there no node you can pick as the
>>> master component?
>>
>> There is the mmsys clock-controller node at the top of the MMSYS address
>> space (0x1400-0x14ff):
>>
>> mmsys: clock-controller at 1400 {
>> compatible = "mediatek,mt8173-mmsys", "syscon";
>> reg = <0 0x1400 0 0x1000>;
>> #clock-cells = <1>;
>> };
>>
>> Its register space also contains the MMSYS_CONFIG region that controls
>> the multiplexers between the display function blocks, so that would be a
>> good candidate.
>> No driver binds to this node yet, the clocks are registered with
>> CLK_OF_DECLARE.
>>
>> I'll try to bind to this node and have the driver find sibling nodes
>> using their compatible strings.
>
> That doesn't seem like a good choice since there are other functions
> in the block. I was thinking one of the display related blocks like
> whatever block provides the main crtc functions.

The two "OVL" nodes correspond to the "crtc" functions of the two
display pipes in this SoC, we would setup the display-subsystem node
like this:

display-subsystem {
  compatible = "mediatek,display-subsystem";
  ports = <>, <>;
};

And, any node that needs to poke around in the mmsys_config area, like
an ovl, could access it using a phandle <> to the common
"mediatek,mt8173-mmsys" device, like this:

ovl0: ovl at 1400c000 {
   compatible = "mediatek,mt8173-ovl";
   reg = <0 0x1400c000 0 0x1000>;
   interrupts = ;
   clocks = < CLK_MM_DISP_OVL0>;
   iommus = < M4U_LARB0_ID M4U_PORT_DISP_OVL0>;
   mediatek,mmsys = <>;
   status = "disabled";
};

One idea to reduce the size of the of_graph would be to just model the
entrance/exit points from the MM subsystem in dt.  So, instead of:
  ovl0 -> color0 -> aal -> od -> ufoe -> dsi0 -> dsi-edp-bridge
  ovl1 -> color1 -> gamma0 -> dpi0 -> hdmi

We can do something like this:
  ovl0 -> dsi0 -> dsi-edp-bridge
  ovl1 -> dpi0 -> hdmi

But ... this might be too limiting for some applications.
So, I think we should just live with the big graph.
I would, however, recommend that you move the graph to its own
mt8173-display-graph.dtsi file which would be #included into a board
specific .dts file.

If you let the board .dts include the graph, then we can possibly
shrink the resulting board specific device tree -
At first we would make the full graph in one .dtsi as above
"mt8173-display-graph.dtsi".
This is the full reference graph that will always work.

Then, if a particular board used a fixed configuration, the system
integrator could create a smaller graph with just the graph nodes that
they care about.

For example, if mt8173-evb only supports a single HDMI output, then
perhaps you would just
set up the endpoints for this single fixed function display pipe in
mt8173-evb-display-graph.dtsi:

 {
status = "okay";
port {
ovl1_to_color1: endpoint at 0 {
remote-endpoint = <_from_ovl1>;
};
};
};

 {
status = "okay";
port at 0 {
color1_from_ovl1: endpoint at 1 {
remote-endpoint = <_to_color1>;
};
};

port at 1 {
color1_to_gamma: endpoint at 0 {
remote-endpoint = <_from_color1>;
};
};
};

 {
status = "okay";
port at 0 {
gamma_from_color1: endpoint {
remote-endpoint = <_to_gamma>;
};
};

port at 1 {
gamma_to_dpi0: endpoint at 3 {
remote-endpoint = <_from_gamma>;
};
};
};

 {
status = "okay";
port at 0 {
dpi0_from_gamma: endpoint at 2 {
remote-endpoint = <_to_dpi0>;
};
};

port at 1 {
dpi0_to_hdmi: endpoint {
remote-endpoint = <_from_dpi0>;
};
};
};

Notice that this also only enables the nodes that we care about (all
of the other nodes would be disabled by default).

I this would allow full flexibility but also drastically cut down on
the resulting .dts size.

The individual component drivers would then march down their graphs
ensuring that all of the corresponding components have been bound, and
then themselves appropriately based on their set of endpoints that are
available.

What do you think?

-Dan


>
> Rob
> 

[Bug 91342] Very dark textures on some objects in indoors environments in Postal 2

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

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

--- Comment #12 from Daniel Scharrer  ---
The apitrace is fixed for me with this commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=b3f9c5cc0fab6d770d220efd87ba3746c6673875

acutiator, can you check if the bug is fixed for you as well?

-- 
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/20151001/a43d4d34/attachment.html>

[PATCH 6/6] drm/msm: add OCMEM driver

[Rob Clark]

On Thu, Oct 1, 2015 at 8:59 PM, Stephen Boyd  wrote:
> On 10/01, Rob Clark wrote:
>> On Thu, Oct 1, 2015 at 3:25 PM, Rob Clark  wrote:
>> > On Thu, Oct 1, 2015 at 2:00 PM, Stephen Boyd  
>> > wrote:
>> >>
>> >> The simplest thing to do is to split the memory between GPU and
>> >> vidc statically. The other use cases with preemption and eviction
>> >> and DMA add a lot of complexity that we can explore at a later
>> >> time if need be.
>> >
>> > true, as long as one of the clients is the static gpu client, I guess
>> > we could reasonably easily support up to two clients reasonably
>> > easily...
>>
>> btw, random thought..  drm_mm is a utility in drm that serves a
>> similar function to genalloc for graphics drivers to manage their
>> address space(s) (used for everything from mmap virtual address space
>> of buffers allocated against device to managing vram and gart
>> allocations, etc... when vram carveout is used w/ drm/msm (due to no
>> iommu) I use it to manage allocations from the carveout).  It has some
>> potentially convenient twists, like supporting allocation from top of
>> the "address space" instead of bottom.  I'm thinking in particular of
>> allocating "narrow mode" allocations from top and "wide mode" from
>> bottom since wide vs narrow can only be set per region and not per
>> macro within the region.  (It can also search by first-fit or
>> best-fit.. although not sure if that is useful to us, since OCMEM size
>> is relatively constrained.)
>>
>> Not that I really want to keep ocmem allocator in drm.. I'd really
>> rather it be someone else's headache once it gets to implementing the
>> crazy stuff for all the random use-cases of other OCMEM users, since
>> gpu's use of OCMEM is rather simple/static..
>>
>> The way downstream driver does this is with a bunch of extra
>> bookkeeping on top of genalloc so it can do a dummy allocation to
>> force "from the top" allocation (and then immediately freeing the
>> dummy allocation)..  Maybe it just makes sense to teach genalloc how
>> to do from-top vs from-bottom allocations?  Not really sure..
>>
>
> It looks like video and GPU both use wide mode, if I'm reading
> the code correctly. So it seems that we don't need to do anything
> special for allocations, just hand the GPU and vidc a chunk of
> the memory in wide mode and then let the GPU and vidc drivers
> manage buffers within their chunk however they see fit.

right, I think it is just audio that uses narrow-mode..  and at that
point I think we need to use rpm for configuring things, since I guess
audio wants to do some of that from dsp for low-power audio playback
type use-cases??  Maybe we can ignore this for a while.. although when
we get to the point of fixing it, spiffing out genalloc sounds more
interesting than layering a bunch of bookkeeping on top of genalloc..

> One pitfall is going to be power management. ocmem is closely
> tied to the GPU power domains, so when video is using its chunk
> of memory we're going to need to keep ocmem powered up even if
> the GPU is off. I suppose for now we can just leave it always
> powered on once the driver probes, but if we ever want to turn it
> off we're going to need some tracking mechanism to make sure we
> don't turn it off when buffers are in use.

part of the problem that right now drm/msm is going to hold onto it's
allocation even when it clks down gpu.  I suppose not terribly
difficult to fix (although one reason why I didn't bother making
things terribly dynamic w/ clk mgmt or macro mode state in current
ocmem patch).. at this point I'm still more at the 'just try to make
it work in the first place' stage, rather than worrying too much about
optimizing for power..

BR,
-R

[Bug 92214] Flightgear crashes during splashboot with R600 driver and mesa 11.0.2

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

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

--- Comment #9 from Barto  ---
with apitrace I found maybe an interesting thing when I replay my trace file
for the bug :

t seems that the function "glRasterPos2i(0,0)" is the last openGL call before
the crash, if I try to run this call in apitrace ( with a double click ) I can
see this error message :

caught an unhandled exception
glretrace+0x23c99c
/usr/lib/libpthread.so.0+0x10d5f
?+0x7f2f764655eb
apitrace: info: taking default action for signal 4

I followed my instinct, I found a C++ source code in google about
glRasterPos2i() function and I compile it in order to test the glRasterPos2i()
function :

#include 
#include 
#include 

using namespace std;


void display()
{
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity();

glColor3ub(255,0,0);
glPushMatrix();
glScalef(5,5,5);
glBegin(GL_QUADS);
glVertex2f(-1,-1);
glVertex2f(1,-1);
glVertex2f(1,1);
glVertex2f(-1,1);
glEnd();
glPopMatrix();

glColor3ub(0,255,0);// A
glRasterPos2i(0,0); // B

string tmp( "wha-hey!" );
for( size_t i = 0; i < tmp.size(); ++i )
{
glutBitmapCharacter(GLUT_BITMAP_HELVETICA_18, tmp[i]);
}

glutSwapBuffers();
}

void reshape(int w, int h)
{
glViewport(0, 0, w, h);

glMatrixMode(GL_PROJECTION);
glLoadIdentity();

double aspect_ratio = (double)w / (double)h;
glOrtho(-10*aspect_ratio, 10*aspect_ratio, -10, 10, -1, 1);
}

int main(int argc, char **argv)
{
glutInit(, argv);
glutInitDisplayMode(GLUT_RGBA | GLUT_DEPTH | GLUT_DOUBLE);

glutInitWindowSize(800,600);
glutCreateWindow("Text");

glutDisplayFunc(display);
glutReshapeFunc(reshape);
glutMainLoop();
return EXIT_SUCCESS;
}

If I run this test code I get the same error message : "illegal instruction",

but if I comment the line "glRasterPos2i(0,0);" then there is no bug, the test
program can run and I see a screen with a red square,

I am a newbie in openGL programming but it seems that mesa 11.0.2 has a problem
with "glRasterPos2i()" function if the r600 gallium driver is used ( amd radeon
HD4650 Pcie graphic card )

-- 
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/20151001/abbc766d/attachment.html>

[Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

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

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

--- Comment #11 from Tim Sammut  ---
(In reply to Robert Abraham from comment #6)
> commit 
> 4eebd5a4e72697aac25a8a57d3f888a9d5f80370
> 
> breaks the backlight for me.

Yep, me too. Reverting that change against a 4.2.1 kernel completely fixes the
issues. Brightness adjusts and OSD appears.

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

[Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

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

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

Tim Sammut  changed:

   What|Removed |Added

  Component|Video(DRI - non Intel)  |Platform_x86

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

[Bug 92220] GL_NV_vdpau_interop partially available

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

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

--- Comment #3 from Alex Deucher  ---
You can't really enable a GL extension if there is not support for the entire
thing.  Early versions of UVD did not support field based output.  The
extension provides access to both the raw decoded video surfaces (field based)
and the vdpau processed output surface (frame based).  I think by default kodi
only uses the vdapu processed output which is the part that is supported. 
Changing the kodi settings may require the full extension which will not work.

I guess there are 3 options:

1. Force the option but limit it to cases where you are only using the output
surface via the interop extension.  This works today.
2. Add an extra step to the drivers using shaders to split the frame up into
separate fields in vlVdpVideoSurfaceGallium
(src/gallium/state_trackers/vdpau/surface.c) for chips that don't support field
based decode.  This adds an extra copy and someone needs to write the code. 
With that done, the extension can be enabled on all asics.
3.  Write a new simplified GL/VDPAU interop extension that only supports
interop with output surfaces.  This extension could be enabled on all asics.

-- 
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/20151001/5b8fd8ac/attachment.html>

[PATCH 6/6] drm/msm: add OCMEM driver

[Rob Clark]

On Thu, Oct 1, 2015 at 3:25 PM, Rob Clark  wrote:
> On Thu, Oct 1, 2015 at 2:00 PM, Stephen Boyd  wrote:
>> On 10/01, Stanimir Varbanov wrote:
>>> On 09/30/2015 02:45 PM, Rob Clark wrote:
>>> > On Wed, Sep 30, 2015 at 7:31 AM, Rob Clark  wrote:
>>> >> On Wed, Sep 30, 2015 at 3:51 AM, Stanimir Varbanov
>>> >>  wrote:
>>> >>> On 09/29/2015 10:48 PM, Rob Clark wrote:
>>> >> was mandatory or just power optimization..  but yes, the plan was to
>>> >> move it somewhere else (not sure quite where, drivers/doc/qcom?)
>>> >> sometime..  Preferably when someone who understands all the other
>>> >> ocmem use-cases better could figure out what we really need to add to
>>> >> the driver.
>>> >>
>>> >> In downstream driver there is a lot of complexity that appears to be
>>> >> in order to allow two clients to each allocate a portion of a macro
>>> >> within a region (ie. aggregate_macro_state(), apply_macro_vote(),
>>> >> etc), and I wanted to figure out if that is even a valid use-case
>>> >> before trying to make ocmem something that could actually support
>>> >> multiple clients.
>>> >>
>>> >> There is also some complexity about ensuring that if clients aren't
>>> >> split up on region boundaries, that you don't have one client in
>>> >> region asking for wide-mode and other for narrow-mode..
>>> >> (switch_region_mode()) but maybe we could handle that by just
>>> >> allocating wide from bottom and narrow from top.  Also seems to be
>>> >> some craziness for allowing one client to pre-empt/evict another.. a
>>> >> dm engine, etc, etc..
>>> >>
>>> >> All I know is gpu just statically allocates one big region aligned
>>> >> chunk of ocmem, so I ignored the rest of the crazy (maybe or maybe not
>>> >> hypothetical) use-cases for now...
>>>
>>> OK, I will try to sort out ocmem use cases for vidc driver.
>>>
>>
>> The simplest thing to do is to split the memory between GPU and
>> vidc statically. The other use cases with preemption and eviction
>> and DMA add a lot of complexity that we can explore at a later
>> time if need be.
>
> true, as long as one of the clients is the static gpu client, I guess
> we could reasonably easily support up to two clients reasonably
> easily...

btw, random thought..  drm_mm is a utility in drm that serves a
similar function to genalloc for graphics drivers to manage their
address space(s) (used for everything from mmap virtual address space
of buffers allocated against device to managing vram and gart
allocations, etc... when vram carveout is used w/ drm/msm (due to no
iommu) I use it to manage allocations from the carveout).  It has some
potentially convenient twists, like supporting allocation from top of
the "address space" instead of bottom.  I'm thinking in particular of
allocating "narrow mode" allocations from top and "wide mode" from
bottom since wide vs narrow can only be set per region and not per
macro within the region.  (It can also search by first-fit or
best-fit.. although not sure if that is useful to us, since OCMEM size
is relatively constrained.)

Not that I really want to keep ocmem allocator in drm.. I'd really
rather it be someone else's headache once it gets to implementing the
crazy stuff for all the random use-cases of other OCMEM users, since
gpu's use of OCMEM is rather simple/static..

The way downstream driver does this is with a bunch of extra
bookkeeping on top of genalloc so it can do a dummy allocation to
force "from the top" allocation (and then immediately freeing the
dummy allocation)..  Maybe it just makes sense to teach genalloc how
to do from-top vs from-bottom allocations?  Not really sure..

BR,
-R

[Bug 92220] GL_NV_vdpau_interop partially available

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

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

--- Comment #2 from Peter Frühberger  ---
>From Kodi POV we like to have a best practice to cope with such devices. For
now we check for the extension and if found use the methods it defines.

As those cards don't expose this extentions we exit early. If there is
something we can do to make kodi work reliable on that hardware without any
crude hacks - like asking for extension and use it even if not there at all -
we are happy to implement such methods.

The best would be to implement the missing feature by some Shader / whatever
solution - transparent to use and enable the extension completely again.

-- 
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/20151001/28b7a5f7/attachment.html>

[Bug 92220] GL_NV_vdpau_interop partially available

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

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

riaasm at yahoo.com changed:

   What|Removed |Added

Summary|GL_NV_vdpau_interop |GL_NV_vdpau_interop
   |partially implemented   |partially available

-- 
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/20151001/837c84fd/attachment.html>

[Bug 92214] Flightgear crashes during splashboot with R600 driver and mesa 11.0.2

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

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

--- Comment #8 from Barto  ---
(In reply to Emil Velikov from comment #7)
> Running with LIBGL_ALWAYS_SOFTWARE removes any hardware specifics and
> glxgears/foo runs on the CPU alone. Suspecting a different bug - perhaps
> glibc 2.22/llvm 3.7 related ? I'm using same gcc + glibc 2.21-4 + llvm
> 3.6.2-3.
> 
> Might want to open another bug report for that one.

I use glibc 2.22-3 ( not 2.21-4 ) and llvm 3.7.0-4, they are in the archlinux
stable repositories,

"export LIBGL_ALWAYS_SOFTWARE=1" doesn't work with all openGL programs,
glxgears, blender, 3D games, they all crash with the error "Illegal instruction
(core dumped)" if "LIBGL_ALWAYS_SOFTWARE" is set to "1"

-- 
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/20151001/b782719f/attachment.html>

[Bug 92220] GL_NV_vdpau_interop partially implemented

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

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

--- Comment #1 from riaasm at yahoo.com ---
(Can't seem to edit my earlier comment, so I'll continue here)
It seems like there's something strange going on with this GL extension.
Someone on the Kodi forum looked into this for me and found out that the
problem was that it's only partially supported. I'm not sure how this can or
should be fixed. 

If this is a hardware limitation, perhaps there should be some way to find out
if at least the one-way part of the extension is supported (from userspace). 

If it's only partially implemented in the radeon driver, perhaps this needs to
be completed. Or maybe the part that's implemented is good enough to enable the
extension, I don't know. 

But it seemed like it was worth mentioning to the appropriate people. There is
also mention of a 200ms (or 175ms to be exact) delay/latency for the video
processing (which means the video is lagging 200ms behind the audio) in the
Kodi thread. It's possible that it is not related to this, but I wanted to
mention it anyway (in case it is related).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151001/a063edaa/attachment.html>

[Bug 92214] Flightgear crashes during splashboot with R600 driver and mesa 11.0.2

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

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

--- Comment #7 from Emil Velikov  ---
Running with LIBGL_ALWAYS_SOFTWARE removes any hardware specifics and
glxgears/foo runs on the CPU alone. Suspecting a different bug - perhaps glibc
2.22/llvm 3.7 related ? I'm using same gcc + glibc 2.21-4 + llvm 3.6.2-3.

Might want to open another bug report for that one.

-- 
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/20151001/3ff2e831/attachment.html>

[Bug 92220] GL_NV_vdpau_interop partially implemented

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

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

Bug ID: 92220
   Summary: GL_NV_vdpau_interop partially implemented
   Product: Mesa
   Version: 10.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: riaasm at yahoo.com
QA Contact: dri-devel at lists.freedesktop.org

Hardware: RS880 AMD Radeon HD 4290

It seems like the GL_NV_vdpau_interop extension is only partially supported on
this hardware. The vdpau -> GL part works, but not the other way around.
However, since it's only partially supported, the extension is not enabled. But
the vdpau -> GL part is very useful for hardware accelerated video, as is done
in Kodi. 

When I watch a video in Kodi, the h/w acceleration doesn't work. When I enable
this extension by using the environment variable MESA_EXTENSION_OVERRIDE, I can
watch the video in Kodi using h/w acceleration through VDPAU. 

I've discussed this on the Kodi forum and it was suggested that it would be a
good idea to report this as a bug. The thread can be found here:
http://forum.kodi.tv/showthread.php?tid=231416=3

-- 
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/20151001/8ff71ca7/attachment.html>

[PATCH] drm/gma500: fix double freeing

[Patrik Jakobsson]

On Wed, Sep 30, 2015 at 8:12 AM, Sudip Mukherjee
 wrote:
> On Tue, Sep 29, 2015 at 03:20:35PM +0200, Patrik Jakobsson wrote:
>> On Thu, Sep 24, 2015 at 5:57 PM, Sudip Mukherjee
>>  wrote:
>> > On Wed, Sep 09, 2015 at 06:20:40PM +0530, Sudip Mukherjee wrote:
>> >> If backing->stolen is true then we were freeing backing by calling
>> >> psb_gtt_free_range() but we called it again after unlocking the mutex.
>> >> Lets make it NULL after freeing in psb_gtt_free_range() and check for
>> >> NULL before calling the function for the second time.
>> >>
>> >> Signed-off-by: Sudip Mukherjee 
>> >> ---
>> > Hi Patrik,
>> > A gentle ping.
>> >
>> > regards
>> > sudip
>>
>> Hi, sorry for the late reply.
>>
>> Why are we freeing the range twice in the first case?
> I think,
> if backing->stolen is true then backing is released using
> psb_gtt_free_range() but if backing->stolen is false then the gem object
> is freed but the backing is not yet freed. To free that backing
> psb_gtt_free_range() has been called second time. My patch tried to fix
> the possibility of backing->stolen being true and backing being freed 2
> times.
>
> regards
> sudip

There are some special handling of the stolen framebuffer that I don't
remember entirely but the basic concept is that we free the backing
when we drop the last reference on a gem object. That will trigger a
psb_gtt_free_range(). So in this case it looks to me that the extra
free is not needed at all. That's my quick reasoning, feel free to
prove me wrong :)

Thanks
Patrik

[PATCH RFC V2 5/5] DT: sti: add audio HDMI dai link in audio card

[Arnaud Pouliquen]

Add the HDMI dai link to support audio for HDMi output

Signed-off-by: Arnaud Pouliquen 
---
 arch/arm/boot/dts/stih410.dtsi   |  6 +-
 arch/arm/boot/dts/stihxxx-b2120.dtsi | 21 +
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index 7ee7dc0..dfc61a9 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -186,8 +186,9 @@
 <_s_d2_quadfs 0>;
};

-   sti-hdmi at 8d04000 {
+   sti_hdmi: sti-hdmi at 8d04000 {
compatible = "st,stih407-hdmi";
+   #sound-dai-cells = <0>;
reg = <0x8d04000 0x1000>;
reg-names = "hdmi-reg";
interrupts = ;
@@ -211,6 +212,9 @@
resets = < 
STIH407_HDMI_TX_PHY_SOFTRESET>;
ddc = <>;

+   sound-dai {
+   format = "spdif";
+   };
};

sti-hda at 8d02000 {
diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi 
b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index 3ad9c82..80fed19 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -81,6 +81,9 @@
audio_controller: sti-asoc-platform {
status = "okay";
};
+   sti_uni_player0: sti-uni-player at 0 {
+   status = "okay";
+   };
sti_uni_player2: sti-uni-player at 2 {
status = "okay";
};
@@ -93,6 +96,12 @@
sti_uni_reader1: sti-uni-reader at 1 {
status = "okay";
};
+
+   sti-display-subsystem {
+   sti_hdmi: sti-hdmi at 8d04000 {
+   status = "okay";
+   };
+   };
};

sound {
@@ -125,6 +134,18 @@
sound-dai = <_sasg_codec 0>;
};
};
+   simple-audio-card,dai-link at 2 {
+   /* HDMI */
+   format = "i2s";
+   mclk-fs = <128>;
+   cpu {
+   sound-dai = <_uni_player0>;
+   };
+
+   codec {
+   sound-dai = <_hdmi>;
+   };
+   };
};

 };
-- 
1.9.1

[PATCH RFC V2 4/5] drm: sti: connect audio driver

[Arnaud Pouliquen]

Registeur Asoc codec and implement audio bridge ops.

Signed-off-by: Arnaud Pouliquen 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 184 ++---
 drivers/gpu/drm/sti/sti_hdmi.h |   3 +
 2 files changed, 176 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 06595e9..cf0e307 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -17,6 +17,8 @@
 #include 
 #include 

+#include 
+
 #include "sti_hdmi.h"
 #include "sti_hdmi_tx3g4c28phy.h"
 #include "sti_hdmi_tx3g0c55phy.h"
@@ -34,6 +36,8 @@
 #define HDMI_DFLT_CHL0_DAT  0x0110
 #define HDMI_DFLT_CHL1_DAT  0x0114
 #define HDMI_DFLT_CHL2_DAT  0x0118
+#define HDMI_AUDIO_CFG  0x0200
+#define HDMI_SPDIF_FIFO_STATUS  0x0204
 #define HDMI_SW_DI_1_HEAD_WORD  0x0210
 #define HDMI_SW_DI_1_PKT_WORD0  0x0214
 #define HDMI_SW_DI_1_PKT_WORD1  0x0218
@@ -43,6 +47,9 @@
 #define HDMI_SW_DI_1_PKT_WORD5  0x0228
 #define HDMI_SW_DI_1_PKT_WORD6  0x022C
 #define HDMI_SW_DI_CFG  0x0230
+#define HDMI_SAMPLE_FLAT_MASK   0x0244
+#define HDMI_AUDN   0x0400
+#define HDMI_AUD_CTS0x0404
 #define HDMI_SW_DI_2_HEAD_WORD  0x0600
 #define HDMI_SW_DI_2_PKT_WORD0  0x0604
 #define HDMI_SW_DI_2_PKT_WORD1  0x0608
@@ -109,6 +116,29 @@

 #define HDMI_STA_SW_RST BIT(1)

+#define HDMI_AUD_CFG_8CH   BIT(0)
+#define HDMI_AUD_CFG_SPDIF_DIV_2   BIT(1)
+#define HDMI_AUD_CFG_SPDIF_DIV_3   BIT(2)
+#define HDMI_AUD_CFG_SPDIF_CLK_DIV_4   (BIT(1) | BIT(2))
+#define HDMI_AUD_CFG_CTS_CLK_256FS BIT(12)
+#define HDMI_AUD_CFG_DTS_INVALID   BIT(16)
+#define HDMI_AUD_CFG_ONE_BIT_INVALID   (BIT(18) | BIT(19) | BIT(20) |  BIT(21))
+#define HDMI_AUD_CFG_CH12_VALIDBIT(28)
+#define HDMI_AUD_CFG_CH34_VALIDBIT(29)
+#define HDMI_AUD_CFG_CH56_VALIDBIT(30)
+#define HDMI_AUD_CFG_CH78_VALIDBIT(31)
+
+/* sample flat mask */
+#define HDMI_SAMPLE_FLAT_NO 0
+#define HDMI_SAMPLE_FLAT_SP0 BIT(0)
+#define HDMI_SAMPLE_FLAT_SP1 BIT(1)
+#define HDMI_SAMPLE_FLAT_SP2 BIT(2)
+#define HDMI_SAMPLE_FLAT_SP3 BIT(3)
+#define HDMI_SAMPLE_FLAT_ALL (HDMI_SAMPLE_FLAT_SP0 \
+ | HDMI_SAMPLE_FLAT_SP1 \
+ | HDMI_SAMPLE_FLAT_SP2 \
+ | HDMI_SAMPLE_FLAT_SP3)
+
 #define HDMI_INFOFRAME_HEADER_TYPE(x)(((x) & 0xff) <<  0)
 #define HDMI_INFOFRAME_HEADER_VERSION(x) (((x) & 0xff) <<  8)
 #define HDMI_INFOFRAME_HEADER_LEN(x) (((x) & 0x0f) << 16)
@@ -380,19 +410,15 @@ static int hdmi_avi_infoframe_config(struct sti_hdmi 
*hdmi)
  */
 static int hdmi_audio_infoframe_config(struct sti_hdmi *hdmi)
 {
-   struct hdmi_audio_infoframe infofame;
+   struct hdmi_audio_infoframe *infoframe;
u8 buffer[HDMI_INFOFRAME_SIZE(AUDIO)];
int ret;

-   ret = hdmi_audio_infoframe_init();
-   if (ret < 0) {
-   DRM_ERROR("failed to setup audio infoframe: %d\n", ret);
-   return ret;
-   }
+   DRM_DEBUG_DRIVER("enter %s\n", __func__);

-   infofame.channels = 2;
+   infoframe = >audio.infoframe;

-   ret = hdmi_audio_infoframe_pack(, buffer, sizeof(buffer));
+   ret = hdmi_audio_infoframe_pack(infoframe, buffer, sizeof(buffer));
if (ret < 0) {
DRM_ERROR("failed to pack audio infoframe: %d\n", ret);
return ret;
@@ -404,6 +430,60 @@ static int hdmi_audio_infoframe_config(struct sti_hdmi 
*hdmi)
 }

 /**
+ * set audio frame rate
+ *
+ * @hdmi: pointer on the hdmi internal structure
+ *
+ */
+static int hdmi_audio_set_infoframe(struct sti_hdmi *hdmi,
+   struct hdmi_audio_infoframe *info)
+{
+   struct hdmi_audio_n_cts n_cts;
+   int ret, audio_cfg;
+
+   DRM_DEBUG_DRIVER("enter %s\n", __func__);
+
+   hdmi->audio.infoframe = *info;
+
+   if (!hdmi->enabled)
+   return 0;
+
+   /* update HDMI registers according to configuration */
+   audio_cfg = HDMI_AUD_CFG_SPDIF_DIV_2 | HDMI_AUD_CFG_DTS_INVALID |
+   HDMI_AUD_CFG_ONE_BIT_INVALID;
+
+   switch (info->channels) {
+   case 8:
+   audio_cfg |= HDMI_AUD_CFG_CH78_VALID;
+   case 6:
+   audio_cfg |= HDMI_AUD_CFG_CH56_VALID;
+   case 4:
+   audio_cfg |= HDMI_AUD_CFG_CH34_VALID | HDMI_AUD_CFG_8CH;
+   case 2:
+   audio_cfg |= HDMI_AUD_CFG_CH12_VALID;
+   break;
+   default:
+   DRM_ERROR("ERROR: Unsupported number of channels (%d)!\n",
+ info->channels);
+   return -EINVAL;
+   }
+
+   hdmi_write(hdmi, audio_cfg, HDMI_AUDIO_CFG);
+
+   /* update N parameter */
+   ret = 

[PATCH RFC V2 3/5] ASoC: codec: hdmi drm codec driver

[Arnaud Pouliquen]

Add a generic codec to interface audio with DRM drivers

Signed-off-by: Arnaud Pouliquen 
---
 include/sound/hdmi_drm.h|  15 ++
 sound/soc/codecs/Kconfig|   8 +-
 sound/soc/codecs/Makefile   |   2 +
 sound/soc/codecs/hdmi_drm.c | 358 
 4 files changed, 380 insertions(+), 3 deletions(-)
 create mode 100644 include/sound/hdmi_drm.h
 create mode 100644 sound/soc/codecs/hdmi_drm.c

diff --git a/include/sound/hdmi_drm.h b/include/sound/hdmi_drm.h
new file mode 100644
index 000..411acee
--- /dev/null
+++ b/include/sound/hdmi_drm.h
@@ -0,0 +1,15 @@
+/*
+ * Interface for HDMI DRM  codec
+ *
+ * Author: Arnaud Pouliquen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __HDMI_DRM__H__
+#define __HDMI_DRM__H__
+
+#define HDMI_DRM_CODEC_DRV_NAME "hdmi-drm-audio-codec"
+
+#endif
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 395ef5d..fe5b0c8 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -80,6 +80,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MC13783 if MFD_MC13XXX
select SND_SOC_ML26124 if I2C
select SND_SOC_HDMI_CODEC
+   select SND_SOC_HDMI_DRM_CODEC
select SND_SOC_PCM1681 if I2C
select SND_SOC_PCM1792A if SPI_MASTER
select SND_SOC_PCM3008
@@ -445,9 +446,10 @@ config SND_SOC_DMIC
 config SND_SOC_HDMI_CODEC
tristate "HDMI stub CODEC"

-   tristate
-   select SND_PCM_ELD
-   select SND_PCM_IEC958
+config SND_SOC_HDMI_DRM_CODEC
+   tristate "HDMI DRM CODEC"
+   select SND_PCM_ELD
+   select SND_PCM_IEC958

 config SND_SOC_ES8328
tristate "Everest Semi ES8328 CODEC"
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index f683b33..41b2dcb 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -73,6 +73,7 @@ snd-soc-max9850-objs := max9850.o
 snd-soc-mc13783-objs := mc13783.o
 snd-soc-ml26124-objs := ml26124.o
 snd-soc-hdmi-codec-objs := hdmi-codec.o
+snd-soc-hdmi-drm-codec-objs := hdmi_drm.o
 snd-soc-pcm1681-objs := pcm1681.o
 snd-soc-pcm1792a-codec-objs := pcm1792a.o
 snd-soc-pcm3008-objs := pcm3008.o
@@ -265,6 +266,7 @@ obj-$(CONFIG_SND_SOC_MAX9850)   += snd-soc-max9850.o
 obj-$(CONFIG_SND_SOC_MC13783)  += snd-soc-mc13783.o
 obj-$(CONFIG_SND_SOC_ML26124)  += snd-soc-ml26124.o
 obj-$(CONFIG_SND_SOC_HDMI_CODEC) += snd-soc-hdmi-codec.o
+obj-$(CONFIG_SND_SOC_HDMI_DRM_CODEC) += snd-soc-hdmi-drm-codec.o
 obj-$(CONFIG_SND_SOC_PCM1681)  += snd-soc-pcm1681.o
 obj-$(CONFIG_SND_SOC_PCM1792A) += snd-soc-pcm1792a-codec.o
 obj-$(CONFIG_SND_SOC_PCM3008)  += snd-soc-pcm3008.o
diff --git a/sound/soc/codecs/hdmi_drm.c b/sound/soc/codecs/hdmi_drm.c
new file mode 100644
index 000..1176d3b
--- /dev/null
+++ b/sound/soc/codecs/hdmi_drm.c
@@ -0,0 +1,358 @@
+/*
+ * ALSA SoC codec driver for DRM HDMI device.
+ * Copyright (C) STMicroelectronics SA 2015
+ * Authors: Arnaud Pouliquen 
+ *  for STMicroelectronics.
+ * Inspirate from hdmi-codec (Jyri Sarha )
+
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct hdmi_drm_dai_data {
+   struct drm_bridge *bridge;
+   struct hdmi_audio_mode mode;
+   struct drm_audio_bridge_cfg cfg;
+   enum {
+   HDMI_DRM_I2S,
+   HDMI_DRM_SPDIF
+   } hai;
+};
+
+static const struct snd_soc_dapm_widget hdmi_drm_widgets[] = {
+   SND_SOC_DAPM_OUTPUT("TX"),
+};
+
+static const struct snd_soc_dapm_route hdmi_drm_routes[] = {
+   { "TX", NULL, "Playback" },
+};
+
+int hdmi_drm_dai_startup(struct snd_pcm_substream *substream,
+struct snd_soc_dai *dai)
+{
+   struct hdmi_drm_dai_data *priv = snd_soc_dai_get_drvdata(dai);
+   uint8_t *eld;
+
+   dev_dbg(dai->dev, "%s: enter for bridge %p\n", __func__, priv->bridge);
+
+   eld = drm_audio_bridge_mode_get(priv->bridge);
+   if (!eld)
+   return 0;
+
+   return snd_pcm_hw_constraint_eld(substream->runtime, eld);
+}
+
+static void hdmi_drm_dai_shutdown(struct snd_pcm_substream *substream,
+  struct snd_soc_dai *dai)
+{
+   struct hdmi_drm_dai_data *priv = snd_soc_dai_get_drvdata(dai);
+
+   drm_audio_bridge_post_disable(priv->bridge);
+}
+
+static int hdmi_drm_dai_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+   struct hdmi_drm_dai_data *priv = snd_soc_dai_get_drvdata(dai);
+   struct hdmi_audio_infoframe *iframe = >mode.infoframe;
+   unsigned char *iec = priv->mode.iec_status;
+   struct drm_audio_bridge_cfg *cfg = >cfg;
+   int ret;
+
+  

[PATCH RFC V2 2/5] drm: add helper functions to add audio capabilities for bridge

[Arnaud Pouliquen]

Extend bridge capabilities for audio to enable to connect an audio driver to a
DRM driver with audio capabilities

Signed-off-by: Arnaud Pouliquen 
---
 drivers/gpu/drm/drm_bridge.c | 137 ++-
 include/drm/drm_crtc.h   |  62 
 include/drm/drm_modes.h  |  12 
 3 files changed, 210 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 6b8f721..d1a437e 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -194,7 +194,7 @@ EXPORT_SYMBOL(drm_bridge_mode_fixup);
  * chain, starting from the last bridge to the first. These are called before
  * calling the encoder's prepare op.
  *
- * Note: the bridge passed should be the one closest to the encoder
+ * Note: the bridge passed should be the othingsne closest to the encoder
  */
 void drm_bridge_disable(struct drm_bridge *bridge)
 {
@@ -328,6 +328,141 @@ struct drm_bridge *of_drm_find_bridge(struct device_node 
*np)
 EXPORT_SYMBOL(of_drm_find_bridge);
 #endif

+/**
+ * DOC: audio bridge callbacks
+ *
+ * The drm_audio_bridge_funcs ops are populated by the bridge driver that has
+ * audio capabilities (e.g. HDMI)
+ * The alsa driver (or asoc codec) uses the defined helpers.
+ * These helpers call a specific drm_audio_bridge_funcs ops defined by
+ * bridges with audio capabilities during encoder configuration.
+ *
+ * pre_enable: this contains actions needed to be done by the bridge before
+ * audio is enabled by its source.
+ *
+ * enable: this contains actions needed to be done by the audio bridge once its
+ * source is enabled. In other words, enable is called once the source is
+ * ready to start stream rendering.
+ *
+ * disable: this contains actions needed to be done by audio bridge when
+ * disable the audio part, assuming that its source is still enabled.
+ *
+ * post_disable: this contains actions needed to be done by the bridge once
+ * its source is disabled.
+ *
+ * mode_set: this sets up the mode by the audio bridge. It assumes that its
+ * audio source is aligned on this mode.
+ *
+ * mode_get: this get the supported modes based on ELD table. this can be use
+ * by audio source to fix audio constraints according to mode.
+ */
+
+/**
+ * drm_audio_bridge_pre_enable - calls 'pre_enable' drm_audio_bridge_funcs op
+ * for audio bridge in the encoder chain.
+ * @bridge: bridge control structure
+ */
+int drm_audio_bridge_pre_enable(struct drm_bridge *bridge,
+struct drm_audio_bridge_cfg *cfg)
+{
+   if (!bridge)
+   return -EINVAL;
+
+   if (bridge->audio_funcs->pre_enable)
+   return bridge->audio_funcs->pre_enable(bridge, cfg);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_audio_bridge_pre_enable);
+
+/**
+ * drm_audio_bridge_disable - calls 'disable' drm_audio_bridge_funcs op
+ * for audio bridge in the encoder chain.
+ * @bridge: bridge control structure
+ */
+int drm_audio_bridge_disable(struct drm_bridge *bridge)
+{
+   if (!bridge)
+   return -EINVAL;
+
+   if (bridge->audio_funcs->disable)
+   return bridge->audio_funcs->disable(bridge);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_audio_bridge_disable);
+
+/**
+ * drm_audio_bridge_enable - calls 'enable' drm_audio_bridge_funcs audio
+ * bridge in the encoder chain.
+ * @bridge: bridge control structure
+ */
+int drm_audio_bridge_enable(struct drm_bridge *bridge)
+{
+   if (!bridge)
+   return -EINVAL;
+
+   if (bridge->audio_funcs->enable)
+   return bridge->audio_funcs->enable(bridge);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_audio_bridge_enable);
+
+/**
+ * drm_audio_bridge_post_disable - calls 'disable' drm_audio_bridge_funcs op
+ * for audio bridge in the encoder chain.
+ * @bridge: bridge control structure
+ */
+int drm_audio_bridge_post_disable(struct drm_bridge *bridge)
+{
+   if (!bridge)
+   return -EINVAL;
+
+   if (bridge->audio_funcs->post_disable)
+   return bridge->audio_funcs->post_disable(bridge);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_audio_bridge_post_disable);
+
+/**
+ * drm_audio_bridge_mode_set - calls 'mode_set' drm_audio_bridge_funcs op
+ * for audio bridge in the encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired audio mode to be set for the audio bridge
+ */
+int drm_audio_bridge_mode_set(struct drm_bridge *bridge,
+  struct hdmi_audio_mode *mode)
+{
+   if (!bridge)
+   return -EINVAL;
+
+   if (bridge->audio_funcs->mode_set)
+   return bridge->audio_funcs->mode_set(bridge, mode);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_audio_bridge_mode_set);
+
+/**
+ * drm_audio_bridge_mode_get - calls 'enable'drm_audio_bridge_funcs op
+ * for audio bridge in the encoder chain.
+ * @bridge: bridge control structure
+ * Note: The returned pointer needs to be freed using kfree().
+ */
+uint8_t 

[PATCH RFC V2 1/5] video: hdmi: add helper function for N and CTS

[Arnaud Pouliquen]

Add helper function to compute HDMI CTS and N parameters
Implementation is based on HDMI 1.4b specification.

Signed-off-by: Arnaud Pouliquen 
Cc: linux-fbdev at vger.kernel.org
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
---
 drivers/video/hdmi.c | 147 +++
 include/linux/hdmi.h |  12 +
 2 files changed, 159 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..93e2fdf 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1242,3 +1242,150 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame, 
void *buffer)
return ret;
 }
 EXPORT_SYMBOL(hdmi_infoframe_unpack);
+
+/**
+ * audio clock regeneration (acr) parameters
+ * N and CTS computation are based on HDMI specification 1.4b
+ */
+enum audio_rate {
+   HDMI_AUDIO_N_CTS_32KHZ,
+   HDMI_AUDIO_N_CTS_44_1KHZ,
+   HDMI_AUDIO_N_CTS_48KHZ,
+};
+
+struct hdmi_audio_acr {
+   unsigned long pixel_clk;
+   struct hdmi_audio_n_cts n_cts;
+};
+
+static const struct hdmi_audio_acr hdmi_audio_standard_acr[3][12] = {
+   { /*32 kHz*/
+   {  25175, {  4576,  28125 } }, /* 25,20/1.001  MHz */
+   {  25200, {  4096,  25200 } }, /* 25.20MHz */
+   {  27000, {  4096,  27000 } }, /* 27.00MHz */
+   {  27027, {  4096,  27027 } }, /* 27.00*1.001  MHz */
+   {  54000, {  4096,  54000 } }, /* 54.00MHz */
+   {  54054, {  4096,  54054 } }, /* 54.00*1.001  MHz */
+   {  74176, { 11648, 310938 } }, /* 74.25/1.001  MHz */
+   {  74250, {  4096,  74250 } }, /* 74.25MHz */
+   { 148352, { 11648, 421875 } }, /* 148.50/1.001 MHz */
+   { 148500, {  4096, 148500 } }, /* 148.50   MHz */
+   { 296703, {  5824, 421875 } }, /* 297/1.001MHz */
+   { 297000, {  3072, 222750 } }, /* 297  MHz */
+   },
+   { /*44.1 kHz, 88.2 kHz  176.4 kHz*/
+   {  25175, {  7007,  31250 } }, /* 25,20/1.001  MHz */
+   {  25200, {  6272,  28000 } }, /* 25.20MHz */
+   {  27000, {  6272,  3 } }, /* 27.00MHz */
+   {  27027, {  6272,  30030 } }, /* 27.00*1.001  MHz */
+   {  54000, {  6272,  6 } }, /* 54.00MHz */
+   {  54054, {  6272,  60060 } }, /* 54.00*1.001  MHz */
+   {  74176, { 17836, 234375 } }, /* 74.25/1.001  MHz */
+   {  74250, {  6272,  82500 } }, /* 74.25MHz */
+   { 148352, {  8918, 234375 } }, /* 148.50/1.001 MHz */
+   { 148500, {  6272, 165000 } }, /* 148.50   MHz */
+   { 296703, {  4459, 234375 } }, /* 297/1.001MHz */
+   { 297000, {  4704, 247500 } }, /* 297  MHz */
+   },
+   { /*48 kHz, 96 kHz  192 kHz*/
+   {  25175, {  6864,  28125 } }, /* 25,20/1.001  MHz */
+   {  25200, {  6144,  25200 } }, /* 25.20MHz */
+   {  27000, {  6144,  27000 } }, /* 27.00MHz */
+   {  27027, {  6144,  27027 } }, /* 27.00*1.001  MHz */
+   {  54000, {  6144,  54000 } }, /* 54.00MHz */
+   {  54054, {  6144,  54054 } }, /* 54.00*1.001  MHz */
+   {  74176, { 11648, 140625 } }, /* 74.25/1.001  MHz */
+   {  74250, {  6144,  74250 } }, /* 74.25MHz */
+   { 148352, {  5824, 140625 } }, /* 148.50/1.001 MHz */
+   { 148500, {  6144, 148500 } }, /* 148.50   MHz */
+   { 296703, {  5824, 281250 } }, /* 297/1.001MHz */
+   { 297000, {  5120, 247500 } }, /* 297  MHz */
+   }
+};
+
+/**
+ * hdmi_compute_n_cts() - compute N and CTS parameters
+ * @audio_fs: audio frame clock frequency in KHz
+ * @pixel_clk: pixel cloack frequency in kHz
+ * @n_cts: N and CTS parameter returned to user
+ *
+ * Values computed are based on table described in HDMI specification 1.4b
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_audio_compute_n_cts(enum hdmi_audio_sample_frequency audio_fs,
+unsigned long pixel_clk,
+struct hdmi_audio_n_cts *n_cts)
+{
+   int audio_freq_id, i;
+   int ratio = 1;
+   const struct hdmi_audio_acr  *acr_table;
+   const struct hdmi_audio_n_cts *predef_n_cts = NULL;
+
+   switch (audio_fs) {
+   case HDMI_AUDIO_SAMPLE_FREQUENCY_32000:
+   audio_freq_id = HDMI_AUDIO_N_CTS_32KHZ;
+   n_cts->n = 4096;
+   break;
+
+   case HDMI_AUDIO_SAMPLE_FREQUENCY_44100:
+   audio_freq_id = HDMI_AUDIO_N_CTS_44_1KHZ;
+   n_cts->n = 6272;
+   break;
+
+   case HDMI_AUDIO_SAMPLE_FREQUENCY_48000:
+   audio_freq_id = HDMI_AUDIO_N_CTS_48KHZ;
+   n_cts->n = 6144;
+   break;
+
+   

[PATCH RFC V2 0/5] another generic audio hdmi codec proposal

[Arnaud Pouliquen]

Version 2:
This version integrates missing features upgraded to be aligned when possible 
with patch set:
[PATCH RFC v4 0/8] Implement generic ASoC HDMI codec and use it in tda998x

It does not support the abort callback, the mute and syclk ops. 
This could be added in V3 or separate patch if justified.  

  [RFC 1/5]video: hdmi: add help function for N and CTS
- Replace real frequency value by enum in switch case
Notice that this patch is independant from the rest of the implentation
  [RFC 2/5]drm: add helper functions to add audio capabilities for bridge
- extend audio bridge ops
  [RFC 3/5]ASoC: codec:  hdmi drm codec driver
aligned when possible with hdmi-codec.c implementation
. ELD management for alsa contraints
. Support of SPDIF and I2S mode
. hwparam ond set_fmt functions implemented
  [RFC 4/5]drm: sti: connect audio driver
=> Implementation for STI platform
  [RFC 5/5]DT: sti: add audio HDMI dai link in audio card
=> Devicetree example

Version 1:

This patch set is a tentative to implement a generic code for the HDMI audio.
Main concept are aligned with solution proposeded for TI platform. 
 -  ASoC codec driver registered by DRM driver
 -  ASOC driver is a generic driver.
 -  compatible with simple card

 Difference is that i propose a DRM generic interface based on bridge structure.
 Advantage is that all data exchanges are done through the DRM API.

 I think also that some helper functions could been used for N and CTS 
parameters calculation,
 as suggested by Russell King in a previous mail.

 I full aware that some features (like ELD and info frame) are partially or not 
implemented in my patches. 
 This patch set is more a skeleton than a full implementation...
 I just post it to suggest a possible DRM API.

Arnaud Pouliquen (5):
  video: hdmi: add helper function for N and CTS
  drm: add helper function to add audio capabilities for bridge
  ASoC: codec:  hdmi drm codec driver
  drm: sti: connect audio driver
  DT: sti: add audio HDMI dai link in audio card

 arch/arm/boot/dts/stih410.dtsi   |   6 +-
 arch/arm/boot/dts/stihxxx-b2120.dtsi |  21 ++
 drivers/gpu/drm/drm_bridge.c | 137 +-
 drivers/gpu/drm/sti/sti_hdmi.c   | 184 --
 drivers/gpu/drm/sti/sti_hdmi.h   |   3 +
 drivers/video/hdmi.c | 147 ++
 include/drm/drm_crtc.h   |  62 ++
 include/drm/drm_modes.h  |  12 ++
 include/linux/hdmi.h |  12 ++
 include/sound/hdmi_drm.h |  15 ++
 sound/soc/codecs/Kconfig |   8 +-
 sound/soc/codecs/Makefile|   2 +
 sound/soc/codecs/hdmi_drm.c  | 358 +++
 13 files changed, 951 insertions(+), 16 deletions(-)
 create mode 100644 include/sound/hdmi_drm.h
 create mode 100644 sound/soc/codecs/hdmi_drm.c

-- 
1.9.1

[PATCH 1/2] drm: Stop using drm_vblank_count() as the hw frame counter

[Ville Syrjälä]

On Thu, Oct 01, 2015 at 06:44:22PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 01, 2015 at 11:25:36AM -0400, Rob Clark wrote:
> > On Wed, Sep 30, 2015 at 10:14 AM, Ville Syrjälä
> >  wrote:
> > > On Wed, Sep 30, 2015 at 04:08:02PM +0200, Daniel Vetter wrote:
> > >> On Wed, Sep 30, 2015 at 04:46:48PM +0300, ville.syrjala at 
> > >> linux.intel.com wrote:
> > >> > From: Ville Syrjälä 
> > >> >
> > >> > drm_vblank_count() returns the software counter. We should not pretend
> > >> > it's the hw counter since we use the hw counter to figuere out what the
> > >> > software counter value should be. So instead provide a new function
> > >> > drm_vblank_no_hw_counter() for drivers that don't have a real hw
> > >> > counter. The new function simply returns 0, which is about the only
> > >> > thing it can do.
> > >>
> > >> Shouldn't we instead just make the get_vblank_counter hook optional?
> > >
> > > Perhaps. But maybe this way would encourage people to go look for a
> > > hw frame counter in their hardware?
> > 
> > Well, I guess at this point we have more drm/kms drivers for hw
> > without hw frame counters..  maybe a helper that guestimates based on
> > time elapsed since last vbl irq would be useful..
> 
> That's already being done for the sw counter.

... assuming you have accurate vbl timestamps that is.

> 
> > 
> > BR,
> > -R
> > 
> > >> -Daniel
> > >>
> > >> >
> > >> > Cc: Vincent Abriou 
> > >> > Cc: Thierry Reding 
> > >> > Signed-off-by: Ville Syrjälä 
> > >> > ---
> > >> >  drivers/gpu/drm/armada/armada_drv.c  |  2 +-
> > >> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
> > >> >  drivers/gpu/drm/drm_irq.c| 17 +
> > >> >  drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
> > >> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c|  2 +-
> > >> >  drivers/gpu/drm/imx/imx-drm-core.c   |  2 +-
> > >> >  drivers/gpu/drm/msm/msm_drv.c|  2 +-
> > >> >  drivers/gpu/drm/nouveau/nouveau_drm.c|  2 +-
> > >> >  drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
> > >> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c|  2 +-
> > >> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |  2 +-
> > >> >  drivers/gpu/drm/shmobile/shmob_drm_drv.c |  2 +-
> > >> >  drivers/gpu/drm/sti/sti_drv.c|  2 +-
> > >> >  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
> > >> >  include/drm/drmP.h   |  1 +
> > >> >  15 files changed, 31 insertions(+), 13 deletions(-)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> > >> > b/drivers/gpu/drm/armada/armada_drv.c
> > >> > index 225034b..464a13f 100644
> > >> > --- a/drivers/gpu/drm/armada/armada_drv.c
> > >> > +++ b/drivers/gpu/drm/armada/armada_drv.c
> > >> > @@ -300,7 +300,7 @@ static struct drm_driver armada_drm_driver = {
> > >> > .lastclose  = armada_drm_lastclose,
> > >> > .unload = armada_drm_unload,
> > >> > .set_busid  = drm_platform_set_busid,
> > >> > -   .get_vblank_counter = drm_vblank_count,
> > >> > +   .get_vblank_counter = drm_vblank_no_hw_counter,
> > >> > .enable_vblank  = armada_drm_enable_vblank,
> > >> > .disable_vblank = armada_drm_disable_vblank,
> > >> >  #ifdef CONFIG_DEBUG_FS
> > >> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> > >> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > >> > index 8bc62ec..2eb1c66 100644
> > >> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > >> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > >> > @@ -697,7 +697,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
> > >> > .irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
> > >> > .irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
> > >> > .irq_uninstall = atmel_hlcdc_dc_irq_uninstall,
> > >> > -   .get_vblank_counter = drm_vblank_count,
> > >> > +   .get_vblank_counter = drm_vblank_no_hw_counter,
> > >> > .enable_vblank = atmel_hlcdc_dc_enable_vblank,
> > >> > .disable_vblank = atmel_hlcdc_dc_disable_vblank,
> > >> > .gem_free_object = drm_gem_cma_free_object,
> > >> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > >> > index ed2394e..7d70b7c 100644
> > >> > --- a/drivers/gpu/drm/drm_irq.c
> > >> > +++ b/drivers/gpu/drm/drm_irq.c
> > >> > @@ -1797,3 +1797,20 @@ bool drm_crtc_handle_vblank(struct drm_crtc 
> > >> > *crtc)
> > >> > return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
> > >> >  }
> > >> >  EXPORT_SYMBOL(drm_crtc_handle_vblank);
> > >> > +
> > >> > +/**
> > >> > + * drm_vblank_no_hw_counter - "No hw counter" implementation of 
> > >> > .get_vblank_counter()
> > >> > + * @dev: DRM device
> > >> > + * @pipe: CRTC for which to read the counter
> > >> > + *
> > >> > + * Drivers can plug this into the .get_vblank_counter() function if
> > >> > + * there is no useable hardware frame counter available.
> > >> > + *
> > >> > + * Returns:
> > 

[PATCH 1/2] drm: Stop using drm_vblank_count() as the hw frame counter

[Ville Syrjälä]

On Thu, Oct 01, 2015 at 11:25:36AM -0400, Rob Clark wrote:
> On Wed, Sep 30, 2015 at 10:14 AM, Ville Syrjälä
>  wrote:
> > On Wed, Sep 30, 2015 at 04:08:02PM +0200, Daniel Vetter wrote:
> >> On Wed, Sep 30, 2015 at 04:46:48PM +0300, ville.syrjala at linux.intel.com 
> >> wrote:
> >> > From: Ville Syrjälä 
> >> >
> >> > drm_vblank_count() returns the software counter. We should not pretend
> >> > it's the hw counter since we use the hw counter to figuere out what the
> >> > software counter value should be. So instead provide a new function
> >> > drm_vblank_no_hw_counter() for drivers that don't have a real hw
> >> > counter. The new function simply returns 0, which is about the only
> >> > thing it can do.
> >>
> >> Shouldn't we instead just make the get_vblank_counter hook optional?
> >
> > Perhaps. But maybe this way would encourage people to go look for a
> > hw frame counter in their hardware?
> 
> Well, I guess at this point we have more drm/kms drivers for hw
> without hw frame counters..  maybe a helper that guestimates based on
> time elapsed since last vbl irq would be useful..

That's already being done for the sw counter.

> 
> BR,
> -R
> 
> >> -Daniel
> >>
> >> >
> >> > Cc: Vincent Abriou 
> >> > Cc: Thierry Reding 
> >> > Signed-off-by: Ville Syrjälä 
> >> > ---
> >> >  drivers/gpu/drm/armada/armada_drv.c  |  2 +-
> >> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
> >> >  drivers/gpu/drm/drm_irq.c| 17 +
> >> >  drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
> >> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c|  2 +-
> >> >  drivers/gpu/drm/imx/imx-drm-core.c   |  2 +-
> >> >  drivers/gpu/drm/msm/msm_drv.c|  2 +-
> >> >  drivers/gpu/drm/nouveau/nouveau_drm.c|  2 +-
> >> >  drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
> >> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c|  2 +-
> >> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |  2 +-
> >> >  drivers/gpu/drm/shmobile/shmob_drm_drv.c |  2 +-
> >> >  drivers/gpu/drm/sti/sti_drv.c|  2 +-
> >> >  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
> >> >  include/drm/drmP.h   |  1 +
> >> >  15 files changed, 31 insertions(+), 13 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> >> > b/drivers/gpu/drm/armada/armada_drv.c
> >> > index 225034b..464a13f 100644
> >> > --- a/drivers/gpu/drm/armada/armada_drv.c
> >> > +++ b/drivers/gpu/drm/armada/armada_drv.c
> >> > @@ -300,7 +300,7 @@ static struct drm_driver armada_drm_driver = {
> >> > .lastclose  = armada_drm_lastclose,
> >> > .unload = armada_drm_unload,
> >> > .set_busid  = drm_platform_set_busid,
> >> > -   .get_vblank_counter = drm_vblank_count,
> >> > +   .get_vblank_counter = drm_vblank_no_hw_counter,
> >> > .enable_vblank  = armada_drm_enable_vblank,
> >> > .disable_vblank = armada_drm_disable_vblank,
> >> >  #ifdef CONFIG_DEBUG_FS
> >> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> >> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> > index 8bc62ec..2eb1c66 100644
> >> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> > @@ -697,7 +697,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
> >> > .irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
> >> > .irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
> >> > .irq_uninstall = atmel_hlcdc_dc_irq_uninstall,
> >> > -   .get_vblank_counter = drm_vblank_count,
> >> > +   .get_vblank_counter = drm_vblank_no_hw_counter,
> >> > .enable_vblank = atmel_hlcdc_dc_enable_vblank,
> >> > .disable_vblank = atmel_hlcdc_dc_disable_vblank,
> >> > .gem_free_object = drm_gem_cma_free_object,
> >> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> >> > index ed2394e..7d70b7c 100644
> >> > --- a/drivers/gpu/drm/drm_irq.c
> >> > +++ b/drivers/gpu/drm/drm_irq.c
> >> > @@ -1797,3 +1797,20 @@ bool drm_crtc_handle_vblank(struct drm_crtc *crtc)
> >> > return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
> >> >  }
> >> >  EXPORT_SYMBOL(drm_crtc_handle_vblank);
> >> > +
> >> > +/**
> >> > + * drm_vblank_no_hw_counter - "No hw counter" implementation of 
> >> > .get_vblank_counter()
> >> > + * @dev: DRM device
> >> > + * @pipe: CRTC for which to read the counter
> >> > + *
> >> > + * Drivers can plug this into the .get_vblank_counter() function if
> >> > + * there is no useable hardware frame counter available.
> >> > + *
> >> > + * Returns:
> >> > + * 0
> >> > + */
> >> > +u32 drm_vblank_no_hw_counter(struct drm_device *dev, int pipe)
> >> > +{
> >> > +   return 0;
> >> > +}
> >> > +EXPORT_SYMBOL(drm_vblank_no_hw_counter);
> >> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> >> > b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> > index f0a5839..fb9cfc5 100644
> >> > 

[Bug 92214] Flightgear crashes during splashboot with R600 driver and mesa 11.0.2

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

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

--- Comment #6 from Barto  ---
Created attachment 118575
  --> https://bugs.freedesktop.org/attachment.cgi?id=118575=edit
new backtrace with a debug version of mesa 11.0.2

new backtrace with a debug version of mesa 11.0.2

-- 
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/20151001/d11a2aea/attachment.html>

[PATCH] drm/nouveau: fix memory leak

[Sudip Mukherjee]

On Thu, Oct 01, 2015 at 04:40:59PM +1000, Ben Skeggs wrote:
> On 09/25/2015 01:59 AM, Sudip Mukherjee wrote:
> > On Fri, Sep 11, 2015 at 03:00:56PM +0530, Sudip Mukherjee wrote:
> >> If pm_runtime_get_sync() we were going to "out" but we missed
> >> freeing vma.
> >> 
> >> Signed-off-by: Sudip Mukherjee  ---
> > Hi Ben, Another gentle ping for another patch.
> Both patches are in my tree.

Thanks Ben.

regards
sudip

[PATCH v1.1 03/15] vga_switcheroo: Set active attribute to false for audio clients

[Lukas Wunner]

Hi Daniel,

On Thu, Sep 24, 2015 at 05:13:02PM +0200, Daniel Vetter wrote:
> I added your clarification to the commit message and pulled in the patch.

As requested, here's an on-list gentle reminder that a portion of
this series hasn't been merged yet, specifically:

[PATCH 04/15] vga_switcheroo: Add missing locking
[PATCH 05/15] vga_switcheroo: Drop client power state
[PATCH 06/15] vga_switcheroo: Use enum vga_switcheroo_state instead
[PATCH 07/15] vga_switcheroo: Use VGA_SWITCHEROO_UNKNOWN_ID instead
[PATCH 08/15] vga_switcheroo: Use enum vga_switcheroo_client_id
[PATCH 10/15] ALSA: hda - Spell vga_switcheroo consistently
[PATCH 12/15] drm/nouveau: Spell vga_switcheroo consistently

In the case of patch 10, Takashi Iwai has suggested off-list that it be
merged through drm-misc and has kindly offered his
Reviewed-by: Takashi Iwai 

In the case of patch 12, I guess it may be merged through darktama's repo.

The patches were submitted to dri-devel September 17 and are also
available on GitHub for easier reviewing:
https://github.com/l1k/linux/commits/vga_switcheroo_docs

If anyone has comments or objections please come forward.

Thank you,

Lukas

[Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Vincent ABRIOU]

On 09/22/2015 05:21 PM, Tvrtko Ursulin wrote:
>
> On 09/22/2015 03:53 PM, David Herrmann wrote:
>> Hi
>>
>> On Thu, Sep 10, 2015 at 12:15 PM, Tvrtko Ursulin
>>  wrote:
>>> On 09/10/2015 10:56 AM, Daniel Vetter wrote:
 That's not different from the compositor just freezing instead of
 crashing: Screen contents stays on and nothing happens. Imo this really is
 all just broken userspace, and the kernel can't make sure userspace
 doesn't randomly fall over.

 What we need to make sure is that assuming things work ok-ish there's no
 observed regression. And I still think that's the case here.
>>>
>>>
>>> I would disagree on the no regressions when things work okay-ish principle,
>>> there should be no regressions in the pessimistic scenario when security is
>>> concerned.
>>>
>>> If we can agree the stuck frame on screen is not desirable from the security
>>> point of view, then this change does enlarge the attack surface.
>>>
>>> Because, apart from freezing the compositor, it now also works to crash it
>>> and prevent restart. Maybe it is far fetched, but as I said, attackers have
>>> much better imagination with these things.
>>
>> I'd much more prefer a FB flag that forces a modeset on ID removal.
>> Anyone who cares for it can set it, and the kernel will make sure to
>> never keep such FBs around. However, for most use-cases, we want the
>> FB to stay around after close() or FB removal.
>>
>> Btw., I also don't see the attack scenario at all. If an attacker
>> makes your compositor crash at the same moment a security-relevant
>> information is shown on screen, then the information is already
>> visible. Who cares that it stays visible? Sure, I can make up an
>> hypothetical use-case where that matters, but I cannot think of
>> something real.
>> Also, if the hypothetical scenario we go for is "if the compositor
>> crashes", then I guess there's bigger problems than the FB content.
>
> It allows losing control of the sensitive information in a new way and
> so by definition results in a less secure system.
>
> Apparently for the goal of less flicker and easier userspace
> programming. Ie. avoiding the need for a back channel, apart from the
> fact back channel has now just been moved to the kernel.
>
> I would recommend passing this by some more security conscious eyes.
>

I made some test using weston and modetest.

When testing planes, and switching from weston to modetest, the plane 
activated with modetest is then displayed in weston and vice-versa. We 
can overcome this by updating the middleware (I only test it with 
modetest for now) to force them to properly disable the CRTC and plane 
when closed properly (I don't speak about crash). The middlewares only 
relies on drmModeRmFB to close CRTC or planes. But with this patch it 
will break the habits.
Think is will be better to update the middlewares before going futher in 
that patch direction.

Regards
Vincent

[PATCH 6/6] drm/msm: add OCMEM driver

[Stephen Boyd]

On 10/01, Rob Clark wrote:
> On Thu, Oct 1, 2015 at 3:25 PM, Rob Clark  wrote:
> > On Thu, Oct 1, 2015 at 2:00 PM, Stephen Boyd  
> > wrote:
> >>
> >> The simplest thing to do is to split the memory between GPU and
> >> vidc statically. The other use cases with preemption and eviction
> >> and DMA add a lot of complexity that we can explore at a later
> >> time if need be.
> >
> > true, as long as one of the clients is the static gpu client, I guess
> > we could reasonably easily support up to two clients reasonably
> > easily...
> 
> btw, random thought..  drm_mm is a utility in drm that serves a
> similar function to genalloc for graphics drivers to manage their
> address space(s) (used for everything from mmap virtual address space
> of buffers allocated against device to managing vram and gart
> allocations, etc... when vram carveout is used w/ drm/msm (due to no
> iommu) I use it to manage allocations from the carveout).  It has some
> potentially convenient twists, like supporting allocation from top of
> the "address space" instead of bottom.  I'm thinking in particular of
> allocating "narrow mode" allocations from top and "wide mode" from
> bottom since wide vs narrow can only be set per region and not per
> macro within the region.  (It can also search by first-fit or
> best-fit.. although not sure if that is useful to us, since OCMEM size
> is relatively constrained.)
> 
> Not that I really want to keep ocmem allocator in drm.. I'd really
> rather it be someone else's headache once it gets to implementing the
> crazy stuff for all the random use-cases of other OCMEM users, since
> gpu's use of OCMEM is rather simple/static..
> 
> The way downstream driver does this is with a bunch of extra
> bookkeeping on top of genalloc so it can do a dummy allocation to
> force "from the top" allocation (and then immediately freeing the
> dummy allocation)..  Maybe it just makes sense to teach genalloc how
> to do from-top vs from-bottom allocations?  Not really sure..
> 

It looks like video and GPU both use wide mode, if I'm reading
the code correctly. So it seems that we don't need to do anything
special for allocations, just hand the GPU and vidc a chunk of
the memory in wide mode and then let the GPU and vidc drivers
manage buffers within their chunk however they see fit.

One pitfall is going to be power management. ocmem is closely
tied to the GPU power domains, so when video is using its chunk
of memory we're going to need to keep ocmem powered up even if
the GPU is off. I suppose for now we can just leave it always
powered on once the driver probes, but if we ever want to turn it
off we're going to need some tracking mechanism to make sure we
don't turn it off when buffers are in use.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[Bug 92214] Flightgear crashes during splashboot with R600 driver and mesa 11.0.2

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

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

--- Comment #5 from Barto  ---
(In reply to Emil Velikov from comment #4)

> Works like a charm here ;-) I always double-check that things aren't stuffed
> before making a release.
> 
> Can you rebuild the package with debug info [1] and provide another
> backtrace ?


this is strange, because each time I use "export LIBGL_ALWAYS_SOFTWARE=1" I get
a crash in openGL application, for example with "glxgears" :

$ export LIBGL_ALWAYS_SOFTWARE=1
$ glxgears
Illegal instruction (core dumped)

maybe the bug occurs only with r600 driver,

I will try to rebuild mesa package with debug info and I will post a new
backtrace

-- 
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/20151001/f580d7b7/attachment.html>

[Bug 92214] Flightgear crashes during splashboot with R600 driver and mesa 11.0.2

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

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

--- Comment #4 from Emil Velikov  ---
(In reply to Barto from comment #2)
> I notice that "export LIBGL_ALWAYS_SOFTWARE=1" triggers always a crash on
> every openGL if I use it ( opengl software emulation ),
> 
> why "export LIBGL_ALWAYS_SOFTWARE=1" doesn't work with mesa 11 ?

Works like a charm here ;-) I always double-check that things aren't stuffed
before making a release.

Can you rebuild the package with debug info [1] and provide another backtrace ?

-Emil
P.S. Not a radeon dev, but a fellow archer :)

[1] https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces#PKGBUILD

-- 
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/20151001/c7369b42/attachment.html>

[Bug 92214] Flightgear crashes during splashboot with R600 driver and mesa 11.0.2

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

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

--- Comment #3 from Barto  ---
Created attachment 118571
  --> https://bugs.freedesktop.org/attachment.cgi?id=118571=edit
apitrace when the bug occurs

here is an apitrace when the bug occurs

-- 
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/20151001/ca557326/attachment.html>

[Bug 92214] Flightgear crashes during splashboot with R600 driver and mesa 11.0.2

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

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

--- Comment #2 from Barto  ---
I notice that "export LIBGL_ALWAYS_SOFTWARE=1" triggers always a crash on every
openGL if I use it ( opengl software emulation ),

why "export LIBGL_ALWAYS_SOFTWARE=1" doesn't work with mesa 11 ?

-- 
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/20151001/19552f1e/attachment.html>

[Bug 92214] Flightgear crashes during splashboot with R600 driver and mesa 11.0.2

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

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

--- Comment #1 from Barto  ---
Created attachment 118567
  --> https://bugs.freedesktop.org/attachment.cgi?id=118567=edit
glxinfo

the output of glxinfo

-- 
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/20151001/f73efbd7/attachment.html>

[Bug 92214] Flightgear crashes during splashboot with R600 driver and mesa 11.0.2

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

335
No locals.
#4  0x00725fef in fgMainInit (argc=16, argv=)
at
/home/cesar/compilation/pkg/flightgear3.4/src/flightgear-3.4.0/src/Main/main.cxx:519
version = "3.4.0"
col = 
configResult = 
showLauncher = 
result = 
#5  0x006d48aa in main (argc=16, argv=0x7fffe3a8)
at
/home/cesar/compilation/pkg/flightgear3.4/src/flightgear-3.4.0/src/Main/bootstrap.cxx:234
_hostname = "ultima-dbr\000\000\000\000\000\000[\000\000\000n", '\000'
,
"w\000\000\000|\000\000\000pF\270\363\377\177\000\000В\217\001\000\000\000\000\200qG\001\000\000\000\000\300qG\001\000\000\000\000\003\000\000\000\000\000\000\000Xwh\363\377\177\000\000\003\000\000\000\000\000\000\000\000{\207\063\331a+\267\020\004\000\000\000\000\000\000
 at 
qG\001\000\000\000\000yF\270\363\377\177\000\000\200qG\001\000\000\000\000\300qG\001\000\000\000\000\201\062h\363\377\177\000\000В\217\001\000\000\000\000\000{\207\063\331a+\267\200qG\001\000\000\000\000\030\002\000\000\000\000\000\000\032\002\000\000\000\000\000\000\031\002"...
fgviewer = false

-- 
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/20151001/e5890c9c/attachment-0001.html>

[PATCH] drm: Hack around CONFIG_AGP=m build failures

[Michal Marek]

On 2015-10-01 16:50, Michal Marek wrote:
> On 2015-10-01 12:17, Daniel Vetter wrote:
>> On Thu, Oct 01, 2015 at 11:58:32AM +0200, Michal Marek wrote:
>>> On 2015-10-01 10:19, Jani Nikula wrote:
 On Thu, 01 Oct 2015, Daniel Vetter  wrote:
> Surprisingly kbuild can't cope with tristates in the
> -$(CONFIG_FOO) pattern. This patch hacks up a solution.

 Given that it's two distinct Makefile variables (foo-y and foo-m) being
 assigned to, I don't really find this surprising. Maybe this could be
 made to work as a convenience, but there might be other, more surpising
 consequences.
>>>
>>> I actually think that kbuild should be able to handle this. The likely
>>> reason why it is not doing it right now is that in an ideal world,
>>> modules are modules can be built out of tree against just the kernel and
>>> their static dependencies. In real world, we sometimes have features in
>>> modules that are enabled if other modules are enabled. I'll post a patch
>>> later. We also have lots of tests fo CONFIG_FOO || CONFIG_FOO_MODULE in
>>> built-in code, which is a similar case.
>>
>> Cool. I'll keep this hack in drm-misc then. Please cc me on the proper
>> solution so I know when I can revert it again.
> 
> It's not as trivial as it seemed, because there are at least three
> Makefiles that rely on the current behavior:
> 
> init/Makefile
> drivers/misc/ibmasm/Makefile
> fs/logfs/Makefile

drivers/usb/chipidea is also on the list.

Michal

[RFC v3 0/7] MT8173 DRM support

[Daniel Kurtz]

Hi Philipp,

On Wed, Sep 30, 2015 at 11:29 PM, Philipp Zabel  
wrote:
> Hi,
>
> this is an update to the MT8173 DRM support RFC. These patches have
> a build dependency on two other patches on top of v4.3-rc1:
> https://patchwork.kernel.org/patch/6914941 ("iommu: Implement common IOMMU
> ops for DMA mapping"), and
> https://patchwork.kernel.org/patch/6928621 ("memory: mediatek: Add SMI 
> driver").
>
> I have changed the device tree bindings to group the display function blocks
> under a display-subsystem node. I'm not happy with this organisation as the
> display-subsystem node is not really a physical bus. I'd much prefer 
> connecting
> the function blocks with an of-graph, if it is acceptable for just the graph
> to cost >8 KiB dtb size.
>
> The added HDMI driver still directly accesses an undocumented register in the
> apmixedsys (clock-controller) register space to set a divider of the TVDPLL.
> That will be fixed as soon as I understand what this clock is connected to.
>
> Changes since v2:
>  - Grouped DISP function block nodes under the display-subsystem node
>  - Added of-graph ports to binding documentation
>  - Dropped legacy framebuffer support
>  - Dropped plane zpos property
>  - Update plane->disp_size in atomic_update instead of atomic_check
>  - Added asynchronous commit support
>  - Split DSI and MIPI TX (MIPI D-PHY) drivers
>  - Added DPI driver
>  - Added HDMI driver
>  - Added HDMI DDC I2C master driver
>  - Added HDMI PHY driver
>
> CK Hu (3):
>   dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
>   drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
>   drm/mediatek: Add DSI sub driver
>
> Daniel Kurtz (1):
>   drm/mediatek: Add HDMI support

Thanks for the shout-out, but I really can't take any credit for this patch :-)
Somewhere along the life of this patch its ownership changed.
It should probably be Jie Qiu as per its SOB.

>
> Jie Qiu (2):
>   drm/mediatek: Add DPI sub driver
>   drm/mediatek: enable hdmi output control bit
>
> Philipp Zabel (1):
>   dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding

Can you also include the actual mt8173.dtsi (& mt8173-evb.dts) changes
that use this binding next time?
This will make it possible to actually build and test the driver.

Thanks,
-Dan

[PATCH] drm: Hack around CONFIG_AGP=m build failures

[Michal Marek]

On 2015-10-01 12:17, Daniel Vetter wrote:
> On Thu, Oct 01, 2015 at 11:58:32AM +0200, Michal Marek wrote:
>> On 2015-10-01 10:19, Jani Nikula wrote:
>>> On Thu, 01 Oct 2015, Daniel Vetter  wrote:
 Surprisingly kbuild can't cope with tristates in the
 -$(CONFIG_FOO) pattern. This patch hacks up a solution.
>>>
>>> Given that it's two distinct Makefile variables (foo-y and foo-m) being
>>> assigned to, I don't really find this surprising. Maybe this could be
>>> made to work as a convenience, but there might be other, more surpising
>>> consequences.
>>
>> I actually think that kbuild should be able to handle this. The likely
>> reason why it is not doing it right now is that in an ideal world,
>> modules are modules can be built out of tree against just the kernel and
>> their static dependencies. In real world, we sometimes have features in
>> modules that are enabled if other modules are enabled. I'll post a patch
>> later. We also have lots of tests fo CONFIG_FOO || CONFIG_FOO_MODULE in
>> built-in code, which is a similar case.
> 
> Cool. I'll keep this hack in drm-misc then. Please cc me on the proper
> solution so I know when I can revert it again.

It's not as trivial as it seemed, because there are at least three
Makefiles that rely on the current behavior:

init/Makefile
drivers/misc/ibmasm/Makefile
fs/logfs/Makefile

While ibmasm and logfs can and probably should be fixed to work with
modular 8250 and mtd, respectively, init/Makefile would need a
workaround to only pick up do_mounts_rd.o and do_mounts_md.o if the
respective block drivers are built-in. So we would be trading one hack
for another.

Michal

[PATCH 16/16] drm/sti: Use drm_crtc_vblank_*() API

[Vincent ABRIOU]

On 09/24/2015 06:35 PM, Thierry Reding wrote:
> From: Thierry Reding 
>
> Non-legacy drivers should only use this API to allow per-CRTC data to be
> eventually moved into struct drm_crtc.
>
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Signed-off-by: Thierry Reding 
> ---
>   drivers/gpu/drm/sti/sti_crtc.c  | 37 -
>   drivers/gpu/drm/sti/sti_gdp.c   |  2 +-
>   drivers/gpu/drm/sti/sti_hqvdp.c |  2 +-
>   drivers/gpu/drm/sti/sti_vtg.c   | 14 +++---
>   drivers/gpu/drm/sti/sti_vtg.h   |  4 ++--
>   5 files changed, 31 insertions(+), 28 deletions(-)
>

Tested on top of next-20151001.
You can add my Ack-by on this patch
Ack-by: Vincent Abriou 

Vincent

[PATCH 09/16] drm/irq: Use unsigned int pipe in public API

[Vincent ABRIOU]

On 09/24/2015 06:35 PM, Thierry Reding wrote:
> From: Thierry Reding 
>
> This continues the pattern started in commit cc1ef118fc09 ("drm/irq:
> Make pipe unsigned and name consistent"). This is applied to the public
> APIs and driver callbacks, so pretty much all drivers need to be updated
> to match the new prototypes.
>
> Cc: Christian König 
> Cc: Alex Deucher 
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Cc: Inki Dae 
> Cc: Jianwei Wang 
> Cc: Alison Wang 
> Cc: Patrik Jakobsson 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Philipp Zabel 
> Cc: David Airlie 
> Cc: Rob Clark 
> Cc: Ben Skeggs 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> Cc: Mark Yao 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Thomas Hellstrom 
> Signed-off-by: Thierry Reding 
> ---

[...]

>   drivers/gpu/drm/sti/sti_crtc.c   | 16 ++--
>   drivers/gpu/drm/sti/sti_crtc.h   |  4 +--

[...]

> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
> index 81c56ea9d87f..c6fb8dee11de 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_crtc.c
> @@ -299,7 +299,7 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
>  return 0;
>   }
>
> -int sti_crtc_enable_vblank(struct drm_device *dev, int crtc)
> +int sti_crtc_enable_vblank(struct drm_device *dev, unsigned int pipe)
>   {
>  struct sti_private *dev_priv = dev->dev_private;
>  struct sti_compositor *compo = dev_priv->compo;
> @@ -307,9 +307,9 @@ int sti_crtc_enable_vblank(struct drm_device *dev, int 
> crtc)
>
>  DRM_DEBUG_DRIVER("\n");
>
> -   if (sti_vtg_register_client(crtc == STI_MIXER_MAIN ?
> +   if (sti_vtg_register_client(pipe == STI_MIXER_MAIN ?
>  compo->vtg_main : compo->vtg_aux,
> -   vtg_vblank_nb, crtc)) {
> +   vtg_vblank_nb, pipe)) {
>  DRM_ERROR("Cannot register VTG notifier\n");
>  return -EINVAL;
>  }
> @@ -318,7 +318,7 @@ int sti_crtc_enable_vblank(struct drm_device *dev, int 
> crtc)
>   }
>   EXPORT_SYMBOL(sti_crtc_enable_vblank);
>
> -void sti_crtc_disable_vblank(struct drm_device *drm_dev, int crtc)
> +void sti_crtc_disable_vblank(struct drm_device *drm_dev, unsigned int pipe)
>   {
>  struct sti_private *priv = drm_dev->dev_private;
>  struct sti_compositor *compo = priv->compo;
> @@ -326,14 +326,14 @@ void sti_crtc_disable_vblank(struct drm_device 
> *drm_dev, int crtc)
>
>  DRM_DEBUG_DRIVER("\n");
>
> -   if (sti_vtg_unregister_client(crtc == STI_MIXER_MAIN ?
> +   if (sti_vtg_unregister_client(pipe == STI_MIXER_MAIN ?
>  compo->vtg_main : compo->vtg_aux, vtg_vblank_nb))
>  DRM_DEBUG_DRIVER("Warning: cannot unregister VTG 
> notifier\n");
>
>  /* free the resources of the pending requests */
> -   if (compo->mixer[crtc]->pending_event) {
> -   drm_vblank_put(drm_dev, crtc);
> -   compo->mixer[crtc]->pending_event = NULL;
> +   if (compo->mixer[pipe]->pending_event) {
> +   drm_vblank_put(drm_dev, pipe);
> +   compo->mixer[pipe]->pending_event = NULL;
>  }
>   }
>   EXPORT_SYMBOL(sti_crtc_disable_vblank);
> diff --git a/drivers/gpu/drm/sti/sti_crtc.h b/drivers/gpu/drm/sti/sti_crtc.h
> index 51963e6ddbe7..3f2d89a3634d 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.h
> +++ b/drivers/gpu/drm/sti/sti_crtc.h
> @@ -13,8 +13,8 @@ struct sti_mixer;
>
>   int sti_crtc_init(struct drm_device *drm_dev, struct sti_mixer *mixer,
>struct drm_plane *primary, struct drm_plane *cursor);
> -int sti_crtc_enable_vblank(struct drm_device *dev, int crtc);
> -void sti_crtc_disable_vblank(struct drm_device *dev, int crtc);
> +int sti_crtc_enable_vblank(struct drm_device *dev, unsigned int pipe);
> +void sti_crtc_disable_vblank(struct drm_device *dev, unsigned int pipe);
>   int sti_crtc_vblank_cb(struct notifier_block *nb,
> unsigned long event, void *data);
>   bool sti_crtc_is_main(struct drm_crtc *drm_crtc);

Tested on top of next-20151001.
You can add my Ack-by on this patch
Ack-by: Vincent Abriou 

Vincent

[PATCH] drm/nouveau: fix memory leak

[Ben Skeggs]

On 09/25/2015 01:59 AM, Sudip Mukherjee wrote:
> On Fri, Sep 11, 2015 at 03:00:56PM +0530, Sudip Mukherjee wrote:
>> If pm_runtime_get_sync() we were going to "out" but we missed
>> freeing vma.
>> 
>> Signed-off-by: Sudip Mukherjee  ---
> Hi Ben, Another gentle ping for another patch.
Both patches are in my tree.

Thanks,
Ben.

> 
> regards sudip ___ 
> dri-devel mailing list dri-devel at lists.freedesktop.org 
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[PATCH 4/6] qcom-scm: add ocmem support

[Rob Clark]

On Tue, Sep 29, 2015 at 6:33 PM, Stephen Boyd  wrote:
> On 09/29, Rob Clark wrote:
>> On Tue, Sep 29, 2015 at 5:38 PM, Stephen Boyd  
>> wrote:
>> > On 09/29, Rob Clark wrote:
>> >> diff --git a/drivers/firmware/qcom_scm-32.c 
>> >> b/drivers/firmware/qcom_scm-32.c
>> >> index c1e4325..e1ac97f 100644
>> >> --- a/drivers/firmware/qcom_scm-32.c
>> >> +++ b/drivers/firmware/qcom_scm-32.c
>> >> @@ -500,6 +500,59 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req 
>> >> *req, u32 req_cnt, u32 *resp)
>> >>   req, req_cnt * sizeof(*req), resp, sizeof(*resp));
>> >>  }
>> >>
>> >> +int __qcom_scm_ocmem_secure_cfg(unsigned sec_id)
>> >> +{
>> >> + int ret, scm_ret = 0;
>> >> + struct msm_scm_sec_cfg {
>> >
>> > We've left these as anonymous structs for things like
>> > qcom_scm_set_boot_addr(), maybe we should do the same here.
>> >
>> >> + __le32 id;
>> >> + __le32 spare;
>> >
>> > Also, the iommu driver would use this API and it uses this
>> > "spare" element, so perhaps this whole function should be renamed
>> > to be more generic and take two values. Downstream the function
>> > is called scm_restore_sec_cfg, so maybe something similar.  And
>> > the service id is MP for "memory protection", so
>> > QCOM_SCM_OCMEM_SECURE_SVC could be QCOM_SCM_MEMORY_PROTECTION?
>>
>> heh,
>>
>> #define SCM_SVC_MP0xC
>> #define IOMMU_SECURE_CFG2
>>
>> vs.
>>
>> #define OCMEM_SECURE_SVC_ID 12
>> #define OCMEM_SECURE_CFG_ID 0x2
>>
>> that wasn't obscure at all!
>
> :)
>
>>
>> Maybe then there is a better name than spare?  Looks like downstream
>> iommu calls it cb_num?
>
> Yeah I think that's the only use to indicate which context bank
> it is. Maybe we can have a single id configure API and a special
> iommu context bank API that both funnel into the same private two
> number API. Otherwise we have a bunch of callers passing 0 for
> the second argument because they don't care.

so fwiw, I went thru all the downstream scm_call() callers..  there
are a lot of callers to SCM_SVC_MP service (through a couple different
#defines), but most of them are different cmd-id's.  The ones using
SECURE_CFG (0x2) are:

  * dwc3_msm_restore_sec_config()
  * ocmem_restore_sec_program()
  * msm_iommu_sec_program_iommu()

so we have two points passing in zero for ctx-bank, one that does not.
I don't think it is worth having two API's to save hard-coding zero in
two places ;-)

BR,
-R

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

[PATCH 07/16] drm/sti: Store correct CRTC index in events

[Vincent ABRIOU]

On 09/24/2015 06:35 PM, Thierry Reding wrote:
> From: Thierry Reding 
>
> A negative pipe causes a special case to be triggered for drivers that
> don't have proper VBLANK support. STi does support VBLANKs, so there is
> no need for the fallback code.
>
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Signed-off-by: Thierry Reding 
> ---
>   drivers/gpu/drm/sti/sti_crtc.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
> index 018ffc970e96..81c56ea9d87f 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_crtc.c
> @@ -274,7 +274,7 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
>
>   spin_lock_irqsave(_dev->event_lock, flags);
>   if (compo->mixer[*crtc]->pending_event) {
> - drm_send_vblank_event(drm_dev, -1,
> + drm_send_vblank_event(drm_dev, *crtc,
> compo->mixer[*crtc]->pending_event);
>   drm_vblank_put(drm_dev, *crtc);
>   compo->mixer[*crtc]->pending_event = NULL;
>

Successfully tested on next-20151001
Ack-by: Vincent Abriou 

Vincent

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, a few i915 fixes for v4.3.

Do note the drm kms helper change from Egbert, I'm afraid it was not
posted on dri-devel, just intel-gfx. However the change is trivial and
needed as a dependency for the deadlock fix in i915.

BR,
Jani.

The following changes since commit 9ffecb10283508260936b96022d4ee43a7798b4c:

  Linux 4.3-rc3 (2015-09-27 07:50:08 -0400)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-10-01

for you to fetch changes up to b94be972538f4523f09243af7c726158f0bfae33:

  drm/i915: Call non-locking version of drm_kms_helper_poll_enable(), v2 
(2015-09-30 16:32:27 +0300)


Egbert Eich (2):
  drm: Add a non-locking version of drm_kms_helper_poll_enable(), v2
  drm/i915: Call non-locking version of drm_kms_helper_poll_enable(), v2

Michel Thierry (1):
  drm/i915: Consider HW CSB write pointer before resetting the sw read 
pointer

Rodrigo Vivi (1):
  drm/i915/skl: Don't call intel_prepare_ddi when encoder list isn't yet 
initialized.

 drivers/gpu/drm/drm_probe_helper.c  | 19 +---
 drivers/gpu/drm/i915/intel_hotplug.c|  2 +-
 drivers/gpu/drm/i915/intel_lrc.c| 39 +++--
 drivers/gpu/drm/i915/intel_lrc.h|  2 ++
 drivers/gpu/drm/i915/intel_runtime_pm.c |  3 ++-
 include/drm/drm_crtc_helper.h   |  1 +
 6 files changed, 54 insertions(+), 12 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v2 2/2] drm/qxl: avoid dependency lock

[poma]

On 24.09.2015 15:25, Frediano Ziglio wrote:
> qxl_bo_unref calls drm_gem_object_unreference_unlocked which
> locks dev->struct_mutex. However this lock could be already
> locked if the call came from qxl_gem_object_free.
> As we don't need to call qxl_bo_ref/qxl_bo_unref cause
> qxl_release_list_add will hold a reference by itself avoid
> to call them and the possible deadlock.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  drivers/gpu/drm/qxl/qxl_release.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
> b/drivers/gpu/drm/qxl/qxl_release.c
> index b66ec33..4efa8e2 100644
> --- a/drivers/gpu/drm/qxl/qxl_release.c
> +++ b/drivers/gpu/drm/qxl/qxl_release.c
> @@ -307,7 +307,7 @@ int qxl_alloc_surface_release_reserved(struct qxl_device 
> *qdev,
>   idr_ret = qxl_release_alloc(qdev, QXL_RELEASE_SURFACE_CMD, 
> release);
>   if (idr_ret < 0)
>   return idr_ret;
> - bo = qxl_bo_ref(to_qxl_bo(entry->tv.bo));
> + bo = to_qxl_bo(entry->tv.bo);
>  
>   (*release)->release_offset = create_rel->release_offset + 64;
>  
> @@ -316,8 +316,6 @@ int qxl_alloc_surface_release_reserved(struct qxl_device 
> *qdev,
>   info = qxl_release_map(qdev, *release);
>   info->id = idr_ret;
>   qxl_release_unmap(qdev, *release, info);
> -
> - qxl_bo_unref();
>   return 0;
>   }
>  
> 


Tested with:
 - Rawhide-Xfce-Live-1001.iso
  \ 4.3.0-0.rc3.git2.4.fc24.x86_64
   + v2-1-2-drm-qxl-avoid-buffer-reservation-in-qxl_crtc_page_flip.patch
   + v2-2-2-drm-qxl-avoid-dependency-lock.patch

Tested-by: poma 

[PATCH 6/6] drm/msm: add OCMEM driver

[Rob Clark]

On Thu, Oct 1, 2015 at 2:00 PM, Stephen Boyd  wrote:
> On 10/01, Stanimir Varbanov wrote:
>> On 09/30/2015 02:45 PM, Rob Clark wrote:
>> > On Wed, Sep 30, 2015 at 7:31 AM, Rob Clark  wrote:
>> >> On Wed, Sep 30, 2015 at 3:51 AM, Stanimir Varbanov
>> >>  wrote:
>> >>> On 09/29/2015 10:48 PM, Rob Clark wrote:
>> >> was mandatory or just power optimization..  but yes, the plan was to
>> >> move it somewhere else (not sure quite where, drivers/doc/qcom?)
>> >> sometime..  Preferably when someone who understands all the other
>> >> ocmem use-cases better could figure out what we really need to add to
>> >> the driver.
>> >>
>> >> In downstream driver there is a lot of complexity that appears to be
>> >> in order to allow two clients to each allocate a portion of a macro
>> >> within a region (ie. aggregate_macro_state(), apply_macro_vote(),
>> >> etc), and I wanted to figure out if that is even a valid use-case
>> >> before trying to make ocmem something that could actually support
>> >> multiple clients.
>> >>
>> >> There is also some complexity about ensuring that if clients aren't
>> >> split up on region boundaries, that you don't have one client in
>> >> region asking for wide-mode and other for narrow-mode..
>> >> (switch_region_mode()) but maybe we could handle that by just
>> >> allocating wide from bottom and narrow from top.  Also seems to be
>> >> some craziness for allowing one client to pre-empt/evict another.. a
>> >> dm engine, etc, etc..
>> >>
>> >> All I know is gpu just statically allocates one big region aligned
>> >> chunk of ocmem, so I ignored the rest of the crazy (maybe or maybe not
>> >> hypothetical) use-cases for now...
>>
>> OK, I will try to sort out ocmem use cases for vidc driver.
>>
>
> The simplest thing to do is to split the memory between GPU and
> vidc statically. The other use cases with preemption and eviction
> and DMA add a lot of complexity that we can explore at a later
> time if need be.

true, as long as one of the clients is the static gpu client, I guess
we could reasonably easily support up to two clients reasonably
easily...

BR,
-R

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

[PATCH 4/6] qcom-scm: add ocmem support

[Stephen Boyd]

On 10/01, Rob Clark wrote:
> On Tue, Sep 29, 2015 at 6:33 PM, Stephen Boyd  wrote:
> > On 09/29, Rob Clark wrote:
> >> On Tue, Sep 29, 2015 at 5:38 PM, Stephen Boyd  
> >> wrote:
> >
> > Yeah I think that's the only use to indicate which context bank
> > it is. Maybe we can have a single id configure API and a special
> > iommu context bank API that both funnel into the same private two
> > number API. Otherwise we have a bunch of callers passing 0 for
> > the second argument because they don't care.
> 
> so fwiw, I went thru all the downstream scm_call() callers..  there
> are a lot of callers to SCM_SVC_MP service (through a couple different
> #defines), but most of them are different cmd-id's.  The ones using
> SECURE_CFG (0x2) are:
> 
>   * dwc3_msm_restore_sec_config()
>   * ocmem_restore_sec_program()
>   * msm_iommu_sec_program_iommu()
> 
> so we have two points passing in zero for ctx-bank, one that does not.
> I don't think it is worth having two API's to save hard-coding zero in
> two places ;-)
> 

What sources are you looking at? It seems like whatever you have
is over a year old. About a year ago, we consolidated all calls
to this specific SCM call into a single API called
scm_restore_sec_cfg (see commit 9933a272db9a5612bcc2ee0ef9149f70c8166eb3
"qcom: scm: Provide an API that restores security configuration" on
msm-3.10).

Looking at our latest msm-3.10 branch I see

drivers/crypto/msm/ice.c:ret = scm_restore_sec_cfg(cbuf.device_id, 
cbuf.spare, _ret);

cbuf.spare is 0 here.

drivers/iommu/msm_iommu_sec.c:   ret = scm_restore_sec_cfg(drvdata->sec_id, 
ctx_drvdata->num, _ret);

This is the only real user of spare

drivers/pci/host/pci-msm.c:  ret = scm_restore_sec_cfg(dev->scm_dev_id, 0, 
_ret);
drivers/scsi/ufs/ufs-qcom.c: ret = scm_restore_sec_cfg(cbuf.device_id, 
cbuf.spare, _ret);

cbuf.spare is 0 here.

drivers/soc/qcom/ocmem_core.c:   rc = scm_restore_sec_cfg(sec_id, 0, 
_ret);
drivers/video/msm/mdss/mdss_mdp.c:   ret = scm_restore_sec_cfg(SEC_DEVICE_MDSS, 
0, _ret);

So that's 6 callers and 1 uses the second argument.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/2] drm: handle cursor_set2 in restore_fbdev_mode

[Daniel Vetter]

On Thu, Oct 01, 2015 at 12:36:27PM +0100, Emil Velikov wrote:
> Hi Alex,
> 
> On 30 September 2015 at 19:47, Alex Deucher  wrote:
> > If a driver uses the cursor_set2 crtc callback rather than
> > cursor_set, use that.  This fixes the fbdev helper for drivers
> > that use cursor_set2.
> >
> > Change-Id: I127d3f8e72789ba70c3648140f87c6187864e130
> Are Change-Id lines accepted in the kernel ? Iirc there was some noise
> against them a while back.

Some maintainers reject them, I don't think anyone here in the drm
subsystem cares really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[GIT PULL] exynos-drm-fixes

[Inki Dae]

Hi Dave,

   This pull request includes regression fixups, build warnings, and
   trivial cleanups which mostly remove some codes not used anymore.

   Please, kindly let me know if there is any problem.


Thanks,
Inki Dae

The following changes since commit fd03420b5624617a708fb9b13634b41b37c22cfa:

  Merge tag 'drm-intel-fixes-2015-09-24' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-09-25 06:52:37 
+1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
exynos-drm-fixes

for you to fetch changes up to cda374253f862bd0f43edda6935a48294fe8ed3e:

  drm/exynos: Staticize local function in exynos_drm_gem.c (2015-10-01 14:29:51 
+0900)


Daniel Kurtz (1):
  drm/exynos: Remove useless EXPORT_SYMBOL_GPLs

Gustavo Padovan (4):
  drm/exynos: remove fimd_mode_fixup()
  drm/exynos: remove decon_mode_fixup()
  drm/exynos: remove unused mode_fixup() code
  drm/exynos: fimd: actually disable dp clock

Inki Dae (1):
  drm/exynos: dp: remove suspend/resume functions

Joonyoung Shim (8):
  drm/exynos: fix layering violation of address
  drm/exynos: fix missed calling of drm_prime_gem_destroy()
  drm/exynos: remove unnecessary NULL assignment
  drm/exynos: staticize exynos_drm_gem_init()
  drm/exynos: cleanup function calling written twice
  drm/exynos: cleanup line feed in exynos_drm_gem_get_ioctl
  drm/exynos: remove call to drm_gem_free_mmap_offset()
  drm/exynos: create a fake mmap offset with gem creation

Krzysztof Kozlowski (1):
  drm/exynos: Staticize local function in exynos_drm_gem.c

Thierry Reding (3):
  drm/exynos: Suspend/resume is unused if !PM
  drm/exynos: fimc: Clock control is unused if !PM
  drm/exynos: rotator: Clock control is unused if !PM

 drivers/gpu/drm/exynos/exynos7_drm_decon.c  | 12 
 drivers/gpu/drm/exynos/exynos_dp_core.c | 23 ---
 drivers/gpu/drm/exynos/exynos_drm_core.c|  6 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 15 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  2 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  4 --
 drivers/gpu/drm/exynos/exynos_drm_fimc.c| 36 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c| 14 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  3 -
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 94 +
 drivers/gpu/drm/exynos/exynos_drm_gem.h |  6 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  2 +-
 12 files changed, 65 insertions(+), 152 deletions(-)

[PATCH 08/20] drm/armada: use xchg() to atomically update dplane->old_fb

[Russell King - ARM Linux]

On Wed, Sep 30, 2015 at 11:49:44AM +0100, Emil Velikov wrote:
> Hi Russell,
> 
> On 29 September 2015 at 19:10, Russell King  
> wrote:
> > Rather than using a spinlock, use xchg() to atomically update
> > dplane->old_fb.  This allows us to eliminate dplane->lock.
> >
> > Signed-off-by: Russell King 
> > ---
> [...]
> > @@ -76,13 +75,10 @@ static void armada_ovl_retire_fb(struct 
> > armada_ovl_plane *dplane,
> >  {
> > struct drm_framebuffer *old_fb;
> >
> > -   spin_lock(>lock);
> > -   old_fb = dplane->old_fb;
> > -   dplane->old_fb = fb;
> > -   spin_unlock(>lock);
> > +   old_fb = xchg(>old_fb, fb);
> >
> > if (old_fb)
> > -   armada_drm_queue_unref_work(dplane->base.dev, old_fb);
> > +   armada_drm_queue_unref_work(dplane->base.base.dev, old_fb);
> Shouldn't this be part of another patch ?

Yes, you're right, it should be in:

drm/armada: introduce generic armada_plane struct

Now moved there, thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[RESEND] drm/exynos: Staticize local function in exynos_drm_gem.c

[Krzysztof Kozlowski]

The exynos_drm_gem_mmap_buffer() is not used outside so make it static.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index f12fbc36b120..ba9cadb9acef 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -313,7 +313,7 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
 }

-int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
+static int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj 
*exynos_gem_obj,
  struct vm_area_struct *vma)
 {
struct drm_device *drm_dev = exynos_gem_obj->base.dev;
-- 
1.9.1

[PATCH 1/2] drm: handle cursor_set2 in restore_fbdev_mode

[Alex Deucher]

On Thu, Oct 1, 2015 at 1:13 PM, Alex Deucher  wrote:
> On Thu, Oct 1, 2015 at 1:01 PM, Alex Deucher  wrote:
>> On Wed, Sep 30, 2015 at 11:50 PM, Michel Dänzer  
>> wrote:
>>> On 01.10.2015 03:47, Alex Deucher wrote:
 If a driver uses the cursor_set2 crtc callback rather than
 cursor_set, use that.  This fixes the fbdev helper for drivers
 that use cursor_set2.

 Change-Id: I127d3f8e72789ba70c3648140f87c6187864e130
 Signed-off-by: Alex Deucher 
 ---
  drivers/gpu/drm/drm_fb_helper.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/drm_fb_helper.c 
 b/drivers/gpu/drm/drm_fb_helper.c
 index 418d299..ca08c47 100644
 --- a/drivers/gpu/drm/drm_fb_helper.c
 +++ b/drivers/gpu/drm/drm_fb_helper.c
 @@ -345,7 +345,11 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
 *fb_helper)
   struct drm_crtc *crtc = mode_set->crtc;
   int ret;

 - if (crtc->funcs->cursor_set) {
 + if (crtc->funcs->cursor_set2) {
 + ret = crtc->funcs->cursor_set2(crtc, NULL, 0, 0, 0, 
 0, 0);
 + if (ret)
 + error = true;
 + } else if (crtc->funcs->cursor_set) {
   ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
   if (ret)
   error = true;

>>>
>>> Hah, nice catch. The series is
>>>
>>> Reviewed-by: Michel Dänzer 
>>>
>>> (I assume you tested with something like killall -9 Xorg and confirming
>>> sure the cursor doesn't stay visible in console)
>>>
>>
>> The cursor still stays visible in the console.  Interestingly, the
>> cursor still shows up in the console even without these patches.
>
> restore_fbdev_mode doesn't end up get called when I killall -9 X.

For clarity, drm_fb_helper_set_par which which ultimately calls
restore_fbdev_mode never gets called.

Alex

>
> Alex
>
>>
>> Alex

[PATCH 1/2] drm: handle cursor_set2 in restore_fbdev_mode

[Alex Deucher]

On Thu, Oct 1, 2015 at 1:01 PM, Alex Deucher  wrote:
> On Wed, Sep 30, 2015 at 11:50 PM, Michel Dänzer  
> wrote:
>> On 01.10.2015 03:47, Alex Deucher wrote:
>>> If a driver uses the cursor_set2 crtc callback rather than
>>> cursor_set, use that.  This fixes the fbdev helper for drivers
>>> that use cursor_set2.
>>>
>>> Change-Id: I127d3f8e72789ba70c3648140f87c6187864e130
>>> Signed-off-by: Alex Deucher 
>>> ---
>>>  drivers/gpu/drm/drm_fb_helper.c | 6 +-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 418d299..ca08c47 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -345,7 +345,11 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
>>> *fb_helper)
>>>   struct drm_crtc *crtc = mode_set->crtc;
>>>   int ret;
>>>
>>> - if (crtc->funcs->cursor_set) {
>>> + if (crtc->funcs->cursor_set2) {
>>> + ret = crtc->funcs->cursor_set2(crtc, NULL, 0, 0, 0, 
>>> 0, 0);
>>> + if (ret)
>>> + error = true;
>>> + } else if (crtc->funcs->cursor_set) {
>>>   ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
>>>   if (ret)
>>>   error = true;
>>>
>>
>> Hah, nice catch. The series is
>>
>> Reviewed-by: Michel Dänzer 
>>
>> (I assume you tested with something like killall -9 Xorg and confirming
>> sure the cursor doesn't stay visible in console)
>>
>
> The cursor still stays visible in the console.  Interestingly, the
> cursor still shows up in the console even without these patches.

restore_fbdev_mode doesn't end up get called when I killall -9 X.

Alex

>
> Alex

[PATCH 1/2] drm: handle cursor_set2 in restore_fbdev_mode

[Alex Deucher]

On Wed, Sep 30, 2015 at 11:50 PM, Michel Dänzer  wrote:
> On 01.10.2015 03:47, Alex Deucher wrote:
>> If a driver uses the cursor_set2 crtc callback rather than
>> cursor_set, use that.  This fixes the fbdev helper for drivers
>> that use cursor_set2.
>>
>> Change-Id: I127d3f8e72789ba70c3648140f87c6187864e130
>> Signed-off-by: Alex Deucher 
>> ---
>>  drivers/gpu/drm/drm_fb_helper.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 418d299..ca08c47 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -345,7 +345,11 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
>> *fb_helper)
>>   struct drm_crtc *crtc = mode_set->crtc;
>>   int ret;
>>
>> - if (crtc->funcs->cursor_set) {
>> + if (crtc->funcs->cursor_set2) {
>> + ret = crtc->funcs->cursor_set2(crtc, NULL, 0, 0, 0, 0, 
>> 0);
>> + if (ret)
>> + error = true;
>> + } else if (crtc->funcs->cursor_set) {
>>   ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
>>   if (ret)
>>   error = true;
>>
>
> Hah, nice catch. The series is
>
> Reviewed-by: Michel Dänzer 
>
> (I assume you tested with something like killall -9 Xorg and confirming
> sure the cursor doesn't stay visible in console)
>

The cursor still stays visible in the console.  Interestingly, the
cursor still shows up in the console even without these patches.

Alex

[PATCH 1/2] drm: handle cursor_set2 in restore_fbdev_mode

[Deucher, Alexander]

> -Original Message-
> From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
> Sent: Thursday, October 01, 2015 7:36 AM
> To: Alex Deucher
> Cc: ML dri-devel; Deucher, Alexander
> Subject: Re: [PATCH 1/2] drm: handle cursor_set2 in restore_fbdev_mode
> 
> Hi Alex,
> 
> On 30 September 2015 at 19:47, Alex Deucher 
> wrote:
> > If a driver uses the cursor_set2 crtc callback rather than
> > cursor_set, use that.  This fixes the fbdev helper for drivers
> > that use cursor_set2.
> >
> > Change-Id: I127d3f8e72789ba70c3648140f87c6187864e130
> Are Change-Id lines accepted in the kernel ? Iirc there was some noise
> against them a while back.

It was just a temporary problem with my git client.  I've already fixed it 
locally.

Alex

> 
> Thanks
> Emil

[PATCH 1/2] drm: handle cursor_set2 in restore_fbdev_mode

[Michel Dänzer]

On 01.10.2015 03:47, Alex Deucher wrote:
> If a driver uses the cursor_set2 crtc callback rather than
> cursor_set, use that.  This fixes the fbdev helper for drivers
> that use cursor_set2.
> 
> Change-Id: I127d3f8e72789ba70c3648140f87c6187864e130
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 418d299..ca08c47 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -345,7 +345,11 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
> *fb_helper)
>   struct drm_crtc *crtc = mode_set->crtc;
>   int ret;
>  
> - if (crtc->funcs->cursor_set) {
> + if (crtc->funcs->cursor_set2) {
> + ret = crtc->funcs->cursor_set2(crtc, NULL, 0, 0, 0, 0, 
> 0);
> + if (ret)
> + error = true;
> + } else if (crtc->funcs->cursor_set) {
>   ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
>   if (ret)
>   error = true;
> 

Hah, nice catch. The series is

Reviewed-by: Michel Dänzer 

(I assume you tested with something like killall -9 Xorg and confirming
sure the cursor doesn't stay visible in console)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "drm_agp_release" [drivers/gpu/drm/radeon/radeon.ko] undefined!
ERROR: "drm_agp_acquire" [drivers/gpu/drm/radeon/radeon.ko] undefined!
ERROR: "drm_agp_enable" [drivers/gpu/drm/radeon/radeon.ko] undefined!
ERROR: "drm_agp_info" [drivers/gpu/drm/radeon/radeon.ko] undefined!
ERROR: "drm_agp_release" [drivers/gpu/drm/mga/mga.ko] undefined!
ERROR: "drm_agp_acquire" [drivers/gpu/drm/mga/mga.ko] undefined!
ERROR: "drm_agp_free" [drivers/gpu/drm/mga/mga.ko] undefined!
ERROR: "drm_agp_bind" [drivers/gpu/drm/mga/mga.ko] undefined!
ERROR: "drm_agp_unbind" [drivers/gpu/drm/mga/mga.ko] undefined!
ERROR: "drm_agp_alloc" [drivers/gpu/drm/mga/mga.ko] undefined!
ERROR: "drm_agp_enable" [drivers/gpu/drm/mga/mga.ko] undefined!
ERROR: "drm_agp_info" [drivers/gpu/drm/mga/mga.ko] undefined!
ERROR: "drm_agp_unbind_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_init" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_alloc_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_clear" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_info_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_enable_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_release_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_bind_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_acquire_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_free_ioctl" [drivers/gpu/drm/drm.ko] undefined!

Not quite sure which commit caused this, but I have used the drm-misc
tree from next-20150930 for today.

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

[PATCH 1/2] drm: handle cursor_set2 in restore_fbdev_mode

[Emil Velikov]

Hi Alex,

On 30 September 2015 at 19:47, Alex Deucher  wrote:
> If a driver uses the cursor_set2 crtc callback rather than
> cursor_set, use that.  This fixes the fbdev helper for drivers
> that use cursor_set2.
>
> Change-Id: I127d3f8e72789ba70c3648140f87c6187864e130
Are Change-Id lines accepted in the kernel ? Iirc there was some noise
against them a while back.

Thanks
Emil

[PATCH] drm: Hack around CONFIG_AGP=m build failures

[Daniel Vetter]

On Thu, Oct 01, 2015 at 11:58:32AM +0200, Michal Marek wrote:
> On 2015-10-01 10:19, Jani Nikula wrote:
> > On Thu, 01 Oct 2015, Daniel Vetter  wrote:
> >> Surprisingly kbuild can't cope with tristates in the
> >> -$(CONFIG_FOO) pattern. This patch hacks up a solution.
> > 
> > Given that it's two distinct Makefile variables (foo-y and foo-m) being
> > assigned to, I don't really find this surprising. Maybe this could be
> > made to work as a convenience, but there might be other, more surpising
> > consequences.
> 
> I actually think that kbuild should be able to handle this. The likely
> reason why it is not doing it right now is that in an ideal world,
> modules are modules can be built out of tree against just the kernel and
> their static dependencies. In real world, we sometimes have features in
> modules that are enabled if other modules are enabled. I'll post a patch
> later. We also have lots of tests fo CONFIG_FOO || CONFIG_FOO_MODULE in
> built-in code, which is a similar case.

Cool. I'll keep this hack in drm-misc then. Please cc me on the proper
solution so I know when I can revert it again.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 91342] Very dark textures on some objects in indoors environments in Postal 2

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

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

--- Comment #11 from Daniel Scharrer  ---
*** Bug 91998 has been marked as a duplicate of this bug. ***

-- 
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/20151001/bf281b2b/attachment.html>

[Bug 91998] Object rendered completely black in The Book of Unwritten Tales: The Critter Chronicles

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

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

Daniel Scharrer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Daniel Scharrer  ---
Both this and and the POSTAL 2 issue come from the same root problem - an Inf
or NaN returned by POW for vertices 'behind' the spotlight (dot(spot_direction,
vertex_direction) < 0):
http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/ffvertex_prog.c#n954

*** This bug has been marked as a duplicate of bug 91342 ***

-- 
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/20151001/fb6493c4/attachment-0001.html>

[PATCH] drm: Hack around CONFIG_AGP=m build failures

[Michal Marek]

On 2015-10-01 10:19, Jani Nikula wrote:
> On Thu, 01 Oct 2015, Daniel Vetter  wrote:
>> Surprisingly kbuild can't cope with tristates in the
>> -$(CONFIG_FOO) pattern. This patch hacks up a solution.
> 
> Given that it's two distinct Makefile variables (foo-y and foo-m) being
> assigned to, I don't really find this surprising. Maybe this could be
> made to work as a convenience, but there might be other, more surpising
> consequences.

I actually think that kbuild should be able to handle this. The likely
reason why it is not doing it right now is that in an ideal world,
modules are modules can be built out of tree against just the kernel and
their static dependencies. In real world, we sometimes have features in
modules that are enabled if other modules are enabled. I'll post a patch
later. We also have lots of tests fo CONFIG_FOO || CONFIG_FOO_MODULE in
built-in code, which is a similar case.

Michal

[PATCH 1/2] drm: Stop using drm_vblank_count() as the hw frame counter

[Rob Clark]

On Thu, Oct 1, 2015 at 11:47 AM, Ville Syrjälä
 wrote:
> On Thu, Oct 01, 2015 at 06:44:22PM +0300, Ville Syrjälä wrote:
>> On Thu, Oct 01, 2015 at 11:25:36AM -0400, Rob Clark wrote:
>> > On Wed, Sep 30, 2015 at 10:14 AM, Ville Syrjälä
>> >  wrote:
>> > > On Wed, Sep 30, 2015 at 04:08:02PM +0200, Daniel Vetter wrote:
>> > >> On Wed, Sep 30, 2015 at 04:46:48PM +0300, ville.syrjala at 
>> > >> linux.intel.com wrote:
>> > >> > From: Ville Syrjälä 
>> > >> >
>> > >> > drm_vblank_count() returns the software counter. We should not pretend
>> > >> > it's the hw counter since we use the hw counter to figuere out what 
>> > >> > the
>> > >> > software counter value should be. So instead provide a new function
>> > >> > drm_vblank_no_hw_counter() for drivers that don't have a real hw
>> > >> > counter. The new function simply returns 0, which is about the only
>> > >> > thing it can do.
>> > >>
>> > >> Shouldn't we instead just make the get_vblank_counter hook optional?
>> > >
>> > > Perhaps. But maybe this way would encourage people to go look for a
>> > > hw frame counter in their hardware?
>> >
>> > Well, I guess at this point we have more drm/kms drivers for hw
>> > without hw frame counters..  maybe a helper that guestimates based on
>> > time elapsed since last vbl irq would be useful..
>>
>> That's already being done for the sw counter.
>
> ... assuming you have accurate vbl timestamps that is.

yeah.. the set of drivers supporting drv->get_vblank_timestamp() is
even smaller than the ones supporting drv->get_vblank_counter() ;-)

That all said, I think msm/mdp5 could actually support
->get_vblank_counter(), and I think even ->get_scanout_position() and
therefore ->get_vblank_timestamp()..   but afaict mdp4 does not have
any line and frame count registers.  And iirc, omap did not.. and I'd
guess a lot of the other small embedded and mobile display controller
blocks out there do not..

BR,
-R

>> >
>> > >> -Daniel
>> > >>
>> > >> >
>> > >> > Cc: Vincent Abriou 
>> > >> > Cc: Thierry Reding 
>> > >> > Signed-off-by: Ville Syrjälä 
>> > >> > ---
>> > >> >  drivers/gpu/drm/armada/armada_drv.c  |  2 +-
>> > >> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
>> > >> >  drivers/gpu/drm/drm_irq.c| 17 +
>> > >> >  drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
>> > >> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c|  2 +-
>> > >> >  drivers/gpu/drm/imx/imx-drm-core.c   |  2 +-
>> > >> >  drivers/gpu/drm/msm/msm_drv.c|  2 +-
>> > >> >  drivers/gpu/drm/nouveau/nouveau_drm.c|  2 +-
>> > >> >  drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
>> > >> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c|  2 +-
>> > >> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |  2 +-
>> > >> >  drivers/gpu/drm/shmobile/shmob_drm_drv.c |  2 +-
>> > >> >  drivers/gpu/drm/sti/sti_drv.c|  2 +-
>> > >> >  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
>> > >> >  include/drm/drmP.h   |  1 +
>> > >> >  15 files changed, 31 insertions(+), 13 deletions(-)
>> > >> >
>> > >> > diff --git a/drivers/gpu/drm/armada/armada_drv.c 
>> > >> > b/drivers/gpu/drm/armada/armada_drv.c
>> > >> > index 225034b..464a13f 100644
>> > >> > --- a/drivers/gpu/drm/armada/armada_drv.c
>> > >> > +++ b/drivers/gpu/drm/armada/armada_drv.c
>> > >> > @@ -300,7 +300,7 @@ static struct drm_driver armada_drm_driver = {
>> > >> > .lastclose  = armada_drm_lastclose,
>> > >> > .unload = armada_drm_unload,
>> > >> > .set_busid  = drm_platform_set_busid,
>> > >> > -   .get_vblank_counter = drm_vblank_count,
>> > >> > +   .get_vblank_counter = drm_vblank_no_hw_counter,
>> > >> > .enable_vblank  = armada_drm_enable_vblank,
>> > >> > .disable_vblank = armada_drm_disable_vblank,
>> > >> >  #ifdef CONFIG_DEBUG_FS
>> > >> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
>> > >> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> > >> > index 8bc62ec..2eb1c66 100644
>> > >> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> > >> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> > >> > @@ -697,7 +697,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
>> > >> > .irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
>> > >> > .irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
>> > >> > .irq_uninstall = atmel_hlcdc_dc_irq_uninstall,
>> > >> > -   .get_vblank_counter = drm_vblank_count,
>> > >> > +   .get_vblank_counter = drm_vblank_no_hw_counter,
>> > >> > .enable_vblank = atmel_hlcdc_dc_enable_vblank,
>> > >> > .disable_vblank = atmel_hlcdc_dc_disable_vblank,
>> > >> > .gem_free_object = drm_gem_cma_free_object,
>> > >> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> > >> > index ed2394e..7d70b7c 100644
>> > >> > --- a/drivers/gpu/drm/drm_irq.c
>> > >> > +++ b/drivers/gpu/drm/drm_irq.c
>> > 

[RFC v3 0/7] MT8173 DRM support

[Philipp Zabel]

Hi Daniel,

Am Donnerstag, den 01.10.2015, 16:55 +0800 schrieb Daniel Kurtz:
[...]
> > CK Hu (3):
> >   dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
> >   drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
> >   drm/mediatek: Add DSI sub driver
> >
> > Daniel Kurtz (1):
> >   drm/mediatek: Add HDMI support
> 
> Thanks for the shout-out, but I really can't take any credit for this patch 
> :-)
> Somewhere along the life of this patch its ownership changed.
> It should probably be Jie Qiu as per its SOB.

Whoops, I'll change the author for this patch as you suggest.

> > Jie Qiu (2):
> >   drm/mediatek: Add DPI sub driver
> >   drm/mediatek: enable hdmi output control bit
> >
> > Philipp Zabel (1):
> >   dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
> 
> Can you also include the actual mt8173.dtsi (& mt8173-evb.dts) changes
> that use this binding next time?
> This will make it possible to actually build and test the driver.

I'll include the mt8173.dtsi changes next time, but I'm not aware what
needs to be done for mt8173-evb apart from enabling the hdmi node.

best regards
Philipp

[PATCH 2/2] drm/mst: update the link_address_sent before sending the link address (v2)

[Dave Airlie]

On 30 September 2015 at 17:44, Daniel Vetter  wrote:
> On Sun, Sep 06, 2015 at 06:53:00PM +1000, Dave Airlie wrote:
>> There is a race where the reply could get processed by another
>> work queue before we've updated the state.
>>
>> Update the state before sending the msg to close it.
>>
>> v2: reset value if return indicates we haven't send the msg.
>>
>> Pointed out by Adam J Richter on
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91481
>> Signed-off-by: Dave Airlie 
>
> Ok we see to have two callers of drm_dp_send_link_address:
> - drm_dp_add_port, but the only caller of that in turn is again
>   drm_dp_send_link_address. This is just self-recursion.
> - drm_dp_check_and_send_link_address, which in turn is called only by
>   itself and by drm_dp_mst_link_probe_work.
>
> drm_dp_mst_link_probe_work is only called from the mgr->work function, and
> a single work item is never run concurrently.
>
> I don't see any race here at all. A good cleanup though would be what
> Adam's original patch has done and move the link_address_sent = true into
> drm_dp_send_link_address.

I think we were being paranoid about the work queue vs the send_link_address
if you can't have multiple then it matters not.

But I'll repost the cleaned up version as it makes things easier to grok.

Dave.

[PATCH 2/6] scripts/kernel-doc: Adding infrastructure for markdown support

[Jani Nikula]

On Mon, 07 Sep 2015, Danilo Cesar Lemes de Paula  wrote:
>  %.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
> + @(which pandoc > /dev/null 2>&1) || \
> + (echo "*** To get propper documentation you need to install pandoc 
> ***";)

s/propper/proper/

This only seems to be applied to our (drm-intel) topical branch,
otherwise would've sent a patch.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] vgaarb: use kzalloc in vga_arbiter_add_pci_device()

[Jani Nikula]

On Wed, 30 Sep 2015, Rasmus Villemoes  wrote:
> Signed-off-by: Rasmus Villemoes 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/vga/vgaarb.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index a0b433456107..3166e4bc4eb6 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -531,7 +531,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> *pdev)
>   return false;
>  
>   /* Allocate structure */
> - vgadev = kmalloc(sizeof(struct vga_device), GFP_KERNEL);
> + vgadev = kzalloc(sizeof(struct vga_device), GFP_KERNEL);
>   if (vgadev == NULL) {
>   pr_err("failed to allocate pci device\n");
>   /*
> @@ -541,8 +541,6 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> *pdev)
>   return false;
>   }
>  
> - memset(vgadev, 0, sizeof(*vgadev));
> -
>   /* Take lock & check for duplicates */
>   spin_lock_irqsave(_lock, flags);
>   if (vgadev_find(pdev) != NULL) {
> -- 
> 2.1.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] vgaarb: use kzalloc in vga_arbiter_add_pci_device()

[Daniel Vetter]

On Thu, Oct 01, 2015 at 11:26:40AM +0300, Jani Nikula wrote:
> On Wed, 30 Sep 2015, Rasmus Villemoes  wrote:
> > Signed-off-by: Rasmus Villemoes 
> 
> Reviewed-by: Jani Nikula 

Applied to drm-misc, thanks.
-Daniel

> 
> > ---
> >  drivers/gpu/vga/vgaarb.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> > index a0b433456107..3166e4bc4eb6 100644
> > --- a/drivers/gpu/vga/vgaarb.c
> > +++ b/drivers/gpu/vga/vgaarb.c
> > @@ -531,7 +531,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> > *pdev)
> > return false;
> >  
> > /* Allocate structure */
> > -   vgadev = kmalloc(sizeof(struct vga_device), GFP_KERNEL);
> > +   vgadev = kzalloc(sizeof(struct vga_device), GFP_KERNEL);
> > if (vgadev == NULL) {
> > pr_err("failed to allocate pci device\n");
> > /*
> > @@ -541,8 +541,6 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
> > *pdev)
> > return false;
> > }
> >  
> > -   memset(vgadev, 0, sizeof(*vgadev));
> > -
> > /* Take lock & check for duplicates */
> > spin_lock_irqsave(_lock, flags);
> > if (vgadev_find(pdev) != NULL) {
> > -- 
> > 2.1.3
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/2] drm: Stop using drm_vblank_count() as the hw frame counter

[Rob Clark]

On Wed, Sep 30, 2015 at 10:14 AM, Ville Syrjälä
 wrote:
> On Wed, Sep 30, 2015 at 04:08:02PM +0200, Daniel Vetter wrote:
>> On Wed, Sep 30, 2015 at 04:46:48PM +0300, ville.syrjala at linux.intel.com 
>> wrote:
>> > From: Ville Syrjälä 
>> >
>> > drm_vblank_count() returns the software counter. We should not pretend
>> > it's the hw counter since we use the hw counter to figuere out what the
>> > software counter value should be. So instead provide a new function
>> > drm_vblank_no_hw_counter() for drivers that don't have a real hw
>> > counter. The new function simply returns 0, which is about the only
>> > thing it can do.
>>
>> Shouldn't we instead just make the get_vblank_counter hook optional?
>
> Perhaps. But maybe this way would encourage people to go look for a
> hw frame counter in their hardware?

Well, I guess at this point we have more drm/kms drivers for hw
without hw frame counters..  maybe a helper that guestimates based on
time elapsed since last vbl irq would be useful..

BR,
-R

>> -Daniel
>>
>> >
>> > Cc: Vincent Abriou 
>> > Cc: Thierry Reding 
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/armada/armada_drv.c  |  2 +-
>> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
>> >  drivers/gpu/drm/drm_irq.c| 17 +
>> >  drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
>> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c|  2 +-
>> >  drivers/gpu/drm/imx/imx-drm-core.c   |  2 +-
>> >  drivers/gpu/drm/msm/msm_drv.c|  2 +-
>> >  drivers/gpu/drm/nouveau/nouveau_drm.c|  2 +-
>> >  drivers/gpu/drm/omapdrm/omap_drv.c   |  2 +-
>> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c|  2 +-
>> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |  2 +-
>> >  drivers/gpu/drm/shmobile/shmob_drm_drv.c |  2 +-
>> >  drivers/gpu/drm/sti/sti_drv.c|  2 +-
>> >  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
>> >  include/drm/drmP.h   |  1 +
>> >  15 files changed, 31 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/armada/armada_drv.c 
>> > b/drivers/gpu/drm/armada/armada_drv.c
>> > index 225034b..464a13f 100644
>> > --- a/drivers/gpu/drm/armada/armada_drv.c
>> > +++ b/drivers/gpu/drm/armada/armada_drv.c
>> > @@ -300,7 +300,7 @@ static struct drm_driver armada_drm_driver = {
>> > .lastclose  = armada_drm_lastclose,
>> > .unload = armada_drm_unload,
>> > .set_busid  = drm_platform_set_busid,
>> > -   .get_vblank_counter = drm_vblank_count,
>> > +   .get_vblank_counter = drm_vblank_no_hw_counter,
>> > .enable_vblank  = armada_drm_enable_vblank,
>> > .disable_vblank = armada_drm_disable_vblank,
>> >  #ifdef CONFIG_DEBUG_FS
>> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
>> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> > index 8bc62ec..2eb1c66 100644
>> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> > @@ -697,7 +697,7 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
>> > .irq_preinstall = atmel_hlcdc_dc_irq_uninstall,
>> > .irq_postinstall = atmel_hlcdc_dc_irq_postinstall,
>> > .irq_uninstall = atmel_hlcdc_dc_irq_uninstall,
>> > -   .get_vblank_counter = drm_vblank_count,
>> > +   .get_vblank_counter = drm_vblank_no_hw_counter,
>> > .enable_vblank = atmel_hlcdc_dc_enable_vblank,
>> > .disable_vblank = atmel_hlcdc_dc_disable_vblank,
>> > .gem_free_object = drm_gem_cma_free_object,
>> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> > index ed2394e..7d70b7c 100644
>> > --- a/drivers/gpu/drm/drm_irq.c
>> > +++ b/drivers/gpu/drm/drm_irq.c
>> > @@ -1797,3 +1797,20 @@ bool drm_crtc_handle_vblank(struct drm_crtc *crtc)
>> > return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
>> >  }
>> >  EXPORT_SYMBOL(drm_crtc_handle_vblank);
>> > +
>> > +/**
>> > + * drm_vblank_no_hw_counter - "No hw counter" implementation of 
>> > .get_vblank_counter()
>> > + * @dev: DRM device
>> > + * @pipe: CRTC for which to read the counter
>> > + *
>> > + * Drivers can plug this into the .get_vblank_counter() function if
>> > + * there is no useable hardware frame counter available.
>> > + *
>> > + * Returns:
>> > + * 0
>> > + */
>> > +u32 drm_vblank_no_hw_counter(struct drm_device *dev, int pipe)
>> > +{
>> > +   return 0;
>> > +}
>> > +EXPORT_SYMBOL(drm_vblank_no_hw_counter);
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> > b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> > index f0a5839..fb9cfc5 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> > @@ -447,7 +447,7 @@ static struct drm_driver exynos_drm_driver = {
>> > .lastclose  = exynos_drm_lastclose,
>> > .postclose  = exynos_drm_postclose,
>> > .set_busid  = 

[PATCH 6/6] drm/msm: add OCMEM driver

[Stanimir Varbanov]

On 09/30/2015 02:45 PM, Rob Clark wrote:
> On Wed, Sep 30, 2015 at 7:31 AM, Rob Clark  wrote:
>> On Wed, Sep 30, 2015 at 3:51 AM, Stanimir Varbanov
>>  wrote:
>>> Hi Rob,
>>>
>>> Thanks for your work.
>>>
>>> On 09/29/2015 10:48 PM, Rob Clark wrote:
 For now, since the GPU is the only upstream consumer, just stuff this
 into drm/msm.  Eventually if we have other consumers, we'll have to
>>>
>>> As the video encoder/decoder driver (vidc) for apq8084 && msm8974 also
>>> use the ocmem for scratch buffers, it might be better to relocate the
>>> ocmem driver in drivers/soc/qcom from the beginning?
>>
>> I wasn't really sure how soon vidc would support 8084/8974 (I assume
>> first target is 8916 which fortunately doesn't have ocmem), or if it

My expectations are that the same driver will work on apq8084, as well.

>> was mandatory or just power optimization..  but yes, the plan was to
>> move it somewhere else (not sure quite where, drivers/doc/qcom?)
>> sometime..  Preferably when someone who understands all the other
>> ocmem use-cases better could figure out what we really need to add to
>> the driver.
>>
>> In downstream driver there is a lot of complexity that appears to be
>> in order to allow two clients to each allocate a portion of a macro
>> within a region (ie. aggregate_macro_state(), apply_macro_vote(),
>> etc), and I wanted to figure out if that is even a valid use-case
>> before trying to make ocmem something that could actually support
>> multiple clients.
>>
>> There is also some complexity about ensuring that if clients aren't
>> split up on region boundaries, that you don't have one client in
>> region asking for wide-mode and other for narrow-mode..
>> (switch_region_mode()) but maybe we could handle that by just
>> allocating wide from bottom and narrow from top.  Also seems to be
>> some craziness for allowing one client to pre-empt/evict another.. a
>> dm engine, etc, etc..
>>
>> All I know is gpu just statically allocates one big region aligned
>> chunk of ocmem, so I ignored the rest of the crazy (maybe or maybe not
>> hypothetical) use-cases for now...

OK, I will try to sort out ocmem use cases for vidc driver.

> 
> btw, I should add that I don't mind adding it in drivers/soc/qcom (or
> somewhere else?) to start with if others prefer, I just didn't want to
> give the wrong impression that it is ready yet for multiple clients.

I see. Then to avoid confusions you could remove all clients and keep
only graphics from ocmem_client enum.

> 
> All I know is the gpu uses it statically and is pretty much useless
> without ocmem, so for lack of understanding of the other use cases I
> just tried to add simply what the gpu needs..

Got it now, thanks.

-- 
regards,
Stan

[PATCH] drm: Hack around CONFIG_AGP=m build failures

[Jani Nikula]

On Thu, 01 Oct 2015, Daniel Vetter  wrote:
> Surprisingly kbuild can't cope with tristates in the
> -$(CONFIG_FOO) pattern. This patch hacks up a solution.

Given that it's two distinct Makefile variables (foo-y and foo-m) being
assigned to, I don't really find this surprising. Maybe this could be
made to work as a convenience, but there might be other, more surpising
consequences.

> Reported-by: Stephen Rothwell 
> Reported-by: Ville Syrjälä 
> Cc: Stephen Rothwell 
> Cc: Ville Syrjälä 
> Cc: Michal Marek 
> Cc: linux-kbuild at vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index f458d6e33655..e814517513ce 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -21,6 +21,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>  drm-$(CONFIG_OF) += drm_of.o
>  drm-$(CONFIG_AGP) += drm_agpsupport.o
>  
> +drm-y += $(drm-m)

I know what you're doing here, but somehow this looks wrong to me. A bit
of git grep also doesn't find convincing arguments to back this up.

I'd solve this with a bit of fairly straightforward indirection in the
Kconfig to keep the Makefile itself neat. I think it also better
documents the intention here.

Patch follows.

BR,
Jani.


>From efbc9fb6f6284e81a4b9e7599b3233b656cec452 Mon Sep 17 00:00:00 2001
From: Jani Nikula 
Date: Thu, 1 Oct 2015 10:53:22 +0300
Subject: [PATCH] drm: fix CONFIG_AGP=m build failures
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Cc: Jani Nikula 

If CONFIG_AGP is enabled as a module, drm_agpsupport.o is not linked
into drm, causing:

ERROR: "drm_agp_unbind_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_init" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_alloc_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_clear" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_info_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_enable_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_release_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_bind_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_acquire_ioctl" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "drm_agp_free_ioctl" [drivers/gpu/drm/drm.ko] undefined!

Regression from
commit a7fb8a23c1afa607ec8ce9f61df645f37c529434
Author: Daniel Vetter 
Date:   Wed Sep 9 16:45:52 2015 +0200

drm: Remove __OS_HAS_AGP

Add an intermediate bool CONFIG_DRM_AGP, selected if CONFIG_AGP is
enabled either as module or built-in.

Reported-by: Stephen Rothwell 
Reported-by: Ville Syrjälä 
Cc: Stephen Rothwell 
Cc: Ville Syrjälä 
Cc: Michal Marek 
Cc: linux-kbuild at vger.kernel.org
Cc: Daniel Vetter 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/Kconfig  | 4 
 drivers/gpu/drm/Makefile | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1a0a8df2eed8..aecbec030aa4 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -7,6 +7,7 @@
 menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
support)"
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA
+   select DRM_AGP if AGP
select HDMI
select FB_CMDLINE
select I2C
@@ -21,6 +22,9 @@ menuconfig DRM
  details.  You should also select and configure AGP
  (/dev/agpgart) support if it is available for your platform.

+config DRM_AGP
+   bool
+
 config DRM_MIPI_DSI
bool
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f458d6e33655..c04d5a33fcac 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -19,7 +19,7 @@ drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
-drm-$(CONFIG_AGP) += drm_agpsupport.o
+drm-$(CONFIG_DRM_AGP) += drm_agpsupport.o

 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
-- 
2.1.4

[PATCH libdrm] xf86drm: Fix error handling for drmGetDevices()

[Emil Velikov]

Hi Matt,

On 30 September 2015 at 17:30, Matt Roper  wrote:
> If the opendir() call in drmGetDevices() returns failure, we jump to an
> error label that calls closedir() and then returns.  However this means
> that we're calling closedir(NULL) which may not be safe on all
> implementations.  We are also leaking the local_devices array that was
> allocated before the opendir() call.
>
> Fix both of these issues by jumping to an earlier error label (to free
> local_devices) and guarding the closedir() call with a NULL test.
>
> Cc: Emil Velikov 
> Signed-off-by: Matt Roper 
> ---
>  xf86drm.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index c1cab1b..763d710 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -3209,7 +3209,7 @@ int drmGetDevices(drmDevicePtr devices[], int 
> max_devices)
>  sysdir = opendir(DRM_DIR_NAME);
>  if (!sysdir) {
>  ret = -errno;
> -goto close_sysdir;
> +goto free_locals;
>  }
>
>  i = 0;
> @@ -3280,9 +3280,10 @@ int drmGetDevices(drmDevicePtr devices[], int 
> max_devices)
>
>  free_devices:
>  drmFreeDevices(local_devices, i);
> +free_locals:
>  free(local_devices);
>
> -close_sysdir:
> -closedir(sysdir);
> +if (sysdir)
> +   closedir(sysdir);
Any objections if we move the new label & free() here and drop the if
check above? I can do that before pushing if that's ok with you.

Thanks for catching this.
Emil

[PATCH 1/2] drm: Stop using drm_vblank_count() as the hw frame counter

[Vincent ABRIOU]

On 09/30/2015 04:14 PM, Ville Syrjälä wrote:
> On Wed, Sep 30, 2015 at 04:08:02PM +0200, Daniel Vetter wrote:
>> On Wed, Sep 30, 2015 at 04:46:48PM +0300, ville.syrjala at linux.intel.com 
>> wrote:
>>> From: Ville Syrjälä 
>>>
>>> drm_vblank_count() returns the software counter. We should not pretend
>>> it's the hw counter since we use the hw counter to figuere out what the
>>> software counter value should be. So instead provide a new function
>>> drm_vblank_no_hw_counter() for drivers that don't have a real hw
>>> counter. The new function simply returns 0, which is about the only
>>> thing it can do.
>>
>> Shouldn't we instead just make the get_vblank_counter hook optional?
>
> Perhaps. But maybe this way would encourage people to go look for a
> hw frame counter in their hardware?
>
>> -Daniel
>>
>>>
>>> Cc: Vincent Abriou 
>>> Cc: Thierry Reding 
>>> Signed-off-by: Ville Syrjälä 
>>> ---
>>>   drivers/gpu/drm/armada/armada_drv.c  |  2 +-
>>>   drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
>>>   drivers/gpu/drm/drm_irq.c    | 17 +++++
>>>   drivers/gpu/drm/exynos/exynos_drm_drv.c  |  2 +-
>>>   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c|  2 +-

The 2 patches have been successfully tested on next-20151001. The 
warning message is gone and hw vblank counter stucks to 0.

Tested-by: Vincent Abriou 

Thanks for the patches

Vincent

[PATCH 6/6] drm/msm: add OCMEM driver

[Stephen Boyd]

On 10/01, Stanimir Varbanov wrote:
> On 09/30/2015 02:45 PM, Rob Clark wrote:
> > On Wed, Sep 30, 2015 at 7:31 AM, Rob Clark  wrote:
> >> On Wed, Sep 30, 2015 at 3:51 AM, Stanimir Varbanov
> >>  wrote:
> >>> On 09/29/2015 10:48 PM, Rob Clark wrote:
> >> was mandatory or just power optimization..  but yes, the plan was to
> >> move it somewhere else (not sure quite where, drivers/doc/qcom?)
> >> sometime..  Preferably when someone who understands all the other
> >> ocmem use-cases better could figure out what we really need to add to
> >> the driver.
> >>
> >> In downstream driver there is a lot of complexity that appears to be
> >> in order to allow two clients to each allocate a portion of a macro
> >> within a region (ie. aggregate_macro_state(), apply_macro_vote(),
> >> etc), and I wanted to figure out if that is even a valid use-case
> >> before trying to make ocmem something that could actually support
> >> multiple clients.
> >>
> >> There is also some complexity about ensuring that if clients aren't
> >> split up on region boundaries, that you don't have one client in
> >> region asking for wide-mode and other for narrow-mode..
> >> (switch_region_mode()) but maybe we could handle that by just
> >> allocating wide from bottom and narrow from top.  Also seems to be
> >> some craziness for allowing one client to pre-empt/evict another.. a
> >> dm engine, etc, etc..
> >>
> >> All I know is gpu just statically allocates one big region aligned
> >> chunk of ocmem, so I ignored the rest of the crazy (maybe or maybe not
> >> hypothetical) use-cases for now...
> 
> OK, I will try to sort out ocmem use cases for vidc driver.
> 

The simplest thing to do is to split the memory between GPU and
vidc statically. The other use cases with preemption and eviction
and DMA add a lot of complexity that we can explore at a later
time if need be.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[RFC v2 1/4] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding

[Philipp Zabel]

Am Mittwoch, den 30.09.2015, 12:13 -0500 schrieb Rob Herring:
> On Mon, Sep 21, 2015 at 3:11 AM, Philipp Zabel  
> wrote:
> > Note how the display-subsystem node overlaps the larb node. Is that
> > acceptable?
> 
> Given what the graph looks like, perhaps. However, do you really need
> a container node? It only serves to provide a list of nodes (e.g. all
> the children) to include as components. There are other ways to
> determine this list. You could find all nodes just searching
> compatible strings for each component. You just need to bind the drm
> driver to some other DT node. Is there no node you can pick as the
> master component?

There is the mmsys clock-controller node at the top of the MMSYS address
space (0x1400-0x14ff):

mmsys: clock-controller at 1400 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
#clock-cells = <1>;
};

Its register space also contains the MMSYS_CONFIG region that controls
the multiplexers between the display function blocks, so that would be a
good candidate.
No driver binds to this node yet, the clocks are registered with
CLK_OF_DECLARE.

I'll try to bind to this node and have the driver find sibling nodes
using their compatible strings.

thanks
Philipp

[RFC v2 1/4] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding

[Philipp Zabel]

Am Mittwoch, den 30.09.2015, 11:57 -0500 schrieb Rob Herring:
> On Wed, Sep 30, 2015 at 10:30 AM, Philipp Zabel  
> wrote:
> > Am Freitag, den 18.09.2015, 15:33 -0500 schrieb Rob Herring:
> >> On Fri, Sep 18, 2015 at 11:11 AM, Philipp Zabel  >> pengutronix.de> wrote:
> >> > From: CK Hu 
> >> >
> >> > Add device tree binding documentation for the display subsystem in
> >> > Mediatek MT8173 SoCs.
> >> >
> >> > Signed-off-by: CK Hu 
> >> > Signed-off-by: Philipp Zabel 
> >> > ---
> >> >  .../bindings/drm/mediatek/mediatek,disp.txt| 131 
> >> > +
> >> >  .../bindings/drm/mediatek/mediatek,dsi.txt |  29 +
> >> >  2 files changed, 160 insertions(+)
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/drm/mediatek/mediatek,disp.txt
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt
> >> >
> >> > diff --git 
> >> > a/Documentation/devicetree/bindings/drm/mediatek/mediatek,disp.txt 
> >> > b/Documentation/devicetree/bindings/drm/mediatek/mediatek,disp.txt
> >> > new file mode 100644
> >> > index 000..a3811bd
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/drm/mediatek/mediatek,disp.txt
> >> > @@ -0,0 +1,131 @@
> >> > +Mediatek display subsystem
> >> > +==
> >> > +
> >> > +The Mediatek display subsystem consists of various DISP function blocks 
> >> > in the
> >> > +MMSYS register space. The connections between them can be configured by 
> >> > output
> >> > +and input selectors in the MMSYS_CONFIG register space and register 
> >> > updates can
> >> > +be synchronized to video frame boundaries with help of a DISP_MUTEX 
> >> > function
> >> > +block.
> >> > +
> >> > +The display-subsystem node binds together all individual device nodes 
> >> > that
> >> > +comprise the DISP subsystem.
> >> > +
> >> > +Required properties:
> >> > +
> >> > +- compatible: "mediatek,-disp"
> >>
> >> > +- components: Should contain a list of phandles pointing to the DISP 
> >> > function
> >> > +  block device nodes.
> >> > +- component-names: Should contain the name of the function block 
> >> > pointed to
> >> > +  by the components phandle of the same index.
> >>
> >> NAK. Group these nodes under a parent node, use of-graph or just don't
> >> put this into DT. Don't invent a new way.
> >
> > If I connect the DISP nodes using of-graph bindings, the full graph will
> > look somewhat like this (including the currently unused function blocks,
> > all properties but ports and endpoints removed for brevity):
> >
> > ovl0 at 1400c000 {
> > port {
> > ovl0_to_color0: endpoint at 0 {
> > remote-endpoint = <_from_ovl0>;
> > };
> >
> > ovl0_to_wdma0: endpoint at 1 {
> > remote-endpoint = <_from_ovl0>;
> > };
> > };
> > };
> >
> > ovl1 at 1400d000 {
> > port {
> > ovl1_to_color1: endpoint at 0 {
> > remote-endpoint = <_from_ovl1>;
> > };
> >
> > ovl1_to_wdma1: endpoint at 1 {
> > remote-endpoint = <_from_ovl1>;
> > };
> > };
> > };
> >
> > rdma0 at 1400e000 {
> > port at 0 {
> > rdma0_from_od: endpoint {
> > remote-endpoint = <_to_rdma0>;
> > };
> > };
> >
> > port at 1 {
> > rdma0_to_ufoe: endpoint at 0 {
> > remote-endpoint = <_from_rdma0>;
> > };
> >
> > rdma0_to_split0: endpoint at 1 {
> > remote-endpoint = <_from_rdma0>;
> > };
> >
> > rdma0_to_color0: endpoint at 2 {
> > remote-endpoint = <_from_rdma0>;
> > };
> > };
> > };
> >
> > rdma1 at 1400f000 {
> > port at 0 {
> > rdma1_from_gamma: endpoint {
> > remote-endpoint = <_to_rdma1>;
> > };
> > };
> >
> > port at 1 {
> > rdma1_to_dsi0: endpoint at 0 {
> > remote-endpoint = <_from_rdma1>;
> > };
> >
> > rdma1_to_dsi1: endpoint at 1 {
> > remote-endpoint = <_from_rdma1>;
> > };
> >
> > rdma1_to_dpi0: endpoint at 2 {
> > remote-endpoint = <_from_rdma1>;
> > };
> >
> >   

[PATCH 00/48] Etnaviv changes RFCv1->RFCv2

[Lucas Stach]

Am Mittwoch, den 30.09.2015, 09:53 +0200 schrieb Christian Gmeiner:
> Hi Lucas,
> 
> 2015-09-28 12:39 GMT+02:00 Lucas Stach :
> > Hi Christian,
> >
> > Am Montag, den 28.09.2015, 11:46 +0200 schrieb Christian Gmeiner:
> >> Hi Lucas.
> >>
> >> I think I have run into a cache flush / cache coherency issue. I will
> >> try to reproduce this issue with a small example and will
> >> keep you updated.
> >
> > What are the symptoms of the issue you are hitting? Maybe I can
> > reproduce or see if I have an idea right away.
> >
> 
> With the help of the etnaviv_2d_test in my libdrm repo on github I was able
> to test different bo flags.
> 
> ETNA_BO_UNCACHED and ETNA_BO_CACHED are working as expected.
> The rendering result looks as expected. If I try ETNA_BO_WC the rendering
> result looks different for every run.
> 
I have an idea what's going wrong here. Will keep you updated.

Regards,
Lucas

> debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1
> Version: 1.0.0
>   Name: etnaviv
>   Date: 20150910
>   Description: etnaviv DRM
> bo cpu prep: 0
> debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp
> 052880d433e1bf495e268206addd4087  /tmp/etna.bmp
> debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1
> Version: 1.0.0
>   Name: etnaviv
>   Date: 20150910
>   Description: etnaviv DRM
> bo cpu prep: 0
> debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp
> f1a02a52d81c0b79b098877e6b7d9303  /tmp/etna.bmp
> debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1
> Version: 1.0.0
>   Name: etnaviv
>   Date: 20150910
>   Description: etnaviv DRM
> bo cpu prep: 0
> debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp
> de5a428eb1f6567849ef40a944a995b8  /tmp/etna.bmp
> 
> etna_cmd_stream_finish() waits until the submitted command stream was
> processed by the GPU. I tried to use etna_bo_cpu_prep(..) but I that did not
> help.
> 
> I am doing something wrong? Should this work in theory?
> 
> diff --git a/tests/etnaviv/etnaviv_2d_test.c b/tests/etnaviv/etnaviv_2d_test.c
> index e1ee8a8..037da5b 100644
> --- a/tests/etnaviv/etnaviv_2d_test.c
> +++ b/tests/etnaviv/etnaviv_2d_test.c
> @@ -200,7 +200,7 @@ int main(int argc, char *argv[])
> goto fail;
> }
> 
> -   bmp = etna_bo_new(dev, bmp_size, ETNA_BO_UNCACHED);
> +   bmp = etna_bo_new(dev, bmp_size, ETNA_BO_WC);
> if (!bmp) {
> ret = 5;
> goto fail;
> @@ -218,8 +218,10 @@ int main(int argc, char *argv[])
> 
> etna_cmd_stream_finish(stream);
> 
> +   int state = etna_bo_cpu_prep(bmp, DRM_ETNA_PREP_READ);
> +   printf("bo cpu prep: %d\n", state);
> bmp_dump32(etna_bo_map(bmp), width, height, false, "/tmp/etna.bmp");
> -
> +   etna_bo_cpu_fini(bmp);
>  fail:
> if (stream)
> etna_cmd_stream_del(stream);
> 
> Greets
> --
> Christian Gmeiner, MSc
> 
> https://soundcloud.com/christian-gmeiner

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH 2/2] drm: Use DRM_ROTATE_MASK and DRM_REFLECT_MASK

[Ville Syrjälä]

On Thu, Oct 01, 2015 at 10:00:58AM +0300, Joonas Lahtinen wrote:
> Avoid magic numbers and use the introduced defines.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
>  drivers/gpu/drm/drm_crtc.c  | 3 ++-
>  drivers/gpu/drm/drm_rect.c  | 4 ++--
>  drivers/gpu/drm/omapdrm/omap_fb.c   | 4 ++--
>  drivers/gpu/drm/omapdrm/omap_plane.c| 2 +-
>  5 files changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 36fda86..d0299ae 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -633,7 +633,7 @@ static int atmel_hlcdc_plane_atomic_check(struct 
> drm_plane *p,
>   if (!state->bpp[i])
>   return -EINVAL;
>  
> - switch (state->base.rotation & 0xf) {
> + switch (state->base.rotation & DRM_ROTATE_MASK) {
>   case BIT(DRM_ROTATE_90):
>   offset = ((y_offset + state->src_y + patched_src_w - 1) 
> /
> ydiv) * fb->pitches[i];
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e600a5f..e7c8422 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5629,7 +5629,8 @@ unsigned int drm_rotation_simplify(unsigned int 
> rotation,
>  {
>   if (rotation & ~supported_rotations) {
>   rotation ^= BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y);
> - rotation = (rotation & ~0xf) | BIT((ffs(rotation & 0xf) + 1) % 
> 4);
> + rotation = (rotation & DRM_REFLECT_MASK) |
> +BIT((ffs(rotation & DRM_ROTATE_MASK) + 1) % 4);
>   }
>  
>   return rotation;
> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> index 631f5af..531ac4c 100644
> --- a/drivers/gpu/drm/drm_rect.c
> +++ b/drivers/gpu/drm/drm_rect.c
> @@ -330,7 +330,7 @@ void drm_rect_rotate(struct drm_rect *r,
>   }
>   }

There's also a
'rotation & (BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y))' stuff in these
functions that could be changed to use the new reflect mask instead.

But anyway, the patches look fine, so for both
Reviewed-by: Ville Syrjälä 

PS. I wouldn't be opposed to a patch that kills the BIT() stuff all
over (ie. changes the defines to be of the form 1<  
> - switch (rotation & 0xf) {
> + switch (rotation & DRM_ROTATE_MASK) {
>   case BIT(DRM_ROTATE_0):
>   break;
>   case BIT(DRM_ROTATE_90):
> @@ -390,7 +390,7 @@ void drm_rect_rotate_inv(struct drm_rect *r,
>  {
>   struct drm_rect tmp;
>  
> - switch (rotation & 0xf) {
> + switch (rotation & DRM_ROTATE_MASK) {
>   case BIT(DRM_ROTATE_0):
>   break;
>   case BIT(DRM_ROTATE_90):
> diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
> b/drivers/gpu/drm/omapdrm/omap_fb.c
> index 51b1219..636a1f9 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fb.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
> @@ -171,7 +171,7 @@ void omap_framebuffer_update_scanout(struct 
> drm_framebuffer *fb,
>   uint32_t w = win->src_w;
>   uint32_t h = win->src_h;
>  
> - switch (win->rotation & 0xf) {
> + switch (win->rotation & DRM_ROTATE_MASK) {
>   default:
>   dev_err(fb->dev->dev, "invalid rotation: %02x",
>   (uint32_t)win->rotation);
> @@ -209,7 +209,7 @@ void omap_framebuffer_update_scanout(struct 
> drm_framebuffer *fb,
>   info->rotation_type = OMAP_DSS_ROT_TILER;
>   info->screen_width  = omap_gem_tiled_stride(plane->bo, orient);
>   } else {
> - switch (win->rotation & 0xf) {
> + switch (win->rotation & DRM_ROTATE_MASK) {
>   case 0:
>   case BIT(DRM_ROTATE_0):
>   /* OK */
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index 09e363b..3054bda 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -108,7 +108,7 @@ static void omap_plane_atomic_update(struct drm_plane 
> *plane,
>   win.src_x = state->src_x >> 16;
>   win.src_y = state->src_y >> 16;
>  
> - switch (state->rotation & 0xf) {
> + switch (state->rotation & DRM_ROTATE_MASK) {
>   case BIT(DRM_ROTATE_90):
>   case BIT(DRM_ROTATE_270):
>   win.src_w = state->src_h >> 16;
> -- 
> 2.4.3

-- 
Ville Syrjälä
Intel OTC

[PATCH] drm: Hack around CONFIG_AGP=m build failures

[Ville Syrjälä]

On Thu, Oct 01, 2015 at 08:48:39AM +0200, Daniel Vetter wrote:
> Surprisingly kbuild can't cope with tristates in the
> -$(CONFIG_FOO) pattern. This patch hacks up a solution.
> 
> Reported-by: Stephen Rothwell 
> Reported-by: Ville Syrjälä 
> Cc: Stephen Rothwell 
> Cc: Ville Syrjälä 
> Cc: Michal Marek 
> Cc: linux-kbuild at vger.kernel.org
> Signed-off-by: Daniel Vetter 

Tested-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index f458d6e33655..e814517513ce 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -21,6 +21,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>  drm-$(CONFIG_OF) += drm_of.o
>  drm-$(CONFIG_AGP) += drm_agpsupport.o
>  
> +drm-y += $(drm-m)
> +
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
>   drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
>  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> -- 
> 2.5.1

-- 
Ville Syrjälä
Intel OTC

[PATCH 2/2] drm: Use DRM_ROTATE_MASK and DRM_REFLECT_MASK

[Joonas Lahtinen]

Avoid magic numbers and use the introduced defines.

Cc: Ville Syrjälä 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
 drivers/gpu/drm/drm_crtc.c  | 3 ++-
 drivers/gpu/drm/drm_rect.c  | 4 ++--
 drivers/gpu/drm/omapdrm/omap_fb.c   | 4 ++--
 drivers/gpu/drm/omapdrm/omap_plane.c| 2 +-
 5 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 36fda86..d0299ae 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -633,7 +633,7 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_plane 
*p,
if (!state->bpp[i])
return -EINVAL;

-   switch (state->base.rotation & 0xf) {
+   switch (state->base.rotation & DRM_ROTATE_MASK) {
case BIT(DRM_ROTATE_90):
offset = ((y_offset + state->src_y + patched_src_w - 1) 
/
  ydiv) * fb->pitches[i];
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e600a5f..e7c8422 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5629,7 +5629,8 @@ unsigned int drm_rotation_simplify(unsigned int rotation,
 {
if (rotation & ~supported_rotations) {
rotation ^= BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y);
-   rotation = (rotation & ~0xf) | BIT((ffs(rotation & 0xf) + 1) % 
4);
+   rotation = (rotation & DRM_REFLECT_MASK) |
+  BIT((ffs(rotation & DRM_ROTATE_MASK) + 1) % 4);
}

return rotation;
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index 631f5af..531ac4c 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -330,7 +330,7 @@ void drm_rect_rotate(struct drm_rect *r,
}
}

-   switch (rotation & 0xf) {
+   switch (rotation & DRM_ROTATE_MASK) {
case BIT(DRM_ROTATE_0):
break;
case BIT(DRM_ROTATE_90):
@@ -390,7 +390,7 @@ void drm_rect_rotate_inv(struct drm_rect *r,
 {
struct drm_rect tmp;

-   switch (rotation & 0xf) {
+   switch (rotation & DRM_ROTATE_MASK) {
case BIT(DRM_ROTATE_0):
break;
case BIT(DRM_ROTATE_90):
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 51b1219..636a1f9 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -171,7 +171,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
uint32_t w = win->src_w;
uint32_t h = win->src_h;

-   switch (win->rotation & 0xf) {
+   switch (win->rotation & DRM_ROTATE_MASK) {
default:
dev_err(fb->dev->dev, "invalid rotation: %02x",
(uint32_t)win->rotation);
@@ -209,7 +209,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
info->rotation_type = OMAP_DSS_ROT_TILER;
info->screen_width  = omap_gem_tiled_stride(plane->bo, orient);
} else {
-   switch (win->rotation & 0xf) {
+   switch (win->rotation & DRM_ROTATE_MASK) {
case 0:
case BIT(DRM_ROTATE_0):
/* OK */
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 09e363b..3054bda 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -108,7 +108,7 @@ static void omap_plane_atomic_update(struct drm_plane 
*plane,
win.src_x = state->src_x >> 16;
win.src_y = state->src_y >> 16;

-   switch (state->rotation & 0xf) {
+   switch (state->rotation & DRM_ROTATE_MASK) {
case BIT(DRM_ROTATE_90):
case BIT(DRM_ROTATE_270):
win.src_w = state->src_h >> 16;
-- 
2.4.3

[PATCH 1/2] drm: Add DRM_ROTATE_MASK and DRM_REFLECT_MASK

[Joonas Lahtinen]

Makes it cleaner to separate the two from rotation variable.

Cc: Ville Syrjälä 
Signed-off-by: Joonas Lahtinen 
---
 include/drm/drm_crtc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 683f142..33ddedd 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -86,10 +86,12 @@ static inline uint64_t I642U64(int64_t val)
 }

 /* rotation property bits */
+#define DRM_ROTATE_MASK 0x0f
 #define DRM_ROTATE_0   0
 #define DRM_ROTATE_90  1
 #define DRM_ROTATE_180 2
 #define DRM_ROTATE_270 3
+#define DRM_REFLECT_MASK (~DRM_ROTATE_MASK)
 #define DRM_REFLECT_X  4
 #define DRM_REFLECT_Y  5

-- 
2.4.3

[PATCH v3 5/5] [media] imx-ipu: Add i.MX IPUv3 scaler driver

[Jean-Michel Hautbois]

Hi Philipp, Hans,


2015-07-24 17:12 GMT+02:00 Hans Verkuil :
> Hi Philipp,
>
> A quick review of this driver:
>
> On 07/16/2015 06:24 PM, Philipp Zabel wrote:
>> From: Sascha Hauer 
>>
>> This patch adds support for hardware accelerated scaling and color
>> space conversion between memory buffers using the IPUv3 IC.
>> Since the maximum output size of the IC unit is 1024x1024 pixels, multiple
>> IC tasks with overlapping tiles are used internally to scale and convert
>> larger frames.
>>
>> The IC operates with a burst size of at least 8 pixels. Depending on the
>> frame width and scaling factor, up to 7 junk pixels may be written after
>> the end of the frame. The sizeimage is increased accordingly.
>>
>> Signed-off-by: Sascha Hauer 
>> Signed-off-by: Michael Olbrich 
>> Signed-off-by: Philipp Zabel 
>> ---
>> Changes since v2:
>>  - Disabled USERPTR memory, hardware doesn't support it.
>>  - Embedded struct video_device in ipu_scale_dev.
>>  - Set icc pointer to NULL on error.
>>  - Fixed module description.
>> ---
>>  drivers/media/platform/imx/Kconfig  |   9 +
>>  drivers/media/platform/imx/Makefile |   1 +
>>  drivers/media/platform/imx/imx-ipu-scaler.c | 859 
>> 
>>  drivers/media/platform/imx/imx-ipu.c|   2 +-
>>  drivers/media/platform/imx/imx-ipu.h|   1 +
>>  5 files changed, 871 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/media/platform/imx/imx-ipu-scaler.c
>>
>> diff --git a/drivers/media/platform/imx/Kconfig 
>> b/drivers/media/platform/imx/Kconfig
>> index a90c973..4694367 100644
>> --- a/drivers/media/platform/imx/Kconfig
>> +++ b/drivers/media/platform/imx/Kconfig
>> @@ -1,2 +1,11 @@
>>  config VIDEO_IMX_IPU_COMMON
>>   tristate
>> +
>> +config VIDEO_IMX_IPU_SCALER
>> + tristate "i.MX5/6 IPUv3 based image scaler driver"
>> + depends on VIDEO_DEV && IMX_IPUV3_CORE
>> + select VIDEOBUF2_DMA_CONTIG
>> + select VIDEO_IMX_IPU_COMMON
>> + select V4L2_MEM2MEM_DEV
>> + ---help---
>> +   This is a v4l2 scaler video driver for the IPUv3 on i.MX5/6.
>> diff --git a/drivers/media/platform/imx/Makefile 
>> b/drivers/media/platform/imx/Makefile
>> index 5de119c..f20aa0b 100644
>> --- a/drivers/media/platform/imx/Makefile
>> +++ b/drivers/media/platform/imx/Makefile
>> @@ -1 +1,2 @@
>>  obj-$(CONFIG_VIDEO_IMX_IPU_COMMON)   += imx-ipu.o
>> +obj-$(CONFIG_VIDEO_IMX_IPU_SCALER)   += imx-ipu-scaler.o
>> diff --git a/drivers/media/platform/imx/imx-ipu-scaler.c 
>> b/drivers/media/platform/imx/imx-ipu-scaler.c
>> new file mode 100644
>> index 000..6c6d0aa
>> --- /dev/null
>> +++ b/drivers/media/platform/imx/imx-ipu-scaler.c
>> @@ -0,0 +1,860 @@
>> +/*
>> + * i.MX IPUv3 scaler driver
>> + *
>> + * Copyright (C) 2011 Sascha Hauer, Pengutronix
>> + *
>> + * based on the mem2mem test driver
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "imx-ipu.h"
>> +
>> +#define MIN_W 32
>> +#define MIN_H 32
>> +#define MAX_W 4096
>> +#define MAX_H 4096
>> +#define DIM_ALIGN_MASK 0x08 /* 8-alignment for dimensions */
>> +
>> +/* Flags that indicate a format can be used for capture/output */
>> +#define MEM2MEM_CAPTURE  (1 << 0)
>> +#define MEM2MEM_OUTPUT   (1 << 1)
>> +
>> +#define MEM2MEM_NAME "imx-ipuv3-scale"
>> +
>> +/* Per queue */
>> +#define MEM2MEM_DEF_NUM_BUFS VIDEO_MAX_FRAME
>> +/* In bytes, per queue */
>> +#define MEM2MEM_VID_MEM_LIMIT(64 * 1024 * 1024)
>> +
>> +#define fh_to_ctx(__fh)  container_of(__fh, struct ipu_scale_ctx, fh)
>> +
>> +enum {
>> + V4L2_M2M_SRC = 0,
>> + V4L2_M2M_DST = 1,
>> +};
>> +
>> +struct ipu_scale_dev {
>> + struct v4l2_device  v4l2_dev;
>> + struct video_device vfd;
>> + struct device   *dev;
>> + struct ipu_soc  *ipu;
>> +
>> + atomic_tnum_inst;
>> + spinlock_t  irqlock;
>> +
>> + struct v4l2_m2m_dev *m2m_dev;
>> + struct mutexdev_mutex;
>> +};
>> +
>> +/* Per-queue, driver-specific private data */
>> +struct ipu_scale_q_data {
>> + struct v4l2_pix_format  cur_fmt;
>> + struct v4l2_rectrect;
>> +};
>> +
>> +struct ipu_scale_ctx {
>> + struct ipu_scale_dev*ipu_scaler;
>> +
>> + struct v4l2_fh  fh;
>> + struct vb2_alloc_ctx

[PATCH] drm: Don't zero vblank timestamps from the irq handler

[Daniel Vetter]

On Thu, Oct 01, 2015 at 09:27:20AM +0200, Thierry Reding wrote:
> On Wed, Sep 30, 2015 at 07:21:34PM +0300, ville.syrjala at linux.intel.com 
> wrote:
> > From: Ville Syrjälä 
> > 
> > If we couldn't get a high precisions vblank timestamp, we currently
> > store a zeroed timestamp instead and assume the next vblank irq to
> > get us something better. This makes sense when trying to update the
> > timestamp from eg. vblank enable. But if we do this from the vblank
> > irq we will never get a vblank timestamp unless we high precision
> > timestamps are available and succeeded. This break weston for instance
> > on drivers lacking high precision timestamps.
> > 
> > To fix this, zero the timestamp only when not called from vbl irq.
> > When called from the irq, we still want the timestamp, even if not
> > perfect.
> > 
> > This fixes a regression from
> > 4dfd64862ff852df drm: Use vblank timestamps to guesstimate how many vblanks 
> > were missed
> > 
> > Cc: Mario Kleiner 
> > Cc: Thierry Reding 
> > Reported-by: Thierry Reding 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_irq.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> Applied on top of next-20151001 and the weston problem I was seeing is
> gone, so:
> 
> Tested-by: Thierry Reding 
> 
> I think it might be worth considering squashing this into the offending
> commit to avoid breaking bisectibility.

Can't squash any more since history is frozen in drm-next. Applied to
drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: Don't zero vblank timestamps from the irq handler

[Thierry Reding]

On Wed, Sep 30, 2015 at 07:21:34PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrjälä 
> 
> If we couldn't get a high precisions vblank timestamp, we currently
> store a zeroed timestamp instead and assume the next vblank irq to
> get us something better. This makes sense when trying to update the
> timestamp from eg. vblank enable. But if we do this from the vblank
> irq we will never get a vblank timestamp unless we high precision
> timestamps are available and succeeded. This break weston for instance
> on drivers lacking high precision timestamps.
> 
> To fix this, zero the timestamp only when not called from vbl irq.
> When called from the irq, we still want the timestamp, even if not
> perfect.
> 
> This fixes a regression from
> 4dfd64862ff852df drm: Use vblank timestamps to guesstimate how many vblanks 
> were missed
> 
> Cc: Mario Kleiner 
> Cc: Thierry Reding 
> Reported-by: Thierry Reding 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_irq.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

Applied on top of next-20151001 and the weston problem I was seeing is
gone, so:

Tested-by: Thierry Reding 

I think it might be worth considering squashing this into the offending
commit to avoid breaking bisectibility.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151001/09e97c7b/attachment.sig>

[PATCH libdrm] xf86drm: Fix error handling for drmGetDevices()

[Matt Roper]

On Thu, Oct 01, 2015 at 11:12:34AM +0100, Emil Velikov wrote:
> Hi Matt,
> 
> On 30 September 2015 at 17:30, Matt Roper  
> wrote:
> > If the opendir() call in drmGetDevices() returns failure, we jump to an
> > error label that calls closedir() and then returns.  However this means
> > that we're calling closedir(NULL) which may not be safe on all
> > implementations.  We are also leaking the local_devices array that was
> > allocated before the opendir() call.
> >
> > Fix both of these issues by jumping to an earlier error label (to free
> > local_devices) and guarding the closedir() call with a NULL test.
> >
> > Cc: Emil Velikov 
> > Signed-off-by: Matt Roper 
> > ---
> >  xf86drm.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/xf86drm.c b/xf86drm.c
> > index c1cab1b..763d710 100644
> > --- a/xf86drm.c
> > +++ b/xf86drm.c
> > @@ -3209,7 +3209,7 @@ int drmGetDevices(drmDevicePtr devices[], int 
> > max_devices)
> >  sysdir = opendir(DRM_DIR_NAME);
> >  if (!sysdir) {
> >  ret = -errno;
> > -goto close_sysdir;
> > +goto free_locals;
> >  }
> >
> >  i = 0;
> > @@ -3280,9 +3280,10 @@ int drmGetDevices(drmDevicePtr devices[], int 
> > max_devices)
> >
> >  free_devices:
> >  drmFreeDevices(local_devices, i);
> > +free_locals:
> >  free(local_devices);
> >
> > -close_sysdir:
> > -closedir(sysdir);
> > +if (sysdir)
> > +   closedir(sysdir);
> Any objections if we move the new label & free() here and drop the if
> check above? I can do that before pushing if that's ok with you.
> 
> Thanks for catching this.
> Emil

Sure, that sounds fine too.  Thanks!


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

[PATCH] drm: Hack around CONFIG_AGP=m build failures

[Daniel Vetter]

Surprisingly kbuild can't cope with tristates in the
-$(CONFIG_FOO) pattern. This patch hacks up a solution.

Reported-by: Stephen Rothwell 
Reported-by: Ville Syrjälä 
Cc: Stephen Rothwell 
Cc: Ville Syrjälä 
Cc: Michal Marek 
Cc: linux-kbuild at vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f458d6e33655..e814517513ce 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -21,6 +21,8 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o

+drm-y += $(drm-m)
+
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
-- 
2.5.1

linux-next: build failure after merge of the drm-misc tree

[Daniel Vetter]

On Thu, Oct 01, 2015 at 12:47:17PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "drm_agp_release" [drivers/gpu/drm/radeon/radeon.ko] undefined!
> ERROR: "drm_agp_acquire" [drivers/gpu/drm/radeon/radeon.ko] undefined!
> ERROR: "drm_agp_enable" [drivers/gpu/drm/radeon/radeon.ko] undefined!
> ERROR: "drm_agp_info" [drivers/gpu/drm/radeon/radeon.ko] undefined!
> ERROR: "drm_agp_release" [drivers/gpu/drm/mga/mga.ko] undefined!
> ERROR: "drm_agp_acquire" [drivers/gpu/drm/mga/mga.ko] undefined!
> ERROR: "drm_agp_free" [drivers/gpu/drm/mga/mga.ko] undefined!
> ERROR: "drm_agp_bind" [drivers/gpu/drm/mga/mga.ko] undefined!
> ERROR: "drm_agp_unbind" [drivers/gpu/drm/mga/mga.ko] undefined!
> ERROR: "drm_agp_alloc" [drivers/gpu/drm/mga/mga.ko] undefined!
> ERROR: "drm_agp_enable" [drivers/gpu/drm/mga/mga.ko] undefined!
> ERROR: "drm_agp_info" [drivers/gpu/drm/mga/mga.ko] undefined!
> ERROR: "drm_agp_unbind_ioctl" [drivers/gpu/drm/drm.ko] undefined!
> ERROR: "drm_agp_init" [drivers/gpu/drm/drm.ko] undefined!
> ERROR: "drm_agp_alloc_ioctl" [drivers/gpu/drm/drm.ko] undefined!
> ERROR: "drm_agp_clear" [drivers/gpu/drm/drm.ko] undefined!
> ERROR: "drm_agp_info_ioctl" [drivers/gpu/drm/drm.ko] undefined!
> ERROR: "drm_agp_enable_ioctl" [drivers/gpu/drm/drm.ko] undefined!
> ERROR: "drm_agp_release_ioctl" [drivers/gpu/drm/drm.ko] undefined!
> ERROR: "drm_agp_bind_ioctl" [drivers/gpu/drm/drm.ko] undefined!
> ERROR: "drm_agp_acquire_ioctl" [drivers/gpu/drm/drm.ko] undefined!
> ERROR: "drm_agp_free_ioctl" [drivers/gpu/drm/drm.ko] undefined!
> 
> Not quite sure which commit caused this, but I have used the drm-misc
> tree from next-20150930 for today.

Build fail for CONFIG_AGP=m (bot not y or n). I'm wrestling kbuild atm.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/2] of: Add vendor prefix for QiaoDian Xianshi

[Rob Herring]

On Wed, Sep 30, 2015 at 5:54 PM, Alexandre Belloni
 wrote:
> On 30/09/2015 at 17:16:10 -0500, Rob Herring wrote :
>> On Wed, Sep 30, 2015 at 4:42 PM, Alexandre Belloni
>>  wrote:
>> > Use "qiaodian" as the vendor prefix for QiaoDian Xianshi Corporation in
>> > device tree compatible strings.
>> >
>> > Signed-off-by: Alexandre Belloni 
>> > ---
>> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> > b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> > index ac5f0c34ae00..76579e2ef162 100644
>> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> > @@ -174,6 +174,7 @@ qca Qualcomm Atheros, Inc.
>> >  qcom   Qualcomm Technologies, Inc
>> >  qemu   QEMU, a generic and open source machine emulator and virtualizer
>> >  qi Qi Hardware
>> > +qd QiaoDian XianShi Corporation
>>
>> Doesn't match the commit msg...
>>
>
> Yeah, I was not sure which one I should use actually, is "qd"
> sufficient? I couldn't find much information on the company, I chose to
> use the prefix they use for their parts.

I would lean toward qiaodian, but either is fine.

Rob

[RFC v2 1/4] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding

[Rob Herring]

On Thu, Oct 1, 2015 at 3:59 AM, Philipp Zabel  wrote:
> Am Mittwoch, den 30.09.2015, 12:13 -0500 schrieb Rob Herring:
>> On Mon, Sep 21, 2015 at 3:11 AM, Philipp Zabel  
>> wrote:
>> > Note how the display-subsystem node overlaps the larb node. Is that
>> > acceptable?
>>
>> Given what the graph looks like, perhaps. However, do you really need
>> a container node? It only serves to provide a list of nodes (e.g. all
>> the children) to include as components. There are other ways to
>> determine this list. You could find all nodes just searching
>> compatible strings for each component. You just need to bind the drm
>> driver to some other DT node. Is there no node you can pick as the
>> master component?
>
> There is the mmsys clock-controller node at the top of the MMSYS address
> space (0x1400-0x14ff):
>
> mmsys: clock-controller at 1400 {
> compatible = "mediatek,mt8173-mmsys", "syscon";
> reg = <0 0x1400 0 0x1000>;
> #clock-cells = <1>;
> };
>
> Its register space also contains the MMSYS_CONFIG region that controls
> the multiplexers between the display function blocks, so that would be a
> good candidate.
> No driver binds to this node yet, the clocks are registered with
> CLK_OF_DECLARE.
>
> I'll try to bind to this node and have the driver find sibling nodes
> using their compatible strings.

That doesn't seem like a good choice since there are other functions
in the block. I was thinking one of the display related blocks like
whatever block provides the main crtc functions.

Rob

[Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

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

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

--- Comment #10 from Michel Dänzer  ---
It may be easier to contact the apple-gmux developers via e-mail. The
scripts/get_maintainer.pl script should be useful for that.

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

[git pull] vmwgfx-fixes-4.3

[Thomas Hellstrom]

Dave, 

A single commit to fix a command submission hang regression.


The following changes since commit 30c64664f110f76064e364cb5dd385edc3751ba5:

  drm: Allow also control clients to check the drm version (2015-09-24 00:24:24 
-0700)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux tags/vmwgfx-fixes-4.3-151001

for you to fetch changes up to 575f9c8604e0b4c7b36fb41fc5fd280a3c336906:

  drm/vmwgfx: Fix a command submission hang regression (2015-09-30 05:50:37 
-0700)


Pull request of 2015-10-01


Thomas Hellstrom (1):
  drm/vmwgfx: Fix a command submission hang regression

 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 
 1 file changed, 8 insertions(+)

[PATCH 1/2] drm/vmwgfx: use kzalloc in vmw_surface_define_ioctl()

[kbuild test robot]

Hi Rasmus,

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:771:1-13: alloc with no test, 
>> possible model on line 817

vim +771 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c

543831cf Thomas Hellstrom 2012-11-20  765  
543831cf Thomas Hellstrom 2012-11-20  766   srf->sizes = 
kmalloc(srf->num_sizes * sizeof(*srf->sizes), GFP_KERNEL);
543831cf Thomas Hellstrom 2012-11-20  767   if (unlikely(srf->sizes == 
NULL)) {
543831cf Thomas Hellstrom 2012-11-20  768   ret = -ENOMEM;
543831cf Thomas Hellstrom 2012-11-20  769   goto out_no_sizes;
543831cf Thomas Hellstrom 2012-11-20  770   }
543831cf Thomas Hellstrom 2012-11-20 @771   srf->offsets = 
kmalloc(srf->num_sizes * sizeof(*srf->offsets),
543831cf Thomas Hellstrom 2012-11-20  772  
GFP_KERNEL);
543831cf Thomas Hellstrom 2012-11-20  773   if (unlikely(srf->sizes == 
NULL)) {
543831cf Thomas Hellstrom 2012-11-20  774   ret = -ENOMEM;
543831cf Thomas Hellstrom 2012-11-20  775   goto out_no_offsets;
543831cf Thomas Hellstrom 2012-11-20  776   }
543831cf Thomas Hellstrom 2012-11-20  777  
543831cf Thomas Hellstrom 2012-11-20  778   user_sizes = (struct 
drm_vmw_size __user *)(unsigned long)
543831cf Thomas Hellstrom 2012-11-20  779   req->size_addr;
543831cf Thomas Hellstrom 2012-11-20  780  
543831cf Thomas Hellstrom 2012-11-20  781   ret = 
copy_from_user(srf->sizes, user_sizes,
543831cf Thomas Hellstrom 2012-11-20  782
srf->num_sizes * sizeof(*srf->sizes));
543831cf Thomas Hellstrom 2012-11-20  783   if (unlikely(ret != 0)) {
543831cf Thomas Hellstrom 2012-11-20  784   ret = -EFAULT;
543831cf Thomas Hellstrom 2012-11-20  785   goto out_no_copy;
543831cf Thomas Hellstrom 2012-11-20  786   }
543831cf Thomas Hellstrom 2012-11-20  787  
543831cf Thomas Hellstrom 2012-11-20  788   srf->base_size = *srf->sizes;
543831cf Thomas Hellstrom 2012-11-20  789   srf->autogen_filter = 
SVGA3D_TEX_FILTER_NONE;
15c6f656 Zack Rusin   2012-11-21  790   srf->multisample_count = 0;
543831cf Thomas Hellstrom 2012-11-20  791  
543831cf Thomas Hellstrom 2012-11-20  792   cur_bo_offset = 0;
543831cf Thomas Hellstrom 2012-11-20  793   cur_offset = srf->offsets;
543831cf Thomas Hellstrom 2012-11-20  794   cur_size = srf->sizes;
543831cf Thomas Hellstrom 2012-11-20  795  
543831cf Thomas Hellstrom 2012-11-20  796   for (i = 0; i < 
DRM_VMW_MAX_SURFACE_FACES; ++i) {
543831cf Thomas Hellstrom 2012-11-20  797   for (j = 0; j < 
srf->mip_levels[i]; ++j) {
7e8d9da3 Thomas Hellstrom 2012-11-20  798   uint32_t stride 
= svga3dsurface_calculate_pitch
7e8d9da3 Thomas Hellstrom 2012-11-20  799   (desc, 
cur_size);
543831cf Thomas Hellstrom 2012-11-20  800  
543831cf Thomas Hellstrom 2012-11-20  801   
cur_offset->face = i;
543831cf Thomas Hellstrom 2012-11-20  802   cur_offset->mip 
= j;
543831cf Thomas Hellstrom 2012-11-20  803   
cur_offset->bo_offset = cur_bo_offset;
7e8d9da3 Thomas Hellstrom 2012-11-20  804   cur_bo_offset 
+= svga3dsurface_get_image_buffer_size
7e8d9da3 Thomas Hellstrom 2012-11-20  805   (desc, 
cur_size, stride);
543831cf Thomas Hellstrom 2012-11-20  806   ++cur_offset;
543831cf Thomas Hellstrom 2012-11-20  807   ++cur_size;
543831cf Thomas Hellstrom 2012-11-20  808   }
543831cf Thomas Hellstrom 2012-11-20  809   }
543831cf Thomas Hellstrom 2012-11-20  810   res->backup_size = 
cur_bo_offset;
543831cf Thomas Hellstrom 2012-11-20  811   if (srf->scanout &&
543831cf Thomas Hellstrom 2012-11-20  812   srf->num_sizes == 1 &&
543831cf Thomas Hellstrom 2012-11-20  813   srf->sizes[0].width == 64 &&
543831cf Thomas Hellstrom 2012-11-20  814   srf->sizes[0].height == 64 
&&
543831cf Thomas Hellstrom 2012-11-20  815   srf->format == 
SVGA3D_A8R8G8B8) {
543831cf Thomas Hellstrom 2012-11-20  816  
fc815f88 Rasmus Villemoes 2015-09-30 @817   srf->snooper.image = 
kzalloc(64 * 64 * 4, GFP_KERNEL);
fc815f88 Rasmus Villemoes 2015-09-30  818   if 
(!srf->snooper.image) {
543831cf Thomas Hellstrom 2012-11-20  819   
DRM_ERROR("Failed to allocate cursor_image\n");
543831cf Thomas Hellstrom 2012-11-20  820   ret = -ENOMEM;

:: The code at line 771 was first introduced by commit
:: 543831cfc976669b8da963b3e94933e21e051846 drm/vmwgfx: Break out surface 
and context management to separate files

:: TO: Thomas Hellstrom 
:: CC: Dave Airlie 

---
0-DAY kernel test infrastructureOpen Source Technology Center

WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90() - evildoer found and neutralized

[Jiang Liu]

On 2015/9/30 20:44, Joerg Roedel wrote:
> On Wed, Sep 30, 2015 at 03:45:39PM +0800, Jiang Liu wrote:
>> So we need to figure out why we got irq number 0 after enabling
>> MSI for AMD IOMMU device. The only hint I got is that iommu driver just
>> grabbing the PCI device without providing a PCI device driver for IOMMU
>> PCI device, we have solved a similar case for eata driver. So could you
>> please help to apply this debug patch to gather more info and send me
>> /proc/interrupts?
> 
> I think I have an idea on how dev->irq got 0 after pci_enable_msi(). The
> PCI probe code calls pcibios_alloc_irq() and after a failed probe it calls
> pcibios_free_irq(), which sets dev->irq to 0.
> The AMD IOMMU driver does not register a pci_driver for itself, it just
> doesn't make sense for it. But the PCI device containing the IOMMU gets
> probed later, which fails because there is no driver for it. So the
> following call to pcibios_free_irq() clears dev->irq, so that it is 0 on
> the next resume. Does that make sense?

Thanks Joerg, that makes sense. If some driver tries to binding to the
IOMMU device, it will trigger the scenario as you described. For
example,  Xen backend driver will try to probe all PCI devices
if enabled. I will do more investigation tomorrow.
Thanks!
Gerry

[PATCH 1/2] of: Add vendor prefix for QiaoDian Xianshi

[Alexandre Belloni]

On 30/09/2015 at 17:16:10 -0500, Rob Herring wrote :
> On Wed, Sep 30, 2015 at 4:42 PM, Alexandre Belloni
>  wrote:
> > Use "qiaodian" as the vendor prefix for QiaoDian Xianshi Corporation in
> > device tree compatible strings.
> >
> > Signed-off-by: Alexandre Belloni 
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> > b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index ac5f0c34ae00..76579e2ef162 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -174,6 +174,7 @@ qca Qualcomm Atheros, Inc.
> >  qcom   Qualcomm Technologies, Inc
> >  qemu   QEMU, a generic and open source machine emulator and virtualizer
> >  qi Qi Hardware
> > +qd QiaoDian XianShi Corporation
> 
> Doesn't match the commit msg...
> 

Yeah, I was not sure which one I should use actually, is "qd"
sufficient? I couldn't find much information on the company, I chose to
use the prefix they use for their parts.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 2/2] drm: panel: simple: add QiaoDian qd43003c0-40

[Alexandre Belloni]

And I forgot to add that this is V2, I've just added .bpc.

On 30/09/2015 at 23:42:17 +0200, Alexandre Belloni wrote :
> From: Josh Wu 
> 
> The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel.
> 
> Timings from the OTA5180A document, ver 0.9, section
> 10.1.1:
>   http://www.orientdisplay.com/pdf/OTA5180A.pdf
> 
> Signed-off-by: Josh Wu 
> Signed-off-by: Alexandre Belloni 
> ---
>  .../devicetree/bindings/panel/qd,qd43003c0-40.txt  |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 27 
> ++
>  2 files changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt
> 
> diff --git a/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt 
> b/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt
> new file mode 100644
> index ..900bc6ebeaff
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt
> @@ -0,0 +1,7 @@
> +QiaoDian XianShi Corporation 4"3 TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "qd,qd43003c0-40"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index f97b73ec4713..667cac37d2e5 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1027,6 +1027,30 @@ static const struct panel_desc ortustech_com43h4m85ulc 
> = {
>   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
>  };
>  
> +static const struct drm_display_mode qd43003c0_40_mode = {
> + .clock = 9000,
> + .hdisplay = 480,
> + .hsync_start = 480 + 8,
> + .hsync_end = 480 + 8 + 4,
> + .htotal = 480 + 8 + 4 + 39,
> + .vdisplay = 272,
> + .vsync_start = 272 + 4,
> + .vsync_end = 272 + 4 + 10,
> + .vtotal = 272 + 4 + 10 + 2,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc qd43003c0_40 = {
> + .modes = _40_mode,
> + .num_modes = 1,
> + .bpc = 8,
> + .size = {
> + .width = 95,
> + .height = 53,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> +};
> +
>  static const struct drm_display_mode samsung_ltn101nt05_mode = {
>   .clock = 54030,
>   .hdisplay = 1024,
> @@ -1182,6 +1206,9 @@ static const struct of_device_id platform_of_match[] = {
>   .compatible = "ortustech,com43h4m85ulc",
>   .data = _com43h4m85ulc,
>   }, {
> + .compatible = "qd,qd43003c0-40",
> + .data = _40,
> + }, {
>   .compatible = "samsung,ltn101nt05",
>   .data = _ltn101nt05,
>   }, {
> -- 
> 2.1.4
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 2/2] drm: panel: simple: add QiaoDian qd43003c0-40

[Alexandre Belloni]

From: Josh Wu 

The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel.

Timings from the OTA5180A document, ver 0.9, section
10.1.1:
  http://www.orientdisplay.com/pdf/OTA5180A.pdf

Signed-off-by: Josh Wu 
Signed-off-by: Alexandre Belloni 
---
 .../devicetree/bindings/panel/qd,qd43003c0-40.txt  |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 2 files changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt

diff --git a/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt 
b/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt
new file mode 100644
index ..900bc6ebeaff
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt
@@ -0,0 +1,7 @@
+QiaoDian XianShi Corporation 4"3 TFT LCD panel
+
+Required properties:
+- compatible: should be "qd,qd43003c0-40"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f97b73ec4713..667cac37d2e5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1027,6 +1027,30 @@ static const struct panel_desc ortustech_com43h4m85ulc = 
{
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };

+static const struct drm_display_mode qd43003c0_40_mode = {
+   .clock = 9000,
+   .hdisplay = 480,
+   .hsync_start = 480 + 8,
+   .hsync_end = 480 + 8 + 4,
+   .htotal = 480 + 8 + 4 + 39,
+   .vdisplay = 272,
+   .vsync_start = 272 + 4,
+   .vsync_end = 272 + 4 + 10,
+   .vtotal = 272 + 4 + 10 + 2,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc qd43003c0_40 = {
+   .modes = _40_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 95,
+   .height = 53,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
 static const struct drm_display_mode samsung_ltn101nt05_mode = {
.clock = 54030,
.hdisplay = 1024,
@@ -1182,6 +1206,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "ortustech,com43h4m85ulc",
.data = _com43h4m85ulc,
}, {
+   .compatible = "qd,qd43003c0-40",
+   .data = _40,
+   }, {
.compatible = "samsung,ltn101nt05",
.data = _ltn101nt05,
}, {
-- 
2.1.4

[PATCH 1/2] of: Add vendor prefix for QiaoDian Xianshi

[Alexandre Belloni]

Use "qiaodian" as the vendor prefix for QiaoDian Xianshi Corporation in
device tree compatible strings.

Signed-off-by: Alexandre Belloni 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ac5f0c34ae00..76579e2ef162 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -174,6 +174,7 @@ qca Qualcomm Atheros, Inc.
 qcom   Qualcomm Technologies, Inc
 qemu   QEMU, a generic and open source machine emulator and virtualizer
 qi Qi Hardware
+qd QiaoDian XianShi Corporation
 qnap   QNAP Systems, Inc.
 radxa  Radxa
 raidsonic  RaidSonic Technology GmbH
-- 
2.1.4

[PATCH 1/2] drm/vmwgfx: use kzalloc in vmw_surface_define_ioctl()

[Rasmus Villemoes]

On Wed, Sep 30 2015, kbuild test robot  wrote:

> Hi Rasmus,
>
> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
> ignore]
>
>
> coccinelle warnings: (new ones prefixed by >>)
>
>>> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:771:1-13: alloc with no test, 
>>> possible model on line 817
>
> vim +771 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
>
> 543831cf Thomas Hellstrom 2012-11-20  765  
> 543831cf Thomas Hellstrom 2012-11-20  766 srf->sizes = 
> kmalloc(srf->num_sizes * sizeof(*srf->sizes), GFP_KERNEL);
> 543831cf Thomas Hellstrom 2012-11-20  767 if (unlikely(srf->sizes == 
> NULL)) {
> 543831cf Thomas Hellstrom 2012-11-20  768 ret = -ENOMEM;
> 543831cf Thomas Hellstrom 2012-11-20  769 goto out_no_sizes;
> 543831cf Thomas Hellstrom 2012-11-20  770 }
> 543831cf Thomas Hellstrom 2012-11-20 @771 srf->offsets = 
> kmalloc(srf->num_sizes * sizeof(*srf->offsets),
> 543831cf Thomas Hellstrom 2012-11-20  772
> GFP_KERNEL);
> 543831cf Thomas Hellstrom 2012-11-20  773 if (unlikely(srf->sizes == 
> NULL)) {
> 543831cf Thomas Hellstrom 2012-11-20  774 ret = -ENOMEM;
> 543831cf Thomas Hellstrom 2012-11-20  775 goto out_no_offsets;
> 543831cf Thomas Hellstrom 2012-11-20  776 }
> 543831cf Thomas Hellstrom 2012-11-20  777  

Wauv, that was fast. So, I'm pretty sure this has nothing to do with the
patch I just sent, but there's a bug nevertheless. The NULL test has
been copy-pasted from just above, but we're testing srf->sizes again,
not srf->offsets which we just tried to allocate.

Subject: [PATCH] drm/vmwgfx: check kmalloc return value

srf->sizes has been allocated and checked a few lines above; fix up
the copy-pasto so that we check srf->offsets.

Reported-by: kbuild test robot 
Signed-off-by: Rasmus Villemoes 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 64b50409fa07..0cf0055e0e08 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -770,7 +770,7 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
*data,
}
srf->offsets = kmalloc(srf->num_sizes * sizeof(*srf->offsets),
   GFP_KERNEL);
-   if (unlikely(srf->sizes == NULL)) {
+   if (unlikely(srf->offsets == NULL)) {
ret = -ENOMEM;
goto out_no_offsets;
}