date:20130703

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

--- Comment #2 from Thomas Lindroth  ---
Created attachment 81982
  --> https://bugs.freedesktop.org/attachment.cgi?id=81982=edit
output with R600_DEBUG=sb,ps,vs

Steam also use opengl to draw it's UI so some of these shaders comes from it.

-- 
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/20130703/cf2a3cba/attachment.html>

Best practice device tree design for display subsystems/DRM



> -Original Message-
> From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com]
> Sent: Wednesday, July 03, 2013 7:53 PM
> To: Russell King
> Cc: Inki Dae; 'Sascha Hauer'; 'Daniel Drake'; 'Jean-Francois Moine';
> devicetree-discuss at lists.ozlabs.org; dri-devel at lists.freedesktop.org
> Subject: Re: Best practice device tree design for display subsystems/DRM
> 
> On 07/03/13 11:53, Russell King wrote:
> > On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote:
> >> That's not whether we can write device driver or not. dtsi is common
> spot in
> >> other subsystems. Do you think the cardX node is meaningful to other
> >> subsystems?
> >
> > Yes, because fbdev could also use it to solve the same problem which
> we're
> > having with DRM.
> 
> Inki,
> 
> I do not understand why you keep referring to the SoC dtsi. Im my
> example, I said that it is made up and joined from both SoC dtsi and
> board dts.
> 
> So, of course, lcd controller nodes and dcon are part of dove.dtsi
> because they are physically available on every Dove SoC.
> 
> Also, the connection from lcd0 to the external HDMI encoder node
> is in the board dts because you can happily build a Dove SoC board
> with a different HDMI encoder or with no encoder at all.
> 
> The video-card super node is not in any way specific to DRM and

In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or lcd0
and lcd1 drivers which are placed in drivers/video/backlight/.

And let's assume the following:

On board A
 Display controller - lcd 0
On board B
 Display controller - lcd 1
On board C
 Display controller - lcd 0 and lcd 1

Without the super node, user could configure Linux kernel through menuconfig
like below;
board A:  enabling lcd 0, and disabling lcd 1,
board B: disabling lcd 0, and enabling lcd 1,
board C: enabling lcd 0 and lcd 1.

All we have to do is to configure menuconfig to enable only drivers for
certain board. Why does fbdev need the super node? Please give me comments
if there is my missing point.

Thanks,
Inki Dae

> describes a virtual graphics card comprising both SoC and board
> components (on a per-board basis). You can have both DRM or fbdev
> use that virtual video card node to register your subsystem drivers
> required to provide video output.
> 
> I agree to what Sascha said, the decision to put one or two
> virtual graphics card in the device tree depending on the use
> case is sketchy. You can have one card/two card on the same
> board, so at this point device tree is not describing HW but
> use case.
> 
> But honestly, I see no way around it and it is the only way
> to allow to even have the decision for one or two cards at all.
> There is no way for auto-probing the users intention...
> 
> Sebastian

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

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

--- Comment #5 from Bj?rn Beutel  ---
@Alex Deucher: 

AFAIK, that bug has been in r300g from its very beginnings (in contrast to
r300c).

-- 
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/20130703/540f7778/attachment.html>

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

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

--- Comment #4 from Bj?rn Beutel  ---
Created attachment 81980
  --> https://bugs.freedesktop.org/attachment.cgi?id=81980=edit
Patch that sets the needed CS buffer size in "r300_render_draw_elements"

The attached patch solves the problem for me in Mesa 9.1 and Mesa Git.

For me, it seems as if the buffer is not always properly flushed in between
when "r300_render_draw_elements" has to divide it into two or more runs.

-- 
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/20130703/6c2b3a84/attachment.html>

[Bug 66349] Using SB shader optimization caused segfault in Serious Sam 3: BFE

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

--- Comment #1 from Vadim Girlin  ---
Please attach the output with "R600_DEBUG=sb,ps,vs".

-- 
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/20130703/45a39661/attachment-0001.html>

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

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

--- Comment #3 from Alex Deucher  ---
Is this a regression?  If so, can you bisect?

-- 
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/20130703/a3f8bc8c/attachment.html>

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #81975|text/plain  |image/png
  mime type||

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

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

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

--- Comment #2 from Bj?rn Beutel  ---
Created attachment 81979
  --> https://bugs.freedesktop.org/attachment.cgi?id=81979=edit
dmesg output

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

[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart

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

--- Comment #1 from Bj?rn Beutel  ---
Created attachment 81978
  --> https://bugs.freedesktop.org/attachment.cgi?id=81978=edit
glxinfo output

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

[Bug 66558] New: RS690: 3D artifacts when playing SuperTuxKart

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

  Priority: medium
Bug ID: 66558
  Assignee: dri-devel at lists.freedesktop.org
   Summary: RS690: 3D artifacts when playing SuperTuxKart
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: bjoern-beutel at arcor.de
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r300
   Product: Mesa

Created attachment 81975
  --> https://bugs.freedesktop.org/attachment.cgi?id=81975=edit
Example of corruption in SuperTuxKart

Using the 300g driver from Mesa 9.1, the SuperTuxKart game sometimes shows
artifacts, as show in the attached example.

-- 
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/20130703/47661c3e/attachment.html>

Best practice device tree design for display subsystems/DRM

On 07/03/13 13:32, Russell King wrote:
> On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote:
>> But honestly, I see no way around it and it is the only way
>> to allow to even have the decision for one or two cards at all.
>> There is no way for auto-probing the users intention...

Russell,

in general, for me it is hard to find out when you are really asking
questions, use rhetorical questions or sarcasm. I am not a native 
speaker, so do not take any of the below personal if I am not getting
the point of it.

> It's not _just_ about the users intention - for get that, because really
> it's to do with solving a much bigger question, and that question is:
>
>   How do we know when all the components are present?

By exploiting phandles passed to the supernode. That supernode is very
board specific so it is defined in a board dts and can take into account
every available/unavailable physical device.

> In other words, how do we know that we have LCD0 and LCD1 connected to
> the DCON, which is connected to a LCD and/or a HDMI tranceiver.  How

About LCD0/LCD1 connected to DCON, you have to deal with that in the
subsystem driver, i.e. DRM driver knows about some possible DCON but
registers it only if there is a phandle to a node compatible with
"marvell,armada-510-dcon" passed.

About LCD (panel)/HDMI transceiver, use a (hopefully standard) property
to hook the device (LCD0 on Dove) with the node of the HDMI transmitter.

> do we know that the on-board VGA DACs are wired up and to be used?

Boards not using VGA DAC (LCD1 on Dove) just disable the device_node
and do not pass the node's phandle in the supernode.

> How do we know which I2C bus the VGA port is connected to, and whether
> to expect an I2C bus?

Again, passing a phandle to the i2c-controller node in lcd1 node.
Please note that the pure existence of this phandle property does not
in any way imply you have to use it at all in the driver. But if you
have a driver for Dove's LCD1 and that needs to know how it can access
monitor's EDID, connect it to the i2c-controller node.

I understand that this very i2c-controller driver may not be loaded
the time DRM driver accesses it. But that is not related to DT but
driver core. Currently, I guess -EPROBEDEFER or bail out is the only
option. But from a driver POV you can still say: "somebody told me
to use i2c0 for EDID, so don't blame me it is not there".

> Let's look at the Cubox setup (sorry, but you _will_ have to use a
> fixed-width font for this):
>
> CPU bus
> |
> +-I2C -TDA998X --(HDMI)--> Display
> ||
> |   (RGB888+clock+sync)
> +-LCD0 -.   /
> +--DCON ---(VGA)---> not wired
> +-LCD1 (unused)-'
>
> DCON can allegedly route the data from LCD0 or LCD1 to the parallel
> interface which the TDA998x sits on, and/or the VGA interface.  In
> the case of other setups, the TDA998x may be a LCD panel.

dove.dtsi:
...
soc {
internal-regs {
...
i2c0: i2c-controller at abcd0 {
compatible = "marvell,mv64xxx-i2c";
...
status = "disabled";
};

lcd0: lcd-controller at 82 {
compatible = "marvell,armada-510-lcd";
reg = <0x82 0x1000>;
status = "disabled";
};

lcd1: lcd-controller at 81 {
compatible = "marvell,armada-510-lcd";
reg = <0x81 0x1000>;
status = "disabled";
};

dcon: display-controller at 83 {
compatible = "marvell,armada-510-dcon";
reg = <0x83 0x100>;
status = "disabled";
};
};
};

dove-cubox.dts:
/include/ "dove.dtsi"

video {
card0 {
compatible = "marvell,armada-510-video",
  "linux,video-card";
linux,video-memory-size = <0x10>;
linux,video-devices = < >;
};
};

 { status = "okay"; };

 {
status = "okay";
clocks = < 0>;
clock-names = "extclk0";
/* pin config 0 = DUMB_RGB888 */
marvell,pin-configuration = <0>;
...
linux,video-external-encoder = <>;
};

 {
status = "okay";

tda998x: hdmi-transmitter at 60 {
compatible = "nxp,tda19988";
reg = <0x60>;
/* pin config 18 = RGB888 */
nxp,pin-configuration = <18>;
/* HPD gpio pin */
interrupt-gpios = < 12>;
};

si5351: programmable-pll {
/* Note: this binding already exists */
compatible = "silabs,5351a-msop10";
...
#clock-cells = <1>;

/* referenced as < 0> */

Best practice device tree design for display subsystems/DRM



> -Original Message-
> From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com]
> Sent: Wednesday, July 03, 2013 6:09 PM
> To: Sascha Hauer
> Cc: Inki Dae; 'Daniel Drake'; 'Jean-Francois Moine'; devicetree-
> discuss at lists.ozlabs.org; 'Russell King'; dri-devel at 
> lists.freedesktop.org
> Subject: Re: Best practice device tree design for display subsystems/DRM
> 
> On 07/03/13 11:02, Sascha Hauer wrote:
> > On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
> >>> video {
> >>>   /* Single video card w/ multiple lcd controllers */
> >>>   card0 {
> >>>   compatible = "marvell,armada-510-display";
> >>>   reg = <0 0x3f00 0x100>; /* video-mem hole */
> >>>   /* later: linux,video-memory-size = <0x100>; */
> >>>   marvell,video-devices = <  >;
> >>>   };
> >>>
> >>>   /* OR: Multiple video card w/ single lcd controllers */
> >>>   card0 {
> >>>   compatible = "marvell,armada-510-display";
> >>>   ...
> >>>   marvell,video-devices = <>;
> >>>   };
> >>>
> >>>   card1 {
> >>>   compatible = "marvell,armada-510-display";
> >>>   ...
> >>>   marvell,video-devices = <>;
> >>>   };
> >>> };
> >>
> >> Sorry but I'd like to say that this cannot be used commonly. Shouldn't
> you
> >> really consider Linux framebuffer or other subsystems? The above dtsi
> file
> >> is specific to DRM subsystem. And I think the dtsi file has no any
> >> dependency on certain subsystem so board dtsi file should be considered
> for
> >> all device drivers based on other subsystems: i.e., Linux framebuffer,
> DRM,
> >> and so no. So I *strongly* object to it. All we have to do is to keep
> the
> >> dtsi file as is, and to find other better way that can be used commonly
> in
> >> DRM.
> 
> Sascha, Inki,
> 
> can you clarify how the above will _not_ allow you to write a fb driver
> exploiting the cardX nodes?
> 

That's not whether we can write device driver or not. dtsi is common spot in
other subsystems. Do you think the cardX node is meaningful to other
subsystems?

Thanks,
Inki Dae

> While lcd controller and dcon are physically available, the video card
> is just a virtual combination of those.
> 
> > +1 for not encoding the projected usecase of the graphics subsystem into
> > the devicetree. Whether the two LCD controllers shall be used together
> > or separately should not affect the devicetree. devicetree is about
> > hardware description, not configuration.
> 
> Have you had a look at gpio-leds? It _is_ actually a configuration of
> GPIO to be used as LED triggers. IMHO DT is just fine for describing
> even "virtual" hardware you make up out of existing devices. Without it
> there is no way for the subsystems to determine the configuration.
> 
> Regarding gpio-leds, how should the driver know the single gpio line
> out of tens of available lines, if you do not use a virtual gpio led
> node to describe it?
> 
> Sebastian

Best practice device tree design for display subsystems/DRM



> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> Behalf Of Sebastian Hesselbarth
> Sent: Wednesday, July 03, 2013 6:41 AM
> To: Daniel Drake
> Cc: Jean-Francois Moine; devicetree-discuss at lists.ozlabs.org; dri-
> devel at lists.freedesktop.org; Russell King
> Subject: Re: Best practice device tree design for display subsystems/DRM
> 
> On 07/02/2013 11:04 PM, Daniel Drake wrote:
> > On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
> >   wrote:
> >> I am against a super node which contains lcd and dcon/ire nodes. You
> can
> >> enable those devices on a per board basis. We add them to dove.dtsi but
> >> disable them by default (status = "disabled").
> >>
> >> The DRM driver itself should get a video-card node outside of
> >> soc/internal-regs where you can put e.g. video memory hole (or video
> >> mem size if it will be taken from RAM later)
> >
> > For completeness of the discussion, and my understanding too, can you
> > explain your objections to the display super-node in a bit more
> > detail?
> 
> lcd-controller nodes and dcon node will need to be children of
> internal-regs nodes. The internal-regs node is required for address
> translation as the mbus base address can be configured. The above does
> not permit a super-node - but you cannot have the nodes above outside
> of internal-regs.
> 
> As Russell stated, he wants a proposal for the "unusual case" i.e.
> you have two lcd controllers. You use one for Xorg and the other for
> e.g. running a linux terminal console.
> 
> This would require some reference from the super node to the lcd
> controller to sort out which DRM device (represented by the super
> node) should be using which lcd controller device.
> 
> Using status = "disabled" alone will only allow to enable or disable
> lcd controller nodes but not assign any of it to your two super-nodes.
> 
> So my current proposal after thinking about Russell's statements
> whould be phandles as Jean-Francois already mentioned. I am not sure
> what OF maintainers will think about it, but that is another thing.
> 
> Basically, you will have:
> (Note: names and property-names are just to show how it could work,
> and example is joined from possible future dove.dtsi and dove-board.dts)
> 
> video {
>   /* Single video card w/ multiple lcd controllers */
>   card0 {
>   compatible = "marvell,armada-510-display";
>   reg = <0 0x3f00 0x100>; /* video-mem hole */
>   /* later: linux,video-memory-size = <0x100>; */
>   marvell,video-devices = <  >;
>   };
> 
>   /* OR: Multiple video card w/ single lcd controllers */
>   card0 {
>   compatible = "marvell,armada-510-display";
>   ...
>   marvell,video-devices = <>;
>   };
> 
>   card1 {
>   compatible = "marvell,armada-510-display";
>   ...
>   marvell,video-devices = <>;
>   };
> };

Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think the dtsi file has no any
dependency on certain subsystem so board dtsi file should be considered for
all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
and so no. So I *strongly* object to it. All we have to do is to keep the
dtsi file as is, and to find other better way that can be used commonly in
DRM.

Thanks,
Inki Dae

> 
> mbus {
>   compatible = "marvell,dove-mbus";
>   ranges = <...>;
> 
>   sb-regs {
>   ranges = <0 0xf100 0 0x10>;
>   ...
>   }
> 
>   nb-regs {
>   ranges = <0 0xf180 0 0x10>;
> 
>   lcd0: lcd-controller at 2 {
>   compatible = "marvell,armada-510-lcd";
>   reg = <0x2 0x1000>;
>   interrupts = <47>;
>   ...
>   /* use EXTCLK0 with lcd0 */
>   clocks = <_clk0>;
>   clock-names = "extclk0";
>   marvell,external-encoder = <>;
>   };
> 
>   lcd1: lcd-controller at 1 {
>   compatible = "marvell,armada-510-lcd";
>   reg = <0x1 0x1000>;
>   interrupts = <46>;
>   ...
>   /* use LCDPLL with lcd1 */
>   clocks = <_pll_clk>;
>   clock-names = "lcdpll";
>   };
>   }
> };
> 
>  {
>   tda998x: hdmi-transmitter at 60 {
>   compatible = "nxp,tda19988";
>   reg = <0x60>;
>   ...
>   }
> };
> 
> Each lcd controller node represents a platform_device and the display
> nodes above should

[pull] radeon drm-next-3.11

2013-07-03 Thread alexdeuc...@gmail.com

From: Alex Deucher 

Hi Dave,

A few more DPM fixes.

The following changes since commit 7982128c3d447df27db963af67bc6b8dc7efb1de:

  drm/radeon/dpm: add debugfs support for SI (2013-07-01 16:09:06 -0400)

are available in the git repository at:
  git://people.freedesktop.org/~agd5f/linux drm-next-3.11

Alex Deucher (6):
  drm/radeon/dpm: clarify debugfs warning
  drm/radeon: fix endian bug in radeon_atom_get_mclk_range_table()
  drm/radeon/aruba: disable additional rlc features
  drm/radeon/sumo: disable PG when changing UVD clocks
  drm/radeon/tn: disable PG when changing UVD clocks
  drm/radeon/sumo: implement support for disable_gfx_power_gating_in_uvd 
flag

Mike Lothian (1):
  drm/radeon/dpm: fix compilation with certain versions of gcc

 drivers/gpu/drm/radeon/evergreen.c   |2 --
 drivers/gpu/drm/radeon/ni_dpm.c  |1 +
 drivers/gpu/drm/radeon/radeon_atombios.c |2 +-
 drivers/gpu/drm/radeon/radeon_pm.c   |2 +-
 drivers/gpu/drm/radeon/rv6xx_dpm.c   |1 +
 drivers/gpu/drm/radeon/rv770_dpm.c   |1 +
 drivers/gpu/drm/radeon/si_dpm.c  |1 +
 drivers/gpu/drm/radeon/sumo_dpm.c|   24 ++--
 drivers/gpu/drm/radeon/trinity_dpm.c |9 +
 9 files changed, 37 insertions(+), 6 deletions(-)

[PATCH 3/3] drm/exynos: remove duplicated error routine and unnecessary assign

2013-07-03 Thread Seung-Woo Kim

There were duplicated error handling routines during allocating
pages in lowlevel_buffer_allocate() and g2d_userptr_get_dma_addr().
Also unnecessary NULL assignments for variable used not any more
are removed from g2d_userptr_get_dma_addr() and
g2d_userptr_put_dma_addr().

Signed-off-by: Seung-Woo Kim 
Signed-off-by: YoungJun Cho 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c |6 +++---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   12 
 2 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 518b6d8..b8ac06d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -68,8 +68,8 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
>dma_attrs);
if (!buf->kvaddr) {
DRM_ERROR("failed to allocate buffer.\n");
-   drm_free_large(buf->pages);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err_free;
}

start_addr = buf->dma_addr;
@@ -106,7 +106,7 @@ err_free_attrs:
dma_free_attrs(dev->dev, buf->size, buf->pages,
(dma_addr_t)buf->dma_addr, >dma_attrs);
buf->dma_addr = (dma_addr_t)NULL;
-
+err_free:
if (!is_drm_iommu_supported(dev))
drm_free_large(buf->pages);

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index fb19ee5..42a5a54 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -388,12 +388,9 @@ out:

sg_free_table(g2d_userptr->sgt);
kfree(g2d_userptr->sgt);
-   g2d_userptr->sgt = NULL;

drm_free_large(g2d_userptr->pages);
-   g2d_userptr->pages = NULL;
kfree(g2d_userptr);
-   g2d_userptr = NULL;
 }

 static dma_addr_t *g2d_userptr_get_dma_addr(struct drm_device *drm_dev,
@@ -466,8 +463,8 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
drm_device *drm_dev,
pages = drm_calloc_large(npages, sizeof(struct page *));
if (!pages) {
DRM_ERROR("failed to allocate pages.\n");
-   kfree(g2d_userptr);
-   return ERR_PTR(-ENOMEM);
+   ret = -ENOMEM;
+   goto err_free;
}

vma = find_vma(current->mm, userptr);
@@ -543,7 +540,6 @@ err_sg_free_table:

 err_free_sgt:
kfree(sgt);
-   sgt = NULL;

 err_free_userptr:
exynos_gem_put_pages_to_userptr(g2d_userptr->pages,
@@ -555,9 +551,9 @@ err_put_vma:

 err_free_pages:
drm_free_large(pages);
+
+err_free:
kfree(g2d_userptr);
-   pages = NULL;
-   g2d_userptr = NULL;

return ERR_PTR(ret);
 }
-- 
1.7.4.1

[PATCH v2 2/3] drm/exynos: fix pages allocation size in lowlevel_buffer_allocate

2013-07-03 Thread Seung-Woo Kim

From: YoungJun Cho 

When IOMMU is not supported, buf->pages has to be allocated to
assign the result of phys_to_page() which return type is struct
page *. So it is sufficient to allocate buf->pages with the size
of multiple struct page pointers.

Signed-off-by: YoungJun Cho 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: Kyungmin Park 
---
change from v1:
- adds precedence patch to fix allocation of array as Ville and Inki commented

 drivers/gpu/drm/exynos/exynos_drm_buf.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 245c9ae..c300b2a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -57,7 +57,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
dma_addr_t start_addr;
unsigned int i = 0;

-   buf->pages = drm_calloc_large(nr_pages, sizeof(struct page));
+   buf->pages = drm_calloc_large(nr_pages, sizeof(struct page *));
if (!buf->pages) {
DRM_ERROR("failed to allocate pages.\n");
return -ENOMEM;
-- 
1.7.4.1

[PATCH 1/3] drm/exynos: use drm_calloc_large when allocates pointer array

2013-07-03 Thread Seung-Woo Kim

From: YoungJun Cho 

If the type of object is pointer array, the drm_calloc_large() is
more suitable than kzalloc() for its allocation function. And uses
drm_free_large() instead of kfree() also.

Signed-off-by: YoungJun Cho 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_buf.c |9 -
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |6 +++---
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c 
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 22865ba..245c9ae 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -57,8 +57,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
dma_addr_t start_addr;
unsigned int i = 0;

-   buf->pages = kzalloc(sizeof(struct page) * nr_pages,
-   GFP_KERNEL);
+   buf->pages = drm_calloc_large(nr_pages, sizeof(struct page));
if (!buf->pages) {
DRM_ERROR("failed to allocate pages.\n");
return -ENOMEM;
@@ -69,7 +68,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
>dma_attrs);
if (!buf->kvaddr) {
DRM_ERROR("failed to allocate buffer.\n");
-   kfree(buf->pages);
+   drm_free_large(buf->pages);
return -ENOMEM;
}

@@ -109,7 +108,7 @@ err_free_attrs:
buf->dma_addr = (dma_addr_t)NULL;

if (!is_drm_iommu_supported(dev))
-   kfree(buf->pages);
+   drm_free_large(buf->pages);

return ret;
 }
@@ -134,7 +133,7 @@ static void lowlevel_buffer_deallocate(struct drm_device 
*dev,
if (!is_drm_iommu_supported(dev)) {
dma_free_attrs(dev->dev, buf->size, buf->kvaddr,
(dma_addr_t)buf->dma_addr, >dma_attrs);
-   kfree(buf->pages);
+   drm_free_large(buf->pages);
} else
dma_free_attrs(dev->dev, buf->size, buf->pages,
(dma_addr_t)buf->dma_addr, >dma_attrs);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index af75434..fb19ee5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -390,7 +390,7 @@ out:
kfree(g2d_userptr->sgt);
g2d_userptr->sgt = NULL;

-   kfree(g2d_userptr->pages);
+   drm_free_large(g2d_userptr->pages);
g2d_userptr->pages = NULL;
kfree(g2d_userptr);
g2d_userptr = NULL;
@@ -463,7 +463,7 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
drm_device *drm_dev,
npages = (end - start) >> PAGE_SHIFT;
g2d_userptr->npages = npages;

-   pages = kzalloc(npages * sizeof(struct page *), GFP_KERNEL);
+   pages = drm_calloc_large(npages, sizeof(struct page *));
if (!pages) {
DRM_ERROR("failed to allocate pages.\n");
kfree(g2d_userptr);
@@ -554,7 +554,7 @@ err_put_vma:
exynos_gem_put_vma(g2d_userptr->vma);

 err_free_pages:
-   kfree(pages);
+   drm_free_large(pages);
kfree(g2d_userptr);
pages = NULL;
g2d_userptr = NULL;
-- 
1.7.4.1

Best practice device tree design for display subsystems/DRM



> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> Behalf Of Russell King
> Sent: Wednesday, July 03, 2013 4:08 AM
> To: Daniel Drake
> Cc: Jean-Fran?ois Moine; devicetree-discuss at lists.ozlabs.org; dri-
> devel at lists.freedesktop.org; Sebastian Hesselbarth
> Subject: Re: Best practice device tree design for display subsystems/DRM
> 
> On Tue, Jul 02, 2013 at 12:54:41PM -0600, Daniel Drake wrote:
> > On Tue, Jul 2, 2013 at 12:43 PM, Russell King 
> wrote:
> > > I will point out that relying on driver probing orders has already
> been
> > > stated by driver model people to be unsafe.  This is why I will not
> > > adopt such a solution for my driver; it is a bad design.
> >
> > Just to clarify, what you're objecting to is effectively the
> > following? Because it is not guaranteed in the future that the probe
> > order will be the same as the platform_driver_register() calls?
> 
> Correct.  Consider what happens if the devices are registered after
> the driver(s) have been registered, which may not be in the correct
> order.
> 

That's true but how drivers could be registered prior to devices? The
devices registering codes are built in kernel image so the drivers cannot be
registered prior to devices as long as we don't modify the devices to be
registered first. Is there any case that driver should be registered first?

Thanks,
Inki Dae

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

Best practice device tree design for display subsystems/DRM



> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> Behalf Of Stephane Marchesin
> Sent: Wednesday, July 03, 2013 10:46 AM
> To: Dave Airlie
> Cc: Jean-Francois Moine; Daniel Drake;
devicetree-discuss at lists.ozlabs.org;
> dri-devel at lists.freedesktop.org; Russell King; Sebastian Hesselbarth
> Subject: Re: Best practice device tree design for display subsystems/DRM
> 
> On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie  wrote:
> > On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer 
> wrote:
> >> On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
> >>> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
> >>> > I am against a super node which contains lcd and dcon/ire nodes. You
> can
> >>> > enable those devices on a per board basis. We add them to dove.dtsi
> but
> >>> > disable them by default (status = "disabled").
> >>> >
> >>> > The DRM driver itself should get a video-card node outside of
> >>> > soc/internal-regs where you can put e.g. video memory hole (or video
> >>> > mem size if it will be taken from RAM later)
> >>> >
> >>> > About the unusual case, I guess we should try to get both lcd
> >>> > controllers into one DRM driver. Then support mirror or screen
> >>> > extension X already provides. For those applications where you want
> >>> > X on one lcd and some other totally different video stream - wait
> >>> > for someone to come up with a request or proposal.
> >>>
> >>> Well, all I can say then is that the onus is on those who want to
> treat
> >>> the components as separate devices to come up with some foolproof way
> >>> to solve this problem which doesn't involve making assumptions about
> >>> the way that devices are probed and doesn't end up creating artificial
> >>> restrictions on how the devices can be used - and doesn't end up
> burdening
> >>> the common case with lots of useless complexity that they don't need.
> >>>
> >>> It's _that_ case which needs to come up with a proposal about how to
> >>> handle it because you _can't_ handle it at the moment in any sane
> >>> manner which meets the criteria I've set out above, and at the moment
> >>> the best proposal by far to resolve that is the "super node" approach.
> >>>
> >>> There is _no_ way in the device model to combine several individual
> >>> devices together into one logical device safely when the subsystem
> >>> requires that there be a definite point where everything is known.
> >>> That applies even more so with -EPROBE_DEFER.  With the presence of
> >>> such a thing, there is now no logical point where any code can say
> >>> definitively that the system has technically finished booting and all
> >>> resources are known.
> >>>
> >>> That's the problem - if you don't od the super-node approach, you end
> >>> up with lots of individual devices which you have to figure out some
> >>> way of combining, and coping with missing ones which might not be
> >>> available in the order you want them to be, etc.
> >>>
> >>> That's the advantage of the "super node" approach - it's a container
> >>> to tell you what's required in order to complete the creation of the
> >>> logical device, and you can parse the sub-nodes to locate the
> >>> information you need.
> >>
> >> I think such an approach would lead to drm drivers which all parse
> their
> >> "super nodes" themselves and driver authors would become very creative
> >> how such a node should look like.
> >>
> >> Also this gets messy with i2c devices which are normally registered
> >> under their i2c bus masters. With the super node approach these would
> >> have to live under the super node, maybe with a phandle to the i2c bus
> >> master. This again probably leads to very SoC specific solutions. It
> >> also doesn't solve the problem that the i2c bus master needs to be
> >> registered by the time the DRM driver probes.
> >>
> >> On i.MX the IPU unit not only handles the display path but also the
> >> capture path. v4l2 begins to evolve an OF model in which each
> (sub)device
> >> has its natural position in the devicetree; the devices are then
> >> connected with phandles. I'm not sure how good this will work together
> >> with a super node approach.
> >>
> >>>
> >>> An alternative as I see it is that DRM - and not only DRM but also
> >>> the DRM API and Xorg - would need to evolve hotplug support for the
> >>> various parts of the display subsystem.  Do we have enough people
> >>> with sufficient knowledge and willingness to be able to make all
> >>> that happen?  I don't think we do, and I don't see that there's any
> >>> funding out there to make such a project happen, which would make it
> >>> a volunteer/spare time effort.
> >>
> >> +1 for this solution, even if this means more work to get from the
> >> ground.
> >>
> >> Do we really need full hotplug support in the DRM API and Xorg? I mean
> >> it would really be nice if Xorg

[ANNOUNCE] libdrm 2.4.46

2013-07-03 Thread Alex Deucher

On Wed, Jul 3, 2013 at 3:20 PM, Laurent Pinchart
 wrote:
> Hi Dave,
>
> On Wednesday 03 July 2013 10:17:34 Dave Airlie wrote:
>> On Wed, Jul 3, 2013 at 9:55 AM, Laurent Pinchart wrote:
>> > On Tuesday 02 July 2013 18:22:01 Dave Airlie wrote:
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA1
>> >>
>> >> Release because I want the cursor ioctls released,
>> >> also haswell and radeon ids.
>> >
>> > Any chance to get the "[PATCH v6 00/23] modetest enhancements" series
>> > included in the next release ?
>>
>> Do you not have commit access?
>
> No I don't.
>
>> if not I'd advise getting it,
>>
>> libdrm is maintained by everyone collectively and gets released when
>> someone sees the need for something in git.
>>
>> I certainly don't pull patches in from others to it very often, and
>> modetest I generally blame on jbarnes.
>
> How do I get commit access ?

http://www.freedesktop.org/wiki/AccountRequests/

Alex

MacBook Pro 10,1 + i915

2013-07-03 Thread Marek Vasut

Dear Chris Wilson,

> On Wed, Jul 03, 2013 at 01:35:35PM +0200, Marek Vasut wrote:
> > Hi Chris,
> > 
> > > On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> > > > Hi guys,
> > > > 
> > > > I recently got the rMBP 10,1 model, it has two graphic cards:
> > > > 
> > > > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
> > > > processor Graphics Controller (rev 09)
> > > > 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce
> > > > GT 650M Mac Edition] (rev a1)
> > > > 
> > > > I'm running linux 3.10-rc7 . The nvidia works with nouveau, but I'd
> > > > prefer to switch the nvidia off altogether and use the intel GPU.
> > > > 
> > > > So far I arrived at the point where I disabled X11, mounted debugfs
> > > > and tried the vgaswitcheroo. With the nvidia still in operation, I
> > > > see the console. Unfortunatelly, I end up with a black screen after
> > > > I run the following command to switch to the intel GPU:
> > > > 
> > > > echo IGD > /sys/kernel/debug/vgaswitcheroo/switch
> > > > 
> > > > If I try to switch back to the nvidia card (using echo DIS > ...),
> > > > the screen remains black. This state persists until reboot. I
> > > > suspect [1] is the same bug, none of the hints there helped.
> > > 
> > > It is not that bug. This bug I believe is that no one has figured out
> > > how to reprobe the eDP and initialise it after a vgaswitch.
> > 
> > Do we have any kind of hints into what direction I should dig ? I mean, I
> > went through the i915 source, went through David Airlies' patches [1] ,
> > but no success so far.
> > 
> > (User-unfriendly howto below, I hope this might help someone)
> > 
> > The interesting part is that if I do the following, the intel card
> > operates correctly:
> > 1) power down the mac
> > 2) boot into OSX
> > 3) install gfxcardstatus 2.2.1
> > 4) select Discrete first ; then select Integrated card (a popup must be
> > displayed in both cases in the top right corner indicating the operation
> > succeeded)
> > 5) reboot, start Linux
> > 
> > Now in Linux, I do have nouveau blacklisted and the nvidia blob is NOT
> > installed at all. I
> > - modprobe nouveau
> > - mount -t debugfs debug /sys/kernel/debug
> > - echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
> > 
> > And I have 16W power consumption, therefore the intel card is in
> > operation and nvidia is probably off. The laptop is still a little hot
> > in linux, but that's OK.
> > 
> > Yet I'd prefer to avoid the above booting into macos and do all this in
> > Linux. If you could give me any pointers, that'd be really appreciated.
> 
> I think you should also be able to accomplish the same if you were to
> reload the i915 module after doing the vgaswitch.

I tried this, but the i915 didn't detect any panels connected to outputs. I 
think the panel is somehow "disconnected" from the eDP, maybe it's the apple 
GMUX thing interfering.

> A starting point for patches would be for a notifier to run after
> vgaswitch, and for i915 to hook into that notification and reprobe
> panels (LVDS/eDP).

Ok, I think I understand it a little. I will try to fiddle with the kernel a 
bit 
and see where it gets me.

> -Chris

Thanks a lot!

Best regards,
Marek Vasut

[PATCH 6/6] drm: Optionally create mm blocks from top-to-bottom

2013-07-03 Thread Ben Widawsky

From: Chris Wilson 

Clients like i915 needs to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation of the
mappable portion of the GTT to only those buffers that require CPU
access through the GTT.

v2 by Ben:
Update callers in i915_gem_object_bind_to_gtt()
Turn search flags and allocation flags into separate enums
Make checkpatch happy where logical/easy

v3: by Ben:
Rebased on create_block removal

Signed-off-by: Chris Wilson 
CC: 
Signed-off-by: Ben Widawsky 

Conflicts:
drivers/gpu/drm/drm_mm.c
include/drm/drm_mm.h
---
 drivers/gpu/drm/drm_mm.c   | 121 +++
 drivers/gpu/drm/i915/i915_gem.c|   4 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c|   3 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c |   5 +-
 include/drm/drm_mm.h   | 148 -
 5 files changed, 166 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 9e8dfbc..4a30d55 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -49,7 +49,7 @@

 #define MM_UNUSED_TARGET 4

-static struct drm_mm_node *drm_mm_kmalloc(struct drm_mm *mm, int atomic)
+static struct drm_mm_node *drm_mm_kmalloc(struct drm_mm *mm, bool atomic)
 {
struct drm_mm_node *child;

@@ -105,7 +105,8 @@ EXPORT_SYMBOL(drm_mm_pre_get);
 static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
 struct drm_mm_node *node,
 unsigned long size, unsigned alignment,
-unsigned long color)
+unsigned long color,
+enum drm_mm_allocator_flags flags)
 {
struct drm_mm *mm = hole_node->mm;
unsigned long hole_start = drm_mm_hole_node_start(hole_node);
@@ -118,12 +119,22 @@ static void drm_mm_insert_helper(struct drm_mm_node 
*hole_node,
if (mm->color_adjust)
mm->color_adjust(hole_node, color, _start, _end);

+   if (flags & DRM_MM_CREATE_TOP)
+   adj_start = adj_end - size;
+
if (alignment) {
unsigned tmp = adj_start % alignment;
-   if (tmp)
-   adj_start += alignment - tmp;
+   if (tmp) {
+   if (flags & DRM_MM_CREATE_TOP)
+   adj_start -= tmp;
+   else
+   adj_start += alignment - tmp;
+   }
}

+   BUG_ON(adj_start < hole_start);
+   BUG_ON(adj_end > hole_end);
+
if (adj_start == hole_start) {
hole_node->hole_follows = 0;
list_del(_node->hole_stack);
@@ -148,7 +159,8 @@ static void drm_mm_insert_helper(struct drm_mm_node 
*hole_node,
 }

 int drm_mm_create_block(struct drm_mm *mm, struct drm_mm_node *node,
-   unsigned long start, unsigned long size)
+   unsigned long start, unsigned long size,
+   enum drm_mm_allocator_flags flags)
 {
struct drm_mm_node *hole;
unsigned long end = start + size;
@@ -190,15 +202,15 @@ struct drm_mm_node *drm_mm_get_block_generic(struct 
drm_mm_node *hole_node,
 unsigned long size,
 unsigned alignment,
 unsigned long color,
-int atomic)
+enum drm_mm_allocator_flags flags)
 {
struct drm_mm_node *node;

-   node = drm_mm_kmalloc(hole_node->mm, atomic);
+   node = drm_mm_kmalloc(hole_node->mm, flags & DRM_MM_CREATE_ATOMIC);
if (unlikely(node == NULL))
return NULL;

-   drm_mm_insert_helper(hole_node, node, size, alignment, color);
+   drm_mm_insert_helper(hole_node, node, size, alignment, color, flags);

return node;
 }
@@ -211,32 +223,28 @@ EXPORT_SYMBOL(drm_mm_get_block_generic);
  */
 int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
   unsigned long size, unsigned alignment,
-  unsigned long color)
+  unsigned long color,
+  enum drm_mm_allocator_flags aflags,
+  enum drm_mm_search_flags sflags)
 {
struct drm_mm_node *hole_node;

hole_node = drm_mm_search_free_generic(mm, size, alignment,
-  color, 0);
+  color, sflags);
if (!hole_node)
return -ENOSPC;

-   drm_mm_insert_helper(hole_node, node,

[PATCH 1/6] drm: pre allocate node for create_block

2013-07-03 Thread Ben Widawsky

For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
will break a bunch of code, but amongst them are 2 callers of
drm_mm_create_block(), both related to stolen memory.

It also allows us to embed the drm_mm_node into the object currently
which provides a nice transition over to the new code.

v2: Reordered to do before ripping out obj->gtt_offset.
Some minor cleanups made available because of reordering.

CC: 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/drm_mm.c   | 16 +--
 drivers/gpu/drm/i915/i915_gem_gtt.c| 18 +
 drivers/gpu/drm/i915/i915_gem_stolen.c | 36 +++---
 include/drm/drm_mm.h   |  9 +
 4 files changed, 49 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 07cf99c..9e8dfbc 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -147,12 +147,10 @@ static void drm_mm_insert_helper(struct drm_mm_node 
*hole_node,
}
 }

-struct drm_mm_node *drm_mm_create_block(struct drm_mm *mm,
-   unsigned long start,
-   unsigned long size,
-   bool atomic)
+int drm_mm_create_block(struct drm_mm *mm, struct drm_mm_node *node,
+   unsigned long start, unsigned long size)
 {
-   struct drm_mm_node *hole, *node;
+   struct drm_mm_node *hole;
unsigned long end = start + size;
unsigned long hole_start;
unsigned long hole_end;
@@ -161,10 +159,6 @@ struct drm_mm_node *drm_mm_create_block(struct drm_mm *mm,
if (hole_start > start || hole_end < end)
continue;

-   node = drm_mm_kmalloc(mm, atomic);
-   if (unlikely(node == NULL))
-   return NULL;
-
node->start = start;
node->size = size;
node->mm = mm;
@@ -184,11 +178,11 @@ struct drm_mm_node *drm_mm_create_block(struct drm_mm *mm,
node->hole_follows = 1;
}

-   return node;
+   return 0;
}

WARN(1, "no hole found for block 0x%lx + 0x%lx\n", start, size);
-   return NULL;
+   return -ENOSPC;
 }
 EXPORT_SYMBOL(drm_mm_create_block);

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 66929ea..5c6fc0e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -629,14 +629,24 @@ void i915_gem_setup_global_gtt(struct drm_device *dev,

/* Mark any preallocated objects as occupied */
list_for_each_entry(obj, _priv->mm.bound_list, global_list) {
+   int ret;
DRM_DEBUG_KMS("reserving preallocated space: %x + %zx\n",
  obj->gtt_offset, obj->base.size);

BUG_ON(obj->gtt_space != I915_GTT_RESERVED);
-   obj->gtt_space = drm_mm_create_block(_priv->mm.gtt_space,
-obj->gtt_offset,
-obj->base.size,
-false);
+   obj->gtt_space = kzalloc(sizeof(*obj->gtt_space), GFP_KERNEL);
+   if (!obj->gtt_space) {
+   DRM_ERROR("Failed to preserve all objects\n");
+   break;
+   }
+   ret = drm_mm_create_block(_priv->mm.gtt_space,
+ obj->gtt_space,
+ obj->gtt_offset,
+ obj->base.size);
+   if (ret) {
+   DRM_DEBUG_KMS("Reservation failed\n");
+   kfree(obj->gtt_space);
+   }
obj->has_global_gtt_mapping = 1;
}

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 8e02344..f9db84a 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -330,6 +330,7 @@ i915_gem_object_create_stolen_for_preallocated(struct 
drm_device *dev,
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj;
struct drm_mm_node *stolen;
+   int ret;

if (dev_priv->mm.stolen_base == 0)
return NULL;
@@ -344,11 +345,15 @@ i915_gem_object_create_stolen_for_preallocated(struct 
drm_device *dev,
if (WARN_ON(size == 0))
return NULL;

-   stolen = drm_mm_create_block(_priv->mm.stolen,
-stolen_offset, size,
-false);
-   if (stolen == NULL) {
+

Best practice device tree design for display subsystems/DRM

2013-07-03 Thread Lucas Stach

Am Dienstag, den 02.07.2013, 18:46 -0700 schrieb St?phane Marchesin:
> On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie  wrote:
> > On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer  
> > wrote:
> >> On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
> >>> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
> >>> > I am against a super node which contains lcd and dcon/ire nodes. You can
> >>> > enable those devices on a per board basis. We add them to dove.dtsi but
> >>> > disable them by default (status = "disabled").
> >>> >
> >>> > The DRM driver itself should get a video-card node outside of
> >>> > soc/internal-regs where you can put e.g. video memory hole (or video
> >>> > mem size if it will be taken from RAM later)
> >>> >
> >>> > About the unusual case, I guess we should try to get both lcd
> >>> > controllers into one DRM driver. Then support mirror or screen
> >>> > extension X already provides. For those applications where you want
> >>> > X on one lcd and some other totally different video stream - wait
> >>> > for someone to come up with a request or proposal.
> >>>
> >>> Well, all I can say then is that the onus is on those who want to treat
> >>> the components as separate devices to come up with some foolproof way
> >>> to solve this problem which doesn't involve making assumptions about
> >>> the way that devices are probed and doesn't end up creating artificial
> >>> restrictions on how the devices can be used - and doesn't end up burdening
> >>> the common case with lots of useless complexity that they don't need.
> >>>
> >>> It's _that_ case which needs to come up with a proposal about how to
> >>> handle it because you _can't_ handle it at the moment in any sane
> >>> manner which meets the criteria I've set out above, and at the moment
> >>> the best proposal by far to resolve that is the "super node" approach.
> >>>
> >>> There is _no_ way in the device model to combine several individual
> >>> devices together into one logical device safely when the subsystem
> >>> requires that there be a definite point where everything is known.
> >>> That applies even more so with -EPROBE_DEFER.  With the presence of
> >>> such a thing, there is now no logical point where any code can say
> >>> definitively that the system has technically finished booting and all
> >>> resources are known.
> >>>
> >>> That's the problem - if you don't od the super-node approach, you end
> >>> up with lots of individual devices which you have to figure out some
> >>> way of combining, and coping with missing ones which might not be
> >>> available in the order you want them to be, etc.
> >>>
> >>> That's the advantage of the "super node" approach - it's a container
> >>> to tell you what's required in order to complete the creation of the
> >>> logical device, and you can parse the sub-nodes to locate the
> >>> information you need.
> >>
> >> I think such an approach would lead to drm drivers which all parse their
> >> "super nodes" themselves and driver authors would become very creative
> >> how such a node should look like.
> >>
> >> Also this gets messy with i2c devices which are normally registered
> >> under their i2c bus masters. With the super node approach these would
> >> have to live under the super node, maybe with a phandle to the i2c bus
> >> master. This again probably leads to very SoC specific solutions. It
> >> also doesn't solve the problem that the i2c bus master needs to be
> >> registered by the time the DRM driver probes.
> >>
> >> On i.MX the IPU unit not only handles the display path but also the
> >> capture path. v4l2 begins to evolve an OF model in which each (sub)device
> >> has its natural position in the devicetree; the devices are then
> >> connected with phandles. I'm not sure how good this will work together
> >> with a super node approach.
> >>
> >>>
> >>> An alternative as I see it is that DRM - and not only DRM but also
> >>> the DRM API and Xorg - would need to evolve hotplug support for the
> >>> various parts of the display subsystem.  Do we have enough people
> >>> with sufficient knowledge and willingness to be able to make all
> >>> that happen?  I don't think we do, and I don't see that there's any
> >>> funding out there to make such a project happen, which would make it
> >>> a volunteer/spare time effort.
> >>
> >> +1 for this solution, even if this means more work to get from the
> >> ground.
> >>
> >> Do we really need full hotplug support in the DRM API and Xorg? I mean
> >> it would really be nice if Xorg detected a newly registered device, but
> >> as a start it should be sufficient when Xorg detects what's there when
> >> it starts, no?
> >
> > Since fbdev and fbcon sit on top of drm to provide the console
> > currently I'd also expect some fun with them. How do I get a console
> > if I have no outputs at boot, but I have crtcs? do I just wait around
> > until an output appears.
> >
> > There are a number of issues with hotplugging encoders

[Bug 66473] hdmi oops with mem sleep

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

--- Comment #1 from Andy Furniss  ---
It seems that this only happens on the second mem sleep - so to trigger it
looks like I need to boot with tv off, turn on tv but not enaable, sleep and
resume, then sleep again will give oops.

-- 
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/20130703/02a710d8/attachment.html>

[Bug 66551] New: System hang when DPM enabled on rs780.

vclk: 53300 dclk: 4
Jul  3 15:31:22 x4 kernel:  power level 0sclk: 5
vddc_index: 1
Jul  3 15:31:22 x4 kernel:  power level 1sclk: 5
vddc_index: 1
Jul  3 15:31:22 x4 kernel:  status: 
Jul  3 15:31:22 x4 kernel: switching from power state:
Jul  3 15:31:22 x4 kernel:  ui class: none
Jul  3 15:31:22 x4 kernel:  internal class: boot 
Jul  3 15:31:22 x4 kernel:  caps: video 
Jul  3 15:31:22 x4 kernel:  uvdvclk: 0 dclk: 0
Jul  3 15:31:22 x4 kernel:  power level 0sclk: 5
vddc_index: 2
Jul  3 15:31:22 x4 kernel:  power level 1sclk: 5
vddc_index: 2
Jul  3 15:31:22 x4 kernel:  status: c b 
Jul  3 15:31:22 x4 kernel: switching to power state:
Jul  3 15:31:22 x4 kernel:  ui class: performance
Jul  3 15:31:22 x4 kernel:  internal class: none
Jul  3 15:31:22 x4 kernel:  caps: video 
Jul  3 15:31:22 x4 kernel:  uvdvclk: 0 dclk: 0
Jul  3 15:31:22 x4 kernel:  power level 0sclk: 5
vddc_index: 1
Jul  3 15:31:22 x4 kernel:  power level 1sclk: 7
vddc_index: 2
Jul  3 15:31:22 x4 kernel:  status: r 
Jul  3 15:31:22 x4 kernel: [drm] radeon: dpm initialized

-- 
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/20130703/a41eef19/attachment-0001.html>

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

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

--- Comment #6 from Christian K?nig  ---
(In reply to comment #5)
> Pretty sure the instability has nothing to do with this.

Good to know, well at least this bug loses a bit priority then.

> As far as I can tell, this would happen whenever the system suspend fails
> after deactivating the drivers and the PM system restarts everything when
> the system hasn't actually suspended.  The "pm_test" file just seems to
> cause an error return value at an appropriate point in the suspend code.
> When the system actually sleeps the uvd suspend code seems fine, but if it
> doesn't sleep then there is this delay.

Oh! Do I get this right that it only happens when you try to suspend the system
but then doesn't really do the power cycle (for whatever reason)?

Well that would explain it, cause thise case isn't really supported by the
hardware. A complete manual reset of the UVD block (without an external power
cycle) is somewhere between very very tricky and impossible.

> I'm not sure if this would help in making a work-around.

At least it explains the behavior. We could try to get it working by playing
around with the different soft reset methods, but I have my doubts that this
will ever work correctly.

-- 
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/20130703/bafdcc84/attachment.html>

Best practice device tree design for display subsystems/DRM

On 07/03/13 13:43, Inki Dae wrote:
>> I do not understand why you keep referring to the SoC dtsi. Im my
>> example, I said that it is made up and joined from both SoC dtsi and
>> board dts.
>>
>> So, of course, lcd controller nodes and dcon are part of dove.dtsi
>> because they are physically available on every Dove SoC.
>>
>> Also, the connection from lcd0 to the external HDMI encoder node
>> is in the board dts because you can happily build a Dove SoC board
>> with a different HDMI encoder or with no encoder at all.
>>
>> The video-card super node is not in any way specific to DRM and
>
> In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or lcd0
> and lcd1 drivers which are placed in drivers/video/backlight/.
>
> And let's assume the following:
>
> On board A
>   Display controller - lcd 0
> On board B
>   Display controller - lcd 1
> On board C
>   Display controller - lcd 0 and lcd 1
>
> Without the super node, user could configure Linux kernel through menuconfig
> like below;
>   board A:  enabling lcd 0, and disabling lcd 1,
>   board B: disabling lcd 0, and enabling lcd 1,
>   board C: enabling lcd 0 and lcd 1.
>
> All we have to do is to configure menuconfig to enable only drivers for
> certain board. Why does fbdev need the super node? Please give me comments
> if there is my missing point.

I assume when you say "configure menuconfig" you mean
"create a CONFIG_DISPLAY_CONTROLLER_AS_USED_ON_BOARD_A,
CONFIG_DISPLAY_CONTROLLER_AS_USED_ON_BOARD_B, ..." ?

This finally will require you to have
(a) #ifdef mess for every single board _and_ driver above
(b) new CONFIG_.._BOARD_D plus new #ifdefs in fbdev driver for every
 new board
(c) A new set of the above CONFIG_/#ifdef for DRM driver

This can also be done with device_tree and supernode approach,
so for your example above:

BoardA.dts:
video { card0 { video-devices = <>; }; };

BoardB.dts:
video { card0 { video-devices = <>; }; };

BoardC.dts:
video { card0 { video-devices = < >; }; };

and in the driver your are prepared for looping over the video-devices
property and parsing the compatible string of the nodes passed.

Sebastian

MacBook Pro 10,1 + i915

2013-07-03 Thread Chris Wilson

On Wed, Jul 03, 2013 at 01:35:35PM +0200, Marek Vasut wrote:
> Hi Chris,
> 
> > On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> > > Hi guys,
> > > 
> > > I recently got the rMBP 10,1 model, it has two graphic cards:
> > > 
> > > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
> > > processor Graphics Controller (rev 09)
> > > 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT
> > > 650M Mac Edition] (rev a1)
> > > 
> > > I'm running linux 3.10-rc7 . The nvidia works with nouveau, but I'd
> > > prefer to switch the nvidia off altogether and use the intel GPU.
> > > 
> > > So far I arrived at the point where I disabled X11, mounted debugfs and
> > > tried the vgaswitcheroo. With the nvidia still in operation, I see the
> > > console. Unfortunatelly, I end up with a black screen after I run the
> > > following command to switch to the intel GPU:
> > > 
> > > echo IGD > /sys/kernel/debug/vgaswitcheroo/switch
> > > 
> > > If I try to switch back to the nvidia card (using echo DIS > ...), the
> > > screen remains black. This state persists until reboot. I suspect [1] is
> > > the same bug, none of the hints there helped.
> > 
> > It is not that bug. This bug I believe is that no one has figured out
> > how to reprobe the eDP and initialise it after a vgaswitch.
> 
> Do we have any kind of hints into what direction I should dig ? I mean, I 
> went 
> through the i915 source, went through David Airlies' patches [1] , but no 
> success so far.
> 
> (User-unfriendly howto below, I hope this might help someone)
> 
> The interesting part is that if I do the following, the intel card operates 
> correctly:
> 1) power down the mac
> 2) boot into OSX
> 3) install gfxcardstatus 2.2.1
> 4) select Discrete first ; then select Integrated card (a popup must be 
> displayed in both cases in the top right corner indicating the operation 
> succeeded)
> 5) reboot, start Linux
> 
> Now in Linux, I do have nouveau blacklisted and the nvidia blob is NOT 
> installed 
> at all. I
> - modprobe nouveau
> - mount -t debugfs debug /sys/kernel/debug
> - echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
> 
> And I have 16W power consumption, therefore the intel card is in operation 
> and 
> nvidia is probably off. The laptop is still a little hot in linux, but that's 
> OK.
> 
> Yet I'd prefer to avoid the above booting into macos and do all this in 
> Linux. 
> If you could give me any pointers, that'd be really appreciated.

I think you should also be able to accomplish the same if you were to
reload the i915 module after doing the vgaswitch.

A starting point for patches would be for a notifier to run after
vgaswitch, and for i915 to hook into that notification and reprobe
panels (LVDS/eDP).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

MacBook Pro 10,1 + i915

2013-07-03 Thread Marek Vasut

Hi Chris,

> On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> > Hi guys,
> > 
> > I recently got the rMBP 10,1 model, it has two graphic cards:
> > 
> > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
> > processor Graphics Controller (rev 09)
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT
> > 650M Mac Edition] (rev a1)
> > 
> > I'm running linux 3.10-rc7 . The nvidia works with nouveau, but I'd
> > prefer to switch the nvidia off altogether and use the intel GPU.
> > 
> > So far I arrived at the point where I disabled X11, mounted debugfs and
> > tried the vgaswitcheroo. With the nvidia still in operation, I see the
> > console. Unfortunatelly, I end up with a black screen after I run the
> > following command to switch to the intel GPU:
> > 
> > echo IGD > /sys/kernel/debug/vgaswitcheroo/switch
> > 
> > If I try to switch back to the nvidia card (using echo DIS > ...), the
> > screen remains black. This state persists until reboot. I suspect [1] is
> > the same bug, none of the hints there helped.
> 
> It is not that bug. This bug I believe is that no one has figured out
> how to reprobe the eDP and initialise it after a vgaswitch.

Do we have any kind of hints into what direction I should dig ? I mean, I went 
through the i915 source, went through David Airlies' patches [1] , but no 
success so far.

(User-unfriendly howto below, I hope this might help someone)

The interesting part is that if I do the following, the intel card operates 
correctly:
1) power down the mac
2) boot into OSX
3) install gfxcardstatus 2.2.1
4) select Discrete first ; then select Integrated card (a popup must be 
displayed in both cases in the top right corner indicating the operation 
succeeded)
5) reboot, start Linux

Now in Linux, I do have nouveau blacklisted and the nvidia blob is NOT 
installed 
at all. I
- modprobe nouveau
- mount -t debugfs debug /sys/kernel/debug
- echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

And I have 16W power consumption, therefore the intel card is in operation and 
nvidia is probably off. The laptop is still a little hot in linux, but that's 
OK.

Yet I'd prefer to avoid the above booting into macos and do all this in Linux. 
If you could give me any pointers, that'd be really appreciated.

Thanks!

[1] http://cgit.freedesktop.org/~airlied/linux/log/?h=switchy-wip

Best regards,
Marek Vasut

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] ERROR radeon: error initializing UVD (-1).

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

Christian K?nig  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #10 from Christian K?nig  ---
Thanks for the info, closing it.

-- 
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/20130703/5492ebdf/attachment.html>

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
> On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
> > 
> > +1 for not encoding the projected usecase of the graphics subsystem into
> > the devicetree. Whether the two LCD controllers shall be used together
> > or separately should not affect the devicetree. devicetree is about
> > hardware description, not configuration.
> 
> And if we listen to that argument, then this problem is basically
> impossible to solve sanely.
> 
> Are we really saying that we have no acceptable way to represent
> componentized devices in DT?  If that's true, then DT fails to represent
> quite a lot of ARM hardware, and frankly we shouldn't be using it.  I
> can't believe that's true though.
> 
> The problem is that even with an ASoC like approach, that doesn't work
> here because there's no way to know how many "components" to expect.
> That's what the "supernode" is doing - telling us what components group
> together to form a device.
> 
> Moreover, if you pay attention to my proposal, what you will realise is
> that it isn't DRM specific - it's totally subsystem agnostic.  All it's
> doing is collecting a set of other devices together and only then
> publishing a device representing the full set of sub-devices.
> 
> Now think about that: what is DRM specific about that solution?  What
> is the DRM specific about "collecting a set of devices together and
> publishing a new device" ?
> 
> How is this not "describing the hardware"?  If I attach a HDMI transceiver
> to the DCON which is then connected to LCD0, is it not "describing the
> hardware" to put into DT that LCD0, DCON, and the HDMI transceiver are
> all connected together and therefore are required?  One of the points of
> DT after all is that it can and should be used to represent the
> relationship between devices.
> 
> No - using the tree approach doesn't work, because LCD0, LCD1 and DCON
> are all on the same physical bus, but are themselves connected together.
> If you like, there are multiple heirarchies here - there's the bus
> heirarchy, and then there's the device heirarchy.  Both of these
> heirarchies need to be represented in DT, otherwise you're not describing
> the hardware properly.

And I think with these multiple hierarchies there is some confusion in
this thread.

The devicetree is structured by the bus hierarchy and we shouldn't
change that. The bus hierarchy doesn't necessarily match the device
hierarchy though.

The supernode has to describe the device hierarchy instead. If it does
so by referencing the physical devices by using phandles I'm
perfectly fine with this approach. If this even leads to subsystem
agnostic code which can be used to compose v4l2, ASoC or DRM devices
I'd really love it.

The only thing we shouldn't do is to describe a whole virtual device
directly under a single node in the devicetree as this breaks when bus
hierarchy and device hierarchy differ.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PULL] drm-intel-fixes for 3.11

2013-07-03 Thread Daniel Vetter

Hi Dave,

Pile of fixes for 3.11. A bit large in patch count, but that's simply due
to two fixes being split up into really small parts. Also I've included a
few more vlv patches than I'd have included for other platforms. But since
vlv is officially supported for the first time only in 3.11 that shouldn't
result in unbearable risks.

Highlights:
- ghost eDP fixes for hsw from Paulo
- fix PCH detection in virtualized enviroments (Rui Guo)
- duct-tape dma sg construction when swiotlb is in use (Konrad), dupe with
  a patch in your drm-fixes branch
- fix sdvo hotplug on i965g
- tune down a bunch of dmesg ERRORs which can be hit under normal
  conditions
- detect invalid pitches for tiled scanout buffers (Chris)
- a pile of vlv fixes from Ville: rps improvements, fixes for the dpll
  LPF, fixup the sprite mmio offsets
- fix context size on hsw (Ben)
- locking fixes for the hotplug code, specifically the storm handling
- fix get_config on CPT (Xiong Zhang)
- Fix the domain tracking when an unlocked seqno wait was interrupt
  (Chris), this seems to explain tons of little corruption bugs in the
  ddx. Chris also added a nice igt to exercise this.
- work around stack-corrupting vnsprintf in our error state dumper

I have 1-2 fixes in flight (like reset improvements on gm45, recently
discovered with more paranoid igt tests), but those need a bit more time
to settle. So I've figured I'll flush out my current pile of patches.

Cheers, Daniel

The following changes since commit d482e5fa299c2cfbb4700143dd766273730e2357:

  Revert "drm: kms_helper: don't lose hotplug event" (2013-06-28 20:31:34 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-07-03

for you to fetch changes up to 446f8d81ca2d9cefb614e87f2fabcc996a9e4e7e:

  drm/i915: Don't try to tear down the stolen drm_mm if it's not there 
(2013-07-02 11:47:19 +0200)


Ben Widawsky (1):
  drm/i915: Fix context sizes on HSW

Chris Wilson (4):
  drm/i915: Detect invalid scanout pitches
  drm/i915: Only clear write-domains after a successful wait-seqno
  drm/i915: Refactor the wait_rendering completion into a common routine
  drm/i915: Break up the large vsnprintf() in print_error_buffers()

Damien Lespiau (1):
  drm/i915: Introduce an HAS_IPS() macro

Daniel Vetter (11):
  drm/i915: tune down DIDL warning about too many outputs
  drm/i915: Fix up sdvo hpd pins for i965g/gm
  drm/i915: don't scream into dmesg when a modeset fails
  drm/i915: fix locking around ironlake_enable|disable_display_irq
  drm/i915: close tiny race in the ilk pcu even interrupt setup
  drm/i915: s/hotplug_irq_storm_detect/intel_hpd_irq_handler/
  drm/i915: fold the hpd_irq_setup call into intel_hpd_irq_handler
  drm/i915: fold the queue_work into intel_hpd_irq_handler
  drm/i915: fold the no-irq check into intel_hpd_irq_handler
  drm/i915: fix hpd interrupt register locking
  drm/i915: Don't try to tear down the stolen drm_mm if it's not there

Jani Nikula (1):
  drm/i915: fix build warning on format specifier mismatch

Konrad Rzeszutek Wilk (1):
  drm/i915: make compact dma scatter lists creation work with SWIOTLB 
backend.

Paulo Zanoni (7):
  drm/i915: don't check encoder at DP connector destroy()
  drm/i915: extract intel_edp_init_connector
  drm/i915: propagate errors from intel_dp_init_connector
  drm/i915: fix the "ghost eDP" connector unwind path
  drm/i915: fix the "ghost eDP" encoder unwind path
  drm/i915: check the return value of intel_dp_i2c_init
  drm/i915: rename intel_dp_destroy to intel_dp_connector_destroy

Rui Guo (1):
  drm/i915: Fix PCH detect with multiple ISA bridges in VM

Ville Syrj?l? (11):
  drm/i915: Remove duplicated WaForceL3Serialization:vlv
  drm/i915: Clean up VLV rps code a bit
  drm/i915: Don't wait for Punit after each freq change on VLV
  drm/i915: Make the rps new_delay comparison more readable
  drm/i915: GEN6_RP_INTERRUPT_LIMITS doesn't seem to exist on VLV
  drm/i915: Don't increase the GPU frequency from the delayed VLV rps timer
  drm/i915: Jump to at least RPe on VLV when increasing the GPU frequency
  drm/i915: Fix VLV PLL LPF coefficients for DAC
  drm/i915: s/LFP/LPF in DPIO PLL register names
  Revert "drm/i915: Don't use the HDMI port color range bit on Valleyview"
  drm/i915: Fix VLV sprite register offsets

Xiong Zhang (1):
  drm/i915: correct intel_dp_get_config() function for DevCPT

 drivers/gpu/drm/i915/i915_debugfs.c |  119 -
 drivers/gpu/drm/i915/i915_drv.c |   18 ++-
 drivers/gpu/drm/i915/i915_drv.h |2 +
 drivers/gpu/drm/i915/i915_gem.c |   64 +
 drivers/gpu/drm/i915/i915_gem_context.c |2 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c  |9 +-
 drivers/gpu/drm/i915/i915_irq.c |

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] ERROR radeon: error initializing UVD (-1).

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

Alex Deucher  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

-- 
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/20130703/affc9712/attachment.html>

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] ERROR radeon: error initializing UVD (-1).

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

--- Comment #9 from Justin Piszcz  ---
(In reply to comment #8)
> Please do a "make clean" then and fully recompile your kernel.
> 
> The kernel makefile doesn't recognize it when you change the firmware on the
> disk and still builds the old firmware file into the kernel.


$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git
Cloning into 'linux-firmware'...
remote: Counting objects: 2210, done.
remote: Compressing objects: 100% (1102/1102), done.
remote: Total 2210 (delta 1121), reused 2114 (delta 1073)
Receiving objects: 100% (2210/2210), 39.99 MiB | 6.39 MiB/s, done.
Resolving deltas: 100% (1121/1121), done.

$ date
Wed Jul  3 08:53:01 EDT 2013

# mv /lib/firmware /lib/firmware.old
# mv linux-firmware/ /lib/firmware
# cd /lib/firmware/radeon
# md5sum CEDAR* CYPRESS_uvd.bin
2b244d41832f46382bfbb8994522dcdd  CEDAR_me.bin
23915e382ea0d2f2491a19146ca3001c  CEDAR_pfp.bin
e8770d3d588f24dc6f1a8609c9db3467  CEDAR_rlc.bin
fb23b281dcc94a035d374e709c9842bd  CYPRESS_uvd.bin

Check firmware:

/lib/firmware/radeon# md5sum CEDAR* CYPRESS_uvd.bin
2b244d41832f46382bfbb8994522dcdd  CEDAR_me.bin
23915e382ea0d2f2491a19146ca3001c  CEDAR_pfp.bin
e8770d3d588f24dc6f1a8609c9db3467  CEDAR_rlc.bin
fb23b281dcc94a035d374e709c9842bd  CYPRESS_uvd.bin

Use fresh tree:

# cp linux-3.10/.config oldconfig
# rm -rf linux-3.10
# tar jxf linux-3.10.tar.bz2
# rm linux
# ln -s linux-3.10 linux
# cp oldconfig linux/.config
# cd linux
# make oldconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
warning: (DRM_RADEON && DRM_I915 && DRM_GMA500 && DRM_TILCDC && FB_BACKLIGHT &&
USB_APPLEDISPLAY && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI
&& EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE
which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)
warning: (HAVE_TEXT_POKE_SMP) selects STOP_MACHINE which has unmet direct
dependencies (SMP && MODULE_UNLOAD || HOTPLUG_CPU)
warning: (DRM_RADEON && DRM_I915 && DRM_GMA500 && DRM_TILCDC && FB_BACKLIGHT &&
USB_APPLEDISPLAY && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI
&& EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE
which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)
warning: (HAVE_TEXT_POKE_SMP) selects STOP_MACHINE which has unmet direct
dependencies (SMP && MODULE_UNLOAD || HOTPLUG_CPU)
#
# configuration written to .config
#

Compile kernel/install/reboot.

It is happy now, I've removed my distribution's firmware package as well.


[0.817384] [drm] GART: num cpu pages 131072, num gpu pages 131072
[0.817917] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[0.818047] [drm] Loading CEDAR Microcode
[0.826262] [drm] PCIE GART of 512M enabled (table at 0x0004).

[0.840416] [drm] radeon: irq initialized.
[0.857152] [drm] ring test on 0 succeeded in 2 usecs
[0.857267] [drm] ring test on 3 succeeded in 1 usecs
[1.043474] [drm] ring test on 5 succeeded in 4 usecs
[1.043537] [drm] UVD initialized successfully.
[1.043826] [drm] ib test on ring 0 succeeded in 0 usecs
[1.043912] [drm] ib test on ring 3 succeeded in 0 usecs
[1.195406] [drm] ib test on ring 5 succeeded
[1.196322] [drm] Radeon Display Connectors
[1.196378] [drm] Connector 0:
[1.196432] [drm]   DP-1
[1.196486] [drm]   HPD2
[1.196545] [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c
0x646c
[1.196613] [drm]   Encoders:
[1.196667] [drm] DFP1: INTERNAL_UNIPHY1
[1.196723] [drm] Connector 1:
[1.196777] [drm]   DVI-I-1
[1.196830] [drm]   HPD4
[1.196884] [drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c
0x645c
[1.196952] [drm]   Encoders:
[1.197006] [drm] DFP2: INTERNAL_UNIPHY
[1.197061] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[1.197117] [drm] Connector 2:
[1.197171] [drm]   VGA-1
[1.197225] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c
0x643c
[1.197293] [drm]   Encoders:
[1.197347] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[1.197445] [drm] Internal thermal controller with fan control
[1.197570] [drm] radeon: power management initialized
[1.291637] [drm] fb mappable at 0x3C0FE035F000
[1.291695] [drm] vram apper at 0x3C0FE000
[1.291750] [drm] size 9216000
[1.291804] [drm] fb depth is 24
[1.291858] [drm]pitch is 7680


Thanks,

Justin.

-- 
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/20130703/25f55753/attachment.html>

Best practice device tree design for display subsystems/DRM

On 07/03/13 11:52, Russell King wrote:
> On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
>> On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
 video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = "marvell,armada-510-display";
reg = <0 0x3f00 0x100>; /* video-mem hole */
/* later: linux,video-memory-size = <0x100>; */
marvell,video-devices = <  >;
};

/* OR: Multiple video card w/ single lcd controllers */
card0 {
compatible = "marvell,armada-510-display";
...
marvell,video-devices = <>;
};

card1 {
compatible = "marvell,armada-510-display";
...
marvell,video-devices = <>;
};
 };
>>>
>>> Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
>>> really consider Linux framebuffer or other subsystems? The above dtsi file
>>> is specific to DRM subsystem. And I think the dtsi file has no any
>>> dependency on certain subsystem so board dtsi file should be considered for
>>> all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
>>> and so no. So I *strongly* object to it. All we have to do is to keep the
>>> dtsi file as is, and to find other better way that can be used commonly in
>>> DRM.
>>
>> +1 for not encoding the projected usecase of the graphics subsystem into
>> the devicetree. Whether the two LCD controllers shall be used together
>> or separately should not affect the devicetree. devicetree is about
>> hardware description, not configuration.
>
> And if we listen to that argument, then this problem is basically
> impossible to solve sanely.
>
> Are we really saying that we have no acceptable way to represent
> componentized devices in DT?  If that's true, then DT fails to represent
> quite a lot of ARM hardware, and frankly we shouldn't be using it.  I
> can't believe that's true though.

I think DT is able to describe componentized devices, as long as you
ignore DRM/fbdev/ASoC's demands and try to have a look at the HW without
any specific backend in mind.

We both had a similar discussion about ASoC's separation of bus-side and
codec-side subdevices. In HW, there is no such separation but one single
audio controller (at least on Dove). Moreover, a full featured, again
virtual, sound card comprises a lot more than just what is in the SoC.
There is external codecs, jacks, aso.

> The problem is that even with an ASoC like approach, that doesn't work
> here because there's no way to know how many "components" to expect.
> That's what the "supernode" is doing - telling us what components group
> together to form a device.

True. The supernode forms a virtual device on top of the individual
components of both SoC and board. For the driver subsystem, all that is
required should be probed by starting from the supernode. If what is
found is not sufficient for the driver subsystem to register a working
subsystem device, bail out. If there is more than you expect, ignore
it and cross your fingers. IMHO DT is not the solution for describing
the world, but it is sufficient for any subsystem driver to find what
it needs to know.

> Moreover, if you pay attention to my proposal, what you will realise is
> that it isn't DRM specific - it's totally subsystem agnostic.  All it's
> doing is collecting a set of other devices together and only then
> publishing a device representing the full set of sub-devices.
>
> Now think about that: what is DRM specific about that solution?  What
> is the DRM specific about "collecting a set of devices together and
> publishing a new device" ?
>
> How is this not "describing the hardware"?  If I attach a HDMI transceiver
> to the DCON which is then connected to LCD0, is it not "describing the
> hardware" to put into DT that LCD0, DCON, and the HDMI transceiver are
> all connected together and therefore are required?  One of the points of
> DT after all is that it can and should be used to represent the
> relationship between devices.
>
> No - using the tree approach doesn't work, because LCD0, LCD1 and DCON
> are all on the same physical bus, but are themselves connected together.
> If you like, there are multiple heirarchies here - there's the bus
> heirarchy, and then there's the device heirarchy.  Both of these
> heirarchies need to be represented in DT, otherwise you're not describing
> the hardware properly.

IMHO DT is more than describing physical connections between devices but
also describing logical connections between devices. While, for example,
a SATA bus master could happily do DMA writes to the GPIO registers just
because it is physically connected to it, it makes no sense. OTOH an LED
connected to a gpio pin is not directly connected to the GPIO register
but at least needs to know who to ask for toggling the line.

I know

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 08:43:20PM +0900, Inki Dae wrote:
> In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or lcd0
> and lcd1 drivers which are placed in drivers/video/backlight/.

No, that's totally wrong.  Framebuffer drivers are not backlights.
Framebuffer drivers go in drivers/video not drivers/video/backlight.

> And let's assume the following:
> 
> On board A
>  Display controller - lcd 0
> On board B
>  Display controller - lcd 1
> On board C
>  Display controller - lcd 0 and lcd 1
> 
> Without the super node, user could configure Linux kernel through menuconfig
> like below;
>   board A:  enabling lcd 0, and disabling lcd 1,
>   board B: disabling lcd 0, and enabling lcd 1,
>   board C: enabling lcd 0 and lcd 1.

I don't think so.  By using menuconfig, you completely miss the point of
using DT - which is to allow us to have a single kernel image which can
support multiple boards with different configurations, even different
SoCs.

> All we have to do is to configure menuconfig to enable only drivers for
> certain board. Why does fbdev need the super node? Please give me comments
> if there is my missing point.

fbdev needs the supernode _OR_ some way to specify that information which
you're putting into menuconfig, because what's correct for the way one
board is physically wired is not correct for how another board is
physically wired.

With that information in menuconfig, you get a kernel image which can
support board A, or board B, or board C but not a single kernel image
which can support board A and board B and board C by loading that very
same kernel image onto all three boards with just a different DT image.

This is the *whole* point of ARM moving over to DT.

If we wanted to use menuconfig to sort these kinds of board specific
details, we wouldn't be investing so much time and effort into moving
over to DT for ARM.  In fact, we used to use menuconfig to sort out
some of these kinds of details, and we've firmly decided that this is
the wrong approach.

Today, there is a very strong push towards having a single kernel image
which runs on every (modern) ARM board with DT describing not only the
board level hardware but also the internal SoC as well.

-- 
Russell King

Best practice device tree design for display subsystems/DRM

On 07/03/13 11:53, Russell King wrote:
> On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote:
>> That's not whether we can write device driver or not. dtsi is common spot in
>> other subsystems. Do you think the cardX node is meaningful to other
>> subsystems?
>
> Yes, because fbdev could also use it to solve the same problem which we're
> having with DRM.

Inki,

I do not understand why you keep referring to the SoC dtsi. Im my
example, I said that it is made up and joined from both SoC dtsi and
board dts.

So, of course, lcd controller nodes and dcon are part of dove.dtsi
because they are physically available on every Dove SoC.

Also, the connection from lcd0 to the external HDMI encoder node
is in the board dts because you can happily build a Dove SoC board
with a different HDMI encoder or with no encoder at all.

The video-card super node is not in any way specific to DRM and
describes a virtual graphics card comprising both SoC and board
components (on a per-board basis). You can have both DRM or fbdev
use that virtual video card node to register your subsystem drivers
required to provide video output.

I agree to what Sascha said, the decision to put one or two
virtual graphics card in the device tree depending on the use
case is sketchy. You can have one card/two card on the same
board, so at this point device tree is not describing HW but
use case.

But honestly, I see no way around it and it is the only way
to allow to even have the decision for one or two cards at all.
There is no way for auto-probing the users intention...

Sebastian

[Bug 64850] Second screen black on Pitcairn PRO

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

--- Comment #20 from Jakob Nixdorf  ---
Just FYI:
This bug is still present with kernel 3.10.0 and the newest firmware from git.

-- 
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/20130703/f2074a42/attachment.html>

[patch] drm/nvc0/gr: remove duplicate break statements

2013-07-03 Thread Dan Carpenter

There are two break statements in a row.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c 
b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c
index 3be7b95..f1c0767 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c
@@ -2249,7 +2249,6 @@ nvc0_grctx_generate_tp(struct nvc0_graph_priv *priv)
nv_wr32(priv, 0x419f54, 0x);
nv_wr32(priv, 0x419f58, 0x);
break;
-   break;
default:
BUG_ON(1);
break;
@@ -2321,7 +2320,6 @@ nvc0_grctx_generate(struct nvc0_graph_priv *priv)
}
}
break;
-   break;
case 0xc0:
case 0xc3:
case 0xc4:

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] ERROR radeon: error initializing UVD (-1).

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

--- Comment #8 from Christian K?nig  ---
Please do a "make clean" then and fully recompile your kernel.

The kernel makefile doesn't recognize it when you change the firmware on the
disk and still builds the old firmware file into the kernel.

-- 
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/20130703/0385d71c/attachment.html>

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote:
> But honestly, I see no way around it and it is the only way
> to allow to even have the decision for one or two cards at all.
> There is no way for auto-probing the users intention...

It's not _just_ about the users intention - for get that, because really
it's to do with solving a much bigger question, and that question is:

How do we know when all the components are present?

In other words, how do we know that we have LCD0 and LCD1 connected to
the DCON, which is connected to a LCD and/or a HDMI tranceiver.  How
do we know that the on-board VGA DACs are wired up and to be used?
How do we know which I2C bus the VGA port is connected to, and whether
to expect an I2C bus?

Let's look at the Cubox setup (sorry, but you _will_ have to use a
fixed-width font for this):

CPU bus
|
+-I2C -TDA998X --(HDMI)--> Display
||
|   (RGB888+clock+sync)
+-LCD0 -.   /
+--DCON ---(VGA)---> not wired
+-LCD1 (unused)-'

DCON can allegedly route the data from LCD0 or LCD1 to the parallel
interface which the TDA998x sits on, and/or the VGA interface.  In
the case of other setups, the TDA998x may be a LCD panel.

The OLPC setup (which seems to be the more common case in terms of the
on-SoC device structure):

CPU bus
|
+-LCD ---(RGB666+clock+sync)> LCD panel

and I believe an HDMI tranceiver somewhere.

In the above diagrams, "LCD" and "LCD0"/"LCD1" are essentially all the
same basic IP block, so they should use the same driver code.  Moreover,
each named element is a separate platform device.

In the first, to drive that correctly, you need the following before
"loading" the display system:
1. LCD0, and optionally LCD1 and DCON to be found and known to display driver.
2. I2C driver to be probed and available for use.
3. TDA998x to be found and known to display driver.
Only once you have all those components can you allow display to "load".

Now consider the case where the TDA998x is not present but the parallel
interface is connected directly to a LCD panel.  This then becomes:
1. LCD0, and optionally LCD1 and DCON to be found and known to display driver.
2. LCD panel details known to display driver.

If the VGA port is being used, then both of these cases need to be
supplemented with:
N. I2C bus for VGA DDC to be probed and available for use.
N+1. DCON must be known to the display driver.
N+2. LCD1 required if different display modes on the devices are required.

In the OLPC case, it's just:
1. LCD to be found and known to display driver.
2. LCD panel details known to display driver.

What you should be getting from the above is that the platform devices
which are required for any kind of display subsystem driver to initialize
is not really a function of the "software" use case, but how (a) the
board hardware has been designed and put together, and (b) the internal
structure of the SoC.

Moreover, the problem which we're facing is this: how does a display
driver know which platform devices to expect from a DT description to
make the decision that all parts required for the physical wiring of
the board are now present.

Consider this too: what if you have a LCD panel on your RGB888 interface
which is also connected to a HDMI transceiver which can do scaling and
re-syncing (basically format conversion - the TDA998x appears to have
this capability), and you drive it with a mode suitable for HDMI but not
the LCD panel because the driver doesn't know that there's a LCD panel
also connected?  This is why I feel that the hotplug idea is actually
rather unsafe, and if we go down that path we're building in that risk.

(And I think the OLPC guys may be have exactly that kind of setup...)

-- 
Russell King

[PATCH] drm/nouveau: bump fence timeout to 150 seconds

2013-07-03 Thread Maarten Lankhorst

Fixes parallel piglit runs on fermi with boot clock speeds.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 1e753b0..460dd00 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -144,7 +144,7 @@ nouveau_fence_emit(struct nouveau_fence *fence, struct 
nouveau_channel *chan)
int ret;

fence->channel  = chan;
-   fence->timeout  = jiffies + (3 * DRM_HZ);
+   fence->timeout  = jiffies + (150 * DRM_HZ);
fence->sequence = ++fctx->sequence;

ret = fctx->emit(fence);

[PATCH] drm/exynos: add error check routine in exynos_drm_open

Nice catch!!!. Applied.

Thanks,
Inki Dae

2013/7/1 Seung-Woo Kim :
> From: YoungJun Cho 
>
> When the exynos_drm_subdrv_open() returns error, the file_priv
> should be released and file->driver_priv set to NULL.
>
> Signed-off-by: YoungJun Cho 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 2762373..ca2729a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -155,6 +155,7 @@ static int exynos_drm_unload(struct drm_device *dev)
>  static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
>  {
> struct drm_exynos_file_private *file_priv;
> +   int ret;
>
> file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
> if (!file_priv)
> @@ -162,7 +163,13 @@ static int exynos_drm_open(struct drm_device *dev, 
> struct drm_file *file)
>
> file->driver_priv = file_priv;
>
> -   return exynos_drm_subdrv_open(dev, file);
> +   ret = exynos_drm_subdrv_open(dev, file);
> +   if (ret) {
> +   kfree(file_priv);
> +   file->driver_priv = NULL;
> +   }
> +
> +   return ret;
>  }
>
>  static void exynos_drm_preclose(struct drm_device *dev,
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/exynos: initialize the buf_num in vp_video_buffer

Applied.

Thanks,
Inki Dae

2013/7/1 Seung-Woo Kim :
> From: YoungJun Cho 
>
> The buf_num in vp_video_buffer() should be 1 or 2, but it is not
> initialized, and only set to 2 in NV12M or NV12MT cases.
> So this patch initializes the buf_num with 1 as default.
>
> Signed-off-by: YoungJun Cho 
> Signed-off-by: Seung-Woo Kim 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index b1280b4..42ffb71 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -379,7 +379,7 @@ static void vp_video_buffer(struct mixer_context *ctx, 
> int win)
> unsigned long flags;
> struct hdmi_win_data *win_data;
> unsigned int x_ratio, y_ratio;
> -   unsigned int buf_num;
> +   unsigned int buf_num = 1;
> dma_addr_t luma_addr[2], chroma_addr[2];
> bool tiled_mode = false;
> bool crcb_mode = false;
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/exynos: remove dead code in vidi_power_on

Applied.

Thanks,
Inki Dae

2013/7/1 Seung-Woo Kim :
> From: YoungJun Cho 
>
> The type of input parameter enable is bool, so it does not need
> to check whether true or false.
>
> Signed-off-by: YoungJun Cho 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c |3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index 784bbce..41cc74d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -413,9 +413,6 @@ static int vidi_power_on(struct vidi_context *ctx, bool 
> enable)
> struct exynos_drm_subdrv *subdrv = >subdrv;
> struct device *dev = subdrv->dev;
>
> -   if (enable != false && enable != true)
> -   return -EINVAL;
> -
> if (enable) {
> ctx->suspended = false;
>
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: fix not to remain exynos_gem_obj as a leak

Applied.

Thanks,
Inki Dae

2013/7/1 Seung-Woo Kim :
> From: YoungJun Cho 
>
> The exynos_drm_gem_create() only calls drm_gem_object_release()
> when exynos_drm_alloc_buf() is failed, and exynos_gem_obj remains
> as a leak, which is allocated in exynos_drm_gem_init().
> So this patch fixes it not to remain as a leak.
>
> Signed-off-by: YoungJun Cho 
> Signed-off-by: Seung-Woo Kim 
> Signed-off-by: Kyungmin Park 
> ---
> This patch is based on exynos-drm-next branch.
>
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index c3f15e7..24c22a8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -246,13 +246,14 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct 
> drm_device *dev,
> exynos_gem_obj->flags = flags;
>
> ret = exynos_drm_alloc_buf(dev, buf, flags);
> -   if (ret < 0) {
> -   drm_gem_object_release(_gem_obj->base);
> -   goto err_fini_buf;
> -   }
> +   if (ret < 0)
> +   goto err_gem_fini;
>
> return exynos_gem_obj;
>
> +err_gem_fini:
> +   drm_gem_object_release(_gem_obj->base);
> +   kfree(exynos_gem_obj);
>  err_fini_buf:
> exynos_drm_fini_buf(dev, buf);
> return ERR_PTR(ret);
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Best practice device tree design for display subsystems/DRM

On 07/03/13 11:02, Sascha Hauer wrote:
> On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
>>> video {
>>> /* Single video card w/ multiple lcd controllers */
>>> card0 {
>>> compatible = "marvell,armada-510-display";
>>> reg = <0 0x3f00 0x100>; /* video-mem hole */
>>> /* later: linux,video-memory-size = <0x100>; */
>>> marvell,video-devices = <  >;
>>> };
>>>
>>> /* OR: Multiple video card w/ single lcd controllers */
>>> card0 {
>>> compatible = "marvell,armada-510-display";
>>> ...
>>> marvell,video-devices = <>;
>>> };
>>>
>>> card1 {
>>> compatible = "marvell,armada-510-display";
>>> ...
>>> marvell,video-devices = <>;
>>> };
>>> };
>>
>> Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
>> really consider Linux framebuffer or other subsystems? The above dtsi file
>> is specific to DRM subsystem. And I think the dtsi file has no any
>> dependency on certain subsystem so board dtsi file should be considered for
>> all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
>> and so no. So I *strongly* object to it. All we have to do is to keep the
>> dtsi file as is, and to find other better way that can be used commonly in
>> DRM.

Sascha, Inki,

can you clarify how the above will _not_ allow you to write a fb driver
exploiting the cardX nodes?

While lcd controller and dcon are physically available, the video card
is just a virtual combination of those.

> +1 for not encoding the projected usecase of the graphics subsystem into
> the devicetree. Whether the two LCD controllers shall be used together
> or separately should not affect the devicetree. devicetree is about
> hardware description, not configuration.

Have you had a look at gpio-leds? It _is_ actually a configuration of
GPIO to be used as LED triggers. IMHO DT is just fine for describing
even "virtual" hardware you make up out of existing devices. Without it
there is no way for the subsystems to determine the configuration.

Regarding gpio-leds, how should the driver know the single gpio line
out of tens of available lines, if you do not use a virtual gpio led
node to describe it?

Sebastian

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
> > video {
> > /* Single video card w/ multiple lcd controllers */
> > card0 {
> > compatible = "marvell,armada-510-display";
> > reg = <0 0x3f00 0x100>; /* video-mem hole */
> > /* later: linux,video-memory-size = <0x100>; */
> > marvell,video-devices = <  >;
> > };
> > 
> > /* OR: Multiple video card w/ single lcd controllers */
> > card0 {
> > compatible = "marvell,armada-510-display";
> > ...
> > marvell,video-devices = <>;
> > };
> > 
> > card1 {
> > compatible = "marvell,armada-510-display";
> > ...
> > marvell,video-devices = <>;
> > };
> > };
> 
> Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
> really consider Linux framebuffer or other subsystems? The above dtsi file
> is specific to DRM subsystem. And I think the dtsi file has no any
> dependency on certain subsystem so board dtsi file should be considered for
> all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
> and so no. So I *strongly* object to it. All we have to do is to keep the
> dtsi file as is, and to find other better way that can be used commonly in
> DRM.

+1 for not encoding the projected usecase of the graphics subsystem into
the devicetree. Whether the two LCD controllers shall be used together
or separately should not affect the devicetree. devicetree is about
hardware description, not configuration.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote:
> That's not whether we can write device driver or not. dtsi is common spot in
> other subsystems. Do you think the cardX node is meaningful to other
> subsystems?

Yes, because fbdev could also use it to solve the same problem which we're
having with DRM.

-- 
Russell King

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
> On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
> > > video {
> > >   /* Single video card w/ multiple lcd controllers */
> > >   card0 {
> > >   compatible = "marvell,armada-510-display";
> > >   reg = <0 0x3f00 0x100>; /* video-mem hole */
> > >   /* later: linux,video-memory-size = <0x100>; */
> > >   marvell,video-devices = <  >;
> > >   };
> > > 
> > >   /* OR: Multiple video card w/ single lcd controllers */
> > >   card0 {
> > >   compatible = "marvell,armada-510-display";
> > >   ...
> > >   marvell,video-devices = <>;
> > >   };
> > > 
> > >   card1 {
> > >   compatible = "marvell,armada-510-display";
> > >   ...
> > >   marvell,video-devices = <>;
> > >   };
> > > };
> > 
> > Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
> > really consider Linux framebuffer or other subsystems? The above dtsi file
> > is specific to DRM subsystem. And I think the dtsi file has no any
> > dependency on certain subsystem so board dtsi file should be considered for
> > all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
> > and so no. So I *strongly* object to it. All we have to do is to keep the
> > dtsi file as is, and to find other better way that can be used commonly in
> > DRM.
> 
> +1 for not encoding the projected usecase of the graphics subsystem into
> the devicetree. Whether the two LCD controllers shall be used together
> or separately should not affect the devicetree. devicetree is about
> hardware description, not configuration.

And if we listen to that argument, then this problem is basically
impossible to solve sanely.

Are we really saying that we have no acceptable way to represent
componentized devices in DT?  If that's true, then DT fails to represent
quite a lot of ARM hardware, and frankly we shouldn't be using it.  I
can't believe that's true though.

The problem is that even with an ASoC like approach, that doesn't work
here because there's no way to know how many "components" to expect.
That's what the "supernode" is doing - telling us what components group
together to form a device.

Moreover, if you pay attention to my proposal, what you will realise is
that it isn't DRM specific - it's totally subsystem agnostic.  All it's
doing is collecting a set of other devices together and only then
publishing a device representing the full set of sub-devices.

Now think about that: what is DRM specific about that solution?  What
is the DRM specific about "collecting a set of devices together and
publishing a new device" ?

How is this not "describing the hardware"?  If I attach a HDMI transceiver
to the DCON which is then connected to LCD0, is it not "describing the
hardware" to put into DT that LCD0, DCON, and the HDMI transceiver are
all connected together and therefore are required?  One of the points of
DT after all is that it can and should be used to represent the
relationship between devices.

No - using the tree approach doesn't work, because LCD0, LCD1 and DCON
are all on the same physical bus, but are themselves connected together.
If you like, there are multiple heirarchies here - there's the bus
heirarchy, and then there's the device heirarchy.  Both of these
heirarchies need to be represented in DT, otherwise you're not describing
the hardware properly.

-- 
Russell King

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] ERROR radeon: error initializing UVD (-1).

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

--- Comment #7 from Justin Piszcz  ---
Created attachment 81952
  --> https://bugs.freedesktop.org/attachment.cgi?id=81952=edit
dmesg with patch

-- 
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/20130703/11ff26a9/attachment.html>

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] ERROR radeon: error initializing UVD (-1).

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

--- Comment #6 from Justin Piszcz  ---
attach(In reply to comment #5)
> Created attachment 81945 [details] [review]
> Debugging patch
> 
> Please try the attached patch, it shouldn't fix the issue but instead
> outputs some debug messages ("IH: CP") into dmesg.
> 
> If you don't see those messages try to but the system under some graphics
> load, for example start glxgears ten times simultaneously or something like
> that.

Yes, that is what happened:

[  334.326551] [drm:evergreen_irq_process] *ERROR* IH: CP EOP
[  334.326700] [drm:evergreen_irq_process] *ERROR* IH: CP EOP
[  334.326922] [drm:evergreen_irq_process] *ERROR* IH: CP EOP
[  334.327071] [drm:evergreen_irq_process] *ERROR* IH: CP EOP
[  334.327190] [drm:evergreen_irq_process] *ERROR* IH: CP EOP

Attaching full dmesg 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/20130703/470cf6f5/attachment.html>

Best practice device tree design for display subsystems/DRM

On 07/03/13 08:55, Sascha Hauer wrote:
> On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
>> Have you also considered how suspend/resume works in such a place,
>> where every driver is independent? The ChromeOS guys have bitched
>> before about the exynos driver which is has lots of sub-drivers, how
>> do you control the s/r ordering in a crazy system like that? I'd
>> prefer a central driver, otherwise there is too many moving parts.
>
> Composing a DRM device out of subdevices doesn't necessarily mean the
> components should be suspended/resumed in arbitrary order. The DRM
> device should always be suspended first (thus deactivating sub devices
> as necessary and as done already) and resumed last.
>
> Note that a super node approach does not solve this magically. We would
> still have to make sure that the i2c bus masters on our SoC are suspended
> after the DRM device.

+1 for a video card supernode that at best should be some very generic
node with standard properties provided by DRM backend. IIRC there was
a proposal for of_video_card a while ago.

At least for Marvell SoCs, moving device nodes out of the bus structure
will not work. The parent bus is _required_ for address mapping as the
base address is configurable. Using phandles can solve this without
moving nodes.

Also, having separate device nodes does not require a separate driver
for each nodes. All nodes get platform_devices registered, but you can
choose not to have a matching driver for it. Then the video card super
node can pick up that nodes by using the phandles passed and register
a single DRM driver claiming the devices.

Moreover, if we talk about SoC graphics, we have to take audio into
account. If you move all nodes to your video card super node, you will
add another bunch of issues for ASoC linking to e.g. the I2C HDMI
transmitter SPDIF codec.

IMHO phandles and super node subnodes are equivalent from a driver
point-of-view but phandles are more likely to cause less pain for
other subsystems.

The super node approach will also allow to have the same SoC/board
components being used as single video card or multiple video cards
environment. There is virtually no way to automatically determine what
devices belong to "your" video card(s) in a SoC, so we need something to
describe those cards.

One thing I am concerned about is what Sascha pointed out above. If you
hook up an external I2C encoder to your card, you cannot make sure I2C
bus is suspended before DRM device. To be honest, proposing a solution
for that is still way beyond my expertise wrt to Linux internals, so I
am not even trying it. Maybe I am even missing a very important point
for the super node/phandle proposal, if so, please clarify.

Sebastian

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600 [Solved]

2013-07-03 Thread Jörg-Volker Peetz

Alex Deucher wrote, on 07/03/2013 00:49:
> On Tue, Jul 2, 2013 at 4:34 PM, J?rg-Volker Peetz  wrote:
>> Alex Deucher wrote, on 07/02/2013 22:17:
>>> On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz  wrote:
 Alex Deucher wrote, on 07/02/2013 21:46:
> On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz  
> wrote:
>> With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics 
>> (ATI
>> RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Radeon 
>> HD 5400
>> Series]) uvd seems to be broken.
>>
>> The new firware files are installed in /lib/firmware/radeon:
>>
>> sha1 hashes
>> 3142a64061ade6032c95ed948c85b15dd0ae46be  CEDAR_me.bin
>> a92856a4fa16926e2451a6335da7e20f01fde210  CEDAR_pfp.bin
>> 644b29756636687ad31a49da4aa3ed85dcedecdb  CEDAR_rlc.bin
>> 992d49518d3936986b5ce3ddb0d9bbd75135bb8f  CYPRESS_uvd.bin
>> 3e04529600d666ddb2f2f83bb0112d4fab516c04  R600_rlc.bin
>>
>> The system boots without initial ram disk.
>
> Make sure your system is using the latest CEDAR_rlc.bin as well.
>
> Alex
>
 Thanks for the hint, Alex. Actually I took the files today from your 
 repository
 at http://people.freedesktop.org/~agd5f/radeon_ucode/ and checked them 
 against
 the ones downloaded from
 http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git .
>>>
>>> Make sure that your kernel is actually using the new ones.
>>>
>>> Alex
>>>
>>
>> The files are located in /lib/firmware/radeon , the kernel configuration 
>> contains
>>
>> CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin radeon/R600_rlc.bin
>> radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin
>> radeon/CYPRESS_uvd.bin"
>> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>>
>> I compiled the kernel with the firmware files already in 
>> /lib/firmware/radeon .
>> The kernel boots without initial ram disk.
>>
> 
> I've encountered people having all sorts of problems with stale or
> truncated firmware, so I just wanted to double check.  The best test
> would be to build the driver as a module and blacklist the module,
> then, once the system is booted to a non-X runlevel, manually load the
> module so it loads the ucode directly from the filesystem.
> 
> Alex
> 
Thank you Alex, for insisting. The "Denkfehler" was indeed at my side: At first,
I compiled the kernel with the old firmware. Then I noticed the missing firmware
module "CYPRESS_uvd.bin". After an information trip around the internet, I
downloaded the missing and the up-to-date firmware modules and put them into
place as well as adapted the kernel configuration.
Then I just did a new "make" in the kernel directory.

But, it seems the make rules don't recognize changed firmware modules. In the
end I still saw the described error messages in the dmesg-output.
Today, after reading your e-mail I came to this conclusion and recompiled the
kernel completely, i.e., beginning with a "make clean". And, voil?, everything
now works.

Best regards,
J?rg-Volker.

[P.S.: I'm sorry, if you receive this letter twice, I somehow didn't send it to
the list the first time.]

[ANNOUNCE] libdrm 2.4.46

2013-07-03 Thread Dave Airlie

On Wed, Jul 3, 2013 at 9:55 AM, Laurent Pinchart
 wrote:
> Hi Dave,
>
> On Tuesday 02 July 2013 18:22:01 Dave Airlie wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Release because I want the cursor ioctls released,
>> also haswell and radeon ids.
>
> Any chance to get the "[PATCH v6 00/23] modetest enhancements" series included
> in the next release ?

Do you not have commit access? if not I'd advise getting it,

libdrm is maintained by everyone collectively and gets released when
someone sees the need for something in git.

I certainly don't pull patches in from others to it very often, and
modetest I generally blame on jbarnes.

Dave.

Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 11:14:45PM +0100, Russell King wrote:
> On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
> > Have you also considered how suspend/resume works in such a place,
> > where every driver is independent? The ChromeOS guys have bitched
> > before about the exynos driver which is has lots of sub-drivers, how
> > do you control the s/r ordering in a crazy system like that? I'd
> > prefer a central driver, otherwise there is too many moving parts.
> 
> From earlier in the evolution of Armada DRM, that has also been my
> preferred idea - though probably not quite how people think.
> 
> My idea was to have a separate "driver" assemble all the constituent
> parts, and then register the "armada-drm" platform device providing
> via platform resources and/or platform data all the necessary
> information (maybe not even bothering to decode the OF nodes but just
> provide a collection of nodes for each consituent part.)

This sounds similar to what ASoC does. There a sound device is a
devicenode which only has phandles to the various components which
are still registered by the regular device model.

What I'm currently missing in DRM is a place where I can register the
various components (analog to snd_soc_register_codec /
snd_soc_register_component)  until some upper layer DRM driver collects
the pieces and registers a DRM device (as said, no need for real
hotplug).

If we had this component, there would be no need for i2c encoder helpers
which insist on registering their own i2c devices instead of using the
devices which are found in the devicetree.

> 
> Such a thing could be turned into a generic solution for all the
> multi-part drivers.  If we use Sebastian's idea of using phandles
> (it seems there's a precident for it with the direction v4l2 is
> going to solve a similar problem) then we likely have a standard
> way of describing component-ized display setups in DT.

What the v4l2 guys are currently doing is definitely worth looking
at before we come up with a different approach for DRM. v4l2 has the
same problems, it would be a shame if we come up with a totally
different solution.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[pull] radeon drm-next-3.11

2013-07-03 Thread Alex Deucher

On Wed, Jul 3, 2013 at 2:39 AM, Ruslan N. Marchenko  
wrote:
> Am 01.07.2013 23:01, schrieb alexdeucher at gmail.com:
>>
>> From: Alex Deucher
>>
>> Hi Dave,
>>
>> A few more patches for 3.11:
>> - add debugfs interface to check current DPM state
>> - Fix a bug that caused problems with DPM on BTC+ asics.
>>
>> The following changes since commit
>> f7d452f4fd5d86f764807a1234a407deb5b105ef:
>>
>>Merge branch 'drm-nouveau-next' of
>> git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
>> (2013-07-01 14:10:20 +1000)
>>
>> are available in the git repository at:
>>
>>git://people.freedesktop.org/~agd5f/linux drm-next-3.11
>>
>> Alex Deucher (12):
>>drm/radeon: remove sumo dpm/uvd bringup leftovers
>>drm/radeon/atom: fix endian bug in radeon_atom_init_mc_reg_table()
>>drm/radeon: fix typo in radeon_atom_init_mc_reg_table()
>>drm/radeon/dpm: re-enable state transitions for BTC
>>drm/radeon/dpm: re-enable state transitions for Cayman
>>drm/radeon/dpm: add infrastructure to support debugfs info
>>drm/radeon/dpm: add debugfs support for rv6xx
>>drm/radeon/dpm: add debugfs support for 7xx/evergreen/btc
>>drm/radeon/dpm: add debugfs support for ON/LN
>>drm/radeon/dpm: add debugfs support for TN
>>drm/radeon/dpm: add debugfs support for cayman
>>drm/radeon/dpm: add debugfs support for SI
>>
>>   drivers/gpu/drm/radeon/btc_dpm.c |3 --
>>   drivers/gpu/drm/radeon/ni_dpm.c  |   25 +---
>>   drivers/gpu/drm/radeon/nid.h |4 ++
>>   drivers/gpu/drm/radeon/radeon.h  |2 +
>>   drivers/gpu/drm/radeon/radeon_asic.c |8 +
>>   drivers/gpu/drm/radeon/radeon_asic.h |   12 
>>   drivers/gpu/drm/radeon/radeon_atombios.c |3 +-
>>   drivers/gpu/drm/radeon/radeon_pm.c   |   40
>> ++
>>   drivers/gpu/drm/radeon/rv6xx_dpm.c   |   25 
>>   drivers/gpu/drm/radeon/rv770_dpm.c   |   30 
>>   drivers/gpu/drm/radeon/rv770d.h  |4 ++
>>   drivers/gpu/drm/radeon/si_dpm.c  |   19 
>>   drivers/gpu/drm/radeon/sid.h |4 ++
>>   drivers/gpu/drm/radeon/sumo_dpm.c|   45
>> ++---
>>   drivers/gpu/drm/radeon/trinity_dpm.c |   21 ++
>>   15 files changed, 206 insertions(+), 39 deletions(-)
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> This is really excellent and very wanted addition to the radeon, a huge
> thanks Alex for giving a second life to my old TimelineX with hybrid
> AMD/Intel graphics. Intel ironlake became a bit outdated already but with
> ATi HD 5650 I was able to drink tee all day long since it never came lower
> than 90 degrees Celsius.   Now it comfortably sits at 55-60 so I can use it
> back again.
>
> As I noticed it supports now either dynpm or profile method of clocking,
> however profiles themselves also have several (3) power states. Also during
> init phase it writes that it switching from boot to performance profile - so
> what exactly is the difference between dpm and profile method? Will dynpm
> react to ACPI events like lid closed or AC offline or I better to add calls
> to acpid event handlers to tweak the profiles/methods?

With with the old profile/dynpm methods, the driver was responsible
for changing the power states.  With dpm, there is dedicated hardware
on the GPU that automatically changes the power levels based on GPU
load.  E.g., when you have an idle desktop, the hw will put the gpu
into the lowest power level, when you start to use the 3D engine,
etc., it will automatically switch the GPU into higher power levels.
With dpm you can also manually switch between performance and battery
states.  Both states will automatically switch between power levels,
but the battery state generally has a narrower range of power levels.
The driver could automatically transition based on acpi events (there
was an option do to that with the old profile method), but that's not
currently hooked up and that's more of a policy choice, so it seems
like something that would be better handled in userspace (e.g., you
may want to use the performance state even when ac is offline or you
may want to use the battery state when AC is connected, etc.).

Alex

3.10 kernel: [drm:evergreen_startup] ERROR radeon: error initializing UVD (-1). [SOLVED]

2013-07-03 Thread Justin Piszcz

-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com] 
Sent: Tuesday, July 02, 2013 3:41 PM
To: Justin Piszcz
Cc: linux-kernel at vger.kernel.org; dri-devel at lists.freedesktop.org
Subject: Re: 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error
initializing UVD (-1).

Please open a bug (product: DRI, component: DRM/Radeon):
https://bugs.freedesktop.org
and attach your dmesg output and xorg log.

Alex

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

Grabbed firmware, removed distribution firmware package, re-built kernel and
all is working now, thanks!

Justin.

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600 [Solved]

2013-07-03 Thread Jörg-Volker Peetz

Alex Deucher wrote, on 07/03/2013 00:49:
> On Tue, Jul 2, 2013 at 4:34 PM, J?rg-Volker Peetz  wrote:
>> Alex Deucher wrote, on 07/02/2013 22:17:
>>> On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz  wrote:
 Alex Deucher wrote, on 07/02/2013 21:46:
> On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz  
> wrote:
>> With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics 
>> (ATI
>> RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Radeon 
>> HD 5400
>> Series]) uvd seems to be broken.
>>
>> The new firware files are installed in /lib/firmware/radeon:
>>
>> sha1 hashes
>> 3142a64061ade6032c95ed948c85b15dd0ae46be  CEDAR_me.bin
>> a92856a4fa16926e2451a6335da7e20f01fde210  CEDAR_pfp.bin
>> 644b29756636687ad31a49da4aa3ed85dcedecdb  CEDAR_rlc.bin
>> 992d49518d3936986b5ce3ddb0d9bbd75135bb8f  CYPRESS_uvd.bin
>> 3e04529600d666ddb2f2f83bb0112d4fab516c04  R600_rlc.bin
>>
>> The system boots without initial ram disk.
>
> Make sure your system is using the latest CEDAR_rlc.bin as well.
>
> Alex
>
 Thanks for the hint, Alex. Actually I took the files today from your 
 repository
 at http://people.freedesktop.org/~agd5f/radeon_ucode/ and checked them 
 against
 the ones downloaded from
 http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git .
>>>
>>> Make sure that your kernel is actually using the new ones.
>>>
>>> Alex
>>>
>>
>> The files are located in /lib/firmware/radeon , the kernel configuration 
>> contains
>>
>> CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin radeon/R600_rlc.bin
>> radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin
>> radeon/CYPRESS_uvd.bin"
>> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>>
>> I compiled the kernel with the firmware files already in 
>> /lib/firmware/radeon .
>> The kernel boots without initial ram disk.
>>
> 
> I've encountered people having all sorts of problems with stale or
> truncated firmware, so I just wanted to double check.  The best test
> would be to build the driver as a module and blacklist the module,
> then, once the system is booted to a non-X runlevel, manually load the
> module so it loads the ucode directly from the filesystem.
> 
> Alex
> 
Thank you Alex, for insisting. The "Denkfehler" was indeed at my side: At first,
I compiled the kernel with the old firmware. Then I noticed the missing firmware
module "CYPRESS_uvd.bin". After an information trip around the internet, I
downloaded the missing and the up-to-date firmware modules and put them into
place as well as adapted the kernel configuration.
Then I just did a new "make" in the kernel directory.

But, it seems the make rules don't recognize changed firmware modules. In the
end I still saw the described error messages in the dmesg-output.
Today, after reading your e-mail I came to this conclusion and recompiled the
kernel completely, i.e., beginning with a "make clean". And, voil?, everything
now works.

Best regards,
J?rg-Volker.

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

2013-07-03 Thread YoungJun Cho

Dear Mr.Dae,

On Jul 2, 2013 9:42 PM, "Inki Dae"  wrote:
>
> 2013/7/2 YoungJun Cho :
> > Dear Ville
> >
> > On Jul 2, 2013 8:42 PM, "Ville Syrj?l?" 
> > wrote:
> >>
> >> On Tue, Jul 02, 2013 at 07:59:22PM +0900, Seung-Woo Kim wrote:
> >> > From: YoungJun Cho 
> >> >
> >> > When drm iommu is not supported, buf->pages has to be allocated
> >> > and assigned to phys_to_page() result, which type is struct page *.
> >> > So it is sufficient to allocate buf->pages with multiple struct
> >> > page pointer size.
> >> >
> >> > Signed-off-by: YoungJun Cho 
> >> > Signed-off-by: Kyungmin Park 
> >> > ---
> >> >  drivers/gpu/drm/exynos/exynos_drm_buf.c |2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
> >> > b/drivers/gpu/drm/exynos/exynos_drm_buf.c
> >> > index 22865ba..3200622 100644
> >> > --- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
> >> > +++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
> >> > @@ -57,7 +57,7 @@ static int lowlevel_buffer_allocate(struct
drm_device
> >> > *dev,
> >> >   dma_addr_t start_addr;
> >> >   unsigned int i = 0;
> >> >
> >> > - buf->pages = kzalloc(sizeof(struct page) * nr_pages,
> >> > + buf->pages = kzalloc(sizeof(struct page *) * nr_pages,
> >> >   GFP_KERNEL);
> >>
> >> Looks like a prime candidate for kcalloc()
> >>
> >
> > Thank you for nice comments.
> > I had no idea to consider overflow!
> >
> > I'll update again.
>
> Mr. Cho,
>
> it seems better to use utility function, drm_calloc_large().
>

Your comment is more suitable for this patch. I'll use it.

Thank you!

Best regards YJ

> Thanks,
> Inki Dae
>
> >
> > Best regards YJ
> >
> >> >   if (!buf->pages) {
> >> >   DRM_ERROR("failed to allocate pages.\n");
> >> > --
> >> > 1.7.9.5
> >> >
> >> > ___
> >> > dri-devel mailing list
> >> > dri-devel at lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>
> >> --
> >> Ville Syrj?l?
> >> Intel OTC
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130703/a130c657/attachment-0001.html>

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600 [Solved]

2013-07-03 Thread Alex Deucher

On Wed, Jul 3, 2013 at 3:14 AM, J?rg-Volker Peetz  
wrote:
> Alex Deucher wrote, on 07/03/2013 00:49:
>> On Tue, Jul 2, 2013 at 4:34 PM, J?rg-Volker Peetz  wrote:
>>> Alex Deucher wrote, on 07/02/2013 22:17:
 On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz  
 wrote:
> Alex Deucher wrote, on 07/02/2013 21:46:
>> On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz  
>> wrote:
>>> With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics 
>>> (ATI
>>> RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility 
>>> Radeon HD 5400
>>> Series]) uvd seems to be broken.
>>>
>>> The new firware files are installed in /lib/firmware/radeon:
>>>
>>> sha1 hashes
>>> 3142a64061ade6032c95ed948c85b15dd0ae46be  CEDAR_me.bin
>>> a92856a4fa16926e2451a6335da7e20f01fde210  CEDAR_pfp.bin
>>> 644b29756636687ad31a49da4aa3ed85dcedecdb  CEDAR_rlc.bin
>>> 992d49518d3936986b5ce3ddb0d9bbd75135bb8f  CYPRESS_uvd.bin
>>> 3e04529600d666ddb2f2f83bb0112d4fab516c04  R600_rlc.bin
>>>
>>> The system boots without initial ram disk.
>>
>> Make sure your system is using the latest CEDAR_rlc.bin as well.
>>
>> Alex
>>
> Thanks for the hint, Alex. Actually I took the files today from your 
> repository
> at http://people.freedesktop.org/~agd5f/radeon_ucode/ and checked them 
> against
> the ones downloaded from
> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git .

 Make sure that your kernel is actually using the new ones.

 Alex

>>>
>>> The files are located in /lib/firmware/radeon , the kernel configuration 
>>> contains
>>>
>>> CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin radeon/R600_rlc.bin
>>> radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin
>>> radeon/CYPRESS_uvd.bin"
>>> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>>>
>>> I compiled the kernel with the firmware files already in 
>>> /lib/firmware/radeon .
>>> The kernel boots without initial ram disk.
>>>
>>
>> I've encountered people having all sorts of problems with stale or
>> truncated firmware, so I just wanted to double check.  The best test
>> would be to build the driver as a module and blacklist the module,
>> then, once the system is booted to a non-X runlevel, manually load the
>> module so it loads the ucode directly from the filesystem.
>>
>> Alex
>>
> Thank you Alex, for insisting. The "Denkfehler" was indeed at my side: At 
> first,
> I compiled the kernel with the old firmware. Then I noticed the missing 
> firmware
> module "CYPRESS_uvd.bin". After an information trip around the internet, I
> downloaded the missing and the up-to-date firmware modules and put them into
> place as well as adapted the kernel configuration.
> Then I just did a new "make" in the kernel directory.
>
> But, it seems the make rules don't recognize changed firmware modules. In the
> end I still saw the described error messages in the dmesg-output.
> Today, after reading your e-mail I came to this conclusion and recompiled the
> kernel completely, i.e., beginning with a "make clean". And, voil?, everything
> now works.

Glad to hear you got it working!

Alex

MacBook Pro 10,1 + i915

2013-07-03 Thread Chris Wilson

On Mon, Jul 01, 2013 at 10:39:14PM +0200, Marek Vasut wrote:
> Hi guys,
> 
> I recently got the rMBP 10,1 model, it has two graphic cards:
> 
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor 
> Graphics Controller (rev 09)
> 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 650M 
> Mac Edition] (rev a1)
> 
> I'm running linux 3.10-rc7 . The nvidia works with nouveau, but I'd prefer to 
> switch the nvidia off altogether and use the intel GPU.
> 
> So far I arrived at the point where I disabled X11, mounted debugfs and tried 
> the vgaswitcheroo. With the nvidia still in operation, I see the console. 
> Unfortunatelly, I end up with a black screen after I run the following 
> command 
> to switch to the intel GPU:
> 
> echo IGD > /sys/kernel/debug/vgaswitcheroo/switch
> 
> If I try to switch back to the nvidia card (using echo DIS > ...), the screen 
> remains black. This state persists until reboot. I suspect [1] is the same 
> bug, 
> none of the hints there helped.

It is not that bug. This bug I believe is that no one has figured out
how to reprobe the eDP and initialise it after a vgaswitch.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
> On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer  
> wrote:
> > On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
> >> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
> >> > I am against a super node which contains lcd and dcon/ire nodes. You can
> >> > enable those devices on a per board basis. We add them to dove.dtsi but
> >> > disable them by default (status = "disabled").
> >> >
> >> > The DRM driver itself should get a video-card node outside of
> >> > soc/internal-regs where you can put e.g. video memory hole (or video
> >> > mem size if it will be taken from RAM later)
> >> >
> >> > About the unusual case, I guess we should try to get both lcd
> >> > controllers into one DRM driver. Then support mirror or screen
> >> > extension X already provides. For those applications where you want
> >> > X on one lcd and some other totally different video stream - wait
> >> > for someone to come up with a request or proposal.
> >>
> >> Well, all I can say then is that the onus is on those who want to treat
> >> the components as separate devices to come up with some foolproof way
> >> to solve this problem which doesn't involve making assumptions about
> >> the way that devices are probed and doesn't end up creating artificial
> >> restrictions on how the devices can be used - and doesn't end up burdening
> >> the common case with lots of useless complexity that they don't need.
> >>
> >> It's _that_ case which needs to come up with a proposal about how to
> >> handle it because you _can't_ handle it at the moment in any sane
> >> manner which meets the criteria I've set out above, and at the moment
> >> the best proposal by far to resolve that is the "super node" approach.
> >>
> >> There is _no_ way in the device model to combine several individual
> >> devices together into one logical device safely when the subsystem
> >> requires that there be a definite point where everything is known.
> >> That applies even more so with -EPROBE_DEFER.  With the presence of
> >> such a thing, there is now no logical point where any code can say
> >> definitively that the system has technically finished booting and all
> >> resources are known.
> >>
> >> That's the problem - if you don't od the super-node approach, you end
> >> up with lots of individual devices which you have to figure out some
> >> way of combining, and coping with missing ones which might not be
> >> available in the order you want them to be, etc.
> >>
> >> That's the advantage of the "super node" approach - it's a container
> >> to tell you what's required in order to complete the creation of the
> >> logical device, and you can parse the sub-nodes to locate the
> >> information you need.
> >
> > I think such an approach would lead to drm drivers which all parse their
> > "super nodes" themselves and driver authors would become very creative
> > how such a node should look like.
> >
> > Also this gets messy with i2c devices which are normally registered
> > under their i2c bus masters. With the super node approach these would
> > have to live under the super node, maybe with a phandle to the i2c bus
> > master. This again probably leads to very SoC specific solutions. It
> > also doesn't solve the problem that the i2c bus master needs to be
> > registered by the time the DRM driver probes.
> >
> > On i.MX the IPU unit not only handles the display path but also the
> > capture path. v4l2 begins to evolve an OF model in which each (sub)device
> > has its natural position in the devicetree; the devices are then
> > connected with phandles. I'm not sure how good this will work together
> > with a super node approach.
> >
> >>
> >> An alternative as I see it is that DRM - and not only DRM but also
> >> the DRM API and Xorg - would need to evolve hotplug support for the
> >> various parts of the display subsystem.  Do we have enough people
> >> with sufficient knowledge and willingness to be able to make all
> >> that happen?  I don't think we do, and I don't see that there's any
> >> funding out there to make such a project happen, which would make it
> >> a volunteer/spare time effort.
> >
> > +1 for this solution, even if this means more work to get from the
> > ground.
> >
> > Do we really need full hotplug support in the DRM API and Xorg? I mean
> > it would really be nice if Xorg detected a newly registered device, but
> > as a start it should be sufficient when Xorg detects what's there when
> > it starts, no?
> 
> Since fbdev and fbcon sit on top of drm to provide the console
> currently I'd also expect some fun with them. How do I get a console
> if I have no outputs at boot, but I have crtcs? do I just wait around
> until an output appears.

I thought the console/fb stuff should go away.

> 
> There are a number of issues with hotplugging encoders and connectors
> at runtime, when really the SoC/board designer knows what it provides
> and should be able

[pull] radeon drm-next-3.11

2013-07-03 Thread Ruslan N. Marchenko

Am 01.07.2013 23:01, schrieb alexdeucher at gmail.com:
> From: Alex Deucher
>
> Hi Dave,
>
> A few more patches for 3.11:
> - add debugfs interface to check current DPM state
> - Fix a bug that caused problems with DPM on BTC+ asics.
>
> The following changes since commit f7d452f4fd5d86f764807a1234a407deb5b105ef:
>
>Merge branch 'drm-nouveau-next' of 
> git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-07-01 
> 14:10:20 +1000)
>
> are available in the git repository at:
>
>git://people.freedesktop.org/~agd5f/linux drm-next-3.11
>
> Alex Deucher (12):
>drm/radeon: remove sumo dpm/uvd bringup leftovers
>drm/radeon/atom: fix endian bug in radeon_atom_init_mc_reg_table()
>drm/radeon: fix typo in radeon_atom_init_mc_reg_table()
>drm/radeon/dpm: re-enable state transitions for BTC
>drm/radeon/dpm: re-enable state transitions for Cayman
>drm/radeon/dpm: add infrastructure to support debugfs info
>drm/radeon/dpm: add debugfs support for rv6xx
>drm/radeon/dpm: add debugfs support for 7xx/evergreen/btc
>drm/radeon/dpm: add debugfs support for ON/LN
>drm/radeon/dpm: add debugfs support for TN
>drm/radeon/dpm: add debugfs support for cayman
>drm/radeon/dpm: add debugfs support for SI
>
>   drivers/gpu/drm/radeon/btc_dpm.c |3 --
>   drivers/gpu/drm/radeon/ni_dpm.c  |   25 +---
>   drivers/gpu/drm/radeon/nid.h |4 ++
>   drivers/gpu/drm/radeon/radeon.h  |2 +
>   drivers/gpu/drm/radeon/radeon_asic.c |8 +
>   drivers/gpu/drm/radeon/radeon_asic.h |   12 
>   drivers/gpu/drm/radeon/radeon_atombios.c |3 +-
>   drivers/gpu/drm/radeon/radeon_pm.c   |   40 ++
>   drivers/gpu/drm/radeon/rv6xx_dpm.c   |   25 
>   drivers/gpu/drm/radeon/rv770_dpm.c   |   30 
>   drivers/gpu/drm/radeon/rv770d.h  |4 ++
>   drivers/gpu/drm/radeon/si_dpm.c  |   19 
>   drivers/gpu/drm/radeon/sid.h |4 ++
>   drivers/gpu/drm/radeon/sumo_dpm.c|   45 
> ++---
>   drivers/gpu/drm/radeon/trinity_dpm.c |   21 ++
>   15 files changed, 206 insertions(+), 39 deletions(-)
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
This is really excellent and very wanted addition to the radeon, a huge 
thanks Alex for giving a second life to my old TimelineX with hybrid 
AMD/Intel graphics. Intel ironlake became a bit outdated already but 
with ATi HD 5650 I was able to drink tee all day long since it never 
came lower than 90 degrees Celsius.   Now it comfortably sits at 55-60 
so I can use it back again.

As I noticed it supports now either dynpm or profile method of clocking, 
however profiles themselves also have several (3) power states. Also 
during init phase it writes that it switching from boot to performance 
profile - so what exactly is the difference between dpm and profile 
method? Will dynpm react to ACPI events like lid closed or AC offline or 
I better to add calls to acpid event handlers to tweak the profiles/methods?

In any case it's just a new breath to my relict brick, especially now 
when its successor is at service repair :)

-- 
Looking forward to reading yours...
  Ruslan N. Marchenko

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] ERROR radeon: error initializing UVD (-1).

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

--- Comment #5 from Christian K?nig  ---
Created attachment 81945
  --> https://bugs.freedesktop.org/attachment.cgi?id=81945=edit
Debugging patch

Please try the attached patch, it shouldn't fix the issue but instead outputs
some debug messages ("IH: CP") into dmesg.

If you don't see those messages try to but the system under some graphics load,
for example start glxgears ten times simultaneously or something like that.

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

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] ERROR radeon: error initializing UVD (-1).

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

-- 
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/20130703/6f78c822/attachment.html>

Best practice device tree design for display subsystems/DRM

2013-07-03 Thread Dave Airlie

On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer  wrote:
> On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
>> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
>> > I am against a super node which contains lcd and dcon/ire nodes. You can
>> > enable those devices on a per board basis. We add them to dove.dtsi but
>> > disable them by default (status = "disabled").
>> >
>> > The DRM driver itself should get a video-card node outside of
>> > soc/internal-regs where you can put e.g. video memory hole (or video
>> > mem size if it will be taken from RAM later)
>> >
>> > About the unusual case, I guess we should try to get both lcd
>> > controllers into one DRM driver. Then support mirror or screen
>> > extension X already provides. For those applications where you want
>> > X on one lcd and some other totally different video stream - wait
>> > for someone to come up with a request or proposal.
>>
>> Well, all I can say then is that the onus is on those who want to treat
>> the components as separate devices to come up with some foolproof way
>> to solve this problem which doesn't involve making assumptions about
>> the way that devices are probed and doesn't end up creating artificial
>> restrictions on how the devices can be used - and doesn't end up burdening
>> the common case with lots of useless complexity that they don't need.
>>
>> It's _that_ case which needs to come up with a proposal about how to
>> handle it because you _can't_ handle it at the moment in any sane
>> manner which meets the criteria I've set out above, and at the moment
>> the best proposal by far to resolve that is the "super node" approach.
>>
>> There is _no_ way in the device model to combine several individual
>> devices together into one logical device safely when the subsystem
>> requires that there be a definite point where everything is known.
>> That applies even more so with -EPROBE_DEFER.  With the presence of
>> such a thing, there is now no logical point where any code can say
>> definitively that the system has technically finished booting and all
>> resources are known.
>>
>> That's the problem - if you don't od the super-node approach, you end
>> up with lots of individual devices which you have to figure out some
>> way of combining, and coping with missing ones which might not be
>> available in the order you want them to be, etc.
>>
>> That's the advantage of the "super node" approach - it's a container
>> to tell you what's required in order to complete the creation of the
>> logical device, and you can parse the sub-nodes to locate the
>> information you need.
>
> I think such an approach would lead to drm drivers which all parse their
> "super nodes" themselves and driver authors would become very creative
> how such a node should look like.
>
> Also this gets messy with i2c devices which are normally registered
> under their i2c bus masters. With the super node approach these would
> have to live under the super node, maybe with a phandle to the i2c bus
> master. This again probably leads to very SoC specific solutions. It
> also doesn't solve the problem that the i2c bus master needs to be
> registered by the time the DRM driver probes.
>
> On i.MX the IPU unit not only handles the display path but also the
> capture path. v4l2 begins to evolve an OF model in which each (sub)device
> has its natural position in the devicetree; the devices are then
> connected with phandles. I'm not sure how good this will work together
> with a super node approach.
>
>>
>> An alternative as I see it is that DRM - and not only DRM but also
>> the DRM API and Xorg - would need to evolve hotplug support for the
>> various parts of the display subsystem.  Do we have enough people
>> with sufficient knowledge and willingness to be able to make all
>> that happen?  I don't think we do, and I don't see that there's any
>> funding out there to make such a project happen, which would make it
>> a volunteer/spare time effort.
>
> +1 for this solution, even if this means more work to get from the
> ground.
>
> Do we really need full hotplug support in the DRM API and Xorg? I mean
> it would really be nice if Xorg detected a newly registered device, but
> as a start it should be sufficient when Xorg detects what's there when
> it starts, no?

Since fbdev and fbcon sit on top of drm to provide the console
currently I'd also expect some fun with them. How do I get a console
if I have no outputs at boot, but I have crtcs? do I just wait around
until an output appears.

There are a number of issues with hotplugging encoders and connectors
at runtime, when really the SoC/board designer knows what it provides
and should be able to tell the driver in some fashion.

The main problems when I played with hot adding eDP on Intel last
time, are we have grouping of crtc/encoder/connectors for multi-seat
future use, these groups need to be updated, and I think the other
issue was updating the

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

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

--- Comment #5 from Austin Lund  ---
Pretty sure the instability has nothing to do with this.

So I guess this bug is about the failing IB test and long delay to resume the
display.

As far as I can tell, this would happen whenever the system suspend fails after
deactivating the drivers and the PM system restarts everything when the system
hasn't actually suspended.  The "pm_test" file just seems to cause an error
return value at an appropriate point in the suspend code.  When the system
actually sleeps the uvd suspend code seems fine, but if it doesn't sleep then
there is this delay.

I'm not sure if this would help in making a work-around.

-- 
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/20130703/11d9d10a/attachment.html>

[PATCH] drm/nva3/disp: Fix HDMI audio regression

2013-07-03 Thread Ilia Mirkin

This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix
HDMI audio regression). The regression happened as a result of
refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into
core).

Reported-and-tested-by: Max Baldwin 
Signed-off-by: Ilia Mirkin 
---

The actual testing was done on a NVCF card (550 Ti). Prior to this,
AC3/DTS audio passthrough worked, but regular audio did not. With this
change, regular audio started to work too. This should probably be
sent to stable as well.

 drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
index f065fc2..db8c6fd 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
@@ -55,6 +55,10 @@ nva3_hdmi_ctrl(struct nv50_disp_priv *priv, int head, int 
or, u32 data)
nv_wr32(priv, 0x61c510 + soff, 0x);
nv_mask(priv, 0x61c500 + soff, 0x0001, 0x0001);

+   nv_mask(priv, 0x61c5d0 + soff, 0x00070001, 0x00010001); /* SPARE, 
HW_CTS */
+   nv_mask(priv, 0x61c568 + soff, 0x00010101, 0x); /* ACR_CTRL, ?? 
*/
+   nv_mask(priv, 0x61c578 + soff, 0x8000, 0x8000); /* 
ACR_0441_ENABLE */
+
/* ??? */
nv_mask(priv, 0x61733c, 0x0010, 0x0010); /* RESETF */
nv_mask(priv, 0x61733c, 0x1000, 0x1000); /* LOOKUP_EN */
-- 
1.8.1.5

[PATCH 0/6] DRM: Unified VMA Offset Manager

2013-07-03 Thread Laurent Pinchart

Hi David,

On Monday 01 July 2013 20:32:57 David Herrmann wrote:
> Hi
> 
> I picked up the initial work from Dave [1], fixed several bugs, rewrote the
> drm_mm node handling and adjusted the different drivers.
> The series tries to replace the VMA-offset managers from GEM and TTM with a
> single unified implementation. It uses the TTM RBTree idea to allow
> sub-mappings (which wouldn't be feasible with hashtables).

Nice work, thank you. Could you please also update 
Documentation/DocBook/drm.tmpl ?

> Changes to Dave's v1:
>  * Fixed a ref-count bug in TTM during object lookup
>  * Use embedded drm_mm_node objects to avoid allocations
>  * Document drm_vma_* API
>  * Reviewed TTM locking
>  * Fixed all new drivers
>  * Use node->vm_pages instead of obj->size for GEM size calculations
> 
> Notes:
>  * Tested on nouveau only! I will try to test i915 this week. However, the
>gem changes seem pretty trivial.
>  * I couldn't even compile-test the ARM drivers. However, the omapdrm diffs
>are the only changes that are non-trivial. Is there any ongoing work to
>remove the arch-deps in DRM drivers?
>  * _DRM_GEM is no longer used, but I guess we need to keep it for backwards
>compat?
>  * If we replace node_list in drm_mm with an rbtree, we can drop it from
>drm_vma_offset_manager completely. However, I wanted to avoid heavy
> drm_mm changes and left this for follow up patches.
>  * This is currently based on linux-3.10 from today. Next series will be
>rebased on drm-next/linux-next, but the current -next trees continously
> break my machines..
>But the only changes should be to fix additional drivers. I didn't see
> any other things to fix for drm-next.
> 
> Another series, which I will send later, adds "struct file" lists for each
> drm-vma-offset so we can get access control over gem objects. Also, I have
> an experimental series to remove the allocation helpers in drm_mm and let
> drivers embed drm_mm_node instead. Lets see how that works out.
> 
> Comments welcome!
> Cheers
> David
> 
> [1]: http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-vma-manager
> 
> David Herrmann (6):
>   drm: make drm_mm_init() return void
>   drm: mm: add drm_mm_node_linked() helper
>   drm: add unified vma offset manager
>   drm: gem: convert to new unified vma manager
>   drm: ttm: convert to unified vma offset manager
>   drm: provide generic drm_vma_node_unmap() helper
> 
>  drivers/gpu/drm/Makefile   |   2 +-
>  drivers/gpu/drm/ast/ast_main.c |   2 +-
>  drivers/gpu/drm/cirrus/cirrus_main.c   |   2 +-
>  drivers/gpu/drm/drm_gem.c  |  93 ++--
>  drivers/gpu/drm/drm_gem_cma_helper.c   |   9 +-
>  drivers/gpu/drm/drm_mm.c   |   5 +-
>  drivers/gpu/drm/drm_vma_manager.c  | 224 ++
>  drivers/gpu/drm/exynos/exynos_drm_gem.c|   7 +-
>  drivers/gpu/drm/gma500/gem.c   |   8 +-
>  drivers/gpu/drm/i915/i915_gem.c|  13 +-
>  drivers/gpu/drm/mgag200/mgag200_main.c |   2 +-
>  drivers/gpu/drm/nouveau/nouveau_display.c  |   2 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c  |   2 +-
>  drivers/gpu/drm/omapdrm/omap_gem.c |  11 +-
>  drivers/gpu/drm/omapdrm/omap_gem_helpers.c |  49 +--
>  drivers/gpu/drm/qxl/qxl_object.h   |   2 +-
>  drivers/gpu/drm/qxl/qxl_release.c  |   2 +-
>  drivers/gpu/drm/radeon/radeon_object.h |   5 +-
>  drivers/gpu/drm/ttm/ttm_bo.c   |  82 ++-
>  drivers/gpu/drm/ttm/ttm_bo_manager.c   |   8 +-
>  drivers/gpu/drm/ttm/ttm_bo_util.c  |   3 +-
>  drivers/gpu/drm/ttm/ttm_bo_vm.c|  81 ---
>  drivers/gpu/drm/udl/udl_gem.c  |   6 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |   4 +-
>  include/drm/drmP.h |   7 +-
>  include/drm/drm_mm.h   |  11 +-
>  include/drm/drm_vma_manager.h  | 122 
>  include/drm/ttm/ttm_bo_api.h   |  15 +-
>  include/drm/ttm/ttm_bo_driver.h|   7 +-
>  include/uapi/drm/drm.h |   2 +-
>  30 files changed, 464 insertions(+), 324 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_vma_manager.c
>  create mode 100644 include/drm/drm_vma_manager.h

-- 
Regards,

Laurent Pinchart

[ANNOUNCE] libdrm 2.4.46

2013-07-03 Thread Laurent Pinchart

Hi Dave,

On Tuesday 02 July 2013 18:22:01 Dave Airlie wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Release because I want the cursor ioctls released,
> also haswell and radeon ids.

Any chance to get the "[PATCH v6 00/23] modetest enhancements" series included 
in the next release ?

-- 
Regards,

Laurent Pinchart

Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
> > I am against a super node which contains lcd and dcon/ire nodes. You can
> > enable those devices on a per board basis. We add them to dove.dtsi but
> > disable them by default (status = "disabled").
> >
> > The DRM driver itself should get a video-card node outside of  
> > soc/internal-regs where you can put e.g. video memory hole (or video
> > mem size if it will be taken from RAM later)
> >
> > About the unusual case, I guess we should try to get both lcd
> > controllers into one DRM driver. Then support mirror or screen
> > extension X already provides. For those applications where you want
> > X on one lcd and some other totally different video stream - wait
> > for someone to come up with a request or proposal.
> 
> Well, all I can say then is that the onus is on those who want to treat
> the components as separate devices to come up with some foolproof way
> to solve this problem which doesn't involve making assumptions about
> the way that devices are probed and doesn't end up creating artificial
> restrictions on how the devices can be used - and doesn't end up burdening
> the common case with lots of useless complexity that they don't need.
> 
> It's _that_ case which needs to come up with a proposal about how to
> handle it because you _can't_ handle it at the moment in any sane
> manner which meets the criteria I've set out above, and at the moment
> the best proposal by far to resolve that is the "super node" approach.
> 
> There is _no_ way in the device model to combine several individual
> devices together into one logical device safely when the subsystem
> requires that there be a definite point where everything is known.
> That applies even more so with -EPROBE_DEFER.  With the presence of
> such a thing, there is now no logical point where any code can say
> definitively that the system has technically finished booting and all
> resources are known.
> 
> That's the problem - if you don't od the super-node approach, you end
> up with lots of individual devices which you have to figure out some
> way of combining, and coping with missing ones which might not be
> available in the order you want them to be, etc.
> 
> That's the advantage of the "super node" approach - it's a container
> to tell you what's required in order to complete the creation of the
> logical device, and you can parse the sub-nodes to locate the
> information you need.

I think such an approach would lead to drm drivers which all parse their
"super nodes" themselves and driver authors would become very creative
how such a node should look like.

Also this gets messy with i2c devices which are normally registered
under their i2c bus masters. With the super node approach these would
have to live under the super node, maybe with a phandle to the i2c bus
master. This again probably leads to very SoC specific solutions. It
also doesn't solve the problem that the i2c bus master needs to be
registered by the time the DRM driver probes.

On i.MX the IPU unit not only handles the display path but also the
capture path. v4l2 begins to evolve an OF model in which each (sub)device
has its natural position in the devicetree; the devices are then
connected with phandles. I'm not sure how good this will work together
with a super node approach.

> 
> An alternative as I see it is that DRM - and not only DRM but also
> the DRM API and Xorg - would need to evolve hotplug support for the
> various parts of the display subsystem.  Do we have enough people
> with sufficient knowledge and willingness to be able to make all
> that happen?  I don't think we do, and I don't see that there's any
> funding out there to make such a project happen, which would make it
> a volunteer/spare time effort.

+1 for this solution, even if this means more work to get from the
ground.

Do we really need full hotplug support in the DRM API and Xorg? I mean
it would really be nice if Xorg detected a newly registered device, but
as a start it should be sufficient when Xorg detects what's there when
it starts, no?

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Best practice device tree design for display subsystems/DRM

On 07/02/2013 11:04 PM, Daniel Drake wrote:
> On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
>   wrote:
>> I am against a super node which contains lcd and dcon/ire nodes. You can
>> enable those devices on a per board basis. We add them to dove.dtsi but
>> disable them by default (status = "disabled").
>>
>> The DRM driver itself should get a video-card node outside of
>> soc/internal-regs where you can put e.g. video memory hole (or video
>> mem size if it will be taken from RAM later)
>
> For completeness of the discussion, and my understanding too, can you
> explain your objections to the display super-node in a bit more
> detail?

lcd-controller nodes and dcon node will need to be children of
internal-regs nodes. The internal-regs node is required for address
translation as the mbus base address can be configured. The above does
not permit a super-node - but you cannot have the nodes above outside
of internal-regs.

As Russell stated, he wants a proposal for the "unusual case" i.e.
you have two lcd controllers. You use one for Xorg and the other for
e.g. running a linux terminal console.

This would require some reference from the super node to the lcd
controller to sort out which DRM device (represented by the super
node) should be using which lcd controller device.

Using status = "disabled" alone will only allow to enable or disable
lcd controller nodes but not assign any of it to your two super-nodes.

So my current proposal after thinking about Russell's statements
whould be phandles as Jean-Francois already mentioned. I am not sure
what OF maintainers will think about it, but that is another thing.

Basically, you will have:
(Note: names and property-names are just to show how it could work,
and example is joined from possible future dove.dtsi and dove-board.dts)

video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = "marvell,armada-510-display";
reg = <0 0x3f00 0x100>; /* video-mem hole */
/* later: linux,video-memory-size = <0x100>; */
marvell,video-devices = <  >;
};

/* OR: Multiple video card w/ single lcd controllers */
card0 {
compatible = "marvell,armada-510-display";
...
marvell,video-devices = <>;
};

card1 {
compatible = "marvell,armada-510-display";
...
marvell,video-devices = <>;
};
};

mbus {
compatible = "marvell,dove-mbus";
ranges = <...>;

sb-regs {
ranges = <0 0xf100 0 0x10>;
...
}

nb-regs {
ranges = <0 0xf180 0 0x10>;

lcd0: lcd-controller at 2 {
compatible = "marvell,armada-510-lcd";
reg = <0x2 0x1000>;
interrupts = <47>;
...
/* use EXTCLK0 with lcd0 */
clocks = <_clk0>;
clock-names = "extclk0";
marvell,external-encoder = <>;
};

lcd1: lcd-controller at 1 {
compatible = "marvell,armada-510-lcd";
reg = <0x1 0x1000>;
interrupts = <46>;
...
/* use LCDPLL with lcd1 */
clocks = <_pll_clk>;
clock-names = "lcdpll";
};
}
};

 {
tda998x: hdmi-transmitter at 60 {
compatible = "nxp,tda19988";
reg = <0x60>;
...
}
};

Each lcd controller node represents a platform_device and the display
nodes above should look up phandles and determine type (ctrc or dcon)
by compatible string of the nodes the phandles point to.

Sebastian

Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
> Have you also considered how suspend/resume works in such a place,
> where every driver is independent? The ChromeOS guys have bitched
> before about the exynos driver which is has lots of sub-drivers, how
> do you control the s/r ordering in a crazy system like that? I'd
> prefer a central driver, otherwise there is too many moving parts.

>From earlier in the evolution of Armada DRM, that has also been my
preferred idea - though probably not quite how people think.

My idea was to have a separate "driver" assemble all the constituent
parts, and then register the "armada-drm" platform device providing
via platform resources and/or platform data all the necessary
information (maybe not even bothering to decode the OF nodes but just
provide a collection of nodes for each consituent part.)

Such a thing could be turned into a generic solution for all the
multi-part drivers.  If we use Sebastian's idea of using phandles
(it seems there's a precident for it with the direction v4l2 is
going to solve a similar problem) then we likely have a standard
way of describing component-ized display setups in DT.

-- 
Russell King

RE: Best practice device tree design for display subsystems/DRM

 -Original Message-
 From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
 [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
 Behalf Of Stephane Marchesin
 Sent: Wednesday, July 03, 2013 10:46 AM
 To: Dave Airlie
 Cc: Jean-Francois Moine; Daniel Drake;
devicetree-disc...@lists.ozlabs.org;
 dri-devel@lists.freedesktop.org; Russell King; Sebastian Hesselbarth
 Subject: Re: Best practice device tree design for display subsystems/DRM

 On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie airl...@gmail.com wrote:
  On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer s.ha...@pengutronix.de
 wrote:
  On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
  On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
   I am against a super node which contains lcd and dcon/ire nodes. You
 can
   enable those devices on a per board basis. We add them to dove.dtsi
 but
   disable them by default (status = disabled).

   The DRM driver itself should get a video-card node outside of
   soc/internal-regs where you can put e.g. video memory hole (or video
   mem size if it will be taken from RAM later)

   About the unusual case, I guess we should try to get both lcd
   controllers into one DRM driver. Then support mirror or screen
   extension X already provides. For those applications where you want
   X on one lcd and some other totally different video stream - wait
   for someone to come up with a request or proposal.

  Well, all I can say then is that the onus is on those who want to
 treat
  the components as separate devices to come up with some foolproof way
  to solve this problem which doesn't involve making assumptions about
  the way that devices are probed and doesn't end up creating artificial
  restrictions on how the devices can be used - and doesn't end up
 burdening
  the common case with lots of useless complexity that they don't need.

  It's _that_ case which needs to come up with a proposal about how to
  handle it because you _can't_ handle it at the moment in any sane
  manner which meets the criteria I've set out above, and at the moment
  the best proposal by far to resolve that is the super node approach.

  There is _no_ way in the device model to combine several individual
  devices together into one logical device safely when the subsystem
  requires that there be a definite point where everything is known.
  That applies even more so with -EPROBE_DEFER.  With the presence of
  such a thing, there is now no logical point where any code can say
  definitively that the system has technically finished booting and all
  resources are known.

  That's the problem - if you don't od the super-node approach, you end
  up with lots of individual devices which you have to figure out some
  way of combining, and coping with missing ones which might not be
  available in the order you want them to be, etc.

  That's the advantage of the super node approach - it's a container
  to tell you what's required in order to complete the creation of the
  logical device, and you can parse the sub-nodes to locate the
  information you need.

  I think such an approach would lead to drm drivers which all parse
 their
  super nodes themselves and driver authors would become very creative
  how such a node should look like.

  Also this gets messy with i2c devices which are normally registered
  under their i2c bus masters. With the super node approach these would
  have to live under the super node, maybe with a phandle to the i2c bus
  master. This again probably leads to very SoC specific solutions. It
  also doesn't solve the problem that the i2c bus master needs to be
  registered by the time the DRM driver probes.

  On i.MX the IPU unit not only handles the display path but also the
  capture path. v4l2 begins to evolve an OF model in which each
 (sub)device
  has its natural position in the devicetree; the devices are then
  connected with phandles. I'm not sure how good this will work together
  with a super node approach.

  An alternative as I see it is that DRM - and not only DRM but also
  the DRM API and Xorg - would need to evolve hotplug support for the
  various parts of the display subsystem.  Do we have enough people
  with sufficient knowledge and willingness to be able to make all
  that happen?  I don't think we do, and I don't see that there's any
  funding out there to make such a project happen, which would make it
  a volunteer/spare time effort.

  +1 for this solution, even if this means more work to get from the
  ground.

  Do we really need full hotplug support in the DRM API and Xorg? I mean
  it would really be nice if Xorg detected a newly registered device, but
  as a start it should be sufficient when Xorg detects what's there when
  it starts, no?

  Since fbdev and fbcon sit on top of drm to provide the console
  currently I'd also expect some fun with them. How do I get a console
  if I have no outputs at

Re: [pull] radeon drm-next-3.11

2013-07-03 Thread Ruslan N. Marchenko


Am 01.07.2013 23:01, schrieb alexdeuc...@gmail.com:

From: Alex Deucheralexander.deuc...@amd.com

Hi Dave,

A few more patches for 3.11:
- add debugfs interface to check current DPM state
- Fix a bug that caused problems with DPM on BTC+ asics.

The following changes since commit f7d452f4fd5d86f764807a1234a407deb5b105ef:

   Merge branch 'drm-nouveau-next' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-07-01 
14:10:20 +1000)

are available in the git repository at:

   git://people.freedesktop.org/~agd5f/linux drm-next-3.11

Alex Deucher (12):
   drm/radeon: remove sumo dpm/uvd bringup leftovers
   drm/radeon/atom: fix endian bug in radeon_atom_init_mc_reg_table()
   drm/radeon: fix typo in radeon_atom_init_mc_reg_table()
   drm/radeon/dpm: re-enable state transitions for BTC
   drm/radeon/dpm: re-enable state transitions for Cayman
   drm/radeon/dpm: add infrastructure to support debugfs info
   drm/radeon/dpm: add debugfs support for rv6xx
   drm/radeon/dpm: add debugfs support for 7xx/evergreen/btc
   drm/radeon/dpm: add debugfs support for ON/LN
   drm/radeon/dpm: add debugfs support for TN
   drm/radeon/dpm: add debugfs support for cayman
   drm/radeon/dpm: add debugfs support for SI

  drivers/gpu/drm/radeon/btc_dpm.c |3 --
  drivers/gpu/drm/radeon/ni_dpm.c  |   25 +---
  drivers/gpu/drm/radeon/nid.h |4 ++
  drivers/gpu/drm/radeon/radeon.h  |2 +
  drivers/gpu/drm/radeon/radeon_asic.c |8 +
  drivers/gpu/drm/radeon/radeon_asic.h |   12 
  drivers/gpu/drm/radeon/radeon_atombios.c |3 +-
  drivers/gpu/drm/radeon/radeon_pm.c   |   40 ++
  drivers/gpu/drm/radeon/rv6xx_dpm.c   |   25 
  drivers/gpu/drm/radeon/rv770_dpm.c   |   30 
  drivers/gpu/drm/radeon/rv770d.h  |4 ++
  drivers/gpu/drm/radeon/si_dpm.c  |   19 
  drivers/gpu/drm/radeon/sid.h |4 ++
  drivers/gpu/drm/radeon/sumo_dpm.c|   45 ++---
  drivers/gpu/drm/radeon/trinity_dpm.c |   21 ++
  15 files changed, 206 insertions(+), 39 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

This is really excellent and very wanted addition to the radeon, a huge 
thanks Alex for giving a second life to my old TimelineX with hybrid 
AMD/Intel graphics. Intel ironlake became a bit outdated already but 
with ATi HD 5650 I was able to drink tee all day long since it never 
came lower than 90 degrees Celsius.   Now it comfortably sits at 55-60 
so I can use it back again.


As I noticed it supports now either dynpm or profile method of clocking, 
however profiles themselves also have several (3) power states. Also 
during init phase it writes that it switching from boot to performance 
profile - so what exactly is the difference between dpm and profile 
method? Will dynpm react to ACPI events like lid closed or AC offline or 
I better to add calls to acpid event handlers to tweak the profiles/methods?


In any case it's just a new breath to my relict brick, especially now 
when its successor is at service repair :)


--
Looking forward to reading yours...
 Ruslan N. Marchenko

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Best practice device tree design for display subsystems/DRM

On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote:
 On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
  On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote:
  On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote:
   I am against a super node which contains lcd and dcon/ire nodes. You can
   enable those devices on a per board basis. We add them to dove.dtsi but
   disable them by default (status = disabled).
  
   The DRM driver itself should get a video-card node outside of
   soc/internal-regs where you can put e.g. video memory hole (or video
   mem size if it will be taken from RAM later)
  
   About the unusual case, I guess we should try to get both lcd
   controllers into one DRM driver. Then support mirror or screen
   extension X already provides. For those applications where you want
   X on one lcd and some other totally different video stream - wait
   for someone to come up with a request or proposal.
 
  Well, all I can say then is that the onus is on those who want to treat
  the components as separate devices to come up with some foolproof way
  to solve this problem which doesn't involve making assumptions about
  the way that devices are probed and doesn't end up creating artificial
  restrictions on how the devices can be used - and doesn't end up burdening
  the common case with lots of useless complexity that they don't need.
 
  It's _that_ case which needs to come up with a proposal about how to
  handle it because you _can't_ handle it at the moment in any sane
  manner which meets the criteria I've set out above, and at the moment
  the best proposal by far to resolve that is the super node approach.
 
  There is _no_ way in the device model to combine several individual
  devices together into one logical device safely when the subsystem
  requires that there be a definite point where everything is known.
  That applies even more so with -EPROBE_DEFER.  With the presence of
  such a thing, there is now no logical point where any code can say
  definitively that the system has technically finished booting and all
  resources are known.
 
  That's the problem - if you don't od the super-node approach, you end
  up with lots of individual devices which you have to figure out some
  way of combining, and coping with missing ones which might not be
  available in the order you want them to be, etc.
 
  That's the advantage of the super node approach - it's a container
  to tell you what's required in order to complete the creation of the
  logical device, and you can parse the sub-nodes to locate the
  information you need.
 
  I think such an approach would lead to drm drivers which all parse their
  super nodes themselves and driver authors would become very creative
  how such a node should look like.
 
  Also this gets messy with i2c devices which are normally registered
  under their i2c bus masters. With the super node approach these would
  have to live under the super node, maybe with a phandle to the i2c bus
  master. This again probably leads to very SoC specific solutions. It
  also doesn't solve the problem that the i2c bus master needs to be
  registered by the time the DRM driver probes.
 
  On i.MX the IPU unit not only handles the display path but also the
  capture path. v4l2 begins to evolve an OF model in which each (sub)device
  has its natural position in the devicetree; the devices are then
  connected with phandles. I'm not sure how good this will work together
  with a super node approach.
 
 
  An alternative as I see it is that DRM - and not only DRM but also
  the DRM API and Xorg - would need to evolve hotplug support for the
  various parts of the display subsystem.  Do we have enough people
  with sufficient knowledge and willingness to be able to make all
  that happen?  I don't think we do, and I don't see that there's any
  funding out there to make such a project happen, which would make it
  a volunteer/spare time effort.
 
  +1 for this solution, even if this means more work to get from the
  ground.
 
  Do we really need full hotplug support in the DRM API and Xorg? I mean
  it would really be nice if Xorg detected a newly registered device, but
  as a start it should be sufficient when Xorg detects what's there when
  it starts, no?
 
 Since fbdev and fbcon sit on top of drm to provide the console
 currently I'd also expect some fun with them. How do I get a console
 if I have no outputs at boot, but I have crtcs? do I just wait around
 until an output appears.

I thought the console/fb stuff should go away.

 
 There are a number of issues with hotplugging encoders and connectors
 at runtime, when really the SoC/board designer knows what it provides
 and should be able to tell the driver in some fashion.
 
 The main problems when I played with hot adding eDP on Intel last
 time, are we have grouping of crtc/encoder/connectors for multi-seat
 future use, these groups need to be updated,

[PATCH] drm/nva3/disp: Fix HDMI audio regression

2013-07-03 Thread Ilia Mirkin

This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix
HDMI audio regression). The regression happened as a result of
refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into
core).

Reported-and-tested-by: Max Baldwin archerse...@gmail.com
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---

The actual testing was done on a NVCF card (550 Ti). Prior to this,
AC3/DTS audio passthrough worked, but regular audio did not. With this
change, regular audio started to work too. This should probably be
sent to stable as well.

 drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
index f065fc2..db8c6fd 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c
@@ -55,6 +55,10 @@ nva3_hdmi_ctrl(struct nv50_disp_priv *priv, int head, int 
or, u32 data)
nv_wr32(priv, 0x61c510 + soff, 0x);
nv_mask(priv, 0x61c500 + soff, 0x0001, 0x0001);
 
+   nv_mask(priv, 0x61c5d0 + soff, 0x00070001, 0x00010001); /* SPARE, 
HW_CTS */
+   nv_mask(priv, 0x61c568 + soff, 0x00010101, 0x); /* ACR_CTRL, ?? 
*/
+   nv_mask(priv, 0x61c578 + soff, 0x8000, 0x8000); /* 
ACR_0441_ENABLE */
+
/* ??? */
nv_mask(priv, 0x61733c, 0x0010, 0x0010); /* RESETF */
nv_mask(priv, 0x61733c, 0x1000, 0x1000); /* LOOKUP_EN */
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: Add missing includes

2013-07-03 Thread Mark Brown

From: Mark Brown broo...@linaro.org

Ensure that all externally accessed functions are correctly prototyped
when defined in each file by making sure the headers with the protoypes
are included in the file with the definition.

Signed-off-by: Mark Brown broo...@linaro.org
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 1 +
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c| 1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimc.c  | 1 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_gsc.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_rotator.c   | 1 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 1 +
 10 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 8bcc13a..ec80293 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -17,6 +17,7 @@
 #include drm/exynos_drm.h
 #include exynos_drm_drv.h
 #include exynos_drm_encoder.h
+#include exynos_drm_connector.h
 
 #define to_exynos_connector(x) container_of(x, struct exynos_drm_connector,\
drm_connector)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 073c10a..6933ee9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -15,6 +15,7 @@
 #include drm/drmP.h
 #include drm/drm_crtc_helper.h
 
+#include exynos_drm_crtc.h
 #include exynos_drm_drv.h
 #include exynos_drm_encoder.h
 #include exynos_drm_plane.h
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index ff7f2a8..8adafde 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -11,6 +11,7 @@
 
 #include drm/drmP.h
 #include drm/exynos_drm.h
+#include exynos_drm_dmabuf.h
 #include exynos_drm_drv.h
 #include exynos_drm_gem.h
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8f007aa..45b6cb3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -19,6 +19,7 @@
 
 #include exynos_drm_drv.h
 #include exynos_drm_fb.h
+#include exynos_drm_fbdev.h
 #include exynos_drm_gem.h
 #include exynos_drm_iommu.h
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 4a1616a..a83e664 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -22,6 +22,7 @@
 #include drm/drmP.h
 #include drm/exynos_drm.h
 #include regs-fimc.h
+#include exynos_drm_drv.h
 #include exynos_drm_ipp.h
 #include exynos_drm_fimc.h
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index af75434..03ba897 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -24,6 +24,7 @@
 #include drm/drmP.h
 #include drm/exynos_drm.h
 #include exynos_drm_drv.h
+#include exynos_drm_g2d.h
 #include exynos_drm_gem.h
 #include exynos_drm_iommu.h
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 762f40d..4683251 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -21,6 +21,7 @@
 #include drm/drmP.h
 #include drm/exynos_drm.h
 #include regs-gsc.h
+#include exynos_drm_drv.h
 #include exynos_drm_ipp.h
 #include exynos_drm_gsc.h
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 83efc66..63ebeeb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -16,6 +16,7 @@
 #include exynos_drm_encoder.h
 #include exynos_drm_fb.h
 #include exynos_drm_gem.h
+#include exynos_drm_plane.h
 
 #define to_exynos_plane(x) container_of(x, struct exynos_plane, base)
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 9b6c709..2e9eee2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -22,6 +22,7 @@
 #include drm/exynos_drm.h
 #include regs-rotator.h
 #include exynos_drm.h
+#include exynos_drm_drv.h
 #include exynos_drm_ipp.h
 
 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 24376c1..498647a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -24,6 +24,7 @@
 #include exynos_drm_drv.h
 #include exynos_drm_crtc.h
 #include exynos_drm_encoder.h
+#include exynos_drm_vidi.h
 
 /* vidi has totally three virtual windows. */
 #define WINDOWS_NR 3
-- 
1.8.3.1

[PATCH] drm: Convert drm class driver from legacy pm ops to dev_pm_ops

2013-07-03 Thread Shuah Khan

Convert drivers/gpu/drm class to use dev_pm_ops for power management and
remove Legacy PM ops hooks. With this change, drm class registers
suspend/resume callbacks via class-pm (dev_pm_ops) instead of Legacy
class-suspend/resume. When __device_suspend() runs call-backs, it will
find class-pm ops for the drm class.

drm_class_suspend() hook calls driver legacy ops with the state information.
e.g: drm_class_suspend() calls into driver suspend routines
via drm_dev-driver-suspend(drm_dev, state).

Once drm_class_suspend() is converted to dev_pm_ops, it will no longer
have access to pm_transition which it has to pass into driver legacy
suspend calls. A new freeze and suspend hooks are added to address the not
having access to the state information. The new freeze and suspend hooks
simply call __drm_class_suspend() with the appropriate pm state information.
__drm_class_suspend() is the original suspend hook with a new name.

Signed-off-by: Shuah Khan shuah...@samsung.com
---
 drivers/gpu/drm/drm_sysfs.c |   33 +
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 0229665..2290b3b 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -30,14 +30,14 @@ static struct device_type drm_sysfs_device_minor = {
 };
 
 /**
- * drm_class_suspend - DRM class suspend hook
+ * __drm_class_suspend - internal DRM class suspend routine
  * @dev: Linux device to suspend
  * @state: power state to enter
  *
  * Just figures out what the actual struct drm_device associated with
  * @dev is and calls its suspend hook, if present.
  */
-static int drm_class_suspend(struct device *dev, pm_message_t state)
+static int __drm_class_suspend(struct device *dev, pm_message_t state)
 {
if (dev-type == drm_sysfs_device_minor) {
struct drm_minor *drm_minor = to_drm_minor(dev);
@@ -52,6 +52,26 @@ static int drm_class_suspend(struct device *dev, 
pm_message_t state)
 }
 
 /**
+ * drm_class_suspend - internal DRM class suspend hook. Simply calls
+ * __drm_class_suspend() with the correct pm state.
+ * @dev: Linux device to suspend
+ */
+static int drm_class_suspend(struct device *dev)
+{
+   return __drm_class_suspend(dev, PMSG_SUSPEND);
+}
+
+/**
+ * drm_class_freeze - internal DRM class freeze hook. Simply calls
+ * __drm_class_suspend() with the correct pm state.
+ * @dev: Linux device to freeze
+ */
+static int drm_class_freeze(struct device *dev)
+{
+   return __drm_class_suspend(dev, PMSG_FREEZE);
+}
+
+/**
  * drm_class_resume - DRM class resume hook
  * @dev: Linux device to resume
  *
@@ -72,6 +92,12 @@ static int drm_class_resume(struct device *dev)
return 0;
 }
 
+static const struct dev_pm_ops drm_class_dev_pm_ops = {
+   .suspend= drm_class_suspend,
+   .resume = drm_class_resume,
+   .freeze = drm_class_freeze,
+};
+
 static char *drm_devnode(struct device *dev, umode_t *mode)
 {
return kasprintf(GFP_KERNEL, dri/%s, dev_name(dev));
@@ -106,8 +132,7 @@ struct class *drm_sysfs_create(struct module *owner, char 
*name)
goto err_out;
}
 
-   class-suspend = drm_class_suspend;
-   class-resume = drm_class_resume;
+   class-pm = drm_class_dev_pm_ops;
 
err = class_create_file(class, class_attr_version.attr);
if (err)
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

armada_drm clock selection - try 2

Hi Russell,

Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.

A helper function in the core lets each variant find the best clock.
As you suggested we first try external (dedicated) clocks, where we can
change the rate to find an exact match. We fall back on looking at the rates
of the other clocks and we return the clock that provides us with the closest
match after integer division (rejecting those that don't bring us within 1%).

There is still the possibility that two CRTCs on the same device end up using
the same clock, so I added a usage counter to each clock to prevent the rate
from being changed by another CRTC.

This is compile-tested only - but after your feedback I will add the
remaining required hacks and test it on XO.

diff --git a/drivers/gpu/drm/armada/armada_510.c 
b/drivers/gpu/drm/armada/armada_510.c
index a016888..7dff2dc 100644
--- a/drivers/gpu/drm/armada/armada_510.c
+++ b/drivers/gpu/drm/armada/armada_510.c
@@ -17,12 +17,29 @@
 
 static int armada510_init(struct armada_private *priv, struct device *dev)
 {
-   priv-extclk[0] = devm_clk_get(dev, ext_ref_clk_1);
+   struct armada_clk_info *clk_info = devm_kzalloc(dev,
+   sizeof(struct armada_clk_info) * 4, GFP_KERNEL);
 
-   if (IS_ERR(priv-extclk[0])  PTR_ERR(priv-extclk[0]) == -ENOENT)
-   priv-extclk[0] = ERR_PTR(-EPROBE_DEFER);
+   if (!clk_info)
+   return -ENOMEM;
 
-   return PTR_RET(priv-extclk[0]);
+   /* External clocks */
+   clk_info[0].clk = devm_clk_get(dev, ext_ref_clk_0);
+   clk_info[0].is_dedicated = true;
+   clk_info[0].sclk = SCLK_510_EXTCLK0;
+   clk_info[1].clk = devm_clk_get(dev, ext_ref_clk_1);
+   clk_info[1].is_dedicated = true;
+   clk_info[1].sclk = SCLK_510_EXTCLK1;
+
+   /* Internal/shared clocks */
+   clk_info[2].clk = devm_clk_get(dev, axi);
+   clk_info[2].sclk = SCLK_510_AXI;
+   clk_info[3].clk = devm_clk_get(dev, pll);
+   clk_info[3].sclk = SCLK_510_PLL;
+
+   priv-num_clks = 4;
+   priv-clk_info = clk_info;
+   return 0;
 }
 
 static int armada510_crtc_init(struct armada_crtc *dcrtc)
@@ -38,42 +55,25 @@ static int armada510_crtc_init(struct armada_crtc *dcrtc)
  * supportable, and again with sclk != NULL to set the clocks up for
  * that.  The former can return an error, but the latter is expected
  * not to.
- *
- * We currently are pretty rudimentary here, always selecting
- * EXT_REF_CLK_1 for LCD0 and erroring LCD1.  This needs improvement!
  */
 static int armada510_crtc_compute_clock(struct armada_crtc *dcrtc,
const struct drm_display_mode *mode, uint32_t *sclk)
 {
struct armada_private *priv = dcrtc-crtc.dev-dev_private;
-   struct clk *clk = priv-extclk[0];
-   int ret;
-
-   if (dcrtc-num == 1)
-   return -EINVAL;
-
-   if (IS_ERR(clk))
-   return PTR_ERR(clk);
-
-   if (dcrtc-clk != clk) {
-   ret = clk_prepare_enable(clk);
-   if (ret)
-   return ret;
-   dcrtc-clk = clk;
-   }
+   struct armada_clk_info *clk_info;
+   int err;
+   int divider;
 
-   if (sclk) {
-   uint32_t rate, ref, div;
+   clk_info = armada_drm_find_best_clock(priv, mode-clock * 1000, 
divider);
+   if (!clk_info)
+   return -ENOENT;
 
-   rate = mode-clock * 1000;
-   ref = clk_round_rate(clk, rate);
-   div = DIV_ROUND_UP(ref, rate);
-   if (div  1)
-   div = 1;
+   err = armada_drm_crtc_switch_clock(dcrtc, clk_info);
+   if (err)
+   return err;
 
-   clk_set_rate(clk, ref);
-   *sclk = div | SCLK_510_EXTCLK1;
-   }
+   if (sclk)
+   *sclk = divider | clk_info-sclk;
 
return 0;
 }
diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index f489157..8202be2 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -83,6 +83,34 @@ enum csc_mode {
  * porch, which we're reprogramming.)
  */
 
+/* Switch to a new clock source after disabling and unpreparing the current
+ * one. If non-NULL, the new clock source is expected to be prepared before
+ * this function is called. */
+int armada_drm_crtc_switch_clock(struct armada_crtc *dcrtc,
+   struct armada_clk_info *clk_info)
+{
+   int err;
+
+   if (dcrtc-active_clk == clk_info)
+   return 0;
+
+   if (dcrtc-active_clk) {
+   clk_disable_unprepare(dcrtc-active_clk-clk);
+   dcrtc-active_clk-usage_count--;
+   dcrtc-active_clk = NULL;
+   }
+
+   if (clk_info) {
+   err = clk_enable(clk_info-clk);
+   if (err)
+   return err;
+

MacBook Pro 10,1 + i915

2013-07-03 Thread Marek Vasut

Hi guys,

I recently got the rMBP 10,1 model, it has two graphic cards:

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor 
Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 650M 
Mac Edition] (rev a1)

I'm running linux 3.10-rc7 . The nvidia works with nouveau, but I'd prefer to 
switch the nvidia off altogether and use the intel GPU.

So far I arrived at the point where I disabled X11, mounted debugfs and tried 
the vgaswitcheroo. With the nvidia still in operation, I see the console. 
Unfortunatelly, I end up with a black screen after I run the following command 
to switch to the intel GPU:

echo IGD  /sys/kernel/debug/vgaswitcheroo/switch

If I try to switch back to the nvidia card (using echo DIS  ...), the screen 
remains black. This state persists until reboot. I suspect [1] is the same bug, 
none of the hints there helped.

Can you please give me any hint/patch/idea/... how to continue?

Thank you!

[1] https://bugs.freedesktop.org/show_bug.cgi?id=61115

Best regards,
Marek Vasut
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: armada_drm clock selection - try 2


On 07/01/2013 10:30 PM, Daniel Drake wrote:

Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.

A helper function in the core lets each variant find the best clock.
As you suggested we first try external (dedicated) clocks, where we can
change the rate to find an exact match. We fall back on looking at the rates
of the other clocks and we return the clock that provides us with the closest
match after integer division (rejecting those that don't bring us within 1%).

There is still the possibility that two CRTCs on the same device end up using
the same clock, so I added a usage counter to each clock to prevent the rate
from being changed by another CRTC.

This is compile-tested only - but after your feedback I will add the
remaining required hacks and test it on XO.

diff --git a/drivers/gpu/drm/armada/armada_510.c 
b/drivers/gpu/drm/armada/armada_510.c
index a016888..7dff2dc 100644
--- a/drivers/gpu/drm/armada/armada_510.c
+++ b/drivers/gpu/drm/armada/armada_510.c
@@ -17,12 +17,29 @@

  static int armada510_init(struct armada_private *priv, struct device *dev)
  {
-   priv-extclk[0] = devm_clk_get(dev, ext_ref_clk_1);
+   struct armada_clk_info *clk_info = devm_kzalloc(dev,
+   sizeof(struct armada_clk_info) * 4, GFP_KERNEL);

-   if (IS_ERR(priv-extclk[0])  PTR_ERR(priv-extclk[0]) == -ENOENT)
-   priv-extclk[0] = ERR_PTR(-EPROBE_DEFER);
+   if (!clk_info)
+   return -ENOMEM;

-   return PTR_RET(priv-extclk[0]);
+   /* External clocks */
+   clk_info[0].clk = devm_clk_get(dev, ext_ref_clk_0);
+   clk_info[0].is_dedicated = true;


Daniel,

I guess extclk0 and extclk1 should be sufficient for clock names.
Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
extclk0 simultaneously. See below for .is_dedicated in general.

[...]

diff --git a/drivers/gpu/drm/armada/armada_drm.h 
b/drivers/gpu/drm/armada/armada_drm.h
index e8c4f80..4fe8ec5 100644
--- a/drivers/gpu/drm/armada/armada_drm.h
+++ b/drivers/gpu/drm/armada/armada_drm.h
@@ -55,6 +55,20 @@ void armada_drm_vbl_event_remove_unlocked(struct armada_crtc 
*,
__e-fn = _f;\
  } while (0)

+struct armada_clk_info {
+   struct clk *clk;
+
+   /* If this clock is dedicated to us, we can change its rate without
+* worrying about any other users in other parts of the system. */
+   bool is_dedicated;
+
+   /* However, we cannot share the same dedicated clock between two CRTCs
+* if each CRTC wants a different rate. Track the number of users. */
+   int usage_count;


You can share the same clock between two CRTCs. Just consider CRTC1
using a mode with half pixel clock as CRTC0. Not that I think this will
ever happen, but it is possible.


+   /* The bits in the SCLK register that select this clock */
+   uint32_t sclk;
+};

  struct armada_private;

@@ -77,7 +91,8 @@ struct armada_private {
struct drm_fb_helper*fbdev;
struct armada_crtc  *dcrtc[2];
struct drm_mm   linear;
-   struct clk  *extclk[2];
+   int num_clks;
+   struct armada_clk_info  *clk_info;
struct drm_property *csc_yuv_prop;
struct drm_property *csc_rgb_prop;
struct drm_property *colorkey_prop;
@@ -99,6 +114,9 @@ void __armada_drm_queue_unref_work(struct drm_device *,
  void armada_drm_queue_unref_work(struct drm_device *,
struct drm_framebuffer *);

+struct armada_clk_info *armada_drm_find_best_clock(struct armada_private *priv,
+   long rate, int *divider);
+
  extern const struct drm_mode_config_funcs armada_drm_mode_config_funcs;

  int armada_fbdev_init(struct drm_device *);
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index e0a08e9..411d56f 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -16,6 +16,97 @@
  #include armada_ioctl.h
  #include armada_ioctlP.h

+/* Find the best clock and integer divisor for a given rate.
+ * NULL is returned when no clock can be found.
+ * When the return value is non-NULL, the divider output variable is set
+ * appropriately, and the clock is returned in prepared state. */
+struct armada_clk_info *armada_drm_find_best_clock(struct armada_private *priv,
+   long rate, int *divider)


I prefer not to try to find the best clock (source) at all. Let the
user pass the clock name by e.g. platform_data (or DT) and just try to
get the requested pixclk or a integer multiple of it. You will never be
able to find the best clock for all use cases.

Just figure out, if integer division is sufficient to get requested
pixclk and clk_set_rate otherwise. This may be useful for current mode
running at 148.5MHz (1080p50) and new mode at 74.25MHz (1080i50, 720p).


+{
+

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver


On 07/01/2013 11:55 PM, Rob Clark wrote:

On Mon, Jul 1, 2013 at 4:52 AM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com  wrote:

- TDA998x irq handling - ignored
- TDA998x sync fix - ignored


At least the sync fix, looks like I missed it (it probably is a good
idea to CC me if you want me to look at it).  Looks like there was
some follow-up discussion on both patches, unless I missed seeing a
newer version of those patches.


Yeah, I will update the patch for current mainline linux as it was
based on some of Russell's RFC patches.


Sometimes if you think a patch has been ignored/forgotten, it doesn't
hurt to ping on mailing list or #dri-devel..  a lot of us are working
not just on kernel (the relatively small part in the whole linux
graphics stack), but also mesa and/or x11.  Some times things end up
several pages down in the mail folder.  It's not because we are all
sitting on a beach drinking margaritas, or because we don't like you.
It is just because we are busy and missed it.

Last few months I've been pretty buried in r/e + gallium driver for
new gpu, so I wasn't always checking dri-devel list every day.  At
least now I am in drm-driver mode again ;-)


It is ok, I don't blame anyone here. Darren wants to test it on tilcdc.
I also found a datasheet for TDA9983b which is kind of compatible but
has more information about register layout in it. IIRC digikey also has
it.


- Fix drm I2C slave encoder probing


If you have a better idea about how to make the slave encoder probing
better (and/or more generic to support stuff other than i2c), please
send RFC patch.  (And if you already did this, please send updated
version, see previous point about sometimes missing patches.)


Also, will send an updated fix.

Sebastian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: armada_drm clock selection - try 2

On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
 I guess extclk0 and extclk1 should be sufficient for clock names.
 Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
 extclk0 simultaneously. See below for .is_dedicated in general.

Maybe we can find better terminology, or just document it a bit
better, but having two CRTCs share the same clock falls within the
scheme designed and implemented there. Dedicated simply means a
clock that is dedicated to the display controller, it is not shared by
other devices.

 +struct armada_clk_info {
 +   struct clk *clk;
 +
 +   /* If this clock is dedicated to us, we can change its rate
 without
 +* worrying about any other users in other parts of the system. */
 +   bool is_dedicated;
 +
 +   /* However, we cannot share the same dedicated clock between two
 CRTCs
 +* if each CRTC wants a different rate. Track the number of users.
 */
 +   int usage_count;


 You can share the same clock between two CRTCs. Just consider CRTC1
 using a mode with half pixel clock as CRTC0. Not that I think this will
 ever happen, but it is possible.

And my implementation already lets that happen - its just that I
didn't document it in enough detail.

 I prefer not to try to find the best clock (source) at all. Let the
 user pass the clock name by e.g. platform_data (or DT) and just try to
 get the requested pixclk or a integer multiple of it. You will never be
 able to find the best clock for all use cases.

 Just figure out, if integer division is sufficient to get requested
 pixclk and clk_set_rate otherwise. This may be useful for current mode
 running at 148.5MHz (1080p50) and new mode at 74.25MHz (1080i50, 720p).

I am not opposed to this approach, it is nice and simple, but as
Russell points out we do additionally need to distinguish between
clocks that are ours to play with, vs those that are shared with
other devices. It would be a bad idea to try call clk_set_rate() on
the AXI bus clock, for example, changing the clock for a whole bunch
of other devices. This is what the is_dedicated flag is about. However
such a flag could be easily added to the DT/platform data definition
that you propose.

Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]

2013-07-03 Thread Sedat Dilek

On Mon, Jul 1, 2013 at 11:03 AM, Sedat Dilek sedat.di...@gmail.com wrote:
On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek sedat.di...@gmail.com wrote:
On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi all,

Changes since 20130628:

The regulator tree gained a build failure so I used the version from
next-20130628.

The trivial tree gained a conflict against the fbdev tree.

The arm-soc tree gained a conflict against the net-next tree.

The akpm tree lost a few patches that turned up elsewhere and I removed 2
that were causing run time problems.

[ CC drm and drm-intel folks ]

[ Did not check any relevant MLs ]

Please, see attached dmesg output.

Clock mismatch, one for Jesse to figure out. Note that this patch is
for 3.12, I simply haven't yet gotten around to properly split my
patch queue so a few spilled into -next. I'll do that now.

I like lightspeed-fast replies :-).

Guess drm/i915: get mode clock when reading the pipe config v9 [1]
is the cause.

Problem solved by applying these patches to next-20130701 from
intel-gfx patchwork-service [0]:

[1/2] drm/i915: fixup messages in pipe_config_compare
[2/2] drm/i915: get clock config when checking CRTC state too

AFAICS 2/2 was folded into updated drm/i915: get mode clock when
reading the pipe config v9 [3].

It would be kind to be CCed on the patches and get also some credits.
Also a CC to the report in linux-next should IMHO be done.

- Sedat -

[0] https://patchwork.kernel.org/project/intel-gfx/list/
[1] https://patchwork.kernel.org/patch/2809031/
[2] https://patchwork.kernel.org/patch/2809021/
[3]
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-nightlyid=f1f644dc66cbaf5a4c7dcde683361536b41885b9

- Sedat -

[1]
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queuedid=d325d8b4f351f9d45e7c8baabf581fd21f343133

-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RADEON / DPM: GPU cannot properly up-clock

2013-07-03 Thread Joshua C.

2013/6/28 Joshua C. joshua...@gmail.com:
 2013/6/27 Alex Deucher alexdeuc...@gmail.com:
 On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. joshua...@gmail.com wrote:
 2013/6/26 Deucher, Alexander alexander.deuc...@amd.com:

 -Original Message-
 From: Joshua C. [mailto:joshua...@gmail.com]
 Sent: Wednesday, June 26, 2013 1:52 PM
 To: dri-devel@lists.freedesktop.org
 Cc: Deucher, Alexander
 Subject: RADEON / DPM: GPU cannot properly up-clock

 First of all thank you guys for pushing this out! Great work!

 I tried the latest code in drm-next-3.11-wip (up to commit
 b3c1e0c3ba885db44 drm/radeon: fix endian issues in atombios dpm
 code) in connection with the latest radeon_ucode (latest update on
 2013-06-26). I also reintroduced the debugfs info so that I can better
 observe the gpu-settings. For this I put back the following patch:

 diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
 b/drivers/gpu/drm/radeon/radeon_pm.c
 index 7ba5d6f..9367234 100644
 --- a/drivers/gpu/drm/radeon/radeon_pm.c
 +++ b/drivers/gpu/drm/radeon/radeon_pm.c
 @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct
 radeon_device *rdev)
  ret = device_create_file(rdev-dev, dev_attr_power_method);
  if (ret)
  DRM_ERROR(failed to create device file for power method\n);
 +
 +if (radeon_debugfs_pm_init(rdev)) {
 +DRM_ERROR(Failed to register debugfs file for PM!\n);
 +}
 +
  DRM_INFO(radeon: dpm initialized\n);
  }

 --
 1.8.2.1

 I removed that code for a reason when DPM is active.  With DPM the 
 hardware changes the power state dynamically internally so that old 
 debugging information is completely irrelevant when DPM is active.

 Alex

 I see. Do you have any idea why I see those delays when playing a
 HD-movie? They do not appear when switching to dynpm. I use the latest
 llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0),
 xf86-video-ati(deve) - all fetched from git as of 2013-06-26.

 What type of movie is it and what are you using to decode the movie? UVD?  
 CPU?

 Alex

 Here is an example of the information from one of the films:

 Stream 0
 Type: Video
 Codec: H264 - MPEG-4 AVC (part 10) (avc1)
 Lang: English
 Res: 1280x544
 Bitrate: 23.976215
 Format: Planar 4:2:0 YVU
 Stream 1
 Type: Audio
 Codec: DTS Audio (dts )
 Lang: English
 Channels: 3F2R/LFE
 Freq: 48000 Hz
 Bitrate: 1536 kb/s

 I recompiled the whole videostack (mesa, llvm, drm, xserver,
 xf86-video-ati, vdpau - all from git) against the patched kernel and
 can say that currently there are no visible regressions. The slow
 motion is almost gone. However I still see it in some frames but I'm
 not sure if this is a kernel-part-problem or just a mesa-problem.

 However I observe the following:

 Under windows: smooth play, temps in idle: 34-35C, cpu-usage: up to 5%
 on all cores on a 4-core cpu, temps when playing the film: up to 42C,
 cpu-usage: up to 5% on all 4 cores

 Under linux (updated as described above): some discrepences (those
 happen pretty rarely, though), temps in idle: 34-36C, cpu-usage: up to
 5%, temps when playing the film: no more than 37C, cpu-usage: one core
 is constantly spiking up to 40% the other 3 stay below 7%.

 When looking through the dmesg I cannot see that dpm is changing the
 power state to uvd. This makes me believe that I'm maybe using a
 cpu-decode rather then the dedicated uvd. The gpu-temps are also
 staying surpricingly low comapred to windows...

 --
 --joshua

With the latest git 7982128c3d447df27db963af67bc6b8dc7efb1de
drm/radeon/dpm: add debugfs support for SI from
git://people.freedesktop.org/~agd5f/linux drm-next-3.11 everything
works fine here (on TURKS). Under Linux I get the same temps as under
windows. No more tearing when watching videos. The GPU re-clocks as
desired...

--
--joshua
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: armada_drm clock selection - try 2


On 07/02/13 03:57, Daniel Drake wrote:

On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:

I prefer not to try to find the best clock (source) at all. Let the
user pass the clock name by e.g. platform_data (or DT) and just try to
get the requested pixclk or a integer multiple of it. You will never be
able to find the best clock for all use cases.

Just figure out, if integer division is sufficient to get requested
pixclk and clk_set_rate otherwise. This may be useful for current mode
running at 148.5MHz (1080p50) and new mode at 74.25MHz (1080i50, 720p).


I am not opposed to this approach, it is nice and simple, but as
Russell points out we do additionally need to distinguish between
clocks that are ours to play with, vs those that are shared with
other devices. It would be a bad idea to try call clk_set_rate() on
the AXI bus clock, for example, changing the clock for a whole bunch
of other devices. This is what the is_dedicated flag is about. However
such a flag could be easily added to the DT/platform data definition
that you propose.


Daniel,

now I got the idea of .is_dedicated. At least for Dove, we could still
implement AXI bus clock as fixed-rate clock, so you cannot mess with it.
I am almost sure, it will hang Dove when you change it, as there are
some devices depending on it (and the correct rate of it). Moreover,
LCDCLK is dedicated to CRTC0/1 so AXICLK is the only clock not
dedicated to LCD controllers.

But I am fine with .is_dedicated - I just think we should not try to
find the best clock source but leave that decision to the user
(=developer, DTS author; not userspace user).

Sebastian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Add missing includes

2013-07-03 Thread Mark Brown

On Tue, Jul 02, 2013 at 09:21:32PM +0900, Inki Dae wrote:

  Ensure that all externally accessed functions are correctly prototyped
  when defined in each file by making sure the headers with the protoypes
  are included in the file with the definition.

 I don't see why this patch is needed. it seems like including unnecessary
 headers so it makes the code size enlarged.

Well, aside from it being basic good practice and allowing the compiler
to check for errors in the prototypes this is also something that sparse
warns about.

If the resulting binary size is changed by having the headers included
then that indicates a bug in the headers - they *really* shouldn't be
doing anything substantial here.  None of the headers in question looked
at all worrying.


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI device IDs for device needing the i915 invert_brightness quirk

2013-07-03 Thread Pedro Ângelo


Dear all,

Recently I've come across this article about a probable fix for my 
laptop's black screen on boot:


http://people.skolelinux.org/pere/blog/Fixing_the_Linux_black_screen_of_death_on_machines_with_Intel_HD_video.html

I've tried the fix and it works perfectly so I'm contacting you as 
directed in the above article to send the PCI device IDs of the 
integrated graphics card of the laptop in question for future inclusion 
in the driver.


The laptop is an HP Envy 14 2020, the output of lspci -vvnn for the 
graphics card is:




00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd 
Generation Core
Processor Family Integrated Graphics Controller [8086:0116] (rev 09) 
(prog-if 00

 [VGA controller])
Subsystem: Hewlett-Packard Company Device [103c:3385]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Step

ping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- 
TAbort- MAbort- SERR- PERR- INTx-

Latency: 0
Interrupt: pin A routed to IRQ 52
Region 0: Memory at c800 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at b000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 4000 [size=64]
Expansion ROM at unassigned [disabled]T
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: feeff00c  Data: 41c1
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915



Best regards,
Pedro Ângelo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Best practice device tree design for display subsystems/DRM

Hi,

I'm looking into implementing devicetree support in armada_drm and
would like to better understand the best practice here.

Adding DT support for a DRM driver seems to be complicated by the fact
that DRM is not hotpluggable - it is not possible for the drm_device
to be initialised without an output, with the output connector/encoder
appearing at some later moment. Instead, the connectors/encoders must
be fully loaded before the drm_driver load function returns. This
means that we cannot drive the individual display components through
individual, separate modules - we need a way to control their load
order.

Looking at existing DRM drivers:

tilcdc_drm takes an approach that each of the components in the
display subsystem (panel, framebuffer, encoder, display controllers)
are separate DT nodes and do not have any DT-level linkage.
It implements just a single module, and that module carefully
initialises things in this order:
 1. Register platform drivers for output components
 2. Register main drm_driver

When the output component's platform drivers get loaded, probes for
such drivers immediately run as they match things in the device tree.
At this point, there is no drm_device available for the outputs to
bind to, so instead, references to these platform devices just get
saved in some global structures.

Later, when the drm_driver gets registered and loaded, the global
structures are consulted to find all of the output devices at the
right moment.


exynos seems to take a the same approach. Components are separate in
the device tree, and each component is implemented as a platform
driver or i2c driver. However all the drivers are built together in
the same module, and the module_init sequence is careful to initialise
all of the output component drivers before loading the DRM driver. The
output component driver store their findings in global structures.



Russell King suggested an alternative design for armada_drm. If all
display components are represented within the same display
super-node, we can examine the DT during drm_device initialisation and
initialise the appropriate output components. In this case, the output
components would not be registered as platform drivers.

The end result would be something similar to exynos/tilcdc (i.e.
drm_driver figuring out its output in the appropriate moment), however
the hackyness of using global storage to store output devices before
drm_driver is ready is avoided. And there is the obvious difference in
devicetree layout, which would look something like:

display {
  compatible = marvell,armada-510-display;
  clocks = ext_clk0, lcd_pll_clk;
  lcd0 {
compatible = marvell,armada-510-lcd;
reg = 0xf182 0x1000;
interrupts = 47;
  };
  lcd1 {
compatible = marvell,armada-510-lcd;
reg = 0xf181 0x1000;
interrupts = 46;
  };
  dcon {
compatible = marvell,armada-510-dcon;
reg = ...;
  };
};

Any thoughts/comments?

Thanks
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

2013-07-03 Thread Russell King - ARM Linux

On Tue, Jul 02, 2013 at 09:01:55PM +0300, Ville Syrjälä wrote:
 On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote:
  On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux
  li...@arm.linux.org.uk wrote:
   | Default Colorimetry
   |
   | ...
   |
   | 480p, 480i, 576p, 576i, 240p and 288p
   |
   | The default colorimetry for all 480-line, 576-line, 240-line, and 
   288-line
   | video formats described in CEA-861-D is based on SMPTE 170M.
   |
   | 1080i, 1080p and 720p
   |
   | The default colorimetry for high-definition video formats (1080i, 1080p 
   and
   | 720p) described in CEA-861-D is based on ITU-R BT.709-5.
 
 I think this was pretty much copy pasted from CEA-861-D which is very
 vague.
 
 CEA-861-E is a bit better, and more clearly states that if the sink can
 receive YCbCr, then the source should use it by default for CE formats,
 and the default colorimetry depends on whether it's SD or HD. It also
 states that when transmitting IT or CE formats as RGB, the color space
 is the one defined in the EDID. CEA-861-D only made that statement for
 IT formats, and left the RGB CE format case out in the cold.

Actually, what I'm doing there is probably wrong when you consider
what is going on:

 Overlay (YUV) - YUV-RGB colorspace conversion
  |
  v
 Graphic (RGB) ---(colorkey) HDMI

These bits control the YUV-RGB colorspace conversion.  The is it 601
or 709 colorspace question applies more to the colorspace of the
overlay image.  As far as I can tell, that is unspecified within our
normal video playback programs - there's provision to communicate that
information (they certainly don't seem to look for any kind of Xv
attribute).

The is it computer or studio RGB question (I think - I can't say
because the documentation is hellishly poor, and you now have as much
information on this as I do) refers to the colorspace of the RGB side.

So, maybe I should move the YUV colorspace setting to be a drm_plane
property?  But then how do we know what format it is supposed to be?
Do we just pick one and hope it's right?  Do we try to autodetect it
from the size of the drm_plane framebuffer?  What if something
downscales a HD YUV framebuffer to something smaller because the
display is smaller?

What I can say is that I've watched many hours of content with my driver
and at 720p output resolution, I prefer it converting the YUV between
709 to studio RGB - otherwise the blacks are too black and I find that
I have to adjust the brightness/contrast to bring the black levels up
compared to a standard TV broadcast.

 Oh and the other thing someone should do is fix the intel Xv code to
 use BT.709 CSC matrix for HD content. I believe that code is hardcoded
 for BT.601 currently, which may explain the last weirdness reported in
 that CEA bug or ours.

How do you propose to switch between the two?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Best practice device tree design for display subsystems/DRM

2013-07-03 Thread Jean-Francois Moine

On Tue, 2 Jul 2013 11:43:59 -0600
Daniel Drake d...@laptop.org wrote:

 Hi,

Hi Daniel,

 I'm looking into implementing devicetree support in armada_drm and
 would like to better understand the best practice here.
 
 Adding DT support for a DRM driver seems to be complicated by the fact
 that DRM is not hotpluggable - it is not possible for the drm_device
 to be initialised without an output, with the output connector/encoder
 appearing at some later moment. Instead, the connectors/encoders must
 be fully loaded before the drm_driver load function returns. This
 means that we cannot drive the individual display components through
 individual, separate modules - we need a way to control their load
 order.
 
 Looking at existing DRM drivers:
[snip]

It seems that you did not look at the NVIDIA Tegra driver (I got its
general concept for my own driver, but I used a simple atomic counter):

- at probe time, the main driver (drivers/gpu/host1x/drm/drm.c) scans
  the DT and finds its external modules. These ones are put in a
  clients list.

- when loaded, the other modules register themselves into the main
  driver. This last one checks if each module is in the client list.
  If so, the module is moved from the client to an active list.

- when the client list is empty, this means all modules are started,
  and, so, the main driver starts the drm stuff.

The active list is kept for module unloading.

 Russell King suggested an alternative design for armada_drm. If all
 display components are represented within the same display
 super-node, we can examine the DT during drm_device initialisation and
 initialise the appropriate output components. In this case, the output
 components would not be registered as platform drivers.
 
 The end result would be something similar to exynos/tilcdc (i.e.
 drm_driver figuring out its output in the appropriate moment), however
 the hackyness of using global storage to store output devices before
 drm_driver is ready is avoided. And there is the obvious difference in
 devicetree layout, which would look something like:
 
 display {
   compatible = marvell,armada-510-display;
   clocks = ext_clk0, lcd_pll_clk;
   lcd0 {
 compatible = marvell,armada-510-lcd;
 reg = 0xf182 0x1000;
 interrupts = 47;
   };
   lcd1 {
 compatible = marvell,armada-510-lcd;
 reg = 0xf181 0x1000;
 interrupts = 46;
   };
   dcon {
 compatible = marvell,armada-510-dcon;
 reg = ...;
   };
 };

Putting phandles in the 'display' seems more flexible (I did not do so
because I knew the hardware - 2 LCDs and the dcon/ire).

But, anyway, this does not solve the exact moment the modules are
loaded at startup time.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 11:43:59AM -0600, Daniel Drake wrote:
 exynos seems to take a the same approach. Components are separate in
 the device tree, and each component is implemented as a platform
 driver or i2c driver. However all the drivers are built together in
 the same module, and the module_init sequence is careful to initialise
 all of the output component drivers before loading the DRM driver. The
 output component driver store their findings in global structures.

I will point out that relying on driver probing orders has already been
stated by driver model people to be unsafe.  This is why I will not
adopt such a solution for my driver; it is a bad design.

-- 
Russell King
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Best practice device tree design for display subsystems/DRM

On Tue, Jul 2, 2013 at 12:43 PM, Russell King r...@arm.linux.org.uk wrote:
 I will point out that relying on driver probing orders has already been
 stated by driver model people to be unsafe.  This is why I will not
 adopt such a solution for my driver; it is a bad design.

Just to clarify, what you're objecting to is effectively the
following? Because it is not guaranteed in the future that the probe
order will be the same as the platform_driver_register() calls?

static int __init exynos_drm_init(void)
{
ret = platform_driver_register(hdmi_driver);
if (ret  0)
goto out_hdmi;
ret = platform_driver_register(mixer_driver);
if (ret  0)
goto out_mixer;
ret = platform_driver_register(exynos_drm_common_hdmi_driver);
if (ret  0)
goto out_common_hdmi;
ret = platform_driver_register(exynos_drm_platform_driver);
if (ret  0)
goto out_drm;

(exynos_drm_platform_driver is the driver that creates the drm_device)

Thanks
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 12:54:41PM -0600, Daniel Drake wrote:
 On Tue, Jul 2, 2013 at 12:43 PM, Russell King r...@arm.linux.org.uk wrote:
  I will point out that relying on driver probing orders has already been
  stated by driver model people to be unsafe.  This is why I will not
  adopt such a solution for my driver; it is a bad design.
 
 Just to clarify, what you're objecting to is effectively the
 following? Because it is not guaranteed in the future that the probe
 order will be the same as the platform_driver_register() calls?

Correct.  Consider what happens if the devices are registered after
the driver(s) have been registered, which may not be in the correct
order.

-- 
Russell King
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Best practice device tree design for display subsystems/DRM