[Bug 82154] [HAWAII] gpu-reset when closing gwenview, fails to resume (atombios stuck executing), then flickery noise

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

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

--- Comment #2 from Luzipher  ---
Created attachment 104028
  --> https://bugs.freedesktop.org/attachment.cgi?id=104028=edit
Xorg.0.log of gpu crash

-- 
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/20140804/cd0d6d69/attachment.html>

[Bug 82154] [HAWAII] gpu-reset when closing gwenview, fails to resume (atombios stuck executing), then flickery noise

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

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

--- Comment #1 from Luzipher  ---
Created attachment 104027
  --> https://bugs.freedesktop.org/attachment.cgi?id=104027=edit
dmesg of gpu crash

-- 
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/20140804/6a4c7e71/attachment-0001.html>

[Bug 82154] New: [HAWAII] gpu-reset when closing gwenview, fails to resume (atombios stuck executing), then flickery noise

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

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

  Priority: medium
Bug ID: 82154
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [HAWAII] gpu-reset when closing gwenview, fails to
resume (atombios stuck executing), then flickery noise
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: luziphermcleod at yahoo.ie
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Observation:


With Hawaii acceleration enabled (including drm) I just got a gpu reset that
failed to recover. It happended when I closed a gwenview window after a few
hours of use (window manager was cinnamon). After going black and switching off
for a while, the screens (2x DVI and 1x HDMI) came back, but displayed only
flickery noise (I could see where the mouse pointer would've been as a
differently noisy rectangle, and could move it). I could still ssh into the
machine and aquire dmesg and Xorg.0.log.

Interesting messages from dmesg:
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing C466 (len 254,
WS 0, PS 4) @ 0xC490
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing B9EC (len 145,
WS 0, PS 8) @ 0xBA77
[drm:ci_dpm_enable] *ERROR* ci_start_dpm failed
[drm:radeon_pm_resume_dpm] *ERROR* radeon: dpm resume failed


Driver Stack Details:
=

1)Kernel: agd5f's drm-next-3.17-wip (2014-08-03), Hawaii accel enabled
2)libdrm: git (2014-08-03)
3)mesa: git (2014-08-03)
4)Xorg-server: 1.16.0
5)xf86-video-ati: git (2014-08-03 with patch to enable accel)
6)glamor: xorg-server integrated 1.0.0
7)llvm: 3.5svn (updated recently)
8)new radeon firmware files for hawaii accel

Hardware Configuration:
=

Graphics Card: Hawaii XT, Sapphire Radeon R9 290X Tri-X OC, 4GB GDDR5
Processor: Core i7-965 (LGA 1366)
Mainboard: Asus P6T Deluxe
RAM: 6GB

-- 
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/20140804/331e4ac3/attachment.html>

[PATCH 8/9] Add devicetree bindings for Rockchip Soc EDP

[Heiko Stübner]

Am Montag, 4. August 2014, 12:55:59 schrieb mark yao:
> Signed-off-by: mark yao 
> ---
>  .../devicetree/bindings/video/rockchip-panel.txt   |   34
>  1 file changed, 34 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/video/rockchip-panel.txt
> b/Documentation/devicetree/bindings/video/rockchip-panel.txt index
> f599806..f6d80f6 100644
> --- a/Documentation/devicetree/bindings/video/rockchip-panel.txt
> +++ b/Documentation/devicetree/bindings/video/rockchip-panel.txt
> @@ -80,3 +80,37 @@ Example:
>   rockchip,data-width = <24>;
>   rockchip,panel = <>;
>   };
> +
> +Rockchip RK3288 EDP interface
> +
> +Required properties:
> +-compatible: "rockchip,rk3288-edp";
> +
> +- reg: physical base address of the controller and length
> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +- clock-names: from common clock binding:
> + Required elements: "clk_edp"
> + "clk_edp_24m"
> + "clk_edp_24m_parent"
> + "pclk_edp"
> +- rockchip,grf: this soc should set GRF regs, so need get grf here.
> +- resets: Must contain an entry for each entry in reset-names.
> + See ../reset/reset.txt for details.
> +- reset-names: Must include the following entries:
> +  - edp
> +- rockchip,panel: required a panel node
> +
> +Example:
> + edp: edp at ff97 {
> + compatible = "rockchip,rk3288-edp";
> +reg = <0xff97 0x4000>;
> +interrupts = ;
> +clocks = < SCLK_EDP>, < SCLK_EDP_24M>, <
> PCLK_EDP_CTRL>, <>; +clock-names = "clk_edp",
> "clk_edp_24m", "pclk_edp", "clk_edp_24m_parent"; +

clk_epd_24m_parent is not part of the hardware, so instead of referencing the 
target-parent as part of the device clocks, the new
"clk: Support for clock parents and rates assigned from device tree"
should be used for setting the target parent - so the re-parenting code should 
also move out of the driver.

This commit [0] is part of the clk-pull request and thus will most likely be 
part of 3.17.


Heiko

[0] 
http://git.linaro.org/people/mike.turquette/linux.git/commitdiff/86be408bfbd846fab3c4ac21d6f9298bd2e4b790?hp=09575693a2511b5ddae0105546e0d9cefc936e34



> +rockchip,grf = <>;
> +resets = < 111>;
> +reset-names = "edp";
> + rockchip,panel = <>;
> + };

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #238 from Paul Bodenbenner  ---
I am pretty sure that the problem which I encounter isn't related to a thermal
problem. At the next hang I will check if I still can connect through ssh for
checking logs.

-- 
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/20140804/8ffca0c7/attachment.html>

[PATCH] radeon: allow write_reloc with unaccounted buffers to cope with Mesa R200 bug

[Marek Olšák]

Actually, please disregard this patch. I have found and fixed the real
problem in mesa/r200.

Marek

On Mon, Aug 4, 2014 at 5:58 PM, Alex Deucher  wrote:
> On Fri, Aug 1, 2014 at 9:43 AM, Marek Ol??k  wrote:
>> From: Marek Ol??k 
>>
>> ---
>>
>> I'm not really interested in studying the R200 driver to fix it.
>> This has to suffice.
>
> Reviewed-by: Alex Deucher 
>
>>
>>  radeon/radeon_cs_gem.c | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
>> index b87c6b1..bcfa05b 100644
>> --- a/radeon/radeon_cs_gem.c
>> +++ b/radeon/radeon_cs_gem.c
>> @@ -178,6 +178,15 @@ static int cs_gem_write_reloc(struct radeon_cs_int *cs,
>>  uint32_t idx;
>>  unsigned i;
>>
>> +if (!boi->space_accounted) {
>> +struct radeon_cs *rcs = (struct radeon_cs*)cs;
>> +int r;
>> +
>> +radeon_cs_space_add_persistent_bo(rcs, bo, read_domain, 
>> write_domain);
>> +r = radeon_cs_space_check(rcs);
>> +if (r)
>> +return r;
>> +}
>>  assert(boi->space_accounted);
>>
>>  /* check domains */
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 74250] [HAWAII][DPM] New Version 3.1 for ASIC_ProfilingInfo / ci_upload_dpm_level_enable_mask failed

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

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

Luzipher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Luzipher  ---
Fixed: the error messages are gone with the following commits on branch
'drm-next-3.17-wip':
* drm/radeon/dpm: handle voltage info fetching on hawaii
* drm/radeon/atom: add new voltage fetch function for hawaii

Dynamic mclk is not supported with multiple monitors according to agd5f on irc.

@Kai: since you apparently tested with the now useless patch from attachment
#93015 last time, maybe you want to try with current unmodified
'drm-next-3.17-wip' again ? (Don't forget the updated firmware, I always do ;-)
). If that still doesn't resolve your issues, please open a new bug.

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

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Christian König]

Am 04.08.2014 um 17:09 schrieb Maarten Lankhorst:
> op 04-08-14 17:04, Christian K?nig schreef:
>> Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
>>> op 04-08-14 16:45, Christian K?nig schreef:
 Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
> op 04-08-14 16:37, Christian K?nig schreef:
>>> It'a pain to deal with gpu reset.
>> Yeah, well that's nothing new.
>>
>>> I've now tried other solutions but that would mean reverting to the old 
>>> style during gpu lockup recovery, and only running the delayed work 
>>> when !lockup.
>>> But this meant that the timeout was useless to add. I think the 
>>> cleanest is keeping the v2 patch, because potentially any waiting code 
>>> can be called during lockup recovery.
>> The lockup code itself should never call any waiting code and V2 doesn't 
>> seem to handle a couple of cases correctly either.
>>
>> How about moving the fence waiting out of the reset code?
> What cases did I miss then?
>
> I'm curious how you want to move the fence waiting out of reset, when 
> there are so many places that could potentially wait, like radeon_ib_get 
> can call radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that 
> can wait on radeon_fence_wait_next, etc.
 The IB test itself doesn't needs to be protected by the exclusive lock. 
 Only everything between radeon_save_bios_scratch_regs and 
 radeon_ring_restore.
>>> I'm not sure about that, what do you want to do if the ring tests fail? Do 
>>> you have to retake the exclusive lock?
>> Just set need_reset again and return -EAGAIN, that should have mostly the 
>> same effect as what we are doing right now.
> Yeah, except for the locking the ttm delayed workqueue, but that bool should 
> be easy to save/restore.
> I think this could work.

Actually you could activate the delayed workqueue much earlier as well.

Thinking more about it that sounds like a bug in the current code, 
because we probably want the workqueue activated before waiting for the 
fence.

Christian.

>
> ~Maarten
>

[PATCH v2] drm/ttm: expose CPU address of DMA-allocated pages

[Alexandre Courbot]

Pages allocated using the DMA API have a coherent memory mapping. Make
this mapping visible to drivers so they can decide to use it instead of
creating their own redundant one.

Signed-off-by: Alexandre Courbot 
Acked-by: David Airlie 
---
Changes since v1:
- Perform only one allocation for pages, CPU and DMA addresses
- Added David's ack

 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  2 ++
 drivers/gpu/drm/ttm/ttm_tt.c | 13 -
 include/drm/ttm/ttm_bo_driver.h  |  2 ++
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index fb8259f69839..0301fac5badd 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -847,6 +847,7 @@ static int ttm_dma_pool_get_pages(struct dma_pool *pool,
if (count) {
d_page = list_first_entry(>free_list, struct dma_page, 
page_list);
ttm->pages[index] = d_page->p;
+   ttm_dma->cpu_address[index] = d_page->vaddr;
ttm_dma->dma_address[index] = d_page->dma;
list_move_tail(_page->page_list, _dma->pages_list);
r = 0;
@@ -978,6 +979,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct 
device *dev)
INIT_LIST_HEAD(_dma->pages_list);
for (i = 0; i < ttm->num_pages; i++) {
ttm->pages[i] = NULL;
+   ttm_dma->cpu_address[i] = 0;
ttm_dma->dma_address[i] = 0;
}

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 75f319090043..bf080abc86d1 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -55,9 +55,12 @@ static void ttm_tt_alloc_page_directory(struct ttm_tt *ttm)

 static void ttm_dma_tt_alloc_page_directory(struct ttm_dma_tt *ttm)
 {
-   ttm->ttm.pages = drm_calloc_large(ttm->ttm.num_pages, sizeof(void*));
-   ttm->dma_address = drm_calloc_large(ttm->ttm.num_pages,
-   sizeof(*ttm->dma_address));
+   ttm->ttm.pages = drm_calloc_large(ttm->ttm.num_pages,
+ sizeof(*ttm->ttm.pages) +
+ sizeof(*ttm->dma_address) +
+ sizeof(*ttm->cpu_address));
+   ttm->cpu_address = (void *) (ttm->ttm.pages + ttm->ttm.num_pages);
+   ttm->dma_address = (void *) (ttm->cpu_address + ttm->ttm.num_pages);
 }

 #ifdef CONFIG_X86
@@ -228,7 +231,7 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct 
ttm_bo_device *bdev,

INIT_LIST_HEAD(_dma->pages_list);
ttm_dma_tt_alloc_page_directory(ttm_dma);
-   if (!ttm->pages || !ttm_dma->dma_address) {
+   if (!ttm->pages) {
ttm_tt_destroy(ttm);
pr_err("Failed allocating page table\n");
return -ENOMEM;
@@ -243,7 +246,7 @@ void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)

drm_free_large(ttm->pages);
ttm->pages = NULL;
-   drm_free_large(ttm_dma->dma_address);
+   ttm_dma->cpu_address = NULL;
ttm_dma->dma_address = NULL;
 }
 EXPORT_SYMBOL(ttm_dma_tt_fini);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 202f0a7171e8..1d9f0f1ff52d 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -133,6 +133,7 @@ struct ttm_tt {
  * struct ttm_dma_tt
  *
  * @ttm: Base ttm_tt struct.
+ * @cpu_address: The CPU address of the pages
  * @dma_address: The DMA (bus) addresses of the pages
  * @pages_list: used by some page allocation backend
  *
@@ -142,6 +143,7 @@ struct ttm_tt {
  */
 struct ttm_dma_tt {
struct ttm_tt ttm;
+   void **cpu_address;
dma_addr_t *dma_address;
struct list_head pages_list;
 };
-- 
2.0.3

[PATCH 17/19] drm/radeon: use rcu waits in some ioctls

[Michel Dänzer]

On 04.08.2014 17:56, Maarten Lankhorst wrote:
> op 04-08-14 10:42, Michel D?nzer schreef:
>> On 02.08.2014 02:07, Maarten Lankhorst wrote:
>>> On 01-08-14 16:13, Michel D?nzer wrote:
 On 01.08.2014 19:12, Maarten Lankhorst wrote:
> On 01-08-14 10:27, Michel D?nzer wrote:
>> On 01.08.2014 00:34, Maarten Lankhorst wrote:
>>> @@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device 
>>> *dev, void *data,
>>> struct drm_radeon_gem_wait_idle *args = data;
>>> struct drm_gem_object *gobj;
>>> struct radeon_bo *robj;
>>> -   int r;
>>> +   int r = 0;
>>> +   long ret;
>>>  
>>> gobj = drm_gem_object_lookup(dev, filp, args->handle);
>>> if (gobj == NULL) {
>>> return -ENOENT;
>>> }
>>> robj = gem_to_radeon_bo(gobj);
>>> -   r = radeon_bo_wait(robj, NULL, false);
>>> +   ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, 
>>> true, 30 * HZ);
>>> +   if (ret == 0)
>>> +   r = -EBUSY;
>>> +   else if (ret < 0)
>>> +   r = ret;
>>> +
>>> /* callback hw specific functions if any */
>>> if (rdev->asic->ioctl_wait_idle)
>>> robj->rdev->asic->ioctl_wait_idle(rdev, robj);
>> Heads up, this conflicts with
>> http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html
>> which passes a non-NULL second argument to radeon_bo_wait() to get the
>> BO's current domain.
> Ok, I will fix it up and resend it later.
>
> Does it matter if I grab the current domain without grabbing the lock
> here? Because it doesn't matter if it sees the old or new domain, it
> could have been changed after returning too.
 It should be the domain where the BO is located when the fence we are
 waiting for here signals.
>>> Could we compare domain before and after the rcu wait, and retry
>>> waiting if they're different, and the new one is VRAM? (eg eviction
>>> happened) That should prevent needing to lock the bo.
>> Eviction normally only happens from VRAM, not to VRAM. :) So if you know
>> whether the domain is VRAM or not after the wait, you can just proceed
>> accordingly, I don't see why you'd need to wait again.
> Because in the worst case you didn't wait on the fence that started
> the eviction, but one before it. ;-)

I'm afraid you've lost me. Can you determine the domain that
radeon_bo_wait() would have returned?


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

[PULL] drm-intel-next

[Dave Airlie]

On 4 August 2014 17:10, Daniel Vetter  wrote:
> Hi Dave,
>
> Final feature pull for 3.17.
>
> drm-intel-next-2014-07-25:
> - Ditch UMS support (well just the config option for now)
> - Prep work for future platforms (Sonika Jindal, Damien)
> - runtime pm/soix fixes (Paulo, Jesse)
> - psr tracking improvements, locking fixes, now enabled by default!
> - rps fixes for chv (Deepak, Ville)
> - drm core patches for rotation support (Ville, Sagar Kamble) - the i915 parts
>   unfortunately didn't make it yet
> - userptr fixes (Chris)
> - minimum backlight brightness (Jani), acked long ago by Matthew Garret on 
> irc -
>   I've forgotten about this patch :(
>
> QA is a bit unhappy about the DP MST stuff since it broke hpd testing a
> bit, but otherwise looks sane. I've backmerged drm-next to resolve
> conflicts with the mst stuff, which means the new tag itself doesn't
> contain the overview as usual.

They are unhappy to do their job?

I'm a bit confused. :-P

Dave.

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

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

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

--- Comment #7 from Eugene  ---
(In reply to comment #6)
> (In reply to comment #5)
> > Sorry, but I don't understand how to determine how r600_dri.so was built and
> > etc.
> 
> Since you seem to be using Ubuntu, installing the libgl1-mesa-dri-dbg
> package should make sure there are debugging symbols for r600_dri.so.

Yes, I'm using Kubuntu. And Libgl1-mesa-dri-dbg recently installed. Last report
is here:
https://crash-stats.mozilla.com/report/index/eee0e46e-1b64-4288-b9ac-fd5a82140804

-- 
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/20140804/02d0bfdb/attachment.html>

[PATCH 17/19] drm/radeon: use rcu waits in some ioctls

[Michel Dänzer]

On 02.08.2014 02:07, Maarten Lankhorst wrote:
> On 01-08-14 16:13, Michel D?nzer wrote:
>> On 01.08.2014 19:12, Maarten Lankhorst wrote:
>>> On 01-08-14 10:27, Michel D?nzer wrote:
 On 01.08.2014 00:34, Maarten Lankhorst wrote:
>
> @@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device 
> *dev, void *data,
>   struct drm_radeon_gem_wait_idle *args = data;
>   struct drm_gem_object *gobj;
>   struct radeon_bo *robj;
> - int r;
> + int r = 0;
> + long ret;
>  
>   gobj = drm_gem_object_lookup(dev, filp, args->handle);
>   if (gobj == NULL) {
>   return -ENOENT;
>   }
>   robj = gem_to_radeon_bo(gobj);
> - r = radeon_bo_wait(robj, NULL, false);
> + ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true, 
> 30 * HZ);
> + if (ret == 0)
> + r = -EBUSY;
> + else if (ret < 0)
> + r = ret;
> +
>   /* callback hw specific functions if any */
>   if (rdev->asic->ioctl_wait_idle)
>   robj->rdev->asic->ioctl_wait_idle(rdev, robj);

 Heads up, this conflicts with
 http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html
 which passes a non-NULL second argument to radeon_bo_wait() to get the
 BO's current domain.
>>> Ok, I will fix it up and resend it later.
>>>
>>> Does it matter if I grab the current domain without grabbing the lock
>>> here? Because it doesn't matter if it sees the old or new domain, it
>>> could have been changed after returning too.
>>
>> It should be the domain where the BO is located when the fence we are
>> waiting for here signals.
> Could we compare domain before and after the rcu wait, and retry
> waiting if they're different, and the new one is VRAM? (eg eviction
> happened) That should prevent needing to lock the bo.

Eviction normally only happens from VRAM, not to VRAM. :) So if you know
whether the domain is VRAM or not after the wait, you can just proceed
accordingly, I don't see why you'd need to wait again.


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

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Maarten Lankhorst]

op 04-08-14 17:04, Christian K?nig schreef:
> Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
>> op 04-08-14 16:45, Christian K?nig schreef:
>>> Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
 op 04-08-14 16:37, Christian K?nig schreef:
>> It'a pain to deal with gpu reset.
> Yeah, well that's nothing new.
>
>> I've now tried other solutions but that would mean reverting to the old 
>> style during gpu lockup recovery, and only running the delayed work when 
>> !lockup.
>> But this meant that the timeout was useless to add. I think the cleanest 
>> is keeping the v2 patch, because potentially any waiting code can be 
>> called during lockup recovery.
> The lockup code itself should never call any waiting code and V2 doesn't 
> seem to handle a couple of cases correctly either.
>
> How about moving the fence waiting out of the reset code?
 What cases did I miss then?

 I'm curious how you want to move the fence waiting out of reset, when 
 there are so many places that could potentially wait, like radeon_ib_get 
 can call radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that 
 can wait on radeon_fence_wait_next, etc.
>>> The IB test itself doesn't needs to be protected by the exclusive lock. 
>>> Only everything between radeon_save_bios_scratch_regs and 
>>> radeon_ring_restore.
>> I'm not sure about that, what do you want to do if the ring tests fail? Do 
>> you have to retake the exclusive lock?
>
> Just set need_reset again and return -EAGAIN, that should have mostly the 
> same effect as what we are doing right now.
Yeah, except for the locking the ttm delayed workqueue, but that bool should be 
easy to save/restore.
I think this could work.

~Maarten

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Christian König]

Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
> op 04-08-14 16:45, Christian K?nig schreef:
>> Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
>>> op 04-08-14 16:37, Christian K?nig schreef:
> It'a pain to deal with gpu reset.
 Yeah, well that's nothing new.

> I've now tried other solutions but that would mean reverting to the old 
> style during gpu lockup recovery, and only running the delayed work when 
> !lockup.
> But this meant that the timeout was useless to add. I think the cleanest 
> is keeping the v2 patch, because potentially any waiting code can be 
> called during lockup recovery.
 The lockup code itself should never call any waiting code and V2 doesn't 
 seem to handle a couple of cases correctly either.

 How about moving the fence waiting out of the reset code?
>>> What cases did I miss then?
>>>
>>> I'm curious how you want to move the fence waiting out of reset, when there 
>>> are so many places that could potentially wait, like radeon_ib_get can call 
>>> radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on 
>>> radeon_fence_wait_next, etc.
>> The IB test itself doesn't needs to be protected by the exclusive lock. Only 
>> everything between radeon_save_bios_scratch_regs and radeon_ring_restore.
> I'm not sure about that, what do you want to do if the ring tests fail? Do 
> you have to retake the exclusive lock?

Just set need_reset again and return -EAGAIN, that should have mostly 
the same effect as what we are doing right now.

Christian.

>
> ~Maarten
>

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Maarten Lankhorst]

op 04-08-14 16:45, Christian K?nig schreef:
> Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
>> op 04-08-14 16:37, Christian K?nig schreef:
 It'a pain to deal with gpu reset.
>>> Yeah, well that's nothing new.
>>>
 I've now tried other solutions but that would mean reverting to the old 
 style during gpu lockup recovery, and only running the delayed work when 
 !lockup.
 But this meant that the timeout was useless to add. I think the cleanest 
 is keeping the v2 patch, because potentially any waiting code can be 
 called during lockup recovery.
>>> The lockup code itself should never call any waiting code and V2 doesn't 
>>> seem to handle a couple of cases correctly either.
>>>
>>> How about moving the fence waiting out of the reset code?
>> What cases did I miss then?
>>
>> I'm curious how you want to move the fence waiting out of reset, when there 
>> are so many places that could potentially wait, like radeon_ib_get can call 
>> radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on 
>> radeon_fence_wait_next, etc.
>
> The IB test itself doesn't needs to be protected by the exclusive lock. Only 
> everything between radeon_save_bios_scratch_regs and radeon_ring_restore.
I'm not sure about that, what do you want to do if the ring tests fail? Do you 
have to retake the exclusive lock?

~Maarten

[PATCH 1/9] drm: Add drm driver for Rockchip Socs

[Daniel Vetter]

On Mon, Aug 04, 2014 at 12:45:07PM +0800, mark yao wrote:
> This patch is a DRM Driver for Rockchip Socs, driver provides an abstraction
> for the graphics hardware, such as lcd controller and connector interface.
> 
> Signed-off-by: mark yao 
> ---

Just a quick drive-by comment below, don't consider this a full review by
far ;-)

> +static int lcdc_bind(struct device *dev, struct device *master, void *data)
> +{
> + struct drm_device *drm_dev = data;
> + struct rockchip_drm_private *private = drm_dev->dev_private;
> + struct lcdc_context *ctx = dev_get_drvdata(dev);
> + struct drm_crtc *crtc;
> +
> + ctx->drm_dev = drm_dev;
> +
> + ctx->pipe = rockchip_drm_pipe_get(dev);
> + ctx->dpms = DRM_MODE_DPMS_OFF;
> + crtc = >crtc;
> +
> + private->crtc[ctx->pipe] = crtc;
> + ctx->plane = rockchip_plane_init(drm_dev, 1 << ctx->pipe, true);
> + drm_crtc_init(drm_dev, crtc, _crtc_funcs);

This function is deprecated, please use the _with_planes versions so that
this new driver supports universal planes properly.

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

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Christian König]

Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
> op 04-08-14 16:37, Christian K?nig schreef:
>>> It'a pain to deal with gpu reset.
>> Yeah, well that's nothing new.
>>
>>> I've now tried other solutions but that would mean reverting to the old 
>>> style during gpu lockup recovery, and only running the delayed work when 
>>> !lockup.
>>> But this meant that the timeout was useless to add. I think the cleanest is 
>>> keeping the v2 patch, because potentially any waiting code can be called 
>>> during lockup recovery.
>> The lockup code itself should never call any waiting code and V2 doesn't 
>> seem to handle a couple of cases correctly either.
>>
>> How about moving the fence waiting out of the reset code?
> What cases did I miss then?
>
> I'm curious how you want to move the fence waiting out of reset, when there 
> are so many places that could potentially wait, like radeon_ib_get can call 
> radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on 
> radeon_fence_wait_next, etc.

The IB test itself doesn't needs to be protected by the exclusive lock. 
Only everything between radeon_save_bios_scratch_regs and 
radeon_ring_restore.

Christian.

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Maarten Lankhorst]

op 04-08-14 16:37, Christian K?nig schreef:
>> It'a pain to deal with gpu reset.
>
> Yeah, well that's nothing new.
>
>> I've now tried other solutions but that would mean reverting to the old 
>> style during gpu lockup recovery, and only running the delayed work when 
>> !lockup.
>> But this meant that the timeout was useless to add. I think the cleanest is 
>> keeping the v2 patch, because potentially any waiting code can be called 
>> during lockup recovery.
>
> The lockup code itself should never call any waiting code and V2 doesn't seem 
> to handle a couple of cases correctly either.
>
> How about moving the fence waiting out of the reset code?
What cases did I miss then?

I'm curious how you want to move the fence waiting out of reset, when there are 
so many places that could potentially wait, like radeon_ib_get can call 
radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on 
radeon_fence_wait_next, etc.

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Christian König]

> It'a pain to deal with gpu reset.

Yeah, well that's nothing new.

> I've now tried other solutions but that would mean reverting to the old style 
> during gpu lockup recovery, and only running the delayed work when !lockup.
> But this meant that the timeout was useless to add. I think the cleanest is 
> keeping the v2 patch, because potentially any waiting code can be called 
> during lockup recovery.

The lockup code itself should never call any waiting code and V2 doesn't 
seem to handle a couple of cases correctly either.

How about moving the fence waiting out of the reset code?

Christian.

Am 04.08.2014 um 15:34 schrieb Maarten Lankhorst:
> Hey,
>
> op 04-08-14 13:57, Christian K?nig schreef:
>> Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst:
>>> op 04-08-14 10:36, Christian K?nig schreef:
 Hi Maarten,

 Sorry for the delay. I've got way to much todo recently.

 Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
> On 01-08-14 18:35, Christian K?nig wrote:
>> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
>>> Signed-off-by: Maarten Lankhorst 
>>> ---
>>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not
>>> allowing radeon_fence_driver_check_lockup to take exclusive_lock,
>>> and kill it during lockup recovery instead.
>> That looks like the delayed work starts running as soon as we submit a 
>> fence, and not when it's needed for waiting.
>>
>> Since it's a backup for failing IRQs I would rather put it into 
>> radeon_irq_kms.c and start/stop it when the IRQs are started/stoped.
> The delayed work is not just for failing irq's, it's also the handler 
> that's used to detect lockups, which is why I trigger after processing 
> fences, and reset the timer after processing.
 The idea was turning the delayed work on and off when we turn the irq on 
 and off as well, processing of the delayed work handler can still happen 
 in radeon_fence.c

> Specifically what happened was this scenario:
>
> - lock up occurs
> - write lock taken by gpu_reset
> - delayed work runs, tries to acquire read lock, blocks
> - gpu_reset tries to cancel delayed work synchronously
> - has to wait for delayed work to finish -> deadlock
 Why do you want to disable the work item from the lockup handler in the 
 first place?

 Just take the exclusive lock in the work item, when it concurrently runs 
 with the lockup handler it will just block for the lockup handler to 
 complete.
>>> With the delayed work radeon_fence_wait no longer handles unreliable 
>>> interrupts itself, so it has to run from the lockup handler.
>>> But an alternative solution could be adding a radeon_fence_wait_timeout, 
>>> ignore the timeout and check if fence is signaled on timeout.
>>> This would probably be a cleaner solution.
>> Yeah, agree. Manually specifying a timeout in the fence wait on lockup 
>> handling sounds like the best alternative to me.
> It'a pain to deal with gpu reset.
>
> I've now tried other solutions but that would mean reverting to the old style 
> during gpu lockup recovery, and only running the delayed work when !lockup.
> But this meant that the timeout was useless to add. I think the cleanest is 
> keeping the v2 patch, because potentially any waiting code can be called 
> during lockup recovery.
>
> ~Maarten
>

[Bug 82139] [r600g, bisected] multiple ubo piglit regressions

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

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

--- Comment #2 from Andreas Boll  ---
Created attachment 104009
  --> https://bugs.freedesktop.org/attachment.cgi?id=104009=edit
arb_uniform_buffer_object-rendering dump after 01bf8bb

R600_DEBUG=fs,vs,gs,ps bin/arb_uniform_buffer_object-rendering -fbo

-- 
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/20140804/ee7f5f10/attachment.html>

[Bug 82139] [r600g, bisected] multiple ubo piglit regressions

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

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

--- Comment #1 from Andreas Boll  ---
Created attachment 104008
  --> https://bugs.freedesktop.org/attachment.cgi?id=104008=edit
arb_uniform_buffer_object-rendering dump before 01bf8bb

R600_DEBUG=fs,vs,gs,ps bin/arb_uniform_buffer_object-rendering -fbo

-- 
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/20140804/8e788b2e/attachment.html>

[Bug 82139] New: [r600g, bisected] multiple ubo piglit regressions

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

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

  Priority: medium
Bug ID: 82139
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [r600g, bisected] multiple ubo piglit regressions
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: andreas.boll.dev at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

I noticed multiple ubo piglit regressions on 10.3-devel / r600g / BARTS
since this commit:

commit 01bf8bb87565ed3677e43c6b6deeb90378d88647
Author: Brian Paul 
Date:   Tue Jul 1 07:57:43 2014 -0600

st/mesa: don't use address register for constant-indexed ir_binop_ubo_load

Before, we were always using the address register and indirect addressing
to index into a UBO constant buffer.  With this change we only do that
when necessary.

Using the piglit bin/arb_uniform_buffer_object-rendering test as an
example:

Shader code:
  uniform ub_rot {float rotation; };
  ...
  m[1][1] = cos(rotation);

Before:
  IMM[1] INT32 {0, 1, 0, 0}
  1: UARL ADDR[0].x, IMM[1].
  2: MOV TEMP[0].x, CONST[3][ADDR[0].x].
  3: COS TEMP[1].x, TEMP[0].

After:
  0: COS TEMP[0].x, CONST[3][0].

Reviewed-by: Roland Scheidegger 

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index d660a6b..69d67e1 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -1971,9 +1971,17 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
   assert(ir->type->is_vector() || ir->type->is_scalar());

   if (const_offset_ir) {
- index_reg = st_src_reg_for_int(const_offset / 16);
-  } else {
- emit(ir, TGSI_OPCODE_USHR, st_dst_reg(index_reg), op[1],
st_src_reg_for_int(4));
+ /* Constant index into constant buffer */
+ cbuf.reladdr = NULL;
+ cbuf.index = const_offset / 16;
+ cbuf.has_index2 = true;
+  }
+  else {
+ /* Relative/variable index into constant buffer */
+ emit(ir, TGSI_OPCODE_USHR, st_dst_reg(index_reg), op[1],
+  st_src_reg_for_int(4));
+ cbuf.reladdr = ralloc(mem_ctx, st_src_reg);
+ memcpy(cbuf.reladdr, _reg, sizeof(index_reg));
   }

   cbuf.swizzle = swizzle_for_size(ir->type->vector_elements);
@@ -1982,9 +1990,6 @@ glsl_to_tgsi_visitor::visit(ir_expression *ir)
 const_offset % 16 / 4,
 const_offset % 16 / 4);

-  cbuf.reladdr = ralloc(mem_ctx, st_src_reg);
-  memcpy(cbuf.reladdr, _reg, sizeof(index_reg));
-
   if (ir->type->base_type == GLSL_TYPE_BOOL) {
  emit(ir, TGSI_OPCODE_USNE, result_dst, cbuf, st_src_reg_for_int(0));
   } else {


I guess it unhides a driver bug, since softpipe and llvmpipe are not affected.

Regressed tests:

spec/ARB_uniform_buffer_object/bufferstorage
spec/ARB_uniform_buffer_object/maxblocks
spec/ARB_uniform_buffer_object/rendering

spec/glsl-1.40/uniform_buffer/fs-mat4
spec/glsl-1.40/uniform_buffer/fs-two-members
spec/glsl-1.40/uniform_buffer/vs-mat4
spec/glsl-1.40/uniform_buffer/vs-two-members

spec/glsl-1.50/uniform_buffer/gs-mat4
spec/glsl-1.50/uniform_buffer/gs-two-members


Thanks,
Andreas.

-- 
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/20140804/9fe9af1e/attachment-0001.html>

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Laurent Pinchart]

On Monday 04 August 2014 09:30:04 Daniel Vetter wrote:
> On Fri, Aug 01, 2014 at 02:58:21PM +0200, Laurent Pinchart wrote:
> > On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote:
> >> On 05/12/14 11:04, Randy Dunlap wrote:
> >>> On 05/12/2014 08:54 AM, Daniel Vetter wrote:
>  On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote:
> > On 05/12/2014 01:58 AM, Daniel Vetter wrote:
> >> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
> > If we decide to go for property documentation inside the source
> > code then I believe we'll have to create our own format, as
> > creating a properties table from kerneldoc information extracted
> > from comments is probably not possible.
>  
>  Can comeone pick up the ball here and figure out what needs to be
>  done?
>  
>  The reason why I want a central place for the documentation is to
>  force people to collaborate outside their own sandbox when adding
>  properties. Whether that's docbook or some text file I don't care
>  so much at this point. The fact that it's a central place should
>  mandate that the patches changing it will go through dri-devel
>  and so everyone should se them, and when adding new properties it
>  would make the patch author more likely to look around a bit
>  before adding another slighty incompatible version of the same
>  property. If someone has a better suggestion how to encforce this
>  I'm all ears.
>  
>  Of course this idea can still fail if our esteemed maintainer
>  merges stuff without checking for violations of this policy.
>  Dave, any thoughts on the subject?
> >>> 
> >>> Yeah I'm happy to block merging stuff, if we can spot new 
> >>> properties when stuff is posted on dri-devel, so much the better,
> >>> 
> >>> most drivers still send everything via dri-devel anyways, its only
> >>> really Intel I have to worry about so far,
> >> 
> >> I'll enforce that all prop stuff gets cc: dri-devel and that it has
> >> updates for the prop docs.
> >> 
> >>> But we should definitely add it to the new driver review checklist
> >>> as well.
> >>> 
> >>> I'm also on the side of this patch is ugly and makes my eyes burn,
> >>> please please get a plan to use something else ASAP, I'm willing
> >>> to merge this but I'm tempted to give it a lifetime of a kernel or
> >>> two before I burn it.
> >> 
> >> Ok, I'll try to move "make kerneldoc suck less" up the task list
> >> and maybe find someone to do it for me internally ;-)
> > 
> > I certainly have no objections to making kerneldoc suck less.
> > There was already an attempt to use asciidoc (like git uses) for
> > kernel-doc (a few years ago, by Sam Ravnborg).  I support(ed) that
> > effort.
>  
>  Hm, do you have pointers to those? My google-fu seems lacking ...
> >>> 
> >>> I googled for /kernel doc asciidoc ravnborg/ and found several hits
> >>> for them.
> >>> 
>  Ok, let's move this to the top and start discussions. The past few
>  months I've written piles of kerneldoc comments for the DRM DocBook
>  (all pulled in as kerneldoc, docbook .tmpl has just the chapter
>  structure). DOC: sections are really useful to pull all the actual
>  documentation out of the docbook xml into kerneldoc.
>  
>  But I've also done piles of docs for intel-gpu-tools, which is using
>  gtkdoc. And there are some clear deficiencies:
>  
>  - No markdown for inline coments. Lack of lists and tables is hurting
>    especially badly. If we add this (and I don't care one iota whether
>    it's
> >>> 
> >>> Yes, I've tried to add lists to kernel-doc notation but have failed so
> >>> far.
> >>> 
>    markdown or asciidoc or something else as long as it's readable
>    plain text in comments) we should be able to move all the existing
>    docbook xml paragraphs/lists/tables into kerneldoc comments.
>  
>  - Automatic cross-referencing of functions. If you place e.g.
>    function() or #struct anywhere in a documentation comment gtk-doc
>    automatically inserts a hyperlink to the relevant documentation
>    page across the entire project. Really powerful and makes overview
>    sections much more useful entry points for beginners since they can
>    easily jump back betweeen the high-level overview and low-
>    level per-function documentation.
> >>> 
> >>> That's a nice-to-have IMO, but a really nice one.
> >>> 
>  - In a really perfect world it would help if kerneldoc could collect
>    structure member kerneldoc from per-member comments. Especially for
>    large structures with lots of comments this would bring the
>    kerneldoc and struct member much closer together.
>  
>  So that's 

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

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

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

--- Comment #1 from Alex Deucher  ---
Can you bisect?

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

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Maarten Lankhorst]

Hey,

op 04-08-14 13:57, Christian K?nig schreef:
> Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst:
>> op 04-08-14 10:36, Christian K?nig schreef:
>>> Hi Maarten,
>>>
>>> Sorry for the delay. I've got way to much todo recently.
>>>
>>> Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
 On 01-08-14 18:35, Christian K?nig wrote:
> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
>> Signed-off-by: Maarten Lankhorst 
>> ---
>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not
>> allowing radeon_fence_driver_check_lockup to take exclusive_lock,
>> and kill it during lockup recovery instead.
> That looks like the delayed work starts running as soon as we submit a 
> fence, and not when it's needed for waiting.
>
> Since it's a backup for failing IRQs I would rather put it into 
> radeon_irq_kms.c and start/stop it when the IRQs are started/stoped.
 The delayed work is not just for failing irq's, it's also the handler 
 that's used to detect lockups, which is why I trigger after processing 
 fences, and reset the timer after processing.
>>> The idea was turning the delayed work on and off when we turn the irq on 
>>> and off as well, processing of the delayed work handler can still happen in 
>>> radeon_fence.c
>>>
 Specifically what happened was this scenario:

 - lock up occurs
 - write lock taken by gpu_reset
 - delayed work runs, tries to acquire read lock, blocks
 - gpu_reset tries to cancel delayed work synchronously
 - has to wait for delayed work to finish -> deadlock
>>> Why do you want to disable the work item from the lockup handler in the 
>>> first place?
>>>
>>> Just take the exclusive lock in the work item, when it concurrently runs 
>>> with the lockup handler it will just block for the lockup handler to 
>>> complete.
>> With the delayed work radeon_fence_wait no longer handles unreliable 
>> interrupts itself, so it has to run from the lockup handler.
>> But an alternative solution could be adding a radeon_fence_wait_timeout, 
>> ignore the timeout and check if fence is signaled on timeout.
>> This would probably be a cleaner solution.
>
> Yeah, agree. Manually specifying a timeout in the fence wait on lockup 
> handling sounds like the best alternative to me.
It'a pain to deal with gpu reset.

I've now tried other solutions but that would mean reverting to the old style 
during gpu lockup recovery, and only running the delayed work when !lockup.
But this meant that the timeout was useless to add. I think the cleanest is 
keeping the v2 patch, because potentially any waiting code can be called during 
lockup recovery.

~Maarten

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #13 from Kai  ---
Created attachment 104001
  --> https://bugs.freedesktop.org/attachment.cgi?id=104001=edit
sysporf points to libpixman

According to the sysprof output, libpixman is the place where moste CPU time
goes. If you want the sysprof output, let me know and I e-mail it to you. Not
sure I want to put it on the internet, as didn't have time to check what data
might be disclosed.

-- 
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/20140804/133a9f68/attachment.html>

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #12 from Kai  ---
Created attachment 104000
  --> https://bugs.freedesktop.org/attachment.cgi?id=104000=edit
X uses a lot of CPU cycles, as shown by top

As you can see from this top screenshot, X is using a lot of CPU cycles.

-- 
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/20140804/2537d2a0/attachment.html>

[Bug 81021] AMD CPUs w/ Integrated Graphics (APUs) And Turbo Core Only Boost If "fglrx" Module Is Loaded

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

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

--- Comment #8 from Alex Deucher  ---
I'm not sure why you don't think you need a GPU driver installed.  When the
driver is installed it not only allows the GPU to dynamically adjust it clocks
and voltages up for performance, but also enables low power states and turns
off certain blocks when they are not in use, so overall, you'll probably save
more power with the GPU driver loaded than just leaving the GPU in the state
set up by the bios.

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

[PATCH 1/4] drm/radeon: use packet2 for nop on hawaii with old firmware

[Alex Deucher]

On Fri, Aug 1, 2014 at 2:05 PM, Andreas Boll  
wrote:
> From: Alex Deucher 
>
> Older firmware didn't support the new nop packet.
>
> v2 (Andreas Boll):
>  - Drop usage of packet3 for new firmware
>
> Signed-off-by: Alex Deucher 
> Reviewed-by: Christian K?nig  (v1)
> Signed-off-by: Andreas Boll 
> Cc: stable at vger.kernel.org

Added the series to my 3.17 tree.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/cik.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index c0ea661..e5985d5 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -7900,6 +7900,7 @@ restart_ih:
>  static int cik_startup(struct radeon_device *rdev)
>  {
> struct radeon_ring *ring;
> +   u32 nop;
> int r;
>
> /* enable pcie gen2/3 link */
> @@ -8033,9 +8034,15 @@ static int cik_startup(struct radeon_device *rdev)
> }
> cik_irq_set(rdev);
>
> +   if (rdev->family == CHIP_HAWAII) {
> +   nop = RADEON_CP_PACKET2;
> +   } else {
> +   nop = PACKET3(PACKET3_NOP, 0x3FFF);
> +   }
> +
> ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
> r = radeon_ring_init(rdev, ring, ring->ring_size, 
> RADEON_WB_CP_RPTR_OFFSET,
> -PACKET3(PACKET3_NOP, 0x3FFF));
> +nop);
> if (r)
> return r;
>
> @@ -8043,7 +8050,7 @@ static int cik_startup(struct radeon_device *rdev)
> /* type-2 packets are deprecated on MEC, use type-3 instead */
> ring = >ring[CAYMAN_RING_TYPE_CP1_INDEX];
> r = radeon_ring_init(rdev, ring, ring->ring_size, 
> RADEON_WB_CP1_RPTR_OFFSET,
> -PACKET3(PACKET3_NOP, 0x3FFF));
> +nop);
> if (r)
> return r;
> ring->me = 1; /* first MEC */
> @@ -8054,7 +8061,7 @@ static int cik_startup(struct radeon_device *rdev)
> /* type-2 packets are deprecated on MEC, use type-3 instead */
> ring = >ring[CAYMAN_RING_TYPE_CP2_INDEX];
> r = radeon_ring_init(rdev, ring, ring->ring_size, 
> RADEON_WB_CP2_RPTR_OFFSET,
> -PACKET3(PACKET3_NOP, 0x3FFF));
> +nop);
> if (r)
> return r;
> /* dGPU only have 1 MEC */
> --
> 2.0.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #11 from Kai  ---
I've uploaded the requested files (attachment 103995, attachment 103996,
attachment 103997) and now checked the installed Flash version, it is
11.2.202.394.

-- 
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/20140804/4732f2a6/attachment.html>

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #10 from Kai  ---
Created attachment 103997
  --> https://bugs.freedesktop.org/attachment.cgi?id=103997=edit
glxinfo output

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

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #9 from Kai  ---
Created attachment 103996
  --> https://bugs.freedesktop.org/attachment.cgi?id=103996=edit
dmesg output

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

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #8 from Kai  ---
Created attachment 103995
  --> https://bugs.freedesktop.org/attachment.cgi?id=103995=edit
Xorg.0.log

-- 
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/20140804/5801d93c/attachment.html>

[PATCH 1/2] drm/exynos: g2d: make ioctls more robust

[Tobias Jakobi]

On 2014-08-04 02:28, Inki Dae wrote:
> Oops, sorry. I didn't check v2.
No problem :)

It would be good if you could also check the libdrm patches that I've 
resent some while ago.

With best wishes,
Tobias

[GIT PULL] exynos-drm-next

[Inki Dae]

Hi Dave,

   This pull request includes i80 interface support, module auto-loading
   ipp consolidation, and trivail fixups and cleanups.

Summary:
- Add i80 interface support. For this, we added some features to
  Exynos drm framework, which don't affect any other SoC and common
  framework because they are specific to Exynos drm.
- Add module auto-loading support. For this, sub drivers of Exynos drm
  exports their of match tables to userspace. This allows modules to be
  loaded automatically based on devicetree information
- Consolidate ipp driver. This patch just just includes cleanups and
  a littl bit refactoring codes.

If there is any problem, please kindly let me know.

Thanks,
Inki Dae

The following changes since commit 08d645c181e9b9482c249e82a061c279a986db15:

  agp: remove read/write stubs (2014-08-02 06:43:51 +1000)

are available in the git repository at:

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

for you to fetch changes up to ef7ce055a9e00f6376416466b996515a27b7cb31:

  drm/exynos: g2d: let exynos_g2d_get_ver_ioctl fail (2014-08-04 13:39:28 +0900)


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

Andrzej Hajda (12):
  drm/exynos/ipp: remove type casting
  drm/exynos/ipp: remove unused field from exynos_drm_ipp_private
  drm/exynos/ipp: remove struct exynos_drm_ipp_private
  drm/exynos/ipp: correct address type
  drm/exynos/ipp: remove temporary variable
  drm/exynos/ipp: remove incorrect checks of list_first_entry result
  drm/exynos/ipp: simplify memory check function
  drm/exynos/ipp: remove useless registration checks
  drm/exynos/ipp: simplify ipp_find_obj
  drm/exynos/ipp: remove redundant messages
  drm/exynos/ipp: simplify ipp_create_id
  drm/exynos/ipp: simplify ipp_find_driver

Jingoo Han (1):
  drm/exynos: dp: Use correct module license

Joonyoung Shim (1):
  drm/exynos: control blending of mixer graphic layer 0

Krzysztof Kozlowski (1):
  drm/exynos: Fix NULL pointer exception when suspending without components

Marek Szyprowski (2):
  drm/exynos: hdmi: make 'hdmi-en' regulator optional and keep it enabled
  drm/exynos: hdmi: enable exynos 4210 and 4x12 soc support

Sachin Kamat (2):
  drm/exynos: Remove unused variable from exynos_hdmi.c
  drm/exynos: Remove unused variable in exynos_drm_gem.c

Seung-Woo Kim (1):
  drm/exynos: hdmi: add null check for hdmiphy_port

Sjoerd Simons (3):
  Subject: Revert "drm/exynos: fix module build error"
  Subject: Revert "drm/exynos: remove MODULE_DEVICE_TABLE definitions"
  drm/exynos: Add MODULE_DEVICE_TABLE entries for various components

Tobias Jakobi (2):
  drm/exynos: g2d: make ioctls more robust
  drm/exynos: g2d: let exynos_g2d_get_ver_ioctl fail

YoungJun Cho (12):
  drm/exynos: dsi: move the EoT packets configuration point
  drm/exynos: use wait_event_timeout() for safety usage
  ARM: dts: samsung-fimd: add LCD I80 interface specific properties
  drm/exynos: add TE handler to support LCD I80 interface
  drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface
  drm/exynos: fimd: support LCD I80 interface
  ARM: dts: exynos_dsim: add exynos5410 compatible to DT bindings
  drm/exynos: dsi: add driver data to support Exynos5410/5420/5440 SoCs
  ARM: dts: exynos4: add system register property
  ARM: dts: exynos5: add system register property
  ARM: dts: exynos5420: add mipi-phy node
  ARM: dts: exynos5420: add dsi node

 .../devicetree/bindings/video/exynos_dsim.txt  |4 +-
 .../devicetree/bindings/video/exynos_mixer.txt |5 +-
 .../devicetree/bindings/video/samsung-fimd.txt |   28 ++
 arch/arm/boot/dts/exynos4.dtsi |1 +
 arch/arm/boot/dts/exynos5.dtsi |1 +
 arch/arm/boot/dts/exynos5420.dtsi  |   20 ++
 drivers/gpu/drm/exynos/Kconfig |1 +
 drivers/gpu/drm/exynos/exynos_dp_core.c|3 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   15 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |7 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   10 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|  270 +--
 drivers/gpu/drm/exynos/exynos_drm_fimc.c   |1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  277 
 drivers/gpu/drm/exynos/exynos_drm_g2d.c|   29 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c|3 -
 drivers/gpu/drm/exynos/exynos_drm_ipp.c|  259 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.h|4 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c|1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   36 

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Christian König]

Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst:
> op 04-08-14 10:36, Christian K?nig schreef:
>> Hi Maarten,
>>
>> Sorry for the delay. I've got way to much todo recently.
>>
>> Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
>>> On 01-08-14 18:35, Christian K?nig wrote:
 Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
> Signed-off-by: Maarten Lankhorst 
> ---
> V1 had a nasty bug breaking gpu lockup recovery. The fix is not
> allowing radeon_fence_driver_check_lockup to take exclusive_lock,
> and kill it during lockup recovery instead.
 That looks like the delayed work starts running as soon as we submit a 
 fence, and not when it's needed for waiting.

 Since it's a backup for failing IRQs I would rather put it into 
 radeon_irq_kms.c and start/stop it when the IRQs are started/stoped.
>>> The delayed work is not just for failing irq's, it's also the handler 
>>> that's used to detect lockups, which is why I trigger after processing 
>>> fences, and reset the timer after processing.
>> The idea was turning the delayed work on and off when we turn the irq on and 
>> off as well, processing of the delayed work handler can still happen in 
>> radeon_fence.c
>>
>>> Specifically what happened was this scenario:
>>>
>>> - lock up occurs
>>> - write lock taken by gpu_reset
>>> - delayed work runs, tries to acquire read lock, blocks
>>> - gpu_reset tries to cancel delayed work synchronously
>>> - has to wait for delayed work to finish -> deadlock
>> Why do you want to disable the work item from the lockup handler in the 
>> first place?
>>
>> Just take the exclusive lock in the work item, when it concurrently runs 
>> with the lockup handler it will just block for the lockup handler to 
>> complete.
> With the delayed work radeon_fence_wait no longer handles unreliable 
> interrupts itself, so it has to run from the lockup handler.
> But an alternative solution could be adding a radeon_fence_wait_timeout, 
> ignore the timeout and check if fence is signaled on timeout.
> This would probably be a cleaner solution.

Yeah, agree. Manually specifying a timeout in the fence wait on lockup 
handling sounds like the best alternative to me.

Christian.

>
> ~Maarten
>

3D and then OpenCL on VIA VX800/VX820

[Dave Airlie]

On 4 August 2014 11:52, Felix Nawothnig  wrote:
> Hey...
>
> I know that this sounds crazy, but I'd like to attempt to do it - that is if
> it is possible at all. :-)
>
> From following the Noveau and Gallium development over the last years
> (including reading the source code) I have a slight clue how to do things
> but basically I'm a newbie to 3D driver development. (I do on the other hand
> have solid knowledge of higher level 3D programming, and solid knowledge of
> low-level / driver / hardware development).
>
> Still, I'm willing to learn - so...
>
> Tell me if it's possible at all (or maybe if just the first part might be
> possible) and give me a very slight hint where to start (obviously the start
> would be how to begin the 3D support for VX800/VX820).
>
> And yea. I know this will take ages if I do this by myself - and the chances
> to succeed are slim...
>
> But everyone needs a hobby. ;-)
>
> And I love the idea of supporting OpenCL on an architecture where the vendor
> would probably never ever support it on any OS. :-)

These are DX9 parts from what I know, so the most you'd get going on
them is similar
to what R500 or NV40 exposes, GL 2.1, I highly doubt they do MSAA, and even
higher doubt they have any ability to run OpenCL in a useful or manner.

OpenCL needs features the GPU doesn't expose.

You'd also want to start with a KMS driver (openchrome) and at least
get that working first,
then maybe build a gallium driver on top of that.

The Via DX11 chips might be more interesting in that they might have
some useful hw bits,
though I've no idea how you'd start to RE them.

Dave.

[PATCH 9/9] drm: add Rockchip Soc rk3288 edp connector

[mark yao]

Signed-off-by: mark yao 
---
 drivers/gpu/drm/rockchip/connector/Kconfig |9 +
 drivers/gpu/drm/rockchip/connector/Makefile|1 +
 .../gpu/drm/rockchip/connector/rk3288_dp_core.c|  586 ++
 .../gpu/drm/rockchip/connector/rk3288_dp_core.h|  355 ++
 drivers/gpu/drm/rockchip/connector/rk3288_dp_reg.c | 1192 
 drivers/gpu/drm/rockchip/connector/rk3288_dp_reg.h |  378 +++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   13 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|3 +
 8 files changed, 2537 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_dp_core.c
 create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_dp_core.h
 create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_dp_reg.c
 create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_dp_reg.h

diff --git a/drivers/gpu/drm/rockchip/connector/Kconfig 
b/drivers/gpu/drm/rockchip/connector/Kconfig
index 248942f..caffc5b 100644
--- a/drivers/gpu/drm/rockchip/connector/Kconfig
+++ b/drivers/gpu/drm/rockchip/connector/Kconfig
@@ -6,3 +6,12 @@ config RK3288_LVDS
  rk3288 lvds transmitter support ttl rgb, lvds and dual lvds
  mode, dual lvds mode is support for the plane which need dual
  lvds channels.
+
+config RK3288_DP
+   bool "RK3288 edp connector support"
+   depends on DRM_ROCKCHIP_CONNECTOR
+   help
+ Choose this option if you have a rk32xx eDP connector.
+ Rockchip rk3288 SoC has eDP TX Controller can be used.
+ If you have an Embedded DisplayPort Panel, say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/connector/Makefile 
b/drivers/gpu/drm/rockchip/connector/Makefile
index dcfbdef..4be77ea 100644
--- a/drivers/gpu/drm/rockchip/connector/Makefile
+++ b/drivers/gpu/drm/rockchip/connector/Makefile
@@ -2,3 +2,4 @@
 # Makefile for display connector like lvds edp mipi
 #
 obj-$(CONFIG_RK3288_LVDS)  += rk3288_lvds.o
+obj-$(CONFIG_RK3288_DP)+= rk3288_dp_core.o rk3288_dp_reg.o
diff --git a/drivers/gpu/drm/rockchip/connector/rk3288_dp_core.c 
b/drivers/gpu/drm/rockchip/connector/rk3288_dp_core.c
new file mode 100644
index 000..3756383
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/connector/rk3288_dp_core.c
@@ -0,0 +1,586 @@
+/*
+* Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+* Author:
+*  yxj 
+*  cym 
+*
+* based on exynos_dp_core.c
+*
+* This program is free software; you can redistribute it and/or modify it
+* under the terms of the GNU General Public License as published by the
+* Free Software Foundation; either version 2 of the License, or (at your
+* option) any later version.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rk3288_dp_core.h"
+
+static int rk3288_edp_clk_enable(struct rk3288_edp *edp)
+{
+   int ret = 0;
+
+   if (!edp->clk_on) {
+   ret = clk_prepare_enable(edp->pclk);
+   if (ret < 0) {
+   dev_err(edp->dev, "cannot enable edp pclk %d\n", ret);
+   goto err_pclk;
+   }
+
+   ret = clk_prepare_enable(edp->clk_edp);
+   if (ret < 0) {
+   dev_err(edp->dev, "cannot enable clk_edp %d\n", ret);
+   goto err_clk_edp;
+   }
+
+   ret = clk_set_parent(edp->clk_24m, edp->clk_24m_parent);
+   if (ret < 0) {
+   dev_err(edp->dev, "cannot set edp clk_24m parent %d\n",
+   ret);
+   goto err_clk_24m;
+   }
+
+   ret = clk_prepare_enable(edp->clk_24m);
+   if (ret < 0) {
+   dev_err(edp->dev, "cannot enable edp clk_24m %d\n",
+   ret);
+   goto err_clk_24m;
+   }
+
+   edp->clk_on = true;
+   }
+
+   return 0;
+
+err_clk_24m:
+   clk_disable_unprepare(edp->clk_edp);
+err_clk_edp:
+   clk_disable_unprepare(edp->pclk);
+err_pclk:
+   edp->clk_on = false;
+
+   return ret;
+}
+
+static int rk3288_edp_clk_disable(struct rk3288_edp *edp)
+{
+   if (edp->clk_on) {
+   clk_disable_unprepare(edp->pclk);
+   clk_disable_unprepare(edp->clk_edp);
+   clk_disable_unprepare(edp->clk_24m);
+   edp->clk_on = false;
+   }
+
+   return 0;
+}
+
+static int rk3288_edp_pre_init(struct rk3288_edp *edp)
+{
+   u32 val;
+   int ret = 0;
+
+   val = GRF_EDP_REF_CLK_SEL_INTER | (GRF_EDP_REF_CLK_SEL_INTER << 16);
+   ret = regmap_write(edp->grf, edp->soc_data->grf_soc_con12, val);
+   if (ret != 0) {
+   dev_err(edp->dev, "Could not write to GRF: %d\n", ret);
+   return ret;
+   }
+
+   

[PATCH 8/9] Add devicetree bindings for Rockchip Soc EDP

[mark yao]

Signed-off-by: mark yao 
---
 .../devicetree/bindings/video/rockchip-panel.txt   |   34 
 1 file changed, 34 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/rockchip-panel.txt 
b/Documentation/devicetree/bindings/video/rockchip-panel.txt
index f599806..f6d80f6 100644
--- a/Documentation/devicetree/bindings/video/rockchip-panel.txt
+++ b/Documentation/devicetree/bindings/video/rockchip-panel.txt
@@ -80,3 +80,37 @@ Example:
rockchip,data-width = <24>;
rockchip,panel = <>;
};
+
+Rockchip RK3288 EDP interface
+
+Required properties:
+-compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+- clocks: from common clock binding: handle to dp clock.
+   of memory mapped region.
+- clock-names: from common clock binding:
+   Required elements: "clk_edp"
+   "clk_edp_24m"
+   "clk_edp_24m_parent"
+   "pclk_edp"
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+- resets: Must contain an entry for each entry in reset-names.
+   See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - edp
+- rockchip,panel: required a panel node
+
+Example:
+   edp: edp at ff97 {
+   compatible = "rockchip,rk3288-edp";
+reg = <0xff97 0x4000>;
+interrupts = ;
+clocks = < SCLK_EDP>, < SCLK_EDP_24M>, < 
PCLK_EDP_CTRL>, <>;
+clock-names = "clk_edp", "clk_edp_24m", "pclk_edp", 
"clk_edp_24m_parent";
+
+rockchip,grf = <>;
+resets = < 111>;
+reset-names = "edp";
+   rockchip,panel = <>;
+   };
-- 
1.7.9.5

[PATCH 7/9] drm: add Rockchip Soc rk3288 lvds connector

[mark yao]

Signed-off-by: mark yao 
---
 drivers/gpu/drm/rockchip/Kconfig |1 +
 drivers/gpu/drm/rockchip/Makefile|2 +-
 drivers/gpu/drm/rockchip/connector/Kconfig   |8 +
 drivers/gpu/drm/rockchip/connector/Makefile  |4 +
 drivers/gpu/drm/rockchip/connector/rk3288_lvds.c |  332 ++
 drivers/gpu/drm/rockchip/connector/rk3288_lvds.h |   50 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |   13 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h  |3 +
 8 files changed, 412 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/connector/Kconfig
 create mode 100644 drivers/gpu/drm/rockchip/connector/Makefile
 create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_lvds.c
 create mode 100644 drivers/gpu/drm/rockchip/connector/rk3288_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index ccce827..407cbb6 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -40,3 +40,4 @@ config DRM_ROCKCHIP_CONNECTOR
  such as lcd plane, lvds, edp , mipi, etc.

 source "drivers/gpu/drm/rockchip/lcdc/Kconfig"
+source "drivers/gpu/drm/rockchip/connector/Kconfig"
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 6d49edc..7d5877a 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -8,6 +8,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_gem.o \
rockchip_drm_fb.o rockchip_drm_fbdev.o \
rockchip_panel.o

-obj-$(CONFIG_DRM_ROCKCHIP_CONNECTOR) += rockchip_drm_connector.o
+obj-$(CONFIG_DRM_ROCKCHIP_CONNECTOR) += rockchip_drm_connector.o connector/
 obj-$(CONFIG_DRM_ROCKCHIP_LCDC) += rockchip_drm_lcdc.o lcdc/
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/connector/Kconfig 
b/drivers/gpu/drm/rockchip/connector/Kconfig
new file mode 100644
index 000..248942f
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/connector/Kconfig
@@ -0,0 +1,8 @@
+config RK3288_LVDS
+   bool "RK3288 lvds connector support"
+   depends on DRM_ROCKCHIP_CONNECTOR
+   help
+ Choose this option if you have a rk3288 lvds connector.
+ rk3288 lvds transmitter support ttl rgb, lvds and dual lvds
+ mode, dual lvds mode is support for the plane which need dual
+ lvds channels.
diff --git a/drivers/gpu/drm/rockchip/connector/Makefile 
b/drivers/gpu/drm/rockchip/connector/Makefile
new file mode 100644
index 000..dcfbdef
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/connector/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for display connector like lvds edp mipi
+#
+obj-$(CONFIG_RK3288_LVDS)  += rk3288_lvds.o
diff --git a/drivers/gpu/drm/rockchip/connector/rk3288_lvds.c 
b/drivers/gpu/drm/rockchip/connector/rk3288_lvds.c
new file mode 100644
index 000..3ca4c6f
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/connector/rk3288_lvds.c
@@ -0,0 +1,332 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  hjc 
+ *  mark yao 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "../rockchip_drm_connector.h"
+#include "../rockchip_drm_lcdc.h"
+#include "rk3288_lvds.h"
+
+/*
+ * @grf_offset: offset inside the grf regmap for setting the rockchip lvds
+ */
+struct rk3288_lvds_soc_data {
+   int grf_gpio1d_iomux;
+   int grf_soc_con6;
+   int grf_soc_con7;
+};
+
+struct rk3288_lvds {
+   void *base;
+   int format;
+   struct drm_display_mode mode;
+   struct device *dev;
+   void __iomem *regs;
+   struct regmap *grf;
+   struct rk3288_lvds_soc_data *soc_data;
+   struct clk *pclk;
+   bool standby;
+};
+
+static inline void lvds_writel(struct rk3288_lvds *lvds, u32 offset, u32 val)
+{
+   writel_relaxed(val, lvds->regs + offset);
+   writel_relaxed(val, lvds->regs + offset + 0x100);
+}
+
+static inline int lvds_name_to_format(const char *s)
+{
+   if (!s)
+   return 0;
+
+   if (strncmp(s, "jeida", 6) == 0)
+   return LVDS_FORMAT_JEIDA;
+   else if (strncmp(s, "vesa", 6) == 0)
+   return LVDS_FORMAT_VESA;
+
+   return 0;
+}
+
+static void rk3288_lvds_disable(struct rockchip_connector *conn)
+{
+   struct rk3288_lvds *lvds = conn->priv;
+   int ret = 0;
+
+   if (lvds->standby)
+   

[PATCH 6/9] Add devicetree bindings for Rockchip Soc LVDS

[mark yao]

Signed-off-by: mark yao 
---
 .../devicetree/bindings/video/rockchip-panel.txt   |   30 
 1 file changed, 30 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/rockchip-panel.txt 
b/Documentation/devicetree/bindings/video/rockchip-panel.txt
index 9fc200a..f599806 100644
--- a/Documentation/devicetree/bindings/video/rockchip-panel.txt
+++ b/Documentation/devicetree/bindings/video/rockchip-panel.txt
@@ -50,3 +50,33 @@ Example:
};

};
+
+Rockchip RK3288 LVDS interface
+
+Required properties:
+-compatible: "rockchip,rk3288-lvds";
+
+- reg: physical base address of the controller and length
+- clocks: from common clock binding: handle to dp clock.
+   of memory mapped region.
+- clock-names: from common clock binding: Shall be "pclk_lvds".
+   pclk_lvds: for power domain, if it disable soc will power down
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+- rockchip,data-mapping: should be "vesa" or "jeida"
+   This describes how the color bits are laid out in the
+   serialized LVDS signal.
+- rockchip,data-width: should be <18> or <24>
+- rockchip,panel: required a panel node
+
+Example:
+   lvds: lvds at ff96c000 {
+   compatible = "rockchip,rk3288-lvds";
+   reg = <0xff96c000 0x4000>;
+   clocks = < PCLK_LVDS_PHY>;
+   clock-names = "pclk_lvds";
+
+   rockchip,grf = <>;
+   rockchip,data-mapping = "jeida";
+   rockchip,data-width = <24>;
+   rockchip,panel = <>;
+   };
-- 
1.7.9.5

[PATCH 5/9] drm: add Rockchip rk3288 lcd controller driver

[mark yao]

Signed-off-by: mark yao 
---
 drivers/gpu/drm/rockchip/Kconfig|2 +
 drivers/gpu/drm/rockchip/Makefile   |2 +-
 drivers/gpu/drm/rockchip/lcdc/Kconfig   |9 +
 drivers/gpu/drm/rockchip/lcdc/Makefile  |4 +
 drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.c |  819 ++
 drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.h | 1202 +++
 6 files changed, 2037 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/lcdc/Kconfig
 create mode 100644 drivers/gpu/drm/rockchip/lcdc/Makefile
 create mode 100644 drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.c
 create mode 100644 drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 592e999..ccce827 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -38,3 +38,5 @@ config DRM_ROCKCHIP_CONNECTOR
  Choose this option if you want to use Rockchip Primary DISPLAY.
  The driver provides an abstraction for Rockchip display devices,
  such as lcd plane, lvds, edp , mipi, etc.
+
+source "drivers/gpu/drm/rockchip/lcdc/Kconfig"
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a5e5132..6d49edc 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -9,5 +9,5 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_gem.o \
rockchip_panel.o

 obj-$(CONFIG_DRM_ROCKCHIP_CONNECTOR) += rockchip_drm_connector.o
-obj-$(CONFIG_DRM_ROCKCHIP_LCDC) += rockchip_drm_lcdc.o
+obj-$(CONFIG_DRM_ROCKCHIP_LCDC) += rockchip_drm_lcdc.o lcdc/
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/lcdc/Kconfig 
b/drivers/gpu/drm/rockchip/lcdc/Kconfig
new file mode 100644
index 000..2b94057
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/lcdc/Kconfig
@@ -0,0 +1,9 @@
+config LCDC_RK3288
+bool "rk3288 lcdc support"
+depends on DRM_ROCKCHIP_LCDC
+help
+ Choose this option if you have a rk3288 lcd controller.
+ rk3288 lcdc is the display interface from memory frame buffer
+ to display device. There are two lcd controllers on rk3288,
+ They have same regs setting, can use same drivers. We use the
+ lcdc id distinguish between them
diff --git a/drivers/gpu/drm/rockchip/lcdc/Makefile 
b/drivers/gpu/drm/rockchip/lcdc/Makefile
new file mode 100644
index 000..943dcd6
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/lcdc/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for the lcd control device driver.
+
+obj-$(CONFIG_LCDC_RK3288) += rk3288_lcdc.o
diff --git a/drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.c 
b/drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.c
new file mode 100644
index 000..f1b016c
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/lcdc/rk3288_lcdc.c
@@ -0,0 +1,819 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  hjc 
+ *  mark yao 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_OF
+#include 
+#include 
+#endif
+
+#include "../rockchip_drm_lcdc.h"
+#include "rk3288_lcdc.h"
+
+#define RK3288_LCDC_BIG_BASE 0xff93
+#define RK3288_LCDC_LIT_BASE 0xff94
+
+static struct lcdc_win_data lcdc_win[] = {
+   [0] = {
+   .id = 0,
+   .zpos = ZPOS_DEFAULT_WIN,
+   .fmt_10 = 0,
+   .win_lb_mode = 0x4,
+   .swap_rb = 0,
+   },
+   [1] = {
+   .id = 1,
+   .zpos = ZPOS_UNUSED_WIN,
+   .fmt_10 = 0,
+   .win_lb_mode = 0x4,
+   .swap_rb = 0,
+   },
+   [2] = {
+   .id = 2,
+   .zpos = ZPOS_CURSOR_WIN,
+   .fmt_10 = 0,
+   .win_lb_mode = 0x4,
+   .swap_rb = 0,
+   },
+   [3] = {
+   .id = 3,
+   .zpos = ZPOS_UNUSED_WIN,
+   },
+};
+
+static void rk3288_lcdc_win_commit(struct lcdc_driver *lcdc_drv,
+  struct lcdc_win_data *win);
+static void rk3288_lcdc_dpms(struct lcdc_driver *lcdc_drv, int mode);
+
+static int rk3288_lcdc_get_id(u32 phy_base)
+{
+   if (phy_base == RK3288_LCDC_BIG_BASE)
+   return 0;
+   else if (phy_base == RK3288_LCDC_LIT_BASE)
+   return 1;
+   else
+   return -EINVAL;
+}
+
+static int rk3288_lcdc_clk_enable(struct lcdc_device *lcdc_dev)
+{
+   int 

[PATCH 4/9] Add devicetree bindings for Rockchip lcd controller

[mark yao]

Signed-off-by: mark yao 
---
 .../devicetree/bindings/video/rockchip-lcdc.txt|   33 
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-lcdc.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-lcdc.txt 
b/Documentation/devicetree/bindings/video/rockchip-lcdc.txt
new file mode 100644
index 000..7fb2b73
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-lcdc.txt
@@ -0,0 +1,33 @@
+Device-Tree bindings for Rockchip SoC display controller (LCDC)
+
+LCDC (LCD Controller) is the Display Controller for the Rockchip
+series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3066-lcdc";
+   "rockchip,rk3188-lcdc";
+   "rockchip,rk3288-lcdc";
+
+- interrupts: should contain a list of all LCDC IP block interrupts in the
+order: VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+
+- clock-names: Must contain
+   aclk_lcdc: for ddr buffer transfer.
+   hclk_lcdc: for ahb bus to R/W the phy regs.
+   dclk_lcdc: pixel clock.
+
+Example:
+SoC specific DT entry:
+   lcdc1: lcdc at ff94 {
+   compatible = "rockchip,rk3288-lcdc";
+   reg = <0xff94 0x19c>;
+   interrupts = ;
+   clocks = < ACLK_LCDC1>, < DCLK_LCDC1>, < 
HCLK_LCDC1>;
+   clock-names = "aclk_lcdc", "dclk_lcdc", "hclk_lcdc";
+   };
-- 
1.7.9.5

[PATCH 3/9] drm: add driver for panels used by the Rockchip DRM

[mark yao]

Signed-off-by: mark yao 
---
 drivers/gpu/drm/rockchip/Makefile |3 +-
 drivers/gpu/drm/rockchip/rockchip_panel.c |  297 +
 2 files changed, 299 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_panel.c

diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 45c9d50..a5e5132 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -5,7 +5,8 @@
 ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/rockchip

 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_gem.o \
-   rockchip_drm_fb.o rockchip_drm_fbdev.o
+   rockchip_drm_fb.o rockchip_drm_fbdev.o \
+   rockchip_panel.o

 obj-$(CONFIG_DRM_ROCKCHIP_CONNECTOR) += rockchip_drm_connector.o
 obj-$(CONFIG_DRM_ROCKCHIP_LCDC) += rockchip_drm_lcdc.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_panel.c 
b/drivers/gpu/drm/rockchip/rockchip_panel.c
new file mode 100644
index 000..87401a2
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_panel.c
@@ -0,0 +1,297 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:mark yao 
+ *
+ * based on panel-simple.c
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+
+/* TODO: convert to gpiod_*() API once it's been merged */
+#define GPIO_ACTIVE_LOW(1 << 0)
+
+struct pwr_gpio {
+   struct list_head head;
+   unsigned long enable_gpio_flags;
+   int enable_gpio;
+};
+
+struct rockchip_panel {
+   struct drm_panel base;
+   bool enabled;
+
+   struct drm_display_mode mode;
+   struct rockchip_panel_special priv;
+
+   struct list_head pwrlist;
+};
+
+static inline struct rockchip_panel *to_rockchip_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct rockchip_panel, base);
+}
+
+static int rockchip_panel_disable(struct drm_panel *panel)
+{
+   struct rockchip_panel *p = to_rockchip_panel(panel);
+   struct pwr_gpio *pwr;
+   struct list_head *pos;
+
+   if (!p->enabled)
+   return 0;
+
+   list_for_each(pos, >pwrlist) {
+   pwr = list_entry(pos, struct pwr_gpio, head);
+   if (gpio_is_valid(pwr->enable_gpio)) {
+   if (pwr->enable_gpio_flags & GPIO_ACTIVE_LOW)
+   gpio_set_value(pwr->enable_gpio, 1);
+   else
+   gpio_set_value(pwr->enable_gpio, 0);
+   }
+   }
+
+   p->enabled = false;
+
+   return 0;
+}
+
+static int rockchip_panel_enable(struct drm_panel *panel)
+{
+   struct rockchip_panel *p = to_rockchip_panel(panel);
+   struct pwr_gpio *pwr;
+   struct list_head *pos;
+
+   if (p->enabled)
+   return 0;
+
+   list_for_each(pos, >pwrlist) {
+   pwr = list_entry(pos, struct pwr_gpio, head);
+   if (gpio_is_valid(pwr->enable_gpio)) {
+   if (pwr->enable_gpio_flags & GPIO_ACTIVE_LOW)
+   gpio_set_value(pwr->enable_gpio, 0);
+   else
+   gpio_set_value(pwr->enable_gpio, 1);
+   }
+   }
+
+   p->enabled = true;
+
+   return 0;
+}
+
+static int rockchip_panel_get_modes(struct drm_panel *panel)
+{
+   struct rockchip_panel *p = to_rockchip_panel(panel);
+   struct drm_device *drm = panel->drm;
+   struct drm_connector *connector = panel->connector;
+   const struct drm_display_mode *m = >mode;
+   struct drm_display_mode *mode;
+
+   mode = drm_mode_duplicate(drm, m);
+   if (!mode) {
+   dev_err(drm->dev, "failed to add mode %ux%u@%u\n",
+   m->hdisplay, m->vdisplay, m->vrefresh);
+   return 0;
+   }
+
+   drm_mode_set_name(mode);
+   drm_mode_probed_add(connector, mode);
+
+   return 1;
+}
+
+static const struct drm_panel_funcs rockchip_panel_funcs = {
+   .disable = rockchip_panel_disable,
+   .enable = rockchip_panel_enable,
+   .get_modes = rockchip_panel_get_modes,
+};
+
+static int rockchip_name_to_face(const char *s)
+{
+   if (!s)
+   return 0;
+
+   if (strncmp(s, "r8g8b8", 6) == 0)
+   return ROCKCHIP_OUTFACE_P888;
+   else if (strncmp(s, "r6g6b6", 6) == 0)
+   return ROCKCHIP_OUTFACE_P666;
+   else if (strncmp(s, 

[PATCH 2/9] Add devicetree bindings for panels used by the Rockchip DRM

[mark yao]

Signed-off-by: mark yao 
---
 .../devicetree/bindings/video/rockchip-panel.txt   |   52 
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-panel.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-panel.txt 
b/Documentation/devicetree/bindings/video/rockchip-panel.txt
new file mode 100644
index 000..9fc200a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-panel.txt
@@ -0,0 +1,52 @@
+Rockchip LCD Display interface
+
+Required properties:
+-compatible: "rockchip,rockchip-panel";
+
+- rockchip,output-face: lcdc display mode value should set as following
+   "r8g8b8": 24bit display port, R8 G8 B8
+   "r6g6b6": 18bit display port, R6 G6 B6
+   "r5g6b5": 16bit display port, R5 G6 B5
+
+Optional properties:
+- display-timings: timings for the connected panel as described by
+   Documentation/devicetree/bindings/video/display-timing.txt
+Optional properties:
+- rockchip,power-gpios: gpio to power on or off the LCD (as many as needed)
+- lcdc-vcc18: Defined if power supply of lcd controller is 1.8v,
+   Not defined if power supply of lcd controller is 3.3v.
+- output-dither: support dithering the output color.
+- color-swap-rb: swap R and B color per pixel.
+- color-swap-rg: swap R and G color per pixel.
+- color-swap-bg: swap B and G color per pixel.
+
+Example:
+   panel {
+   compatible = "rockchip,rockchip-panel";
+   rockchip,output-face = "r6g6b6";
+
+   enable-gpios = < 3 GPIO_ACTIVE_HIGH
+4 GPIO_ACTIVE_HIGH>;
+   output-dither;
+
+   display-timings {
+   native-mode = <_disp0>;
+
+   timing_disp0: 1280x800 {
+   clock-frequency = <7100>;
+   hactive = <1280>;
+   vactive = <800>;
+   hback-porch = <100>;
+   hfront-porch = <18>;
+   vback-porch = <8>;
+   vfront-porch = <6>;
+   hsync-len = <10>;
+   vsync-len = <2>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   de-active = <0>;
+   pixelclk-active = <0>;
+   };
+   };
+
+   };
-- 
1.7.9.5

[PATCH 1/9] drm: Add drm driver for Rockchip Socs

[mark yao]

This patch is a DRM Driver for Rockchip Socs, driver provides an abstraction
for the graphics hardware, such as lcd controller and connector interface.

Signed-off-by: mark yao 
---
 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   40 ++
 drivers/gpu/drm/rockchip/Makefile |   12 +
 drivers/gpu/drm/rockchip/rockchip_drm_connector.c |  412 
 drivers/gpu/drm/rockchip/rockchip_drm_connector.h |   36 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  600 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |  128 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|   48 ++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |   63 ++
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   24 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  163 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   40 ++
 drivers/gpu/drm/rockchip/rockchip_drm_lcdc.c  |  720 +
 drivers/gpu/drm/rockchip/rockchip_drm_lcdc.h  |  131 
 include/uapi/drm/rockchip_drm.h   |  110 
 17 files changed, 2558 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/Kconfig
 create mode 100644 drivers/gpu/drm/rockchip/Makefile
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_connector.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_connector.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_lcdc.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_lcdc.h
 create mode 100644 include/uapi/drm/rockchip_drm.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f512004..5951c2c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -170,6 +170,8 @@ config DRM_SAVAGE

 source "drivers/gpu/drm/exynos/Kconfig"

+source "drivers/gpu/drm/rockchip/Kconfig"
+
 source "drivers/gpu/drm/vmwgfx/Kconfig"

 source "drivers/gpu/drm/gma500/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index dd2ba42..40babd2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VIA)  +=via/
 obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
 obj-$(CONFIG_DRM_EXYNOS) +=exynos/
+obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
 obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
new file mode 100644
index 000..592e999
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -0,0 +1,40 @@
+config DRM_ROCKCHIP
+   tristate "DRM Support for Rockchip"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_PANEL
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
+   select VIDEOMODE_HELPERS
+   select OF
+   help
+ Choose this option if you have a Rockchip soc chipset.
+ This driver provides kernel mode setting and buffer
+ management to userspace. This driver does not provides
+ 2D or 3D acceleration; acceleration is performed by other
+ IP found on the SoC.
+
+config DRM_ROCKCHIP_LCDC
+   bool "ROCKCHIP DRM LCDC"
+   depends on DRM_ROCKCHIP
+   select FB_MODE_HELPERS
+   help
+ Choose this option if you want to use Rockchip lcdc for DRM.
+ The driver provides an abstraction for Rockchip lcd controller,
+ lcd controller is the display interface from memory frame buffer
+ to display device.
+
+config DRM_ROCKCHIP_CONNECTOR
+   bool "ROCKCHIP DRM CONNECTOR"
+   depends on OF && DRM_ROCKCHIP && DRM_ROCKCHIP_LCDC
+   select FB_MODE_HELPERS
+   select VIDEOMODE_HELPERS
+   help
+ Choose this option if you want to use Rockchip Primary DISPLAY.
+ The driver provides an abstraction for Rockchip display devices,
+ such as lcd plane, lvds, edp , mipi, etc.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
new file mode 100644
index 000..45c9d50
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -0,0 

[PATCH 0/9] Add drm driver for Rockchip Socs

[mark yao]

From: mark yao 

This a series of patches is a DRM Driver for Rockchip Socs, driver provides
an abstraction for the graphics hardware, as lcd controller and
connector interface.

add rk3288 lcd controller.
add rk3288 lvds and rk3288 edp connector.

Tested on rk3288 sdk board, use lvds or edp connector, boot and display OK

mark yao (9):
  drm: Add drm driver for Rockchip Socs
  Add devicetree bindings for panels used by the Rockchip DRM
  drm: add driver for panels used by the Rockchip DRM
  Add devicetree bindings for Rockchip lcd controller
  drm: add Rockchip rk3288 lcd controller driver
  Add devicetree bindings for Rockchip Soc LVDS
  drm: add Rockchip Soc rk3288 lvds connector
  Add devicetree bindings for Rockchip Soc EDP
  drm: add Rockchip Soc rk3288 edp connector


-- 
1.7.9.5

[pull] drm/msm: msm-next for 3.17

[Rob Clark]

Dave,

This time around we have a mix of new hw enablement (mdp5 v1.3 /
apq8084), plus devicetree and various upstream changes (mostly
adapting to CCF vs downstream clk driver differences) for mdp4 /
apq8064.  With these drm/msm patches plus a few other small patchsets
(from linaro qcom integration branch.. mostly stuff queued up for
3.17) we have the inforce ifc6410 board working, with gpu.  Much nicer
to work with than ancient vendor android branch :-)

The following changes since commit c759606c96dc052373d4c36ea383595da46b04e9:

  Merge tag 'drm-intel-next-2014-07-25-merged' of
git://anongit.freedesktop.org/drm-intel into drm-next (2014-08-04
17:57:34 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~robclark/linux msm-next

for you to fetch changes up to a2fe6cdc03d7a9b0d048a7f32f9d8827e06c67fa:

  drm/msm/hdmi: fix HDMI_MUX_EN gpio request typo (2014-08-04 11:55:30 -0400)


Beeresh Gopal (2):
  drm/msm/hdmi: enable lpm-mux if it is present
  drm/msm/hdmi: fix HDMI_MUX_EN gpio request typo

Hai Li (1):
  drm/msm: Implement msm drm fb_mmap callback function

Rob Clark (9):
  drm/msm: fix double struct_mutex acquire
  drm/msm: DT support for 8960/8064 (v3)
  drm/msm: update generated headers
  drm/msm: hdmi phy 8960 phy pll
  drm/msm/mdp4: add mdp axi clk
  drm/msm: fix BUG_ON() in error cleanup path
  drm/msm: no mmu is only error if not using vram carveout
  drm/msm: use upstream iommu
  drm/msm: fix potential deadlock in gpu init

Stephane Viau (2):
  drm/msm: activate iommu support
  drm/msm/mdp5: add support for MDP5 v1.3

 Documentation/devicetree/bindings/drm/msm/gpu.txt  |  52 +++
 Documentation/devicetree/bindings/drm/msm/hdmi.txt |  46 +++
 Documentation/devicetree/bindings/drm/msm/mdp.txt  |  48 +++
 drivers/gpu/drm/msm/Kconfig|   1 -
 drivers/gpu/drm/msm/adreno/a2xx.xml.h  |  58 ++-
 drivers/gpu/drm/msm/adreno/a3xx.xml.h  | 296 +++---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c  |   7 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h  |   5 +
 drivers/gpu/drm/msm/adreno/adreno_common.xml.h |  56 ++-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|  14 +-
 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h| 239 +++-
 drivers/gpu/drm/msm/dsi/dsi.xml.h  |   4 +-
 drivers/gpu/drm/msm/dsi/mmss_cc.xml.h  |   4 +-
 drivers/gpu/drm/msm/dsi/sfpb.xml.h |   4 +-
 drivers/gpu/drm/msm/hdmi/hdmi.c|  69 ++--
 drivers/gpu/drm/msm/hdmi/hdmi.h|   1 +
 drivers/gpu/drm/msm/hdmi/hdmi.xml.h| 109 +-
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c  |  23 +-
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c   | 377 +-
 drivers/gpu/drm/msm/hdmi/qfprom.xml.h  |   4 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h|   4 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c|  25 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h|   1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h| 431 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 159 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h|  25 ++
 drivers/gpu/drm/msm/mdp/mdp_common.xml.h   |   4 +-
 drivers/gpu/drm/msm/msm_drv.c  |  52 ++-
 drivers/gpu/drm/msm/msm_fbdev.c|  45 ++-
 drivers/gpu/drm/msm/msm_gem.c  |  15 +-
 drivers/gpu/drm/msm/msm_gpu.c  |  12 +-
 drivers/gpu/drm/msm/msm_iommu.c|  31 +-
 drivers/gpu/drm/msm/msm_mmu.h  |   8 +-
 33 files changed, 1837 insertions(+), 392 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/msm/gpu.txt
 create mode 100644 Documentation/devicetree/bindings/drm/msm/hdmi.txt
 create mode 100644 Documentation/devicetree/bindings/drm/msm/mdp.txt

[PATCH] radeon: allow write_reloc with unaccounted buffers to cope with Mesa R200 bug

[Alex Deucher]

On Fri, Aug 1, 2014 at 9:43 AM, Marek Ol??k  wrote:
> From: Marek Ol??k 
>
> ---
>
> I'm not really interested in studying the R200 driver to fix it.
> This has to suffice.

Reviewed-by: Alex Deucher 

>
>  radeon/radeon_cs_gem.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
> index b87c6b1..bcfa05b 100644
> --- a/radeon/radeon_cs_gem.c
> +++ b/radeon/radeon_cs_gem.c
> @@ -178,6 +178,15 @@ static int cs_gem_write_reloc(struct radeon_cs_int *cs,
>  uint32_t idx;
>  unsigned i;
>
> +if (!boi->space_accounted) {
> +struct radeon_cs *rcs = (struct radeon_cs*)cs;
> +int r;
> +
> +radeon_cs_space_add_persistent_bo(rcs, bo, read_domain, 
> write_domain);
> +r = radeon_cs_space_check(rcs);
> +if (r)
> +return r;
> +}
>  assert(boi->space_accounted);
>
>  /* check domains */
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 17/19] drm/radeon: use rcu waits in some ioctls

[Maarten Lankhorst]

op 04-08-14 11:25, Michel D?nzer schreef:
> On 04.08.2014 17:56, Maarten Lankhorst wrote:
>> op 04-08-14 10:42, Michel D?nzer schreef:
>>> On 02.08.2014 02:07, Maarten Lankhorst wrote:
 On 01-08-14 16:13, Michel D?nzer wrote:
> On 01.08.2014 19:12, Maarten Lankhorst wrote:
>> On 01-08-14 10:27, Michel D?nzer wrote:
>>> On 01.08.2014 00:34, Maarten Lankhorst wrote:
 @@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device 
 *dev, void *data,
struct drm_radeon_gem_wait_idle *args = data;
struct drm_gem_object *gobj;
struct radeon_bo *robj;
 -  int r;
 +  int r = 0;
 +  long ret;
  
gobj = drm_gem_object_lookup(dev, filp, args->handle);
if (gobj == NULL) {
return -ENOENT;
}
robj = gem_to_radeon_bo(gobj);
 -  r = radeon_bo_wait(robj, NULL, false);
 +  ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, 
 true, 30 * HZ);
 +  if (ret == 0)
 +  r = -EBUSY;
 +  else if (ret < 0)
 +  r = ret;
 +
/* callback hw specific functions if any */
if (rdev->asic->ioctl_wait_idle)
robj->rdev->asic->ioctl_wait_idle(rdev, robj);
>>> Heads up, this conflicts with
>>> http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html
>>> which passes a non-NULL second argument to radeon_bo_wait() to get the
>>> BO's current domain.
>> Ok, I will fix it up and resend it later.
>>
>> Does it matter if I grab the current domain without grabbing the lock
>> here? Because it doesn't matter if it sees the old or new domain, it
>> could have been changed after returning too.
> It should be the domain where the BO is located when the fence we are
> waiting for here signals.
 Could we compare domain before and after the rcu wait, and retry
 waiting if they're different, and the new one is VRAM? (eg eviction
 happened) That should prevent needing to lock the bo.
>>> Eviction normally only happens from VRAM, not to VRAM. :) So if you know
>>> whether the domain is VRAM or not after the wait, you can just proceed
>>> accordingly, I don't see why you'd need to wait again.
>> Because in the worst case you didn't wait on the fence that started
>> the eviction, but one before it. ;-)
> I'm afraid you've lost me. Can you determine the domain that
> radeon_bo_wait() would have returned?
>
>
Ok so..

wait ioctl:

waits on fence 1

(eviction to vram happens asynchronously, fence 1 on the bo gets replaced by 
fence 2)

wait 1 completes, new domain is VRAM

vram flush happens, but fence 2 is not signaled yet so not everything is copied.

wait ioctl returns

Or is it unimportant here, and the vram flush doesn't depend on the fence being 
completed?

The second wait would be forced by ttm_bo_vm_fault anyway.

~Maarten

[LIBDRM PATCH 3/3] exynos: Use symbol visibility.

[Maarten Lankhorst]

No changes to exported symbols.

Signed-off-by: Maarten Lankhorst 
---
 exynos/Makefile.am |  1 +
 exynos/exynos_drm.c| 37 -
 exynos/exynos_fimg2d.c | 19 ---
 3 files changed, 33 insertions(+), 24 deletions(-)

diff --git a/exynos/Makefile.am b/exynos/Makefile.am
index 0a2663a..06bee00 100644
--- a/exynos/Makefile.am
+++ b/exynos/Makefile.am
@@ -1,5 +1,6 @@
 AM_CFLAGS = \
$(WARN_CFLAGS) \
+   $(VISIBILITY_CFLAGS) \
-I$(top_srcdir) \
-I$(top_srcdir)/exynos \
$(PTHREADSTUBS_CFLAGS) \
diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
index 5fff259..4c7dd13 100644
--- a/exynos/exynos_drm.c
+++ b/exynos/exynos_drm.c
@@ -38,6 +38,7 @@

 #include 

+#include "libdrm.h"
 #include "exynos_drm.h"
 #include "exynos_drmif.h"

@@ -48,7 +49,7 @@
  *
  * if true, return the device object else NULL.
  */
-struct exynos_device * exynos_device_create(int fd)
+drm_public struct exynos_device * exynos_device_create(int fd)
 {
struct exynos_device *dev;

@@ -69,7 +70,7 @@ struct exynos_device * exynos_device_create(int fd)
  *
  * @dev: exynos drm device object.
  */
-void exynos_device_destroy(struct exynos_device *dev)
+drm_public void exynos_device_destroy(struct exynos_device *dev)
 {
free(dev);
 }
@@ -87,8 +88,8 @@ void exynos_device_destroy(struct exynos_device *dev)
  *
  * if true, return a exynos buffer object else NULL.
  */
-struct exynos_bo * exynos_bo_create(struct exynos_device *dev,
-   size_t size, uint32_t flags)
+drm_public struct exynos_bo * exynos_bo_create(struct exynos_device *dev,
+  size_t size, uint32_t flags)
 {
struct exynos_bo *bo;
struct drm_exynos_gem_create req = {
@@ -141,8 +142,8 @@ fail:
  *
  * if true, return 0 else negative.
  */
-int exynos_bo_get_info(struct exynos_device *dev, uint32_t handle,
-   size_t *size, uint32_t *flags)
+drm_public int exynos_bo_get_info(struct exynos_device *dev, uint32_t handle,
+ size_t *size, uint32_t *flags)
 {
int ret;
struct drm_exynos_gem_info req = {
@@ -167,7 +168,7 @@ int exynos_bo_get_info(struct exynos_device *dev, uint32_t 
handle,
  *
  * @bo: a exynos buffer object to be destroyed.
  */
-void exynos_bo_destroy(struct exynos_bo *bo)
+drm_public void exynos_bo_destroy(struct exynos_bo *bo)
 {
if (!bo)
return;
@@ -199,7 +200,8 @@ void exynos_bo_destroy(struct exynos_bo *bo)
  * if true, return a exynos buffer object else NULL.
  *
  */
-struct exynos_bo * exynos_bo_from_name(struct exynos_device *dev, uint32_t 
name)
+drm_public struct exynos_bo *
+exynos_bo_from_name(struct exynos_device *dev, uint32_t name)
 {
struct exynos_bo *bo;
struct drm_gem_open req = {
@@ -241,7 +243,7 @@ err_free_bo:
  *
  * if true, return 0 else negative.
  */
-int exynos_bo_get_name(struct exynos_bo *bo, uint32_t *name)
+drm_public int exynos_bo_get_name(struct exynos_bo *bo, uint32_t *name)
 {
if (!bo->name) {
struct drm_gem_flink req = {
@@ -264,7 +266,7 @@ int exynos_bo_get_name(struct exynos_bo *bo, uint32_t *name)
return 0;
 }

-uint32_t exynos_bo_handle(struct exynos_bo *bo)
+drm_public uint32_t exynos_bo_handle(struct exynos_bo *bo)
 {
return bo->handle;
 }
@@ -277,7 +279,7 @@ uint32_t exynos_bo_handle(struct exynos_bo *bo)
  *
  * if true, user pointer mmaped else NULL.
  */
-void *exynos_bo_map(struct exynos_bo *bo)
+drm_public void *exynos_bo_map(struct exynos_bo *bo)
 {
if (!bo->vaddr) {
struct exynos_device *dev = bo->dev;
@@ -309,8 +311,8 @@ void *exynos_bo_map(struct exynos_bo *bo)
  *
  * @return: 0 on success, -1 on error, and errno will be set
  */
-int exynos_prime_handle_to_fd(struct exynos_device *dev, uint32_t handle,
-   int *fd)
+drm_public int
+exynos_prime_handle_to_fd(struct exynos_device *dev, uint32_t handle, int *fd)
 {
return drmPrimeHandleToFD(dev->fd, handle, 0, fd);
 }
@@ -324,8 +326,8 @@ int exynos_prime_handle_to_fd(struct exynos_device *dev, 
uint32_t handle,
  *
  * @return: 0 on success, -1 on error, and errno will be set
  */
-int exynos_prime_fd_to_handle(struct exynos_device *dev, int fd,
-   uint32_t *handle)
+drm_public int
+exynos_prime_fd_to_handle(struct exynos_device *dev, int fd, uint32_t *handle)
 {
return drmPrimeFDToHandle(dev->fd, fd, handle);
 }
@@ -347,8 +349,9 @@ int exynos_prime_fd_to_handle(struct exynos_device *dev, 
int fd,
  *
  * if true, return 0 else negative.
  */
-int exynos_vidi_connection(struct exynos_device *dev, uint32_t connect,
-   uint32_t ext, void *edid)
+drm_public int
+exynos_vidi_connection(struct exynos_device *dev, uint32_t connect,
+  uint32_t ext, void *edid)
 {

[LIBDRM PATCH 2/3] freedreno: Use symbol visibility.

[Maarten Lankhorst]

Hiding fd_device_del_locked, and fd_cleanup_bo_cache.

Signed-off-by: Maarten Lankhorst 
---
 freedreno/Makefile.am|  1 +
 freedreno/freedreno_bo.c | 26 +-
 freedreno/freedreno_device.c |  8 
 freedreno/freedreno_pipe.c   | 11 ++-
 freedreno/freedreno_priv.h   |  5 +
 freedreno/freedreno_ringbuffer.c | 38 --
 freedreno/kgsl/kgsl_bo.c |  4 ++--
 7 files changed, 51 insertions(+), 42 deletions(-)

diff --git a/freedreno/Makefile.am b/freedreno/Makefile.am
index 7903e5b..49471e9 100644
--- a/freedreno/Makefile.am
+++ b/freedreno/Makefile.am
@@ -2,6 +2,7 @@ AUTOMAKE_OPTIONS=subdir-objects

 AM_CFLAGS = \
$(WARN_CFLAGS) \
+   $(VISIBILITY_CFLAGS) \
-I$(top_srcdir) \
-I$(top_srcdir)/freedreno \
$(PTHREADSTUBS_CFLAGS) \
diff --git a/freedreno/freedreno_bo.c b/freedreno/freedreno_bo.c
index 8cea4de..3a2e464 100644
--- a/freedreno/freedreno_bo.c
+++ b/freedreno/freedreno_bo.c
@@ -163,8 +163,8 @@ static struct fd_bo *find_in_bucket(struct fd_device *dev,
 }


-struct fd_bo * fd_bo_new(struct fd_device *dev,
-   uint32_t size, uint32_t flags)
+drm_public struct fd_bo *
+fd_bo_new(struct fd_device *dev, uint32_t size, uint32_t flags)
 {
struct fd_bo *bo = NULL;
struct fd_bo_bucket *bucket;
@@ -197,8 +197,8 @@ struct fd_bo * fd_bo_new(struct fd_device *dev,
return bo;
 }

-struct fd_bo *fd_bo_from_handle(struct fd_device *dev,
-   uint32_t handle, uint32_t size)
+drm_public struct fd_bo *
+fd_bo_from_handle(struct fd_device *dev, uint32_t handle, uint32_t size)
 {
struct fd_bo *bo = NULL;

@@ -209,7 +209,7 @@ struct fd_bo *fd_bo_from_handle(struct fd_device *dev,
return bo;
 }

-struct fd_bo * fd_bo_from_name(struct fd_device *dev, uint32_t name)
+drm_public struct fd_bo * fd_bo_from_name(struct fd_device *dev, uint32_t name)
 {
struct drm_gem_open req = {
.name = name,
@@ -242,13 +242,13 @@ out_unlock:
return bo;
 }

-struct fd_bo * fd_bo_ref(struct fd_bo *bo)
+drm_public struct fd_bo * fd_bo_ref(struct fd_bo *bo)
 {
atomic_inc(>refcnt);
return bo;
 }

-void fd_bo_del(struct fd_bo *bo)
+drm_public void fd_bo_del(struct fd_bo *bo)
 {
struct fd_device *dev = bo->dev;

@@ -307,7 +307,7 @@ static void bo_del(struct fd_bo *bo)
bo->funcs->destroy(bo);
 }

-int fd_bo_get_name(struct fd_bo *bo, uint32_t *name)
+drm_public int fd_bo_get_name(struct fd_bo *bo, uint32_t *name)
 {
if (!bo->name) {
struct drm_gem_flink req = {
@@ -330,17 +330,17 @@ int fd_bo_get_name(struct fd_bo *bo, uint32_t *name)
return 0;
 }

-uint32_t fd_bo_handle(struct fd_bo *bo)
+drm_public uint32_t fd_bo_handle(struct fd_bo *bo)
 {
return bo->handle;
 }

-uint32_t fd_bo_size(struct fd_bo *bo)
+drm_public uint32_t fd_bo_size(struct fd_bo *bo)
 {
return bo->size;
 }

-void * fd_bo_map(struct fd_bo *bo)
+drm_public void * fd_bo_map(struct fd_bo *bo)
 {
if (!bo->map) {
uint64_t offset;
@@ -362,12 +362,12 @@ void * fd_bo_map(struct fd_bo *bo)
 }

 /* a bit odd to take the pipe as an arg, but it's a, umm, quirk of kgsl.. */
-int fd_bo_cpu_prep(struct fd_bo *bo, struct fd_pipe *pipe, uint32_t op)
+drm_public int fd_bo_cpu_prep(struct fd_bo *bo, struct fd_pipe *pipe, uint32_t 
op)
 {
return bo->funcs->cpu_prep(bo, pipe, op);
 }

-void fd_bo_cpu_fini(struct fd_bo *bo)
+drm_public void fd_bo_cpu_fini(struct fd_bo *bo)
 {
bo->funcs->cpu_fini(bo);
 }
diff --git a/freedreno/freedreno_device.c b/freedreno/freedreno_device.c
index c34963c..2d3aa33 100644
--- a/freedreno/freedreno_device.c
+++ b/freedreno/freedreno_device.c
@@ -76,7 +76,7 @@ init_cache_buckets(struct fd_device *dev)
}
 }

-struct fd_device * fd_device_new(int fd)
+drm_public struct fd_device * fd_device_new(int fd)
 {
struct fd_device *dev;
drmVersionPtr version;
@@ -115,7 +115,7 @@ struct fd_device * fd_device_new(int fd)
 /* like fd_device_new() but creates it's own private dup() of the fd
  * which is close()d when the device is finalized.
  */
-struct fd_device * fd_device_new_dup(int fd)
+drm_public struct fd_device * fd_device_new_dup(int fd)
 {
struct fd_device *dev = fd_device_new(dup(fd));
if (dev)
@@ -123,7 +123,7 @@ struct fd_device * fd_device_new_dup(int fd)
return dev;
 }

-struct fd_device * fd_device_ref(struct fd_device *dev)
+drm_public struct fd_device * fd_device_ref(struct fd_device *dev)
 {
atomic_inc(>refcnt);
return dev;
@@ -146,7 +146,7 @@ void fd_device_del_locked(struct fd_device *dev)
fd_device_del_impl(dev);
 }

-void fd_device_del(struct fd_device *dev)
+drm_public void fd_device_del(struct fd_device *dev)
 {
if (!atomic_dec_and_test(>refcnt))
return;
diff --git a/freedreno/freedreno_pipe.c 

[LIBDRM PATCH 1/3] omap: Use symbol visibility.

[Maarten Lankhorst]

No changes to exported symbols.

Signed-off-by: Maarten Lankhorst 
---
 omap/Makefile.am |  1 +
 omap/omap_drm.c  | 46 ++
 2 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/omap/Makefile.am b/omap/Makefile.am
index c77520b..0778bdd 100644
--- a/omap/Makefile.am
+++ b/omap/Makefile.am
@@ -1,5 +1,6 @@
 AM_CFLAGS = \
$(WARN_CFLAGS) \
+   $(VISIBILITY_CFLAGS) \
-I$(top_srcdir) \
-I$(top_srcdir)/omap \
$(PTHREADSTUBS_CFLAGS) \
diff --git a/omap/omap_drm.c b/omap/omap_drm.c
index 89f1491..8b4ec46 100644
--- a/omap/omap_drm.c
+++ b/omap/omap_drm.c
@@ -39,6 +39,7 @@
 #include 
 #include 

+#include 
 #include 
 #include 

@@ -91,7 +92,7 @@ static struct omap_device * omap_device_new_impl(int fd)
return dev;
 }

-struct omap_device * omap_device_new(int fd)
+drm_public struct omap_device * omap_device_new(int fd)
 {
struct omap_device *dev = NULL;

@@ -114,13 +115,13 @@ struct omap_device * omap_device_new(int fd)
return dev;
 }

-struct omap_device * omap_device_ref(struct omap_device *dev)
+drm_public struct omap_device * omap_device_ref(struct omap_device *dev)
 {
atomic_inc(>refcnt);
return dev;
 }

-void omap_device_del(struct omap_device *dev)
+drm_public void omap_device_del(struct omap_device *dev)
 {
if (!atomic_dec_and_test(>refcnt))
return;
@@ -131,7 +132,8 @@ void omap_device_del(struct omap_device *dev)
free(dev);
 }

-int omap_get_param(struct omap_device *dev, uint64_t param, uint64_t *value)
+drm_public int
+omap_get_param(struct omap_device *dev, uint64_t param, uint64_t *value)
 {
struct drm_omap_param req = {
.param = param,
@@ -148,7 +150,8 @@ int omap_get_param(struct omap_device *dev, uint64_t param, 
uint64_t *value)
return 0;
 }

-int omap_set_param(struct omap_device *dev, uint64_t param, uint64_t value)
+drm_public int
+omap_set_param(struct omap_device *dev, uint64_t param, uint64_t value)
 {
struct drm_omap_param req = {
.param = param,
@@ -226,8 +229,8 @@ fail:


 /* allocate a new (un-tiled) buffer object */
-struct omap_bo * omap_bo_new(struct omap_device *dev,
-   uint32_t size, uint32_t flags)
+drm_public struct omap_bo *
+omap_bo_new(struct omap_device *dev, uint32_t size, uint32_t flags)
 {
union omap_gem_size gsize = {
.bytes = size,
@@ -239,8 +242,9 @@ struct omap_bo * omap_bo_new(struct omap_device *dev,
 }

 /* allocate a new buffer object */
-struct omap_bo * omap_bo_new_tiled(struct omap_device *dev,
-   uint32_t width, uint32_t height, uint32_t flags)
+drm_public struct omap_bo *
+omap_bo_new_tiled(struct omap_device *dev, uint32_t width,
+ uint32_t height, uint32_t flags)
 {
union omap_gem_size gsize = {
.tiled = {
@@ -254,7 +258,7 @@ struct omap_bo * omap_bo_new_tiled(struct omap_device *dev,
return omap_bo_new_impl(dev, gsize, flags);
 }

-struct omap_bo * omap_bo_ref(struct omap_bo *bo)
+drm_public struct omap_bo *omap_bo_ref(struct omap_bo *bo)
 {
atomic_inc(>refcnt);
return bo;
@@ -280,7 +284,8 @@ static int get_buffer_info(struct omap_bo *bo)
 }

 /* import a buffer object from DRI2 name */
-struct omap_bo * omap_bo_from_name(struct omap_device *dev, uint32_t name)
+drm_public struct omap_bo *
+omap_bo_from_name(struct omap_device *dev, uint32_t name)
 {
struct omap_bo *bo = NULL;
struct drm_gem_open req = {
@@ -313,7 +318,8 @@ fail:
  * fd so caller should close() the fd when it is otherwise done
  * with it (even if it is still using the 'struct omap_bo *')
  */
-struct omap_bo * omap_bo_from_dmabuf(struct omap_device *dev, int fd)
+drm_public struct omap_bo *
+omap_bo_from_dmabuf(struct omap_device *dev, int fd)
 {
struct omap_bo *bo = NULL;
struct drm_prime_handle req = {
@@ -344,7 +350,7 @@ fail:
 }

 /* destroy a buffer object */
-void omap_bo_del(struct omap_bo *bo)
+drm_public void omap_bo_del(struct omap_bo *bo)
 {
if (!bo) {
return;
@@ -377,7 +383,7 @@ void omap_bo_del(struct omap_bo *bo)
 }

 /* get the global flink/DRI2 buffer name */
-int omap_bo_get_name(struct omap_bo *bo, uint32_t *name)
+drm_public int omap_bo_get_name(struct omap_bo *bo, uint32_t *name)
 {
if (!bo->name) {
struct drm_gem_flink req = {
@@ -398,7 +404,7 @@ int omap_bo_get_name(struct omap_bo *bo, uint32_t *name)
return 0;
 }

-uint32_t omap_bo_handle(struct omap_bo *bo)
+drm_public uint32_t omap_bo_handle(struct omap_bo *bo)
 {
return bo->handle;
 }
@@ -406,7 +412,7 @@ uint32_t omap_bo_handle(struct omap_bo *bo)
 /* caller owns the dmabuf fd that is returned and is responsible
  * to close() it when done
  */
-int omap_bo_dmabuf(struct omap_bo *bo)
+drm_public int omap_bo_dmabuf(struct omap_bo *bo)
 {
if (!bo->fd) {
  

[PATCH 17/19] drm/radeon: use rcu waits in some ioctls

[Maarten Lankhorst]

op 04-08-14 10:42, Michel D?nzer schreef:
> On 02.08.2014 02:07, Maarten Lankhorst wrote:
>> On 01-08-14 16:13, Michel D?nzer wrote:
>>> On 01.08.2014 19:12, Maarten Lankhorst wrote:
 On 01-08-14 10:27, Michel D?nzer wrote:
> On 01.08.2014 00:34, Maarten Lankhorst wrote:
>> @@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device 
>> *dev, void *data,
>>  struct drm_radeon_gem_wait_idle *args = data;
>>  struct drm_gem_object *gobj;
>>  struct radeon_bo *robj;
>> -int r;
>> +int r = 0;
>> +long ret;
>>  
>>  gobj = drm_gem_object_lookup(dev, filp, args->handle);
>>  if (gobj == NULL) {
>>  return -ENOENT;
>>  }
>>  robj = gem_to_radeon_bo(gobj);
>> -r = radeon_bo_wait(robj, NULL, false);
>> +ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, 
>> true, 30 * HZ);
>> +if (ret == 0)
>> +r = -EBUSY;
>> +else if (ret < 0)
>> +r = ret;
>> +
>>  /* callback hw specific functions if any */
>>  if (rdev->asic->ioctl_wait_idle)
>>  robj->rdev->asic->ioctl_wait_idle(rdev, robj);
> Heads up, this conflicts with
> http://lists.freedesktop.org/archives/dri-devel/2014-August/065255.html
> which passes a non-NULL second argument to radeon_bo_wait() to get the
> BO's current domain.
 Ok, I will fix it up and resend it later.

 Does it matter if I grab the current domain without grabbing the lock
 here? Because it doesn't matter if it sees the old or new domain, it
 could have been changed after returning too.
>>> It should be the domain where the BO is located when the fence we are
>>> waiting for here signals.
>> Could we compare domain before and after the rcu wait, and retry
>> waiting if they're different, and the new one is VRAM? (eg eviction
>> happened) That should prevent needing to lock the bo.
> Eviction normally only happens from VRAM, not to VRAM. :) So if you know
> whether the domain is VRAM or not after the wait, you can just proceed
> accordingly, I don't see why you'd need to wait again.
Because in the worst case you didn't wait on the fence that started the 
eviction, but one before it. ;-)

~Maarten

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Maarten Lankhorst]

op 04-08-14 10:36, Christian K?nig schreef:
> Hi Maarten,
>
> Sorry for the delay. I've got way to much todo recently.
>
> Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
>>
>> On 01-08-14 18:35, Christian K?nig wrote:
>>> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
 Signed-off-by: Maarten Lankhorst 
 ---
 V1 had a nasty bug breaking gpu lockup recovery. The fix is not
 allowing radeon_fence_driver_check_lockup to take exclusive_lock,
 and kill it during lockup recovery instead.
>>> That looks like the delayed work starts running as soon as we submit a 
>>> fence, and not when it's needed for waiting.
>>>
>>> Since it's a backup for failing IRQs I would rather put it into 
>>> radeon_irq_kms.c and start/stop it when the IRQs are started/stoped.
>> The delayed work is not just for failing irq's, it's also the handler that's 
>> used to detect lockups, which is why I trigger after processing fences, and 
>> reset the timer after processing.
>
> The idea was turning the delayed work on and off when we turn the irq on and 
> off as well, processing of the delayed work handler can still happen in 
> radeon_fence.c
>
>>
>> Specifically what happened was this scenario:
>>
>> - lock up occurs
>> - write lock taken by gpu_reset
>> - delayed work runs, tries to acquire read lock, blocks
>> - gpu_reset tries to cancel delayed work synchronously
>> - has to wait for delayed work to finish -> deadlock
>
> Why do you want to disable the work item from the lockup handler in the first 
> place?
>
> Just take the exclusive lock in the work item, when it concurrently runs with 
> the lockup handler it will just block for the lockup handler to complete.
With the delayed work radeon_fence_wait no longer handles unreliable interrupts 
itself, so it has to run from the lockup handler.
But an alternative solution could be adding a radeon_fence_wait_timeout, ignore 
the timeout and check if fence is signaled on timeout.
This would probably be a cleaner solution.

~Maarten

[PATCH 09/19] drm/radeon: handle lockup in delayed work, v2

[Christian König]

Hi Maarten,

Sorry for the delay. I've got way to much todo recently.

Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
>
> On 01-08-14 18:35, Christian K?nig wrote:
>> Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
>>> Signed-off-by: Maarten Lankhorst 
>>> ---
>>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not
>>> allowing radeon_fence_driver_check_lockup to take exclusive_lock,
>>> and kill it during lockup recovery instead.
>> That looks like the delayed work starts running as soon as we submit a 
>> fence, and not when it's needed for waiting.
>>
>> Since it's a backup for failing IRQs I would rather put it into 
>> radeon_irq_kms.c and start/stop it when the IRQs are started/stoped.
> The delayed work is not just for failing irq's, it's also the handler that's 
> used to detect lockups, which is why I trigger after processing fences, and 
> reset the timer after processing.

The idea was turning the delayed work on and off when we turn the irq on 
and off as well, processing of the delayed work handler can still happen 
in radeon_fence.c

>
> Specifically what happened was this scenario:
>
> - lock up occurs
> - write lock taken by gpu_reset
> - delayed work runs, tries to acquire read lock, blocks
> - gpu_reset tries to cancel delayed work synchronously
> - has to wait for delayed work to finish -> deadlock

Why do you want to disable the work item from the lockup handler in the 
first place?

Just take the exclusive lock in the work item, when it concurrently runs 
with the lockup handler it will just block for the lockup handler to 
complete.

Regards,
Christian.

> ~Maarten

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #7 from Kai  ---
(In reply to comment #6)
> (In reply to comment #4)
> > Yes, Twitch, like YouTube, requires Flash.
> 
> Actually, YouTube doesn't require Flash, at least not for many videos.

If I go by top, then the CPU usage of the plugin container spikes for all
videos on YouTube (usually to about 30-50% on one core with Flash HW
acceleration enabled). But as <https://www.youtube.com/html5> tells me I'm
using the default player, that doesn't seem too surprising.

> > > Does doing anything in particular trigger it in MediathekView?
> > 
> > Sort of: just starting is enough. You get the grey window background at
> > below average speed and then it takes seconds until the UI elements are
> > drawn (list of shows, filter boxes, buttons). Afterwards you can trigger a
> > new CPU spike by trying to click anything or even better on each
> > keypress/character input into the title filter field on the left.
> 
> I can reproduce this with glamor from xserver 1.16.0, but not from current
> xserver Git master. So at least that part is already fixed.

Oh, nice. Do you know which commit resolves this? If not, do you need a bisect?
If yes, will that commit be backported to the 1.16 branch?

-- 
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/20140804/17a977c3/attachment.html>

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #6 from Michel D?nzer  ---
(In reply to comment #4)
> Yes, Twitch, like YouTube, requires Flash.

Actually, YouTube doesn't require Flash, at least not for many videos.


> > Does doing anything in particular trigger it in MediathekView?
> 
> Sort of: just starting is enough. You get the grey window background at
> below average speed and then it takes seconds until the UI elements are
> drawn (list of shows, filter boxes, buttons). Afterwards you can trigger a
> new CPU spike by trying to click anything or even better on each
> keypress/character input into the title filter field on the left.

I can reproduce this with glamor from xserver 1.16.0, but not from current
xserver Git master. So at least that part is already fixed.

-- 
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/20140804/fb78cb78/attachment.html>

[PATCH 2/3] intel: Use symbol visibility.

[Daniel Vetter]

On Thu, Jul 31, 2014 at 03:45:05PM +0200, Maarten Lankhorst wrote:
> No exports changed for this driver.
> 
> Signed-off-by: Maarten Lankhorst 

On a quick look this seems to have all we need really.

Acked-by: Daniel Vetter 

> ---
>  intel/Makefile.am |  1 +
>  intel/intel_bufmgr.c  | 93 
> ---
>  intel/intel_bufmgr_fake.c | 31 
>  intel/intel_bufmgr_gem.c  | 53 +++
>  intel/intel_decode.c  | 19 ++
>  5 files changed, 114 insertions(+), 83 deletions(-)
> 
> diff --git a/intel/Makefile.am b/intel/Makefile.am
> index f49b099..f734b0b 100644
> --- a/intel/Makefile.am
> +++ b/intel/Makefile.am
> @@ -24,6 +24,7 @@
>  
>  AM_CFLAGS = \
>   $(WARN_CFLAGS) \
> + $(VISIBILITY_CFLAGS) \
>   -I$(top_srcdir) \
>   -I$(top_srcdir)/intel \
>   $(PTHREADSTUBS_CFLAGS) \
> diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
> index 905556f..03dba50 100644
> --- a/intel/intel_bufmgr.c
> +++ b/intel/intel_bufmgr.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include "libdrm.h"
>  #include "intel_bufmgr.h"
>  #include "intel_bufmgr_priv.h"
>  #include "xf86drm.h"
> @@ -46,21 +47,21 @@
>   * Convenience functions for buffer management methods.
>   */
>  
> -drm_intel_bo *drm_intel_bo_alloc(drm_intel_bufmgr *bufmgr, const char *name,
> -  unsigned long size, unsigned int alignment)
> +drm_public drm_intel_bo *
> +drm_intel_bo_alloc(drm_intel_bufmgr *bufmgr, const char *name,
> +unsigned long size, unsigned int alignment)
>  {
>   return bufmgr->bo_alloc(bufmgr, name, size, alignment);
>  }
>  
> -drm_intel_bo *drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
> - const char *name,
> - unsigned long size,
> - unsigned int alignment)
> +drm_public drm_intel_bo *
> +drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr, const char *name,
> +   unsigned long size, unsigned int alignment)
>  {
>   return bufmgr->bo_alloc_for_render(bufmgr, name, size, alignment);
>  }
>  
> -drm_intel_bo *
> +drm_public drm_intel_bo *
>  drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
>  int x, int y, int cpp, uint32_t *tiling_mode,
>  unsigned long *pitch, unsigned long flags)
> @@ -69,12 +70,14 @@ drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const 
> char *name,
> tiling_mode, pitch, flags);
>  }
>  
> -void drm_intel_bo_reference(drm_intel_bo *bo)
> +drm_public void
> +drm_intel_bo_reference(drm_intel_bo *bo)
>  {
>   bo->bufmgr->bo_reference(bo);
>  }
>  
> -void drm_intel_bo_unreference(drm_intel_bo *bo)
> +drm_public void
> +drm_intel_bo_unreference(drm_intel_bo *bo)
>  {
>   if (bo == NULL)
>   return;
> @@ -82,24 +85,26 @@ void drm_intel_bo_unreference(drm_intel_bo *bo)
>   bo->bufmgr->bo_unreference(bo);
>  }
>  
> -int drm_intel_bo_map(drm_intel_bo *buf, int write_enable)
> +drm_public int
> +drm_intel_bo_map(drm_intel_bo *buf, int write_enable)
>  {
>   return buf->bufmgr->bo_map(buf, write_enable);
>  }
>  
> -int drm_intel_bo_unmap(drm_intel_bo *buf)
> +drm_public int
> +drm_intel_bo_unmap(drm_intel_bo *buf)
>  {
>   return buf->bufmgr->bo_unmap(buf);
>  }
>  
> -int
> +drm_public int
>  drm_intel_bo_subdata(drm_intel_bo *bo, unsigned long offset,
>unsigned long size, const void *data)
>  {
>   return bo->bufmgr->bo_subdata(bo, offset, size, data);
>  }
>  
> -int
> +drm_public int
>  drm_intel_bo_get_subdata(drm_intel_bo *bo, unsigned long offset,
>unsigned long size, void *data)
>  {
> @@ -118,24 +123,26 @@ drm_intel_bo_get_subdata(drm_intel_bo *bo, unsigned 
> long offset,
>   return 0;
>  }
>  
> -void drm_intel_bo_wait_rendering(drm_intel_bo *bo)
> +drm_public void
> +drm_intel_bo_wait_rendering(drm_intel_bo *bo)
>  {
>   bo->bufmgr->bo_wait_rendering(bo);
>  }
>  
> -void drm_intel_bufmgr_destroy(drm_intel_bufmgr *bufmgr)
> +drm_public void
> +drm_intel_bufmgr_destroy(drm_intel_bufmgr *bufmgr)
>  {
>   bufmgr->destroy(bufmgr);
>  }
>  
> -int
> +drm_public int
>  drm_intel_bo_exec(drm_intel_bo *bo, int used,
> drm_clip_rect_t * cliprects, int num_cliprects, int DR4)
>  {
>   return bo->bufmgr->bo_exec(bo, used, cliprects, num_cliprects, DR4);
>  }
>  
> -int
> +drm_public int
>  drm_intel_bo_mrb_exec(drm_intel_bo *bo, int used,
>   drm_clip_rect_t *cliprects, int num_cliprects, int DR4,
>   unsigned int rings)
> @@ -155,17 +162,20 @@ drm_intel_bo_mrb_exec(drm_intel_bo *bo, int used,
>   }
>  }
>  
> -void drm_intel_bufmgr_set_debug(drm_intel_bufmgr *bufmgr, int enable_debug)
> +drm_public void
> 

[PATCH v5] drm/nouveau: map pages using DMA API

[Daniel Vetter]

On Thu, Jul 31, 2014 at 06:09:42PM +0900, Alexandre Courbot wrote:
> The DMA API is the recommended way to map pages no matter what the
> underlying bus is. Use the DMA functions for page mapping and remove
> currently existing wrappers.
> 
> Signed-off-by: Alexandre Courbot 
> Cc: Daniel Vetter 
> ---
> Changes since v4:
> - Patch against the Nouveau tree instead of the kernel
> - Separated this patch from the rest of the series since it can be
>   merged alone
> - Replaced all pci_map invokations with dma_map. As Daniel pointed
>   out, using the PCI API is deprecated:
> Documentation/DMA-API-HOWTO.txt:
> 
> "Note that the DMA API works with any bus independent of the underlying
> microprocessor architecture. You should use the DMA API rather than the
> bus-specific DMA API, i.e., use the dma_map_*() interfaces rather than the
> pci_map_*() interfaces."
> - As a result, removed the page mapping wrappers which have become
>   unneeded.

Acked-by: Daniel Vetter 

> 
>  drm/nouveau_bo.c   | 22 --
>  lib/core/os.h  |  8 
>  nvkm/engine/device/base.c  | 25 -
>  nvkm/include/core/device.h |  6 --
>  nvkm/subdev/fb/nv50.c  |  7 +--
>  nvkm/subdev/fb/nvc0.c  |  7 +--
>  6 files changed, 30 insertions(+), 45 deletions(-)
> 
> diff --git a/drm/nouveau_bo.c b/drm/nouveau_bo.c
> index 4db886f9f793..e4f2071c46c3 100644
> --- a/drm/nouveau_bo.c
> +++ b/drm/nouveau_bo.c
> @@ -1340,6 +1340,7 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
>   struct nouveau_drm *drm;
>   struct nouveau_device *device;
>   struct drm_device *dev;
> + struct device *pdev;
>   unsigned i;
>   int r;
>   bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
> @@ -1358,6 +1359,7 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
>   drm = nouveau_bdev(ttm->bdev);
>   device = nv_device(drm->device);
>   dev = drm->dev;
> + pdev = nv_device_base(device);
>  
>  #if __OS_HAS_AGP
>   if (drm->agp.stat == ENABLED) {
> @@ -1377,17 +1379,22 @@ nouveau_ttm_tt_populate(struct ttm_tt *ttm)
>   }
>  
>   for (i = 0; i < ttm->num_pages; i++) {
> - ttm_dma->dma_address[i] = nv_device_map_page(device,
> -  ttm->pages[i]);
> - if (!ttm_dma->dma_address[i]) {
> + dma_addr_t addr;
> +
> + addr = dma_map_page(pdev, ttm->pages[i], 0, PAGE_SIZE,
> + DMA_BIDIRECTIONAL);
> +
> + if (dma_mapping_error(pdev, addr)) {
>   while (--i) {
> - nv_device_unmap_page(device,
> -  ttm_dma->dma_address[i]);
> + dma_unmap_page(pdev, ttm_dma->dma_address[i],
> +PAGE_SIZE, DMA_BIDIRECTIONAL);
>   ttm_dma->dma_address[i] = 0;
>   }
>   ttm_pool_unpopulate(ttm);
>   return -EFAULT;
>   }
> +
> + ttm_dma->dma_address[i] = addr;
>   }
>   return 0;
>  }
> @@ -1399,6 +1406,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
>   struct nouveau_drm *drm;
>   struct nouveau_device *device;
>   struct drm_device *dev;
> + struct device *pdev;
>   unsigned i;
>   bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
>  
> @@ -1408,6 +1416,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
>   drm = nouveau_bdev(ttm->bdev);
>   device = nv_device(drm->device);
>   dev = drm->dev;
> + pdev = nv_device_base(device);
>  
>  #if __OS_HAS_AGP
>   if (drm->agp.stat == ENABLED) {
> @@ -1425,7 +1434,8 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
>  
>   for (i = 0; i < ttm->num_pages; i++) {
>   if (ttm_dma->dma_address[i]) {
> - nv_device_unmap_page(device, ttm_dma->dma_address[i]);
> + dma_unmap_page(pdev, ttm_dma->dma_address[i], PAGE_SIZE,
> +DMA_BIDIRECTIONAL);
>   }
>   }
>  
> diff --git a/lib/core/os.h b/lib/core/os.h
> index 5f4f04fbff3d..596e083ffb36 100644
> --- a/lib/core/os.h
> +++ b/lib/core/os.h
> @@ -644,7 +644,7 @@ dma_free_coherent(struct device *dev, size_t sz, void 
> *vaddr, dma_addr_t bus)
>   
> */
>  #include 
>  
> -#define PCI_DMA_BIDIRECTIONAL 1
> +#define DMA_BIDIRECTIONAL 1
>  
>  #define PCI_CAP_ID_AGP 0x02
>  
> @@ -688,7 +688,7 @@ pci_resource_len(struct pci_dev *pdev, int bar)
>  }
>  
>  static inline dma_addr_t
> -pci_map_page(struct pci_dev *pdev, struct page *page, int offset,
> +dma_map_page(struct device *pdev, struct page *page, int offset,
>int length, unsigned flags)
>  {
>   return 0;
> @@ -696,13 +696,13 @@ pci_map_page(struct pci_dev *pdev, 

[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers

[Daniel Vetter]

On Fri, Aug 01, 2014 at 02:58:21PM +0200, Laurent Pinchart wrote:
> Hi Randy,
> 
> On Thursday 31 July 2014 15:16:21 Randy Dunlap wrote:
> > On 05/12/14 11:04, Randy Dunlap wrote:
> > > On 05/12/2014 08:54 AM, Daniel Vetter wrote:
> > >> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote:
> > >>> On 05/12/2014 01:58 AM, Daniel Vetter wrote:
> >  On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
> > >>> If we decide to go for property documentation inside the source code
> > >>> then I believe we'll have to create our own format, as creating a
> > >>> properties table from kerneldoc information extracted from comments
> > >>> is probably not possible.
> > >> 
> > >> Can comeone pick up the ball here and figure out what needs to be
> > >> done?
> > >> 
> > >> The reason why I want a central place for the documentation is to
> > >> force people to collaborate outside their own sandbox when adding
> > >> properties. Whether that's docbook or some text file I don't care so
> > >> much at this point. The fact that it's a central place should mandate
> > >> that the patches changing it will go through dri-devel and so
> > >> everyone should se them, and when adding new properties it would make
> > >> the patch author more likely to look around a bit before adding
> > >> another slighty incompatible version of the same property. If someone
> > >> has a better suggestion how to encforce this I'm all ears.
> > >> 
> > >> Of course this idea can still fail if our esteemed maintainer merges
> > >> stuff without checking for violations of this policy. Dave, any
> > >> thoughts on the subject?
> > > 
> > > Yeah I'm happy to block merging stuff, if we can spot new properties
> > > when stuff is posted on dri-devel, so much the better,
> > > 
> > > most drivers still send everything via dri-devel anyways, its only
> > > really Intel I have to worry about so far,
> >  
> >  I'll enforce that all prop stuff gets cc: dri-devel and that it has
> >  updates for the prop docs.
> >  
> > > But we should definitely add it to the new driver review checklist as
> > > well.
> > > 
> > > I'm also on the side of this patch is ugly and makes my eyes burn,
> > > please please get a plan to use something else ASAP, I'm willing to
> > > merge this but I'm tempted to give it a lifetime of a kernel or two
> > > before I burn it.
> >  
> >  Ok, I'll try to move "make kerneldoc suck less" up the task list and
> >  maybe find someone to do it for me internally ;-)
> > >>> 
> > >>> I certainly have no objections to making kerneldoc suck less.
> > >>> There was already an attempt to use asciidoc (like git uses) for
> > >>> kernel-doc (a few years ago, by Sam Ravnborg).  I support(ed) that
> > >>> effort.
> > >> 
> > >> Hm, do you have pointers to those? My google-fu seems lacking ...
> > > 
> > > I googled for /kernel doc asciidoc ravnborg/ and found several hits for
> > > them.
> > >
> > >> Ok, let's move this to the top and start discussions. The past few months
> > >> I've written piles of kerneldoc comments for the DRM DocBook (all pulled
> > >> in as kerneldoc, docbook .tmpl has just the chapter structure). DOC:
> > >> sections are really useful to pull all the actual documentation out of
> > >> the docbook xml into kerneldoc.
> > >> 
> > >> But I've also done piles of docs for intel-gpu-tools, which is using
> > >> gtkdoc. And there are some clear deficiencies:
> > >> 
> > >> - No markdown for inline coments. Lack of lists and tables is hurting
> > >>   especially badly. If we add this (and I don't care one iota whether
> > >>   it's
> > > 
> > > Yes, I've tried to add lists to kernel-doc notation but have failed so
> > > far.
> > > 
> > >>   markdown or asciidoc or something else as long as it's readable plain
> > >>   text in comments) we should be able to move all the existing docbook
> > >>   xml paragraphs/lists/tables into kerneldoc comments.
> > >> 
> > >> - Automatic cross-referencing of functions. If you place e.g. function()
> > >>   or #struct anywhere in a documentation comment gtk-doc automatically
> > >>   inserts a hyperlink to the relevant documentation page across the
> > >>   entire project. Really powerful and makes overview sections much more
> > >>   useful entry points for beginners since they can easily jump back
> > >>   betweeen the high-level overview and low-level per-function
> > >>   documentation.
> > > 
> > > That's a nice-to-have IMO, but a really nice one.
> > > 
> > >> - In a really perfect world it would help if kerneldoc could collect
> > >>   structure member kerneldoc from per-member comments. Especially for
> > >>   large structures with lots of comments this would bring the kerneldoc
> > >>   and struct member much closer together.
> > >> 
> > >> So that's my wishlist.
> > >> 
> > >>> OTOH, I would only want to 

[PATCH 1/2] drm/exynos: g2d: make ioctls more robust

[Inki Dae]

On 2014? 08? 03? 18:52, Tobias Jakobi wrote:
> Inki Dae wrote:
>> It seems that you have no build test because above line incurs build
>> error. Anyway I fixed it up.
> That's why I have sent v2 of the patch.
> 

Oops, sorry. I didn't check v2.

Thanks,
Inki Dae


> With best wishes,
> Tobias
> 
> 

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

Final feature pull for 3.17.

drm-intel-next-2014-07-25:
- Ditch UMS support (well just the config option for now)
- Prep work for future platforms (Sonika Jindal, Damien)
- runtime pm/soix fixes (Paulo, Jesse)
- psr tracking improvements, locking fixes, now enabled by default!
- rps fixes for chv (Deepak, Ville)
- drm core patches for rotation support (Ville, Sagar Kamble) - the i915 parts
  unfortunately didn't make it yet
- userptr fixes (Chris)
- minimum backlight brightness (Jani), acked long ago by Matthew Garret on irc -
  I've forgotten about this patch :(

QA is a bit unhappy about the DP MST stuff since it broke hpd testing a
bit, but otherwise looks sane. I've backmerged drm-next to resolve
conflicts with the mst stuff, which means the new tag itself doesn't
contain the overview as usual.

Cheers, Daniel


The following changes since commit e05444be705b5c7c7f85d7722b6f97f3a6732d54:

  drm/i915: fix initial fbdev setup warnings (2014-07-24 10:27:42 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2014-07-25-merged

for you to fetch changes up to 4dac3edfe68e5e1b3c2216b84ba160572420fa40:

  Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next 
(2014-07-29 20:49:36 +0200)


Armin Reese (1):
  drm/i915: Do not unmap object unless no other VMAs reference it

Ben Widawsky (2):
  drm/i915/error: Check the potential ctx obj's vm
  drm/i915: Reorder ctx unref on ppgtt cleanup

Borun Fu (1):
  drm/i915: Power gating display wells during i915_pm_suspend

Chris Wilson (5):
  drm/i915: Handle failure to kick out a conflicting fb driver
  drm/i915: Abandon oom quickly if killed by a signal
  drm/i915: Initialise userptr mmu_notifier serial to 1
  drm/i915: Allow overlapping userptr objects
  drm/i915/userptr: Keep spin_lock/unlock in the same block

Damien Lespiau (3):
  drm/i915: PM irq enabling is generic on gen8, too
  drm/i915: Also give the sprite width for WM computation
  drm/i915: Make the WRPLL names const

Daniel Vetter (14):
  drm/i915: ddi: enable runtime pm during dpms
  drm/i915: Run psr_setup unconditionally
  drm/i915: Add a FIXME about drrs/psr interactions
  drm/i915: Track the psr dp connector in dev_priv->psr.enabled
  drm/i915: Don't try to disable psr harder from the work item
  drm/i915: Lock down psr sw/hw state tracking
  drm/i915: More checks for psr.enabled
  drm/i915: Add locking to psr code
  drm/i915: Fix up PSR frontbuffer tracking
  drm/i915: Improve PSR debugfs output
  drm/i915: Remove redundant HAS_PSR checks
  drm/i915: Use genX_ prefix for gt irq enable/disable functions
  drm/i915: Ditch UMS config option
  Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next

Deepak S (9):
  drm/i915: Read guaranteed freq for valleyview
  drm/i915: Add RP0/RP1/RPn render P state thresholds in VLV sysfs
  drm/i915: populate mem_freq/cz_clock for chv
  drm/i915: CHV GPU frequency to opcode functions
  drm/i915/chv: Add basic PM interrupt support for CHV
  drm/i915: Add RP1 render P state thresholds in CHV
  drm/i915: Force GPU Freq to lowest while suspending.
  drm/i915/chv: Drop WaGsvBringDownFreqInRc6
  drm/i915: Fix printing proper min/min/rpe values in debugfs

Fengguang Wu (1):
  drm/i915: byt_gpu_freq() can be static

Jani Nikula (2):
  drm/i915: extract backlight minimum brightness from VBT
  drm/i915: respect the VBT minimum backlight brightness

Jesse Barnes (5):
  drm/i915: don't warn if IRQs are disabled when shutting down display IRQs
  drm/i915: add helper for checking whether IRQs are enabled
  drm/i915: set pm._irqs_disabled at IRQ init time
  drm/i915: clear pm._irqs_disabled field after installing IRQs
  drm/i915: mark IRQs as disabled on unload

Mika Kuoppala (1):
  drm/i915/chv: calculate rc6 residency correctly

Paulo Zanoni (7):
  drm/i915: remove useless runtime PM get calls
  drm/i915: don't write powered down IRQ registers on Gen 8
  drm/i915: HSW_BLC_PWM2_CTL doesn't exist on BDW
  drm/i915: extract and improve gen8_irq_power_well_post_enable
  drm/i915: reorganize the unclaimed register detection code
  drm/i915: BDW can also detect unclaimed registers
  drm/i915: remove plane/cursor/pipe assertions from intel_crtc_disable

Rodrigo Vivi (2):
  drm/i915: Enable PSR by default.
  drm/i915: Fix possible overflow when recording semaphore states.

Sagar Kamble (2):
  Documentation: drm: Removing placeholders for generic drm properties 
description
  Documentation: drm: describing rotation property

Sonika Jindal (8):
  drm/i915: Adding HAS_GMCH_DISPLAY macro
  drm/i915: Allowing changing of wm latencies for valid platforms
  drm/i915: Returning the right VGA control reg for 

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #5 from Kai  ---
(In reply to comment #4)
> (In reply to comment #3)
> > AFAICT Twitch requires Flash; what Flash plugin are you using in what
> > browser?
> 
> Yes, Twitch, like YouTube, requires Flash. I use the plugin installed by
> flashplugin-nonfree and its update-flashplugin-nonfree script. It's the 64
> bit version. I check the version number later again. But it was recently
> updated.

Sorry, forgot to name the browser: Iceweasel 31.0-3 (aka Firefox 31.0).

Just to note this again: other video pages like YouTube don't show the problem
Twitch has. And it's also only giving these spikes, when you try to watch a
recorded broadcast, not for live streams.

-- 
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/20140804/15a311a4/attachment.html>

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #4 from Kai  ---
(In reply to comment #3)
> CPU profiles from sysprof or perf or oprofile might be interesting.

Ok, I'll try to do that; I might not be able to do that today, though.

> AFAICT Twitch requires Flash; what Flash plugin are you using in what
> browser?

Yes, Twitch, like YouTube, requires Flash. I use the plugin installed by
flashplugin-nonfree and its update-flashplugin-nonfree script. It's the 64 bit
version. I check the version number later again. But it was recently updated.

> Does doing anything in particular trigger it in MediathekView?

Sort of: just starting is enough. You get the grey window background at below
average speed and then it takes seconds until the UI elements are drawn (list
of shows, filter boxes, buttons). Afterwards you can trigger a new CPU spike by
trying to click anything or even better on each keypress/character input into
the title filter field on the left.

-- 
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/20140804/d02d4a8e/attachment.html>

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #3 from Michel D?nzer  ---
CPU profiles from sysprof or perf or oprofile might be interesting.

AFAICT Twitch requires Flash; what Flash plugin are you using in what browser?

Does doing anything in particular trigger it in MediathekView?

-- 
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/20140804/2483bbad/attachment.html>

[Bug 82109] Firefox crashes Google Maps, likely related to graphics driver

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

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

--- Comment #2 from Aaron B  ---
SOunds like, and probably is, the same bug I have in Bug 81644. And the other
linked to, too.

-- 
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/20140804/3432b566/attachment-0001.html>

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #2 from Kai  ---
(In reply to comment #1)
> Please attach the Xorg.0.log and the output of dmesg and glxinfo.

Will post those later, when I'm back at that system.

> Is this with DPM successfully changing clocks?

As written in bug 74250, comment #8 reclocking doesn't seem to work for me.
Whatever I've been doing, the output of cat
/sys/kernel/debug/dri/0/radeon_pm_info /sys/kernel/debug/dri/64/radeon_pm_info
stays:
> power level avgsclk: 3 mclk: 15000
> power level avgsclk: 3 mclk: 15000

(observed through a SSH connection, in order to keep the 3D applications
running fullscreen). I can check the clocks with e.g. MediathekView too, but it
would be very weird if the GPU would reclock for "simple" applications and not
for the 3D applications, wouldn't it?

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

[Bug 81261] NVIDIA GT 745M not properly detected

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

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

Ilia Mirkin  changed:

   What|Removed |Added

 CC||imirkin at alum.mit.edu

--- Comment #8 from Ilia Mirkin  ---
There are no nouveau messages and there are NVRM messages. Do these issues
happen with nouveau instead of the blob?

As for not having GLX, you're probably mixing and matching xorg/mesa and nvidia
blob libraries.

The Xorg log all seems fine... you never actually stated anything about the
problem you're having (beyond some annoying lines in dmesg which are usually a
result of buggy ASL logic). And lastly using the blob basically gets you 0
support from most of the open source community. [FTR, the suggested config on
that archlinux wiki page is pretty crazy... but it does seem like it could
work.]

So... what's the issue? Is it that the proprietary nvidia drivers don't work in
some way that you expect them to? Then file a bug with nvidia. If the issue,
whatever it is, is reproducible without the blob drivers, feel free to update.

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

[Bug 82046] xbmc crashes with recent git mesa (git-150ac07) on r600g

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

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

--- Comment #1 from Michel D?nzer  ---
Can you bisect?

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

3D and then OpenCL on VIA VX800/VX820

[Felix Nawothnig]

Hey...

I know that this sounds crazy, but I'd like to attempt to do it - that 
is if it is possible at all. :-)

 From following the Noveau and Gallium development over the last years 
(including reading the source code) I have a slight clue how to do 
things but basically I'm a newbie to 3D driver development. (I do on the 
other hand have solid knowledge of higher level 3D programming, and 
solid knowledge of low-level / driver / hardware development).

Still, I'm willing to learn - so...

Tell me if it's possible at all (or maybe if just the first part might 
be possible) and give me a very slight hint where to start (obviously 
the start would be how to begin the 3D support for VX800/VX820).

And yea. I know this will take ages if I do this by myself - and the 
chances to succeed are slim...

But everyone needs a hobby. ;-)

And I love the idea of supporting OpenCL on an architecture where the 
vendor would probably never ever support it on any OS. :-)

Cheers,
Felix

[Bug 82055] [HAWAII] Running some programs, when HW acceleration is on, causes X to spike in CPU usage → unresponsive desktop

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

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

--- Comment #1 from Michel D?nzer  ---
Please attach the Xorg.0.log and the output of dmesg and glxinfo.

Is this with DPM successfully changing clocks?

-- 
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/20140804/048959a7/attachment.html>

[Bug 82109] Firefox crashes Google Maps, likely related to graphics driver

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

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

--- Comment #1 from Michel D?nzer  ---
We need symbols for the r600_dri.so stack frames, see bug 81680.

-- 
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/20140804/7890a513/attachment.html>

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

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

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

--- Comment #6 from Michel D?nzer  ---
(In reply to comment #5)
> Sorry, but I don't understand how to determine how r600_dri.so was built and
> etc.

Since you seem to be using Ubuntu, installing the libgl1-mesa-dri-dbg package
should make sure there are debugging symbols for r600_dri.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/20140804/7239957b/attachment.html>

[Bug 82109] New: Firefox crashes Google Maps, likely related to graphics driver

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

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

  Priority: medium
Bug ID: 82109
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Firefox crashes Google Maps, likely related to
graphics driver
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: markus.popp at gmx.at
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: 10.1
 Component: Drivers/Gallium/r600
   Product: Mesa

My Firefox (31.0 release to 34.0 nightly) on Linux64 regularly crashes when
accessing Google Maps. First time during a session it works fine, but going
back to Google Maps at a later point during the same session crashes Firefox.

I filed a bug at Mozilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=1022987

but since the crashes are apparently caused by the graphics driver, as
developers told me, I was asked to file a bug report here.

Find a corresponding Firefox Crash Report at

https://crash-stats.mozilla.com/report/index/228c877e-9bdf-4a59-b043-e51592140616

Please let me know if I can assist with providing further information.

-- 
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/20140804/dad82282/attachment.html>

[Bug 81261] NVIDIA GT 745M not properly detected

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

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

Aaron Lu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||aaron.lu at intel.com
  Component|Power-Video |Video(DRI - non Intel)
   Assignee|acpi_power-video at kernel-bug |drivers_video-dri at 
kernel-bu
   |s.osdl.org  |gs.osdl.org
Product|ACPI|Drivers

--- Comment #7 from Aaron Lu  ---
The error message from _ROM and _DSM all seems originated from the nouveau
driver, I would suggest having the nouveau driver developer take a look first.

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