[PATCH] Documentation/dma-buf-sharing.txt: update API descriptions

2014-05-20 Thread Bjorn Helgaas
On Tue, May 20, 2014 at 9:43 PM, Sumit Semwal  
wrote:
> Hi Bjorn,
>
> On 21 May 2014 04:50, Bjorn Helgaas  wrote:
>> On Wed, May 14, 2014 at 08:49:43AM +0900, Gioh Kim wrote:
>>> Update some descriptions for API arguments and descriptions.
>>>
>>> Signed-off-by: Gioh Kim 
>>
>> I applied this to my "dma-api" branch for v3.16, thanks!
> As always, I would queue this up for my dma-buf pull request, along
> with other dma-buf changes.

OK, I dropped this one.

>>> ---
>>>  Documentation/dma-buf-sharing.txt |   14 --
>>>  1 file changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/Documentation/dma-buf-sharing.txt 
>>> b/Documentation/dma-buf-sharing.txt
>>> index 505e711..aadd901 100644
>>> --- a/Documentation/dma-buf-sharing.txt
>>> +++ b/Documentation/dma-buf-sharing.txt
>>> @@ -56,10 +56,10 @@ The dma_buf buffer sharing API usage contains the 
>>> following steps:
>>>size_t size, int flags,
>>>const char *exp_name)
>>>
>>> -   If this succeeds, dma_buf_export allocates a dma_buf structure, and 
>>> returns a
>>> -   pointer to the same. It also associates an anonymous file with this 
>>> buffer,
>>> -   so it can be exported. On failure to allocate the dma_buf object, it 
>>> returns
>>> -   NULL.
>>> +   If this succeeds, dma_buf_export_named allocates a dma_buf structure, 
>>> and
>>> +   returns a pointer to the same. It also associates an anonymous file 
>>> with this
>>> +   buffer, so it can be exported. On failure to allocate the dma_buf 
>>> object,
>>> +   it returns NULL.
>>>
>>> 'exp_name' is the name of exporter - to facilitate information while
>>> debugging.
>>> @@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the 
>>> following steps:
>>> drivers and/or processes.
>>>
>>> Interface:
>>> -  int dma_buf_fd(struct dma_buf *dmabuf)
>>> +  int dma_buf_fd(struct dma_buf *dmabuf, int flags)
>>>
>>> This API installs an fd for the anonymous file associated with this 
>>> buffer;
>>> returns either 'fd', or error.
>>> @@ -157,7 +157,9 @@ to request use of buffer for allocation.
>>> "dma_buf->ops->" indirection from the users of this interface.
>>>
>>> In struct dma_buf_ops, unmap_dma_buf is defined as
>>> -  void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table 
>>> *);
>>> +  void (*unmap_dma_buf)(struct dma_buf_attachment *,
>>> +struct sg_table *,
>>> +enum dma_data_direction);
>>>
>>> unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like
>>> map_dma_buf, this API also must be implemented by the exporter.
>>> --
>>> 1.7.9.5
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>
> --
> Thanks and regards,
>
> Sumit Semwal
> Graphics Engineer - Graphics working group
> Linaro.org ? Open source software for ARM SoCs


[Bug 78987] black screen when trying to enable external VGA screen on Trinity APU laptop

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78987

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and xrandr --verbose output.

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


[Bug 78987] New: black screen when trying to enable external VGA screen on Trinity APU laptop

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78987

  Priority: medium
Bug ID: 78987
  Assignee: dri-devel at lists.freedesktop.org
   Summary: black screen when trying to enable external VGA screen
on Trinity APU laptop
  Severity: major
Classification: Unclassified
OS: All
  Reporter: dev at lynxeye.de
  Hardware: Other
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 99447
  --> https://bugs.freedesktop.org/attachment.cgi?id=99447&action=edit
dmesg from failing machine

Plugging in an VGA monitor and trying to enable it results in black screen on
both the internal laptop display as well as the external VGA monitor.

The graphics is dead after this, I have not found any way to restore the
screen. However the machine is still responding to ssh and I was able to pick
up an quite interesting dmesg snapshot.

If you need me to test patches or need any other information, just ping me.

-- 
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/20140520/09f65a76/attachment.html>


[Bug 75917] backlight switches off when starting X - since kernel-3.13

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=75917

--- Comment #11 from nl at gnuffy.net ---
(In reply to comment #10)
> Created attachment 99427 [details] [review]
> possible fix v2

> Does this patch work any better?

No, pretty much the same behaviour as the first version here. The backlight
switches off when X starts, and comes backs ~5 seconds later. (same delay in
restoring backlight after resume from suspend)

-- 
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/20140520/0c30060b/attachment-0001.html>


[PATCH 7/8] radeon: Out of line radeon_get_ib_value

2014-05-20 Thread Christian König
Yeah, agree. That function is quite critical for command stream parsing 
and patching.

Christian.

Am 20.05.2014 18:16, schrieb Marek Ol??k:
> I think the function should stay in the header file. It's used in
> performance-critical code, so we want it to be inlined.
>
> Marek
>
> On Fri, May 16, 2014 at 11:43 PM, Andi Kleen  wrote:
>> From: Andi Kleen 
>>
>> Saves about 5k of text
>>
>> textdata bss dec hex filename
>> 140803602008168 1507328 1759585610c7dd0 vmlinux-before-radeon
>> 140749782008168 1507328 1759047410c68ca vmlinux-radeon
>>
>> Cc: alexander.deucher at amd.com
>> Cc: dri-devel at lists.freedesktop.org
>> Signed-off-by: Andi Kleen 
>> ---
>>   drivers/gpu/drm/radeon/radeon.h| 10 +-
>>   drivers/gpu/drm/radeon/radeon_device.c |  9 +
>>   2 files changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon.h 
>> b/drivers/gpu/drm/radeon/radeon.h
>> index 6852861..8cae409 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -1032,15 +1032,7 @@ struct radeon_cs_parser {
>>  struct ww_acquire_ctx   ticket;
>>   };
>>
>> -static inline u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
>> -{
>> -   struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
>> -
>> -   if (ibc->kdata)
>> -   return ibc->kdata[idx];
>> -   return p->ib.ptr[idx];
>> -}
>> -
>> +u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx);
>>
>>   struct radeon_cs_packet {
>>  unsignedidx;
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index 0e770bb..1cbd171 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -112,6 +112,15 @@ bool radeon_is_px(struct drm_device *dev)
>>  return false;
>>   }
>>
>> +u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
>> +{
>> +   struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
>> +
>> +   if (ibc->kdata)
>> +   return ibc->kdata[idx];
>> +   return p->ib.ptr[idx];
>> +}
>> +
>>   /**
>>* radeon_program_register_sequence - program an array of registers.
>>*
>> --
>> 1.9.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Bug 78453] [HAWAII] Get acceleration working

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78453

--- Comment #42 from vincent  ---
There is 4 calls to radeon_bo_map outside of si_get_backend_mask, corresponding
to dummy shader upload. There is only one buffer_map(READ), in
si_get_backend_mask, right after the buffer_map(WRITE) from
si_get_backend_mask.

-- 
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/20140520/c4098903/attachment.html>


[Bug 78453] [HAWAII] Get acceleration working

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78453

--- Comment #41 from vincent  ---
If I comment the block that does buffer_map/unmap, eglinfo does not hang the
gpu (although I'm not sure if it's safe). However it doesnt fix
egltri_screen/eglgears_screen.

-- 
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/20140520/20baed8f/attachment.html>


[Bug 78453] [HAWAII] Get acceleration working

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78453

--- Comment #40 from vincent  ---
Hang occurs in si_get_backend_mask in r600_hw_context.c, line 89:


results = ctx->b.ws->buffer_map(buffer->cs_buf, ctx->b.rings.gfx.cs,
PIPE_TRANSFER_READ);

It looks like the packet being sent does not work for Hawaii.

-- 
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/20140520/974f5bf0/attachment.html>


[Bug 78453] [HAWAII] Get acceleration working

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78453

--- Comment #39 from vincent  ---
Hang occurs in radeonsi_screen_create,
src/gallium/drivers/radeonsi/radeonsi_pipe:line 684

"rscreen->b.aux_context = rscreen->b.b.context_create(&rscreen->b.b, NULL);"

-- 
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/20140520/b57e2793/attachment.html>


[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=72685

--- Comment #17 from smoki  ---
 I can confirm this with Radeon 8400, hyperz leaves those artifatcs with hyperz
enabled... but actually i dont think hyperz is at most quilty here, because
first of all rendering on that scene must be proper and actually it is not even
with hyperz disabled as i mention in bug 77785 :). I somehow tend to think
hyperz just likes proper rendering, otherwise when it is not there will be bugs
like this ;).

-- 
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/20140520/8b6604e9/attachment.html>


[Intel-gfx] [PATCH 3/3] drm/i915: Re-enable vblank irqs for already active pipes

2014-05-20 Thread Daniel Vetter
On Tue, May 20, 2014 at 05:20:05PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrj?l? 
> 
> If a pipe is already active when we init/resume there might not be a
> full modeset afterwards so drm_vblank_on() may not get called. In such
> a case if someone is holding a vblank reference across a suspend/resume
> cycle drm_vblank_get() called after resuming won't re-enable the vblank
> interrupts.
> 
> So in order to make sure vblank interrupts get re-enabled post-resume,
> call drm_vblank_on() in intel_sanitize_crtc() if the crtc is already
> active.
> 
> v2: Also drm_vblank_off() if the pipe got disabled magically
> 
> Signed-off-by: Ville Syrj?l? 

This seems to duct-tape over the funny failure I'm seeing on my snb where
kms_flip/vblank-vs-modeset|dpms-suspend work nicely, but
kms_flip/vblank-vs-suspend has some totally hilarious random vblank frame
counter after the modeset.

Testecase: igt/kms_flip/vblank-vs-suspend
Tested-by: Daniel Vetter 

Now the problem I have: We already call this in the crtc_enable hook. Why
does calling this here again add the necessary magic?

/me has no clue

Cheers, Daniel
> ---
>  drivers/gpu/drm/i915/intel_display.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 9420f4f..2e9f0b0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11708,6 +11708,12 @@ static void intel_sanitize_crtc(struct intel_crtc 
> *crtc)
>   reg = PIPECONF(crtc->config.cpu_transcoder);
>   I915_WRITE(reg, I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK);
>  
> + /* restore vblank interrupts to correct state */
> + if (crtc->active)
> + drm_vblank_on(dev, crtc->pipe);
> + else
> + drm_vblank_off(dev, crtc->pipe);
> +
>   /* We need to sanitize the plane -> pipe mapping first because this will
>* disable the crtc (and hence change the state) if it is wrong. Note
>* that gen4+ has a fixed plane -> pipe mapping.  */
> -- 
> 1.8.5.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


[Bug 78453] [HAWAII] Get acceleration working

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78453

--- Comment #38 from vincent  ---
Narrowing further, a hang occurs when calling 

nplat->create_display(dpy->PlatformDisplay, dpy->Options.UseFallback);

in egl_g3d.c:539

-- 
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/20140520/b9966bbd/attachment.html>


[Bug 78453] [HAWAII] Get acceleration working

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78453

--- Comment #37 from vincent  ---
in eglinfo it's eglInitialize that makes the gpu hangs apparently.

With some investigation using gdb, a (the ?) gpu stall occurs with the
following calls :


eglInitialize
-> _eglMatchDriver
--> _eglMatchAndInitialize
---> mod->Driver->API.Initialize(mod->Driver, dpy)

I'm trying to narrow down the issue.

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


[PATCH 5/5] drm/edid: Parse and handle HDMI deep color modes.

2014-05-20 Thread Alex Deucher
From: Mario Kleiner 

Check the HDMI cea block for deep color mode bits. If available,
assign the highest supported bpc for a hdmi display, corresponding
to the given deep color modes.

Signed-off-by: Mario Kleiner 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/drm_edid.c | 110 -
 include/drm/drm_edid.h |   5 +++
 2 files changed, 113 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7a4fd2e..c63f305 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3424,16 +3424,116 @@ bool drm_rgb_quant_range_selectable(struct edid *edid)
 EXPORT_SYMBOL(drm_rgb_quant_range_selectable);

 /**
+ * drm_assign_hdmi_deep_color_info - detect whether monitor supports
+ * hdmi deep color modes and update drm_display_info if so.
+ *
+ * @edid: monitor EDID information
+ * @info: Updated with maximum supported deep color bpc and color format
+ *if deep color supported.
+ *
+ * Parse the CEA extension according to CEA-861-B.
+ * Return true if HDMI deep color supported, false if not or unknown.
+ */
+static bool drm_assign_hdmi_deep_color_info(struct edid *edid,
+struct drm_display_info *info,
+struct drm_connector *connector)
+{
+   u8 *edid_ext, *hdmi;
+   int i;
+   int start_offset, end_offset;
+   unsigned int dc_bpc = 0;
+
+   edid_ext = drm_find_cea_extension(edid);
+   if (!edid_ext)
+   return false;
+
+   if (cea_db_offsets(edid_ext, &start_offset, &end_offset))
+   return false;
+
+   /*
+* Because HDMI identifier is in Vendor Specific Block,
+* search it from all data blocks of CEA extension.
+*/
+   for_each_cea_db(edid_ext, i, start_offset, end_offset) {
+   if (cea_db_is_hdmi_vsdb(&edid_ext[i])) {
+   /* HDMI supports at least 8 bpc */
+   info->bpc = 8;
+
+   hdmi = &edid_ext[i];
+   if (cea_db_payload_len(hdmi) < 6)
+   return false;
+
+   if (hdmi[6] & DRM_EDID_HDMI_DC_30) {
+   dc_bpc = 10;
+   DRM_DEBUG("%s: HDMI sink does deep color 30.\n",
+ 
drm_get_connector_name(connector));
+   }
+
+   if (hdmi[6] & DRM_EDID_HDMI_DC_36) {
+   dc_bpc = 12;
+   DRM_DEBUG("%s: HDMI sink does deep color 36.\n",
+ 
drm_get_connector_name(connector));
+   }
+
+   if (hdmi[6] & DRM_EDID_HDMI_DC_48) {
+   dc_bpc = 16;
+   DRM_DEBUG("%s: HDMI sink does deep color 48.\n",
+ 
drm_get_connector_name(connector));
+   }
+
+   if (dc_bpc > 0) {
+   DRM_DEBUG("%s: Assigning HDMI sink color depth 
as %d bpc.\n",
+ 
drm_get_connector_name(connector), dc_bpc);
+   info->bpc = dc_bpc;
+
+   /*
+* Deep color support mandates RGB444 support 
for all video
+* modes and forbids YCRCB422 support for all 
video modes per
+* HDMI 1.3 spec.
+*/
+   info->color_formats = DRM_COLOR_FORMAT_RGB444;
+
+   /* YCRCB444 is optional according to spec. */
+   if (hdmi[6] & DRM_EDID_HDMI_DC_Y444) {
+   info->color_formats |= 
DRM_COLOR_FORMAT_YCRCB444;
+   DRM_DEBUG("%s: HDMI sink does YCRCB444 
in deep color.\n",
+ 
drm_get_connector_name(connector));
+   }
+
+   /*
+* Spec says that if any deep color mode is 
supported at all,
+* then deep color 36 bit must be supported.
+*/
+   if (!(hdmi[6] & DRM_EDID_HDMI_DC_36)) {
+   DRM_DEBUG("%s: HDMI sink should do 
DC_36, but does not!\n",
+ 
drm_get_connector_name(connector));
+   }
+
+   return true;
+   }
+   else {
+   DRM_DEBUG("%s: No deep color support on this 
HDMI sink.\n",
+

[PATCH 4/5] drm/radeon: Limit hdmi deep color bit depth to 12 bpc.

2014-05-20 Thread Alex Deucher
From: Mario Kleiner 

DCE-4/5/6 can't support more than 12 bpc deep color over hdmi,
so clamp to 12 bpc when a hdmi deep color capable display is
connected. This even makes sense on DCE-8+, which could do up
to 16 bpc, as driving with more than 12 bpc would only waste
video bandwidth as long as we don't support framebuffers with
more than 12 bpc depth.

On pre-DCE4 we clamp hdmi bit depth to 8 bpc, as those asics
don't support hdmi deep color.

Signed-off-by: Mario Kleiner 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index ea50e0a..c1846d4 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -145,6 +145,31 @@ int radeon_get_monitor_bpc(struct drm_connector *connector)
}
break;
}
+
+   if (drm_detect_hdmi_monitor(radeon_connector->edid)) {
+   /* hdmi deep color only implemented on DCE4+ */
+   if ((bpc > 8) && !ASIC_IS_DCE4(rdev)) {
+   DRM_DEBUG("%s: HDMI deep color %d bpc unsupported. 
Using 8 bpc.\n",
+ drm_get_connector_name(connector), 
bpc);
+   bpc = 8;
+   }
+
+   /*
+* Pre DCE-8 hw can't handle > 12 bpc, and more than 12 bpc 
doesn't make
+* much sense without support for > 12 bpc framebuffers. RGB 
4:4:4 at
+* 12 bpc is always supported on hdmi deep color sinks, as this 
is
+* required by the HDMI-1.3 spec. Clamp to a safe 12 bpc 
maximum.
+*/
+   if (bpc > 12) {
+   DRM_DEBUG("%s: HDMI deep color %d bpc unsupported. 
Using 12 bpc.\n",
+ drm_get_connector_name(connector), 
bpc);
+   bpc = 12;
+   }
+   }
+
+   DRM_DEBUG("%s: Display bpc=%d, returned bpc=%d\n",
+ drm_get_connector_name(connector), 
connector->display_info.bpc, bpc);
+
return bpc;
 }

-- 
1.8.3.1



[PATCH 3/5] drm/radeon: Setup HDMI_CONTROL for hdmi deep color gcp's.

2014-05-20 Thread Alex Deucher
From: Mario Kleiner 

Program HDMI_CONTROL to send general control packets
for hdmi deep color mode signalling at every video
frame if bpc > 8.

This is only supported on evergreen / DCE-4 and later.

Signed-off-by: Mario Kleiner 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen_hdmi.c | 38 +
 drivers/gpu/drm/radeon/evergreend.h |  3 ++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 05b0c95..f9842ae 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -293,10 +293,13 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+   struct drm_connector *connector = 
radeon_get_connector_for_encoder(encoder);
u8 buffer[HDMI_INFOFRAME_HEADER_SIZE + HDMI_AVI_INFOFRAME_SIZE];
struct hdmi_avi_infoframe frame;
uint32_t offset;
ssize_t err;
+   uint32_t val;
+   int bpc = 8;

if (!dig || !dig->afmt)
return;
@@ -322,6 +325,41 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode

WREG32(AFMT_AUDIO_CRC_CONTROL + offset, 0x1000);

+   /* hdmi deep color mode general control packets setup, if bpc > 8 */
+   if (encoder->crtc) {
+   struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
+   bpc = radeon_crtc->bpc;
+   }
+
+   val = RREG32(HDMI_CONTROL + offset);
+   val &= ~HDMI_DEEP_COLOR_ENABLE;
+   val &= ~HDMI_DEEP_COLOR_DEPTH_MASK;
+
+   switch (bpc) {
+   case 0:
+   case 6:
+   case 8:
+   case 16:
+   default:
+   DRM_DEBUG("%s: Disabling hdmi deep color for %d bpc.\n",
+drm_get_connector_name(connector), 
bpc);
+   break;
+   case 10:
+   val |= HDMI_DEEP_COLOR_ENABLE;
+   val |= HDMI_DEEP_COLOR_DEPTH(HDMI_30BIT_DEEP_COLOR);
+   DRM_DEBUG("%s: Enabling hdmi deep color 30 for 10 
bpc.\n",
+drm_get_connector_name(connector));
+   break;
+   case 12:
+   val |= HDMI_DEEP_COLOR_ENABLE;
+   val |= HDMI_DEEP_COLOR_DEPTH(HDMI_36BIT_DEEP_COLOR);
+   DRM_DEBUG("%s: Enabling hdmi deep color 36 for 12 
bpc.\n",
+drm_get_connector_name(connector));
+   break;
+   }
+
+   WREG32(HDMI_CONTROL + offset, val);
+
WREG32(HDMI_VBI_PACKET_CONTROL + offset,
   HDMI_NULL_SEND | /* send null packets when required */
   HDMI_GC_SEND | /* send general control packets */
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index f9c7963..b066d67 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -517,10 +517,11 @@
 #   define HDMI_ERROR_ACK(1 << 8)
 #   define HDMI_ERROR_MASK   (1 << 9)
 #   define HDMI_DEEP_COLOR_ENABLE(1 << 24)
-#   define HDMI_DEEP_COLOR_DEPTH (((x) & 3) << 28)
+#   define HDMI_DEEP_COLOR_DEPTH(x)  (((x) & 3) << 28)
 #   define HDMI_24BIT_DEEP_COLOR 0
 #   define HDMI_30BIT_DEEP_COLOR 1
 #   define HDMI_36BIT_DEEP_COLOR 2
+#   define HDMI_DEEP_COLOR_DEPTH_MASK(3 << 28)
 #define HDMI_STATUS  0x7034
 #   define HDMI_ACTIVE_AVMUTE(1 << 0)
 #   define HDMI_AUDIO_PACKET_ERROR   (1 << 16)
-- 
1.8.3.1



[PATCH 2/5] drm/radeon: fix pll setup for hdmi deep color

2014-05-20 Thread Alex Deucher
Need to adjust the pll up for deep color modes.
Additionally, the atom bpc defines were wrong in certain
cases.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c | 36 ++
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index c96d1d5..82ee6b0 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -559,6 +559,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
u32 adjusted_clock = mode->clock;
int encoder_mode = atombios_get_encoder_mode(encoder);
u32 dp_clock = mode->clock;
+   u32 clock = mode->clock;
int bpc = radeon_crtc->bpc;
bool is_duallink = radeon_dig_monitor_is_duallink(encoder, mode->clock);

@@ -634,6 +635,24 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
radeon_crtc->pll_flags |= RADEON_PLL_USE_REF_DIV;
}

+   /* adjust pll for deep color modes */
+   if (encoder_mode == ATOM_ENCODER_MODE_HDMI) {
+   switch (bpc) {
+   case 8:
+   default:
+   break;
+   case 10:
+   clock = (clock * 5) / 4;
+   break;
+   case 12:
+   clock = (clock * 3) / 2;
+   break;
+   case 16:
+   clock = clock * 2;
+   break;
+   }
+   }
+
/* DCE3+ has an AdjustDisplayPll that will adjust the pixel clock
 * accordingly based on the encoder/transmitter to work around
 * special hw requirements.
@@ -655,7 +674,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
switch (crev) {
case 1:
case 2:
-   args.v1.usPixelClock = cpu_to_le16(mode->clock 
/ 10);
+   args.v1.usPixelClock = cpu_to_le16(clock / 10);
args.v1.ucTransmitterID = 
radeon_encoder->encoder_id;
args.v1.ucEncodeMode = encoder_mode;
if (radeon_crtc->ss_enabled && 
radeon_crtc->ss.percentage)
@@ -667,7 +686,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
adjusted_clock = 
le16_to_cpu(args.v1.usPixelClock) * 10;
break;
case 3:
-   args.v3.sInput.usPixelClock = 
cpu_to_le16(mode->clock / 10);
+   args.v3.sInput.usPixelClock = cpu_to_le16(clock 
/ 10);
args.v3.sInput.ucTransmitterID = 
radeon_encoder->encoder_id;
args.v3.sInput.ucEncodeMode = encoder_mode;
args.v3.sInput.ucDispPllConfig = 0;
@@ -681,10 +700,6 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
args.v3.sInput.usPixelClock = 
cpu_to_le16(dp_clock / 10);
} else if (radeon_encoder->devices & 
(ATOM_DEVICE_DFP_SUPPORT)) {
struct radeon_encoder_atom_dig *dig = 
radeon_encoder->enc_priv;
-   if (encoder_mode == 
ATOM_ENCODER_MODE_HDMI)
-   /* deep color support */
-   args.v3.sInput.usPixelClock =
-   
cpu_to_le16((mode->clock * bpc / 8) / 10);
if (dig->coherent_mode)
args.v3.sInput.ucDispPllConfig 
|=

DISPPLL_CONFIG_COHERENT_MODE;
@@ -871,6 +886,11 @@ static void atombios_crtc_program_pll(struct drm_crtc 
*crtc,
args.v5.ucMiscInfo |= 
PIXEL_CLOCK_V5_MISC_HDMI_24BPP;
break;
case 10:
+   /* yes this is correct, the atom define 
is wrong */
+   args.v5.ucMiscInfo |= 
PIXEL_CLOCK_V5_MISC_HDMI_32BPP;
+   break;
+   case 12:
+   /* yes this is correct, the atom define 
is wrong */
args.v5.ucMiscInfo |= 
PIXEL_CLOCK_V5_MISC_HDMI_30BPP;
break;
}
@@ -895,10 +915,10 @@ static void atombios_crtc_program_pll(struct drm_crtc 
*crtc,
args.v6.ucMiscInfo |= 
PIXEL_CLOCK_V6_MISC_HDMI_24BPP;
   

[PATCH 1/5] drm/radeon: only apply hdmi bpc pll flags when encoder mode is hdmi

2014-05-20 Thread Alex Deucher
May fix display issues with non-HDMI displays.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c | 48 ++
 1 file changed, 26 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index fb187c7..c96d1d5 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -864,14 +864,16 @@ static void atombios_crtc_program_pll(struct drm_crtc 
*crtc,
args.v5.ucMiscInfo = 0; /* HDMI depth, etc. */
if (ss_enabled && (ss->type & ATOM_EXTERNAL_SS_MASK))
args.v5.ucMiscInfo |= 
PIXEL_CLOCK_V5_MISC_REF_DIV_SRC;
-   switch (bpc) {
-   case 8:
-   default:
-   args.v5.ucMiscInfo |= 
PIXEL_CLOCK_V5_MISC_HDMI_24BPP;
-   break;
-   case 10:
-   args.v5.ucMiscInfo |= 
PIXEL_CLOCK_V5_MISC_HDMI_30BPP;
-   break;
+   if (encoder_mode == ATOM_ENCODER_MODE_HDMI) {
+   switch (bpc) {
+   case 8:
+   default:
+   args.v5.ucMiscInfo |= 
PIXEL_CLOCK_V5_MISC_HDMI_24BPP;
+   break;
+   case 10:
+   args.v5.ucMiscInfo |= 
PIXEL_CLOCK_V5_MISC_HDMI_30BPP;
+   break;
+   }
}
args.v5.ucTransmitterID = encoder_id;
args.v5.ucEncoderMode = encoder_mode;
@@ -886,20 +888,22 @@ static void atombios_crtc_program_pll(struct drm_crtc 
*crtc,
args.v6.ucMiscInfo = 0; /* HDMI depth, etc. */
if (ss_enabled && (ss->type & ATOM_EXTERNAL_SS_MASK))
args.v6.ucMiscInfo |= 
PIXEL_CLOCK_V6_MISC_REF_DIV_SRC;
-   switch (bpc) {
-   case 8:
-   default:
-   args.v6.ucMiscInfo |= 
PIXEL_CLOCK_V6_MISC_HDMI_24BPP;
-   break;
-   case 10:
-   args.v6.ucMiscInfo |= 
PIXEL_CLOCK_V6_MISC_HDMI_30BPP;
-   break;
-   case 12:
-   args.v6.ucMiscInfo |= 
PIXEL_CLOCK_V6_MISC_HDMI_36BPP;
-   break;
-   case 16:
-   args.v6.ucMiscInfo |= 
PIXEL_CLOCK_V6_MISC_HDMI_48BPP;
-   break;
+   if (encoder_mode == ATOM_ENCODER_MODE_HDMI) {
+   switch (bpc) {
+   case 8:
+   default:
+   args.v6.ucMiscInfo |= 
PIXEL_CLOCK_V6_MISC_HDMI_24BPP;
+   break;
+   case 10:
+   args.v6.ucMiscInfo |= 
PIXEL_CLOCK_V6_MISC_HDMI_30BPP;
+   break;
+   case 12:
+   args.v6.ucMiscInfo |= 
PIXEL_CLOCK_V6_MISC_HDMI_36BPP;
+   break;
+   case 16:
+   args.v6.ucMiscInfo |= 
PIXEL_CLOCK_V6_MISC_HDMI_48BPP;
+   break;
+   }
}
args.v6.ucTransmitterID = encoder_id;
args.v6.ucEncoderMode = encoder_mode;
-- 
1.8.3.1



[PATCH] vgaswitcheroo: switch the mux to the igp on power down when runpm is enabled

2014-05-20 Thread Alex Deucher
Avoids blank screens on muxed systems when runpm is active.

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

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/vga/vga_switcheroo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index ec0ae2d..6866448 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -623,7 +623,8 @@ static int vga_switcheroo_runtime_suspend(struct device 
*dev)
ret = dev->bus->pm->runtime_suspend(dev);
if (ret)
return ret;
-
+   if (vgasr_priv.handler->switchto)
+   vgasr_priv.handler->switchto(VGA_SWITCHEROO_IGD);
vga_switcheroo_power_switch(pdev, VGA_SWITCHEROO_OFF);
return 0;
 }
-- 
1.8.3.1



[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=77785

--- Comment #25 from smoki  ---
Created attachment 99436
  --> https://bugs.freedesktop.org/attachment.cgi?id=99436&action=edit
Unigine Sanctuary - fglrx


 In comparation with fglrx, radeon have blackiness with some lighting invilved
:).

-- 
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/20140520/6ce3adc4/attachment.html>


[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=77785

--- Comment #24 from smoki  ---
Created attachment 99435
  --> https://bugs.freedesktop.org/attachment.cgi?id=99435&action=edit
Unigine Sanctuary - radeon


 Similar blackiness for today with Unigine Sanctuary.

-- 
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/20140520/1bec8f55/attachment.html>


[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

2014-05-20 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=75241

--- Comment #20 from Tasev Nikola  ---
You're right again.

It seems that just build the module doesn't work for me. I build a new kernel
from sources with the ref_div_max 124 and it seems to work for now. 
[drm:radeon_compute_pll_avivo] 162000 - 161990, pll dividers - fb: 1346.2 ref:
17, post 7
I rebooted 3 times and it always boot fine. I would test it for some days and
report if everything work fine. 
Sorry for my previous post

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


[Bug 76321] Incorrect hwmon temperature when radeon card is turned off

2014-05-20 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=76321

--- Comment #7 from Alex Deucher  ---
Yes, I already sent attachment 136431 upstream.

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


[PATCH 7/8] radeon: Out of line radeon_get_ib_value

2014-05-20 Thread Marek Olšák
I think the function should stay in the header file. It's used in
performance-critical code, so we want it to be inlined.

Marek

On Fri, May 16, 2014 at 11:43 PM, Andi Kleen  wrote:
> From: Andi Kleen 
>
> Saves about 5k of text
>
>textdata bss dec hex filename
> 140803602008168 1507328 1759585610c7dd0 vmlinux-before-radeon
> 140749782008168 1507328 1759047410c68ca vmlinux-radeon
>
> Cc: alexander.deucher at amd.com
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Andi Kleen 
> ---
>  drivers/gpu/drm/radeon/radeon.h| 10 +-
>  drivers/gpu/drm/radeon/radeon_device.c |  9 +
>  2 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 6852861..8cae409 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1032,15 +1032,7 @@ struct radeon_cs_parser {
> struct ww_acquire_ctx   ticket;
>  };
>
> -static inline u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
> -{
> -   struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
> -
> -   if (ibc->kdata)
> -   return ibc->kdata[idx];
> -   return p->ib.ptr[idx];
> -}
> -
> +u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx);
>
>  struct radeon_cs_packet {
> unsignedidx;
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 0e770bb..1cbd171 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -112,6 +112,15 @@ bool radeon_is_px(struct drm_device *dev)
> return false;
>  }
>
> +u32 radeon_get_ib_value(struct radeon_cs_parser *p, int idx)
> +{
> +   struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
> +
> +   if (ibc->kdata)
> +   return ibc->kdata[idx];
> +   return p->ib.ptr[idx];
> +}
> +
>  /**
>   * radeon_program_register_sequence - program an array of registers.
>   *
> --
> 1.9.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 02/18] drm/exynos: use wait_event_timeout() for safety usage

2014-05-20 Thread Daniel Kurtz
On Wed, May 14, 2014 at 2:26 PM, YoungJun Cho  wrote:
>
> There could be the case that the page flip operation isn't finished correctly
> with some abnormal condition such as panel reset. So this patch replaces
> wait_event() with wait_event_timeout() to avoid waiting for page flip 
> completion
> infinitely.


This solution looks like we aren't really handling some conditions
completely (such as "panel reset"?). In cases where this timeout can
occur, shouldn't we be clearing pending_flip when we detect that the
flip will never complete?

-Dan

>
>
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 95c9435..485fa26 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -69,8 +69,9 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
> mode)
>
> if (mode > DRM_MODE_DPMS_ON) {
> /* wait for the completion of page flip. */
> -   wait_event(exynos_crtc->pending_flip_queue,
> -   atomic_read(&exynos_crtc->pending_flip) == 0);
> +   wait_event_timeout(exynos_crtc->pending_flip_queue,
> +   !atomic_read(&exynos_crtc->pending_flip),
> +   HZ/20);
> drm_vblank_off(crtc->dev, exynos_crtc->pipe);
> }
>
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC PATCH 2/2 with seqcount v3] reservation: add suppport for read-only access using rcu

2014-05-20 Thread Maarten Lankhorst
op 20-05-14 17:13, Thomas Hellstrom schreef:
> On 05/19/2014 03:13 PM, Maarten Lankhorst wrote:
>> op 19-05-14 15:42, Thomas Hellstrom schreef:
>>> Hi, Maarten!
>>>
>>> Some nitpicks, and that krealloc within rcu lock still worries me.
>>> Otherwise looks good.
>>>
>>> /Thomas
>>>
>>>
>>>
>>> On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
 @@ -55,8 +60,8 @@ int reservation_object_reserve_shared(struct
 reservation_object *obj)
kfree(obj->staged);
obj->staged = NULL;
return 0;
 -}
 -max = old->shared_max * 2;
 +} else
 +max = old->shared_max * 2;
>>> Perhaps as a separate reformatting patch?
>> I'll fold it in to the patch that added
>> reservation_object_reserve_shared.
 +
 +int reservation_object_get_fences_rcu(struct reservation_object *obj,
 +  struct fence **pfence_excl,
 +  unsigned *pshared_count,
 +  struct fence ***pshared)
 +{
 +unsigned shared_count = 0;
 +unsigned retry = 1;
 +struct fence **shared = NULL, *fence_excl = NULL;
 +int ret = 0;
 +
 +while (retry) {
 +struct reservation_object_list *fobj;
 +unsigned seq;
 +
 +seq = read_seqcount_begin(&obj->seq);
 +
 +rcu_read_lock();
 +
 +fobj = rcu_dereference(obj->fence);
 +if (fobj) {
 +struct fence **nshared;
 +
 +shared_count = ACCESS_ONCE(fobj->shared_count);
>>> ACCESS_ONCE() shouldn't be needed inside the seqlock?
>> Yes it is, shared_count may be increased, leading to potential
>> different sizes for krealloc and memcpy
>> if the ACCESS_ONCE is removed. I could use shared_max here instead,
>> which stays the same,
>> but it would waste more memory.
> Maarten, Another perhaps ignorant question WRT this,
> Does ACCESS_ONCE() guarantee that the value accessed is read atomically?
Well I've reworked the code to use shared_max, so this point is moot. :-)

On any archs I'm aware of it would work, either the old or new value would be 
visible, as long as natural alignment is used.
rcu uses the same trick in the rcu_dereference macro, so if this didn't work 
rcu wouldn't work either.

~Maarten


[PATCH] Documentation/dma-buf-sharing.txt: update API descriptions

2014-05-20 Thread Bjorn Helgaas
On Wed, May 14, 2014 at 08:49:43AM +0900, Gioh Kim wrote:
> Update some descriptions for API arguments and descriptions.
> 
> Signed-off-by: Gioh Kim 

I applied this to my "dma-api" branch for v3.16, thanks!

> ---
>  Documentation/dma-buf-sharing.txt |   14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 505e711..aadd901 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -56,10 +56,10 @@ The dma_buf buffer sharing API usage contains the 
> following steps:
>size_t size, int flags,
>const char *exp_name)
>  
> -   If this succeeds, dma_buf_export allocates a dma_buf structure, and 
> returns a
> -   pointer to the same. It also associates an anonymous file with this 
> buffer,
> -   so it can be exported. On failure to allocate the dma_buf object, it 
> returns
> -   NULL.
> +   If this succeeds, dma_buf_export_named allocates a dma_buf structure, and
> +   returns a pointer to the same. It also associates an anonymous file with 
> this
> +   buffer, so it can be exported. On failure to allocate the dma_buf object,
> +   it returns NULL.
>  
> 'exp_name' is the name of exporter - to facilitate information while
> debugging.
> @@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the following 
> steps:
> drivers and/or processes.
>  
> Interface:
> -  int dma_buf_fd(struct dma_buf *dmabuf)
> +  int dma_buf_fd(struct dma_buf *dmabuf, int flags)
>  
> This API installs an fd for the anonymous file associated with this 
> buffer;
> returns either 'fd', or error.
> @@ -157,7 +157,9 @@ to request use of buffer for allocation.
> "dma_buf->ops->" indirection from the users of this interface.
>  
> In struct dma_buf_ops, unmap_dma_buf is defined as
> -  void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *);
> +  void (*unmap_dma_buf)(struct dma_buf_attachment *,
> +struct sg_table *,
> +enum dma_data_direction);
>  
> unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like
> map_dma_buf, this API also must be implemented by the exporter.
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3/3] drm/i915: Re-enable vblank irqs for already active pipes

2014-05-20 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

If a pipe is already active when we init/resume there might not be a
full modeset afterwards so drm_vblank_on() may not get called. In such
a case if someone is holding a vblank reference across a suspend/resume
cycle drm_vblank_get() called after resuming won't re-enable the vblank
interrupts.

So in order to make sure vblank interrupts get re-enabled post-resume,
call drm_vblank_on() in intel_sanitize_crtc() if the crtc is already
active.

v2: Also drm_vblank_off() if the pipe got disabled magically

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_display.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9420f4f..2e9f0b0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11708,6 +11708,12 @@ static void intel_sanitize_crtc(struct intel_crtc 
*crtc)
reg = PIPECONF(crtc->config.cpu_transcoder);
I915_WRITE(reg, I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK);

+   /* restore vblank interrupts to correct state */
+   if (crtc->active)
+   drm_vblank_on(dev, crtc->pipe);
+   else
+   drm_vblank_off(dev, crtc->pipe);
+
/* We need to sanitize the plane -> pipe mapping first because this will
 * disable the crtc (and hence change the state) if it is wrong. Note
 * that gen4+ has a fixed plane -> pipe mapping.  */
-- 
1.8.5.5



[PATCH 2/3] drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off()

2014-05-20 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_display.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index df58afc..9420f4f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1298,6 +1298,17 @@ static void assert_sprites_disabled(struct 
drm_i915_private *dev_priv,
}
 }

+static void assert_vblank_disabled(struct intel_crtc *crtc)
+{
+   struct drm_device *dev = crtc->base.dev;
+   enum pipe pipe = crtc->pipe;
+
+   if (WARN_ON(drm_vblank_get(dev, pipe) == 0)) {
+   drm_vblank_put(dev, pipe);
+   drm_vblank_off(dev, pipe);
+   }
+}
+
 static void ibx_assert_pch_refclk_enabled(struct drm_i915_private *dev_priv)
 {
u32 val;
@@ -3863,6 +3874,8 @@ static void intel_crtc_enable_planes(struct drm_crtc 
*crtc)
int pipe = intel_crtc->pipe;
int plane = intel_crtc->plane;

+   assert_vblank_disabled(intel_crtc);
+
intel_enable_primary_hw_plane(dev_priv, plane, pipe);
intel_enable_planes(crtc);
/* The fixup needs to happen before cursor is enabled */
@@ -3899,6 +3912,8 @@ static void intel_crtc_disable_planes(struct drm_crtc 
*crtc)
intel_crtc_update_cursor(crtc, false);
intel_disable_planes(crtc);
intel_disable_primary_hw_plane(dev_priv, plane, pipe);
+
+   assert_vblank_disabled(intel_crtc);
 }

 static void ironlake_crtc_enable(struct drm_crtc *crtc)
-- 
1.8.5.5



[PATCH 1/3] drm: Always reject drm_vblank_get() after drm_vblank_off()

2014-05-20 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

Make sure drm_vblank_get() never succeeds when called between
drm_vblank_off() and drm_vblank_on(). Borrow a trick from the
old drm_vblank_{pre,post}_modeset() functions and just bump
the refcount in drm_vblank_off() and drop it in drm_vblank_on().

Hopefully the use of inmodeset won't conflict badly with
drm_vblank_{pre,post}_modeset().

For i915 there's a window between drm_vblank_off() and marking the
crtc as inactive where the current code still allows drm_vblank_get().

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_irq.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index dd786d8..69a2b2a 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -958,6 +958,15 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
}
spin_unlock(&dev->event_lock);

+   /*
+* Prevent subsequent drm_vblank_get() from re-enabling
+* the vblank interrupt by bumping the refcount.
+*/
+   if (!dev->vblank[crtc].inmodeset) {
+   atomic_inc(&dev->vblank[crtc].refcount);
+   dev->vblank[crtc].inmodeset = 1;
+   }
+
spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
 }
 EXPORT_SYMBOL(drm_vblank_off);
@@ -972,6 +981,11 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
unsigned long irqflags;

spin_lock_irqsave(&dev->vbl_lock, irqflags);
+   /* Drop our private "prevent drm_vblank_get" refcount */
+   if (dev->vblank[crtc].inmodeset) {
+   atomic_dec(&dev->vblank[crtc].refcount);
+   dev->vblank[crtc].inmodeset = 0;
+   }
/* re-enable interrupts if there's are users left */
if (atomic_read(&dev->vblank[crtc].refcount) != 0)
WARN_ON(drm_vblank_enable(dev, crtc));
-- 
1.8.5.5



[PATCH 0/3] drm/i915: A few more vblank interrupt fixes

2014-05-20 Thread ville.syrj...@linux.intel.com
From: Ville Syrj?l? 

We have a few more corner cases with the drm_vblank_on/off stuff. This
series aims to fix those.

I couldn't think of a good way to write a test case for the drm_vblank_get()
issue since it's a transient state that occurs briefly during modeset. So
I added asserts for it instead.

So far I didn't write a test for the intel_sanitize_crtc() case either. But
I can try to think of something for that...

Ville Syrj?l? (3):
  drm: Always reject drm_vblank_get() after drm_vblank_off()
  drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off()
  drm/i915: Re-enable vblank irqs for already active pipes

 drivers/gpu/drm/drm_irq.c| 14 ++
 drivers/gpu/drm/i915/intel_display.c | 21 +
 2 files changed, 35 insertions(+)

-- 
1.8.5.5



[Intel-gfx] [PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM

2014-05-20 Thread Daniel Vetter
On Tue, May 20, 2014 at 4:20 PM, Daniel Vetter  wrote:
> On Tue, May 20, 2014 at 05:03:33PM +0300, Ville Syrj?l? wrote:
>> On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote:
>> > On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrj?l? wrote:
>> > > On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
>> > > > Now that we unconditionally dtrt when disabling/enabling crtcs we
>> > > > don't need any hacks any longer to keep the vblank logic sane when
>> > > > all the registers go poof. So let's rip it all out.
>> > >
>> > > Hmm. drm_update_vblank_count() will now see some kind of diff between
>> > > the last and current value when the registers got cloberred. So the
>> > > vblank counter reported to userspace will jump. But I guess that's fine
>> > > as long as userspace realizes that the counter is not at all reliable
>> > > across modesets.
>> >
>> > I've added checks for this (the rpm varianst) and for the similiar
>> > suspend/resume issues (the suspend variants) to kms_flip. It seems to work
>> > and we don't actually jump to far. But maybe the tests are horribly
>> > broken.
>>
>> Hmm. If we can force the power well off at the start of the test and then
>> set a mode, I'd expect the vblank counter to jump by almost max_vblank_count
>> since the hw counter would appear to wrap.
>
> Oh, I think the tests are busted ... Need to look at this again.

I've added some debug output and fixed the suspend variants of the
tests and it actually seems to work. I.e. the frame counter before and
after a runtime pm or suspend/resume cycle is monotonic and only
increases by a few frames. The limit the test uses is 100 frames,
which should be tight enough to not confuse userspace.

Of course userspace still needs to be able to cope with cancelled
vblank events, but that's just how it is. At least the frame counters
look sane now. So I think we're good.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=77785

--- Comment #23 from smoki  ---
(In reply to comment #22)
> You are probably seeing bug 66067 for trine 2.

 Yes i saw that bug, sound like unsupportabile from Roland's comment :). I also
saw Grigory's hack, but that is different r600_shader does not use llvm
backend... and this is about SI, so thing may be different and don't know how i
can hack si_shader similar? So most probobly that is it for Trine 2, but maybe
that hack will also help in this case, etc...

 https://bugs.freedesktop.org/attachment.cgi?id=86032

 So if someone know how to hack that like for r600 but for SI to approve it is
the same, i will be glad to try that :).

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


[Bug 76321] Incorrect hwmon temperature when radeon card is turned off

2014-05-20 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=76321

--- Comment #6 from Pali Roh?r  ---
Ok, I will look at it and will try to implemenent it. So can you commit
radeon_hwmon_show_temp() part of patch?

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


[Intel-gfx] [PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM

2014-05-20 Thread Ville Syrjälä
On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrj?l? wrote:
> > On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > > don't need any hacks any longer to keep the vblank logic sane when
> > > all the registers go poof. So let's rip it all out.
> > 
> > Hmm. drm_update_vblank_count() will now see some kind of diff between
> > the last and current value when the registers got cloberred. So the
> > vblank counter reported to userspace will jump. But I guess that's fine
> > as long as userspace realizes that the counter is not at all reliable
> > across modesets.
> 
> I've added checks for this (the rpm varianst) and for the similiar
> suspend/resume issues (the suspend variants) to kms_flip. It seems to work
> and we don't actually jump to far. But maybe the tests are horribly
> broken.

Hmm. If we can force the power well off at the start of the test and then
set a mode, I'd expect the vblank counter to jump by almost max_vblank_count
since the hw counter would appear to wrap.

> 
> Can you please take a closer look? I've thought that the entire point of
> this series (well, one of them) was to finally fix this gag and avoid
> handing totally bogus frame counter values to userspace. Especially for
> system suspend/resume where userspace might get susprised ...

I was mostly interested in making vblank interrupts work during plane
enable/disable. Anything else is a bonus.

> -Daniel
> 
> > 
> > > 
> > > This essentially undoes
> > > 
> > > commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
> > > Author: Paulo Zanoni 
> > > Date:   Tue Jul 23 10:48:11 2013 -0300
> > > 
> > > drm/i915: update last_vblank when disabling the power well
> > > 
> > > Apparently igt/kms_flip is already powerful enough to exercise this
> > > properly, yay! See the reference regression report for details.
> > > 
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=66808
> > > Testcase: igt/kms_flip/*-vs-rpm
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/i915/intel_pm.c | 34 --
> > >  1 file changed, 34 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 75c1c766b507..45fa43f16bb3 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -5423,33 +5423,6 @@ static void hsw_power_well_post_enable(struct 
> > > drm_i915_private *dev_priv)
> > >   }
> > >  }
> > >  
> > > -static void reset_vblank_counter(struct drm_device *dev, enum pipe pipe)
> > > -{
> > > - assert_spin_locked(&dev->vbl_lock);
> > > -
> > > - dev->vblank[pipe].last = 0;
> > > -}
> > > -
> > > -static void hsw_power_well_post_disable(struct drm_i915_private 
> > > *dev_priv)
> > > -{
> > > - struct drm_device *dev = dev_priv->dev;
> > > - enum pipe pipe;
> > > - unsigned long irqflags;
> > > -
> > > - /*
> > > -  * After this, the registers on the pipes that are part of the power
> > > -  * well will become zero, so we have to adjust our counters according to
> > > -  * that.
> > > -  *
> > > -  * FIXME: Should we do this in general in drm_vblank_post_modeset?
> > > -  */
> > > - spin_lock_irqsave(&dev->vbl_lock, irqflags);
> > > - for_each_pipe(pipe)
> > > - if (pipe != PIPE_A)
> > > - reset_vblank_counter(dev, pipe);
> > > - spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> > > -}
> > > -
> > >  static void hsw_set_power_well(struct drm_i915_private *dev_priv,
> > >  struct i915_power_well *power_well, bool enable)
> > >  {
> > > @@ -5478,8 +5451,6 @@ static void hsw_set_power_well(struct 
> > > drm_i915_private *dev_priv,
> > >   I915_WRITE(HSW_PWR_WELL_DRIVER, 0);
> > >   POSTING_READ(HSW_PWR_WELL_DRIVER);
> > >   DRM_DEBUG_KMS("Requesting to disable the power well\n");
> > > -
> > > - hsw_power_well_post_disable(dev_priv);
> > >   }
> > >   }
> > >  }
> > > @@ -5646,11 +5617,6 @@ static void vlv_display_power_well_disable(struct 
> > > drm_i915_private *dev_priv,
> > >   valleyview_disable_display_irqs(dev_priv);
> > >   spin_unlock_irq(&dev_priv->irq_lock);
> > >  
> > > - spin_lock_irq(&dev->vbl_lock);
> > > - for_each_pipe(pipe)
> > > - reset_vblank_counter(dev, pipe);
> > > - spin_unlock_irq(&dev->vbl_lock);
> > > -
> > >   vlv_set_power_well(dev_priv, power_well, false);
> > >  }
> > >  
> > > -- 
> > > 1.8.3.1
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Ville Syrj?l?
> > Intel OTC
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Ville Syrj?l?
Intel OTC


linux-next: manual merge of the dma-buf tree with the drm-intel tree

2014-05-20 Thread Stephen Rothwell
Hi Sumit,

Today's linux-next merge of the dma-buf tree got a conflict in
drivers/gpu/drm/i915/i915_gem_dmabuf.c between commit 5cc9ed4b9a7a
("drm/i915: Introduce mapping of user pages into video memory (userptr)
ioctl") from the drm-intel tree and commit 8dfb1f0f8103 ("dma-buf: use
reservation objects") from the dma-buf 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_dmabuf.c
index 580aa42443ed,817ec444c976..
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@@ -229,15 -233,8 +229,16 @@@ static const struct dma_buf_ops i915_dm
  struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
  struct drm_gem_object *gem_obj, int flags)
  {
 +  struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
 +
 +  if (obj->ops->dmabuf_export) {
 +  int ret = obj->ops->dmabuf_export(obj);
 +  if (ret)
 +  return ERR_PTR(ret);
 +  }
 +
-   return dma_buf_export(gem_obj, &i915_dmabuf_ops, gem_obj->size, flags);
+   return dma_buf_export(gem_obj, &i915_dmabuf_ops, gem_obj->size, flags,
+   NULL);
  }

  static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/53ad9955/attachment.sig>


[PATCH] drm/panel: add support for AUO B133XTN01 panel

2014-05-20 Thread Stéphane Marchesin
This panel is used by my tegra board and supported by the simple-panel
driver.

Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/panel/panel-simple.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 309f29e..46dcad0 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -284,6 +284,28 @@ static const struct panel_desc auo_b101aw03 = {
},
 };

+static const struct drm_display_mode auo_b133xtn01_mode = {
+   .clock = 69500,
+   .hdisplay = 1366,
+   .hsync_start = 1366 + 48,
+   .hsync_end = 1366 + 48 + 32,
+   .htotal = 1366 + 48 + 32 + 20,
+   .vdisplay = 768,
+   .vsync_start = 768 + 3,
+   .vsync_end = 768 + 3 + 6,
+   .vtotal = 768 + 3 + 6 + 13,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b133xtn01 = {
+   .modes = &auo_b133xtn01_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 293,
+   .height = 164,
+   },
+};
+
 static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -377,6 +399,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = &auo_b101aw03,
}, {
+   .compatible = "auo,b133xtn01",
+   .data = &auo_b133xtn01,
+   }, {
.compatible = "chunghwa,claa101wa01a",
.data = &chunghwa_claa101wa01a
}, {
-- 
1.9.1.423.g4596e3a



[PATCH] drm/qxl: return IRQ_NONE if it was not our irq

2014-05-20 Thread Amos Kong
On Mon, May 12, 2014 at 04:35:39PM +0800, Jason Wang wrote:
> Return IRQ_NONE if it was not our irq. This is necessary for the case
> when qxl is sharing irq line with a device A in a crash kernel. If qxl
> is initialized before A and A's irq was raised during this gap,
> returning IRQ_HANDLED in this case will cause this irq to be raised
> again after EOI since kernel think it was handled but in fact it was
> not.
> 
> Cc: Gerd Hoffmann 
> Cc: stable at vger.kernel.org
> Signed-off-by: Jason Wang 
> ---
>  drivers/gpu/drm/qxl/qxl_irq.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_irq.c b/drivers/gpu/drm/qxl/qxl_irq.c
> index 28f84b4..3485bdc 100644
> --- a/drivers/gpu/drm/qxl/qxl_irq.c
> +++ b/drivers/gpu/drm/qxl/qxl_irq.c
> @@ -33,6 +33,9 @@ irqreturn_t qxl_irq_handler(int irq, void *arg)
>  
>   pending = xchg(&qdev->ram_header->int_pending, 0);
>  
> + if (!pending)
> + return IRQ_NONE;
> +

Looks correct.

Revewed-by: Amos Kong 

>   atomic_inc(&qdev->irq_received);
>  
>   if (pending & QXL_INTERRUPT_DISPLAY) {
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Amos.


[Intel-gfx] [PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM

2014-05-20 Thread Daniel Vetter
On Tue, May 20, 2014 at 05:03:33PM +0300, Ville Syrj?l? wrote:
> On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote:
> > On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrj?l? wrote:
> > > On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > > > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > > > don't need any hacks any longer to keep the vblank logic sane when
> > > > all the registers go poof. So let's rip it all out.
> > > 
> > > Hmm. drm_update_vblank_count() will now see some kind of diff between
> > > the last and current value when the registers got cloberred. So the
> > > vblank counter reported to userspace will jump. But I guess that's fine
> > > as long as userspace realizes that the counter is not at all reliable
> > > across modesets.
> > 
> > I've added checks for this (the rpm varianst) and for the similiar
> > suspend/resume issues (the suspend variants) to kms_flip. It seems to work
> > and we don't actually jump to far. But maybe the tests are horribly
> > broken.
> 
> Hmm. If we can force the power well off at the start of the test and then
> set a mode, I'd expect the vblank counter to jump by almost max_vblank_count
> since the hw counter would appear to wrap.

Oh, I think the tests are busted ... Need to look at this again.
-Daniel

> 
> > 
> > Can you please take a closer look? I've thought that the entire point of
> > this series (well, one of them) was to finally fix this gag and avoid
> > handing totally bogus frame counter values to userspace. Especially for
> > system suspend/resume where userspace might get susprised ...
> 
> I was mostly interested in making vblank interrupts work during plane
> enable/disable. Anything else is a bonus.
> 
> > -Daniel
> > 
> > > 
> > > > 
> > > > This essentially undoes
> > > > 
> > > > commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
> > > > Author: Paulo Zanoni 
> > > > Date:   Tue Jul 23 10:48:11 2013 -0300
> > > > 
> > > > drm/i915: update last_vblank when disabling the power well
> > > > 
> > > > Apparently igt/kms_flip is already powerful enough to exercise this
> > > > properly, yay! See the reference regression report for details.
> > > > 
> > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=66808
> > > > Testcase: igt/kms_flip/*-vs-rpm
> > > > Signed-off-by: Daniel Vetter 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_pm.c | 34 --
> > > >  1 file changed, 34 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 75c1c766b507..45fa43f16bb3 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -5423,33 +5423,6 @@ static void hsw_power_well_post_enable(struct 
> > > > drm_i915_private *dev_priv)
> > > > }
> > > >  }
> > > >  
> > > > -static void reset_vblank_counter(struct drm_device *dev, enum pipe 
> > > > pipe)
> > > > -{
> > > > -   assert_spin_locked(&dev->vbl_lock);
> > > > -
> > > > -   dev->vblank[pipe].last = 0;
> > > > -}
> > > > -
> > > > -static void hsw_power_well_post_disable(struct drm_i915_private 
> > > > *dev_priv)
> > > > -{
> > > > -   struct drm_device *dev = dev_priv->dev;
> > > > -   enum pipe pipe;
> > > > -   unsigned long irqflags;
> > > > -
> > > > -   /*
> > > > -* After this, the registers on the pipes that are part of the 
> > > > power
> > > > -* well will become zero, so we have to adjust our counters 
> > > > according to
> > > > -* that.
> > > > -*
> > > > -* FIXME: Should we do this in general in 
> > > > drm_vblank_post_modeset?
> > > > -*/
> > > > -   spin_lock_irqsave(&dev->vbl_lock, irqflags);
> > > > -   for_each_pipe(pipe)
> > > > -   if (pipe != PIPE_A)
> > > > -   reset_vblank_counter(dev, pipe);
> > > > -   spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> > > > -}
> > > > -
> > > >  static void hsw_set_power_well(struct drm_i915_private *dev_priv,
> > > >struct i915_power_well *power_well, bool 
> > > > enable)
> > > >  {
> > > > @@ -5478,8 +5451,6 @@ static void hsw_set_power_well(struct 
> > > > drm_i915_private *dev_priv,
> > > > I915_WRITE(HSW_PWR_WELL_DRIVER, 0);
> > > > POSTING_READ(HSW_PWR_WELL_DRIVER);
> > > > DRM_DEBUG_KMS("Requesting to disable the power 
> > > > well\n");
> > > > -
> > > > -   hsw_power_well_post_disable(dev_priv);
> > > > }
> > > > }
> > > >  }
> > > > @@ -5646,11 +5617,6 @@ static void 
> > > > vlv_display_power_well_disable(struct drm_i915_private *dev_priv,
> > > > valleyview_disable_display_irqs(dev_priv);
> > > > spin_unlock_irq(&dev_priv->irq_lock);
> > > >  
> > > > -   spin_lock_irq(&dev->vbl_lock);
> > > > -   for_each_pipe(pipe)
> > > 

[RFC PATCH 2/2 with seqcount v3] reservation: add suppport for read-only access using rcu

2014-05-20 Thread Thomas Hellstrom
On 05/19/2014 03:13 PM, Maarten Lankhorst wrote:
> op 19-05-14 15:42, Thomas Hellstrom schreef:
>> Hi, Maarten!
>>
>> Some nitpicks, and that krealloc within rcu lock still worries me.
>> Otherwise looks good.
>>
>> /Thomas
>>
>>
>>
>> On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
>>> @@ -55,8 +60,8 @@ int reservation_object_reserve_shared(struct
>>> reservation_object *obj)
>>>   kfree(obj->staged);
>>>   obj->staged = NULL;
>>>   return 0;
>>> -}
>>> -max = old->shared_max * 2;
>>> +} else
>>> +max = old->shared_max * 2;
>> Perhaps as a separate reformatting patch?
> I'll fold it in to the patch that added
> reservation_object_reserve_shared.
>>> +
>>> +int reservation_object_get_fences_rcu(struct reservation_object *obj,
>>> +  struct fence **pfence_excl,
>>> +  unsigned *pshared_count,
>>> +  struct fence ***pshared)
>>> +{
>>> +unsigned shared_count = 0;
>>> +unsigned retry = 1;
>>> +struct fence **shared = NULL, *fence_excl = NULL;
>>> +int ret = 0;
>>> +
>>> +while (retry) {
>>> +struct reservation_object_list *fobj;
>>> +unsigned seq;
>>> +
>>> +seq = read_seqcount_begin(&obj->seq);
>>> +
>>> +rcu_read_lock();
>>> +
>>> +fobj = rcu_dereference(obj->fence);
>>> +if (fobj) {
>>> +struct fence **nshared;
>>> +
>>> +shared_count = ACCESS_ONCE(fobj->shared_count);
>> ACCESS_ONCE() shouldn't be needed inside the seqlock?
> Yes it is, shared_count may be increased, leading to potential
> different sizes for krealloc and memcpy
> if the ACCESS_ONCE is removed. I could use shared_max here instead,
> which stays the same,
> but it would waste more memory.

Maarten, Another perhaps ignorant question WRT this,
Does ACCESS_ONCE() guarantee that the value accessed is read atomically?

/Thomas


[PATCH v3 16/16] drm: sti: Add DRM driver itself

2014-05-20 Thread Benjamin Gaignard
Make the link between all the hardware drivers and DRM/KMS interface.
Create the driver itself and make it register all the sub-components.
Use GEM CMA helpers for buffer allocation.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Kconfig |   8 +
 drivers/gpu/drm/sti/Makefile|   7 +-
 drivers/gpu/drm/sti/sti_compositor.c|  48 
 drivers/gpu/drm/sti/sti_drm_connector.c | 195 ++
 drivers/gpu/drm/sti/sti_drm_connector.h |  16 ++
 drivers/gpu/drm/sti/sti_drm_crtc.c  | 440 
 drivers/gpu/drm/sti/sti_drm_crtc.h  |  21 ++
 drivers/gpu/drm/sti/sti_drm_drv.c   | 338 
 drivers/gpu/drm/sti/sti_drm_encoder.c   | 201 +++
 drivers/gpu/drm/sti/sti_drm_encoder.h   |  16 ++
 drivers/gpu/drm/sti/sti_drm_plane.c | 195 ++
 drivers/gpu/drm/sti/sti_drm_plane.h |  16 ++
 drivers/gpu/drm/sti/sti_tvout.c |  21 ++
 13 files changed, 1521 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.c
 create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.h
 create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.c
 create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.h
 create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.c
 create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.c
 create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.h
 create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.c
 create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.h

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index 76c2e4f..2c80bcf 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,10 +1,18 @@
 config DRM_STI
bool "DRM Support for STMicroelectronics SoC stiH41x Series"
depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
help
  Choose this option to enable DRM on STM stiH41x chipset

+config DRM_STI_FBDEV
+   bool "DRM frame buffer device for STMicroelectronics SoC stiH41x Serie"
+   depends on DRM_STI
+   help
+ Choose this option to enable FBDEV on top of DRM for STM stiH41x 
chipset
+
 config VTAC_STI
bool "Video Trafic Advance Communication Rx and Tx for 
STMicroelectronics SoC stiH41x Series"
depends on DRM_STI
diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index 3b804d4..8eee160 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -1,6 +1,11 @@
 ccflags-y := -Iinclude/drm

-stidrm-y := sti_tvout.o \
+stidrm-y := sti_drm_drv.o \
+   sti_drm_crtc.o \
+   sti_drm_plane.o \
+   sti_drm_connector.o \
+   sti_drm_encoder.o \
+   sti_tvout.o \
sti_hdmi.o \
sti_hdmi_tx3g0c55phy.o \
sti_hdmi_tx3g4c28phy.o \
diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
index 0c9ef6d..b0e2968 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -14,7 +14,10 @@
 #include 

 #include "sti_compositor.h"
+#include "sti_drm_drv.h"
+#include "sti_drm_plane.h"
 #include "sti_gdp.h"
+#include "sti_drm_crtc.h"

 static const struct of_device_id compositor_match_types[];

@@ -86,6 +89,50 @@ static int sti_compositor_init_subdev(struct sti_compositor 
*compo,
 static int sti_compositor_bind(struct device *dev, struct device *master,
void *data)
 {
+   struct sti_compositor *compo = dev_get_drvdata(master);
+   struct drm_device *drm_dev = data;
+   int i, crtc = 0, plane = 0;
+   struct sti_drm_private *dev_priv = drm_dev->dev_private;
+
+   dev_dbg(dev, "%s\n", __func__);
+
+   dev_priv->compo = compo;
+   INIT_LIST_HEAD(&dev_priv->pageflip_evt_list);
+
+   for (i = 0; i < compo->nb_mixers; i++) {
+   if (compo->mixer[i]) {
+   sti_drm_crtc_init(drm_dev, compo->mixer[i]);
+   crtc++;
+   }
+   }
+   if (crtc == 0) {
+   DRM_ERROR("No CRTC available\n");
+   return 1;
+   }
+
+   drm_vblank_init(drm_dev, crtc);
+   /* Allow usage of vblank without having to call drm_irq_install */
+   drm_dev->irq_enabled = 1;
+
+   for (i = 0; i < compo->nb_layers; i++) {
+   if (compo->layer[i]) {
+   /* Create planes for GDP.
+* except GDP0 as it is reserved for CRTC FB */
+   enum sti_layer_desc desc = compo->layer[i]->desc;
+   enum sti_layer_type type = desc & STI_LAYER_TYPE_MASK;
+
+   if ((type == STI_GDP) && (desc != STI_GDP_0)) {
+   sti_drm_plane_init(drm_dev, compo->layer

[PATCH v3 15/16] drm: sti: add debug to mixer

2014-05-20 Thread Benjamin Gaignard
Make mixer driver more verbose

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_mixer.c | 164 
 drivers/gpu/drm/sti/sti_mixer.h |   2 +
 2 files changed, 166 insertions(+)

diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index b6c8214..73d5405 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -6,7 +6,9 @@
  * License terms:  GNU General Public License (GPL), version 2
  */

+#include "sti_drm_drv.h"
 #include "sti_mixer.h"
+#include "sti_compositor.h"
 #include "sti_vtg_utils.h"

 /* Identity: G=Y , B=Cb , R=Cr */
@@ -139,6 +141,8 @@ int sti_mixer_set_layer_depth(struct sti_mixer *mixer, 
struct sti_layer *layer)
mask = GAM_DEPTH_MASK_ID << (3 * depth);
layer_id = layer_id << (3 * depth);

+   DRM_DEBUG_DRIVER("%s %s depth=%d\n", sti_mixer_to_str(mixer),
+sti_layer_to_str(layer), depth);
dev_dbg(mixer->dev, "GAM_MIXER_CRB val 0x%x mask 0x%x\n",
layer_id, mask);
sti_mixer_reg_writemask(mixer, GAM_MIXER_CRB, layer_id, mask);
@@ -197,6 +201,9 @@ int sti_mixer_set_layer_status(struct sti_mixer *mixer,
 {
u32 mask, val;

+   DRM_DEBUG_DRIVER("%s %s %s\n", status ? "enable" : "disable",
+sti_mixer_to_str(mixer), sti_layer_to_str(layer));
+
mask = sti_mixer_get_layer_mask(layer);
if (!mask) {
DRM_ERROR("Can not find layer mask\n");
@@ -239,3 +246,160 @@ struct sti_mixer *sti_mixer_create(struct device *dev, 
int id,

return mixer;
 }
+
+static void sti_mixer_dbg_ctl(struct seq_file *m, int val)
+{
+   int count = 0;
+
+   seq_puts(m, "\tEnabled: ");
+   if (val & 1) {
+   seq_puts(m, "BKG ");
+   count++;
+   }
+   val = val >> 1;
+
+   if (val & 1) {
+   seq_puts(m, "VID0 ");
+   count++;
+   }
+   val = val >> 1;
+   if (val & 1) {
+   seq_puts(m, "VID1 ");
+   count++;
+   }
+   val = val >> 1;
+   if (val & 1) {
+   seq_puts(m, "GDP0 ");
+   count++;
+   }
+   val = val >> 1;
+   if (val & 1) {
+   seq_puts(m, "GDP1 ");
+   count++;
+   }
+   val = val >> 1;
+   if (val & 1) {
+   seq_puts(m, "GDP2 ");
+   count++;
+   }
+   val = val >> 1;
+   if (val & 1) {
+   seq_puts(m, "GDP3 ");
+   count++;
+   }
+   if (!count)
+   seq_puts(m, "Nothing");
+}
+
+static void sti_mixer_dbg_crb(struct seq_file *m, int val)
+{
+   int i;
+
+   seq_puts(m, "\tDepth: ");
+   for (i = 0; i < GAM_MIXER_NB_DEPTH_LEVEL; i++) {
+   switch (val & GAM_DEPTH_MASK_ID) {
+   case GAM_DEPTH_VID0_ID:
+   seq_puts(m, "VID0");
+   break;
+   case GAM_DEPTH_VID1_ID:
+   seq_puts(m, "VID1");
+   break;
+   case GAM_DEPTH_GDP0_ID:
+   seq_puts(m, "GDP0");
+   break;
+   case GAM_DEPTH_GDP1_ID:
+   seq_puts(m, "GDP1");
+   break;
+   case GAM_DEPTH_GDP2_ID:
+   seq_puts(m, "GDP2");
+   break;
+   case GAM_DEPTH_GDP3_ID:
+   seq_puts(m, "GDP3");
+   break;
+   default:
+   seq_puts(m, "---");
+   }
+   if (i < GAM_MIXER_NB_DEPTH_LEVEL - 1)
+   seq_puts(m, " < ");
+   val = val >> 3;
+   }
+}
+
+static void sti_mixer_dbg_mxn(struct seq_file *m, void *addr)
+{
+   int i;
+
+   for (i = 1; i < 8; i++)
+   seq_printf(m, "-0x%08X", (int)readl(addr + i * 4));
+}
+
+#define MIXER_DBG_DUMP(reg) seq_printf(m, "\n " #reg "\t 0x%08X", \
+   sti_mixer_reg_read(mixer, reg))
+
+int sti_mixer_dbg_show(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *)m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct sti_drm_private *dev_priv = dev->dev_private;
+   struct sti_compositor *compo = dev_priv->compo;
+   int i, ret;
+
+   ret = mutex_lock_interruptible(&dev->struct_mutex);
+   if (ret)
+   return ret;
+
+   if (compo == NULL) {
+   seq_puts(m, "No compositor available\n");
+   goto out;
+   }
+
+   for (i = 0; i < compo->nb_mixers; i++) {
+   struct drm_crtc *crtc;
+   struct drm_framebuffer *fb;
+   struct sti_mixer *mixer = compo->mixer[i];
+
+   seq_printf(m, "\n%s", sti_mixer_to_str(mixer));
+   MIXER_DBG_DUMP(GAM_MIXER_CTL);
+   sti_mixer_dbg_ctl(m,
+

[PATCH v3 14/16] drm: sti: add debug to TVout

2014-05-20 Thread Benjamin Gaignard
Use debugfs to dump information about TVout

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_tvout.c | 181 
 1 file changed, 181 insertions(+)

diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
index 3e679a0..fb199c4 100644
--- a/drivers/gpu/drm/sti/sti_tvout.c
+++ b/drivers/gpu/drm/sti/sti_tvout.c
@@ -18,6 +18,7 @@
 #include "sti_tvout.h"
 #include "sti_hdmi.h"
 #include "sti_hda.h"
+#include "sti_drm_drv.h"

 /* glue regsiters */
 #define TVO_CSC_MAIN_M0  0x000
@@ -605,6 +606,186 @@ void sti_tvout_disable(struct sti_tvout *tvout,
connector->stop(connector);
 }

+/*
+ * Debugfs
+ */
+#define TVOUT_DBG_DUMP(reg) seq_printf(m, "\n %-25s 0x%08X", #reg, \
+   readl(tvout->regs + reg))
+#define TVOUT_CONNECTOR_NAME_MAX_LENGHT 10
+#define MAX_STRING_LENGTH 55
+
+static int sti_tvout_dbg_type_to_connector_name(enum sti_tvout_connector_type
+   type, char *name)
+{
+   switch (type) {
+   case STI_TVOUT_CONNECTOR_HDMI:
+   snprintf(name, TVOUT_CONNECTOR_NAME_MAX_LENGHT, "HDMI");
+   break;
+   case STI_TVOUT_CONNECTOR_HDA:
+   snprintf(name, TVOUT_CONNECTOR_NAME_MAX_LENGHT, "HD Analog");
+   break;
+   default:
+   return -1;
+   }
+
+   return 0;
+}
+
+static void tvout_dbg_vip(struct seq_file *m, int val)
+{
+   int r, g, b, tmp, mask;
+   char str[MAX_STRING_LENGTH];
+   static const char *const reorder[] = { "Y_G", "Cb_B", "Cr_R" };
+   static const char *const clipping[] = { "No", "EAV/SAV",
+   "Limited range RGB/Y", "Limited range Cb/Cr",
+   "decided by register" };
+   static const char *const round[] = { "8-bit", "10-bit", "12-bit" };
+   static const char *const input_sel[] = { "Main (color matrix enabled)",
+   "Main (color matrix by-passed)", "", "", "", "", "", "",
+   "Aux (color matrix enabled)", "Aux (color matrix by-passed)",
+   "", "", "", "", "", "Force value"
+   };
+
+   seq_puts(m, "\t");
+
+   mask = TVO_VIP_REORDER_MASK << TVO_VIP_REORDER_R_SHIFT;
+   r = (val & mask) >> TVO_VIP_REORDER_R_SHIFT;
+   mask = TVO_VIP_REORDER_MASK << TVO_VIP_REORDER_G_SHIFT;
+   g = (val & mask) >> TVO_VIP_REORDER_G_SHIFT;
+   mask = TVO_VIP_REORDER_MASK << TVO_VIP_REORDER_B_SHIFT;
+   b = (val & mask) >> TVO_VIP_REORDER_B_SHIFT;
+   snprintf(str, MAX_STRING_LENGTH, "Reorder: %s->%s %s->%s %s->%s",
+reorder[r], reorder[TVO_VIP_REORDER_CR_R_SEL],
+reorder[g], reorder[TVO_VIP_REORDER_Y_G_SEL],
+reorder[b], reorder[TVO_VIP_REORDER_CB_B_SEL]);
+   seq_printf(m, "%-55s", str);
+
+   mask = TVO_VIP_CLIP_MASK << TVO_VIP_CLIP_SHIFT;
+   tmp = (val & mask) >> TVO_VIP_CLIP_SHIFT;
+   snprintf(str, MAX_STRING_LENGTH, "Clipping: %s", clipping[tmp]);
+   seq_printf(m, "%-55s", str);
+
+   seq_printf(m, "\n%-40s", "");
+
+   mask = TVO_VIP_RND_MASK << TVO_VIP_RND_SHIFT;
+   tmp = (val & mask) >> TVO_VIP_RND_SHIFT;
+   snprintf(str, MAX_STRING_LENGTH,
+"Round: input data rounded to %s per component", round[tmp]);
+   seq_printf(m, "%-55s", str);
+
+   tmp = (val & TVO_VIP_SEL_INPUT_MASK);
+   snprintf(str, MAX_STRING_LENGTH, "Input selection: %s", input_sel[tmp]);
+   seq_printf(m, "%-55s", str);
+}
+
+static void tvout_dbg_hd_dac_cfg(struct seq_file *m, int val)
+{
+   seq_puts(m, "\t HD DAC ");
+   seq_puts(m, val & 1 ? "disabled" : "enabled");
+}
+
+static int tvout_dbg_show(struct seq_file *m,
+ enum sti_tvout_connector_type type)
+{
+   struct drm_info_node *node = (struct drm_info_node *)m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct sti_drm_private *dev_priv = dev->dev_private;
+   struct sti_tvout *tvout = dev_priv->tvout;
+   struct sti_tvout_connector *connector = tvout->connector[type];
+   char name[TVOUT_CONNECTOR_NAME_MAX_LENGHT];
+   int ret;
+
+   if (!connector)
+   return -1;
+
+   if (!connector->is_enabled)
+   return -1;
+
+   ret = mutex_lock_interruptible(&dev->struct_mutex);
+   if (ret)
+   return ret;
+
+   if (tvout == NULL) {
+   seq_puts(m, "No tvout available");
+   goto out;
+   }
+
+   ret = sti_tvout_dbg_type_to_connector_name(type, name);
+   if (ret) {
+   seq_puts(m, "No connector!");
+   goto out;
+   }
+
+   seq_printf(m, "\n%s connector: ", name);
+   seq_printf(m, "\nTVOUT: (virt base addr = 0x%p)", tvout->regs);
+   if (connector->is_enabled(connector)) {
+   if (connector->main_path) {
+   seq_puts(m, "\n Connected to the main path");
+ 

[PATCH v3 13/16] drm: sti: add debug to VID

2014-05-20 Thread Benjamin Gaignard
Make VIdeo plug more verbose on what is on going

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_vid.c | 121 ++
 drivers/gpu/drm/sti/sti_vid.h |   1 +
 2 files changed, 122 insertions(+)

diff --git a/drivers/gpu/drm/sti/sti_vid.c b/drivers/gpu/drm/sti/sti_vid.c
index 710665d..35f60d8 100644
--- a/drivers/gpu/drm/sti/sti_vid.c
+++ b/drivers/gpu/drm/sti/sti_vid.c
@@ -8,6 +8,8 @@

 #include "sti_vid.h"
 #include "sti_layer.h"
+#include "sti_compositor.h"
+#include "sti_drm_drv.h"
 #include "sti_vtg_utils.h"

 /* Registers */
@@ -49,6 +51,8 @@ static int sti_vid_prepare_layer(void *lay, bool 
first_prepare)
struct sti_layer *layer = (struct sti_layer *)lay;
struct sti_vid *vid = layer->vid;

+   dev_dbg(vid->dev, "%s %s\n", __func__, sti_layer_to_str(layer));
+
/* Unmask */
val = readl(vid->regs + VID_CTL);
val &= ~VID_CTL_IGNORE;
@@ -64,6 +68,8 @@ static int sti_vid_commit_layer(void *lay)
struct drm_display_mode *mode = layer->mode;
u32 ydo, xdo, yds, xds;

+   dev_dbg(vid->dev, "%s %s\n", __func__, sti_layer_to_str(layer));
+
ydo = sti_vtg_get_line_number(*mode, layer->dst_y);
yds = sti_vtg_get_line_number(*mode, layer->dst_y + layer->dst_h - 1);
xdo = sti_vtg_get_pixel_number(*mode, layer->dst_x);
@@ -81,6 +87,8 @@ static int sti_vid_disable_layer(void *lay)
struct sti_layer *layer = (struct sti_layer *)lay;
struct sti_vid *vid = layer->vid;

+   DRM_DEBUG_DRIVER("%s\n", sti_layer_to_str(layer));
+
/* Mask */
val = readl(vid->regs + VID_CTL);
val |= VID_CTL_IGNORE;
@@ -136,3 +144,116 @@ struct sti_vid *sti_vid_create(struct device *dev, void 
__iomem *baseaddr)

return vid;
 }
+
+static void sti_vid_dbg_ctl(struct seq_file *m, int val)
+{
+   val = val >> 30;
+   seq_puts(m, "\t");
+
+   if (!(val & 1))
+   seq_puts(m, "NOT ");
+   seq_puts(m, "ignored on main mixer - ");
+
+   if (!(val & 2))
+   seq_puts(m, "NOT ");
+   seq_puts(m, "ignored on aux mixer");
+}
+
+static void sti_vid_dbg_vpo(struct seq_file *m, int val)
+{
+   seq_printf(m, "\txdo:%4d\tydo:%4d", val & 0x0FFF, (val >> 16) & 0x0FFF);
+}
+
+static void sti_vid_dbg_vps(struct seq_file *m, int val)
+{
+   seq_printf(m, "\txds:%4d\tyds:%4d", val & 0x0FFF, (val >> 16) & 0x0FFF);
+}
+
+static void sti_vid_dbg_mst(struct seq_file *m, int val)
+{
+   if (val & 1)
+   seq_puts(m, "\tBUFFER UNDERFLOW!");
+}
+
+#define DBG_DUMP(reg) \
+   seq_printf(m, "\n " #reg "\t 0x%08X", readl(vid->regs + reg))
+
+int sti_vid_dbg_show(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *)m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct sti_drm_private *dev_priv = dev->dev_private;
+   struct sti_compositor *compo = dev_priv->compo;
+   enum sti_layer_desc vid_id = *(enum sti_layer_desc *)arg;
+   struct sti_layer *layer;
+   struct sti_vid *vid;
+   struct drm_plane *plane;
+   struct drm_crtc *crtc;
+   struct drm_framebuffer *fb;
+
+   if (compo == NULL) {
+   seq_puts(m, "No compo available\n");
+   goto out;
+   }
+
+   layer = sti_layer_find_layer(compo->layer, vid_id);
+   if (!layer) {
+   seq_puts(m, "Cannot find video layer\n");
+   goto out;
+   }
+   vid = layer->vid;
+
+   seq_printf(m, "\n%s (associated with the mixer_id %d)",
+   sti_layer_to_str(layer), layer->mixer_id);
+   seq_printf(m, "\t %d frame updates",
+  layer->fps_info.curr_frame_counter);
+
+   DBG_DUMP(VID_CTL);
+   sti_vid_dbg_ctl(m, readl(vid->regs + VID_CTL));
+   DBG_DUMP(VID_ALP);
+   DBG_DUMP(VID_CLF);
+   DBG_DUMP(VID_VPO);
+   sti_vid_dbg_vpo(m, readl(vid->regs + VID_VPO));
+   DBG_DUMP(VID_VPS);
+   sti_vid_dbg_vps(m, readl(vid->regs + VID_VPS));
+   DBG_DUMP(VID_KEY1);
+   DBG_DUMP(VID_KEY2);
+   DBG_DUMP(VID_MPR0);
+   DBG_DUMP(VID_MPR1);
+   DBG_DUMP(VID_MPR2);
+   DBG_DUMP(VID_MPR3);
+   DBG_DUMP(VID_MST);
+   sti_vid_dbg_mst(m, readl(vid->regs + VID_MST));
+   DBG_DUMP(VID_BC);
+   DBG_DUMP(VID_TINT);
+   DBG_DUMP(VID_CSAT);
+
+   seq_puts(m, "\n");
+
+   plane = &layer->plane;
+   if (!plane->base.id) {
+   seq_puts(m, " Not connected to any DRM PLANE\n");
+   goto out;
+   }
+   seq_printf(m, " Connected to DRM PLANE #%d which is:\n",
+  plane->base.id);
+
+   crtc = plane->crtc;
+   if (!crtc) {
+   seq_puts(m, "\tNot connected to any DRM CRTC\n");
+   goto out;
+   }
+   seq_printf(m, "\tConnected to DRM CRTC #%d\n", crtc->base.id);
+
+   fb = crtc->fb;
+   if (!fb) {
+   seq_puts(m, "\tNot connecte

[PATCH v3 12/16] drm: sti: add debug to GDP

2014-05-20 Thread Benjamin Gaignard
Allow to get more detailed debug information on GDP

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_drm_drv.h |  36 ++
 drivers/gpu/drm/sti/sti_gdp.c | 235 ++
 drivers/gpu/drm/sti/sti_gdp.h |   2 +
 3 files changed, 273 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.h

diff --git a/drivers/gpu/drm/sti/sti_drm_drv.h 
b/drivers/gpu/drm/sti/sti_drm_drv.h
new file mode 100644
index 000..5660196
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_drm_drv.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2013
+ * Author: Benjamin Gaignard  for 
STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#ifndef _STI_DRM_DRV_H_
+#define _STI_DRM_DRV_H_
+
+#include 
+
+#include 
+
+#include "sti_compositor.h"
+#include "sti_tvout.h"
+
+/*
+ * STI drm private structure
+ * This structure is stored as private in the drm_device
+ *
+ * @compo: compositor
+ * @tvout: TV OUT
+ * @pageflip_evt_list: list of pending page flip requests
+ * @plane_zorder_property: z-order property for CRTC planes
+ */
+struct sti_drm_private {
+   struct sti_compositor *compo;
+   struct sti_tvout *tvout;
+   struct list_head pageflip_evt_list;
+   struct drm_property *plane_zorder_property;
+};
+
+#define STI_MAX_FB_HEIGHT  4096
+#define STI_MAX_FB_WIDTH   4096
+
+#endif
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index 00ff7f9..095d707 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -9,9 +9,11 @@
 #include 
 #include 

+#include "sti_drm_drv.h"
 #include "sti_layer.h"
 #include "sti_gdp.h"
 #include "sti_vtg_utils.h"
+#include "sti_compositor.h"

 #define ENA_COLOR_FILL  (1 << 8)
 #define WAIT_NEXT_VSYNC (1 << 31)
@@ -29,6 +31,25 @@
 #define GDP_YCBR422R   0x12
 #define GDP_AYCBR  0x15

+#define GDP2STR(fmt) { GDP_ ## fmt, #fmt }
+
+static struct gdp_format_to_str {
+   int format;
+   char name[20];
+} sti_gdp_format_to_str[] = {
+   GDP2STR(RGB565),
+   GDP2STR(RGB888),
+   GDP2STR(RGB888_32),
+   GDP2STR(ARGB8565),
+   GDP2STR(ARGB),
+   GDP2STR(ARGB1555),
+   GDP2STR(ARGB),
+   GDP2STR(CLUT8),
+   GDP2STR(YCBR888),
+   GDP2STR(YCBR422R),
+   GDP2STR(AYCBR)
+   };
+
 #define GAM_GDP_CTL_OFFSET 0x00
 #define GAM_GDP_AGC_OFFSET 0x04
 #define GAM_GDP_VPO_OFFSET 0x0C
@@ -137,6 +158,9 @@ static struct sti_gdp_node_list 
*sti_gdp_get_free_nodes(struct sti_layer *layer)
return &gdp->node_list[i];

 end:
+   DRM_DEBUG_DRIVER("Warning, inconsistent NVN for %s: 0x%08X\n",
+   sti_layer_to_str(layer), hw_nvn);
+
return &gdp->node_list[0];
 }

@@ -169,6 +193,8 @@ struct sti_gdp_node_list *sti_gdp_get_current_nodes(struct 
sti_layer *layer)
return &gdp->node_list[i];

 end:
+   DRM_DEBUG_DRIVER("Warning, NVN 0x%08X for %s does not match any node\n",
+   hw_nvn, sti_layer_to_str(layer));
return NULL;
 }

@@ -198,6 +224,9 @@ static int sti_gdp_prepare_layer(void *lay, bool 
first_prepare)
top_field = list->top_field;
btm_field = list->btm_field;

+   dev_dbg(dev, "%s %s top_node:0x%p btm_node:0x%p\n", __func__,
+   sti_layer_to_str(layer), top_field, btm_field);
+
/* Build the top field from layer params */
top_field->gam_gdp_agc = GAM_GDP_AGC_FULL_RANGE;
top_field->gam_gdp_ctl = WAIT_NEXT_VSYNC;
@@ -294,6 +323,9 @@ static int sti_gdp_commit_layer(void *lay)
u32 dma_updated_btm = virt_to_dma(gdp->dev, updated_btm_node);
struct sti_gdp_node_list *curr_list = sti_gdp_get_current_nodes(layer);

+   dev_dbg(gdp->dev, "%s %s top/btm_node:0x%p/0x%p\n", __func__,
+   sti_layer_to_str(layer),
+   updated_top_node, updated_btm_node);
dev_dbg(gdp->dev, "Current NVN:0x%X\n",
readl(gdp->regs + GAM_GDP_NVN_OFFSET));
dev_dbg(gdp->dev, "Posted buff: %lx current buff: %x\n",
@@ -303,6 +335,8 @@ static int sti_gdp_commit_layer(void *lay)
if (curr_list == NULL) {
/* First update or invalid node should directly write in the
 * hw register */
+   DRM_DEBUG_DRIVER("%s first update (or invalid node)",
+   sti_layer_to_str(layer));
writel(gdp->is_curr_top == true ?
dma_updated_btm : dma_updated_top,
gdp->regs + GAM_GDP_NVN_OFFSET);
@@ -342,6 +376,8 @@ static int sti_gdp_disable_layer(void *lay)
struct sti_layer *layer = (struct sti_layer *)lay;
struct sti_gdp *gdp = layer->gdp;

+   DRM_DEBUG_DRIVER("%s\

[PATCH v3 11/16] drm: sti: add Compositor

2014-05-20 Thread Benjamin Gaignard
Compositor control all the input sub-devices and the mixer.
It is the main entry point for composition.
Layer interface is used to control the layer.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Kconfig  |   1 +
 drivers/gpu/drm/sti/Makefile |   2 +
 drivers/gpu/drm/sti/sti_compositor.c | 219 +
 drivers/gpu/drm/sti/sti_compositor.h |  84 ++
 drivers/gpu/drm/sti/sti_layer.c  | 309 +++
 5 files changed, 615 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/sti_compositor.c
 create mode 100644 drivers/gpu/drm/sti/sti_compositor.h
 create mode 100644 drivers/gpu/drm/sti/sti_layer.c

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index 87e6128..76c2e4f 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,6 +1,7 @@
 config DRM_STI
bool "DRM Support for STMicroelectronics SoC stiH41x Series"
depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
+   select DRM_KMS_CMA_HELPER
help
  Choose this option to enable DRM on STM stiH41x chipset

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index 3d52d2a..3b804d4 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -5,6 +5,8 @@ stidrm-y := sti_tvout.o \
sti_hdmi_tx3g0c55phy.o \
sti_hdmi_tx3g4c28phy.o \
sti_hda.o \
+   sti_compositor.o \
+   sti_layer.o \
sti_mixer.o \
sti_gdp.o \
sti_vid.o \
diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
new file mode 100644
index 000..0c9ef6d
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -0,0 +1,219 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2013
+ * Authors: Benjamin Gaignard 
+ *  Fabien Dessenne 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "sti_compositor.h"
+#include "sti_gdp.h"
+
+static const struct of_device_id compositor_match_types[];
+
+/*
+ * stiH407 compositor properties
+ */
+struct sti_compositor_data stih407_compositor_data = {
+   .nb_subdev = 6,
+   .subdev_desc = {
+   {STI_GPD_SUBDEV, (int)STI_GDP_0, 0x100},
+   {STI_GPD_SUBDEV, (int)STI_GDP_1, 0x200},
+   {STI_GPD_SUBDEV, (int)STI_GDP_2, 0x300},
+   {STI_GPD_SUBDEV, (int)STI_GDP_3, 0x400},
+   {STI_VID_SUBDEV, (int)STI_VID_0, 0x700},
+   {STI_MIXER_MAIN_SUBDEV, STI_MIXER_MAIN, 0xC00}
+   },
+};
+
+/*
+ * stiH416 compositor properties
+ * Note:
+ * on stih416 MIXER_AUX has a different base address from MIXER_MAIN
+ * Moreover, GDPx is different for Main and Aux Mixer. So this subdev map does
+ * not fit for stiH416 if we want to enable the MIXER_AUX.
+ */
+struct sti_compositor_data stih416_compositor_data = {
+   .nb_subdev = 3,
+   .subdev_desc = {
+   {STI_GPD_SUBDEV, (int)STI_GDP_0, 0x100},
+   {STI_GPD_SUBDEV, (int)STI_GDP_1, 0x200},
+   {STI_MIXER_MAIN_SUBDEV, STI_MIXER_MAIN, 0xC00}
+   },
+};
+
+static int sti_compositor_init_subdev(struct sti_compositor *compo,
+   struct sti_compositor_subdev_descriptor *desc,
+   int array_size)
+{
+   int i, mixer_id = 0, layer_id = 0;
+
+   dev_dbg(compo->dev, "%s\n", __func__);
+   for (i = 0; i < array_size; i++) {
+   switch (desc[i].type) {
+   case STI_MIXER_MAIN_SUBDEV:
+   case STI_MIXER_AUX_SUBDEV:
+   compo->mixer[mixer_id++] =
+   sti_mixer_create(compo->dev, desc[i].id,
+compo->regs + desc[i].offset);
+   break;
+   case STI_GPD_SUBDEV:
+   case STI_VID_SUBDEV:
+   compo->layer[layer_id++] =
+   sti_layer_create(compo->dev, desc[i].id,
+compo->regs + desc[i].offset);
+   break;
+   /* case STI_CURSOR_SUBDEV : TODO */
+   default:
+   DRM_ERROR("Unknow subdev compoment type\n");
+   return 1;
+   }
+
+   }
+   compo->nb_mixers = mixer_id;
+   compo->nb_layers = layer_id;
+
+   return 0;
+}
+
+static int sti_compositor_bind(struct device *dev, struct device *master,
+   void *data)
+{
+   return 0;
+}
+
+static void sti_compositor_unbind(struct device *dev, struct device *master,
+   void *data)
+{
+   /* do nothing */
+}
+
+s

[PATCH v3 10/16] drm: sti: add Mixer

2014-05-20 Thread Benjamin Gaignard
Mixer hardware IP is responsible of mixing the different inputs layers.
Z-order is managed by the mixer.
We could 2 mixers: one for main path and one for auxilary path

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile|   1 +
 drivers/gpu/drm/sti/sti_mixer.c | 241 
 drivers/gpu/drm/sti/sti_mixer.h |  52 +
 3 files changed, 294 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/sti_mixer.c
 create mode 100644 drivers/gpu/drm/sti/sti_mixer.h

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index b9a3b74..3d52d2a 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -5,6 +5,7 @@ stidrm-y := sti_tvout.o \
sti_hdmi_tx3g0c55phy.o \
sti_hdmi_tx3g4c28phy.o \
sti_hda.o \
+   sti_mixer.o \
sti_gdp.o \
sti_vid.o \
sti_ddc.o
diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
new file mode 100644
index 000..b6c8214
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -0,0 +1,241 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2013
+ * Authors: Benjamin Gaignard 
+ *  Fabien Dessenne 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include "sti_mixer.h"
+#include "sti_vtg_utils.h"
+
+/* Identity: G=Y , B=Cb , R=Cr */
+static const u32 MixerColorSpaceMatIdentity[] = {
+   0x1000, 0x, 0x1000, 0x1000,
+   0x, 0x, 0x, 0x
+};
+
+/* regs offset */
+#define GAM_MIXER_CTL  0x00
+#define GAM_MIXER_BKC  0x04
+#define GAM_MIXER_BCO  0x0C
+#define GAM_MIXER_BCS  0x10
+#define GAM_MIXER_AVO  0x28
+#define GAM_MIXER_AVS  0x2C
+#define GAM_MIXER_CRB  0x34
+#define GAM_MIXER_ACT  0x38
+#define GAM_MIXER_MBP  0x3C
+#define GAM_MIXER_MX0  0x80
+
+/* id for depth of CRB reg */
+#define GAM_DEPTH_VID0_ID  1
+#define GAM_DEPTH_VID1_ID  2
+#define GAM_DEPTH_GDP0_ID  3
+#define GAM_DEPTH_GDP1_ID  4
+#define GAM_DEPTH_GDP2_ID  5
+#define GAM_DEPTH_GDP3_ID  6
+#define GAM_DEPTH_MASK_ID  7
+
+/* mask in CTL reg */
+#define GAM_CTL_BACK_MASK  (1 << 0)
+#define GAM_CTL_VID0_MASK  (1 << 1)
+#define GAM_CTL_VID1_MASK  (1 << 2)
+#define GAM_CTL_GDP0_MASK  (1 << 3)
+#define GAM_CTL_GDP1_MASK  (1 << 4)
+#define GAM_CTL_GDP2_MASK  (1 << 5)
+#define GAM_CTL_GDP3_MASK  (1 << 6)
+
+const char *sti_mixer_to_str(struct sti_mixer *mixer)
+{
+   switch (mixer->id) {
+   case STI_MIXER_MAIN:
+   return "MAIN_MIXER";
+   case STI_MIXER_AUX:
+   return "AUX_MIXER";
+   default:
+   return "";
+   }
+}
+
+static inline u32 sti_mixer_reg_read(struct sti_mixer *mixer, u32 reg_id)
+{
+   return readl(mixer->regs + reg_id);
+}
+
+static inline void sti_mixer_reg_write(struct sti_mixer *mixer,
+  u32 reg_id, u32 val)
+{
+   writel(val, mixer->regs + reg_id);
+}
+
+static inline void sti_mixer_reg_writemask(struct sti_mixer *mixer,
+  u32 reg_id, u32 val, u32 mask)
+{
+   u32 old = sti_mixer_reg_read(mixer, reg_id);
+
+   val = (val & mask) | (old & ~mask);
+   writel(val, mixer->regs + reg_id);
+}
+
+void sti_mixer_set_background_status(struct sti_mixer *mixer, bool enable)
+{
+   sti_mixer_reg_writemask(mixer,
+   GAM_MIXER_CTL, enable, GAM_CTL_BACK_MASK);
+}
+
+static void sti_mixer_set_background_color(struct sti_mixer *mixer,
+  int red, int green, int blue)
+{
+   u32 val = (red << 16) | (green << 8) | blue;
+
+   sti_mixer_reg_write(mixer, GAM_MIXER_BKC, val);
+}
+
+static void sti_mixer_set_background_area(struct sti_mixer *mixer,
+ struct drm_display_mode *mode)
+{
+   u32 ydo, xdo, yds, xds;
+
+   ydo = sti_vtg_get_line_number(*mode, 0);
+   yds = sti_vtg_get_line_number(*mode, mode->vdisplay - 1);
+   xdo = sti_vtg_get_pixel_number(*mode, 0);
+   xds = sti_vtg_get_pixel_number(*mode, mode->hdisplay - 1);
+
+   sti_mixer_reg_write(mixer, GAM_MIXER_BCO, ydo << 16 | xdo);
+   sti_mixer_reg_write(mixer, GAM_MIXER_BCS, yds << 16 | xds);
+}
+
+int sti_mixer_set_layer_depth(struct sti_mixer *mixer, struct sti_layer *layer)
+{
+   int layer_id = 0, depth = layer->zorder;
+   u32 mask;
+
+   if (depth >= GAM_MIXER_NB_DEPTH_LEVEL)
+   return 1;
+
+   switch (layer->desc) {
+   case STI_GDP_0:
+   layer_id = GAM_DEPTH_GDP0_ID;
+   break;
+   case STI_GDP_1:
+   layer_id = GAM_DEPTH_GDP1_ID;
+   break;
+   case STI_GDP_2:
+   layer_id = GAM_DEPTH_GDP2_ID;
+   break;
+  

[PATCH v3 09/16] drm: sti: add VID layer

2014-05-20 Thread Benjamin Gaignard
VIDeo plug are one of the compositor input sub-devices.
VID are dedicated to video inputs like YUV plans.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile|   1 +
 drivers/gpu/drm/sti/sti_layer.h |   4 ++
 drivers/gpu/drm/sti/sti_vid.c   | 138 
 drivers/gpu/drm/sti/sti_vid.h   |  33 ++
 4 files changed, 176 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/sti_vid.c
 create mode 100644 drivers/gpu/drm/sti/sti_vid.h

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index cc04475..b9a3b74 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -6,6 +6,7 @@ stidrm-y := sti_tvout.o \
sti_hdmi_tx3g4c28phy.o \
sti_hda.o \
sti_gdp.o \
+   sti_vid.o \
sti_ddc.o

 obj-$(CONFIG_VTAC_STI) += sti_vtac_tx.o sti_vtac_rx.o
diff --git a/drivers/gpu/drm/sti/sti_layer.h b/drivers/gpu/drm/sti/sti_layer.h
index 45cd1ea..bf3a14f 100644
--- a/drivers/gpu/drm/sti/sti_layer.h
+++ b/drivers/gpu/drm/sti/sti_layer.h
@@ -11,6 +11,7 @@

 #include 
 #include "sti_gdp.h"
+#include "sti_vid.h"

 #define to_sti_layer(x) container_of(x, struct sti_layer, plane)

@@ -58,6 +59,7 @@ struct sti_fps_info {
  * @mode:  display mode
  * @desc:  layer type & id
  * @zorder:layer z-order
+ * @mixer_id:   id of the mixer used to display the layer
  * @enabled:   to know if the layer is active or not
  * @src_x src_y:   coordinates of the input (fb) area
  * @src_w src_h:   size of the input (fb) area
@@ -69,6 +71,7 @@ struct sti_fps_info {
  * @paddr: physical address of the input buffer
  * @fps_info:  frame per second info
  * @gdp:related GDP (if the layer is a GDP)
+ * @vid:related VID (if the layer is a VID/VDP)
  */
 struct sti_layer {
struct drm_plane plane;
@@ -88,6 +91,7 @@ struct sti_layer {
dma_addr_t paddr;
struct sti_fps_info fps_info;
struct sti_gdp *gdp;
+   struct sti_vid *vid;
 };

 struct sti_layer *sti_layer_create(struct device *dev, int desc,
diff --git a/drivers/gpu/drm/sti/sti_vid.c b/drivers/gpu/drm/sti/sti_vid.c
new file mode 100644
index 000..710665d
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_vid.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2013
+ * Author: Fabien Dessenne  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+
+#include "sti_vid.h"
+#include "sti_layer.h"
+#include "sti_vtg_utils.h"
+
+/* Registers */
+#define VID_CTL 0x00
+#define VID_ALP 0x04
+#define VID_CLF 0x08
+#define VID_VPO 0x0C
+#define VID_VPS 0x10
+#define VID_KEY10x28
+#define VID_KEY20x2C
+#define VID_MPR00x30
+#define VID_MPR10x34
+#define VID_MPR20x38
+#define VID_MPR30x3C
+#define VID_MST 0x68
+#define VID_BC  0x70
+#define VID_TINT0x74
+#define VID_CSAT0x78
+
+/* Registers values */
+#define VID_CTL_IGNORE  ((1<<30) | (1<<31))
+#define VID_CTL_PSI_ENABLE  ((1<<2) | (1<<1) | (1<<0))
+#define VID_ALP_OPAQUE  0x0080
+#define VID_BC_DFLT 0x8000
+#define VID_TINT_DFLT   0x
+#define VID_CSAT_DFLT   0x0080
+/* YCbCr to RGB BT709:
+ * R = Y+1.5391Cr
+ * G = Y-0.4590Cr-0.1826Cb
+ * B = Y+1.8125Cb */
+#define VID_MPR0_BT709  0x0A80
+#define VID_MPR1_BT709  0x0AC5
+#define VID_MPR2_BT709  0x07150545
+#define VID_MPR3_BT709  0x0AE8
+
+static int sti_vid_prepare_layer(void *lay, bool first_prepare)
+{
+   u32 val;
+   struct sti_layer *layer = (struct sti_layer *)lay;
+   struct sti_vid *vid = layer->vid;
+
+   /* Unmask */
+   val = readl(vid->regs + VID_CTL);
+   val &= ~VID_CTL_IGNORE;
+   writel(val, vid->regs + VID_CTL);
+
+   return 0;
+}
+
+static int sti_vid_commit_layer(void *lay)
+{
+   struct sti_layer *layer = (struct sti_layer *)lay;
+   struct sti_vid *vid = layer->vid;
+   struct drm_display_mode *mode = layer->mode;
+   u32 ydo, xdo, yds, xds;
+
+   ydo = sti_vtg_get_line_number(*mode, layer->dst_y);
+   yds = sti_vtg_get_line_number(*mode, layer->dst_y + layer->dst_h - 1);
+   xdo = sti_vtg_get_pixel_number(*mode, layer->dst_x);
+   xds = sti_vtg_get_pixel_number(*mode, layer->dst_x + layer->dst_w - 1);
+
+   writel((ydo << 16) | xdo, vid->regs + VID_VPO);
+   writel((yds << 16) | xds, vid->regs + VID_VPS);
+
+   return 0;
+}
+
+static int sti_vid_disable_layer(void *lay)
+{
+   u32 val;
+   struct sti_layer *layer = (struct sti_layer *)lay;
+   st

[PATCH v3 08/16] drm: sti: add GDP layer

2014-05-20 Thread Benjamin Gaignard
Generic Display Pipeline are one of the compositor input sub-devices.
GDP are dedicated to graphic input like RGB plans.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile|   3 +-
 drivers/gpu/drm/sti/sti_gdp.c   | 491 
 drivers/gpu/drm/sti/sti_gdp.h   |  73 ++
 drivers/gpu/drm/sti/sti_layer.h |   5 +
 4 files changed, 571 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/sti/sti_gdp.c
 create mode 100644 drivers/gpu/drm/sti/sti_gdp.h

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index 45536c3..cc04475 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -1,10 +1,11 @@
 ccflags-y := -Iinclude/drm

-stidrm-y :=sti_tvout.o \
+stidrm-y := sti_tvout.o \
sti_hdmi.o \
sti_hdmi_tx3g0c55phy.o \
sti_hdmi_tx3g4c28phy.o \
sti_hda.o \
+   sti_gdp.o \
sti_ddc.o

 obj-$(CONFIG_VTAC_STI) += sti_vtac_tx.o sti_vtac_rx.o
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
new file mode 100644
index 000..00ff7f9
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -0,0 +1,491 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2013
+ * Authors: Benjamin Gaignard 
+ *  Fabien Dessenne 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+
+#include "sti_layer.h"
+#include "sti_gdp.h"
+#include "sti_vtg_utils.h"
+
+#define ENA_COLOR_FILL  (1 << 8)
+#define WAIT_NEXT_VSYNC (1 << 31)
+
+/* GDP color formats */
+#define GDP_RGB565 0x00
+#define GDP_RGB888 0x01
+#define GDP_RGB888_32  0x02
+#define GDP_ARGB8565   0x04
+#define GDP_ARGB   0x05
+#define GDP_ARGB1555   0x06
+#define GDP_ARGB   0x07
+#define GDP_CLUT8  0x0B
+#define GDP_YCBR8880x10
+#define GDP_YCBR422R   0x12
+#define GDP_AYCBR  0x15
+
+#define GAM_GDP_CTL_OFFSET 0x00
+#define GAM_GDP_AGC_OFFSET 0x04
+#define GAM_GDP_VPO_OFFSET 0x0C
+#define GAM_GDP_VPS_OFFSET 0x10
+#define GAM_GDP_PML_OFFSET 0x14
+#define GAM_GDP_PMP_OFFSET 0x18
+#define GAM_GDP_SIZE_OFFSET0x1C
+#define GAM_GDP_NVN_OFFSET 0x24
+#define GAM_GDP_KEY1_OFFSET0x28
+#define GAM_GDP_KEY2_OFFSET0x2C
+#define GAM_GDP_PPT_OFFSET 0x34
+#define GAM_GDP_CML_OFFSET 0x3C
+#define GAM_GDP_MST_OFFSET 0x68
+
+#define GAM_GDP_ALPHARANGE_255  (1 << 5)
+#define GAM_GDP_AGC_FULL_RANGE 0x00808080
+#define GAM_GDP_PPT_IGNORE  ((1 << 1) | (1 << 0))
+#define GAM_GDP_SIZE_MAX0x7FF
+
+static const uint32_t gdp_supported_formats[] = {
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ARGB1555,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_RGB888,
+   DRM_FORMAT_AYUV,
+   DRM_FORMAT_YUV444,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_C8,
+};
+
+static const uint32_t *sti_gdp_get_formats(void)
+{
+   return gdp_supported_formats;
+}
+
+static int sti_gdp_get_nb_formats(void)
+{
+   return ARRAY_SIZE(gdp_supported_formats);
+}
+
+static int sti_gdp_fourcc2format(int fourcc)
+{
+   switch (fourcc) {
+   case DRM_FORMAT_XRGB:
+   return GDP_RGB888_32;
+   case DRM_FORMAT_ARGB:
+   return GDP_ARGB;
+   case DRM_FORMAT_ARGB:
+   return GDP_ARGB;
+   case DRM_FORMAT_ARGB1555:
+   return GDP_ARGB1555;
+   case DRM_FORMAT_RGB565:
+   return GDP_RGB565;
+   case DRM_FORMAT_RGB888:
+   return GDP_RGB888;
+   case DRM_FORMAT_AYUV:
+   return GDP_AYCBR;
+   case DRM_FORMAT_YUV444:
+   return GDP_YCBR888;
+   case DRM_FORMAT_VYUY:
+   return GDP_YCBR422R;
+   case DRM_FORMAT_C8:
+   return GDP_CLUT8;
+   }
+   return -1;
+}
+
+static int sti_gdp_get_alpharange(int format)
+{
+   switch (format) {
+   case GDP_ARGB8565:
+   case GDP_ARGB:
+   case GDP_AYCBR:
+   return GAM_GDP_ALPHARANGE_255;
+   }
+   return 0;
+}
+
+/**
+ * sti_gdp_get_free_nodes
+ * @layer: gdp layer
+ *
+ * Look for a GDP node list that is not currently read by the HW.
+ *
+ * RETURNS:
+ * Pointer to the free GDP node list
+ */
+static struct sti_gdp_node_list *sti_gdp_get_free_nodes(struct sti_layer 
*layer)
+{
+   int hw_nvn;
+   void *virt_nvn;
+   struct sti_gdp *gdp = layer->gdp;
+   int i;
+
+   hw_nvn = readl(gdp->regs + GAM_GDP_NVN_OFFSET);
+   if (!hw_nvn)
+   goto end;
+
+   virt_nvn = dma_to_virt(gdp->dev, (dma_addr_t) hw_nvn);
+
+   for (i = 0; i < GDP_NODE_NB_BANK; i++)
+   if ((virt_nvn != gdp->node_list[i].btm_field) &&
+   (virt_nvn != gdp->node_list[i].top_field))
+   return &gdp->node_lis

[PATCH v3 07/16] drm: sti: add sti layer interface definition

2014-05-20 Thread Benjamin Gaignard
STI hardware have various input sub-devices before mixing block.
Each type of sub-device have different capabilities for scaling,
filtering or accepted pixel format.
This layer interface abstract those differences and make the interaction
with compositor more simple.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_layer.h | 104 
 1 file changed, 104 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/sti_layer.h

diff --git a/drivers/gpu/drm/sti/sti_layer.h b/drivers/gpu/drm/sti/sti_layer.h
new file mode 100644
index 000..ed8386a
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_layer.h
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2013
+ * Authors: Benjamin Gaignard 
+ *  Fabien Dessenne 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#ifndef _STI_LAYER_H_
+#define _STI_LAYER_H_
+
+#include 
+
+#define to_sti_layer(x) container_of(x, struct sti_layer, plane)
+
+#define STI_LAYER_TYPE_SHIFT 8
+#define STI_LAYER_TYPE_MASK (~((1<

[PATCH v3 06/16] drm: sti: add TVOut driver

2014-05-20 Thread Benjamin Gaignard
TVout hardware block is responsible to dispatch the data flow coming
from compositor block to any of the output (HDMI or Analog TV).
It control when output are start/stop and configure according the
require flow path.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile|   3 +-
 drivers/gpu/drm/sti/sti_hda.c   | 372 +
 drivers/gpu/drm/sti/sti_hda.h   |  14 +
 drivers/gpu/drm/sti/sti_hdmi.c  | 542 +++
 drivers/gpu/drm/sti/sti_hdmi.h  |   3 +
 drivers/gpu/drm/sti/sti_tvout.c | 702 
 drivers/gpu/drm/sti/sti_tvout.h | 105 ++
 7 files changed, 1740 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/sti/sti_hda.h
 create mode 100644 drivers/gpu/drm/sti/sti_tvout.c
 create mode 100644 drivers/gpu/drm/sti/sti_tvout.h

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index aa69ea0..45536c3 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -1,6 +1,7 @@
 ccflags-y := -Iinclude/drm

-stidrm-y := sti_hdmi.o \
+stidrm-y :=sti_tvout.o \
+   sti_hdmi.o \
sti_hdmi_tx3g0c55phy.o \
sti_hdmi_tx3g4c28phy.o \
sti_hda.o \
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 315aa0e..dc55ed7 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -11,6 +11,8 @@

 #include 

+#include "sti_hda.h"
+
 /* HDformatter registers */
 #define HDA_ANA_CFG 0x
 #define HDA_ANA_SCALE_CTRL_Y0x0004
@@ -372,6 +374,376 @@ static int sti_hda_get_modes(struct drm_connector 
*drm_connector)
return count;
 }

+/*
+ * Start hd analog
+ *
+ * @connector: pointer on the tvout HD analog connector
+ *
+ * Return 0 on success
+ */
+static int sti_hda_start(struct sti_tvout_connector *connector)
+{
+   struct sti_hda *hda = (struct sti_hda *)connector->priv;
+   u32 val, i, mode_idx;
+   u32 src_filter_y, src_filter_c;
+   u32 *coef_y, *coef_c;
+   u32 filter_mode;
+
+   DRM_DEBUG_DRIVER("\n");
+
+   /* Prepare/enable clocks */
+   if (clk_prepare_enable(hda->clk_pix))
+   DRM_ERROR("Failed to prepare/enable hda_pix clk\n");
+   if (clk_prepare_enable(hda->clk_hddac))
+   DRM_ERROR("Failed to prepare/enable hda_hddac clk\n");
+
+   hda->enabled = true;
+
+   if (!hda_get_mode_idx(hda->mode, &mode_idx)) {
+   DRM_ERROR("Undefined mode\n");
+   return 1;
+   }
+
+   switch (hda_supported_modes[mode_idx].vid_cat) {
+   case VID_HD_148M:
+   DRM_ERROR("Beyond HD analog capabilities\n");
+   return 1;
+   case VID_HD_74M:
+   /* HD use alternate 2x filter */
+   filter_mode = CFG_AWG_FLTR_MODE_HD;
+   src_filter_y = HDA_ANA_SRC_Y_CFG_ALT_2X;
+   src_filter_c = HDA_ANA_SRC_C_CFG_ALT_2X;
+   coef_y = coef_y_alt_2x;
+   coef_c = coef_c_alt_2x;
+   break;
+   case VID_ED:
+   /* ED uses 4x filter */
+   filter_mode = CFG_AWG_FLTR_MODE_ED;
+   src_filter_y = HDA_ANA_SRC_Y_CFG_4X;
+   src_filter_c = HDA_ANA_SRC_C_CFG_4X;
+   coef_y = coef_yc_4x;
+   coef_c = coef_yc_4x;
+   break;
+   case VID_SD:
+   DRM_ERROR("Not supported\n");
+   return 1;
+   default:
+   DRM_ERROR("Undefined resolution\n");
+   return 1;
+   }
+   DRM_DEBUG_DRIVER("Using HDA mode #%d\n", mode_idx);
+
+   /* Enable HD Video DACs */
+   hda_enable_hd_dacs(hda, true);
+
+   /* Configure scaler */
+   writel(SCALE_CTRL_Y_DFLT, hda->regs + HDA_ANA_SCALE_CTRL_Y);
+   writel(SCALE_CTRL_CB_DFLT, hda->regs + HDA_ANA_SCALE_CTRL_CB);
+   writel(SCALE_CTRL_CR_DFLT, hda->regs + HDA_ANA_SCALE_CTRL_CR);
+
+   /* Configure sampler */
+   writel(src_filter_y, hda->regs + HDA_ANA_SRC_Y_CFG);
+   writel(src_filter_c, hda->regs + HDA_ANA_SRC_C_CFG);
+   for (i = 0; i < SAMPLER_COEF_NB; i++) {
+   writel(coef_y[i], hda->regs + HDA_COEFF_Y_PH1_TAP123 + i * 4);
+   writel(coef_c[i], hda->regs + HDA_COEFF_C_PH1_TAP123 + i * 4);
+   }
+
+   /* Configure main HDFormatter */
+   val = 0;
+   val |= (hda->mode.flags & DRM_MODE_FLAG_INTERLACE) ?
+   0 : CFG_AWG_ASYNC_VSYNC_MTD;
+   val |= (CFG_PBPR_SYNC_OFF_VAL << CFG_PBPR_SYNC_OFF_SHIFT);
+   val |= filter_mode;
+   writel(val, hda->regs + HDA_ANA_CFG);
+
+   /* Configure AWG */
+   sti_hda_configure_awg(hda, hda_supported_modes[mode_idx].awg_instr,
+ hda_supported_modes[mode_idx].nb_instr);
+
+   /* Enable AWG */
+   hda_reg_writemask(hda->regs + HDA_ANA_CFG, 1, CFG_AWG_ASYNC_EN);
+
+   return 0;

[PATCH v3 05/16] drm: sti: add HDA driver

2014-05-20 Thread Benjamin Gaignard
Add driver to support analog TV ouput.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile  |   1 +
 drivers/gpu/drm/sti/sti_hda.c | 480 ++
 2 files changed, 481 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/sti_hda.c

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index 6c474eb..aa69ea0 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm
 stidrm-y := sti_hdmi.o \
sti_hdmi_tx3g0c55phy.o \
sti_hdmi_tx3g4c28phy.o \
+   sti_hda.o \
sti_ddc.o

 obj-$(CONFIG_VTAC_STI) += sti_vtac_tx.o sti_vtac_rx.o
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
new file mode 100644
index 000..315aa0e
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -0,0 +1,480 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Author: Fabien Dessenne  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* HDformatter registers */
+#define HDA_ANA_CFG 0x
+#define HDA_ANA_SCALE_CTRL_Y0x0004
+#define HDA_ANA_SCALE_CTRL_CB   0x0008
+#define HDA_ANA_SCALE_CTRL_CR   0x000C
+#define HDA_ANA_ANC_CTRL0x0010
+#define HDA_ANA_SRC_Y_CFG   0x0014
+#define HDA_COEFF_Y_PH1_TAP123  0x0018
+#define HDA_COEFF_Y_PH1_TAP456  0x001C
+#define HDA_COEFF_Y_PH2_TAP123  0x0020
+#define HDA_COEFF_Y_PH2_TAP456  0x0024
+#define HDA_COEFF_Y_PH3_TAP123  0x0028
+#define HDA_COEFF_Y_PH3_TAP456  0x002C
+#define HDA_COEFF_Y_PH4_TAP123  0x0030
+#define HDA_COEFF_Y_PH4_TAP456  0x0034
+#define HDA_ANA_SRC_C_CFG   0x0040
+#define HDA_COEFF_C_PH1_TAP123  0x0044
+#define HDA_COEFF_C_PH1_TAP456  0x0048
+#define HDA_COEFF_C_PH2_TAP123  0x004C
+#define HDA_COEFF_C_PH2_TAP456  0x0050
+#define HDA_COEFF_C_PH3_TAP123  0x0054
+#define HDA_COEFF_C_PH3_TAP456  0x0058
+#define HDA_COEFF_C_PH4_TAP123  0x005C
+#define HDA_COEFF_C_PH4_TAP456  0x0060
+#define HDA_SYNC_AWGI   0x0300
+
+/* HDA_ANA_CFG */
+#define CFG_AWG_ASYNC_EN(1 << 0)
+#define CFG_AWG_ASYNC_HSYNC_MTD (1 << 1)
+#define CFG_AWG_ASYNC_VSYNC_MTD (1 << 2)
+#define CFG_AWG_SYNC_DEL(1 << 3)
+#define CFG_AWG_FLTR_MODE_SHIFT 4
+#define CFG_AWG_FLTR_MODE_MASK  (0xF << CFG_AWG_FLTR_MODE_SHIFT)
+#define CFG_AWG_FLTR_MODE_SD(0 << CFG_AWG_FLTR_MODE_SHIFT)
+#define CFG_AWG_FLTR_MODE_ED(1 << CFG_AWG_FLTR_MODE_SHIFT)
+#define CFG_AWG_FLTR_MODE_HD(2 << CFG_AWG_FLTR_MODE_SHIFT)
+#define CFG_SYNC_ON_PBPR_MASK   (1 << 8)
+#define CFG_PREFILTER_EN_MASK   (1 << 9)
+#define CFG_PBPR_SYNC_OFF_SHIFT 16
+#define CFG_PBPR_SYNC_OFF_MASK  (0x7FF << CFG_PBPR_SYNC_OFF_SHIFT)
+#define CFG_PBPR_SYNC_OFF_VAL   0x117  /* Voltage dependent. stiH416 */
+
+/* Default scaling values */
+#define SCALE_CTRL_Y_DFLT   0x00C50256
+#define SCALE_CTRL_CB_DFLT  0x00DB0249
+#define SCALE_CTRL_CR_DFLT  0x00DB0249
+
+/* Video DACs control */
+#define VIDEO_DACS_CONTROL_MASK 0x0FFF
+#define VIDEO_DACS_CONTROL_SYSCFG2535   0x085C /* for stih416 */
+#define DAC_CFG_HD_OFF_SHIFT5
+#define DAC_CFG_HD_OFF_MASK (0x7 << DAC_CFG_HD_OFF_SHIFT)
+#define VIDEO_DACS_CONTROL_SYSCFG5072   0x0120 /* for stih407 */
+#define DAC_CFG_HD_HZUVW_OFF_SHIFT  1
+#define DAC_CFG_HD_HZUVW_OFF_MASK   (0x1 << DAC_CFG_HD_HZUVW_OFF_SHIFT)
+
+
+/* Upsampler values for the alternative 2X Filter */
+#define SAMPLER_COEF_NB 8
+#define HDA_ANA_SRC_Y_CFG_ALT_2X0x0113
+static u32 coef_y_alt_2x[] = {
+   0x00FE83FB, 0x1F900401, 0x, 0x,
+   0x00F408F9, 0x055F7C25, 0x, 0x
+};
+
+#define HDA_ANA_SRC_C_CFG_ALT_2X0x01750004
+static u32 coef_c_alt_2x[] = {
+   0x001305F7, 0x05274BD0, 0x, 0x,
+   0x0004907C, 0x09C80B9D, 0x, 0x
+};
+
+/* Upsampler values for the 4X Filter */
+#define HDA_ANA_SRC_Y_CFG_4X0x01ED0005
+#define HDA_ANA_SRC_C_CFG_4X0x01ED0004
+static u32 coef_yc_4x[] = {
+   0x00FC827F, 0x008FE20B, 0x00F684FC, 0x050F7C24,
+   0x00F4857C, 0x0A1F402E, 0x00FA027F, 0x0E076E1D
+};
+
+/* AWG instructions for some video modes */
+#define AWG_MAX_INST64
+
+/* 720p at 50 */
+static u32 AWGi_720p_50[] = {
+   0x0971, 0x0C26, 0x013B, 0x0CDA,
+   0x0104, 0x0E7E, 0x0E7F, 0x013B,
+   0x0D8E, 0x0104, 0x1804, 0x0971,
+   0x0C26, 0x003B, 0x0FB4, 0x0FB5,
+

[PATCH v3 04/16] drm: sti: add I2C client driver for HDMI

2014-05-20 Thread Benjamin Gaignard
Add I2C client driver to retrieve EDID.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile  |  3 ++-
 drivers/gpu/drm/sti/sti_ddc.c | 56 +++
 2 files changed, 58 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/sti/sti_ddc.c

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index 5295fc7..6c474eb 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -2,7 +2,8 @@ ccflags-y := -Iinclude/drm

 stidrm-y := sti_hdmi.o \
sti_hdmi_tx3g0c55phy.o \
-   sti_hdmi_tx3g4c28phy.o
+   sti_hdmi_tx3g4c28phy.o \
+   sti_ddc.o

 obj-$(CONFIG_VTAC_STI) += sti_vtac_tx.o sti_vtac_rx.o
 obj-$(CONFIG_VTG_STI) += sti_vtg.o sti_vtg_utils.o
diff --git a/drivers/gpu/drm/sti/sti_ddc.c b/drivers/gpu/drm/sti/sti_ddc.c
new file mode 100644
index 000..147a704
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_ddc.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2013
+ * Author: Benjamin Gaignard  for 
STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#include 
+
+#include 
+#include 
+#include 
+
+#include "sti_hdmi.h"
+
+static int sti_hdmi_ddc_probe(struct i2c_client *client,
+ const struct i2c_device_id *dev_id)
+{
+   sti_hdmi_attach_ddc_client(client);
+
+   DRM_INFO("%s attached %s into i2c adapter successfully\n",
+__func__, client->name);
+
+   return 0;
+}
+
+static int sti_hdmi_ddc_remove(struct i2c_client *client)
+{
+   DRM_INFO("%s detached %s from i2c adapter successfully\n",
+__func__, client->name);
+
+   return 0;
+}
+
+static struct i2c_device_id sti_ddc_idtable[] = {
+   {"sti-hdmiddc", 0},
+   {},
+};
+
+static struct of_device_id hdmiddc_match_types[] = {
+   {
+.compatible = "st,sti-hdmiddc",
+}, {
+/* end node */
+}
+};
+
+struct i2c_driver ddc_driver = {
+   .driver = {
+  .name = "sti-hdmiddc",
+  .owner = THIS_MODULE,
+  .of_match_table = of_match_ptr(hdmiddc_match_types),
+  },
+   .id_table = sti_ddc_idtable,
+   .probe = sti_hdmi_ddc_probe,
+   .remove = sti_hdmi_ddc_remove,
+   .command = NULL,
+};
-- 
1.9.1



[PATCH v3 03/16] drm: sti: add HDMI driver

2014-05-20 Thread Benjamin Gaignard
Add driver for HDMI ouput

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile   |   5 +
 drivers/gpu/drm/sti/sti_hdmi.c | 529 +
 drivers/gpu/drm/sti/sti_hdmi.h | 195 +++
 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 398 ++
 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 224 
 5 files changed, 1351 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/sti_hdmi.c
 create mode 100644 drivers/gpu/drm/sti/sti_hdmi.h
 create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c
 create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index 79fdcb6..5295fc7 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -1,4 +1,9 @@
 ccflags-y := -Iinclude/drm

+stidrm-y := sti_hdmi.o \
+   sti_hdmi_tx3g0c55phy.o \
+   sti_hdmi_tx3g4c28phy.o
+
 obj-$(CONFIG_VTAC_STI) += sti_vtac_tx.o sti_vtac_rx.o
 obj-$(CONFIG_VTG_STI) += sti_vtg.o sti_vtg_utils.o
+obj-$(CONFIG_DRM_STI) += stidrm.o
\ No newline at end of file
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
new file mode 100644
index 000..02b0524
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -0,0 +1,529 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2013
+ * Author: Vincent Abriou  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "sti_hdmi.h"
+#include "sti_vtg_utils.h"
+
+/* Reference to the hdmi device */
+struct device *hdmi_dev;
+
+/*
+ * Helper to write bit field
+ *
+ * @addr: register to update
+ * @val: value to write
+ * @mask: bit field mask to use
+ */
+static inline void hdmi_reg_writemask(void __iomem *addr, u32 val, u32 mask)
+{
+   u32 old = readl(addr);
+
+   val = (val & mask) | (old & ~mask);
+   writel(val, addr);
+}
+
+/*
+ * HDMI interrupt handler
+ *
+ * @irq: irq number
+ * @arg: connector structure
+ */
+static irqreturn_t hdmi_irq_thread(int irq, void *arg)
+{
+   struct sti_hdmi *hdmi = arg;
+   u32 status;
+
+   /* read interrupt status */
+   status = readl(hdmi->regs + HDMI_INT_STA);
+
+   /* PLL lock interrupt */
+   if (status & HDMI_INT_DLL_LCK) {
+   hdmi->event_received = true;
+   wake_up_interruptible(&hdmi->wait_event);
+   }
+
+   /* Hot plug detection */
+   if (status & HDMI_INT_HOT_PLUG) {
+   hdmi->hpd = gpio_get_value(hdmi->hpd_gpio);
+   if (hdmi->drm_dev)
+   drm_helper_hpd_irq_event(hdmi->drm_dev);
+   }
+
+   /* Sw reset completed */
+   if (status & HDMI_INT_SW_RST) {
+   hdmi->event_received = true;
+   wake_up_interruptible(&hdmi->wait_event);
+   }
+
+   /* clear interrupt status */
+   writel(status, hdmi->regs + HDMI_INT_CLR);
+
+   /* TODO: check why this sync bus write solves the problem which
+* is that without this line, the handler is sometimes called twice
+*/
+   /* sync bus write */
+   readl(hdmi->regs + HDMI_INT_STA);
+
+   return IRQ_HANDLED;
+}
+
+/*
+ * Start hdmi phy interface
+ *
+ * @hdmi: pointer on the hdmi internal structure
+ *
+ * Return -1 if error occurs
+ */
+static int hdmi_phy_start(struct sti_hdmi *hdmi)
+{
+   DRM_DEBUG_DRIVER("\n");
+
+   if (hdmi->tx3g0c55phy)
+   return sti_hdmi_tx3g0c55phy_start(hdmi);
+
+   return sti_hdmi_tx3g4c28phy_start(hdmi);
+}
+
+/*
+ * Stop hdmi phy interface
+ *
+ * @hdmi: pointer on the hdmi internal structure
+ */
+static void hdmi_phy_stop(struct sti_hdmi *hdmi)
+{
+   DRM_DEBUG_DRIVER("\n");
+
+   if (hdmi->tx3g0c55phy)
+   sti_hdmi_tx3g0c55phy_stop(hdmi);
+   else
+   sti_hdmi_tx3g4c28phy_stop(hdmi);
+}
+
+/*
+ * Set hdmi active area depending on the drm display mode selected
+ *
+ * @hdmi: pointer on the hdmi internal structure
+ */
+static void hdmi_active_area(struct sti_hdmi *hdmi)
+{
+   u32 xmin, xmax;
+   u32 ymin, ymax;
+
+   DRM_DEBUG_DRIVER("\n");
+
+   /*
+*   ActiveFrontSync   Back  Active
+*   RegionPorch  Porch  Region
+* <---><>0<-><><->
+*
+*   ///|   |  ///|
+*  /// |   | /// |
+* ///  |...|///  |
+*0___  x/ymin   x/ymax
+*
+* <--[hv]display--> <--[hv]display-->
+* <--[hv

[PATCH v3 02/16] drm: sti: add VTAC drivers

2014-05-20 Thread Benjamin Gaignard
Video Trafic Advance Communication Rx and Tx drivers are designed
for inter-die communication.

Both Tx and Rx must share the same configuration to communicate
that is why vtac_mode[] is shared in sti_vtac_utils.h.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Kconfig  |   6 ++
 drivers/gpu/drm/sti/Makefile |   1 +
 drivers/gpu/drm/sti/sti_vtac_rx.c| 169 
 drivers/gpu/drm/sti/sti_vtac_tx.c| 182 +++
 drivers/gpu/drm/sti/sti_vtac_utils.h |  52 ++
 5 files changed, 410 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/sti_vtac_rx.c
 create mode 100644 drivers/gpu/drm/sti/sti_vtac_tx.c
 create mode 100644 drivers/gpu/drm/sti/sti_vtac_utils.h

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index 3fff278..87e6128 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -4,6 +4,12 @@ config DRM_STI
help
  Choose this option to enable DRM on STM stiH41x chipset

+config VTAC_STI
+   bool "Video Trafic Advance Communication Rx and Tx for 
STMicroelectronics SoC stiH41x Series"
+   depends on DRM_STI
+   help
+ Choose this option to enable VTAC on STM stiH41x chipset
+
 config VTG_STI
bool "Video Timing Generator for STMicroelectronics SoC stiH41x Series"
depends on DRM_STI
diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index 33216e1..79fdcb6 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -1,3 +1,4 @@
 ccflags-y := -Iinclude/drm

+obj-$(CONFIG_VTAC_STI) += sti_vtac_tx.o sti_vtac_rx.o
 obj-$(CONFIG_VTG_STI) += sti_vtg.o sti_vtg_utils.o
diff --git a/drivers/gpu/drm/sti/sti_vtac_rx.c 
b/drivers/gpu/drm/sti/sti_vtac_rx.c
new file mode 100644
index 000..77eae19
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_vtac_rx.c
@@ -0,0 +1,169 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2013
+ * Author: Benjamin Gaignard  for 
STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "sti_vtac_utils.h"
+
+#define VTAC_RX_CONFIG 0x00
+#define VTAC_RX_FIFO_CONFIG0x04
+
+#define VTAC_SW_RST_AUTOC  0x02
+#define VTAC_FIFO_CONFIG_VAL   0x04
+
+/*
+ * VTAC RX structure
+ *
+ * @dev: pointer to device structure
+ * @regs: ioremapped regsiters
+ * @clk: clock
+ * @type: main or aux device
+ */
+struct sti_vtac_rx {
+   struct device *dev;
+   void __iomem *regs;
+   struct clk *clk;
+   int type;
+};
+
+static void sti_vtac_rx_reg_dump(struct sti_vtac_rx *vtac_rx)
+{
+   dev_dbg(vtac_rx->dev, "vtac_rx->regs %p\n", vtac_rx->regs);
+   dev_dbg(vtac_rx->dev, "VTAC_RX_CONFIG 0x%x\n",
+   readl(vtac_rx->regs + VTAC_RX_CONFIG));
+   dev_dbg(vtac_rx->dev, "VTAC_RX_FIFO_CONFIG 0x%x\n",
+   readl(vtac_rx->regs + VTAC_RX_FIFO_CONFIG));
+}
+
+static void sti_vtac_rx_set_config(struct sti_vtac_rx *vtac_rx)
+{
+   int i;
+   u32 rx_config = EVEN_PARITY | ODD_PARITY | SW_RST_AUTOC | ENABLE;
+
+   /* Enable VTAC clock */
+   if (clk_prepare_enable(vtac_rx->clk))
+   DRM_ERROR("Failed to prepare/enable vtac_rx clock.\n");
+
+   for (i = 0; i < ARRAY_SIZE(vtac_modes); i++) {
+   if (vtac_modes[i].type == vtac_rx->type) {
+   writel(VTAC_FIFO_CONFIG_VAL,
+  vtac_rx->regs + VTAC_RX_FIFO_CONFIG);
+   rx_config |= vtac_modes[i].vid_in_width << 4;
+   rx_config |= vtac_modes[i].phyts_width << 16;
+   rx_config |= vtac_modes[i].phyts_per_pixel << 23;
+   rx_config |= VTAC_SW_RST_AUTOC;
+   writel(rx_config, vtac_rx->regs + VTAC_RX_CONFIG);
+   }
+   }
+}
+
+static int vtac_rx_bind(struct device *dev, struct device *master, void *data)
+{
+   return 0;
+}
+
+static void vtac_rx_unbind(struct device *dev, struct device *master,
+   void *data)
+{
+   /* do nothing */
+}
+
+static const struct component_ops vtac_rx_ops = {
+   .bind   = vtac_rx_bind,
+   .unbind = vtac_rx_unbind,
+};
+
+static int sti_vtac_rx_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct device_node *np = dev->of_node;
+   struct sti_vtac_rx *vtac_rx;
+   struct resource *res;
+
+   DRM_INFO("%s\n", __func__);
+
+   vtac_rx = devm_kzalloc(dev, sizeof(*vtac_rx), GFP_KERNEL);
+   if (!vtac_rx) {
+   DRM_ERROR("Failed to allocate VTAC RX context\n");
+   return -ENOMEM;
+   }
+   vtac_rx->dev = dev;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   DRM_ERROR("Invalid resource\n");
+   return -ENOMEM;
+   }
+   vtac_rx->regs = devm_ioremap_resource(dev, res

[PATCH v3 01/16] drm: sti: add VTG driver

2014-05-20 Thread Benjamin Gaignard
Video Time Generator drivers are used to synchronize the compositor
and tvout hardware IPs by providing line count, sample count,
synchronization signals (HSYNC, VSYNC) and top and bottom fields indication.
VTG are used by pair for each data path (main or auxiliary): one for master and 
one for slave.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/sti/Kconfig |  11 +
 drivers/gpu/drm/sti/Makefile|   3 +
 drivers/gpu/drm/sti/sti_vtg.c   | 468 
 drivers/gpu/drm/sti/sti_vtg.h   |  20 ++
 drivers/gpu/drm/sti/sti_vtg_utils.c |  99 
 drivers/gpu/drm/sti/sti_vtg_utils.h |  29 +++
 8 files changed, 633 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/Kconfig
 create mode 100644 drivers/gpu/drm/sti/Makefile
 create mode 100644 drivers/gpu/drm/sti/sti_vtg.c
 create mode 100644 drivers/gpu/drm/sti/sti_vtg.h
 create mode 100644 drivers/gpu/drm/sti/sti_vtg_utils.c
 create mode 100644 drivers/gpu/drm/sti/sti_vtg_utils.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index d1cc2f6..0e30029 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -201,3 +201,5 @@ source "drivers/gpu/drm/tegra/Kconfig"
 source "drivers/gpu/drm/panel/Kconfig"

 source "drivers/gpu/drm/bridge/Kconfig"
+
+source "drivers/gpu/drm/sti/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 5e792b0..44f7b17 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_BOCHS) += bochs/
 obj-$(CONFIG_DRM_MSM) += msm/
 obj-$(CONFIG_DRM_TEGRA) += tegra/
+obj-$(CONFIG_DRM_STI) += sti/
 obj-y  += i2c/
 obj-y  += panel/
 obj-y  += bridge/
diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
new file mode 100644
index 000..3fff278
--- /dev/null
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -0,0 +1,11 @@
+config DRM_STI
+   bool "DRM Support for STMicroelectronics SoC stiH41x Series"
+   depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
+   help
+ Choose this option to enable DRM on STM stiH41x chipset
+
+config VTG_STI
+   bool "Video Timing Generator for STMicroelectronics SoC stiH41x Series"
+   depends on DRM_STI
+   help
+ Choose this option to enable VTG on STM stiH41x chipset
diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
new file mode 100644
index 000..33216e1
--- /dev/null
+++ b/drivers/gpu/drm/sti/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_VTG_STI) += sti_vtg.o sti_vtg_utils.o
diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
new file mode 100644
index 000..75d7125
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_vtg.c
@@ -0,0 +1,468 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2013
+ * Authors: Benjamin Gaignard 
+ *  Fabien Dessenne 
+ *  Vincent Abriou 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "sti_vtg_utils.h"
+#include "sti_vtg.h"
+
+#define VTG_TYPE_MASTER 0
+#define VTG_TYPE_SLAVE_BY_EXT0  1
+
+/* registers offset */
+#define VTG_MODE   0x
+#define VTG_CLKLN  0x0008
+#define VTG_HLFLN  0x000C
+#define VTG_DRST_AUTOC 0x0010
+#define VTG_VID_TFO0x0040
+#define VTG_VID_TFS0x0044
+#define VTG_VID_BFO0x0048
+#define VTG_VID_BFS0x004C
+
+#define VTG_HOST_ITS   0x0078
+#define VTG_HOST_ITS_BCLR  0x007C
+#define VTG_HOST_ITM_BCLR  0x0088
+#define VTG_HOST_ITM_BSET  0x008C
+
+#define VTG_H_HD_1 0x00C0
+#define VTG_TOP_V_VD_1 0x00C4
+#define VTG_BOT_V_VD_1 0x00C8
+#define VTG_TOP_V_HD_1 0x00CC
+#define VTG_BOT_V_HD_1 0x00D0
+
+#define VTG_H_HD_2 0x00E0
+#define VTG_TOP_V_VD_2 0x00E4
+#define VTG_BOT_V_VD_2 0x00E8
+#define VTG_TOP_V_HD_2 0x00EC
+#define VTG_BOT_V_HD_2 0x00F0
+
+#define VTG_H_HD_3 0x0100
+#define VTG_TOP_V_VD_3 0x0104
+#define VTG_BOT_V_VD_3 0x0108
+#define VTG_TOP_V_HD_3 0x010C
+#define VTG_BOT_V_HD_3 0x0110
+
+/* IRQ mask */
+#define VTG_IRQ_TOP_FIELD_MASK (1L << 1)
+#define VTG_IRQ_BOTTOM_FIELD_MASK  (1L << 0)
+#define VTG_IRQ_MASK  (VTG_IRQ_TOP_FIELD_MASK | \
+   VTG_IRQ_BOTTOM_FIELD_MASK)
+
+/* Delay introduced by the AWG in nb of pixels */
+#define AWG_DELAY_HD(-9)
+#define AWG_DELAY_ED(-8)
+#define AWG_DELAY_SD(-7)
+
+static const struct of_device_id vtg_match_types[];
+
+/*
+ * STI VTG data structure
+ *
+ * @nb_reg: number of memory resources to register
+ * @reg

[PATCH v3 00/16] Add DRM for stih4xx platforms

2014-05-20 Thread Benjamin Gaignard
This series of patches add the support of DRM/KMS drivers for STMicroelectronics
chipsets stih416 and stih407.

patcheset version 3:
- Correctly split code between probe and bind funtions
- Squash some commits
- remove HQ-VDP device code to have a smaller patcheset,
  we will introduce it later.

patches could be found here: 
git://git.linaro.org/people/benjamin.gaignard/kernel.git
on branch: drm_kms_for_next-v3

patcheset version 2:
- Use componentized device instead of register sub-devices in master
driver probe function
- Fix Makefile and Kconfig to only allow built-in compilation

patches could be found here: 
git://git.linaro.org/people/benjamin.gaignard/kernel.git
on branch: drm_kms_for_next-v2

patcheset version 1:
- First path submission

Hardware is split in two main blocks: Compositor and TVout. Each of them
includes specific hardware IPs and the display timing are controlled by a 
specific
Video Timing Generator hardware IP (VTG).

Compositor is made of the follow hardware IPs:
 - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB)
   buffers
 - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers
 - HQVDP (High Quality Video Display Processor) that supports scaling,
   deinterlacing and some miscellaneous image quality improvements.
   It fetches the Video decoded buffers from memory, processes them and pushes
   them to the Compositor through a HW dedicated bus.
 - Mixer is responsible of mixing all the entries depending of their
   respective z-order and layout

TVout is divided in 3 parts:
 - HDMI to generate HDMI signals, depending of chipset version HDMI phy can
   change.
 - HDA to generate signals for HD analog TV
 - VIP to control/switch data path coming from Compositor

On stih416 compositor and Tvout are on different dies so a Video Trafic Advance
inter-die Communication mechanism (VTAC) is needed.

+-+   
++
| +---+   ++  |   |  ++   
+--+ |
| |   |   ||  |   |  ||   |  +-+
 ++  | |
| | ++  +--+  |   ||  |   |  ||   |  | VIP 
|>|HDMI|  | |
| | |GPD +->|  |  |   ||  |   |  ||   |  | |
 ++  | |
| | ++  |Mixer |--|-->||  |   |  ||---|->| switcher|
 | |
| | |  |  |   ||  |   |  ||   |  | |
 ++  | |
| | |  |  |   ||  |   |  ||   |  | 
|>|HDA |  | |
| | +--+  |   |VTAC|>|VTAC|   |  +-+
 ++  | |
| |   |   ||  |   |  ||   | 
 | |
| | Compositor|   ||  |   |  ||   |   TVout 
 | |
| +---+   ||  |   |  ||   
+--+ |
|  ^  ||  |   |  || ^   
   |
|  |  ||  |   |  || |   
   |
|   +--+  ||  |   |  ||  
+-+   |
|   | VTG (master) |->||  |   |  ||->| VTG (slave) 
|   |
|   +--+  ++  |   |  ++  
+-+   |
|Digital die  |   | 
 Analog Die|
+-+   
++

On stih407 Compositor and Tvout are on the same die

+-+
| +---+  +--+ |
| |   |  |  +-+ ++  | |
| | ++  +--+  |  |  | VIP |>|HDMI|  | |
| | |GPD +->|  |  |  |  | | ++  | |
| | ++  |Mixer |--|--|->| switcher| | |
| | ++   +-+|  |  |  |  | | ++  | |
| | |VDP +-->+HQVDP+--->|  |  |  |  | |>|HDA |  | |
| | ++   +-++--+  |  |  +-+ ++  | |
| |   |  |  | |
| | Compositor|  |   TVout  | |
| +---+  +--+ |
|  ^^ |
|  || |
|   +--+  |
|   | VTG  |  |
|   +--+  |
|Digital d

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

2014-05-20 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=75241

--- Comment #19 from Christian K?nig  ---
>From the logs you are always getting the same set of paramaters, even when you
change the maximum used in the fix:

[drm:radeon_compute_pll_avivo] 162000 - 161990, pll dividers - fb: 1425.4 ref:
21, post 6

With a maximum of 32 and a post divider of 6 the ref divider shouldn't be more
than 5, but it still stays at 21.

Thise means there is something wrong with the way you install the kernel module
(or the modification you make). Please double check that you got the right
kernel module loaded.

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


[Bug 75917] backlight switches off when starting X - since kernel-3.13

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=75917

--- Comment #10 from Alex Deucher  ---
Created attachment 99427
  --> https://bugs.freedesktop.org/attachment.cgi?id=99427&action=edit
possible fix v2

(In reply to comment #9)
> The patch works fine, however the display backlight switches off for several
> seconds during X init now (it didn't with kernel 2.12) but this is not
> really a problem, as it comes back happily :) thank you.

Does this patch work any better?

-- 
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/20140520/989fd69d/attachment.html>


[alsa-devel] [Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)

2014-05-20 Thread Jaroslav Kysela
Date 20.5.2014 14:43, Thierry Reding wrote:
> On Tue, May 20, 2014 at 12:04:38PM +0200, Daniel Vetter wrote:
>> Also adding dri-devel and linux-media. Please don't forget these lists for
>> the next round.
>> -Daniel
>>
>> On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote:
>>> Adding Greg just as an fyi since we've chatted briefly about the avsink
>>> bus. Comments below.
>>> -Daniel
>>>
>>> On Tue, May 20, 2014 at 02:52:19AM +, Lin, Mengdong wrote:
 This RFC is based on previous discussion to set up a generic communication 
 channel between display and audio driver and
 an internal design of Intel MCG/VPG HDMI audio driver. It's still an 
 initial draft and your advice would be appreciated
 to improve the design.

 The basic idea is to create a new avsink module and let both drm and alsa 
 depend on it.
 This new module provides a framework and APIs for synchronization between 
 the display and audio driver.

 1. Display/Audio Client

 The avsink core provides APIs to create, register and lookup a 
 display/audio client.
 A specific display driver (eg. i915) or audio driver (eg. HD-Audio driver) 
 can create a client, add some resources
 objects (shared power wells, display outputs, and audio inputs, register 
 ops) to the client, and then register this
 client to avisink core. The peer driver can look up a registered client by 
 a name or type, or both. If a client gives
 a valid peer client name on registration, avsink core will bind the two 
 clients as peer for each other. And we
 expect a display client and an audio client to be peers for each other in 
 a system.

 int avsink_new_client ( const char *name,
 int type,   /* client type, display or audio */
 struct module *module,
 void *context,
 const char *peer_name,
 struct avsink_client **client_ret);

 int avsink_free_client (struct avsink_client *client);
>>>
>>>
>>> Hm, my idea was to create a new avsink bus and let vga drivers register
>>> devices on that thing and audio drivers register as drivers. There's a bit
>>> more work involved in creating a full-blown bus, but it has a lot of
>>> upsides:
>>> - Established infrastructure for matching drivers (i.e. audio drivers)
>>>   against devices (i.e. avsinks exported by gfx drivers).
>>> - Module refcounting.
>>> - power domain handling and well-integrated into runtime pm.
>>> - Allows integration into componentized device framework since we're
>>>   dealing with a real struct device.
>>> - Better decoupling between gfx and audio side since registration is done
>>>   at runtime.
>>> - We can attach drv private date which the audio driver needs.
> 
> I think this would be another case where the interface framework[0]
> could potentially be used. It doesn't give you all of the above, but
> there's no reason it couldn't be extended. Then again, adding too much
> would end up duplicating more of the driver core, so if something really
> heavy-weight is required here, then the interface framework is not the
> best option.
> 
> [0]: https://lkml.org/lkml/2014/5/13/525

This looks like the right direction. I would go in this way rather than
create specific A/V grouping mechanisms. This seems to be applicable to
more use cases.

Jaroslav

-- 
Jaroslav Kysela 
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.


[Intel-gfx] [PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM

2014-05-20 Thread Daniel Vetter
On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrj?l? wrote:
> On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > don't need any hacks any longer to keep the vblank logic sane when
> > all the registers go poof. So let's rip it all out.
> 
> Hmm. drm_update_vblank_count() will now see some kind of diff between
> the last and current value when the registers got cloberred. So the
> vblank counter reported to userspace will jump. But I guess that's fine
> as long as userspace realizes that the counter is not at all reliable
> across modesets.

I've added checks for this (the rpm varianst) and for the similiar
suspend/resume issues (the suspend variants) to kms_flip. It seems to work
and we don't actually jump to far. But maybe the tests are horribly
broken.

Can you please take a closer look? I've thought that the entire point of
this series (well, one of them) was to finally fix this gag and avoid
handing totally bogus frame counter values to userspace. Especially for
system suspend/resume where userspace might get susprised ...
-Daniel

> 
> > 
> > This essentially undoes
> > 
> > commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
> > Author: Paulo Zanoni 
> > Date:   Tue Jul 23 10:48:11 2013 -0300
> > 
> > drm/i915: update last_vblank when disabling the power well
> > 
> > Apparently igt/kms_flip is already powerful enough to exercise this
> > properly, yay! See the reference regression report for details.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=66808
> > Testcase: igt/kms_flip/*-vs-rpm
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 34 --
> >  1 file changed, 34 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 75c1c766b507..45fa43f16bb3 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -5423,33 +5423,6 @@ static void hsw_power_well_post_enable(struct 
> > drm_i915_private *dev_priv)
> > }
> >  }
> >  
> > -static void reset_vblank_counter(struct drm_device *dev, enum pipe pipe)
> > -{
> > -   assert_spin_locked(&dev->vbl_lock);
> > -
> > -   dev->vblank[pipe].last = 0;
> > -}
> > -
> > -static void hsw_power_well_post_disable(struct drm_i915_private *dev_priv)
> > -{
> > -   struct drm_device *dev = dev_priv->dev;
> > -   enum pipe pipe;
> > -   unsigned long irqflags;
> > -
> > -   /*
> > -* After this, the registers on the pipes that are part of the power
> > -* well will become zero, so we have to adjust our counters according to
> > -* that.
> > -*
> > -* FIXME: Should we do this in general in drm_vblank_post_modeset?
> > -*/
> > -   spin_lock_irqsave(&dev->vbl_lock, irqflags);
> > -   for_each_pipe(pipe)
> > -   if (pipe != PIPE_A)
> > -   reset_vblank_counter(dev, pipe);
> > -   spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> > -}
> > -
> >  static void hsw_set_power_well(struct drm_i915_private *dev_priv,
> >struct i915_power_well *power_well, bool enable)
> >  {
> > @@ -5478,8 +5451,6 @@ static void hsw_set_power_well(struct 
> > drm_i915_private *dev_priv,
> > I915_WRITE(HSW_PWR_WELL_DRIVER, 0);
> > POSTING_READ(HSW_PWR_WELL_DRIVER);
> > DRM_DEBUG_KMS("Requesting to disable the power well\n");
> > -
> > -   hsw_power_well_post_disable(dev_priv);
> > }
> > }
> >  }
> > @@ -5646,11 +5617,6 @@ static void vlv_display_power_well_disable(struct 
> > drm_i915_private *dev_priv,
> > valleyview_disable_display_irqs(dev_priv);
> > spin_unlock_irq(&dev_priv->irq_lock);
> >  
> > -   spin_lock_irq(&dev->vbl_lock);
> > -   for_each_pipe(pipe)
> > -   reset_vblank_counter(dev, pipe);
> > -   spin_unlock_irq(&dev->vbl_lock);
> > -
> > vlv_set_power_well(dev_priv, power_well, false);
> >  }
> >  
> > -- 
> > 1.8.3.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrj?l?
> Intel OTC

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


[Bug 75917] backlight switches off when starting X - since kernel-3.13

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=75917

--- Comment #9 from nl at gnuffy.net ---
(In reply to comment #7)
> Does the attached patch help?

The patch works fine, however the display backlight switches off for several
seconds during X init now (it didn't with kernel 2.12) but this is not really a
problem, as it comes back happily :) thank you.

-- 
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/20140520/5957c0fb/attachment-0001.html>


[Bug 75917] backlight switches off when starting X - since kernel-3.13

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=75917

--- Comment #8 from nl at gnuffy.net ---
Created attachment 99424
  --> https://bugs.freedesktop.org/attachment.cgi?id=99424&action=edit
dmesg output before patching (and with runpm)

-- 
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/20140520/e98c8ef2/attachment.html>


[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

2014-05-20 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=75241

--- Comment #18 from Tasev Nikola  ---
Created attachment 136841
  --> https://bugzilla.kernel.org/attachment.cgi?id=136841&action=edit
dmesg after suspend resume broken

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


[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

2014-05-20 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=75241

--- Comment #17 from Tasev Nikola  ---
Created attachment 136831
  --> https://bugzilla.kernel.org/attachment.cgi?id=136831&action=edit
dmesg after boot working with max divider 32

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


[PATCH 3/3] drm/i915: use async hpd_irq_event function on resume

2014-05-20 Thread Jesse Barnes
Gets the detect code (which may take awhile) out of the resume path,
speeding things up a bit.

Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 302495f..571f688 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -606,7 +606,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool 
restore_gtt_mappings)
intel_hpd_init(dev);
dev_priv->enable_hotplug_processing = true;
/* Config may have changed between suspend and resume */
-   drm_helper_hpd_irq_event(dev);
+   async_schedule(drm_helper_hpd_irq_event_async, dev);
}

intel_opregion_init(dev);
-- 
1.8.4.2



[PATCH 2/3] drm: add async version of hpd_irq_event

2014-05-20 Thread Jesse Barnes
In some cases, the callers of this function may not need the return
value and delaying the uevent is ok.  So add an async version of the
function for use in those cases.

Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/drm_probe_helper.c | 8 
 include/drm/drm_crtc_helper.h  | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 79f07f2..f3aee4a 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -446,3 +446,11 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
return changed;
 }
 EXPORT_SYMBOL(drm_helper_hpd_irq_event);
+
+void drm_helper_hpd_irq_event_async(void *data, async_cookie_t cookie)
+{
+   struct drm_device *dev = data;
+
+   drm_helper_hpd_irq_event(dev);
+}
+EXPORT_SYMBOL(drm_helper_hpd_irq_event_async);
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index a3d75fe..4f4ed9c 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -33,6 +33,7 @@
 #ifndef __DRM_CRTC_HELPER_H__
 #define __DRM_CRTC_HELPER_H__

+#include 
 #include 
 #include 
 #include 
@@ -172,6 +173,7 @@ extern int 
drm_helper_probe_single_connector_modes_nomerge(struct drm_connector
 extern void drm_kms_helper_poll_init(struct drm_device *dev);
 extern void drm_kms_helper_poll_fini(struct drm_device *dev);
 extern bool drm_helper_hpd_irq_event(struct drm_device *dev);
+extern void drm_helper_hpd_irq_event_async(void *data, async_cookie_t cookie);
 extern void drm_kms_helper_hotplug_event(struct drm_device *dev);

 extern void drm_kms_helper_poll_disable(struct drm_device *dev);
-- 
1.8.4.2



[PATCH 1/3] drm/i915: drop encoder hot_plug calls at resume

2014-05-20 Thread Jesse Barnes
We really just want to go detect displays again and fire off a hotplug
event if things have changed, not go through full hotplug processing.

Requested-by: Daniel Vetter 
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/i915_drv.c | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b948c71..302495f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -551,24 +551,6 @@ void intel_console_resume(struct work_struct *work)
console_unlock();
 }

-static void intel_resume_hotplug(struct drm_device *dev)
-{
-   struct drm_mode_config *mode_config = &dev->mode_config;
-   struct intel_encoder *encoder;
-
-   mutex_lock(&mode_config->mutex);
-   DRM_DEBUG_KMS("running encoder hotplug functions\n");
-
-   list_for_each_entry(encoder, &mode_config->encoder_list, base.head)
-   if (encoder->hot_plug)
-   encoder->hot_plug(encoder);
-
-   mutex_unlock(&mode_config->mutex);
-
-   /* Just fire off a uevent and let userspace tell us what to do */
-   drm_helper_hpd_irq_event(dev);
-}
-
 static int i915_drm_thaw_early(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -624,7 +606,7 @@ static int __i915_drm_thaw(struct drm_device *dev, bool 
restore_gtt_mappings)
intel_hpd_init(dev);
dev_priv->enable_hotplug_processing = true;
/* Config may have changed between suspend and resume */
-   intel_resume_hotplug(dev);
+   drm_helper_hpd_irq_event(dev);
}

intel_opregion_init(dev);
-- 
1.8.4.2



[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

2014-05-20 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=75241

--- Comment #16 from Tasev Nikola  ---
Hi 

I tried with 64, 48 and 32 for the ref_div_max .
The only one working at boot is 32 , but after the first suspend resume the 
off range frequency problem appear again. I try a second suspend resume with 
the same result. I try also with the patch from comment 8 with the same 
result, boot succesfull and fail after resume.
And you're right, the calculated parameters are the same in both the working
and broken case again.
The dmesg after boot and after suspend resume are attached.

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


[pull] radeon drm-fixes-3.15

2014-05-20 Thread Christian König
Hi Dave,

by your request I've removed Alex's I2C mutex patch from the branch. I 
would like to keep the VCE patch, cause it actually fixed a serious bug 
for me, but I've fixed the formal error of the missing Signed-off-by line.

Additional to that we have two new fixes from Jerome and Alex, both are 
CC stable as well so important enough for 3.15.

So this is the resend pull of stashed up radeon fixes for 3.15. 
Highlights are:
1. Avoid sending SIGBUS on CPU access just because kernel can't handle 
buffer placement.
2. Some fixes for VM page table updates and buffer placements.
3. Fixing two typos in the PLL and SI register spec.
4. Checking VCE buffers ranges.
5. Mullins and non-VGA pci class fixes.
6. A PX power management fix.
7. Fix for a crash if acceleration fails to initialize.

The following changes since commit 4ba4801d73d14690ed15774424e8b1d4c18323a5:

   Merge tag 'drm-intel-fixes-2014-05-16' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-05-20 
09:56:26 +1000)

are available in the git repository at:


   git://people.freedesktop.org/~deathsimple/linux drm-fixes-3.15

for you to fetch changes up to 4f2f203976964e267dc477de6648bdb3acd2b74b:

   drm/radeon/pm: don't allow debugfs/sysfs access when PX card is off 
(v2) (2014-05-20 14:42:08 +0200)


Alex Deucher (4):
   drm/radeon: fix DCE83 check for mullins
   drm/radeon: handle non-VGA class pci devices with ATRM
   drm/radeon: fix register typo on si
   drm/radeon/pm: don't allow debugfs/sysfs access when PX card is 
off (v2)

Christian K?nig (4):
   drm/radeon: also try GART for CPU accessed buffers
   drm/radeon: fix page directory update size estimation
   drm/radeon: fix buffer placement under memory pressure v2
   drm/radeon: fix typo in finding PLL params

J?r?me Glisse (1):
   drm/radeon: avoid segfault on device open when accel is not working.

Leo Liu (1):
   drm/radeon: check VCE relocation buffer range v3

  drivers/gpu/drm/radeon/radeon.h |   6 +++--
  drivers/gpu/drm/radeon/radeon_bios.c|  14 +++
  drivers/gpu/drm/radeon/radeon_display.c |   2 +-
  drivers/gpu/drm/radeon/radeon_kms.c |  55 
+
  drivers/gpu/drm/radeon/radeon_object.c  |  40 
++
  drivers/gpu/drm/radeon/radeon_pm.c  |  42 
+++-
  drivers/gpu/drm/radeon/radeon_vce.c | 130 
++---
  drivers/gpu/drm/radeon/radeon_vm.c  |   2 +-
  drivers/gpu/drm/radeon/sid.h|   4 +--
  9 files changed, 216 insertions(+), 79 deletions(-)



[Intel-gfx] [PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM

2014-05-20 Thread Ville Syrjälä
On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> Now that we unconditionally dtrt when disabling/enabling crtcs we
> don't need any hacks any longer to keep the vblank logic sane when
> all the registers go poof. So let's rip it all out.

Hmm. drm_update_vblank_count() will now see some kind of diff between
the last and current value when the registers got cloberred. So the
vblank counter reported to userspace will jump. But I guess that's fine
as long as userspace realizes that the counter is not at all reliable
across modesets.

> 
> This essentially undoes
> 
> commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6
> Author: Paulo Zanoni 
> Date:   Tue Jul 23 10:48:11 2013 -0300
> 
> drm/i915: update last_vblank when disabling the power well
> 
> Apparently igt/kms_flip is already powerful enough to exercise this
> properly, yay! See the reference regression report for details.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=66808
> Testcase: igt/kms_flip/*-vs-rpm
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 34 --
>  1 file changed, 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 75c1c766b507..45fa43f16bb3 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5423,33 +5423,6 @@ static void hsw_power_well_post_enable(struct 
> drm_i915_private *dev_priv)
>   }
>  }
>  
> -static void reset_vblank_counter(struct drm_device *dev, enum pipe pipe)
> -{
> - assert_spin_locked(&dev->vbl_lock);
> -
> - dev->vblank[pipe].last = 0;
> -}
> -
> -static void hsw_power_well_post_disable(struct drm_i915_private *dev_priv)
> -{
> - struct drm_device *dev = dev_priv->dev;
> - enum pipe pipe;
> - unsigned long irqflags;
> -
> - /*
> -  * After this, the registers on the pipes that are part of the power
> -  * well will become zero, so we have to adjust our counters according to
> -  * that.
> -  *
> -  * FIXME: Should we do this in general in drm_vblank_post_modeset?
> -  */
> - spin_lock_irqsave(&dev->vbl_lock, irqflags);
> - for_each_pipe(pipe)
> - if (pipe != PIPE_A)
> - reset_vblank_counter(dev, pipe);
> - spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> -}
> -
>  static void hsw_set_power_well(struct drm_i915_private *dev_priv,
>  struct i915_power_well *power_well, bool enable)
>  {
> @@ -5478,8 +5451,6 @@ static void hsw_set_power_well(struct drm_i915_private 
> *dev_priv,
>   I915_WRITE(HSW_PWR_WELL_DRIVER, 0);
>   POSTING_READ(HSW_PWR_WELL_DRIVER);
>   DRM_DEBUG_KMS("Requesting to disable the power well\n");
> -
> - hsw_power_well_post_disable(dev_priv);
>   }
>   }
>  }
> @@ -5646,11 +5617,6 @@ static void vlv_display_power_well_disable(struct 
> drm_i915_private *dev_priv,
>   valleyview_disable_display_irqs(dev_priv);
>   spin_unlock_irq(&dev_priv->irq_lock);
>  
> - spin_lock_irq(&dev->vbl_lock);
> - for_each_pipe(pipe)
> - reset_vblank_counter(dev, pipe);
> - spin_unlock_irq(&dev->vbl_lock);
> -
>   vlv_set_power_well(dev_priv, power_well, false);
>  }
>  
> -- 
> 1.8.3.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrj?l?
Intel OTC


[Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)

2014-05-20 Thread Thierry Reding
 audio driver can register an audio client with

-EPROBE_DEFER is the correct error code for deferred probing.

> > > 6. Display register operation (optional)
> > > 
> > > Some audio driver needs to access GPU audio registers. The register ops 
> > > are provided by the peer display client.
> > > 
> > > struct avsink_registers_ops {
> > >  int (*read_register) (uint32_t reg_addr, uint32_t *data, void 
> > > *context);
> > >  int (*write_register) (uint32_t reg_addr, uint32_t data, void 
> > > *context);
> > >  int (*read_modify_register) (uint32_t reg_addr, uint32_t data, 
> > > uint32_t mask, void *context);
> > > 
> > > int avsink_define_reg_ops (struct avsink_client *client, struct 
> > > avsink_registers_ops *ops);
> > > 
> > > And avsink core provides API for the audio driver to access the display 
> > > registers:
> > > 
> > > int avsink_read_display_register(struct avsink_client *client , uint32_t 
> > > offset, uint32_t *data);
> > > int avsink_write_display_register(struct avsink_client *client , uint32_t 
> > > offset, uint32_t data);
> > > int avsink_read_modify_display_register(struct avsink_client *client, 
> > > uint32_t offset, uint32_t data, uint32_t mask);
> > > 
> > > If the client is an audio client, the avsink core will find it peer 
> > > display client and call its register ops;
> > > and if the client is a display client, the avsink core will just call its 
> > > own register ops.
> > 
> > Oh dear. Where do we need this? Imo this is really horrible, but if we
> > indeed need this then a struct device is better - we can attach mmio
> > resources to devices and let the audio side remap them as best as they see
> > fit.

Can't this just be put behind an explicit API that does what the
register writes would do? If you share an MMIO region between drivers
you always need to make sure that they don't step on each others' toes.
An explicity API can easily take care of that.

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


linux-next: manual merge of the dma-buf tree with the drm-intel tree

2014-05-20 Thread Sumit Semwal
On 20 May 2014 12:25, Stephen Rothwell  wrote:
> Hi Sumit,
>
> Today's linux-next merge of the dma-buf tree got a conflict in
> drivers/gpu/drm/i915/i915_gem_dmabuf.c between commit 5cc9ed4b9a7a
> ("drm/i915: Introduce mapping of user pages into video memory (userptr)
> ioctl") from the drm-intel tree and commit 8dfb1f0f8103 ("dma-buf: use
> reservation objects") from the dma-buf tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
Hi Stephen!

This seems good, thanks!

Best regards,
~Sumit.
> --
> Cheers,
> Stephen Rothwellsfr at canb.auug.org.au
>
> diff --cc drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index 580aa42443ed,817ec444c976..
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@@ -229,15 -233,8 +229,16 @@@ static const struct dma_buf_ops i915_dm
>   struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
>   struct drm_gem_object *gem_obj, int 
> flags)
>   {
>  +  struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
>  +
>  +  if (obj->ops->dmabuf_export) {
>  +  int ret = obj->ops->dmabuf_export(obj);
>  +  if (ret)
>  +  return ERR_PTR(ret);
>  +  }
>  +
> -   return dma_buf_export(gem_obj, &i915_dmabuf_ops, gem_obj->size, 
> flags);
> +   return dma_buf_export(gem_obj, &i915_dmabuf_ops, gem_obj->size, flags,
> +   NULL);
>   }
>
>   static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)


[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=77785

--- Comment #22 from Alex Deucher  ---
(In reply to comment #20)
> Created attachment 99363 [details]
> Trine 2 - radeon
> 
> 
>  One more example of those blackiness, with Trine 2 game. Game is also
> partially black like WoS games, so maybe it is the same issue :).

You are probably seeing bug 66067 for trine 2.

-- 
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/20140520/4c61c1c1/attachment.html>


[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

2014-05-20 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=75241

--- Comment #15 from Christian K?nig  ---
(In reply to Tasev Nikola from comment #14)
> I tried different value from 128 to 90 for the ref_div_max but none work
> with my Belinea 1600x1200 screen.

Try going down to at least 32, this would match the behaviour on 3.14.

The problem is that in both the working and broken case the calculated
parameters are the same.

Broken: [   23.511041] [drm:radeon_compute_pll_avivo] 162000 - 161990, pll
dividers - fb: 1425.4 ref: 21, post 6

Working: [   23.560826] [drm:radeon_compute_pll_avivo] 162000 - 161990, pll
dividers - fb: 1425.4 ref: 21, post 6

So I'm not really sure what else could go wrong here.

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


[PATCH 14/18] drm/panel: add S6E3FA0 driver

2014-05-20 Thread Andrzej Hajda
On 05/14/2014 08:27 AM, YoungJun Cho wrote:
> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
>
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 

Few nitpicks, beside them.

Reviewed-by: Andrzej Hajda 

> ---
>  drivers/gpu/drm/panel/Kconfig |7 +
>  drivers/gpu/drm/panel/Makefile|1 +
>  drivers/gpu/drm/panel/panel-s6e3fa0.c |  570 
> +
>  3 files changed, 578 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 4ec874d..fa51237 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
>   select DRM_MIPI_DSI
>   select VIDEOMODE_HELPERS
>  
> +config DRM_PANEL_S6E3FA0
> + tristate "S6E3FA0 DSI command mode panel"
> + depends on DRM && DRM_PANEL
> + depends on OF
> + select DRM_MIPI_DSI
> + select CMDMODE_HELPERS
> +
>  endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 8b92921..85c6738 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
>  obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
>  obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
> +obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c 
> b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> new file mode 100644
> index 000..a3b2d7e
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> @@ -0,0 +1,570 @@
> +/*
> + * MIPI-DSI based s6e3fa0 AMOLED LCD 5.7 inch panel driver.
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd
> + *
> + * YoungJun Cho 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +/* Manufacturer Command Set */
> +#define MCS_GLOBAL_PARAMETER 0xb0
> +#define MCS_AID  0xb2
> +#define MCS_ELVSSOPT 0xb6
> +#define MCS_TEMPERATURE_SET  0xb8
> +#define MCS_PENTILE_CTRL 0xc0
> +#define MCS_GAMMA_MODE   0xca
> +#define MCS_VDDM 0xd7
> +#define MCS_ALS  0xe3
> +#define MCS_ERR_FG   0xed
> +#define MCS_KEY_LEV1 0xf0
> +#define MCS_PANEL_UPDATE 0xf7
> +#define MCS_KEY_LEV2 0xfc
> +#define MCS_RE   0xfe
> +#define MCS_TOUT2_HSYNC  0xff
> +
> +/* Content Adaptive Brightness Control */
> +#define DCS_WRITE_CABC   0x55
> +
> +#define MTP_ID_LEN   3
> +#define GAMMA_LEVEL_NUM  30
> +
> +#define DEFAULT_VDDM_VAL 0x15
> +
> +struct s6e3fa0 {
> + struct device   *dev;
> + struct drm_panelpanel;
> +
> + struct regulator_bulk_data  supplies[2];
> + struct gpio_desc*reset_gpio;
> + struct gpio_desc*det_gpio;
> + struct gpio_desc*te_gpio;
> + struct cmdmode  cm;
> +
> + unsigned intpower_on_delay;
> + unsigned intreset_delay;
> + unsigned intinit_delay;
> + unsigned intwidth_mm;
> + unsigned intheight_mm;
> +
> + unsigned char   id;
> + unsigned char   vddm;
> + unsigned intbrightness;
> +};
> +
> +#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
> +
> +/* VDD Memory Lookup Table contains paires of {ReadValue, WriteValue} */

s/paires/pairs/

> +static const unsigned char s6e3fa0_vddm_lut[][2] = {
> + {0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
> + {0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
> + {0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
> + {0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
> + {0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
> + {0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
> + {0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
> + {0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
> + {0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
> + {0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
> + {0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
> +

[Intel-gfx] [RFC] set up an sync channel between audio and display driver (i.e. ALSA and DRM)

2014-05-20 Thread Daniel Vetter
Also adding dri-devel and linux-media. Please don't forget these lists for
the next round.
-Daniel

On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote:
> Adding Greg just as an fyi since we've chatted briefly about the avsink
> bus. Comments below.
> -Daniel
> 
> On Tue, May 20, 2014 at 02:52:19AM +, Lin, Mengdong wrote:
> > This RFC is based on previous discussion to set up a generic communication 
> > channel between display and audio driver and
> > an internal design of Intel MCG/VPG HDMI audio driver. It's still an 
> > initial draft and your advice would be appreciated
> > to improve the design.
> > 
> > The basic idea is to create a new avsink module and let both drm and alsa 
> > depend on it.
> > This new module provides a framework and APIs for synchronization between 
> > the display and audio driver.
> > 
> > 1. Display/Audio Client
> > 
> > The avsink core provides APIs to create, register and lookup a 
> > display/audio client.
> > A specific display driver (eg. i915) or audio driver (eg. HD-Audio driver) 
> > can create a client, add some resources
> > objects (shared power wells, display outputs, and audio inputs, register 
> > ops) to the client, and then register this
> > client to avisink core. The peer driver can look up a registered client by 
> > a name or type, or both. If a client gives
> > a valid peer client name on registration, avsink core will bind the two 
> > clients as peer for each other. And we
> > expect a display client and an audio client to be peers for each other in a 
> > system.
> > 
> > int avsink_new_client ( const char *name,
> > int type,   /* client type, display or audio */
> > struct module *module,
> > void *context,
> > const char *peer_name,
> > struct avsink_client **client_ret);
> > 
> > int avsink_free_client (struct avsink_client *client);
> 
> 
> Hm, my idea was to create a new avsink bus and let vga drivers register
> devices on that thing and audio drivers register as drivers. There's a bit
> more work involved in creating a full-blown bus, but it has a lot of
> upsides:
> - Established infrastructure for matching drivers (i.e. audio drivers)
>   against devices (i.e. avsinks exported by gfx drivers).
> - Module refcounting.
> - power domain handling and well-integrated into runtime pm.
> - Allows integration into componentized device framework since we're
>   dealing with a real struct device.
> - Better decoupling between gfx and audio side since registration is done
>   at runtime.
> - We can attach drv private date which the audio driver needs.
> 
> > int avsink_register_client(struct avsink_client *client);
> > int avisink_unregister_client(int client_handle);
> > 
> > struct avsink_client *avsink_lookup_client(const char *name, int type);
> > 
> > struct avsink_client {
> >  const char *name;  /* client name */
> >  int type; /* client type*/
> >  void *context;
> >  struct module *module;  /* top-level module for locking */
> > 
> >  struct avsink_client *peer;  /* peer client */
> > 
> >  /* shared power wells */
> >  struct avsink_power_well *power_well;
> 
> We need to have an struct power_domain here so that we can do proper
> runtime pm. But like I've said above I think we actually want a full blown
> struct device.
> 
> >  int num_power_wells;
> > 
> >  /* endpoints, display outputs or audio inputs */
> >  struct avsink_endpoint * endpoint;
> >  int num_endpints;
> > 
> >  struct avsink_registers_ops *reg_ops; /* ops to access registers 
> > of a client */
> >  void *private_data;
> >  ...
> > };
> 
> I think you're indeed implementing a full blown bus here ;-)
> 
> avsink->client = bus devices/childern
> avsink->peer = driver for all this stuff
> avsink->power_well = runtime pm support for the avsink bus
> avsink->reg_ops = driver bind/unbind support
> 
> > On system boots, the avsink module is loaded before the display and audio 
> > driver module. And the display and audio
> > driver may be loaded on parallel.
> > * If a specific display driver (eg. i915) supports avsink, it can create a 
> > display client, add power wells and display
> >   outputs to the client, and then register the display client to the avsink 
> > core. Then it may look up if there is any
> >   audio client registered, by name or type, and may find an audio client 
> > registered by some audio driver.
> > 
> > * If an audio driver supports avsink, it usually should look up a 
> > registered display client by name or type at first,
> >   because it may need the shared power well in GPU and check the display 
> > outputs' name to bind the audio inputs. If
> >   the display client is not registered yet, the audio driver can choose to 
> > wait (maybe in a work queue) or return
> >   -EAGAIN for a def

[PATCH 02/18] drm/exynos: use wait_event_timeout() for safety usage

2014-05-20 Thread Andrzej Hajda
On 05/14/2014 08:26 AM, YoungJun Cho wrote:
> There could be the case that the page flip operation isn't finished correctly
> with some abnormal condition such as panel reset. So this patch replaces
> wait_event() with wait_event_timeout() to avoid waiting for page flip 
> completion
> infinitely.
>
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 

Reviewed-by: Andrzej Hajda 

> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 95c9435..485fa26 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -69,8 +69,9 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
> mode)
>  
>   if (mode > DRM_MODE_DPMS_ON) {
>   /* wait for the completion of page flip. */
> - wait_event(exynos_crtc->pending_flip_queue,
> - atomic_read(&exynos_crtc->pending_flip) == 0);
> + wait_event_timeout(exynos_crtc->pending_flip_queue,
> + !atomic_read(&exynos_crtc->pending_flip),
> + HZ/20);
>   drm_vblank_off(crtc->dev, exynos_crtc->pipe);
>   }
>  



[PATCH 01/18] drm/exynos: dsi: move the EoT packets configuration point

2014-05-20 Thread Andrzej Hajda
On 05/14/2014 08:26 AM, YoungJun Cho wrote:
> This configuration could be used in MIPI DSI command mode also.
>
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 

Reviewed-by: Andrzej Hajda 

> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 84661fe..0a4e3ce 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -473,8 +473,6 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
>  
>   if (!(dsi->mode_flags & MIPI_DSI_MODE_VSYNC_FLUSH))
>   reg |= DSIM_MFLUSH_VS;
> - if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
> - reg |= DSIM_EOT_DISABLE;
>   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
>   reg |= DSIM_SYNC_INFORM;
>   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> @@ -491,6 +489,9 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
>   reg |= DSIM_HSA_MODE;
>   }
>  
> + if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
> + reg |= DSIM_EOT_DISABLE;
> +
>   switch (dsi->format) {
>   case MIPI_DSI_FMT_RGB888:
>   reg |= DSIM_MAIN_PIX_FORMAT_RGB888;



[PATCH v2 4/7] drivers/base: Add interface framework

2014-05-20 Thread Andrzej Hajda
Hi Thierry, Greg,


On 05/15/2014 10:53 AM, Thierry Reding wrote:
> On Tue, May 13, 2014 at 05:32:15PM -0700, Greg Kroah-Hartman wrote:
>> On Tue, May 13, 2014 at 07:57:13PM +0200, Daniel Vetter wrote:
>>> On Tue, May 13, 2014 at 05:30:47PM +0200, Thierry Reding wrote:
 From: Thierry Reding 

 Some drivers, such as graphics drivers in the DRM subsystem, do not have
 a real device that they can bind to. They are often composed of several
 devices, each having their own driver. The master/component framework
 can be used in these situations to collect the devices pertaining to one
 logical device, wait until all of them have registered and then bind
 them all at once.

 For some situations this is only a partial solution. An implementation
 of a master still needs to be registered with the system somehow. Many
 drivers currently resort to creating a dummy device that a driver can
 bind to and register the master against. This is problematic since it
 requires (and presumes) knowledge about the system within drivers.

 Furthermore there are setups where a suitable device already exists, but
 is already bound to a driver. For example, on Tegra the following device
 tree extract (simplified) represents the host1x device along with child
 devices:

host1x {
display-controller {
...
};

display-controller {
...
};

hdmi {
...
};

dsi {
...
};

csi {
...
};

video-input {
...
};
};

 Each of the child devices is in turn a client of host1x, in that it can
 request resources (command stream DMA channels and syncpoints) from it.
 To implement the DMA channel and syncpoint infrastructure, host1x comes
 with its own driver. Children are implemented in separate drivers. In
 Linux this set of devices would be exposed by DRM and V4L2 drivers.

 However, neither the DRM nor the V4L2 drivers have a single device that
 they can bind to. The DRM device is composed of the display controllers
 and the various output devices, whereas the V4L2 device is composed of
 one or more video input devices.

 This patch introduces the concept of an interface and drivers that can
 bind to a given interface. An interface can be exposed by any device,
 and interface drivers can bind to these interfaces. Multiple drivers can
 bind against a single interface. When a device is removed, interfaces
 exposed by it will be removed as well, thereby removing the drivers that
 were bound to those interfaces.

 In the example above, the host1x device would expose the "tegra-host1x"
 interface. DRM and V4L2 drivers can then bind to that interface and
 instantiate the respective subsystem objects from there.

 Signed-off-by: Thierry Reding >>> public.gmane.org>
 ---
 Note that I'd like to merge this through the Tegra DRM tree so that the
 changes to the Tegra DRM driver later in this series can be merged at
 the same time and are not delayed for another release cycle.

 In particular that means that I'm looking for an Acked-by from Greg.

  drivers/base/Makefile |   2 +-
  drivers/base/interface.c  | 186 
 ++
  include/linux/interface.h |  40 ++
  3 files changed, 227 insertions(+), 1 deletion(-)
  create mode 100644 drivers/base/interface.c
  create mode 100644 include/linux/interface.h
>>>
>>> Hm, this interface stuff smells like bus drivers light. Should we instead
>>> have a pile of helpers to make creating new buses with match methods more
>>> trivial? There's a fairly big pile of small use-cases where this might be
>>> useful. In your case here all the host1x children would sit on a host1x
>>> bus. Admittedly I didn't look into the details.
>>
>> I have no problem adding such "bus-light" functions, to make it easier
>> to create and implement a bus in the driver core, as I know it's really
>> heavy.  That's been on my "todo" list for over a decade now...

I have posted some times ago RFC for interface_tracker framework [1].
It seems with interface_tracker you can achieve similar functionality
and it seems to be more generic.

[1]: https://lkml.org/lkml/2014/4/30/345

Two small things should be added to interface_tracker framework:
- matching objects using string comparison,
- before notifier unregistration call notifier to inform that observed
  interface will disappear for him.

Greg, this is another use case for interface_tracker framework.

To show how it could be achieved I present pseudo patch wh

[PATCH] drm/exynos: Fix PTN3460 dependency

2014-05-20 Thread Jean Delvare
The following configuration options combination:

CONFIG_DRM_EXYNOS_DP=y
CONFIG_DRM_PTN3460=m

currently leads to the following linker failure:

drivers/built-in.o: In function `exynos_drm_attach_lcd_bridge':
.../drivers/gpu/drm/exynos/exynos_dp_core.c:1004:
undefined reference to `ptn3460_init'

This is because ptn3460_init can't be implemented in a module while
its caller is built into the kernel. So add the proper dependency in
Kconfig so that the above can't happen.

I moved DRM_PTN3460 earlier in Kconfig, next to the I2C helper module
section, so that the user has a chance to select it before moving to
the Exynos-specific section.

IMHO the proper way to solve the problem would be to turn ptn3460 into
a clean I2C driver, similar to the other I2C helper chip drivers. It's
the only way to not sink into impossible-to-guess dependencies. Then
ptn3460 could even be moved together with the other I2C helper chip
drivers.

Signed-off-by: Jean Delvare 
Cc: David Airlie 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
---
 drivers/gpu/drm/Kconfig|4 ++--
 drivers/gpu/drm/exynos/Kconfig |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

--- linux-3.15-rc5.orig/drivers/gpu/drm/Kconfig 2014-04-14 09:42:29.689070224 
+0200
+++ linux-3.15-rc5/drivers/gpu/drm/Kconfig  2014-05-19 14:47:02.872050099 
+0200
@@ -83,6 +83,8 @@ config DRM_KMS_CMA_HELPER

 source "drivers/gpu/drm/i2c/Kconfig"

+source "drivers/gpu/drm/bridge/Kconfig"
+
 config DRM_TDFX
tristate "3dfx Banshee/Voodoo3+"
depends on DRM && PCI
@@ -199,5 +201,3 @@ source "drivers/gpu/drm/msm/Kconfig"
 source "drivers/gpu/drm/tegra/Kconfig"

 source "drivers/gpu/drm/panel/Kconfig"
-
-source "drivers/gpu/drm/bridge/Kconfig"
--- linux-3.15-rc5.orig/drivers/gpu/drm/exynos/Kconfig  2014-04-14 
09:42:29.698070438 +0200
+++ linux-3.15-rc5/drivers/gpu/drm/exynos/Kconfig   2014-05-19 
15:23:18.867919528 +0200
@@ -50,7 +50,7 @@ config DRM_EXYNOS_DSI

 config DRM_EXYNOS_DP
bool "EXYNOS DRM DP driver support"
-   depends on DRM_EXYNOS && ARCH_EXYNOS
+   depends on DRM_EXYNOS && ARCH_EXYNOS && (DRM_PTN3460=n || DRM_PTN3460=y 
|| DRM_PTN3460=DRM_EXYNOS)
default DRM_EXYNOS
help
  This enables support for DP device.


-- 
Jean Delvare
SUSE L3 Support


[PATCH v3 1/3] phy: Add exynos-simple-phy driver

2014-05-20 Thread Rahul Sharma
On 19 May 2014 16:24, Tomasz Figa  wrote:
> On 19.05.2014 09:10, Rahul Sharma wrote:
>> On 16 May 2014 20:19, Tomasz Figa  wrote:
>>> On 16.05.2014 16:30, Rahul Sharma wrote:
 On 16 May 2014 16:20, Tomasz Figa  wrote:
> On 16.05.2014 12:35, Rahul Sharma wrote:
>> On 16 May 2014 15:12, Rahul Sharma  wrote:
>>> On 16 May 2014 03:14, Tomasz Figa  wrote:
 On 15.05.2014 06:01, Rahul Sharma wrote:
>> [snip]
>> the PHY provider.
>>
>
> Please correct me if I got you wrong. You want somthing like this:
>
> pmu_system_controller: system-controller at 1004 {
>  ...
>   simple_phys: simple-phys {
> compatible = "samsung,exynos5420-simple-phy";
> ...
>   };
> };

 Not exactly.

 What I meant is that the PMU node itself should be the PHY provider, 
 e.g.

 pmu_system_controller: system-controller at 1004 {
 /* ... */
 #phy-cells = <1>;
 };

 and then the PMU node should instantiate the Exynos simple PHY driver,
 as this is a driver for a facility existing entirely inside of the PMU.
 Moreover, the driver should be rather called Exynos PMU PHY.

 I know this isn't really possible at the moment, but with device tree 
 we
 must design things carefully, so it's better to take a bit more time 
 and
 do things properly.

 So my opinion on this is that there should be a central Exynos PMU
 driver that claims the IO region and instantiates necessary subdrivers,
 such as Exynos PMU PHY driver, Exynos CLKOUT driver, Exynos cpuidle
 driver and more, similar to what is being done in drivers/mfd.
>>>
>>
>> Hi Tomasz,
>>
>> These PHYs are not part of PMU as such. I am not sure if it is correct to
>> probe them as phy provider for all these phys. Only relation of these 
>> phys with
>> the PMU is 'enable/disable control'.
>
> Well, in reality what is implemented by this driver is not even a PHY,
> just some kind of power controllers, which are contained entirely in the
> PMU.
>

 I agree. Actually the role of generic phy framework for these 'simple' 
 phys is
 only that much.

>> Controlling this bit using regmap interface
>> still looks better to me.
>
> Well, when there is a choice between using regmap and not using regmap,
> I'd rather choose the latter. Why would you want to introduce additional
> abstraction layer if there is no need for such?
>
>>
>> IMHO Ideal method would be probing these PHYs independently and resolving
>> the necessary dependencies like syscon handle, clocks etc. This way we 
>> will
>> not be having any common phy provider for all these independent PHYs and 
>> it
>> would be clean to add each of these phy nodes in DT. Please see my 
>> original
>> comment below.
>>
>> http://lkml.iu.edu/hypermail/linux/kernel/1404.1/00701.html
>
> With the solution I proposed, you don't need any kind of dependencies
> for those simple power controllers. They are just single bits that don't
> need anything special to operate, except PMU clock running.

 In that case we can further trim it down and let the drivers use the regmap
 interface to control this bit. Many drivers including HDMI, DP just need 
 that
 much functionality from the phy provider.
>>>
>>> Well, this is what several drivers already do, like USB PHY (dedicated
>>> IP block), watchdog (for watchdog mask), SATA PHY (dedicated IP block
>>> too) or will do, like I2C (for configuration of I2C mux on Exynos5).
>>>
>>> At least this would be consistent with them and wouldn't be an API
>>> abuse, so I'd be inclined to go this way more than introducing
>>> abstractions like this patch does.
>>
>> Ok. I had already posted a patch for this at
>> http://www.spinics.net/lists/linux-samsung-soc/msg28049.html
>> I will revive that thread.
>
> Looks good to me.
>
>>
>> @Tomasz Stanislawski, Do you have different opinion here?
>
> I'm afraid Tomasz might not be very responsive during next few days, as
> he is on a business trip. You might be able to reach him on our internal
> communicator, though.

Thanks Tomasz,

I will contact him over communicator.

Regards.

>
> Best regards,
> Tomasz
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2] drm/exynos: use regmap interface to set hdmiphy control bit in pmu

2014-05-20 Thread Rahul Sharma
Exynos drm hdmi driver used to get dummy hdmiphy clock to
control the PMU bit for hdmiphy. This bit needs to be set
before setting any resolution to hdmi hardware. This was
handled using dummy hdmiphy clock which is removed here.

PMU is already defined as system controller for exynos
SoCs. Hdmi driver is modified to control the phy enable bit
inside PMU using regmap interfaces.

Devicetree binding document for hdmi is also updated.

Signed-off-by: Rahul Sharma 
---
V2:
  1) Squashed hdmiphy clock cleanup patch.
  2) Addressed comments related to indentation, using
 BIT macro while definnig bits and using IS_ERR check
 while verifying regmap handle.

This patch is based on exynos-drm-next branch.

 .../devicetree/bindings/video/exynos_hdmi.txt  |2 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   27 ++--
 drivers/gpu/drm/exynos/regs-hdmi.h |4 +++
 3 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 75ada04..1fd8cf9 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,7 @@ Required properties:
"hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
 - ddc: phandle to the hdmi ddc node
 - phy: phandle to the hdmi phy node
+- samsung,syscon-phandle: phandle for system controller node for PMU.

 Example:

@@ -38,4 +39,5 @@ Example:
hpd-gpio = <&gpx3 7 1>;
ddc = <&hdmi_ddc_node>;
phy = <&hdmi_phy_node>;
+   samsung,syscon-phandle = <&pmu_system_controller>;
};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index b03e721..f5e188f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -38,6 +38,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 

@@ -81,7 +83,6 @@ struct hdmi_resources {
struct clk  *sclk_hdmi;
struct clk  *sclk_pixel;
struct clk  *sclk_hdmiphy;
-   struct clk  *hdmiphy;
struct clk  *mout_hdmi;
struct regulator_bulk_data  *regul_bulk;
int regul_count;
@@ -208,6 +209,7 @@ struct hdmi_context {
const struct hdmiphy_config *phy_confs;
unsigned intphy_conf_count;

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

@@ -2013,7 +2015,10 @@ static void hdmi_poweron(struct exynos_drm_display 
*display)
if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
DRM_DEBUG_KMS("failed to enable regulator bulk\n");

-   clk_prepare_enable(res->hdmiphy);
+   /* set pmu hdmiphy control bit to enable hdmiphy */
+   regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
+   PMU_HDMI_PHY_ENABLE_BIT, 1);
+
clk_prepare_enable(res->hdmi);
clk_prepare_enable(res->sclk_hdmi);

@@ -2040,7 +2045,11 @@ static void hdmi_poweroff(struct exynos_drm_display 
*display)

clk_disable_unprepare(res->sclk_hdmi);
clk_disable_unprepare(res->hdmi);
-   clk_disable_unprepare(res->hdmiphy);
+
+   /* reset pmu hdmiphy control bit to disable hdmiphy */
+   regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
+   PMU_HDMI_PHY_ENABLE_BIT, 0);
+
regulator_bulk_disable(res->regul_count, res->regul_bulk);

pm_runtime_put_sync(hdata->dev);
@@ -2143,11 +2152,6 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
goto fail;
}
-   res->hdmiphy = devm_clk_get(dev, "hdmiphy");
-   if (IS_ERR(res->hdmiphy)) {
-   DRM_ERROR("failed to get clock 'hdmiphy'\n");
-   goto fail;
-   }
res->mout_hdmi = devm_clk_get(dev, "mout_hdmi");
if (IS_ERR(res->mout_hdmi)) {
DRM_ERROR("failed to get clock 'mout_hdmi'\n");
@@ -2353,6 +2357,13 @@ static int hdmi_probe(struct platform_device *pdev)
goto err_hdmiphy;
}

+   hdata->pmureg = syscon_regmap_lookup_by_phandle(dev->of_node,
+   "samsung,syscon-phandle");
+   if (IS_ERR(hdata->pmureg)) {
+   DRM_ERROR("syscon regmap lookup failed.\n");
+   goto err_hdmiphy;
+   }
+
pm_runtime_enable(dev);
hdmi_display.ctx = hdata;

diff --git a/drivers/gpu/drm/exynos/regs-hdmi.h 
b/drivers/gpu/drm/exynos/regs-hdmi.h
index 84a69cd..6d846b9 100644
--- a/drivers/gpu/drm/exynos/regs-hdmi.h
+++ b/drivers/gpu/drm/exynos/regs-hdmi.h
@@ -585,4 +585,8 @@
 #define HDMI_PHY_DISABLE_MODE_SET  0

[Bug 78951] gl_PrimitiveID is zero if no geometry shader is present

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78951

--- Comment #2 from pavol at klacansky.com ---
Alright, I can create 3 geometry shaders for all primitives, but I am not sure
if that is the right way for mesa. Thanks

-- 
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/20140520/eb74270a/attachment.html>


[PATCH 7/8] radeon: Out of line radeon_get_ib_value

2014-05-20 Thread Andi Kleen
On Tue, May 20, 2014 at 06:16:48PM +0200, Marek Ol??k wrote:
> I think the function should stay in the header file. It's used in
> performance-critical code, so we want it to be inlined.

This doesn't make any sense. If it's talking to the hardware it will
be dominated by the cache misses.

-Andi


[PATCH] gpu/drm/ttm: Pass GFP flags in order to avoid deadlock.

2014-05-20 Thread Konrad Rzeszutek Wilk
On Tue, May 20, 2014 at 01:40:40AM +0100, Dave Airlie wrote:
> 
> cc'ing dri-devel.

It looks pretty simple and correct . I can test it tomorrow and make sure it 
works
right.
> 
> > >From d0d57745ba23faf605b0f249b57d283fe1a8ee60 Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa 
> > Date: Mon, 19 May 2014 17:59:03 +0900
> > Subject: [PATCH] gpu/drm/ttm: Pass GFP flags in order to avoid deadlock.
> > 
> > Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added
> > deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free()
> > are currently doing GFP_KERNEL allocation.
> > 
> > But these functions did not get updated to receive gfp_t argument.
> > This patch explicitly passes sc->gfp_mask or GFP_KERNEL to these functions,
> > and removes the deadlock warning.
> > 
> > Signed-off-by: Tetsuo Handa 
> > ---
> >  drivers/gpu/drm/ttm/ttm_page_alloc.c | 19 ++-
> >  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 19 +--
> >  2 files changed, 19 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
> > b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> > index 863bef9..ba8f78e 100644
> > --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> > +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> > @@ -297,8 +297,10 @@ static void ttm_pool_update_free_locked(struct 
> > ttm_page_pool *pool,
> >   *
> >   * @pool: to free the pages from
> >   * @free_all: If set to true will free all pages in pool
> > + * @gfp: GFP flags.
> >   **/
> > -static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free)
> > +static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,
> > + gfp_t gfp)
> >  {
> > unsigned long irq_flags;
> > struct page *p;
> > @@ -309,8 +311,7 @@ static int ttm_page_pool_free(struct ttm_page_pool 
> > *pool, unsigned nr_free)
> > if (NUM_PAGES_TO_ALLOC < nr_free)
> > npages_to_free = NUM_PAGES_TO_ALLOC;
> >  
> > -   pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
> > -   GFP_KERNEL);
> > +   pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> > if (!pages_to_free) {
> > pr_err("Failed to allocate memory for pool free operation\n");
> > return 0;
> > @@ -382,9 +383,7 @@ out:
> >   *
> >   * XXX: (dchinner) Deadlock warning!
> >   *
> > - * ttm_page_pool_free() does memory allocation using GFP_KERNEL.  that 
> > means
> > - * this can deadlock when called a sc->gfp_mask that is not equal to
> > - * GFP_KERNEL.
> > + * We need to pass sc->gfp_mask to ttm_page_pool_free().
> >   *
> >   * This code is crying out for a shrinker per pool
> >   */
> > @@ -405,7 +404,8 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
> > shrink_control *sc)
> > if (shrink_pages == 0)
> > break;
> > pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
> > -   shrink_pages = ttm_page_pool_free(pool, nr_free);
> > +   shrink_pages = ttm_page_pool_free(pool, nr_free,
> > + sc->gfp_mask);
> > freed += nr_free - shrink_pages;
> > }
> > return freed;
> > @@ -706,7 +706,7 @@ static void ttm_put_pages(struct page **pages, unsigned 
> > npages, int flags,
> > }
> > spin_unlock_irqrestore(&pool->lock, irq_flags);
> > if (npages)
> > -   ttm_page_pool_free(pool, npages);
> > +   ttm_page_pool_free(pool, npages, GFP_KERNEL);
> >  }
> >  
> >  /*
> > @@ -846,7 +846,8 @@ void ttm_page_alloc_fini(void)
> > ttm_pool_mm_shrink_fini(_manager);
> >  
> > for (i = 0; i < NUM_POOLS; ++i)
> > -   ttm_page_pool_free(&_manager->pools[i], FREE_ALL_PAGES);
> > +   ttm_page_pool_free(&_manager->pools[i], FREE_ALL_PAGES,
> > +  GFP_KERNEL);
> >  
> > kobject_put(&_manager->kobj);
> > _manager = NULL;
> > diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> > b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> > index fb8259f..1b79bf0 100644
> > --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> > +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> > @@ -411,8 +411,10 @@ static void ttm_dma_page_put(struct dma_pool *pool, 
> > struct dma_page *d_page)
> >   *
> >   * @pool: to free the pages from
> >   * @nr_free: If set to true will free all pages in pool
> > + * @gfp: GFP flags.
> >   **/
> > -static unsigned ttm_dma_page_pool_free(struct dma_pool *pool, unsigned 
> > nr_free)
> > +static unsigned ttm_dma_page_pool_free(struct dma_pool *pool, unsigned 
> > nr_free,
> > +  gfp_t gfp)
> >  {
> > unsigned long irq_flags;
> > struct dma_page *dma_p, *tmp;
> > @@ -430,8 +432,7 @@ static unsigned ttm_dma_page_pool_free(struct dma_pool 
> > *pool, unsigned nr_free)
> >  npages_to_free, nr_free);
> > }
> >  #endif
> > -   pages_to_free = kmalloc(npages_to_free * sizeo

[PATCH 3/6] drm: Support legacy cursor ioctls via universal planes when possible (v3)

2014-05-20 Thread Daniel Vetter
On Mon, May 19, 2014 at 04:58:39PM -0700, Matt Roper wrote:
> If drivers support universal planes and have registered a cursor plane
> with the DRM core, we should use that universal plane support when
> handling legacy cursor ioctls.  Drivers that transition to universal
> planes won't have to maintain separate legacy ioctl handling; drivers
> that don't transition to universal planes will continue to operate
> without any change to behavior.
> 
> Note that there's a bit of a mismatch between the legacy cursor ioctls
> and the universal plane API's --- legacy ioctl's use driver buffer
> handles directly whereas the universal plane API takes drm_framebuffers.
> Since there's no way to recover the driver handle from a
> drm_framebuffer, we can implement legacy ioctl's in terms of universal
> plane interfaces, but cannot implement universal plane interfaces in
> terms of legacy ioctls.  Specifically, there's no way to create a
> general cursor helper in the way we previously created a primary plane
> helper.
> 
> It's important to land this patch before any patches that add universal
> cursor support to individual drivers so that drivers don't have to worry
> about juggling two different styles of reference counting for cursor
> buffers when userspace mixes and matches legacy and universal cursor
> calls.  With this patch, a driver that switches to universal cursor
> support may assume that all cursor buffers are wrapped in a
> drm_framebuffer and can rely on framebuffer reference counting for all
> cursor operations.
> 
> v3:
>  - Drop drm_mode_rmfb() call that is no longer needed now that we're
>using setplane_internal(), which takes care of deref'ing the
>appropriate framebuffer.
> v2:
>  - Use new add_framebuffer_internal() function to create framebuffer
>rather than trying to call directly into the ioctl interface and
>look up the handle returned.
>  - Use new setplane_internal() function to update the cursor plane
>rather than calling through the ioctl interface.  Note that since
>we're no longer looking up an fb_id, no extra reference will be
>taken here.
>  - Grab extra reference to fb under lock in !BO case to avoid issues
>where racing userspace could cause the fb to be destroyed out from
>under us after we grab the fb pointer.
> 
> Signed-off-by: Matt Roper 

Reviewed-by: Daniel Vetter 

Maybe add a comment that setplane_internal will eat the reference, but
optional.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 99 
> ++
>  include/drm/drm_crtc.h |  4 ++
>  2 files changed, 103 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 3e9dae0..a3ebc45 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2516,6 +2516,98 @@ out:
>   return ret;
>  }
>  
> +/**
> + * drm_mode_cursor_universal - translate legacy cursor ioctl call into a
> + * universal plane handler call
> + * @crtc: crtc to update cursor for
> + * @req: data pointer for the ioctl
> + * @file_priv: drm file for the ioctl call
> + *
> + * Legacy cursor ioctl's work directly with driver buffer handles.  To
> + * translate legacy ioctl calls into universal plane handler calls, we need 
> to
> + * wrap the native buffer handle in a drm_framebuffer.
> + *
> + * Note that we assume any handle passed to the legacy ioctls was a 32-bit 
> ARGB
> + * buffer with a pitch of 4*width; the universal plane interface should be 
> used
> + * directly in cases where the hardware can support other buffer settings and
> + * userspace wants to make use of these capabilities.
> + *
> + * Returns:
> + * Zero on success, errno on failure.
> + */
> +static int drm_mode_cursor_universal(struct drm_crtc *crtc,
> +  struct drm_mode_cursor2 *req,
> +  struct drm_file *file_priv)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_framebuffer *fb = NULL;
> + struct drm_mode_fb_cmd2 fbreq = {
> + .width = req->width,
> + .height = req->height,
> + .pixel_format = DRM_FORMAT_ARGB,
> + .pitches = { req->width * 4 },
> + .handles = { req->handle },
> + };
> + int32_t crtc_x, crtc_y;
> + uint32_t crtc_w = 0, crtc_h = 0;
> + uint32_t src_w = 0, src_h = 0;
> + int ret = 0;
> +
> + BUG_ON(!crtc->cursor);
> +
> + /*
> +  * Obtain fb we'll be using (either new or existing) and take an extra
> +  * reference to it if fb != null.  setplane will take care of dropping
> +  * the reference if the plane update fails.
> +  */
> + if (req->flags & DRM_MODE_CURSOR_BO) {
> + if (req->handle) {
> + fb = add_framebuffer_internal(dev, &fbreq, file_priv);
> + if (IS_ERR(fb)) {
> + DRM_DEBUG_KMS("failed to wrap cursor buffer in 
> drm framebuffer\n");
> + 

Fwd: Re: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker functions.

2014-05-20 Thread Thomas Hellstrom
Konrad,

This looks OK to me, but do you have a chance to take a look?

/Thomas



 Original Message 
Return-Path:
X-Original-To:  thomas at shipmail.org
Delivered-To:   thomas at shipmail.org
Received:   from mail.shipmail.org (lin0.kontor.shipmail.org [127.0.0.1])
by mail.shipmail.org (Postfix) with ESMTP id 7EB6A33807A for
; Tue, 20 May 2014 02:40:25 +0200 (CEST)
Received:   from lin0.kontor.shipmail.org [127.0.0.1] by BitDefender SMTP
Proxy on lin0.kontor.shipmail.org [127.0.0.1] for
lin0.kontor.shipmail.org [127.0.0.1]; Tue, 20 May 2014 02:40:25 +0200
(CEST)
Received:   from gabe.freedesktop.org (gabe.freedesktop.org
[131.252.210.177]) by mail.shipmail.org (Postfix) with ESMTP id
1D7B0338079 for ; Tue, 20 May 2014 02:40:25 +0200
(CEST)
Received:   from gabe.freedesktop.org (localhost [127.0.0.1]) by
gabe.freedesktop.org (Postfix) with ESMTP id B14C16E104; Mon, 19 May
2014 17:40:25 -0700 (PDT)
X-Original-To:  dri-devel at lists.freedesktop.org
Delivered-To:   dri-devel at lists.freedesktop.org
Received:   from gir.skynet.ie (gir.skynet.ie [193.1.99.77]) by
gabe.freedesktop.org (Postfix) with ESMTP id E6E276E104 for
; Mon, 19 May 2014 17:40:23 -0700 (PDT)
Received:   from skynet.skynet.ie (skynet.skynet.ie [193.1.99.74]) (using
TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
certificate requested) by gir.skynet.ie (Postfix) with ESMTPS id
C819612529; Tue, 20 May 2014 01:40:21 +0100 (IST)
Date:   Tue, 20 May 2014 01:40:21 +0100 (IST)
From:   Dave Airlie 
X-X-Sender: airlied at skynet.skynet.ie
To: Tetsuo Handa 
Subject:Re: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for
shrinker functions.
In-Reply-To:<201405192339.JIJ04144.FHQFVFOtOSLJOM at I-love.SAKURA.ne.jp>
Message-ID: 
References: <201405192339.JIJ04144.FHQFVFOtOSLJOM at I-love.SAKURA.ne.jp>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version:   1.0
Cc: linux-kernel at vger.kernel.org, glommer at openvz.org, mgorman at 
suse.de,
DRI mailing list , dchinner at redhat.com
X-BeenThere:dri-devel at lists.freedesktop.org
X-Mailman-Version:  2.1.15
Precedence: list
List-Id:Direct Rendering Infrastructure - Development

List-Unsubscribe:
,

List-Archive:   
List-Post:  
List-Help:  
List-Subscribe:
,

Content-Type:   text/plain; charset="us-ascii"
Content-Transfer-Encoding:  7bit
Errors-To:  dri-devel-bounces at lists.freedesktop.org
Sender: "dri-devel" 
X-BitDefender-Scanner:  Mail not scanned due to license constraints



cc'ing dri-devel.

> >From e314a1a1583e585d062dfc30c8aad8bf5380510b Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa 
> Date: Mon, 19 May 2014 18:43:21 +0900
> Subject: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker 
> functions.
> 
> I can observe that RHEL7 environment stalls with 100% CPU usage when a
> certain type of memory pressure is given. While the shrinker functions
> are called by shrink_slab() before the OOM killer is triggered, the stall
> lasts for many minutes.
> 
> I added debug printk() and observed that many threads are blocked for more
> than 10 seconds at ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan()
> functions. Since the kswapd can call these functions later, the current
> thread can return from these functions as soon as chosen by the OOM killer.
> 
> This patch changes "mutex_lock();" to "if (mutex_lock_killable()) return ...;"
> so that any threads can promptly give up. (By the way, as far as I tested,
> changing to "if (!mutex_trylock()) return ...;" likely shortens the duration
> of stall. Maybe we don't need to wait for mutex if someone is already calling
> these functions.)
> 
> Signed-off-by: Tetsuo Handa 
> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index 1b79bf0..f75dab8 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -1012,7 +1012,8 @@ ttm_dma_pool_shrink_scan(struct shrinker *shrink, 
> struct shrink_control *sc)
>   if (list_empty(&_manager->pools))
>   return SHRINK_STOP;
>  
> - mutex_lock(&_manager->lock);
> + if (mutex_lock_killable(&_manager->lock))
> + return SHRINK_STOP;
>   pool_offset = pool_offset % _manager->npools;
>   list_for_each_entry(p, &_manager->pools, pools) {
>   unsigned nr_free;
> @@ -1043,7 +1044,8 @@ ttm_dma_pool_shrink_cou

[Bug 78951] gl_PrimitiveID is zero if no geometry shader is present

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78951

--- Comment #1 from Michel D?nzer  ---
AFAICT the hardware doesn't provide any way to retrieve the primitive ID
without a geometry shader, so we'd probably need to use a passthrough geometry
shader for this. Any volunteers?

-- 
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/20140520/38abb4cd/attachment.html>


[Intel-gfx] [PATCH 1/4] drm: Support legacy cursor ioctls via universal planes when possible (v2)

2014-05-20 Thread Daniel Vetter
On Mon, May 19, 2014 at 03:25:45PM -0700, Matt Roper wrote:
> On Sat, May 17, 2014 at 12:43:04AM +0200, Daniel Vetter wrote:
> > On Sat, May 17, 2014 at 12:38 AM, Matt Roper  
> > wrote:
> > > +   if (ret) {
> > > +   if (req->flags & DRM_MODE_CURSOR_BO)
> > > +   drm_mode_rmfb(dev, &fb->base.id, file_priv);
> > > +   return ret;
> > > +   }
> > 
> > With the new refcount logic an unconditional
> > drm_framebuffer_unreference should be here instead of this. I think,
> > but please double-check since it's late here ;-)
> > -Daniel
> 
> Actually, I'm not sure if we want the unreference at all.
> setplane_internal() unrefs fb on failure (and old_fb on success), so I
> think that's already taken care of.

Oh right, I've forgotten about that part. A one-line comment here that
setplane_internal will eat the reference would be good - you already have
a corresponding comment around setplane_internal but I guess that's not
good enough for silly me ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[Bug 78453] [HAWAII] Get acceleration working

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78453

--- Comment #36 from Michel D?nzer  ---
(In reply to comment #34)
> Unfortunatly egltri_screen display a triangle but sometimes and in a very
> broken way : always a message about gpu stall, sometimes it display garbage,
> sometimes a triangle but on the right or on the left. The gpu is
> definitively doing some rendering works correctly but it fails before
> swapping buffer.

Beware that it might display something from a previous run even if it doesn't
actually render anything. To rule that out, you may want to use another simple
test, e.g. one that only clears the window with glClear(), and alternate
between the tests, so you can tell whether they actually render anything.


> BTW why eglinfo also make the gpu stall ? As far as I can tell there is no
> draw operation involved, just egl initialisation and unintialisation.

A command stream might still be submitted to the hardware when the EGL context
is unbound/destroyed. Should be easy to verify via a breakpoint in gdb.

If that is the case, it might be useful to try narrowing down which part of
that 'empty' command stream hangs the GPU.

-- 
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/20140520/7638f530/attachment.html>


[Bug 78951] gl_PrimitiveID is zero if no geometry shader is present

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78951

pavol at klacansky.com changed:

   What|Removed |Added

 CC||pavol at klacansky.com
Version|unspecified |git

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


[Bug 78951] New: gl_PrimitiveID is zero if no geometry shader is present

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78951

  Priority: medium
Bug ID: 78951
  Assignee: dri-devel at lists.freedesktop.org
   Summary: gl_PrimitiveID is zero if no geometry shader is
present
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: pavol at klacansky.com
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Drivers/Gallium/r600
   Product: Mesa

I case there is no geometry shader attached to program, gl_PrimitiveID is
always zero.

-- 
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/20140520/43bdbc10/attachment.html>


[PATCH 3/6] drm: Support legacy cursor ioctls via universal planes when possible (v4)

2014-05-20 Thread Matt Roper
If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls.  Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition to universal planes will continue to operate
without any change to behavior.

Note that there's a bit of a mismatch between the legacy cursor ioctls
and the universal plane API's --- legacy ioctl's use driver buffer
handles directly whereas the universal plane API takes drm_framebuffers.
Since there's no way to recover the driver handle from a
drm_framebuffer, we can implement legacy ioctl's in terms of universal
plane interfaces, but cannot implement universal plane interfaces in
terms of legacy ioctls.  Specifically, there's no way to create a
general cursor helper in the way we previously created a primary plane
helper.

It's important to land this patch before any patches that add universal
cursor support to individual drivers so that drivers don't have to worry
about juggling two different styles of reference counting for cursor
buffers when userspace mixes and matches legacy and universal cursor
calls.  With this patch, a driver that switches to universal cursor
support may assume that all cursor buffers are wrapped in a
drm_framebuffer and can rely on framebuffer reference counting for all
cursor operations.

v4:
 - Add comments pointing out setplane_internal's reference-eating
   semantics.
v3:
 - Drop drm_mode_rmfb() call that is no longer needed now that we're
   using setplane_internal(), which takes care of deref'ing the
   appropriate framebuffer.
v2:
 - Use new add_framebuffer_internal() function to create framebuffer
   rather than trying to call directly into the ioctl interface and
   look up the handle returned.
 - Use new setplane_internal() function to update the cursor plane
   rather than calling through the ioctl interface.  Note that since
   we're no longer looking up an fb_id, no extra reference will be
   taken here.
 - Grab extra reference to fb under lock in !BO case to avoid issues
   where racing userspace could cause the fb to be destroyed out from
   under us after we grab the fb pointer.

Reviewed-by: Daniel Vetter 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_crtc.c | 107 +
 include/drm/drm_crtc.h |   4 ++
 2 files changed, 111 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3e9dae0..34b6d95 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2258,6 +2258,10 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
crtc = obj_to_crtc(obj);
}

+   /*
+* setplane_internal will take care of deref'ing either the old or new
+* framebuffer depending on success.
+*/
return setplane_internal(crtc, plane, fb,
 plane_req->crtc_x, plane_req->crtc_y,
 plane_req->crtc_w, plane_req->crtc_h,
@@ -2516,6 +2520,102 @@ out:
return ret;
 }

+/**
+ * drm_mode_cursor_universal - translate legacy cursor ioctl call into a
+ * universal plane handler call
+ * @crtc: crtc to update cursor for
+ * @req: data pointer for the ioctl
+ * @file_priv: drm file for the ioctl call
+ *
+ * Legacy cursor ioctl's work directly with driver buffer handles.  To
+ * translate legacy ioctl calls into universal plane handler calls, we need to
+ * wrap the native buffer handle in a drm_framebuffer.
+ *
+ * Note that we assume any handle passed to the legacy ioctls was a 32-bit ARGB
+ * buffer with a pitch of 4*width; the universal plane interface should be used
+ * directly in cases where the hardware can support other buffer settings and
+ * userspace wants to make use of these capabilities.
+ *
+ * Returns:
+ * Zero on success, errno on failure.
+ */
+static int drm_mode_cursor_universal(struct drm_crtc *crtc,
+struct drm_mode_cursor2 *req,
+struct drm_file *file_priv)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_framebuffer *fb = NULL;
+   struct drm_mode_fb_cmd2 fbreq = {
+   .width = req->width,
+   .height = req->height,
+   .pixel_format = DRM_FORMAT_ARGB,
+   .pitches = { req->width * 4 },
+   .handles = { req->handle },
+   };
+   int32_t crtc_x, crtc_y;
+   uint32_t crtc_w = 0, crtc_h = 0;
+   uint32_t src_w = 0, src_h = 0;
+   int ret = 0;
+
+   BUG_ON(!crtc->cursor);
+
+   /*
+* Obtain fb we'll be using (either new or existing) and take an extra
+* reference to it if fb != null.  setplane will take care of dropping
+* the reference if the plane update fails.
+*/
+   if (req->flags & DRM_MODE_CURSOR_BO) {
+   if (req->handl

[git pull] drm intel fixes

2014-05-20 Thread Dave Airlie

Hi Linus,

just some intel fixes, I have some radeon ones but I need to get some 
patches dropped from the pull req.

Dave.

The following changes since commit 14186fea0cb06bc43181ce239efe0df6f1af260a:

  Merge tag 'locks-v3.15-4' of git://git.samba.org/jlayton/linux (2014-05-13 
11:33:09 +0900)

are available in the git repository at:


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

for you to fetch changes up to 4ba4801d73d14690ed15774424e8b1d4c18323a5:

  Merge tag 'drm-intel-fixes-2014-05-16' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-05-20 09:56:26 
+1000)



Aaron Lu (1):
  drm/i915: restore backlight precision when converting from ACPI

Chris Wilson (1):
  drm/i915: Use the first mode if there is no preferred mode in the EDID

Dave Airlie (1):
  Merge tag 'drm-intel-fixes-2014-05-16' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes

Egbert Eich (1):
  drm/i915/SDVO: For sysfs link put directory and target in correct order

Jani Nikula (4):
  drm/i915: clean up VBT eDP link param decoding
  drm/i915: use lane count and link rate from VBT as minimums for eDP
  drm/i915/vlv: reset VLV media force wake request register
  drm/i915/dp: force eDP lane count to max available lanes on BDW

Paulo Zanoni (1):
  drm/i915: consider the source max DP lane count too

Ville Syrj?l? (1):
  drm/i915: Increase WM memory latency values on SNB

 drivers/gpu/drm/i915/intel_bios.c   | 52 +--
 drivers/gpu/drm/i915/intel_dp.c | 55 +++--
 drivers/gpu/drm/i915/intel_fbdev.c  |  9 ++
 drivers/gpu/drm/i915/intel_panel.c  |  8 +++---
 drivers/gpu/drm/i915/intel_pm.c | 40 +++
 drivers/gpu/drm/i915/intel_sdvo.c   |  4 +--
 drivers/gpu/drm/i915/intel_uncore.c |  2 ++
 7 files changed, 141 insertions(+), 29 deletions(-)


[PATCH] gpu/drm/ttm: Pass GFP flags in order to avoid deadlock.

2014-05-20 Thread Dave Airlie

cc'ing dri-devel.

> >From d0d57745ba23faf605b0f249b57d283fe1a8ee60 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa 
> Date: Mon, 19 May 2014 17:59:03 +0900
> Subject: [PATCH] gpu/drm/ttm: Pass GFP flags in order to avoid deadlock.
> 
> Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added
> deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free()
> are currently doing GFP_KERNEL allocation.
> 
> But these functions did not get updated to receive gfp_t argument.
> This patch explicitly passes sc->gfp_mask or GFP_KERNEL to these functions,
> and removes the deadlock warning.
> 
> Signed-off-by: Tetsuo Handa 
> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc.c | 19 ++-
>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 19 +--
>  2 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 863bef9..ba8f78e 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -297,8 +297,10 @@ static void ttm_pool_update_free_locked(struct 
> ttm_page_pool *pool,
>   *
>   * @pool: to free the pages from
>   * @free_all: If set to true will free all pages in pool
> + * @gfp: GFP flags.
>   **/
> -static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free)
> +static int ttm_page_pool_free(struct ttm_page_pool *pool, unsigned nr_free,
> +   gfp_t gfp)
>  {
>   unsigned long irq_flags;
>   struct page *p;
> @@ -309,8 +311,7 @@ static int ttm_page_pool_free(struct ttm_page_pool *pool, 
> unsigned nr_free)
>   if (NUM_PAGES_TO_ALLOC < nr_free)
>   npages_to_free = NUM_PAGES_TO_ALLOC;
>  
> - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
> - GFP_KERNEL);
> + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
>   if (!pages_to_free) {
>   pr_err("Failed to allocate memory for pool free operation\n");
>   return 0;
> @@ -382,9 +383,7 @@ out:
>   *
>   * XXX: (dchinner) Deadlock warning!
>   *
> - * ttm_page_pool_free() does memory allocation using GFP_KERNEL.  that means
> - * this can deadlock when called a sc->gfp_mask that is not equal to
> - * GFP_KERNEL.
> + * We need to pass sc->gfp_mask to ttm_page_pool_free().
>   *
>   * This code is crying out for a shrinker per pool
>   */
> @@ -405,7 +404,8 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
> shrink_control *sc)
>   if (shrink_pages == 0)
>   break;
>   pool = &_manager->pools[(i + pool_offset)%NUM_POOLS];
> - shrink_pages = ttm_page_pool_free(pool, nr_free);
> + shrink_pages = ttm_page_pool_free(pool, nr_free,
> +   sc->gfp_mask);
>   freed += nr_free - shrink_pages;
>   }
>   return freed;
> @@ -706,7 +706,7 @@ static void ttm_put_pages(struct page **pages, unsigned 
> npages, int flags,
>   }
>   spin_unlock_irqrestore(&pool->lock, irq_flags);
>   if (npages)
> - ttm_page_pool_free(pool, npages);
> + ttm_page_pool_free(pool, npages, GFP_KERNEL);
>  }
>  
>  /*
> @@ -846,7 +846,8 @@ void ttm_page_alloc_fini(void)
>   ttm_pool_mm_shrink_fini(_manager);
>  
>   for (i = 0; i < NUM_POOLS; ++i)
> - ttm_page_pool_free(&_manager->pools[i], FREE_ALL_PAGES);
> + ttm_page_pool_free(&_manager->pools[i], FREE_ALL_PAGES,
> +GFP_KERNEL);
>  
>   kobject_put(&_manager->kobj);
>   _manager = NULL;
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index fb8259f..1b79bf0 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -411,8 +411,10 @@ static void ttm_dma_page_put(struct dma_pool *pool, 
> struct dma_page *d_page)
>   *
>   * @pool: to free the pages from
>   * @nr_free: If set to true will free all pages in pool
> + * @gfp: GFP flags.
>   **/
> -static unsigned ttm_dma_page_pool_free(struct dma_pool *pool, unsigned 
> nr_free)
> +static unsigned ttm_dma_page_pool_free(struct dma_pool *pool, unsigned 
> nr_free,
> +gfp_t gfp)
>  {
>   unsigned long irq_flags;
>   struct dma_page *dma_p, *tmp;
> @@ -430,8 +432,7 @@ static unsigned ttm_dma_page_pool_free(struct dma_pool 
> *pool, unsigned nr_free)
>npages_to_free, nr_free);
>   }
>  #endif
> - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
> - GFP_KERNEL);
> + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
>  
>   if (!pages_to_free) {
>   pr_err("%s: Failed to allocate memory for pool free 
> operation\n",
> @@ -530,7 +531,7 @@ static void ttm_dma_free_pool(struct device *d

[PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker functions.

2014-05-20 Thread Dave Airlie

cc'ing dri-devel.

> >From e314a1a1583e585d062dfc30c8aad8bf5380510b Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa 
> Date: Mon, 19 May 2014 18:43:21 +0900
> Subject: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker 
> functions.
> 
> I can observe that RHEL7 environment stalls with 100% CPU usage when a
> certain type of memory pressure is given. While the shrinker functions
> are called by shrink_slab() before the OOM killer is triggered, the stall
> lasts for many minutes.
> 
> I added debug printk() and observed that many threads are blocked for more
> than 10 seconds at ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan()
> functions. Since the kswapd can call these functions later, the current
> thread can return from these functions as soon as chosen by the OOM killer.
> 
> This patch changes "mutex_lock();" to "if (mutex_lock_killable()) return ...;"
> so that any threads can promptly give up. (By the way, as far as I tested,
> changing to "if (!mutex_trylock()) return ...;" likely shortens the duration
> of stall. Maybe we don't need to wait for mutex if someone is already calling
> these functions.)
> 
> Signed-off-by: Tetsuo Handa 
> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index 1b79bf0..f75dab8 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -1012,7 +1012,8 @@ ttm_dma_pool_shrink_scan(struct shrinker *shrink, 
> struct shrink_control *sc)
>   if (list_empty(&_manager->pools))
>   return SHRINK_STOP;
>  
> - mutex_lock(&_manager->lock);
> + if (mutex_lock_killable(&_manager->lock))
> + return SHRINK_STOP;
>   pool_offset = pool_offset % _manager->npools;
>   list_for_each_entry(p, &_manager->pools, pools) {
>   unsigned nr_free;
> @@ -1043,7 +1044,8 @@ ttm_dma_pool_shrink_count(struct shrinker *shrink, 
> struct shrink_control *sc)
>   struct device_pools *p;
>   unsigned long count = 0;
>  
> - mutex_lock(&_manager->lock);
> + if (mutex_lock_killable(&_manager->lock))
> + return 0;
>   list_for_each_entry(p, &_manager->pools, pools)
>   count += p->pool->npages_free;
>   mutex_unlock(&_manager->lock);
> 


[PATCH] drm: tda998x: Add support for CEC address 0x35

2014-05-20 Thread Mark Brown
From: Liviu Dudau 

Currently the tda998x driver only attempts to instantiate the CEC at I2C
address 0x34, meaning that if the CEC is instead at 0x35 (for example,
due to a conflict with another device) we will not be able to use it.
Attempt to handle some such situations by trying to instantiate the CEC
at 0x35 if we fail at 0x34.

[Wrote commit message -- broonie]

Signed-off-by: Liviu Dudau 
Signed-off-by: Jon Medhurst 
Signed-off-by: Mark Brown 
---

I'm aware this isn't wonderful and is tied in with the general questions
about how to enumerate decomposed video devices, I'm partly looking for
feedback on the best way forwards here.

 drivers/gpu/drm/i2c/tda998x_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 240c331405b9..a3368e7d12c4 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1246,6 +1246,8 @@ tda998x_encoder_init(struct i2c_client *client,
priv->current_page = 0xff;
priv->hdmi = client;
priv->cec = i2c_new_dummy(client->adapter, 0x34);
+   if (!priv->cec)
+   priv->cec = i2c_new_dummy(client->adapter, 0x35);
if (!priv->cec) {
kfree(priv);
return -ENODEV;
-- 
2.0.0.rc2



[RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges

2014-05-20 Thread Ajay kumar
On 5/19/14, Thierry Reding  wrote:
> On Sun, May 18, 2014 at 01:50:36PM +0530, Ajay kumar wrote:
>> On Sun, May 18, 2014 at 2:44 AM, Thierry Reding
>>  wrote:
>> > On Thu, May 15, 2014 at 05:10:16PM +0530, Ajay kumar wrote:
>> >> On Thu, May 15, 2014 at 1:43 PM, Thierry Reding
>> >>  wrote:
>> > [...]
>> >> > I still don't see how controlling the enable GPIO from the panel will
>> >> > be
>> >> > in any way better, or different for that matter, from simply
>> >> > enabling
>> >> > the backlight and let the backlight driver handle the enable GPIO.
>> >> > Have
>> >> > you tried to do that and found that it doesn't work?
>> >> It works, but it gives me glitch when I try to configure video.
>> >> This is because backlight_on(pwm-backlight) happens much before
>> >> I configure video(inside drm), and while configuring video there would
>> >> be a glitch,
>> >> and that glitch would be visible to the user since backlight is already
>> >> enabled.
>> >
>> > Okay, so this means that your backlight is turned on too early. Instead
>> > of working around that problem by moving control of the backlight
>> > enable
>> > GPIO from the backlight driver into the panel driver, the correct way
>> > to
>> > fix it is to make sure the backlight stays off until video is ready.
>> Ok. Please suggest an idea how to do the same!
>
> I did post a patch[0] a long time ago that added a way to fix this for
> pwm-backlight at least.
I have tried this. We have to wait till the userspace to switch the
backlight on again :(

>> I have already suggested a simple idea which conforms to a valid spec.
>> Just because enable_gpio is already a part of pwm_bl.c, I somewhat feel
>> like we are forcing people to handle enable_gpio inside pwm_bl.c.
>
> And that's a good thing. That's what people will expect. Backlights are
> exposed via sysfs, which is currently also the only way to control the
> backlight from userspace. If the driver for that doesn't have everything
> required to control the backlight how can userspace control it?
This is a valid point, only at the hardware level.
But if you consider a user experience perspective,
user still will not be able to see the backlight even
though enable_gpio is controlled elsewhere, since
pwm is disabled anyhow.
Now lets talk about backlight_on case. Even though user tries to turn
on the backlight, and the driver turns on backlight supply, pwm and
enable_gpio, the driver cannot always guarantee him that backlight is
"really on" since it also depends on panel power.
Such ambiguities exist for few panels. And, for such panels why can't
we keep enable_gpio in another driver, and let the pwm_bl control only
backlight levels?

>> Note that, pwm_bl can still work properly without enabling the backlight
>> GPIO.
>> And, I did point out to a valid datasheet from AUO, which clearly
>> indicates why
>> backlight enable GPIO should be a part of panel driver and not pwm_bl
>> driver.
>
> Just because some spec mentions the backlight enable pin in some panel
> power up sequence diagram that doesn't mean we have to implement it as
> part of the panel driver.
That is not "some spec". I believe all the AUO panels share the same sequence!

>> I am not trying to say we should remove enable_gpio from pwm_bl.
>> Provided that its already an optional property, and if someone wants
>> to control it in a panel driver, what is wrong in doing so?
>
> See above.
>
> Thierry
>
> [0]: https://lkml.org/lkml/2013/10/7/188
>


[Bug 77785] (radeonsi) Some lighting issues in games, textures goes black

2014-05-20 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=77785

--- Comment #21 from smoki  ---
Created attachment 99364
  --> https://bugs.freedesktop.org/attachment.cgi?id=99364&action=edit
Trine 2 - fglrx

-- 
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/20140520/46ceb4f0/attachment.html>


  1   2   >