CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Mario Kleiner]

Hi all,

there is a rather severe performance problem i accidentally found when 
trying to give Linux 3.16.0 a final test on a x86_64 MacBookPro under 
Ubuntu 14.04 LTS with nouveau as graphics driver.

I was lazy and just installed the Ubuntu precompiled mainline kernel. 
That kernel happens to have CONFIG_DMA_CMA=y set, with a default CMA 
(contiguous memory allocator) size of 64 MB. Older Ubuntu kernels 
weren't compiled with CMA, so i only observed this on 3.16, but previous 
kernels would likely be affected too.

After a few minutes of regular desktop use like switching workspaces, 
scrolling text in a terminal window, Firefox with multiple tabs open, 
Thunderbird etc. (tested with KDE/Kwin, with/without desktop 
composition), i get chunky desktop updates, then multi-second freezes, 
after a few minutes the desktop hangs for over a minute on almost any 
GUI action like switching windows etc. --> Unuseable.

ftrace'ing shows the culprit being this callchain (typical good/bad 
example ftrace snippets at the end of this mail):

...ttm dma coherent memory allocations, e.g., from 
__ttm_dma_alloc_page() ... --> dma_alloc_coherent() --> platform 
specific hooks ... -> dma_generic_alloc_coherent() [on x86_64] --> 
dma_alloc_from_contiguous()

dma_alloc_from_contiguous() is a no-op without CONFIG_DMA_CMA, or when 
the machine is booted with kernel boot cmdline parameter "cma=0", so it 
triggers the fast alloc_pages_node() fallback at least on x86_64.

With CMA, this function becomes progressively more slow with every 
minute of desktop use, e.g., runtimes going up from < 0.3 usecs to 
hundreds or thousands of microseconds (before it gives up and 
alloc_pages_node() fallback is used), so this causes the 
multi-second/minute hangs of the desktop.

So it seems ttm memory allocations quickly fragment and/or exhaust the 
CMA memory area, and dma_alloc_from_contiguous() tries very hard to find 
a fitting hole big enough to satisfy allocations with a retry loop (see 
http://lxr.free-electrons.com/source/drivers/base/dma-contiguous.c#L339) 
that takes forever.

This is not good, also not for other devices which actually need a 
non-fragmented CMA for DMA, so what to do? I doubt most current gpus 
still need physically contiguous dma memory, maybe with exception of 
some embedded gpus?

My naive approach would be to add a new gfp_t flag a la ___GFP_AVOIDCMA, 
and make callers of dma_alloc_from_contiguous() refrain from doing so if 
they have some fallback for getting memory. And then add that flag to 
ttm's ttm_dma_populate() gfp_flags, e.g., around here: 
http://lxr.free-electrons.com/source/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c#L884

However i'm not familiar enough with memory management, so likely 
greater minds here have much better ideas on how to deal with this?

thanks,
-mario

Typical snippet from an example trace of a badly stalling desktop with 
CMA (alloc_pages_node() fallback may have been missing in this traces 
ftrace_filter settings):

1)   |  ttm_dma_pool_get_pages [ttm]() {
  1)   | ttm_dma_page_pool_fill_locked [ttm]() {
  1)   | ttm_dma_pool_alloc_new_pages [ttm]() {
  1)   | __ttm_dma_alloc_page [ttm]() {
  1)   | dma_generic_alloc_coherent() {
  1) ! 1873.071 us | dma_alloc_from_contiguous();
  1) ! 1874.292 us |  }
  1) ! 1875.400 us |}
  1)   | __ttm_dma_alloc_page [ttm]() {
  1)   | dma_generic_alloc_coherent() {
  1) ! 1868.372 us | dma_alloc_from_contiguous();
  1) ! 1869.586 us |  }
  1) ! 1870.053 us |}
  1)   | __ttm_dma_alloc_page [ttm]() {
  1)   | dma_generic_alloc_coherent() {
  1) ! 1871.085 us | dma_alloc_from_contiguous();
  1) ! 1872.240 us |  }
  1) ! 1872.669 us |}
  1)   | __ttm_dma_alloc_page [ttm]() {
  1)   | dma_generic_alloc_coherent() {
  1) ! 1888.934 us | dma_alloc_from_contiguous();
  1) ! 1890.179 us |  }
  1) ! 1890.608 us |}
  1)   0.048 us| ttm_set_pages_caching [ttm]();
  1) ! 7511.000 us |  }
  1) ! 7511.306 us |}
  1) ! 7511.623 us |  }

The good case (with cma=0 kernel cmdline, so dma_alloc_from_contiguous() 
no-ops,)

0)   |  ttm_dma_pool_get_pages [ttm]() {
  0)   | ttm_dma_page_pool_fill_locked [ttm]() {
  0)   | ttm_dma_pool_alloc_new_pages [ttm]() {
  0)   | __ttm_dma_alloc_page [ttm]() {
  0)   | dma_generic_alloc_coherent() {
  0)   0.171 us| dma_alloc_from_contiguous();
  0)   0.849 us| __alloc_pages_nodemask();
  0)   3.029 us|  }
  0)   

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

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

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

--- Comment #4 from Andrei Slavoiu  ---
Created attachment 104309
  --> https://bugs.freedesktop.org/attachment.cgi?id=104309=edit
r600_debug_vs.log

Log file with R600_DEBUG=vs

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

[PATCH] drm: Use the type of the array element when reallocating

[Damien Lespiau]

Static analysers find it 'suspicious', that we're trying to allocate memory for
elements of size sizeof(struct drm_fb_helper_connector) when the array is
defined as struct drm_fb_helper_connector **.

Use sizeof(struct drm_fb_helper_connector *) instead.

Note that the structure being defined as:

struct drm_fb_helper_connector {
struct drm_connector *connector;
};

This was still doing the right thing, but may not in the future if
additional fields are added.

Cc: Todd Previte 
Cc: Dave Airlie 
Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_fb_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 44da703..63d7b8e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -126,7 +126,7 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
*fb_helper, struct drm_

WARN_ON(!mutex_is_locked(_helper->dev->mode_config.mutex));
if (fb_helper->connector_count + 1 > 
fb_helper->connector_info_alloc_count) {
-   temp = krealloc(fb_helper->connector_info, sizeof(struct 
drm_fb_helper_connector) * (fb_helper->connector_count + 1), GFP_KERNEL);
+   temp = krealloc(fb_helper->connector_info, sizeof(struct 
drm_fb_helper_connector *) * (fb_helper->connector_count + 1), GFP_KERNEL);
if (!temp)
return -ENOMEM;

-- 
1.8.3.1

[PATCH] drm: Don't return 0 for a value used as a denominator

[Damien Lespiau]

Static analysis will be unhappy if a function can theoretically return
0 and we're trying to divide by that value.

Mark that case that cannot occur as a BUG() instead.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 352f5d6..b3adf14 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1772,7 +1772,7 @@ static int drm_dp_get_vc_payload_bw(int dp_link_bw, int 
dp_link_count)
case DP_LINK_BW_5_4:
return 10 * dp_link_count;
}
-   return 0;
+   BUG();
 }

 /**
-- 
1.8.3.1

[PATCH] drm/radeon: Always flush VM again on < CIK

[Michel Dänzer]

On 08.08.2014 17:44, Christian K?nig wrote:
 On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher 
 wrote:
> We should be using PFP as much as possible.  Does the attached
> patch help?
>> Unfortunately not.
> 
> Maybe add a readback of the VM base addr pointer to make sure that the
> write has really reached the SBRM?

I'm not sure what exactly you're thinking of, but I'm happy to test any
patches you guys come up with. :)


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

[PATCH] drm/radeon: Read back ring buffer before updating WPTR

[Michel Dänzer]

From: Michel D?nzer 

This fixes a ring test failure reported on a Kabini system which was
triggered by write-combined CPU mappings of the ring buffers.

Reported-and-Tested-by: Will Trives 
Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon_ring.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index 5b4e0cf..6dff529 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -193,6 +193,10 @@ void radeon_ring_commit(struct radeon_device *rdev, struct 
radeon_ring *ring)
radeon_ring_write(ring, ring->nop);
}
mb();
+   /* This is necessary to prevent ring test failures on some systems
+* with write-combined CPU mappings of the ring buffers
+*/
+   (void)ring->ring[ring->wptr];
/* If we are emitting the HDP flush via MMIO, we need to do it after
 * all CPU writes to VRAM finished.
 */
-- 
2.0.1

Looking for a start point for fixing a bug

[Адонай Элохим]

I started looking through the code week or so ago.
No much progress though but could you explain meaning of this to me:

if (running == 0) {
if (running) {
blackout = RREG32(MC_SHARED_BLACKOUT_CNTL);
WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1);
}
...

It's in si.c, line 1564 in current master branch. Is it some
concurrent trick or so?

Thanks,
Oleg

2014-07-22 20:05 GMT+04:00 Alex Deucher :
> On Tue, Jul 22, 2014 at 8:39 AM, ?? ??  wrote:
>> Hello all!
>>
>> I have some spare time and knowledge in C to try to fix some bugs I am
>> seeing on my machine.
>> So I've checked out and compiled all git trees that I may need and now I'm
>> beginning to read articles.
>>
>> And this is the point from where I don't know where to go. I want to fix
>> particular bug #79806 [1].
>> For me there are many places where this bug can hide - mesa? dri? radeon
>> kernel module? and I just don't know whether should I start reading articles
>> about mesa hacking or about dri architecture or about kernel module
>> development.
>>
>> Now I think the best thing for me is to start looking through radeon kernel
>> module code (I've got ingenious idea that power management resides there)
>> and read more about its architecture. Is this right? I mean, I just want to
>> find out, is this a right place to start looking at for this bug?
>
> The power management is handled in the kernel driver.  See radeon_pm.c
> and the relevant *_dpm.c files depending on what asic you have.
>
> Alex
>
>>
>> P.S. Sorry for my English in case it's not good, I'm learning it now
>>
>> P.P.S. And thanks for your hard work!
>>
>> ---
>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=79806
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>

[Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

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

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

--- Comment #12 from Eugene  ---
Is it enough or may be something I did wrong ? Please tell me if so.

-- 
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/20140808/2b649f23/attachment.html>

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014? 08? 08? 16:03, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 22:55, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 22:17, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 20:09, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 18:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 15:58, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
 2014-08-06 16:43 GMT+09:00 Thierry Reding >>> gmail.com>:
> [...]
> As far as I can tell non-continuous mode simply means that the 
> host can
> turn off the HS clock after a high-speed transmission. I think 
> Andrzej
> mentioned this already in another subthread, but this is an 
> optional
> mode that peripherals can support if they have extra circuitry 
> that
> provides an internal clock. Peripherals that don't have such 
> circuitry
> may rely on the HS clock to perform in between transmissions and
> therefore require the HS clock to be always on (continuous mode). 
> That's
> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises 
> that the
> peripheral supports non-continuous mode and therefore the host 
> can turn
> the HS clock off after high-speed transmissions.

 What I don't make sure is this sentence. With
 MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
 One is,
 1. host controller will generates signals if a bit of a register
 related to non-contiguous clock mode is set or unset.
 2. And then video data is transmitted to panel in HS mode.
 3. And then D-PHY detects LP-11 signal (positive and negative lane 
 all
 are high).
 4. And then D-PHY disables HS clock of host controller.
 5. At this time, operation mode of host controller becomes LPM.

 Other is,
 1. host controller will generates signals if a bit of a register
 related to non-contiguous clock mode is set or unset.
 2. And then D-PHY detects LP-11 signal (positive and negative lane 
 all
 are high).
 3. And then video data is transmitted to panel in LPM.
 4. At this time, operation mode of host controller becomes LPM.

 It seems that you says latter case.
>>>
>>> No. High speed clock and low power mode are orthogonal. 
>>> Non-continuous
>>> mode simply means that the clock lane enters LP-11 between HS
>>> transmissions (see 5.6 "Clock Management" of the DSI specification).
>>>
>>
>> It seems that clock lane enters LP-11 regardless of HS clock enabled 
>> if
>> non-continous mode is used. Right?
>
> No, I think as long as HS clock is enabled the clock lane won't enter
> LP-11. Non-continuous mode means that the controller can disable the 
> HS
> clock between HS transmissions. So in non-continuous mode the clock 
> lane
> can enter LP-11 because the controller disables the HS clock.

 It makes me a little bit confusing. You said "if HS clock is enabled,
 the the clock lane won't enter LP-11" But you said again "the clock 
 lane
 can enter LP-11 because the controller disables the HS clock" What is
 the meaning?
>>>
>>> It means that if the HS clock is enabled, then the clock lane is not in
>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>
> In continuous mode, then the clock will never be disabled, hence the
> clock lane will never enter LP-11.
>
>> And also it seems that non-continous mode is different from LPM at 
>> all
>> because with non-continuous mode, command data is transmitted to 
>> panel
>> in HS mode, but with LPM, command data is transmitted to panel in LP
>> mode. Also right?
>
> No. I think you can send command data to the peripheral in low power
> mode in both continuous and non-continuous clock modes.
>
>> If so, shouldn't the host driver disable HS clock, in case of LP 
>> mode,
>> before the host driver transmits command data?
>
> No. If the peripheral doesn't support non-continuous mode, then the HS
> clock must never 

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

So I heard that proper pull requests have a revert on top ;-) So here we
go with my usual mid-merge-window pile of fixes.

Big fix is the duct-tape for ring init on g4x platforms, we seem to have
found the magic again to make those machines as happy as before (not
perfect though unfortunately, but that was never the case).

Otherwise fixes all over:
- tune down some overzealous debug output
- VDD power sequencing fix after resume
- bunch of dsi fixes for baytrail among them hw state checker de-noising
- bunch of error state capture fixes for bdw
- misc tiny fixes/workarounds for various platforms

Last minute rebase was to kick out two patches that shouldn't have been in
here - they're for the state checker, so 0 functional code affected.

Jani's back from vacation, so he'll take over -fixes from here.

Cc'ing Linus since you're travelling in case you want him to pick this up
directly.

Cheers, Daniel


The following changes since commit a91576d7916f6cce76d30303e60e1ac47cf4a76d:

  drm/ttm: Pass GFP flags in order to avoid deadlock. (2014-08-05 10:54:19 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08

for you to fetch changes up to be71eabebaf9f142612d34d42292b454e984dcb5:

  Revert "drm/i915: Enable semaphores on BDW" (2014-08-08 16:22:19 +0200)


Daniel Vetter (4):
  drm/i915: Update DRIVER_DATE to 20140725
  drm/i915: Don't require dev->struct_mutex in psr_match_conditions
  drm/i915: Tune done rc6 enabling output
  drm/i915: Tune down MCH_SSKPD values warning

Deepak S (1):
  drm/i915: Bring GPU Freq to min while suspending.

Imre Deak (2):
  drm/i915: factor out intel_edp_panel_vdd_sanitize
  drm/i915: fix VDD state tracking after system resume

Jiri Kosina (1):
  drm/i915: read HEAD register back in init_ring_common() to enforce 
ordering

Kenneth Graunke (2):
  drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.
  drm/i915: Add the WaCsStallBeforeStateCacheInvalidate:bdw workaround.

Mika Kuoppala (1):
  drm/i915: Don't accumulate hangcheck score on forward progress

Pavel Machek (1):
  drm/i915: work around warning in i915_gem_gtt

Rafael Barbalho (1):
  drm/i915: Fix crash when failing to parse MIPI VBT

Rodrigo Vivi (4):
  drm/i915: Fix error state collecting
  drm/i915: Collect gtier properly on HSW.
  drm/i915: Fix DEIER and GTIER collecting for BDW.
  Revert "drm/i915: Enable semaphores on BDW"

Shobhit Kumar (2):
  drm/i915: wait for all DSI FIFOs to be empty
  drm/i915: Add correct hw/sw config check for DSI encoder

Ville Syrj?l? (1):
  drm/i915: Fix threshold for choosing 32 vs. 64 precisions for VLV DDL 
values

Zhenyu Wang (1):
  drm/i915: Fix drain latency precision multipler for VLV

 drivers/gpu/drm/i915/i915_drv.c |  4 ++
 drivers/gpu/drm/i915/i915_drv.h |  3 +-
 drivers/gpu/drm/i915/i915_gem.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c | 11 +++--
 drivers/gpu/drm/i915/i915_gpu_error.c   | 35 +-
 drivers/gpu/drm/i915/i915_irq.c | 15 --
 drivers/gpu/drm/i915/i915_reg.h | 50 ++--
 drivers/gpu/drm/i915/intel_bios.c   |  2 +-
 drivers/gpu/drm/i915/intel_display.c|  4 ++
 drivers/gpu/drm/i915/intel_dp.c | 67 +++
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_dsi.c| 29 +++-
 drivers/gpu/drm/i915/intel_dsi.h|  1 +
 drivers/gpu/drm/i915/intel_dsi_cmd.c| 16 +++
 drivers/gpu/drm/i915/intel_dsi_cmd.h|  1 +
 drivers/gpu/drm/i915/intel_dsi_pll.c| 81 +
 drivers/gpu/drm/i915/intel_pm.c | 41 -
 drivers/gpu/drm/i915/intel_ringbuffer.c | 47 +--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +
 19 files changed, 310 insertions(+), 102 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 7/7] drm: Remove old defines for vswing and pre-emph values

[sonika.jin...@intel.com]

From: Sonika Jindal 

This is the last patch in the series, so remove old defines

Signed-off-by: Sonika Jindal 
---
 include/drm/drm_dp_helper.h |8 
 1 file changed, 8 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 3840a05..9305c71 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -190,23 +190,15 @@
 # define DP_TRAIN_VOLTAGE_SWING_MASK   0x3
 # define DP_TRAIN_VOLTAGE_SWING_SHIFT  0
 # define DP_TRAIN_MAX_SWING_REACHED(1 << 2)
-# define DP_TRAIN_VOLTAGE_SWING_400(0 << 0)
 # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
-# define DP_TRAIN_VOLTAGE_SWING_600(1 << 0)
 # define DP_TRAIN_VOLTAGE_SWING_LEVEL_1 (1 << 0)
-# define DP_TRAIN_VOLTAGE_SWING_800(2 << 0)
 # define DP_TRAIN_VOLTAGE_SWING_LEVEL_2 (2 << 0)
-# define DP_TRAIN_VOLTAGE_SWING_1200   (3 << 0)
 # define DP_TRAIN_VOLTAGE_SWING_LEVEL_3 (3 << 0)

 # define DP_TRAIN_PRE_EMPHASIS_MASK(3 << 3)
-# define DP_TRAIN_PRE_EMPHASIS_0   (0 << 3)
 # define DP_TRAIN_PRE_EMPH_LEVEL_0 (0 << 3)
-# define DP_TRAIN_PRE_EMPHASIS_3_5 (1 << 3)
 # define DP_TRAIN_PRE_EMPH_LEVEL_1 (1 << 3)
-# define DP_TRAIN_PRE_EMPHASIS_6   (2 << 3)
 # define DP_TRAIN_PRE_EMPH_LEVEL_2 (2 << 3)
-# define DP_TRAIN_PRE_EMPHASIS_9_5 (3 << 3)
 # define DP_TRAIN_PRE_EMPH_LEVEL_3 (3 << 3)

 # define DP_TRAIN_PRE_EMPHASIS_SHIFT   3
-- 
1.7.10.4

[PATCH 6/7] drm/tegra: Renaming DP training vswing pre emph defines

[sonika.jin...@intel.com]

From: Sonika Jindal 

Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.

Done using following cocci patch for each define:
@@
@@

 # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)

...

Signed-off-by: Sonika Jindal 
---
 drivers/gpu/drm/tegra/dpaux.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 708f783..d6b55e3 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -533,9 +533,9 @@ int tegra_dpaux_train(struct tegra_dpaux *dpaux, struct 
drm_dp_link *link,

for (i = 0; i < link->num_lanes; i++)
values[i] = DP_TRAIN_MAX_PRE_EMPHASIS_REACHED |
-   DP_TRAIN_PRE_EMPHASIS_0 |
+   DP_TRAIN_PRE_EMPH_LEVEL_0 |
DP_TRAIN_MAX_SWING_REACHED |
-   DP_TRAIN_VOLTAGE_SWING_400;
+   DP_TRAIN_VOLTAGE_SWING_LEVEL_0;

err = drm_dp_dpcd_write(>aux, DP_TRAINING_LANE0_SET, values,
link->num_lanes);
-- 
1.7.10.4

[PATCH 5/7] drm/radeon: Renaming DP training vswing pre emph defines

[sonika.jin...@intel.com]

From: Sonika Jindal 

Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.

Done using following cocci patch for each define:
@@
@@

 # define DP_TRAIN_VOLTAGE_SWING_1200 (3 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_3 (0 << 0)

...

Signed-off-by: Sonika Jindal 
---
 drivers/gpu/drm/radeon/atombios_dp.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index b1e11f8..95ea276 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -232,8 +232,8 @@ void radeon_dp_aux_init(struct radeon_connector 
*radeon_connector)

 /* general DP utility functions */

-#define DP_VOLTAGE_MAX DP_TRAIN_VOLTAGE_SWING_1200
-#define DP_PRE_EMPHASIS_MAXDP_TRAIN_PRE_EMPHASIS_9_5
+#define DP_VOLTAGE_MAX DP_TRAIN_VOLTAGE_SWING_LEVEL_3
+#define DP_PRE_EMPHASIS_MAXDP_TRAIN_PRE_EMPH_LEVEL_3

 static void dp_get_adjust_train(u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count,
-- 
1.7.10.4

[PATCH 4/7] drm/gma500: Renaming DP training vswing pre emph defines

[sonika.jin...@intel.com]

From: Sonika Jindal 

Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.

Done using following cocci patch for each define:
@@
@@

 # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)

...

Signed-off-by: Sonika Jindal 
---
 drivers/gpu/drm/gma500/cdv_intel_dp.c |4 ++--
 drivers/gpu/drm/gma500/intel_bios.c   |   16 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c 
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index a4cc0e6..9f158ea 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -1089,7 +1089,7 @@ static char   *link_train_names[] = {
 };
 #endif

-#define CDV_DP_VOLTAGE_MAX DP_TRAIN_VOLTAGE_SWING_1200
+#define CDV_DP_VOLTAGE_MAX DP_TRAIN_VOLTAGE_SWING_LEVEL_3
 /*
 static uint8_t
 cdv_intel_dp_pre_emphasis_max(uint8_t voltage_swing)
@@ -1276,7 +1276,7 @@ cdv_intel_dp_set_vswing_premph(struct gma_encoder 
*encoder, uint8_t signal_level
cdv_sb_write(dev, ddi_reg->VSwing2, 
dp_vswing_premph_table[index]);

/* ;gfx_dpio_set_reg(0x814c, 0x40802040) */
-   if ((vswing + premph) == DP_TRAIN_VOLTAGE_SWING_1200)
+   if ((vswing + premph) == DP_TRAIN_VOLTAGE_SWING_LEVEL_3)
cdv_sb_write(dev, ddi_reg->VSwing3, 0x70802040);
else
cdv_sb_write(dev, ddi_reg->VSwing3, 0x40802040);
diff --git a/drivers/gpu/drm/gma500/intel_bios.c 
b/drivers/gpu/drm/gma500/intel_bios.c
index d349734..63bde4e 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -116,30 +116,30 @@ parse_edp(struct drm_psb_private *dev_priv, struct 
bdb_header *bdb)

switch (edp_link_params->preemphasis) {
case 0:
-   dev_priv->edp.preemphasis = DP_TRAIN_PRE_EMPHASIS_0;
+   dev_priv->edp.preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_0;
break;
case 1:
-   dev_priv->edp.preemphasis = DP_TRAIN_PRE_EMPHASIS_3_5;
+   dev_priv->edp.preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_1;
break;
case 2:
-   dev_priv->edp.preemphasis = DP_TRAIN_PRE_EMPHASIS_6;
+   dev_priv->edp.preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_2;
break;
case 3:
-   dev_priv->edp.preemphasis = DP_TRAIN_PRE_EMPHASIS_9_5;
+   dev_priv->edp.preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_3;
break;
}
switch (edp_link_params->vswing) {
case 0:
-   dev_priv->edp.vswing = DP_TRAIN_VOLTAGE_SWING_400;
+   dev_priv->edp.vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
break;
case 1:
-   dev_priv->edp.vswing = DP_TRAIN_VOLTAGE_SWING_600;
+   dev_priv->edp.vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_1;
break;
case 2:
-   dev_priv->edp.vswing = DP_TRAIN_VOLTAGE_SWING_800;
+   dev_priv->edp.vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
break;
case 3:
-   dev_priv->edp.vswing = DP_TRAIN_VOLTAGE_SWING_1200;
+   dev_priv->edp.vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
break;
}
DRM_DEBUG_KMS("VBT reports EDP: VSwing  %d, Preemph %d\n",
-- 
1.7.10.4

[PATCH 3/7] drm/exynos: Renaming DP training vswing pre emph defines

[sonika.jin...@intel.com]

From: Sonika Jindal 

Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.

Done using following cocci patch for each define:
@@
@@

 # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)

...

Signed-off-by: Sonika Jindal 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 4f3c7eb..02602a8 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -329,8 +329,8 @@ static int exynos_dp_link_start(struct exynos_dp_device *dp)
return retval;

for (lane = 0; lane < lane_count; lane++)
-   buf[lane] = DP_TRAIN_PRE_EMPHASIS_0 |
-   DP_TRAIN_VOLTAGE_SWING_400;
+   buf[lane] = DP_TRAIN_PRE_EMPH_LEVEL_0 |
+   DP_TRAIN_VOLTAGE_SWING_LEVEL_0;

retval = exynos_dp_write_bytes_to_dpcd(dp, DP_TRAINING_LANE0_SET,
lane_count, buf);
-- 
1.7.10.4

[PATCH 2/7] drm/i915: Renaming DP training vswing pre emph defines

[sonika.jin...@intel.com]

From: Sonika Jindal 

Rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.

Done using following cocci patch for each define:
@@
@@

 # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)

...

Signed-off-by: Sonika Jindal 
---
 drivers/gpu/drm/i915/intel_bios.c |   16 +--
 drivers/gpu/drm/i915/intel_dp.c   |  194 ++---
 2 files changed, 105 insertions(+), 105 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 031c565..e871f68 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -627,16 +627,16 @@ parse_edp(struct drm_i915_private *dev_priv, struct 
bdb_header *bdb)

switch (edp_link_params->preemphasis) {
case EDP_PREEMPHASIS_NONE:
-   dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_0;
+   dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_0;
break;
case EDP_PREEMPHASIS_3_5dB:
-   dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_3_5;
+   dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_1;
break;
case EDP_PREEMPHASIS_6dB:
-   dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_6;
+   dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_2;
break;
case EDP_PREEMPHASIS_9_5dB:
-   dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_9_5;
+   dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_3;
break;
default:
DRM_DEBUG_KMS("VBT has unknown eDP pre-emphasis value %u\n",
@@ -646,16 +646,16 @@ parse_edp(struct drm_i915_private *dev_priv, struct 
bdb_header *bdb)

switch (edp_link_params->vswing) {
case EDP_VSWING_0_4V:
-   dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_400;
+   dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
break;
case EDP_VSWING_0_6V:
-   dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_600;
+   dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_1;
break;
case EDP_VSWING_0_8V:
-   dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_800;
+   dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
break;
case EDP_VSWING_1_2V:
-   dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_1200;
+   dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
break;
default:
DRM_DEBUG_KMS("VBT has unknown eDP voltage swing value %u\n",
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 34e3c47..01f264c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2381,13 +2381,13 @@ intel_dp_voltage_max(struct intel_dp *intel_dp)
enum port port = dp_to_dig_port(intel_dp)->port;

if (IS_VALLEYVIEW(dev))
-   return DP_TRAIN_VOLTAGE_SWING_1200;
+   return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
else if (IS_GEN7(dev) && port == PORT_A)
-   return DP_TRAIN_VOLTAGE_SWING_800;
+   return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
else if (HAS_PCH_CPT(dev) && port != PORT_A)
-   return DP_TRAIN_VOLTAGE_SWING_1200;
+   return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
else
-   return DP_TRAIN_VOLTAGE_SWING_800;
+   return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
 }

 static uint8_t
@@ -2398,49 +2398,49 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, 
uint8_t voltage_swing)

if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
-   case DP_TRAIN_VOLTAGE_SWING_400:
-   return DP_TRAIN_PRE_EMPHASIS_9_5;
-   case DP_TRAIN_VOLTAGE_SWING_600:
-   return DP_TRAIN_PRE_EMPHASIS_6;
-   case DP_TRAIN_VOLTAGE_SWING_800:
-   return DP_TRAIN_PRE_EMPHASIS_3_5;
-   case DP_TRAIN_VOLTAGE_SWING_1200:
+   case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
+   return DP_TRAIN_PRE_EMPH_LEVEL_3;
+   case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
+   return DP_TRAIN_PRE_EMPH_LEVEL_2;
+   case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
+   return DP_TRAIN_PRE_EMPH_LEVEL_1;
+   case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
default:
-   return DP_TRAIN_PRE_EMPHASIS_0;
+   return DP_TRAIN_PRE_EMPH_LEVEL_0;
}
} else if (IS_VALLEYVIEW(dev)) {
   

[PATCH 1/7] drm: Renaming DP training vswing pre emph defines

[sonika.jin...@intel.com]

From: Sonika Jindal 

Adding new defines, older one will be removed in the last patch in the series.
This is to rename the defines to have levels instead of values for vswing and
pre-emph levels as the values may differ in other scenarios like low vswing of
eDP1.4 where the values are different.

Done using following cocci patch for each define:
@@
@@

 # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
+ # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)

...
Cc: dri-devel at lists.freedesktop.org

Signed-off-by: Sonika Jindal 
---
 include/drm/drm_dp_helper.h |8 
 1 file changed, 8 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index a21568b..3840a05 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -191,15 +191,23 @@
 # define DP_TRAIN_VOLTAGE_SWING_SHIFT  0
 # define DP_TRAIN_MAX_SWING_REACHED(1 << 2)
 # define DP_TRAIN_VOLTAGE_SWING_400(0 << 0)
+# define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
 # define DP_TRAIN_VOLTAGE_SWING_600(1 << 0)
+# define DP_TRAIN_VOLTAGE_SWING_LEVEL_1 (1 << 0)
 # define DP_TRAIN_VOLTAGE_SWING_800(2 << 0)
+# define DP_TRAIN_VOLTAGE_SWING_LEVEL_2 (2 << 0)
 # define DP_TRAIN_VOLTAGE_SWING_1200   (3 << 0)
+# define DP_TRAIN_VOLTAGE_SWING_LEVEL_3 (3 << 0)

 # define DP_TRAIN_PRE_EMPHASIS_MASK(3 << 3)
 # define DP_TRAIN_PRE_EMPHASIS_0   (0 << 3)
+# define DP_TRAIN_PRE_EMPH_LEVEL_0 (0 << 3)
 # define DP_TRAIN_PRE_EMPHASIS_3_5 (1 << 3)
+# define DP_TRAIN_PRE_EMPH_LEVEL_1 (1 << 3)
 # define DP_TRAIN_PRE_EMPHASIS_6   (2 << 3)
+# define DP_TRAIN_PRE_EMPH_LEVEL_2 (2 << 3)
 # define DP_TRAIN_PRE_EMPHASIS_9_5 (3 << 3)
+# define DP_TRAIN_PRE_EMPH_LEVEL_3 (3 << 3)

 # define DP_TRAIN_PRE_EMPHASIS_SHIFT   3
 # define DP_TRAIN_MAX_PRE_EMPHASIS_REACHED  (1 << 5)
-- 
1.7.10.4

[PATCH v2 0/7] Rename DP training vswing/pre-emph defines

[sonika.jin...@intel.com]

From: Sonika Jindal 

Rename the defines to have levels instead of values for vswing and pre-emph
levels as the values may differ in other scenarios like low vswing of eDP 1.4
where the values are different.
Updated in all the drivers as well

v2: Keeping the old defines in first patch and removing them in last patch. Used
cocci semantic patch to replace the defines.

Sonika Jindal (7):
  drm: Renaming DP training vswing pre emph defines
  drm/i915: Renaming DP training vswing pre emph defines
  drm/exynos: Renaming DP training vswing pre emph defines
  drm/gma500: Renaming DP training vswing pre emph defines
  drm/radeon: Renaming DP training vswing pre emph defines
  drm/tegra: Renaming DP training vswing pre emph defines
  drm: Remove old defines for vswing and pre-emph values

 drivers/gpu/drm/exynos/exynos_dp_core.c |4 +-
 drivers/gpu/drm/gma500/cdv_intel_dp.c   |4 +-
 drivers/gpu/drm/gma500/intel_bios.c |   16 +--
 drivers/gpu/drm/i915/intel_bios.c   |   16 +--
 drivers/gpu/drm/i915/intel_dp.c |  194 +++
 drivers/gpu/drm/radeon/atombios_dp.c|4 +-
 drivers/gpu/drm/tegra/dpaux.c   |4 +-
 include/drm/drm_dp_helper.h |   16 +--
 8 files changed, 129 insertions(+), 129 deletions(-)

-- 
1.7.10.4

[PATCH] drm: Don't grab an fb reference for the idr

[Daniel Vetter]

On Fri, Aug 8, 2014 at 12:35 PM, David Herrmann  
wrote:
> Ewww, this is ugly. You now make the unregistration dynamic and it's
> no longer under driver control. The typical device-control flow
> assumes there's an authority that controls at which point objects are
> registered and unregistered. You now bind it to ref-counts. To be
> fair, I think lastclose is equally hackish (and doesn't really work
> like you argued already).

Nope, it don't bind the unregister to the refcount, I only make the
registerstration weak so that you can do such games. For all the
normal framebuffers and anything controlled by drivers we can still
unregister at any point before the final unref.

> I think the real problem is that you want two ref-counts: One
> ref-count controls the object availability, the other ref-count
> controls the visibility to user-space. This is also what gem does: you
> have a kernel-internal ref-count for each gem-object, but you also
> have user-space handles. A handle implies a kernel-internal ref-count
> but not vice versa. And the object is only accessible from user-space,
> as long as you own a handle. I think we want something similar for
> FBs. This way you could unregister the bios-FB once no handle exists
> (assuming a CRTC owns a handle as long as the FB is used as scan-out).
>
> But I guess no-one wants to implement this, so I still think this
> patch is the nicest way to make it work. So I'm fine with it.

This doesn't actually solve anything here - the problem is exactly
that this fb just exists, with no one having an access handle (beyond
the internal usage refcount) on it. Not the fbdev emulation, not
anything from userspace. But we want userspace to get at it with a
gettfb call for smooth transitions, so simply not registering it also
won't work.

The thing just hangs of a few crtcs and should survive as long as
that's the case, but as soon as it's no longer used it should get
reaped. So the right place to hook the unregistration into is really
when the last refcount goes away.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 0/9] Beaglebone-Black HDMI audio

[Ezequiel Garcia]

Hello Jyri,

On 06 Aug 04:47 PM, Jyri Sarha wrote:
> The code has a functional dependency to:
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg108199.html
> 
> Without the above patch the audio card does not probe.
> 
> The code has been rebased on top of Linux 3.16 merged with 
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
> with http://www.mail-archive.com/linux-omap at vger.kernel.org/msg108199.html
> cherry-picked on top.
> 
> All patches have gone trough some cleaning up since the RFC version of
> these patches over half a year ago.
> 

To my surprise, this worked out of the box. Did some simple tests with mpg123
and mplayer.

Tested-by: Ezequiel Garcia 

Thanks a lot!
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[PULL] drm-intel-fixes

[Linus Torvalds]

On Fri, Aug 8, 2014 at 1:52 PM, Linus Torvalds
 wrote:
>
> Got this while bisecting. I'm not sure it's related

It's not.

The actual bug was panel self refresh. It's still broken, and doesn't
work. So enabling it by default was a big mistake (commit
b6d547791fd3: "drm/i915: Enable PSR by default.")

I've reverted that commit, you guys can try again with PSR for the
next kernel release if somebody figures out how to get the damn thing
*out* of panel self-refresh (because that's what I'm assuming is going
on: the graphics may still work fine, but nothing updates on the panel
any more).

   Linus

Radeon: [TTM] Failed to find memory space for buffer [...] eviction

[Thomas Schwinge]

Hi!

I recetly repurposed a BlueMedia OPTIMA II system, Biostar MCP6P M2+
mainboard, AMD Athlon II X2 215 with 2700 MHz, 8 GiB RAM, Xen setup, for
use as a desktop machine (the Xen dom0, specifically).  I put in a
Sapphire Radeon HD 4350 card where I'm connecting the DVI output to a
portrait-oriented (1200x1920) and the VGA output to a landscape-oriented
(1440x900) monitor.  I'm running Debian GNU/Linux testing with the
Cinnamon desktop environment (Gnome Shell derivate of Gnome 2).  This is
being used as a development and all-purpose system, that is, several
virtual desktops, with mostly full-screen terminal/Emacs/web browser
processes running.  This is working nicely.

However, what happens after (irregularely) several hours of usage is that
any interactions involving the desktop get executed very sluggishly
(initially about 1 s of delay, later getting worse), which makes this
unworkable.  Once this happens, I see the following in dmesg, repeating
every once in a while:

[96450.514927] [TTM] Failed to find memory space for buffer 
0x88015daef048 eviction
[96450.514934] [TTM] No space for 88015daef048 (65536 pages, 262144K, 
256M)
[96450.514936] [TTM]   placement[0]=0x00410002 (1)
[96450.514938] [TTM] has_type: 1
[96450.514939] [TTM] use_type: 1
[96450.514940] [TTM] flags: 0x000A
[96450.514941] [TTM] gpu_offset: 0x2000
[96450.514942] [TTM] size: 262144
[96450.514943] [TTM] available_caching: 0x0007
[96450.514944] [TTM] default_caching: 0x0001
[96450.514947] [TTM]  0x-0x0001:1: used
[96450.514949] [TTM]  0x0001-0x0011:   16: used
[96450.514951] [TTM]  0x0011-0x0111:  256: used
[96450.514952] [TTM]  0x0111-0x0121:   16: used
[96450.514953] [TTM]  0x0121-0x0122:1: used
[96450.514955] [TTM]  0x0122-0x0222:  256: used
[96450.514956] [TTM]  0x0222-0x030f:  237: free
[96450.514957] [TTM]  0x030f-0x0313:4: used
[96450.514958] [TTM]  0x0313-0x61c0:24237: free
[96450.514960] [TTM]  0x61c0-0x000161c0:65536: used
[96450.514961] [TTM]  0x000161c0-0x000242fe:57662: free
[96450.514962] [TTM]  0x000242fe-0x000342fe:65536: used
[96450.514963] [TTM]  0x000342fe-0x0003d80c:38158: free
[96450.514965] [TTM]  0x0003d80c-0x0003d90c:  256: used
[96450.514966] [TTM]  0x0003d90c-0x0003ff94: 9864: free
[96450.514967] [TTM]  0x0003ff94-0x0003ffa4:   16: used
[96450.514969] [TTM]  0x0003ffa4-0x0004:   92: free
[96450.514970] [TTM]  total: 262144, used 131894 free 130250

(This looks similar to what Wolfgang S. Rupprecht had reported before,
,
unresolved, as far as I can tell.)

Switching to the Linux console, I find that one to interact normally
(without any noticeable delays), but switching back to X.org the delays
are back, too.

Originally I had been running Debian's 3.13-1-amd64 kernel, now switched
to Debian's 3.16-rc6-amd64, where I'm still seeing this happen.  Any idea
how to cure this?  (I can rebuild the kernel to test patches, I just have
no knowledge at all about this code.)

Some more data:

$ lspci
00:00.0 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a1)
00:01.0 ISA bridge: NVIDIA Corporation MCP61 LPC Bridge (rev a2)
00:01.1 SMBus: NVIDIA Corporation MCP61 SMBus (rev a2)
00:01.2 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a2)
00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a3)
00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev a3)
00:04.0 PCI bridge: NVIDIA Corporation MCP61 PCI bridge (rev a1)
00:05.0 Audio device: NVIDIA Corporation MCP61 High Definition Audio (rev 
a2)
00:06.0 IDE interface: NVIDIA Corporation MCP61 IDE (rev a2)
00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)
00:08.0 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)
00:08.1 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)
00:09.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)
00:0b.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)
00:0c.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h 
Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h 
Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h 
Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h 
Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h 
Processor Link Control
01:06.0 Ethernet controller: Realtek 

[PATCH 6/9] ARM: dts: am33xx: Add external clock provider

[Ezequiel Garcia]

On 06 Aug 04:47 PM, Jyri Sarha wrote:
> Add external clock provaider for am33xx devices.

Typo: s/provaider/provider

-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[PULL] drm-intel-fixes

[Linus Torvalds]

On Fri, Aug 8, 2014 at 12:37 PM, Linus Torvalds
 wrote:
>
> The problem seems to exist already with just the plain drm pull from
> Dave. I thought I had tested that, but apparently not.

Still busy bisecting (and it's going into the i915 part of Dave's drm
pull, so the bisect looks sane so far), but in case some i915 person
is trying to think about what it might be, it doesn't seem to be the
backlight per se.

Sometimes it resumes with the backlight on and something showing on
the screen, but no reaction to mouse or keyboard. And in fact, I have
now gotten an X lockup twice *without* doing resume/suspend, so it
seems like the whole resume/suspend thing is just a way to trigger it,
not the fundamental problem.

The machine is alive (the printscreen button takes a screenshot, for
example - I can tell by the sound), but the graphics side is hung.

This is a Sony Vaio Pro 11, so it's bog-standard intel graphics (Haswell ULT).

 Linus

[PATCH] dma-buf/fence: Fix one more kerneldoc warning

[Thierry Reding]

From: Thierry Reding 

The seqno_fence_init() function's cond argument isn't described in the
kerneldoc comment. Fix that to silence a warning when building DocBook
documentation.

Signed-off-by: Thierry Reding 
---
 include/linux/seqno-fence.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
index 3d6003de4b0d..a1ba6a5ccdd6 100644
--- a/include/linux/seqno-fence.h
+++ b/include/linux/seqno-fence.h
@@ -62,6 +62,7 @@ to_seqno_fence(struct fence *fence)
  * @context: the execution context this fence is a part of
  * @seqno_ofs: the offset within @sync_buf
  * @seqno: the sequence # to signal on
+ * @cond: fence wait condition
  * @ops: the fence_ops for operations on this seqno fence
  *
  * This function initializes a struct seqno_fence with passed parameters,
-- 
2.0.4

[PATCH] dma-buf/fence: Fix a kerneldoc warning

[Thierry Reding]

From: Thierry Reding 

kerneldoc doesn't know how to parse variables, so don't let it try.

Signed-off-by: Thierry Reding 
---
 drivers/dma-buf/fence.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index 4222cb2aa96a..7bb9d65d9a2c 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -29,7 +29,7 @@
 EXPORT_TRACEPOINT_SYMBOL(fence_annotate_wait_on);
 EXPORT_TRACEPOINT_SYMBOL(fence_emit);

-/**
+/*
  * fence context counter: each execution context should have its own
  * fence context, this allows checking if fences belong to the same
  * context or not. One device can have multiple separate contexts,
-- 
2.0.4

[PULL] drm-intel-fixes

[Linus Torvalds]

On Fri, Aug 8, 2014 at 12:19 PM, Linus Torvalds
 wrote:
> On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter  
> wrote:
>>
>>   git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08
>
> Hmm. My laptop no longer resumes properly.

The problem seems to exist already with just the plain drm pull from
Dave. I thought I had tested that, but apparently not.

  Linus

[PATCH] drm/doc: Refer to proper source file

[David Herrmann]

Hi

On Fri, Aug 8, 2014 at 11:33 AM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> Commit 21d70354bba9 ("drm: move drm_stub.c to drm_drv.c") moves the code
> from drm_stub.c into drm_drv.c. Update DocBook to include that instead.
>
> Signed-off-by: Thierry Reding 

Nice catch.

Reviewed-by: David Herrmann 

Thanks
David

> ---
>  Documentation/DocBook/drm.tmpl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index f68dbead883e..6a772b2dc514 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -315,7 +315,7 @@ char *date;
>  drm_dev_unregister() followed by a call to
>  drm_dev_unref().
>
> -!Edrivers/gpu/drm/drm_stub.c
> +!Edrivers/gpu/drm/drm_drv.c
>  
>  
>Driver Load
> --
> 2.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Don't grab an fb reference for the idr

[David Herrmann]

Hi

On Wed, Aug 6, 2014 at 9:10 AM, Daniel Vetter  wrote:
> The current refcounting scheme is that the fb lookup idr also holds a
> reference. This works out nicely bacause thus far we've always
> explicitly cleaned up idr entries for framebuffers:
> - Userspace fbs get removed in the rmfb ioctl or when the drm file
>   gets closed.
> - Kernel fbs (for fbdev emulation) get cleaned up by the driver code
>   at module unload time.
>
> But now i915 also reconstructs the bios fbs for a smooth transition.
> And that fb is purely transitional and should get removed immmediately
> once all crtcs stop using it. Of course if the i915 fbdev code decides
> to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
> in that case the fbdev code will grab it's own reference.
>
> The problem is now that we also want to register that takeover fb in
> the idr, so that userspace can do a smooth transition (animated maybe
> even!) itself. But currently we have no one who will clean up the idr
> reference once that fb isn't useful any more, and so essentially leak
> it.
>
> Fix this by no longer holding a full fb reference for the idr, but
> instead just have a weak reference using kref_get_unless_zero. But
> that requires us to synchronize and clean up with the idr and fb_lock
> in drm_framebuffer_free, so add that. It's a bit ugly that we have to
> unconditionally grab the fb_lock, but without that someone might creep
> through a race.
>
> This leak was caught by the fb leak check in drm_mode_config_cleanup.
> Originally the leak was introduced in
>
> commit 46f297fb83d4f9a6f6891964beb184664341a28b
> Author: Jesse Barnes 
> Date:   Fri Mar 7 08:57:48 2014 -0800
>
> drm/i915: add plane_config fetching infrastructure v2
>
> Cc:  Jesse Barnes 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_crtc.c | 46 
> --
>  1 file changed, 28 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index fa2be24c..33ff631c8d23 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -515,9 +515,6 @@ int drm_framebuffer_init(struct drm_device *dev, struct 
> drm_framebuffer *fb,
> if (ret)
> goto out;
>
> -   /* Grab the idr reference. */
> -   drm_framebuffer_reference(fb);
> -
> dev->mode_config.num_fb++;
> list_add(>head, >mode_config.fb_list);
>  out:
> @@ -527,10 +524,34 @@ out:
>  }
>  EXPORT_SYMBOL(drm_framebuffer_init);
>
> +/* dev->mode_config.fb_lock must be held! */
> +static void __drm_framebuffer_unregister(struct drm_device *dev,
> +struct drm_framebuffer *fb)
> +{
> +   mutex_lock(>mode_config.idr_mutex);
> +   idr_remove(>mode_config.crtc_idr, fb->base.id);
> +   mutex_unlock(>mode_config.idr_mutex);
> +
> +   fb->base.id = 0;
> +}
> +
>  static void drm_framebuffer_free(struct kref *kref)
>  {
> struct drm_framebuffer *fb =
> container_of(kref, struct drm_framebuffer, refcount);
> +   struct drm_device *dev = fb->dev;
> +
> +   /*
> +* The lookup idr holds a weak reference, which has not necessarily 
> been
> +* removed at this point. Check for that.
> +*/
> +   mutex_lock(>mode_config.fb_lock);
> +   if (fb->base.id) {
> +   /* Mark fb as reaped and drop idr ref. */
> +   __drm_framebuffer_unregister(dev, fb);
> +   }
> +   mutex_unlock(>mode_config.fb_lock);

Ewww, this is ugly. You now make the unregistration dynamic and it's
no longer under driver control. The typical device-control flow
assumes there's an authority that controls at which point objects are
registered and unregistered. You now bind it to ref-counts. To be
fair, I think lastclose is equally hackish (and doesn't really work
like you argued already).

I think the real problem is that you want two ref-counts: One
ref-count controls the object availability, the other ref-count
controls the visibility to user-space. This is also what gem does: you
have a kernel-internal ref-count for each gem-object, but you also
have user-space handles. A handle implies a kernel-internal ref-count
but not vice versa. And the object is only accessible from user-space,
as long as you own a handle. I think we want something similar for
FBs. This way you could unregister the bios-FB once no handle exists
(assuming a CRTC owns a handle as long as the FB is used as scan-out).

But I guess no-one wants to implement this, so I still think this
patch is the nicest way to make it work. So I'm fine with it.

Thanks
David

> +
> fb->funcs->destroy(fb);
>  }
>
> @@ -567,8 +588,10 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct 
> drm_device *dev,
>
> mutex_lock(>mode_config.fb_lock);
> fb = __drm_framebuffer_lookup(dev, id);
> -   if 

[PULL] drm-intel-fixes

[Linus Torvalds]

On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter  wrote:
>
>   git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08

Hmm. My laptop no longer resumes properly.

Or rather, I suspect it resumes, but the screen is black.

I will bisect, and I *will* revert if I find the offending commit. I
need that laptop for travel next week.

Linus

Dual-channel DSI

[Thierry Reding]

l above, and I
don't know if it's worth the trouble. Anyway, it would be good to hear
thoughts on this from the device tree maintainers.

> >> I am not sure if it is better. If you do not like video
> >> interfaces
> >> maybe better would be sth like this:
> >>
> >>dsi at 5430 {
> >>panel: panel at 0 {
> >>compatible = "sharp,lq101r1sx01";
> >>reg = <0>;
> >>secondary_dsi = <>;
> >>};
> >>};
> >>
> >>dsiB: dsi at 5440 {
> >>};
> > That's pretty much the same thing that I proposed, except that it
> > reverses the link between the two.
> For me it is fundamentally different - in your proposition you have two
> different panels, in my you have only one, attached to one dsi with
> phandle to 2nd dsi.

Looking at the example again I don't see how it could work. The phandle
references the second DSI host, but we need a reference to the second
DSI peripheral. We can't just assume that it's on the same virtual
channel as the first.

> > In fact I tried something similar to
> > that before, but it has a couple of problems: if the secondary device
> > does not have a compatible string (that's probably not valid in device
> > tree to begin with) then there's no way for the device to report what
> > format it expects or what number of lanes it uses. But those are
> > parameters that are needed to set up the DSI (and display controllers).
> 
> I2C has:
> struct i2c_client *
> i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
> 
> DSI could have something similar, this way you could pass everything you
> need.

We don't need any of that if both devices have a proper compatible
string, which they should have anyway, since then the driver can fill in
those values as appropriate.

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

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Thierry Reding]

 don't think any transmissions can happen when all lanes are in
> >>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
> >>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
> >>>>>>> "Definitions" of the MIPI DSI specification).
> >>>>>>>
> >>>>>>
> >>>>>> Hm.. I see. I meant,
> >>>>>>
> >>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
> >>>>>>disable HS clock <- required.
> >>>>>>
> >>>>>> transmit command data <- in LPM.
> >>>>>
> >>>>> No. Disabling the HS clock is not required for LPM mode. In fact if the
> >>>>> peripheral specifies that it doesn't support non-continuous mode then
> >>>>> the HS clock must *never* be disabled as long as the peripheral is in
> >>>>> use.
> >>>>>
> >>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
> >>>>> need to be considered separately.
> >>>>
> >>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
> >>>>
> >>>> It seems that you say the only way to transfer command data in LPM is
> >>>> non-continuous clock mode.
> >>>
> >>> No, that's not what I'm saying.
> >>>
> >>>> However, you said and also the spec says, "Non-continuous mode simply
> >>>> means that the clock lane enters LP-11 between HS transmissions".
> >>>> Doesn't *between HS transmissions" mean the command data is transmitted
> >>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
> >>>
> >>> Not necessarily. You can transmit command packets in high-speed mode,
> >>> but you don't have to. If you transmit packets in low power mode, then
> >>
> >> That would may why we are mentioning same comments repeatedly.
> >>
> >> In my case, host driver waits for the lane stop state (LP-11), and then
> >> disables HS clock to transmit command data in LPM. Of course, I'm not
> >> sure that yet it's correct way.
> > 
> > That's confusing. How can the lane go to LP-11 when the clock is still
> > running?
> 
> Actually, we are doing so. If the clock is still running then dsi driver
> will wait for stop state of the clock and data lanes. Know that this is
> valid only when initial time - just one time since power up.
> 
>   /* Check clock and data lane state are stop state */
>   timeout = 100;
>   do {
>   if (timeout-- == 0) {
>   dev_err(dsi->dev, "waiting for bus lanes timed out\n");
>   return -EFAULT;
>   }
> 
>   reg = readl(dsi->reg_base + DSIM_STATUS_REG);
>   if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
>   != DSIM_STOP_STATE_DAT(lanes_mask))
>   continue;
>   } while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
> 
> > 
> >> In Tegra, What to do for it?
> > 
> > There are two bits in two separate registers for this:
> > 
> > DSI_HOST_CONTROL:
> >   bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
> >packets
> > - 0 = LOW: low speed
> > - 1 = HIGH: high speed
> > 
> > DSI_CONTROL:
> >   bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
> > - 0 = CONTINUOUS: HS clock is on all the time
> > - 1 = TX_ONLY: HS clock is only active during HS
> >transmissions
> > 
> > So if the peripheral supports non-continuous mode of operation we set
> > the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
> > remains on all the time.
> >
> > When a packet is to be transmitted in high speed mode, we set the
> > DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
> > cleared.
> 
> That is exactly what I want. In your case, if you want to transmit
> command data in Low Power Mode in case of supporting non-continuous
> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
> would clear DSI_HIGH_SPEED_TRANS (LOW).
> 
> So I guess,
> 
> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
> disable DSI_HIGH_SPEED_TRANS;   <- LOW
> enable DSI_HS_CLK_CTRL; <- TX_ONLY
> }
> 
> transmit command data <- in LPM.
> 
> However, what if the peripheral doesn't support non-continuous but want
> to transmit command data in LPM? Is that  impossible?

The above is actually more like this:

if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
clear DSI_HS_CLK_CTRL;
else
set DSI_HS_CLK_CTRL;

if (msg->flags & MIPI_DSI_MSG_USE_LPM)
clear DSI_HIGH_SPEED_TRANS;
else
set DSI_HIGH_SPEED_TRANS;

So for peripherals that don't support non-continuous clock mode, this
will result in the following for low-power transmissions:

clear DSI_HS_CLK_CTRL; /* HS clock always on */
clear DSI_HIGH_SPEED_TRANS;

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

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Andrzej Hajda]

On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
> On 08/08/2014 09:37 AM, Inki Dae wrote:
>> On 2014? 08? 08? 16:03, Thierry Reding wrote:
>>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
 On 2014? 08? 07? 22:55, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 22:17, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 20:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 18:09, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 15:58, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>> 2014-08-06 16:43 GMT+09:00 Thierry Reding > gmail.com>:
>>> [...]
>>> As far as I can tell non-continuous mode simply means that the 
>>> host can
>>> turn off the HS clock after a high-speed transmission. I think 
>>> Andrzej
>>> mentioned this already in another subthread, but this is an 
>>> optional
>>> mode that peripherals can support if they have extra circuitry 
>>> that
>>> provides an internal clock. Peripherals that don't have such 
>>> circuitry
>>> may rely on the HS clock to perform in between transmissions and
>>> therefore require the HS clock to be always on (continuous 
>>> mode). That's
>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises 
>>> that the
>>> peripheral supports non-continuous mode and therefore the host 
>>> can turn
>>> the HS clock off after high-speed transmissions.
>> What I don't make sure is this sentence. With
>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
>> operations.
>> One is,
>> 1. host controller will generates signals if a bit of a register
>> related to non-contiguous clock mode is set or unset.
>> 2. And then video data is transmitted to panel in HS mode.
>> 3. And then D-PHY detects LP-11 signal (positive and negative 
>> lane all
>> are high).
>> 4. And then D-PHY disables HS clock of host controller.
>> 5. At this time, operation mode of host controller becomes LPM.
>>
>> Other is,
>> 1. host controller will generates signals if a bit of a register
>> related to non-contiguous clock mode is set or unset.
>> 2. And then D-PHY detects LP-11 signal (positive and negative 
>> lane all
>> are high).
>> 3. And then video data is transmitted to panel in LPM.
>> 4. At this time, operation mode of host controller becomes LPM.
>>
>> It seems that you says latter case.
> No. High speed clock and low power mode are orthogonal. 
> Non-continuous
> mode simply means that the clock lane enters LP-11 between HS
> transmissions (see 5.6 "Clock Management" of the DSI 
> specification).
>
 It seems that clock lane enters LP-11 regardless of HS clock 
 enabled if
 non-continous mode is used. Right?
>>> No, I think as long as HS clock is enabled the clock lane won't 
>>> enter
>>> LP-11. Non-continuous mode means that the controller can disable 
>>> the HS
>>> clock between HS transmissions. So in non-continuous mode the clock 
>>> lane
>>> can enter LP-11 because the controller disables the HS clock.
>> It makes me a little bit confusing. You said "if HS clock is enabled,
>> the the clock lane won't enter LP-11" But you said again "the clock 
>> lane
>> can enter LP-11 because the controller disables the HS clock" What is
>> the meaning?
> It means that if the HS clock is enabled, then the clock lane is not 
> in
> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>
>>> In continuous mode, then the clock will never be disabled, hence the
>>> clock lane will never enter LP-11.
>>>
 And also it seems that non-continous mode is different from LPM at 
 all
 because with non-continuous mode, command data is transmitted to 
 panel
 in HS mode, but with LPM, command data is transmitted to panel in 
 LP
 mode. Also right?
>>> No. I think you can send command data to the peripheral in low power
>>> mode in both continuous and non-continuous clock modes.
>>>

[PATCH] drm/radeon: Always flush VM again on < CIK

[Michel Dänzer]

On 08.08.2014 00:55, Alex Deucher wrote:
> 
> Note that there is no PFP (or CE) on the compute queues so we can't
> use PFP (or CE) for compute.

AFAICT cik_hdp_flush_cp_ring_emit() always uses the PFP though.


> Note also that the engine bit is not always consistent (for some packets 0
> = ME, 1 = PFP and for others 1= ME and 0 = PFP).

Ugh. Then we should probably use explicit *_ENGINE_PFP/ME macros instead
of *_ENGINE(lucky_number). :)


>> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher  
>> wrote:
>>>
>>> We should be using PFP as much as possible.  Does the attached patch help?

Unfortunately not.


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

[PATCH] drm/doc: Refer to proper source file

[Thierry Reding]

From: Thierry Reding 

Commit 21d70354bba9 ("drm: move drm_stub.c to drm_drv.c") moves the code
from drm_stub.c into drm_drv.c. Update DocBook to include that instead.

Signed-off-by: Thierry Reding 
---
 Documentation/DocBook/drm.tmpl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index f68dbead883e..6a772b2dc514 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -315,7 +315,7 @@ char *date;
 drm_dev_unregister() followed by a call to
 drm_dev_unref().
   
-!Edrivers/gpu/drm/drm_stub.c
+!Edrivers/gpu/drm/drm_drv.c
 
 
   Driver Load
-- 
2.0.4

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Andrzej Hajda]

On 08/08/2014 09:37 AM, Inki Dae wrote:
> On 2014? 08? 08? 16:03, Thierry Reding wrote:
>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 22:55, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
> On 2014? 08? 07? 22:17, Thierry Reding wrote:
>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 20:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
> On 2014? 08? 07? 18:09, Thierry Reding wrote:
>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 15:58, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> 2014-08-06 16:43 GMT+09:00 Thierry Reding  gmail.com>:
>> [...]
>> As far as I can tell non-continuous mode simply means that the 
>> host can
>> turn off the HS clock after a high-speed transmission. I think 
>> Andrzej
>> mentioned this already in another subthread, but this is an 
>> optional
>> mode that peripherals can support if they have extra circuitry 
>> that
>> provides an internal clock. Peripherals that don't have such 
>> circuitry
>> may rely on the HS clock to perform in between transmissions and
>> therefore require the HS clock to be always on (continuous 
>> mode). That's
>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises 
>> that the
>> peripheral supports non-continuous mode and therefore the host 
>> can turn
>> the HS clock off after high-speed transmissions.
> What I don't make sure is this sentence. With
> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
> operations.
> One is,
> 1. host controller will generates signals if a bit of a register
> related to non-contiguous clock mode is set or unset.
> 2. And then video data is transmitted to panel in HS mode.
> 3. And then D-PHY detects LP-11 signal (positive and negative 
> lane all
> are high).
> 4. And then D-PHY disables HS clock of host controller.
> 5. At this time, operation mode of host controller becomes LPM.
>
> Other is,
> 1. host controller will generates signals if a bit of a register
> related to non-contiguous clock mode is set or unset.
> 2. And then D-PHY detects LP-11 signal (positive and negative 
> lane all
> are high).
> 3. And then video data is transmitted to panel in LPM.
> 4. At this time, operation mode of host controller becomes LPM.
>
> It seems that you says latter case.
 No. High speed clock and low power mode are orthogonal. 
 Non-continuous
 mode simply means that the clock lane enters LP-11 between HS
 transmissions (see 5.6 "Clock Management" of the DSI 
 specification).

>>> It seems that clock lane enters LP-11 regardless of HS clock 
>>> enabled if
>>> non-continous mode is used. Right?
>> No, I think as long as HS clock is enabled the clock lane won't enter
>> LP-11. Non-continuous mode means that the controller can disable the 
>> HS
>> clock between HS transmissions. So in non-continuous mode the clock 
>> lane
>> can enter LP-11 because the controller disables the HS clock.
> It makes me a little bit confusing. You said "if HS clock is enabled,
> the the clock lane won't enter LP-11" But you said again "the clock 
> lane
> can enter LP-11 because the controller disables the HS clock" What is
> the meaning?
 It means that if the HS clock is enabled, then the clock lane is not in
 LP-11. When the HS clock stops, then the clock lane enters LP-11.

>> In continuous mode, then the clock will never be disabled, hence the
>> clock lane will never enter LP-11.
>>
>>> And also it seems that non-continous mode is different from LPM at 
>>> all
>>> because with non-continuous mode, command data is transmitted to 
>>> panel
>>> in HS mode, but with LPM, command data is transmitted to panel in LP
>>> mode. Also right?
>> No. I think you can send command data to the peripheral in low power
>> mode in both continuous and non-continuous clock modes.
>>
>>> If so, shouldn't the host driver disable HS clock, in case of LP 
>>> mode,
>>> before the host driver transmits command data?
>> No. If the 

[PULL] drm-intel-fixes

[Linus Torvalds]

On Fri, Aug 8, 2014 at 10:30 AM, Linus Torvalds
 wrote:
>
> This is a Sony Vaio Pro 11, so it's bog-standard intel graphics (Haswell ULT).

Got this while bisecting. I'm not sure it's related, the behavior was
a bit different from the other cases. So I'll try to continue
bisecting, but am a bit worried that there are two possibly unrelated
problems here..

   [ cut here ]
   WARNING: CPU: 0 PID: 1074 at
drivers/gpu/drm/i915/intel_display.c:1234 intel_enable_pipe+0x3f/0x200
[i915]()
   cursor on pipe A assertion failure (expected off, current on)
   Modules linked in: rfcomm fuse ccm ip6t_rpfilter ip6t_REJECT
xt_conntrack mmc_block ebtable_nat ebtable_broute bridge stp llc
ebtable_filter ebtables ip6table_nat n$
snd_pcm media btusb bluetooth hid_multitouch iwlwifi snd_timer
rtsx_pci i2c_i801 cfg80211 lpc_ich mfd_core mei_me snd mei shpchp
soundcore sony_laptop rfkill dm_cr$
   CPU: 0 PID: 1074 Comm: Xorg Not tainted 3.16.0-rc4-00378-g4dac3edfe68e #15
   Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS R0270V7 05/17/2013
   Call Trace:
 ? dump_stack+0x41/0x51
 ? warn_slowpath_common+0x6d/0x90
 ? warn_slowpath_fmt+0x47/0x50
 ? intel_enable_pipe+0x3f/0x200 [i915]
 ? haswell_crtc_enable+0x425/0xa70 [i915]
 ? intel_crtc_update_dpms+0x5e/0x70 [i915]
 ? intel_connector_dpms+0x39/0x70 [i915]
 ? drm_mode_obj_set_property_ioctl+0x396/0x3b0 [drm]
 ? drm_mode_connector_property_set_ioctl+0x29/0x30 [drm]
 ? drm_ioctl+0x178/0x580 [drm]
 ? do_vfs_ioctl+0x2cf/0x4b0
 ? file_has_perm+0x86/0xa0
 ? __audit_syscall_exit+0x151/0x2a0
 ? SyS_ioctl+0x79/0x90
 ? __audit_syscall_exit+0x1f6/0x2a0
 ? system_call_fastpath+0x16/0x1b
   ---[ end trace 86461bbc6e1418cd ]---

Does that make sense to anybody?

  Linus

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014? 08? 07? 22:55, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 22:17, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 20:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 18:09, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 15:58, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>> 2014-08-06 16:43 GMT+09:00 Thierry Reding > gmail.com>:
>>> [...]
>>> As far as I can tell non-continuous mode simply means that the host 
>>> can
>>> turn off the HS clock after a high-speed transmission. I think 
>>> Andrzej
>>> mentioned this already in another subthread, but this is an optional
>>> mode that peripherals can support if they have extra circuitry that
>>> provides an internal clock. Peripherals that don't have such 
>>> circuitry
>>> may rely on the HS clock to perform in between transmissions and
>>> therefore require the HS clock to be always on (continuous mode). 
>>> That's
>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that 
>>> the
>>> peripheral supports non-continuous mode and therefore the host can 
>>> turn
>>> the HS clock off after high-speed transmissions.
>>
>> What I don't make sure is this sentence. With
>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations.
>> One is,
>> 1. host controller will generates signals if a bit of a register
>> related to non-contiguous clock mode is set or unset.
>> 2. And then video data is transmitted to panel in HS mode.
>> 3. And then D-PHY detects LP-11 signal (positive and negative lane 
>> all
>> are high).
>> 4. And then D-PHY disables HS clock of host controller.
>> 5. At this time, operation mode of host controller becomes LPM.
>>
>> Other is,
>> 1. host controller will generates signals if a bit of a register
>> related to non-contiguous clock mode is set or unset.
>> 2. And then D-PHY detects LP-11 signal (positive and negative lane 
>> all
>> are high).
>> 3. And then video data is transmitted to panel in LPM.
>> 4. At this time, operation mode of host controller becomes LPM.
>>
>> It seems that you says latter case.
>
> No. High speed clock and low power mode are orthogonal. Non-continuous
> mode simply means that the clock lane enters LP-11 between HS
> transmissions (see 5.6 "Clock Management" of the DSI specification).
>

 It seems that clock lane enters LP-11 regardless of HS clock enabled if
 non-continous mode is used. Right?
>>>
>>> No, I think as long as HS clock is enabled the clock lane won't enter
>>> LP-11. Non-continuous mode means that the controller can disable the HS
>>> clock between HS transmissions. So in non-continuous mode the clock lane
>>> can enter LP-11 because the controller disables the HS clock.
>>
>> It makes me a little bit confusing. You said "if HS clock is enabled,
>> the the clock lane won't enter LP-11" But you said again "the clock lane
>> can enter LP-11 because the controller disables the HS clock" What is
>> the meaning?
>
> It means that if the HS clock is enabled, then the clock lane is not in
> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>
>>> In continuous mode, then the clock will never be disabled, hence the
>>> clock lane will never enter LP-11.
>>>
 And also it seems that non-continous mode is different from LPM at all
 because with non-continuous mode, command data is transmitted to panel
 in HS mode, but with LPM, command data is transmitted to panel in LP
 mode. Also right?
>>>
>>> No. I think you can send command data to the peripheral in low power
>>> mode in both continuous and non-continuous clock modes.
>>>
 If so, shouldn't the host driver disable HS clock, in case of LP mode,
 before the host driver transmits command data?
>>>
>>> No. If the peripheral doesn't support non-continuous mode, then the HS
>>> clock must never be turned off. On the other hand, if the peripheral
>>> supports non-continuous mode, then the DSI host should automatically
>>> disable the HS clock between high-speed transmissions. That means if a
>>> packet is transmitted in low power mode the DSI host will not be
>>> transmitting in high-speed mode and therefore disable the HS clock.
>>
>> What is LPM you think? I thought LPM 

[PATCH] drm/radeon: Always flush VM again on < CIK

[Christian König]

>>> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher  
>>> wrote:
 We should be using PFP as much as possible.  Does the attached patch help?
> Unfortunately not.

Maybe add a readback of the VM base addr pointer to make sure that the 
write has really reached the SBRM?

Otherwise I'm out of ideas as well,
Christian.


Am 08.08.2014 um 04:38 schrieb Michel D?nzer:
> On 08.08.2014 00:55, Alex Deucher wrote:
>> Note that there is no PFP (or CE) on the compute queues so we can't
>> use PFP (or CE) for compute.
> AFAICT cik_hdp_flush_cp_ring_emit() always uses the PFP though.
>
>
>> Note also that the engine bit is not always consistent (for some packets 0
>> = ME, 1 = PFP and for others 1= ME and 0 = PFP).
> Ugh. Then we should probably use explicit *_ENGINE_PFP/ME macros instead
> of *_ENGINE(lucky_number). :)
>
>
>>> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher  
>>> wrote:
 We should be using PFP as much as possible.  Does the attached patch help?
> Unfortunately not.
>
>

[PATCH 2/2] Enables gem prime helpers for qxl using dummy driver callbacks

[Andreas Pokorny]

As there should not be any other virtual device that might share buffers,
the callbacks remain empty stubs. Still prime can be used to transfer buffers
between processes that use qxl.

Signed-off-by: Andreas Pokorny 
---
 drivers/gpu/drm/qxl/Makefile|  2 +-
 drivers/gpu/drm/qxl/qxl_drv.c   | 13 +++-
 drivers/gpu/drm/qxl/qxl_drv.h   | 12 +++
 drivers/gpu/drm/qxl/qxl_prime.c | 72 +
 4 files changed, 97 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/qxl/qxl_prime.c

diff --git a/drivers/gpu/drm/qxl/Makefile b/drivers/gpu/drm/qxl/Makefile
index ea046ba..3579369 100644
--- a/drivers/gpu/drm/qxl/Makefile
+++ b/drivers/gpu/drm/qxl/Makefile
@@ -4,6 +4,6 @@

 ccflags-y := -Iinclude/drm

-qxl-y := qxl_drv.o qxl_kms.o qxl_display.o qxl_ttm.o qxl_fb.o qxl_object.o 
qxl_gem.o qxl_cmd.o qxl_image.o qxl_draw.o qxl_debugfs.o qxl_irq.o qxl_dumb.o 
qxl_ioctl.o qxl_fence.o qxl_release.o
+qxl-y := qxl_drv.o qxl_kms.o qxl_display.o qxl_ttm.o qxl_fb.o qxl_object.o 
qxl_gem.o qxl_cmd.o qxl_image.o qxl_draw.o qxl_debugfs.o qxl_irq.o qxl_dumb.o 
qxl_ioctl.o qxl_fence.o qxl_release.o qxl_prime.o

 obj-$(CONFIG_DRM_QXL)+= qxl.o
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 005dd18..f372e1b 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -227,7 +227,7 @@ static struct pci_driver qxl_pci_driver = {
 };

 static struct drm_driver qxl_driver = {
-   .driver_features = DRIVER_GEM | DRIVER_MODESET |
+   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
.load = qxl_driver_load,
.unload = qxl_driver_unload,
@@ -242,6 +242,17 @@ static struct drm_driver qxl_driver = {
.debugfs_init = qxl_debugfs_init,
.debugfs_cleanup = qxl_debugfs_takedown,
 #endif
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .gem_prime_export = drm_gem_prime_export,
+   .gem_prime_import = drm_gem_prime_import,
+   .gem_prime_pin = qxl_gem_prime_pin,
+   .gem_prime_unpin = qxl_gem_prime_unpin,
+   .gem_prime_get_sg_table = qxl_gem_prime_get_sg_table,
+   .gem_prime_import_sg_table = qxl_gem_prime_import_sg_table,
+   .gem_prime_vmap = qxl_gem_prime_vmap,
+   .gem_prime_vunmap = qxl_gem_prime_vunmap,
+   .gem_prime_mmap = qxl_gem_prime_mmap,
.gem_free_object = qxl_gem_object_free,
.gem_open_object = qxl_gem_object_open,
.gem_close_object = qxl_gem_object_close,
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 36ed40b..46402b9 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -532,6 +532,18 @@ int qxl_garbage_collect(struct qxl_device *qdev);
 int qxl_debugfs_init(struct drm_minor *minor);
 void qxl_debugfs_takedown(struct drm_minor *minor);

+/* qxl_prime.c */
+int qxl_gem_prime_pin(struct drm_gem_object *obj);
+void qxl_gem_prime_unpin(struct drm_gem_object *obj);
+struct sg_table *qxl_gem_prime_get_sg_table(struct drm_gem_object *obj);
+struct drm_gem_object *qxl_gem_prime_import_sg_table(
+   struct drm_device *dev, size_t size,
+   struct sg_table *sgt);
+void *qxl_gem_prime_vmap(struct drm_gem_object *obj);
+void qxl_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
+int qxl_gem_prime_mmap(struct drm_gem_object *obj,
+   struct vm_area_struct *vma);
+
 /* qxl_irq.c */
 int qxl_irq_init(struct qxl_device *qdev);
 irqreturn_t qxl_irq_handler(int irq, void *arg);
diff --git a/drivers/gpu/drm/qxl/qxl_prime.c b/drivers/gpu/drm/qxl/qxl_prime.c
new file mode 100644
index 000..ba0689c
--- /dev/null
+++ b/drivers/gpu/drm/qxl/qxl_prime.c
@@ -0,0 +1,72 @@
+/*
+ * Copyright 2014 Canonical
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: 

[PATCH 1/2] Simple crtc page flipping emulated using buffer copy

[Andreas Pokorny]

Signed-off-by: Andreas Pokorny 
---
 drivers/gpu/drm/qxl/qxl_display.c | 49 +++
 drivers/gpu/drm/qxl/qxl_drv.c | 18 ++
 drivers/gpu/drm/qxl/qxl_kms.c | 16 +
 3 files changed, 79 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index b8ced08..af9e785 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -187,6 +187,54 @@ static void qxl_crtc_destroy(struct drm_crtc *crtc)
kfree(qxl_crtc);
 }

+static int qxl_crtc_page_flip(struct drm_crtc *crtc,
+  struct drm_framebuffer *fb,
+  struct drm_pending_vblank_event *event,
+  uint32_t page_flip_flags)
+{
+   struct drm_device *dev = crtc->dev;
+   struct qxl_device *qdev = dev->dev_private;
+   struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
+   struct qxl_framebuffer *qfb_src = to_qxl_framebuffer(fb);
+   struct qxl_framebuffer *qfb_old = to_qxl_framebuffer(crtc->primary->fb);
+   struct qxl_bo *bo_old = gem_to_qxl_bo(qfb_old->obj);
+   struct qxl_bo *bo = gem_to_qxl_bo(qfb_src->obj);
+   unsigned long flags;
+   struct drm_clip_rect norect = {
+   .x1 = 0,
+   .y1 = 0,
+   .x2 = fb->width,
+   .y2 = fb->height
+   };
+   int inc = 1;
+   int one_clip_rect = 1;
+   int ret = 0;
+
+   crtc->primary->fb = fb;
+   bo_old->is_primary = false;
+   bo->is_primary = true;
+
+   ret = qxl_bo_reserve(bo, false);
+   if (ret)
+   return ret;
+
+   qxl_draw_dirty_fb(qdev, qfb_src, bo, 0, 0,
+ , one_clip_rect, inc);
+
+   drm_vblank_get(dev, qcrtc->index);
+
+   if (event) {
+   spin_lock_irqsave(>event_lock, flags);
+   drm_send_vblank_event(dev, qcrtc->index, event);
+   spin_unlock_irqrestore(>event_lock, flags);
+   }
+   drm_vblank_put(dev, qcrtc->index);
+
+   qxl_bo_unreserve(bo);
+
+   return 0;
+}
+
 static int
 qxl_hide_cursor(struct qxl_device *qdev)
 {
@@ -374,6 +422,7 @@ static const struct drm_crtc_funcs qxl_crtc_funcs = {
.cursor_move = qxl_crtc_cursor_move,
.set_config = drm_crtc_helper_set_config,
.destroy = qxl_crtc_destroy,
+   .page_flip = qxl_crtc_page_flip,
 };

 static void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 6e93663..005dd18 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -84,6 +84,7 @@ static const struct file_operations qxl_fops = {
.release = drm_release,
.unlocked_ioctl = drm_ioctl,
.poll = drm_poll,
+   .read = drm_read,
.mmap = qxl_mmap,
 };

@@ -195,6 +196,20 @@ static int qxl_pm_restore(struct device *dev)
return qxl_drm_resume(drm_dev, false);
 }

+static u32 qxl_noop_get_vblank_counter(struct drm_device *dev, int crtc)
+{
+   return dev->vblank[crtc].count.counter;
+}
+
+static int qxl_noop_enable_vblank(struct drm_device *dev, int crtc)
+{
+   return 0;
+}
+
+static void qxl_noop_disable_vblank(struct drm_device *dev, int crtc)
+{
+}
+
 static const struct dev_pm_ops qxl_pm_ops = {
.suspend = qxl_pm_suspend,
.resume = qxl_pm_resume,
@@ -216,6 +231,9 @@ static struct drm_driver qxl_driver = {
   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
.load = qxl_driver_load,
.unload = qxl_driver_unload,
+   .get_vblank_counter = qxl_noop_get_vblank_counter,
+   .enable_vblank = qxl_noop_enable_vblank,
+   .disable_vblank = qxl_noop_disable_vblank,

.dumb_create = qxl_mode_dumb_create,
.dumb_map_offset = qxl_mode_dumb_mmap,
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index fd88eb4..853f13b 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -297,6 +297,9 @@ int qxl_driver_unload(struct drm_device *dev)

if (qdev == NULL)
return 0;
+
+   drm_vblank_cleanup(dev);
+
qxl_modeset_fini(qdev);
qxl_device_fini(qdev);

@@ -324,15 +327,20 @@ int qxl_driver_load(struct drm_device *dev, unsigned long 
flags)
if (r)
goto out;

+   r = drm_vblank_init(dev, 1);
+   if (r)
+   goto unload;
+
r = qxl_modeset_init(qdev);
-   if (r) {
-   qxl_driver_unload(dev);
-   goto out;
-   }
+   if (r)
+   goto unload;

drm_kms_helper_poll_init(qdev->ddev);

return 0;
+unload:
+   qxl_driver_unload(dev);
+
 out:
kfree(qdev);
return r;
-- 
2.1.0.rc1

[PATCH 0/2] QXL page flip and prime support

[Andreas Pokorny]

Hi,
This series adds a page flipping implementation using qxl_draw_dirty_fb and 
prime support. Similar to the vmware driver it assumes that there is no other 
virtual device to share buffers with.

Andreas Pokorny (2):
  Simple crtc page flipping emulated using buffer copy
  Enables gem prime helpers for qxl using dummy driver callbacks

 drivers/gpu/drm/qxl/Makefile  |  2 +-
 drivers/gpu/drm/qxl/qxl_display.c | 49 ++
 drivers/gpu/drm/qxl/qxl_drv.c | 31 -
 drivers/gpu/drm/qxl/qxl_drv.h | 12 +++
 drivers/gpu/drm/qxl/qxl_kms.c | 16 ++---
 drivers/gpu/drm/qxl/qxl_prime.c   | 72 +++
 6 files changed, 176 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/qxl/qxl_prime.c

-- 
2.1.0.rc1

[Bug 82186] [r600g] BARTS GPU lockup with minecraft shaders

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

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

--- Comment #1 from EoD  ---
I tried it again with current mesa git master
(ae95b9dd9be56ad84a8a4ab5955f580c337259cb) together with libdrm git master
(07fead4462b2d537d0c3cae69a09272fc426c598) and I am being spammed with the
following messages before the computer locks up:

localhost kernel: [ 2991.517056] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517169] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517189] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517249] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517271] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517374] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517394] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517438] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517458] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517537] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517558] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517651] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517677] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517778] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517799] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517844] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517863] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517955] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.517976] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518018] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518037] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518153] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518175] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518221] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518253] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518354] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518376] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518420] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518443] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518520] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518541] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518620] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518639] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518718] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518739] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518782] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518801] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518931] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518952] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.518995] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.519013] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.519090] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit
localhost kernel: [ 2991.519109] radeon_gem_object_create:62 alloc size 341Mb
bigger than 256Mb limit

-- 
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/20140808/ae735a80/attachment.html>

[PATCH] drm/radeon: Read back ring buffer before updating WPTR

[Alex Deucher]

On Fri, Aug 8, 2014 at 4:45 AM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> This fixes a ring test failure reported on a Kabini system which was
> triggered by write-combined CPU mappings of the ring buffers.
>
> Reported-and-Tested-by: Will Trives 
> Signed-off-by: Michel D?nzer 

Applied to my fixes tree.

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_ring.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index 5b4e0cf..6dff529 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -193,6 +193,10 @@ void radeon_ring_commit(struct radeon_device *rdev, 
> struct radeon_ring *ring)
> radeon_ring_write(ring, ring->nop);
> }
> mb();
> +   /* This is necessary to prevent ring test failures on some systems
> +* with write-combined CPU mappings of the ring buffers
> +*/
> +   (void)ring->ring[ring->wptr];
> /* If we are emitting the HDP flush via MMIO, we need to do it after
>  * all CPU writes to VRAM finished.
>  */
> --
> 2.0.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: Always flush VM again on < CIK

[Alex Deucher]

On Fri, Aug 8, 2014 at 9:31 AM, Alex Deucher  wrote:
> On Fri, Aug 8, 2014 at 4:50 AM, Michel D?nzer  wrote:
>> On 08.08.2014 17:44, Christian K?nig wrote:
>> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher 
>> wrote:
>>> We should be using PFP as much as possible.  Does the attached
>>> patch help?
 Unfortunately not.
>>>
>>> Maybe add a readback of the VM base addr pointer to make sure that the
>>> write has really reached the SBRM?
>>
>> I'm not sure what exactly you're thinking of, but I'm happy to test any
>> patches you guys come up with. :)
>>
>
> Maybe some variant of this patch?

Ignore that one.  typo.  Try this one instead.

Alex
-- next part --
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index dbd9d81..565201d 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -5007,6 +5007,7 @@ static void si_vm_decode_fault(struct radeon_device *rdev,
 void si_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm)
 {
struct radeon_ring *ring = >ring[ridx];
+   u32 reg;

if (vm == NULL)
return;
@@ -5017,15 +5018,23 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
 WRITE_DATA_DST_SEL(0)));

if (vm->id < 8) {
-   radeon_ring_write(ring,
- (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id 
<< 2)) >> 2);
+   reg = (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id << 2)) >> 2;
} else {
-   radeon_ring_write(ring,
- (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm->id 
- 8) << 2)) >> 2);
+   reg = (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm->id - 8) << 2)) 
>> 2;
}
+   radeon_ring_write(ring, reg);
radeon_ring_write(ring, 0);
radeon_ring_write(ring, vm->pd_gpu_addr >> 12);

+   /* wait for the address change to go through */
+   radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+   radeon_ring_write(ring, 3); /* == */
+   radeon_ring_write(ring, reg);
+   radeon_ring_write(ring, 0);
+   radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
+   radeon_ring_write(ring, 0x0fff);
+   radeon_ring_write(ring, 10);
+
/* flush hdp cache */
radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(1) |
@@ -5034,6 +5043,14 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 0x1);

+   /* clear the response reg */
+   radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
+   radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(1) |
+WRITE_DATA_DST_SEL(0)));
+   radeon_ring_write(ring, VM_INVALIDATE_RESPONSE >> 2);
+   radeon_ring_write(ring, 0);
+   radeon_ring_write(ring, 0);
+
/* bits 0-15 are the VM contexts0-15 */
radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(1) |
@@ -5042,6 +5059,15 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 1 << vm->id);

+   /* wait for the invalidate */
+   radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+   radeon_ring_write(ring, 3); /* == */
+   radeon_ring_write(ring, VM_INVALIDATE_RESPONSE >> 2);
+   radeon_ring_write(ring, 0);
+   radeon_ring_write(ring, 1 << vm->id);
+   radeon_ring_write(ring, 1 << vm->id);
+   radeon_ring_write(ring, 10);
+
/* sync PFP to ME, otherwise we might get invalid PFP reads */
radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
radeon_ring_write(ring, 0x0);

[PATCH] drm/radeon: Always flush VM again on < CIK

[Alex Deucher]

On Fri, Aug 8, 2014 at 4:50 AM, Michel D?nzer  wrote:
> On 08.08.2014 17:44, Christian K?nig wrote:
> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher 
> wrote:
>> We should be using PFP as much as possible.  Does the attached
>> patch help?
>>> Unfortunately not.
>>
>> Maybe add a readback of the VM base addr pointer to make sure that the
>> write has really reached the SBRM?
>
> I'm not sure what exactly you're thinking of, but I'm happy to test any
> patches you guys come up with. :)
>

Maybe some variant of this patch?

Alex
-- next part --
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index dbd9d81..0855da0 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -5007,6 +5007,7 @@ static void si_vm_decode_fault(struct radeon_device *rdev,
 void si_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm)
 {
struct radeon_ring *ring = >ring[ridx];
+   u32 reg;

if (vm == NULL)
return;
@@ -5017,15 +5018,23 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
 WRITE_DATA_DST_SEL(0)));

if (vm->id < 8) {
-   radeon_ring_write(ring,
- (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id 
<< 2)) >> 2);
+   reg = (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id << 2)) >> 2;
} else {
-   radeon_ring_write(ring,
- (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm->id 
- 8) << 2)) >> 2);
+   reg = (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm->id - 8) << 2)) 
>> 2;
}
+   radeon_ring_write(ring, reg);
radeon_ring_write(ring, 0);
radeon_ring_write(ring, vm->pd_gpu_addr >> 12);

+   /* wait for the address change to go through */
+   radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+   radeon_ring_write(ring, 3); /* == */
+   radeon_ring_write(ring, reg);
+   radeon_ring_write(ring, 0);
+   radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
+   radeon_ring_write(ring, 0x0fff);
+   radeon_ring_write(ring, 10);
+
/* flush hdp cache */
radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(1) |
@@ -5034,6 +5043,14 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 0x1);

+   /* clear the response reg */
+   radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
+   radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(1) |
+WRITE_DATA_DST_SEL(0)));
+   radeon_ring_write(ring, VM_INVALIDATE_RESPONSE >> 2);
+   radeon_ring_write(ring, 0);
+   radeon_ring_write(ring, 1 << vm->id);
+
/* bits 0-15 are the VM contexts0-15 */
radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(1) |
@@ -5042,6 +5059,15 @@ void si_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 1 << vm->id);

+   /* wait for the invalidate */
+   radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+   radeon_ring_write(ring, 3); /* == */
+   radeon_ring_write(ring, VM_INVALIDATE_RESPONSE >> 2);
+   radeon_ring_write(ring, 0);
+   radeon_ring_write(ring, 1 << vm->id);
+   radeon_ring_write(ring, 1 << vm->id);
+   radeon_ring_write(ring, 10);
+
/* sync PFP to ME, otherwise we might get invalid PFP reads */
radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
radeon_ring_write(ring, 0x0);

Dual-channel DSI

[Andrzej Hajda]

On 08/07/2014 10:54 AM, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:39:36AM +0200, Andrzej Hajda wrote:
>> On 08/07/2014 09:25 AM, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote:
 Hi Thierry,

 Nice case.

 On 08/05/2014 05:39 PM, Thierry Reding wrote:
> Hi everyone,
>
> I've been working on adding support for a panel that uses what's
> commonly known as dual-channel DSI. Sometimes this is referred to as
> ganged-mode as well.
>
> What is it, you ask? It's essentially a hack to work around the band-
> width restrictions of DSI, albeit one that's been commonly implemented
> by several SoC vendors.
>
> This typically works by equipping a peripheral with two DSI interfaces,
> each of which driving one half of the screen (symmetric left-right mode)
> or every other line (symmetric odd-even mode). Apparently there can be
> asymmetric modes in addition to those two, but they seem to be the
> common ones. Often both of the DSI interfaces need to be configured
> using DCS commands and vendor specific registers.
>
> A single display controller is typically used video data transmission.
> This is necessary to provide synchronization and avoid tearing and all
> kinds of other ugliness. For this to work both DSI controllers need to
> be made aware of which chunk of the video data stream is addressing
> them.
>
> From a software perspective, this poses two problems:
>
> 1) A dual-channel device is composed of two DSI peripheral devices which
>cannot be programmed independently of each other. A typical example
>is that the frame memory extents need to be configured differently
>for each of the devices (using the DCS set_column_address and
>set_page_address commands). Therefore each device must know of the
>other, or there must be a driver that binds against a dummy device
>that pulls in the two real devices.
 I am not sure if I understand correctly, but I see it rather as one
 device with two dsi-slave interfaces. Probably panel driver can
 create dsi dummy device to program some registers
 via second dsi interface but the panel will be attached to one control bus.
 It seems to be very similar to mfd/i2c devices with two or more i2c
 addresses.
>>> They are in fact attached to two different control busses. The DSI
>>> controllers that talk to each are separate. On Tegra they are the same
>>> type of IP block, but still two separate instances (with their own
>>> clock, reset, etc. inputs).
>>>
>>> So the panel driver can't create a dummy device to talk to the second
>>> DSI interface because the second DSI interface uses a different DSI
>>> host.
>> Why different DSI host does not allow that? The only thing panel needs
>> is the reference to another DSI host and this can be provided via
>> DT direct phandle or video interface.
> I'm sure one could find ways to make it work. That doesn't mean it's a
> good idea, though. The second peripheral is physically there on the
> second DSI host controller's bus, so it the device should be in device
> tree because so that the device tree matches reality.

The question is what is the reality? Do we have two separate dsi
devices? In such case
both devices should appear in DT.
If we have single device attached to two different DSI hosts I suppose
device should appear
only in one location in DT with link to another DSI host.

>
> 2) On the DSI host side, each of the controller instances needs to know
>the intimate details of the other controller (or alternatively, one
>controller needs to be a "master" and the other a "slave").
 The question is if they need to communicate each other, or they have
 to have similar configurations applied?
>>> On Tegra at least the configuration needs to be almost the same. There
>>> are two registers that may need to be programmed differently. But they
>>> don't have to communicate with each other. Essentially the two registers
>>> that require different programming define which parts of the display
>>> controller's data stream they need to capture and turn into DSI packets.
>>>
>>> Theoretically it would be possible to make this work with two completely
>>> different DSI controllers, but in practice I'd expect that to never
>>> happen. So I'm not sure we need to consider the case where the register
>>> layout is different between the two DSI host controllers.
>> So maybe the configuration could be provided by the panel.
> What configuration? I suppose one idea would be for the panel driver to
> set the type of dual-channel mode that it's using. Panels can typically
> be configured to do symmetric left-right or symmetric odd-even. I think
> technically it's possible to have asymmetric modes, too, but to be
> honest I don't want to think about those yet.
>
> So I think it's reasonable 

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Thierry Reding]

;
> >>>>>>>>
> >>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled 
> >>>>>>>> if
> >>>>>>>> non-continous mode is used. Right?
> >>>>>>>
> >>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter
> >>>>>>> LP-11. Non-continuous mode means that the controller can disable the 
> >>>>>>> HS
> >>>>>>> clock between HS transmissions. So in non-continuous mode the clock 
> >>>>>>> lane
> >>>>>>> can enter LP-11 because the controller disables the HS clock.
> >>>>>>
> >>>>>> It makes me a little bit confusing. You said "if HS clock is enabled,
> >>>>>> the the clock lane won't enter LP-11" But you said again "the clock 
> >>>>>> lane
> >>>>>> can enter LP-11 because the controller disables the HS clock" What is
> >>>>>> the meaning?
> >>>>>
> >>>>> It means that if the HS clock is enabled, then the clock lane is not in
> >>>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
> >>>>>
> >>>>>>> In continuous mode, then the clock will never be disabled, hence the
> >>>>>>> clock lane will never enter LP-11.
> >>>>>>>
> >>>>>>>> And also it seems that non-continous mode is different from LPM at 
> >>>>>>>> all
> >>>>>>>> because with non-continuous mode, command data is transmitted to 
> >>>>>>>> panel
> >>>>>>>> in HS mode, but with LPM, command data is transmitted to panel in LP
> >>>>>>>> mode. Also right?
> >>>>>>>
> >>>>>>> No. I think you can send command data to the peripheral in low power
> >>>>>>> mode in both continuous and non-continuous clock modes.
> >>>>>>>
> >>>>>>>> If so, shouldn't the host driver disable HS clock, in case of LP 
> >>>>>>>> mode,
> >>>>>>>> before the host driver transmits command data?
> >>>>>>>
> >>>>>>> No. If the peripheral doesn't support non-continuous mode, then the HS
> >>>>>>> clock must never be turned off. On the other hand, if the peripheral
> >>>>>>> supports non-continuous mode, then the DSI host should automatically
> >>>>>>> disable the HS clock between high-speed transmissions. That means if a
> >>>>>>> packet is transmitted in low power mode the DSI host will not be
> >>>>>>> transmitting in high-speed mode and therefore disable the HS clock.
> >>>>>>
> >>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So
> >>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of the
> >>>>>> host controller should be disabled.
> >>>>>
> >>>>> No. I don't think any transmissions can happen when all lanes are in
> >>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet
> >>>>> should be transmitted in low power mode (see LP Transmission in 2.1
> >>>>> "Definitions" of the MIPI DSI specification).
> >>>>>
> >>>>
> >>>> Hm.. I see. I meant,
> >>>>
> >>>> if (flags & MIPI_DSI_MSG_USE_LPM)
> >>>>disable HS clock <- required.
> >>>>
> >>>> transmit command data <- in LPM.
> >>>
> >>> No. Disabling the HS clock is not required for LPM mode. In fact if the
> >>> peripheral specifies that it doesn't support non-continuous mode then
> >>> the HS clock must *never* be disabled as long as the peripheral is in
> >>> use.
> >>>
> >>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and
> >>> need to be considered separately.
> >>
> >> I mentioned already LPM and NON_CONTINUOUS are unrelated.
> >>
> >> It seems that you say the only way to transfer command data in LPM is
> >> non-continuous clock mode.
> >
> > No, that's not what I'm saying.
> >
> >> However, you said and also the spec says, "Non-continuous mode simply
> >> means that the clock lane enters LP-11 between HS transmissions".
> >> Doesn't *between HS transmissions" mean the command data is transmitted
> >> in HS, *not in LPM*, and clock lane enters LP-11 between them?
> >
> > Not necessarily. You can transmit command packets in high-speed mode,
> > but you don't have to. If you transmit packets in low power mode, then
> 
> That would may why we are mentioning same comments repeatedly.
> 
> In my case, host driver waits for the lane stop state (LP-11), and then
> disables HS clock to transmit command data in LPM. Of course, I'm not
> sure that yet it's correct way.

That's confusing. How can the lane go to LP-11 when the clock is still
running?

> In Tegra, What to do for it?

There are two bits in two separate registers for this:

DSI_HOST_CONTROL:
  bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
   packets
- 0 = LOW: low speed
- 1 = HIGH: high speed

DSI_CONTROL:
  bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
- 0 = CONTINUOUS: HS clock is on all the time
- 1 = TX_ONLY: HS clock is only active during HS
   transmissions

So if the peripheral supports non-continuous mode of operation we set
the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
remains on all the time.

When a packet is to be transmitted in high speed mode, we set the
DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
cleared.

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

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

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

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

--- Comment #3 from Henri Verbeet  ---
For what it's worth, test_fpu_setup() tests creating a D3D device with a custom
FPU control word. (The background on that is that creating a D3D device should
setup the FPU in a specific way, depending on if D3DCREATE_FPU_PRESERVE is
specified or not.) My guess would be that something in llvm doesn't expect to
be called with a non-default FPU control word.

-- 
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/20140808/a2700b20/attachment.html>

[PATCH] drm: Restore drm_file->is_master

[Dave Airlie]

On 8 August 2014 02:00, David Herrmann  wrote:
> Hi
>
> On Thu, Aug 7, 2014 at 3:04 PM, Chris Wilson  
> wrote:
>> Despite the claims of
>>
>> commit 48ba813701eb14b3008edefef4a0789b328e278c
>> Author: David Herrmann 
>> Date:   Tue Jul 22 18:46:09 2014 +0200
>>
>> drm: drop redundant drm_file->is_master
>>
>> drm_file->is_master is not synomous with having drm_file->master ==
>> drm_file->minor->master. This is because drm_file->master is the same
>> for all drm_files of the same generation and so when there is a master,
>> every drm_file believes itself to be the master. Confusion ensues and
>> things go pear shaped when one file is closed and there is no master
>> anymore.
>
> Uagh, embarrassing. A revert is fine with me, but I'll try to review
> your patch once I get home.
>

At this point I'll just revert, though I do like the wrapper instead
of checking the flag,
but its late in the day.

Dave.

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

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

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

--- Comment #2 from Michel D?nzer  ---
(In reply to comment #1)
> Can you post the output of R600_DEBUG=cs ?

Make that R600_DEBUG=vs , since the crash occurs in
util_make_vertex_passthrough_shader_with_so().

-- 
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/20140808/aeada4a9/attachment.html>

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

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

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

--- Comment #1 from Tom Stellard  ---
Can you post the output of R600_DEBUG=cs ?

-- 
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/20140808/254540ba/attachment.html>

[git pull] drm merge window pull

[Dave Airlie]

Hi Linus,

like all good pull reqs this ends with a revert, so it must mean we 
tested it,

This pull is missing nouveau, Ben has been stuck trying to track down a 
very longstanding bug that revealed itself due to some other changes, I've 
asked him to send you a direct pull request for nouveau once he cleans 
things up. I'm away until Monday so don't want to delay things, you can 
make a decision on that when he sends it, I have my phone so I can ack 
things just not really merge much.

It has one trivial conflict with your tree in armada_drv.c, and also the 
pull request contains some component changes that are already in your 
tree, the base tree from Russell went via Greg's tree already, but some 
stuff still shows up in here that doesn't when I merge my tree into yours.

otherwise all pretty standard graphics fare, one new driver and changes 
all over the place.

New drivers: sti kms driver for STMicroelectronics chipsets stih416 and 
stih407.

core:
lots of cleanups to the drm core
DP MST helper code merged
universal cursor planes.
render nodes enabled by default

panel:
better panel interfaces
new panel support
non-continuous cock advertising ability

ttm:
shrinker fixes

i915: 
hopefully ditched UMS support
runtime pm fixes
psr tracking and locking - now enabled by default
userptr fixes
backlight brightness fixes
MST support merged 
runtime PM for dpms
primary planes locking fixes
gen8 hw semaphore support
fbc fixes
runtime PM on SOix sleep state hw.
mmio base page flipping
lots of vlv/chv fixes.
universal cursor planes

radeon:
Hawaii fixes
display scalar support for non-fixed mode displays
new firmware format support
dpm on more asics by default
GPUVM improvements
uncached and wc GTT buffers
BOs > visible VRAM

exynos:
i80 interface support
module auto-loading
ipp driver consolidated.

armada:
irq handling in crtc layer only
crtc renumbering
add component support
DT interaction changes.

tegra:
load as module fixes
eDP bpp and sync polarity fixed
DSI non-continuous clock mode support
better support for importing buffers from nouveau

msm:
mdp5/adq8084 v1.3 hw enablement
devicetree clk changse
ifc6410 board working

tda998x:
component support
DT documentation update

vmwgfx:
fix compat shader namespace

The following changes since commit 19583ca584d6f574384e17fe7613dfaeadcdc4a6:

  Linux 3.16 (2014-08-03 15:25:02 -0700)

are available in the git repository at:

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

for you to fetch changes up to 7963e9db1b1f842fdc53309baa8714d38e9f5681:

  Revert "drm: drop redundant drm_file->is_master" (2014-08-08 07:30:53 +1000)


Ajay Kumar (15):
  drm/panel: add .prepare() and .unprepare() functions
  drm/panel: Provide convenience wrapper for .get_modes()
  drm/panel: ld9040: Add dummy prepare and unprepare routines
  drm/panel: s6e8aa0: Add dummy prepare and unprepare routines
  drm/panel: simple: Add dummy prepare and unprepare routines
  drm/exynos: dpi: Add support for panel prepare and unprepare routines
  drm/exynos: dsi: Add support for panel prepare and unprepare routines
  drm/tegra: Add support for panel prepare and unprepare routines
  drm/panel: ld9040: Add proper definition for prepare and unprepare
  drm/panel: s6e8aa0: Add proper definition for prepare and unprepare
  drm/panel: simple: Add proper definition for prepare and unprepare
  drm/panel: simple: Support delays in panel functions
  drm/panel: simple: Add AUO B133HTN01 panel support
  drm/exynos: Move DP setup into commit()
  drm/exynos: dp: Modify driver to support drm_panel

Akash Goel (1):
  drm/i915: Added write-enable pte bit supportt

Alban Bedel (1):
  drm/panel: simple: add support for InnoLux N156BGE-L21 panel

Alban Browaeys (1):
  drm/exynos: g2d: add exynos4212 as a compatible device.

Alex Deucher (25):
  drm/radeon/dpm: add support for SVI2 voltage for SI
  drm/radeon: disable gfx cgcg on cik
  drm/radeon: add new firmware header definitions (v3)
  drm/radeon/si: Add support for new ucode format (v3)
  drm/radeon/cik: Add support for new ucode format (v5)
  drm/radeon: enable display scaling on all connectors (v2)
  drm/radeon: consolidate vga and dvi get_modes functions (v2)
  drm/radeon: restructure edid fetching
  drm/radeon: use a fetch function to get the edid
  drm/radeon: track pinned memory (v2)
  drm/radeon: use vram/gart pinned size in radeon_gem_info_ioctl
  drm/radeon: use vram/gart pinned size in