[Bug 89987] Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)

2015-07-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89987

--- Comment #7 from James Le Cuirot  ---
And still a problem in 4.2.0-rc1. Is there nothing I can do to move this along?
It's really irritating. I have tried my best to fix it myself but to no avail.

-- 
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/20150709/6e12ffc7/attachment.html>


drm/imx: parallel-display: fix drm_panel support

2015-07-09 Thread Gary Bisson
Hi Philipp

On Tue, May 19, 2015 at 04:28:12PM +0200, Philipp Zabel wrote:
> The parallel-display driver used an undocumented, non-standard property
> "fsl,panel" to optionally associate with a drm_panel device. This patch
> fixes the driver to use the same OF graph bindings as the LDB driver
> instead:
> 
> parallel-display {
> compatible = "fsl,imx-parallel-display";
> ...
> 
> port at 1 {
> reg = <1>;
> 
> parallel_out: endpoint {
> remote_endpoint = <_in>;
> };
> };
> };
> 
> panel {
> ...
> 
> port {
> panel_in: endpoint {
> remote-endpoint = <_out>;
> };
> };
> };
> 
> Signed-off-by: Philipp Zabel 
> 
> ---

Tested on Nitrogen6x and Sabrelite using a Okaya RS800480T-7X0GP
display. Below are the different patches submitted that make use of this
change:
https://patchwork.kernel.org/patch/6585541/
https://patchwork.kernel.org/patch/6585551/
https://patchwork.kernel.org/patch/6504711/
https://patchwork.kernel.org/patch/6504731/

Tested-by: Gary Bisson 

Regards,
Gary


[PATCH v2 12/23] drm/exynos: don't track enabled state at exynos_crtc

2015-07-09 Thread Gustavo Padovan
2015-07-09 Joonyoung Shim :

> +Cc Andrzej,
> 
> On 07/07/2015 02:41 AM, Daniel Vetter wrote:
> > On Mon, Jul 06, 2015 at 11:20:13AM -0300, Gustavo Padovan wrote:
> >> From: Gustavo Padovan 
> >>
> >> struct drm_crtc already stores the enabled state of the crtc
> >> thus we don't need to replicate enabled in exynos_drm_crtc.
> >>
> 
> I think exynos_crtc->enabled can replace flags for power state of each
> hw driver(e.g. "powered" of mixer driver, "suspended" of fimd driver).
> Further, we can add other flag bit for instead of using special flag
> in hw driver like vsync state("int_en" of mixer driver, "irq_flags" of
> fimd driver.)

The reason I removed it is because crtc->state->active already stores
the same information as exynos_crtc->enabled. I think we could rely
on active as well for mixer powered and suspended.

Gustavo


[PATCH RESEND v2 2/6] drm/exynos/mixer: fix interrupt clearing

2015-07-09 Thread Joonyoung Shim
On 07/09/2015 05:07 PM, Andrzej Hajda wrote:
> The driver used incorrect flags to clear interrupt status.
> The patch fixes it.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index cae98db..25f0aac 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -718,6 +718,10 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
>  
>   /* handling VSYNC */
>   if (val & MXR_INT_STATUS_VSYNC) {
> + /* vsync interrupt use different bit for read and clear */
> + val |= MXR_INT_CLEAR_VSYNC;
> + val &= ~MXR_INT_STATUS_VSYNC;
> +
>   /* interlace scan need to check shadow register */
>   if (ctx->interlace) {
>   base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
> @@ -743,11 +747,6 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
>  
>  out:
>   /* clear interrupts */
> - if (~val & MXR_INT_EN_VSYNC) {
> - /* vsync interrupt use different bit for read and clear */
> - val &= ~MXR_INT_EN_VSYNC;
> - val |= MXR_INT_CLEAR_VSYNC;
> - }
>   mixer_reg_write(res, MXR_INT_STATUS, val);
>  
>   spin_unlock(>reg_slock);
> 

Reviewed-by: Joonyoung Shim 

Thanks.


[PATCH v2] scripts/kernel-doc: Adding cross-reference links to html documentation.

2015-07-09 Thread Jonathan Corbet
On Fri, 26 Jun 2015 12:08:57 -0300
Danilo Cesar Lemes de Paula  wrote:

> To ease the navigation in the documentation we should use  inside
> those tags so readers can easily jump between methods directly.
> 
> This was discussed in 2014[1] and is implemented by getting a list
> of  from the DocBook XML to generate a database. Then it looks
> for , and  tags that matches the ones in
> the database. As it only links existent references, no broken links are
> added.

So I put a lot more time into this today than I really had available.  I
think it's cool stuff, and we definitely want it.  But can I ask for one
more pass?  In particular:

 - It makes the docs build a lot more noisy, that would be nice to fix.

 - A bit more documentation in the script would be nice.  It also is happy
   to run with silly arguments; a detail since nobody will run it
   directly, but still...

 - Most importantly, it breaks "make htmldocs"; in particular, vast
   amounts of error spew results when it gets around to media_api.html.  I
   spent a while trying to figure out what was going on but didn't come up
   with anything conclusive; my suspicion is that it has to do with the
   separate makefile in Documentation/DocBook/media/.

Thanks,

jon


[Nouveau] CUDA fixed VA allocations and sparse mappings

2015-07-09 Thread Andrew Chew
> 2. Use the GPUVM inside the GPU to access system memory. The
> limitation here is that the GPUVM uses 40-bit addresses, so the
> virtual address range must be in the lower 40-bit address range of the
> CPU. Access speed is limited by PCI-e bandwidth. Another limitation is
> that the system memory pages must be pinned as the GPU doesn't support
> page faults.
> 
> The operation of reserving address space and BO creation is one IOCTL,
> while the mapping of the BO to the address space is a second IOCTL.
> There are of course unmap and free IOCTLs. The separation is done for
> a couple of reasons:
> 
> 1. If the application knows that it wants to use only part of the
> memory area it allocated, then there is no point in pinning all the
> BOs. So, the application can map/unmap just part of the allocation.
> 
> 2. If the application knows that it has finished using the BOs, and it
> also knows that it will use them later on, it can unmap the BOs (to
> make them unpinned) but not free them so the memory is still reserved
> (with its contents intact).

Yes, thanks Oled.  I think this is pretty much exactly how I imagine things
to work.

I'll post my code soon and see what you guys think.  There was some
misunderstanding on my part on how bo's work, so I need to rework some
stuff.


[PATCH v2 12/23] drm/exynos: don't track enabled state at exynos_crtc

2015-07-09 Thread Joonyoung Shim
+Cc Andrzej,

On 07/07/2015 02:41 AM, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 11:20:13AM -0300, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> struct drm_crtc already stores the enabled state of the crtc
>> thus we don't need to replicate enabled in exynos_drm_crtc.
>>

I think exynos_crtc->enabled can replace flags for power state of each
hw driver(e.g. "powered" of mixer driver, "suspended" of fimd driver).
Further, we can add other flag bit for instead of using special flag
in hw driver like vsync state("int_en" of mixer driver, "irq_flags" of
fimd driver.)

>> Signed-off-by: Gustavo Padovan 
> 
> Note that exynos_crtc->enabled doesn't match drm_crtc->enabled perfectly
> since the exynos one reflect hw state (including dpms). You want to look
> at crtc->state->active instead on functions enabling stuff, and
> old_crtc_state->active on functions disabling stuff (we don't wire that
> through everywhere yet).
> -Daniel
> 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 16 
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |  1 -
>>  2 files changed, 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index 9bc2353..5ab8972 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -26,14 +26,9 @@ static void exynos_drm_crtc_enable(struct drm_crtc *crtc)
>>  {
>>  struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>  
>> -if (exynos_crtc->enabled)
>> -return;
>> -
>>  if (exynos_crtc->ops->enable)
>>  exynos_crtc->ops->enable(exynos_crtc);
>>  
>> -exynos_crtc->enabled = true;
>> -
>>  drm_crtc_vblank_on(crtc);
>>  }
>>  
>> @@ -41,9 +36,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
>>  {
>>  struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>  
>> -if (!exynos_crtc->enabled)
>> -return;
>> -
>>  /* wait for the completion of page flip. */
>>  if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
>>  (exynos_crtc->event == NULL), HZ/20))
>> @@ -53,8 +45,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
>>  
>>  if (exynos_crtc->ops->disable)
>>  exynos_crtc->ops->disable(exynos_crtc);
>> -
>> -exynos_crtc->enabled = false;
>>  }
>>  
>>  static bool
>> @@ -171,9 +161,6 @@ int exynos_drm_crtc_enable_vblank(struct drm_device 
>> *dev, int pipe)
>>  struct exynos_drm_crtc *exynos_crtc =
>>  to_exynos_crtc(private->crtc[pipe]);
>>  
>> -if (!exynos_crtc->enabled)
>> -return -EPERM;
>> -
>>  if (exynos_crtc->ops->enable_vblank)
>>  return exynos_crtc->ops->enable_vblank(exynos_crtc);
>>  
>> @@ -186,9 +173,6 @@ void exynos_drm_crtc_disable_vblank(struct drm_device 
>> *dev, int pipe)
>>  struct exynos_drm_crtc *exynos_crtc =
>>  to_exynos_crtc(private->crtc[pipe]);
>>  
>> -if (!exynos_crtc->enabled)
>> -return;
>> -
>>  if (exynos_crtc->ops->disable_vblank)
>>  exynos_crtc->ops->disable_vblank(exynos_crtc);
>>  }
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 5bd1d3c..d3a8f0a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -185,7 +185,6 @@ struct exynos_drm_crtc {
>>  struct drm_crtc base;
>>  enum exynos_drm_output_type type;
>>  unsigned intpipe;
>> -boolenabled;
>>  wait_queue_head_t   pending_flip_queue;
>>  struct drm_pending_vblank_event *event;
>>  const struct exynos_drm_crtc_ops*ops;
>> -- 
>> 2.1.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 



[RFCv3 0/5] enable migration of driver pages

2015-07-09 Thread Kirill A. Shutemov
On Thu, Jul 09, 2015 at 04:33:01PM +0300, Ville Syrjälä wrote:
> On Thu, Jul 09, 2015 at 03:08:48PM +0200, Daniel Vetter wrote:
> > On Thu, Jul 09, 2015 at 08:55:25AM +0900, Gioh Kim wrote:
> > > 
> > > 
> > > 2015-07-09 오전 7:47에 Dave Airlie 이(가) 쓴 글:
> > > >>>
> > > >>>
> > > >>>Can the various in-kernel GPU drivers benefit from this?  If so, wiring
> > > >>>up one or more of those would be helpful?
> > > >>
> > > >>
> > > >>I'm sure that other in-kernel GPU drivers can have benefit.
> > > >>It must be helpful.
> > > >>
> > > >>If I was familiar with other in-kernel GPU drivers code, I tried to 
> > > >>patch
> > > >>them.
> > > >>It's too bad.
> > > >
> > > >I'll bring dri-devel into the loop here.
> > > >
> > > >ARM GPU developers please take a look at this stuff, Laurent, Rob,
> > > >Eric I suppose.
> > > 
> > > I sent a patch, https://lkml.org/lkml/2015/3/24/1182, and my opinion 
> > > about compaction
> > > to ARM GPU developers via Korea ARM branch.
> > > I got a reply that they had no time to review it.
> > > 
> > > I hope they're interested to this patch.
> > 
> > i915 gpus would support 64kb and 2mb pages, but we never implemented this.
> > I don't think this would fit for gem based drivers since our backing
> > storage is shmemfs. So if we want to implement page migration (which we'd
> > probably want to make large pages work well) we'd need to pimp shmem to a)
> > hand large pages to us b) forward the migrate calls. Probably that means
> > we need to build our own gemfs reusing shmemfs code.
> 
> AFAIK there are efforts ongoing to make large pages work with shmem.
> 
> Kirill, IIRC you mentioned that you're were looking into this a while
> back?

I work in this direction, but don't have anything to show at the moment.

Hugh has published his implementation of huge tmpfs back in February:

http://lkml.kernel.org/g/alpine.LSU.2.11.1502201941340.14414 at eggly.anvils

-- 
 Kirill A. Shutemov


[PATCH RESEND 0/6] drm/exynos: HDMI related fixes

2015-07-09 Thread Joonyoung Shim
Hi Andrzej,

On 07/09/2015 03:25 PM, Andrzej Hajda wrote:
> 
> 
> Andrzej Hajda (6):
>   drm/exynos/hdmi: fix edid memory leak
>   drm/exynos/mixer: fix interrupt clearing
>   drm/exynos/mixer: correct vsync configuration sequence
>   drm/exynos/mixer: always update INT_EN cache
>   drm/exynos/mixer: simplify poweron flag
>   drm/exynos/mixer: replace MXR_INT_EN register cache with flag
> 
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  7 ++-
>  drivers/gpu/drm/exynos/exynos_mixer.c | 80 
> +--
>  2 files changed, 36 insertions(+), 51 deletions(-)
> 

Looks good to me except one comment of "drm/exynos/mixer: fix interrupt
clearing" patch. Also below my patch can be dropped by this patchset.

http://www.spinics.net/lists/dri-devel/msg85322.html

Reviewed-by: Joonyoung Shim 


[PATCH RESEND 2/6] drm/exynos/mixer: fix interrupt clearing

2015-07-09 Thread Joonyoung Shim
On 07/09/2015 03:25 PM, Andrzej Hajda wrote:
> The driver used incorrect flags to clear interrupt status.
> The patch fixes it.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index cae98db..0686484 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -718,6 +718,9 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
>  
>   /* handling VSYNC */
>   if (val & MXR_INT_STATUS_VSYNC) {
> + /* vsync interrupt use different bit for read and clear */
> + val |= MXR_INT_CLEAR_VSYNC;

MXR_INT_STATUS_VSYNC bit of MXR_INT_STATUS register is read-only, so it
needs to be clear MXR_INT_STATUS_VSYNC bit of val.

> +
>   /* interlace scan need to check shadow register */
>   if (ctx->interlace) {
>   base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
> @@ -743,11 +746,6 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
>  
>  out:
>   /* clear interrupts */
> - if (~val & MXR_INT_EN_VSYNC) {
> - /* vsync interrupt use different bit for read and clear */
> - val &= ~MXR_INT_EN_VSYNC;
> - val |= MXR_INT_CLEAR_VSYNC;
> - }
>   mixer_reg_write(res, MXR_INT_STATUS, val);
>  
>   spin_unlock(>reg_slock);
> 



[RFCv3 0/5] enable migration of driver pages

2015-07-09 Thread Ville Syrjälä
On Thu, Jul 09, 2015 at 03:08:48PM +0200, Daniel Vetter wrote:
> On Thu, Jul 09, 2015 at 08:55:25AM +0900, Gioh Kim wrote:
> > 
> > 
> > 2015-07-09 오전 7:47에 Dave Airlie 이(가) 쓴 글:
> > >>>
> > >>>
> > >>>Can the various in-kernel GPU drivers benefit from this?  If so, wiring
> > >>>up one or more of those would be helpful?
> > >>
> > >>
> > >>I'm sure that other in-kernel GPU drivers can have benefit.
> > >>It must be helpful.
> > >>
> > >>If I was familiar with other in-kernel GPU drivers code, I tried to patch
> > >>them.
> > >>It's too bad.
> > >
> > >I'll bring dri-devel into the loop here.
> > >
> > >ARM GPU developers please take a look at this stuff, Laurent, Rob,
> > >Eric I suppose.
> > 
> > I sent a patch, https://lkml.org/lkml/2015/3/24/1182, and my opinion about 
> > compaction
> > to ARM GPU developers via Korea ARM branch.
> > I got a reply that they had no time to review it.
> > 
> > I hope they're interested to this patch.
> 
> i915 gpus would support 64kb and 2mb pages, but we never implemented this.
> I don't think this would fit for gem based drivers since our backing
> storage is shmemfs. So if we want to implement page migration (which we'd
> probably want to make large pages work well) we'd need to pimp shmem to a)
> hand large pages to us b) forward the migrate calls. Probably that means
> we need to build our own gemfs reusing shmemfs code.

AFAIK there are efforts ongoing to make large pages work with shmem.

Kirill, IIRC you mentioned that you're were looking into this a while
back?

-- 
Ville Syrjälä
Intel OTC


[PATCH 7/7] drm/exynos/hdmi: remove hdmi_v14_conf struct

2015-07-09 Thread Andrzej Hajda
The patch removes intermediate struct for HDMIv14 register configuration,
instead registry values are calculated on the fly.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 427 +--
 1 file changed, 109 insertions(+), 318 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 60663ad..448f534 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -86,71 +86,6 @@ struct hdmi_resources {
int regul_count;
 };

-struct hdmi_tg_regs {
-   u8 cmd[1];
-   u8 h_fsz[2];
-   u8 hact_st[2];
-   u8 hact_sz[2];
-   u8 v_fsz[2];
-   u8 vsync[2];
-   u8 vsync2[2];
-   u8 vact_st[2];
-   u8 vact_sz[2];
-   u8 field_chg[2];
-   u8 vact_st2[2];
-   u8 vact_st3[2];
-   u8 vact_st4[2];
-   u8 vsync_top_hdmi[2];
-   u8 vsync_bot_hdmi[2];
-   u8 field_top_hdmi[2];
-   u8 field_bot_hdmi[2];
-   u8 tg_3d[1];
-};
-
-struct hdmi_v14_core_regs {
-   u8 h_blank[2];
-   u8 v2_blank[2];
-   u8 v1_blank[2];
-   u8 v_line[2];
-   u8 h_line[2];
-   u8 hsync_pol[1];
-   u8 vsync_pol[1];
-   u8 int_pro_mode[1];
-   u8 v_blank_f0[2];
-   u8 v_blank_f1[2];
-   u8 h_sync_start[2];
-   u8 h_sync_end[2];
-   u8 v_sync_line_bef_2[2];
-   u8 v_sync_line_bef_1[2];
-   u8 v_sync_line_aft_2[2];
-   u8 v_sync_line_aft_1[2];
-   u8 v_sync_line_aft_pxl_2[2];
-   u8 v_sync_line_aft_pxl_1[2];
-   u8 v_blank_f2[2]; /* for 3D mode */
-   u8 v_blank_f3[2]; /* for 3D mode */
-   u8 v_blank_f4[2]; /* for 3D mode */
-   u8 v_blank_f5[2]; /* for 3D mode */
-   u8 v_sync_line_aft_3[2];
-   u8 v_sync_line_aft_4[2];
-   u8 v_sync_line_aft_5[2];
-   u8 v_sync_line_aft_6[2];
-   u8 v_sync_line_aft_pxl_3[2];
-   u8 v_sync_line_aft_pxl_4[2];
-   u8 v_sync_line_aft_pxl_5[2];
-   u8 v_sync_line_aft_pxl_6[2];
-   u8 vact_space_1[2];
-   u8 vact_space_2[2];
-   u8 vact_space_3[2];
-   u8 vact_space_4[2];
-   u8 vact_space_5[2];
-   u8 vact_space_6[2];
-};
-
-struct hdmi_v14_conf {
-   struct hdmi_v14_core_regs core;
-   struct hdmi_tg_regs tg;
-};
-
 struct hdmi_context {
struct exynos_drm_display   display;
struct device   *dev;
@@ -170,7 +105,6 @@ struct hdmi_context {
/* current hdmiphy conf regs */
struct drm_display_mode current_mode;
u8  cea_video_id;
-   struct hdmi_v14_confmode_conf;

struct hdmi_resources   res;
const struct hdmi_driver_data   *drv_data;
@@ -1508,143 +1442,119 @@ static void hdmi_v13_mode_apply(struct hdmi_context 
*hdata)

 static void hdmi_v14_mode_apply(struct hdmi_context *hdata)
 {
-   const struct hdmi_tg_regs *tg = >mode_conf.tg;
-   const struct hdmi_v14_core_regs *core = >mode_conf.core;
+   struct drm_display_mode *m = >current_mode;
int tries;

-   /* setting core registers */
-   hdmi_reg_writeb(hdata, HDMI_H_BLANK_0, core->h_blank[0]);
-   hdmi_reg_writeb(hdata, HDMI_H_BLANK_1, core->h_blank[1]);
-   hdmi_reg_writeb(hdata, HDMI_V2_BLANK_0, core->v2_blank[0]);
-   hdmi_reg_writeb(hdata, HDMI_V2_BLANK_1, core->v2_blank[1]);
-   hdmi_reg_writeb(hdata, HDMI_V1_BLANK_0, core->v1_blank[0]);
-   hdmi_reg_writeb(hdata, HDMI_V1_BLANK_1, core->v1_blank[1]);
-   hdmi_reg_writeb(hdata, HDMI_V_LINE_0, core->v_line[0]);
-   hdmi_reg_writeb(hdata, HDMI_V_LINE_1, core->v_line[1]);
-   hdmi_reg_writeb(hdata, HDMI_H_LINE_0, core->h_line[0]);
-   hdmi_reg_writeb(hdata, HDMI_H_LINE_1, core->h_line[1]);
-   hdmi_reg_writeb(hdata, HDMI_HSYNC_POL, core->hsync_pol[0]);
-   hdmi_reg_writeb(hdata, HDMI_VSYNC_POL, core->vsync_pol[0]);
-   hdmi_reg_writeb(hdata, HDMI_INT_PRO_MODE, core->int_pro_mode[0]);
-   hdmi_reg_writeb(hdata, HDMI_V_BLANK_F0_0, core->v_blank_f0[0]);
-   hdmi_reg_writeb(hdata, HDMI_V_BLANK_F0_1, core->v_blank_f0[1]);
-   hdmi_reg_writeb(hdata, HDMI_V_BLANK_F1_0, core->v_blank_f1[0]);
-   hdmi_reg_writeb(hdata, HDMI_V_BLANK_F1_1, core->v_blank_f1[1]);
-   hdmi_reg_writeb(hdata, HDMI_H_SYNC_START_0, core->h_sync_start[0]);
-   hdmi_reg_writeb(hdata, HDMI_H_SYNC_START_1, core->h_sync_start[1]);
-   hdmi_reg_writeb(hdata, HDMI_H_SYNC_END_0, core->h_sync_end[0]);
-   hdmi_reg_writeb(hdata, HDMI_H_SYNC_END_1, core->h_sync_end[1]);
-   hdmi_reg_writeb(hdata, HDMI_V_SYNC_LINE_BEF_2_0,
-   core->v_sync_line_bef_2[0]);
-   hdmi_reg_writeb(hdata, HDMI_V_SYNC_LINE_BEF_2_1,
-   core->v_sync_line_bef_2[1]);
-   hdmi_reg_writeb(hdata, HDMI_V_SYNC_LINE_BEF_1_0,
-   core->v_sync_line_bef_1[0]);
-   hdmi_reg_writeb(hdata, 

[PATCH 6/7] drm/exynos/hdmi: remove hdmi_v13_conf struct

2015-07-09 Thread Andrzej Hajda
The patch removes intermediate struct for HDMIv13 register configuration,
instead registry values are calculated on the fly.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 280 +--
 1 file changed, 101 insertions(+), 179 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a3fe2f0..60663ad 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -107,19 +107,6 @@ struct hdmi_tg_regs {
u8 tg_3d[1];
 };

-struct hdmi_v13_core_regs {
-   u8 h_blank[2];
-   u8 v_blank[3];
-   u8 h_v_line[3];
-   u8 vsync_pol[1];
-   u8 int_pro_mode[1];
-   u8 v_blank_f[3];
-   u8 h_sync_gen[3];
-   u8 v_sync_gen1[3];
-   u8 v_sync_gen2[3];
-   u8 v_sync_gen3[3];
-};
-
 struct hdmi_v14_core_regs {
u8 h_blank[2];
u8 v2_blank[2];
@@ -159,21 +146,11 @@ struct hdmi_v14_core_regs {
u8 vact_space_6[2];
 };

-struct hdmi_v13_conf {
-   struct hdmi_v13_core_regs core;
-   struct hdmi_tg_regs tg;
-};
-
 struct hdmi_v14_conf {
struct hdmi_v14_core_regs core;
struct hdmi_tg_regs tg;
 };

-union hdmi_conf_regs {
-   struct hdmi_v13_conf v13_conf;
-   struct hdmi_v14_conf v14_conf;
-};
-
 struct hdmi_context {
struct exynos_drm_display   display;
struct device   *dev;
@@ -193,7 +170,7 @@ struct hdmi_context {
/* current hdmiphy conf regs */
struct drm_display_mode current_mode;
u8  cea_video_id;
-   union hdmi_conf_regsmode_conf;
+   struct hdmi_v14_confmode_conf;

struct hdmi_resources   res;
const struct hdmi_driver_data   *drv_data;
@@ -614,6 +591,16 @@ static inline void hdmi_reg_writeb(struct hdmi_context 
*hdata,
writeb(value, hdata->regs + reg_id);
 }

+static inline void hdmi_reg_writev(struct hdmi_context *hdata, u32 reg_id,
+  int bytes, u32 val)
+{
+   while (--bytes >= 0) {
+   writeb(val & 0xff, hdata->regs + reg_id);
+   val >>= 8;
+   reg_id += 4;
+   }
+}
+
 static inline void hdmi_reg_writemask(struct hdmi_context *hdata,
 u32 reg_id, u32 value, u32 mask)
 {
@@ -1409,65 +1396,94 @@ static void hdmi_conf_init(struct hdmi_context *hdata)

 static void hdmi_v13_mode_apply(struct hdmi_context *hdata)
 {
-   const struct hdmi_tg_regs *tg = >mode_conf.v13_conf.tg;
-   const struct hdmi_v13_core_regs *core = >mode_conf.v13_conf.core;
+   struct drm_display_mode *m = >current_mode;
+   unsigned int val;
int tries;

-   /* setting core registers */
-   hdmi_reg_writeb(hdata, HDMI_H_BLANK_0, core->h_blank[0]);
-   hdmi_reg_writeb(hdata, HDMI_H_BLANK_1, core->h_blank[1]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_BLANK_0, core->v_blank[0]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_BLANK_1, core->v_blank[1]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_BLANK_2, core->v_blank[2]);
-   hdmi_reg_writeb(hdata, HDMI_V13_H_V_LINE_0, core->h_v_line[0]);
-   hdmi_reg_writeb(hdata, HDMI_V13_H_V_LINE_1, core->h_v_line[1]);
-   hdmi_reg_writeb(hdata, HDMI_V13_H_V_LINE_2, core->h_v_line[2]);
-   hdmi_reg_writeb(hdata, HDMI_VSYNC_POL, core->vsync_pol[0]);
-   hdmi_reg_writeb(hdata, HDMI_INT_PRO_MODE, core->int_pro_mode[0]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_BLANK_F_0, core->v_blank_f[0]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_BLANK_F_1, core->v_blank_f[1]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_BLANK_F_2, core->v_blank_f[2]);
-   hdmi_reg_writeb(hdata, HDMI_V13_H_SYNC_GEN_0, core->h_sync_gen[0]);
-   hdmi_reg_writeb(hdata, HDMI_V13_H_SYNC_GEN_1, core->h_sync_gen[1]);
-   hdmi_reg_writeb(hdata, HDMI_V13_H_SYNC_GEN_2, core->h_sync_gen[2]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_SYNC_GEN_1_0, core->v_sync_gen1[0]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_SYNC_GEN_1_1, core->v_sync_gen1[1]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_SYNC_GEN_1_2, core->v_sync_gen1[2]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_SYNC_GEN_2_0, core->v_sync_gen2[0]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_SYNC_GEN_2_1, core->v_sync_gen2[1]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_SYNC_GEN_2_2, core->v_sync_gen2[2]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_SYNC_GEN_3_0, core->v_sync_gen3[0]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_SYNC_GEN_3_1, core->v_sync_gen3[1]);
-   hdmi_reg_writeb(hdata, HDMI_V13_V_SYNC_GEN_3_2, core->v_sync_gen3[2]);
+   hdmi_reg_writev(hdata, HDMI_H_BLANK_0, 2, m->htotal - m->hdisplay);
+   hdmi_reg_writev(hdata, HDMI_V13_H_V_LINE_0, 3,
+   (m->htotal << 12) | m->vtotal);
+
+   val = (m->flags & DRM_MODE_FLAG_NVSYNC) ? 1 : 0;
+   hdmi_reg_writev(hdata, HDMI_VSYNC_POL, 1, val);
+
+   val = 

[PATCH 5/7] drm/exynos/hdmi: remove redundant configuration fields

2015-07-09 Thread Andrzej Hajda
The patch removes redundant fields from hdmi_conf_regs. Their values
can be calculated from current_mode. This patch is the first step to remove
whole hdmi_conf_regs structure.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 68 +---
 1 file changed, 24 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f9c4de1..a3fe2f0 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -169,14 +169,9 @@ struct hdmi_v14_conf {
struct hdmi_tg_regs tg;
 };

-struct hdmi_conf_regs {
-   int pixel_clock;
-   int cea_video_id;
-   enum hdmi_picture_aspect aspect_ratio;
-   union {
-   struct hdmi_v13_conf v13_conf;
-   struct hdmi_v14_conf v14_conf;
-   } conf;
+union hdmi_conf_regs {
+   struct hdmi_v13_conf v13_conf;
+   struct hdmi_v14_conf v14_conf;
 };

 struct hdmi_context {
@@ -197,7 +192,8 @@ struct hdmi_context {

/* current hdmiphy conf regs */
struct drm_display_mode current_mode;
-   struct hdmi_conf_regs   mode_conf;
+   u8  cea_video_id;
+   union hdmi_conf_regsmode_conf;

struct hdmi_resources   res;
const struct hdmi_driver_data   *drv_data;
@@ -951,7 +947,7 @@ static void hdmi_reg_infoframe(struct hdmi_context *hdata,
u32 hdr_sum;
u8 chksum;
u32 mod;
-   u32 vic;
+   u8 ar;

mod = hdmi_reg_read(hdata, HDMI_MODE_SEL);
if (hdata->dvi_mode) {
@@ -982,27 +978,22 @@ static void hdmi_reg_infoframe(struct hdmi_context *hdata,
 * Set the aspect ratio as per the mode, mentioned in
 * Table 9 AVI InfoFrame Data Byte 2 of CEA-861-D Standard
 */
-   switch (hdata->mode_conf.aspect_ratio) {
+   ar = hdata->current_mode.picture_aspect_ratio;
+   switch (ar) {
case HDMI_PICTURE_ASPECT_4_3:
-   hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(2),
-   hdata->mode_conf.aspect_ratio |
-   AVI_4_3_CENTER_RATIO);
+   ar |= AVI_4_3_CENTER_RATIO;
break;
case HDMI_PICTURE_ASPECT_16_9:
-   hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(2),
-   hdata->mode_conf.aspect_ratio |
-   AVI_16_9_CENTER_RATIO);
+   ar |= AVI_16_9_CENTER_RATIO;
break;
case HDMI_PICTURE_ASPECT_NONE:
default:
-   hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(2),
-   hdata->mode_conf.aspect_ratio |
-   AVI_SAME_AS_PIC_ASPECT_RATIO);
+   ar |= AVI_SAME_AS_PIC_ASPECT_RATIO;
break;
}
+   hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(2), ar);

-   vic = hdata->mode_conf.cea_video_id;
-   hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(4), vic);
+   hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(4), hdata->cea_video_id);

chksum = hdmi_chksum(hdata, HDMI_AVI_BYTE(1),
infoframe->any.length, hdr_sum);
@@ -1418,9 +1409,8 @@ static void hdmi_conf_init(struct hdmi_context *hdata)

 static void hdmi_v13_mode_apply(struct hdmi_context *hdata)
 {
-   const struct hdmi_tg_regs *tg = >mode_conf.conf.v13_conf.tg;
-   const struct hdmi_v13_core_regs *core =
-   >mode_conf.conf.v13_conf.core;
+   const struct hdmi_tg_regs *tg = >mode_conf.v13_conf.tg;
+   const struct hdmi_v13_core_regs *core = >mode_conf.v13_conf.core;
int tries;

/* setting core registers */
@@ -1502,9 +1492,8 @@ static void hdmi_v13_mode_apply(struct hdmi_context 
*hdata)

 static void hdmi_v14_mode_apply(struct hdmi_context *hdata)
 {
-   const struct hdmi_tg_regs *tg = >mode_conf.conf.v14_conf.tg;
-   const struct hdmi_v14_core_regs *core =
-   >mode_conf.conf.v14_conf.core;
+   const struct hdmi_tg_regs *tg = >mode_conf.v14_conf.tg;
+   const struct hdmi_v14_core_regs *core = >mode_conf.v14_conf.core;
int tries;

/* setting core registers */
@@ -1742,7 +1731,7 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata)
int i;

/* pixel clock */
-   i = hdmi_find_phy_conf(hdata, hdata->mode_conf.pixel_clock);
+   i = hdmi_find_phy_conf(hdata, hdata->current_mode.clock * 1000);
if (i < 0) {
DRM_ERROR("failed to find hdmiphy conf\n");
return;
@@ -1794,15 +1783,10 @@ static void hdmi_set_reg(u8 *reg_pair, int num_bytes, 
u32 value)
 static void hdmi_v13_mode_set(struct 

[PATCH 4/7] drm/exynos/hdmi: add driver data pointer to private context

2015-07-09 Thread Andrzej Hajda
The patch replaces duplicated driver data fields in private context with
pointer to driver data. It also simplifies driver data lookup code.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 49 +++-
 1 file changed, 20 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f2e909d..f9c4de1 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -32,8 +32,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -200,14 +200,12 @@ struct hdmi_context {
struct hdmi_conf_regs   mode_conf;

struct hdmi_resources   res;
+   const struct hdmi_driver_data   *drv_data;

int hpd_gpio;
void __iomem*regs_hdmiphy;
-   const struct hdmiphy_config *phy_confs;
-   unsigned intphy_conf_count;

struct regmap   *pmureg;
-   enum hdmi_type  type;
 };

 static inline struct hdmi_context *display_to_hdmi(struct exynos_drm_display 
*d)
@@ -926,7 +924,7 @@ static void hdmi_v14_regs_dump(struct hdmi_context *hdata, 
char *prefix)

 static void hdmi_regs_dump(struct hdmi_context *hdata, char *prefix)
 {
-   if (hdata->type == HDMI_TYPE13)
+   if (hdata->drv_data->type == HDMI_TYPE13)
hdmi_v13_regs_dump(hdata, prefix);
else
hdmi_v14_regs_dump(hdata, prefix);
@@ -1087,8 +1085,8 @@ static int hdmi_find_phy_conf(struct hdmi_context *hdata, 
u32 pixel_clock)
 {
int i;

-   for (i = 0; i < hdata->phy_conf_count; i++)
-   if (hdata->phy_confs[i].pixel_clock == pixel_clock)
+   for (i = 0; i < hdata->drv_data->phy_conf_count; i++)
+   if (hdata->drv_data->phy_confs[i].pixel_clock == pixel_clock)
return i;

DRM_DEBUG_KMS("Could not find phy config for %d\n", pixel_clock);
@@ -1253,7 +1251,7 @@ static void hdmi_reg_acr(struct hdmi_context *hdata, u8 
*acr)
hdmi_reg_writeb(hdata, HDMI_ACR_CTS1, acr[2]);
hdmi_reg_writeb(hdata, HDMI_ACR_CTS2, acr[1]);

-   if (hdata->type == HDMI_TYPE13)
+   if (hdata->drv_data->type == HDMI_TYPE13)
hdmi_reg_writeb(hdata, HDMI_V13_ACR_CON, 4);
else
hdmi_reg_writeb(hdata, HDMI_ACR_CON, 4);
@@ -1387,7 +1385,7 @@ static void hdmi_conf_init(struct hdmi_context *hdata)
HDMI_VID_PREAMBLE_DIS | HDMI_GUARD_BAND_DIS);
}

-   if (hdata->type == HDMI_TYPE13) {
+   if (hdata->drv_data->type == HDMI_TYPE13) {
/* choose bluescreen (fecal) color */
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_0, 0x12);
hdmi_reg_writeb(hdata, HDMI_V13_BLUE_SCREEN_1, 0x34);
@@ -1666,7 +1664,7 @@ static void hdmi_v14_mode_apply(struct hdmi_context 
*hdata)

 static void hdmi_mode_apply(struct hdmi_context *hdata)
 {
-   if (hdata->type == HDMI_TYPE13)
+   if (hdata->drv_data->type == HDMI_TYPE13)
hdmi_v13_mode_apply(hdata);
else
hdmi_v14_mode_apply(hdata);
@@ -1684,7 +1682,7 @@ static void hdmiphy_conf_reset(struct hdmi_context *hdata)
hdmiphy_reg_writeb(hdata, HDMIPHY_MODE_SET_DONE,
HDMI_PHY_ENABLE_MODE_SET);

-   if (hdata->type == HDMI_TYPE13)
+   if (hdata->drv_data->type == HDMI_TYPE13)
reg = HDMI_V13_PHY_RSTOUT;
else
reg = HDMI_PHY_RSTOUT;
@@ -1698,7 +1696,7 @@ static void hdmiphy_conf_reset(struct hdmi_context *hdata)

 static void hdmiphy_poweron(struct hdmi_context *hdata)
 {
-   if (hdata->type != HDMI_TYPE14)
+   if (hdata->drv_data->type != HDMI_TYPE14)
return;

DRM_DEBUG_KMS("\n");
@@ -1718,7 +1716,7 @@ static void hdmiphy_poweron(struct hdmi_context *hdata)

 static void hdmiphy_poweroff(struct hdmi_context *hdata)
 {
-   if (hdata->type != HDMI_TYPE14)
+   if (hdata->drv_data->type != HDMI_TYPE14)
return;

DRM_DEBUG_KMS("\n");
@@ -1750,7 +1748,8 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata)
return;
}

-   ret = hdmiphy_reg_write_buf(hdata, 0, hdata->phy_confs[i].conf, 32);
+   ret = hdmiphy_reg_write_buf(hdata, 0,
+   hdata->drv_data->phy_confs[i].conf, 32);
if (ret) {
DRM_ERROR("failed to configure hdmiphy\n");
return;
@@ -2015,7 +2014,7 @@ static void hdmi_mode_set(struct exynos_drm_display 
*display,
/* preserve mode information for later use. */
drm_mode_copy(>current_mode, mode);

-   if (hdata->type == HDMI_TYPE13)
+   if (hdata->drv_data->type == HDMI_TYPE13)
hdmi_v13_mode_set(hdata, mode);
else
 

[PATCH 3/7] drm/exynos/hdmi: remove private lock code

2015-07-09 Thread Andrzej Hajda
Most of the code is called by drm core framework, so it is already synchronized.
The only async function is irq routine which only calls drm framework so it
does not need to be synchronized.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 27 +++
 1 file changed, 3 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 1d07bdf..f2e909d 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -22,7 +22,6 @@
 #include "regs-hdmi.h"

 #include 
-#include 
 #include 
 #include 
 #include 
@@ -188,7 +187,6 @@ struct hdmi_context {
struct drm_encoder  *encoder;
boolpowered;
booldvi_mode;
-   struct mutexhdmi_mutex;

void __iomem*regs;
int irq;
@@ -1774,10 +1772,8 @@ static void hdmi_conf_apply(struct hdmi_context *hdata)
hdmiphy_conf_reset(hdata);
hdmiphy_conf_apply(hdata);

-   mutex_lock(>hdmi_mutex);
hdmi_start(hdata, false);
hdmi_conf_init(hdata);
-   mutex_unlock(>hdmi_mutex);

hdmi_audio_init(hdata);

@@ -2029,12 +2025,8 @@ static void hdmi_commit(struct exynos_drm_display 
*display)
 {
struct hdmi_context *hdata = display_to_hdmi(display);

-   mutex_lock(>hdmi_mutex);
-   if (!hdata->powered) {
-   mutex_unlock(>hdmi_mutex);
+   if (!hdata->powered)
return;
-   }
-   mutex_unlock(>hdmi_mutex);

hdmi_conf_apply(hdata);
 }
@@ -2043,16 +2035,11 @@ static void hdmi_poweron(struct hdmi_context *hdata)
 {
struct hdmi_resources *res = >res;

-   mutex_lock(>hdmi_mutex);
-   if (hdata->powered) {
-   mutex_unlock(>hdmi_mutex);
+   if (hdata->powered)
return;
-   }

hdata->powered = true;

-   mutex_unlock(>hdmi_mutex);
-
pm_runtime_get_sync(hdata->dev);

if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
@@ -2073,10 +2060,8 @@ static void hdmi_poweroff(struct hdmi_context *hdata)
 {
struct hdmi_resources *res = >res;

-   mutex_lock(>hdmi_mutex);
if (!hdata->powered)
-   goto out;
-   mutex_unlock(>hdmi_mutex);
+   return;

/* HDMI System Disable */
hdmi_reg_writemask(hdata, HDMI_CON_0, 0, HDMI_EN);
@@ -2096,11 +2081,7 @@ static void hdmi_poweroff(struct hdmi_context *hdata)

pm_runtime_put_sync(hdata->dev);

-   mutex_lock(>hdmi_mutex);
hdata->powered = false;
-
-out:
-   mutex_unlock(>hdmi_mutex);
 }

 static void hdmi_dpms(struct exynos_drm_display *display, int mode)
@@ -2330,8 +2311,6 @@ static int hdmi_probe(struct platform_device *pdev)
hdata->display.type = EXYNOS_DISPLAY_TYPE_HDMI;
hdata->display.ops = _display_ops;

-   mutex_init(>hdmi_mutex);
-
platform_set_drvdata(pdev, hdata);

match = of_match_node(hdmi_match_types, dev->of_node);
-- 
1.9.1



[PATCH 2/7] drm/exynos/hdmi: Simplify HPD gpio handling

2015-07-09 Thread Andrzej Hajda
GPIO is tested only in hdmi_detect, so there is no reason to set it in
other places and to preserve its value in context.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3cf09bb..1d07bdf 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -186,7 +186,6 @@ struct hdmi_context {
struct drm_device   *drm_dev;
struct drm_connectorconnector;
struct drm_encoder  *encoder;
-   boolhpd;
boolpowered;
booldvi_mode;
struct mutexhdmi_mutex;
@@ -1037,10 +1036,10 @@ static enum drm_connector_status hdmi_detect(struct 
drm_connector *connector,
 {
struct hdmi_context *hdata = ctx_from_connector(connector);

-   hdata->hpd = gpio_get_value(hdata->hpd_gpio);
+   if (gpio_get_value(hdata->hpd_gpio))
+   return connector_status_connected;

-   return hdata->hpd ? connector_status_connected :
-   connector_status_disconnected;
+   return connector_status_disconnected;
 }

 static void hdmi_connector_destroy(struct drm_connector *connector)
@@ -2156,10 +2155,6 @@ static void hdmi_hotplug_work_func(struct work_struct 
*work)

hdata = container_of(work, struct hdmi_context, hotplug_work.work);

-   mutex_lock(>hdmi_mutex);
-   hdata->hpd = gpio_get_value(hdata->hpd_gpio);
-   mutex_unlock(>hdmi_mutex);
-
if (hdata->drm_dev)
drm_helper_hpd_irq_event(hdata->drm_dev);
 }
@@ -2428,8 +2423,6 @@ out_get_phy_port:
goto err_hdmiphy;
}

-   hdata->hpd = gpio_get_value(hdata->hpd_gpio);
-
INIT_DELAYED_WORK(>hotplug_work, hdmi_hotplug_work_func);

ret = devm_request_threaded_irq(dev, hdata->irq, NULL,
-- 
1.9.1



[PATCH 1/7] drm/exynos/hdmi: remove old platform data code

2015-07-09 Thread Andrzej Hajda
s5p_hdmi_platform_data were used before device tree introduction.
As HDMI driver is DT only we can drop this struct completely.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 36 +---
 1 file changed, 5 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 4a00990..3cf09bb 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -48,7 +48,6 @@
 #include "exynos_mixer.h"

 #include 
-#include 

 #define ctx_from_connector(c)  container_of(c, struct hdmi_context, connector)

@@ -2259,30 +2258,6 @@ fail:
return ret;
 }

-static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
-   (struct device *dev)
-{
-   struct device_node *np = dev->of_node;
-   struct s5p_hdmi_platform_data *pd;
-   u32 value;
-
-   pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
-   if (!pd)
-   goto err_data;
-
-   if (!of_find_property(np, "hpd-gpio", )) {
-   DRM_ERROR("no hpd gpio property found\n");
-   goto err_data;
-   }
-
-   pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
-
-   return pd;
-
-err_data:
-   return NULL;
-}
-
 static struct of_device_id hdmi_match_types[] = {
{
.compatible = "samsung,exynos5-hdmi",
@@ -2343,7 +2318,6 @@ static struct device_node 
*hdmi_legacy_phy_dt_binding(struct device *dev)
 static int hdmi_probe(struct platform_device *pdev)
 {
struct device_node *ddc_node, *phy_node;
-   struct s5p_hdmi_platform_data *pdata;
struct hdmi_driver_data *drv_data;
const struct of_device_id *match;
struct device *dev = >dev;
@@ -2354,10 +2328,6 @@ static int hdmi_probe(struct platform_device *pdev)
if (!dev->of_node)
return -ENODEV;

-   pdata = drm_hdmi_dt_parse_pdata(dev);
-   if (!pdata)
-   return -EINVAL;
-
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -2378,8 +2348,12 @@ static int hdmi_probe(struct platform_device *pdev)
hdata->phy_confs = drv_data->phy_confs;
hdata->phy_conf_count = drv_data->phy_conf_count;

-   hdata->hpd_gpio = pdata->hpd_gpio;
hdata->dev = dev;
+   hdata->hpd_gpio = of_get_named_gpio(dev->of_node, "hpd-gpio", 0);
+   if (hdata->hpd_gpio < 0) {
+   DRM_ERROR("cannot get hpd gpio property\n");
+   return hdata->hpd_gpio;
+   }

ret = hdmi_resources_init(hdata);
if (ret) {
-- 
1.9.1



[PATCH 0/7] drm/exynos/hdmi: refactoring/cleanup patches

2015-07-09 Thread Andrzej Hajda
Hi Inki, Joonyoung,

These patches removes obsolete and old structures, to simplify further
development. They should not change behavior of the driver.

The patchset is based on exynos-drm-next plus my HDMI related fixes [1].

The patchset was tested on Universal and Odroid U3.

[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/132348

Regards
Andrzej


Andrzej Hajda (7):
  drm/exynos/hdmi: remove old platform data code
  drm/exynos/hdmi: Simplify HPD gpio handling
  drm/exynos/hdmi: remove private lock code
  drm/exynos/hdmi: add driver data pointer to private context
  drm/exynos/hdmi: remove redundant configuration fields
  drm/exynos/hdmi: remove hdmi_v13_conf struct
  drm/exynos/hdmi: remove hdmi_v14_conf struct

 drivers/gpu/drm/exynos/exynos_hdmi.c | 860 ++-
 1 file changed, 245 insertions(+), 615 deletions(-)

-- 
1.9.1



[PULL] topic/drm-fixes for 4.2

2015-07-09 Thread Daniel Vetter
Hi Dave,

Non-i915 fixes I picked up in your absence: kerneldoc + 2x cc: stable. The
rockchip fix is just in here to make sure it won't get lost, I kept it
since I didn't yet see a rockchip fixes pull nor confirmation from Mark
that he pulled it into his tree.

Cheers, Daniel


The following changes since commit e24ff467e12e1560de753313976c46e84fa6306a:

  drm/crtc: Fix edid length computation (2015-07-04 00:52:34 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-fixes-2015-07-09

for you to fetch changes up to d4acc1651588835b802a2049f4f3a2adcc1af750:

  Documentation: drm: Fix tablulation in KMS properties table (2015-07-07 
22:42:58 +0200)


Daniel Kurtz (1):
  drm/rockchip: use drm_gem_mmap helpers

Graham Whaley (1):
  Documentation: drm: Fix tablulation in KMS properties table

Zhao Junwang (1):
  drm: add a check for x/y in drm_mode_setcrtc

 Documentation/DocBook/drm.tmpl  |  2 +-
 drivers/gpu/drm/drm_crtc.c  |  7 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 67 +++--
 3 files changed, 40 insertions(+), 36 deletions(-)

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


[PULL] drm-intel-fixes

2015-07-09 Thread Daniel Vetter
Hi Dave,

Pile of fixes for either 4.2 issues or cc: stable. This should fix the 2nd
kind of WARNING Linus's been seeing, please ask him to scream if that's
not the case.

Cheers, Daniel


The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

  Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-07-09

for you to fetch changes up to 52613921b31d8573a212a4b0854b390a18d9849c:

  Revert "drm/i915: Allocate context objects from stolen" (2015-07-09 09:40:16 
+0200)


Chris Wilson (1):
  drm/i915: Declare the swizzling unknown for L-shaped configurations

Daniel Vetter (2):
  drm/i915: Check crtc->active in intel_crtc_disable_planes
  drm/i915: Use crtc_state->active in primary check_plane func

Imre Deak (1):
  drm/i915/chv: fix HW readout of the port PLL fractional divider

Tvrtko Ursulin (1):
  drm/i915: Restore all GGTT VMAs on resume

Ville Syrjälä (1):
  Revert "drm/i915: Allocate context objects from stolen"

 drivers/gpu/drm/i915/i915_gem_context.c |  4 +---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 23 ---
 drivers/gpu/drm/i915/i915_gem_tiling.c  | 12 +++-
 drivers/gpu/drm/i915/intel_display.c| 12 +---
 4 files changed, 37 insertions(+), 14 deletions(-)

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


[PATCH] drm/fourcc: Add formats R8, RG88, GR88

2015-07-09 Thread Pekka Paalanen
On Thu,  9 Jul 2015 01:38:42 -0700
Chad Versace  wrote:

> The Kodi/XBMC developers want to transcode NV12 to RGB with OpenGL
> shaders, importing the two source planes through
> EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an
> R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage.
> 
> CC: Peter Frühberger 
> Cc: Rainer Hochecker 
> Cc: Benjamin Widawsky 
> Signed-off-by: Chad Versace 
> ---
> 
> I recently sent a patch series to mesa-dev that uses these new formats:
> Subject: [PATCH 0/2] egl,i965: Support importing R8 and GR88 dma_bufs as 
> textures
> Date: Thu, 9 Jul 2015 01:17:41 -0700
> 
> 
>  include/uapi/drm/drm_fourcc.h | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 2f295cd..8c5e8b9 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -34,6 +34,13 @@
>  /* color index */
>  #define DRM_FORMAT_C8fourcc_code('C', '8', ' ', ' ') /* 
> [7:0] C */
>  
> +/* 8 bpp Red */
> +#define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /* 
> [7:0] R */
> +
> +/* 16 bpp RG */
> +#define DRM_FORMAT_RG88  fourcc_code('R', 'G', '8', '8') /* 
> [15:0] R:G 8:8 little endian */
> +#define DRM_FORMAT_GR88  fourcc_code('G', 'R', '8', '8') /* 
> [15:0] G:R 8:8 little endian */
> +
>  /* 8 bpp RGB */
>  #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
> 3:3:2 */
>  #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
> 2:3:3 */

Reviewed-by: Pekka Paalanen 


Thanks,
pq


Wayland and GLES1 (Re: R200 DRM/KMS)

2015-07-09 Thread Steven Newbury
On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote:
> On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury  
> wrote:
> >
> >
> > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> >> On 09.07.2015 06:01, Steven Newbury wrote:
> >> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> >> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> >> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
> >> >>>  wrote:
> >> >>>
> >>  Would gles1 be sufficient to run a Wayland compositor, I'm
> >>  guessing probably not..?
> >> >>>
> >> >>> If you can find a Wayland compositor that is written to composite
> >> >>>  with GLES1, that's all you need from the "Wayland side". (Yeah,
> >> >>> this has nothing to do with Wayland per se.) Compositing in
> >> >>> itself without any effects is very simple, as long as you get the
> >> >>> textures up.
> >> >>>
> >> >>> Or, if you find a Wayland compositor written to use desktop
> >> >>> OpenGL for compositing and does not use features your GL driver
> >> >>> does not expose, that's good too.
> >> >>>
> >> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> >> >>
> >> > To answer my own question, it seems that is possible.  I wonder if
> >> > it works with mutter/cogl???
> >>
> >> It does.
> >>
> >> However, your problem seems rather that gnome-shell/mutter doesn't
> >> support R200 anymore.
> > Yes, that's true. I wonder if I can revert the incompatible change or 
> > better create a env variable to revert to the compatible behaviour or 
> > something? I'll need to take a look...
> 
> I'm not sure how valid this is any more:
> https://bugs.freedesktop.org/show_bug.cgi?id=51658
> 
> Basic issue is that r1xx/r2xx hw only has a limited number of render
> buffer formats while they support a lot of texture formats.  Gnome
> shell expects to be able to render to the same formats they can
> texture from.
> 
It looks like a bit of a hack, it's a pity to lose valid texture formats, but 
I've applied the patches from the bug after a little manual intervention. It's 
building now, will take some time!  
-- 
Sent from my Jolla


[PATCH] drm/fourcc: Add formats R8, RG88, GR88

2015-07-09 Thread Daniel Vetter
On Thu, Jul 09, 2015 at 04:08:08PM +0300, Pekka Paalanen wrote:
> On Thu,  9 Jul 2015 01:38:42 -0700
> Chad Versace  wrote:
> 
> > The Kodi/XBMC developers want to transcode NV12 to RGB with OpenGL
> > shaders, importing the two source planes through
> > EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an
> > R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage.
> > 
> > CC: Peter Frühberger 
> > Cc: Rainer Hochecker 
> > Cc: Benjamin Widawsky 
> > Signed-off-by: Chad Versace 
> > ---
> > 
> > I recently sent a patch series to mesa-dev that uses these new formats:
> > Subject: [PATCH 0/2] egl,i965: Support importing R8 and GR88 dma_bufs 
> > as textures
> > Date: Thu, 9 Jul 2015 01:17:41 -0700
> > 
> > 
> >  include/uapi/drm/drm_fourcc.h | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 2f295cd..8c5e8b9 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -34,6 +34,13 @@
> >  /* color index */
> >  #define DRM_FORMAT_C8  fourcc_code('C', '8', ' ', ' ') /* 
> > [7:0] C */
> >  
> > +/* 8 bpp Red */
> > +#define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* 
> > [7:0] R */
> > +
> > +/* 16 bpp RG */
> > +#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
> > [15:0] R:G 8:8 little endian */
> > +#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
> > [15:0] G:R 8:8 little endian */
> > +
> >  /* 8 bpp RGB */
> >  #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
> > 3:3:2 */
> >  #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
> > 2:3:3 */
> 
> Reviewed-by: Pekka Paalanen 

Applied to topic/drm-misc, thanks.
-Daniel
> 
> 
> Thanks,
> pq
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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


[RFCv3 0/5] enable migration of driver pages

2015-07-09 Thread Daniel Vetter
On Thu, Jul 09, 2015 at 08:55:25AM +0900, Gioh Kim wrote:
> 
> 
> 2015-07-09 오전 7:47에 Dave Airlie 이(가) 쓴 글:
> >>>
> >>>
> >>>Can the various in-kernel GPU drivers benefit from this?  If so, wiring
> >>>up one or more of those would be helpful?
> >>
> >>
> >>I'm sure that other in-kernel GPU drivers can have benefit.
> >>It must be helpful.
> >>
> >>If I was familiar with other in-kernel GPU drivers code, I tried to patch
> >>them.
> >>It's too bad.
> >
> >I'll bring dri-devel into the loop here.
> >
> >ARM GPU developers please take a look at this stuff, Laurent, Rob,
> >Eric I suppose.
> 
> I sent a patch, https://lkml.org/lkml/2015/3/24/1182, and my opinion about 
> compaction
> to ARM GPU developers via Korea ARM branch.
> I got a reply that they had no time to review it.
> 
> I hope they're interested to this patch.

i915 gpus would support 64kb and 2mb pages, but we never implemented this.
I don't think this would fit for gem based drivers since our backing
storage is shmemfs. So if we want to implement page migration (which we'd
probably want to make large pages work well) we'd need to pimp shmem to a)
hand large pages to us b) forward the migrate calls. Probably that means
we need to build our own gemfs reusing shmemfs code.

I guess something similar would apply for ttm-based drivers (which use
shmemfs just for swap-in/out but otherwise have their own page allocator,
at least sometimes).

Given all that I'd expect anything implementing migrate to just create a
gpufs thing for the backing storage, no need for more hooks. There's also
other areas for better code sharing among gpu drivers (e.g. mmu notifiers
to get off userspace pages slurped in with gup or shrinker
callbacks to get the gpu off it's memory binge). But that would all be
helper libraries in drm, not sure we need anything new from the core vm.

Also there's a bit a lack of gpu drivers from the arm world in upstream,
which is probabyl why this patch series doesn't come with a user. Might be
better to first upstream the driver before talking about additional
infrastructure that it needs.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH] drm/msm/mdp5:Add DMA pipe planes for MDP5

2015-07-09 Thread jil...@codeaurora.org
Hi Rob,

DMA pipes can be configured to work in either line mode or block mode.
In line mode, it is the same as RGB/VIG pipes except no CSC/SCALE/PP/...
support. So it can be used by any CRTC.
In block mode, it is used as a rotator with writeback(0/1) interface which
is not covered by this change.

> On Tue, Jul 7, 2015 at 5:17 PM, Jilai Wang  wrote:
>> This change is to add planes which use DMA pipes for MDP5.
>
> are DMA pipes only supporting memory->memory operation, or am I
> reading too much into the name "DMA"?  I'm wondering if we need to fix
> the possible_crtcs param that mdp5_plane_init passes to
> drm_universal_plane_init()?
>
> BR,
> -R
>
>
>> Signed-off-by: Jilai Wang 
>> ---
>>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 23 ---
>>  1 file changed, 20 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> index cbda41d..f40896d 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> @@ -316,9 +316,12 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
>> static const enum mdp5_pipe crtcs[] = {
>> SSPP_RGB0, SSPP_RGB1, SSPP_RGB2, SSPP_RGB3,
>> };
>> -   static const enum mdp5_pipe pub_planes[] = {
>> +   static const enum mdp5_pipe vig_planes[] = {
>> SSPP_VIG0, SSPP_VIG1, SSPP_VIG2, SSPP_VIG3,
>> };
>> +   static const enum mdp5_pipe dma_planes[] = {
>> +   SSPP_DMA0, SSPP_DMA1,
>> +   };
>> struct drm_device *dev = mdp5_kms->dev;
>> struct msm_drm_private *priv = dev->dev_private;
>> const struct mdp5_cfg_hw *hw_cfg;
>> @@ -361,12 +364,26 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
>> for (i = 0; i < hw_cfg->pipe_vig.count; i++) {
>> struct drm_plane *plane;
>>
>> -   plane = mdp5_plane_init(dev, pub_planes[i], false,
>> +   plane = mdp5_plane_init(dev, vig_planes[i], false,
>> hw_cfg->pipe_vig.base[i],
>> hw_cfg->pipe_vig.caps);
>> if (IS_ERR(plane)) {
>> ret = PTR_ERR(plane);
>> dev_err(dev->dev, "failed to construct %s plane:
>> %d\n",
>> -   pipe2name(pub_planes[i]), ret);
>> +   pipe2name(vig_planes[i]), ret);
>> +   goto fail;
>> +   }
>> +   }
>> +
>> +   /* DMA planes */
>> +   for (i = 0; i < hw_cfg->pipe_dma.count; i++) {
>> +   struct drm_plane *plane;
>> +
>> +   plane = mdp5_plane_init(dev, dma_planes[i], false,
>> +   hw_cfg->pipe_dma.base[i],
>> hw_cfg->pipe_dma.caps);
>> +   if (IS_ERR(plane)) {
>> +   ret = PTR_ERR(plane);
>> +   dev_err(dev->dev, "failed to construct %s plane:
>> %d\n",
>> +   pipe2name(dma_planes[i]), ret);
>> goto fail;
>> }
>> }
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>> Forum,
>> a Linux Foundation Collaborative Project
>>
>




[PATCH v2] drm/amdkfd: validate pdd where it acquired first

2015-07-09 Thread Maninder Singh
Currently pdd is validate after dereferencing it, which is
not correct, Thus validate pdd before its first use.

Signed-off-by: Maninder Singh 
---
v1: remove validation of pdd after its usage
v2: do validation at first place rather than removing

 drivers/gpu/drm/amd/amdkfd/kfd_process.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 8a1f999..9be0070 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -420,6 +420,12 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev, 
unsigned int pasid)
pqm_uninit(>pqm);

pdd = kfd_get_process_device_data(dev, p);
+
+   if (!pdd) {
+   mutex_unlock(>mutex);
+   return;
+   }
+
if (pdd->reset_wavefronts) {
dbgdev_wave_reset_wavefronts(pdd->dev, p);
pdd->reset_wavefronts = false;
@@ -431,8 +437,7 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev, 
unsigned int pasid)
 * We don't call amd_iommu_unbind_pasid() here
 * because the IOMMU called us.
 */
-   if (pdd)
-   pdd->bound = false;
+   pdd->bound = false;

mutex_unlock(>mutex);
 }
-- 
1.7.9.5



[PATCH 2/2] drm/ttm: improve uncached page deallocation.

2015-07-09 Thread Alex Deucher
On Thu, Jul 9, 2015 at 2:19 PM,   wrote:
> From: Jérôme Glisse 
>
> Calls to set_memory_wb() incure heavy TLB flush and IPI cost. To
> minimize those wait until pool grow beyond batch size before
> draining the pool.
>
> Signed-off-by: Jérôme Glisse 
> Reviewed-by: Mario Kleiner 
> Reviewed-and-Tested-by: Michel Dänzer 
> Reviewed-by: Konrad Rzeszutek Wilk 
> Cc: Thomas Hellstrom 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index af23080..624d941 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -963,13 +963,13 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
> struct device *dev)
> } else {
> pool->npages_free += count;
> list_splice(_dma->pages_list, >free_list);
> -   if (pool->npages_free > _manager->options.max_size) {
> +   /*
> +* Wait to have at at least NUM_PAGES_TO_ALLOC number of pages
> +* to free in order to minimize calls to set_memory_wb().
> +*/
> +   if (pool->npages_free >= (_manager->options.max_size +
> + NUM_PAGES_TO_ALLOC))
> npages = pool->npages_free - 
> _manager->options.max_size;
> -   /* free at least NUM_PAGES_TO_ALLOC number of pages
> -* to reduce calls to set_memory_wb */
> -   if (npages < NUM_PAGES_TO_ALLOC)
> -   npages = NUM_PAGES_TO_ALLOC;
> -   }
> }
> spin_unlock_irqrestore(>lock, irq_flags);
>
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/2] drm/ttm: fix uncached page deallocation to properly fill page pool v3.

2015-07-09 Thread Alex Deucher
On Thu, Jul 9, 2015 at 2:19 PM,   wrote:
> From: Jérôme Glisse 
>
> Current code never allowed the page pool to actualy fill in anyway.
> This fix it, so that we only start freeing page from the pool when
> we go over the pool size.
>
> Changed since v1:
>   - Move the page batching optimization to its separate patch.
>
> Changed since v2:
>   - Do not remove code part of the batching optimization with
> this patch.
>   - Better commit message.
>
> Signed-off-by: Jérôme Glisse 
> Reviewed-by: Mario Kleiner 
> Reviewed-and-Tested-by: Michel Dänzer 
> Reviewed-by: Konrad Rzeszutek Wilk 
> Cc: Thomas Hellstrom 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index 3077f15..af23080 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -963,7 +963,6 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
> struct device *dev)
> } else {
> pool->npages_free += count;
> list_splice(_dma->pages_list, >free_list);
> -   npages = count;
> if (pool->npages_free > _manager->options.max_size) {
> npages = pool->npages_free - 
> _manager->options.max_size;
> /* free at least NUM_PAGES_TO_ALLOC number of pages
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/2] drm/ttm: improve uncached page deallocation.

2015-07-09 Thread j.gli...@gmail.com
From: Jérôme Glisse 

Calls to set_memory_wb() incure heavy TLB flush and IPI cost. To
minimize those wait until pool grow beyond batch size before
draining the pool.

Signed-off-by: Jérôme Glisse 
Reviewed-by: Mario Kleiner 
Reviewed-and-Tested-by: Michel Dänzer 
Reviewed-by: Konrad Rzeszutek Wilk 
Cc: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index af23080..624d941 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -963,13 +963,13 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
} else {
pool->npages_free += count;
list_splice(_dma->pages_list, >free_list);
-   if (pool->npages_free > _manager->options.max_size) {
+   /*
+* Wait to have at at least NUM_PAGES_TO_ALLOC number of pages
+* to free in order to minimize calls to set_memory_wb().
+*/
+   if (pool->npages_free >= (_manager->options.max_size +
+ NUM_PAGES_TO_ALLOC))
npages = pool->npages_free - _manager->options.max_size;
-   /* free at least NUM_PAGES_TO_ALLOC number of pages
-* to reduce calls to set_memory_wb */
-   if (npages < NUM_PAGES_TO_ALLOC)
-   npages = NUM_PAGES_TO_ALLOC;
-   }
}
spin_unlock_irqrestore(>lock, irq_flags);

-- 
1.8.3.1



[PATCH 1/2] drm/ttm: fix uncached page deallocation to properly fill page pool v3.

2015-07-09 Thread j.gli...@gmail.com
From: Jérôme Glisse 

Current code never allowed the page pool to actualy fill in anyway.
This fix it, so that we only start freeing page from the pool when
we go over the pool size.

Changed since v1:
  - Move the page batching optimization to its separate patch.

Changed since v2:
  - Do not remove code part of the batching optimization with
this patch.
  - Better commit message.

Signed-off-by: Jérôme Glisse 
Reviewed-by: Mario Kleiner 
Reviewed-and-Tested-by: Michel Dänzer 
Reviewed-by: Konrad Rzeszutek Wilk 
Cc: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 3077f15..af23080 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -963,7 +963,6 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct 
device *dev)
} else {
pool->npages_free += count;
list_splice(_dma->pages_list, >free_list);
-   npages = count;
if (pool->npages_free > _manager->options.max_size) {
npages = pool->npages_free - _manager->options.max_size;
/* free at least NUM_PAGES_TO_ALLOC number of pages
-- 
1.8.3.1



[PULL] drm-amdkfd-fixes

2015-07-09 Thread Oded Gabbay
Hi Dave,

A single fix so far for 4.2:
- checking a pointer is not null before using it

Thanks,

Oded

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

  Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-fixes-2015-07-09

for you to fetch changes up to a0f67441b06525a1e5fd713ba0d75af4e5d6b198:

  drm/amdkfd: validate pdd where it acquired first (2015-07-09 13:27:52 +0300)


Maninder Singh (1):
  drm/amdkfd: validate pdd where it acquired first

 drivers/gpu/drm/amd/amdkfd/kfd_process.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)


[RFC PATCH] drm/fb: drop panic handling

2015-07-09 Thread Dave Airlie
From: Dave Airlie 

This really doesn't seem to have much chance of working anymore,

esp for irq context, qxl at least tries to talk to the hw,
and waits for irqs, and fails.

with runtime pm and other stuff I think we should just
bail on this for now.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_fb_helper.c | 26 --
 1 file changed, 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cac4229..eaf652b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -429,24 +429,6 @@ static bool drm_fb_helper_force_kernel_mode(void)
return error;
 }

-static int drm_fb_helper_panic(struct notifier_block *n, unsigned long ununsed,
-   void *panic_str)
-{
-   /*
-* It's a waste of time and effort to switch back to text console
-* if the kernel should reboot before panic messages can be seen.
-*/
-   if (panic_timeout < 0)
-   return 0;
-
-   pr_err("panic occurred, switching back to text console\n");
-   return drm_fb_helper_force_kernel_mode();
-}
-
-static struct notifier_block paniced = {
-   .notifier_call = drm_fb_helper_panic,
-};
-
 static bool drm_fb_helper_is_bound(struct drm_fb_helper *fb_helper)
 {
struct drm_device *dev = fb_helper->dev;
@@ -672,9 +654,6 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
if (!list_empty(_helper->kernel_fb_list)) {
list_del(_helper->kernel_fb_list);
if (list_empty(_fb_helper_list)) {
-   pr_info("drm: unregistered panic notifier\n");
-   atomic_notifier_chain_unregister(_notifier_list,
-);
unregister_sysrq_key('v', 
_drm_fb_helper_restore_op);
}
}
@@ -1109,12 +1088,7 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
dev_info(fb_helper->dev->dev, "fb%d: %s frame buffer device\n",
info->node, info->fix.id);

-   /* Switch back to kernel console on panic */
-   /* multi card linked list maybe */
if (list_empty(_fb_helper_list)) {
-   dev_info(fb_helper->dev->dev, "registered panic notifier\n");
-   atomic_notifier_chain_register(_notifier_list,
-  );
register_sysrq_key('v', _drm_fb_helper_restore_op);
}

-- 
2.4.3



[PATCH v2] drm/amdkfd: validate pdd where it acquired first

2015-07-09 Thread Oded Gabbay
On Thu, Jul 9, 2015 at 12:11 PM, Maninder Singh  
wrote:
> Currently pdd is validate after dereferencing it, which is
> not correct, Thus validate pdd before its first use.
>
> Signed-off-by: Maninder Singh 
> ---
> v1: remove validation of pdd after its usage
> v2: do validation at first place rather than removing
>
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> index 8a1f999..9be0070 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> @@ -420,6 +420,12 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev, 
> unsigned int pasid)
> pqm_uninit(>pqm);
>
> pdd = kfd_get_process_device_data(dev, p);
> +
> +   if (!pdd) {
> +   mutex_unlock(>mutex);
> +   return;
> +   }
> +
> if (pdd->reset_wavefronts) {
> dbgdev_wave_reset_wavefronts(pdd->dev, p);
> pdd->reset_wavefronts = false;
> @@ -431,8 +437,7 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev, 
> unsigned int pasid)
>  * We don't call amd_iommu_unbind_pasid() here
>  * because the IOMMU called us.
>  */
> -   if (pdd)
> -   pdd->bound = false;
> +   pdd->bound = false;
>
> mutex_unlock(>mutex);
>  }
> --
> 1.7.9.5
>
Thanks!
Applied to my -fixes tree.

Oded


[Nouveau] CUDA fixed VA allocations and sparse mappings

2015-07-09 Thread Oded Gabbay
On Tue, Jul 7, 2015 at 8:27 PM, Jerome Glisse  wrote:
> On Tue, Jul 07, 2015 at 11:29:38AM -0400, Ilia Mirkin wrote:
>> On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew  wrote:
>> > Hello,
>> >
>> > I am currently looking into ways to support fixed virtual address 
>> > allocations
>> > and sparse mappings in nouveau, as a step towards supporting CUDA.
>> >
>> > CUDA requires that the GPU virtual address for a given buffer match the
>> > CPU virtual address.  Therefore, when mapping a CUDA buffer, we have to 
>> > have
>> > a way of specifying a particular virtual address to map to (we would ask 
>> > that
>> > the CPU virtual address be used).  Currently, as I understand it, the 
>> > allocator
>> > implemented in nvkm/core/mm.c, used to provision virtual addresses, doesn't
>> > allow for this (but it's very easy to modify the allocator slightly to 
>> > allow
>> > for this, which I have done locally in my experiments).
>> >
>> > In addition, the CUDA use case typically involves allocating a big chunk of
>> > address space ahead of time as a way to reserve that chunk for future CUDA
>> > use.  It then maps individual buffers into that address space as needed.
>> > Currently, the virtual address allocation is done during buffer mapping, so
>> > in order to support these sparse mappings, it seems to me that the virtual
>> > address allocation and buffer mapping need to be decoupled into separate
>> > operations.
>> >
>> > My current strawman proposal for supporting this is to introduce two new 
>> > ioctls
>> > DRM_IOCTL_NOUVEAU_AS_ALLOC and DRM_IOCTL_NOUVEAU_AS_FREE, that look roughly
>> > like this:
>> >
>> > #define NOUVEAU_AS_ALLOC_FLAGS_FIXED_OFFSET 0x1
>> > struct drm_nouveau_as_alloc {
>> > uint64_t pages; /* in, pages */
>> > uint32_t page_size; /* in, bytes */
>> > uint32_t flags; /* in */
>> > uint64_t offset;/* in/out, byte address */
>> > };
>> >
>> > struct drm_nouveau_as_free {
>> > uint64_t offset;/* in, byte address */
>> > };
>> >
>> > These ioctls just call into the allocator to allocate a range of addresses,
>> > resulting in a struct nvkm_vma that tracks that allocation (or releases the
>> > struct nvkm_vma back into the virtual address pool in the case of the free
>> > ioctl).  If NOUVEAU_AS_ALLOC_FLAGS_FIXED_OFFSET is set, offset specifies 
>> > the
>> > requested virtual address.  Otherwise, an arbitrary address will be
>> > allocated.
>>
>> Well, this can't just be an address space. You still need bo's, if
>> this is to work with nouveau -- it has to know when to swap things in
>> and out, when they're used, etc. (and/or move between VRAM and GART
>> and system/swap). I suspect that your target here are the GK20A and
>> GM20B chips which don't have dedicated VRAM, but the ioctl's need to
>> work for everything.
>>
>> Would it be sufficient to extend NOUVEAU_GEM_NEW or create a
>> NOUVEAU_GEM_NEW_FIXED or something? IOW, why do have to separate the
>> concept of a GEM object and a VM allocation?
>
> Well maybe something like i did for radeon. With radeon you have 2 set of
> ioctl. One to create/delete bo (GEM stuff) and one to associate a virtual
> address with a bo. I wanted to let the userspace decide on virtual address
> of buffer precisely for the same reason CUDA do it ie to allow to map some
> buffer at same address in GPU address space as in CPU address space. So far
> we never really took advantage of that on radeon side.
>
> Also on radeon you can map same bo at different virtual address in same
> process (you will need different file descriptor for each mapping and you
> can only submit command stream using mapping valid for the file descriptor).
> Thought this is mostly usefull when sharing same bo accross different
> process.
>
> I think my radeon virtual address ioclt are nice design but other might
> disagree. If you want to look at the code :
>
>   drivers/gpu/drm/radeon/radeon_vm.c
>   drivers/gpu/drm/radeon/radeon_gem.c
>
> Grep for _va (virtual address per bo) or _vm (virtual address manager per
> file descriptor) function name and structure name.
>
> On the command stream and bo eviction side everything is as usual on radeon.
> So a bo can be evicted btw 2 command stream to make room for another one.
> Either its mapping is invalidated or updated to point to system memory. So
> most of the logic for everything else remain the same (just need to update
> the multiple virtual address space).
>
>
>>
>> >
>> > In addition to this, a way to map/unmap buffers is needed.  Ordinarily, one
>> > would just use DRM_IOCTL_PRIME_FD_TO_HANDLE to import and map a dmabuf into
>> > gem.  However, this ioctl will try to grab the virtual address range for 
>> > this
>> > buffer, which will fail in the CUDA case since the virtual address range
>> > has been reserved ahead of time.  So we perhaps introduce a set of ioctls
>> > to map/unmap buffers on top of an already existing virtual address 
>> > allocation.
>>
>> My suggestion above 

[PATCH 12/12] drm/amd: remove amd gnb bus default runtime pm ops

2015-07-09 Thread Alex Deucher
From: Maruthi Srinivas Bayyavarapu 

with the default gnb bus runtime pm ops, alsa pcm device attached to
it is unable to get runtime suspended/resumed.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
---
 drivers/gpu/drm/amd/bus/amd_gnb_bus.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/bus/amd_gnb_bus.c 
b/drivers/gpu/drm/amd/bus/amd_gnb_bus.c
index 071b16c..13d5506 100644
--- a/drivers/gpu/drm/amd/bus/amd_gnb_bus.c
+++ b/drivers/gpu/drm/amd/bus/amd_gnb_bus.c
@@ -142,11 +142,6 @@ static const struct dev_pm_ops amd_gnb_bus_device_pm_ops = 
{
.thaw = amd_gnb_bus_device_pm_thaw,
.poweroff = amd_gnb_bus_device_pm_poweroff,
.restore = amd_gnb_bus_device_pm_restore,
-   SET_RUNTIME_PM_OPS(
-   pm_generic_runtime_suspend,
-   pm_generic_runtime_resume,
-   pm_runtime_idle
-   )
 };

 /* The bus should only be registered by the first amd_gnb, but further
-- 
1.8.3.1



[PATCH 11/12] drm/amd: add ACP suspend/resume functionality

2015-07-09 Thread Alex Deucher
From: Maruthi Srinivas Bayyavarapu 

ACP IP can be powered on and off during system wide suspend/resume
transition. AMD ASoC PCM device will use this module during
system suspend/resume and PCM device's runtime pm.

Also, updated code comments.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Reviewed-by: Murali Krishna Vemuri 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/acp/acp_hw.c  | 220 +++---
 drivers/gpu/drm/amd/acp/acp_hw.h  |  19 +++
 drivers/gpu/drm/amd/acp/include/amd_acp.h |  18 +++
 3 files changed, 204 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/amd/acp/acp_hw.c b/drivers/gpu/drm/amd/acp/acp_hw.c
index 0a07774..94b2c56 100644
--- a/drivers/gpu/drm/amd/acp/acp_hw.c
+++ b/drivers/gpu/drm/amd/acp/acp_hw.c
@@ -40,17 +40,16 @@
 #include 
 #include 

-#define VISLANDS30_IV_SRCID_ACP 0x00a2
-
 #include "acp_gfx_if.h"
 #include "acp_hw.h"

 #include "acp_2_2_d.h"
 #include "acp_2_2_sh_mask.h"

+#define VISLANDS30_IV_SRCID_ACP 0x00a2
+
 /* Configure a given dma channel parameters - enable/disble,
  * number of descriptors, priority */
-
 static void config_acp_dma_channel(struct amd_acp_device *acp_dev, u8 ch_num,
   u16 dscr_strt_idx, u16 num_dscrs,
   enum acp_dma_priority_level priority_level)
@@ -58,38 +57,30 @@ static void config_acp_dma_channel(struct amd_acp_device 
*acp_dev, u8 ch_num,
u32 dma_ctrl;
struct amd_acp_private *acp_prv = (struct amd_acp_private *)acp_dev;

-   /* read the dma control register and disable the channel run field */
+   /* disable the channel run field */
dma_ctrl = cgs_read_register(acp_prv->cgs_device,
 mmACP_DMA_CNTL_0 + ch_num);
-   /* clear the dma channel control bits */
dma_ctrl &= ~ACP_DMA_CNTL_0__DMAChRun_MASK;
-
cgs_write_register(acp_prv->cgs_device, (mmACP_DMA_CNTL_0 + ch_num),
   dma_ctrl);

-   /* there is no transfer happening on this channel so
-* program DMAChDscrStrIdx to the index number of the first descriptor
-* to be processed.
-*/
+   /* program a DMA channel with first descriptor to be processed. */
cgs_write_register(acp_prv->cgs_device,
   (mmACP_DMA_DSCR_STRT_IDX_0 + ch_num),
   (ACP_DMA_DSCR_STRT_IDX_0__DMAChDscrStrtIdx_MASK &
dscr_strt_idx));

-   /* program DMAChDscrDscrCnt to the number of descriptors to be
-* processed in the transfer
-*/
+   /* program a DMA channel with the number of descriptors to be
+* processed in the transfer */
cgs_write_register(acp_prv->cgs_device,
   (mmACP_DMA_DSCR_CNT_0 + ch_num),
   (ACP_DMA_DSCR_CNT_0__DMAChDscrCnt_MASK & num_dscrs));

-   /* set DMAChPrioLvl according to the priority */
+   /* set DMA channel priority */
cgs_write_register(acp_prv->cgs_device, (mmACP_DMA_PRIO_0 + ch_num),
   priority_level);
 }

-
-
 /* Initialize the dma descriptors location in SRAM and page size */
 static void acp_dma_descr_init(struct amd_acp_private *acp_prv)
 {
@@ -143,7 +134,9 @@ static void config_dma_descriptor_in_sram(struct 
amd_acp_device *acp_dev,
   descr_info->size_xfer_dir.val);
 }

-/* Initialize the DMA descriptor information */
+/* Initialize the DMA descriptor information for transfer between
+ * system memory <-> ACP SRAM
+ */
 static void set_acp_sysmem_dma_descriptors(struct amd_acp_device *acp_dev,
   u32 size, int direction,
   u32 pte_offset)
@@ -215,7 +208,9 @@ static void set_acp_sysmem_dma_descriptors(struct 
amd_acp_device *acp_dev,
}
 }

-/* Initialize the i2s dma descriptors in SRAM */
+/* Initialize the DMA descriptor information for transfer between
+ * ACP SRAM <-> I2S
+ */
 static void set_acp_to_i2s_dma_descriptors(struct amd_acp_device *acp_dev,
   u32 size, int direction)
 {
@@ -226,9 +221,6 @@ static void set_acp_to_i2s_dma_descriptors(struct 
amd_acp_device *acp_dev,

num_descr = 2;

-   /* Let I2s Know the direction of transfer and source/destination
-*  of data
-*/
dmadscr[0].size_xfer_dir.val = (u32) 0x0;
if (direction == STREAM_PLAYBACK) {
dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH13;
@@ -304,7 +296,7 @@ static u16 get_dscr_idx(struct amd_acp_device *acp_dev, int 
direction)

 }

-/* Create page table entries in ACP SRAM for the allocated memory */
+/* Create page table entries in ACP SRAM for the allocated memory */
 static void acp_pte_config(struct amd_acp_device *acp_dev, struct page *pg,
   u16 num_of_pages, 

[PATCH 10/12] drm/amd: modify ACP DMA buffer position update logic

2015-07-09 Thread Alex Deucher
From: Maruthi Srinivas Bayyavarapu 

The following are design changes for ACP DMA :
1. For capture usecase, DMA Interrupt on Complete is added for
   ACP_TO_SYSRAM_CH_NUM DMA channel
2. For playback usecase, the destination for DMA descriptors is
   reversed.
3. Finally, modified DMA buffer position update logic as per above
   changes.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Reviewed-by: Murali Krishna Vemuri 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/acp/acp_hw.c | 142 ++-
 drivers/gpu/drm/amd/acp/acp_hw.h |  19 ++
 2 files changed, 86 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/amd/acp/acp_hw.c b/drivers/gpu/drm/amd/acp/acp_hw.c
index 069fea7..0a07774 100644
--- a/drivers/gpu/drm/amd/acp/acp_hw.c
+++ b/drivers/gpu/drm/amd/acp/acp_hw.c
@@ -40,7 +40,7 @@
 #include 
 #include 

-#define VISLANDS30_IV_SRCID_ACP0x00a2  // 
162
+#define VISLANDS30_IV_SRCID_ACP 0x00a2

 #include "acp_gfx_if.h"
 #include "acp_hw.h"
@@ -91,10 +91,9 @@ static void config_acp_dma_channel(struct amd_acp_device 
*acp_dev, u8 ch_num,


 /* Initialize the dma descriptors location in SRAM and page size */
-static void acp_dma_descr_init(struct amd_acp_device *acp_dev)
+static void acp_dma_descr_init(struct amd_acp_private *acp_prv)
 {
u32 sram_pte_offset = 0;
-   struct amd_acp_private *acp_prv = (struct amd_acp_private *)acp_dev;

/* SRAM starts at 0x0400. From that offset one page (4KB) left for
 * filling DMA descriptors.sram_pte_offset = 0x04001000 , used for
@@ -146,10 +145,11 @@ static void config_dma_descriptor_in_sram(struct 
amd_acp_device *acp_dev,

 /* Initialize the DMA descriptor information */
 static void set_acp_sysmem_dma_descriptors(struct amd_acp_device *acp_dev,
-  u32 size, int direction, u32 
pte_offset)
+  u32 size, int direction,
+  u32 pte_offset)
 {
-   u16 dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
u16 num_descr;
+   u16 dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
acp_dma_dscr_transfer_t dmadscr[2];

num_descr = 2;
@@ -157,11 +157,13 @@ static void set_acp_sysmem_dma_descriptors(struct 
amd_acp_device *acp_dev,
dmadscr[0].size_xfer_dir.val = (u32) 0x0;
if (direction == STREAM_PLAYBACK) {
dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
-   dmadscr[0].dest = ACP_SHARED_RAM_BANK_38_ADDRESS;
+   dmadscr[0].dest = ACP_SHARED_RAM_BANK_38_ADDRESS + (size / 2);
dmadscr[0].src = ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS +
(pte_offset * PAGE_SIZE_4K);
dmadscr[0].size_xfer_dir.s.trans_direction =
ACP_DMA_ATTRIBUTES_DAGB_ONION_TO_SHAREDMEM;
+   dmadscr[0].size_xfer_dir.s.size = (size / 2);
+   dmadscr[0].size_xfer_dir.s.ioc = (u32) 0x0;
} else if (direction == STREAM_CAPTURE) {
dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH14;
dmadscr[0].src = ACP_SHARED_RAM_BANK_47_ADDRESS;
@@ -169,31 +171,31 @@ static void set_acp_sysmem_dma_descriptors(struct 
amd_acp_device *acp_dev,
(pte_offset * PAGE_SIZE_4K);
dmadscr[0].size_xfer_dir.s.trans_direction =
ACP_DMA_ATTRIBUTES_SHAREDMEM_TO_DAGB_ONION;
+   dmadscr[0].size_xfer_dir.s.size = size / 2;
+   dmadscr[0].size_xfer_dir.s.ioc = (u32) 0x1;
}

-   /* allot 1 period size per descriptor = total size (size) /2
-* => params_buffer_bytes(params)/params_periods(params);
-*/
-   dmadscr[0].size_xfer_dir.s.size = size / 2;
-
-   dmadscr[0].size_xfer_dir.s.ioc = (u32) 0x0;
-
config_dma_descriptor_in_sram(acp_dev, dma_dscr_idx, [0]);

dmadscr[1].size_xfer_dir.val = (u32) 0x0;
-   dmadscr[1].dest = dmadscr[0].dest + dmadscr[0].size_xfer_dir.s.size;
-   dmadscr[1].src = dmadscr[0].src + dmadscr[0].size_xfer_dir.s.size;
-   dmadscr[1].size_xfer_dir.s.size = dmadscr[0].size_xfer_dir.s.size;
-   dmadscr[1].size_xfer_dir.s.ioc = (u32) 0x0;
-
if (direction == STREAM_PLAYBACK) {
dma_dscr_idx = PLAYBACK_END_DMA_DESCR_CH12;
+   dmadscr[1].dest = ACP_SHARED_RAM_BANK_38_ADDRESS;
+   dmadscr[1].src = ACP_INTERNAL_APERTURE_WINDOW_0_ADDRESS +
+   (pte_offset * PAGE_SIZE_4K) + (size / 2);
dmadscr[1].size_xfer_dir.s.trans_direction =
ACP_DMA_ATTRIBUTES_DAGB_ONION_TO_SHAREDMEM;
+   dmadscr[1].size_xfer_dir.s.size = (size / 2);
+   dmadscr[1].size_xfer_dir.s.ioc = (u32) 0x0;
} else if (direction == STREAM_CAPTURE) {
dma_dscr_idx = CAPTURE_END_DMA_DESCR_CH14;

[PATCH 09/12] drm/amd: add ACP driver support (v4)

2015-07-09 Thread Alex Deucher
From: Maruthi Bayyavarapu 

This adds the ACP (Audio CoProcessor) IP driver and wires
it up to the amdgpu driver.  The ACP block provides the DMA
engine and bus for the i2s codec which is supported by an
alsa driver.  This is required for audio on APUs that
utilize an i2s codec.

v2: integrate i2s/az check patch
v3: s/amd_acp/amdgpu_acp/
v4: update copyright notice

Reviewed-by: Jammy Zhou 
Reviewed-by: Maruthi Bayyavarapu 
Signed-off-by: Maruthi Bayyavarapu 
Signed-off-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/amd/acp/Kconfig  |   9 +
 drivers/gpu/drm/amd/acp/Makefile |   9 +
 drivers/gpu/drm/amd/acp/acp_hw.c | 964 +++
 drivers/gpu/drm/amd/acp/acp_hw.h |  99 +++
 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h |  49 ++
 drivers/gpu/drm/amd/acp/include/amd_acp.h| 196 ++
 drivers/gpu/drm/amd/amdgpu/Makefile  |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  11 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c  | 201 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h  |  40 ++
 drivers/gpu/drm/amd/amdgpu/vi.c  |  12 +
 drivers/gpu/drm/amd/include/amd_shared.h |   1 +
 13 files changed, 1606 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/amd/acp/Kconfig
 create mode 100644 drivers/gpu/drm/amd/acp/Makefile
 create mode 100644 drivers/gpu/drm/amd/acp/acp_hw.c
 create mode 100644 drivers/gpu/drm/amd/acp/acp_hw.h
 create mode 100644 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h
 create mode 100644 drivers/gpu/drm/amd/acp/include/amd_acp.h
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8c3cc9e..88daeee 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -144,6 +144,8 @@ config DRM_AMDGPU

 source "drivers/gpu/drm/amd/amdgpu/Kconfig"

+source "drivers/gpu/drm/amd/acp/Kconfig"
+
 source "drivers/gpu/drm/nouveau/Kconfig"

 config DRM_I810
diff --git a/drivers/gpu/drm/amd/acp/Kconfig b/drivers/gpu/drm/amd/acp/Kconfig
new file mode 100644
index 000..11c5faf
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/Kconfig
@@ -0,0 +1,9 @@
+menu "ACP Configuration"
+
+config DRM_AMD_ACP
+   bool "Enable ACP IP support"
+   default y
+   help
+   Choose this option to enable ACP IP support for AMD SOCs.
+
+endmenu
diff --git a/drivers/gpu/drm/amd/acp/Makefile b/drivers/gpu/drm/amd/acp/Makefile
new file mode 100644
index 000..c8c3303
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the ACP, which is a sub-component
+# of AMDSOC/AMDGPU drm driver.
+# It provides the HW control for ACP related functionalities.
+
+ccflags-y += -Idrivers/gpu/drm/amd/include/asic_reg/acp
+subdir-ccflags-y += -I$(AMDACPPATH)/ -I$(AMDACPPATH)/include
+
+AMD_ACP_FILES := $(AMDACPPATH)/acp_hw.o
diff --git a/drivers/gpu/drm/amd/acp/acp_hw.c b/drivers/gpu/drm/amd/acp/acp_hw.c
new file mode 100644
index 000..069fea7
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/acp_hw.c
@@ -0,0 +1,964 @@
+/*
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * NOTE:
+ * Certain pieces were reused from Synopsis I2S IP related code,
+ * which otherwise can also be found at:
+ * sound/soc/dwc/designware_i2s.c
+ *
+ * Copyright notice as appears in the above file:
+ *
+ * Copyright (C) 2010 ST Microelectronics
+ * Rajeev Kumar 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define VISLANDS30_IV_SRCID_ACP0x00a2 

[PATCH 08/12] drm/amd: add ACP 2.x register headers

2015-07-09 Thread Alex Deucher
From: Chunming Zhou 

These are register headers for the ACP (Audio CoProcessor)
block on the GPU.

Reviewed-by: Maruthi Bayyavarapu 
Acked-by: Jammy Zhou 
Signed-off-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 .../gpu/drm/amd/include/asic_reg/acp/acp_2_1_d.h   |  437 
 .../drm/amd/include/asic_reg/acp/acp_2_1_enum.h| 1198 ++
 .../drm/amd/include/asic_reg/acp/acp_2_1_sh_mask.h | 1568 +
 .../gpu/drm/amd/include/asic_reg/acp/acp_2_2_d.h   |  609 ++
 .../drm/amd/include/asic_reg/acp/acp_2_2_enum.h| 1068 +
 .../drm/amd/include/asic_reg/acp/acp_2_2_sh_mask.h | 2292 
 .../gpu/drm/amd/include/asic_reg/acp/acp_2_3_d.h   |  582 +
 .../drm/amd/include/asic_reg/acp/acp_2_3_enum.h| 1079 +
 .../drm/amd/include/asic_reg/acp/acp_2_3_sh_mask.h | 2192 +++
 9 files changed, 11025 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_1_d.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_1_enum.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_1_sh_mask.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_2_d.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_2_enum.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_2_sh_mask.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_3_d.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_3_enum.h
 create mode 100644 drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_3_sh_mask.h

diff --git a/drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_1_d.h 
b/drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_1_d.h
new file mode 100644
index 000..bedbe6a
--- /dev/null
+++ b/drivers/gpu/drm/amd/include/asic_reg/acp/acp_2_1_d.h
@@ -0,0 +1,437 @@
+/*
+ * ACP_2_1 Register documentation
+ *
+ * Copyright (C) 2014  Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
LIABILITY, WHETHER IN
+ * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef ACP_2_1_D_H
+#define ACP_2_1_D_H
+
+#define mmACP_DMA_CNTL_0   
 0x5000
+#define mmACP_DMA_CNTL_1   
 0x5001
+#define mmACP_DMA_CNTL_2   
 0x5002
+#define mmACP_DMA_CNTL_3   
 0x5003
+#define mmACP_DMA_CNTL_4   
 0x5004
+#define mmACP_DMA_CNTL_5   
 0x5005
+#define mmACP_DMA_CNTL_6   
 0x5006
+#define mmACP_DMA_CNTL_7   
 0x5007
+#define mmACP_DMA_CNTL_8   
 0x5008
+#define mmACP_DMA_CNTL_9   
 0x5009
+#define mmACP_DMA_CNTL_10  
 0x500a
+#define mmACP_DMA_CNTL_11  
 0x500b
+#define mmACP_DMA_CNTL_12  
 0x500c
+#define mmACP_DMA_CNTL_13  
 0x500d
+#define mmACP_DMA_CNTL_14  
 0x500e
+#define mmACP_DMA_CNTL_15  
 0x500f
+#define mmACP_DMA_DSCR_STRT_IDX_0  
 0x5010
+#define mmACP_DMA_DSCR_STRT_IDX_1  
 0x5011
+#define mmACP_DMA_DSCR_STRT_IDX_2  
 0x5012
+#define mmACP_DMA_DSCR_STRT_IDX_3  
 0x5013
+#define mmACP_DMA_DSCR_STRT_IDX_4  
 0x5014
+#define mmACP_DMA_DSCR_STRT_IDX_5

[PATCH 07/12] drm/amdgpu: implement cgs gpu memory callbacks

2015-07-09 Thread Alex Deucher
From: Chunming Zhou 

This implements the cgs interface for allocating
GPU memory.

Reviewed-by: Jammy Zhou 
Signed-off-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 238 ++--
 1 file changed, 226 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index c1ee39e..ac0f124 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -21,7 +21,11 @@
  *
  *
  */
+#include 
+#include 
 #include 
+#include 
+#include 
 #include "amdgpu.h"
 #include "cgs_linux.h"
 #include "atom.h"
@@ -39,6 +43,30 @@ static int amdgpu_cgs_gpu_mem_info(void *cgs_device, enum 
cgs_gpu_mem_type type,
   uint64_t *mc_start, uint64_t *mc_size,
   uint64_t *mem_size)
 {
+   CGS_FUNC_ADEV;
+   switch(type) {
+   case CGS_GPU_MEM_TYPE__VISIBLE_CONTIG_FB:
+   case CGS_GPU_MEM_TYPE__VISIBLE_FB:
+   *mc_start = 0;
+   *mc_size = adev->mc.visible_vram_size;
+   *mem_size = adev->mc.visible_vram_size - adev->vram_pin_size;
+   break;
+   case CGS_GPU_MEM_TYPE__INVISIBLE_CONTIG_FB:
+   case CGS_GPU_MEM_TYPE__INVISIBLE_FB:
+   *mc_start = adev->mc.visible_vram_size;
+   *mc_size = adev->mc.real_vram_size - adev->mc.visible_vram_size;
+   *mem_size = *mc_size;
+   break;
+   case CGS_GPU_MEM_TYPE__GART_CACHEABLE:
+   case CGS_GPU_MEM_TYPE__GART_WRITECOMBINE:
+   *mc_start = adev->mc.gtt_start;
+   *mc_size = adev->mc.gtt_size;
+   *mem_size = adev->mc.gtt_size - adev->gart_pin_size;
+   break;
+   default:
+   return -EINVAL;
+   }
+
return 0;
 }

@@ -47,11 +75,43 @@ static int amdgpu_cgs_gmap_kmem(void *cgs_device, void 
*kmem,
uint64_t min_offset, uint64_t max_offset,
cgs_handle_t *kmem_handle, uint64_t *mcaddr)
 {
-   return 0;
+   CGS_FUNC_ADEV;
+   int ret;
+   struct amdgpu_bo *bo;
+   struct page *kmem_page = vmalloc_to_page(kmem);
+   int npages = ALIGN(size, PAGE_SIZE) >> PAGE_SHIFT;
+
+   struct sg_table *sg = drm_prime_pages_to_sg(_page, npages);
+   ret = amdgpu_bo_create(adev, size, PAGE_SIZE, false,
+  AMDGPU_GEM_DOMAIN_GTT, 0, sg, );
+   if (ret)
+   return ret;
+   ret = amdgpu_bo_reserve(bo, false);
+   if (unlikely(ret != 0))
+   return ret;
+
+   /* pin buffer into GTT */
+   ret = amdgpu_bo_pin_restricted(bo, AMDGPU_GEM_DOMAIN_GTT,
+  min_offset, max_offset, mcaddr);
+   amdgpu_bo_unreserve(bo);
+
+   *kmem_handle = (cgs_handle_t)bo;
+   return ret;
 }

 static int amdgpu_cgs_gunmap_kmem(void *cgs_device, cgs_handle_t kmem_handle)
 {
+   struct amdgpu_bo *obj = (struct amdgpu_bo *)kmem_handle;
+
+   if (obj) {
+   int r = amdgpu_bo_reserve(obj, false);
+   if (likely(r == 0)) {
+   amdgpu_bo_unpin(obj);
+   amdgpu_bo_unreserve(obj);
+   }
+   amdgpu_bo_unref();
+
+   }
return 0;
 }

@@ -61,46 +121,200 @@ static int amdgpu_cgs_alloc_gpu_mem(void *cgs_device,
uint64_t min_offset, uint64_t max_offset,
cgs_handle_t *handle)
 {
-   return 0;
+   CGS_FUNC_ADEV;
+   uint16_t flags = 0;
+   int ret = 0;
+   uint32_t domain = 0;
+   struct amdgpu_bo *obj;
+   struct ttm_placement placement;
+   struct ttm_place place;
+
+   if (min_offset > max_offset) {
+   BUG_ON(1);
+   return -EINVAL;
+   }
+
+   /* fail if the alignment is not a power of 2 */
+   if (((align != 1) && (align & (align - 1)))
+   || size == 0 || align == 0)
+   return -EINVAL;
+
+
+   switch(type) {
+   case CGS_GPU_MEM_TYPE__VISIBLE_CONTIG_FB:
+   case CGS_GPU_MEM_TYPE__VISIBLE_FB:
+   flags = AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
+   domain = AMDGPU_GEM_DOMAIN_VRAM;
+   if (max_offset > adev->mc.real_vram_size)
+   return -EINVAL;
+   place.fpfn = min_offset >> PAGE_SHIFT;
+   place.lpfn = max_offset >> PAGE_SHIFT;
+   place.flags = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
+   TTM_PL_FLAG_VRAM;
+   break;
+   case CGS_GPU_MEM_TYPE__INVISIBLE_CONTIG_FB:
+   case CGS_GPU_MEM_TYPE__INVISIBLE_FB:
+   flags = AMDGPU_GEM_CREATE_NO_CPU_ACCESS;
+   domain = AMDGPU_GEM_DOMAIN_VRAM;
+   if (adev->mc.visible_vram_size < adev->mc.real_vram_size) 

[PATCH 06/12] drm/amdgpu: add atom interfaces for CGS

2015-07-09 Thread Alex Deucher
From: Chunming Zhou 

This implements the interface for atombios command
and data table access.

Reviewed-by: Jammy Zhou 
Signed-off-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index 93fbf35..c1ee39e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -24,6 +24,7 @@
 #include 
 #include "amdgpu.h"
 #include "cgs_linux.h"
+#include "atom.h"

 struct amdgpu_cgs_device {
struct cgs_device base;
@@ -221,24 +222,39 @@ static const void *amdgpu_cgs_atom_get_data_table(void 
*cgs_device,
  unsigned table, uint16_t 
*size,
  uint8_t *frev, uint8_t *crev)
 {
-   /* TODO */
+   CGS_FUNC_ADEV;
+   uint16_t data_start;
+
+   if (amdgpu_atom_parse_data_header(
+   adev->mode_info.atom_context, table, size,
+   frev, crev, _start))
+   return (uint8_t*)adev->mode_info.atom_context->bios +
+   data_start;
+
return NULL;
 }

 static int amdgpu_cgs_atom_get_cmd_table_revs(void *cgs_device, unsigned table,
  uint8_t *frev, uint8_t *crev)
 {
-   /* TODO */
-   return 0;
+   CGS_FUNC_ADEV;
+
+   if (amdgpu_atom_parse_cmd_header(
+   adev->mode_info.atom_context, table,
+   frev, crev))
+   return 0;
+
+   return -EINVAL;
 }

 static int amdgpu_cgs_atom_exec_cmd_table(void *cgs_device, unsigned table,
  void *args)
 {
-   /* TODO */
-   return 0;
-}
+   CGS_FUNC_ADEV;

+   return amdgpu_atom_execute_table(
+   adev->mode_info.atom_context, table, args);
+}

 static int amdgpu_cgs_create_pm_request(void *cgs_device, cgs_handle_t 
*request)
 {
-- 
1.8.3.1



[PATCH 05/12] drm/amdgpu: Implement irq interfaces for CGS

2015-07-09 Thread Alex Deucher
From: Chunming Zhou 

This implements the irq src registrar.

Reviewed-by: Jammy Zhou 
Signed-off-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 81 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c  |  2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h  |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c |  5 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h |  1 +
 5 files changed, 84 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index 6ac3df8..93fbf35 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -290,26 +290,95 @@ static int amdgpu_cgs_set_camera_voltages(void 
*cgs_device, uint32_t mask,
return -EPERM;
 }

+struct cgs_irq_params {
+   unsigned src_id;
+   cgs_irq_source_set_func_t set;
+   cgs_irq_handler_func_t handler;
+   void *private_data;
+};
+
+static int cgs_set_irq_state(struct amdgpu_device *adev,
+struct amdgpu_irq_src *src,
+unsigned type,
+enum amdgpu_interrupt_state state)
+{
+   struct cgs_irq_params *irq_params =
+   (struct cgs_irq_params *)src->data;
+   if (!irq_params)
+   return -EINVAL;
+   if (!irq_params->set)
+   return -EINVAL;
+   return irq_params->set(irq_params->private_data,
+  irq_params->src_id,
+  type,
+  (int)state);
+}
+
+static int cgs_process_irq(struct amdgpu_device *adev,
+  struct amdgpu_irq_src *source,
+  struct amdgpu_iv_entry *entry)
+{
+   struct cgs_irq_params *irq_params =
+   (struct cgs_irq_params *)source->data;
+   if (!irq_params)
+   return -EINVAL;
+   if (!irq_params->handler)
+   return -EINVAL;
+   return irq_params->handler(irq_params->private_data,
+  irq_params->src_id,
+  entry->iv_entry);
+}
+
+static const struct amdgpu_irq_src_funcs cgs_irq_funcs = {
+   .set = cgs_set_irq_state,
+   .process = cgs_process_irq,
+};
+
 static int amdgpu_cgs_add_irq_source(void *cgs_device, unsigned src_id,
 unsigned num_types,
 cgs_irq_source_set_func_t set,
 cgs_irq_handler_func_t handler,
 void *private_data)
 {
-   /* TODO */
-   return 0;
+   CGS_FUNC_ADEV;
+   int ret = 0;
+   struct cgs_irq_params *irq_params;
+   struct amdgpu_irq_src *source =
+   kzalloc(sizeof(struct amdgpu_irq_src), GFP_KERNEL);
+   if (!source)
+   return -ENOMEM;
+   irq_params =
+   kzalloc(sizeof(struct cgs_irq_params), GFP_KERNEL);
+   if (!irq_params) {
+   kfree(source);
+   return -ENOMEM;
+   }
+   source->num_types = num_types;
+   source->funcs = _irq_funcs;
+   irq_params->src_id = src_id;
+   irq_params->set = set;
+   irq_params->handler = handler;
+   irq_params->private_data = private_data;
+   source->data = (void *)irq_params;
+   ret = amdgpu_irq_add_id(adev, src_id, source);
+   if (ret) {
+   kfree(irq_params);
+   kfree(source);
+   }
+
+   return ret;
 }

 static int amdgpu_cgs_irq_get(void *cgs_device, unsigned src_id, unsigned type)
 {
-   /* TODO */
-   return 0;
+   CGS_FUNC_ADEV;
+   return amdgpu_irq_get(adev, adev->irq.sources[src_id], type);
 }

 static int amdgpu_cgs_irq_put(void *cgs_device, unsigned src_id, unsigned type)
 {
-   /* TODO */
-   return 0;
+   CGS_FUNC_ADEV;
+   return amdgpu_irq_put(adev, adev->irq.sources[src_id], type);
 }

 static const struct cgs_ops amdgpu_cgs_ops = {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
index db5422e..272275a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
@@ -199,6 +199,8 @@ restart_ih:
rmb();

while (adev->irq.ih.rptr != wptr) {
+   entry.iv_entry = (const uint32_t *)
+   >irq.ih.ring[adev->irq.ih.rptr >> 2];
amdgpu_ih_decode_iv(adev, );
adev->irq.ih.rptr &= adev->irq.ih.ptr_mask;

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
index c62b09e..ba38ae6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
@@ -52,6 +52,7 @@ struct amdgpu_iv_entry {
unsigned ring_id;
unsigned vm_id;
unsigned pas_id;
+   const uint32_t *iv_entry;
 };

 int 

[PATCH 04/12] drm/amdgpu: Implement the pciconfig callbacks for CGS

2015-07-09 Thread Alex Deucher
From: Chunming Zhou 

This implements the pciconfig register accessors.

Reviewed-by: Jammy Zhou 
Signed-off-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 40 +++--
 1 file changed, 28 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index 7ba92f7..6ac3df8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -21,6 +21,7 @@
  *
  *
  */
+#include 
 #include "amdgpu.h"
 #include "cgs_linux.h"

@@ -163,42 +164,57 @@ static void amdgpu_cgs_write_ind_register(void 
*cgs_device,

 static uint8_t amdgpu_cgs_read_pci_config_byte(void *cgs_device, unsigned addr)
 {
-   /* TODO */
-   return 0;
+   CGS_FUNC_ADEV;
+   uint8_t val;
+   int ret = pci_read_config_byte(adev->pdev, addr, );
+   if (WARN(ret, "pci_read_config_byte error"))
+   return 0;
+   return val;
 }

 static uint16_t amdgpu_cgs_read_pci_config_word(void *cgs_device, unsigned 
addr)
 {
-   /* TODO */
-   return 0;
+   CGS_FUNC_ADEV;
+   uint16_t val;
+   int ret = pci_read_config_word(adev->pdev, addr, );
+   if (WARN(ret, "pci_read_config_word error"))
+   return 0;
+   return val;
 }

 static uint32_t amdgpu_cgs_read_pci_config_dword(void *cgs_device,
 unsigned addr)
 {
-   /* TODO */
-   return 0;
+   CGS_FUNC_ADEV;
+   uint32_t val;
+   int ret = pci_read_config_dword(adev->pdev, addr, );
+   if (WARN(ret, "pci_read_config_dword error"))
+   return 0;
+   return val;
 }

 static void amdgpu_cgs_write_pci_config_byte(void *cgs_device, unsigned addr,
 uint8_t value)
 {
-   /* TODO */
-   return;
+   CGS_FUNC_ADEV;
+   int ret = pci_write_config_byte(adev->pdev, addr, value);
+   WARN(ret, "pci_write_config_byte error");
 }

 static void amdgpu_cgs_write_pci_config_word(void *cgs_device, unsigned addr,
 uint16_t value)
 {
-   /* TODO */
-   return;
+   CGS_FUNC_ADEV;
+   int ret = pci_write_config_word(adev->pdev, addr, value);
+   WARN(ret, "pci_write_config_word error");
 }

 static void amdgpu_cgs_write_pci_config_dword(void *cgs_device, unsigned addr,
  uint32_t value)
 {
-   /* TODO */
-   return;
+   CGS_FUNC_ADEV;
+   int ret = pci_write_config_dword(adev->pdev, addr, value);
+   WARN(ret, "pci_write_config_dword error");
 }

 static const void *amdgpu_cgs_atom_get_data_table(void *cgs_device,
-- 
1.8.3.1



[PATCH 03/12] drm/amdgpu: Implement mmio callbacks for CGS

2015-07-09 Thread Alex Deucher
From: Chunming Zhou 

This implements the MMIO register accessors.

Reviewed-by: Jammy Zhou 
Signed-off-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 45 -
 1 file changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index aea264a..7ba92f7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -103,22 +103,38 @@ static int amdgpu_cgs_kunmap_gpu_mem(void *cgs_device, 
cgs_handle_t handle)

 static uint32_t amdgpu_cgs_read_register(void *cgs_device, unsigned offset)
 {
-   /* TODO */
-   return 0;
+   CGS_FUNC_ADEV;
+   return RREG32(offset);
 }

 static void amdgpu_cgs_write_register(void *cgs_device, unsigned offset,
  uint32_t value)
 {
-   /* TODO */
-   return;
+   CGS_FUNC_ADEV;
+   WREG32(offset, value);
 }

 static uint32_t amdgpu_cgs_read_ind_register(void *cgs_device,
 enum cgs_ind_reg space,
 unsigned index)
 {
-   /* TODO */
+   CGS_FUNC_ADEV;
+   switch (space) {
+   case CGS_IND_REG__MMIO:
+   return RREG32_IDX(index);
+   case CGS_IND_REG__PCIE:
+   return RREG32_PCIE(index);
+   case CGS_IND_REG__SMC:
+   return RREG32_SMC(index);
+   case CGS_IND_REG__UVD_CTX:
+   return RREG32_UVD_CTX(index);
+   case CGS_IND_REG__DIDT:
+   return RREG32_DIDT(index);
+   case CGS_IND_REG__AUDIO_ENDPT:
+   DRM_ERROR("audio endpt register access not implemented.\n");
+   return 0;
+   }
+   WARN(1, "Invalid indirect register space");
return 0;
 }

@@ -126,8 +142,23 @@ static void amdgpu_cgs_write_ind_register(void *cgs_device,
  enum cgs_ind_reg space,
  unsigned index, uint32_t value)
 {
-   /* TODO */
-   return;
+   CGS_FUNC_ADEV;
+   switch (space) {
+   case CGS_IND_REG__MMIO:
+   return WREG32_IDX(index, value);
+   case CGS_IND_REG__PCIE:
+   return WREG32_PCIE(index, value);
+   case CGS_IND_REG__SMC:
+   return WREG32_SMC(index, value);
+   case CGS_IND_REG__UVD_CTX:
+   return WREG32_UVD_CTX(index, value);
+   case CGS_IND_REG__DIDT:
+   return WREG32_DIDT(index, value);
+   case CGS_IND_REG__AUDIO_ENDPT:
+   DRM_ERROR("audio endpt register access not implemented.\n");
+   return;
+   }
+   WARN(1, "Invalid indirect register space");
 }

 static uint8_t amdgpu_cgs_read_pci_config_byte(void *cgs_device, unsigned addr)
-- 
1.8.3.1



[PATCH 02/12] drm/amd: Add CGS interfaces

2015-07-09 Thread Alex Deucher
From: Chunming Zhou 

CGS (Common Graphics Services) is an AMD cross component
abstraction layer to designed to better encapsulate
specific IP block drivers so different teams can effectively
work on differnet IP block drivers independently. It provides
a common interface for things like accessing registers,
allocating GPU memory, and registering interrupt sources.
The plan is to eventually move more and more IP drivers to
this interface.  The first user is the ACP IP driver.

Reviewed-by: Jammy Zhou 
Signed-off-by: Chunming Zhou 
Acked-by: Christian König 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/Makefile  |   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c  | 327 ++
 drivers/gpu/drm/amd/include/cgs_common.h | 563 +++
 drivers/gpu/drm/amd/include/cgs_linux.h  | 135 
 5 files changed, 1029 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
 create mode 100644 drivers/gpu/drm/amd/include/cgs_common.h
 create mode 100644 drivers/gpu/drm/amd/include/cgs_linux.h

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 616dfd4..f17d0cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -71,6 +71,9 @@ amdgpu-y += \
amdgpu_vce.o \
vce_v3_0.o

+# add cgs
+amdgpu-y += amdgpu_cgs.o
+
 amdgpu-$(CONFIG_COMPAT) += amdgpu_ioc32.o
 amdgpu-$(CONFIG_VGA_SWITCHEROO) += amdgpu_atpx_handler.o
 amdgpu-$(CONFIG_ACPI) += amdgpu_acpi.o
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 0165783..9c41d25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -42,6 +42,7 @@
 #include 
 #include 

+#include 
 #include 
 #include 

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
new file mode 100644
index 000..aea264a
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ *
+ */
+#include "amdgpu.h"
+#include "cgs_linux.h"
+
+struct amdgpu_cgs_device {
+   struct cgs_device base;
+   struct amdgpu_device *adev;
+};
+
+#define CGS_FUNC_ADEV  \
+   struct amdgpu_device *adev =\
+   ((struct amdgpu_cgs_device *)cgs_device)->adev
+
+static int amdgpu_cgs_gpu_mem_info(void *cgs_device, enum cgs_gpu_mem_type 
type,
+  uint64_t *mc_start, uint64_t *mc_size,
+  uint64_t *mem_size)
+{
+   return 0;
+}
+
+static int amdgpu_cgs_gmap_kmem(void *cgs_device, void *kmem,
+   uint64_t size,
+   uint64_t min_offset, uint64_t max_offset,
+   cgs_handle_t *kmem_handle, uint64_t *mcaddr)
+{
+   return 0;
+}
+
+static int amdgpu_cgs_gunmap_kmem(void *cgs_device, cgs_handle_t kmem_handle)
+{
+   return 0;
+}
+
+static int amdgpu_cgs_alloc_gpu_mem(void *cgs_device,
+   enum cgs_gpu_mem_type type,
+   uint64_t size, uint64_t align,
+   uint64_t min_offset, uint64_t max_offset,
+   cgs_handle_t *handle)
+{
+   return 0;
+}
+
+static int amdgpu_cgs_import_gpu_mem(void *cgs_device, int dmabuf_fd,
+cgs_handle_t *handle)
+{
+   /* TODO */
+   return 0;
+}
+
+static int amdgpu_cgs_free_gpu_mem(void *cgs_device, cgs_handle_t handle)
+{
+   /* TODO */
+   return 0;
+}
+
+static int amdgpu_cgs_gmap_gpu_mem(void *cgs_device, cgs_handle_t handle,
+   

[PATCH 01/12] drm/amdgpu: add amd_gnb_bus support

2015-07-09 Thread Alex Deucher
From: Chunming Zhou 

This is used by the incoming ACP driver.  The DMA
engine for the i2s audio codec is part of the GPU.

This exposes an amd gnb bus for the i2s codec to
hang off of.

Reviewed-by: Jammy Zhou 
Signed-off-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/Kconfig   |   3 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/amd/bus/Kconfig   |   7 +
 drivers/gpu/drm/amd/bus/Makefile  |   4 +
 drivers/gpu/drm/amd/bus/amd_gnb_bus.c | 266 ++
 drivers/gpu/drm/amd/include/bus/amd_gnb_bus.h |  78 
 6 files changed, 359 insertions(+)
 create mode 100644 drivers/gpu/drm/amd/bus/Kconfig
 create mode 100644 drivers/gpu/drm/amd/bus/Makefile
 create mode 100644 drivers/gpu/drm/amd/bus/amd_gnb_bus.c
 create mode 100644 drivers/gpu/drm/amd/include/bus/amd_gnb_bus.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c46ca31..8c3cc9e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -120,6 +120,8 @@ config DRM_RADEON

 source "drivers/gpu/drm/radeon/Kconfig"

+source "drivers/gpu/drm/amd/bus/Kconfig"
+
 config DRM_AMDGPU
tristate "AMD GPU"
depends on DRM && PCI
@@ -134,6 +136,7 @@ config DRM_AMDGPU
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+   select DRM_AMD_GNB_BUS
help
  Choose this option if you have a recent AMD Radeon graphics card.

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 5713d05..5380477 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_DRM_TDFX)+= tdfx/
 obj-$(CONFIG_DRM_R128) += r128/
 obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
 obj-$(CONFIG_DRM_RADEON)+= radeon/
+obj-$(CONFIG_DRM_AMD_GNB_BUS)   += amd/bus/
 obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
 obj-$(CONFIG_DRM_MGA)  += mga/
 obj-$(CONFIG_DRM_I810) += i810/
diff --git a/drivers/gpu/drm/amd/bus/Kconfig b/drivers/gpu/drm/amd/bus/Kconfig
new file mode 100644
index 000..f101dd8
--- /dev/null
+++ b/drivers/gpu/drm/amd/bus/Kconfig
@@ -0,0 +1,7 @@
+menu "AMD GNB BUS"
+   visible if 0
+
+config DRM_AMD_GNB_BUS
+   tristate "AMD GNB bus - used for GNB IPs such as ACP and ISP"
+
+endmenu
diff --git a/drivers/gpu/drm/amd/bus/Makefile b/drivers/gpu/drm/amd/bus/Makefile
new file mode 100644
index 000..c41ffc9
--- /dev/null
+++ b/drivers/gpu/drm/amd/bus/Makefile
@@ -0,0 +1,4 @@
+#
+ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/amd/include/bus/
+
+obj-$(CONFIG_DRM_AMD_GNB_BUS) := amd_gnb_bus.o
diff --git a/drivers/gpu/drm/amd/bus/amd_gnb_bus.c 
b/drivers/gpu/drm/amd/bus/amd_gnb_bus.c
new file mode 100644
index 000..071b16c
--- /dev/null
+++ b/drivers/gpu/drm/amd/bus/amd_gnb_bus.c
@@ -0,0 +1,266 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ *
+ */
+#include 
+#include 
+#include 
+#include "amd_gnb_bus.h"
+
+#define to_amd_gnb_bus_device(x) container_of((x), struct amd_gnb_bus_dev, dev)
+#define to_amd_gnb_bus_driver(drv) (container_of((drv),
\
+   struct amd_gnb_bus_driver, \
+   driver))
+
+static int amd_gnb_bus_match(struct device *dev, struct device_driver *drv)
+{
+   struct amd_gnb_bus_dev *amd_gnb_bus_dev = to_amd_gnb_bus_device(dev);
+   struct amd_gnb_bus_driver *amd_gnb_bus_driver =
+   to_amd_gnb_bus_driver(drv);
+
+   return amd_gnb_bus_dev->ip == amd_gnb_bus_driver->ip ? 1 : 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int amd_gnb_bus_legacy_suspend(struct device *dev, pm_message_t mesg)
+{
+   struct amd_gnb_bus_dev *amd_gnb_bus_dev = to_amd_gnb_bus_device(dev);
+   struct amd_gnb_bus_driver *driver;
+
+   if (!amd_gnb_bus_dev || !dev->driver)
+

[Bug 90728] dvd playback with vlc and vdpau causes segmentation fault

2015-07-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90728

Christian König  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #23 from Christian König  ---
(In reply to Chris Rankin from comment #22)
> For reference: is this fix only relevant for UVD/UVD+ please?

It's relevant for all hardware before UVD 3, e.g. R6xx R7xx, Evergreen.

UVD+ was just a marketing name for a certain feature set and isn't related to a
hardware generation in any way.

But yeah for newer hardware it's rather irrelevant.

-- 
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/20150709/7bb1b745/attachment-0001.html>


[pull] radeon and amdgpu drm-fixes-4.2

2015-07-09 Thread Alex Deucher
Hi Dave,

radeon and amdgpu fixes for 4.2.  All over the place:
- fix cursor corruption on resume and re-enable no VT switch on suspend
- vblank fixes
- fix gpuvm error messages
- misc other fixes

The following changes since commit d6ac4ffc61ace6ed6f183e9fd7f207c0ddafb897:

  Merge branch 'for-linus' of git://ftp.arm.linux.org.uk/~rmk/linux-arm 
(2015-07-07 15:19:09 -0700)

are available in the git repository at:


  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.2

for you to fetch changes up to 355c822847fa70fa1df6a7451b7ecf76116efcd2:

  drm/radeon: disable vce init on cayman (v2) (2015-07-09 11:40:12 -0400)


Alex Deucher (2):
  Revert "Revert "drm/radeon: dont switch vt on suspend""
  drm/radeon: disable vce init on cayman (v2)

Christian König (3):
  drm/radeon: allways add the VM clear duplicate
  drm/radeon: check if BO_VA is set before adding it to the invalidation 
list
  drm/amdgpu: fix timeout calculation

Dan Carpenter (1):
  drm/radeon: fix underflow in r600_cp_dispatch_texture()

Grigori Goronzy (4):
  drm/radeon: use RCU query for GEM_BUSY syscall
  drm/radeon: fix HDP flushing
  drm/radeon: default to 2048 MB GART size on SI+
  drm/radeon: unpin cursor BOs on suspend and pin them again on resume (v2)

Mario Kleiner (2):
  drm/radeon: Handle irqs only based on irq ring, not irq status regs.
  drm/amdgpu: Handle irqs only based on irq ring, not irq status regs.

Michel Dänzer (2):
  drm/radeon: Clean up reference counting and pinning of the cursor BOs
  drm/radeon: Fold radeon_set_cursor() into radeon_show_cursor()

 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  22 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  22 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  22 +-
 drivers/gpu/drm/radeon/cik.c| 336 +++
 drivers/gpu/drm/radeon/evergreen.c  | 392 ++--
 drivers/gpu/drm/radeon/ni.c |  25 +-
 drivers/gpu/drm/radeon/r600.c   | 155 +++--
 drivers/gpu/drm/radeon/r600_cp.c|   2 +-
 drivers/gpu/drm/radeon/radeon_cursor.c  | 109 -
 drivers/gpu/drm/radeon/radeon_device.c  |  66 --
 drivers/gpu/drm/radeon/radeon_fb.c  |   1 +
 drivers/gpu/drm/radeon/radeon_gem.c |  12 +-
 drivers/gpu/drm/radeon/radeon_mode.h|   1 -
 drivers/gpu/drm/radeon/radeon_vm.c  |  40 ++--
 drivers/gpu/drm/radeon/si.c | 336 +++
 16 files changed, 871 insertions(+), 672 deletions(-)


[RFC][PATCH 1/1] drm/amdkfd: Remove redundant pdd validation

2015-07-09 Thread Oded Gabbay
On Mon, Jun 29, 2015 at 7:33 AM, Maninder Singh  
wrote:
>
> pdd is already dereferenced before this check.
> So it is redundtant to validate pdd here.
>
> Signed-off-by: Maninder Singh 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> index 8a1f999..4dbc4e5 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> @@ -431,8 +431,7 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev, 
> unsigned int pasid)
>  * We don't call amd_iommu_unbind_pasid() here
>  * because the IOMMU called us.
>  */
> -   if (pdd)
> -   pdd->bound = false;
> +   pdd->bound = false;
>
> mutex_unlock(>mutex);
>  }
> --
> 1.7.9.5
>
Hi Maninder,

You are correct pdd was already dereferenced so this check is
redundant. However, I think a better patch would be to move the check
to where pdd is first acquired (a few lines above it), because I don't
see there any check.

Could you please do that and resend the patch ? Use latest v4.2-rc1
label from Linus please.

Thansk,

   Oded


[PATCH 1/2] drm/ttm: fix object deallocation to properly fill in the page pool.

2015-07-09 Thread Michel Dänzer
On 09.07.2015 03:16, j.glisse at gmail.com wrote:
> From: Jérôme Glisse 
> 
> Current code never allowed the page pool to actualy fill in anyway.
> This fix it, so that we only start freeing page from the pool when
> we go over the pool size.
> 
> Signed-off-by: Jérôme Glisse 

[...]

> - if (pool->npages_free > _manager->options.max_size) {
> + if (pool->npages_free > _manager->options.max_size)
>   npages = pool->npages_free - _manager->options.max_size;
> - /* free at least NUM_PAGES_TO_ALLOC number of pages
> -  * to reduce calls to set_memory_wb */
> - if (npages < NUM_PAGES_TO_ALLOC)
> - npages = NUM_PAGES_TO_ALLOC;
> - }

This should be part of patch 2. With that fixed, both patches are

Reviewed-and-Tested-by: Michel Dänzer 


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


Wayland and GLES1 (Re: R200 DRM/KMS)

2015-07-09 Thread Michel Dänzer
On 09.07.2015 06:01, Steven Newbury wrote:
> On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
>> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
>>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
>>>  wrote:
>>> 
>>>> Would gles1 be sufficient to run a Wayland compositor, I'm 
>>>> guessing probably not..?
>>> 
>>> If you can find a Wayland compositor that is written to composite
>>>  with GLES1, that's all you need from the "Wayland side". (Yeah,
>>> this has nothing to do with Wayland per se.) Compositing in
>>> itself without any effects is very simple, as long as you get the
>>> textures up.
>>> 
>>> Or, if you find a Wayland compositor written to use desktop
>>> OpenGL for compositing and does not use features your GL driver
>>> does not expose, that's good too.
>>> 
>> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
>> 
> To answer my own question, it seems that is possible.  I wonder if
> it works with mutter/cogl???

It does.

However, your problem seems rather that gnome-shell/mutter doesn't
support R200 anymore.


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

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/fd979396/attachment.sig>


Wayland and GLES1 (Re: R200 DRM/KMS)

2015-07-09 Thread Alex Deucher
On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury  wrote:
>
>
> On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
>> On 09.07.2015 06:01, Steven Newbury wrote:
>> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
>> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
>> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
>> >>>  wrote:
>> >>>
>>  Would gles1 be sufficient to run a Wayland compositor, I'm
>>  guessing probably not..?
>> >>>
>> >>> If you can find a Wayland compositor that is written to composite
>> >>>  with GLES1, that's all you need from the "Wayland side". (Yeah,
>> >>> this has nothing to do with Wayland per se.) Compositing in
>> >>> itself without any effects is very simple, as long as you get the
>> >>> textures up.
>> >>>
>> >>> Or, if you find a Wayland compositor written to use desktop
>> >>> OpenGL for compositing and does not use features your GL driver
>> >>> does not expose, that's good too.
>> >>>
>> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
>> >>
>> > To answer my own question, it seems that is possible.  I wonder if
>> > it works with mutter/cogl???
>>
>> It does.
>>
>> However, your problem seems rather that gnome-shell/mutter doesn't
>> support R200 anymore.
> Yes, that's true. I wonder if I can revert the incompatible change or better 
> create a env variable to revert to the compatible behaviour or something? 
> I'll need to take a look...

I'm not sure how valid this is any more:
https://bugs.freedesktop.org/show_bug.cgi?id=51658

Basic issue is that r1xx/r2xx hw only has a limited number of render
buffer formats while they support a lot of texture formats.  Gnome
shell expects to be able to render to the same formats they can
texture from.

Alex

>
> [I'm going to be posting a lot from my phone, my laptop power jack has just 
> broken, again! :-( You'd think after 3.5 decades of making laptops we'd have 
> come up with a better design!]
> --
> Sent from my Jolla
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


linux-next: manual merge of the drm-intel tree with Linus' tree

2015-07-09 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/i915_gem_gtt.c

between commit:

  00245266b4be ("drm/i915/ppgtt: Break loop in gen8_ppgtt_clear_range failure 
path")

from Linus' tree and commit:

  567047be2a7e ("drm/i915/gtt: Use macros to access dma mapped pages")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/gpu/drm/i915/i915_gem_gtt.c
index dcc6a88c560e,ed65f24867b4..
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@@ -513,10 -583,9 +583,9 @@@ static void gen8_ppgtt_clear_range(stru
while (num_entries) {
struct i915_page_directory *pd;
struct i915_page_table *pt;
-   struct page *page_table;

if (WARN_ON(!ppgtt->pdp.page_directory[pdpe]))
 -  continue;
 +  break;

pd = ppgtt->pdp.page_directory[pdpe];

@@@ -525,11 -594,9 +594,9 @@@

pt = pd->page_table[pde];

-   if (WARN_ON(!pt->page))
+   if (WARN_ON(!px_page(pt)))
 -  continue;
 +  break;

-   page_table = pt->page;
- 
last_pte = pte + num_entries;
if (last_pte > GEN8_PTES)
last_pte = GEN8_PTES;
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/f1b0ee5b/attachment.sig>


linux-next: manual merge of the drm-intel tree with the drm-intel-fixes trees

2015-07-09 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/intel_display.c

between commits:

  63fef06ada94 ("drm/i915: Check crtc->active in intel_crtc_disable_planes")
  dec4f799d0a4 ("drm/i915: Use crtc_state->active in primary check_plane func")

from the drm-intel-fixes tree and commit:

  a539205a1628 ("drm/i915: atomic plane updates in a nutshell")
  da20eabd2c69 ("drm/i915: Split plane updates of crtc->atomic into a helper, 
v2.")

from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/gpu/drm/i915/intel_display.c
index ba9321998a41,4bcbff9793d4..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -4851,25 -4800,13 +4800,16 @@@ static void intel_crtc_disable_planes(s
  {
struct drm_device *dev = crtc->dev;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct intel_plane *intel_plane;
+   struct drm_plane *p;
int pipe = intel_crtc->pipe;

 +  if (!intel_crtc->active)
 +  return;
 +
-   intel_crtc_wait_for_pending_flips(crtc);
- 
-   intel_pre_disable_primary(crtc);
- 
intel_crtc_dpms_overlay_disable(intel_crtc);
-   for_each_intel_plane(dev, intel_plane) {
-   if (intel_plane->pipe == pipe) {
-   struct drm_crtc *from = intel_plane->base.crtc;

-   intel_plane->disable_plane(_plane->base,
-  from ?: crtc, true);
-   }
-   }
+   drm_for_each_plane_mask(p, dev, plane_mask)
+   to_intel_plane(p)->disable_plane(p, crtc);

/*
 * FIXME: Once we grow proper nuclear flip support out of this we need
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/0bdff701/attachment.sig>


[Bug 90728] dvd playback with vlc and vdpau causes segmentation fault

2015-07-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90728

Chris Rankin  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |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/20150709/8fe2d75a/attachment.html>


[Bug 90728] dvd playback with vlc and vdpau causes segmentation fault

2015-07-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90728

--- Comment #22 from Chris Rankin  ---
For reference: is this fix only relevant for UVD/UVD+ please?

-- 
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/20150709/4807a91e/attachment.html>


[RFC PATCH] drm: use dma_map_sg_attrs for GEM CMA objects

2015-07-09 Thread Steve Longerbeam
The GEM CMA helper allocates GEM objects with dma_alloc_writecombine(),
so the objects are cache coherent, and the exporter methods for these
objects can skip cache sync.

To accomplish this a dma atrribute is added to drm_gem_object,
and is used with dma_map_sg_attrs/dma_unmap_sg_attrs in
drm_gem_map_dma_buf/drm_gem_map_detach. GEM CMA sets the attribute
to DMA_ATTR_SKIP_CPU_SYNC when the object is allocated in
drm_gem_cma_create().

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/drm/drm_gem.c| 1 +
 drivers/gpu/drm/drm_gem_cma_helper.c | 2 ++
 drivers/gpu/drm/drm_prime.c  | 7 ---
 include/drm/drm_gem.h| 5 +
 4 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 16a1647..f7f4531 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -169,6 +169,7 @@ void drm_gem_private_object_init(struct drm_device *dev,
obj->handle_count = 0;
obj->size = size;
drm_vma_node_reset(>vma_node);
+   init_dma_attrs(>dma_attrs);
 }
 EXPORT_SYMBOL(drm_gem_private_object_init);

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index bd75f30..73c949a 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -75,6 +75,8 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size)
goto error;
}

+   dma_set_attr(DMA_ATTR_SKIP_CPU_SYNC, _obj->dma_attrs);
+
return cma_obj;

 error:
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9f935f5..9eaa8d3 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -153,8 +153,8 @@ static void drm_gem_map_detach(struct dma_buf *dma_buf,
sgt = prime_attach->sgt;
if (sgt) {
if (prime_attach->dir != DMA_NONE)
-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
-   prime_attach->dir);
+   dma_unmap_sg_attrs(attach->dev, sgt->sgl, sgt->nents,
+  prime_attach->dir, >dma_attrs);
sg_free_table(sgt);
}

@@ -201,7 +201,8 @@ static struct sg_table *drm_gem_map_dma_buf(struct 
dma_buf_attachment *attach,
sgt = obj->dev->driver->gem_prime_get_sg_table(obj);

if (!IS_ERR(sgt)) {
-   if (!dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir)) {
+   if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents,
+ dir, >dma_attrs)) {
sg_free_table(sgt);
kfree(sgt);
sgt = ERR_PTR(-ENOMEM);
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 7a592d7..f5546bf 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -104,6 +104,11 @@ struct drm_gem_object {
struct dma_buf *dma_buf;

/**
+* dma_attrs - DMA attributes for this GEM object
+*/
+   struct dma_attrs dma_attrs;
+
+   /**
 * import_attach - dma buf attachment backing this object
 *
 * Any foreign dma_buf imported as a gem object has this set to the
-- 
1.9.1



[Bug 91281] Tonga VCE 2160p encode fails with BO to small for addr

2015-07-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91281

Bug ID: 91281
   Summary: Tonga VCE 2160p encode fails with  BO to small for
addr
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

I don't know what the VCE is supposed to do on this R9 285 card but testing
with 2160p gives.

amdgpu: The CS has been rejected, see dmesg for more information.

[drm:amdgpu_vce_cs_reloc [amdgpu]] *ERROR* BO to small for addr 0x000245 14
13

Same test works with 1080p (bit slow but I haven't tested/understood the PM
situation yet).

-- 
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/20150709/639037d8/attachment.html>


[Bug 91279] agd5f drm tonga occasional traps error:0 in libdrm_amdgpu.so.1.0.0

2015-07-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91279

Bug ID: 91279
   Summary: agd5f drm tonga occasional traps error:0 in
libdrm_amdgpu.so.1.0.0
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

These don't always happen and I don't know how to provoke or if they affect
anything.

 traps: plugin-containe[532] general protection ip:7fa27df08850 sp:7fff36eef0c0
error:0 in libdrm_amdgpu.so.1.0.0[7fa27df04000+7000]

-- 
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/20150709/d82993e3/attachment.html>


[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley

2015-07-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91278

--- Comment #2 from Andy Furniss  ---
Created attachment 117013
  --> https://bugs.freedesktop.org/attachment.cgi?id=117013=edit
xorg-log for ref (not from lock)

-- 
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/20150709/ad7992dd/attachment.html>


[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley

2015-07-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91278

--- Comment #1 from Andy Furniss  ---
Created attachment 117012
  --> https://bugs.freedesktop.org/attachment.cgi?id=117012=edit
dmesg with lock

-- 
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/20150709/1e18a0ec/attachment.html>


[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley

2015-07-09 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91278

Bug ID: 91278
   Summary: Tonga GPU lock/reset fail  with Unigine Valley
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

R9 285 kernel agd5f amdgpu with or without patches from 

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

mesa is agd5f with a few patches from mainline to build with current llvm.

ddx is git against older xorg.

Simpler games like openarena don't lock.

Valley settings ultra, 8xAA, fullscreen 1920x1080.

Doesn't show in this log but I've also seen some

 [drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA (-35)

around the lock/reset on previous tests.

-- 
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/20150709/8b803072/attachment-0001.html>


[PATCH RESEND v2 2/6] drm/exynos/mixer: fix interrupt clearing

2015-07-09 Thread Andrzej Hajda
The driver used incorrect flags to clear interrupt status.
The patch fixes it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index cae98db..25f0aac 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -718,6 +718,10 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)

/* handling VSYNC */
if (val & MXR_INT_STATUS_VSYNC) {
+   /* vsync interrupt use different bit for read and clear */
+   val |= MXR_INT_CLEAR_VSYNC;
+   val &= ~MXR_INT_STATUS_VSYNC;
+
/* interlace scan need to check shadow register */
if (ctx->interlace) {
base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
@@ -743,11 +747,6 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)

 out:
/* clear interrupts */
-   if (~val & MXR_INT_EN_VSYNC) {
-   /* vsync interrupt use different bit for read and clear */
-   val &= ~MXR_INT_EN_VSYNC;
-   val |= MXR_INT_CLEAR_VSYNC;
-   }
mixer_reg_write(res, MXR_INT_STATUS, val);

spin_unlock(>reg_slock);
-- 
1.9.1



[RFCv3 0/5] enable migration of driver pages

2015-07-09 Thread Gioh Kim


2015-07-09 오전 7:47에 Dave Airlie 이(가) 쓴 글:
>>>
>>>
>>> Can the various in-kernel GPU drivers benefit from this?  If so, wiring
>>> up one or more of those would be helpful?
>>
>>
>> I'm sure that other in-kernel GPU drivers can have benefit.
>> It must be helpful.
>>
>> If I was familiar with other in-kernel GPU drivers code, I tried to patch
>> them.
>> It's too bad.
>
> I'll bring dri-devel into the loop here.
>
> ARM GPU developers please take a look at this stuff, Laurent, Rob,
> Eric I suppose.

I sent a patch, https://lkml.org/lkml/2015/3/24/1182, and my opinion about 
compaction
to ARM GPU developers via Korea ARM branch.
I got a reply that they had no time to review it.

I hope they're interested to this patch.


>
> Daniel Vetter you might have some opinions as well.
>
> Dave.
>


[RFCv3 0/5] enable migration of driver pages

2015-07-09 Thread Dave Airlie
>>
>>
>> Can the various in-kernel GPU drivers benefit from this?  If so, wiring
>> up one or more of those would be helpful?
>
>
> I'm sure that other in-kernel GPU drivers can have benefit.
> It must be helpful.
>
> If I was familiar with other in-kernel GPU drivers code, I tried to patch
> them.
> It's too bad.

I'll bring dri-devel into the loop here.

ARM GPU developers please take a look at this stuff, Laurent, Rob,
Eric I suppose.

Daniel Vetter you might have some opinions as well.

Dave.


[PATCH RESEND 6/6] drm/exynos/mixer: replace MXR_INT_EN register cache with flag

2015-07-09 Thread Andrzej Hajda
Driver uses only VSYNC interrupts, so we need to cache VSYNC bit state only.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 453b6bb..7e57409 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -71,6 +71,7 @@ enum mixer_version_id {

 enum mixer_flag_bits {
MXR_BIT_POWERED,
+   MXR_BIT_VSYNC,
 };

 struct mixer_context {
@@ -84,7 +85,6 @@ struct mixer_context {
boolinterlace;
boolvp_enabled;
boolhas_sclk;
-   u32 int_en;

struct mixer_resources  mixer_res;
enum mixer_version_id   mxr_ver;
@@ -902,10 +902,9 @@ static int mixer_enable_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
struct mixer_resources *res = _ctx->mixer_res;

-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags)) {
-   mixer_ctx->int_en |= MXR_INT_EN_VSYNC;
+   __set_bit(MXR_BIT_VSYNC, _ctx->flags);
+   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
return 0;
-   }

/* enable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
@@ -919,10 +918,10 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
struct mixer_resources *res = _ctx->mixer_res;

-   if (!test_bit(MXR_BIT_POWERED, _ctx->flags)) {
-   mixer_ctx->int_en &= MXR_INT_EN_VSYNC;
+   __clear_bit(MXR_BIT_VSYNC, _ctx->flags);
+
+   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
return;
-   }

/* disable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
@@ -1035,9 +1034,10 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)

mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);

-   if (ctx->int_en & MXR_INT_EN_VSYNC)
+   if (test_bit(MXR_BIT_VSYNC, >flags)) {
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, 
MXR_INT_CLEAR_VSYNC);
-   mixer_reg_write(res, MXR_INT_EN, ctx->int_en);
+   mixer_reg_writemask(res, MXR_INT_EN, ~0, MXR_INT_EN_VSYNC);
+   }
mixer_win_reset(ctx);
 }

@@ -1056,8 +1056,6 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)
for (i = 0; i < MIXER_WIN_NR; i++)
mixer_win_disable(crtc, i);

-   ctx->int_en = mixer_reg_read(res, MXR_INT_EN);
-
clear_bit(MXR_BIT_POWERED, >flags);

clk_disable_unprepare(res->hdmi);
-- 
1.9.1



[PATCH RESEND 5/6] drm/exynos/mixer: simplify poweron flag

2015-07-09 Thread Andrzej Hajda
The driver uses bool protected by mutex to track power state.
The patch replaces this combo with single bit and atomic bitops.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 52 ++-
 1 file changed, 14 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 53bcb70..453b6bb 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -69,6 +69,10 @@ enum mixer_version_id {
MXR_VER_128_0_0_184,
 };

+enum mixer_flag_bits {
+   MXR_BIT_POWERED,
+};
+
 struct mixer_context {
struct platform_device *pdev;
struct device   *dev;
@@ -76,13 +80,12 @@ struct mixer_context {
struct exynos_drm_crtc  *crtc;
struct exynos_drm_plane planes[MIXER_WIN_NR];
int pipe;
+   unsigned long   flags;
boolinterlace;
-   boolpowered;
boolvp_enabled;
boolhas_sclk;
u32 int_en;

-   struct mutexmixer_mutex;
struct mixer_resources  mixer_res;
enum mixer_version_id   mxr_ver;
wait_queue_head_t   wait_vsync_queue;
@@ -899,7 +902,7 @@ static int mixer_enable_vblank(struct exynos_drm_crtc *crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
struct mixer_resources *res = _ctx->mixer_res;

-   if (!mixer_ctx->powered) {
+   if (!test_bit(MXR_BIT_POWERED, _ctx->flags)) {
mixer_ctx->int_en |= MXR_INT_EN_VSYNC;
return 0;
}
@@ -916,7 +919,7 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
struct mixer_resources *res = _ctx->mixer_res;

-   if (!mixer_ctx->powered) {
+   if (!test_bit(MXR_BIT_POWERED, _ctx->flags)) {
mixer_ctx->int_en &= MXR_INT_EN_VSYNC;
return;
}
@@ -932,12 +935,8 @@ static void mixer_win_commit(struct exynos_drm_crtc *crtc, 
unsigned int win)

DRM_DEBUG_KMS("win: %d\n", win);

-   mutex_lock(_ctx->mixer_mutex);
-   if (!mixer_ctx->powered) {
-   mutex_unlock(_ctx->mixer_mutex);
+   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
return;
-   }
-   mutex_unlock(_ctx->mixer_mutex);

if (win > 1 && mixer_ctx->vp_enabled)
vp_video_buffer(mixer_ctx, win);
@@ -953,12 +952,8 @@ static void mixer_win_disable(struct exynos_drm_crtc 
*crtc, unsigned int win)

DRM_DEBUG_KMS("win: %d\n", win);

-   mutex_lock(_ctx->mixer_mutex);
-   if (!mixer_ctx->powered) {
-   mutex_unlock(_ctx->mixer_mutex);
+   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
return;
-   }
-   mutex_unlock(_ctx->mixer_mutex);

spin_lock_irqsave(>reg_slock, flags);
mixer_vsync_set_update(mixer_ctx, false);
@@ -974,12 +969,8 @@ static void mixer_wait_for_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
int err;

-   mutex_lock(_ctx->mixer_mutex);
-   if (!mixer_ctx->powered) {
-   mutex_unlock(_ctx->mixer_mutex);
+   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
return;
-   }
-   mutex_unlock(_ctx->mixer_mutex);

err = drm_vblank_get(mixer_ctx->drm_dev, mixer_ctx->pipe);
if (err < 0) {
@@ -1007,13 +998,8 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
struct mixer_resources *res = >mixer_res;
int ret;

-   mutex_lock(>mixer_mutex);
-   if (ctx->powered) {
-   mutex_unlock(>mixer_mutex);
+   if (test_bit(MXR_BIT_POWERED, >flags))
return;
-   }
-
-   mutex_unlock(>mixer_mutex);

pm_runtime_get_sync(ctx->dev);

@@ -1045,9 +1031,7 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
}
}

-   mutex_lock(>mixer_mutex);
-   ctx->powered = true;
-   mutex_unlock(>mixer_mutex);
+   set_bit(MXR_BIT_POWERED, >flags);

mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);

@@ -1063,12 +1047,8 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)
struct mixer_resources *res = >mixer_res;
int i;

-   mutex_lock(>mixer_mutex);
-   if (!ctx->powered) {
-   mutex_unlock(>mixer_mutex);
+   if (!test_bit(MXR_BIT_POWERED, >flags))
return;
-   }
-   mutex_unlock(>mixer_mutex);

mixer_stop(ctx);
mixer_regs_dump(ctx);
@@ -1078,9 +1058,7 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)

ctx->int_en = mixer_reg_read(res, MXR_INT_EN);

-   mutex_lock(>mixer_mutex);
-   ctx->powered = false;
-   mutex_unlock(>mixer_mutex);
+   clear_bit(MXR_BIT_POWERED, >flags);

[PATCH RESEND 4/6] drm/exynos/mixer: always update INT_EN cache

2015-07-09 Thread Andrzej Hajda
INT_EN cache field was updated only by mixer_enable_vblank.
The patch adds update also by mixer_disable_vblank function.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index b338a10..53bcb70 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -916,6 +916,11 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
struct mixer_resources *res = _ctx->mixer_res;

+   if (!mixer_ctx->powered) {
+   mixer_ctx->int_en &= MXR_INT_EN_VSYNC;
+   return;
+   }
+
/* disable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
mixer_reg_writemask(res, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
-- 
1.9.1



[PATCH RESEND 3/6] drm/exynos/mixer: correct vsync configuration sequence

2015-07-09 Thread Andrzej Hajda
Specification advises to clear vsync indicator before configuring vsync.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 0686484..b338a10 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -905,8 +905,8 @@ static int mixer_enable_vblank(struct exynos_drm_crtc *crtc)
}

/* enable vsync interrupt */
-   mixer_reg_writemask(res, MXR_INT_EN, MXR_INT_EN_VSYNC,
-   MXR_INT_EN_VSYNC);
+   mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
+   mixer_reg_writemask(res, MXR_INT_EN, ~0, MXR_INT_EN_VSYNC);

return 0;
 }
@@ -917,6 +917,7 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)
struct mixer_resources *res = _ctx->mixer_res;

/* disable vsync interrupt */
+   mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
mixer_reg_writemask(res, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
 }

@@ -1045,6 +1046,8 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)

mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);

+   if (ctx->int_en & MXR_INT_EN_VSYNC)
+   mixer_reg_writemask(res, MXR_INT_STATUS, ~0, 
MXR_INT_CLEAR_VSYNC);
mixer_reg_write(res, MXR_INT_EN, ctx->int_en);
mixer_win_reset(ctx);
 }
-- 
1.9.1



[PATCH RESEND 2/6] drm/exynos/mixer: fix interrupt clearing

2015-07-09 Thread Andrzej Hajda
The driver used incorrect flags to clear interrupt status.
The patch fixes it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index cae98db..0686484 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -718,6 +718,9 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)

/* handling VSYNC */
if (val & MXR_INT_STATUS_VSYNC) {
+   /* vsync interrupt use different bit for read and clear */
+   val |= MXR_INT_CLEAR_VSYNC;
+
/* interlace scan need to check shadow register */
if (ctx->interlace) {
base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
@@ -743,11 +746,6 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)

 out:
/* clear interrupts */
-   if (~val & MXR_INT_EN_VSYNC) {
-   /* vsync interrupt use different bit for read and clear */
-   val &= ~MXR_INT_EN_VSYNC;
-   val |= MXR_INT_CLEAR_VSYNC;
-   }
mixer_reg_write(res, MXR_INT_STATUS, val);

spin_unlock(>reg_slock);
-- 
1.9.1



[PATCH RESEND 1/6] drm/exynos/hdmi: fix edid memory leak

2015-07-09 Thread Andrzej Hajda
edid returned by drm_get_edid should be freed.
The patch fixes it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 99e2864..4a00990 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1064,6 +1064,7 @@ static int hdmi_get_modes(struct drm_connector *connector)
 {
struct hdmi_context *hdata = ctx_from_connector(connector);
struct edid *edid;
+   int ret;

if (!hdata->ddc_adpt)
return -ENODEV;
@@ -1079,7 +1080,11 @@ static int hdmi_get_modes(struct drm_connector 
*connector)

drm_mode_connector_update_edid_property(connector, edid);

-   return drm_add_edid_modes(connector, edid);
+   ret = drm_add_edid_modes(connector, edid);
+
+   kfree(edid);
+
+   return ret;
 }

 static int hdmi_find_phy_conf(struct hdmi_context *hdata, u32 pixel_clock)
-- 
1.9.1



[PATCH RESEND 0/6] drm/exynos: HDMI related fixes

2015-07-09 Thread Andrzej Hajda


Andrzej Hajda (6):
  drm/exynos/hdmi: fix edid memory leak
  drm/exynos/mixer: fix interrupt clearing
  drm/exynos/mixer: correct vsync configuration sequence
  drm/exynos/mixer: always update INT_EN cache
  drm/exynos/mixer: simplify poweron flag
  drm/exynos/mixer: replace MXR_INT_EN register cache with flag

 drivers/gpu/drm/exynos/exynos_hdmi.c  |  7 ++-
 drivers/gpu/drm/exynos/exynos_mixer.c | 80 +--
 2 files changed, 36 insertions(+), 51 deletions(-)

-- 
1.9.1



[Bug 101261] Radeon - Kernel warning when driver is unbound from secondary GPU

2015-07-09 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=101261

Beau V.C. Bellamy  changed:

   What|Removed |Added

Summary|Radeon - Kernel warning |Radeon - Kernel warning
   |when driver is unbound to   |when driver is unbound from
   |secondary GPU   |secondary GPU

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


[Bug 101261] Radeon - Kernel warning when driver is unbound to secondary GPU

2015-07-09 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=101261

--- Comment #2 from Beau V.C. Bellamy  ---
When unbinding the radeon driver from a second GPU in order to bind to the
vfio-pci driver (so it can be used on a virtual machine), the linux kernel will
display several warnings.  It looks like some resources may be double-freed. 
The GPU will otherwise work flawlessly in the VM with full acceleration on the
stock AMD windows drivers.

This actually shows up on all kernels that I've tried: 4.1.0, 3.19, 3.18, etc.

I'm not sure it's related, but the first GPU when running X on the host will
have some difficulties getting OpenGL working (I have a routine that involves a
dance with glxgears and firefox) and will work for some time and then take the
entire system down hard.  If I avoid anything OpenGL/DRM, the system will run
indefinitely.

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


DRM-vmwgfx: Deletion of an unnecessary check before the function call "vfree"

2015-07-09 Thread John Hunter
On Thu, Jul 9, 2015 at 12:55 AM, SF Markus Elfring <
elfring at users.sourceforge.net> wrote:

> > Reviewed-by: Zhao Junwang 
> >
> > kfree will check that.
>
> How does this feedback fit to a check before a call
> of the vfree() function?
>
> I might have made a mistake, the ctl^] lead me to the vfree in mm/nommu.c,
there is also a vfree() function in mm/vmalloc.c.

Anyway, I think the catch is reasonable.


> Regards,
> Markus
>



-- 
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/c688e5f5/attachment.html>


[Bug 101261] Radeon - Kernel warning when driver is unbound to secondary GPU

2015-07-09 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=101261

--- Comment #1 from Beau V.C. Bellamy  ---
Created attachment 182291
  --> https://bugzilla.kernel.org/attachment.cgi?id=182291=edit
Script to unbind and start VM

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


[Bug 101261] New: Radeon - Kernel warning when driver is unbound to secondary GPU

2015-07-09 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=101261

Bug ID: 101261
   Summary: Radeon - Kernel warning when driver is unbound to
secondary GPU
   Product: Drivers
   Version: 2.5
Kernel Version: 4.0.7
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: bellamy.beau at gmail.com
Regression: No

Created attachment 182281
  --> https://bugzilla.kernel.org/attachment.cgi?id=182281=edit
dmesg output

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


[Bug 100541] Since 4.1, the mouse cursor is corrupted after suspend/resume

2015-07-09 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=100541

Christian Casteyde  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
 Resolution|CODE_FIX|PATCH_ALREADY_AVAILABLE

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


[Bug 100541] Since 4.1, the mouse cursor is corrupted after suspend/resume

2015-07-09 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=100541

Christian Casteyde  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #7 from Christian Casteyde  ---
Effectively, these patches fix the problem on 4.1:

drm/radeon: unpin cursor BOs on suspend and pin them again on resume (v2)
drm/radeon: Clean up reference counting and pinning of the cursor BOs

Thanks

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


Wayland and GLES1 (Re: R200 DRM/KMS)

2015-07-09 Thread Steven Newbury


On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote:
> On 09.07.2015 06:01, Steven Newbury wrote:
> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury
> >>>  wrote:
> >>> 
>  Would gles1 be sufficient to run a Wayland compositor, I'm 
>  guessing probably not..?
> >>> 
> >>> If you can find a Wayland compositor that is written to composite
> >>>  with GLES1, that's all you need from the "Wayland side". (Yeah,
> >>> this has nothing to do with Wayland per se.) Compositing in
> >>> itself without any effects is very simple, as long as you get the
> >>> textures up.
> >>> 
> >>> Or, if you find a Wayland compositor written to use desktop
> >>> OpenGL for compositing and does not use features your GL driver
> >>> does not expose, that's good too.
> >>> 
> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> >> 
> > To answer my own question, it seems that is possible.  I wonder if
> > it works with mutter/cogl???
> 
> It does.
> 
> However, your problem seems rather that gnome-shell/mutter doesn't
> support R200 anymore.
Yes, that's true. I wonder if I can revert the incompatible change or better 
create a env variable to revert to the compatible behaviour or something? I'll 
need to take a look...

[I'm going to be posting a lot from my phone, my laptop power jack has just 
broken, again! :-( You'd think after 3.5 decades of making laptops we'd have 
come up with a better design!]
-- 
Sent from my Jolla


[PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver

2015-07-09 Thread Wang J.W.
Hi Mark,

Thank you very much for your review!

From: Mark yao [mailto:mark@rock-chips.com] 
Sent: Wednesday, July 01, 2015 9:59 AM
To: Wang Jianwei-B52261
Cc: David Airlie; daniel.vetter at intel.com; stefan at agner.ch; dri-devel; 
linux-kernel; linux-arm-kernel at lists.infradead.org; Wang Jianwei-B52261
Subject: Re: [PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver

On 2015年06月30日 18:01, Wang J.W. wrote:

From: Jianwei Wang 

This patch add support for Two Dimensional Animation and Compositing Engine 
(2D-ACE) on the Freescale SoCs.

2D-ACE is a Freescale display controller. 2D-ACE describes the functionality of 
the module extremely well its name is a value that cannot be used as a token in 
programming languages.
Instead the valid token "DCU" is used to tag the register names and function 
names.

The Display Controller Unit (DCU) module is a system master that fetches 
graphics stored in internal or external memory and displays them on a TFT LCD 
panel. A wide range of panel sizes is supported and the timing of the interface 
signals is highly configurable.
Graphics are read directly from memory and then blended in real-time, which 
allows for dynamic content creation with minimal CPU intervention.

The features:
(1) Full RGB888 output to TFT LCD panel.
(2) For the current LCD panel, WQVGA "480x272" is supported.
(3) Blending of each pixel using up to 4 source layers dependent on size of 
panel.
(4) Each graphic layer can be placed with one pixel resolution in either axis.
(5) Each graphic layer support RGB565 and RGB888 direct colors without alpha 
channel and BGRA BGRA ARGB1555 direct colors with an alpha channel and 
YUV422 format.
(6) Each graphic layer support alpha blending with 8-bit resolution.

This is a simplified version, only one primary plane, one framebuffer created 
for fbdev, one crtc, one connector for TFT LCD panel, an encoder.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---

Changed in V5

- Update commit message
- Add layer registers initialization
- Remove unused functions
- Rename driver folder
- Move pixel clock control functions to fsl_dcu_drm_drv.c
- remove redundant enable the clock implicitly using regmap
- Add maintainer message

Changed in V4:

-This version doesn't have functionality changed  Just a minor adjustment.

Changed in V3:

- Test driver on Vybrid board and add compatible string
- Remove unused functions
- set default crtc for encoder
- replace legacy functions with atomic help functions
- Set the unique name of the DRM device
- Implement irq handle function for vblank interrupt

Changed in v2:
- Add atomic support
- Modify bindings file
- Rename node for compatibility
- Move platform related code out for compatibility

 .../devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt|  50 +++
 MAINTAINERS|   8 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/fsl-dcu/Kconfig|  17 +
 drivers/gpu/drm/fsl-dcu/Makefile   |   7 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c| 194 +++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h|  30 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 172 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h |  22 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  | 373 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  | 223 
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c|  26 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c  |  42 +++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h  |  17 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c| 192 +++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h|  23 ++
 17 files changed, 1399 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
 create mode 100644 drivers/gpu/drm/fsl-dcu/Kconfig  create mode 100644 
drivers/gpu/drm/fsl-dcu/Makefile  create mode 100644 
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h

diff --git a/Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt 
b/Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
new file mode 100644
index 000..bdc7d5b
--- 

Device enumeration support in libdrm

2015-07-09 Thread Zhou, Jammy
Although I don't like the method of manually iterating sysfs, it seems the last 
resort if we want to avoid introducing libudev dependency.

Besides, you mentioned that you would spend some time on the device enumeration 
interface, do you have some chance to look at it?

Regards,
Jammy

-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com] 
Sent: Thursday, July 09, 2015 12:25 AM
To: Zhou, Jammy
Cc: dri-devel at lists.freedesktop.org
Subject: Re: Device enumeration support in libdrm

Hello Jammy,

On 8 July 2015 at 06:53, Zhou, Jammy  wrote:
> Hi Emil,
>
>
>
> With our previous RFC patches to add interfaces to support GPU device 
> enumeration support in libdrm, the udev mechanism was used. But we 
> found that if we introduce the libudev dependency for libdrm, there 
> will be some problem to run steam application on recent distributions 
> (for example, Ubuntu 14.04 LTS) because of the conflict between the 
> system libudev.so.1 (loaded by libdrm) and the libudev.so.0 (bundled 
> in steam-runtime and loaded by steam application). There are some 
> similar issues as mentioned in the links below. Although we can argue 
> that it is application’s problem, can we get rid of libudev for the 
> device enumeration before Valve can make steam-runtime use system 
> libraries by default? It is much appreciated if you can give some 
> suggestions about how we can support device enumeration with libdrm.
>
I believe I mentioned it before, perhaps I wasn't clear enough. Rather than 
using libudev, manually iterate through sysfs. I agree it's not a not pretty 
solution yet the libdrm code already has much weirder stuff.

Cheers
Emil


[Bug 100541] Since 4.1, the mouse cursor is corrupted after suspend/resume

2015-07-09 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=100541

--- Comment #6 from Michel Dänzer  ---
The mouse cursor corruption should be fixed with the drm-fixes-4.2-wip branch
of http://cgit.freedesktop.org/~agd5f/linux/ .

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


[PATCH] drm/fourcc: Add formats R8, RG88, GR88

2015-07-09 Thread Chad Versace
The Kodi/XBMC developers want to transcode NV12 to RGB with OpenGL
shaders, importing the two source planes through
EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an
R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage.

CC: Peter Frühberger 
Cc: Rainer Hochecker 
Cc: Benjamin Widawsky 
Signed-off-by: Chad Versace 
---

I recently sent a patch series to mesa-dev that uses these new formats:
Subject: [PATCH 0/2] egl,i965: Support importing R8 and GR88 dma_bufs as 
textures
Date: Thu, 9 Jul 2015 01:17:41 -0700


 include/uapi/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 2f295cd..8c5e8b9 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -34,6 +34,13 @@
 /* color index */
 #define DRM_FORMAT_C8  fourcc_code('C', '8', ' ', ' ') /* [7:0] C */

+/* 8 bpp Red */
+#define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
+
+/* 16 bpp RG */
+#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
[15:0] R:G 8:8 little endian */
+#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
[15:0] G:R 8:8 little endian */
+
 /* 8 bpp RGB */
 #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
3:3:2 */
 #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
2:3:3 */
-- 
2.5.0.rc1



[PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver

2015-07-09 Thread Wang J.W.
Hi Mark,

Thank you very much for your review!

> -Original Message-
> From: Wang Jianwei-B52261
> Sent: Thursday, July 09, 2015 9:28 AM
> To: Wang Jianwei-B52261
> Subject: FW: [PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver
> 
> 
> From: Jianwei Wang 
> 
> This patch add support for Two Dimensional Animation and Compositing
> Engine (2D-ACE) on the Freescale SoCs.
> 
> 2D-ACE is a Freescale display controller. 2D-ACE describes the
> functionality of the module extremely well its name is a value that cannot
> be used as a token in programming languages.
> Instead the valid token "DCU" is used to tag the register names and
> function names.
> 
> The Display Controller Unit (DCU) module is a system master that fetches
> graphics stored in internal or external memory and displays them on a TFT
> LCD panel. A wide range of panel sizes is supported and the timing of the
> interface signals is highly configurable.
> Graphics are read directly from memory and then blended in real-time,
> which allows for dynamic content creation with minimal CPU intervention.
> 
> The features:
> (1) Full RGB888 output to TFT LCD panel.
> (2) For the current LCD panel, WQVGA "480x272" is supported.
> (3) Blending of each pixel using up to 4 source layers dependent on size
> of panel.
> (4) Each graphic layer can be placed with one pixel resolution in either
> axis.
> (5) Each graphic layer support RGB565 and RGB888 direct colors without
> alpha channel and BGRA BGRA ARGB1555 direct colors with an alpha
> channel and YUV422 format.
> (6) Each graphic layer support alpha blending with 8-bit resolution.
> 
> This is a simplified version, only one primary plane, one framebuffer
> created for fbdev, one crtc, one connector for TFT LCD panel, an encoder.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> ---
> 
> Changed in V5
> 
> - Update commit message
> - Add layer registers initialization
> - Remove unused functions
> - Rename driver folder
> - Move pixel clock control functions to fsl_dcu_drm_drv.c
> - remove redundant enable the clock implicitly using regmap
> - Add maintainer message
> 
> Changed in V4:
> 
> -This version doesn't have functionality changed  Just a minor adjustment.
> 
> Changed in V3:
> 
> - Test driver on Vybrid board and add compatible string
> - Remove unused functions
> - set default crtc for encoder
> - replace legacy functions with atomic help functions
> - Set the unique name of the DRM device
> - Implement irq handle function for vblank interrupt
> 
> Changed in v2:
> - Add atomic support
> - Modify bindings file
> - Rename node for compatibility
> - Move platform related code out for compatibility
> 
>  .../devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt|  50 +++
>  MAINTAINERS|   8 +
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/fsl-dcu/Kconfig|  17 +
>  drivers/gpu/drm/fsl-dcu/Makefile   |   7 +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c| 194 +++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h|  30 ++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 172 ++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h |  22 ++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  | 373
> +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  | 223 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c|  26 ++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c  |  42 +++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h  |  17 +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c| 192 +++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h|  23 ++
>  17 files changed, 1399 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/drm/fsl-
> dcu/fsl,dcu.txt
>  create mode 100644 drivers/gpu/drm/fsl-dcu/Kconfig  create mode 100644
> drivers/gpu/drm/fsl-dcu/Makefile  create mode 100644 drivers/gpu/drm/fsl-
> dcu/fsl_dcu_drm_connector.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h
> 
> diff --git a/Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
> b/Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
> new file mode 100644
> index 000..bdc7d5b
> --- 

[PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver

2015-07-09 Thread Wang J.W.
able_vblank(struct drm_device *dev, int

+crtc) { }

+

+static const struct file_operations fsl_dcu_drm_fops = {

+  .owner = THIS_MODULE,

+  .open  = drm_open,

+  .release   = drm_release,

+  .unlocked_ioctl = drm_ioctl,

+#ifdef CONFIG_COMPAT

+  .compat_ioctl  = drm_compat_ioctl,

+#endif

+  .poll  = drm_poll,

+  .read  = drm_read,

+  .llseek= no_llseek,

+  .mmap  = drm_gem_cma_mmap,

+};

+

+static struct drm_driver fsl_dcu_drm_driver = {

+  .driver_features   = DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET

+ | DRIVER_PRIME,

Your patch support atomic, I think driver_features need add DRIVER_ATOMIC

Ok!



+  .load  = fsl_dcu_load,

+  .unload= fsl_dcu_unload,

+  .preclose  = fsl_dcu_drm_preclose,

+  .irq_handler   = fsl_dcu_drm_irq,

+  .get_vblank_counter= drm_vblank_count,

+  .enable_vblank = fsl_dcu_drm_enable_vblank,

+  .disable_vblank= fsl_dcu_drm_disable_vblank,

+  .gem_free_object   = drm_gem_cma_free_object,

+  .gem_vm_ops= _gem_cma_vm_ops,

+  .prime_handle_to_fd= drm_gem_prime_handle_to_fd,

+  .prime_fd_to_handle= drm_gem_prime_fd_to_handle,

+  .gem_prime_import  = drm_gem_prime_import,

+  .gem_prime_export  = drm_gem_prime_export,

+  .gem_prime_get_sg_table= drm_gem_cma_prime_get_sg_table,

+  .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,

+  .gem_prime_vmap= drm_gem_cma_prime_vmap,

+  .gem_prime_vunmap  = drm_gem_cma_prime_vunmap,

+  .gem_prime_mmap= drm_gem_cma_prime_mmap,

+  .dumb_create   = drm_gem_cma_dumb_create,

+  .dumb_map_offset   = drm_gem_cma_dumb_map_offset,

+  .dumb_destroy  = drm_gem_dumb_destroy,

+  .fops  = _dcu_drm_fops,

+  .name  = "fsl-dcu-drm",

+  .desc  = "Freescale DCU DRM",

+  .date  = "20150213",

+  .major = 1,

+  .minor = 0,

+};

+

+#ifdef CONFIG_PM_SLEEP

+static void dcu_pixclk_disable(void)

+{

+  struct regmap *scfg_regmap;

+

+  scfg_regmap = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg");

+  if (IS_ERR(scfg_regmap)) {

+ pr_err("No syscfg phandle specified\n");

+ return;

+  }

+

+  regmap_write(scfg_regmap, SCFG_PIXCLKCR, PXCK_DISABLE); }

+

+static int fsl_dcu_drm_pm_suspend(struct device *dev) {

+  struct fsl_dcu_drm_device *fsl_dev = dev_get_drvdata(dev);

Andrzej Hajda told me at my drm driver:

  drm_dev can be NULL here, it can happen when system is suspended

  before all components are bound. It can also contain invalid pointer

  if after successfull drm initialization de-initialization happens for

  some reason.



  Some workaround is to check for null here and set drvdata to null on

  master unbind. But I guess it should be protected somehow to avoid races

  in accessing drvdata.



You didn't use components, but maybe fsl_dev can be NULL for some reason as 
Andrzej said.



--

ï¼­ark



Ok, I’ll update these soon.



--

BR.

Jianwei
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150709/8a809d42/attachment-0001.html>


R200 DRM/KMS

2015-07-09 Thread Emil Velikov
Hi Steven,

A couple of more (wild) ideas, below but first...

On 8 July 2015 at 17:48, Steven Newbury  wrote:
> On Wed, 2015-07-08 at 17:10 +0100, Emil Velikov wrote:
>> On 8 July 2015 at 14:55, Alex Deucher  wrote:
>> > On Wed, Jul 8, 2015 at 9:53 AM, Steven Newbury <
>> > steve at snewbury.org.uk> wrote:
>> > >
>> > >
>> > > On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
>> > > > On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury <
>> > > > steve at snewbury.org.uk> wrote:
>> > > > >
>> > > > >
>> > > > > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
>> > > > > > On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <
>> > > > > > steve at snewbury.org.uk> wrote:
>> > > > > > >
>> > > > > > > I've tried an xserver-1.16, and ddx, libdrm without LTO
>> > > > > > > and with
>> > > > > > > gcc4.9.  Exactly the same thing.  I wondered whether the
>> > > > > > > unused i810
>> > > > > > > could be interfering but triggering a device "remove"
>> > > > > > > before starting
>> > > > > > > X made no difference.
>> > > > > > >
I've completely missed out on this - you have a i810 in there ? Bth,
I'm not sure how well (if any) our userspace works when mixing UMS and
KMS drivers. Toggling off it in the BIOS, blacklisting the kernel
module, checking if it's the boot vga and if X gets it right are nice
things to test/try.

[snip]
> Sitting on a KMS console, "systemctl start gdm", no plymouth
> installed.
Don't know what gdm is up-to these days but a while back it used to
try bringing one X session for the greeter, quickly tear it down and
bring another one for the desktop. Not a gdm person so don't quote me
on that :-)
Yet if that is (roughly) still the case, a likely race condition is on.

>  It's just during Xserver initialisation that
> drmSetInterfaceVersion() fails.  AFAIK Xserver startup is entirely
> single process, single thread.  I've written a little test utility
> which works fine on the system in question.
>
> Compile attached file with:
> gcc -O2 -o test-drm test-drm.c $(pkg-config --cflags libdrm) $(pkg
> -config --libs libdrm)
>
Your test utility seems to do a lot more than the few lines in
radeon_kms.c. Would it be possible that you're misinterpreted the
output (relative to the Xorg.log) ? I know I would :-)

>
>> Personally I would add a healthy amount of printk/printf though the
>> kernel drm + radeon and the ddx.
>
> I guess it doesn't really matter since patching out the code "fixes"
> it...
As you wish. Personally I tend to give it a bit more before giving up.

As this is getting a bit long/messy I'd suspect that a bugzilla entry
with information/logs might be good. It's up-to you, as I won't be
able to help much more.

Good luck,
Emil