[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

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

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

--- Comment #12 from Alex Deucher  ---
(In reply to comment #11)
> (In reply to comment #10)
> > Make sure you update your 32 bit 3D driver as you appear to be using a 64
> > bit distro and wine requires a 32 bit 3D driver.
> 
> This issue appeared for me in 2D games/applications, too. Haven't yet tested
> with newer mesa.

If they are 32-bit games, you'll hit the same issue.

-- 
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/20121005/e698281e/attachment.html>

[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine

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

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

--- Comment #11 from mailbox.tec at gmail.com ---
(In reply to comment #10)
> Make sure you update your 32 bit 3D driver as you appear to be using a 64
> bit distro and wine requires a 32 bit 3D driver.

This issue appeared for me in 2D games/applications, too. Haven't yet tested
with newer mesa.

-- 
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/20121005/c2848b6e/attachment.html>

[PATCH V7 11/15] drm: Handle io prot correctly for MIPS

[Huacai Chen]

Signed-off-by: Huacai Chen 
Signed-off-by: Hongliang Tao 
Signed-off-by: Hua Yan 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_vm.c  |2 +-
 drivers/gpu/drm/ttm/ttm_bo_util.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 961ee08..3f06166 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct 
vm_area_struct *vma)
tmp = pgprot_writecombine(tmp);
else
tmp = pgprot_noncached(tmp);
-#elif defined(__sparc__) || defined(__arm__)
+#elif defined(__sparc__) || defined(__arm__) || defined(__mips__)
tmp = pgprot_noncached(tmp);
 #endif
return tmp;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index f8187ea..0df71ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
else
tmp = pgprot_noncached(tmp);
 #endif
-#if defined(__sparc__)
+#if defined(__sparc__) || defined(__mips__)
if (!(caching_flags & TTM_PL_FLAG_CACHED))
tmp = pgprot_noncached(tmp);
 #endif
-- 
1.7.7.3

[PATCH V3] drm/radeon: Include swiotlb.h if SWIOTLB configured

[Huacai Chen]

When SWIOTLB is configured, if without this patch kernel compilation
fails with such error messages:

drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of 
function 'swiotlb_nr_tbl'
drivers/gpu/drm/radeon/radeon_ttm.c:607:3: warning: passing argument 2 of 
'ttm_dma_populate' from incompatible pointer type
include/drm/ttm/ttm_page_alloc.h:81:12: note: expected 'struct device *' but 
argument is of type 'struct device *'
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate':
drivers/gpu/drm/radeon/radeon_ttm.c:653:3: warning: passing argument 2 of 
'ttm_dma_unpopulate' from incompatible pointer type
include/drm/ttm/ttm_page_alloc.h:82:13: note: expected 'struct device *' but 
argument is of type 'struct device *'

V2:
1, Add compilation error messages;
2, Make the From: address the same as Signed-off-by address.

V3:
1, Send to Alex Deucher since this is radeon specific;
2, Add Reviewed-by email addresses.

Signed-off-by: Huacai Chen 
Signed-off-by: Hongliang Tao 
Signed-off-by: Hua Yan 
Reviewed-by: Michel D?nzer 
Reviewed-by: Konrad Rzeszutek Wilk 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/radeon/radeon_ttm.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 5b71c71..fc3ac22 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -41,6 +41,10 @@
 #include "radeon_reg.h"
 #include "radeon.h"

+#ifdef CONFIG_SWIOTLB
+#include 
+#endif
+
 #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT)

 static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
-- 
1.7.7.3

[GIT PULL v2] exynos-drm-next

[Inki Dae]

Hello Dave,

as I mentioned, this pull request adds hdmi device tree support
and includes related patch set such as disabling of hdmi internal
interrupt, suppport for platform variants for hdmi and mixer,
support to disable video processor based on platform type and
removal of drm common platform data. as you know, this patch
set was delayed because it included an media side patch. so for this,
we got an ack from v4l2-based hdmi driver author, Tomasz Stanislawski.

Changelog v1:
this patch set updates exynos drm framework and includes minor fixups.
and this pull request except hdmi device tree support patch set posted
by Rahul Sharma because that includes media side patch so for this
patch set, we may have git pull one more time in addition, if we get
an agreement with media guys. for this patch, you can refer to below link,
http://comments.gmane.org/gmane.comp.video.dri.devel/74504

if there is any problem, please let me know.

Thanks,
Inki Dae

The following changes since commit 29cb602532b0a82f22322cece8a89f022368d557:

  drm/exynos: added device object to subdrv's remove callback as argument 
(2012-10-04 10:05:59 +0900)

are available in the git repository at:
  git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-next

Inki Dae (15):
  drm/exynos: separated subdrv_probe function into two parts.
  drm/exynos: separeated fimd_power_on into some parts.
  drm/exynos: fixed duplicated mode setting.
  drm/exynos: add wait_for_vblank callback interface.
  drm/exynos: make sure that hardware overlay for fimd is disabled
  drm/exynos: make sure that hardware overlay for hdmi is disabled
  drm/exynos: check NV12M format specific to Exynos properly
  drm/exynos: update crtc to plane safely
  drm/exynos: Disable plane when released
  drm/exynos: add pid to g2d_runqueue_node
  drm/exynos: fix duplicated mutex lock issue
  drm/exynos: check crtc's dpms mode at page flip
  drm/exynos: check crtc's dpms mode at SetCrtc
  drm/exynos: support drm_wait_vblank feature for VIDI
  drm/exynos: fix display power call issue.

Joonyoung Shim (2):
  drm/exynos: fix to calculate CRTC shown via screen
  drm/exynos: fix kcalloc size of g2d cmdlist node

Leela Krishna Amudala (1):
  drm/exynos: add platform_device_id table and driver data for drm fimd

Rahul Sharma (9):
  drm: exynos: remove drm hdmi platform data struct
  drm: exynos: hdmi: add support for exynos5 ddc
  drm: exynos: hdmi: add support for exynos5 hdmiphy
  drm: exynos: hdmi: add support for platform variants for mixer
  drm: exynos: hdmi: add support to disable video processor in mixer
  drm: exynos: hdmi: add support for exynos5 mixer
  drm: exynos: hdmi: replace is_v13 with version check in hdmi
  drm: exynos: hdmi: add support for exynos5 hdmi
  drm: exynos: hdmi: remove drm common hdmi platform data struct

Sachin Kamat (1):
  drm/exynos: Fix potential NULL pointer dereference

Tomasz Stanislawski (5):
  media: s5p-hdmi: add HPD GPIO to platform data
  drm: exynos: hdmi: support for platform variants
  drm: exynos: hdmi: fix interrupt handling
  drm: exynos: hdmi: use s5p-hdmi platform data
  drm: exynos: hdmi: turn off HPD interrupt in HDMI chip

 drivers/gpu/drm/exynos/exynos_ddc.c   |   22 ++-
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   50 +-
 drivers/gpu/drm/exynos/exynos_drm_connector.h |4 +
 drivers/gpu/drm/exynos/exynos_drm_core.c  |  100 +++
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   20 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   17 ++
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |  116 +++--
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   65 +++-
 drivers/gpu/drm/exynos/exynos_drm_fb.h|   20 +--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  115 ++---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |5 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   62 ---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |3 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   58 ++-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   22 +++-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |  196 +++--
 drivers/gpu/drm/exynos/exynos_hdmiphy.c   |   12 ++-
 drivers/gpu/drm/exynos/exynos_mixer.c |  240 +++--
 drivers/gpu/drm/exynos/regs-mixer.h   |3 +
 include/drm/exynos_drm.h  |   37 +---
 include/media/s5p_hdmi.h  |2 +
 22 files changed, 905 insertions(+), 267 deletions(-)

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

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

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





--- Comment #7 from Peter   2012-10-05 20:00:56 ---
Thank you for letting me know. My VGA button (for switching between performance
and powersave mode) is also implemented as a software solution. When pressed, a
WMI ACPI event is generated which is processed by the Hotkey.exe program in
Windows. I guess yours works in a similar way.

Btw, are you able to test the aforementioned suspend/resume cycle in windows?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

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

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





--- Comment #6 from Alessandro Pignotti   
2012-10-05 19:36:03 ---
It's a switch. On linux I think it justs send a generic input event. So it's
implemented in software under windows.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

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

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





--- Comment #5 from Peter   2012-10-05 19:25:38 ---
Is that a switch (left/right slide) or toggle (slide to one side and it goes
back automatically)?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

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

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


Alessandro Pignotti  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Comment #4 from Alessandro Pignotti   
2012-10-05 19:22:05 ---
Unfortunately I don't have such indicator. The windows way of solving the issue
is using a physical switch.

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

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

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

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





--- Comment #3 from Peter   2012-10-05 19:13:52 ---
You can mark this bug as a duplicate of that bug.

Does your machine have an indicator that shows whether the discrete graphics
card is enabled or not? If you happens to have such an indicator and also have
a Windows installation with drivers installed, can you check what happens
around suspend/resume?

On my Nvidia Optimus laptop, the following holds for a s/r cycle under Windows:

- indicator shows initially that the dGPU is deactivated.
- Before suspend, indicator shows that dGPU is activated.
- On resume, the indicator initially shows the dGPU as deactivated. Then, it
turns shortly to "activated", and then to "deactivated" again.
- indicator finally shows the dGPU as deactivated.

Is this also true for AMD?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

HDMI ELD info failed to extract occasionally

[taiten...@gmail.com]

Hi,

I found a potential bug for i915 regarding to ELD parsing.

I was trying to monitor ELD by watching "/proc/asound/card0/eld#3.0" and I
realized that the ELD might failed to read from HDMI when AC power is not
plugged.
This looks like a potential hardware or driver issue, does anyone aware of
this?
I am also looking for the right place to file the bug, please suggest.

lspci result
00:02.0 VGA compatible controller: Intel Corporation Ivy Bridge Graphics
Controller (rev 05)
00:14.0 USB controller: Intel Corporation Panther Point USB xHCI Host
Controller (rev 04)
00:16.0 Communication controller: Intel Corporation Panther Point MEI
Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation Panther Point USB Enhanced Host
Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation Panther Point High Definition Audio
Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 1
(rev c4)
00:1c.1 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 2
(rev c4)
00:1d.0 USB controller: Intel Corporation Panther Point USB Enhanced Host
Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Panther Point LPC Controller (rev 04)
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller
[RAID mode] (rev 04)
00:1f.3 SMBus: Intel Corporation Panther Point SMBus Controller (rev 04)

Best Regads,
Taiten Peng
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121005/fb8e2216/attachment.html>

[PATCH 1/2 v6] of: add helper to parse display timings

[Steffen Trumtrar]

On Fri, Oct 05, 2012 at 10:21:37AM -0600, Stephen Warren wrote:
> On 10/05/2012 10:16 AM, Steffen Trumtrar wrote:
> > On Thu, Oct 04, 2012 at 12:47:16PM -0600, Stephen Warren wrote:
> >> On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
> ...
> >>> + for_each_child_of_node(timings_np, entry) {
> >>> + struct signal_timing *st;
> >>> +
> >>> + st = of_get_display_timing(entry);
> >>> +
> >>> + if (!st)
> >>> + continue;
> >>
> >> I wonder if that shouldn't be an error?
> > 
> > In the sense of a pr_err not a -EINVAL I presume?! It is a little bit quiet 
> > in
> > case of a faulty spec, that is right.
> 
> I did mean return an error; if we try to parse something and can't,
> shouldn't we return an error?
> 
> I suppose it may be possible to limp on and use whatever subset of modes
> could be parsed and drop the others, which is what this code does, but
> the code after the loop would definitely return an error if zero timings
> were parseable.

If a display supports multiple modes, I think it is better to have a working
mode (even if it is not the preferred one) than have none at all.
If there is no mode at all, that should be an error, right.

Regards,
Steffen

-- 
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- |

[PATCH 1/2 v6] of: add helper to parse display timings

[Steffen Trumtrar]

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
> Hi Steffen
> 
> Sorry for chiming in so late in the game, but I've long been wanting to 
> have a look at this and compare with what we do for V4L2, so, this seems a 
> great opportunity to me:-)
> 
> On Thu, 4 Oct 2012, Steffen Trumtrar wrote:
> 
> > Signed-off-by: Steffen Trumtrar 
> > ---
> >  .../devicetree/bindings/video/display-timings.txt  |  222 
> > 
> >  drivers/of/Kconfig |5 +
> >  drivers/of/Makefile|1 +
> >  drivers/of/of_display_timings.c|  183 
> >  include/linux/of_display_timings.h |   85 
> >  5 files changed, 496 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/video/display-timings.txt
> >  create mode 100644 drivers/of/of_display_timings.c
> >  create mode 100644 include/linux/of_display_timings.h
> > 
> > diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
> > b/Documentation/devicetree/bindings/video/display-timings.txt
> > new file mode 100644
> > index 000..45e39bd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/display-timings.txt
> > @@ -0,0 +1,222 @@
> > +display-timings bindings
> > +==
> > +
> > +display-timings-node
> > +
> > +
> > +required properties:
> > + - none
> > +
> > +optional properties:
> > + - default-timing: the default timing value
> > +
> > +timings-subnode
> > +---
> > +
> > +required properties:
> > + - hactive, vactive: Display resolution
> > + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing 
> > parameters
> > +   in pixels
> > +   vfront-porch, vback-porch, vsync-len: Vertical display timing 
> > parameters in
> > +   lines
> > + - clock: displayclock in Hz
> 
> You're going to hate me for this, but eventually we want to actually 
> reference clock objects in our DT bindings. For now, even if you don't 
> want to actually add clock phandles and stuff here, I think, using the 
> standard "clock-frequency" property would be much better!
> 

Well, that shouldn't be a big deal, the "clock-frequency" property I mean :-)

> > +
> > +optional properties:
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
> 
> For the above two we also considered using bool properties but eventually 
> settled down with integer ones:
> 
> - hsync-active = <1>
> 
> for active-high and 0 for active low. This has the added advantage of 
> being able to omit this property in the .dts, which then doesn't mean, 
> that the polarity is active low, but rather, that the hsync line is not 
> used on this hardware. So, maybe it would be good to use the same binding 
> here too?
> 

Never really thought about it that way. But the argument sounds convincing.

> > + - de-active-high (bool): Data-Enable pulse is active high
> > + - pixelclk-inverted (bool): pixelclock is inverted
> 
> We don't (yet) have a de-active property in V4L, don't know whether we'll 
> ever have to distingsuish between what some datasheets call "HREF" and 
> HSYNC in DT, but maybe similarly to the above an integer would be 
> preferred. As for pixclk, we call the property "pclk-sample" and it's also 
> an integer.
> 
> > + - interlaced (bool)
> 
> Is "interlaced" a property of the hardware, i.e. of the board? Can the 
> same display controller on one board require interlaced data and on 
> another board - progressive? BTW, I'm not very familiar with display 
> interfaces, but for interlaced you probably sometimes use a field signal, 
> whose polarity you also want to specify here? We use a "field-even-active" 
> integer property for it.
> 

I don't really know about that; have to collect some info first.

> Thanks
> Guennadi

Thank you.

Regards,
Steffen

-- 
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- |

[PATCH 1/2 v6] of: add helper to parse display timings

[Steffen Trumtrar]

On Thu, Oct 04, 2012 at 12:47:16PM -0600, Stephen Warren wrote:
> On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
> 
> A patch description would be useful for something like this.
> 

Yes. Shame on me.

> > diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
> > b/Documentation/devicetree/bindings/video/display-timings.txt
> > new file mode 100644
> ...
> > +Usage in backend
> > +
> 
> Everything before that point in the file looks fine to me.
> 

\o/

> Everything after this point in the file seems to be Linux-specific
> implementation details. Does it really belong in the DT binding
> documentation, rather than some Linux-specific documentation file?
> 

I guess you are right about that.

> > +struct drm_display_mode
> > +===
> > +
> > +  
> > +--+-+--+---+
> > +  |  | |  |
> >|  ?
> > +  |  | |  |
> >|  |
> > +  |  | |  |
> >|  |
> > +  
> > +--###--+---+
> >   |
> 
> I suspect the entire horizontal box above (and the entire vertical box
> all the way down the left-hand side) should be on the bottom/right
> instead of top/left. The reason I think this is because all of
> vsync_start, vsync_end, vdisplay have to be referenced to some known
> point, which is usually zero or the start of the timing definition, /or/
> there would be some value indicating the size of the top marging/porch
> in order to say where those other values are referenced to.
> 
> > +  |  #   ? ?  ?#  |
> >|  |
> > +  |  #   | |  |#  |
> >|  |
> > +  |  #   | |  |#  |
> >|  |
> > +  |  #   | |  |#  |
> >|  |
> > +  |  #   | |  |#  |
> >|  |
> > +  |  #   | |  |   hdisplay #  |
> >|  |
> > +  |  #<--++--->#  |
> >|  |
> > +  |  #   | |  |#  |
> >|  |
> > +  |  #   |vsync_start |#  |
> >|  |
> > +  |  #   | |  |#  |
> >|  |
> > +  |  #   | |vsync_end |#  |
> >|  |
> > +  |  #   | |  |vdisplay#  |
> >|  |
> > +  |  #   | |  |#  |
> >|  |
> > +  |  #   | |  |#  |
> >|  |
> > +  |  #   | |  |#  |
> >|  | vtotal
> > +  |  #   | |  |#  |
> >|  |
> > +  |  #   | |  | hsync_start#  |
> >|  |
> > +  |  #<--+-+--+-->|
> >|  |
> > +  |  #   | |  |#  |
> >|  |
> > +  |  #   | |  | hsync_end  #  |
> >|  |
> > +  |  
> > #<--+-+--+-->|  |
> > +  |  #   | |  ?#  |
> >|  |
> > +  
> > +--|#|--+---+
> >   |
> > +  |  |   | |   |  |
> >|  |
> > +  |  |   | |   |  |
> >|  |
> > +  |  |   ? |   |  |
> >|  |
> > +  
> > +--+-+---+--+---+
> >   |
> > +  |  | |   |  |
> >|  |
> > +  |  | |   |  |
> >|  |
> > +  |  | ?   |  |
> >|  ?
> > +  
> > +--+-+--+---+
> > +   htotal
> > +   
> > <->
> 
> > diff --git a/drivers/of/of_display_timings.c 
> > b/drivers/of/of_display_timings.c
> 
> > +static int parse_property(struct device_node *np, char *name,
> > +   struct 

HDMI ELD info failed to extract occasionally

[Jani Nikula]

On Fri, 05 Oct 2012, "taiten987 at gmail.com"  wrote:
> I found a potential bug for i915 regarding to ELD parsing.
>
> I was trying to monitor ELD by watching "/proc/asound/card0/eld#3.0"
> and I realized that the ELD might failed to read from HDMI when AC
> power is not plugged.  This looks like a potential hardware or driver
> issue, does anyone aware of this?

Hi Taiten, that's a bit thin on the details. What's the exact difference
you see with AC vs. battery? Is there anything special in dmesg? If not,
how about when you enable drm.debug=0xe kernel parameter? Which kernel
version are you running?

> I am also looking for the right place to file the bug, please suggest.

https://bugs.freedesktop.org/enter_bug.cgi 
Product: DRI, Component: DRM/Intel


BR,
Jani.


>
> lspci result
> 00:02.0 VGA compatible controller: Intel Corporation Ivy Bridge Graphics
> Controller (rev 05)
> 00:14.0 USB controller: Intel Corporation Panther Point USB xHCI Host
> Controller (rev 04)
> 00:16.0 Communication controller: Intel Corporation Panther Point MEI
> Controller #1 (rev 04)
> 00:1a.0 USB controller: Intel Corporation Panther Point USB Enhanced Host
> Controller #2 (rev 04)
> 00:1b.0 Audio device: Intel Corporation Panther Point High Definition Audio
> Controller (rev 04)
> 00:1c.0 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 1
> (rev c4)
> 00:1c.1 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 2
> (rev c4)
> 00:1d.0 USB controller: Intel Corporation Panther Point USB Enhanced Host
> Controller #1 (rev 04)
> 00:1f.0 ISA bridge: Intel Corporation Panther Point LPC Controller (rev 04)
> 00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller
> [RAID mode] (rev 04)
> 00:1f.3 SMBus: Intel Corporation Panther Point SMBus Controller (rev 04)
>
> Best Regads,
> Taiten Peng
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Rob Clark]

On Fri, Oct 5, 2012 at 5:41 PM, Imre Deak  wrote:
> On Fri, 2012-10-05 at 16:18 -0600, Rob Clark wrote:
>> On Fri, Oct 5, 2012 at 7:37 AM, Imre Deak  wrote:
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index ab1ef15..056e810 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -6247,7 +6247,6 @@ static void do_intel_finish_page_flip(struct 
>> > drm_device *dev,
>> > struct intel_unpin_work *work;
>> > struct drm_i915_gem_object *obj;
>> > struct drm_pending_vblank_event *e;
>> > -   struct timeval tvbl;
>> > unsigned long flags;
>> >
>> > /* Ignore early vblank irqs */
>> > @@ -6264,12 +6263,13 @@ static void do_intel_finish_page_flip(struct 
>> > drm_device *dev,
>> > intel_crtc->unpin_work = NULL;
>> >
>> > if (work->event) {
>> > -   e = work->event;
>> > -   e->event.sequence = drm_vblank_count_and_time(dev, 
>> > intel_crtc->pipe, );
>> > -
>> > -   e->event.tv_sec = tvbl.tv_sec;
>> > -   e->event.tv_usec = tvbl.tv_usec;
>> > +   struct drm_vblank_time tvbl;
>> > +   u32 seq;
>> >
>> > +   e = work->event;
>> > +   seq = drm_vblank_count_and_time(dev, intel_crtc->pipe, 
>> > );
>> > +   drm_set_event_seq_and_time(>event, e->timestamp_raw, 
>> > seq,
>> > +  );
>> > list_add_tail(>base.link,
>> >   >base.file_priv->event_list);
>> > wake_up_interruptible(>base.file_priv->event_wait);
>>
>>
>> btw, I wonder if we could just have a helper like:
>>
>> int drm_send_page_flip_event(struct drm_device *dev, int crtc,
>>   struct drm_pending_vblank_event *event);
>>
>> Since most drivers have pretty much the same code for sending vblank
>> event after a page flip..
>>
>> I guess not strictly related to monotonic timestamps, but it has been
>> a cleanup that I've been meaning to do for a while.. and I guess if
>> this was done first it wouldn't mean touching each driver (as much) to
>> add support for monotonic timestamps.
>
> Good idea, we should do this.
>
> But if we want to reduce the diff from my changes then the proto should
> rather be:
>
> int drm_send_page_flip_event(struct drm_device *dev, int crtc,
>struct drm_pending_vblank_event *event,
>int seq, struct timeval *now);

do we need 'seq' and 'now'?  I was sort of thinking that could all be
internal to the send_page_flip_event() fxn.. ie. like:

-
void drm_send_page_flip_event(struct drm_device *dev, int pipe,
struct drm_crtc *crtc, struct drm_pending_vblank_event *event)
{
struct timeval tnow, tvbl;

do_gettimeofday();

event->event.sequence = drm_vblank_count_and_time(dev, pipe, );

/* Called before vblank count and timestamps have
 * been updated for the vblank interval of flip
 * completion? Need to increment vblank count and
 * add one videorefresh duration to returned timestamp
 * to account for this. We assume this happened if we
 * get called over 0.9 frame durations after the last
 * timestamped vblank.
 *
 * This calculation can not be used with vrefresh rates
 * below 5Hz (10Hz to be on the safe side) without
 * promoting to 64 integers.
 */
if (10 * (timeval_to_ns() - timeval_to_ns()) >
9 * crtc->framedur_ns) {
event->event.sequence++;
tvbl = ns_to_timeval(timeval_to_ns() +
 crtc->framedur_ns);
}

event->event.tv_sec = tvbl.tv_sec;
event->event.tv_usec = tvbl.tv_usec;

list_add_tail(>base.link,
  >base.file_priv->event_list);
wake_up_interruptible(>base.file_priv->event_wait);
}
-

well, this would be the pre-monotonic timestamp version.. and it is a
bit weird to have to pass in both crtc ptr and pipe #.. I don't see
anything obvious in drm core that links pipe # and crtc ptr, although
userspace seems to make this assumption about order of crtc's.  But I
think that if() statement is only in i915 driver.. I assume because
you don't know if this will get called before or after
drm_handle_vblank()?  I guess that shouldn't hurt for other drivers.

then each driver would just have something like:

-
if (work->event)
drm_send_page_flip_event(dev, intel_crtc->pipe, crtc, 
work->event);
-


> with struct timeval changing to struct drm_vblank_time with my changes.
>
> I can do this if you agree - unless you have something ready.

I've locally split out this into a helper fxn in omapdrm, but haven't
got around to pushing it to core and updating other drivers.  If you
want I can send a patch, 

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

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

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





--- Comment #2 from Alessandro Pignotti   
2012-10-05 17:56:21 ---
Yes my setup is as you described. The bug looks the same as this indeed
https://bugzilla.kernel.org/show_bug.cgi?id=44391

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 2/2 v6] of: add generic videomode description

[Steffen Trumtrar]

On Thu, Oct 04, 2012 at 12:51:00PM -0600, Stephen Warren wrote:
> On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
> > Get videomode from devicetree in a format appropriate for the
> > backend. drm_display_mode and fb_videomode are supported atm.
> > Uses the display signal timings from of_display_timings
> 
> > +++ b/drivers/of/of_videomode.c
> 
> > +int videomode_from_timing(struct display_timings *disp, struct videomode 
> > *vm,
> 
> > +   st = display_timings_get(disp, index);
> > +
> > +   if (!st) {
> 
> It's a little odd to leave a blank line between those two lines.

Hm, well okay. That can be remedied

> 
> Only half of the code in this file seems OF-related; the routines to
> convert a timing to a videomode or drm display mode seem like they'd be
> useful outside device tree, so I wonder if putting them into
> of_videomode.c is the correct thing to do. Still, it's probably not a
> big deal.
> 

I am not sure, what the appropriate way to do this is. I can split it up 
(again).


-- 
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- |

[RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Imre Deak]

On Fri, 2012-10-05 at 16:14 +0200, Michel D?nzer wrote:
> On Fre, 2012-10-05 at 16:59 +0300, Imre Deak wrote: 
> > On Fri, 2012-10-05 at 15:55 +0200, Michel D?nzer wrote:
> > > On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote: 
> > > > In practice we never want the timestamps for vblank and page flip events
> > > > to be affected by time adjustments, so in addition to the gettimeofday
> > > > timestamps we used so far add support for raw monotonic timestamps.
> > > > 
> > > > For backward compatibility use flags to select between the old and new
> > > > timestamp format.
> > > > 
> > > > Note that with this change we will save the timestamp in both formats,
> > > > for cases where multiple clients are expecting an event notification in
> > > > different time formats.
> > > 
> > > I wonder if all this trouble is really necessary. I honestly can't
> > > imagine any user of this API requiring non-monotonic timestamps and
> > > breaking with monotonic ones. I think it was simply a mistake that we
> > > didn't make them monotonic in the first place (or maybe it wasn't even
> > > possible when this API was first introduced).
> > 
> > Yea, I'd rather simply switch over to monotonic timestamps too. But that
> > would break apps that already compare against the wall time for whatever
> > purpose (for example A/V sync).
> 
> Are there actually any such apps in the real world?

Tbh, I haven't checked, but we can't be sure in any case.

> Do they work when the wall time jumps?

They will have a problem with that yes. But providing them with a
monotonic clock when they expect otherwise will probably make them
unusable, so I think it's better to avoid that.

--Imre

[RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Imre Deak]

On Fri, 2012-10-05 at 15:55 +0200, Michel D?nzer wrote:
> On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote: 
> > In practice we never want the timestamps for vblank and page flip events
> > to be affected by time adjustments, so in addition to the gettimeofday
> > timestamps we used so far add support for raw monotonic timestamps.
> > 
> > For backward compatibility use flags to select between the old and new
> > timestamp format.
> > 
> > Note that with this change we will save the timestamp in both formats,
> > for cases where multiple clients are expecting an event notification in
> > different time formats.
> 
> I wonder if all this trouble is really necessary. I honestly can't
> imagine any user of this API requiring non-monotonic timestamps and
> breaking with monotonic ones. I think it was simply a mistake that we
> didn't make them monotonic in the first place (or maybe it wasn't even
> possible when this API was first introduced).

Yea, I'd rather simply switch over to monotonic timestamps too. But that
would break apps that already compare against the wall time for whatever
purpose (for example A/V sync).

--Imre

[RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Imre Deak]

In practice we never want the timestamps for vblank and page flip events
to be affected by time adjustments, so in addition to the gettimeofday
timestamps we used so far add support for raw monotonic timestamps.

For backward compatibility use flags to select between the old and new
timestamp format.

Note that with this change we will save the timestamp in both formats,
for cases where multiple clients are expecting an event notification in
different time formats. In theory we could track the clients and save
the timestamp only in one format if possible, but the overhead of this
tracking would be bigger than just saving both formats always.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_crtc.c|2 +
 drivers/gpu/drm/drm_ioctl.c   |3 ++
 drivers/gpu/drm/drm_irq.c |   68 +
 drivers/gpu/drm/i915/i915_irq.c   |2 +-
 drivers/gpu/drm/i915/intel_display.c  |   12 ++---
 drivers/gpu/drm/radeon/radeon_display.c   |   10 +++--
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/radeon_kms.c   |2 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c |9 ++--
 include/drm/drm.h |5 ++-
 include/drm/drmP.h|   38 +---
 include/drm/drm_mode.h|4 +-
 12 files changed, 104 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c317f72..e492363 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3550,6 +3550,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
goto out;
}

+   e->timestamp_raw = page_flip->flags &
+  DRM_MODE_PAGE_FLIP_TIMESTAMP_RAW;
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof e->event;
e->event.user_data = page_flip->user_data;
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 64a62c6..0a30299 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -287,6 +287,9 @@ int drm_getcap(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
req->value |= dev->driver->prime_fd_to_handle ? 
DRM_PRIME_CAP_IMPORT : 0;
req->value |= dev->driver->prime_handle_to_fd ? 
DRM_PRIME_CAP_EXPORT : 0;
break;
+   case DRM_CAP_TIMESTAMP_RAW:
+   req->value = 1;
+   break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 5e42981..4879363 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -105,7 +105,7 @@ static void vblank_disable_and_save(struct drm_device *dev, 
int crtc)
u32 vblcount;
s64 diff_ns;
int vblrc;
-   struct timeval tvblank;
+   struct drm_vblank_time tvblank;

/* Prevent vblank irq processing while disabling vblank irqs,
 * so no updates of timestamps or count can happen after we've
@@ -137,8 +137,8 @@ static void vblank_disable_and_save(struct drm_device *dev, 
int crtc)
 * as updated by last invocation of drm_handle_vblank() in vblank irq.
 */
vblcount = atomic_read(>_vblank_count[crtc]);
-   diff_ns = timeval_to_ns() -
- timeval_to_ns((dev, crtc, vblcount));
+   diff_ns = timeval_to_ns() -
+ timeval_to_ns((dev, crtc, vblcount).raw);

/* If there is at least 1 msec difference between the last stored
 * timestamp and tvblank, then we are currently executing our
@@ -550,7 +550,8 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
  * @crtc: Which crtc's vblank timestamp to retrieve.
  * @max_error: Desired maximum allowable error in timestamps (nanosecs).
  * On return contains true maximum error of timestamp.
- * @vblank_time: Pointer to struct timeval which should receive the timestamp.
+ * @vblank_time: Pointer to struct drm_vblank_time which should receive the
+ *  timestamp both in raw monotonic and wall-time format.
  * @flags: Flags to pass to driver:
  * 0 = Default.
  * DRM_CALLED_FROM_VBLIRQ = If function is called from vbl irq handler.
@@ -572,7 +573,7 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
  */
 int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc,
  int *max_error,
- struct timeval *vblank_time,
+ struct drm_vblank_time *vblank_time,
  unsigned flags,
  struct drm_crtc *refcrtc)
 {
@@ -693,12 +694,13 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev, int crtc,
/* Subtract time delta from raw 

[RFC 3/4] drm: use raw time in drm_calc_vbltimestamp_from_scanoutpos

[Imre Deak]

The timestamp is used here for handling the timeout case, so we don't
want it to be affected by time adjustments.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_irq.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 77f6577..5e42981 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -576,7 +576,7 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device 
*dev, int crtc,
  unsigned flags,
  struct drm_crtc *refcrtc)
 {
-   struct timeval stime, raw_time;
+   struct timespec raw_stime, raw_etime, real_etime;
struct drm_display_mode *mode;
int vbl_status, vtotal, vdisplay;
int vpos, hpos, i;
@@ -625,13 +625,13 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev, int crtc,
preempt_disable();

/* Get system timestamp before query. */
-   do_gettimeofday();
+   getrawmonotonic(_stime);

/* Get vertical and horizontal scanout pos. vpos, hpos. */
vbl_status = dev->driver->get_scanout_position(dev, crtc, 
, );

/* Get system timestamp after query. */
-   do_gettimeofday(_time);
+   getnstime_raw_and_real(_etime, _etime);

preempt_enable();

@@ -642,7 +642,8 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device 
*dev, int crtc,
return -EIO;
}

-   duration_ns = timeval_to_ns(_time) - timeval_to_ns();
+   duration_ns = timespec_to_ns(_etime) -
+ timespec_to_ns(_stime);

/* Accept result with <  max_error nsecs timing uncertainty. */
if (duration_ns <= (s64) *max_error)
@@ -692,11 +693,11 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev, int crtc,
/* Subtract time delta from raw timestamp to get final
 * vblank_time timestamp for end of vblank.
 */
-   *vblank_time = ns_to_timeval(timeval_to_ns(_time) - delta_ns);
+   *vblank_time = ns_to_timeval(timeval_to_ns(_time) - delta_ns);

DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d 
rep]\n",
  crtc, (int)vbl_status, hpos, vpos,
- (long)raw_time.tv_sec, (long)raw_time.tv_usec,
+ (long)raw_stime.tv_sec, (long)raw_stime.tv_nsec / 1000,
  (long)vblank_time->tv_sec, (long)vblank_time->tv_usec,
  (int)duration_ns/1000, i);

-- 
1.7.9.5

[RFC 2/4] drm: make memset/calloc for _vblank_time more robust

[Imre Deak]

Using sizeof(*var) instead of sizeof(var_type) allows changing var_type
w/o breaking callers that depend on the size.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_irq.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 076c4a8..77f6577 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -90,7 +90,7 @@ int drm_irq_by_busid(struct drm_device *dev, void *data,
 static void clear_vblank_timestamps(struct drm_device *dev, int crtc)
 {
memset(>_vblank_time[crtc * DRM_VBLANKTIME_RBSIZE], 0,
-   DRM_VBLANKTIME_RBSIZE * sizeof(struct timeval));
+   DRM_VBLANKTIME_RBSIZE * sizeof(dev->_vblank_time[0]));
 }

 /*
@@ -248,7 +248,7 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
goto err;

dev->_vblank_time = kcalloc(num_crtcs * DRM_VBLANKTIME_RBSIZE,
-   sizeof(struct timeval), GFP_KERNEL);
+   sizeof(dev->_vblank_time[0]), GFP_KERNEL);
if (!dev->_vblank_time)
goto err;

-- 
1.7.9.5

[RFC 1/4] time: export getnstime_raw_and_real for DRM

[Imre Deak]

Needed by the upcoming DRM raw monotonic timestamp support.

Signed-off-by: Imre Deak 
---
 kernel/time/timekeeping.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index d3b91e7..073d262 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -365,7 +365,7 @@ void ktime_get_ts(struct timespec *ts)
 }
 EXPORT_SYMBOL_GPL(ktime_get_ts);

-#ifdef CONFIG_NTP_PPS
+#if defined(CONFIG_NTP_PPS) || defined(CONFIG_DRM) || 
defined(CONFIG_DRM_MODULE)

 /**
  * getnstime_raw_and_real - get day and raw monotonic time in timespec format
-- 
1.7.9.5

[RFC 0/4] drm: add raw monotonic timestamp support

[Imre Deak]

This is needed to make applications depending on vblank/page flip
timestamps independent of time ajdustments.

I've tested these with an updated intel-gpu-test/flip_test and will send
the update for that once there's no objection about this patchset.

The patchset is based on danvet's dinq branch with the following
additional patches from the intel-gfx ML applied: 
drm/i915: paper over a pipe-enable vs pageflip race
drm/i915: don't frob the vblank ts in finish_page_flip
drm/i915: call drm_handle_vblank before finish_page_flip

Imre Deak (4):
  time: export getnstime_raw_and_real for DRM
  drm: make memset/calloc for _vblank_time more robust
  drm: use raw time in drm_calc_vbltimestamp_from_scanoutpos
  drm: add support for raw monotonic vblank timestamps

 drivers/gpu/drm/drm_crtc.c|2 +
 drivers/gpu/drm/drm_ioctl.c   |3 ++
 drivers/gpu/drm/drm_irq.c |   83 -
 drivers/gpu/drm/i915/i915_irq.c   |2 +-
 drivers/gpu/drm/i915/intel_display.c  |   12 ++---
 drivers/gpu/drm/radeon/radeon_display.c   |   10 ++--
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/radeon_kms.c   |2 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c |9 ++--
 include/drm/drm.h |5 +-
 include/drm/drmP.h|   38 +++--
 include/drm/drm_mode.h|4 +-
 kernel/time/timekeeping.c |2 +-
 13 files changed, 113 insertions(+), 61 deletions(-)

-- 
1.7.9.5

Monitor sync out of range with current Linux git tree

[Markus Trippelsdorf]

On 2012.10.05 at 10:25 -0400, Alex Deucher wrote:
> On Fri, Oct 5, 2012 at 10:15 AM, Markus Trippelsdorf
>  wrote:
> > On 2012.10.05 at 10:02 -0400, Alex Deucher wrote:
> >> On Fri, Oct 5, 2012 at 9:38 AM, Markus Trippelsdorf
> >>  wrote:
> >> > On 2012.10.05 at 09:14 -0400, Alex Deucher wrote:
> >> >> On Fri, Oct 5, 2012 at 8:37 AM, Markus Trippelsdorf
> >> >>  wrote:
> >> >> > When I cold start my machine I see the following error message on my
> >> >> > monitor:
> >> >> >
> >> >> >  Out of Range
> >> >> >  48.2kHz / 44Hz
> >> >> >
> >> >> > I have to reboot on older kernel and kexec to the current one to get 
> >> >> > it
> >> >> > working again.
> >> >>
> >> >> I don't see anything amiss; can you bisect?
> >> >
> >> > Yes. It's your commit:
> >> >
> >> > commit 9dbbcfc6894957fdbb311ba92c85c026659878b5
> >> > Author: Alex Deucher 
> >> > Date:   Wed Sep 12 17:39:57 2012 -0400
> >> >
> >> > drm/radeon/dce3: use a single PPLL for all DP displays
> >>
> >> Can you apply the attached patch and send me the output?
> >
> > [drm] == start crtc 0 driving DVI-D-1 ==
> > [drm] crtc 0 is not DP
> > [drm] plls in use 0x0
> > [drm] crtc 0 using pll 0x1
> > [drm] == end crtc 0 ==
> 
> Does the attached patch fix the issue?

Yes. Thanks Alex.

-- 
Markus

[RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Rob Clark]

On Fri, Oct 5, 2012 at 7:37 AM, Imre Deak  wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ab1ef15..056e810 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6247,7 +6247,6 @@ static void do_intel_finish_page_flip(struct drm_device 
> *dev,
> struct intel_unpin_work *work;
> struct drm_i915_gem_object *obj;
> struct drm_pending_vblank_event *e;
> -   struct timeval tvbl;
> unsigned long flags;
>
> /* Ignore early vblank irqs */
> @@ -6264,12 +6263,13 @@ static void do_intel_finish_page_flip(struct 
> drm_device *dev,
> intel_crtc->unpin_work = NULL;
>
> if (work->event) {
> -   e = work->event;
> -   e->event.sequence = drm_vblank_count_and_time(dev, 
> intel_crtc->pipe, );
> -
> -   e->event.tv_sec = tvbl.tv_sec;
> -   e->event.tv_usec = tvbl.tv_usec;
> +   struct drm_vblank_time tvbl;
> +   u32 seq;
>
> +   e = work->event;
> +   seq = drm_vblank_count_and_time(dev, intel_crtc->pipe, );
> +   drm_set_event_seq_and_time(>event, e->timestamp_raw, seq,
> +  );
> list_add_tail(>base.link,
>   >base.file_priv->event_list);
> wake_up_interruptible(>base.file_priv->event_wait);


btw, I wonder if we could just have a helper like:

int drm_send_page_flip_event(struct drm_device *dev, int crtc,
  struct drm_pending_vblank_event *event);

Since most drivers have pretty much the same code for sending vblank
event after a page flip..

I guess not strictly related to monotonic timestamps, but it has been
a cleanup that I've been meaning to do for a while.. and I guess if
this was done first it wouldn't mean touching each driver (as much) to
add support for monotonic timestamps.

BR,
-R

> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 7ddef8f..55c014a 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -272,7 +272,6 @@ void radeon_crtc_handle_flip(struct radeon_device *rdev, 
> int crtc_id)
> struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
> struct radeon_unpin_work *work;
> struct drm_pending_vblank_event *e;
> -   struct timeval now;
> unsigned long flags;
> u32 update_pending;
> int vpos, hpos;
> @@ -329,10 +328,13 @@ void radeon_crtc_handle_flip(struct radeon_device 
> *rdev, int crtc_id)
>
> /* wakeup userspace */
> if (work->event) {
> +   struct drm_vblank_time now;
> +   u32 seq;
> +
> e = work->event;
> -   e->event.sequence = drm_vblank_count_and_time(rdev->ddev, 
> crtc_id, );
> -   e->event.tv_sec = now.tv_sec;
> -   e->event.tv_usec = now.tv_usec;
> +   seq = drm_vblank_count_and_time(rdev->ddev, crtc_id, );
> +   drm_set_event_seq_and_time(>event, e->timestamp_raw,
> +  seq, );
> list_add_tail(>base.link, >base.file_priv->event_list);
> wake_up_interruptible(>base.file_priv->event_wait);
> }

Monitor sync out of range with current Linux git tree

[Markus Trippelsdorf]

On 2012.10.05 at 10:02 -0400, Alex Deucher wrote:
> On Fri, Oct 5, 2012 at 9:38 AM, Markus Trippelsdorf
>  wrote:
> > On 2012.10.05 at 09:14 -0400, Alex Deucher wrote:
> >> On Fri, Oct 5, 2012 at 8:37 AM, Markus Trippelsdorf
> >>  wrote:
> >> > When I cold start my machine I see the following error message on my
> >> > monitor:
> >> >
> >> >  Out of Range
> >> >  48.2kHz / 44Hz
> >> >
> >> > I have to reboot on older kernel and kexec to the current one to get it
> >> > working again.
> >>
> >> I don't see anything amiss; can you bisect?
> >
> > Yes. It's your commit:
> >
> > commit 9dbbcfc6894957fdbb311ba92c85c026659878b5
> > Author: Alex Deucher 
> > Date:   Wed Sep 12 17:39:57 2012 -0400
> >
> > drm/radeon/dce3: use a single PPLL for all DP displays
> 
> Can you apply the attached patch and send me the output?

[drm] == start crtc 0 driving DVI-D-1 ==
[drm] crtc 0 is not DP
[drm] plls in use 0x0
[drm] crtc 0 using pll 0x1
[drm] == end crtc 0 ==

-- 
Markus

[RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Michel Dänzer]

On Fre, 2012-10-05 at 16:59 +0300, Imre Deak wrote: 
> On Fri, 2012-10-05 at 15:55 +0200, Michel D?nzer wrote:
> > On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote: 
> > > In practice we never want the timestamps for vblank and page flip events
> > > to be affected by time adjustments, so in addition to the gettimeofday
> > > timestamps we used so far add support for raw monotonic timestamps.
> > > 
> > > For backward compatibility use flags to select between the old and new
> > > timestamp format.
> > > 
> > > Note that with this change we will save the timestamp in both formats,
> > > for cases where multiple clients are expecting an event notification in
> > > different time formats.
> > 
> > I wonder if all this trouble is really necessary. I honestly can't
> > imagine any user of this API requiring non-monotonic timestamps and
> > breaking with monotonic ones. I think it was simply a mistake that we
> > didn't make them monotonic in the first place (or maybe it wasn't even
> > possible when this API was first introduced).
> 
> Yea, I'd rather simply switch over to monotonic timestamps too. But that
> would break apps that already compare against the wall time for whatever
> purpose (for example A/V sync).

Are there actually any such apps in the real world? Do they work when
the wall time jumps?


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[RFC 0/4] drm: add raw monotonic timestamp support

[Eric Anholt]

Imre Deak  writes:

> This is needed to make applications depending on vblank/page flip
> timestamps independent of time ajdustments.
>
> I've tested these with an updated intel-gpu-test/flip_test and will send
> the update for that once there's no objection about this patchset.
>
> The patchset is based on danvet's dinq branch with the following
> additional patches from the intel-gfx ML applied: 
> drm/i915: paper over a pipe-enable vs pageflip race
> drm/i915: don't frob the vblank ts in finish_page_flip
> drm/i915: call drm_handle_vblank before finish_page_flip

While people are in pageflip code:

It would be really, really cool for application tracing if we could get
timestamps out of our swaps that used the TIMESTAMP register that is the
timer used for event tracing on the GPU using GL_ARB_timer_query.  Then
you could get decent visualizations of the latency of your rendering.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121005/dbc4e823/attachment.pgp>

[RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Michel Dänzer]

On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote: 
> In practice we never want the timestamps for vblank and page flip events
> to be affected by time adjustments, so in addition to the gettimeofday
> timestamps we used so far add support for raw monotonic timestamps.
> 
> For backward compatibility use flags to select between the old and new
> timestamp format.
> 
> Note that with this change we will save the timestamp in both formats,
> for cases where multiple clients are expecting an event notification in
> different time formats.

I wonder if all this trouble is really necessary. I honestly can't
imagine any user of this API requiring non-monotonic timestamps and
breaking with monotonic ones. I think it was simply a mistake that we
didn't make them monotonic in the first place (or maybe it wasn't even
possible when this API was first introduced).


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

Monitor sync out of range with current Linux git tree

[Markus Trippelsdorf]

On 2012.10.05 at 09:14 -0400, Alex Deucher wrote:
> On Fri, Oct 5, 2012 at 8:37 AM, Markus Trippelsdorf
>  wrote:
> > When I cold start my machine I see the following error message on my
> > monitor:
> >
> >  Out of Range
> >  48.2kHz / 44Hz
> >
> > I have to reboot on older kernel and kexec to the current one to get it
> > working again.
> 
> I don't see anything amiss; can you bisect?

Yes. It's your commit:

commit 9dbbcfc6894957fdbb311ba92c85c026659878b5
Author: Alex Deucher 
Date:   Wed Sep 12 17:39:57 2012 -0400

drm/radeon/dce3: use a single PPLL for all DP displays

-- 
Markus

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

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

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


Peter  changed:

   What|Removed |Added

 CC||lekensteyn at gmail.com




--- Comment #1 from Peter   2012-10-05 15:01:01 ---
Possibly a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=44391
(which is about Nvidia Optimus, but a solution possibly has the same patch)

So you have a MUX-less hybrid Intel / AMD setup if I am not mistaken?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

Monitor sync out of range with current Linux git tree

[Markus Trippelsdorf]

When I cold start my machine I see the following error message on my
monitor:

 Out of Range
 48.2kHz / 44Hz

I have to reboot on older kernel and kexec to the current one to get it
working again.

[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4083554 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c60c00
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 0 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
[drm] radeon: power management initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF000
[drm] size 7299072
[drm] fb depth is 24
[drm]pitch is 6912
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 131x105
fb0: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.24.0 20080528 for :01:05.0 on minor 0


X.Org X Server 1.13.0
Release Date: 2012-09-05
...
[ 4.790] (II) [KMS] Kernel modesetting enabled.
[ 4.790] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 4.790] (II) RADEON(0): Creating default Display subsection in Screen 
section
"Default Screen Section" for depth/fbbpp 24/32
[ 4.790] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
[ 4.790] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp 
pixmaps)
[ 4.790] (==) RADEON(0): Default visual is TrueColor
[ 4.790] (==) RADEON(0): RGB weight 888
[ 4.790] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[ 4.790] (--) RADEON(0): Chipset: "ATI Radeon HD 3300 Graphics" (ChipID = 
0x9614)
[ 4.790] (II) RADEON(0): PCI card detected
[ 4.791] (II) Loading sub module "exa"
[ 4.791] (II) LoadModule: "exa"
[ 4.792] (II) Loading /usr/lib64/xorg/modules/libexa.so
[ 4.792] (II) Module exa: vendor="X.Org Foundation"
[ 4.792]compiled for 1.13.0, module version = 2.6.0
[ 4.792]ABI class: X.Org Video Driver, version 13.0
[ 4.792] (II) RADEON(0): KMS Color Tiling: enabled
[ 4.792] (II) RADEON(0): KMS Pageflipping: enabled
[ 4.792] (II) RADEON(0): SwapBuffers wait for vsync: enabled
[ 4.813] (II) RADEON(0): Output VGA-0 has no monitor section
[ 4.870] (II) RADEON(0): Output DVI-0 using monitor section DVI-0
[ 4.870] (**) RADEON(0): Option "Rotate" "left"
[ 4.890] (II) RADEON(0): EDID for output VGA-0
[ 4.950] (II) RADEON(0): EDID for output DVI-0
[ 4.950] (II) RADEON(0): Manufacturer: GSM  Model: 4e48  Serial#: 148502
[ 4.950] (II) RADEON(0): Year: 2006  Week: 8
[ 4.950] (II) RADEON(0): EDID Version: 1.3
[ 4.950] (II) RADEON(0): Digital Display Input
[ 4.950] (II) RADEON(0): Max Image Size [cm]: horiz.: 43  vert.: 27
[ 4.950] (II) RADEON(0): Gamma: 2.20
[ 4.950] (II) RADEON(0): DPMS capabilities: StandBy Suspend Off
[ 4.950] (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 
[ 4.950] (II) RADEON(0): First detailed timing is preferred mode
[ 4.950] (II) RADEON(0): redX: 0.651 redY: 0.333   greenX: 0.277 greenY: 
0.614
[ 4.950] (II) RADEON(0): blueX: 0.145 blueY: 0.082   whiteX: 0.313 whiteY: 
0.329
[ 4.950] (II) RADEON(0): Supported established timings:
[ 4.950] (II) RADEON(0): 720x400 at 70Hz
[ 4.950] (II) RADEON(0): 640x480 at 60Hz
[ 4.950] (II) RADEON(0): 640x480 at 75Hz
[ 4.950] (II) RADEON(0): 800x600 at 56Hz
[ 4.950] (II) RADEON(0): 800x600 at 60Hz
[ 4.950] (II) RADEON(0): 800x600 at 75Hz
[ 4.950] (II) RADEON(0): 832x624 at 75Hz
[ 4.950] (II) RADEON(0): 1024x768 

[PATCH 04/14] media: add V4L2 DT binding documentation

[Guennadi Liakhovetski]

On Fri, 5 Oct 2012, Hans Verkuil wrote:

> On Fri October 5 2012 11:43:27 Guennadi Liakhovetski wrote:
> > On Wed, 3 Oct 2012, Rob Herring wrote:
> > 
> > > On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
> > > > Hi Rob
> > > > 
> > > > On Tue, 2 Oct 2012, Rob Herring wrote:
> > > > 
> > > >> On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:

[snip]

> > > >>> +Optional link properties:
> > > >>> +- remote: phandle to the other endpoint link DT node.
> > > >>
> > > >> This name is a little vague. Perhaps "endpoint" would be better.
> > > > 
> > > > "endpoint" can also refer to something local like in USB case. Maybe 
> > > > rather the description of the "remote" property should be improved?
> > > 
> > > remote-endpoint?
> > 
> > Sorry, I really don't want to pull in yet another term here. We've got 
> > ports and links already, now you're proposing to also use "endpoind." 
> > Until now everyone was happy with "remote," any more opinions on this?
> 
> Actually, when I was reviewing the patch series today I got confused as
> well by 'remote'. What about 'remote-link'?

Yes, I was thinking about this one too, it looks a bit clumsy, but it does 
make it clearer, what is meant.

> And v4l2_of_get_remote() can be renamed to v4l2_of_get_remote_link() which
> I think is a lot clearer.
> 
> The text can be improved as well since this:
> 
> - remote: phandle to the other endpoint link DT node.
> 
> is a bit vague. How about:
> 
> - remote-link: phandle to the remote end of this link.

Looks good to me.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH 04/14] media: add V4L2 DT binding documentation

[Hans Verkuil]

On Fri October 5 2012 11:43:27 Guennadi Liakhovetski wrote:
> On Wed, 3 Oct 2012, Rob Herring wrote:
> 
> > On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
> > > Hi Rob
> > > 
> > > On Tue, 2 Oct 2012, Rob Herring wrote:
> > > 
> > >> On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:
> > >>> This patch adds a document, describing common V4L2 device tree bindings.
> > >>>
> > >>> Co-authored-by: Sylwester Nawrocki 
> > >>> Signed-off-by: Guennadi Liakhovetski 
> > >>> ---
> > >>>  Documentation/devicetree/bindings/media/v4l2.txt |  162 
> > >>> ++
> > >>>  1 files changed, 162 insertions(+), 0 deletions(-)
> > >>>  create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
> > >>>
> > >>> diff --git a/Documentation/devicetree/bindings/media/v4l2.txt 
> > >>> b/Documentation/devicetree/bindings/media/v4l2.txt
> > >>> new file mode 100644
> > >>> index 000..b8b3f41
> > >>> --- /dev/null
> > >>> +++ b/Documentation/devicetree/bindings/media/v4l2.txt
> > >>> @@ -0,0 +1,162 @@
> > >>> +Video4Linux Version 2 (V4L2)
> > >>
> > >> DT describes the h/w, but V4L2 is Linux specific. I think the binding
> > >> looks pretty good in terms of it is describing the h/w and not V4L2
> > >> components or settings. So in this case it's really just the name of the
> > >> file and title I have issue with.
> > > 
> > > Hm, I see your point, then, I guess, you'd also like the file name 
> > > changed. What should we use then? Just "video?" But there's already a 
> > > whole directory Documentation/devicetree/bindings/video dedicated to 
> > > graphics output (drm, fbdev). "video-camera" or "video-capture?" But this 
> > > file shall also be describing video output. Use "video.txt" and describe 
> > > inside what exactly this file is for?
> > 
> > Video output will probably have a lot of overlap with the graphics side.
> > How about video-interfaces.txt?
> 
> Hm, that's a bit too vague for me. Somewhere on the outskirts of my mind 
> I'm still considering making just one standard for both V4L2 and fbdev / 
> DRM? Just yesterday we were discussing some common properties with what is 
> being proposed in
> 
> http://www.mail-archive.com/linux-media at vger.kernel.org/index.html#53322
> 
> Still, I think, these two subsystems deserve two separate standards and 
> should just try to re-use properties wherever that makes sense. 
> video-stream seems a bit better, but this too is just a convention - 
> talking about video cameras and TV output as video streaming devices and 
> considering displays more static devices. In principle displays can be 
> considered taking streaming data just as well as TV encoders. What if we 
> just call this camera-tv.txt?
> 
> > >> One other comment below:
> > >>
> > >>> +
> > >>> +General concept
> > >>> +---
> > >>> +
> > >>> +Video pipelines consist of external devices, e.g. camera sensors, 
> > >>> controlled
> > >>> +over an I2C, SPI or UART bus, and SoC internal IP blocks, including 
> > >>> video DMA
> > >>> +engines and video data processors.
> > >>> +
> > >>> +SoC internal blocks are described by DT nodes, placed similarly to 
> > >>> other SoC
> > >>> +blocks. External devices are represented as child nodes of their 
> > >>> respective bus
> > >>> +controller nodes, e.g. I2C.
> > >>> +
> > >>> +Data interfaces on all video devices are described by "port" child DT 
> > >>> nodes.
> > >>> +Configuration of a port depends on other devices participating in the 
> > >>> data
> > >>> +transfer and is described by "link" DT nodes, specified as children of 
> > >>> the
> > >>> +"port" nodes:
> > >>> +
> > >>> +/foo {
> > >>> +   port at 0 {
> > >>> +   link at 0 { ... };
> > >>> +   link at 1 { ... };
> > >>> +   };
> > >>> +   port at 1 { ... };
> > >>> +};
> > >>> +
> > >>> +If a port can be configured to work with more than one other device on 
> > >>> the same
> > >>> +bus, a "link" child DT node must be provided for each of them. If more 
> > >>> than one
> > >>> +port is present on a device or more than one link is connected to a 
> > >>> port, a
> > >>> +common scheme, using "#address-cells," "#size-cells" and "reg" 
> > >>> properties is
> > >>> +used.
> > >>> +
> > >>> +Optional link properties:
> > >>> +- remote: phandle to the other endpoint link DT node.
> > >>
> > >> This name is a little vague. Perhaps "endpoint" would be better.
> > > 
> > > "endpoint" can also refer to something local like in USB case. Maybe 
> > > rather the description of the "remote" property should be improved?
> > 
> > remote-endpoint?
> 
> Sorry, I really don't want to pull in yet another term here. We've got 
> ports and links already, now you're proposing to also use "endpoind." 
> Until now everyone was happy with "remote," any more opinions on this?

Actually, when I was reviewing the patch series today I got confused as
well by 'remote'. What about 'remote-link'?

And v4l2_of_get_remote() can be renamed to 

linux-next: Tree for Oct 5 (nouveau)

[Randy Dunlap]

On 10/04/2012 09:54 PM, Stephen Rothwell wrote:

> Hi all,
> 
> Do not add stuff destined for v3.8 to your linux-next included branches
> until after v3.7-rc1 is released.
> 
> Changes since 201201004:
> 


on x86_64, when CONFIG_AGP is not enabled:

  CC [M]  drivers/gpu/drm/nouveau/nouveau_bo.o
drivers/gpu/drm/nouveau/nouveau_bo.c: In function 'nouveau_ttm_tt_create':
drivers/gpu/drm/nouveau/nouveau_bo.c:463:3: error: implicit declaration of 
function 'ttm_agp_tt_create'
drivers/gpu/drm/nouveau/nouveau_bo.c:463:3: warning: return makes pointer from 
integer without a cast
make[5]: *** [drivers/gpu/drm/nouveau/nouveau_bo.o] Error 1


-- 
~Randy

[RFC] drm/radeon: make dynamic allocation of page tables on demand in radeon_vm_update_pte v2

[Christian König]

Trying to resolve the remaining bugs today. Expect an v3 of the patch 
this evening or Monday morning.

Cheers,
Christian.

On 04.10.2012 16:32, Dmitry Cherkasov wrote:
> v2: setup and alloc number of contiguous PTs if possible
>
> Warning: Heaven benchmark /sometimes/ fails with this patch after
> 10 or 15 minutes of working, so any insight is greatly appreciated.
>
> The code is a bit bloated because it's a question how a decent optimization
> should be made: via macros? using structs? etc.
>
> The rationale for struct radeon_pt is that BO may contain several contiguous
> PTs and we should have that u64 gpu_addr to point to actual begining of PT.
>
> I've only tested it on cayman card, should work on SI but who knows? ;)
>
> Please say your ideas.
> ---
>   drivers/gpu/drm/radeon/radeon.h  |   12 ++
>   drivers/gpu/drm/radeon/radeon_gart.c |  263 
> --
>   2 files changed, 260 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index b04c064..38d4eda 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -659,6 +659,15 @@ struct radeon_ring {
>   /* number of entries in page table */
>   #define RADEON_VM_PTE_COUNT (1 << RADEON_VM_BLOCK_SIZE)
>   
> +struct radeon_pt {
> + /* BO containing the page table */
> + /* radeon_sa_bo_gpu_addr(sa_bo); */
> + struct radeon_sa_bo *bo;
> +
> + /* GPU address of page table */
> + u64 gpu_addr;
> +};
> +
>   struct radeon_vm {
>   struct list_headlist;
>   struct list_headva;
> @@ -671,6 +680,9 @@ struct radeon_vm {
>   struct radeon_fence *fence;
>   /* last flush or NULL if we still need to flush */
>   struct radeon_fence *last_flush;
> +
> + /* page tables list */
> + struct radeon_pt *vm_pts;
>   };
>   
>   struct radeon_vm_manager {
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 753b7ca..cea918d 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -500,6 +500,10 @@ static void radeon_vm_free_pt(struct radeon_device *rdev,
>   struct radeon_vm *vm)
>   {
>   struct radeon_bo_va *bo_va;
> + int i;
> +
> + int driver_table_entries = (rdev->vm_manager.max_pfn >>
> + RADEON_VM_BLOCK_SIZE);
>   
>   if (!vm->sa_bo)
>   return;
> @@ -510,6 +514,14 @@ static void radeon_vm_free_pt(struct radeon_device *rdev,
>   list_for_each_entry(bo_va, >va, vm_list) {
>   bo_va->valid = false;
>   }
> +
> + if (vm->vm_pts == NULL)
> + return;
> +
> + for (i = 0;i < driver_table_entries; i++)
> + radeon_sa_bo_free(rdev, >vm_pts[i].bo, vm->fence);
> +
> + kfree (vm->vm_pts);
>   }
>   
>   /**
> @@ -563,6 +575,9 @@ int radeon_vm_alloc_pt(struct radeon_device *rdev, struct 
> radeon_vm *vm)
>   int r;
>   u64 *pd_addr;
>   int tables_size;
> + int driver_table_size = (rdev->vm_manager.max_pfn >>
> +  RADEON_VM_BLOCK_SIZE) *
> + sizeof(struct radeon_pt);
>   
>   if (vm == NULL) {
>   return -EINVAL;
> @@ -570,7 +585,6 @@ int radeon_vm_alloc_pt(struct radeon_device *rdev, struct 
> radeon_vm *vm)
>   
>   /* allocate enough to cover the current VM size */
>   tables_size = RADEON_GPU_PAGE_ALIGN(radeon_vm_directory_size(rdev));
> - tables_size += RADEON_GPU_PAGE_ALIGN(vm->last_pfn * 8);
>   
>   if (vm->sa_bo != NULL) {
>   /* update lru */
> @@ -600,6 +614,16 @@ retry:
>   vm->pd_gpu_addr = radeon_sa_bo_gpu_addr(vm->sa_bo);
>   memset(pd_addr, 0, tables_size);
>   
> + vm->vm_pts = kmalloc(driver_table_size, GFP_KERNEL);
> +
> + if (vm->vm_pts == NULL) {
> + DRM_ERROR("Cannot allocate space for driver page table\n");
> + radeon_sa_bo_free(rdev, >sa_bo, vm->fence);
> + return -ENOMEM;
> + }
> +
> + memset(vm->vm_pts, 0, driver_table_size);
> +
>   list_add_tail(>list, >vm_manager.lru_vm);
>   return radeon_vm_bo_update_pte(rdev, vm, rdev->ring_tmp_bo.bo,
>  >ring_tmp_bo.bo->tbo.mem);
> @@ -864,6 +888,69 @@ uint64_t radeon_vm_map_gart(struct radeon_device *rdev, 
> uint64_t addr)
>   return result;
>   }
>   
> +/* setup @count pfns starting at @addr to PTEs starting at @pt_start and
> + * @pde_count pdes starting at @pd_start */
> +
> +static void radeon_vm_map_pfns (struct radeon_device *rdev,
> + uint64_t pt_addr, uint64_t pt_offset,
> + uint64_t addr, uint64_t pte_count,
> + uint64_t pd_start, uint32_t pde_count, uint32_t 
> flags)
> +{
> + if (pde_count == 0 && pte_count == 0)
> + return;
> +
> + 

[RFC 1/4] time: export getnstime_raw_and_real for DRM

[Kristian Høgsberg]

On Fri, Oct 5, 2012 at 9:36 AM, Imre Deak  wrote:
> Needed by the upcoming DRM raw monotonic timestamp support.

I just had a quick look at driver/input/evdev.c, since evdev devices
did a similar change recently to allow evdev timestamp from the
monotonic clock.  They're using a different time API:

time_mono = ktime_get();
time_real = ktime_sub(time_mono, ktime_get_monotonic_offset());

and

event->time = ktime_to_timeval(client->clkid == CLOCK_MONOTONIC ?
mono : real);

I'm not really up-to-date on kernel time APIs, but I wonder if that
may be better?  At least, I suspect we wouldn't need changes outside
drm if we use this API.

Kristian


> Signed-off-by: Imre Deak 
> ---
>  kernel/time/timekeeping.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index d3b91e7..073d262 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -365,7 +365,7 @@ void ktime_get_ts(struct timespec *ts)
>  }
>  EXPORT_SYMBOL_GPL(ktime_get_ts);
>
> -#ifdef CONFIG_NTP_PPS
> +#if defined(CONFIG_NTP_PPS) || defined(CONFIG_DRM) || 
> defined(CONFIG_DRM_MODULE)
>
>  /**
>   * getnstime_raw_and_real - get day and raw monotonic time in timespec format
> --
> 1.7.9.5
>

[PATCH 04/14] media: add V4L2 DT binding documentation

[Guennadi Liakhovetski]

On Wed, 3 Oct 2012, Rob Herring wrote:

> On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
> > Hi Rob
> > 
> > On Tue, 2 Oct 2012, Rob Herring wrote:
> > 
> >> On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:
> >>> This patch adds a document, describing common V4L2 device tree bindings.
> >>>
> >>> Co-authored-by: Sylwester Nawrocki 
> >>> Signed-off-by: Guennadi Liakhovetski 
> >>> ---
> >>>  Documentation/devicetree/bindings/media/v4l2.txt |  162 
> >>> ++
> >>>  1 files changed, 162 insertions(+), 0 deletions(-)
> >>>  create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/media/v4l2.txt 
> >>> b/Documentation/devicetree/bindings/media/v4l2.txt
> >>> new file mode 100644
> >>> index 000..b8b3f41
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/media/v4l2.txt
> >>> @@ -0,0 +1,162 @@
> >>> +Video4Linux Version 2 (V4L2)
> >>
> >> DT describes the h/w, but V4L2 is Linux specific. I think the binding
> >> looks pretty good in terms of it is describing the h/w and not V4L2
> >> components or settings. So in this case it's really just the name of the
> >> file and title I have issue with.
> > 
> > Hm, I see your point, then, I guess, you'd also like the file name 
> > changed. What should we use then? Just "video?" But there's already a 
> > whole directory Documentation/devicetree/bindings/video dedicated to 
> > graphics output (drm, fbdev). "video-camera" or "video-capture?" But this 
> > file shall also be describing video output. Use "video.txt" and describe 
> > inside what exactly this file is for?
> 
> Video output will probably have a lot of overlap with the graphics side.
> How about video-interfaces.txt?

Hm, that's a bit too vague for me. Somewhere on the outskirts of my mind 
I'm still considering making just one standard for both V4L2 and fbdev / 
DRM? Just yesterday we were discussing some common properties with what is 
being proposed in

http://www.mail-archive.com/linux-media at vger.kernel.org/index.html#53322

Still, I think, these two subsystems deserve two separate standards and 
should just try to re-use properties wherever that makes sense. 
video-stream seems a bit better, but this too is just a convention - 
talking about video cameras and TV output as video streaming devices and 
considering displays more static devices. In principle displays can be 
considered taking streaming data just as well as TV encoders. What if we 
just call this camera-tv.txt?

> >> One other comment below:
> >>
> >>> +
> >>> +General concept
> >>> +---
> >>> +
> >>> +Video pipelines consist of external devices, e.g. camera sensors, 
> >>> controlled
> >>> +over an I2C, SPI or UART bus, and SoC internal IP blocks, including 
> >>> video DMA
> >>> +engines and video data processors.
> >>> +
> >>> +SoC internal blocks are described by DT nodes, placed similarly to other 
> >>> SoC
> >>> +blocks. External devices are represented as child nodes of their 
> >>> respective bus
> >>> +controller nodes, e.g. I2C.
> >>> +
> >>> +Data interfaces on all video devices are described by "port" child DT 
> >>> nodes.
> >>> +Configuration of a port depends on other devices participating in the 
> >>> data
> >>> +transfer and is described by "link" DT nodes, specified as children of 
> >>> the
> >>> +"port" nodes:
> >>> +
> >>> +/foo {
> >>> + port at 0 {
> >>> + link at 0 { ... };
> >>> + link at 1 { ... };
> >>> + };
> >>> + port at 1 { ... };
> >>> +};
> >>> +
> >>> +If a port can be configured to work with more than one other device on 
> >>> the same
> >>> +bus, a "link" child DT node must be provided for each of them. If more 
> >>> than one
> >>> +port is present on a device or more than one link is connected to a 
> >>> port, a
> >>> +common scheme, using "#address-cells," "#size-cells" and "reg" 
> >>> properties is
> >>> +used.
> >>> +
> >>> +Optional link properties:
> >>> +- remote: phandle to the other endpoint link DT node.
> >>
> >> This name is a little vague. Perhaps "endpoint" would be better.
> > 
> > "endpoint" can also refer to something local like in USB case. Maybe 
> > rather the description of the "remote" property should be improved?
> 
> remote-endpoint?

Sorry, I really don't want to pull in yet another term here. We've got 
ports and links already, now you're proposing to also use "endpoind." 
Until now everyone was happy with "remote," any more opinions on this?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform data

[Tomasz Stanislawski]

Hi Rahul Sharma,

On 10/04/2012 05:18 PM, Rahul Sharma wrote:
> From: Tomasz Stanislawski 
> 
> This patch extends s5p-hdmi platform data by a GPIO identifier for
> Hot-Plug-Detection pin.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 

Acked-by: Tomasz Stanislawski 

Regards,
Tomasz Stanislawski

> ---
>  include/media/s5p_hdmi.h |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
> index 361a751..181642b 100644
> --- a/include/media/s5p_hdmi.h
> +++ b/include/media/s5p_hdmi.h
> @@ -20,6 +20,7 @@ struct i2c_board_info;
>   * @hdmiphy_info: template for HDMIPHY I2C device
>   * @mhl_bus: controller id for MHL control bus
>   * @mhl_info: template for MHL I2C device
> + * @hpd_gpio: GPIO for Hot-Plug-Detect pin
>   *
>   * NULL pointer for *_info fields indicates that
>   * the corresponding chip is not present
> @@ -29,6 +30,7 @@ struct s5p_hdmi_platform_data {
>   struct i2c_board_info *hdmiphy_info;
>   int mhl_bus;
>   struct i2c_board_info *mhl_info;
> + int hpd_gpio;
>  };
>  
>  #endif /* S5P_HDMI_H */
> 

[PATCHv9 00/25] Integration of videobuf2 with DMABUF

[Hans Verkuil]

On Tue October 2 2012 16:27:11 Tomasz Stanislawski wrote:
> Hello everyone,
> This patchset adds support for DMABUF [2] importing and exporting to V4L2
> stack.

Hi Tomasz,

Thanks for this patch series! I've finished reviewing it, and only found minor
things. The only (minor) API issue I found is in patch 18 where I would suggest
that reordering the fields will make things a bit more natural.

For patches 1, 3, 4, 5, 6, 7, 8, 10, 11, 12, 13, 14, 15, 16, 19, 20, 21, 22,
23, 24, 25:

Acked-by: Hans Verkuil 

After fixing the typos you can also add my Acked-by for patch 9.

Regards,

Hans

> v9:
> - rebase on 3.6
> - change type for fs to __s32
> - add support for vb2_ioctl_expbuf
> - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING',
>   it will be posted as a separate patch
> - fix typos and style in Documentation (from Hans Verkuil)
> - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig
> - use data_offset and length while queueing DMABUF
> - return the most recently used fd at VIDIOC_DQBUF
> - use (buffer-type, index, plane) tuple instead of mem_offset
>   to identify a for exporting (from Hans Verkuil)
> - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart)
> - add testing alignment of vaddr and size while verifying userptr
>   against DMA capabilities (from Laurent Pinchart)
> - substitute VM_DONTDUMP with VM_RESERVED
> - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart)
> 
> v8:
> - rebased on 3.6-rc1
> - merged importer and exporter patchsets
> - fixed missing fields in v4l2_plane32 and v4l2_buffer32 structs
> - fixed typos/style in documentation
> - significant reduction of warnings from checkpatch.pl
> - fixed STREAMOFF issues reported by Dima Zavin [4] by adding
>   __vb2_dqbuf helper to vb2-core
> - DC fails if userptr is not correctly aligned
> - add support for DMA attributes in DC
> - add support for buffers with no kernel mapping
> - add reference counting on device from allocator context
> - dummy support for mmap
> - use dma_get_sgtable, drop vb2_dc_kaddr_to_pages hack and
>   vb2_dc_get_base_sgt helper
> 
> v7:
> - support for V4L2_MEMORY_DMABUF in v4l2-compact-ioctl32.c
> - cosmetic fixes to the documentation
> - added importing for vmalloc because vmap support in dmabuf for 3.5
>   was pull-requested
> - support for dmabuf importing for VIVI
> - resurrect allocation of dma-contig context
> - remove reference of alloc_ctx in dma-contig buffer
> - use sg_alloc_table_from_pages
> - fix DMA scatterlist calls to use orig_nents instead of nents
> - fix memleak in vb2_dc_sgt_foreach_page (use orig_nents instead of nents)
> 
> v6:
> - fixed missing entry in v4l2_memory_names
> - fixed a bug occuring after get_user_pages failure
> - fixed a bug caused by using invalid vma for get_user_pages
> - prepare/finish no longer call dma_sync for dmabuf buffers
> 
> v5:
> - removed change of importer/exporter behaviour
> - fixes vb2_dc_pages_to_sgt basing on Laurent's hints
> - changed pin/unpin words to lock/unlock in Doc
> 
> v4:
> - rebased on mainline 3.4-rc2
> - included missing importing support for s5p-fimc and s5p-tv
> - added patch for changing map/unmap for importers
> - fixes to Documentation part
> - coding style fixes
> - pairing {map/unmap}_dmabuf in vb2-core
> - fixing variable types and semantic of arguments in videobufb2-dma-contig.c
> 
> v3:
> - rebased on mainline 3.4-rc1
> - split 'code refactor' patch to multiple smaller patches
> - squashed fixes to Sumit's patches
> - patchset is no longer dependant on 'DMA mapping redesign'
> - separated path for handling IO and non-IO mappings
> - add documentation for DMABUF importing to V4L
> - removed all DMABUF exporter related code
> - removed usage of dma_get_pages extension
> 
> v2:
> - extended VIDIOC_EXPBUF argument from integer memoffset to struct
>   v4l2_exportbuffer
> - added patch that breaks DMABUF spec on (un)map_atachment callcacks but 
> allows
>   to work with existing implementation of DMABUF prime in DRM
> - all dma-contig code refactoring patches were squashed
> - bugfixes
> 
> v1: List of changes since [1].
> - support for DMA api extension dma_get_pages, the function is used to 
> retrieve
>   pages used to create DMA mapping.
> - small fixes/code cleanup to videobuf2
> - added prepare and finish callbacks to vb2 allocators, it is used keep
>   consistency between dma-cpu acess to the memory (by Marek Szyprowski)
> - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated 
> from
>   [3].
> - support for dma-buf exporting in vb2-dma-contig allocator
> - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers,
>   originated from [3]
> - changed handling for userptr buffers (by Marek Szyprowski, Andrzej
>   Pietrasiewicz)
> - let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski)
> 
> [1] 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42966/focus=42968
> [2] 

[PATCHv9 18/25] v4l: add buffer exporting via dmabuf

[Hans Verkuil]

On Tue October 2 2012 16:27:29 Tomasz Stanislawski wrote:
> This patch adds extension to V4L2 api. It allow to export a mmap buffer as 
> file
> descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by
> mmap and return a file descriptor on success.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/media/video/v4l2-compat-ioctl32.c |1 +
>  drivers/media/video/v4l2-dev.c|1 +
>  drivers/media/video/v4l2-ioctl.c  |   10 ++
>  include/linux/videodev2.h |   28 
>  include/media/v4l2-ioctl.h|2 ++
>  5 files changed, 42 insertions(+)
> 
> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c 
> b/drivers/media/video/v4l2-compat-ioctl32.c
> index f0b5aba..8788000 100644
> --- a/drivers/media/video/v4l2-compat-ioctl32.c
> +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> @@ -971,6 +971,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int 
> cmd, unsigned long arg)
>   case VIDIOC_S_FBUF32:
>   case VIDIOC_OVERLAY32:
>   case VIDIOC_QBUF32:
> + case VIDIOC_EXPBUF:
>   case VIDIOC_DQBUF32:
>   case VIDIOC_STREAMON32:
>   case VIDIOC_STREAMOFF32:
> diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
> index 07aeafc..c43127c 100644
> --- a/drivers/media/video/v4l2-dev.c
> +++ b/drivers/media/video/v4l2-dev.c
> @@ -638,6 +638,7 @@ static void determine_valid_ioctls(struct video_device 
> *vdev)
>   SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
>   SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
>   SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf);
> + SET_VALID_IOCTL(ops, VIDIOC_EXPBUF, vidioc_expbuf);
>   SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf);
>   SET_VALID_IOCTL(ops, VIDIOC_OVERLAY, vidioc_overlay);
>   SET_VALID_IOCTL(ops, VIDIOC_G_FBUF, vidioc_g_fbuf);
> diff --git a/drivers/media/video/v4l2-ioctl.c 
> b/drivers/media/video/v4l2-ioctl.c
> index dffd3c9..f3ec8c0 100644
> --- a/drivers/media/video/v4l2-ioctl.c
> +++ b/drivers/media/video/v4l2-ioctl.c
> @@ -458,6 +458,15 @@ static void v4l_print_buffer(const void *arg, bool 
> write_only)
>   tc->type, tc->flags, tc->frames, *(__u32 
> *)tc->userbits);
>  }
>  
> +static void v4l_print_exportbuffer(const void *arg, bool write_only)
> +{
> + const struct v4l2_exportbuffer *p = arg;
> +
> + pr_cont("fd=%d, type=%s, index=%u, plane=%u, flags=0x%08x\n",
> + p->fd, prt_names(p->type, v4l2_type_names),
> + p->index, p->plane, p->flags);
> +}
> +
>  static void v4l_print_create_buffers(const void *arg, bool write_only)
>  {
>   const struct v4l2_create_buffers *p = arg;
> @@ -1947,6 +1956,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
>   IOCTL_INFO_STD(VIDIOC_S_FBUF, vidioc_s_fbuf, v4l_print_framebuffer, 
> INFO_FL_PRIO),
>   IOCTL_INFO_STD(VIDIOC_OVERLAY, vidioc_overlay, v4l_print_u32, 
> INFO_FL_PRIO),
>   IOCTL_INFO_FNC(VIDIOC_QBUF, v4l_qbuf, v4l_print_buffer, INFO_FL_QUEUE),
> + IOCTL_INFO_STD(VIDIOC_EXPBUF, vidioc_expbuf, v4l_print_exportbuffer, 0),

This needs the INFO_FL_QUEUE flag, that way this call is serialized
with the other queuing ioctls.

You can also add INFO_FL_CLEAR(v4l2_expbuf, flags). This assumes a field order
in the struct as given in my comment below. The FL_CLEAR flag will zero all
fields after 'flags'.

>   IOCTL_INFO_FNC(VIDIOC_DQBUF, v4l_dqbuf, v4l_print_buffer, 
> INFO_FL_QUEUE),
>   IOCTL_INFO_FNC(VIDIOC_STREAMON, v4l_streamon, v4l_print_buftype, 
> INFO_FL_PRIO | INFO_FL_QUEUE),
>   IOCTL_INFO_FNC(VIDIOC_STREAMOFF, v4l_streamoff, v4l_print_buftype, 
> INFO_FL_PRIO | INFO_FL_QUEUE),
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index e04a73e..f429b6a 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -688,6 +688,33 @@ struct v4l2_buffer {
>  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
>  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
>  
> +/**
> + * struct v4l2_exportbuffer - export of video buffer as DMABUF file 
> descriptor
> + *
> + * @fd:  file descriptor associated with DMABUF (set by driver)
> + * @flags:   flags for newly created file, currently only O_CLOEXEC is
> + *   supported, refer to manual of open syscall for more details
> + * @index:   id number of the buffer
> + * @type:enum v4l2_buf_type; buffer type (type == *_MPLANE for
> + *   multiplanar buffers);
> + * @plane:   index of the plane to be exported, 0 for single plane queues
> + *
> + * Contains data used for exporting a video buffer as DMABUF file descriptor.
> + * The buffer is identified by a 'cookie' returned by VIDIOC_QUERYBUF
> + * (identical to the cookie used to mmap() the buffer to userspace). All
> + * reserved fields must be set to zero. The field reserved0 is expected to
> + * become a structure 'type' 

[PATCHv9 17/25] Documentation: media: description of DMABUF exporting in V4L2

[Hans Verkuil]

More stylistic comments and a suggestion for re-ordering the fields in the 
expbuf struct.

On Tue October 2 2012 16:27:28 Tomasz Stanislawski wrote:
> This patch adds description and usage examples for exporting
> DMABUF file descriptor in V4L2.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 
> CC: linux-doc at vger.kernel.org
> ---
>  Documentation/DocBook/media/v4l/compat.xml|3 +
>  Documentation/DocBook/media/v4l/io.xml|3 +
>  Documentation/DocBook/media/v4l/v4l2.xml  |1 +
>  Documentation/DocBook/media/v4l/vidioc-expbuf.xml |  212 
> +
>  4 files changed, 219 insertions(+)
>  create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml
> 
> diff --git a/Documentation/DocBook/media/v4l/compat.xml 
> b/Documentation/DocBook/media/v4l/compat.xml
> index a46f95b..f0512aa 100644
> --- a/Documentation/DocBook/media/v4l/compat.xml
> +++ b/Documentation/DocBook/media/v4l/compat.xml
> @@ -2625,6 +2625,9 @@ ioctls.
> Importing DMABUF file descriptors as a new IO method described
> in .
>  
> +
> +   Exporting DMABUF files using  ioctl.
> +
>
>  
>  
> diff --git a/Documentation/DocBook/media/v4l/io.xml 
> b/Documentation/DocBook/media/v4l/io.xml
> index 5b58657..476f448 100644
> --- a/Documentation/DocBook/media/v4l/io.xml
> +++ b/Documentation/DocBook/media/v4l/io.xml
> @@ -488,6 +488,9 @@ DMA buffer from userspace using a file descriptor 
> previously exported for a
>  different or the same device (known as the importer role), or both. This
>  section describes the DMABUF importer role API in V4L2.
>  
> +Refer to  DMABUF exporting  for
> +details about exporting a V4L2 buffers as DMABUF file descriptors.

"exporting a" -> "exporting"

> +
>  Input and output devices support the streaming I/O method when the
>  V4L2_CAP_STREAMING flag in the
>  capabilities field of  returned 
> by
> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
> b/Documentation/DocBook/media/v4l/v4l2.xml
> index eee6908..d8c2597 100644
> --- a/Documentation/DocBook/media/v4l/v4l2.xml
> +++ b/Documentation/DocBook/media/v4l/v4l2.xml
> @@ -543,6 +543,7 @@ and discussions on the V4L mailing list.
>  
>  
>  
> +
>  
>  
>  
> diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml 
> b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
> new file mode 100644
> index 000..bf28e7d
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
> @@ -0,0 +1,212 @@
> +
> +
> +  
> +ioctl VIDIOC_EXPBUF
> +
> +  
> +
> +  
> +VIDIOC_EXPBUF
> +Export a buffer as a DMABUF file descriptor.
> +  
> +
> +  
> +
> +  
> + int ioctl
> + int fd
> + int request
> + struct v4l2_exportbuffer 
> *argp
> +  
> +
> +  
> +
> +  
> +Arguments
> +
> +
> +  
> + fd
> + 
> +   
> + 
> +  
> +  
> + request
> + 
> +   VIDIOC_EXPBUF
> + 
> +  
> +  
> + argp
> + 
> +   
> + 
> +  
> +
> +  
> +
> +  
> +Description
> +
> +
> +  Experimental
> +  This is an  experimental 
> +  interface and may change in the future.
> +
> +
> +This ioctl is an extension to the memory
> +mapping I/O method therefore it is available only for

"method therefore" -> "method, therefore"

> +V4L2_MEMORY_MMAP buffers.  It can be used to export a
> +buffer as a DMABUF file at any time after buffers have been allocated with 
> the
> + ioctl.
> +
> + To export a buffer, applicationis fill .  The

applicationis -> applications

> + type  field is set to the same buffer type as was
> +previously used with   type .
> +Applications must also set the  index  field. 
> Valid
> +index numbers range from zero to the number of buffers allocated with
> + ( count )
> +minus one.  For multi plane API, applications set the  plane

"multi plane" -> "the multi-planar"

> + field to the index of the plane to be exported. Valid planes
> +range from zero to the maximal number of valid planes for currently active

"for" -> "for the"

> +format. For single plane API, applications must set  plane

"single plane" -> "the single-planar"

> + to zero.  Additional flags may be posted in the 
> +flags  field.  Refer to a manual for open() for details.
> +Currently only O_CLOEXEC is supported.  All other fields must be set to zero.
> +In a case of multi-planar API, every plane is exported separately using

"a case of" -> "the case of the"

> +multiple  VIDIOC_EXPBUF  calls. 
> +
> + After calling VIDIOC_EXPBUF the  fd
> + field will be set by a driver.  This is a DMABUF file
> +descriptor. The application may pass it to other API. Refer to  "APIs"

or alternatively (and I like that better):

"API" -> "DMABUF-aware devices"

> +linkend="dmabuf">DMABUF importing for details about importing DMABUF
> +files into V4L2 nodes. A developer is encouraged to close a DMABUF 

[PATCH] drm/radeon: allocate PPLLs from low to high

[alexdeuc...@gmail.com]

From: Alex Deucher 

The order shouldn't matter, but there have been problems
reported on certain older asics.  This behaves more
like the original code before the PPLL allocation
rework.

Signed-off-by: Alex Deucher 
Cc:  Markus Trippelsdorf 
---
 drivers/gpu/drm/radeon/atombios_crtc.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 96184d0..2e566e1 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1690,10 +1690,10 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
}
/* all other cases */
pll_in_use = radeon_get_pll_use_mask(crtc);
-   if (!(pll_in_use & (1 << ATOM_PPLL2)))
-   return ATOM_PPLL2;
if (!(pll_in_use & (1 << ATOM_PPLL1)))
return ATOM_PPLL1;
+   if (!(pll_in_use & (1 << ATOM_PPLL2)))
+   return ATOM_PPLL2;
DRM_ERROR("unable to allocate a PPLL\n");
return ATOM_PPLL_INVALID;
} else {
@@ -1715,10 +1715,10 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
}
/* all other cases */
pll_in_use = radeon_get_pll_use_mask(crtc);
-   if (!(pll_in_use & (1 << ATOM_PPLL2)))
-   return ATOM_PPLL2;
if (!(pll_in_use & (1 << ATOM_PPLL1)))
return ATOM_PPLL1;
+   if (!(pll_in_use & (1 << ATOM_PPLL2)))
+   return ATOM_PPLL2;
DRM_ERROR("unable to allocate a PPLL\n");
return ATOM_PPLL_INVALID;
} else {
-- 
1.7.7.5

Monitor sync out of range with current Linux git tree

[Alex Deucher]

On Fri, Oct 5, 2012 at 10:15 AM, Markus Trippelsdorf
 wrote:
> On 2012.10.05 at 10:02 -0400, Alex Deucher wrote:
>> On Fri, Oct 5, 2012 at 9:38 AM, Markus Trippelsdorf
>>  wrote:
>> > On 2012.10.05 at 09:14 -0400, Alex Deucher wrote:
>> >> On Fri, Oct 5, 2012 at 8:37 AM, Markus Trippelsdorf
>> >>  wrote:
>> >> > When I cold start my machine I see the following error message on my
>> >> > monitor:
>> >> >
>> >> >  Out of Range
>> >> >  48.2kHz / 44Hz
>> >> >
>> >> > I have to reboot on older kernel and kexec to the current one to get it
>> >> > working again.
>> >>
>> >> I don't see anything amiss; can you bisect?
>> >
>> > Yes. It's your commit:
>> >
>> > commit 9dbbcfc6894957fdbb311ba92c85c026659878b5
>> > Author: Alex Deucher 
>> > Date:   Wed Sep 12 17:39:57 2012 -0400
>> >
>> > drm/radeon/dce3: use a single PPLL for all DP displays
>>
>> Can you apply the attached patch and send me the output?
>
> [drm] == start crtc 0 driving DVI-D-1 ==
> [drm] crtc 0 is not DP
> [drm] plls in use 0x0
> [drm] crtc 0 using pll 0x1
> [drm] == end crtc 0 ==

Does the attached patch fix the issue?

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-allocate-PPLLs-from-low-to-high.patch
Type: text/x-diff
Size: 1661 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121005/8307ab7d/attachment.patch>

[PATCHv9 09/25] v4l: vb2: add prepare/finish callbacks to allocators

[Hans Verkuil]

Some small typos...

On Tue October 2 2012 16:27:20 Tomasz Stanislawski wrote:
> From: Marek Szyprowski 
> 
> This patch adds support for prepare/finish callbacks in VB2 allocators. These
> callback are used for buffer flushing.
> 
> Signed-off-by: Marek Szyprowski 
> Acked-by: Laurent Pinchart 
> ---
>  drivers/media/video/videobuf2-core.c |   11 +++
>  include/media/videobuf2-core.h   |7 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/media/video/videobuf2-core.c 
> b/drivers/media/video/videobuf2-core.c
> index 901bc56..05da3b4 100644
> --- a/drivers/media/video/videobuf2-core.c
> +++ b/drivers/media/video/videobuf2-core.c
> @@ -844,6 +844,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
> vb2_buffer_state state)
>  {
>   struct vb2_queue *q = vb->vb2_queue;
>   unsigned long flags;
> + unsigned int plane;
>  
>   if (vb->state != VB2_BUF_STATE_ACTIVE)
>   return;
> @@ -854,6 +855,10 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
> vb2_buffer_state state)
>   dprintk(4, "Done processing on buffer %d, state: %d\n",
>   vb->v4l2_buf.index, vb->state);
>  
> + /* sync buffers */
> + for (plane = 0; plane < vb->num_planes; ++plane)
> + call_memop(q, finish, vb->planes[plane].mem_priv);
> +
>   /* Add the buffer to the done buffers list */
>   spin_lock_irqsave(>done_lock, flags);
>   vb->state = state;
> @@ -1148,9 +1153,15 @@ err:
>  static void __enqueue_in_driver(struct vb2_buffer *vb)
>  {
>   struct vb2_queue *q = vb->vb2_queue;
> + unsigned int plane;
>  
>   vb->state = VB2_BUF_STATE_ACTIVE;
>   atomic_inc(>queued_count);
> +
> + /* sync buffers */
> + for (plane = 0; plane < vb->num_planes; ++plane)
> + call_memop(q, prepare, vb->planes[plane].mem_priv);
> +
>   q->ops->buf_queue(vb);
>  }
>  
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index 84f11f2..c306fec 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -56,6 +56,10 @@ struct vb2_fileio_data;
>   *   dmabuf
>   * @unmap_dmabuf: releases access control to the dmabuf - allocator is 
> notified
>   * that this driver is done using the dmabuf for now
> + * @prepare: called everytime the buffer is passed from userspace to the
> + *   driver, usefull for cache synchronisation, optional

everytime -> every time
usefull -> useful

> + * @finish:  called everytime the buffer is passed back from the driver

everytime -> every time

> + *   to the userspace, also optional
>   * @vaddr:   return a kernel virtual address to a given memory buffer
>   *   associated with the passed private structure or NULL if no
>   *   such mapping exists
> @@ -82,6 +86,9 @@ struct vb2_mem_ops {
>   unsigned long size, int write);
>   void(*put_userptr)(void *buf_priv);
>  
> + void(*prepare)(void *buf_priv);
> + void(*finish)(void *buf_priv);
> +
>   void*(*attach_dmabuf)(void *alloc_ctx, struct dma_buf *dbuf,
>   unsigned long size, int write);
>   void(*detach_dmabuf)(void *buf_priv);
> 

[PATCH 1/2 v6] of: add helper to parse display timings

[Stephen Warren]

On 10/05/2012 10:16 AM, Steffen Trumtrar wrote:
> On Thu, Oct 04, 2012 at 12:47:16PM -0600, Stephen Warren wrote:
>> On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
...
>>> +   for_each_child_of_node(timings_np, entry) {
>>> +   struct signal_timing *st;
>>> +
>>> +   st = of_get_display_timing(entry);
>>> +
>>> +   if (!st)
>>> +   continue;
>>
>> I wonder if that shouldn't be an error?
> 
> In the sense of a pr_err not a -EINVAL I presume?! It is a little bit quiet in
> case of a faulty spec, that is right.

I did mean return an error; if we try to parse something and can't,
shouldn't we return an error?

I suppose it may be possible to limp on and use whatever subset of modes
could be parsed and drop the others, which is what this code does, but
the code after the loop would definitely return an error if zero timings
were parseable.

[PATCH 1/2 v6] of: add helper to parse display timings

[Stephen Warren]

On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
> Hi Steffen
> 
> Sorry for chiming in so late in the game, but I've long been wanting to 
> have a look at this and compare with what we do for V4L2, so, this seems a 
> great opportunity to me:-)
> 
> On Thu, 4 Oct 2012, Steffen Trumtrar wrote:

>> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
>> b/Documentation/devicetree/bindings/video/display-timings.txt

>> +timings-subnode
>> +---
>> +
>> +required properties:
>> + - hactive, vactive: Display resolution
>> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing 
>> parameters
>> +   in pixels
>> +   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters 
>> in
>> +   lines
>> + - clock: displayclock in Hz
> 
> You're going to hate me for this, but eventually we want to actually 
> reference clock objects in our DT bindings. For now, even if you don't 
> want to actually add clock phandles and stuff here, I think, using the 
> standard "clock-frequency" property would be much better!

In a definition of a display timing, we will never need to use the clock
binding; the clock binding would be used by the HW module that is
generating a timing, not by the timing definition itself.

That said, your comment about renaming the property to avoid any kind of
conceptual conflict is still quite valid. This is bike-shedding, but
"pixel-clock" might be more in line with typical video mode terminology,
although there's certainly preference in DT for using the generic term
clock-frequency that you proposed. Either is fine by me.

>> +optional properties:
>> + - hsync-active-high (bool): Hsync pulse is active high
>> + - vsync-active-high (bool): Vsync pulse is active high
> 
> For the above two we also considered using bool properties but eventually 
> settled down with integer ones:
> 
> - hsync-active = <1>
> 
> for active-high and 0 for active low. This has the added advantage of 
> being able to omit this property in the .dts, which then doesn't mean, 
> that the polarity is active low, but rather, that the hsync line is not 
> used on this hardware. So, maybe it would be good to use the same binding 
> here too?

I agree. This also covers the case where analog display connectors often
use polarity to differentiate similar modes, yet digital connectors
often always use a fixed polarity since the receiving device can
"measure" the signal in more complete ways.

If the board HW inverts these lines, the same property names can exist
in the display controller itself, and the two values XORd together to
yield the final output polarity.

>> + - de-active-high (bool): Data-Enable pulse is active high
>> + - pixelclk-inverted (bool): pixelclock is inverted
> 
> We don't (yet) have a de-active property in V4L, don't know whether we'll 
> ever have to distingsuish between what some datasheets call "HREF" and 
> HSYNC in DT, but maybe similarly to the above an integer would be 
> preferred. As for pixclk, we call the property "pclk-sample" and it's also 
> an integer.

Thinking about this more: de-active-high is likely to be a
board-specific property and hence something in the display controller,
not in the mode definition?

>> + - interlaced (bool)
> 
> Is "interlaced" a property of the hardware, i.e. of the board? Can the 
> same display controller on one board require interlaced data and on 
> another board - progressive?

Interlace is a property of a display mode. It's quite possible for a
particular display controller to switch between interlace and
progressive output at run-time. For example, reconfiguring the output
between 480i, 720p, 1080i, 1080p modes. Admittedly, if you're talking to
a built-in LCD display, you're probably always going to be driving the
single mode required by the panel, and that mode will likely always be
progressive. However, since this binding attempts to describe any
display timing, I think we still need this property per mode.

> BTW, I'm not very familiar with display 
> interfaces, but for interlaced you probably sometimes use a field signal, 
> whose polarity you also want to specify here? We use a "field-even-active" 
> integer property for it.

I think that's a property of the display controller itself, rather than
an individual mode, although I'm not 100% certain. My assertion is that
the physical interface that the display controller is driving will
determine whether embedded or separate sync is used, and in the separate
sync case, how the field signal is defined, and that all interlace modes
driven over that interface will use the same field signal definition.

[PATCHv9 03/25] v4l: vb2: add support for shared buffer (dma_buf)

[Hans Verkuil]

Just a small heads-up for an upcoming change...

On Tue October 2 2012 16:27:14 Tomasz Stanislawski wrote:
> From: Sumit Semwal 
> 
> This patch adds support for DMABUF memory type in videobuf2. It calls relevant
> APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
> 
> For this version, the support is for videobuf2 as a user of the shared buffer;
> so the allocation of the buffer is done outside of V4L2. [A sample allocator 
> of
> dma-buf shared buffer is given at [1]]
> 
> [1]: Rob Clark's DRM:
>https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf
> 
> Signed-off-by: Tomasz Stanislawski 
>[original work in the PoC for buffer sharing]
> Signed-off-by: Sumit Semwal 
> Signed-off-by: Sumit Semwal 
> Acked-by: Laurent Pinchart 
> ---
>  drivers/media/video/Kconfig  |1 +
>  drivers/media/video/videobuf2-core.c |  207 
> +-
>  include/media/videobuf2-core.h   |   27 +
>  3 files changed, 232 insertions(+), 3 deletions(-)
> 



> @@ -970,6 +1040,109 @@ static int __qbuf_mmap(struct vb2_buffer *vb, const 
> struct v4l2_buffer *b)
>  }
>  
>  /**
> + * __qbuf_dmabuf() - handle qbuf of a DMABUF buffer
> + */
> +static int __qbuf_dmabuf(struct vb2_buffer *vb, const struct v4l2_buffer *b)
> +{
> + struct v4l2_plane planes[VIDEO_MAX_PLANES];
> + struct vb2_queue *q = vb->vb2_queue;
> + void *mem_priv;
> + unsigned int plane;
> + int ret;
> + int write = !V4L2_TYPE_IS_OUTPUT(q->type);
> +
> + /* Verify and copy relevant information provided by the userspace */
> + ret = __fill_vb2_buffer(vb, b, planes);

Note that this code will have to change a bit when my multiplanar fixes go in:

http://www.spinics.net/lists/linux-media/msg54601.html

__fill_vb2_buffer is now a void function, so there won't be any need to check
the error.

> + if (ret)
> + return ret;
> +
> + for (plane = 0; plane < vb->num_planes; ++plane) {
> + struct dma_buf *dbuf = dma_buf_get(planes[plane].m.fd);
> +
> + if (IS_ERR_OR_NULL(dbuf)) {
> + dprintk(1, "qbuf: invalid dmabuf fd for plane %d\n",
> + plane);
> + ret = -EINVAL;
> + goto err;
> + }
> +
> + /* use DMABUF size if length is not provided */
> + if (planes[plane].length == 0)
> + planes[plane].length = dbuf->size;
> +
> + if (planes[plane].length < planes[plane].data_offset +
> + q->plane_sizes[plane]) {
> + ret = -EINVAL;
> + goto err;
> + }
> +
> + /* Skip the plane if already verified */
> + if (dbuf == vb->planes[plane].dbuf &&
> + vb->v4l2_planes[plane].length == planes[plane].length) {
> + dma_buf_put(dbuf);
> + continue;
> + }
> +
> + dprintk(1, "qbuf: buffer for plane %d changed\n", plane);
> +
> + /* Release previously acquired memory if present */
> + __vb2_plane_dmabuf_put(q, >planes[plane]);
> + memset(>v4l2_planes[plane], 0, sizeof(struct v4l2_plane));
> +
> + /* Acquire each plane's memory */
> + mem_priv = call_memop(q, attach_dmabuf, q->alloc_ctx[plane],
> + dbuf, planes[plane].length, write);
> + if (IS_ERR(mem_priv)) {
> + dprintk(1, "qbuf: failed to attach dmabuf\n");
> + ret = PTR_ERR(mem_priv);
> + dma_buf_put(dbuf);
> + goto err;
> + }
> +
> + vb->planes[plane].dbuf = dbuf;
> + vb->planes[plane].mem_priv = mem_priv;
> + }
> +
> + /* TODO: This pins the buffer(s) with  dma_buf_map_attachment()).. but
> +  * really we want to do this just before the DMA, not while queueing
> +  * the buffer(s)..
> +  */
> + for (plane = 0; plane < vb->num_planes; ++plane) {
> + ret = call_memop(q, map_dmabuf, vb->planes[plane].mem_priv);
> + if (ret) {
> + dprintk(1, "qbuf: failed to map dmabuf for plane %d\n",
> + plane);
> + goto err;
> + }
> + vb->planes[plane].dbuf_mapped = 1;
> + }
> +
> + /*
> +  * Call driver-specific initialization on the newly acquired buffer,
> +  * if provided.
> +  */
> + ret = call_qop(q, buf_init, vb);
> + if (ret) {
> + dprintk(1, "qbuf: buffer initialization failed\n");
> + goto err;
> + }
> +
> + /*
> +  * Now that everything is in order, copy relevant information
> +  * provided by userspace.
> +  */
> + for (plane = 0; plane < vb->num_planes; ++plane)
> + vb->v4l2_planes[plane] = planes[plane];
> +
> + return 0;
> +err:
> + /* In case of 

[PATCHv9 02/25] Documentation: media: description of DMABUF importing in V4L2

[Hans Verkuil]

Hi Tomasz,

Just a few more stylistic issues...

On Tue October 2 2012 16:27:13 Tomasz Stanislawski wrote:
> This patch adds description and usage examples for importing
> DMABUF file descriptor in V4L2.
> 
> Signed-off-by: Tomasz Stanislawski 
> Signed-off-by: Kyungmin Park 
> CC: linux-doc at vger.kernel.org
> ---
>  Documentation/DocBook/media/v4l/compat.xml |4 +
>  Documentation/DocBook/media/v4l/io.xml |  180 
> +++-
>  .../DocBook/media/v4l/vidioc-create-bufs.xml   |   16 +-
>  Documentation/DocBook/media/v4l/vidioc-qbuf.xml|   17 ++
>  Documentation/DocBook/media/v4l/vidioc-reqbufs.xml |   47 ++---
>  5 files changed, 234 insertions(+), 30 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/compat.xml 
> b/Documentation/DocBook/media/v4l/compat.xml
> index faa0fd1..a46f95b 100644
> --- a/Documentation/DocBook/media/v4l/compat.xml
> +++ b/Documentation/DocBook/media/v4l/compat.xml
> @@ -2621,6 +2621,10 @@ ioctls.
>  
> Support for frequency band enumeration: 
>  ioctl.
>  
> +
> +   Importing DMABUF file descriptors as a new IO method described
> +   in .
> +
>
>  
>  
> diff --git a/Documentation/DocBook/media/v4l/io.xml 
> b/Documentation/DocBook/media/v4l/io.xml
> index 1885cc0..5b58657 100644
> --- a/Documentation/DocBook/media/v4l/io.xml
> +++ b/Documentation/DocBook/media/v4l/io.xml
> @@ -331,7 +331,7 @@ application until one or more buffers can be dequeued. By 
> default
>  outgoing queue. When the O_NONBLOCK flag was
>  given to the  function, VIDIOC_DQBUF
>  returns immediately with an  when no buffer is available. The
> - or  function are always available.
> + or  functions are always available.
>  
>  To start and stop capturing or output applications call the
>   and  ioctl. Note
> @@ -472,6 +472,161 @@ rest should be evident.
>
>
>  
> +  
> +Streaming I/O (DMA buffer importing)
> +
> +
> +  Experimental
> +  This is an  experimental 
> +  interface and may change in the future.
> +
> +
> +The DMABUF framework provides a generic method for sharing buffers
> +between multiple devices. Device drivers that support DMABUF can export a DMA
> +buffer to userspace as a file descriptor (known as the exporter role), 
> import a
> +DMA buffer from userspace using a file descriptor previously exported for a
> +different or the same device (known as the importer role), or both. This
> +section describes the DMABUF importer role API in V4L2.
> +
> +Input and output devices support the streaming I/O method when the
> +V4L2_CAP_STREAMING flag in the
> +capabilities field of  returned 
> by
> +the  ioctl is set. Whether importing DMA buffers through
> +DMABUF file descriptors is supported is determined by calling the
> + ioctl with the memory type set to
> +V4L2_MEMORY_DMABUF.
> +
> +This I/O method is dedicated for sharing DMA buffers between V4L 
> and
> +other APIs.

It's more accurate to say something along the lines of: "...is dedicated to 
sharing
DMA buffers between different devices, which may be V4L devices or other
video-related devices (e.g. DRM)."

One of the uses of this API is to share buffers between different V4L devices, 
so
that's a bit more generic than the original sentence suggests.

> Buffers (planes) are allocated by a driver on behalf of an
> +application. Next, these buffers are exported to the application as file
> +descriptors using an API which is specific for an allocator driver.  Only 
> such
> +file descriptor are exchanged. The descriptors and meta-information are 
> passed
> +in  (or in  in the multi-planar API case).  The 
> driver
> +must be switched into DMABUF I/O mode by calling the  with 
> the
> +desired buffer type.
> +
> +
> +  Initiating streaming I/O with DMABUF file descriptors
> +
> +  
> + reqbuf;
> +
> +memset (reqbuf, 0, sizeof (reqbuf));

no space after memset

> +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> +reqbuf.memory = V4L2_MEMORY_DMABUF;
> +reqbuf.count = 1;
> +
> +if (ioctl (fd, , reqbuf) == -1) {

no space after ioctl

> + if (errno == EINVAL)
> + printf("Video capturing or DMABUF streaming is not 
> supported\n");
> + else
> + perror("VIDIOC_REQBUFS");
> +
> + exit(EXIT_FAILURE);
> +}
> +  
> +
> +
> +The buffer (plane) file descriptor is passed on the fly with the
> + ioctl. In case of multiplanar buffers, every plane can be
> +associated with a different DMABUF descriptor. Although buffers are commonly
> +cycled, applications can pass a different DMABUF descriptor at each
> +VIDIOC_QBUF call.
> +
> +
> +  Queueing DMABUF using single plane API
> +
> +  
> +int buffer_queue(int v4lfd, int index, int dmafd)
> +{
> +  buf;
> +
> + memset(buf, 0, sizeof buf);
> + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> + buf.memory = V4L2_MEMORY_DMABUF;
> + buf.index = index;
> + buf.m.fd = dmafd;
> +
> +  

Monitor sync out of range with current Linux git tree

[Alex Deucher]

On Fri, Oct 5, 2012 at 9:38 AM, Markus Trippelsdorf
 wrote:
> On 2012.10.05 at 09:14 -0400, Alex Deucher wrote:
>> On Fri, Oct 5, 2012 at 8:37 AM, Markus Trippelsdorf
>>  wrote:
>> > When I cold start my machine I see the following error message on my
>> > monitor:
>> >
>> >  Out of Range
>> >  48.2kHz / 44Hz
>> >
>> > I have to reboot on older kernel and kexec to the current one to get it
>> > working again.
>>
>> I don't see anything amiss; can you bisect?
>
> Yes. It's your commit:
>
> commit 9dbbcfc6894957fdbb311ba92c85c026659878b5
> Author: Alex Deucher 
> Date:   Wed Sep 12 17:39:57 2012 -0400
>
> drm/radeon/dce3: use a single PPLL for all DP displays

Can you apply the attached patch and send me the output?

Thanks,

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-pll-debug.patch
Type: text/x-diff
Size: 5374 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121005/b2cec14c/attachment.patch>

[PATCH 1/2 v6] of: add helper to parse display timings

[Robert Schwebel]

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
> > +optional properties:
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
>
> For the above two we also considered using bool properties but eventually
> settled down with integer ones:
>
> - hsync-active = <1>
>
> for active-high and 0 for active low. This has the added advantage of
> being able to omit this property in the .dts, which then doesn't mean,
> that the polarity is active low, but rather, that the hsync line is not
> used on this hardware. So, maybe it would be good to use the same binding
> here too?

Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.

rsc
-- 
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- |

No subject

[Robert Schwebel]

, pza
Bcc:
Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings
Reply-To:
In-Reply-To: 
X-Sent-From: Pengutronix Hildesheim
X-URL: http://www.pengutronix.de/
X-IRC: #ptxdist @freenode
X-Accept-Language: de,en
X-Accept-Content-Type: text/plain
X-Uptime: 09:13:09 up 103 days, 22:24, 36 users,  load average: 0,57, 0,60,
 0,61

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
> > +optional properties:
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
>
> For the above two we also considered using bool properties but eventually
> settled down with integer ones:
>
> - hsync-active = <1>
>
> for active-high and 0 for active low. This has the added advantage of
> being able to omit this property in the .dts, which then doesn't mean,
> that the polarity is active low, but rather, that the hsync line is not
> used on this hardware. So, maybe it would be good to use the same binding
> here too?

Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.

rsc
-- 
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- |

[PATCH] drm: nouveau: Fix build warning seen is HWMON is undefined

[Guenter Roeck]

Fix:

nouveau_pm.c: In function ?nouveau_hwmon_init?:
nouveau_pm.c:703:24: warning: unused variable ?therm? [-Wunused-variable]

Signed-off-by: Guenter Roeck 
---
This was seen in the latest upstream kernel.

 drivers/gpu/drm/nouveau/nouveau_pm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_pm.c 
b/drivers/gpu/drm/nouveau/nouveau_pm.c
index 0bf64c9..90dc63e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_pm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_pm.c
@@ -699,10 +699,10 @@ static int
 nouveau_hwmon_init(struct drm_device *dev)
 {
struct nouveau_pm *pm = nouveau_pm(dev);
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   struct nouveau_therm *therm = nouveau_therm(drm->device);

 #if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
+   struct nouveau_drm *drm = nouveau_drm(dev);
+   struct nouveau_therm *therm = nouveau_therm(drm->device);
struct device *hwmon_dev;
int ret = 0;

-- 
1.7.9.7

[PATCH 00/14] drm: exynos: hdmi: add dt based support for exynos5 hdmi

[RAHUL SHARMA]

Thanks Joonyoung,

I have addressed your comments in v1 set.
Please have a look at them.

regards,
Rahul Sharma

On Tue, Oct 2, 2012 at 1:01 PM, Joonyoung Shim  
wrote:
> Hi,
>
>
> On 09/28/2012 11:25 PM, Rahul Sharma wrote:
>>
>> This patch set adds the DT based support for Samsung's Exynos5250 in
>> DRM-HDMI.
>> It includes disabling of hdmi internal interrupt, suppport for platform
>> variants for hdmi and mixer, support to disable video processor based on
>> platform type and removal of drm common platform data.
>
>
> Looks good to me overall, i commented a bit.
>
> Thanks.
>
>
>> Rahul Sharma (9):
>>drm: exynos: remove drm hdmi platform data struct
>>drm: exynos: hdmi: add support for exynos5 ddc
>>drm: exynos: hdmi: add support for exynos5 hdmiphy
>>drm: exynos: hdmi: add support for platform variants for mixer
>>drm: exynos: hdmi: add support to disable video processor in mixer
>>drm: exynos: hdmi: add support for exynos5 mixer
>>drm: exynos: hdmi: replace is_v13 with version check in hdmi
>>drm: exynos: hdmi: add support for exynos5 hdmi
>>drm: exynos: hdmi: remove drm common hdmi platform data struct
>>
>> Tomasz Stanislawski (5):
>>media: s5p-hdmi: add HPD GPIO to platform data
>>drm: exynos: hdmi: support for platform variants
>>drm: exynos: hdmi: fix interrupt handling
>>drm: exynos: hdmi: use s5p-hdmi platform data
>>drm: exynos: hdmi: turn off HPD interrupt in HDMI chip
>>
>>   drivers/gpu/drm/exynos/exynos_ddc.c  |   22 +++-
>>   drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   51 
>>   drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +
>>   drivers/gpu/drm/exynos/exynos_hdmi.c |  196
>> ---
>>   drivers/gpu/drm/exynos/exynos_hdmiphy.c  |   12 ++-
>>   drivers/gpu/drm/exynos/exynos_mixer.c|  219
>> ++
>>   drivers/gpu/drm/exynos/regs-mixer.h  |2 +
>>   include/drm/exynos_drm.h |   27 
>>   include/media/s5p_hdmi.h |2 +
>>   9 files changed, 369 insertions(+), 164 deletions(-)
>>
>>
>

[PATCH 1/2 v6] of: add helper to parse display timings

[Guennadi Liakhovetski]

Hi Steffen

Sorry for chiming in so late in the game, but I've long been wanting to 
have a look at this and compare with what we do for V4L2, so, this seems a 
great opportunity to me:-)

On Thu, 4 Oct 2012, Steffen Trumtrar wrote:

> Signed-off-by: Steffen Trumtrar 
> ---
>  .../devicetree/bindings/video/display-timings.txt  |  222 
> 
>  drivers/of/Kconfig |5 +
>  drivers/of/Makefile|1 +
>  drivers/of/of_display_timings.c|  183 
>  include/linux/of_display_timings.h |   85 
>  5 files changed, 496 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/video/display-timings.txt
>  create mode 100644 drivers/of/of_display_timings.c
>  create mode 100644 include/linux/of_display_timings.h
> 
> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
> b/Documentation/devicetree/bindings/video/display-timings.txt
> new file mode 100644
> index 000..45e39bd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/display-timings.txt
> @@ -0,0 +1,222 @@
> +display-timings bindings
> +==
> +
> +display-timings-node
> +
> +
> +required properties:
> + - none
> +
> +optional properties:
> + - default-timing: the default timing value
> +
> +timings-subnode
> +---
> +
> +required properties:
> + - hactive, vactive: Display resolution
> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
> +   in pixels
> +   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters 
> in
> +   lines
> + - clock: displayclock in Hz

You're going to hate me for this, but eventually we want to actually 
reference clock objects in our DT bindings. For now, even if you don't 
want to actually add clock phandles and stuff here, I think, using the 
standard "clock-frequency" property would be much better!

> +
> +optional properties:
> + - hsync-active-high (bool): Hsync pulse is active high
> + - vsync-active-high (bool): Vsync pulse is active high

For the above two we also considered using bool properties but eventually 
settled down with integer ones:

- hsync-active = <1>

for active-high and 0 for active low. This has the added advantage of 
being able to omit this property in the .dts, which then doesn't mean, 
that the polarity is active low, but rather, that the hsync line is not 
used on this hardware. So, maybe it would be good to use the same binding 
here too?

> + - de-active-high (bool): Data-Enable pulse is active high
> + - pixelclk-inverted (bool): pixelclock is inverted

We don't (yet) have a de-active property in V4L, don't know whether we'll 
ever have to distingsuish between what some datasheets call "HREF" and 
HSYNC in DT, but maybe similarly to the above an integer would be 
preferred. As for pixclk, we call the property "pclk-sample" and it's also 
an integer.

> + - interlaced (bool)

Is "interlaced" a property of the hardware, i.e. of the board? Can the 
same display controller on one board require interlaced data and on 
another board - progressive? BTW, I'm not very familiar with display 
interfaces, but for interlaced you probably sometimes use a field signal, 
whose polarity you also want to specify here? We use a "field-even-active" 
integer property for it.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[no subject]

[Robert Schwebel]

tomi.valkei...@ti.com, pza
Bcc:
Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings
Reply-To:
In-Reply-To: Pine.LNX.4.64.1210042307300.3744@axis700.grange
X-Sent-From: Pengutronix Hildesheim
X-URL: http://www.pengutronix.de/
X-IRC: #ptxdist @freenode
X-Accept-Language: de,en
X-Accept-Content-Type: text/plain
X-Uptime: 09:13:09 up 103 days, 22:24, 36 users,  load average: 0,57, 0,60,
 0,61

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
  +optional properties:
  + - hsync-active-high (bool): Hsync pulse is active high
  + - vsync-active-high (bool): Vsync pulse is active high

 For the above two we also considered using bool properties but eventually
 settled down with integer ones:

 - hsync-active = 1

 for active-high and 0 for active low. This has the added advantage of
 being able to omit this property in the .dts, which then doesn't mean,
 that the polarity is active low, but rather, that the hsync line is not
 used on this hardware. So, maybe it would be good to use the same binding
 here too?

Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.

rsc
-- 
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- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2 v6] of: add helper to parse display timings

[Robert Schwebel]

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
  +optional properties:
  + - hsync-active-high (bool): Hsync pulse is active high
  + - vsync-active-high (bool): Vsync pulse is active high

 For the above two we also considered using bool properties but eventually
 settled down with integer ones:

 - hsync-active = 1

 for active-high and 0 for active low. This has the added advantage of
 being able to omit this property in the .dts, which then doesn't mean,
 that the polarity is active low, but rather, that the hsync line is not
 used on this hardware. So, maybe it would be good to use the same binding
 here too?

Philipp, this is the same argumentation as we discussed yesterday for
the dual-link LVDS option, so that one could be modelled in a similar
way.

rsc
-- 
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- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 problems with suspend to disk

[Hugo Mills]

   Hi,

   On 3.6, I've got a problem with my video driver after resuming from
suspend-to-disk: the lower part of the display flickers, rapidly but
irregularly (think of a neon sign in a bad film noir), flicking
between the correct display and... something else, it's hard to see
what.

   Shutting the lid of the machine (to trigger a suspend-to-ram) and
waking it up again fixes the flicker.

   In syslogs, I have nothing obvious on suspend, and this warning on
resume:

Oct  4 19:53:04 ruth kernel: [ 2892.184086] [ cut here ]
Oct  4 19:53:04 ruth kernel: [ 2892.184114] WARNING: at 
drivers/gpu/drm/i915/intel_display.c:1225 intel_crtc_disable+0x52/0x86 [i915]()
Oct  4 19:53:04 ruth kernel: [ 2892.184115] Hardware name: 0196CTO
Oct  4 19:53:04 ruth kernel: [ 2892.184117] pipe B assertion failure (expected 
off, current on)
Oct  4 19:53:04 ruth kernel: [ 2892.184188] Modules linked in: 
cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative rfcomm 
bnep binfmt_misc uinput nfsd auth_rpcgss nfs_acl nfs lockd fscache sunrpc ext4 
jbd2 mbcache loop arc4 iwldvm mac80211 snd_hda_codec_hdmi 
snd_hda_codec_conexant coretemp i915 snd_hda_intel snd_hda_codec drm_kms_helper 
iwlwifi snd_hwdep snd_pcm snd_page_alloc joydev snd_seq snd_seq_device 
snd_timer kvm_intel drm i2c_algo_bit thinkpad_acpi acpi_cpufreq nvram btusb 
bluetooth kvm crc16 cfg80211 microcode psmouse evdev i2c_i801 video rfkill wmi 
mperf i2c_core snd battery ac processor soundcore button btrfs crc32c libcrc32c 
zlib_deflate sha256_generic ablk_helper cryptd aes_x86_64 aes_generic cbc 
dm_crypt dm_mod sd_mod crc_t10dif ums_realtek usb_storage uas thermal 
thermal_sys ahci libahci libata uhci_hcd scsi_mod ehci_hcd r8169 mii usbcore 
usb_common
Oct  4 19:53:04 ruth kernel: [ 2892.184198] Pid: 4117, comm: kworker/u:3 Not 
tainted 3.6.0 #14
Oct  4 19:53:04 ruth kernel: [ 2892.184199] Call Trace:
Oct  4 19:53:04 ruth kernel: [ 2892.184207]  [8102bdc5] ? 
warn_slowpath_common+0x78/0x8c
Oct  4 19:53:04 ruth kernel: [ 2892.184213]  [8104afd3] ? 
async_schedule+0xc/0xc
Oct  4 19:53:04 ruth kernel: [ 2892.184216]  [8102be71] ? 
warn_slowpath_fmt+0x45/0x4a
Oct  4 19:53:04 ruth kernel: [ 2892.184221]  [8104afd3] ? 
async_schedule+0xc/0xc
Oct  4 19:53:04 ruth kernel: [ 2892.184238]  [a03fdae0] ? 
intel_crtc_disable+0x52/0x86 [i915]
Oct  4 19:53:04 ruth kernel: [ 2892.184245]  [a0273e47] ? 
drm_helper_disable_unused_functions+0xd0/0xfb [drm_kms_helper]
Oct  4 19:53:04 ruth kernel: [ 2892.184250]  [a027461e] ? 
drm_helper_resume_force_mode+0xf1/0xff [drm_kms_helper]
Oct  4 19:53:04 ruth kernel: [ 2892.184254]  [8104afd3] ? 
async_schedule+0xc/0xc
Oct  4 19:53:04 ruth kernel: [ 2892.184264]  [a03dc17f] ? 
i915_drm_thaw+0xd4/0x10b [i915]
Oct  4 19:53:04 ruth kernel: [ 2892.184274]  [a03dc4fc] ? 
i915_resume+0x3b/0x50 [i915]
Oct  4 19:53:04 ruth kernel: [ 2892.184279]  [81193f21] ? 
pci_legacy_resume+0x39/0x39
Oct  4 19:53:04 ruth kernel: [ 2892.184284]  [812196f7] ? 
dpm_run_callback.isra.5+0x26/0x54
Oct  4 19:53:04 ruth kernel: [ 2892.184289]  [81219fe1] ? 
device_resume+0xd0/0x110
Oct  4 19:53:04 ruth kernel: [ 2892.184292]  [8121a035] ? 
async_resume+0x14/0x38
Oct  4 19:53:04 ruth kernel: [ 2892.184296]  [8104b070] ? 
async_run_entry_fn+0x9d/0x175
Oct  4 19:53:04 ruth kernel: [ 2892.184300]  [81041a1a] ? 
process_one_work+0x184/0x2a3
Oct  4 19:53:04 ruth kernel: [ 2892.184304]  [810426f1] ? 
worker_thread+0x1fe/0x29f
Oct  4 19:53:04 ruth kernel: [ 2892.184307]  [810424f3] ? 
manage_workers+0x223/0x223
Oct  4 19:53:04 ruth kernel: [ 2892.184310]  [810424f3] ? 
manage_workers+0x223/0x223
Oct  4 19:53:04 ruth kernel: [ 2892.184315]  [81045adf] ? 
kthread+0x67/0x6f
Oct  4 19:53:04 ruth kernel: [ 2892.184319]  [812fe774] ? 
kernel_thread_helper+0x4/0x10
Oct  4 19:53:04 ruth kernel: [ 2892.184324]  [81045a78] ? 
kthread_freezable_should_stop+0x3c/0x3c
Oct  4 19:53:04 ruth kernel: [ 2892.184327]  [812fe770] ? 
gs_change+0xb/0xb
Oct  4 19:53:04 ruth kernel: [ 2892.184328] ---[ end trace 4e63ed9ed8ebc493 ]---

   Hardware is a Lenovo Thinkpad Edge13, lspci says:

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 07)

aka

00:02.0 0300: 8086:2a42 (rev 07)

   Let me know if you need more information. I can probably manage a
bisect if necessary -- it's easily repeatable as a bug.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- Ceci n'est pas une pipe:  | ---   


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

Re: i915 problems with suspend to disk

[Hugo Mills]

On Thu, Oct 04, 2012 at 09:31:39PM +0200, Daniel Vetter wrote:
 On Thu, Oct 04, 2012 at 08:20:17PM +0100, Hugo Mills wrote:
 On 3.6, I've got a problem with my video driver after resuming from
  suspend-to-disk: the lower part of the display flickers, rapidly but
  irregularly (think of a neon sign in a bad film noir), flicking
  between the correct display and... something else, it's hard to see
  what.
  
 Shutting the lid of the machine (to trigger a suspend-to-ram) and
  waking it up again fixes the flicker.
  
 In syslogs, I have nothing obvious on suspend, and this warning on
  resume:
[snip]
 Hardware is a Lenovo Thinkpad Edge13, lspci says:
  
  00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series 
  Chipset Integrated Graphics Controller (rev 07)
  
  aka
  
  00:02.0 0300: 8086:2a42 (rev 07)
  
 Let me know if you need more information. I can probably manage a
  bisect if necessary -- it's easily repeatable as a bug.
 
 Before you do a bisect, can you try the drm-intel-fixes branch from
 http://cgit.freedesktop.org/~danvet/drm-intel or a bit more risky, latest
 upstream git? That contains a completely rewritten modeset code, which
 might fix this already. To fix the breakage on 3.6 I guess we need a
 bisect - at least I don't have any idea off-hand what could have gone
 wrong here.

   Thank you for the quick response.

   The drm-intel-fixes branch seems to have done the trick. No more
flickering. I think we can call this one fixed.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
 --- I always felt that as a C programmer, I --- 
 was becoming typecast.  


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

Re: Re: [PATCH 00/14] drm: exynos: hdmi: add dt based support for exynos5 hdmi

[RAHUL SHARMA]

Thanks Joonyoung,

I have addressed your comments in v1 set.
Please have a look at them.

regards,
Rahul Sharma

On Tue, Oct 2, 2012 at 1:01 PM, Joonyoung Shim jy0922.s...@samsung.com wrote:
 Hi,


 On 09/28/2012 11:25 PM, Rahul Sharma wrote:

 This patch set adds the DT based support for Samsung's Exynos5250 in
 DRM-HDMI.
 It includes disabling of hdmi internal interrupt, suppport for platform
 variants for hdmi and mixer, support to disable video processor based on
 platform type and removal of drm common platform data.


 Looks good to me overall, i commented a bit.

 Thanks.


 Rahul Sharma (9):
drm: exynos: remove drm hdmi platform data struct
drm: exynos: hdmi: add support for exynos5 ddc
drm: exynos: hdmi: add support for exynos5 hdmiphy
drm: exynos: hdmi: add support for platform variants for mixer
drm: exynos: hdmi: add support to disable video processor in mixer
drm: exynos: hdmi: add support for exynos5 mixer
drm: exynos: hdmi: replace is_v13 with version check in hdmi
drm: exynos: hdmi: add support for exynos5 hdmi
drm: exynos: hdmi: remove drm common hdmi platform data struct

 Tomasz Stanislawski (5):
media: s5p-hdmi: add HPD GPIO to platform data
drm: exynos: hdmi: support for platform variants
drm: exynos: hdmi: fix interrupt handling
drm: exynos: hdmi: use s5p-hdmi platform data
drm: exynos: hdmi: turn off HPD interrupt in HDMI chip

   drivers/gpu/drm/exynos/exynos_ddc.c  |   22 +++-
   drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   51 
   drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +
   drivers/gpu/drm/exynos/exynos_hdmi.c |  196
 ---
   drivers/gpu/drm/exynos/exynos_hdmiphy.c  |   12 ++-
   drivers/gpu/drm/exynos/exynos_mixer.c|  219
 ++
   drivers/gpu/drm/exynos/regs-mixer.h  |2 +
   include/drm/exynos_drm.h |   27 
   include/media/s5p_hdmi.h |2 +
   9 files changed, 369 insertions(+), 164 deletions(-)




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

Re: [PATCHv9 02/25] Documentation: media: description of DMABUF importing in V4L2

[Hans Verkuil]

Hi Tomasz,

Just a few more stylistic issues...

On Tue October 2 2012 16:27:13 Tomasz Stanislawski wrote:
 This patch adds description and usage examples for importing
 DMABUF file descriptor in V4L2.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 CC: linux-...@vger.kernel.org
 ---
  Documentation/DocBook/media/v4l/compat.xml |4 +
  Documentation/DocBook/media/v4l/io.xml |  180 
 +++-
  .../DocBook/media/v4l/vidioc-create-bufs.xml   |   16 +-
  Documentation/DocBook/media/v4l/vidioc-qbuf.xml|   17 ++
  Documentation/DocBook/media/v4l/vidioc-reqbufs.xml |   47 ++---
  5 files changed, 234 insertions(+), 30 deletions(-)
 
 diff --git a/Documentation/DocBook/media/v4l/compat.xml 
 b/Documentation/DocBook/media/v4l/compat.xml
 index faa0fd1..a46f95b 100644
 --- a/Documentation/DocBook/media/v4l/compat.xml
 +++ b/Documentation/DocBook/media/v4l/compat.xml
 @@ -2621,6 +2621,10 @@ ioctls./para
  listitem
 paraSupport for frequency band enumeration: 
 VIDIOC-ENUM-FREQ-BANDS; ioctl./para
  /listitem
 +listitem
 +   paraImporting DMABUF file descriptors as a new IO method described
 +   in xref linkend=dmabuf /./para
 +/listitem
/itemizedlist
  /section
  
 diff --git a/Documentation/DocBook/media/v4l/io.xml 
 b/Documentation/DocBook/media/v4l/io.xml
 index 1885cc0..5b58657 100644
 --- a/Documentation/DocBook/media/v4l/io.xml
 +++ b/Documentation/DocBook/media/v4l/io.xml
 @@ -331,7 +331,7 @@ application until one or more buffers can be dequeued. By 
 default
  outgoing queue. When the constantO_NONBLOCK/constant flag was
  given to the func-open; function, constantVIDIOC_DQBUF/constant
  returns immediately with an EAGAIN; when no buffer is available. The
 -func-select; or func-poll; function are always available./para
 +func-select; or func-poll; functions are always available./para
  
  paraTo start and stop capturing or output applications call the
  VIDIOC-STREAMON; and VIDIOC-STREAMOFF; ioctl. Note
 @@ -472,6 +472,161 @@ rest should be evident./para
/footnote/para
/section
  
 +  section id=dmabuf
 +titleStreaming I/O (DMA buffer importing)/title
 +
 +note
 +  titleExperimental/title
 +  paraThis is an link linkend=experimental experimental /link
 +  interface and may change in the future./para
 +/note
 +
 +paraThe DMABUF framework provides a generic method for sharing buffers
 +between multiple devices. Device drivers that support DMABUF can export a DMA
 +buffer to userspace as a file descriptor (known as the exporter role), 
 import a
 +DMA buffer from userspace using a file descriptor previously exported for a
 +different or the same device (known as the importer role), or both. This
 +section describes the DMABUF importer role API in V4L2./para
 +
 +paraInput and output devices support the streaming I/O method when the
 +constantV4L2_CAP_STREAMING/constant flag in the
 +structfieldcapabilities/structfield field of v4l2-capability; returned 
 by
 +the VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through
 +DMABUF file descriptors is supported is determined by calling the
 +VIDIOC-REQBUFS; ioctl with the memory type set to
 +constantV4L2_MEMORY_DMABUF/constant./para
 +
 +paraThis I/O method is dedicated for sharing DMA buffers between V4L 
 and
 +other APIs.

It's more accurate to say something along the lines of: ...is dedicated to 
sharing
DMA buffers between different devices, which may be V4L devices or other
video-related devices (e.g. DRM).

One of the uses of this API is to share buffers between different V4L devices, 
so
that's a bit more generic than the original sentence suggests.

 Buffers (planes) are allocated by a driver on behalf of an
 +application. Next, these buffers are exported to the application as file
 +descriptors using an API which is specific for an allocator driver.  Only 
 such
 +file descriptor are exchanged. The descriptors and meta-information are 
 passed
 +in v4l2-buffer; (or in v4l2-plane; in the multi-planar API case).  The 
 driver
 +must be switched into DMABUF I/O mode by calling the VIDIOC-REQBUFS; with 
 the
 +desired buffer type./para
 +
 +example
 +  titleInitiating streaming I/O with DMABUF file descriptors/title
 +
 +  programlisting
 +v4l2-requestbuffers; reqbuf;
 +
 +memset (amp;reqbuf, 0, sizeof (reqbuf));

no space after memset

 +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 +reqbuf.memory = V4L2_MEMORY_DMABUF;
 +reqbuf.count = 1;
 +
 +if (ioctl (fd, VIDIOC-REQBUFS;, amp;reqbuf) == -1) {

no space after ioctl

 + if (errno == EINVAL)
 + printf(Video capturing or DMABUF streaming is not 
 supported\n);
 + else
 + perror(VIDIOC_REQBUFS);
 +
 + exit(EXIT_FAILURE);
 +}
 +  /programlisting
 +/example
 +
 +paraThe buffer (plane) file descriptor is passed on the fly with 

Re: [PATCHv9 03/25] v4l: vb2: add support for shared buffer (dma_buf)

[Hans Verkuil]

Just a small heads-up for an upcoming change...

On Tue October 2 2012 16:27:14 Tomasz Stanislawski wrote:
 From: Sumit Semwal sumit.sem...@ti.com
 
 This patch adds support for DMABUF memory type in videobuf2. It calls relevant
 APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
 
 For this version, the support is for videobuf2 as a user of the shared buffer;
 so the allocation of the buffer is done outside of V4L2. [A sample allocator 
 of
 dma-buf shared buffer is given at [1]]
 
 [1]: Rob Clark's DRM:
https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[original work in the PoC for buffer sharing]
 Signed-off-by: Sumit Semwal sumit.sem...@ti.com
 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
 Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  drivers/media/video/Kconfig  |1 +
  drivers/media/video/videobuf2-core.c |  207 
 +-
  include/media/videobuf2-core.h   |   27 +
  3 files changed, 232 insertions(+), 3 deletions(-)
 

snip

 @@ -970,6 +1040,109 @@ static int __qbuf_mmap(struct vb2_buffer *vb, const 
 struct v4l2_buffer *b)
  }
  
  /**
 + * __qbuf_dmabuf() - handle qbuf of a DMABUF buffer
 + */
 +static int __qbuf_dmabuf(struct vb2_buffer *vb, const struct v4l2_buffer *b)
 +{
 + struct v4l2_plane planes[VIDEO_MAX_PLANES];
 + struct vb2_queue *q = vb-vb2_queue;
 + void *mem_priv;
 + unsigned int plane;
 + int ret;
 + int write = !V4L2_TYPE_IS_OUTPUT(q-type);
 +
 + /* Verify and copy relevant information provided by the userspace */
 + ret = __fill_vb2_buffer(vb, b, planes);

Note that this code will have to change a bit when my multiplanar fixes go in:

http://www.spinics.net/lists/linux-media/msg54601.html

__fill_vb2_buffer is now a void function, so there won't be any need to check
the error.

 + if (ret)
 + return ret;
 +
 + for (plane = 0; plane  vb-num_planes; ++plane) {
 + struct dma_buf *dbuf = dma_buf_get(planes[plane].m.fd);
 +
 + if (IS_ERR_OR_NULL(dbuf)) {
 + dprintk(1, qbuf: invalid dmabuf fd for plane %d\n,
 + plane);
 + ret = -EINVAL;
 + goto err;
 + }
 +
 + /* use DMABUF size if length is not provided */
 + if (planes[plane].length == 0)
 + planes[plane].length = dbuf-size;
 +
 + if (planes[plane].length  planes[plane].data_offset +
 + q-plane_sizes[plane]) {
 + ret = -EINVAL;
 + goto err;
 + }
 +
 + /* Skip the plane if already verified */
 + if (dbuf == vb-planes[plane].dbuf 
 + vb-v4l2_planes[plane].length == planes[plane].length) {
 + dma_buf_put(dbuf);
 + continue;
 + }
 +
 + dprintk(1, qbuf: buffer for plane %d changed\n, plane);
 +
 + /* Release previously acquired memory if present */
 + __vb2_plane_dmabuf_put(q, vb-planes[plane]);
 + memset(vb-v4l2_planes[plane], 0, sizeof(struct v4l2_plane));
 +
 + /* Acquire each plane's memory */
 + mem_priv = call_memop(q, attach_dmabuf, q-alloc_ctx[plane],
 + dbuf, planes[plane].length, write);
 + if (IS_ERR(mem_priv)) {
 + dprintk(1, qbuf: failed to attach dmabuf\n);
 + ret = PTR_ERR(mem_priv);
 + dma_buf_put(dbuf);
 + goto err;
 + }
 +
 + vb-planes[plane].dbuf = dbuf;
 + vb-planes[plane].mem_priv = mem_priv;
 + }
 +
 + /* TODO: This pins the buffer(s) with  dma_buf_map_attachment()).. but
 +  * really we want to do this just before the DMA, not while queueing
 +  * the buffer(s)..
 +  */
 + for (plane = 0; plane  vb-num_planes; ++plane) {
 + ret = call_memop(q, map_dmabuf, vb-planes[plane].mem_priv);
 + if (ret) {
 + dprintk(1, qbuf: failed to map dmabuf for plane %d\n,
 + plane);
 + goto err;
 + }
 + vb-planes[plane].dbuf_mapped = 1;
 + }
 +
 + /*
 +  * Call driver-specific initialization on the newly acquired buffer,
 +  * if provided.
 +  */
 + ret = call_qop(q, buf_init, vb);
 + if (ret) {
 + dprintk(1, qbuf: buffer initialization failed\n);
 + goto err;
 + }
 +
 + /*
 +  * Now that everything is in order, copy relevant information
 +  * provided by userspace.
 +  */
 + for (plane = 0; plane  vb-num_planes; ++plane)
 + vb-v4l2_planes[plane] = planes[plane];
 +
 + return 0;
 +err:
 + /* In case of errors, release planes that were 

Re: [PATCHv9 09/25] v4l: vb2: add prepare/finish callbacks to allocators

[Hans Verkuil]

Some small typos...

On Tue October 2 2012 16:27:20 Tomasz Stanislawski wrote:
 From: Marek Szyprowski m.szyprow...@samsung.com
 
 This patch adds support for prepare/finish callbacks in VB2 allocators. These
 callback are used for buffer flushing.
 
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  drivers/media/video/videobuf2-core.c |   11 +++
  include/media/videobuf2-core.h   |7 +++
  2 files changed, 18 insertions(+)
 
 diff --git a/drivers/media/video/videobuf2-core.c 
 b/drivers/media/video/videobuf2-core.c
 index 901bc56..05da3b4 100644
 --- a/drivers/media/video/videobuf2-core.c
 +++ b/drivers/media/video/videobuf2-core.c
 @@ -844,6 +844,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
 vb2_buffer_state state)
  {
   struct vb2_queue *q = vb-vb2_queue;
   unsigned long flags;
 + unsigned int plane;
  
   if (vb-state != VB2_BUF_STATE_ACTIVE)
   return;
 @@ -854,6 +855,10 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
 vb2_buffer_state state)
   dprintk(4, Done processing on buffer %d, state: %d\n,
   vb-v4l2_buf.index, vb-state);
  
 + /* sync buffers */
 + for (plane = 0; plane  vb-num_planes; ++plane)
 + call_memop(q, finish, vb-planes[plane].mem_priv);
 +
   /* Add the buffer to the done buffers list */
   spin_lock_irqsave(q-done_lock, flags);
   vb-state = state;
 @@ -1148,9 +1153,15 @@ err:
  static void __enqueue_in_driver(struct vb2_buffer *vb)
  {
   struct vb2_queue *q = vb-vb2_queue;
 + unsigned int plane;
  
   vb-state = VB2_BUF_STATE_ACTIVE;
   atomic_inc(q-queued_count);
 +
 + /* sync buffers */
 + for (plane = 0; plane  vb-num_planes; ++plane)
 + call_memop(q, prepare, vb-planes[plane].mem_priv);
 +
   q-ops-buf_queue(vb);
  }
  
 diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
 index 84f11f2..c306fec 100644
 --- a/include/media/videobuf2-core.h
 +++ b/include/media/videobuf2-core.h
 @@ -56,6 +56,10 @@ struct vb2_fileio_data;
   *   dmabuf
   * @unmap_dmabuf: releases access control to the dmabuf - allocator is 
 notified
   * that this driver is done using the dmabuf for now
 + * @prepare: called everytime the buffer is passed from userspace to the
 + *   driver, usefull for cache synchronisation, optional

everytime - every time
usefull - useful

 + * @finish:  called everytime the buffer is passed back from the driver

everytime - every time

 + *   to the userspace, also optional
   * @vaddr:   return a kernel virtual address to a given memory buffer
   *   associated with the passed private structure or NULL if no
   *   such mapping exists
 @@ -82,6 +86,9 @@ struct vb2_mem_ops {
   unsigned long size, int write);
   void(*put_userptr)(void *buf_priv);
  
 + void(*prepare)(void *buf_priv);
 + void(*finish)(void *buf_priv);
 +
   void*(*attach_dmabuf)(void *alloc_ctx, struct dma_buf *dbuf,
   unsigned long size, int write);
   void(*detach_dmabuf)(void *buf_priv);
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv9 17/25] Documentation: media: description of DMABUF exporting in V4L2

[Hans Verkuil]

More stylistic comments and a suggestion for re-ordering the fields in the 
expbuf struct.

On Tue October 2 2012 16:27:28 Tomasz Stanislawski wrote:
 This patch adds description and usage examples for exporting
 DMABUF file descriptor in V4L2.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 CC: linux-...@vger.kernel.org
 ---
  Documentation/DocBook/media/v4l/compat.xml|3 +
  Documentation/DocBook/media/v4l/io.xml|3 +
  Documentation/DocBook/media/v4l/v4l2.xml  |1 +
  Documentation/DocBook/media/v4l/vidioc-expbuf.xml |  212 
 +
  4 files changed, 219 insertions(+)
  create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml
 
 diff --git a/Documentation/DocBook/media/v4l/compat.xml 
 b/Documentation/DocBook/media/v4l/compat.xml
 index a46f95b..f0512aa 100644
 --- a/Documentation/DocBook/media/v4l/compat.xml
 +++ b/Documentation/DocBook/media/v4l/compat.xml
 @@ -2625,6 +2625,9 @@ ioctls./para
 paraImporting DMABUF file descriptors as a new IO method described
 in xref linkend=dmabuf /./para
  /listitem
 +listitem
 +   paraExporting DMABUF files using VIDIOC-EXPBUF; ioctl./para
 +/listitem
/itemizedlist
  /section
  
 diff --git a/Documentation/DocBook/media/v4l/io.xml 
 b/Documentation/DocBook/media/v4l/io.xml
 index 5b58657..476f448 100644
 --- a/Documentation/DocBook/media/v4l/io.xml
 +++ b/Documentation/DocBook/media/v4l/io.xml
 @@ -488,6 +488,9 @@ DMA buffer from userspace using a file descriptor 
 previously exported for a
  different or the same device (known as the importer role), or both. This
  section describes the DMABUF importer role API in V4L2./para
  
 +paraRefer to link linked=vidioc-expbuf DMABUF exporting /link for
 +details about exporting a V4L2 buffers as DMABUF file descriptors./para

exporting a - exporting

 +
  paraInput and output devices support the streaming I/O method when the
  constantV4L2_CAP_STREAMING/constant flag in the
  structfieldcapabilities/structfield field of v4l2-capability; returned 
 by
 diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
 b/Documentation/DocBook/media/v4l/v4l2.xml
 index eee6908..d8c2597 100644
 --- a/Documentation/DocBook/media/v4l/v4l2.xml
 +++ b/Documentation/DocBook/media/v4l/v4l2.xml
 @@ -543,6 +543,7 @@ and discussions on the V4L mailing list./revremark
  sub-enuminput;
  sub-enumoutput;
  sub-enumstd;
 +sub-expbuf;
  sub-g-audio;
  sub-g-audioout;
  sub-g-crop;
 diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml 
 b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
 new file mode 100644
 index 000..bf28e7d
 --- /dev/null
 +++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
 @@ -0,0 +1,212 @@
 +refentry id=vidioc-expbuf
 +
 +  refmeta
 +refentrytitleioctl VIDIOC_EXPBUF/refentrytitle
 +manvol;
 +  /refmeta
 +
 +  refnamediv
 +refnameVIDIOC_EXPBUF/refname
 +refpurposeExport a buffer as a DMABUF file descriptor./refpurpose
 +  /refnamediv
 +
 +  refsynopsisdiv
 +funcsynopsis
 +  funcprototype
 + funcdefint functionioctl/function/funcdef
 + paramdefint parameterfd/parameter/paramdef
 + paramdefint parameterrequest/parameter/paramdef
 + paramdefstruct v4l2_exportbuffer 
 *parameterargp/parameter/paramdef
 +  /funcprototype
 +/funcsynopsis
 +  /refsynopsisdiv
 +
 +  refsect1
 +titleArguments/title
 +
 +variablelist
 +  varlistentry
 + termparameterfd/parameter/term
 + listitem
 +   parafd;/para
 + /listitem
 +  /varlistentry
 +  varlistentry
 + termparameterrequest/parameter/term
 + listitem
 +   paraVIDIOC_EXPBUF/para
 + /listitem
 +  /varlistentry
 +  varlistentry
 + termparameterargp/parameter/term
 + listitem
 +   para/para
 + /listitem
 +  /varlistentry
 +/variablelist
 +  /refsect1
 +
 +  refsect1
 +titleDescription/title
 +
 +note
 +  titleExperimental/title
 +  paraThis is an link linkend=experimental experimental /link
 +  interface and may change in the future./para
 +/note
 +
 +paraThis ioctl is an extension to the link linkend=mmapmemory
 +mapping/link I/O method therefore it is available only for

method therefore - method, therefore

 +constantV4L2_MEMORY_MMAP/constant buffers.  It can be used to export a
 +buffer as a DMABUF file at any time after buffers have been allocated with 
 the
 +VIDIOC-REQBUFS; ioctl./para
 +
 +para To export a buffer, applicationis fill v4l2-exportbuffer;.  The

applicationis - applications

 +structfield type /structfield field is set to the same buffer type as was
 +previously used with  v4l2-requestbuffers;structfield type /structfield.
 +Applications must also set the structfield index /structfield field. 
 Valid
 +index numbers range from zero to the number of buffers allocated with
 

Re: [PATCHv9 18/25] v4l: add buffer exporting via dmabuf

[Hans Verkuil]

On Tue October 2 2012 16:27:29 Tomasz Stanislawski wrote:
 This patch adds extension to V4L2 api. It allow to export a mmap buffer as 
 file
 descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by
 mmap and return a file descriptor on success.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/video/v4l2-compat-ioctl32.c |1 +
  drivers/media/video/v4l2-dev.c|1 +
  drivers/media/video/v4l2-ioctl.c  |   10 ++
  include/linux/videodev2.h |   28 
  include/media/v4l2-ioctl.h|2 ++
  5 files changed, 42 insertions(+)
 
 diff --git a/drivers/media/video/v4l2-compat-ioctl32.c 
 b/drivers/media/video/v4l2-compat-ioctl32.c
 index f0b5aba..8788000 100644
 --- a/drivers/media/video/v4l2-compat-ioctl32.c
 +++ b/drivers/media/video/v4l2-compat-ioctl32.c
 @@ -971,6 +971,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int 
 cmd, unsigned long arg)
   case VIDIOC_S_FBUF32:
   case VIDIOC_OVERLAY32:
   case VIDIOC_QBUF32:
 + case VIDIOC_EXPBUF:
   case VIDIOC_DQBUF32:
   case VIDIOC_STREAMON32:
   case VIDIOC_STREAMOFF32:
 diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
 index 07aeafc..c43127c 100644
 --- a/drivers/media/video/v4l2-dev.c
 +++ b/drivers/media/video/v4l2-dev.c
 @@ -638,6 +638,7 @@ static void determine_valid_ioctls(struct video_device 
 *vdev)
   SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
   SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
   SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf);
 + SET_VALID_IOCTL(ops, VIDIOC_EXPBUF, vidioc_expbuf);
   SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf);
   SET_VALID_IOCTL(ops, VIDIOC_OVERLAY, vidioc_overlay);
   SET_VALID_IOCTL(ops, VIDIOC_G_FBUF, vidioc_g_fbuf);
 diff --git a/drivers/media/video/v4l2-ioctl.c 
 b/drivers/media/video/v4l2-ioctl.c
 index dffd3c9..f3ec8c0 100644
 --- a/drivers/media/video/v4l2-ioctl.c
 +++ b/drivers/media/video/v4l2-ioctl.c
 @@ -458,6 +458,15 @@ static void v4l_print_buffer(const void *arg, bool 
 write_only)
   tc-type, tc-flags, tc-frames, *(__u32 
 *)tc-userbits);
  }
  
 +static void v4l_print_exportbuffer(const void *arg, bool write_only)
 +{
 + const struct v4l2_exportbuffer *p = arg;
 +
 + pr_cont(fd=%d, type=%s, index=%u, plane=%u, flags=0x%08x\n,
 + p-fd, prt_names(p-type, v4l2_type_names),
 + p-index, p-plane, p-flags);
 +}
 +
  static void v4l_print_create_buffers(const void *arg, bool write_only)
  {
   const struct v4l2_create_buffers *p = arg;
 @@ -1947,6 +1956,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
   IOCTL_INFO_STD(VIDIOC_S_FBUF, vidioc_s_fbuf, v4l_print_framebuffer, 
 INFO_FL_PRIO),
   IOCTL_INFO_STD(VIDIOC_OVERLAY, vidioc_overlay, v4l_print_u32, 
 INFO_FL_PRIO),
   IOCTL_INFO_FNC(VIDIOC_QBUF, v4l_qbuf, v4l_print_buffer, INFO_FL_QUEUE),
 + IOCTL_INFO_STD(VIDIOC_EXPBUF, vidioc_expbuf, v4l_print_exportbuffer, 0),

This needs the INFO_FL_QUEUE flag, that way this call is serialized
with the other queuing ioctls.

You can also add INFO_FL_CLEAR(v4l2_expbuf, flags). This assumes a field order
in the struct as given in my comment below. The FL_CLEAR flag will zero all
fields after 'flags'.

   IOCTL_INFO_FNC(VIDIOC_DQBUF, v4l_dqbuf, v4l_print_buffer, 
 INFO_FL_QUEUE),
   IOCTL_INFO_FNC(VIDIOC_STREAMON, v4l_streamon, v4l_print_buftype, 
 INFO_FL_PRIO | INFO_FL_QUEUE),
   IOCTL_INFO_FNC(VIDIOC_STREAMOFF, v4l_streamoff, v4l_print_buftype, 
 INFO_FL_PRIO | INFO_FL_QUEUE),
 diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
 index e04a73e..f429b6a 100644
 --- a/include/linux/videodev2.h
 +++ b/include/linux/videodev2.h
 @@ -688,6 +688,33 @@ struct v4l2_buffer {
  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
  
 +/**
 + * struct v4l2_exportbuffer - export of video buffer as DMABUF file 
 descriptor
 + *
 + * @fd:  file descriptor associated with DMABUF (set by driver)
 + * @flags:   flags for newly created file, currently only O_CLOEXEC is
 + *   supported, refer to manual of open syscall for more details
 + * @index:   id number of the buffer
 + * @type:enum v4l2_buf_type; buffer type (type == *_MPLANE for
 + *   multiplanar buffers);
 + * @plane:   index of the plane to be exported, 0 for single plane queues
 + *
 + * Contains data used for exporting a video buffer as DMABUF file descriptor.
 + * The buffer is identified by a 'cookie' returned by VIDIOC_QUERYBUF
 + * (identical to the cookie used to mmap() the buffer to userspace). All
 + * reserved fields must be set to zero. The field reserved0 is expected to
 + * become a structure 'type' allowing an alternative layout of the structure
 + * content. 

Re: [PATCHv9 00/25] Integration of videobuf2 with DMABUF

[Hans Verkuil]

On Tue October 2 2012 16:27:11 Tomasz Stanislawski wrote:
 Hello everyone,
 This patchset adds support for DMABUF [2] importing and exporting to V4L2
 stack.

Hi Tomasz,

Thanks for this patch series! I've finished reviewing it, and only found minor
things. The only (minor) API issue I found is in patch 18 where I would suggest
that reordering the fields will make things a bit more natural.

For patches 1, 3, 4, 5, 6, 7, 8, 10, 11, 12, 13, 14, 15, 16, 19, 20, 21, 22,
23, 24, 25:

Acked-by: Hans Verkuil hans.verk...@cisco.com

After fixing the typos you can also add my Acked-by for patch 9.

Regards,

Hans

 v9:
 - rebase on 3.6
 - change type for fs to __s32
 - add support for vb2_ioctl_expbuf
 - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING',
   it will be posted as a separate patch
 - fix typos and style in Documentation (from Hans Verkuil)
 - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig
 - use data_offset and length while queueing DMABUF
 - return the most recently used fd at VIDIOC_DQBUF
 - use (buffer-type, index, plane) tuple instead of mem_offset
   to identify a for exporting (from Hans Verkuil)
 - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart)
 - add testing alignment of vaddr and size while verifying userptr
   against DMA capabilities (from Laurent Pinchart)
 - substitute VM_DONTDUMP with VM_RESERVED
 - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart)
 
 v8:
 - rebased on 3.6-rc1
 - merged importer and exporter patchsets
 - fixed missing fields in v4l2_plane32 and v4l2_buffer32 structs
 - fixed typos/style in documentation
 - significant reduction of warnings from checkpatch.pl
 - fixed STREAMOFF issues reported by Dima Zavin [4] by adding
   __vb2_dqbuf helper to vb2-core
 - DC fails if userptr is not correctly aligned
 - add support for DMA attributes in DC
 - add support for buffers with no kernel mapping
 - add reference counting on device from allocator context
 - dummy support for mmap
 - use dma_get_sgtable, drop vb2_dc_kaddr_to_pages hack and
   vb2_dc_get_base_sgt helper
 
 v7:
 - support for V4L2_MEMORY_DMABUF in v4l2-compact-ioctl32.c
 - cosmetic fixes to the documentation
 - added importing for vmalloc because vmap support in dmabuf for 3.5
   was pull-requested
 - support for dmabuf importing for VIVI
 - resurrect allocation of dma-contig context
 - remove reference of alloc_ctx in dma-contig buffer
 - use sg_alloc_table_from_pages
 - fix DMA scatterlist calls to use orig_nents instead of nents
 - fix memleak in vb2_dc_sgt_foreach_page (use orig_nents instead of nents)
 
 v6:
 - fixed missing entry in v4l2_memory_names
 - fixed a bug occuring after get_user_pages failure
 - fixed a bug caused by using invalid vma for get_user_pages
 - prepare/finish no longer call dma_sync for dmabuf buffers
 
 v5:
 - removed change of importer/exporter behaviour
 - fixes vb2_dc_pages_to_sgt basing on Laurent's hints
 - changed pin/unpin words to lock/unlock in Doc
 
 v4:
 - rebased on mainline 3.4-rc2
 - included missing importing support for s5p-fimc and s5p-tv
 - added patch for changing map/unmap for importers
 - fixes to Documentation part
 - coding style fixes
 - pairing {map/unmap}_dmabuf in vb2-core
 - fixing variable types and semantic of arguments in videobufb2-dma-contig.c
 
 v3:
 - rebased on mainline 3.4-rc1
 - split 'code refactor' patch to multiple smaller patches
 - squashed fixes to Sumit's patches
 - patchset is no longer dependant on 'DMA mapping redesign'
 - separated path for handling IO and non-IO mappings
 - add documentation for DMABUF importing to V4L
 - removed all DMABUF exporter related code
 - removed usage of dma_get_pages extension
 
 v2:
 - extended VIDIOC_EXPBUF argument from integer memoffset to struct
   v4l2_exportbuffer
 - added patch that breaks DMABUF spec on (un)map_atachment callcacks but 
 allows
   to work with existing implementation of DMABUF prime in DRM
 - all dma-contig code refactoring patches were squashed
 - bugfixes
 
 v1: List of changes since [1].
 - support for DMA api extension dma_get_pages, the function is used to 
 retrieve
   pages used to create DMA mapping.
 - small fixes/code cleanup to videobuf2
 - added prepare and finish callbacks to vb2 allocators, it is used keep
   consistency between dma-cpu acess to the memory (by Marek Szyprowski)
 - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated 
 from
   [3].
 - support for dma-buf exporting in vb2-dma-contig allocator
 - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers,
   originated from [3]
 - changed handling for userptr buffers (by Marek Szyprowski, Andrzej
   Pietrasiewicz)
 - let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski)
 
 [1] 
 http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42966/focus=42968
 [2] https://lkml.org/lkml/2011/12/26/29
 [3] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
 

Re: [PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform data

[Tomasz Stanislawski]

Hi Rahul Sharma,

On 10/04/2012 05:18 PM, Rahul Sharma wrote:
 From: Tomasz Stanislawski t.stanisl...@samsung.com
 
 This patch extends s5p-hdmi platform data by a GPIO identifier for
 Hot-Plug-Detection pin.
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

Acked-by: Tomasz Stanislawski t.stanisl...@samsung.com

Regards,
Tomasz Stanislawski

 ---
  include/media/s5p_hdmi.h |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
 diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
 index 361a751..181642b 100644
 --- a/include/media/s5p_hdmi.h
 +++ b/include/media/s5p_hdmi.h
 @@ -20,6 +20,7 @@ struct i2c_board_info;
   * @hdmiphy_info: template for HDMIPHY I2C device
   * @mhl_bus: controller id for MHL control bus
   * @mhl_info: template for MHL I2C device
 + * @hpd_gpio: GPIO for Hot-Plug-Detect pin
   *
   * NULL pointer for *_info fields indicates that
   * the corresponding chip is not present
 @@ -29,6 +30,7 @@ struct s5p_hdmi_platform_data {
   struct i2c_board_info *hdmiphy_info;
   int mhl_bus;
   struct i2c_board_info *mhl_info;
 + int hpd_gpio;
  };
  
  #endif /* S5P_HDMI_H */
 

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

Re: [RFC] drm/radeon: make dynamic allocation of page tables on demand in radeon_vm_update_pte v2

[Christian König]

Trying to resolve the remaining bugs today. Expect an v3 of the patch 
this evening or Monday morning.


Cheers,
Christian.

On 04.10.2012 16:32, Dmitry Cherkasov wrote:

v2: setup and alloc number of contiguous PTs if possible

Warning: Heaven benchmark /sometimes/ fails with this patch after
10 or 15 minutes of working, so any insight is greatly appreciated.

The code is a bit bloated because it's a question how a decent optimization
should be made: via macros? using structs? etc.

The rationale for struct radeon_pt is that BO may contain several contiguous
PTs and we should have that u64 gpu_addr to point to actual begining of PT.

I've only tested it on cayman card, should work on SI but who knows? ;)

Please say your ideas.
---
  drivers/gpu/drm/radeon/radeon.h  |   12 ++
  drivers/gpu/drm/radeon/radeon_gart.c |  263 --
  2 files changed, 260 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b04c064..38d4eda 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -659,6 +659,15 @@ struct radeon_ring {
  /* number of entries in page table */
  #define RADEON_VM_PTE_COUNT (1  RADEON_VM_BLOCK_SIZE)
  
+struct radeon_pt {

+   /* BO containing the page table */
+   /* radeon_sa_bo_gpu_addr(sa_bo); */
+   struct radeon_sa_bo *bo;
+
+   /* GPU address of page table */
+   u64 gpu_addr;
+};
+
  struct radeon_vm {
struct list_headlist;
struct list_headva;
@@ -671,6 +680,9 @@ struct radeon_vm {
struct radeon_fence *fence;
/* last flush or NULL if we still need to flush */
struct radeon_fence *last_flush;
+
+   /* page tables list */
+   struct radeon_pt *vm_pts;
  };
  
  struct radeon_vm_manager {

diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 753b7ca..cea918d 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -500,6 +500,10 @@ static void radeon_vm_free_pt(struct radeon_device *rdev,
struct radeon_vm *vm)
  {
struct radeon_bo_va *bo_va;
+   int i;
+
+   int driver_table_entries = (rdev-vm_manager.max_pfn 
+   RADEON_VM_BLOCK_SIZE);
  
  	if (!vm-sa_bo)

return;
@@ -510,6 +514,14 @@ static void radeon_vm_free_pt(struct radeon_device *rdev,
list_for_each_entry(bo_va, vm-va, vm_list) {
bo_va-valid = false;
}
+
+   if (vm-vm_pts == NULL)
+   return;
+
+   for (i = 0;i  driver_table_entries; i++)
+   radeon_sa_bo_free(rdev, vm-vm_pts[i].bo, vm-fence);
+
+   kfree (vm-vm_pts);
  }
  
  /**

@@ -563,6 +575,9 @@ int radeon_vm_alloc_pt(struct radeon_device *rdev, struct 
radeon_vm *vm)
int r;
u64 *pd_addr;
int tables_size;
+   int driver_table_size = (rdev-vm_manager.max_pfn 
+RADEON_VM_BLOCK_SIZE) *
+   sizeof(struct radeon_pt);
  
  	if (vm == NULL) {

return -EINVAL;
@@ -570,7 +585,6 @@ int radeon_vm_alloc_pt(struct radeon_device *rdev, struct 
radeon_vm *vm)
  
  	/* allocate enough to cover the current VM size */

tables_size = RADEON_GPU_PAGE_ALIGN(radeon_vm_directory_size(rdev));
-   tables_size += RADEON_GPU_PAGE_ALIGN(vm-last_pfn * 8);
  
  	if (vm-sa_bo != NULL) {

/* update lru */
@@ -600,6 +614,16 @@ retry:
vm-pd_gpu_addr = radeon_sa_bo_gpu_addr(vm-sa_bo);
memset(pd_addr, 0, tables_size);
  
+	vm-vm_pts = kmalloc(driver_table_size, GFP_KERNEL);

+
+   if (vm-vm_pts == NULL) {
+   DRM_ERROR(Cannot allocate space for driver page table\n);
+   radeon_sa_bo_free(rdev, vm-sa_bo, vm-fence);
+   return -ENOMEM;
+   }
+
+   memset(vm-vm_pts, 0, driver_table_size);
+
list_add_tail(vm-list, rdev-vm_manager.lru_vm);
return radeon_vm_bo_update_pte(rdev, vm, rdev-ring_tmp_bo.bo,
   rdev-ring_tmp_bo.bo-tbo.mem);
@@ -864,6 +888,69 @@ uint64_t radeon_vm_map_gart(struct radeon_device *rdev, 
uint64_t addr)
return result;
  }
  
+/* setup @count pfns starting at @addr to PTEs starting at @pt_start and

+ * @pde_count pdes starting at @pd_start */
+
+static void radeon_vm_map_pfns (struct radeon_device *rdev,
+   uint64_t pt_addr, uint64_t pt_offset,
+   uint64_t addr, uint64_t pte_count,
+   uint64_t pd_start, uint32_t pde_count, uint32_t 
flags)
+{
+   if (pde_count == 0  pte_count == 0)
+   return;
+
+   radeon_asic_vm_set_page(rdev, pt_addr + pt_offset, addr,
+   pte_count,
+   RADEON_GPU_PAGE_SIZE, flags);
+
+   

[GIT PULL v2] exynos-drm-next

[Inki Dae]

Hello Dave,

as I mentioned, this pull request adds hdmi device tree support
and includes related patch set such as disabling of hdmi internal
interrupt, suppport for platform variants for hdmi and mixer,
support to disable video processor based on platform type and
removal of drm common platform data. as you know, this patch
set was delayed because it included an media side patch. so for this,
we got an ack from v4l2-based hdmi driver author, Tomasz Stanislawski.

Changelog v1:
this patch set updates exynos drm framework and includes minor fixups.
and this pull request except hdmi device tree support patch set posted
by Rahul Sharma because that includes media side patch so for this
patch set, we may have git pull one more time in addition, if we get
an agreement with media guys. for this patch, you can refer to below link,
http://comments.gmane.org/gmane.comp.video.dri.devel/74504

if there is any problem, please let me know.

Thanks,
Inki Dae

The following changes since commit 29cb602532b0a82f22322cece8a89f022368d557:

  drm/exynos: added device object to subdrv's remove callback as argument 
(2012-10-04 10:05:59 +0900)

are available in the git repository at:
  git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-next

Inki Dae (15):
  drm/exynos: separated subdrv_probe function into two parts.
  drm/exynos: separeated fimd_power_on into some parts.
  drm/exynos: fixed duplicated mode setting.
  drm/exynos: add wait_for_vblank callback interface.
  drm/exynos: make sure that hardware overlay for fimd is disabled
  drm/exynos: make sure that hardware overlay for hdmi is disabled
  drm/exynos: check NV12M format specific to Exynos properly
  drm/exynos: update crtc to plane safely
  drm/exynos: Disable plane when released
  drm/exynos: add pid to g2d_runqueue_node
  drm/exynos: fix duplicated mutex lock issue
  drm/exynos: check crtc's dpms mode at page flip
  drm/exynos: check crtc's dpms mode at SetCrtc
  drm/exynos: support drm_wait_vblank feature for VIDI
  drm/exynos: fix display power call issue.

Joonyoung Shim (2):
  drm/exynos: fix to calculate CRTC shown via screen
  drm/exynos: fix kcalloc size of g2d cmdlist node

Leela Krishna Amudala (1):
  drm/exynos: add platform_device_id table and driver data for drm fimd

Rahul Sharma (9):
  drm: exynos: remove drm hdmi platform data struct
  drm: exynos: hdmi: add support for exynos5 ddc
  drm: exynos: hdmi: add support for exynos5 hdmiphy
  drm: exynos: hdmi: add support for platform variants for mixer
  drm: exynos: hdmi: add support to disable video processor in mixer
  drm: exynos: hdmi: add support for exynos5 mixer
  drm: exynos: hdmi: replace is_v13 with version check in hdmi
  drm: exynos: hdmi: add support for exynos5 hdmi
  drm: exynos: hdmi: remove drm common hdmi platform data struct

Sachin Kamat (1):
  drm/exynos: Fix potential NULL pointer dereference

Tomasz Stanislawski (5):
  media: s5p-hdmi: add HPD GPIO to platform data
  drm: exynos: hdmi: support for platform variants
  drm: exynos: hdmi: fix interrupt handling
  drm: exynos: hdmi: use s5p-hdmi platform data
  drm: exynos: hdmi: turn off HPD interrupt in HDMI chip

 drivers/gpu/drm/exynos/exynos_ddc.c   |   22 ++-
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   50 +-
 drivers/gpu/drm/exynos/exynos_drm_connector.h |4 +
 drivers/gpu/drm/exynos/exynos_drm_core.c  |  100 +++
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   20 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   17 ++
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |  116 +++--
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   65 +++-
 drivers/gpu/drm/exynos/exynos_drm_fb.h|   20 +--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  115 ++---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |5 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |   62 ---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |3 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   58 ++-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   22 +++-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |  196 +++--
 drivers/gpu/drm/exynos/exynos_hdmiphy.c   |   12 ++-
 drivers/gpu/drm/exynos/exynos_mixer.c |  240 +++--
 drivers/gpu/drm/exynos/regs-mixer.h   |3 +
 include/drm/exynos_drm.h  |   37 +---
 include/media/s5p_hdmi.h  |2 +
 22 files changed, 905 insertions(+), 267 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/14] media: add V4L2 DT binding documentation

[Guennadi Liakhovetski]

On Fri, 5 Oct 2012, Hans Verkuil wrote:

 On Fri October 5 2012 11:43:27 Guennadi Liakhovetski wrote:
  On Wed, 3 Oct 2012, Rob Herring wrote:
  
   On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
Hi Rob

On Tue, 2 Oct 2012, Rob Herring wrote:

On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:

[snip]

+Optional link properties:
+- remote: phandle to the other endpoint link DT node.
   
This name is a little vague. Perhaps endpoint would be better.

endpoint can also refer to something local like in USB case. Maybe 
rather the description of the remote property should be improved?
   
   remote-endpoint?
  
  Sorry, I really don't want to pull in yet another term here. We've got 
  ports and links already, now you're proposing to also use endpoind. 
  Until now everyone was happy with remote, any more opinions on this?
 
 Actually, when I was reviewing the patch series today I got confused as
 well by 'remote'. What about 'remote-link'?

Yes, I was thinking about this one too, it looks a bit clumsy, but it does 
make it clearer, what is meant.

 And v4l2_of_get_remote() can be renamed to v4l2_of_get_remote_link() which
 I think is a lot clearer.
 
 The text can be improved as well since this:
 
 - remote: phandle to the other endpoint link DT node.
 
 is a bit vague. How about:
 
 - remote-link: phandle to the remote end of this link.

Looks good to me.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Monitor sync out of range with current Linux git tree

[Markus Trippelsdorf]

When I cold start my machine I see the following error message on my
monitor:

 Out of Range
 48.2kHz / 44Hz

I have to reboot on older kernel and kexec to the current one to get it
working again.

[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
used)
radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4083554 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0xC004).
radeon :01:05.0: WB enabled
radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and 
cpu addr 0x880215c60c00
radeon :01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 0 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
[drm] radeon: power management initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF000
[drm] size 7299072
[drm] fb depth is 24
[drm]pitch is 6912
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 131x105
fb0: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.24.0 20080528 for :01:05.0 on minor 0


X.Org X Server 1.13.0
Release Date: 2012-09-05
...
[ 4.790] (II) [KMS] Kernel modesetting enabled.
[ 4.790] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 4.790] (II) RADEON(0): Creating default Display subsection in Screen 
section
Default Screen Section for depth/fbbpp 24/32
[ 4.790] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32
[ 4.790] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp 
pixmaps)
[ 4.790] (==) RADEON(0): Default visual is TrueColor
[ 4.790] (==) RADEON(0): RGB weight 888
[ 4.790] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[ 4.790] (--) RADEON(0): Chipset: ATI Radeon HD 3300 Graphics (ChipID = 
0x9614)
[ 4.790] (II) RADEON(0): PCI card detected
[ 4.791] (II) Loading sub module exa
[ 4.791] (II) LoadModule: exa
[ 4.792] (II) Loading /usr/lib64/xorg/modules/libexa.so
[ 4.792] (II) Module exa: vendor=X.Org Foundation
[ 4.792]compiled for 1.13.0, module version = 2.6.0
[ 4.792]ABI class: X.Org Video Driver, version 13.0
[ 4.792] (II) RADEON(0): KMS Color Tiling: enabled
[ 4.792] (II) RADEON(0): KMS Pageflipping: enabled
[ 4.792] (II) RADEON(0): SwapBuffers wait for vsync: enabled
[ 4.813] (II) RADEON(0): Output VGA-0 has no monitor section
[ 4.870] (II) RADEON(0): Output DVI-0 using monitor section DVI-0
[ 4.870] (**) RADEON(0): Option Rotate left
[ 4.890] (II) RADEON(0): EDID for output VGA-0
[ 4.950] (II) RADEON(0): EDID for output DVI-0
[ 4.950] (II) RADEON(0): Manufacturer: GSM  Model: 4e48  Serial#: 148502
[ 4.950] (II) RADEON(0): Year: 2006  Week: 8
[ 4.950] (II) RADEON(0): EDID Version: 1.3
[ 4.950] (II) RADEON(0): Digital Display Input
[ 4.950] (II) RADEON(0): Max Image Size [cm]: horiz.: 43  vert.: 27
[ 4.950] (II) RADEON(0): Gamma: 2.20
[ 4.950] (II) RADEON(0): DPMS capabilities: StandBy Suspend Off
[ 4.950] (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 
[ 4.950] (II) RADEON(0): First detailed timing is preferred mode
[ 4.950] (II) RADEON(0): redX: 0.651 redY: 0.333   greenX: 0.277 greenY: 
0.614
[ 4.950] (II) RADEON(0): blueX: 0.145 blueY: 0.082   whiteX: 0.313 whiteY: 
0.329
[ 4.950] (II) RADEON(0): Supported established timings:
[ 4.950] (II) RADEON(0): 720x400@70Hz
[ 4.950] (II) RADEON(0): 640x480@60Hz
[ 4.950] (II) RADEON(0): 640x480@75Hz
[ 4.950] (II) RADEON(0): 800x600@56Hz
[ 4.950] (II) RADEON(0): 800x600@60Hz
[ 4.950] (II) RADEON(0): 800x600@75Hz
[ 4.950] (II) RADEON(0): 832x624@75Hz
[ 4.950] (II) RADEON(0): 1024x768@60Hz
[ 4.950] (II) RADEON(0): 

[PATCH V3] drm/radeon: Include swiotlb.h if SWIOTLB configured

[Huacai Chen]

When SWIOTLB is configured, if without this patch kernel compilation
fails with such error messages:

drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate':
drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of 
function 'swiotlb_nr_tbl'
drivers/gpu/drm/radeon/radeon_ttm.c:607:3: warning: passing argument 2 of 
'ttm_dma_populate' from incompatible pointer type
include/drm/ttm/ttm_page_alloc.h:81:12: note: expected 'struct device *' but 
argument is of type 'struct device *'
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate':
drivers/gpu/drm/radeon/radeon_ttm.c:653:3: warning: passing argument 2 of 
'ttm_dma_unpopulate' from incompatible pointer type
include/drm/ttm/ttm_page_alloc.h:82:13: note: expected 'struct device *' but 
argument is of type 'struct device *'

V2:
1, Add compilation error messages;
2, Make the From: address the same as Signed-off-by address.

V3:
1, Send to Alex Deucher since this is radeon specific;
2, Add Reviewed-by email addresses.

Signed-off-by: Huacai Chen che...@lemote.com
Signed-off-by: Hongliang Tao ta...@lemote.com
Signed-off-by: Hua Yan y...@lemote.com
Reviewed-by: Michel Dänzer michel.daen...@amd.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/radeon/radeon_ttm.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 5b71c71..fc3ac22 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -41,6 +41,10 @@
 #include radeon_reg.h
 #include radeon.h
 
+#ifdef CONFIG_SWIOTLB
+#include linux/swiotlb.h
+#endif
+
 #define DRM_FILE_PAGE_OFFSET (0x1ULL  PAGE_SHIFT)
 
 static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
-- 
1.7.7.3

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

Re: Monitor sync out of range with current Linux git tree

[Alex Deucher]

On Fri, Oct 5, 2012 at 8:37 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
 When I cold start my machine I see the following error message on my
 monitor:

  Out of Range
  48.2kHz / 44Hz

 I have to reboot on older kernel and kexec to the current one to get it
 working again.

I don't see anything amiss; can you bisect?

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

[RFC 0/4] drm: add raw monotonic timestamp support

[Imre Deak]

This is needed to make applications depending on vblank/page flip
timestamps independent of time ajdustments.

I've tested these with an updated intel-gpu-test/flip_test and will send
the update for that once there's no objection about this patchset.

The patchset is based on danvet's dinq branch with the following
additional patches from the intel-gfx ML applied: 
drm/i915: paper over a pipe-enable vs pageflip race
drm/i915: don't frob the vblank ts in finish_page_flip
drm/i915: call drm_handle_vblank before finish_page_flip

Imre Deak (4):
  time: export getnstime_raw_and_real for DRM
  drm: make memset/calloc for _vblank_time more robust
  drm: use raw time in drm_calc_vbltimestamp_from_scanoutpos
  drm: add support for raw monotonic vblank timestamps

 drivers/gpu/drm/drm_crtc.c|2 +
 drivers/gpu/drm/drm_ioctl.c   |3 ++
 drivers/gpu/drm/drm_irq.c |   83 -
 drivers/gpu/drm/i915/i915_irq.c   |2 +-
 drivers/gpu/drm/i915/intel_display.c  |   12 ++---
 drivers/gpu/drm/radeon/radeon_display.c   |   10 ++--
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/radeon_kms.c   |2 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c |9 ++--
 include/drm/drm.h |5 +-
 include/drm/drmP.h|   38 +++--
 include/drm/drm_mode.h|4 +-
 kernel/time/timekeeping.c |2 +-
 13 files changed, 113 insertions(+), 61 deletions(-)

-- 
1.7.9.5

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

[RFC 1/4] time: export getnstime_raw_and_real for DRM

[Imre Deak]

Needed by the upcoming DRM raw monotonic timestamp support.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 kernel/time/timekeeping.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index d3b91e7..073d262 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -365,7 +365,7 @@ void ktime_get_ts(struct timespec *ts)
 }
 EXPORT_SYMBOL_GPL(ktime_get_ts);
 
-#ifdef CONFIG_NTP_PPS
+#if defined(CONFIG_NTP_PPS) || defined(CONFIG_DRM) || 
defined(CONFIG_DRM_MODULE)
 
 /**
  * getnstime_raw_and_real - get day and raw monotonic time in timespec format
-- 
1.7.9.5

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

[RFC 2/4] drm: make memset/calloc for _vblank_time more robust

[Imre Deak]

Using sizeof(*var) instead of sizeof(var_type) allows changing var_type
w/o breaking callers that depend on the size.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/drm_irq.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 076c4a8..77f6577 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -90,7 +90,7 @@ int drm_irq_by_busid(struct drm_device *dev, void *data,
 static void clear_vblank_timestamps(struct drm_device *dev, int crtc)
 {
memset(dev-_vblank_time[crtc * DRM_VBLANKTIME_RBSIZE], 0,
-   DRM_VBLANKTIME_RBSIZE * sizeof(struct timeval));
+   DRM_VBLANKTIME_RBSIZE * sizeof(dev-_vblank_time[0]));
 }
 
 /*
@@ -248,7 +248,7 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
goto err;
 
dev-_vblank_time = kcalloc(num_crtcs * DRM_VBLANKTIME_RBSIZE,
-   sizeof(struct timeval), GFP_KERNEL);
+   sizeof(dev-_vblank_time[0]), GFP_KERNEL);
if (!dev-_vblank_time)
goto err;
 
-- 
1.7.9.5

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

[RFC 3/4] drm: use raw time in drm_calc_vbltimestamp_from_scanoutpos

[Imre Deak]

The timestamp is used here for handling the timeout case, so we don't
want it to be affected by time adjustments.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/drm_irq.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 77f6577..5e42981 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -576,7 +576,7 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device 
*dev, int crtc,
  unsigned flags,
  struct drm_crtc *refcrtc)
 {
-   struct timeval stime, raw_time;
+   struct timespec raw_stime, raw_etime, real_etime;
struct drm_display_mode *mode;
int vbl_status, vtotal, vdisplay;
int vpos, hpos, i;
@@ -625,13 +625,13 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev, int crtc,
preempt_disable();
 
/* Get system timestamp before query. */
-   do_gettimeofday(stime);
+   getrawmonotonic(raw_stime);
 
/* Get vertical and horizontal scanout pos. vpos, hpos. */
vbl_status = dev-driver-get_scanout_position(dev, crtc, 
vpos, hpos);
 
/* Get system timestamp after query. */
-   do_gettimeofday(raw_time);
+   getnstime_raw_and_real(raw_etime, real_etime);
 
preempt_enable();
 
@@ -642,7 +642,8 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device 
*dev, int crtc,
return -EIO;
}
 
-   duration_ns = timeval_to_ns(raw_time) - timeval_to_ns(stime);
+   duration_ns = timespec_to_ns(raw_etime) -
+ timespec_to_ns(raw_stime);
 
/* Accept result with   max_error nsecs timing uncertainty. */
if (duration_ns = (s64) *max_error)
@@ -692,11 +693,11 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev, int crtc,
/* Subtract time delta from raw timestamp to get final
 * vblank_time timestamp for end of vblank.
 */
-   *vblank_time = ns_to_timeval(timeval_to_ns(raw_time) - delta_ns);
+   *vblank_time = ns_to_timeval(timeval_to_ns(real_time) - delta_ns);
 
DRM_DEBUG(crtc %d : v %d p(%d,%d)@ %ld.%ld - %ld.%ld [e %d us, %d 
rep]\n,
  crtc, (int)vbl_status, hpos, vpos,
- (long)raw_time.tv_sec, (long)raw_time.tv_usec,
+ (long)raw_stime.tv_sec, (long)raw_stime.tv_nsec / 1000,
  (long)vblank_time-tv_sec, (long)vblank_time-tv_usec,
  (int)duration_ns/1000, i);
 
-- 
1.7.9.5

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

[RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Imre Deak]

In practice we never want the timestamps for vblank and page flip events
to be affected by time adjustments, so in addition to the gettimeofday
timestamps we used so far add support for raw monotonic timestamps.

For backward compatibility use flags to select between the old and new
timestamp format.

Note that with this change we will save the timestamp in both formats,
for cases where multiple clients are expecting an event notification in
different time formats. In theory we could track the clients and save
the timestamp only in one format if possible, but the overhead of this
tracking would be bigger than just saving both formats always.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/drm_crtc.c|2 +
 drivers/gpu/drm/drm_ioctl.c   |3 ++
 drivers/gpu/drm/drm_irq.c |   68 +
 drivers/gpu/drm/i915/i915_irq.c   |2 +-
 drivers/gpu/drm/i915/intel_display.c  |   12 ++---
 drivers/gpu/drm/radeon/radeon_display.c   |   10 +++--
 drivers/gpu/drm/radeon/radeon_drv.c   |2 +-
 drivers/gpu/drm/radeon/radeon_kms.c   |2 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c |9 ++--
 include/drm/drm.h |5 ++-
 include/drm/drmP.h|   38 +---
 include/drm/drm_mode.h|4 +-
 12 files changed, 104 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c317f72..e492363 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3550,6 +3550,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
goto out;
}
 
+   e-timestamp_raw = page_flip-flags 
+  DRM_MODE_PAGE_FLIP_TIMESTAMP_RAW;
e-event.base.type = DRM_EVENT_FLIP_COMPLETE;
e-event.base.length = sizeof e-event;
e-event.user_data = page_flip-user_data;
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 64a62c6..0a30299 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -287,6 +287,9 @@ int drm_getcap(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
req-value |= dev-driver-prime_fd_to_handle ? 
DRM_PRIME_CAP_IMPORT : 0;
req-value |= dev-driver-prime_handle_to_fd ? 
DRM_PRIME_CAP_EXPORT : 0;
break;
+   case DRM_CAP_TIMESTAMP_RAW:
+   req-value = 1;
+   break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 5e42981..4879363 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -105,7 +105,7 @@ static void vblank_disable_and_save(struct drm_device *dev, 
int crtc)
u32 vblcount;
s64 diff_ns;
int vblrc;
-   struct timeval tvblank;
+   struct drm_vblank_time tvblank;
 
/* Prevent vblank irq processing while disabling vblank irqs,
 * so no updates of timestamps or count can happen after we've
@@ -137,8 +137,8 @@ static void vblank_disable_and_save(struct drm_device *dev, 
int crtc)
 * as updated by last invocation of drm_handle_vblank() in vblank irq.
 */
vblcount = atomic_read(dev-_vblank_count[crtc]);
-   diff_ns = timeval_to_ns(tvblank) -
- timeval_to_ns(vblanktimestamp(dev, crtc, vblcount));
+   diff_ns = timeval_to_ns(tvblank.raw) -
+ timeval_to_ns(vblanktimestamp(dev, crtc, vblcount).raw);
 
/* If there is at least 1 msec difference between the last stored
 * timestamp and tvblank, then we are currently executing our
@@ -550,7 +550,8 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
  * @crtc: Which crtc's vblank timestamp to retrieve.
  * @max_error: Desired maximum allowable error in timestamps (nanosecs).
  * On return contains true maximum error of timestamp.
- * @vblank_time: Pointer to struct timeval which should receive the timestamp.
+ * @vblank_time: Pointer to struct drm_vblank_time which should receive the
+ *  timestamp both in raw monotonic and wall-time format.
  * @flags: Flags to pass to driver:
  * 0 = Default.
  * DRM_CALLED_FROM_VBLIRQ = If function is called from vbl irq handler.
@@ -572,7 +573,7 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
  */
 int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc,
  int *max_error,
- struct timeval *vblank_time,
+ struct drm_vblank_time *vblank_time,
  unsigned flags,
  struct drm_crtc *refcrtc)
 {
@@ -693,12 +694,13 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device 

Re: Monitor sync out of range with current Linux git tree

[Markus Trippelsdorf]

On 2012.10.05 at 09:14 -0400, Alex Deucher wrote:
 On Fri, Oct 5, 2012 at 8:37 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  When I cold start my machine I see the following error message on my
  monitor:
 
   Out of Range
   48.2kHz / 44Hz
 
  I have to reboot on older kernel and kexec to the current one to get it
  working again.
 
 I don't see anything amiss; can you bisect?

Yes. It's your commit:

commit 9dbbcfc6894957fdbb311ba92c85c026659878b5
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Wed Sep 12 17:39:57 2012 -0400

drm/radeon/dce3: use a single PPLL for all DP displays

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

Re: [RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Michel Dänzer]

On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote: 
 In practice we never want the timestamps for vblank and page flip events
 to be affected by time adjustments, so in addition to the gettimeofday
 timestamps we used so far add support for raw monotonic timestamps.
 
 For backward compatibility use flags to select between the old and new
 timestamp format.
 
 Note that with this change we will save the timestamp in both formats,
 for cases where multiple clients are expecting an event notification in
 different time formats.

I wonder if all this trouble is really necessary. I honestly can't
imagine any user of this API requiring non-monotonic timestamps and
breaking with monotonic ones. I think it was simply a mistake that we
didn't make them monotonic in the first place (or maybe it wasn't even
possible when this API was first introduced).


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Imre Deak]

On Fri, 2012-10-05 at 15:55 +0200, Michel Dänzer wrote:
 On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote: 
  In practice we never want the timestamps for vblank and page flip events
  to be affected by time adjustments, so in addition to the gettimeofday
  timestamps we used so far add support for raw monotonic timestamps.
  
  For backward compatibility use flags to select between the old and new
  timestamp format.
  
  Note that with this change we will save the timestamp in both formats,
  for cases where multiple clients are expecting an event notification in
  different time formats.
 
 I wonder if all this trouble is really necessary. I honestly can't
 imagine any user of this API requiring non-monotonic timestamps and
 breaking with monotonic ones. I think it was simply a mistake that we
 didn't make them monotonic in the first place (or maybe it wasn't even
 possible when this API was first introduced).

Yea, I'd rather simply switch over to monotonic timestamps too. But that
would break apps that already compare against the wall time for whatever
purpose (for example A/V sync).

--Imre


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

Re: Monitor sync out of range with current Linux git tree

[Markus Trippelsdorf]

On 2012.10.05 at 10:02 -0400, Alex Deucher wrote:
 On Fri, Oct 5, 2012 at 9:38 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On 2012.10.05 at 09:14 -0400, Alex Deucher wrote:
  On Fri, Oct 5, 2012 at 8:37 AM, Markus Trippelsdorf
  mar...@trippelsdorf.de wrote:
   When I cold start my machine I see the following error message on my
   monitor:
  
Out of Range
48.2kHz / 44Hz
  
   I have to reboot on older kernel and kexec to the current one to get it
   working again.
 
  I don't see anything amiss; can you bisect?
 
  Yes. It's your commit:
 
  commit 9dbbcfc6894957fdbb311ba92c85c026659878b5
  Author: Alex Deucher alexander.deuc...@amd.com
  Date:   Wed Sep 12 17:39:57 2012 -0400
 
  drm/radeon/dce3: use a single PPLL for all DP displays
 
 Can you apply the attached patch and send me the output?

[drm] == start crtc 0 driving DVI-D-1 ==
[drm] crtc 0 is not DP
[drm] plls in use 0x0
[drm] crtc 0 using pll 0x1
[drm] == end crtc 0 ==

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

Re: [RFC 4/4] drm: add support for raw monotonic vblank timestamps

[Imre Deak]

On Fri, 2012-10-05 at 16:14 +0200, Michel Dänzer wrote:
 On Fre, 2012-10-05 at 16:59 +0300, Imre Deak wrote: 
  On Fri, 2012-10-05 at 15:55 +0200, Michel Dänzer wrote:
   On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote: 
In practice we never want the timestamps for vblank and page flip events
to be affected by time adjustments, so in addition to the gettimeofday
timestamps we used so far add support for raw monotonic timestamps.

For backward compatibility use flags to select between the old and new
timestamp format.

Note that with this change we will save the timestamp in both formats,
for cases where multiple clients are expecting an event notification in
different time formats.
   
   I wonder if all this trouble is really necessary. I honestly can't
   imagine any user of this API requiring non-monotonic timestamps and
   breaking with monotonic ones. I think it was simply a mistake that we
   didn't make them monotonic in the first place (or maybe it wasn't even
   possible when this API was first introduced).
  
  Yea, I'd rather simply switch over to monotonic timestamps too. But that
  would break apps that already compare against the wall time for whatever
  purpose (for example A/V sync).
 
 Are there actually any such apps in the real world?

Tbh, I haven't checked, but we can't be sure in any case.

 Do they work when the wall time jumps?

They will have a problem with that yes. But providing them with a
monotonic clock when they expect otherwise will probably make them
unusable, so I think it's better to avoid that.

--Imre


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

Re: Monitor sync out of range with current Linux git tree

[Alex Deucher]

On Fri, Oct 5, 2012 at 10:15 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
 On 2012.10.05 at 10:02 -0400, Alex Deucher wrote:
 On Fri, Oct 5, 2012 at 9:38 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On 2012.10.05 at 09:14 -0400, Alex Deucher wrote:
  On Fri, Oct 5, 2012 at 8:37 AM, Markus Trippelsdorf
  mar...@trippelsdorf.de wrote:
   When I cold start my machine I see the following error message on my
   monitor:
  
Out of Range
48.2kHz / 44Hz
  
   I have to reboot on older kernel and kexec to the current one to get it
   working again.
 
  I don't see anything amiss; can you bisect?
 
  Yes. It's your commit:
 
  commit 9dbbcfc6894957fdbb311ba92c85c026659878b5
  Author: Alex Deucher alexander.deuc...@amd.com
  Date:   Wed Sep 12 17:39:57 2012 -0400
 
  drm/radeon/dce3: use a single PPLL for all DP displays

 Can you apply the attached patch and send me the output?

 [drm] == start crtc 0 driving DVI-D-1 ==
 [drm] crtc 0 is not DP
 [drm] plls in use 0x0
 [drm] crtc 0 using pll 0x1
 [drm] == end crtc 0 ==

Does the attached patch fix the issue?

Alex
From 22044ce8b98127eea9761f3dd86d70abe7dd0a09 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexander.deuc...@amd.com
Date: Fri, 5 Oct 2012 10:22:02 -0400
Subject: [PATCH] drm/radeon: allocate PPLLs from low to high

The order shouldn't matter, but there have been problems
reported on certain older asics.  This behaves more
like the original code before the PPLL allocation
rework.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/atombios_crtc.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 96184d0..2e566e1 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1690,10 +1690,10 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 		}
 		/* all other cases */
 		pll_in_use = radeon_get_pll_use_mask(crtc);
-		if (!(pll_in_use  (1  ATOM_PPLL2)))
-			return ATOM_PPLL2;
 		if (!(pll_in_use  (1  ATOM_PPLL1)))
 			return ATOM_PPLL1;
+		if (!(pll_in_use  (1  ATOM_PPLL2)))
+			return ATOM_PPLL2;
 		DRM_ERROR(unable to allocate a PPLL\n);
 		return ATOM_PPLL_INVALID;
 	} else {
@@ -1715,10 +1715,10 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
 			}
 			/* all other cases */
 			pll_in_use = radeon_get_pll_use_mask(crtc);
-			if (!(pll_in_use  (1  ATOM_PPLL2)))
-return ATOM_PPLL2;
 			if (!(pll_in_use  (1  ATOM_PPLL1)))
 return ATOM_PPLL1;
+			if (!(pll_in_use  (1  ATOM_PPLL2)))
+return ATOM_PPLL2;
 			DRM_ERROR(unable to allocate a PPLL\n);
 			return ATOM_PPLL_INVALID;
 		} else {
-- 
1.7.7.5

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

Re: Monitor sync out of range with current Linux git tree

[Markus Trippelsdorf]

On 2012.10.05 at 10:25 -0400, Alex Deucher wrote:
 On Fri, Oct 5, 2012 at 10:15 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On 2012.10.05 at 10:02 -0400, Alex Deucher wrote:
  On Fri, Oct 5, 2012 at 9:38 AM, Markus Trippelsdorf
  mar...@trippelsdorf.de wrote:
   On 2012.10.05 at 09:14 -0400, Alex Deucher wrote:
   On Fri, Oct 5, 2012 at 8:37 AM, Markus Trippelsdorf
   mar...@trippelsdorf.de wrote:
When I cold start my machine I see the following error message on my
monitor:
   
 Out of Range
 48.2kHz / 44Hz
   
I have to reboot on older kernel and kexec to the current one to get 
it
working again.
  
   I don't see anything amiss; can you bisect?
  
   Yes. It's your commit:
  
   commit 9dbbcfc6894957fdbb311ba92c85c026659878b5
   Author: Alex Deucher alexander.deuc...@amd.com
   Date:   Wed Sep 12 17:39:57 2012 -0400
  
   drm/radeon/dce3: use a single PPLL for all DP displays
 
  Can you apply the attached patch and send me the output?
 
  [drm] == start crtc 0 driving DVI-D-1 ==
  [drm] crtc 0 is not DP
  [drm] plls in use 0x0
  [drm] crtc 0 using pll 0x1
  [drm] == end crtc 0 ==
 
 Does the attached patch fix the issue?

Yes. Thanks Alex.

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

[PATCH] drm/radeon: allocate PPLLs from low to high

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

The order shouldn't matter, but there have been problems
reported on certain older asics.  This behaves more
like the original code before the PPLL allocation
rework.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc:  Markus Trippelsdorf mar...@trippelsdorf.de
---
 drivers/gpu/drm/radeon/atombios_crtc.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 96184d0..2e566e1 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1690,10 +1690,10 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
}
/* all other cases */
pll_in_use = radeon_get_pll_use_mask(crtc);
-   if (!(pll_in_use  (1  ATOM_PPLL2)))
-   return ATOM_PPLL2;
if (!(pll_in_use  (1  ATOM_PPLL1)))
return ATOM_PPLL1;
+   if (!(pll_in_use  (1  ATOM_PPLL2)))
+   return ATOM_PPLL2;
DRM_ERROR(unable to allocate a PPLL\n);
return ATOM_PPLL_INVALID;
} else {
@@ -1715,10 +1715,10 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
}
/* all other cases */
pll_in_use = radeon_get_pll_use_mask(crtc);
-   if (!(pll_in_use  (1  ATOM_PPLL2)))
-   return ATOM_PPLL2;
if (!(pll_in_use  (1  ATOM_PPLL1)))
return ATOM_PPLL1;
+   if (!(pll_in_use  (1  ATOM_PPLL2)))
+   return ATOM_PPLL2;
DRM_ERROR(unable to allocate a PPLL\n);
return ATOM_PPLL_INVALID;
} else {
-- 
1.7.7.5

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

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

[bugzilla-daemon]

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


Peter lekenst...@gmail.com changed:

   What|Removed |Added

 CC||lekenst...@gmail.com




--- Comment #1 from Peter lekenst...@gmail.com  2012-10-05 15:01:01 ---
Possibly a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=44391
(which is about Nvidia Optimus, but a solution possibly has the same patch)

So you have a MUX-less hybrid Intel / AMD setup if I am not mistaken?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HDMI ELD info failed to extract occasionally

[Jani Nikula]

On Fri, 05 Oct 2012, taiten...@gmail.com taiten...@gmail.com wrote:
 I found a potential bug for i915 regarding to ELD parsing.

 I was trying to monitor ELD by watching /proc/asound/card0/eld#3.0
 and I realized that the ELD might failed to read from HDMI when AC
 power is not plugged.  This looks like a potential hardware or driver
 issue, does anyone aware of this?

Hi Taiten, that's a bit thin on the details. What's the exact difference
you see with AC vs. battery? Is there anything special in dmesg? If not,
how about when you enable drm.debug=0xe kernel parameter? Which kernel
version are you running?

 I am also looking for the right place to file the bug, please suggest.

https://bugs.freedesktop.org/enter_bug.cgi 
Product: DRI, Component: DRM/Intel


BR,
Jani.



 lspci result
 00:02.0 VGA compatible controller: Intel Corporation Ivy Bridge Graphics
 Controller (rev 05)
 00:14.0 USB controller: Intel Corporation Panther Point USB xHCI Host
 Controller (rev 04)
 00:16.0 Communication controller: Intel Corporation Panther Point MEI
 Controller #1 (rev 04)
 00:1a.0 USB controller: Intel Corporation Panther Point USB Enhanced Host
 Controller #2 (rev 04)
 00:1b.0 Audio device: Intel Corporation Panther Point High Definition Audio
 Controller (rev 04)
 00:1c.0 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 1
 (rev c4)
 00:1c.1 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 2
 (rev c4)
 00:1d.0 USB controller: Intel Corporation Panther Point USB Enhanced Host
 Controller #1 (rev 04)
 00:1f.0 ISA bridge: Intel Corporation Panther Point LPC Controller (rev 04)
 00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller
 [RAID mode] (rev 04)
 00:1f.3 SMBus: Intel Corporation Panther Point SMBus Controller (rev 04)

 Best Regads,
 Taiten Peng
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2 v6] of: add generic videomode description

[Steffen Trumtrar]

On Thu, Oct 04, 2012 at 12:51:00PM -0600, Stephen Warren wrote:
 On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
  Get videomode from devicetree in a format appropriate for the
  backend. drm_display_mode and fb_videomode are supported atm.
  Uses the display signal timings from of_display_timings
 
  +++ b/drivers/of/of_videomode.c
 
  +int videomode_from_timing(struct display_timings *disp, struct videomode 
  *vm,
 
  +   st = display_timings_get(disp, index);
  +
  +   if (!st) {
 
 It's a little odd to leave a blank line between those two lines.

Hm, well okay. That can be remedied

 
 Only half of the code in this file seems OF-related; the routines to
 convert a timing to a videomode or drm display mode seem like they'd be
 useful outside device tree, so I wonder if putting them into
 of_videomode.c is the correct thing to do. Still, it's probably not a
 big deal.
 

I am not sure, what the appropriate way to do this is. I can split it up 
(again).


-- 
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- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2 v6] of: add helper to parse display timings

[Stephen Warren]

On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
 Hi Steffen
 
 Sorry for chiming in so late in the game, but I've long been wanting to 
 have a look at this and compare with what we do for V4L2, so, this seems a 
 great opportunity to me:-)
 
 On Thu, 4 Oct 2012, Steffen Trumtrar wrote:

 diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
 b/Documentation/devicetree/bindings/video/display-timings.txt

 +timings-subnode
 +---
 +
 +required properties:
 + - hactive, vactive: Display resolution
 + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing 
 parameters
 +   in pixels
 +   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters 
 in
 +   lines
 + - clock: displayclock in Hz
 
 You're going to hate me for this, but eventually we want to actually 
 reference clock objects in our DT bindings. For now, even if you don't 
 want to actually add clock phandles and stuff here, I think, using the 
 standard clock-frequency property would be much better!

In a definition of a display timing, we will never need to use the clock
binding; the clock binding would be used by the HW module that is
generating a timing, not by the timing definition itself.

That said, your comment about renaming the property to avoid any kind of
conceptual conflict is still quite valid. This is bike-shedding, but
pixel-clock might be more in line with typical video mode terminology,
although there's certainly preference in DT for using the generic term
clock-frequency that you proposed. Either is fine by me.

 +optional properties:
 + - hsync-active-high (bool): Hsync pulse is active high
 + - vsync-active-high (bool): Vsync pulse is active high
 
 For the above two we also considered using bool properties but eventually 
 settled down with integer ones:
 
 - hsync-active = 1
 
 for active-high and 0 for active low. This has the added advantage of 
 being able to omit this property in the .dts, which then doesn't mean, 
 that the polarity is active low, but rather, that the hsync line is not 
 used on this hardware. So, maybe it would be good to use the same binding 
 here too?

I agree. This also covers the case where analog display connectors often
use polarity to differentiate similar modes, yet digital connectors
often always use a fixed polarity since the receiving device can
measure the signal in more complete ways.

If the board HW inverts these lines, the same property names can exist
in the display controller itself, and the two values XORd together to
yield the final output polarity.

 + - de-active-high (bool): Data-Enable pulse is active high
 + - pixelclk-inverted (bool): pixelclock is inverted
 
 We don't (yet) have a de-active property in V4L, don't know whether we'll 
 ever have to distingsuish between what some datasheets call HREF and 
 HSYNC in DT, but maybe similarly to the above an integer would be 
 preferred. As for pixclk, we call the property pclk-sample and it's also 
 an integer.

Thinking about this more: de-active-high is likely to be a
board-specific property and hence something in the display controller,
not in the mode definition?

 + - interlaced (bool)
 
 Is interlaced a property of the hardware, i.e. of the board? Can the 
 same display controller on one board require interlaced data and on 
 another board - progressive?

Interlace is a property of a display mode. It's quite possible for a
particular display controller to switch between interlace and
progressive output at run-time. For example, reconfiguring the output
between 480i, 720p, 1080i, 1080p modes. Admittedly, if you're talking to
a built-in LCD display, you're probably always going to be driving the
single mode required by the panel, and that mode will likely always be
progressive. However, since this binding attempts to describe any
display timing, I think we still need this property per mode.

 BTW, I'm not very familiar with display 
 interfaces, but for interlaced you probably sometimes use a field signal, 
 whose polarity you also want to specify here? We use a field-even-active 
 integer property for it.

I think that's a property of the display controller itself, rather than
an individual mode, although I'm not 100% certain. My assertion is that
the physical interface that the display controller is driving will
determine whether embedded or separate sync is used, and in the separate
sync case, how the field signal is defined, and that all interlace modes
driven over that interface will use the same field signal definition.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2 v6] of: add helper to parse display timings

[Steffen Trumtrar]

On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote:
 Hi Steffen
 
 Sorry for chiming in so late in the game, but I've long been wanting to 
 have a look at this and compare with what we do for V4L2, so, this seems a 
 great opportunity to me:-)
 
 On Thu, 4 Oct 2012, Steffen Trumtrar wrote:
 
  Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
  ---
   .../devicetree/bindings/video/display-timings.txt  |  222 
  
   drivers/of/Kconfig |5 +
   drivers/of/Makefile|1 +
   drivers/of/of_display_timings.c|  183 
   include/linux/of_display_timings.h |   85 
   5 files changed, 496 insertions(+)
   create mode 100644 
  Documentation/devicetree/bindings/video/display-timings.txt
   create mode 100644 drivers/of/of_display_timings.c
   create mode 100644 include/linux/of_display_timings.h
  
  diff --git a/Documentation/devicetree/bindings/video/display-timings.txt 
  b/Documentation/devicetree/bindings/video/display-timings.txt
  new file mode 100644
  index 000..45e39bd
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/video/display-timings.txt
  @@ -0,0 +1,222 @@
  +display-timings bindings
  +==
  +
  +display-timings-node
  +
  +
  +required properties:
  + - none
  +
  +optional properties:
  + - default-timing: the default timing value
  +
  +timings-subnode
  +---
  +
  +required properties:
  + - hactive, vactive: Display resolution
  + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing 
  parameters
  +   in pixels
  +   vfront-porch, vback-porch, vsync-len: Vertical display timing 
  parameters in
  +   lines
  + - clock: displayclock in Hz
 
 You're going to hate me for this, but eventually we want to actually 
 reference clock objects in our DT bindings. For now, even if you don't 
 want to actually add clock phandles and stuff here, I think, using the 
 standard clock-frequency property would be much better!
 

Well, that shouldn't be a big deal, the clock-frequency property I mean :-)

  +
  +optional properties:
  + - hsync-active-high (bool): Hsync pulse is active high
  + - vsync-active-high (bool): Vsync pulse is active high
 
 For the above two we also considered using bool properties but eventually 
 settled down with integer ones:
 
 - hsync-active = 1
 
 for active-high and 0 for active low. This has the added advantage of 
 being able to omit this property in the .dts, which then doesn't mean, 
 that the polarity is active low, but rather, that the hsync line is not 
 used on this hardware. So, maybe it would be good to use the same binding 
 here too?
 

Never really thought about it that way. But the argument sounds convincing.

  + - de-active-high (bool): Data-Enable pulse is active high
  + - pixelclk-inverted (bool): pixelclock is inverted
 
 We don't (yet) have a de-active property in V4L, don't know whether we'll 
 ever have to distingsuish between what some datasheets call HREF and 
 HSYNC in DT, but maybe similarly to the above an integer would be 
 preferred. As for pixclk, we call the property pclk-sample and it's also 
 an integer.
 
  + - interlaced (bool)
 
 Is interlaced a property of the hardware, i.e. of the board? Can the 
 same display controller on one board require interlaced data and on 
 another board - progressive? BTW, I'm not very familiar with display 
 interfaces, but for interlaced you probably sometimes use a field signal, 
 whose polarity you also want to specify here? We use a field-even-active 
 integer property for it.
 

I don't really know about that; have to collect some info first.

 Thanks
 Guennadi

Thank you.

Regards,
Steffen

-- 
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- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2 v6] of: add helper to parse display timings

[Steffen Trumtrar]

On Fri, Oct 05, 2012 at 10:21:37AM -0600, Stephen Warren wrote:
 On 10/05/2012 10:16 AM, Steffen Trumtrar wrote:
  On Thu, Oct 04, 2012 at 12:47:16PM -0600, Stephen Warren wrote:
  On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
 ...
  + for_each_child_of_node(timings_np, entry) {
  + struct signal_timing *st;
  +
  + st = of_get_display_timing(entry);
  +
  + if (!st)
  + continue;
 
  I wonder if that shouldn't be an error?
  
  In the sense of a pr_err not a -EINVAL I presume?! It is a little bit quiet 
  in
  case of a faulty spec, that is right.
 
 I did mean return an error; if we try to parse something and can't,
 shouldn't we return an error?
 
 I suppose it may be possible to limp on and use whatever subset of modes
 could be parsed and drop the others, which is what this code does, but
 the code after the loop would definitely return an error if zero timings
 were parseable.

If a display supports multiple modes, I think it is better to have a working
mode (even if it is not the preferred one) than have none at all.
If there is no mode at all, that should be an error, right.

Regards,
Steffen

-- 
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- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

[bugzilla-daemon]

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





--- Comment #2 from Alessandro Pignotti alexpigna@gmail.com  2012-10-05 
17:56:21 ---
Yes my setup is as you described. The bug looks the same as this indeed
https://bugzilla.kernel.org/show_bug.cgi?id=44391

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

[bugzilla-daemon]

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


Alessandro Pignotti alexpigna@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Comment #4 from Alessandro Pignotti alexpigna@gmail.com  2012-10-05 
19:22:05 ---
Unfortunately I don't have such indicator. The windows way of solving the issue
is using a physical switch.

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

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

[bugzilla-daemon]

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





--- Comment #5 from Peter lekenst...@gmail.com  2012-10-05 19:25:38 ---
Is that a switch (left/right slide) or toggle (slide to one side and it goes
back automatically)?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

[bugzilla-daemon]

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





--- Comment #6 from Alessandro Pignotti alexpigna@gmail.com  2012-10-05 
19:36:03 ---
It's a switch. On linux I think it justs send a generic input event. So it's
implemented in software under windows.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45061] Power consumption higher after resume, probably vgaswitcheroo/radeon related

[bugzilla-daemon]

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





--- Comment #7 from Peter lekenst...@gmail.com  2012-10-05 20:00:56 ---
Thank you for letting me know. My VGA button (for switching between performance
and powersave mode) is also implemented as a software solution. When pressed, a
WMI ACPI event is generated which is processed by the Hotkey.exe program in
Windows. I guess yours works in a similar way.

Btw, are you able to test the aforementioned suspend/resume cycle in windows?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for Oct 5 (nouveau)

[Randy Dunlap]

On 10/04/2012 09:54 PM, Stephen Rothwell wrote:

 Hi all,
 
 Do not add stuff destined for v3.8 to your linux-next included branches
 until after v3.7-rc1 is released.
 
 Changes since 201201004:
 


on x86_64, when CONFIG_AGP is not enabled:

  CC [M]  drivers/gpu/drm/nouveau/nouveau_bo.o
drivers/gpu/drm/nouveau/nouveau_bo.c: In function 'nouveau_ttm_tt_create':
drivers/gpu/drm/nouveau/nouveau_bo.c:463:3: error: implicit declaration of 
function 'ttm_agp_tt_create'
drivers/gpu/drm/nouveau/nouveau_bo.c:463:3: warning: return makes pointer from 
integer without a cast
make[5]: *** [drivers/gpu/drm/nouveau/nouveau_bo.o] Error 1


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