[PATCH 0/2] i.MX53 IPU + TVE patches

[Philipp Zabel]

Hi,

converting the IPU IRQ handling to use irq_domain_add_linear is listed in
drivers/staging/imx-drm/TODO as one of the tasks to be done before the IPU
driver can be moved out of staging. These patches fix the number IPU_NUM_IRQS
and add a linear irq domain.

regards
Philipp

---
 drivers/staging/imx-drm/TODO|  1 -
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 66 +++--
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h|  4 +-
 3 files changed, 45 insertions(+), 26 deletions(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] staging: drm/imx: convert IPU irq driver to irq_domain_add_linear

[Philipp Zabel]

The IPU has a lot of interrupts. Instead of allocating descs for all
of them, register a linear irq domain and create mappings as needed.
This was listed in the TODO as a prerequisite to move the IPU driver
out of staging.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/TODO|  1 -
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 66 +++--
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h|  2 +-
 3 files changed, 44 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
index 123acbe..f806415 100644
--- a/drivers/staging/imx-drm/TODO
+++ b/drivers/staging/imx-drm/TODO
@@ -6,7 +6,6 @@ TODO:
 - Factor out more code to common helper functions
 - decide where to put the base driver. It is not specific to a subsystem
   and would be used by DRM/KMS and media/V4L2
-- convert irq driver to irq_domain_add_linear
 
 Missing features (not necessarily for moving out of staging):
 
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index 0127601..1a7b59e 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "imx-ipu-v3.h"
@@ -799,16 +800,18 @@ err_di_0:
 static void ipu_irq_handle(struct ipu_soc *ipu, const int *regs, int num_regs)
 {
unsigned long status;
-   int i, bit, irq_base;
+   int i, bit, irq;
 
for (i = 0; i < num_regs; i++) {
 
status = ipu_cm_read(ipu, IPU_INT_STAT(regs[i]));
status &= ipu_cm_read(ipu, IPU_INT_CTRL(regs[i]));
 
-   irq_base = ipu->irq_start + regs[i] * 32;
-   for_each_set_bit(bit, &status, 32)
-   generic_handle_irq(irq_base + bit);
+   for_each_set_bit(bit, &status, 32) {
+   irq = irq_linear_revmap(ipu->domain, regs[i] * 32 + 
bit);
+   if (irq)
+   generic_handle_irq(irq);
+   }
}
 }
 
@@ -841,7 +844,7 @@ static void ipu_err_irq_handler(unsigned int irq, struct 
irq_desc *desc)
 static void ipu_ack_irq(struct irq_data *d)
 {
struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   unsigned int irq = d->irq - ipu->irq_start;
+   irq_hw_number_t irq = d->hwirq;
 
ipu_cm_write(ipu, 1 << (irq % 32), IPU_INT_STAT(irq / 32));
 }
@@ -849,7 +852,7 @@ static void ipu_ack_irq(struct irq_data *d)
 static void ipu_unmask_irq(struct irq_data *d)
 {
struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   unsigned int irq = d->irq - ipu->irq_start;
+   irq_hw_number_t irq = d->hwirq;
unsigned long flags;
u32 reg;
 
@@ -865,7 +868,7 @@ static void ipu_unmask_irq(struct irq_data *d)
 static void ipu_mask_irq(struct irq_data *d)
 {
struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   unsigned int irq = d->irq - ipu->irq_start;
+   irq_hw_number_t irq = d->hwirq;
unsigned long flags;
u32 reg;
 
@@ -888,7 +891,12 @@ static struct irq_chip ipu_irq_chip = {
 int ipu_idmac_channel_irq(struct ipu_soc *ipu, struct ipuv3_channel *channel,
enum ipu_channel_irq irq_type)
 {
-   return ipu->irq_start + irq_type + channel->num;
+   int irq = irq_linear_revmap(ipu->domain, irq_type + channel->num);
+
+   if (!irq)
+   irq = irq_create_mapping(ipu->domain, irq_type + channel->num);
+
+   return irq;
 }
 EXPORT_SYMBOL_GPL(ipu_idmac_channel_irq);
 
@@ -975,18 +983,30 @@ err_register:
return ret;
 }
 
-static int ipu_irq_init(struct ipu_soc *ipu)
+static int ipu_irq_map(struct irq_domain *h, unsigned int irq,
+  irq_hw_number_t hw)
 {
-   int i;
+   struct ipu_soc *ipu = h->host_data;
+
+   irq_set_chip_and_handler(irq, &ipu_irq_chip, handle_level_irq);
+   set_irq_flags(irq, IRQF_VALID);
+   irq_set_chip_data(irq, ipu);
+
+   return 0;
+}
 
-   ipu->irq_start = irq_alloc_descs(-1, 0, IPU_NUM_IRQS, 0);
-   if (ipu->irq_start < 0)
-   return ipu->irq_start;
+const struct irq_domain_ops ipu_irq_domain_ops = {
+   .map = ipu_irq_map,
+   .xlate = irq_domain_xlate_onecell,
+};
 
-   for (i = ipu->irq_start; i < ipu->irq_start + IPU_NUM_IRQS; i++) {
-   irq_set_chip_and_handler(i, &ipu_irq_chip, handle_level_irq);
-   set_irq_flags(i, IRQF_VALID);
-   irq_set_chip_data(i, ipu);
+static int ipu_irq_init(struct ipu_soc *ipu)
+{
+   ipu->domain = irq_domain_add_linear(ipu->dev->of_node, IPU_NUM_IRQS,
+   &ipu_irq_domain_ops, ipu);
+   if (!ipu->domain) {
+   dev_err(ipu->dev, "failed to add irq domain\n");
+   return -ENODEV;
}
 
irq_set_chained_handler(ipu->irq_sync, ipu_irq_handler);
@@ -999,20 +1019,20 @@ stati

[PATCH 1/2] staging: drm/imx: fix number of IPU IRQs

[Philipp Zabel]

There are 15 32-bit registers altogether.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-prv.h 
b/drivers/staging/imx-drm/ipu-v3/ipu-prv.h
index 5518028..12d7eaf 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-prv.h
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-prv.h
@@ -110,7 +110,7 @@ struct ipu_soc;
 #define IDMAC_BAND_EN(ch)  IPU_IDMAC_REG(0x0040 + 4 * ((ch) / 32))
 #define IDMAC_CHA_BUSY(ch) IPU_IDMAC_REG(0x0100 + 4 * ((ch) / 32))
 
-#define IPU_NUM_IRQS   (32 * 5)
+#define IPU_NUM_IRQS   (32 * 15)
 
 enum ipu_modules {
IPU_CONF_CSI0_EN= (1 << 0),
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] i.MX53 IPU + TVE patches

[Philipp Zabel]

Am Freitag, den 21.06.2013, 10:27 +0200 schrieb Philipp Zabel:
> Hi,
> 

Sorry, copy & paste error.
The correct subject is IPU linear irq domain:

> converting the IPU IRQ handling to use irq_domain_add_linear is listed in
> drivers/staging/imx-drm/TODO as one of the tasks to be done before the IPU
> driver can be moved out of staging. These patches fix the number IPU_NUM_IRQS
> and add a linear irq domain.
> 
> regards
> Philipp
> 
> ---
>  drivers/staging/imx-drm/TODO|  1 -
>  drivers/staging/imx-drm/ipu-v3/ipu-common.c | 66 
> +++--
>  drivers/staging/imx-drm/ipu-v3/ipu-prv.h|  4 +-
>  3 files changed, 45 insertions(+), 26 deletions(-)
> 
> 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Lucas Stach]

Am Donnerstag, den 20.06.2013, 20:15 +0900 schrieb Inki Dae:
[...]
> > > > You already need some kind of IPC between the two tasks, as I suspect
> > > > even in your example it wouldn't make much sense to queue the buffer
> > > > over and over again in task B without task A writing anything to it.
> > So
> > > > task A has to signal task B there is new data in the buffer to be
> > > > processed.
> > > >
> > > > There is no need to share the buffer over and over again just to get
> > the
> > > > two processes to work together on the same thing. Just share the fd
> > > > between both and then do out-of-band completion signaling, as you need
> > > > this anyway. Without this you'll end up with unpredictable behavior.
> > > > Just because sync allows you to access the buffer doesn't mean it's
> > > > valid for your use-case. Without completion signaling you could easily
> > > > end up overwriting your data from task A multiple times before task B
> > > > even tries to lock the buffer for processing.
> > > >
> > > > So the valid flow is (and this already works with the current APIs):
> > > > Task ATask B
> > > > ----
> > > > CPU access buffer
> > > >  --completion signal->
> > > >   qbuf (dragging buffer into
> > > >   device domain, flush caches,
> > > >   reserve buffer etc.)
> > > > |
> > > >   wait for device operation to
> > > >   complete
> > > > |
> > > >   dqbuf (dragging buffer back
> > > >   into CPU domain, invalidate
> > > >   caches, unreserve)
> > > > <-completion signal
> > > > CPU access buffer
> > > >
> > >
> > > Correct. In case that data flow goes from A to B, it needs some kind
> > > of IPC between the two tasks every time as you said. Then, without
> > > dmabuf-sync, how do think about the case that two tasks share the same
> > > buffer but these tasks access the buffer(buf1) as write, and data of
> > > the buffer(buf1) isn't needed to be shared?
> > >
> > Sorry, I don't see the point you are trying to solve here. If you share
> > a buffer and want its content to be clearly defined at every point in
> > time you have to synchronize the tasks working with the buffer, not just
> > the buffer accesses itself.
> > 
> > Easiest way to do so is doing sync through userspace with out-of-band
> > IPC, like in the example above.
> 
> In my opinion, that's not definitely easiest way. What I try to do is
> to avoid using *the out-of-band IPC*. As I mentioned in document file,
> the conventional mechanism not only makes user application
> complicated-user process needs to understand how the device driver is
> worked-but also may incur performance overhead by using the
> out-of-band IPC. The above my example may not be enough to you but
> there would be other cases able to use my approach efficiently.
> 

Yeah, you'll some knowledge and understanding about the API you are
working with to get things right. But I think it's not an unreasonable
thing to expect the programmer working directly with kernel interfaces
to read up on how things work.

Second thing: I'll rather have *one* consistent API for every subsystem,
even if they differ from each other than having to implement this
syncpoint thing in every subsystem. Remember: a single execbuf in DRM
might reference both GEM objects backed by dma-buf as well native SHM or
CMA backed objects. The dma-buf-mgr proposal already allows you to
handle dma-bufs much the same way during validation than native GEM
objects.

And to get back to my original point: if you have more than one task
operating together on a buffer you absolutely need some kind of real IPC
to sync them up and do something useful. Both you syncpoints and the
proposed dma-fences only protect the buffer accesses to make sure
different task don't stomp on each other. There is nothing in there to
make sure that the output of your pipeline is valid. You have to take
care of that yourself in userspace. I'll reuse your example to make it
clear what I mean:

Task A Task B
-- ---
dma_buf_sync_lock(buf1)
CPU write buf1
dma_buf_sync_unlock(buf1)
  -schedule Task A again---
dma_buf_sync_lock(buf1)
CPU write buf1
dma_buf_sync_unlock(buf1)
-schedule Task B-
   qbuf(buf1)
  dma_buf_sync_lock(buf1)
   

[PATCH 3/4] staging: drm/imx: ipuv3-crtc: immediately update crtc->fb in ipu_page_flip

[Philipp Zabel]

Since commit 8cf1e9811471f2910fa38dc1b28e1789080ba961
("drm: Add consistency check for page-flipping") drm_mode_page_flip_ioctl
contains a WARN_ON that triggers if the .page_flip callback didn't update
the crtc->fb pointer to the new framebuffer immediately.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipuv3-crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index abcdaef..4a7eedf 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -147,6 +147,7 @@ static int ipu_page_flip(struct drm_crtc *crtc,
 
ipu_crtc->newfb = fb;
ipu_crtc->page_flip_event = event;
+   crtc->fb = fb;
 
return 0;
 }
@@ -329,7 +330,6 @@ static irqreturn_t ipu_irq_handler(int irq, void *dev_id)
imx_drm_handle_vblank(ipu_crtc->imx_crtc);
 
if (ipu_crtc->newfb) {
-   ipu_crtc->base.fb = ipu_crtc->newfb;
ipu_crtc->newfb = NULL;
ipu_drm_set_base(&ipu_crtc->base, 0, 0);
ipu_crtc_handle_pageflip(ipu_crtc);
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] IPU DMFC bandwidth allocation fix and cleanups

[Philipp Zabel]

Hi,

the following patches remove some unused variables, replace some
hard-coded channel numbers with existing descriptive defines, fix
the DMFC bandwidth (or rather: FIFO space) allocation, and update
ipu_page_flip() to immediately set crtc->fb.

regards
Philipp

---
 drivers/staging/imx-drm/imx-drm-core.c|  3 ---
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 22 --
 drivers/staging/imx-drm/ipuv3-crtc.c  |  7 +--
 3 files changed, 17 insertions(+), 15 deletions(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] staging: drm/imx: remove unused variables

[Philipp Zabel]

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/imx-drm-core.c | 3 ---
 drivers/staging/imx-drm/ipuv3-crtc.c   | 5 -
 2 files changed, 8 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index 6455305..56d6bc4 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -491,7 +491,6 @@ int imx_drm_add_crtc(struct drm_crtc *crtc,
 {
struct imx_drm_device *imxdrm = __imx_drm_device();
struct imx_drm_crtc *imx_drm_crtc;
-   const struct drm_crtc_funcs *crtc_funcs;
int ret;
 
mutex_lock(&imxdrm->mutex);
@@ -512,8 +511,6 @@ int imx_drm_add_crtc(struct drm_crtc *crtc,
imx_drm_crtc->cookie.cookie = cookie;
imx_drm_crtc->cookie.id = id;
 
-   crtc_funcs = imx_drm_helper_funcs->crtc_funcs;
-
imx_drm_crtc->crtc = crtc;
imx_drm_crtc->imxdrm = imxdrm;
 
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index ff5c633..abcdaef 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -42,9 +41,6 @@ struct ipu_framebuffer {
 };
 
 struct ipu_crtc {
-   struct drm_fb_helperfb_helper;
-   struct ipu_framebuffer  ifb;
-   int num_crtcs;
struct device   *dev;
struct drm_crtc base;
struct imx_drm_crtc *imx_crtc;
@@ -54,7 +50,6 @@ struct ipu_crtc {
struct dmfc_channel *dmfc;
struct ipu_di   *di;
int enabled;
-   struct ipu_priv *ipu_priv;
struct drm_pending_vblank_event *page_flip_event;
struct drm_framebuffer  *newfb;
int irq;
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] staging: drm/imx: ipu-dmfc: fix bandwidth allocation

[Philipp Zabel]

The IPU can request up to four pixels per access, which gives four
times the bandwidth compared to what the driver currently assumes.
After correcting this, we have to increase safety margins for
bandwidth requirement calculations.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
index 91821bc..1dc9817 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
@@ -292,7 +292,7 @@ int ipu_dmfc_alloc_bandwidth(struct dmfc_channel *dmfc,
 {
struct ipu_dmfc_priv *priv = dmfc->priv;
int slots = dmfc_bandwidth_to_slots(priv, bandwidth_pixel_per_second);
-   int segment = 0, ret = 0;
+   int segment = -1, ret = 0;
 
dev_dbg(priv->dev, "dmfc: trying to allocate %ldMpixel/s for IPU 
channel %d\n",
bandwidth_pixel_per_second / 100,
@@ -307,7 +307,17 @@ int ipu_dmfc_alloc_bandwidth(struct dmfc_channel *dmfc,
goto out;
}
 
-   segment = dmfc_find_slots(priv, slots);
+   /* Always allocate at least 128*4 bytes (2 slots) */
+   if (slots < 2)
+   slots = 2;
+
+   /* For the MEM_BG channel, first try to allocate twice the slots */
+   if (dmfc->data->ipu_channel == IPUV3_CHANNEL_MEM_BG_SYNC)
+   segment = dmfc_find_slots(priv, slots * 2);
+   if (segment >= 0)
+   slots *= 2;
+   else
+   segment = dmfc_find_slots(priv, slots);
if (segment < 0) {
ret = -EBUSY;
goto out;
@@ -391,7 +401,7 @@ int ipu_dmfc_init(struct ipu_soc *ipu, struct device *dev, 
unsigned long base,
 * We have a total bandwidth of clkrate * 4pixel divided
 * into 8 slots.
 */
-   priv->bandwidth_per_slot = clk_get_rate(ipu_clk) / 8;
+   priv->bandwidth_per_slot = clk_get_rate(ipu_clk) * 4 / 8;
 
dev_dbg(dev, "dmfc: 8 slots with %ldMpixel/s bandwidth each\n",
priv->bandwidth_per_slot / 100);
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] staging: drm/imx: ipu-dmfc: use defines for ipu channel numbers

[Philipp Zabel]

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
index 1dc9817..2e97c33 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
@@ -61,7 +61,7 @@ struct dmfc_channel_data {
 
 static const struct dmfc_channel_data dmfcdata[] = {
{
-   .ipu_channel= 23,
+   .ipu_channel= IPUV3_CHANNEL_MEM_BG_SYNC,
.channel_reg= DMFC_DP_CHAN,
.shift  = DMFC_DP_CHAN_5B_23,
.eot_shift  = 20,
@@ -73,13 +73,13 @@ static const struct dmfc_channel_data dmfcdata[] = {
.eot_shift  = 22,
.max_fifo_lines = 1,
}, {
-   .ipu_channel= 27,
+   .ipu_channel= IPUV3_CHANNEL_MEM_FG_SYNC,
.channel_reg= DMFC_DP_CHAN,
.shift  = DMFC_DP_CHAN_5F_27,
.eot_shift  = 21,
.max_fifo_lines = 2,
}, {
-   .ipu_channel= 28,
+   .ipu_channel= IPUV3_CHANNEL_MEM_DC_SYNC,
.channel_reg= DMFC_WR_CHAN,
.shift  = DMFC_WR_CHAN_1_28,
.eot_shift  = 16,
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

2013/6/21 Lucas Stach 

> Am Donnerstag, den 20.06.2013, 20:15 +0900 schrieb Inki Dae:
> [...]
> > > > > You already need some kind of IPC between the two tasks, as I
> suspect
> > > > > even in your example it wouldn't make much sense to queue the
> buffer
> > > > > over and over again in task B without task A writing anything to
> it.
> > > So
> > > > > task A has to signal task B there is new data in the buffer to be
> > > > > processed.
> > > > >
> > > > > There is no need to share the buffer over and over again just to
> get
> > > the
> > > > > two processes to work together on the same thing. Just share the fd
> > > > > between both and then do out-of-band completion signaling, as you
> need
> > > > > this anyway. Without this you'll end up with unpredictable
> behavior.
> > > > > Just because sync allows you to access the buffer doesn't mean it's
> > > > > valid for your use-case. Without completion signaling you could
> easily
> > > > > end up overwriting your data from task A multiple times before
> task B
> > > > > even tries to lock the buffer for processing.
> > > > >
> > > > > So the valid flow is (and this already works with the current
> APIs):
> > > > > Task ATask B
> > > > > ----
> > > > > CPU access buffer
> > > > >  --completion signal->
> > > > >   qbuf (dragging buffer
> into
> > > > >   device domain, flush
> caches,
> > > > >   reserve buffer etc.)
> > > > > |
> > > > >   wait for device
> operation to
> > > > >   complete
> > > > > |
> > > > >   dqbuf (dragging buffer
> back
> > > > >   into CPU domain,
> invalidate
> > > > >   caches, unreserve)
> > > > > <-completion signal
> > > > > CPU access buffer
> > > > >
> > > >
> > > > Correct. In case that data flow goes from A to B, it needs some kind
> > > > of IPC between the two tasks every time as you said. Then, without
> > > > dmabuf-sync, how do think about the case that two tasks share the
> same
> > > > buffer but these tasks access the buffer(buf1) as write, and data of
> > > > the buffer(buf1) isn't needed to be shared?
> > > >
> > > Sorry, I don't see the point you are trying to solve here. If you share
> > > a buffer and want its content to be clearly defined at every point in
> > > time you have to synchronize the tasks working with the buffer, not
> just
> > > the buffer accesses itself.
> > >
> > > Easiest way to do so is doing sync through userspace with out-of-band
> > > IPC, like in the example above.
> >
> > In my opinion, that's not definitely easiest way. What I try to do is
> > to avoid using *the out-of-band IPC*. As I mentioned in document file,
> > the conventional mechanism not only makes user application
> > complicated-user process needs to understand how the device driver is
> > worked-but also may incur performance overhead by using the
> > out-of-band IPC. The above my example may not be enough to you but
> > there would be other cases able to use my approach efficiently.
> >
>
> Yeah, you'll some knowledge and understanding about the API you are
> working with to get things right. But I think it's not an unreasonable
> thing to expect the programmer working directly with kernel interfaces
> to read up on how things work.
>
> Second thing: I'll rather have *one* consistent API for every subsystem,
> even if they differ from each other than having to implement this
> syncpoint thing in every subsystem. Remember: a single execbuf in DRM
> might reference both GEM objects backed by dma-buf as well native SHM or
> CMA backed objects. The dma-buf-mgr proposal already allows you to
> handle dma-bufs much the same way during validation than native GEM
> objects.
>

Actually, at first I had implemented a fence helper framework based on
reservation and dma fence to provide easy-use-interface for device
drivers. However, that was wrong implemention: I had not only customized
the dma fence but also not considered dead lock issue. After that, I have
reimplemented it as dmabuf sync to solve dead issue, and at that time, I
realized that we first need to concentrate on the most basic thing: the
fact CPU and CPU, CPU and DMA, or DMA and DMA can access a same buffer, And
the fact simple is the best, and the fact we need not only kernel side but
also user side interfaces. After that, I collected what is the common part
for all subsystems, and I have devised this dmabuf sync framework for it.
I'm not really specialist in Desktop world. So question. isn't the execbuf
used only for

Re: [Intel-gfx] [PATCH] drm/i915: move i915_trace_irq_get() out of the tracing macro

[Chris Wilson]

On Fri, Jun 21, 2013 at 12:15:53PM +0200, Sebastian Andrzej Siewior wrote:
> There is a report on RT about "BUG: scheduling while atomic" because the
> sleeping lock is taken in tracing context. This patch simply moves
> locking operation out of the tracing macro.

No. This enables the IRQ, as well as making a number of
very expensively serialised read, unconditionally.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch] drm/nouveau: off by one in nouveau_drm_vblank_enable()

[Dan Carpenter]

On Wed, Apr 03, 2013 at 01:33:09PM +0200, Maarten Lankhorst wrote:
> Op 03-04-13 10:05, Dan Carpenter schreef:
> > The test here should be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()".
> >
> > Signed-off-by: Dan Carpenter 
> Acked-by: Maarten Lankhorst 

We still need this patch in linux-next.

regards,
dan carpenter

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

re: drm/radeon/kms: get HPD info for connectors

[Dan Carpenter]

Hello Alex Deucher,

The patch eed45b30cd14: "drm/radeon/kms: get HPD info for connectors" 
from Dec 4, 2009, leads to the following warning:
"drivers/gpu/drm/radeon/radeon_atombios.c:950 
radeon_get_atom_connector_info_from_supported_devices_table()
 error: buffer overflow 'supported_devices->info.asConnInfo' 10 <= 15"

drivers/gpu/drm/radeon/radeon_atombios.c
   943  if (frev > 1)
   944  max_device = ATOM_MAX_SUPPORTED_DEVICE;
   945  else
   946  max_device = ATOM_MAX_SUPPORTED_DEVICE_INFO;
   947  
   948  for (i = 0; i < max_device; i++) {
   949  ATOM_CONNECTOR_INFO_I2C ci =
   950  supported_devices->info.asConnInfo[i];

If max_device is set to ATOM_MAX_SUPPORTED_DEVICE then we read beyond
the end of the asConnInfo[] array and crash.

   951  
   952  bios_connectors[i].valid = false;
   953  

regards,
dan carpenter

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Lucas Stach]

Hi Inki,

please refrain from sending HTML Mails, it makes proper quoting without
messing up the layout everywhere pretty hard.

Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae:
[...]

> Yeah, you'll some knowledge and understanding about the API
> you are
> working with to get things right. But I think it's not an
> unreasonable
> thing to expect the programmer working directly with kernel
> interfaces
> to read up on how things work.
> 
> Second thing: I'll rather have *one* consistent API for every
> subsystem,
> even if they differ from each other than having to implement
> this
> syncpoint thing in every subsystem. Remember: a single execbuf
> in DRM
> might reference both GEM objects backed by dma-buf as well
> native SHM or
> CMA backed objects. The dma-buf-mgr proposal already allows
> you to
> handle dma-bufs much the same way during validation than
> native GEM
> objects.
>  
> Actually, at first I had implemented a fence helper framework based on
> reservation and dma fence to provide easy-use-interface for device
> drivers. However, that was wrong implemention: I had not only
> customized the dma fence but also not considered dead lock issue.
> After that, I have reimplemented it as dmabuf sync to solve dead
> issue, and at that time, I realized that we first need to concentrate
> on the most basic thing: the fact CPU and CPU, CPU and DMA, or DMA and
> DMA can access a same buffer, And the fact simple is the best, and the
> fact we need not only kernel side but also user side interfaces. After
> that, I collected what is the common part for all subsystems, and I
> have devised this dmabuf sync framework for it. I'm not really
> specialist in Desktop world. So question. isn't the execbuf used only
> for the GPU? the gpu has dedicated video memory(VRAM) so it needs
> migration mechanism between system memory and the dedicated video
> memory, and also to consider ordering issue while be migrated.
>  

Yeah, execbuf is pretty GPU specific, but I don't see how this matters
for this discussion. Also I don't see a big difference between embedded
and desktop GPUs. Buffer migration is more of a detail here. Both take
command stream that potentially reference other buffers, which might be
native GEM or dma-buf backed objects. Both have to make sure the buffers
are in the right domain (caches cleaned and address mappings set up) and
are available for the desired operation, meaning you have to sync with
other DMA engines and maybe also with CPU.

The only case where sync isn't clearly defined right now by the current
API entrypoints is when you access memory through the dma-buf fallback
mmap support, which might happen with some software processing element
in a video pipeline or something. I agree that we will need a userspace
interface here, but I think this shouldn't be yet another sync object,
but rather more a prepare/fini_cpu_access ioctl on the dma-buf which
hooks into the existing dma-fence and reservation stuff.

> 
> And to get back to my original point: if you have more than
> one task
> operating together on a buffer you absolutely need some kind
> of real IPC
> to sync them up and do something useful. Both you syncpoints
> and the
> proposed dma-fences only protect the buffer accesses to make
> sure
> different task don't stomp on each other. There is nothing in
> there to
> make sure that the output of your pipeline is valid. You have
> to take
> care of that yourself in userspace. I'll reuse your example to
> make it
> clear what I mean:
> 
> Task A Task B
> -- ---
> dma_buf_sync_lock(buf1)
> CPU write buf1
> dma_buf_sync_unlock(buf1)
>   -schedule Task A again---
> dma_buf_sync_lock(buf1)
> CPU write buf1
> dma_buf_sync_unlock(buf1)
> -schedule Task B-
>qbuf(buf1)
> 
> dma_buf_sync_lock(buf1)
>
> 
> This is what can happen if you don't take care of proper
> syncing. Task A
> writes something to the buffer in expectation that Task B will
> take care
> of it, but before Task B even gets scheduled Task A overwrites
> the
> buffer again. Not what you wanted, isn't it?
>  
> Exactly wrong example. I had already mentioned about that. "In case
> that data flow goes from A to B, it needs some kind of IPC between the
> two tasks every time"  So again, your example would have no any
> probl

[PATCH 1/2] staging: drm/imx: use generic irqchip

[Philipp Zabel]

This depends on the patch "genirq: Generic chip: Add linear irq domain support"
and removes the custom IPU irq_chip and irq_domain_ops. Instead, the generic
irq chip implementation is reused.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 90 +
 1 file changed, 26 insertions(+), 64 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index d629d6d..c135c66 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -986,53 +986,6 @@ static void ipu_err_irq_handler(unsigned int irq, struct 
irq_desc *desc)
chained_irq_exit(chip, desc);
 }
 
-static void ipu_ack_irq(struct irq_data *d)
-{
-   struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   irq_hw_number_t irq = d->hwirq;
-
-   ipu_cm_write(ipu, 1 << (irq % 32), IPU_INT_STAT(irq / 32));
-}
-
-static void ipu_unmask_irq(struct irq_data *d)
-{
-   struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   irq_hw_number_t irq = d->hwirq;
-   unsigned long flags;
-   u32 reg;
-
-   spin_lock_irqsave(&ipu->lock, flags);
-
-   reg = ipu_cm_read(ipu, IPU_INT_CTRL(irq / 32));
-   reg |= 1 << (irq % 32);
-   ipu_cm_write(ipu, reg, IPU_INT_CTRL(irq / 32));
-
-   spin_unlock_irqrestore(&ipu->lock, flags);
-}
-
-static void ipu_mask_irq(struct irq_data *d)
-{
-   struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   irq_hw_number_t irq = d->hwirq;
-   unsigned long flags;
-   u32 reg;
-
-   spin_lock_irqsave(&ipu->lock, flags);
-
-   reg = ipu_cm_read(ipu, IPU_INT_CTRL(irq / 32));
-   reg &= ~(1 << (irq % 32));
-   ipu_cm_write(ipu, reg, IPU_INT_CTRL(irq / 32));
-
-   spin_unlock_irqrestore(&ipu->lock, flags);
-}
-
-static struct irq_chip ipu_irq_chip = {
-   .name = "IPU",
-   .irq_ack = ipu_ack_irq,
-   .irq_mask = ipu_mask_irq,
-   .irq_unmask = ipu_unmask_irq,
-};
-
 int ipu_idmac_channel_irq(struct ipu_soc *ipu, struct ipuv3_channel *channel,
enum ipu_channel_irq irq_type)
 {
@@ -1171,32 +1124,39 @@ err_register:
return ret;
 }
 
-static int ipu_irq_map(struct irq_domain *h, unsigned int irq,
-  irq_hw_number_t hw)
-{
-   struct ipu_soc *ipu = h->host_data;
-
-   irq_set_chip_and_handler(irq, &ipu_irq_chip, handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID);
-   irq_set_chip_data(irq, ipu);
-
-   return 0;
-}
-
-const struct irq_domain_ops ipu_irq_domain_ops = {
-   .map = ipu_irq_map,
-   .xlate = irq_domain_xlate_onecell,
-};
 
 static int ipu_irq_init(struct ipu_soc *ipu)
 {
+   struct irq_chip_generic *gc;
+   struct irq_chip_type *ct;
+   int ret, i;
+
ipu->domain = irq_domain_add_linear(ipu->dev->of_node, IPU_NUM_IRQS,
-   &ipu_irq_domain_ops, ipu);
+   &irq_generic_chip_ops, ipu);
if (!ipu->domain) {
dev_err(ipu->dev, "failed to add irq domain\n");
return -ENODEV;
}
 
+   ret = irq_alloc_domain_generic_chips(ipu->domain, 32, 1, "IPU",
+handle_level_irq, 0, IRQF_VALID, 
0);
+   if (ret < 0) {
+   dev_err(ipu->dev, "failed to alloc generic irq chips\n");
+   irq_domain_remove(ipu->domain);
+   return ret;
+   }
+
+   for (i = 0; i < IPU_NUM_IRQS; i += 32) {
+   gc = irq_get_domain_generic_chip(ipu->domain, i);
+   gc->reg_base = ipu->cm_reg;
+   ct = gc->chip_types;
+   ct->chip.irq_ack = irq_gc_ack_set_bit;
+   ct->chip.irq_mask = irq_gc_mask_clr_bit;
+   ct->chip.irq_unmask = irq_gc_mask_set_bit;
+   ct->regs.ack = IPU_INT_STAT(i / 32);
+   ct->regs.mask = IPU_INT_CTRL(i / 32);
+   }
+
irq_set_chained_handler(ipu->irq_sync, ipu_irq_handler);
irq_set_handler_data(ipu->irq_sync, ipu);
irq_set_chained_handler(ipu->irq_err, ipu_err_irq_handler);
@@ -1214,6 +1174,8 @@ static void ipu_irq_exit(struct ipu_soc *ipu)
irq_set_chained_handler(ipu->irq_sync, NULL);
irq_set_handler_data(ipu->irq_sync, NULL);
 
+   /* TODO: remove irq_domain_generic_chips */
+
for (i = 0; i < IPU_NUM_IRQS; i++) {
irq = irq_linear_revmap(ipu->domain, i);
if (irq)
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] staging: drm/imx: use generic irq chip unused field to block out invalid irqs

[Philipp Zabel]

This depends on the patch "genirq: irqchip: Add mask to block out invalid irqs"
and masks out reserved bits using the unused interrupt bitfield.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index c135c66..b470cda 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -1129,6 +1129,16 @@ static int ipu_irq_init(struct ipu_soc *ipu)
 {
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
+   unsigned long unused[IPU_NUM_IRQS / 32] = {
+   0x400100d0, 0xffe000fd,
+   0x400100d0, 0xffe000fd,
+   0x400100d0, 0xffe000fd,
+   0x4077, 0xffe7e1fd,
+   0x23fe, 0x8880fff0,
+   0xf98fe7d0, 0xfff81fff,
+   0x400100d0, 0xffe000fd,
+   0x,
+   };
int ret, i;
 
ipu->domain = irq_domain_add_linear(ipu->dev->of_node, IPU_NUM_IRQS,
@@ -1149,6 +1159,7 @@ static int ipu_irq_init(struct ipu_soc *ipu)
for (i = 0; i < IPU_NUM_IRQS; i += 32) {
gc = irq_get_domain_generic_chip(ipu->domain, i);
gc->reg_base = ipu->cm_reg;
+   gc->unused = unused[i / 32];
ct = gc->chip_types;
ct->chip.irq_ack = irq_gc_ack_set_bit;
ct->chip.irq_mask = irq_gc_mask_clr_bit;
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] IPU generic irq chip

[Philipp Zabel]

Hi,

with linear domain support in the generic irq chip framework, we can drop the
custom irq_chip / irq_domain_ops altogether and use the generic irq chip
implementation instead. The following two patches depend on
"genirq: Generic chip: Add linear irq domain support" and
"genirq: irqchip: Add mask to block out invalid irqs":
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?id=e8bd834f73714378ef110a64287db1b77033c8da

regards
Philipp

---
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 101 ++--
 1 file changed, 37 insertions(+), 64 deletions(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/radeon/kms: get HPD info for connectors

[Alex Deucher]

On Fri, Jun 21, 2013 at 8:25 AM, Dan Carpenter  wrote:
> Hello Alex Deucher,
>
> The patch eed45b30cd14: "drm/radeon/kms: get HPD info for connectors"
> from Dec 4, 2009, leads to the following warning:
> "drivers/gpu/drm/radeon/radeon_atombios.c:950
> radeon_get_atom_connector_info_from_supported_devices_table()
>  error: buffer overflow 'supported_devices->info.asConnInfo' 10 <= 15"
>
> drivers/gpu/drm/radeon/radeon_atombios.c
>943  if (frev > 1)
>944  max_device = ATOM_MAX_SUPPORTED_DEVICE;
>945  else
>946  max_device = ATOM_MAX_SUPPORTED_DEVICE_INFO;
>947
>948  for (i = 0; i < max_device; i++) {
>949  ATOM_CONNECTOR_INFO_I2C ci =
>950  supported_devices->info.asConnInfo[i];
>
> If max_device is set to ATOM_MAX_SUPPORTED_DEVICE then we read beyond
> the end of the asConnInfo[] array and crash.

The array is variably sized based on the vbios version so the array
size in the header is largely meaningless.

Alex

>
>951
>952  bios_connectors[i].valid = false;
>953
>
> regards,
> dan carpenter
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

2013/6/21 Lucas Stach :
> Hi Inki,
>
> please refrain from sending HTML Mails, it makes proper quoting without
> messing up the layout everywhere pretty hard.
>

Sorry about that. I should have used text mode.

> Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae:
> [...]
>
>> Yeah, you'll some knowledge and understanding about the API
>> you are
>> working with to get things right. But I think it's not an
>> unreasonable
>> thing to expect the programmer working directly with kernel
>> interfaces
>> to read up on how things work.
>>
>> Second thing: I'll rather have *one* consistent API for every
>> subsystem,
>> even if they differ from each other than having to implement
>> this
>> syncpoint thing in every subsystem. Remember: a single execbuf
>> in DRM
>> might reference both GEM objects backed by dma-buf as well
>> native SHM or
>> CMA backed objects. The dma-buf-mgr proposal already allows
>> you to
>> handle dma-bufs much the same way during validation than
>> native GEM
>> objects.
>>
>> Actually, at first I had implemented a fence helper framework based on
>> reservation and dma fence to provide easy-use-interface for device
>> drivers. However, that was wrong implemention: I had not only
>> customized the dma fence but also not considered dead lock issue.
>> After that, I have reimplemented it as dmabuf sync to solve dead
>> issue, and at that time, I realized that we first need to concentrate
>> on the most basic thing: the fact CPU and CPU, CPU and DMA, or DMA and
>> DMA can access a same buffer, And the fact simple is the best, and the
>> fact we need not only kernel side but also user side interfaces. After
>> that, I collected what is the common part for all subsystems, and I
>> have devised this dmabuf sync framework for it. I'm not really
>> specialist in Desktop world. So question. isn't the execbuf used only
>> for the GPU? the gpu has dedicated video memory(VRAM) so it needs
>> migration mechanism between system memory and the dedicated video
>> memory, and also to consider ordering issue while be migrated.
>>
>
> Yeah, execbuf is pretty GPU specific, but I don't see how this matters
> for this discussion. Also I don't see a big difference between embedded
> and desktop GPUs. Buffer migration is more of a detail here. Both take
> command stream that potentially reference other buffers, which might be
> native GEM or dma-buf backed objects. Both have to make sure the buffers
> are in the right domain (caches cleaned and address mappings set up) and
> are available for the desired operation, meaning you have to sync with
> other DMA engines and maybe also with CPU.

Yeah, right. Then, in case of desktop gpu, does't it need additional
something to do when a buffer/s is/are migrated from system memory to
video memory domain, or from video memory to system memory domain? I
guess the below members does similar thing, and all other DMA devices
would not need them:
struct fence {
  ...
  unsigned int context, seqno;
  ...
};

And,
   struct seqno_fence {
 ...
 uint32_t seqno_ofs;
 ...
   };

>
> The only case where sync isn't clearly defined right now by the current
> API entrypoints is when you access memory through the dma-buf fallback
> mmap support, which might happen with some software processing element
> in a video pipeline or something. I agree that we will need a userspace
> interface here, but I think this shouldn't be yet another sync object,
> but rather more a prepare/fini_cpu_access ioctl on the dma-buf which
> hooks into the existing dma-fence and reservation stuff.

I think we don't need addition ioctl commands for that. I am thinking
of using existing resources as possible. My idea also is similar in
using the reservation stuff to your idea because my approach also
should use the dma-buf resource. However, My idea is that a user
process, that wants buffer synchronization with the other, sees a sync
object as a file descriptor like dma-buf does. The below shows simple
my idea about it:

ioctl(dmabuf_fd, DMA_BUF_IOC_OPEN_SYNC, &sync);

flock(sync->fd, LOCK_SH); <- LOCK_SH means a shared lock.
CPU access for read
flock(sync->fd, LOCK_UN);

Or

flock(sync->fd, LOCK_EX); <- LOCK_EX means an exclusive lock
CPU access for write
flock(sync->fd, LOCK_UN);

close(sync->fd);

As you know, that's similar to dmabuf export feature.

In addition, a more simple idea,
flock(dmabuf_fd, LOCK_SH/EX);
CPU access for read/write
flock(dmabuf_fd, LOCK_UN);

However, I'm not sure that the above examples could be worked well,
and there are no problems yet: actually, I don't fully understand
flock mechanism, so looking into it.

>
>>
>> And to get back to my original point: if you have more than
>> one task

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Jerome Glisse]

On Fri, Jun 21, 2013 at 12:55 PM, Inki Dae  wrote:
> 2013/6/21 Lucas Stach :
>> Hi Inki,
>>
>> please refrain from sending HTML Mails, it makes proper quoting without
>> messing up the layout everywhere pretty hard.
>>
>
> Sorry about that. I should have used text mode.
>
>> Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae:
>> [...]
>>
>>> Yeah, you'll some knowledge and understanding about the API
>>> you are
>>> working with to get things right. But I think it's not an
>>> unreasonable
>>> thing to expect the programmer working directly with kernel
>>> interfaces
>>> to read up on how things work.
>>>
>>> Second thing: I'll rather have *one* consistent API for every
>>> subsystem,
>>> even if they differ from each other than having to implement
>>> this
>>> syncpoint thing in every subsystem. Remember: a single execbuf
>>> in DRM
>>> might reference both GEM objects backed by dma-buf as well
>>> native SHM or
>>> CMA backed objects. The dma-buf-mgr proposal already allows
>>> you to
>>> handle dma-bufs much the same way during validation than
>>> native GEM
>>> objects.
>>>
>>> Actually, at first I had implemented a fence helper framework based on
>>> reservation and dma fence to provide easy-use-interface for device
>>> drivers. However, that was wrong implemention: I had not only
>>> customized the dma fence but also not considered dead lock issue.
>>> After that, I have reimplemented it as dmabuf sync to solve dead
>>> issue, and at that time, I realized that we first need to concentrate
>>> on the most basic thing: the fact CPU and CPU, CPU and DMA, or DMA and
>>> DMA can access a same buffer, And the fact simple is the best, and the
>>> fact we need not only kernel side but also user side interfaces. After
>>> that, I collected what is the common part for all subsystems, and I
>>> have devised this dmabuf sync framework for it. I'm not really
>>> specialist in Desktop world. So question. isn't the execbuf used only
>>> for the GPU? the gpu has dedicated video memory(VRAM) so it needs
>>> migration mechanism between system memory and the dedicated video
>>> memory, and also to consider ordering issue while be migrated.
>>>
>>
>> Yeah, execbuf is pretty GPU specific, but I don't see how this matters
>> for this discussion. Also I don't see a big difference between embedded
>> and desktop GPUs. Buffer migration is more of a detail here. Both take
>> command stream that potentially reference other buffers, which might be
>> native GEM or dma-buf backed objects. Both have to make sure the buffers
>> are in the right domain (caches cleaned and address mappings set up) and
>> are available for the desired operation, meaning you have to sync with
>> other DMA engines and maybe also with CPU.
>
> Yeah, right. Then, in case of desktop gpu, does't it need additional
> something to do when a buffer/s is/are migrated from system memory to
> video memory domain, or from video memory to system memory domain? I
> guess the below members does similar thing, and all other DMA devices
> would not need them:
> struct fence {
>   ...
>   unsigned int context, seqno;
>   ...
> };
>
> And,
>struct seqno_fence {
>  ...
>  uint32_t seqno_ofs;
>  ...
>};
>
>>
>> The only case where sync isn't clearly defined right now by the current
>> API entrypoints is when you access memory through the dma-buf fallback
>> mmap support, which might happen with some software processing element
>> in a video pipeline or something. I agree that we will need a userspace
>> interface here, but I think this shouldn't be yet another sync object,
>> but rather more a prepare/fini_cpu_access ioctl on the dma-buf which
>> hooks into the existing dma-fence and reservation stuff.
>
> I think we don't need addition ioctl commands for that. I am thinking
> of using existing resources as possible. My idea also is similar in
> using the reservation stuff to your idea because my approach also
> should use the dma-buf resource. However, My idea is that a user
> process, that wants buffer synchronization with the other, sees a sync
> object as a file descriptor like dma-buf does. The below shows simple
> my idea about it:
>
> ioctl(dmabuf_fd, DMA_BUF_IOC_OPEN_SYNC, &sync);
>
> flock(sync->fd, LOCK_SH); <- LOCK_SH means a shared lock.
> CPU access for read
> flock(sync->fd, LOCK_UN);
>
> Or
>
> flock(sync->fd, LOCK_EX); <- LOCK_EX means an exclusive lock
> CPU access for write
> flock(sync->fd, LOCK_UN);
>
> close(sync->fd);
>
> As you know, that's similar to dmabuf export feature.
>
> In addition, a more simple idea,
> flock(dmabuf_fd, LOCK_SH/EX);
> CPU access for read/write
> flock(dmabuf_fd, LOCK_UN);
>
> However, I'm not sure that the above examples could be worke

[PATCH V2 0/7] drm/tilcdc: bug fixes, mode selection improvements

[Darren Etheridge]

The series of patches that follow are intended to address issues that
have been found in the tilcdc drm driver. The patchset enables support
for screen resolutions with horizontal resolutions greater than 1024
pixels.  The patchset also addresses a limitation where certain
monitor timings would overflow LCD controller timing registers causing
either no monitor signal or a very corrupted display.  This patchset
will stop monitor modes from being reported as valid if the lcd
controller cannot support them.  

V2:
Fix typos in commit messages
Add a patch that enables runtime modesetting to work correctly
Fix an issue where the slave encoder can initialize before the i2c
subsystem, resulting in no displays being configured.

Applies cleanly on drm-next.

Darren Etheridge (6):
  drm/tilcdc: support pixel widths greater than 1024
  drm/tilcdc: adding some more devicetree config
  drm/tilcdc: fixing off by one errors found on analyzer
  drm/tilcdc: adding more guards to prevent selection of invalid modes
  drm/tilcdc: whitespace fixes and tidyup
  drm/tilcdc fixing i2c/slave initialization race

Pantelis Antoniou (1):
  drm/tilcdc: Clear bits of register we're going to set.

 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |8 ++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  117 +--
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|   25 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   24 -
 drivers/gpu/drm/tilcdc/tilcdc_regs.h   |1 +
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  |   53 +
 6 files changed, 189 insertions(+), 39 deletions(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2 1/7] drm/tilcdc: support pixel widths greater than 1024

[Darren Etheridge]

TI LCD controller version 2 has an extended eleventh
bit that enables horizontal resolutions greater than
1024 pixels to be specified (upto 2048).  This patch
adds support for setting this bit on LCDC V2.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |   15 +++
 drivers/gpu/drm/tilcdc/tilcdc_regs.h |1 +
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 5dd3c7d..84fdf25 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -310,6 +310,21 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
((vsw & 0x3f) << 10);
tilcdc_write(dev, LCDC_RASTER_TIMING_1_REG, reg);
 
+   /*
+* be sure to set Bit 10 for the V2 LCDC controller,
+* otherwise limited to 1024 pixels width, stopping
+* 1920x1080 being suppoted.
+*/
+   if (priv->rev == 2) {
+   if ((mode->vdisplay - 1) & 0x400) {
+   tilcdc_set(dev, LCDC_RASTER_TIMING_2_REG,
+   LCDC_LPP_B10);
+   } else {
+   tilcdc_clear(dev, LCDC_RASTER_TIMING_2_REG,
+   LCDC_LPP_B10);
+   }
+   }
+
/* Configure display type: */
reg = tilcdc_read(dev, LCDC_RASTER_CTRL_REG) &
~(LCDC_TFT_MODE | LCDC_MONO_8BIT_MODE | LCDC_MONOCHROME_MODE |
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
index 17fd1b4..1bf5e25 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
@@ -80,6 +80,7 @@
 #define LCDC_INVERT_PIXEL_CLOCK  BIT(22)
 #define LCDC_INVERT_HSYNCBIT(21)
 #define LCDC_INVERT_VSYNCBIT(20)
+#define LCDC_LPP_B10 BIT(26)
 
 /* LCDC Block */
 #define LCDC_PID_REG 0x0
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2 2/7] drm/tilcdc: adding some more devicetree config

[Darren Etheridge]

Adding support for max-pixelclock and max-width device tree
entries. As some devices that use the tilcdc hardware module
have restrictions on the allowed/tested values.  Also update DT
bindings document to reflect new parameters.

Signed-off-by: Darren Etheridge 
---
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |8 +++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |   23 ++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|   15 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   22 +++
 4 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index e5f1301..fff10da 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -10,6 +10,14 @@ Recommended properties:
services interrupts for this device.
  - ti,hwmods: Name of the hwmod associated to the LCDC
 
+Optional properties:
+ - max-bandwidth: The maximum pixels per second that the memory
+   interface / lcd controller combination can sustain
+ - max-width: The maximum horizontal pixel width supported by
+   the lcd controller.
+ - max-pixelclock: The maximum pixel clock that can be supported
+   by the lcd controller in KHz.
+
 Example:
 
fb: fb@4830e000 {
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 84fdf25..05f2b14 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -448,10 +448,29 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
if (mode->vdisplay > 2048)
return MODE_VIRTUAL_Y;
 
+   /*
+* some devices have a maximum allowed pixel clock
+* configured from the DT
+*/
+   if (mode->clock > priv->max_pixelclock) {
+   DBG("Pruning mode, pixel clock too high");
+   return MODE_CLOCK_HIGH;
+   }
+
+   /*
+* some devices further limit the max horizontal resolution
+* configured from the DT
+*/
+   if (mode->hdisplay > priv->max_width)
+   return MODE_BAD_WIDTH;
+
/* filter out modes that would require too much memory bandwidth: */
-   bandwidth = mode->hdisplay * mode->vdisplay * drm_mode_vrefresh(mode);
-   if (bandwidth > priv->max_bandwidth)
+   bandwidth = mode->hdisplay * mode->vdisplay *
+   drm_mode_vrefresh(mode);
+   if (bandwidth > priv->max_bandwidth) {
+   DBG("Pruning mode, exceeds defined bandwidth limit");
return MODE_BAD;
+   }
 
return MODE_OK;
 }
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index f2a6528..1e8f273 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -212,7 +212,20 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
 #endif
 
if (of_property_read_u32(node, "max-bandwidth", &priv->max_bandwidth))
-   priv->max_bandwidth = 1280 * 1024 * 60;
+   priv->max_bandwidth = TILCDC_DEFAULT_MAX_BANDWIDTH;
+
+   DBG("Maximum Bandwidth Value %d", priv->max_bandwidth);
+
+   if (of_property_read_u32(node, "ti,max-width", &priv->max_width))
+   priv->max_width = TILCDC_DEFAULT_MAX_WIDTH;
+
+   DBG("Maximum Horizontal Pixel Width Value %dpixels", priv->max_width);
+
+   if (of_property_read_u32(node, "ti,max-pixelclock",
+   &priv->max_pixelclock))
+   priv->max_pixelclock = TILCDC_DEFAULT_MAX_PIXELCLOCK;
+
+   DBG("Maximum Pixel Clock Value %dKHz", priv->max_pixelclock);
 
pm_runtime_enable(dev->dev);
 
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 0906843..66df316 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -34,6 +34,18 @@
 #include 
 #include 
 
+/* Defaulting to pixel clock defined on AM335x */
+#define TILCDC_DEFAULT_MAX_PIXELCLOCK  126000
+/* Defaulting to max width as defined on AM335x */
+#define TILCDC_DEFAULT_MAX_WIDTH  2048
+/*
+ * This may need some tweaking, but want to allow at least 1280x1024@60
+ * with optimized DDR & EMIF settings tweaked 1920x1080@24 appears to
+ * be supportable
+ */
+#define TILCDC_DEFAULT_MAX_BANDWIDTH  (1280*1024*60)
+
+
 struct tilcdc_drm_private {
void __iomem *mmio;
 
@@ -43,6 +55,16 @@ struct tilcdc_drm_private {
 
/* don't attempt resolutions w/ higher W * H * Hz: */
uint32_t max_bandwidth;
+   /*
+* Pixel Clock will be restricted to some value as
+* defined in the device datasheet measured in KHz
+*/
+   uint32_t max_pixelclock;
+   /*
+* Max allowable width is limited on a per device basis
+* meas

[PATCH V2 4/7] drm/tilcdc: adding more guards to prevent selection of invalid modes

[Darren Etheridge]

The tilcdc has a number of limitations for the allowed sizes of
the various adjustable timing parameter.  Some modes are outside
of these timings.  This commit will prune modes that report timings
that will overflow the allowed sizes in the tilcdc.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |   46 ++
 1 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 4455a41..283e0a6 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -442,7 +442,12 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
 {
struct tilcdc_drm_private *priv = crtc->dev->dev_private;
unsigned int bandwidth;
+   uint32_t hbp, hfp, hsw, vbp, vfp, vsw;
 
+   /*
+* check to see if the width is within the range that
+* the LCD Controller physically supports
+*/
if (mode->hdisplay > tilcdc_crtc_max_width(crtc))
return MODE_VIRTUAL_X;
 
@@ -453,6 +458,47 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
if (mode->vdisplay > 2048)
return MODE_VIRTUAL_Y;
 
+   DBG("Processing mode %dx%d@%d with pixel clock %d",
+   mode->hdisplay, mode->vdisplay,
+   drm_mode_vrefresh(mode), mode->clock);
+
+   hbp = mode->htotal - mode->hsync_end;
+   hfp = mode->hsync_start - mode->hdisplay;
+   hsw = mode->hsync_end - mode->hsync_start;
+   vbp = mode->vtotal - mode->vsync_end;
+   vfp = mode->vsync_start - mode->vdisplay;
+   vsw = mode->vsync_end - mode->vsync_start;
+
+   if ((hbp-1) & ~0x3ff) {
+   DBG("Pruning mode: Horizontal Back Porch out of range");
+   return MODE_HBLANK_WIDE;
+   }
+
+   if ((hfp-1) & ~0x3ff) {
+   DBG("Pruning mode: Horizontal Front Porch out of range");
+   return MODE_HBLANK_WIDE;
+   }
+
+   if ((hsw-1) & ~0x3ff) {
+   DBG("Pruning mode: Horizontal Sync Width out of range");
+   return MODE_HSYNC_WIDE;
+   }
+
+   if (vbp & ~0xff) {
+   DBG("Pruning mode: Vertical Back Porch out of range");
+   return MODE_VBLANK_WIDE;
+   }
+
+   if (vfp & ~0xff) {
+   DBG("Pruning mode: Vertical Front Porch out of range");
+   return MODE_VBLANK_WIDE;
+   }
+
+   if ((vsw-1) & ~0x3f) {
+   DBG("Pruning mode: Vertical Sync Width out of range");
+   return MODE_VSYNC_WIDE;
+   }
+
/*
 * some devices have a maximum allowed pixel clock
 * configured from the DT
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2 3/7] drm/tilcdc: fixing off by one errors found on analyzer

[Darren Etheridge]

When hooking up to an HDMI analyzer noticed some timings were
off by one.  Referring to the hardware technical reference manual
for the lcd controller some of the timing registers use 0 to
represent 1.  This patch addresses that issue.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |   19 ---
 1 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 05f2b14..4455a41 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -289,17 +289,22 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
reg = tilcdc_read(dev, LCDC_RASTER_TIMING_2_REG) & ~0x000fff00;
reg |= LCDC_AC_BIAS_FREQUENCY(info->ac_bias) |
LCDC_AC_BIAS_TRANSITIONS_PER_INT(info->ac_bias_intrpt);
+
+   /*
+* subtract one from hfp, hbp, hsw because the hardware uses
+* a value of 0 as 1
+*/
if (priv->rev == 2) {
-   reg |= (hfp & 0x300) >> 8;
-   reg |= (hbp & 0x300) >> 4;
-   reg |= (hsw & 0x3c0) << 21;
+   reg |= ((hfp-1) & 0x300) >> 8;
+   reg |= ((hbp-1) & 0x300) >> 4;
+   reg |= ((hsw-1) & 0x3c0) << 21;
}
tilcdc_write(dev, LCDC_RASTER_TIMING_2_REG, reg);
 
reg = (((mode->hdisplay >> 4) - 1) << 4) |
-   ((hbp & 0xff) << 24) |
-   ((hfp & 0xff) << 16) |
-   ((hsw & 0x3f) << 10);
+   (((hbp-1) & 0xff) << 24) |
+   (((hfp-1) & 0xff) << 16) |
+   (((hsw-1) & 0x3f) << 10);
if (priv->rev == 2)
reg |= (((mode->hdisplay >> 4) - 1) & 0x40) >> 3;
tilcdc_write(dev, LCDC_RASTER_TIMING_0_REG, reg);
@@ -307,7 +312,7 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
reg = ((mode->vdisplay - 1) & 0x3ff) |
((vbp & 0xff) << 24) |
((vfp & 0xff) << 16) |
-   ((vsw & 0x3f) << 10);
+   (((vsw-1) & 0x3f) << 10);
tilcdc_write(dev, LCDC_RASTER_TIMING_1_REG, reg);
 
/*
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2 5/7] drm/tilcdc: whitespace fixes and tidyup

[Darren Etheridge]

keeping checkpatch happy.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 283e0a6..6118651 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -42,7 +42,8 @@ struct tilcdc_crtc {
 
 static void unref_worker(struct work_struct *work)
 {
-   struct tilcdc_crtc *tilcdc_crtc = container_of(work, struct 
tilcdc_crtc, work);
+   struct tilcdc_crtc *tilcdc_crtc =
+   container_of(work, struct tilcdc_crtc, work);
struct drm_device *dev = tilcdc_crtc->base.dev;
struct drm_framebuffer *fb;
 
@@ -55,10 +56,12 @@ static void unref_worker(struct work_struct *work)
 static void set_scanout(struct drm_crtc *crtc, int n)
 {
static const uint32_t base_reg[] = {
-   LCDC_DMA_FB_BASE_ADDR_0_REG, 
LCDC_DMA_FB_BASE_ADDR_1_REG,
+   LCDC_DMA_FB_BASE_ADDR_0_REG,
+   LCDC_DMA_FB_BASE_ADDR_1_REG,
};
static const uint32_t ceil_reg[] = {
-   LCDC_DMA_FB_CEILING_ADDR_0_REG, 
LCDC_DMA_FB_CEILING_ADDR_1_REG,
+   LCDC_DMA_FB_CEILING_ADDR_0_REG,
+   LCDC_DMA_FB_CEILING_ADDR_1_REG,
};
static const uint32_t stat[] = {
LCDC_END_OF_FRAME0, LCDC_END_OF_FRAME1,
@@ -194,7 +197,8 @@ static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int 
mode)
tilcdc_crtc->frame_done = false;
stop(crtc);
 
-   /* if necessary wait for framedone irq which will still come
+   /*
+* if necessary wait for framedone irq which will still come
 * before putting things to sleep..
 */
if (priv->rev == 2) {
@@ -504,7 +508,7 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
 * configured from the DT
 */
if (mode->clock > priv->max_pixelclock) {
-   DBG("Pruning mode, pixel clock too high");
+   DBG("Pruning mode: pixel clock too high");
return MODE_CLOCK_HIGH;
}
 
@@ -519,7 +523,7 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
bandwidth = mode->hdisplay * mode->vdisplay *
drm_mode_vrefresh(mode);
if (bandwidth > priv->max_bandwidth) {
-   DBG("Pruning mode, exceeds defined bandwidth limit");
+   DBG("Pruning mode: exceeds defined bandwidth limit");
return MODE_BAD;
}
 
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2 6/7] drm/tilcdc fixing i2c/slave initialization race

[Darren Etheridge]

In certain senarios drm will initialize before i2c this means that i2c
slave devices like the nxp tda998x will fail to be probed.  This patch
detects this condition then defers the probe of the slave device and
the tilcdc main driver.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c   |   10 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h   |2 +-
 drivers/gpu/drm/tilcdc/tilcdc_slave.c |   53 ++---
 3 files changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 1e8f273..40b71da 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -26,6 +26,7 @@
 #include "drm_fb_helper.h"
 
 static LIST_HEAD(module_list);
+static bool slave_probing;
 
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
@@ -41,6 +42,11 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
list_del(&mod->list);
 }
 
+void tilcdc_slave_probedefer(bool defered)
+{
+   slave_probing = defered;
+}
+
 static struct of_device_id tilcdc_of_match[];
 
 static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
@@ -580,6 +586,10 @@ static int tilcdc_pdev_probe(struct platform_device *pdev)
return -ENXIO;
}
 
+   /* defer probing if slave is in deferred probing */
+   if (slave_probing == true)
+   return -EPROBE_DEFER;
+
return drm_platform_init(&tilcdc_driver, pdev);
 }
 
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 66df316..0938036 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -117,7 +117,7 @@ struct tilcdc_module {
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs);
 void tilcdc_module_cleanup(struct tilcdc_module *mod);
-
+void tilcdc_slave_probedefer(bool defered);
 
 /* Panel config that needs to be set in the crtc, but is not coming from
  * the mode timings.  The display module is expected to call
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 8bf4fd1..dfffaf0 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -298,6 +298,7 @@ static int slave_probe(struct platform_device *pdev)
struct tilcdc_module *mod;
struct pinctrl *pinctrl;
uint32_t i2c_phandle;
+   struct i2c_adapter *slavei2c;
int ret = -EINVAL;
 
/* bail out early if no DT data: */
@@ -306,44 +307,48 @@ static int slave_probe(struct platform_device *pdev)
return -ENXIO;
}
 
-   slave_mod = kzalloc(sizeof(*slave_mod), GFP_KERNEL);
-   if (!slave_mod)
-   return -ENOMEM;
-
-   mod = &slave_mod->base;
-
-   tilcdc_module_init(mod, "slave", &slave_module_ops);
-
-   pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
-   if (IS_ERR(pinctrl))
-   dev_warn(&pdev->dev, "pins are not configured\n");
-
+   /* Bail out early if i2c not specified */
if (of_property_read_u32(node, "i2c", &i2c_phandle)) {
dev_err(&pdev->dev, "could not get i2c bus phandle\n");
-   goto fail;
+   return ret;
}
 
-   mod->preferred_bpp = slave_info.bpp;
-
i2c_node = of_find_node_by_phandle(i2c_phandle);
if (!i2c_node) {
dev_err(&pdev->dev, "could not get i2c bus node\n");
-   goto fail;
+   return ret;
}
 
-   slave_mod->i2c = of_find_i2c_adapter_by_node(i2c_node);
-   if (!slave_mod->i2c) {
+   /* but defer the probe if it can't be initialized it might come later */
+   slavei2c = of_find_i2c_adapter_by_node(i2c_node);
+   of_node_put(i2c_node);
+
+   if (!slavei2c) {
+   ret = -EPROBE_DEFER;
+   tilcdc_slave_probedefer(true);
dev_err(&pdev->dev, "could not get i2c\n");
-   goto fail;
+   return ret;
}
 
-   of_node_put(i2c_node);
+   slave_mod = kzalloc(sizeof(*slave_mod), GFP_KERNEL);
+   if (!slave_mod)
+   return -ENOMEM;
 
-   return 0;
+   mod = &slave_mod->base;
 
-fail:
-   slave_destroy(mod);
-   return ret;
+   mod->preferred_bpp = slave_info.bpp;
+
+   slave_mod->i2c = slavei2c;
+
+   tilcdc_module_init(mod, "slave", &slave_module_ops);
+
+   pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+   if (IS_ERR(pinctrl))
+   dev_warn(&pdev->dev, "pins are not configured\n");
+
+   tilcdc_slave_probedefer(false);
+
+   return 0;
 }
 
 static int slave_remove(struct platform_device *pdev)
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH V2 7/7] drm/tilcdc: Clear bits of register we're going to set.

[Darren Etheridge]

From: Pantelis Antoniou 

Bits weren't cleared so resolution changes didn't work.

Signed-off-by: Pantelis Antoniou 
Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 6118651..eb06f70 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -299,6 +299,8 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
 * a value of 0 as 1
 */
if (priv->rev == 2) {
+   /* clear bits we're going to set */
+   reg &= ~0x7833;
reg |= ((hfp-1) & 0x300) >> 8;
reg |= ((hbp-1) & 0x300) >> 4;
reg |= ((hsw-1) & 0x3c0) << 21;
-- 
1.7.0.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 mapping large (3MB) scatter list, hitting limits on certain IOMMUs that can only map contingous regions up to 2MB.

[Konrad Rzeszutek Wilk]

Hey,

I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
(3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-rc6
I found that i915 would halt with a 

[drm:intel_pipe_set_base] *ERROR* pin & fence failed
[drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28

after a bit of debugging (see patch below) I traced it down
to the fact that the scatter list that is provided at the end has
a huge (3MB) page. I am wondering if anybody knows what patch might
have introduced it to grab such a large memory segment?

The other thing I am wondering is if there are some fallbacks when the
underlaying IOMMU can't deal with a request for contingous regions
that are more than 2MB?

Thanks.

>From a681a4adb4738c32cb1acdf6f5161bf877816b01 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Fri, 21 Jun 2013 11:17:55 -0400
Subject: [PATCH] dbug: print scatterlist.

[ cut here ]
WARNING: at drivers/gpu/drm/i915/i915_gem_gtt.c:418 
i915_gem_gtt_prepare_object+0x180/0x200()
10 but got 0
Modules linked in:
 crc32_pclmul sdhci_pci crc32c_intel sdhci mmc_core ghash_clmulni_intel
CPU: 0 PID: 216 Comm: plymouthd Not tainted 3.10.0-rc6+ #16
Hardware name: LENOVO 2325DV4/2325DV4, BIOS G2ET86WW (2.06 ) 11/13/2012
 0009 8801fa42d958 816e6d89 8801fa42d998
 8105d2b0 8801fa42d988  8801fb0f4d80
 81c172e0 8801fa76f000 000a 8801fa42d9f8
Call Trace:
 [] dump_stack+0x19/0x1b
 [] warn_slowpath_common+0x70/0xa0
 [] warn_slowpath_fmt+0x46/0x50
 [] i915_gem_gtt_prepare_object+0x180/0x200
 [] i915_gem_object_pin+0x321/0x670
 [] i915_gem_object_pin_to_display_plane+0x81/0x190
 [] intel_pin_and_fence_fb_obj+0x85/0x1a0
 [] intel_pipe_set_base+0x7c/0x220
 [] intel_crtc_set_config+0x89e/0x990
 [] drm_mode_set_config_internal+0x2e/0x60
 [] drm_mode_setcrtc+0xfb/0x620
 [] ? kmem_cache_alloc_trace+0x39/0x1f0
 [] ? drm_vm_open_locked+0x57/0x90
 [] drm_ioctl+0x549/0x680
 [] ? drm_mode_setplane+0x3b0/0x3b0
 [] do_vfs_ioctl+0x97/0x580
 [] ? inode_has_perm.isra.32.constprop.62+0x2a/0x30
 [] ? file_has_perm+0x97/0xb0
 [] SyS_ioctl+0x91/0xb0
 [] tracesys+0xdd/0xe2
---[ end trace 7b6adc5450d9a9e1 ]---
i915 :00:02.0: i915_gem_gtt_prepare_object: Mapping 10 pages, mapped: 0
[0] virT:8801fd37c000 dma: 1fd37c000, size:4096
[1] virT:8801fd37b000 dma: 1fd37b000, size:4096
[2] virT:8801fd37a000 dma: 1fd37a000, size:4096
[3] virT:8801fd378000 dma: 1fd378000, size:4096
[4] virT:8801fd131000 dma: 1fd131000, size:4096
[5] virT:880200c36000 dma: 200c36000, size:4096
[6] virT:8801fd1a4000 dma: 1fd1a4000, size:69632
[7] virT:8801fd3bb000 dma: 1fd3bb000, size:4096
[8] virT:8801fd3c dma: 1fd3c, size:262144
[9] virT:8801f940 dma: 1f940, size:3866624
[drm] 3011: ret:-28
[drm] 3540: ret:-28
[drm] 3364: ret:-28
[drm:intel_pin_and_fence_fb_obj] *ERROR* i915_gem_object_pin_to_display_plane 
failed: -28
[drm:intel_pipe_set_base] *ERROR* pin & fence failed
[drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/i915/i915_drv.c |  6 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c | 28 +---
 2 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8411942..141c6fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -133,6 +133,12 @@ module_param_named(coherent, use_coherent, int, 0600);
 MODULE_PARM_DESC(use_coherent,
 "Use coherent DMA API calls (default: false)");
 
+int i915_sgl __read_mostly = 0;
+module_param_named(sgl, i915_sgl, int, 0600);
+MODULE_PARM_DESC(sgl,
+"Print scatterlist SG's when DMA mapping them (default: 
false)");
+
+
 static struct drm_driver driver;
 extern int intel_agp_enabled;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index acb3b3f..292179c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -28,6 +28,7 @@
 #include "i915_trace.h"
 #include "intel_drv.h"
 
+extern int use_coherent;
 typedef uint32_t gen6_gtt_pte_t;
 
 /* PPGTT stuff */
@@ -403,15 +404,36 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
 
i915_gem_chipset_flush(dev);
 }
-
+extern int i915_sgl;
 int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj)
 {
+   int elem;
if (obj->has_dma_mapping)
return 0;
 
-   if (!dma_map_sg(&obj->base.dev->pdev->dev,
+   elem = dma_map_sg(&obj->base.dev->pdev->dev,
obj->pages->sgl, obj->pages->nents,
-   PCI_DMA_BIDIRECTIONAL))
+   PCI_DMA_BIDIRECTIONAL);
+
+   WARN(elem == 0, "%d but got %d", obj->pages->nents, elem);
+
+   if (i915_sgl && obj->pages && o

[PATCH v2 0/8] ARM: dts: exynos5420: add support for hdmi subsystem

[Rahul Sharma]

Common properties for I2C and Hdmi Subsystem is moved to exynos5
dtsi file. It also adds Device tree nodes and clocks information
for exynos5420 SoC. It adds pinctrl node for hdmi hpd gpio and
update binding documents.

This patch is based on v3.11-next/soc-exynos5420-pinctrl branch
at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git

device tree binding document for hdmi compatible type is update at
http://www.spinics.net/lists/dri-devel/msg39987.html

v2:
1) Added patch for moving common i2c properties to exynos5.dtsi
2) Added patch for moving common hdmi, mixer properties to exynos5.dtsi
3) moved hpd pinctrl node to board file.
4) Added Sachin's patch to update binding document for hdmi with hpd
information.

Andrew Bresticker (1):
  ARM: dts: exynos5420: add i2c device nodes

Rahul Sharma (6):
  ARM: dts: exynos5250: move common i2c properties to exynos5 dtsi
  ARM: dts: exynos5250: move common hdmi properties to exynos5 dtsi
  ARM: dts: exynos5420: add dt nodes for hdmi subsystem
  ARM: dts: exynos5420: add clocks for hdmi subsystem
  ARM: dts: exynos5420: add hdmi hpd gpio pinctrl node
  of/documentation: update with clock information for exynos hdmi
subsystem

Sachin Kamat (1):
  of/documentation: Update hpd gpio property for exynos_hdmi

 .../devicetree/bindings/video/exynos_hdmi.txt  |   20 ++--
 .../devicetree/bindings/video/exynos_mixer.txt |4 ++
 arch/arm/boot/dts/cros5250-common.dtsi |2 +-
 arch/arm/boot/dts/exynos5.dtsi |   48 
 arch/arm/boot/dts/exynos5250-arndale.dts   |8 +++-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |   10 +++-
 arch/arm/boot/dts/exynos5250-snow.dts  |8 
 arch/arm/boot/dts/exynos5250.dtsi  |   28 +---
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |   31 +
 arch/arm/boot/dts/exynos5420.dtsi  |   46 +++
 10 files changed, 171 insertions(+), 34 deletions(-)

-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/8] ARM: dts: exynos5250: move common i2c properties to exynos5 dtsi

[Rahul Sharma]

I2C nodes shares many properties across exynos5 SoCs (exynos5250
and exyno5420). Common code is moved to exynos5.dtsi which is
included in exyno5250 and exynos5420 SoC files.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5.dtsi|   36 +
 arch/arm/boot/dts/exynos5250-arndale.dts  |1 +
 arch/arm/boot/dts/exynos5250-smdk5250.dts |3 +++
 arch/arm/boot/dts/exynos5250.dtsi |   20 
 4 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index f65e124..1ae179e 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -108,4 +108,40 @@
interrupts = <0 42 0>;
status = "disabled";
};
+
+   i2c_0: i2c@12C6 {
+   compatible = "samsung,s3c2440-i2c";
+   reg = <0x12C6 0x100>;
+   interrupts = <0 56 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c_1: i2c@12C7 {
+   compatible = "samsung,s3c2440-i2c";
+   reg = <0x12C7 0x100>;
+   interrupts = <0 57 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c_2: i2c@12C8 {
+   compatible = "samsung,s3c2440-i2c";
+   reg = <0x12C8 0x100>;
+   interrupts = <0 58 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c_3: i2c@12C9 {
+   compatible = "samsung,s3c2440-i2c";
+   reg = <0x12C9 0x100>;
+   interrupts = <0 59 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index abc7272..5c7dd6d 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -30,6 +30,7 @@
};
 
i2c@12C6 {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <2>;
samsung,i2c-slave-addr = <0x66>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 35a66de..d3da369 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -28,6 +28,7 @@
};
 
i2c@12C6 {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <2>;
 
@@ -62,6 +63,7 @@
};
 
i2c@12C7 {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <2>;
 
@@ -101,6 +103,7 @@
};
 
i2c@12C8 {
+   status = "okay";
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
 
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index d04ab0a..baf6f88 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -217,11 +217,6 @@
};
 
i2c_0: i2c@12C6 {
-   compatible = "samsung,s3c2440-i2c";
-   reg = <0x12C6 0x100>;
-   interrupts = <0 56 0>;
-   #address-cells = <1>;
-   #size-cells = <0>;
clocks = <&clock 294>;
clock-names = "i2c";
pinctrl-names = "default";
@@ -229,11 +224,6 @@
};
 
i2c_1: i2c@12C7 {
-   compatible = "samsung,s3c2440-i2c";
-   reg = <0x12C7 0x100>;
-   interrupts = <0 57 0>;
-   #address-cells = <1>;
-   #size-cells = <0>;
clocks = <&clock 295>;
clock-names = "i2c";
pinctrl-names = "default";
@@ -241,11 +231,6 @@
};
 
i2c_2: i2c@12C8 {
-   compatible = "samsung,s3c2440-i2c";
-   reg = <0x12C8 0x100>;
-   interrupts = <0 58 0>;
-   #address-cells = <1>;
-   #size-cells = <0>;
clocks = <&clock 296>;
clock-names = "i2c";
pinctrl-names = "default";
@@ -253,11 +238,6 @@
};
 
i2c_3: i2c@12C9 {
-   compatible = "samsung,s3c2440-i2c";
-   reg = <0x12C9 0x100>;
-   interrupts = <0 59 0>;
-   #address-cells = <1>;
-   #size-cells = <0>;
clocks = <&clock 297>;
clock-names = "i2c";
pinctrl-names = "default";
-- 
1.7.10.4

__

[PATCH v2 2/8] ARM: dts: exynos5420: add i2c device nodes

[Rahul Sharma]

From: Andrew Bresticker 

This adds device-tree nodes for the i2c busses on Exynos
5420 platforms.

Signed-off-by: Andrew Bresticker 
Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5420.dtsi |   32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8c54c4b..953f877 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -24,6 +24,10 @@
pinctrl2 = &pinctrl_2;
pinctrl3 = &pinctrl_3;
pinctrl4 = &pinctrl_4;
+   i2c0 = &i2c_0;
+   i2c1 = &i2c_1;
+   i2c2 = &i2c_2;
+   i2c3 = &i2c_3;
};
 
cpus {
@@ -145,4 +149,32 @@
clocks = <&clock 260>, <&clock 131>;
clock-names = "uart", "clk_uart_baud0";
};
+
+   i2c_0: i2c@12C6 {
+   clocks = <&clock 261>;
+   clock-names = "i2c";
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c0_bus>;
+   };
+
+   i2c_1: i2c@12C7 {
+   clocks = <&clock 262>;
+   clock-names = "i2c";
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_bus>;
+   };
+
+   i2c_2: i2c@12C8 {
+   clocks = <&clock 263>;
+   clock-names = "i2c";
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c2_bus>;
+   };
+
+   i2c_3: i2c@12C9 {
+   clocks = <&clock 264>;
+   clock-names = "i2c";
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c3_bus>;
+   };
 };
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Russell King - ARM Linux]

On Thu, Jun 20, 2013 at 09:47:07AM +0200, Lucas Stach wrote:
> Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
> > 
> > > -Original Message-
> > > From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
> > > [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
> > > Behalf Of Russell King - ARM Linux
> > > Sent: Thursday, June 20, 2013 3:29 AM
> > > To: Inki Dae
> > > Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
> > > Cho; linux-me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> > > framework
> > > 
> > > On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
> > > > On the other hand, the below shows how we could enhance the conventional
> > > > way with my approach (just example):
> > > >
> > > > CPU -> DMA,
> > > > ioctl(qbuf command)  ioctl(streamon)
> > > >   |   |
> > > >   |   |
> > > > qbuf  <- dma_buf_sync_get   start streaming <- syncpoint
> > > >
> > > > dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object.
> > > And
> > > > the syncpoint is performed by calling dma_buf_sync_lock(), and then DMA
> > > > accesses the sync buffer.
> > > >
> > > > And DMA -> CPU,
> > > > ioctl(dqbuf command)
> > > >   |
> > > >   |
> > > > dqbuf <- nothing to do
> > > >
> > > > Actual syncpoint is when DMA operation is completed (in interrupt
> > > handler):
> > > > the syncpoint is performed by calling dma_buf_sync_unlock().
> > > > Hence,  my approach is to move the syncpoints into just before dma
> > > access
> > > > as long as possible.
> > > 
> > > What you've just described does *not* work on architectures such as
> > > ARMv7 which do speculative cache fetches from memory at any time that
> > > that memory is mapped with a cacheable status, and will lead to data
> > > corruption.
> > 
> > I didn't explain that enough. Sorry about that. 'nothing to do' means that a
> > dmabuf sync interface isn't called but existing functions are called. So
> > this may be explained again:
> > ioctl(dqbuf command)
> > |
> > |
> > dqbuf <- 1. dma_unmap_sg
> > 2. dma_buf_sync_unlock (syncpoint)
> > 
> > The syncpoint I mentioned means lock mechanism; not doing cache operation.
> > 
> > In addition, please see the below more detail examples.
> > 
> > The conventional way (without dmabuf-sync) is:
> > Task A 
> > 
> >  1. CPU accesses buf  
> >  2. Send the buf to Task B  
> >  3. Wait for the buf from Task B
> >  4. go to 1
> > 
> > Task B
> > ---
> > 1. Wait for the buf from Task A
> > 2. qbuf the buf 
> > 2.1 insert the buf to incoming queue
> > 3. stream on
> > 3.1 dma_map_sg if ready, and move the buf to ready queue
> > 3.2 get the buf from ready queue, and dma start.
> > 4. dqbuf
> > 4.1 dma_unmap_sg after dma operation completion
> > 4.2 move the buf to outgoing queue
> > 5. back the buf to Task A
> > 6. go to 1
> > 
> > In case that two tasks share buffers, and data flow goes from Task A to Task
> > B, we would need IPC operation to send and receive buffers properly between
> > those two tasks every time CPU or DMA access to buffers is started or
> > completed.
> > 
> > 
> > With dmabuf-sync:
> > 
> > Task A 
> > 
> >  1. dma_buf_sync_lock <- synpoint (call by user side)
> >  2. CPU accesses buf  
> >  3. dma_buf_sync_unlock <- syncpoint (call by user side)
> >  4. Send the buf to Task B (just one time)
> >  5. go to 1
> > 
> > 
> > Task B
> > ---
> > 1. Wait for the buf from Task A (just one time)
> > 2. qbuf the buf 
> > 1.1 insert the buf to incoming queue
> > 3. stream on
> > 3.1 dma_buf_sync_lock <- syncpoint (call by kernel side)
> > 3.2 dma_map_sg if ready, and move the buf to ready queue
> > 3.3 get the buf from ready queue, and dma start.
> > 4. dqbuf
> > 4.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
> > 4.2 dma_unmap_sg after dma operation completion
> > 4.3 move the buf to outgoing queue
> > 5. go to 1
> > 
> > On the other hand, in case of using dmabuf-sync, as you can see the above
> > example, we would need IPC operation just one time. That way, I think we
> > could not only reduce performance overhead but also make user application
> > simplified. Of course, this approach can be used for all DMA device drivers
> > such as DRM. I'm not a specialist in v4l2 world so there may be missing
> > point.
> > 
> 
> You already need some kind of IPC between the two tasks, as I suspect
> even in your example it wouldn't make much sen

Re: [PATCH v5 2/7] mutex: add support for wound/wait style locks, v5

[Ingo Molnar]

* Maarten Lankhorst  wrote:

> Changes since RFC patch v1:
>  - Updated to use atomic_long instead of atomic, since the reservation_id was 
> a long.
>  - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
>  - removed mutex_locked_set_reservation_id (or w/e it was called)
> Changes since RFC patch v2:
>  - remove use of __mutex_lock_retval_arg, add warnings when using wrong 
> combination of
>mutex_(,reserve_)lock/unlock.
> Changes since v1:
>  - Add __always_inline to __mutex_lock_common, otherwise reservation paths 
> can be
>triggered from normal locks, because __builtin_constant_p might evaluate 
> to false
>for the constant 0 in that case. Tests for this have been added in the 
> next patch.
>  - Updated documentation slightly.
> Changes since v2:
>  - Renamed everything to ww_mutex. (mlankhorst)
>  - Added ww_acquire_ctx and ww_class. (mlankhorst)
>  - Added a lot of checks for wrong api usage. (mlankhorst)
>  - Documentation updates. (danvet)
> Changes since v3:
>  - Small documentation fixes (robclark)
>  - Memory barrier fix (danvet)
> Changes since v4:
>  - Remove ww_mutex_unlock_single and ww_mutex_lock_single.
>  - Rename ww_mutex_trylock_single to ww_mutex_trylock.
>  - Remove separate implementations of ww_mutex_lock_slow*, normal
>functions can be used. Inline versions still exist for extra
>debugging.
>  - Cleanup unneeded memory barriers, add comment to the remaining
>smp_mb().

That's not a proper changelog. It should be a short description of what it 
does, possibly referring to the new Documentation/ww-mutex-design.txt file 
for more details.

> Signed-off-by: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Rob Clark 

That's not a valid signoff chain: the last signoff in the chain is the 
person sending me the patch. The first signoff is the person who wrote the 
patch. The other two gents should be Acked-by I suspect?

Thanks,

Ingo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/7] mutex: add support for wound/wait style locks, v5

[Ingo Molnar]

* Maarten Lankhorst  wrote:

> +The algorithm that TTM came up with for dealing with this problem is quite
> +simple. [...]

'TTM' here reads like a person - but in reality it's the TTM graphics 
subsystem, right?

Please clarify this portion of the text.

Thanks,

Ingo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/7] mutex: add support for wound/wait style locks, v5

[Ingo Molnar]

* Maarten Lankhorst  wrote:

> Well they've helped me with some of the changes and contributed some 
> code and/or fixes, but if acked-by is preferred I'll use that..

Such contributions can be credited in the changelog, and/or copyright 
notices, and/or the code itself. The signoff chain on the other hand is 
strictly defined as a 'route the patch took', with a single point of 
origin, the main author. See Documentation/SubmittingPatches, pt 12.

[ A signoff chain _can_ signal multi-authored code where the code got 
  written by someone and then further fixed/developed by someone else - 
  who adds a SOB to the end - but in that case I expect to get the patch 
  from the last person in the signoff chain. ]

Thanks,

Ingo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/8] ARM: dts: exynos5250: move common hdmi properties to exynos5 dtsi

[Rahul Sharma]

Hdmi Subsystem nodes shares many properties across exynos5 SoCs
(exynos5250 and exyno5420). Common code is moved to exynos5.dtsi
which is included in exyno5250 and exynos5420 SoC files.

It also renames the hdmi and mixer nodes as per dt naming
convention in the format name@phy_add.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/cros5250-common.dtsi|2 +-
 arch/arm/boot/dts/exynos5.dtsi|   12 
 arch/arm/boot/dts/exynos5250-arndale.dts  |7 ++-
 arch/arm/boot/dts/exynos5250-smdk5250.dts |7 ++-
 arch/arm/boot/dts/exynos5250-snow.dts |8 
 arch/arm/boot/dts/exynos5250.dtsi |8 ++--
 6 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..abda0b9 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -299,7 +299,7 @@
status = "disabled";
};
 
-   hdmi {
+   hdmi@1453 {
hpd-gpio = <&gpx3 7 0>;
};
 
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 1ae179e..dcb4943 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -144,4 +144,16 @@
#size-cells = <0>;
status = "disabled";
};
+
+   hdmi@1453 {
+   reg = <0x1453 0x7>;
+   interrupts = <0 95 0>;
+   status = "disabled";
+   };
+
+   mixer@1445 {
+   reg = <0x1445 0x1>;
+   interrupts = <0 94 0>;
+   status = "disabled";
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 5c7dd6d..c18c346 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -423,13 +423,18 @@
};
};
 
-   hdmi {
+   hdmi@1453 {
+   status = "okay";
hpd-gpio = <&gpx3 7 2>;
vdd_osc-supply = <&ldo10_reg>;
vdd_pll-supply = <&ldo8_reg>;
vdd-supply = <&ldo8_reg>;
};
 
+   mixer@1445 {
+   status = "okay";
+   };
+
mmc_reg: voltage-regulator {
compatible = "regulator-fixed";
regulator-name = "VDD_33ON_2.8V";
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index d3da369..c1b8b7f 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -221,10 +221,15 @@
status = "disabled";
};
 
-   hdmi {
+   hdmi@1453 {
+   status = "okay";
hpd-gpio = <&gpx3 7 0>;
};
 
+   mixer@1445 {
+   status = "okay";
+   };
+
codec@1100 {
samsung,mfc-r = <0x4300 0x80>;
samsung,mfc-l = <0x5100 0x80>;
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index e79331d..b1378af 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -196,4 +196,12 @@
clock-frequency = <2400>;
};
};
+
+   hdmi@1453 {
+   status = "okay";
+   };
+
+   mixer@1445 {
+   status = "okay";
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index baf6f88..0fdbe55 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -578,20 +578,16 @@
clock-names = "gscl";
};
 
-   hdmi {
+   hdmi@1453 {
compatible = "samsung,exynos5-hdmi";
-   reg = <0x1453 0x7>;
-   interrupts = <0 95 0>;
clocks = <&clock 333>, <&clock 136>, <&clock 137>,
<&clock 333>, <&clock 333>;
clock-names = "hdmi", "sclk_hdmi", "sclk_pixel",
"sclk_hdmiphy", "hdmiphy";
};
 
-   mixer {
+   mixer@1445 {
compatible = "samsung,exynos5-mixer";
-   reg = <0x1445 0x1>;
-   interrupts = <0 94 0>;
};
 
dp-controller {
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/8] ARM: dts: exynos5420: add dt nodes for hdmi subsystem

[Rahul Sharma]

Add hdmi, mixer, ddc device tree nodes for Exynos 5420 SoC.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   20 
 arch/arm/boot/dts/exynos5420.dtsi |8 
 2 files changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 08607df..fcd0f69 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -30,4 +30,24 @@
clock-frequency = <2400>;
};
};
+
+   hdmi@1453 {
+   status = "okay";
+   hpd-gpio = <&gpx3 7 0>;
+   };
+
+   mixer@1445 {
+   status = "okay";
+   };
+
+   i2c_2: i2c@12C8 {
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-max-bus-freq = <66000>;
+   status = "okay";
+
+   hdmiddc@50 {
+   compatible = "samsung,exynos4210-hdmiddc";
+   reg = <0x50>;
+   };
+   };
 };
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 953f877..93caef7 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -177,4 +177,12 @@
pinctrl-names = "default";
pinctrl-0 = <&i2c3_bus>;
};
+
+   hdmi@1453 {
+   compatible = "samsung,exynos4212-hdmi";
+   };
+
+   mixer@1445 {
+   compatible = "samsung,exynos5420-mixer";
+   };
 };
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 5/8] ARM: dts: exynos5420: add clocks for hdmi subsystem

[Rahul Sharma]

Add clocks for hdmi and mixer for exynos5420 SoC.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5420.dtsi |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 93caef7..5fa4093 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -180,9 +180,15 @@
 
hdmi@1453 {
compatible = "samsung,exynos4212-hdmi";
+   clocks = <&clock 413>, <&clock 143>, <&clock 144>,
+   <&clock 158>, <&clock 1024>;
+   clock-names = "hdmi", "sclk_hdmi", "sclk_pixel",
+   "sclk_hdmiphy", "mout_hdmi";
};
 
mixer@1445 {
compatible = "samsung,exynos5420-mixer";
+   clocks = <&clock 431>, <&clock 143>;
+   clock-names = "mixer", "sclk_hdmi";
};
 };
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 6/8] ARM: dts: exynos5420: add hdmi hpd gpio pinctrl node

[Rahul Sharma]

Add pinctrl node for hdmi-hpd gpio pin to exynos5420
device tree files.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index fcd0f69..0f98eab 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -31,9 +31,20 @@
};
};
 
+   pinctrl@1340 {
+   hdmi_hpd_irq: hdmi-hpd-irq {
+   samsung,pins = "gpx3-7";
+   samsung,pin-function = <0>;
+   samsung,pin-pud = <1>;
+   samsung,pin-drv = <0>;
+   };
+   };
+
hdmi@1453 {
status = "okay";
hpd-gpio = <&gpx3 7 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&hdmi_hpd_irq>;
};
 
mixer@1445 {
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 7/8] of/documentation: Update hpd gpio property for exynos_hdmi

[Rahul Sharma]

From: Sachin Kamat 

Exynos SoCs use pinctrl to configure GPIOs. Update the document
to reflect this change.

Signed-off-by: Sachin Kamat 
Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/video/exynos_hdmi.txt |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 589edee..584385a 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -8,9 +8,7 @@ Required properties:
 - hpd-gpio: following information about the hotplug gpio pin.
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
-   c) pin function mode.
-   d) optional flags and pull up/down.
-   e) drive strength.
+   c) optional flags and pull up/down.
 
 Example:
 
@@ -18,5 +16,5 @@ Example:
compatible = "samsung,exynos5-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
-   hpd-gpio = <&gpx3 7 0xf 1 3>;
+   hpd-gpio = <&gpx3 7 1>;
};
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 8/8] of/documentation: update with clock information for exynos hdmi subsystem

[Rahul Sharma]

Adding information about clocks to the binding documentation
for exynos mixer and hdmi.

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/video/exynos_hdmi.txt  |   14 +-
 Documentation/devicetree/bindings/video/exynos_mixer.txt |4 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 584385a..827e64b 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -9,7 +9,19 @@ Required properties:
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
c) optional flags and pull up/down.
-
+- clocks: list of clock IDs from SoC clock driver.
+   a) hdmi: It is required for gate operation on aclk_200_disp1 clock
+   which clocks the display1 block.
+   b) sclk_hdmi: It is required for gate operation on sclk_hdmi clock
+   which clocks hdmi IP.
+   c) sclk_pixel: Parent for mux mout_hdmi.
+   d) sclk_hdmiphy: Parent for mux mout_hdmi.
+   e) mout_hdmi: It is required by the driver to switch between the 2
+   parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable
+   after configuration, parent is set to sclk_hdmiphy else
+   sclk_pixel.
+- clock-names: aliases as per driver requirements for above clock IDs:
+   "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
 Example:
 
hdmi {
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9b2ea03..54790a2 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -5,6 +5,10 @@ Required properties:
 - reg: physical base address of the mixer and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
+- clocks: list of clock IDs from SoC clock driver.
+   a) mixer: It is required for gate operation on aclk_200_disp1 clock
+   which clocks the display1 block.
+   b) sclk_hdmi: Parent for mux mout_mixer.
 
 Example:
 
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4] drm/i2c: tda998x: fix sync generation and calculation

[Sebastian Hesselbarth]

This fixes the wrong sync generation and sync calculation. It has only
been tested for progressive and interlaced modes. Sync timings for a
bunch of modes have also been verified with an oscilloscope near-end
(TDA998x input) and far-end (DVI receiver output).

Signed-off-by: Sebastian Hesselbarth 
---
Changelog:
v3->v4:
- switch sync settings from active-before-sync to sync-before-active
  as HDMI data island packets require horizontal counter in sync <256
- also test some interlaced modes 

v2->v3:
- fixed compiler warnings (it is getting late)

v1->v2:
- also fix interlaced sync generation (tested with 1080i50)

Cc: David Airlie 
Cc: Russell King - ARM Linux 
Cc: Darren Etheridge 
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/i2c/tda998x_drv.c |  179 +++--
 1 files changed, 113 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 819dcba..1d7782e 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -141,8 +141,12 @@ struct tda998x_priv {
 #define REG_VS_LINE_END_1_LSB REG(0x00, 0xae) /* write */
 #define REG_VS_PIX_END_1_MSB  REG(0x00, 0xaf) /* write */
 #define REG_VS_PIX_END_1_LSB  REG(0x00, 0xb0) /* write */
+#define REG_VS_LINE_STRT_2_MSBREG(0x00, 0xb1) /* write */
+#define REG_VS_LINE_STRT_2_LSBREG(0x00, 0xb2) /* write */
 #define REG_VS_PIX_STRT_2_MSB REG(0x00, 0xb3) /* write */
 #define REG_VS_PIX_STRT_2_LSB REG(0x00, 0xb4) /* write */
+#define REG_VS_LINE_END_2_MSB REG(0x00, 0xb5) /* write */
+#define REG_VS_LINE_END_2_LSB REG(0x00, 0xb6) /* write */
 #define REG_VS_PIX_END_2_MSB  REG(0x00, 0xb7) /* write */
 #define REG_VS_PIX_END_2_LSB  REG(0x00, 0xb8) /* write */
 #define REG_HS_PIX_START_MSB  REG(0x00, 0xb9) /* write */
@@ -153,21 +157,29 @@ struct tda998x_priv {
 #define REG_VWIN_START_1_LSB  REG(0x00, 0xbe) /* write */
 #define REG_VWIN_END_1_MSBREG(0x00, 0xbf) /* write */
 #define REG_VWIN_END_1_LSBREG(0x00, 0xc0) /* write */
+#define REG_VWIN_START_2_MSB  REG(0x00, 0xc1) /* write */
+#define REG_VWIN_START_2_LSB  REG(0x00, 0xc2) /* write */
+#define REG_VWIN_END_2_MSBREG(0x00, 0xc3) /* write */
+#define REG_VWIN_END_2_LSBREG(0x00, 0xc4) /* write */
 #define REG_DE_START_MSB  REG(0x00, 0xc5) /* write */
 #define REG_DE_START_LSB  REG(0x00, 0xc6) /* write */
 #define REG_DE_STOP_MSB   REG(0x00, 0xc7) /* write */
 #define REG_DE_STOP_LSB   REG(0x00, 0xc8) /* write */
 #define REG_TBG_CNTRL_0   REG(0x00, 0xca) /* write */
+# define TBG_CNTRL_0_TOP_TGL  (1 << 0)
+# define TBG_CNTRL_0_TOP_SEL  (1 << 1)
+# define TBG_CNTRL_0_DE_EXT   (1 << 2)
+# define TBG_CNTRL_0_TOP_EXT  (1 << 3)
 # define TBG_CNTRL_0_FRAME_DIS(1 << 5)
 # define TBG_CNTRL_0_SYNC_MTHD(1 << 6)
 # define TBG_CNTRL_0_SYNC_ONCE(1 << 7)
 #define REG_TBG_CNTRL_1   REG(0x00, 0xcb) /* write */
-# define TBG_CNTRL_1_VH_TGL_0 (1 << 0)
-# define TBG_CNTRL_1_VH_TGL_1 (1 << 1)
-# define TBG_CNTRL_1_VH_TGL_2 (1 << 2)
-# define TBG_CNTRL_1_VHX_EXT_DE   (1 << 3)
-# define TBG_CNTRL_1_VHX_EXT_HS   (1 << 4)
-# define TBG_CNTRL_1_VHX_EXT_VS   (1 << 5)
+# define TBG_CNTRL_1_H_TGL(1 << 0)
+# define TBG_CNTRL_1_V_TGL(1 << 1)
+# define TBG_CNTRL_1_TGL_EN   (1 << 2)
+# define TBG_CNTRL_1_X_EXT(1 << 3)
+# define TBG_CNTRL_1_H_EXT(1 << 4)
+# define TBG_CNTRL_1_V_EXT(1 << 5)
 # define TBG_CNTRL_1_DWIN_DIS (1 << 6)
 #define REG_ENABLE_SPACE  REG(0x00, 0xd6) /* write */
 #define REG_HVF_CNTRL_0   REG(0x00, 0xe4) /* write */
@@ -740,43 +752,68 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
 {
struct tda998x_priv *priv = to_tda998x_priv(encoder);
-   uint16_t hs_start, hs_end, line_start, line_end;
-   uint16_t vwin_start, vwin_end, de_start, de_end;
-   uint16_t ref_pix, ref_line, pix_start2;
+   uint16_t ref_pix, ref_line, n_pix, n_line;
+   uint16_t hs_pix_s, hs_pix_e;
+   uint16_t vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e;
+   uint16_t vs2_pix_s, vs2_pix_e, vs2_line_s, vs2_line_e;
+   uint16_t vwin1_line_s, vwin1_line_e;
+   uint16_t vwin2_line_s, vwin2_line_e;
+   uint16_t de_pix_s, de_pix_e;
uint8_t reg, div, rep;
 
-   hs_start   = mode->hsync_start - mode->hdisplay;
-   hs_end = mode->hsync_end - mode->hdisplay;
-   line_start = 1;
-   line_end   = 1 + mode->vsync_end - mode->vsync_start;
-   vwin_start = mode->vtotal - mode->vsync_start;
-   vwin_end   = vwin_start + mode->vdisplay;
-   de_start   = mode->htotal - mode->hdi

Re: [PATCH v4] drm/i2c: tda998x: fix sync generation and calculation

[Russell King - ARM Linux]

On Thu, Jun 20, 2013 at 09:46:03PM +0200, Sebastian Hesselbarth wrote:
> + ref_pix  = 3 + mode->hsync_start - mode->hdisplay;
> + de_pix_s = mode->htotal - mode->hdisplay;
> + de_pix_e = de_pix_s + mode->hdisplay;
> + hs_pix_s = mode->hsync_start - mode->hdisplay;
> + hs_pix_e = hs_pix_s + mode->hsync_end - mode->hsync_start;

Correct, however, these can be simplified.

For de_pix_e:

de_pix_e = de_pix_s + mode->hdisplay;
de_pix_s = mode->htotal - mode->hdisplay;

Putting de_pix_s into de_pix_e's equation, you get:

de_pix_e = mode->htotal - mode->hdisplay + mode->hdisplay;

which ends up simply as:

de_pix_e = mode->htotal;

Now, doing the same for hs_pix_e:

hs_pix_e = mode->hsync_start - mode->hdisplay + mode->hsync_end - 
mode->hsync_start;

which ends up as:

hs_pix_e = mode->hsync_end - mode->hdisplay;

So overall these come out as:

de_pix_e = mode->htotal;
de_pix_s = mode->htotal - mode->hdisplay;
hs_pix_e = mode->hsync_end - mode->hdisplay;
hs_pix_s = mode->hsync_start - mode->hdisplay;

I've listed them in reverse order because it makes more sense to me when
thinking about it.  What we're basically doing is rotating this by
hdisplay pixel clocks to the left, so using abbreviations:

ht=htotal
hds=hdisplay start
hde=hdisplay end
hss=hsync_start
hse=hsync_end

0ht
hdshde  hss hse   |
|---||---||

becomes:
0ht
0   hss hse  hdshde
||---||---|

and from that you can visualize taking hdisplay (being hde-hds) off each
timing parameter modulo htotal gives you the above equations.

These calculations are the same as what was originally in the driver:

+   de_start   = mode->htotal - mode->hdisplay;
+   de_end = mode->htotal;
+   hs_start   = mode->hsync_start - mode->hdisplay;
+   hs_end = mode->hsync_end - mode->hdisplay;

when it was first committed.

This is otherwise exactly what I came up with which gets my TV working
again in HDMI mode.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/i2c: tda998x: fix sync generation and calculation

[Sebastian Hesselbarth]

On 06/20/2013 10:06 PM, Russell King - ARM Linux wrote:

On Thu, Jun 20, 2013 at 09:46:03PM +0200, Sebastian Hesselbarth wrote:

+   ref_pix  = 3 + mode->hsync_start - mode->hdisplay;
+   de_pix_s = mode->htotal - mode->hdisplay;
+   de_pix_e = de_pix_s + mode->hdisplay;
+   hs_pix_s = mode->hsync_start - mode->hdisplay;
+   hs_pix_e = hs_pix_s + mode->hsync_end - mode->hsync_start;


Correct, however, these can be simplified.

[...]

These calculations are the same as what was originally in the driver:

+   de_start   = mode->htotal - mode->hdisplay;
+   de_end = mode->htotal;
+   hs_start   = mode->hsync_start - mode->hdisplay;
+   hs_end = mode->hsync_end - mode->hdisplay;

when it was first committed.

This is otherwise exactly what I came up with which gets my TV working
again in HDMI mode.


Russell,

I am fine with any way to describe de/hs but you should notice that
I also modified refpix/refline and added interlaced sync. With the
original sync calculation, on some modes there was source blanking
captured by TDA998x which was also visible in the output image. I
chose the above description to make it more readable.

Also the patch takes care of input sync and output sync inversion
while the original driver always expected positive HS/VS.

I tested these sync settings on 4 DVI monitors and TV sets all
accepted each mode perfectly. Especially, not-so-cheap TV sets
are very picky about wrong sync.

Sebastian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem

[Mike Turquette]

Quoting Kukjin Kim (2013-06-19 07:01:17)
> On 06/19/13 13:04, Rahul Sharma wrote:
> > + mike
> >
> Mike, I'm waiting for your reply on this. If you're OK, let me take this 
> series on top of exynos5420 stuff in samsung tree.
> 
> Of course, if any concerns, please let me know.

I never got these patches.  I'm not subscribed to devicetree-devel or
linux-samsung so I only got two replies to patch #0, but none of the
code. Can you or Rajul resend?

Thanks,
Mike

> 
> Thanks,
> - Kukjin
> 
> > On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma  
> > wrote:
> >> Add clock changes for hdmi subsystem for exynos5250 SoC. These
> >> include addition of new clocks like mout_hdmi and smmu_tv, associating
> >> ID to clk_hdmiphy and some essential corrections.
> >>
> >> This set is based on kukjin's for-next branch at
> >> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.
> >>
> >> This set dependents on the following patches which add support for 
> >> Exynos5420
> >> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg19264.html
> >>
> >> Rahul Sharma (5):
> >>clk/exynos5420: add sclk_hdmiphy to the list of special clocks
> >>clk/exynos5420: add gate clock for tv sysmmu
> >>clk/exynos5420: fix the order of parents of hdmi mux
> >>clk/exynos5420: add hdmi mux to change parents in hdmi driver
> >>clk/exynos5420: assign sclk_pixel id to pixel clock divider
> >>
> >>   .../devicetree/bindings/clock/exynos5420-clock.txt   |7 +++
> >>   drivers/clk/samsung/clk-exynos5420.c |   18 
> >> +++---
> >>   2 files changed, 18 insertions(+), 7 deletions(-)
> >>
> >> --
> >> 1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: move i915_trace_irq_get() out of the tracing macro

[Sebastian Andrzej Siewior]

There is a report on RT about "BUG: scheduling while atomic" because the
sleeping lock is taken in tracing context. This patch simply moves
locking operation out of the tracing macro.

Reported-by: Joakim Hernberg 
[c.e...@osadl.org: pull out seqno and define it so it compiled]
Signed-off-by: Sebastian Andrzej Siewior 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 -
 drivers/gpu/drm/i915/i915_trace.h  | 1 -
 drivers/gpu/drm/i915/intel_ringbuffer.h| 2 ++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 87a3227..fa5b45f 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -844,6 +844,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct intel_ring_buffer *ring;
u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 exec_start, exec_len;
+   u32 seqno;
u32 mask, flags;
int ret, mode, i;
bool need_relocs;
@@ -1081,7 +1082,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
goto err;
}
 
-   trace_i915_gem_ring_dispatch(ring, intel_ring_get_seqno(ring), flags);
+   seqno = intel_ring_get_seqno(ring);
+   trace_i915_gem_ring_dispatch(ring, seqno, flags);
+   i915_trace_irq_get(ring, seqno);
 
i915_gem_execbuffer_move_to_active(&eb->objects, ring);
i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index 3db4a68..29217db 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -244,7 +244,6 @@ TRACE_EVENT(i915_gem_ring_dispatch,
   __entry->ring = ring->id;
   __entry->seqno = seqno;
   __entry->flags = flags;
-  i915_trace_irq_get(ring, seqno);
   ),
 
TP_printk("dev=%u, ring=%u, seqno=%u, flags=%x",
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 799f04c..13ffe58 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -262,8 +262,10 @@ static inline u32 intel_ring_get_seqno(struct 
intel_ring_buffer *ring)
 
 static inline void i915_trace_irq_get(struct intel_ring_buffer *ring, u32 
seqno)
 {
+#ifdef CONFIG_TRACEPOINTS
if (ring->trace_irq_seqno == 0 && ring->irq_get(ring))
ring->trace_irq_seqno = seqno;
+#endif
 }
 
 /* DRI warts */
-- 
1.8.3.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: move i915_trace_irq_get() out of the tracing macro

[Sebastian Andrzej Siewior]

On 06/21/2013 01:08 PM, Chris Wilson wrote:
> On Fri, Jun 21, 2013 at 12:15:53PM +0200, Sebastian Andrzej Siewior wrote:
>> There is a report on RT about "BUG: scheduling while atomic" because the
>> sleeping lock is taken in tracing context. This patch simply moves
>> locking operation out of the tracing macro.
> 
> No. This enables the IRQ, as well as making a number of
> very expensively serialised read, unconditionally.

Ach in case CONFIG_TRACING is enabled but the tracepoint itself is
disabled. In that case it is probably best to drop this tracepoint from
-RT.

> -Chris
> 
Sebastian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drivers/gpu/drm/mgag200/mgag200_cursor.c:134:57: sparse: incorrect type in argument 1 (different address spaces)

[Christopher Harvey]

Hey Dave,

Do we care about these warnings? I'm not sure how to get around them.

thanks,
Chris

P.S, this is my last day at Matrox, but I'll maintain it from another
email.

On Fri, Jun 21 2013, kbuild test robot  wrote:
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next master
> head:   849aa58856855ae73d9654b2e675f2c7a6ad4c9b
> commit: a080db9fdda77ffaa43679d21b4bd78ead0cf9e1 drm/mgag200: Hardware cursor 
> support
> date:   4 days ago
>
>
> sparse warnings: (new ones prefixed by >>)
>
>>> drivers/gpu/drm/mgag200/mgag200_cursor.c:134:57: sparse: incorrect type in 
>>> argument 1 (different address spaces)
>drivers/gpu/drm/mgag200/mgag200_cursor.c:134:57:expected void 
> [noderef] *
>drivers/gpu/drm/mgag200/mgag200_cursor.c:134:57:got void *
>>> drivers/gpu/drm/mgag200/mgag200_cursor.c:200:65: sparse: incorrect type in 
>>> argument 1 (different address spaces)
>drivers/gpu/drm/mgag200/mgag200_cursor.c:200:65:expected void 
> [noderef] *
>drivers/gpu/drm/mgag200/mgag200_cursor.c:200:65:got void *
>>> drivers/gpu/drm/mgag200/mgag200_cursor.c:218:55: sparse: incorrect type in 
>>> argument 1 (different address spaces)
>drivers/gpu/drm/mgag200/mgag200_cursor.c:218:55:expected void volatile 
> [noderef] *dst
>drivers/gpu/drm/mgag200/mgag200_cursor.c:218:55:got void *
>
> vim +134 drivers/gpu/drm/mgag200/mgag200_cursor.c
>
>128}
>129}
>130
>131memset(&colour_set[0], 0, sizeof(uint32_t)*16);
>132/* width*height*4 = 16384 */
>133for (i = 0; i < 16384; i += 4) {
>  > 134this_colour = ioread32(bo->kmap.virtual + i);
>135/* No transparency */
>136if (this_colour>>24 != 0xff &&
>137this_colour>>24 != 0x0) {
>138if (warn_transparent) {
>139dev_info(&dev->pdev->dev, 
> "Video card doesn't support cursors with partial transparency.\n");
>140dev_info(&dev->pdev->dev, "Not 
> enabling hardware cursor.\n");
>141warn_transparent = false; /* 
> Only tell the user once. */
>142}
>143ret = -EINVAL;
>144goto out3;
>145}
>146/* Don't need to store transparent pixels as 
> colours */
>147if (this_colour>>24 == 0x0)
>148continue;
>149found = false;
>150for (palette_iter = &colour_set[0]; 
> palette_iter != next_space; palette_iter++) {
>151if (*palette_iter == this_colour) {
>152found = true;
>153break;
>154}
>155}
>156if (found)
>157continue;
>158/* We only support 4bit paletted cursors */
>159if (colour_count >= 16) {
>160if (warn_palette) {
>161dev_info(&dev->pdev->dev, 
> "Video card only supports cursors with up to 16 colours.\n");
>162dev_info(&dev->pdev->dev, "Not 
> enabling hardware cursor.\n");
>163warn_palette = false; /* Only 
> tell the user once. */
>164}
>165ret = -EINVAL;
>166goto out3;
>167}
>168*next_space = this_colour;
>169next_space++;
>170colour_count++;
>171}
>172
>173/* Program colours from cursor icon into palette */
>174for (i = 0; i < colour_count; i++) {
>175if (i <= 2)
>176reg_index = 0x8 + i*0x4;
>177else
>178reg_index = 0x60 + i*0x3;
>179WREG_DAC(reg_index, colour_set[i] & 0xff);
>180WREG_DAC(reg_index+1, colour_set[i]>>8 & 0xff);
>181WREG_DAC(reg_index+2, colour_set[i]>>16 & 0xff);
>182BUG_ON((colour_set[i]>>24 & 0xff) != 0xff);
>183}
>184
>185/* Map up-coming buffer to write colour indices */
>186 

Re: [PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem

[Mike Turquette]

Quoting Rahul Sharma (2013-06-20 21:47:35)
> On Fri, Jun 21, 2013 at 10:02 AM, Mike Turquette  
> wrote:
> > Quoting Kukjin Kim (2013-06-19 07:01:17)
> >> On 06/19/13 13:04, Rahul Sharma wrote:
> >> > + mike
> >> >
> >> Mike, I'm waiting for your reply on this. If you're OK, let me take this
> >> series on top of exynos5420 stuff in samsung tree.
> >>
> >> Of course, if any concerns, please let me know.
> >
> > I never got these patches.  I'm not subscribed to devicetree-devel or
> > linux-samsung so I only got two replies to patch #0, but none of the
> > code. Can you or Rajul resend?
> >
> 
> Sure mike.

Acked-by: Mike Turquette 

Regards,
Mike

> 
> > Thanks,
> > Mike
> >
> >>
> >> Thanks,
> >> - Kukjin
> >>
> >> > On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma  
> >> > wrote:
> >> >> Add clock changes for hdmi subsystem for exynos5250 SoC. These
> >> >> include addition of new clocks like mout_hdmi and smmu_tv, associating
> >> >> ID to clk_hdmiphy and some essential corrections.
> >> >>
> >> >> This set is based on kukjin's for-next branch at
> >> >> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.
> >> >>
> >> >> This set dependents on the following patches which add support for 
> >> >> Exynos5420
> >> >> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg19264.html
> >> >>
> >> >> Rahul Sharma (5):
> >> >>clk/exynos5420: add sclk_hdmiphy to the list of special clocks
> >> >>clk/exynos5420: add gate clock for tv sysmmu
> >> >>clk/exynos5420: fix the order of parents of hdmi mux
> >> >>clk/exynos5420: add hdmi mux to change parents in hdmi driver
> >> >>clk/exynos5420: assign sclk_pixel id to pixel clock divider
> >> >>
> >> >>   .../devicetree/bindings/clock/exynos5420-clock.txt   |7 +++
> >> >>   drivers/clk/samsung/clk-exynos5420.c |   18 
> >> >> +++---
> >> >>   2 files changed, 18 insertions(+), 7 deletions(-)
> >> >>
> >> >> --
> >> >> 1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: always provide debugfs function prototypes

[Arnd Bergmann]

It is generally considered bad style to enclose function prototypes
in header files in #ifdef. This case illustrates why that is:
The tegra host1x driver calls into the debugfs functions if
CONFIG_DEBUG_FS is enabled, but that code is otherwise already
discarded by the compiler, so leaving the prototype in place
actually makes everything work.

drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_init':
drivers/gpu/host1x/drm/dc.c:1004:2: error: implicit declaration of function 
'drm_debugfs_create_files' [-Werror=implicit-function-declaration]
drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_exit': 
drivers/gpu/host1x/drm/dc.c:1026:2: error: implicit declaration of function 
'drm_debugfs_remove_files' [-Werror=implicit-function-declaration]

Signed-off-by: Arnd Bergmann 
Cc: Ben Gamari 
Cc: Dave Airlie 

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 63d17ee..8bc105e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1551,7 +1551,7 @@ extern int drm_proc_init(struct drm_minor *minor, struct 
proc_dir_entry *root);
 extern int drm_proc_cleanup(struct drm_minor *minor, struct proc_dir_entry 
*root);
 
/* Debugfs support */
-#if defined(CONFIG_DEBUG_FS)
+
 extern int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root);
 extern int drm_debugfs_create_files(struct drm_info_list *files, int count,
@@ -1559,7 +1559,6 @@ extern int drm_debugfs_create_files(struct drm_info_list 
*files, int count,
 extern int drm_debugfs_remove_files(struct drm_info_list *files, int count,
 struct drm_minor *minor);
 extern int drm_debugfs_cleanup(struct drm_minor *minor);
-#endif
 
/* Info file support */
 extern int drm_name_info(struct seq_file *m, void *data);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

2013/6/22 Jerome Glisse :
> On Fri, Jun 21, 2013 at 12:55 PM, Inki Dae  wrote:
>> 2013/6/21 Lucas Stach :
>>> Hi Inki,
>>>
>>> please refrain from sending HTML Mails, it makes proper quoting without
>>> messing up the layout everywhere pretty hard.
>>>
>>
>> Sorry about that. I should have used text mode.
>>
>>> Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae:
>>> [...]
>>>
 Yeah, you'll some knowledge and understanding about the API
 you are
 working with to get things right. But I think it's not an
 unreasonable
 thing to expect the programmer working directly with kernel
 interfaces
 to read up on how things work.

 Second thing: I'll rather have *one* consistent API for every
 subsystem,
 even if they differ from each other than having to implement
 this
 syncpoint thing in every subsystem. Remember: a single execbuf
 in DRM
 might reference both GEM objects backed by dma-buf as well
 native SHM or
 CMA backed objects. The dma-buf-mgr proposal already allows
 you to
 handle dma-bufs much the same way during validation than
 native GEM
 objects.

 Actually, at first I had implemented a fence helper framework based on
 reservation and dma fence to provide easy-use-interface for device
 drivers. However, that was wrong implemention: I had not only
 customized the dma fence but also not considered dead lock issue.
 After that, I have reimplemented it as dmabuf sync to solve dead
 issue, and at that time, I realized that we first need to concentrate
 on the most basic thing: the fact CPU and CPU, CPU and DMA, or DMA and
 DMA can access a same buffer, And the fact simple is the best, and the
 fact we need not only kernel side but also user side interfaces. After
 that, I collected what is the common part for all subsystems, and I
 have devised this dmabuf sync framework for it. I'm not really
 specialist in Desktop world. So question. isn't the execbuf used only
 for the GPU? the gpu has dedicated video memory(VRAM) so it needs
 migration mechanism between system memory and the dedicated video
 memory, and also to consider ordering issue while be migrated.

>>>
>>> Yeah, execbuf is pretty GPU specific, but I don't see how this matters
>>> for this discussion. Also I don't see a big difference between embedded
>>> and desktop GPUs. Buffer migration is more of a detail here. Both take
>>> command stream that potentially reference other buffers, which might be
>>> native GEM or dma-buf backed objects. Both have to make sure the buffers
>>> are in the right domain (caches cleaned and address mappings set up) and
>>> are available for the desired operation, meaning you have to sync with
>>> other DMA engines and maybe also with CPU.
>>
>> Yeah, right. Then, in case of desktop gpu, does't it need additional
>> something to do when a buffer/s is/are migrated from system memory to
>> video memory domain, or from video memory to system memory domain? I
>> guess the below members does similar thing, and all other DMA devices
>> would not need them:
>> struct fence {
>> ...
>> unsigned int context, seqno;
>> ...
>> };
>>
>> And,
>> struct seqno_fence {
>> ...
>> uint32_t seqno_ofs;
>> ...
>> };
>>
>>>
>>> The only case where sync isn't clearly defined right now by the current
>>> API entrypoints is when you access memory through the dma-buf fallback
>>> mmap support, which might happen with some software processing element
>>> in a video pipeline or something. I agree that we will need a userspace
>>> interface here, but I think this shouldn't be yet another sync object,
>>> but rather more a prepare/fini_cpu_access ioctl on the dma-buf which
>>> hooks into the existing dma-fence and reservation stuff.
>>
>> I think we don't need addition ioctl commands for that. I am thinking
>> of using existing resources as possible. My idea also is similar in
>> using the reservation stuff to your idea because my approach also
>> should use the dma-buf resource. However, My idea is that a user
>> process, that wants buffer synchronization with the other, sees a sync
>> object as a file descriptor like dma-buf does. The below shows simple
>> my idea about it:
>>
>> ioctl(dmabuf_fd, DMA_BUF_IOC_OPEN_SYNC, &sync);
>>
>> flock(sync->fd, LOCK_SH); <- LOCK_SH means a shared lock.
>> CPU access for read
>> flock(sync->fd, LOCK_UN);
>>
>> Or
>>
>> flock(sync->fd, LOCK_EX); <- LOCK_EX means an exclusive lock
>> CPU access for write
>> flock(sync->fd, LOCK_UN);
>>
>> close(sync->fd);
>>
>> As you know, that's similar to dmabuf export feature.
>>
>> In addition, a more simple idea,
>> flock(dmabuf_fd, LOCK_SH/EX);
>> CPU access for read/write
>> flock(dmabuf_fd, LOCK_UN);
>>
>> However, I'm not sure that the above examples could be worked well,
>> and there are no problems yet: actually, I don't fully understand
>> flock mechanism, so looking into it.
>>
>>>

 And to get back 

Regression introduced by 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4 ("drm/i915: create compact dma scatter lists for gem objects") Was:Re: i915 mapping large (3MB) scatter list, hitting limits on certa

[Konrad Rzeszutek Wilk]

On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote:
> Hey,

CC-ing Imre,

Imre, your patch 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
("drm/i915: create compact dma scatter lists for gem objects") is the cause
of the regression.

If I revert your patch it boots fine without any trouble.

I am not entirely sure why that is - as I added some debug code in
lib/swiotlb.c to trigger when it can't find 3MB  area (which
is what I thought initially was the issue) - but none of the debug
code seems to be hit.

Any thoughts?
> 
> I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
> (3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-rc6
> I found that i915 would halt with a 
> 
> [drm:intel_pipe_set_base] *ERROR* pin & fence failed
> [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28
> 
> after a bit of debugging (see patch below) I traced it down
> to the fact that the scatter list that is provided at the end has
> a huge (3MB) page. I am wondering if anybody knows what patch might
> have introduced it to grab such a large memory segment?
> 
> The other thing I am wondering is if there are some fallbacks when the
> underlaying IOMMU can't deal with a request for contingous regions
> that are more than 2MB?
> 
> Thanks.
> 
> >From a681a4adb4738c32cb1acdf6f5161bf877816b01 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk 
> Date: Fri, 21 Jun 2013 11:17:55 -0400
> Subject: [PATCH] dbug: print scatterlist.
> 
> [ cut here ]
> WARNING: at drivers/gpu/drm/i915/i915_gem_gtt.c:418 
> i915_gem_gtt_prepare_object+0x180/0x200()
> 10 but got 0
> Modules linked in:
>  crc32_pclmul sdhci_pci crc32c_intel sdhci mmc_core ghash_clmulni_intel
> CPU: 0 PID: 216 Comm: plymouthd Not tainted 3.10.0-rc6+ #16
> Hardware name: LENOVO 2325DV4/2325DV4, BIOS G2ET86WW (2.06 ) 11/13/2012
>  0009 8801fa42d958 816e6d89 8801fa42d998
>  8105d2b0 8801fa42d988  8801fb0f4d80
>  81c172e0 8801fa76f000 000a 8801fa42d9f8
> Call Trace:
>  [] dump_stack+0x19/0x1b
>  [] warn_slowpath_common+0x70/0xa0
>  [] warn_slowpath_fmt+0x46/0x50
>  [] i915_gem_gtt_prepare_object+0x180/0x200
>  [] i915_gem_object_pin+0x321/0x670
>  [] i915_gem_object_pin_to_display_plane+0x81/0x190
>  [] intel_pin_and_fence_fb_obj+0x85/0x1a0
>  [] intel_pipe_set_base+0x7c/0x220
>  [] intel_crtc_set_config+0x89e/0x990
>  [] drm_mode_set_config_internal+0x2e/0x60
>  [] drm_mode_setcrtc+0xfb/0x620
>  [] ? kmem_cache_alloc_trace+0x39/0x1f0
>  [] ? drm_vm_open_locked+0x57/0x90
>  [] drm_ioctl+0x549/0x680
>  [] ? drm_mode_setplane+0x3b0/0x3b0
>  [] do_vfs_ioctl+0x97/0x580
>  [] ? inode_has_perm.isra.32.constprop.62+0x2a/0x30
>  [] ? file_has_perm+0x97/0xb0
>  [] SyS_ioctl+0x91/0xb0
>  [] tracesys+0xdd/0xe2
> ---[ end trace 7b6adc5450d9a9e1 ]---
> i915 :00:02.0: i915_gem_gtt_prepare_object: Mapping 10 pages, mapped: 0
> [0] virT:8801fd37c000 dma: 1fd37c000, size:4096
> [1] virT:8801fd37b000 dma: 1fd37b000, size:4096
> [2] virT:8801fd37a000 dma: 1fd37a000, size:4096
> [3] virT:8801fd378000 dma: 1fd378000, size:4096
> [4] virT:8801fd131000 dma: 1fd131000, size:4096
> [5] virT:880200c36000 dma: 200c36000, size:4096
> [6] virT:8801fd1a4000 dma: 1fd1a4000, size:69632
> [7] virT:8801fd3bb000 dma: 1fd3bb000, size:4096
> [8] virT:8801fd3c dma: 1fd3c, size:262144
> [9] virT:8801f940 dma: 1f940, size:3866624
> [drm] 3011: ret:-28
> [drm] 3540: ret:-28
> [drm] 3364: ret:-28
> [drm:intel_pin_and_fence_fb_obj] *ERROR* i915_gem_object_pin_to_display_plane 
> failed: -28
> [drm:intel_pipe_set_base] *ERROR* pin & fence failed
> [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  6 ++
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 28 +---
>  2 files changed, 31 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 8411942..141c6fb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -133,6 +133,12 @@ module_param_named(coherent, use_coherent, int, 0600);
>  MODULE_PARM_DESC(use_coherent,
>"Use coherent DMA API calls (default: false)");
>  
> +int i915_sgl __read_mostly = 0;
> +module_param_named(sgl, i915_sgl, int, 0600);
> +MODULE_PARM_DESC(sgl,
> +  "Print scatterlist SG's when DMA mapping them (default: 
> false)");
> +
> +
>  static struct drm_driver driver;
>  extern int intel_agp_enabled;
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index acb3b3f..292179c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -28,6 +28,7 @@
>  #include "i915_trace.h"
>  #include "intel_drv.h"
>  

[PULL] drm-tegra-fixes

[Dave Airlie]

>   git://anongit.freedesktop.org/tegra/linux.git drm/fixes
>
> for you to fetch changes up to 2b15aa0fd466a4b2defdfd84c0b5168804b3eb33:
>
>   gpu: host1x: Rework CPU syncpoint increment (2013-06-20 12:21:38 +0200)
>
> I know this comes awfully late and is much bigger than I'd like. It's
> all my fault, though, since I've been travelling a lot lately and just
> didn't find the time to prepare this earlier. I did want to sort out
> patches that didn't warrant to go in before the final 3.10 release, but
> all met the criteria as far as I could tell.
>

Don't think I want to submit this to Linus, its way too much at this point,

User visible oops or regressions is all you get now really.

Dave.



> Arto Merilainen (5):
>   gpu: host1x: Check reloc table before usage
>   gpu: host1x: Copy gathers before verification
>   gpu: host1x: Fix memory access in syncpt request
>   gpu: host1x: Fix client_managed type
>   gpu: host1x: Rework CPU syncpoint increment
>
> Emil Goode (1):
>   drm/tegra: Include header drm/drm.h
>
> Laurent Pinchart (1):
>   drm/tegra: Remove DRIVER_BUS_PLATFORM from driver_features
>
> Terje Bergstrom (2):
>   gpu: host1x: Check INCR opcode correctly
>   gpu: host1x: Don't reset firewall between gathers
>
> Thierry Reding (5):
>   drm/tegra: Don't disable unused planes
>   drm/tegra: Explicitly set irq_enabled
>   drm/tegra: Honor pixel-format changes
>   MAINTAINERS: Update Tegra DRM entry
>   drm/tegra: Fix return value
>
> Wei Yongjun (2):
>   drm/tegra: fix missing unlock on error
>   drm/tegra: fix error return code in gr2d_submit()
>
>  MAINTAINERS   |   7 +-
>  drivers/gpu/host1x/dev.h  |   8 +--
>  drivers/gpu/host1x/drm/dc.c   |   5 ++
>  drivers/gpu/host1x/drm/drm.c  |  14 +++-
>  drivers/gpu/host1x/drm/gr2d.c |  12 ++--
>  drivers/gpu/host1x/hw/cdma_hw.c   |   2 +-
>  drivers/gpu/host1x/hw/syncpt_hw.c |  12 ++--
>  drivers/gpu/host1x/job.c  | 135 
> +-
>  drivers/gpu/host1x/syncpt.c   |  26 +++-
>  drivers/gpu/host1x/syncpt.h   |  13 ++--
>  include/uapi/drm/tegra_drm.h  |   2 +
>  11 files changed, 113 insertions(+), 123 deletions(-)

[git pull] drm radeon fixes

[Dave Airlie]

Hi Linus,

one core fix, but mostly radeon fixes for s/r and big endian UVD support,
and a fix to stop the GPU being reset for no good reason, and crashing 
people's machines.

Dave.

The following changes since commit df63d3ecbca514bad99513b2401448d19a9bb92e:

  Merge tag 'drm-intel-fixes-2013-06-11' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-06-11 
19:38:27 +1000)

are available in the git repository at:


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

for you to fetch changes up to 9aa36876ddeb85dfb0bcf37be06bbdc62e954f16:

  Merge branch 'drm-fixes-3.10' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2013-06-21 08:52:19 +1000)



Alex Deucher (1):
  drm/radeon: fix UVD on big endian

Dave Airlie (2):
  Merge branch 'drm-fixes-3.10' of 
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge branch 'drm-fixes-3.10' of 
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Jerome Glisse (3):
  drm/radeon: do not try to uselessly update virtual memory pagetable
  drm/radeon: fix write back suspend regression with uvd v2
  drm/radeon: update lockup tracking when scheduling in empty ring

Laurent Pinchart (1):
  drm/prime: Honor requested file flags when exporting a buffer

 drivers/gpu/drm/drm_prime.c|  3 +-
 drivers/gpu/drm/radeon/r600.c  | 13 +++--
 drivers/gpu/drm/radeon/radeon_device.c | 53 +++---
 drivers/gpu/drm/radeon/radeon_fence.c  | 10 +--
 drivers/gpu/drm/radeon/radeon_gart.c   |  6 ++--
 drivers/gpu/drm/radeon/radeon_ring.c   |  7 +
 drivers/gpu/drm/radeon/radeon_uvd.c| 48 +++---
 7 files changed, 85 insertions(+), 55 deletions(-)

[PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem

[Rahul Sharma]

On Fri, Jun 21, 2013 at 10:02 AM, Mike Turquette  
wrote:
> Quoting Kukjin Kim (2013-06-19 07:01:17)
>> On 06/19/13 13:04, Rahul Sharma wrote:
>> > + mike
>> >
>> Mike, I'm waiting for your reply on this. If you're OK, let me take this
>> series on top of exynos5420 stuff in samsung tree.
>>
>> Of course, if any concerns, please let me know.
>
> I never got these patches.  I'm not subscribed to devicetree-devel or
> linux-samsung so I only got two replies to patch #0, but none of the
> code. Can you or Rajul resend?
>

Sure mike.

> Thanks,
> Mike
>
>>
>> Thanks,
>> - Kukjin
>>
>> > On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma 
>> >  wrote:
>> >> Add clock changes for hdmi subsystem for exynos5250 SoC. These
>> >> include addition of new clocks like mout_hdmi and smmu_tv, associating
>> >> ID to clk_hdmiphy and some essential corrections.
>> >>
>> >> This set is based on kukjin's for-next branch at
>> >> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.
>> >>
>> >> This set dependents on the following patches which add support for 
>> >> Exynos5420
>> >> http://www.mail-archive.com/linux-samsung-soc at 
>> >> vger.kernel.org/msg19264.html
>> >>
>> >> Rahul Sharma (5):
>> >>clk/exynos5420: add sclk_hdmiphy to the list of special clocks
>> >>clk/exynos5420: add gate clock for tv sysmmu
>> >>clk/exynos5420: fix the order of parents of hdmi mux
>> >>clk/exynos5420: add hdmi mux to change parents in hdmi driver
>> >>clk/exynos5420: assign sclk_pixel id to pixel clock divider
>> >>
>> >>   .../devicetree/bindings/clock/exynos5420-clock.txt   |7 +++
>> >>   drivers/clk/samsung/clk-exynos5420.c |   18 
>> >> +++---
>> >>   2 files changed, 18 insertions(+), 7 deletions(-)
>> >>
>> >> --
>> >> 1.7.10.4

[PATCH 1/5] clk/exynos5250: Fix HDMI clock number in documentation

[Rahul Sharma]

+Mike

On Mon, Jun 10, 2013 at 4:17 PM, Rahul Sharma  wrote:
> This patch is already posted at
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg18331.html
> and
>
> Reviewed-by: Doug Anderson 
>
> On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma  
> wrote:
>> From: Arun Kumar K 
>>
>> This patch corrects the HDMI clock number given wrongly
>> in the documentation.
>>
>> Signed-off-by: Arun Kumar K 
>> Signed-off-by: Rahul Sharma 
>> ---
>>  Documentation/devicetree/bindings/clock/exynos5250-clock.txt |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
>> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> index 781a627..1a05761 100644
>> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> @@ -154,7 +154,7 @@ clock which they consume.
>>dsim0341
>>dp   342
>>mixer343
>> -  hdmi 345
>> +  hdmi 344
>>
>>  Example 1: An example of a clock controller node is listed below.
>>
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] clk/exynos5250: add mout_hdmi mux clock for hdmi

[Rahul Sharma]

+Mike

On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma  
wrote:
> hdmi driver needs to change the parent of hdmi clock
> frequently between pixel clock and hdmiphy clock. hdmiphy is
> not stable after power on and for a short interval while changing
> the phy configuration. For this duration pixel clock is used to
> clock hdmi.
>
> This patch is exposing the mux for changing parent.
>
> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/clock/exynos5250-clock.txt |8 
>  drivers/clk/samsung/clk-exynos5250.c |5 -
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index 1a05761..b337147 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -156,6 +156,14 @@ clock which they consume.
>mixer343
>hdmi 344
>
> +
> +   [Clock Muxes]
> +
> +  ClockID
> +  
> +  mout_hdmi1024
> +
> +
>  Example 1: An example of a clock controller node is listed below.
>
> clock: clock-controller at 0x1001 {
> diff --git a/drivers/clk/samsung/clk-exynos5250.c 
> b/drivers/clk/samsung/clk-exynos5250.c
> index 5c97e75..587d913 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -100,6 +100,9 @@ enum exynos5250_clks {
> tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
> wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
>
> +   /* mux clocks */
> +   mout_hdmi = 1024,
> +
> nr_clks,
>  };
>
> @@ -231,7 +234,7 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata 
> = {
> MUX(none, "mout_fimd1", mout_group1_p, SRC_DISP1_0, 0, 4),
> MUX(none, "mout_mipi1", mout_group1_p, SRC_DISP1_0, 12, 4),
> MUX(none, "mout_dp", mout_group1_p, SRC_DISP1_0, 16, 4),
> -   MUX(none, "mout_hdmi", mout_hdmi_p, SRC_DISP1_0, 20, 1),
> +   MUX(mout_hdmi, "mout_hdmi", mout_hdmi_p, SRC_DISP1_0, 20, 1),
> MUX(none, "mout_audio0", mout_audio0_p, SRC_MAU, 0, 4),
> MUX(none, "mout_mmc0", mout_group1_p, SRC_FSYS, 0, 4),
> MUX(none, "mout_mmc1", mout_group1_p, SRC_FSYS, 4, 4),
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] clk/exynos5250: add sclk_hdmiphy in the list of special clocks

[Rahul Sharma]

+Mike

On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma  
wrote:
> hdmi driver needs hdmiphy clock which is one of the parent
> for hdmi mux clock. This is required while changing the parent
> of mux clock.
>
> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/clock/exynos5250-clock.txt |1 +
>  drivers/clk/samsung/clk-exynos5250.c |3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index b337147..f333d61 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -59,6 +59,7 @@ clock which they consume.
>sclk_spi0154
>sclk_spi1155
>sclk_spi2156
> +  sclk_hdmiphy 157
>
>
> [Peripheral Clock Gates]
> diff --git a/drivers/clk/samsung/clk-exynos5250.c 
> b/drivers/clk/samsung/clk-exynos5250.c
> index 587d913..88cdb13 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -87,6 +87,7 @@ enum exynos5250_clks {
> sclk_mmc0, sclk_mmc1, sclk_mmc2, sclk_mmc3, sclk_sata, sclk_usb3,
> sclk_jpeg, sclk_uart0, sclk_uart1, sclk_uart2, sclk_uart3, sclk_pwm,
> sclk_audio1, sclk_audio2, sclk_spdif, sclk_spi0, sclk_spi1, sclk_spi2,
> +   sclk_hdmiphy,
>
> /* gate clocks */
> gscl0 = 256, gscl1, gscl2, gscl3, gscl_wa, gscl_wb, smmu_gscl0,
> @@ -199,7 +200,7 @@ struct samsung_fixed_rate_clock 
> exynos5250_fixed_rate_ext_clks[] __initdata = {
>
>  /* fixed rate clocks generated inside the soc */
>  struct samsung_fixed_rate_clock exynos5250_fixed_rate_clks[] __initdata = {
> -   FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
> +   FRATE(sclk_hdmiphy, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
> FRATE(none, "sclk_hdmi27m", NULL, CLK_IS_ROOT, 2700),
> FRATE(none, "sclk_dptxphy", NULL, CLK_IS_ROOT, 2400),
> FRATE(none, "sclk_uhostphy", NULL, CLK_IS_ROOT, 4800),
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] clk/exynos5250: add clock for tv sysmmu

[Rahul Sharma]

+Mike

On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma  
wrote:
> Adding sysmmu clock for tv for exynos5250 SoC. It also
> adds aclk200_disp1 mux which is the actual parent of the
> disp1 block (contains hdmi, mixer, sysmmu_tv).
>
> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/clock/exynos5250-clock.txt |1 +
>  drivers/clk/samsung/clk-exynos5250.c |6 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index f333d61..f1c7e7f 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -156,6 +156,7 @@ clock which they consume.
>dp   342
>mixer343
>hdmi 344
> +  smmu_tv  345
>
>
> [Clock Muxes]
> diff --git a/drivers/clk/samsung/clk-exynos5250.c 
> b/drivers/clk/samsung/clk-exynos5250.c
> index 88cdb13..bb93d61 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -24,6 +24,7 @@
>  #define SRC_CORE1  0x4204
>  #define SRC_TOP0   0x10210
>  #define SRC_TOP2   0x10218
> +#define SRC_TOP3   0x1021C
>  #define SRC_GSCL   0x10220
>  #define SRC_DISP1_00x1022c
>  #define SRC_MAU0x10240
> @@ -99,7 +100,7 @@ enum exynos5250_clks {
> spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, 
> hsi2c2,
> hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
> tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
> -   wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
> +   wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, smmu_tv,
>
> /* mux clocks */
> mout_hdmi = 1024,
> @@ -172,6 +173,7 @@ PNAME(mout_mpll_user_p) = { "fin_pll", "sclk_mpll" };
>  PNAME(mout_bpll_user_p)= { "fin_pll", "sclk_bpll" };
>  PNAME(mout_aclk166_p)  = { "sclk_cpll", "sclk_mpll_user" };
>  PNAME(mout_aclk200_p)  = { "sclk_mpll_user", "sclk_bpll_user" };
> +PNAME(mout_aclk200_disp1_sub_p) = { "fin_pll", "aclk200" };
>  PNAME(mout_hdmi_p) = { "div_hdmi_pixel", "sclk_hdmiphy" };
>  PNAME(mout_usb3_p) = { "sclk_mpll_user", "sclk_cpll" };
>  PNAME(mout_group1_p)   = { "fin_pll", "fin_pll", "sclk_hdmi27m",
> @@ -227,6 +229,7 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata 
> = {
> MUX(none, "mout_aclk166", mout_aclk166_p, SRC_TOP0, 8, 1),
> MUX(none, "mout_aclk333", mout_aclk166_p, SRC_TOP0, 16, 1),
> MUX(none, "mout_aclk200", mout_aclk200_p, SRC_TOP0, 12, 1),
> +   MUX(none, "aclk200_disp1", mout_aclk200_disp1_sub_p, SRC_TOP3, 4, 1),
> MUX(none, "mout_cam_bayer", mout_group1_p, SRC_GSCL, 12, 4),
> MUX(none, "mout_cam0", mout_group1_p, SRC_GSCL, 16, 4),
> MUX(none, "mout_cam1", mout_group1_p, SRC_GSCL, 20, 4),
> @@ -328,6 +331,7 @@ struct samsung_gate_clock exynos5250_gate_clks[] 
> __initdata = {
> GATE(smmu_gscl1, "smmu_gscl1", "aclk266", GATE_IP_GSCL, 8, 0, 0),
> GATE(smmu_gscl2, "smmu_gscl2", "aclk266", GATE_IP_GSCL, 9, 0, 0),
> GATE(smmu_gscl3, "smmu_gscl3", "aclk266", GATE_IP_GSCL, 10, 0, 0),
> +   GATE(smmu_tv, "smmu_tv", "aclk200_disp1", GATE_IP_DISP1, 9, 0, 0),
> GATE(mfc, "mfc", "aclk333", GATE_IP_MFC, 0, 0, 0),
> GATE(smmu_mfcl, "smmu_mfcl", "aclk333", GATE_IP_MFC, 1, 0, 0),
> GATE(smmu_mfcr, "smmu_mfcr", "aclk333", GATE_IP_MFC, 2, 0, 0),
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem

[Rahul Sharma]

+Mike

On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma  
wrote:
> parent of hdmi and mixer block is mentioned as aclk200 which is
> not correct. It is clocked by the ouput of aclk200_disp1. Hence
> parent for mixer and hdmi clocks is changed to aclk200_disp1.
>
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/clk/samsung/clk-exynos5250.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5250.c 
> b/drivers/clk/samsung/clk-exynos5250.c
> index bb93d61..2075f5f 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -468,8 +468,8 @@ struct samsung_gate_clock exynos5250_gate_clks[] 
> __initdata = {
> GATE(mie1, "mie1", "aclk200", GATE_IP_DISP1, 1, 0, 0),
> GATE(dsim0, "dsim0", "aclk200", GATE_IP_DISP1, 3, 0, 0),
> GATE(dp, "dp", "aclk200", GATE_IP_DISP1, 4, 0, 0),
> -   GATE(mixer, "mixer", "aclk200", GATE_IP_DISP1, 5, 0, 0),
> -   GATE(hdmi, "hdmi", "aclk200", GATE_IP_DISP1, 6, 0, 0),
> +   GATE(mixer, "mixer", "aclk200_disp1", GATE_IP_DISP1, 5, 0, 0),
> +   GATE(hdmi, "hdmi", "aclk200_disp1", GATE_IP_DISP1, 6, 0, 0),
>  };
>
>  static __initdata struct of_device_id ext_clk_match[] = {
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] clk/exynos5420: add sclk_hdmiphy to the list of special clocks

[Rahul Sharma]

+Mike

On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma  
wrote:
> Add sclk_hdmiphy to the list of exposed clocks. This is required
> by hdmi driver to change the parent of hdmi clock.
>
> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
>  drivers/clk/samsung/clk-exynos5420.c |4 ++--
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt 
> b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> index 9bcc4b1..596a368 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> @@ -59,6 +59,7 @@ clock which they consume.
>sclk_pwm 155
>sclk_gscl_wa 156
>sclk_gscl_wb 157
> +  sclk_hdmiphy 158
>
> [Peripheral Clock Gates]
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> b/drivers/clk/samsung/clk-exynos5420.c
> index 68a96cb..0945435 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -91,7 +91,7 @@ enum exynos5420_clks {
> sclk_i2s2, sclk_pcm1, sclk_pcm2, sclk_spdif, sclk_hdmi, sclk_pixel,
> sclk_dp1, sclk_mipi1, sclk_fimd1, sclk_maudio0, sclk_maupcm0,
> sclk_usbd300, sclk_usbd301, sclk_usbphy300, sclk_usbphy301, 
> sclk_unipro,
> -   sclk_pwm, sclk_gscl_wa, sclk_gscl_wb,
> +   sclk_pwm, sclk_gscl_wa, sclk_gscl_wb, sclk_hdmiphy,
>
> /* gate clocks */
> aclk66_peric = 256, uart0, uart1, uart2, uart3, i2c0, i2c1, i2c2, 
> i2c3,
> @@ -268,7 +268,7 @@ struct samsung_fixed_rate_clock 
> exynos5420_fixed_rate_ext_clks[] __initdata = {
>
>  /* fixed rate clocks generated inside the soc */
>  struct samsung_fixed_rate_clock exynos5420_fixed_rate_clks[] __initdata = {
> -   FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
> +   FRATE(sclk_hdmiphy, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
> FRATE(none, "sclk_pwi", NULL, CLK_IS_ROOT, 2400),
> FRATE(none, "sclk_usbh20", NULL, CLK_IS_ROOT, 4800),
> FRATE(none, "mphy_refclk_ixtal24", NULL, CLK_IS_ROOT, 4800),
> --
> 1.7.10.4
>

[PATCH 2/5] clk/exynos5420: add gate clock for tv sysmmu

[Rahul Sharma]

+Mike

On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma  
wrote:
> Adding sysmmu clock for tv for exynos5420.
>
> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
>  drivers/clk/samsung/clk-exynos5420.c |3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt 
> b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> index 596a368..f0b1ce0 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> @@ -180,6 +180,7 @@ clock which they consume.
>fimc_lite3   495
>aclk_g3d 500
>g3d  501
> +  smmu_tv  502
>
>  Example 1: An example of a clock controller node is listed below.
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> b/drivers/clk/samsung/clk-exynos5420.c
> index 0945435..e8be481 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -109,7 +109,7 @@ enum exynos5420_clks {
> aclk300_gscl = 460, smmu_gscl0, smmu_gscl1, gscl_wa, gscl_wb, gscl0,
> gscl1, clk_3aa, aclk266_g2d = 470, sss, slim_sss, mdma0,
> aclk333_g2d = 480, g2d, aclk333_432_gscl = 490, smmu_3aa, smmu_fimcl0,
> -   smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d,
> +   smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d, smmu_tv,
>
> nr_clks,
>  };
> @@ -696,6 +696,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] 
> __initdata = {
> GATE(smmu_mscl0, "smmu_mscl0", "aclk400_mscl", GATE_IP_MSCL, 8, 0, 0),
> GATE(smmu_mscl1, "smmu_mscl1", "aclk400_mscl", GATE_IP_MSCL, 9, 0, 0),
> GATE(smmu_mscl2, "smmu_mscl2", "aclk400_mscl", GATE_IP_MSCL, 10, 0, 
> 0),
> +   GATE(smmu_tv, "smmu_tv", "aclk200_disp1", GATE_IP_DISP1, 9, 0, 0),
>  };
>
>  static __initdata struct of_device_id ext_clk_match[] = {
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] clk/exynos5420: fix the order of parents of hdmi mux

[Rahul Sharma]

+Mike

On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma  
wrote:
> Listing sclk_hdmiphy at 0th position in the list of parents is
> causing wrong configuration in reg SRC_DISP10.
>
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/clk/samsung/clk-exynos5420.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> b/drivers/clk/samsung/clk-exynos5420.c
> index e8be481..193d25e 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -257,7 +257,7 @@ PNAME(audio2_p) = { "fin_pll", "cdclk2", "sclk_dpll", 
> "sclk_mpll",
>   "sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
>  PNAME(spdif_p) = { "fin_pll", "dout_audio0", "dout_audio1", "dout_audio2",
>   "spdif_extclk", "sclk_ipll", "sclk_epll", "sclk_rpll" };
> -PNAME(hdmi_p)  = { "sclk_hdmiphy", "dout_hdmi_pixel" };
> +PNAME(hdmi_p)  = { "dout_hdmi_pixel", "sclk_hdmiphy" };
>  PNAME(maudio0_p)   = { "fin_pll", "maudio_clk", "sclk_dpll", "sclk_mpll",
>   "sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" 
> };
>
> --
> 1.7.10.4
>

[PATCH 4/5] clk/exynos5420: add hdmi mux to change parents in hdmi driver

[Rahul Sharma]

+Mike

On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma  
wrote:
> hdmi driver needs to change the parent of hdmi clock
> to pixel clock or hdmiphy clock, based on the stability
> of hdmiphy. This patch is exposing the mux for changing
> the parent.
>
> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/clock/exynos5420-clock.txt |5 +
>  drivers/clk/samsung/clk-exynos5420.c |5 -
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt 
> b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> index f0b1ce0..c7a319d 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> @@ -182,6 +182,11 @@ clock which they consume.
>g3d  501
>smmu_tv  502
>
> +  Mux  ID
> +  
> +
> +  mout_hdmi1024
> +
>  Example 1: An example of a clock controller node is listed below.
>
> clock: clock-controller at 0x1001 {
> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> b/drivers/clk/samsung/clk-exynos5420.c
> index 193d25e..59cf177 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -111,6 +111,9 @@ enum exynos5420_clks {
> aclk333_g2d = 480, g2d, aclk333_432_gscl = 490, smmu_3aa, smmu_fimcl0,
> smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d, smmu_tv,
>
> +   /* mux clocks */
> +   mout_hdmi = 1024,
> +
> nr_clks,
>  };
>
> @@ -371,7 +374,7 @@ struct samsung_mux_clock exynos5420_mux_clks[] __initdata 
> = {
> MUX(none, "mout_mipi1", group2_p, SRC_DISP10, 16, 3),
> MUX(none, "mout_dp1", group2_p, SRC_DISP10, 20, 3),
> MUX(none, "mout_pixel", group2_p, SRC_DISP10, 24, 3),
> -   MUX(none, "mout_hdmi", hdmi_p, SRC_DISP10, 28, 1),
> +   MUX(mout_hdmi, "mout_hdmi", hdmi_p, SRC_DISP10, 28, 1),
>
> /* MAU Block */
> MUX(none, "mout_maudio0", maudio0_p, SRC_MAU, 28, 3),
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] clk/exynos5420: assign sclk_pixel id to pixel clock divider

[Rahul Sharma]

+Mike

On Tue, Jun 18, 2013 at 7:54 PM, Rahul Sharma  wrote:
> With this patch, it is at par with Exynos5250 and Exynos4 clocks
> where sclk_pixel ID is assigned to a divider clock but in real,
> sclk_pixel is listed under gate clocks (enum value).
>
> Alternate to this, I can allocate a new ID, div_pixel, listed under
> new category of Divider Clocks for Exyno4, 5250 and 5420.
> div_pixel ID can be assigned to pixel clock dividers for all 3 SoCs.
> This ID can be accessed by hdmi driver as usual. While sclk_pixel
> ID can be left unused for Exyno4, 5250 as there are no pixel clock
> gates. And, For 5420, sclk_pixel can optionally be used to
> enable/disable the pixel clock gate.
>
> Regards,
> Rahul Sharma.
>
> On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma  
> wrote:
>> sclk_pixel is used to represent pixel clock divider on all exynos
>> SoCs not as a gate clock. It is queried in driver to pass as the
>> parent to hdmi clock while switching between parents. A new ID can
>> be asssigned Pixel gate clock which is currently not in use. Pixel
>> clock gate is default 'on'.
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>>  drivers/clk/samsung/clk-exynos5420.c |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
>> b/drivers/clk/samsung/clk-exynos5420.c
>> index 59cf177..edd0696 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -434,7 +434,7 @@ struct samsung_div_clock exynos5420_div_clks[] 
>> __initdata = {
>> DIV(none, "dout_fimd1", "mout_fimd1", DIV_DISP10, 0, 4),
>> DIV(none, "dout_mipi1", "mout_mipi1", DIV_DISP10, 16, 8),
>> DIV(none, "dout_dp1", "mout_dp1", DIV_DISP10, 24, 4),
>> -   DIV(none, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),
>> +   DIV(sclk_pixel, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),
>>
>> /* Audio Block */
>> DIV(none, "dout_maudio0", "mout_maudio0", DIV_MAU, 20, 4),
>> @@ -570,7 +570,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] 
>> __initdata = {
>> GATE_TOP_SCLK_DISP1, 3, CLK_SET_RATE_PARENT, 0),
>> GATE(sclk_hdmi, "sclk_hdmi", "mout_hdmi",
>> GATE_TOP_SCLK_DISP1, 9, CLK_SET_RATE_PARENT, 0),
>> -   GATE(sclk_pixel, "sclk_pixel", "dout_hdmi_pixel",
>> +   GATE(none, "sclk_pixel", "dout_hdmi_pixel",
>> GATE_TOP_SCLK_DISP1, 10, CLK_SET_RATE_PARENT, 0),
>> GATE(sclk_dp1, "sclk_dp1", "dout_dp1",
>> GATE_TOP_SCLK_DISP1, 20, CLK_SET_RATE_PARENT, 0),
>> --
>> 1.7.10.4
>>

[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

[Inki Dae]

2013/6/20 Rahul Sharma 

> Thanks Mr. Kim,
>
> I will post v4 with aforesaid change.
>
>
You don't need  to re-post it. I gonna change it to "ARM/dts: change
compatible strings for Exynos5250 hdmi subsystem", and merge it. Is there
another you want?

Thanks,
Inki Dae

regards,
> Rahul Sharma.
>
> On Wed, Jun 19, 2013 at 7:22 PM, Kukjin Kim  wrote:
> > On 06/19/13 22:50, Kukjin Kim wrote:
> >>
> >> On 06/19/13 21:51, Rahul Sharma wrote:
> >>>
> >>> This patch renames the combatible strings for hdmi, mixer, ddc
> >>> and hdmiphy. It follows the convention of using compatible string
> >>> which represent the SoC in which the IP was added for the first
> >>> time.
> >>>
> >>> Signed-off-by: Rahul Sharma
> >>
> >>
> >> Acked-by: Kukjin Kim 
> >>
> >
> > Just one nit in subject:
> >
> > [PATCH] ARM: dts: . for exynos5250
> >
> > Thanks,
> >
> > - Kukjin
> >
> >>> ---
> >>> arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
> >>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
> >>> arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
> >>> 3 files changed, 6 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
> >>> b/arch/arm/boot/dts/cros5250-common.dtsi
> >>> index 3f0239e..dc259e8b 100644
> >>> --- a/arch/arm/boot/dts/cros5250-common.dtsi
> >>> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> >>> @@ -190,7 +190,7 @@
> >>> samsung,i2c-max-bus-freq =<66000>;
> >>>
> >>> hdmiddc at 50 {
> >>> - compatible = "samsung,exynos5-hdmiddc";
> >>> + compatible = "samsung,exynos4210-hdmiddc";
> >>> reg =<0x50>;
> >>> };
> >>> };
> >>> @@ -224,7 +224,7 @@
> >>> samsung,i2c-max-bus-freq =<378000>;
> >>>
> >>> hdmiphy at 38 {
> >>> - compatible = "samsung,exynos5-hdmiphy";
> >>> + compatible = "samsung,exynos4212-hdmiphy";
> >>> reg =<0x38>;
> >>> };
> >>> };
> >>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> >>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> >>> index 3e0c792..f320d7c 100644
> >>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> >>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> >>> @@ -72,7 +72,7 @@
> >>> samsung,i2c-max-bus-freq =<66000>;
> >>>
> >>> hdmiddc at 50 {
> >>> - compatible = "samsung,exynos5-hdmiddc";
> >>> + compatible = "samsung,exynos4210-hdmiddc";
> >>> reg =<0x50>;
> >>> };
> >>> };
> >>> @@ -102,7 +102,7 @@
> >>> samsung,i2c-max-bus-freq =<66000>;
> >>>
> >>> hdmiphy at 38 {
> >>> - compatible = "samsung,exynos5-hdmiphy";
> >>> + compatible = "samsung,exynos4212-hdmiphy";
> >>> reg =<0x38>;
> >>> };
> >>> };
> >>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> >>> b/arch/arm/boot/dts/exynos5250.dtsi
> >>> index 0673524..2f7763b 100644
> >>> --- a/arch/arm/boot/dts/exynos5250.dtsi
> >>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> >>> @@ -601,7 +601,7 @@
> >>> };
> >>>
> >>> hdmi {
> >>> - compatible = "samsung,exynos5-hdmi";
> >>> + compatible = "samsung,exynos4212-hdmi";
> >>> reg =<0x1453 0x7>;
> >>> interrupts =<0 95 0>;
> >>> clocks =<&clock 333>,<&clock 136>,<&clock 137>,
> >>> @@ -611,7 +611,7 @@
> >>> };
> >>>
> >>> mixer {
> >>> - compatible = "samsung,exynos5-mixer";
> >>> + compatible = "samsung,exynos5250-mixer";
> >>> reg =<0x1445 0x1>;
> >>> interrupts =<0 94 0>;
> >>> };
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130621/9b6e8c76/attachment.html>

[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

[Rahul Sharma]

Thanks Mr. Dae, nothing else for this series.

On Fri, Jun 21, 2013 at 10:47 AM, Inki Dae  wrote:
>
>
>
> 2013/6/20 Rahul Sharma 
>>
>> Thanks Mr. Kim,
>>
>> I will post v4 with aforesaid change.
>>
>
> You don't need  to re-post it. I gonna change it to "ARM/dts: change
> compatible strings for Exynos5250 hdmi subsystem", and merge it. Is there
> another you want?
>
> Thanks,
> Inki Dae
>
>> regards,
>> Rahul Sharma.
>>
>> On Wed, Jun 19, 2013 at 7:22 PM, Kukjin Kim  wrote:
>> > On 06/19/13 22:50, Kukjin Kim wrote:
>> >>
>> >> On 06/19/13 21:51, Rahul Sharma wrote:
>> >>>
>> >>> This patch renames the combatible strings for hdmi, mixer, ddc
>> >>> and hdmiphy. It follows the convention of using compatible string
>> >>> which represent the SoC in which the IP was added for the first
>> >>> time.
>> >>>
>> >>> Signed-off-by: Rahul Sharma
>> >>
>> >>
>> >> Acked-by: Kukjin Kim 
>> >>
>> >
>> > Just one nit in subject:
>> >
>> > [PATCH] ARM: dts: . for exynos5250
>> >
>> > Thanks,
>> >
>> > - Kukjin
>> >
>> >>> ---
>> >>> arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
>> >>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
>> >>> arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
>> >>> 3 files changed, 6 insertions(+), 6 deletions(-)
>> >>>
>> >>> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
>> >>> b/arch/arm/boot/dts/cros5250-common.dtsi
>> >>> index 3f0239e..dc259e8b 100644
>> >>> --- a/arch/arm/boot/dts/cros5250-common.dtsi
>> >>> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
>> >>> @@ -190,7 +190,7 @@
>> >>> samsung,i2c-max-bus-freq =<66000>;
>> >>>
>> >>> hdmiddc at 50 {
>> >>> - compatible = "samsung,exynos5-hdmiddc";
>> >>> + compatible = "samsung,exynos4210-hdmiddc";
>> >>> reg =<0x50>;
>> >>> };
>> >>> };
>> >>> @@ -224,7 +224,7 @@
>> >>> samsung,i2c-max-bus-freq =<378000>;
>> >>>
>> >>> hdmiphy at 38 {
>> >>> - compatible = "samsung,exynos5-hdmiphy";
>> >>> + compatible = "samsung,exynos4212-hdmiphy";
>> >>> reg =<0x38>;
>> >>> };
>> >>> };
>> >>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> >>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> >>> index 3e0c792..f320d7c 100644
>> >>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> >>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> >>> @@ -72,7 +72,7 @@
>> >>> samsung,i2c-max-bus-freq =<66000>;
>> >>>
>> >>> hdmiddc at 50 {
>> >>> - compatible = "samsung,exynos5-hdmiddc";
>> >>> + compatible = "samsung,exynos4210-hdmiddc";
>> >>> reg =<0x50>;
>> >>> };
>> >>> };
>> >>> @@ -102,7 +102,7 @@
>> >>> samsung,i2c-max-bus-freq =<66000>;
>> >>>
>> >>> hdmiphy at 38 {
>> >>> - compatible = "samsung,exynos5-hdmiphy";
>> >>> + compatible = "samsung,exynos4212-hdmiphy";
>> >>> reg =<0x38>;
>> >>> };
>> >>> };
>> >>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>> >>> b/arch/arm/boot/dts/exynos5250.dtsi
>> >>> index 0673524..2f7763b 100644
>> >>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> >>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> >>> @@ -601,7 +601,7 @@
>> >>> };
>> >>>
>> >>> hdmi {
>> >>> - compatible = "samsung,exynos5-hdmi";
>> >>> + compatible = "samsung,exynos4212-hdmi";
>> >>> reg =<0x1453 0x7>;
>> >>> interrupts =<0 95 0>;
>> >>> clocks =<&clock 333>,<&clock 136>,<&clock 137>,
>> >>> @@ -611,7 +611,7 @@
>> >>> };
>> >>>
>> >>> mixer {
>> >>> - compatible = "samsung,exynos5-mixer";
>> >>> + compatible = "samsung,exynos5250-mixer";
>> >>> reg =<0x1445 0x1>;
>> >>> interrupts =<0 94 0>;
>> >>> };
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

[PATCH 0/2] i.MX53 IPU + TVE patches

[Philipp Zabel]

Hi,

converting the IPU IRQ handling to use irq_domain_add_linear is listed in
drivers/staging/imx-drm/TODO as one of the tasks to be done before the IPU
driver can be moved out of staging. These patches fix the number IPU_NUM_IRQS
and add a linear irq domain.

regards
Philipp

---
 drivers/staging/imx-drm/TODO|  1 -
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 66 +++--
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h|  4 +-
 3 files changed, 45 insertions(+), 26 deletions(-)

[PATCH 2/2] staging: drm/imx: convert IPU irq driver to irq_domain_add_linear

[Philipp Zabel]

The IPU has a lot of interrupts. Instead of allocating descs for all
of them, register a linear irq domain and create mappings as needed.
This was listed in the TODO as a prerequisite to move the IPU driver
out of staging.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/TODO|  1 -
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 66 +++--
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h|  2 +-
 3 files changed, 44 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
index 123acbe..f806415 100644
--- a/drivers/staging/imx-drm/TODO
+++ b/drivers/staging/imx-drm/TODO
@@ -6,7 +6,6 @@ TODO:
 - Factor out more code to common helper functions
 - decide where to put the base driver. It is not specific to a subsystem
   and would be used by DRM/KMS and media/V4L2
-- convert irq driver to irq_domain_add_linear

 Missing features (not necessarily for moving out of staging):

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index 0127601..1a7b59e 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "imx-ipu-v3.h"
@@ -799,16 +800,18 @@ err_di_0:
 static void ipu_irq_handle(struct ipu_soc *ipu, const int *regs, int num_regs)
 {
unsigned long status;
-   int i, bit, irq_base;
+   int i, bit, irq;

for (i = 0; i < num_regs; i++) {

status = ipu_cm_read(ipu, IPU_INT_STAT(regs[i]));
status &= ipu_cm_read(ipu, IPU_INT_CTRL(regs[i]));

-   irq_base = ipu->irq_start + regs[i] * 32;
-   for_each_set_bit(bit, &status, 32)
-   generic_handle_irq(irq_base + bit);
+   for_each_set_bit(bit, &status, 32) {
+   irq = irq_linear_revmap(ipu->domain, regs[i] * 32 + 
bit);
+   if (irq)
+   generic_handle_irq(irq);
+   }
}
 }

@@ -841,7 +844,7 @@ static void ipu_err_irq_handler(unsigned int irq, struct 
irq_desc *desc)
 static void ipu_ack_irq(struct irq_data *d)
 {
struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   unsigned int irq = d->irq - ipu->irq_start;
+   irq_hw_number_t irq = d->hwirq;

ipu_cm_write(ipu, 1 << (irq % 32), IPU_INT_STAT(irq / 32));
 }
@@ -849,7 +852,7 @@ static void ipu_ack_irq(struct irq_data *d)
 static void ipu_unmask_irq(struct irq_data *d)
 {
struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   unsigned int irq = d->irq - ipu->irq_start;
+   irq_hw_number_t irq = d->hwirq;
unsigned long flags;
u32 reg;

@@ -865,7 +868,7 @@ static void ipu_unmask_irq(struct irq_data *d)
 static void ipu_mask_irq(struct irq_data *d)
 {
struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   unsigned int irq = d->irq - ipu->irq_start;
+   irq_hw_number_t irq = d->hwirq;
unsigned long flags;
u32 reg;

@@ -888,7 +891,12 @@ static struct irq_chip ipu_irq_chip = {
 int ipu_idmac_channel_irq(struct ipu_soc *ipu, struct ipuv3_channel *channel,
enum ipu_channel_irq irq_type)
 {
-   return ipu->irq_start + irq_type + channel->num;
+   int irq = irq_linear_revmap(ipu->domain, irq_type + channel->num);
+
+   if (!irq)
+   irq = irq_create_mapping(ipu->domain, irq_type + channel->num);
+
+   return irq;
 }
 EXPORT_SYMBOL_GPL(ipu_idmac_channel_irq);

@@ -975,18 +983,30 @@ err_register:
return ret;
 }

-static int ipu_irq_init(struct ipu_soc *ipu)
+static int ipu_irq_map(struct irq_domain *h, unsigned int irq,
+  irq_hw_number_t hw)
 {
-   int i;
+   struct ipu_soc *ipu = h->host_data;
+
+   irq_set_chip_and_handler(irq, &ipu_irq_chip, handle_level_irq);
+   set_irq_flags(irq, IRQF_VALID);
+   irq_set_chip_data(irq, ipu);
+
+   return 0;
+}

-   ipu->irq_start = irq_alloc_descs(-1, 0, IPU_NUM_IRQS, 0);
-   if (ipu->irq_start < 0)
-   return ipu->irq_start;
+const struct irq_domain_ops ipu_irq_domain_ops = {
+   .map = ipu_irq_map,
+   .xlate = irq_domain_xlate_onecell,
+};

-   for (i = ipu->irq_start; i < ipu->irq_start + IPU_NUM_IRQS; i++) {
-   irq_set_chip_and_handler(i, &ipu_irq_chip, handle_level_irq);
-   set_irq_flags(i, IRQF_VALID);
-   irq_set_chip_data(i, ipu);
+static int ipu_irq_init(struct ipu_soc *ipu)
+{
+   ipu->domain = irq_domain_add_linear(ipu->dev->of_node, IPU_NUM_IRQS,
+   &ipu_irq_domain_ops, ipu);
+   if (!ipu->domain) {
+   dev_err(ipu->dev, "failed to add irq domain\n");
+   return -ENODEV;
}

irq_set_chained_handler(ipu->irq_sync, ipu_irq_handler);
@@ -999,20 +1019,20 @@ static int ipu_irq_i

[PATCH 1/2] staging: drm/imx: fix number of IPU IRQs

[Philipp Zabel]

There are 15 32-bit registers altogether.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-prv.h 
b/drivers/staging/imx-drm/ipu-v3/ipu-prv.h
index 5518028..12d7eaf 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-prv.h
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-prv.h
@@ -110,7 +110,7 @@ struct ipu_soc;
 #define IDMAC_BAND_EN(ch)  IPU_IDMAC_REG(0x0040 + 4 * ((ch) / 32))
 #define IDMAC_CHA_BUSY(ch) IPU_IDMAC_REG(0x0100 + 4 * ((ch) / 32))

-#define IPU_NUM_IRQS   (32 * 5)
+#define IPU_NUM_IRQS   (32 * 15)

 enum ipu_modules {
IPU_CONF_CSI0_EN= (1 << 0),
-- 
1.8.3.1

[PATCH 0/2] i.MX53 IPU + TVE patches

[Philipp Zabel]

Am Freitag, den 21.06.2013, 10:27 +0200 schrieb Philipp Zabel:
> Hi,
> 

Sorry, copy & paste error.
The correct subject is IPU linear irq domain:

> converting the IPU IRQ handling to use irq_domain_add_linear is listed in
> drivers/staging/imx-drm/TODO as one of the tasks to be done before the IPU
> driver can be moved out of staging. These patches fix the number IPU_NUM_IRQS
> and add a linear irq domain.
> 
> regards
> Philipp
> 
> ---
>  drivers/staging/imx-drm/TODO|  1 -
>  drivers/staging/imx-drm/ipu-v3/ipu-common.c | 66 
> +++--
>  drivers/staging/imx-drm/ipu-v3/ipu-prv.h|  4 +-
>  3 files changed, 45 insertions(+), 26 deletions(-)
> 
> 

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Lucas Stach]

Am Donnerstag, den 20.06.2013, 20:15 +0900 schrieb Inki Dae:
[...]
> > > > You already need some kind of IPC between the two tasks, as I suspect
> > > > even in your example it wouldn't make much sense to queue the buffer
> > > > over and over again in task B without task A writing anything to it.
> > So
> > > > task A has to signal task B there is new data in the buffer to be
> > > > processed.
> > > >
> > > > There is no need to share the buffer over and over again just to get
> > the
> > > > two processes to work together on the same thing. Just share the fd
> > > > between both and then do out-of-band completion signaling, as you need
> > > > this anyway. Without this you'll end up with unpredictable behavior.
> > > > Just because sync allows you to access the buffer doesn't mean it's
> > > > valid for your use-case. Without completion signaling you could easily
> > > > end up overwriting your data from task A multiple times before task B
> > > > even tries to lock the buffer for processing.
> > > >
> > > > So the valid flow is (and this already works with the current APIs):
> > > > Task ATask B
> > > > ----
> > > > CPU access buffer
> > > >  --completion signal->
> > > >   qbuf (dragging buffer into
> > > >   device domain, flush caches,
> > > >   reserve buffer etc.)
> > > > |
> > > >   wait for device operation to
> > > >   complete
> > > > |
> > > >   dqbuf (dragging buffer back
> > > >   into CPU domain, invalidate
> > > >   caches, unreserve)
> > > > <-completion signal
> > > > CPU access buffer
> > > >
> > >
> > > Correct. In case that data flow goes from A to B, it needs some kind
> > > of IPC between the two tasks every time as you said. Then, without
> > > dmabuf-sync, how do think about the case that two tasks share the same
> > > buffer but these tasks access the buffer(buf1) as write, and data of
> > > the buffer(buf1) isn't needed to be shared?
> > >
> > Sorry, I don't see the point you are trying to solve here. If you share
> > a buffer and want its content to be clearly defined at every point in
> > time you have to synchronize the tasks working with the buffer, not just
> > the buffer accesses itself.
> > 
> > Easiest way to do so is doing sync through userspace with out-of-band
> > IPC, like in the example above.
> 
> In my opinion, that's not definitely easiest way. What I try to do is
> to avoid using *the out-of-band IPC*. As I mentioned in document file,
> the conventional mechanism not only makes user application
> complicated-user process needs to understand how the device driver is
> worked-but also may incur performance overhead by using the
> out-of-band IPC. The above my example may not be enough to you but
> there would be other cases able to use my approach efficiently.
> 

Yeah, you'll some knowledge and understanding about the API you are
working with to get things right. But I think it's not an unreasonable
thing to expect the programmer working directly with kernel interfaces
to read up on how things work.

Second thing: I'll rather have *one* consistent API for every subsystem,
even if they differ from each other than having to implement this
syncpoint thing in every subsystem. Remember: a single execbuf in DRM
might reference both GEM objects backed by dma-buf as well native SHM or
CMA backed objects. The dma-buf-mgr proposal already allows you to
handle dma-bufs much the same way during validation than native GEM
objects.

And to get back to my original point: if you have more than one task
operating together on a buffer you absolutely need some kind of real IPC
to sync them up and do something useful. Both you syncpoints and the
proposed dma-fences only protect the buffer accesses to make sure
different task don't stomp on each other. There is nothing in there to
make sure that the output of your pipeline is valid. You have to take
care of that yourself in userspace. I'll reuse your example to make it
clear what I mean:

Task A Task B
-- ---
dma_buf_sync_lock(buf1)
CPU write buf1
dma_buf_sync_unlock(buf1)
  -schedule Task A again---
dma_buf_sync_lock(buf1)
CPU write buf1
dma_buf_sync_unlock(buf1)
-schedule Task B-
   qbuf(buf1)
  dma_buf_sync_lock(buf1)
   

[PATCH 3/4] staging: drm/imx: ipuv3-crtc: immediately update crtc->fb in ipu_page_flip

[Philipp Zabel]

Since commit 8cf1e9811471f2910fa38dc1b28e1789080ba961
("drm: Add consistency check for page-flipping") drm_mode_page_flip_ioctl
contains a WARN_ON that triggers if the .page_flip callback didn't update
the crtc->fb pointer to the new framebuffer immediately.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipuv3-crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index abcdaef..4a7eedf 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -147,6 +147,7 @@ static int ipu_page_flip(struct drm_crtc *crtc,

ipu_crtc->newfb = fb;
ipu_crtc->page_flip_event = event;
+   crtc->fb = fb;

return 0;
 }
@@ -329,7 +330,6 @@ static irqreturn_t ipu_irq_handler(int irq, void *dev_id)
imx_drm_handle_vblank(ipu_crtc->imx_crtc);

if (ipu_crtc->newfb) {
-   ipu_crtc->base.fb = ipu_crtc->newfb;
ipu_crtc->newfb = NULL;
ipu_drm_set_base(&ipu_crtc->base, 0, 0);
ipu_crtc_handle_pageflip(ipu_crtc);
-- 
1.8.3.1

[PATCH 0/4] IPU DMFC bandwidth allocation fix and cleanups

[Philipp Zabel]

Hi,

the following patches remove some unused variables, replace some
hard-coded channel numbers with existing descriptive defines, fix
the DMFC bandwidth (or rather: FIFO space) allocation, and update
ipu_page_flip() to immediately set crtc->fb.

regards
Philipp

---
 drivers/staging/imx-drm/imx-drm-core.c|  3 ---
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 22 --
 drivers/staging/imx-drm/ipuv3-crtc.c  |  7 +--
 3 files changed, 17 insertions(+), 15 deletions(-)

[PATCH 1/4] staging: drm/imx: remove unused variables

[Philipp Zabel]

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/imx-drm-core.c | 3 ---
 drivers/staging/imx-drm/ipuv3-crtc.c   | 5 -
 2 files changed, 8 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index 6455305..56d6bc4 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -491,7 +491,6 @@ int imx_drm_add_crtc(struct drm_crtc *crtc,
 {
struct imx_drm_device *imxdrm = __imx_drm_device();
struct imx_drm_crtc *imx_drm_crtc;
-   const struct drm_crtc_funcs *crtc_funcs;
int ret;

mutex_lock(&imxdrm->mutex);
@@ -512,8 +511,6 @@ int imx_drm_add_crtc(struct drm_crtc *crtc,
imx_drm_crtc->cookie.cookie = cookie;
imx_drm_crtc->cookie.id = id;

-   crtc_funcs = imx_drm_helper_funcs->crtc_funcs;
-
imx_drm_crtc->crtc = crtc;
imx_drm_crtc->imxdrm = imxdrm;

diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index ff5c633..abcdaef 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -42,9 +41,6 @@ struct ipu_framebuffer {
 };

 struct ipu_crtc {
-   struct drm_fb_helperfb_helper;
-   struct ipu_framebuffer  ifb;
-   int num_crtcs;
struct device   *dev;
struct drm_crtc base;
struct imx_drm_crtc *imx_crtc;
@@ -54,7 +50,6 @@ struct ipu_crtc {
struct dmfc_channel *dmfc;
struct ipu_di   *di;
int enabled;
-   struct ipu_priv *ipu_priv;
struct drm_pending_vblank_event *page_flip_event;
struct drm_framebuffer  *newfb;
int irq;
-- 
1.8.3.1

[PATCH 2/4] staging: drm/imx: ipu-dmfc: fix bandwidth allocation

[Philipp Zabel]

The IPU can request up to four pixels per access, which gives four
times the bandwidth compared to what the driver currently assumes.
After correcting this, we have to increase safety margins for
bandwidth requirement calculations.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
index 91821bc..1dc9817 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
@@ -292,7 +292,7 @@ int ipu_dmfc_alloc_bandwidth(struct dmfc_channel *dmfc,
 {
struct ipu_dmfc_priv *priv = dmfc->priv;
int slots = dmfc_bandwidth_to_slots(priv, bandwidth_pixel_per_second);
-   int segment = 0, ret = 0;
+   int segment = -1, ret = 0;

dev_dbg(priv->dev, "dmfc: trying to allocate %ldMpixel/s for IPU 
channel %d\n",
bandwidth_pixel_per_second / 100,
@@ -307,7 +307,17 @@ int ipu_dmfc_alloc_bandwidth(struct dmfc_channel *dmfc,
goto out;
}

-   segment = dmfc_find_slots(priv, slots);
+   /* Always allocate at least 128*4 bytes (2 slots) */
+   if (slots < 2)
+   slots = 2;
+
+   /* For the MEM_BG channel, first try to allocate twice the slots */
+   if (dmfc->data->ipu_channel == IPUV3_CHANNEL_MEM_BG_SYNC)
+   segment = dmfc_find_slots(priv, slots * 2);
+   if (segment >= 0)
+   slots *= 2;
+   else
+   segment = dmfc_find_slots(priv, slots);
if (segment < 0) {
ret = -EBUSY;
goto out;
@@ -391,7 +401,7 @@ int ipu_dmfc_init(struct ipu_soc *ipu, struct device *dev, 
unsigned long base,
 * We have a total bandwidth of clkrate * 4pixel divided
 * into 8 slots.
 */
-   priv->bandwidth_per_slot = clk_get_rate(ipu_clk) / 8;
+   priv->bandwidth_per_slot = clk_get_rate(ipu_clk) * 4 / 8;

dev_dbg(dev, "dmfc: 8 slots with %ldMpixel/s bandwidth each\n",
priv->bandwidth_per_slot / 100);
-- 
1.8.3.1

[PATCH 4/4] staging: drm/imx: ipu-dmfc: use defines for ipu channel numbers

[Philipp Zabel]

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
index 1dc9817..2e97c33 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
@@ -61,7 +61,7 @@ struct dmfc_channel_data {

 static const struct dmfc_channel_data dmfcdata[] = {
{
-   .ipu_channel= 23,
+   .ipu_channel= IPUV3_CHANNEL_MEM_BG_SYNC,
.channel_reg= DMFC_DP_CHAN,
.shift  = DMFC_DP_CHAN_5B_23,
.eot_shift  = 20,
@@ -73,13 +73,13 @@ static const struct dmfc_channel_data dmfcdata[] = {
.eot_shift  = 22,
.max_fifo_lines = 1,
}, {
-   .ipu_channel= 27,
+   .ipu_channel= IPUV3_CHANNEL_MEM_FG_SYNC,
.channel_reg= DMFC_DP_CHAN,
.shift  = DMFC_DP_CHAN_5F_27,
.eot_shift  = 21,
.max_fifo_lines = 2,
}, {
-   .ipu_channel= 28,
+   .ipu_channel= IPUV3_CHANNEL_MEM_DC_SYNC,
.channel_reg= DMFC_WR_CHAN,
.shift  = DMFC_WR_CHAN_1_28,
.eot_shift  = 16,
-- 
1.8.3.1

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

 3. reference buf1 for reading
>  3.1 wait for fence from GPU to
>  signal
> 4. kick off V4L2 processing
>
>
That seems like very specific to Desktop GPU. isn't it?


> So you don't need to wait in userspace and potentially avoid some
> context switches,


Also not true.


> but you still have to make sure that GPU commands are
> queued before you queue the V4L2 operation to make sure things get
> operated on in the right order.
>
>
>


I'd like to say you that my approach is not perfact so may definietly
have many problems and addition works - actually, I found some problems and
are solving them, in addition, the implememtation to generic user side
interfacing mechanism is in progress for the destination - , and thanks to
your comments. However, I think we can try to do for more better something.
Lastly, I'll look forward to keeping up your good advices.

Thanks,
Inki Dae



> Regards,
> Lucas
>
> --
> Pengutronix e.K.   | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130621/71d8da2d/attachment.html>

[Intel-gfx] [PATCH] drm/i915: move i915_trace_irq_get() out of the tracing macro

[Chris Wilson]

On Fri, Jun 21, 2013 at 12:15:53PM +0200, Sebastian Andrzej Siewior wrote:
> There is a report on RT about "BUG: scheduling while atomic" because the
> sleeping lock is taken in tracing context. This patch simply moves
> locking operation out of the tracing macro.

No. This enables the IRQ, as well as making a number of
very expensively serialised read, unconditionally.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[patch] drm/nouveau: off by one in nouveau_drm_vblank_enable()

[Dan Carpenter]

On Wed, Apr 03, 2013 at 01:33:09PM +0200, Maarten Lankhorst wrote:
> Op 03-04-13 10:05, Dan Carpenter schreef:
> > The test here should be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()".
> >
> > Signed-off-by: Dan Carpenter 
> Acked-by: Maarten Lankhorst 

We still need this patch in linux-next.

regards,
dan carpenter

drm/radeon/kms: get HPD info for connectors

[Dan Carpenter]

Hello Alex Deucher,

The patch eed45b30cd14: "drm/radeon/kms: get HPD info for connectors" 
from Dec 4, 2009, leads to the following warning:
"drivers/gpu/drm/radeon/radeon_atombios.c:950 
radeon_get_atom_connector_info_from_supported_devices_table()
 error: buffer overflow 'supported_devices->info.asConnInfo' 10 <= 15"

drivers/gpu/drm/radeon/radeon_atombios.c
   943  if (frev > 1)
   944  max_device = ATOM_MAX_SUPPORTED_DEVICE;
   945  else
   946  max_device = ATOM_MAX_SUPPORTED_DEVICE_INFO;
   947  
   948  for (i = 0; i < max_device; i++) {
   949  ATOM_CONNECTOR_INFO_I2C ci =
   950  supported_devices->info.asConnInfo[i];

If max_device is set to ATOM_MAX_SUPPORTED_DEVICE then we read beyond
the end of the asConnInfo[] array and crash.

   951  
   952  bios_connectors[i].valid = false;
   953  

regards,
dan carpenter

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Lucas Stach]

Hi Inki,

please refrain from sending HTML Mails, it makes proper quoting without
messing up the layout everywhere pretty hard.

Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae:
[...]

> Yeah, you'll some knowledge and understanding about the API
> you are
> working with to get things right. But I think it's not an
> unreasonable
> thing to expect the programmer working directly with kernel
> interfaces
> to read up on how things work.
> 
> Second thing: I'll rather have *one* consistent API for every
> subsystem,
> even if they differ from each other than having to implement
> this
> syncpoint thing in every subsystem. Remember: a single execbuf
> in DRM
> might reference both GEM objects backed by dma-buf as well
> native SHM or
> CMA backed objects. The dma-buf-mgr proposal already allows
> you to
> handle dma-bufs much the same way during validation than
> native GEM
> objects.
>  
> Actually, at first I had implemented a fence helper framework based on
> reservation and dma fence to provide easy-use-interface for device
> drivers. However, that was wrong implemention: I had not only
> customized the dma fence but also not considered dead lock issue.
> After that, I have reimplemented it as dmabuf sync to solve dead
> issue, and at that time, I realized that we first need to concentrate
> on the most basic thing: the fact CPU and CPU, CPU and DMA, or DMA and
> DMA can access a same buffer, And the fact simple is the best, and the
> fact we need not only kernel side but also user side interfaces. After
> that, I collected what is the common part for all subsystems, and I
> have devised this dmabuf sync framework for it. I'm not really
> specialist in Desktop world. So question. isn't the execbuf used only
> for the GPU? the gpu has dedicated video memory(VRAM) so it needs
> migration mechanism between system memory and the dedicated video
> memory, and also to consider ordering issue while be migrated.
>  

Yeah, execbuf is pretty GPU specific, but I don't see how this matters
for this discussion. Also I don't see a big difference between embedded
and desktop GPUs. Buffer migration is more of a detail here. Both take
command stream that potentially reference other buffers, which might be
native GEM or dma-buf backed objects. Both have to make sure the buffers
are in the right domain (caches cleaned and address mappings set up) and
are available for the desired operation, meaning you have to sync with
other DMA engines and maybe also with CPU.

The only case where sync isn't clearly defined right now by the current
API entrypoints is when you access memory through the dma-buf fallback
mmap support, which might happen with some software processing element
in a video pipeline or something. I agree that we will need a userspace
interface here, but I think this shouldn't be yet another sync object,
but rather more a prepare/fini_cpu_access ioctl on the dma-buf which
hooks into the existing dma-fence and reservation stuff.

> 
> And to get back to my original point: if you have more than
> one task
> operating together on a buffer you absolutely need some kind
> of real IPC
> to sync them up and do something useful. Both you syncpoints
> and the
> proposed dma-fences only protect the buffer accesses to make
> sure
> different task don't stomp on each other. There is nothing in
> there to
> make sure that the output of your pipeline is valid. You have
> to take
> care of that yourself in userspace. I'll reuse your example to
> make it
> clear what I mean:
> 
> Task A Task B
> -- ---
> dma_buf_sync_lock(buf1)
> CPU write buf1
> dma_buf_sync_unlock(buf1)
>   -schedule Task A again---
> dma_buf_sync_lock(buf1)
> CPU write buf1
> dma_buf_sync_unlock(buf1)
> -schedule Task B-
>qbuf(buf1)
> 
> dma_buf_sync_lock(buf1)
>
> 
> This is what can happen if you don't take care of proper
> syncing. Task A
> writes something to the buffer in expectation that Task B will
> take care
> of it, but before Task B even gets scheduled Task A overwrites
> the
> buffer again. Not what you wanted, isn't it?
>  
> Exactly wrong example. I had already mentioned about that. "In case
> that data flow goes from A to B, it needs some kind of IPC between the
> two tasks every time"  So again, your example would have no any
> probl

[PATCH 1/2] staging: drm/imx: use generic irqchip

[Philipp Zabel]

This depends on the patch "genirq: Generic chip: Add linear irq domain support"
and removes the custom IPU irq_chip and irq_domain_ops. Instead, the generic
irq chip implementation is reused.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 90 +
 1 file changed, 26 insertions(+), 64 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index d629d6d..c135c66 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -986,53 +986,6 @@ static void ipu_err_irq_handler(unsigned int irq, struct 
irq_desc *desc)
chained_irq_exit(chip, desc);
 }

-static void ipu_ack_irq(struct irq_data *d)
-{
-   struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   irq_hw_number_t irq = d->hwirq;
-
-   ipu_cm_write(ipu, 1 << (irq % 32), IPU_INT_STAT(irq / 32));
-}
-
-static void ipu_unmask_irq(struct irq_data *d)
-{
-   struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   irq_hw_number_t irq = d->hwirq;
-   unsigned long flags;
-   u32 reg;
-
-   spin_lock_irqsave(&ipu->lock, flags);
-
-   reg = ipu_cm_read(ipu, IPU_INT_CTRL(irq / 32));
-   reg |= 1 << (irq % 32);
-   ipu_cm_write(ipu, reg, IPU_INT_CTRL(irq / 32));
-
-   spin_unlock_irqrestore(&ipu->lock, flags);
-}
-
-static void ipu_mask_irq(struct irq_data *d)
-{
-   struct ipu_soc *ipu = irq_data_get_irq_chip_data(d);
-   irq_hw_number_t irq = d->hwirq;
-   unsigned long flags;
-   u32 reg;
-
-   spin_lock_irqsave(&ipu->lock, flags);
-
-   reg = ipu_cm_read(ipu, IPU_INT_CTRL(irq / 32));
-   reg &= ~(1 << (irq % 32));
-   ipu_cm_write(ipu, reg, IPU_INT_CTRL(irq / 32));
-
-   spin_unlock_irqrestore(&ipu->lock, flags);
-}
-
-static struct irq_chip ipu_irq_chip = {
-   .name = "IPU",
-   .irq_ack = ipu_ack_irq,
-   .irq_mask = ipu_mask_irq,
-   .irq_unmask = ipu_unmask_irq,
-};
-
 int ipu_idmac_channel_irq(struct ipu_soc *ipu, struct ipuv3_channel *channel,
enum ipu_channel_irq irq_type)
 {
@@ -1171,32 +1124,39 @@ err_register:
return ret;
 }

-static int ipu_irq_map(struct irq_domain *h, unsigned int irq,
-  irq_hw_number_t hw)
-{
-   struct ipu_soc *ipu = h->host_data;
-
-   irq_set_chip_and_handler(irq, &ipu_irq_chip, handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID);
-   irq_set_chip_data(irq, ipu);
-
-   return 0;
-}
-
-const struct irq_domain_ops ipu_irq_domain_ops = {
-   .map = ipu_irq_map,
-   .xlate = irq_domain_xlate_onecell,
-};

 static int ipu_irq_init(struct ipu_soc *ipu)
 {
+   struct irq_chip_generic *gc;
+   struct irq_chip_type *ct;
+   int ret, i;
+
ipu->domain = irq_domain_add_linear(ipu->dev->of_node, IPU_NUM_IRQS,
-   &ipu_irq_domain_ops, ipu);
+   &irq_generic_chip_ops, ipu);
if (!ipu->domain) {
dev_err(ipu->dev, "failed to add irq domain\n");
return -ENODEV;
}

+   ret = irq_alloc_domain_generic_chips(ipu->domain, 32, 1, "IPU",
+handle_level_irq, 0, IRQF_VALID, 
0);
+   if (ret < 0) {
+   dev_err(ipu->dev, "failed to alloc generic irq chips\n");
+   irq_domain_remove(ipu->domain);
+   return ret;
+   }
+
+   for (i = 0; i < IPU_NUM_IRQS; i += 32) {
+   gc = irq_get_domain_generic_chip(ipu->domain, i);
+   gc->reg_base = ipu->cm_reg;
+   ct = gc->chip_types;
+   ct->chip.irq_ack = irq_gc_ack_set_bit;
+   ct->chip.irq_mask = irq_gc_mask_clr_bit;
+   ct->chip.irq_unmask = irq_gc_mask_set_bit;
+   ct->regs.ack = IPU_INT_STAT(i / 32);
+   ct->regs.mask = IPU_INT_CTRL(i / 32);
+   }
+
irq_set_chained_handler(ipu->irq_sync, ipu_irq_handler);
irq_set_handler_data(ipu->irq_sync, ipu);
irq_set_chained_handler(ipu->irq_err, ipu_err_irq_handler);
@@ -1214,6 +1174,8 @@ static void ipu_irq_exit(struct ipu_soc *ipu)
irq_set_chained_handler(ipu->irq_sync, NULL);
irq_set_handler_data(ipu->irq_sync, NULL);

+   /* TODO: remove irq_domain_generic_chips */
+
for (i = 0; i < IPU_NUM_IRQS; i++) {
irq = irq_linear_revmap(ipu->domain, i);
if (irq)
-- 
1.8.3.1

[PATCH 2/2] staging: drm/imx: use generic irq chip unused field to block out invalid irqs

[Philipp Zabel]

This depends on the patch "genirq: irqchip: Add mask to block out invalid irqs"
and masks out reserved bits using the unused interrupt bitfield.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index c135c66..b470cda 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
@@ -1129,6 +1129,16 @@ static int ipu_irq_init(struct ipu_soc *ipu)
 {
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
+   unsigned long unused[IPU_NUM_IRQS / 32] = {
+   0x400100d0, 0xffe000fd,
+   0x400100d0, 0xffe000fd,
+   0x400100d0, 0xffe000fd,
+   0x4077, 0xffe7e1fd,
+   0x23fe, 0x8880fff0,
+   0xf98fe7d0, 0xfff81fff,
+   0x400100d0, 0xffe000fd,
+   0x,
+   };
int ret, i;

ipu->domain = irq_domain_add_linear(ipu->dev->of_node, IPU_NUM_IRQS,
@@ -1149,6 +1159,7 @@ static int ipu_irq_init(struct ipu_soc *ipu)
for (i = 0; i < IPU_NUM_IRQS; i += 32) {
gc = irq_get_domain_generic_chip(ipu->domain, i);
gc->reg_base = ipu->cm_reg;
+   gc->unused = unused[i / 32];
ct = gc->chip_types;
ct->chip.irq_ack = irq_gc_ack_set_bit;
ct->chip.irq_mask = irq_gc_mask_clr_bit;
-- 
1.8.3.1

[PATCH 0/2] IPU generic irq chip

[Philipp Zabel]

Hi,

with linear domain support in the generic irq chip framework, we can drop the
custom irq_chip / irq_domain_ops altogether and use the generic irq chip
implementation instead. The following two patches depend on
"genirq: Generic chip: Add linear irq domain support" and
"genirq: irqchip: Add mask to block out invalid irqs":
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?id=e8bd834f73714378ef110a64287db1b77033c8da

regards
Philipp

---
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 101 ++--
 1 file changed, 37 insertions(+), 64 deletions(-)

drm/radeon/kms: get HPD info for connectors

[Alex Deucher]

On Fri, Jun 21, 2013 at 8:25 AM, Dan Carpenter  
wrote:
> Hello Alex Deucher,
>
> The patch eed45b30cd14: "drm/radeon/kms: get HPD info for connectors"
> from Dec 4, 2009, leads to the following warning:
> "drivers/gpu/drm/radeon/radeon_atombios.c:950
> radeon_get_atom_connector_info_from_supported_devices_table()
>  error: buffer overflow 'supported_devices->info.asConnInfo' 10 <= 15"
>
> drivers/gpu/drm/radeon/radeon_atombios.c
>943  if (frev > 1)
>944  max_device = ATOM_MAX_SUPPORTED_DEVICE;
>945  else
>946  max_device = ATOM_MAX_SUPPORTED_DEVICE_INFO;
>947
>948  for (i = 0; i < max_device; i++) {
>949  ATOM_CONNECTOR_INFO_I2C ci =
>950  supported_devices->info.asConnInfo[i];
>
> If max_device is set to ATOM_MAX_SUPPORTED_DEVICE then we read beyond
> the end of the asConnInfo[] array and crash.

The array is variably sized based on the vbios version so the array
size in the header is largely meaningless.

Alex

>
>951
>952  bios_connectors[i].valid = false;
>953
>
> regards,
> dan carpenter
>

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Jerome Glisse]

On Fri, Jun 21, 2013 at 12:55 PM, Inki Dae  wrote:
> 2013/6/21 Lucas Stach :
>> Hi Inki,
>>
>> please refrain from sending HTML Mails, it makes proper quoting without
>> messing up the layout everywhere pretty hard.
>>
>
> Sorry about that. I should have used text mode.
>
>> Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae:
>> [...]
>>
>>> Yeah, you'll some knowledge and understanding about the API
>>> you are
>>> working with to get things right. But I think it's not an
>>> unreasonable
>>> thing to expect the programmer working directly with kernel
>>> interfaces
>>> to read up on how things work.
>>>
>>> Second thing: I'll rather have *one* consistent API for every
>>> subsystem,
>>> even if they differ from each other than having to implement
>>> this
>>> syncpoint thing in every subsystem. Remember: a single execbuf
>>> in DRM
>>> might reference both GEM objects backed by dma-buf as well
>>> native SHM or
>>> CMA backed objects. The dma-buf-mgr proposal already allows
>>> you to
>>> handle dma-bufs much the same way during validation than
>>> native GEM
>>> objects.
>>>
>>> Actually, at first I had implemented a fence helper framework based on
>>> reservation and dma fence to provide easy-use-interface for device
>>> drivers. However, that was wrong implemention: I had not only
>>> customized the dma fence but also not considered dead lock issue.
>>> After that, I have reimplemented it as dmabuf sync to solve dead
>>> issue, and at that time, I realized that we first need to concentrate
>>> on the most basic thing: the fact CPU and CPU, CPU and DMA, or DMA and
>>> DMA can access a same buffer, And the fact simple is the best, and the
>>> fact we need not only kernel side but also user side interfaces. After
>>> that, I collected what is the common part for all subsystems, and I
>>> have devised this dmabuf sync framework for it. I'm not really
>>> specialist in Desktop world. So question. isn't the execbuf used only
>>> for the GPU? the gpu has dedicated video memory(VRAM) so it needs
>>> migration mechanism between system memory and the dedicated video
>>> memory, and also to consider ordering issue while be migrated.
>>>
>>
>> Yeah, execbuf is pretty GPU specific, but I don't see how this matters
>> for this discussion. Also I don't see a big difference between embedded
>> and desktop GPUs. Buffer migration is more of a detail here. Both take
>> command stream that potentially reference other buffers, which might be
>> native GEM or dma-buf backed objects. Both have to make sure the buffers
>> are in the right domain (caches cleaned and address mappings set up) and
>> are available for the desired operation, meaning you have to sync with
>> other DMA engines and maybe also with CPU.
>
> Yeah, right. Then, in case of desktop gpu, does't it need additional
> something to do when a buffer/s is/are migrated from system memory to
> video memory domain, or from video memory to system memory domain? I
> guess the below members does similar thing, and all other DMA devices
> would not need them:
> struct fence {
>   ...
>   unsigned int context, seqno;
>   ...
> };
>
> And,
>struct seqno_fence {
>  ...
>  uint32_t seqno_ofs;
>  ...
>};
>
>>
>> The only case where sync isn't clearly defined right now by the current
>> API entrypoints is when you access memory through the dma-buf fallback
>> mmap support, which might happen with some software processing element
>> in a video pipeline or something. I agree that we will need a userspace
>> interface here, but I think this shouldn't be yet another sync object,
>> but rather more a prepare/fini_cpu_access ioctl on the dma-buf which
>> hooks into the existing dma-fence and reservation stuff.
>
> I think we don't need addition ioctl commands for that. I am thinking
> of using existing resources as possible. My idea also is similar in
> using the reservation stuff to your idea because my approach also
> should use the dma-buf resource. However, My idea is that a user
> process, that wants buffer synchronization with the other, sees a sync
> object as a file descriptor like dma-buf does. The below shows simple
> my idea about it:
>
> ioctl(dmabuf_fd, DMA_BUF_IOC_OPEN_SYNC, &sync);
>
> flock(sync->fd, LOCK_SH); <- LOCK_SH means a shared lock.
> CPU access for read
> flock(sync->fd, LOCK_UN);
>
> Or
>
> flock(sync->fd, LOCK_EX); <- LOCK_EX means an exclusive lock
> CPU access for write
> flock(sync->fd, LOCK_UN);
>
> close(sync->fd);
>
> As you know, that's similar to dmabuf export feature.
>
> In addition, a more simple idea,
> flock(dmabuf_fd, LOCK_SH/EX);
> CPU access for read/write
> flock(dmabuf_fd, LOCK_UN);
>
> However, I'm not sure that the above examples could be worke

[PATCH V2 0/7] drm/tilcdc: bug fixes, mode selection improvements

[Darren Etheridge]

The series of patches that follow are intended to address issues that
have been found in the tilcdc drm driver. The patchset enables support
for screen resolutions with horizontal resolutions greater than 1024
pixels.  The patchset also addresses a limitation where certain
monitor timings would overflow LCD controller timing registers causing
either no monitor signal or a very corrupted display.  This patchset
will stop monitor modes from being reported as valid if the lcd
controller cannot support them.  

V2:
Fix typos in commit messages
Add a patch that enables runtime modesetting to work correctly
Fix an issue where the slave encoder can initialize before the i2c
subsystem, resulting in no displays being configured.

Applies cleanly on drm-next.

Darren Etheridge (6):
  drm/tilcdc: support pixel widths greater than 1024
  drm/tilcdc: adding some more devicetree config
  drm/tilcdc: fixing off by one errors found on analyzer
  drm/tilcdc: adding more guards to prevent selection of invalid modes
  drm/tilcdc: whitespace fixes and tidyup
  drm/tilcdc fixing i2c/slave initialization race

Pantelis Antoniou (1):
  drm/tilcdc: Clear bits of register we're going to set.

 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |8 ++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  117 +--
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|   25 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   24 -
 drivers/gpu/drm/tilcdc/tilcdc_regs.h   |1 +
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  |   53 +
 6 files changed, 189 insertions(+), 39 deletions(-)

[PATCH V2 1/7] drm/tilcdc: support pixel widths greater than 1024

[Darren Etheridge]

TI LCD controller version 2 has an extended eleventh
bit that enables horizontal resolutions greater than
1024 pixels to be specified (upto 2048).  This patch
adds support for setting this bit on LCDC V2.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |   15 +++
 drivers/gpu/drm/tilcdc/tilcdc_regs.h |1 +
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 5dd3c7d..84fdf25 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -310,6 +310,21 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
((vsw & 0x3f) << 10);
tilcdc_write(dev, LCDC_RASTER_TIMING_1_REG, reg);

+   /*
+* be sure to set Bit 10 for the V2 LCDC controller,
+* otherwise limited to 1024 pixels width, stopping
+* 1920x1080 being suppoted.
+*/
+   if (priv->rev == 2) {
+   if ((mode->vdisplay - 1) & 0x400) {
+   tilcdc_set(dev, LCDC_RASTER_TIMING_2_REG,
+   LCDC_LPP_B10);
+   } else {
+   tilcdc_clear(dev, LCDC_RASTER_TIMING_2_REG,
+   LCDC_LPP_B10);
+   }
+   }
+
/* Configure display type: */
reg = tilcdc_read(dev, LCDC_RASTER_CTRL_REG) &
~(LCDC_TFT_MODE | LCDC_MONO_8BIT_MODE | LCDC_MONOCHROME_MODE |
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
index 17fd1b4..1bf5e25 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
@@ -80,6 +80,7 @@
 #define LCDC_INVERT_PIXEL_CLOCK  BIT(22)
 #define LCDC_INVERT_HSYNCBIT(21)
 #define LCDC_INVERT_VSYNCBIT(20)
+#define LCDC_LPP_B10 BIT(26)

 /* LCDC Block */
 #define LCDC_PID_REG 0x0
-- 
1.7.0.4

[PATCH V2 2/7] drm/tilcdc: adding some more devicetree config

[Darren Etheridge]

Adding support for max-pixelclock and max-width device tree
entries. As some devices that use the tilcdc hardware module
have restrictions on the allowed/tested values.  Also update DT
bindings document to reflect new parameters.

Signed-off-by: Darren Etheridge 
---
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |8 +++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |   23 ++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|   15 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   22 +++
 4 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index e5f1301..fff10da 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -10,6 +10,14 @@ Recommended properties:
services interrupts for this device.
  - ti,hwmods: Name of the hwmod associated to the LCDC

+Optional properties:
+ - max-bandwidth: The maximum pixels per second that the memory
+   interface / lcd controller combination can sustain
+ - max-width: The maximum horizontal pixel width supported by
+   the lcd controller.
+ - max-pixelclock: The maximum pixel clock that can be supported
+   by the lcd controller in KHz.
+
 Example:

fb: fb at 4830e000 {
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 84fdf25..05f2b14 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -448,10 +448,29 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
if (mode->vdisplay > 2048)
return MODE_VIRTUAL_Y;

+   /*
+* some devices have a maximum allowed pixel clock
+* configured from the DT
+*/
+   if (mode->clock > priv->max_pixelclock) {
+   DBG("Pruning mode, pixel clock too high");
+   return MODE_CLOCK_HIGH;
+   }
+
+   /*
+* some devices further limit the max horizontal resolution
+* configured from the DT
+*/
+   if (mode->hdisplay > priv->max_width)
+   return MODE_BAD_WIDTH;
+
/* filter out modes that would require too much memory bandwidth: */
-   bandwidth = mode->hdisplay * mode->vdisplay * drm_mode_vrefresh(mode);
-   if (bandwidth > priv->max_bandwidth)
+   bandwidth = mode->hdisplay * mode->vdisplay *
+   drm_mode_vrefresh(mode);
+   if (bandwidth > priv->max_bandwidth) {
+   DBG("Pruning mode, exceeds defined bandwidth limit");
return MODE_BAD;
+   }

return MODE_OK;
 }
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index f2a6528..1e8f273 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -212,7 +212,20 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
 #endif

if (of_property_read_u32(node, "max-bandwidth", &priv->max_bandwidth))
-   priv->max_bandwidth = 1280 * 1024 * 60;
+   priv->max_bandwidth = TILCDC_DEFAULT_MAX_BANDWIDTH;
+
+   DBG("Maximum Bandwidth Value %d", priv->max_bandwidth);
+
+   if (of_property_read_u32(node, "ti,max-width", &priv->max_width))
+   priv->max_width = TILCDC_DEFAULT_MAX_WIDTH;
+
+   DBG("Maximum Horizontal Pixel Width Value %dpixels", priv->max_width);
+
+   if (of_property_read_u32(node, "ti,max-pixelclock",
+   &priv->max_pixelclock))
+   priv->max_pixelclock = TILCDC_DEFAULT_MAX_PIXELCLOCK;
+
+   DBG("Maximum Pixel Clock Value %dKHz", priv->max_pixelclock);

pm_runtime_enable(dev->dev);

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 0906843..66df316 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -34,6 +34,18 @@
 #include 
 #include 

+/* Defaulting to pixel clock defined on AM335x */
+#define TILCDC_DEFAULT_MAX_PIXELCLOCK  126000
+/* Defaulting to max width as defined on AM335x */
+#define TILCDC_DEFAULT_MAX_WIDTH  2048
+/*
+ * This may need some tweaking, but want to allow at least 1280x1024 at 60
+ * with optimized DDR & EMIF settings tweaked 1920x1080 at 24 appears to
+ * be supportable
+ */
+#define TILCDC_DEFAULT_MAX_BANDWIDTH  (1280*1024*60)
+
+
 struct tilcdc_drm_private {
void __iomem *mmio;

@@ -43,6 +55,16 @@ struct tilcdc_drm_private {

/* don't attempt resolutions w/ higher W * H * Hz: */
uint32_t max_bandwidth;
+   /*
+* Pixel Clock will be restricted to some value as
+* defined in the device datasheet measured in KHz
+*/
+   uint32_t max_pixelclock;
+   /*
+* Max allowable width is limited on a per device basis
+* measu

[PATCH V2 4/7] drm/tilcdc: adding more guards to prevent selection of invalid modes

[Darren Etheridge]

The tilcdc has a number of limitations for the allowed sizes of
the various adjustable timing parameter.  Some modes are outside
of these timings.  This commit will prune modes that report timings
that will overflow the allowed sizes in the tilcdc.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |   46 ++
 1 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 4455a41..283e0a6 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -442,7 +442,12 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
 {
struct tilcdc_drm_private *priv = crtc->dev->dev_private;
unsigned int bandwidth;
+   uint32_t hbp, hfp, hsw, vbp, vfp, vsw;

+   /*
+* check to see if the width is within the range that
+* the LCD Controller physically supports
+*/
if (mode->hdisplay > tilcdc_crtc_max_width(crtc))
return MODE_VIRTUAL_X;

@@ -453,6 +458,47 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
if (mode->vdisplay > 2048)
return MODE_VIRTUAL_Y;

+   DBG("Processing mode %dx%d@%d with pixel clock %d",
+   mode->hdisplay, mode->vdisplay,
+   drm_mode_vrefresh(mode), mode->clock);
+
+   hbp = mode->htotal - mode->hsync_end;
+   hfp = mode->hsync_start - mode->hdisplay;
+   hsw = mode->hsync_end - mode->hsync_start;
+   vbp = mode->vtotal - mode->vsync_end;
+   vfp = mode->vsync_start - mode->vdisplay;
+   vsw = mode->vsync_end - mode->vsync_start;
+
+   if ((hbp-1) & ~0x3ff) {
+   DBG("Pruning mode: Horizontal Back Porch out of range");
+   return MODE_HBLANK_WIDE;
+   }
+
+   if ((hfp-1) & ~0x3ff) {
+   DBG("Pruning mode: Horizontal Front Porch out of range");
+   return MODE_HBLANK_WIDE;
+   }
+
+   if ((hsw-1) & ~0x3ff) {
+   DBG("Pruning mode: Horizontal Sync Width out of range");
+   return MODE_HSYNC_WIDE;
+   }
+
+   if (vbp & ~0xff) {
+   DBG("Pruning mode: Vertical Back Porch out of range");
+   return MODE_VBLANK_WIDE;
+   }
+
+   if (vfp & ~0xff) {
+   DBG("Pruning mode: Vertical Front Porch out of range");
+   return MODE_VBLANK_WIDE;
+   }
+
+   if ((vsw-1) & ~0x3f) {
+   DBG("Pruning mode: Vertical Sync Width out of range");
+   return MODE_VSYNC_WIDE;
+   }
+
/*
 * some devices have a maximum allowed pixel clock
 * configured from the DT
-- 
1.7.0.4

[PATCH V2 3/7] drm/tilcdc: fixing off by one errors found on analyzer

[Darren Etheridge]

When hooking up to an HDMI analyzer noticed some timings were
off by one.  Referring to the hardware technical reference manual
for the lcd controller some of the timing registers use 0 to
represent 1.  This patch addresses that issue.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |   19 ---
 1 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 05f2b14..4455a41 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -289,17 +289,22 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
reg = tilcdc_read(dev, LCDC_RASTER_TIMING_2_REG) & ~0x000fff00;
reg |= LCDC_AC_BIAS_FREQUENCY(info->ac_bias) |
LCDC_AC_BIAS_TRANSITIONS_PER_INT(info->ac_bias_intrpt);
+
+   /*
+* subtract one from hfp, hbp, hsw because the hardware uses
+* a value of 0 as 1
+*/
if (priv->rev == 2) {
-   reg |= (hfp & 0x300) >> 8;
-   reg |= (hbp & 0x300) >> 4;
-   reg |= (hsw & 0x3c0) << 21;
+   reg |= ((hfp-1) & 0x300) >> 8;
+   reg |= ((hbp-1) & 0x300) >> 4;
+   reg |= ((hsw-1) & 0x3c0) << 21;
}
tilcdc_write(dev, LCDC_RASTER_TIMING_2_REG, reg);

reg = (((mode->hdisplay >> 4) - 1) << 4) |
-   ((hbp & 0xff) << 24) |
-   ((hfp & 0xff) << 16) |
-   ((hsw & 0x3f) << 10);
+   (((hbp-1) & 0xff) << 24) |
+   (((hfp-1) & 0xff) << 16) |
+   (((hsw-1) & 0x3f) << 10);
if (priv->rev == 2)
reg |= (((mode->hdisplay >> 4) - 1) & 0x40) >> 3;
tilcdc_write(dev, LCDC_RASTER_TIMING_0_REG, reg);
@@ -307,7 +312,7 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
reg = ((mode->vdisplay - 1) & 0x3ff) |
((vbp & 0xff) << 24) |
((vfp & 0xff) << 16) |
-   ((vsw & 0x3f) << 10);
+   (((vsw-1) & 0x3f) << 10);
tilcdc_write(dev, LCDC_RASTER_TIMING_1_REG, reg);

/*
-- 
1.7.0.4

[PATCH V2 5/7] drm/tilcdc: whitespace fixes and tidyup

[Darren Etheridge]

keeping checkpatch happy.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 283e0a6..6118651 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -42,7 +42,8 @@ struct tilcdc_crtc {

 static void unref_worker(struct work_struct *work)
 {
-   struct tilcdc_crtc *tilcdc_crtc = container_of(work, struct 
tilcdc_crtc, work);
+   struct tilcdc_crtc *tilcdc_crtc =
+   container_of(work, struct tilcdc_crtc, work);
struct drm_device *dev = tilcdc_crtc->base.dev;
struct drm_framebuffer *fb;

@@ -55,10 +56,12 @@ static void unref_worker(struct work_struct *work)
 static void set_scanout(struct drm_crtc *crtc, int n)
 {
static const uint32_t base_reg[] = {
-   LCDC_DMA_FB_BASE_ADDR_0_REG, 
LCDC_DMA_FB_BASE_ADDR_1_REG,
+   LCDC_DMA_FB_BASE_ADDR_0_REG,
+   LCDC_DMA_FB_BASE_ADDR_1_REG,
};
static const uint32_t ceil_reg[] = {
-   LCDC_DMA_FB_CEILING_ADDR_0_REG, 
LCDC_DMA_FB_CEILING_ADDR_1_REG,
+   LCDC_DMA_FB_CEILING_ADDR_0_REG,
+   LCDC_DMA_FB_CEILING_ADDR_1_REG,
};
static const uint32_t stat[] = {
LCDC_END_OF_FRAME0, LCDC_END_OF_FRAME1,
@@ -194,7 +197,8 @@ static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int 
mode)
tilcdc_crtc->frame_done = false;
stop(crtc);

-   /* if necessary wait for framedone irq which will still come
+   /*
+* if necessary wait for framedone irq which will still come
 * before putting things to sleep..
 */
if (priv->rev == 2) {
@@ -504,7 +508,7 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
 * configured from the DT
 */
if (mode->clock > priv->max_pixelclock) {
-   DBG("Pruning mode, pixel clock too high");
+   DBG("Pruning mode: pixel clock too high");
return MODE_CLOCK_HIGH;
}

@@ -519,7 +523,7 @@ int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct 
drm_display_mode *mode)
bandwidth = mode->hdisplay * mode->vdisplay *
drm_mode_vrefresh(mode);
if (bandwidth > priv->max_bandwidth) {
-   DBG("Pruning mode, exceeds defined bandwidth limit");
+   DBG("Pruning mode: exceeds defined bandwidth limit");
return MODE_BAD;
}

-- 
1.7.0.4

[PATCH V2 6/7] drm/tilcdc fixing i2c/slave initialization race

[Darren Etheridge]

In certain senarios drm will initialize before i2c this means that i2c
slave devices like the nxp tda998x will fail to be probed.  This patch
detects this condition then defers the probe of the slave device and
the tilcdc main driver.

Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c   |   10 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h   |2 +-
 drivers/gpu/drm/tilcdc/tilcdc_slave.c |   53 ++---
 3 files changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 1e8f273..40b71da 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -26,6 +26,7 @@
 #include "drm_fb_helper.h"

 static LIST_HEAD(module_list);
+static bool slave_probing;

 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
@@ -41,6 +42,11 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
list_del(&mod->list);
 }

+void tilcdc_slave_probedefer(bool defered)
+{
+   slave_probing = defered;
+}
+
 static struct of_device_id tilcdc_of_match[];

 static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
@@ -580,6 +586,10 @@ static int tilcdc_pdev_probe(struct platform_device *pdev)
return -ENXIO;
}

+   /* defer probing if slave is in deferred probing */
+   if (slave_probing == true)
+   return -EPROBE_DEFER;
+
return drm_platform_init(&tilcdc_driver, pdev);
 }

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 66df316..0938036 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -117,7 +117,7 @@ struct tilcdc_module {
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs);
 void tilcdc_module_cleanup(struct tilcdc_module *mod);
-
+void tilcdc_slave_probedefer(bool defered);

 /* Panel config that needs to be set in the crtc, but is not coming from
  * the mode timings.  The display module is expected to call
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 8bf4fd1..dfffaf0 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -298,6 +298,7 @@ static int slave_probe(struct platform_device *pdev)
struct tilcdc_module *mod;
struct pinctrl *pinctrl;
uint32_t i2c_phandle;
+   struct i2c_adapter *slavei2c;
int ret = -EINVAL;

/* bail out early if no DT data: */
@@ -306,44 +307,48 @@ static int slave_probe(struct platform_device *pdev)
return -ENXIO;
}

-   slave_mod = kzalloc(sizeof(*slave_mod), GFP_KERNEL);
-   if (!slave_mod)
-   return -ENOMEM;
-
-   mod = &slave_mod->base;
-
-   tilcdc_module_init(mod, "slave", &slave_module_ops);
-
-   pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
-   if (IS_ERR(pinctrl))
-   dev_warn(&pdev->dev, "pins are not configured\n");
-
+   /* Bail out early if i2c not specified */
if (of_property_read_u32(node, "i2c", &i2c_phandle)) {
dev_err(&pdev->dev, "could not get i2c bus phandle\n");
-   goto fail;
+   return ret;
}

-   mod->preferred_bpp = slave_info.bpp;
-
i2c_node = of_find_node_by_phandle(i2c_phandle);
if (!i2c_node) {
dev_err(&pdev->dev, "could not get i2c bus node\n");
-   goto fail;
+   return ret;
}

-   slave_mod->i2c = of_find_i2c_adapter_by_node(i2c_node);
-   if (!slave_mod->i2c) {
+   /* but defer the probe if it can't be initialized it might come later */
+   slavei2c = of_find_i2c_adapter_by_node(i2c_node);
+   of_node_put(i2c_node);
+
+   if (!slavei2c) {
+   ret = -EPROBE_DEFER;
+   tilcdc_slave_probedefer(true);
dev_err(&pdev->dev, "could not get i2c\n");
-   goto fail;
+   return ret;
}

-   of_node_put(i2c_node);
+   slave_mod = kzalloc(sizeof(*slave_mod), GFP_KERNEL);
+   if (!slave_mod)
+   return -ENOMEM;

-   return 0;
+   mod = &slave_mod->base;

-fail:
-   slave_destroy(mod);
-   return ret;
+   mod->preferred_bpp = slave_info.bpp;
+
+   slave_mod->i2c = slavei2c;
+
+   tilcdc_module_init(mod, "slave", &slave_module_ops);
+
+   pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+   if (IS_ERR(pinctrl))
+   dev_warn(&pdev->dev, "pins are not configured\n");
+
+   tilcdc_slave_probedefer(false);
+
+   return 0;
 }

 static int slave_remove(struct platform_device *pdev)
-- 
1.7.0.4

[PATCH V2 7/7] drm/tilcdc: Clear bits of register we're going to set.

[Darren Etheridge]

From: Pantelis Antoniou 

Bits weren't cleared so resolution changes didn't work.

Signed-off-by: Pantelis Antoniou 
Signed-off-by: Darren Etheridge 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 6118651..eb06f70 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -299,6 +299,8 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
 * a value of 0 as 1
 */
if (priv->rev == 2) {
+   /* clear bits we're going to set */
+   reg &= ~0x7833;
reg |= ((hfp-1) & 0x300) >> 8;
reg |= ((hbp-1) & 0x300) >> 4;
reg |= ((hsw-1) & 0x3c0) << 21;
-- 
1.7.0.4

i915 mapping large (3MB) scatter list, hitting limits on certain IOMMUs that can only map contingous regions up to 2MB.

[Konrad Rzeszutek Wilk]

Hey,

I am using an ThinkPad X230 with an Intel HD 4000. With a stock Fedora 18
(3.9.6) I can get it to boot and work just fine with Xen. If I use v3.10-rc6
I found that i915 would halt with a 

[drm:intel_pipe_set_base] *ERROR* pin & fence failed
[drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28

after a bit of debugging (see patch below) I traced it down
to the fact that the scatter list that is provided at the end has
a huge (3MB) page. I am wondering if anybody knows what patch might
have introduced it to grab such a large memory segment?

The other thing I am wondering is if there are some fallbacks when the
underlaying IOMMU can't deal with a request for contingous regions
that are more than 2MB?

Thanks.

>From a681a4adb4738c32cb1acdf6f5161bf877816b01 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Fri, 21 Jun 2013 11:17:55 -0400
Subject: [PATCH] dbug: print scatterlist.

[ cut here ]
WARNING: at drivers/gpu/drm/i915/i915_gem_gtt.c:418 
i915_gem_gtt_prepare_object+0x180/0x200()
10 but got 0
Modules linked in:
 crc32_pclmul sdhci_pci crc32c_intel sdhci mmc_core ghash_clmulni_intel
CPU: 0 PID: 216 Comm: plymouthd Not tainted 3.10.0-rc6+ #16
Hardware name: LENOVO 2325DV4/2325DV4, BIOS G2ET86WW (2.06 ) 11/13/2012
 0009 8801fa42d958 816e6d89 8801fa42d998
 8105d2b0 8801fa42d988  8801fb0f4d80
 81c172e0 8801fa76f000 000a 8801fa42d9f8
Call Trace:
 [] dump_stack+0x19/0x1b
 [] warn_slowpath_common+0x70/0xa0
 [] warn_slowpath_fmt+0x46/0x50
 [] i915_gem_gtt_prepare_object+0x180/0x200
 [] i915_gem_object_pin+0x321/0x670
 [] i915_gem_object_pin_to_display_plane+0x81/0x190
 [] intel_pin_and_fence_fb_obj+0x85/0x1a0
 [] intel_pipe_set_base+0x7c/0x220
 [] intel_crtc_set_config+0x89e/0x990
 [] drm_mode_set_config_internal+0x2e/0x60
 [] drm_mode_setcrtc+0xfb/0x620
 [] ? kmem_cache_alloc_trace+0x39/0x1f0
 [] ? drm_vm_open_locked+0x57/0x90
 [] drm_ioctl+0x549/0x680
 [] ? drm_mode_setplane+0x3b0/0x3b0
 [] do_vfs_ioctl+0x97/0x580
 [] ? inode_has_perm.isra.32.constprop.62+0x2a/0x30
 [] ? file_has_perm+0x97/0xb0
 [] SyS_ioctl+0x91/0xb0
 [] tracesys+0xdd/0xe2
---[ end trace 7b6adc5450d9a9e1 ]---
i915 :00:02.0: i915_gem_gtt_prepare_object: Mapping 10 pages, mapped: 0
[0] virT:8801fd37c000 dma: 1fd37c000, size:4096
[1] virT:8801fd37b000 dma: 1fd37b000, size:4096
[2] virT:8801fd37a000 dma: 1fd37a000, size:4096
[3] virT:8801fd378000 dma: 1fd378000, size:4096
[4] virT:8801fd131000 dma: 1fd131000, size:4096
[5] virT:880200c36000 dma: 200c36000, size:4096
[6] virT:8801fd1a4000 dma: 1fd1a4000, size:69632
[7] virT:8801fd3bb000 dma: 1fd3bb000, size:4096
[8] virT:8801fd3c dma: 1fd3c, size:262144
[9] virT:8801f940 dma: 1f940, size:3866624
[drm] 3011: ret:-28
[drm] 3540: ret:-28
[drm] 3364: ret:-28
[drm:intel_pin_and_fence_fb_obj] *ERROR* i915_gem_object_pin_to_display_plane 
failed: -28
[drm:intel_pipe_set_base] *ERROR* pin & fence failed
[drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28

Signed-off-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/i915/i915_drv.c |  6 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c | 28 +---
 2 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8411942..141c6fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -133,6 +133,12 @@ module_param_named(coherent, use_coherent, int, 0600);
 MODULE_PARM_DESC(use_coherent,
 "Use coherent DMA API calls (default: false)");

+int i915_sgl __read_mostly = 0;
+module_param_named(sgl, i915_sgl, int, 0600);
+MODULE_PARM_DESC(sgl,
+"Print scatterlist SG's when DMA mapping them (default: 
false)");
+
+
 static struct drm_driver driver;
 extern int intel_agp_enabled;

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index acb3b3f..292179c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -28,6 +28,7 @@
 #include "i915_trace.h"
 #include "intel_drv.h"

+extern int use_coherent;
 typedef uint32_t gen6_gtt_pte_t;

 /* PPGTT stuff */
@@ -403,15 +404,36 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)

i915_gem_chipset_flush(dev);
 }
-
+extern int i915_sgl;
 int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj)
 {
+   int elem;
if (obj->has_dma_mapping)
return 0;

-   if (!dma_map_sg(&obj->base.dev->pdev->dev,
+   elem = dma_map_sg(&obj->base.dev->pdev->dev,
obj->pages->sgl, obj->pages->nents,
-   PCI_DMA_BIDIRECTIONAL))
+   PCI_DMA_BIDIRECTIONAL);
+
+   WARN(elem == 0, "%d but got %d", obj->pages->nents, elem);
+
+   if (i915_sgl && obj->pages && obj->pa

[PATCH] drm/i915: move i915_trace_irq_get() out of the tracing macro

[Sebastian Andrzej Siewior]

There is a report on RT about "BUG: scheduling while atomic" because the
sleeping lock is taken in tracing context. This patch simply moves
locking operation out of the tracing macro.

Reported-by: Joakim Hernberg 
[C.Emde at osadl.org: pull out seqno and define it so it compiled]
Signed-off-by: Sebastian Andrzej Siewior 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 -
 drivers/gpu/drm/i915/i915_trace.h  | 1 -
 drivers/gpu/drm/i915/intel_ringbuffer.h| 2 ++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 87a3227..fa5b45f 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -844,6 +844,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct intel_ring_buffer *ring;
u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 exec_start, exec_len;
+   u32 seqno;
u32 mask, flags;
int ret, mode, i;
bool need_relocs;
@@ -1081,7 +1082,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
goto err;
}

-   trace_i915_gem_ring_dispatch(ring, intel_ring_get_seqno(ring), flags);
+   seqno = intel_ring_get_seqno(ring);
+   trace_i915_gem_ring_dispatch(ring, seqno, flags);
+   i915_trace_irq_get(ring, seqno);

i915_gem_execbuffer_move_to_active(&eb->objects, ring);
i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index 3db4a68..29217db 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -244,7 +244,6 @@ TRACE_EVENT(i915_gem_ring_dispatch,
   __entry->ring = ring->id;
   __entry->seqno = seqno;
   __entry->flags = flags;
-  i915_trace_irq_get(ring, seqno);
   ),

TP_printk("dev=%u, ring=%u, seqno=%u, flags=%x",
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 799f04c..13ffe58 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -262,8 +262,10 @@ static inline u32 intel_ring_get_seqno(struct 
intel_ring_buffer *ring)

 static inline void i915_trace_irq_get(struct intel_ring_buffer *ring, u32 
seqno)
 {
+#ifdef CONFIG_TRACEPOINTS
if (ring->trace_irq_seqno == 0 && ring->irq_get(ring))
ring->trace_irq_seqno = seqno;
+#endif
 }

 /* DRI warts */
-- 
1.8.3.1

[Intel-gfx] [PATCH] drm/i915: move i915_trace_irq_get() out of the tracing macro

[Sebastian Andrzej Siewior]

On 06/21/2013 01:08 PM, Chris Wilson wrote:
> On Fri, Jun 21, 2013 at 12:15:53PM +0200, Sebastian Andrzej Siewior wrote:
>> There is a report on RT about "BUG: scheduling while atomic" because the
>> sleeping lock is taken in tracing context. This patch simply moves
>> locking operation out of the tracing macro.
> 
> No. This enables the IRQ, as well as making a number of
> very expensively serialised read, unconditionally.

Ach in case CONFIG_TRACING is enabled but the tracepoint itself is
disabled. In that case it is probably best to drop this tracepoint from
-RT.

> -Chris
> 
Sebastian