[PATCH] drm/cma: Use the %zu specifier for printing size_t

[Fabio Estevam]

From: Fabio Estevam 

Building for arm64 causes the following warnings:

drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_create':
drivers/gpu/drm/drm_gem_cma_helper.c:114:4: warning: format '%d' expects 
argument of type 'int', but argument 3 has type 'size_t' [-Wformat=]
size);
^
drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_describe':
drivers/gpu/drm/drm_gem_cma_helper.c:393:4: warning: format '%d' expects 
argument of type 'int', but argument 8 has type 'size_t' [-Wformat=]
off, _obj->paddr, cma_obj->vaddr, obj->size);
^

Use the %zu specifier for printing size_t.

Reported-by: Olof's autobuilder 
Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/drm_gem_cma_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index e419eed..bd75f30 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -110,7 +110,7 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct 
drm_device *drm,
cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
if (!cma_obj->vaddr) {
-   dev_err(drm->dev, "failed to allocate buffer with size %d\n",
+   dev_err(drm->dev, "failed to allocate buffer with size %zu\n",
size);
ret = -ENOMEM;
goto error;
@@ -388,7 +388,7 @@ void drm_gem_cma_describe(struct drm_gem_cma_object 
*cma_obj,

off = drm_vma_node_start(>vma_node);

-   seq_printf(m, "%2d (%2d) %08llx %pad %p %d",
+   seq_printf(m, "%2d (%2d) %08llx %pad %p %zu",
obj->name, obj->refcount.refcount.counter,
off, _obj->paddr, cma_obj->vaddr, obj->size);

-- 
1.9.1

[PATCH] drm/mm: Support 4 GiB and larger ranges

[Russell King - ARM Linux]

On Tue, Jan 27, 2015 at 09:31:26AM +0100, Thomas Hellstrom wrote:
> On 01/27/2015 09:15 AM, Thierry Reding wrote:
> > Are you referring to the 4 GiB - 1 comment? The point I was trying to
> > make is not that the granularity of the IOVA space needs to be 1 byte
> > but rather that using an unsigned long for a size on a 32-bit machine
> > will give you 4 GiB - 1 addresses. The IOMMU page size is still 4 KiB
> > for Tegra.
> 
> I was rather referring to that if the range manager (drm_mm) is set up
> to manage pages instead of bytes
> (like, for example, the TTM VM address space), you'd get 4G - 1 pages,
> which, I believe, is sufficient on most 32 bit systems?

It'd probably also be more efficient on 32-bit systems rather than
shifting them over to using 64-bit quantities.

If the allocation granularity were to move to pages, would it be worth
moving to a pfn-based addressing system too, rather than sticking with
a byte address there too?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 2/2] drm/exynos: remove to use unnecessary MODULE_xxx macro

[Joonyoung Shim]

The exynos_drm_dmabuf.c file doesn't include any module feature and it
isn't built to module.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 60192ed..3833bf8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -279,7 +279,3 @@ err_buf_detach:

return ERR_PTR(ret);
 }
-
-MODULE_AUTHOR("Inki Dae ");
-MODULE_DESCRIPTION("Samsung SoC DRM DMABUF Module");
-MODULE_LICENSE("GPL");
-- 
1.9.1

[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_DMABUF config

[Joonyoung Shim]

The exynos drm driver has DRIVER_PRIME capability, then it's reasonable
to support dmabuf as default. Remove DRM_EXYNOS_DMABUF config, it will
prevent that user selects the option unnecessarily.

Signed-off-by: Joonyoung Shim 
---
This patch can be conflicted below link patch of Marek to remove
selection of DRM_EXYNOS_IOMMU.

http://www.spinics.net/lists/linux-samsung-soc/msg41392.html

 drivers/gpu/drm/exynos/Kconfig | 6 --
 drivers/gpu/drm/exynos/Makefile| 3 +--
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.h | 5 -
 3 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9..c8385f7 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -18,12 +18,6 @@ config DRM_EXYNOS_IOMMU
help
  Choose this option if you want to use IOMMU feature for DRM.

-config DRM_EXYNOS_DMABUF
-   bool "EXYNOS DRM DMABUF"
-   depends on DRM_EXYNOS
-   help
- Choose this option if you want to use DMABUF feature for DRM.
-
 config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 33ae365..0856891 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -6,10 +6,9 @@ ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
 exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
-   exynos_drm_plane.o
+   exynos_drm_plane.o exynos_drm_dmabuf.o

 exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DPI) += exynos_drm_dpi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.h 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.h
index 49acfaf..886de9f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.h
@@ -12,14 +12,9 @@
 #ifndef _EXYNOS_DRM_DMABUF_H_
 #define _EXYNOS_DRM_DMABUF_H_

-#ifdef CONFIG_DRM_EXYNOS_DMABUF
 struct dma_buf *exynos_dmabuf_prime_export(struct drm_device *drm_dev,
struct drm_gem_object *obj, int flags);

 struct drm_gem_object *exynos_dmabuf_prime_import(struct drm_device *drm_dev,
struct dma_buf *dma_buf);
-#else
-#define exynos_dmabuf_prime_export NULL
-#define exynos_dmabuf_prime_import NULL
-#endif
 #endif
-- 
1.9.1

[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD

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

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

--- Comment #25 from Arthur Marsh  ---
Created attachment 112889
  --> https://bugs.freedesktop.org/attachment.cgi?id=112889=edit
2015012718dmesg.txt lock-up with first post 3.19.0-rc6 patches applied

The lock-up occurred within the first 20 seconds of playing the video, but
slightly later than with plain 3.19.0-rc6.

-- 
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/20150127/8bc96ff1/attachment.html>

[Bug 88717] [r300g] r300compiler error: Failed to translate rgb instruction - while running a game with gallium-nine

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

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

--- Comment #5 from Tom Stellard  ---
Can you send me before/after dumps of RADEON_DEBUG=fs,vs,ps from one of the
regressed games?

-- 
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/20150127/3792ad04/attachment.html>

[PATCH 2/2] drm: bridge/sti_dvo: Adapt to bridge API change

[Benjamin Gaignard]

Compare to Dave's patch this one doesn't take care of driver unbind
but that is a general issue I have to address in STI driver.
I would like to fix all unbind issues (hdmi, dvo, hda) in the same way
but it isn't link to this topic.

so you could my ack on this patch, up to me to fix unbind problems
with additionnal patches

2015-01-27 13:21 GMT+01:00 Fabio Estevam :
> Commit fbc4572e9c48e45b ("drm/bridge: make bridge registration independent of
> drm flow") introduced some drm/bridge API modifications. Make the necessary
> changes so that we can avoid the build breakage:
>
> drivers/gpu/drm/sti/sti_dvo.c: In function 'sti_dvo_brigde_destroy':
> drivers/gpu/drm/sti/sti_dvo.c:277:2: error: implicit declaration of function 
> 'drm_bridge_cleanup' [-Werror=implicit-function-declaration]
> drivers/gpu/drm/sti/sti_dvo.c: At top level:
> drivers/gpu/drm/sti/sti_dvo.c:287:2: error: unknown field ‘destroy’ 
> specified in initializer
> drivers/gpu/drm/sti/sti_dvo.c: In function 'sti_dvo_bind':
> drivers/gpu/drm/sti/sti_dvo.c:419:2: error: implicit declaration of function 
> 'drm_bridge_init' [-Werror=implicit-function-declaration]
>
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/gpu/drm/sti/sti_dvo.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
> index 651afad..1088fc5 100644
> --- a/drivers/gpu/drm/sti/sti_dvo.c
> +++ b/drivers/gpu/drm/sti/sti_dvo.c
> @@ -272,19 +272,12 @@ static void sti_dvo_bridge_nope(struct drm_bridge 
> *bridge)
> /* do nothing */
>  }
>
> -static void sti_dvo_brigde_destroy(struct drm_bridge *bridge)
> -{
> -   drm_bridge_cleanup(bridge);
> -   kfree(bridge);
> -}
> -
>  static const struct drm_bridge_funcs sti_dvo_bridge_funcs = {
> .pre_enable = sti_dvo_pre_enable,
> .enable = sti_dvo_bridge_nope,
> .disable = sti_dvo_disable,
> .post_disable = sti_dvo_bridge_nope,
> .mode_set = sti_dvo_set_mode,
> -   .destroy = sti_dvo_brigde_destroy,
>  };
>
>  static int sti_dvo_connector_get_modes(struct drm_connector *connector)
> @@ -416,7 +409,8 @@ static int sti_dvo_bind(struct device *dev, struct device 
> *master, void *data)
> return -ENOMEM;
>
> bridge->driver_private = dvo;
> -   drm_bridge_init(drm_dev, bridge, _dvo_bridge_funcs);
> +   bridge->funcs = _dvo_bridge_funcs;
> +   drm_bridge_attach(drm_dev, bridge);
>
> encoder->bridge = bridge;
> connector->encoder = encoder;
> @@ -446,7 +440,6 @@ static int sti_dvo_bind(struct device *dev, struct device 
> *master, void *data)
>  err_sysfs:
> drm_connector_unregister(drm_connector);
>  err_connector:
> -   drm_bridge_cleanup(bridge);
> drm_connector_cleanup(drm_connector);
> return -EINVAL;
>  }
> --
> 1.9.1
>



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[PATCH] drm: bridge/dw_hdmi: Fix return error path

[Philipp Zabel]

Hi Fabio,

Am Dienstag, den 27.01.2015, 10:54 -0200 schrieb Fabio Estevam:
> If devm_request_threaded_irq() fails we should jump to 'err_iahb' label that 
> will disable the clocks that were previously enabled.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/gpu/drm/bridge/dw_hdmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index ed3dfe7..cd6a706 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -1642,7 +1642,7 @@ int dw_hdmi_bind(struct device *dev, struct device 
> *master,
>   dw_hdmi_irq, IRQF_SHARED,
>   dev_name(dev), hdmi);
>   if (ret)
> - return ret;
> + goto err_iahb;
>  
>   /*
>* To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator

Thanks for the fix. I have applied this to my tree since I've introduced
the bug in there.

regards
Philipp

[PATCH v3] drm/dp: Use large transactions for I2C over AUX

[Simon Farnsworth]

DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in
their I2C over AUX implementation. They work fine with Windows, but fail
with Linux.

It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a zero
byte transfer ending the I2C transaction.

Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
reply, assume that there's a hardware bottleneck, and shrink our read size
to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
in the hopes that it'll be closest to what Windows does, as no sink I've
found actually gives short replies.

Also provide a module parameter for testing smaller transfer sizes, in case
there are sinks out there that cannot work with Windows.

Signed-off-by: Simon Farnsworth 
---

v3 changes, after feedback from Ville and more testing of Windows:

 * Change the short reply algorithm to match Ville's description of the
   DisplayPort 1.2 spec wording.

 * Add a module parameter to set the default transfer size for
   experiments. Requested over IRC by Ville.

No-one's been able to find a device that does short replies, but experiments
show that bigger reads are faster on most devices. Ville got:

 DP->DVI (OUI 001cf8):  40ms -> 35ms
 DP->VGA (OUI 0022b9):  45ms -> 38ms
 Zotac DP->2xHDMI:  25ms ->  4ms

v2 changes, after feedback from Thierry and Ville:

 * Handle short replies. I've decided (arbitrarily) that a short reply
   results in us dropping back to the newly chosen size for the rest of this
   I2C transaction. Thus, given an attempt to read the first 16 bytes of
   EDID, and a sink that only does 4 bytes of buffering, we will see the
   following AUX transfers for the EDID read (after address is set):

   
   Read 16 bytes from I2C over AUX.
   Reply with 4 bytes
   Read 4 bytes
   Reply with 4 bytes
   Read 4 bytes
   Reply with 4 bytes
   Read 4 bytes
   Reply with 4 bytes
   

Note that I've not looked at MST support - I have neither the DP 1.2 spec
nor any MST branch devices, so I can't test anything I write or check it
against a spec. It looks from the code, however, as if MST has the branch
device do the split from a big request into small transactions.

 drivers/gpu/drm/drm_dp_helper.c | 91 -
 include/drm/drm_dp_helper.h |  5 +++
 2 files changed, 77 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 79968e3..3db116c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -396,11 +396,13 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
*adapter)
  * retrying the transaction as appropriate.  It is assumed that the
  * aux->transfer function does not modify anything in the msg other than the
  * reply field.
+ *
+ * Returns bytes transferred on success, or a negative error code on failure.
  */
 static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
*msg)
 {
unsigned int retry;
-   int err;
+   int ret;

/*
 * DP1.2 sections 2.7.7.1.5.6.1 and 2.7.7.1.6.6.1: A DP Source device
@@ -409,14 +411,14 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)
 */
for (retry = 0; retry < 7; retry++) {
mutex_lock(>hw_mutex);
-   err = aux->transfer(aux, msg);
+   ret = aux->transfer(aux, msg);
mutex_unlock(>hw_mutex);
-   if (err < 0) {
-   if (err == -EBUSY)
+   if (ret < 0) {
+   if (ret == -EBUSY)
continue;

-   DRM_DEBUG_KMS("transaction failed: %d\n", err);
-   return err;
+   DRM_DEBUG_KMS("transaction failed: %d\n", ret);
+   return ret;
}


@@ -457,9 +459,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
 * Both native ACK and I2C ACK replies received. We
 * can assume the transfer was successful.
 */
-   if (err < msg->size)
-   return -EPROTO;
-   return 0;
+   return ret;

case DP_AUX_I2C_REPLY_NACK:
DRM_DEBUG_KMS("I2C nack\n");
@@ -482,14 +482,67 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)
return -EREMOTEIO;
 }

+/*
+ * Keep retrying drm_dp_i2c_do_msg until all data has been transferred.
+ *
+ * Returns an error code on failure, or a recommended transfer size on success.
+ */
+static int drm_dp_i2c_drain_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
*msg)
+{
+   int ret;
+   struct drm_dp_aux_msg drain_msg;
+   int drain_bytes;
+
+   ret = 

[PATCH] drm/dp: Use large transactions for I2C over AUX

[Ville Syrjälä]

On Mon, Jan 26, 2015 at 04:39:29PM +, Simon Farnsworth wrote:
> On Monday 26 January 2015 18:11:01 Ville Syrjälä wrote:
> > On Mon, Jan 26, 2015 at 03:47:13PM +, Simon Farnsworth wrote:
> > > On Monday 26 January 2015 17:33:35 Ville Syrjälä wrote:
> > > > On Mon, Jan 26, 2015 at 03:22:48PM +, Simon Farnsworth wrote:
> > > > > DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs 
> > > > > in
> > > > > their I2C over AUX implementation. They work fine with Windows, but 
> > > > > fail
> > > > > with Linux.
> > > > > 
> > > > > It turns out that they cannot keep an I2C transaction open unless the
> > > > > previous read was 16 bytes; shorter reads can only be followed by a 
> > > > > zero
> > > > > byte transfer ending the I2C transaction.
> > > > > 
> > > > > Copy Windows's behaviour, and read 16 bytes at a time. If we get a 
> > > > > short
> > > > > reply, assume that there's a hardware bottleneck, and shrink our read 
> > > > > size
> > > > > to match.
> > > > > 
> > > > > Signed-off-by: Simon Farnsworth 
> > > > > ---
> > > > > 
> > > > > v2 changes, after feedback from Thierry and Ville:
> > > > > 
> > > > >  * Handle short replies. I've decided (arbitrarily) that a short reply
> > > > >results in us dropping back to the newly chosen size for the rest 
> > > > > of this
> > > > >I2C transaction. Thus, given an attempt to read the first 16 bytes 
> > > > > of
> > > > >EDID, and a sink that only does 4 bytes of buffering, we will see 
> > > > > the
> > > > >following AUX transfers for the EDID read (after address is set):
> > > > > 
> > > > >
> > > > >Read 16 bytes from I2C over AUX.
> > > > >Reply with 4 bytes
> > > > >Read 4 bytes
> > > > >Reply with 4 bytes
> > > > >Read 4 bytes
> > > > >Reply with 4 bytes
> > > > >Read 4 bytes
> > > > >Reply with 4 bytes
> > > > >
> > > > 
> > > > I think that's agaisnt the spec. IIRC you have to keep repeating the
> > > > same transaction (meaning address/len are unchanged) until all the data
> > > > was transferred.
> > > >
> > > Do you have a spec reference against the DisplayPort 1.1a (last public
> > > version) spec? My chosen behaviour matches Table 2-50 in the 1.1a spec.
> > 
> > In my copy if DP v1.1 the example in 2-50 just keeps repeating w/ 16 bytes.
> > So doesn't match what you do. And that's unchanged in v1.2.
> >
> Yes, looks like I misread the table; I was more thinking about "what are the
> semantics of a 4 byte reply to a 16 byte read?" when I read that bit of the
> spec.
> 
> > DP v1.2 has some extra clarifications for this stuff:
> > "2.7.7 I2C-overAUX Transaction Clarifications and Implementation Rules
> > 
> >  2.7.7.1.6.4 Upon the Reply of I2C_ACK|AUX_ACK Followed by the Total Number 
> > of Data
> >  Bytes Fewer than LEN+1, to a Request Transaction with MOT Bit Set Either 
> > to 0 or 1
> > 
> >  The Source device must:
> >  o Repeat the identical I2C-read-over-AUX transaction with the updated
> >LEN value equal to the original LEN value minus the total number of data
> >bytes received so far,
> >  o Repeat the identical I2C-read-over-AUX transaction with the same LEN
> >value as the original value, or,
> >  o Issue an address-only I2C-over-AUX with MOT bit set to 0 to prompt I2C 
> > STOP
> >to terminate the current I2C-read-over-AUX transaction.
> >  It should be noted that when the Source device repeats the same 
> > I2C-read-over-AUX
> >  transaction with the same LEN value as the original value, the Sink device 
> > is
> >  likely to read more data bytes than the Source device needs."
> > 
> So what would be the best implementation strategy for Linux? Bear in mind
> that I don't have the 1.2 spec, nor do I have any devices which give a
> partial response to a 16 byte read, so I'm coding blind here, based solely
> on the information people are giving me.
> 
> The simplest strategy would be to keep repeating with 16 byte reads all the
> time, but Thierry's original comment and response to the first patch have
> suggested that that's a performance problem waiting to happen, hence the
> effort to find a better strategy.
> 
> My strategy was intended to spot that there's probably a FIFO in the middle
> that's too small, and reduce the transfer size to avoid overflowing the
> FIFO. I could make it more complex by remembering that the last read was a
> partial read, finishing it off by reducing the read size, then sticking to
> the new smaller size, but that's added complexity and I'm not sure of its
> value.
> 
> Should I simply stick to 16 byte reads, and cope with getting back less data
> than I want, or do you think we need the more complex strategy that complies
> with DP 1.2?

So I've been experimenting a bit with various dongles here, and sadly I've
not managed to get any one of them to return short reads :(

I did find one that allows changing the speed of the i2c bus, but even if
I reduce it to 1khz there are no short reads, just a 

[RFC v3 4/4] drm/i915: Enable DSI panel enable/disable based on PMIC

[Shobhit Kumar]

This allows for proper PPS during enable/disable of BYT-T platforms
where these signals are routed through PMIC. Needs DRM_PANEL to be
selected by default as well

v2: Adapt to panel find function name change in drm_panel

Signed-off-by: Shobhit Kumar 
---
 drivers/gpu/drm/i915/Kconfig   |  1 +
 drivers/gpu/drm/i915/intel-panel-crystalcove.c |  1 +
 drivers/gpu/drm/i915/intel_dsi.c   | 16 
 drivers/gpu/drm/i915/intel_dsi.h   |  6 ++
 4 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 0510ef0..bacbc06 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -18,6 +18,7 @@ config DRM_I915
select INPUT if ACPI
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
+   select DRM_PANEL
help
  Choose this option if you have a system that has "Intel Graphics
  Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/intel-panel-crystalcove.c 
b/drivers/gpu/drm/i915/intel-panel-crystalcove.c
index a6aefa3..0f129b2 100644
--- a/drivers/gpu/drm/i915/intel-panel-crystalcove.c
+++ b/drivers/gpu/drm/i915/intel-panel-crystalcove.c
@@ -154,6 +154,7 @@ static struct platform_driver crystalcove_panel_driver = {

 module_platform_driver(crystalcove_panel_driver);

+MODULE_ALIAS();
 MODULE_AUTHOR("Shobhit Kumar 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "i915_drv.h"
@@ -230,6 +231,8 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)

DRM_DEBUG_KMS("\n");

+   drm_panel_enable(intel_dsi->panel);
+
/* Disable DPOunit clock gating, can stall pipe
 * and we need DPLL REFA always enabled */
tmp = I915_READ(DPLL(pipe));
@@ -392,6 +395,8 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder)

msleep(intel_dsi->panel_off_delay);
msleep(intel_dsi->panel_pwr_cycle_delay);
+
+   drm_panel_disable(intel_dsi->panel);
 }

 static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
@@ -896,6 +901,17 @@ void intel_dsi_init(struct drm_device *dev)
fixed_mode->type |= DRM_MODE_TYPE_PREFERRED;
intel_panel_init(_connector->panel, fixed_mode, NULL);

+   /* Initialize the PMIC based drm_panel if available on the platform */
+   if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {
+   intel_dsi->panel = drm_find_panel_by_name("crystal_cove_panel");
+   if (!intel_dsi->panel) {
+   DRM_ERROR("PMIC Panel control will not work !!\n");
+   return;
+   }
+
+   drm_panel_attach(intel_dsi->panel, connector);
+   }
+
return;

 err:
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 8fe2064..4a9242d 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -33,6 +33,9 @@
 #define DSI_DUAL_LINK_FRONT_BACK   1
 #define DSI_DUAL_LINK_PIXEL_ALT2

+#define PPS_BLC_PMIC   0
+#define PPS_BLC_SOC1
+
 struct intel_dsi_device {
unsigned int panel_id;
const char *name;
@@ -83,6 +86,8 @@ struct intel_dsi {

struct intel_connector *attached_connector;

+   struct drm_panel *panel;
+
/* bit mask of ports being driven */
u16 ports;

@@ -116,6 +121,7 @@ struct intel_dsi {
u32 dphy_reg;
u32 video_frmt_cfg_bits;
u16 lp_byte_clk;
+   u8 pps_blc;

/* timeouts in byte clocks */
u16 lp_rx_timeout;
-- 
1.9.1

[RFC v3 3/4] drm/i915: Add new panel driver based on crystal cove pmic

[Shobhit Kumar]

This driver provides support for the "crystal_cove_panel" cell device.
On BYT-T pmic has to be used to enable/disable panel.

v2: Addressed Jani's comments
- Moved inside i915
- Correct licensing
- Remove unused stuff
- Do not initialize prepare/unprepare as they are not needed as of now
- Correct backlight off delay

Signed-off-by: Shobhit Kumar 
---
 drivers/gpu/drm/i915/Kconfig   |  12 ++
 drivers/gpu/drm/i915/Makefile  |   3 +
 drivers/gpu/drm/i915/intel-panel-crystalcove.c | 159 +
 3 files changed, 174 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/intel-panel-crystalcove.c

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 4e39ab3..0510ef0 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -69,3 +69,15 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
  option changes the default for that module option.

  If in doubt, say "N".
+
+config DRM_I915_PANEL_CRYSTALCOVE_PMIC
+   bool "Enable drm panel for crystal cove pmic based control"
+   depends on DRM_I915
+   depends on DRM_PANEL
+   default n
+   help
+ Choose this option if you have BYT-T based device with DSI panel. On
+ BYT-T there a crystal cove PMIC which controls the PANEL EN/DISABLE
+ signals.
+
+ If in doubt, say "N".
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1849ffa..cc2f10d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -88,4 +88,7 @@ i915-y += i915_dma.o \

 obj-$(CONFIG_DRM_I915)  += i915.o

+# I915 DRM Panels
+obj-$(CONFIG_DRM_I915_PANEL_CRYSTALCOVE_PMIC)  += intel-panel-crystalcove.o
+
 CFLAGS_i915_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/i915/intel-panel-crystalcove.c 
b/drivers/gpu/drm/i915/intel-panel-crystalcove.c
new file mode 100644
index 000..a6aefa3
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel-panel-crystalcove.c
@@ -0,0 +1,159 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shobhit Kumar 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PMIC_PANEL_EN  0x52
+#define PMIC_PWM_EN0x51
+#define PMIC_BKL_EN0x4B
+#define PMIC_PWM_LEVEL 0x4E
+
+struct crystalcove_panel {
+   struct drm_panel base;
+   bool enabled;
+
+   /* crystal cove pmic regmap */
+   struct regmap *regmap;
+};
+
+static inline struct crystalcove_panel *to_crystalcove_panel(struct drm_panel 
*panel)
+{
+   return container_of(panel, struct crystalcove_panel, base);
+}
+
+static int crystalcove_panel_disable(struct drm_panel *panel)
+{
+   struct crystalcove_panel *p = to_crystalcove_panel(panel);
+
+   if (!p->enabled)
+   return 0;
+
+   DRM_DEBUG_KMS("\n");
+
+   /* invoke the pmic driver */
+   regmap_write(p->regmap, PMIC_PANEL_EN, 0x00);
+
+   /* Disable backlight as well */
+   regmap_write(p->regmap, PMIC_PWM_LEVEL, 0);
+   msleep(20);
+   regmap_write(p->regmap, PMIC_PWM_EN, 0x00);
+   regmap_write(p->regmap, PMIC_BKL_EN, 0x7F);
+
+   p->enabled = false;
+
+   return 0;
+}
+
+static int crystalcove_panel_enable(struct drm_panel *panel)
+{
+   struct crystalcove_panel *p = to_crystalcove_panel(panel);
+
+   if (p->enabled)
+   return 0;
+
+   DRM_DEBUG_KMS("\n");
+
+   /* invoke the pmic driver */
+   regmap_write(p->regmap, PMIC_PANEL_EN, 0x01);
+
+   /* Enable BKL as well */
+   regmap_write(p->regmap, PMIC_BKL_EN, 0xFF);
+   regmap_write(p->regmap, PMIC_PWM_EN, 0x01);
+   msleep(20);
+   regmap_write(p->regmap, PMIC_PWM_LEVEL, 255);
+
+   p->enabled = true;
+
+   return 0;
+}
+
+static const struct drm_panel_funcs 

[RFC v3 2/4] mfd: Add a new cell device for panel controlled by crystal cove pmic

[Shobhit Kumar]

On BYT-T configuration, panel enable/disable signals are routed through
PMIC. Add a cell device for the same.

Signed-off-by: Shobhit Kumar 
---
 drivers/mfd/intel_soc_pmic_crc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
index c85e2ec..c8ccc24 100644
--- a/drivers/mfd/intel_soc_pmic_crc.c
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -109,6 +109,9 @@ static struct mfd_cell crystal_cove_dev[] = {
{
.name = "crystal_cove_pmic",
},
+   {
+   .name = "crystal_cove_panel",
+   },
 };

 static struct regmap_config crystal_cove_regmap_config = {
-- 
1.9.1

[RFC v3 1/4] drm: Add support to find drm_panel by name

[Shobhit Kumar]

For scenarios where OF is not available, we can use panel identification by
name.

Signed-off-by: Shobhit Kumar 
---
 drivers/gpu/drm/drm_panel.c | 18 ++
 include/drm/drm_panel.h |  3 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e..e1cb8cf 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -95,6 +95,24 @@ struct drm_panel *of_drm_find_panel(struct device_node *np)
 EXPORT_SYMBOL(of_drm_find_panel);
 #endif

+struct drm_panel *drm_find_panel_by_name(const char *name)
+{
+   struct drm_panel *panel;
+
+   mutex_lock(_lock);
+
+   list_for_each_entry(panel, _list, list) {
+   if (strcmp(panel->name, name) == 0) {
+   mutex_unlock(_lock);
+   return panel;
+   }
+   }
+
+   mutex_unlock(_lock);
+   return NULL;
+}
+EXPORT_SYMBOL(drm_find_panel_by_name);
+
 MODULE_AUTHOR("Thierry Reding ");
 MODULE_DESCRIPTION("DRM panel infrastructure");
 MODULE_LICENSE("GPL and additional rights");
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 1fbcc96..1ef9ff3 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -74,6 +74,7 @@ struct drm_panel {
struct drm_device *drm;
struct drm_connector *connector;
struct device *dev;
+   char name[NAME_MAX];

const struct drm_panel_funcs *funcs;

@@ -137,4 +138,6 @@ static inline struct drm_panel *of_drm_find_panel(struct 
device_node *np)
 }
 #endif

+struct drm_panel *drm_find_panel_by_name(const char *name);
+
 #endif
-- 
1.9.1

[RFC v3 0/4] Crystal Cove PMIC based Panel and Backlight Control

[Shobhit Kumar]

Hi All
Please find modifed set of patches using regmap interface to accedd the PMIC 
registers. These patches implement a drm_panel as a platform driver for the
mfd_cell device declared in intel_soc_pmic_core.c. 

DRM is extended to provide a find panel by name in absence of OF. 

Backlight control is pending. For now I am doing Backlight Enable/Disable also
during panel/enable as this will at least save power.

Regards
Shobhit

Shobhit Kumar (4):
  drm: Add support to find drm_panel by name
  mfd: Add a new cell device for panel controlled by crystal cove pmic
  drm/i915: Add new panel driver based on crystal cove pmic
  drm/i915: Enable DSI panel enable/disable based on PMIC

 drivers/gpu/drm/drm_panel.c|  18 +++
 drivers/gpu/drm/i915/Kconfig   |  13 ++
 drivers/gpu/drm/i915/Makefile  |   3 +
 drivers/gpu/drm/i915/intel-panel-crystalcove.c | 160 +
 drivers/gpu/drm/i915/intel_dsi.c   |  16 +++
 drivers/gpu/drm/i915/intel_dsi.h   |   6 +
 drivers/mfd/intel_soc_pmic_crc.c   |   3 +
 include/drm/drm_panel.h|   3 +
 8 files changed, 222 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/intel-panel-crystalcove.c

-- 
1.9.1

[Bug 88408] Black screen in Nuclear Dawn

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

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

--- Comment #20 from commiethebeastie at gmail.com ---
Created attachment 112885
  --> https://bugs.freedesktop.org/attachment.cgi?id=112885=edit
llvm-3.6-rc1

-- 
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/20150127/61fd044c/attachment-0001.html>

[Bug 88408] Black screen in Nuclear Dawn

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

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

--- Comment #19 from commiethebeastie at gmail.com ---
Created attachment 112884
  --> https://bugs.freedesktop.org/attachment.cgi?id=112884=edit
llvm-3.5

-- 
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/20150127/b9066305/attachment.html>

[PATCH 2/6] drm/exynos: track vblank events on a per crtc basis

[Daniel Vetter]

On Tue, Jan 27, 2015 at 12:59:15PM +, Daniel Stone wrote:
> Hi,
> 
> On 23 January 2015 at 12:42, Gustavo Padovan  wrote:
> >  void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe)
> >  {
> > struct exynos_drm_private *dev_priv = dev->dev_private;
> > -   struct drm_pending_vblank_event *e, *t;
> > struct drm_crtc *drm_crtc = dev_priv->crtc[pipe];
> > struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
> > -   unsigned long flags;
> >
> > -   spin_lock_irqsave(>event_lock, flags);
> > +   if (exynos_crtc->event) {
> >
> > -   list_for_each_entry_safe(e, t, _priv->pageflip_event_list,
> > -   base.link) {
> > -   /* if event's pipe isn't same as crtc then ignore it. */
> > -   if (pipe != e->pipe)
> > -   continue;
> > -
> > -   list_del(>base.link);
> > -   drm_send_vblank_event(dev, -1, e);
> > +   spin_lock_irq(>event_lock);
> > +   drm_send_vblank_event(dev, -1, exynos_crtc->event);
> > drm_vblank_put(dev, pipe);
> > -   atomic_set(_crtc->pending_flip, 0);
> > wake_up(_crtc->pending_flip_queue);
> > -   }
> > +   spin_unlock_irq(>event_lock);
> >
> > -   spin_unlock_irqrestore(>event_lock, flags);
> > +   exynos_crtc->event = NULL;
> > +   }
> >  }
> 
> Doesn't this need to hold the CRTC lock to not race with, e.g, the
> page_flip caller? This gets called from IRQ context though, so might
> need conversion to soft-IRQ to do so, or another per-CRTC spinlock
> just to protect the event.

dev->even_lock should be enough, but I suspect that lock also protects
exynos_crtc->event (at least that's the case in i915.ko). So would need to
be moved out of the if block again.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.

At each attach, the constraints are calculated based on the following:
- max_segment_size, max_segment_count, segment_boundary_mask from
   device_dma_parameters.

In case the attaching device's constraints don't match up, attach() fails.

At detach, the constraints are recalculated based on the remaining
attached devices.

Two helpers are added:
- dma_buf_get_constraints - which gives the current constraints as calculated
  during each attach on the buffer till the time,
- dma_buf_recalc_constraints - which recalculates the constraints for all
  currently attached devices for the 'paranoid' ones amongst us.

The idea of this patch is largely taken from Rob Clark's RFC at
https://lkml.org/lkml/2012/7/19/285, and the comments received on it.

Cc: Rob Clark 
Signed-off-by: Sumit Semwal 
---
v3: 
- Thanks to Russell's comment, remove dma_mask and coherent_dma_mask from
  constraints' calculation; has a nice side effect of letting us use
  device_dma_parameters directly to list constraints.
- update the debugfs output to show constraint info as well.

v2: split constraints-sharing and allocation helpers

 drivers/dma-buf/dma-buf.c | 126 +-
 include/linux/dma-buf.h   |   7 +++
 2 files changed, 132 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..f363f1440803 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -264,6 +264,66 @@ static inline int is_dma_buf_file(struct file *file)
return file->f_op == _buf_fops;
 }

+static inline void init_constraints(struct device_dma_parameters *cons)
+{
+   cons->max_segment_count = (unsigned int)-1;
+   cons->max_segment_size = (unsigned int)-1;
+   cons->segment_boundary_mask = (unsigned long)-1;
+}
+
+/*
+ * calc_constraints - calculates if the new attaching device's constraints
+ * match, with the constraints of already attached devices; if yes, returns
+ * the constraints; else return ERR_PTR(-EINVAL)
+ */
+static int calc_constraints(struct device *dev,
+   struct device_dma_parameters *calc_cons)
+{
+   struct device_dma_parameters cons = *calc_cons;
+
+   cons.max_segment_count = min(cons.max_segment_count,
+   dma_get_max_seg_count(dev));
+   cons.max_segment_size = min(cons.max_segment_size,
+   dma_get_max_seg_size(dev));
+   cons.segment_boundary_mask &= dma_get_seg_boundary(dev);
+
+   if (!cons.max_segment_count ||
+   !cons.max_segment_size ||
+   !cons.segment_boundary_mask) {
+   pr_err("Dev: %s's constraints don't match\n", dev_name(dev));
+   return -EINVAL;
+   }
+
+   *calc_cons = cons;
+
+   return 0;
+}
+
+/*
+ * recalc_constraints - recalculates constraints for all attached devices;
+ *  useful for detach() recalculation, and for dma_buf_recalc_constraints()
+ *  helper.
+ *  Returns recalculated constraints in recalc_cons, or error in the unlikely
+ *  case when constraints of attached devices might have changed.
+ */
+static int recalc_constraints(struct dma_buf *dmabuf,
+ struct device_dma_parameters *recalc_cons)
+{
+   struct device_dma_parameters calc_cons;
+   struct dma_buf_attachment *attach;
+   int ret = 0;
+
+   init_constraints(_cons);
+
+   list_for_each_entry(attach, >attachments, node) {
+   ret = calc_constraints(attach->dev, _cons);
+   if (ret)
+   return ret;
+   }
+   *recalc_cons = calc_cons;
+   return 0;
+}
+
 /**
  * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
  * with this buffer, so it can be exported.
@@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
dmabuf->ops = ops;
dmabuf->size = size;
dmabuf->exp_name = exp_name;
+
+   init_constraints(>constraints);
+
init_waitqueue_head(>poll);
dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = >poll;
dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
@@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,
  struct device *dev)
 {
struct dma_buf_attachment *attach;
-   int ret;
+   int ret = 0;

if (WARN_ON(!dmabuf || !dev))
return ERR_PTR(-EINVAL);
@@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
*dmabuf,

mutex_lock(>lock);

+   if (calc_constraints(dev, >constraints))
+   goto err_constraints;
+
if (dmabuf->ops->attach) {
ret = dmabuf->ops->attach(dmabuf, dev, attach);
if (ret)
@@ -448,6 +514,7 @@ struct dma_buf_attachment 

[RFCv3 1/2] device: add dma_params->max_segment_count

[Sumit Semwal]

From: Rob Clark 

For devices which have constraints about maximum number of segments in
an sglist.  For example, a device which could only deal with contiguous
buffers would set max_segment_count to 1.

The initial motivation is for devices sharing buffers via dma-buf,
to allow the buffer exporter to know the constraints of other
devices which have attached to the buffer.  The dma_mask and fields
in 'struct device_dma_parameters' tell the exporter everything else
that is needed, except whether the importer has constraints about
maximum number of segments.

Signed-off-by: Rob Clark 
 [sumits: Minor updates wrt comments]
Signed-off-by: Sumit Semwal 
---

v3: include Robin Murphy's fix[1] for handling '0' as a value for
 max_segment_count
v2: minor updates wrt comments on the first version

[1]: http://article.gmane.org/gmane.linux.kernel.iommu/8175/

 include/linux/device.h  |  1 +
 include/linux/dma-mapping.h | 19 +++
 2 files changed, 20 insertions(+)

diff --git a/include/linux/device.h b/include/linux/device.h
index fb506738f7b7..a32f9b67315c 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -647,6 +647,7 @@ struct device_dma_parameters {
 * sg limitations.
 */
unsigned int max_segment_size;
+   unsigned int max_segment_count;/* INT_MAX for unlimited */
unsigned long segment_boundary_mask;
 };

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c3007cb4bfa6..d3351a36d5ec 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct 
device *dev,
return -EIO;
 }

+#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
+
+static inline unsigned int dma_get_max_seg_count(struct device *dev)
+{
+   if (dev->dma_parms && dev->dma_parms->max_segment_count)
+   return dev->dma_parms->max_segment_count;
+   return DMA_SEGMENTS_MAX_SEG_COUNT;
+}
+
+static inline int dma_set_max_seg_count(struct device *dev,
+   unsigned int count)
+{
+   if (dev->dma_parms) {
+   dev->dma_parms->max_segment_count = count;
+   return 0;
+   }
+   return -EIO;
+}
+
 static inline unsigned long dma_get_seg_boundary(struct device *dev)
 {
return dev->dma_parms ?
-- 
1.9.1

[PATCH 2/6] drm/exynos: track vblank events on a per crtc basis

[Daniel Stone]

Hi,

On 23 January 2015 at 12:42, Gustavo Padovan  wrote:
>  void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe)
>  {
> struct exynos_drm_private *dev_priv = dev->dev_private;
> -   struct drm_pending_vblank_event *e, *t;
> struct drm_crtc *drm_crtc = dev_priv->crtc[pipe];
> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
> -   unsigned long flags;
>
> -   spin_lock_irqsave(>event_lock, flags);
> +   if (exynos_crtc->event) {
>
> -   list_for_each_entry_safe(e, t, _priv->pageflip_event_list,
> -   base.link) {
> -   /* if event's pipe isn't same as crtc then ignore it. */
> -   if (pipe != e->pipe)
> -   continue;
> -
> -   list_del(>base.link);
> -   drm_send_vblank_event(dev, -1, e);
> +   spin_lock_irq(>event_lock);
> +   drm_send_vblank_event(dev, -1, exynos_crtc->event);
> drm_vblank_put(dev, pipe);
> -   atomic_set(_crtc->pending_flip, 0);
> wake_up(_crtc->pending_flip_queue);
> -   }
> +   spin_unlock_irq(>event_lock);
>
> -   spin_unlock_irqrestore(>event_lock, flags);
> +   exynos_crtc->event = NULL;
> +   }
>  }

Doesn't this need to hold the CRTC lock to not race with, e.g, the
page_flip caller? This gets called from IRQ context though, so might
need conversion to soft-IRQ to do so, or another per-CRTC spinlock
just to protect the event.

Cheers,
Daniel

[RFCv2 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Sumit Semwal]

Hi Russell!

On 21 January 2015 at 23:01, Russell King - ARM Linux
 wrote:
> On Wed, Jan 21, 2015 at 09:46:47AM +0530, Sumit Semwal wrote:
>> +static int calc_constraints(struct device *dev,
>> + struct dma_buf_constraints *calc_cons)
>> +{
>> + struct dma_buf_constraints cons = *calc_cons;
>> +
>> + cons.dma_mask &= dma_get_mask(dev);
>
> I don't think this makes much sense when you consider that the DMA
> infrastructure supports buses with offsets.  The DMA mask is th
> upper limit of the _bus_ specific address, it is not a mask per-se.
>
> What this means is that &= is not the right operation.  Moreover,
> simply comparing masks which could be from devices on unrelated
> buses doesn't make sense either.
>
> However, that said, I don't have an answer for what you want to
> achieve here.

Thanks for your comments! I suppose in that case, I will leave out the
*dma_masks from this constraints information for now; we can re-visit
it when a specific use case really needs information about the
dma-masks of the attached devices.

I will post an updated patch-set soon.
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.



-- 
Thanks and regards,

Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs

LLVM / Clang git for libclc: optimized build or debug?

[Michel Dänzer]

On 27.01.2015 04:20, Dieter Nützel wrote:
> make[1]: Leaving directory '/opt/llvm/bindings'
> llvm[0]: * Completed Debug+Asserts Build
> llvm[0]: * Note: Debug build can be 10 times slower than an
> llvm[0]: * optimized build. Use make ENABLE_OPTIMIZED=1 to
> llvm[0]: * make an optimized build. Alternatively you can
> llvm[0]: * configure with --enable-optimized.
> 304.322u 15.792s 1:50.25 290.3% 0+0k 6156432+1518784io 942pf+0w

FWIW, I use these debug vs. optimization related options for building LLVM:

'--enable-optimized' '--with-optimize-option=-O2  -ftree-vectorize
-march=amdfam10 -mtune=native' '--enable-assertions'
'--enable-debug-runtime' '--enable-debug-symbols'
'CPPFLAGS=-fno-omit-frame-pointer' 'CFLAGS=-fno-omit-frame-pointer'
'CXXFLAGS=-fno-omit-frame-pointer'

That gives good performance while preserving assertions and debugging
symbols. -march=amdfam10 (as opposed to -march=native or a newer AMD CPU
family) avoids generating machine code which valgrind can't handle, and
-fno-omit-frame-pointer allows profile call graphs to make sense.


> Second:
> 'make -j 4' do NOT work in the first run. --- Known?

Not to me.


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

[PULL] topic/atomic-core

[Daniel Vetter]

Hi Dave,

Mostly just small fixes and polish all over, plus the dpms-on-atomic
stuff.

Cheers, Daniel


The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470:

  Merge remote-tracking branch 'origin/master' into drm-next (2015-01-22 
10:44:41 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/atomic-core-2015-01-27

for you to fetch changes up to 9469244d869623e8b54d9f3d4d00737e377af273:

  drm/atomic: Fix potential use of state after free (2015-01-27 10:02:52 +0100)


Ander Conselvan de Oliveira (1):
  drm/atomic: Fix potential use of state after free

Daniel Vetter (6):
  drm: Add standardized boolean props
  drm/atomic: Add drm_crtc_state->active
  drm/atomic-helper: add connector->dpms() implementation
  drm/atomic-helpers: Recover full cursor plane behaviour
  drm/atomic-helpers: Saner encoder/crtc callbacks
  drm/atomic-helper: debug output for modesets

Matt Roper (2):
  drm/plane-helper: Skip prepare_fb/cleanup_fb when newfb==oldfb
  drm/plane-helper: Fix transitional helper kerneldocs

 drivers/gpu/drm/drm_atomic.c|  21 -
 drivers/gpu/drm/drm_atomic_helper.c | 181 +---
 drivers/gpu/drm/drm_crtc.c  |  76 ++-
 drivers/gpu/drm/drm_plane_helper.c  |  14 ++-
 include/drm/drm_atomic_helper.h |   2 +
 include/drm/drm_crtc.h  |   7 ++
 include/drm/drm_crtc_helper.h   |  20 +++-
 7 files changed, 300 insertions(+), 21 deletions(-)

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

[PATCH] drm/msm/mdp5: only flush on a CRTC ->atomic_flush()

[Stephane Viau]

MDP5 hardware has some limitation and requires to avoid flushing
registers more than once between two Vblanks.

This change removes all FLUSH operations (except for HW cursor)
beside the one coming from a CRTC's ->atomic_flush().

This avoid this type of behavior (eg: CRTC + 1 plane overlay):

[drm:mdp5_crtc_vblank_irq] vblank
[drm:mdp5_ctl_commit] flush (20048)   CTL + LM0 + RGB0
[drm:mdp5_ctl_commit] flush (20040)   CTL + LM0
[drm:mdp5_crtc_vblank_irq] blank
[drm:mdp5_ctl_commit] flush (20049)   CTL + LM0 + RGB0 + VIG0
[drm:mdp5_crtc_vblank_irq] blank

and replaces it by:

[drm:mdp5_crtc_vblank_irq] vblank
[drm:mdp5_ctl_commit] flush (20048)   CTL + LM0 + RGB0
[drm:mdp5_crtc_vblank_irq] blank
[drm:mdp5_ctl_commit] flush (20049)   CTL + LM0 + RGB0 + VIG0
[drm:mdp5_crtc_vblank_irq] blank

Only *one* FLUSH is called between Vblanks interrupts.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 10f93cf..f455f38 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -297,7 +297,7 @@ static void mdp5_crtc_commit(struct drm_crtc *crtc)
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
DBG("%s", mdp5_crtc->name);
mdp5_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
-   crtc_flush_all(crtc);
+
/* drop the ref to mdp clk's that we got in prepare: */
mdp5_disable(get_kms(crtc));
 }
@@ -600,7 +600,6 @@ void mdp5_crtc_set_intf(struct drm_crtc *crtc, int intf,
 {
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
struct mdp5_kms *mdp5_kms = get_kms(crtc);
-   uint32_t flush_mask = 0;
uint32_t intf_sel;
unsigned long flags;

@@ -639,10 +638,6 @@ void mdp5_crtc_set_intf(struct drm_crtc *crtc, int intf,

DBG("%s: intf_sel=%08x", mdp5_crtc->name, intf_sel);
mdp5_ctl_set_intf(mdp5_crtc->ctl, intf);
-   flush_mask |= mdp5_ctl_get_flush(mdp5_crtc->ctl);
-   flush_mask |= mdp5_lm_get_flush(mdp5_crtc->lm);
-
-   crtc_flush(crtc, flush_mask);
 }

 int mdp5_crtc_get_lm(struct drm_crtc *crtc)
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

[Bug 86043] Optimus issue with libdrm 2.4.58

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

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

--- Comment #4 from Niek Bergman  ---
Can confirm this issue locally on my current system.

Running Steam through the "primusrun" Bumblebee wrapper to start games on the
nVidia card leads to the following error after starting a game:

malloc: unknown:0: assertion botched
free: called with unallocated block argument
last command: (null)
Aborting...Aborted (core dumped)

I can also confirm that downgrading libdrm-intel1 to 2.4.56 fixes the issue and
allows the game to run on the nVidia card just fine. Furthermore, starting
Steam without "primusrun" (thereby causing the game to start on the Intel card)
also does not cause this issue.

Should any testing be desired, I'd be happy to oblige.

-- 
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/20150127/ceacf669/attachment.html>

[PATCH 2/2] drm/exynos: remove to use unnecessary MODULE_xxx macro

[Gustavo Padovan]

2015-01-27 Joonyoung Shim :

> The exynos_drm_dmabuf.c file doesn't include any module feature and it
> isn't built to module.
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 4 
>  1 file changed, 4 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_DMABUF config

[Gustavo Padovan]

2015-01-27 Joonyoung Shim :

> The exynos drm driver has DRIVER_PRIME capability, then it's reasonable
> to support dmabuf as default. Remove DRM_EXYNOS_DMABUF config, it will
> prevent that user selects the option unnecessarily.
> 
> Signed-off-by: Joonyoung Shim 
> ---
> This patch can be conflicted below link patch of Marek to remove
> selection of DRM_EXYNOS_IOMMU.
> 
> http://www.spinics.net/lists/linux-samsung-soc/msg41392.html
> 
>  drivers/gpu/drm/exynos/Kconfig | 6 --
>  drivers/gpu/drm/exynos/Makefile| 3 +--
>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.h | 5 -
>  3 files changed, 1 insertion(+), 13 deletions(-)

Reviewed-by: Gustavo Padovan 

Gustavo

[PATCH] drm: bridge/dw_hdmi: Fix return error path

[Fabio Estevam]

If devm_request_threaded_irq() fails we should jump to 'err_iahb' label that 
will disable the clocks that were previously enabled.

Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index ed3dfe7..cd6a706 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1642,7 +1642,7 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
dw_hdmi_irq, IRQF_SHARED,
dev_name(dev), hdmi);
if (ret)
-   return ret;
+   goto err_iahb;

/*
 * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
-- 
1.9.1

[PATCH v3] drm/panel: add s6e3ha2 AMOLED panel driver

[Hyungwon Hwang]

From: Donghwa Lee 

This patch adds MIPI-DSI based S6E3HA2 panel driver. This panel has
1440x2560 resolution in 5.7-inch physical panel.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Cc: Inki Dae 
Cc: Sangbae Lee 
---
Changes for v2:
- Fix errata in documentation and source code comments
Changes for v3:
- Remove the term LCD to clarify the sort of this panel
- Rename lcd-en-gpios to panel-en-gpios to clarify the sort of this panel
- Fix errata in documentation and source code comments
 .../devicetree/bindings/panel/samsung,s6e3ha2.txt  |  49 ++
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-s6e3ha2.c  | 513 +
 4 files changed, 569 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-s6e3ha2.c

diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3ha2.txt 
b/Documentation/devicetree/bindings/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..5210926
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,49 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: core voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin
+  - panel-en-gpios: a GPIO spec for the panel enable pin
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal gpio 
pin
+
+Optional properties:
+  - display-timings: timings for the connected panel as described by [1]
+  - panel-width-mm: physical panel width [mm]
+  - panel-height-mm: physical panel height [mm]
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+panel at 0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 0>;
+   panel-en-gpios = < 5 0>;
+   te-gpios = < 3 1>;
+   panel-width-mm = <71>;
+   panel-height-mm = <125>;
+
+   display-timings {
+   timing-0 {
+   clock-frequency = <0>;
+   hactive = <1440>;
+   vactive = <2560>;
+   hfront-porch = <1>;
+   hback-porch = <1>;
+   hsync-len = <1>;
+   vfront-porch = <1>;
+   vback-porch = <15>;
+   vsync-len = <1>;
+   };
+   };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index dec60b2..451b5f3 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -46,4 +46,10 @@ config DRM_PANEL_S6E63J0X03
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS

+config DRM_PANEL_S6E3HA2
+   tristate "S6E3HA2 DSI video mode panel"
+   depends on OF
+   select DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 6467be7..7bd7b84 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
 obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_S6E63J0X03) += panel-s6e63j0x03.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
+obj-$(CONFIG_DRM_PANEL_S6E3HA2) += panel-s6e3ha2.o
diff --git a/drivers/gpu/drm/panel/panel-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-s6e3ha2.c
new file mode 100644
index 000..af22bdc
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3ha2.c
@@ -0,0 +1,513 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Donghwa Lee 
+ *
+ * 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 
+#include 
+#include 
+
+struct s6e3ha2 {
+   struct device *dev;
+   struct drm_panel panel;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *panel_en_gpio;
+   struct videomode vm;
+   u32 width_mm;
+   u32 height_mm;
+
+   /* This field is tested by functions directly accessing DSI bus before
+* transfer, transfer is skipped if it is set. In case of transfer
+ 

[Bug 88183] radeonsi: R9 280X hangs with SuperTuxKart

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

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

--- Comment #26 from smoki  ---
(In reply to Michel Dänzer from comment #25)
> Note that I'm referring specifically to the VM faults triggered by your
> apitrace from comment 5.

 I can't even start that one, it just throw this:

0 6 glXCreateWindow(dpy = 0x1fd84a0, config = 0x2060a80, win = 58720258,
attribList = {}) = 58720259
6: warning: unsupported glXCreateWindow call
X Error of failed request:  GLXBadFBConfig
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  34 ()
  Serial number of failed request:  22
  Current serial number in output stream:  20

 Probably shipped gcc libs 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/20150127/2eab80f1/attachment.html>

[Intel-gfx] [PATCH] drivers: gpu: drm: i915: intel_fifo_underrun.c: Fix a typo in comment

[Daniel Vetter]

On Tue, Jan 27, 2015 at 09:56:49AM +0200, Jani Nikula wrote:
> On Mon, 26 Jan 2015, Kumar Amit Mehta  wrote:
> > The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent
> > with the code and the rest of the comment for this routine. This patch
> > fixes this typo in comment.
> >
> > Signed-off-by: Kumar Amit Mehta 
> 
> Reviewed-by: Jani Nikula 

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

[Bug 64867] Hangs on Cayman (HD6950) when watching flash/using vdpau

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

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

Dave Airlie  changed:

   What|Removed |Added

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

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

[GIT PULL] drm/tegra: Changes for v3.20-rc1

[Thierry Reding]

Hi Dave,

The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470:

  Merge remote-tracking branch 'origin/master' into drm-next (2015-01-22 
10:44:41 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-3.20-rc1

for you to fetch changes up to 31f40f86526b71009973854c1dfe799ee70f7588:

  drm/tegra: Use correct relocation target offsets (2015-01-27 10:14:59 +0100)

This is essentially the same as the pull request that I sent out earlier
but with a fix for building the host1x and tegra-drm drivers as modules
squashed in.

Thanks,
Thierry


drm/tegra: Changes for v3.20-rc1

The biggest part of these changes is the conversion to atomic mode-
setting. A lot of cleanup and demidlayering was required before the
conversion, with the result being a whole lot of changes.

Besides the atomic mode-setting support, the host1x bus now has the
proper infrastructure to support suspend/resume for child devices.

Finally, a couple of smaller cleanup patches round things off.


Dan Carpenter (3):
  drm/tegra: Check for NULL pointer instead of IS_ERR()
  drm/tegra: dc: Fix bad irqsave/restore in tegra_dc_finish_page_flip()
  drm/tegra: gem: oops in error handling

David Ung (2):
  drm/tegra: dsi: Adjust D-PHY timing
  drm/tegra: Use correct relocation target offsets

Thierry Reding (49):
  gpu: host1x: Call ->remove() only when a device is bound
  gpu: host1x: Call host1x_device_add() under lock
  gpu: host1x: Factor out __host1x_device_del()
  gpu: host1x: Provide a proper struct bus_type
  drm/tegra: gem: Use iommu_map_sg()
  drm/tegra: Remove redundant zeroing out of memory
  drm/tegra: plane: Use proper possible_crtcs mask
  drm/tegra: dc: Initialize border color
  drm/tegra: dc: Describe register copies
  drm/tegra: dc: Return planar flag for non-YUV modes
  drm/tegra: hdmi: Registers are 32-bit
  drm/tegra: dsi: Registers are 32-bit
  drm/tegra: dsi: Soft-reset controller on ->disable
  drm/tegra: dsi: Reset across ->exit()/->init()
  drm/plane: Make ->atomic_update() mandatory
  drm/plane: Add optional ->atomic_disable() callback
  drm/atomic: Add ->atomic_check() to encoder helpers
  drm/tegra: Use tegra_commit_dc() in output drivers
  drm/tegra: Stop CRTC at CRTC disable time
  drm/tegra: dc: Wait for idle when disabled
  drm/tegra: Move tegra_drm_mode_funcs to the core
  drm/tegra: dc: No longer disable planes at CRTC disable
  drm/tegra: Convert output midlayer to helpers
  drm/tegra: output: Make ->setup_clock() optional
  drm/tegra: Add tegra_dc_setup_clock() helper
  drm/tegra: rgb: Demidlayer
  drm/tegra: hdmi: Demidlayer
  drm/tegra: dsi: Demidlayer
  drm/tegra: sor: Demidlayer
  drm/tegra: debugfs cleanup cannot fail
  drm/tegra: Remove remnants of the output midlayer
  drm/tegra: Output cleanup functions cannot fail
  drm/tegra: dc: Do not needlessly deassert reset
  drm/tegra: Atomic conversion, phase 1
  drm/tegra: Atomic conversion, phase 2
  drm/tegra: Atomic conversion, phase 3, step 1
  drm/tegra: dc: Store clock setup in atomic state
  drm/tegra: rgb: Implement ->atomic_check()
  drm/tegra: dsi: Implement ->atomic_check()
  drm/tegra: hdmi: Implement ->atomic_check()
  drm/tegra: sor: Implement ->atomic_check()
  drm/tegra: dc: Use atomic clock state in modeset
  drm/tegra: Atomic conversion, phase 3, step 2
  drm/tegra: Atomic conversion, phase 3, step 3
  drm/tegra: Remove unused ->mode_fixup() callbacks
  drm/tegra: Track active planes in CRTC state
  drm/tegra: Track tiling and format in plane state
  drm/tegra: dc: Unify enabling the display controller
  drm/tegra: Add minimal power management

 drivers/gpu/Makefile|5 +-
 drivers/gpu/drm/drm_atomic_helper.c |   34 +-
 drivers/gpu/drm/drm_plane_helper.c  |   10 +-
 drivers/gpu/drm/tegra/dc.c  |  955 ++
 drivers/gpu/drm/tegra/drm.c |  140 -
 drivers/gpu/drm/tegra/drm.h |   91 +--
 drivers/gpu/drm/tegra/dsi.c |  578 ++
 drivers/gpu/drm/tegra/fb.c  |   25 +-
 drivers/gpu/drm/tegra/gem.c |   39 +-
 drivers/gpu/drm/tegra/hdmi.c|  327 +--
 drivers/gpu/drm/tegra/mipi-phy.c|   25 +-
 drivers/gpu/drm/tegra/output.c  |  168 +-
 drivers/gpu/drm/tegra/rgb.c |  218 +++
 drivers/gpu/drm/tegra/sor.c | 1105 ++-
 drivers/gpu/host1x/bus.c|  201 ---
 drivers/gpu/host1x/bus.h|4 +-
 drivers/gpu/host1x/dev.c|6 +-
 include/drm/drm_atomic_helper.h |   37 ++
 include/drm/drm_crtc_helper.h   |6 +
 

[PATCH 2/2] drm: bridge/sti_dvo: Adapt to bridge API change

[Fabio Estevam]

Commit fbc4572e9c48e45b ("drm/bridge: make bridge registration independent of
drm flow") introduced some drm/bridge API modifications. Make the necessary
changes so that we can avoid the build breakage:

drivers/gpu/drm/sti/sti_dvo.c: In function 'sti_dvo_brigde_destroy':
drivers/gpu/drm/sti/sti_dvo.c:277:2: error: implicit declaration of function 
'drm_bridge_cleanup' [-Werror=implicit-function-declaration]
drivers/gpu/drm/sti/sti_dvo.c: At top level:
drivers/gpu/drm/sti/sti_dvo.c:287:2: error: unknown field ‘destroy’ 
specified in initializer
drivers/gpu/drm/sti/sti_dvo.c: In function 'sti_dvo_bind':
drivers/gpu/drm/sti/sti_dvo.c:419:2: error: implicit declaration of function 
'drm_bridge_init' [-Werror=implicit-function-declaration]

Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/sti/sti_dvo.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 651afad..1088fc5 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -272,19 +272,12 @@ static void sti_dvo_bridge_nope(struct drm_bridge *bridge)
/* do nothing */
 }

-static void sti_dvo_brigde_destroy(struct drm_bridge *bridge)
-{
-   drm_bridge_cleanup(bridge);
-   kfree(bridge);
-}
-
 static const struct drm_bridge_funcs sti_dvo_bridge_funcs = {
.pre_enable = sti_dvo_pre_enable,
.enable = sti_dvo_bridge_nope,
.disable = sti_dvo_disable,
.post_disable = sti_dvo_bridge_nope,
.mode_set = sti_dvo_set_mode,
-   .destroy = sti_dvo_brigde_destroy,
 };

 static int sti_dvo_connector_get_modes(struct drm_connector *connector)
@@ -416,7 +409,8 @@ static int sti_dvo_bind(struct device *dev, struct device 
*master, void *data)
return -ENOMEM;

bridge->driver_private = dvo;
-   drm_bridge_init(drm_dev, bridge, _dvo_bridge_funcs);
+   bridge->funcs = _dvo_bridge_funcs;
+   drm_bridge_attach(drm_dev, bridge);

encoder->bridge = bridge;
connector->encoder = encoder;
@@ -446,7 +440,6 @@ static int sti_dvo_bind(struct device *dev, struct device 
*master, void *data)
 err_sysfs:
drm_connector_unregister(drm_connector);
 err_connector:
-   drm_bridge_cleanup(bridge);
drm_connector_cleanup(drm_connector);
return -EINVAL;
 }
-- 
1.9.1

[PATCH 1/2] drm: bridge/dw_hdmi: Adapt to bridge API change

[Fabio Estevam]

Commit fbc4572e9c48e45b ("drm/bridge: make bridge registration independent of
drm flow") introduced some drm/bridge API modifications. Make the necessary
changes so that we can avoid the build breakage:

drivers/gpu/drm/bridge/dw_hdmi.c: In function 'dw_hdmi_bridge_destroy':
drivers/gpu/drm/bridge/dw_hdmi.c:1378:2: error: implicit declaration of 
function 'drm_bridge_cleanup' [-Werror=implicit-function-declaration]
drivers/gpu/drm/bridge/dw_hdmi.c: At top level:
drivers/gpu/drm/bridge/dw_hdmi.c:1471:2: error: unknown field 'destroy' 
specified in initializer
drivers/gpu/drm/bridge/dw_hdmi.c: In function 'dw_hdmi_register':
drivers/gpu/drm/bridge/dw_hdmi.c:1535:2: error: implicit declaration of 
function 'drm_bridge_init' [-Werror=implicit-function-declaration]

Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 6ea0005..ed3dfe7 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1373,12 +1373,6 @@ static void dw_hdmi_bridge_enable(struct drm_bridge 
*bridge)
dw_hdmi_poweron(hdmi);
 }

-static void dw_hdmi_bridge_destroy(struct drm_bridge *bridge)
-{
-   drm_bridge_cleanup(bridge);
-   kfree(bridge);
-}
-
 static void dw_hdmi_bridge_nop(struct drm_bridge *bridge)
 {
/* do nothing */
@@ -1468,7 +1462,6 @@ struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
.post_disable = dw_hdmi_bridge_nop,
.mode_set = dw_hdmi_bridge_mode_set,
.mode_fixup = dw_hdmi_bridge_mode_fixup,
-   .destroy = dw_hdmi_bridge_destroy,
 };

 static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
@@ -1531,8 +1524,8 @@ static int dw_hdmi_register(struct drm_device *drm, 
struct dw_hdmi *hdmi)

hdmi->bridge = bridge;
bridge->driver_private = hdmi;
-
-   ret = drm_bridge_init(drm, bridge, _hdmi_bridge_funcs);
+   bridge->funcs = _hdmi_bridge_funcs;
+   ret = drm_bridge_attach(drm, bridge);
if (ret) {
DRM_ERROR("Failed to initialize bridge with drm\n");
return -EINVAL;
-- 
1.9.1

[Bug 86089] [r600g][mesa 10.4.0-dev] shader failure - r600_sb::bc_finalizer::cf_peephole() when starting Second Life

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

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

Dave Airlie  changed:

   What|Removed |Added

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

--- Comment #9 from Dave Airlie  ---
should be fixed in master a while back.

-- 
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/20150127/a98fc5e6/attachment.html>

[PATCH 1/2] exynos: Don't use DRM_EXYNOS_GEM_{MAP_OFFSET/MMAP} ioctls

[Hyungwon Hwang]

Dear Emil,

On Mon, 26 Jan 2015 19:05:51 +
Emil Velikov  wrote:

> On 26 January 2015 at 01:42, Hyungwon Hwang 
> wrote:
> > Dear Tobias,
> >
> > Thanks for fixing it.
> >
> > Signed-off-by: Hyungwon Hwang 
> >
> Hi Hyungwon Hwang
> 
> I'm a bit confused about the use of s-o-b here. I've assumed that
> libdrm follows the kernel style [1] for those type of things ?
> Would you have anything handy which I can read on the topic ?

I also think that DRI-devel mailing list follow the kernel rule. I used
s-o-b here by the meaning of (a) below (this text is excerpted from the
link you sent)

12) Sign your work

To improve tracking of who did what, especially with patches that can
percolate to their final resting place in the kernel through several
layers of maintainers, we've introduced a "sign-off" procedure on
patches that are being emailed around.

The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the right to
pass it on as an open-source patch.  The rules are pretty simple: if you
can certify the below:

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

Was it wrong to add s-o-b here? Should I have used "Reviewed-by" here?
I am sorry, if I broke the rule and confused you.

> 
> Cheers,
> Emil
> 
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/SubmittingPatches#n358
> 
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?


Best regards,
Hyungwon Hwang

[git pull] drm fixes

[Linus Torvalds]

On Mon, Jan 26, 2015 at 6:06 PM, Dave Airlie  wrote:
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~airlied/linux drm-fixes

No they aren't, actually, because you've screwed up your repository.

It looks like you were using an alternates that has gone away:

   remote: error: object directory
/srv/anongit.freedesktop.org/git/nouveau/linux-2.6/objects does not
exist; check .git/objects/info/alternates.
   remote: error: Could not read fe06a892edbcd0cd42ea5928e4492a337e3bd90c
   remote: fatal: bad tree object fe06a892edbcd0cd42ea5928e4492a337e3bd90c
   remote: aborting due to possible repository corruption on the remote side.

it really looks like you started your repo by doing a shared clone
from an insane source (ie the nouveau tree), and then the nouveau tree
got renamed or deleted (perhaps somebody decided that the whole
"linux-2.6" naming doesn't make sense any more, since we haven't been
at 2.6 for years). So now your repository depends on another repo that
is gone.

It's should be trivially fixable by just editing the git "alternates"
file to point to the proper base again, since that fe06a892edbc object
is definitely part of my base kernel, but basically you shouldn't do
shared clones unless you know you can really *rely* on the clone
you're sharing from. Doing it from some random side project like the
nouveau tree sounds like a bad bad idea.

Linus

[PATCH V9 13/14] ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints

[Ajay kumar]

Hi Kukjin,

On Fri, Jan 23, 2015 at 12:31 PM, Kukjin Kim  wrote:
> Ajay Kumar wrote:
>>
>> Define videoports and use endpoints to describe the connection between
>> the encoder, bridge and the panel, instead of using phandles.
>>
>> Signed-off-by: Ajay Kumar 
>> Acked-by: Inki Dae 
>> Tested-by: Rahul Sharma 
>> Tested-by: Javier Martinez Canillas 
>> Tested-by: Gustavo Padovan 
>> Tested-by: Sjoerd Simons 
>> ---
>>  arch/arm/boot/dts/exynos5250-snow.dts |   30 --
>>  1 file changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
>> b/arch/arm/boot/dts/exynos5250-snow.dts
>> index b9aeec4..1bd5d3a 100644
>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>> @@ -183,7 +183,20 @@
>>   powerdown-gpios = < 5 GPIO_ACTIVE_HIGH>;
>>   reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
>>   edid-emulation = <5>;
>> - panel = <>;
>> +
>> + ports {
>> + port at 0 {
>> + bridge_out: endpoint {
>> + remote-endpoint = <_in>;
>> + };
>> + };
>> +
>> + port at 1 {
>> + bridge_in: endpoint {
>> + remote-endpoint = <_out>;
>> + };
>> + };
>> + };
>>   };
>>   };
>>
>> @@ -228,6 +241,12 @@
>>   compatible = "auo,b116xw03";
>>   power-supply = <>;
>>   backlight = <>;
>> +
>> + port {
>> + panel_in: endpoint {
>> + remote-endpoint = <_out>;
>> + };
>> + };
>>   };
>>  };
>>
>> @@ -242,7 +261,14 @@
>>   samsung,link-rate = <0x0a>;
>>   samsung,lane-count = <2>;
>>   samsung,hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
>> - bridge = <>;
>> +
>> + ports {
>> + port at 0 {
>> + dp_out: endpoint {
>> + remote-endpoint = <_in>;
>> + };
>> + };
>> + };
>>  };
>>
>>   {
>> --
>> 1.7.9.5
>
> I'm fine on the DT changes in this series, shall I take 13/14 and 14/14 in
> Samsung tree?
Yes, please take these patches.

Thanks and regards,
Ajay Kumar

[PATCH] drivers: gpu: drm: i915: intel_fifo_underrun.c: Fix a typo in comment

[Jani Nikula]

On Mon, 26 Jan 2015, Kumar Amit Mehta  wrote:
> The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent
> with the code and the rest of the comment for this routine. This patch
> fixes this typo in comment.
>
> Signed-off-by: Kumar Amit Mehta 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/intel_fifo_underrun.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c 
> b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> index 77af512..04e248d 100644
> --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> @@ -341,7 +341,7 @@ bool intel_set_pch_fifo_underrun_reporting(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  /**
> - * intel_pch_fifo_underrun_irq_handler - handle PCH fifo underrun interrupt
> + * intel_cpu_fifo_underrun_irq_handler - handle CPU fifo underrun interrupt
>   * @dev_priv: i915 device instance
>   * @pipe: (CPU) pipe to set state for
>   *
> -- 
> 2.1.0
>

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] [rfc] drm/sti: fixup for bridge interface

[Dave Airlie]

From: Dave Airlie 

So sti doesn't build because the bridge interfaces changes didn't
catch up to its new DVO driver.

Now I might just carry this patch, but I might just push the
bridge pull into a side-pull until someone resolves it.

So this might not be the right solution to the problem, so
please figure it out and let me know ASAP.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/sti/sti_dvo.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 651afad..aeb5070 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -91,6 +91,7 @@ struct sti_dvo {
struct dvo_config *config;
bool enabled;
struct drm_encoder *encoder;
+   struct drm_bridge *bridge;
 };

 struct sti_dvo_connector {
@@ -272,19 +273,12 @@ static void sti_dvo_bridge_nope(struct drm_bridge *bridge)
/* do nothing */
 }

-static void sti_dvo_brigde_destroy(struct drm_bridge *bridge)
-{
-   drm_bridge_cleanup(bridge);
-   kfree(bridge);
-}
-
 static const struct drm_bridge_funcs sti_dvo_bridge_funcs = {
.pre_enable = sti_dvo_pre_enable,
.enable = sti_dvo_bridge_nope,
.disable = sti_dvo_disable,
.post_disable = sti_dvo_bridge_nope,
.mode_set = sti_dvo_set_mode,
-   .destroy = sti_dvo_brigde_destroy,
 };

 static int sti_dvo_connector_get_modes(struct drm_connector *connector)
@@ -416,8 +410,21 @@ static int sti_dvo_bind(struct device *dev, struct device 
*master, void *data)
return -ENOMEM;

bridge->driver_private = dvo;
-   drm_bridge_init(drm_dev, bridge, _dvo_bridge_funcs);
+   bridge->funcs = _dvo_bridge_funcs;
+   bridge->of_node = dvo->dev.of_node;
+   err = drm_bridge_add(bridge);
+   if (err) {
+   DRM_ERROR("Failed to add bridge\n");
+   return err;
+   }

+   err = drm_bridge_attach(drm_dev, bridge);
+   if (err) {
+   DRM_ERROR("Failed to attach bridge\n");
+   return err;
+   }
+
+   dvo->bridge = bridge;
encoder->bridge = bridge;
connector->encoder = encoder;
dvo->encoder = encoder;
@@ -446,7 +453,7 @@ static int sti_dvo_bind(struct device *dev, struct device 
*master, void *data)
 err_sysfs:
drm_connector_unregister(drm_connector);
 err_connector:
-   drm_bridge_cleanup(bridge);
+   drm_bridge_remove(bridge);
drm_connector_cleanup(drm_connector);
return -EINVAL;
 }
@@ -454,7 +461,9 @@ err_connector:
 static void sti_dvo_unbind(struct device *dev,
   struct device *master, void *data)
 {
-   /* do nothing */
+   struct sti_dvo *dvo = dev_get_drvdata(dev);
+
+   drm_bridge_remove(dvo->bridge);
 }

 static const struct component_ops sti_dvo_ops = {
-- 
1.9.3

[PATCH] drm/mm: Support 4 GiB and larger ranges

[Thomas Hellstrom]

On 01/27/2015 09:15 AM, Thierry Reding wrote:
> On Tue, Jan 27, 2015 at 07:07:44AM +0100, Thomas Hellstrom wrote:
>> On 01/26/2015 11:51 PM, Dave Airlie wrote:
>>> On 23 January 2015 at 18:05, Thierry Reding
 wrote:
 From: Thierry Reding 

 The current implementation is limited by the number of addresses that
 fit into an unsigned long. This causes problems on 32-bit Tegra where
 unsigned long is 32-bit but drm_mm is used to manage an IOVA space of
 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1
 (or 4 GiB - 4 KiB for page granularity).

 This commit changes the start and size of the range to be an unsigned
 64-bit integer, thus allowing much larger ranges to be supported.
>>> This seems fine to me, Chris, Daniel or Thomas, any objections?
>>>
>>> Dave.
>>
>> This is perfectly fine with me, although I'm a bit curious why the
>> allocation granularity of the IOVA space needs to be 1 byte?
>
> Are you referring to the 4 GiB - 1 comment? The point I was trying to
> make is not that the granularity of the IOVA space needs to be 1 byte
> but rather that using an unsigned long for a size on a 32-bit machine
> will give you 4 GiB - 1 addresses. The IOMMU page size is still 4 KiB
> for Tegra.

I was rather referring to that if the range manager (drm_mm) is set up
to manage pages instead of bytes
(like, for example, the TTM VM address space), you'd get 4G - 1 pages,
which, I believe, is sufficient on most 32 bit systems?

Thanks,

/Thomas


>
> Thierry

[PATCH] drm/mm: Support 4 GiB and larger ranges

[Chris Wilson]

On Tue, Jan 27, 2015 at 08:51:12AM +1000, Dave Airlie wrote:
> On 23 January 2015 at 18:05, Thierry Reding  
> wrote:
> > From: Thierry Reding 
> >
> > The current implementation is limited by the number of addresses that
> > fit into an unsigned long. This causes problems on 32-bit Tegra where
> > unsigned long is 32-bit but drm_mm is used to manage an IOVA space of
> > 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1
> > (or 4 GiB - 4 KiB for page granularity).
> >
> > This commit changes the start and size of the range to be an unsigned
> > 64-bit integer, thus allowing much larger ranges to be supported.
> 
> This seems fine to me, Chris, Daniel or Thomas, any objections?

None, lgtm. Would be worth just tidying the struct up for natural
alignment (especially the drm_mm_node) to remove some holes.

Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/bridge: dw_hdmi: adapt to updated bridge API

[Dave Airlie]

On 26 January 2015 at 23:12, Heiko Stübner  wrote:
> Commits 8eb17f05bc18 ("drm/bridge: do not pass drm_bridge_funcs to
> drm_bridge_init") and fbc4572e9c48 ("drm/bridge: make bridge registration
> independent of drm flow") changed the bridge API without taking into account
> the also newly introduced dw_hdmi bridge.
>
> Therefore adapt the dw_hdmi bridge to the new bridge API.
>
> The bridge struct is already allocated using devm_kzalloc, so the destroy
> function can go away completely.
>
> Signed-off-by: Heiko Stuebner 

Thanks, I merged this after I pulled Thierry's change.

Dave.

[PATCH] drm/mm: Support 4 GiB and larger ranges

[Thierry Reding]

On Tue, Jan 27, 2015 at 07:07:44AM +0100, Thomas Hellstrom wrote:
> On 01/26/2015 11:51 PM, Dave Airlie wrote:
> > On 23 January 2015 at 18:05, Thierry Reding  
> > wrote:
> >> From: Thierry Reding 
> >>
> >> The current implementation is limited by the number of addresses that
> >> fit into an unsigned long. This causes problems on 32-bit Tegra where
> >> unsigned long is 32-bit but drm_mm is used to manage an IOVA space of
> >> 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1
> >> (or 4 GiB - 4 KiB for page granularity).
> >>
> >> This commit changes the start and size of the range to be an unsigned
> >> 64-bit integer, thus allowing much larger ranges to be supported.
> > This seems fine to me, Chris, Daniel or Thomas, any objections?
> >
> > Dave.
> 
> This is perfectly fine with me, although I'm a bit curious why the
> allocation granularity of the IOVA space needs to be 1 byte?

Are you referring to the 4 GiB - 1 comment? The point I was trying to
make is not that the granularity of the IOVA space needs to be 1 byte
but rather that using an unsigned long for a size on a 32-bit machine
will give you 4 GiB - 1 addresses. The IOMMU page size is still 4 KiB
for Tegra.

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

[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later

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

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

Christian König  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #5 from Christian König  ---
(In reply to Mike S. from comment #4)
> I am no expert, but looking at the code, a ref_div value of 14 seems wrong.
> In r600d.h the REF_DIV_MASK is only 3 bits wide, so the max value it should
> ever be is 7, right?

The REF_DIV_MASK in r600d.h is for the system clock setup, not for the display
clock.

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

[GIT PULL] drm/tegra: Changes for v3.20-rc1

[Dave Airlie]

On 23 January 2015 at 23:56, Thierry Reding  wrote:
> Hi Dave,
>
> The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470:
>
>   Merge remote-tracking branch 'origin/master' into drm-next (2015-01-22 
> 10:44:41 +1000)
>
> are available in the git repository at:
>
>   git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-3.20-rc1
>
> for you to fetch changes up to 28dd241d37bd136e140c884897f64b79bf8d7a83:
>
>   drm/tegra: Use correct relocation target offsets (2015-01-23 12:17:04 +0100)

  MODPOST 1728 modules
ERROR: "host1x_unregister" [drivers/gpu/host1x/host1x.ko] undefined!
ERROR: "host1x_register" [drivers/gpu/host1x/host1x.ko] undefined!
ERROR: "host1x_driver_register_full"
[drivers/gpu/drm/tegra/tegra-drm.ko] undefined!
ERROR: "host1x_device_exit" [drivers/gpu/drm/tegra/tegra-drm.ko] undefined!
ERROR: "host1x_client_unregister" [drivers/gpu/drm/tegra/tegra-drm.ko]
undefined!
ERROR: "host1x_driver_unregister" [drivers/gpu/drm/tegra/tegra-drm.ko]
undefined!
ERROR: "host1x_device_init" [drivers/gpu/drm/tegra/tegra-drm.ko] undefined!
ERROR: "host1x_client_register" [drivers/gpu/drm/tegra/tegra-drm.ko] undefined!

you win the broke my build prize.

Please try again :-)

just put the fix on top of this and send a new pull req, it looks trivial.

Dave.

[PATCH] drm/mm: Support 4 GiB and larger ranges

[Dave Airlie]

On 23 January 2015 at 18:05, Thierry Reding  wrote:
> From: Thierry Reding 
>
> The current implementation is limited by the number of addresses that
> fit into an unsigned long. This causes problems on 32-bit Tegra where
> unsigned long is 32-bit but drm_mm is used to manage an IOVA space of
> 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1
> (or 4 GiB - 4 KiB for page granularity).
>
> This commit changes the start and size of the range to be an unsigned
> 64-bit integer, thus allowing much larger ranges to be supported.

This seems fine to me, Chris, Daniel or Thomas, any objections?

Dave.

[Bug 91861] [Radeon RS780] Blank screen (no signal) on HDMI after boot in 3.15 & later

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

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

--- Comment #4 from Mike S.  ---
I haven't yet tested the patch to cap ref_div to 7, but here are the values
reported with drm.debug=0xE, in case they are useful:

1. Kernel 3.14 (working):
14851, fb: 145.2 ref: 2, post: 7

2. Kernel 3.18 (not working):
148500 - 148500, fb: 1016.3 ref: 14, post: 7

I am no expert, but looking at the code, a ref_div value of 14 seems wrong. In
r600d.h the REF_DIV_MASK is only 3 bits wide, so the max value it should ever
be is 7, right?

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

[PATCH] drm/mm: Support 4 GiB and larger ranges

[Thomas Hellstrom]

On 01/26/2015 11:51 PM, Dave Airlie wrote:
> On 23 January 2015 at 18:05, Thierry Reding  
> wrote:
>> From: Thierry Reding 
>>
>> The current implementation is limited by the number of addresses that
>> fit into an unsigned long. This causes problems on 32-bit Tegra where
>> unsigned long is 32-bit but drm_mm is used to manage an IOVA space of
>> 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1
>> (or 4 GiB - 4 KiB for page granularity).
>>
>> This commit changes the start and size of the range to be an unsigned
>> 64-bit integer, thus allowing much larger ranges to be supported.
> This seems fine to me, Chris, Daniel or Thomas, any objections?
>
> Dave.

This is perfectly fine with me, although I'm a bit curious why the
allocation granularity of the IOVA space needs to be 1 byte?

Thanks,
Thomas

[Bug 88183] radeonsi: R9 280X hangs with SuperTuxKart

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

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

--- Comment #25 from Michel Dänzer  ---
(In reply to Alexandre Demers from comment #24)
> To my knowledge, since I've had this video card (a few months), I've been
> dealing with VM faults.

Note that I'm referring specifically to the VM faults triggered by your
apitrace from comment 5. A VM fault by itself is a generic symptom which can be
caused by many different things, it's more or less the equivalent of a CPU
segmentation fault.


> However, are VM faults only related to mesa or can they come from somewhere
> else (drm)?

The Mesa driver is most likely in general, though in this particular case it
could also be e.g. libdrm_radeon calculating the surface parameters
incorrectly.

-- 
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/20150127/d0712502/attachment.html>

[Bug 88183] radeonsi: R9 280X hangs with SuperTuxKart

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

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

--- Comment #24 from Alexandre Demers  ---
(In reply to Michel Dänzer from comment #22)
> Has anyone found a Mesa commit yet where the VM faults *don't* occur?
> Otherwise, there's nothing to bisect for them.

To my knowledge, since I've had this video card (a few months), I've been
dealing with VM faults. Here they are triggered in SuperTuxKart, but I've also
reportered them in another bug about Serious Sam 3 (which hangs the GPU in a
few seconds). However, are VM faults only related to mesa or can they come from
somewhere else (drm)?

-- 
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/20150127/732639fd/attachment.html>

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

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

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

--- Comment #7 from Dave Airlie  ---
FYI I've posted patches to mesa-dev to address this for evergreen and later.

-- 
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/20150127/bbe87c3d/attachment.html>

[PATCH 1/2] exynos: Don't use DRM_EXYNOS_GEM_{MAP_OFFSET/MMAP} ioctls

[Emil Velikov]

On 27 January 2015 at 01:05, Hyungwon Hwang  wrote:
> Dear Emil,
>
> On Mon, 26 Jan 2015 19:05:51 +
> Emil Velikov  wrote:
>
>> On 26 January 2015 at 01:42, Hyungwon Hwang 
>> wrote:
>> > Dear Tobias,
>> >
>> > Thanks for fixing it.
>> >
>> > Signed-off-by: Hyungwon Hwang 
>> >
>> Hi Hyungwon Hwang
>>
>> I'm a bit confused about the use of s-o-b here. I've assumed that
>> libdrm follows the kernel style [1] for those type of things ?
>> Would you have anything handy which I can read on the topic ?
>
> I also think that DRI-devel mailing list follow the kernel rule.
Sweet I'm not loosing my mind (much).

[...]
> Was it wrong to add s-o-b here? Should I have used "Reviewed-by" here?
> I am sorry, if I broke the rule and confused you.
>
Don't think any apology is due, I was just hinting that the patch has
the s-o-b already :P
Where as "what I should have used" that depends on your intent and/or
the action undertaken.

Thanks
Emil

[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD

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

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

--- Comment #24 from Arthur Marsh  ---
Created attachment 112868
  --> https://bugs.freedesktop.org/attachment.cgi?id=112868=edit
20150127dmesg.txt with 3.19.0-rc6 - lock-up after a few seconds of video play

with kernel 3.19.0-rc6, the gpu locked up after a few seconds of playing the
same video.

-- 
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/20150127/ba9a38c3/attachment-0001.html>

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

This feels larger than I'd like but its for three reasons.

a) amdkfd finalising the API more, this is a new feature introduced last 
merge window, and I'd prefer to make the tweaks
to the API before it first gets into a stable release.

b) radeon regression required splitting an internal API to fix properly,
so it just changed a few more lines

c) vmwgfx fix changes a lock from a mutex->spin lock, this is fallout
from the new sleep checking.

Otherwise there is just some tda998x fixes.

Dave.

The following changes since commit 26bc420b59a38e4e6685a73345a0def461136dce:

  Linux 3.19-rc6 (2015-01-25 20:04:41 -0800)

are available in the git repository at:

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

for you to fetch changes up to 5159571ceb44eba9bf9f9a34ec625386d421de9c:

  Merge branch 'drm-fixes-3.19' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2015-01-27 09:56:13 +1000)



Andrew Jackson (1):
  drm/i2c: tda998x: set the CEC I2C address based on the slave I2C address

Ben Goz (1):
  drm/amdkfd: PQM handle queue creation fault

Dave Airlie (5):
  Merge branch 'vmwgfx-fixes-3.19' of 
git://people.freedesktop.org/~thomash/linux into drm-fixes
  Merge branch 'drm-tda998x-fixes' of 
git://ftp.arm.linux.org.uk/~rmk/linux-arm into drm-fixes
  Merge tag 'v3.19-rc6' into drm-fixes
  Merge tag 'drm-amdkfd-fixes-2015-01-26' of 
git://people.freedesktop.org/~gabbayo/linux into drm-fixes
  Merge branch 'drm-fixes-3.19' of 
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Jean-Francois Moine (2):
  drm: tda998x: Protect the page register
  drm: tda998x: Fix EDID read timeout on HDMI connect

Michel Dänzer (3):
  drm/radeon: Split off gart_get_page_entry ASIC hook from set_page_entry
  drm/radeon: Restore GART table contents after pinning it in VRAM v3
  drm/radeon: Remove rdev->gart.pages_addr array

Oded Gabbay (4):
  drm/amdkfd: Allow user to limit only queues per device
  drm/radeon: Don't increment pipe_id in kgd_init_pipeline
  drm/amdkfd: Fix bug in pipelines initialization
  drm/amdkfd: Fix bug in call to init_pipelines()

Thomas Hellstrom (1):
  drm/vmwgfx: Replace the hw mutex with a hw spinlock

 drivers/gpu/drm/amd/amdkfd/kfd_device.c|  6 +-
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  | 78 +-
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |  1 +
 drivers/gpu/drm/amd/amdkfd/kfd_module.c| 27 +++-
 drivers/gpu/drm/amd/amdkfd/kfd_pasid.c |  2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h  | 17 +++--
 .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 12 ++--
 drivers/gpu/drm/i2c/tda998x_drv.c  | 52 ---
 drivers/gpu/drm/radeon/cik_sdma.c  |  1 -
 drivers/gpu/drm/radeon/ni_dma.c|  1 -
 drivers/gpu/drm/radeon/r100.c  | 10 ++-
 drivers/gpu/drm/radeon/r300.c  | 16 +++--
 drivers/gpu/drm/radeon/radeon.h|  9 ++-
 drivers/gpu/drm/radeon/radeon_asic.c   | 24 +++
 drivers/gpu/drm/radeon/radeon_asic.h   | 12 ++--
 drivers/gpu/drm/radeon/radeon_device.c |  2 +
 drivers/gpu/drm/radeon/radeon_gart.c   | 54 +--
 drivers/gpu/drm/radeon/radeon_kfd.c|  2 +-
 drivers/gpu/drm/radeon/radeon_vm.c |  6 +-
 drivers/gpu/drm/radeon/rs400.c | 14 ++--
 drivers/gpu/drm/radeon/rs600.c | 14 ++--
 drivers/gpu/drm/radeon/si_dma.c|  1 -
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 28 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 25 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c  | 18 +
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c   | 36 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c  |  8 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_irq.c| 25 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|  2 -
 29 files changed, 315 insertions(+), 188 deletions(-)