Re: [RFC PATCH v2 0/5] Add vblank hooks to struct drm_crtc_funcs
On Sun, Jan 22, 2017 at 02:09:01PM +0800, Shawn Guo wrote: > From: Shawn Guo > > The vblank is mostly CRTC specific and implemented as part of CRTC > driver. The first patch adds 3 vblank core-driver hooks into struct > drm_crtc_funcs, and wraps around core vblank handling code to use the > new hooks for modern MODESET drivers and the ones in struct drm_driver > as fallback for legacy drivers. > > The other patches in the series are to demonstrate how the new hooks > are going to influence the driver code. There are more drivers than > the ones included here can be converted. But before doing that, I would > like to get some feedbacks first, expecially on how .get_vblank_counter > should be converted when it's being drm_vblank_no_hw_counter(). > > .get_vblank_counter = drm_vblank_no_hw_counter I dropped some suggestions about this onto patch 3. Thanks for doing this, I think it looks rather pretty. -Daniel > The series is generated against branch drm-misc-next. > > Changes for v2: > - Wrap around core vblank handling code to save >drm_crtc_enable[disable]_vblank() helpers > - Add .get_vblank_counter to struct drm_crtc_funcs > - Add some comments to link between two sets of hooks > - Add one hdlcd driver patch for example > > Shawn Guo (5): > drm: add vblank hooks to struct drm_crtc_funcs > drm: hdlcd: use vblank hooks in struct drm_crtc_funcs > drm: zte: zx_vou_enable[disable]_vblank can be static > drm: rockchip: remove struct rockchip_crtc_funcs > drm: imx: remove struct imx_drm_crtc and imx_drm_crtc_helper_funcs > > drivers/gpu/drm/arm/hdlcd_crtc.c| 20 ++ > drivers/gpu/drm/arm/hdlcd_drv.c | 20 -- > drivers/gpu/drm/drm_irq.c | 53 +-- > drivers/gpu/drm/imx/imx-drm-core.c | 101 > > drivers/gpu/drm/imx/imx-drm.h | 13 > drivers/gpu/drm/imx/ipuv3-crtc.c| 58 ++-- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 51 -- > drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 14 > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 +-- > drivers/gpu/drm/zte/zx_drm_drv.c| 2 - > drivers/gpu/drm/zte/zx_vou.c| 61 +++-- > drivers/gpu/drm/zte/zx_vou.h| 3 - > include/drm/drm_crtc.h | 34 ++ > include/drm/drm_drv.h | 9 +++ > 14 files changed, 157 insertions(+), 291 deletions(-) > > -- > 1.9.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/24] drm/bridge/sii8620: add continuations to messages
On 01/23/2017 04:03 PM, Andrzej Hajda wrote:
On 23.01.2017 09:31, Archit Taneja wrote:
On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
Due to asynchronous nature of MHL flow of execution is dispersed. Logical
continuation of some actions happens after response of peer, i.e in interrupt
handler. To simplify coding continuation mechanism has been added - it is now
possible to provide continuation callback, which will be called after peer
responds to given action.
Could you wrap this to 75 chars?
OK
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sil-sii8620.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 75867c0..cde0074 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -78,12 +78,15 @@ struct sii8620_mt_msg;
typedef void (*sii8620_mt_msg_cb)(struct sii8620 *ctx,
struct sii8620_mt_msg *msg);
+typedef void (*sii8620_cb)(struct sii8620 *ctx, int ret);
+
struct sii8620_mt_msg {
struct list_head node;
u8 reg[4];
u8 ret;
sii8620_mt_msg_cb send;
sii8620_mt_msg_cb recv;
+ sii8620_cb continuation;
};
static const u8 sii8620_i2c_page[] = {
@@ -258,6 +261,8 @@ static void sii8620_mt_work(struct sii8620 *ctx)
node);
if (msg->recv)
msg->recv(ctx, msg);
+ if (msg->continuation)
+ msg->continuation(ctx, msg->ret);
I was wondering if instead of executing the continuation via a callback,
would it make sense to insert them as a new message instead?
I don't have the complete context of this, so feel free to ignore the suggestion
if doesn't make sense.
My assumption was that continuation should be tied to the message it was
attached to - ie it should be called after response for the message and
it should be called with the result of the response.
If we assume messages are fully serialized (as it is now) it could be
done as you suggested, but I prefer to leave possibility to de-serialize
message queue in the future.
Sure. Let's leave it as is.
Archit
Regards
Andrzej
Thanks,
Archit
list_del(&msg->node);
kfree(msg);
}
@@ -310,6 +315,21 @@ static struct sii8620_mt_msg *sii8620_mt_msg_new(struct
sii8620 *ctx)
return msg;
}
+static void sii8620_mt_set_cont(struct sii8620 *ctx, sii8620_cb cont)
+{
+ struct sii8620_mt_msg *msg;
+
+ if (ctx->error)
+ return;
+
+ if (list_empty(&ctx->mt_queue)) {
+ ctx->error = -EINVAL;
+ return;
+ }
+ msg = list_last_entry(&ctx->mt_queue, struct sii8620_mt_msg, node);
+ msg->continuation = cont;
+}
+
static void sii8620_mt_msc_cmd(struct sii8620 *ctx, u8 cmd, u8 arg1, u8 arg2)
{
struct sii8620_mt_msg *msg = sii8620_mt_msg_new(ctx);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/atomic: make release_crtc_commit() static
On Mon, Jan 16, 2017 at 07:36:27PM -0200, Gustavo Padovan wrote: > Hi Wei, > > 2017-01-12 Wei Yongjun : > > > From: Wei Yongjun > > > > Fixes the following sparse warning: > > > > drivers/gpu/drm/drm_atomic_helper.c:1360:6: warning: > > symbol 'release_crtc_commit' was not declared. Should it be static? > > > > Signed-off-by: Wei Yongjun > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Reviewed-by: Gustavo Padovan Thanks for the patch, applied to drm-misc. Gustavo, for next time around please just use your commit rights when reviewing a simple patch like this :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm: Use atomic state for FB in legacy ioctls
On Fri, Jan 13, 2017 at 03:12:07PM +, Daniel Stone wrote:
> Hi Dan,
>
> On 13 January 2017 at 12:56, Dan Carpenter wrote:
> > drivers/gpu/drm/drm_crtc.c:392 drm_mode_getcrtc()
> > error: we previously assumed 'crtc->primary->state' could be null
> > (see line 384)
> >
> > drivers/gpu/drm/drm_crtc.c
> >383
> >384 if (crtc->primary->state && crtc->primary->state->fb)
> >
> > New check for NULL.
> >
> >385 crtc_resp->fb_id =
> > crtc->primary->state->fb->base.id;
> >386 else if (!crtc->primary->state && crtc->primary->fb)
> >387 crtc_resp->fb_id = crtc->primary->fb->base.id;
> >388 else
> >389 crtc_resp->fb_id = 0;
> >390
> >391 if (crtc->state) {
> >392 crtc_resp->x = crtc->primary->state->src_x >> 16;
> >^^^
> > Old unchecked dereference. It's possible that non-NULL "crtc->state"
> > implies a non-NULL "crtc->primary->state", but I didn't spot the
> > relationship immediately.
>
> Thanks for this. I believe this is indeed an invariant; Dan Vetter
> could confirm, if he's managed to find internet in Hobart. Assuming
> this is the case, what's the best way to communicate this to smatch;
> would that be through a BUG_ON or similar?
Yeah, we assume that if a driver uses state stuff, it's used everywhere.
But I'm not sure anymore how much that holds true for a driver
transitioning to atomic, so adding a BUG_ON to tell smatch or extend the
if check to also check for crtc->primary->state (it wont make a diffrence
for atomic drivers) if the BUG_ON doesn't clue in smatch enough.
Can you pls submit the right patch, since I don't have a working smatch
setup here?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 4.10-rc6 (just missed rc5 tagging :-)
On Mon, Jan 23, 2017 at 09:38:48AM +1000, Dave Airlie wrote: > Hi Linus, > > Okay holidays and LCA kinda caught up with me, I thought I'd get some > of this dequeued last week, but Hobart was > sunny and warm and not all gloomy and rainy as usual. > > This is a bit large, but not too much considering it's two weeks stuff > from AMD and Intel. > > core: one locking fix that helps with dynamic suspend/resume races > i915: mostly GVT updates, GVT was a recent introduction so fixes for > it shouldn't cause any notable side effects. > amdgpu: a bunch of fixes for GPUs with a different memory controller > design that need different firmware. > exynos: decon regression fixes > msm: two regression fixes > etnaviv: a workaround for an mmu bug that needs a lot more work. > virtio: sparse fix, and a maintainers update > > I've looked through most of this and I think it should be fine, but > let me know if it's scarily too much. > > Dave. > > The following changes since commit 6edd870bca30b3aa69370a99bcefc1e5f2b8b190: > > Merge branch 'drm-fixes-4.10' of > git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-01-09 > 09:47:19 +1000) > > are available in the git repository at: > > git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.10-rc6 You pushed the tag, but didn't update your drm-fixes branch. Confuses my pull request scripts a bit :-) -Daniel > > for you to fetch changes up to 932790109f62aa52bdb4bb62aa66653c0b51bc75: > > Merge tag 'drm-qemu-20170110' of git://git.kraxel.org/linux into > drm-fixes (2017-01-23 09:25:53 +1000) > > > drm fixes across the board > > > Alex Deucher (8): > drm/radeon/si: load special ucode for certain MC configs > drm/amdgpu/si: load special ucode for certain MC configs > drm/amdgpu: drop oland quirks > drm/amdgpu: drop the mclk quirk for hainan > drm/radeon: drop oland quirks > drm/radeon: drop the mclk quirk for hainan > drm/radeon: add support for new hainan variants > drm/amdgpu: add support for new hainan variants > > Andrzej Hajda (5): > drm/exynos/decon5433: update shadow registers iff there are active > windows > drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are > disabled > drm/exynos/decon5433: do not disable video after reset > drm/exynos/decon5433: fix CMU programming > drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement > > Changbin Du (13): > drm/i915/gvt: fix error handing of tlb_control emulation > drm/i915/gvt: fix return value in mul_force_wake_write > drm/i915/gvt: always use readq and writeq > drm/i915/gvt: fix use after free for workload > drm/i915/gvt: dec vgpu->running_workload_num after the workload > is really done > drm/i915/gvt: introudce intel_vgpu_reset_resource() to reset > vgpu resource state > drm/i915/gvt: introuduce intel_vgpu_reset_gtt() to reset gtt > drm/i915/gvt: move cfg space inititation function to cfg_space.c > drm/i915/gvt: introduce intel_vgpu_reset_cfg_space to reset > configuration space > drm/i915/gvt: move mmio init/clean function to mmio.c > drm/i915/gvt: introduce intel_vgpu_reset_mmio() to reset mmio space > drm/i915/gvt: fix vGPU instance reuse issues by vGPU reset function > drm/i915/gvt: rewrite gt reset handler using new function > intel_gvt_reset_vgpu_locked > > Chris Wilson (2): > drm/i915: Clear ret before unbinding in i915_gem_evict_something() > drm/i915: Fix phys pwrite for struct_mutex-less operation > > Daniel Vetter (1): > drm/probe-helpers: Drop locking from poll_enable > > Dave Airlie (8): > Merge tag 'drm-misc-fixes-2017-01-09' of > git://anongit.freedesktop.org/git/drm-misc into drm-fixes > Merge tag 'drm-intel-fixes-2017-01-19' of > git://anongit.freedesktop.org/git/drm-intel into drm-fixes > Merge tag 'drm-misc-fixes-2017-01-13' of > git://anongit.freedesktop.org/git/drm-misc into drm-fixes > Merge branch 'msm-fixes-4.10-rc4' of > git://people.freedesktop.org/~robclark/linux into drm-fixes > Merge branch 'drm-fixes-4.10' of > git://people.freedesktop.org/~agd5f/linux into drm-fixes > Merge branch 'exynos-drm-fixes' of > git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes > Merge branch 'drm-etnaviv-fixes' of > https://git.pengutronix.de/git/lst/linux into drm-fixes > Merge tag 'drm-qemu-20170110' of git://git.kraxel.org/linux into > drm-fixes > > Flora Cui (1): > drm/amdgpu: fix vm_fault_stop on gfx6 > > Francisco Jerez (1): > drm/i915: Remove WaDisableLSQCROPERFforOCL KBL workaround. > > Gerd Hoffmann (3): > drm/virtio: fix framebuffer sparse warning > drm: update MAINTAINERS for qemu drivers (bochs, cirrus, qxl, > virtio-gpu) > drm: flip cirrus drive
Re: [PATCH] drm: don't link DP aux i2c adapter to the hardware device node
On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote: > The i2c adapter on DP AUX is purely a software construct. Linking > it to the device node of the parent device is wrong, as it leads to > 2 devices sharing the same device node, which is bad practice, as > well as the i2c trying to populate children of the i2c adapter by > looking at the child device nodes of the parent device. > > Signed-off-by: Lucas Stach Since this is about dt, I have no idea what it does or why. Needs someone else to look at & merge. -Daniel > --- > drivers/gpu/drm/drm_dp_helper.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c > index 3e6fe82c6d64..f91ade1edbde 100644 > --- a/drivers/gpu/drm/drm_dp_helper.c > +++ b/drivers/gpu/drm/drm_dp_helper.c > @@ -1020,7 +1020,6 @@ int drm_dp_aux_register(struct drm_dp_aux *aux) > aux->ddc.class = I2C_CLASS_DDC; > aux->ddc.owner = THIS_MODULE; > aux->ddc.dev.parent = aux->dev; > - aux->ddc.dev.of_node = aux->dev->of_node; > > strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev), > sizeof(aux->ddc.name)); > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/24] drm/bridge/sii8620: add support for burst eMSC transmissions
On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
Burst transmissions are used in MHL3 mode negotiation.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sil-sii8620.c | 196 ++-
drivers/gpu/drm/bridge/sil-sii8620.h | 4 +
2 files changed, 198 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9f9fd99..744e685 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -9,6 +9,8 @@
* published by the Free Software Foundation.
*/
+#include
+
#include
#include
#include
@@ -28,7 +30,8 @@
#include "sil-sii8620.h"
-#define VAL_RX_HDMI_CTRL2_DEFVAL VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
+#define SII8620_BURST_BUF_LEN 288
+#define VAL_RX_HDMI_CTRL2_DEFVAL VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
enum sii8620_mode {
CM_DISCONNECTED,
@@ -71,6 +74,15 @@ struct sii8620 {
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
struct list_head mt_queue;
+ struct {
+ int r_size;
+ int r_count;
+ int rx_ack;
+ int rx_count;
+ u8 rx_buf[32];
+ int tx_count;
+ u8 tx_buf[32];
+ } burst;
};
struct sii8620_mt_msg;
@@ -511,6 +523,134 @@ static inline void sii8620_mt_read_xdevcap_reg(struct
sii8620 *ctx, u8 reg)
sii8620_mt_read_devcap_reg(ctx, reg | 0x80);
}
+static void *sii8620_burst_get_tx_buf(struct sii8620 *ctx, int len)
+{
+ u8 *buf = &ctx->burst.tx_buf[ctx->burst.tx_count];
+ int size = len + 2;
+
+ if (ctx->burst.tx_count + size > ARRAY_SIZE(ctx->burst.tx_buf)) {
+ dev_err(ctx->dev, "TX-BLK buffer exhausted\n");
+ ctx->error = -EINVAL;
+ return NULL;
+ }
+
+ ctx->burst.tx_count += size;
+ buf[1] = len;
+
+ return buf + 2;
+}
+
+static u8 *sii8620_burst_get_rx_buf(struct sii8620 *ctx, int len)
+{
+ u8 *buf = &ctx->burst.rx_buf[ctx->burst.rx_count];
+ int size = len + 1;
+
+ if (ctx->burst.tx_count + size > ARRAY_SIZE(ctx->burst.tx_buf)) {
+ dev_err(ctx->dev, "RX-BLK buffer exhausted\n");
+ ctx->error = -EINVAL;
+ return NULL;
+ }
+
+ ctx->burst.rx_count += size;
+ buf[0] = len;
+
+ return buf + 1;
+}
+
+static void sii8620_burst_send(struct sii8620 *ctx)
+{
+ int tx_left = ctx->burst.tx_count;
+ u8 *d = ctx->burst.tx_buf;
+
+ while (tx_left > 0) {
+ int len = d[1] + 2;
+
+ if (ctx->burst.r_count + len > ctx->burst.r_size)
+ break;
+ d[0] = min(ctx->burst.rx_ack, 255);
+ ctx->burst.rx_ack -= d[0];
+ sii8620_write_buf(ctx, REG_EMSC_XMIT_WRITE_PORT, d, len);
+ ctx->burst.r_count += len;
+ tx_left -= len;
+ d += len;
+ }
+
+ ctx->burst.tx_count = tx_left;
+
+ while (ctx->burst.rx_ack > 0) {
+ u8 b[2] = { min(ctx->burst.rx_ack, 255), 0 };
+
+ if (ctx->burst.r_count + 2 > ctx->burst.r_size)
+ break;
+ ctx->burst.rx_ack -= b[0];
+ sii8620_write_buf(ctx, REG_EMSC_XMIT_WRITE_PORT, b, 2);
+ ctx->burst.r_count += 2;
+ }
+}
+
+static void sii8620_burst_receive(struct sii8620 *ctx)
+{
+ u8 buf[3], *d;
+ int count;
+
+ sii8620_read_buf(ctx, REG_EMSCRFIFOBCNTL, buf, 2);
+ count = get_unaligned_le16(buf);
+ while (count > 0) {
+ int len = min(count, 3);
+
+ sii8620_read_buf(ctx, REG_EMSC_RCV_READ_PORT, buf, len);
+ count -= len;
+ ctx->burst.rx_ack += len - 1;
+ ctx->burst.r_count -= buf[1];
+ if (ctx->burst.r_count < 0)
+ ctx->burst.r_count = 0;
+
+ if (len < 3 || !buf[2])
+ continue;
+
+ len = buf[2];
+ d = sii8620_burst_get_rx_buf(ctx, len);
+ if (!d)
+ continue;
+ sii8620_read_buf(ctx, REG_EMSC_RCV_READ_PORT, d, len);
+ count -= len;
+ ctx->burst.rx_ack += len;
+ }
+}
+
+static void sii8620_burst_tx_rbuf_info(struct sii8620 *ctx, int size)
+{
+ struct mhl_burst_blk_rcv_buffer_info *d =
+ sii8620_burst_get_tx_buf(ctx, sizeof(*d));
+ if (!d)
+ return;
+
+ d->id = cpu_to_be16(MHL_BURST_ID_BLK_RCV_BUFFER_INFO);
+ d->size = cpu_to_le16(size);
+}
+
+static void sii8620_burst_rx_all(struct sii8620 *ctx)
+{
+ u8 *d = ctx->burst.rx_buf;
+ int count = ctx->burst.rx_count;
+
+ while (count-- > 0) {
+ int len = *d++;
+ int id = get_unaligned_be16(&d[0]);
+
+ switch (id) {
+ case MHL_BURST_ID_BLK_R
Re: [PATCH] drm/armada: Include current dir on CFLAGS for armada trace
On Mon, Jan 16, 2017 at 06:13:30PM -0200, Gustavo Padovan wrote: > From: Gustavo Padovan > > Otherwise compilation fails like this: > > In file included from drivers/gpu/drm/armada/armada_trace.h:66:0, > from drivers/gpu/drm/armada/armada_trace.c:3: > ./include/trace/define_trace.h:88:43: fatal error: ./armada_trace.h: No such > file or directory > compilation terminated. > > Signed-off-by: Gustavo Padovan We have this already in commit 7357f89954b6d005df6ab8929759e78d7d9a80f9 Author: Daniel Vetter Date: Fri Dec 30 17:38:52 2016 +0100 drm/armada: Fix compile fail > --- > drivers/gpu/drm/armada/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/armada/Makefile b/drivers/gpu/drm/armada/Makefile > index a18f156..64c0b45 100644 > --- a/drivers/gpu/drm/armada/Makefile > +++ b/drivers/gpu/drm/armada/Makefile > @@ -4,3 +4,5 @@ armada-y += armada_510.o > armada-$(CONFIG_DEBUG_FS) += armada_debugfs.o > > obj-$(CONFIG_DRM_ARMADA) := armada.o > + > +CFLAGS_armada_trace.o := -I$(src) > -- > 2.5.5 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: g2d: fix overflow of cmdlist size
Hi Tobias, On 01/21/2017 01:05 AM, Tobias Jakobi wrote: > Hello Joonyoung, > > > Joonyoung Shim wrote: >> Hi Tobias, >> >> On 01/19/2017 10:16 PM, Tobias Jakobi wrote: >>> Hello Joonyoung, >>> >>> Joonyoung Shim wrote: Hi Tobias, On 01/17/2017 11:24 PM, Tobias Jakobi wrote: > Joonyoung Shim wrote: >> The size of cmdlist is integer type, so it can be overflowed by cmd and >> cmd_buf that has too big size. This patch will fix overflow issue as >> checking maximum size of cmd and cmd_buf. > I don't understand/see the issue here. Could you point out for which > input of the set_cmdlist ioctl you see this particular overflow? > > In particular it is not clear to me which size field you're talking > about. struct g2d_cmdlist does not have any field named 'size'. > I mean size of cmdlist is size = cmdlist->last + req->cmd_nr * 2 + req->cmd_buf_nr * 2 + 2; in exynos_g2d_set_cmdlist_ioctl(). >>> ok, that makes things more clear. But then you need to fix the commit >>> message. The current message implies that this 'size' you're talking >>> about is some property of the cmdlist. >>> >>> Also the new comment is wrong. >>> /* Check size of cmd and cmdlist: last 2 is about G2D_BITBLT_START */ >>> >>> What is cmd and cmdlist? You're mixing two different things here. We are >>> still checking the size of 'cmdlist' (which is a struct g2d_cmdlist) here. >>> >>> What you add is a check for the fields of 'req' (which is a struct >>> drm_exynos_g2d_set_cmdlist). >>> >>> With all that said, I don't like the changes. I see the issue, but the >>> current solution should be cleaner. >>> >>> I propose this. We just check req->cmd_buf_nr and req->cmd_nr against >>> G2D_CMDLIST_DATA_NUM. This leaves us enough headrom so that the later >>> computation (i.e. what is ending up in the local variable 'size') can >>> never overflow. >>> >> >> Agree, it's more clear to check req->cmd_buf_nr and req->cmd_nr against >> G2D_CMDLIST_DATA_NUM. >> >>> For a comment for the check I propose this: >>> "To avoid an integer overflow for the later size computations, we >>> enforce a maximum number of submitted commands here. This limit is >>> sufficient for all conceivable usage cases of the G2D." >>> >> >> Could you post your patch to ML about this if you want? > Sure, I've just send it together with two other small patches. Let me > know if the current version is OK with you. I hope I did the order of > SoB correctly (I know that Krzysztof has pointed this out lately). > I don't know exactly about order of SoB but it's ok to me except WARNING: line over 80 characters from checkpatch.pl. Thanks for posting. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Clean up the 1366x768 fixup codes
On Fri, Jan 20, 2017 at 09:46:17PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 17, 2017 at 05:43:29PM +0100, Takashi Iwai wrote:
> > This is just a cleanup, no functional change.
> >
> > The fixup code for 1366x768 in drm_mode_create_from_cmdline_mode() is
> > basically a copy of the existing code in drm_edid.c. Make the latter
> > code public so that it can be called from the former function.
> >
> > Signed-off-by: Takashi Iwai
> > ---
> > v1->v2: Fix the wrong line removal of drm_mode_set_crtcinfo() call
>
> We prefer to include the changelog in the commit message proper.
> But it can be hoisted up easily enough when pushing.
>
> lgtm
> Reviewed-by: Ville Syrjälä
Ville, can you pls also apply&push this to drm-misc.git?
Thanks, Daniel
>
> >
> > drivers/gpu/drm/drm_crtc_internal.h | 3 +++
> > drivers/gpu/drm/drm_edid.c | 6 +++---
> > drivers/gpu/drm/drm_modes.c | 8 ++--
> > 3 files changed, 8 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> > b/drivers/gpu/drm/drm_crtc_internal.h
> > index cdf6860c9d22..01bde7103ad6 100644
> > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > @@ -199,3 +199,6 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
> >void *data, struct drm_file *file_priv);
> > int drm_mode_page_flip_ioctl(struct drm_device *dev,
> > void *data, struct drm_file *file_priv);
> > +
> > +/* drm_edid.c */
> > +void drm_mode_fixup_1366x768(struct drm_display_mode *mode);
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 336be31ff3de..739a19cb27d9 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -2152,7 +2152,7 @@ drm_dmt_modes_for_range(struct drm_connector
> > *connector, struct edid *edid,
> > /* fix up 1366x768 mode from 1368x768;
> > * GFT/CVT can't express 1366 width which isn't dividable by 8
> > */
> > -static void fixup_mode_1366x768(struct drm_display_mode *mode)
> > +void drm_mode_fixup_1366x768(struct drm_display_mode *mode)
> > {
> > if (mode->hdisplay == 1368 && mode->vdisplay == 768) {
> > mode->hdisplay = 1366;
> > @@ -2176,7 +2176,7 @@ drm_gtf_modes_for_range(struct drm_connector
> > *connector, struct edid *edid,
> > if (!newmode)
> > return modes;
> >
> > - fixup_mode_1366x768(newmode);
> > + drm_mode_fixup_1366x768(newmode);
> > if (!mode_in_range(newmode, edid, timing) ||
> > !valid_inferred_mode(connector, newmode)) {
> > drm_mode_destroy(dev, newmode);
> > @@ -2205,7 +2205,7 @@ drm_cvt_modes_for_range(struct drm_connector
> > *connector, struct edid *edid,
> > if (!newmode)
> > return modes;
> >
> > - fixup_mode_1366x768(newmode);
> > + drm_mode_fixup_1366x768(newmode);
> > if (!mode_in_range(newmode, edid, timing) ||
> > !valid_inferred_mode(connector, newmode)) {
> > drm_mode_destroy(dev, newmode);
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index e6b19bc9021a..35bb993ebc39 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1461,12 +1461,8 @@ drm_mode_create_from_cmdline_mode(struct drm_device
> > *dev,
> >
> > mode->type |= DRM_MODE_TYPE_USERDEF;
> > /* fix up 1368x768: GFT/CVT can't express 1366 width due to alignment */
> > - if (cmd->xres == 1366 && mode->hdisplay == 1368) {
> > - mode->hdisplay = 1366;
> > - mode->hsync_start--;
> > - mode->hsync_end--;
> > - drm_mode_set_name(mode);
> > - }
> > + if (cmd->xres == 1366)
> > + drm_mode_fixup_1366x768(mode);
> > drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
> > return mode;
> > }
> > --
> > 2.11.0
>
> --
> Ville Syrjälä
> Intel OTC
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] amdgpu: HDMI Stereo 3D support
On Thu, Jan 19, 2017 at 10:10:21AM -0500, Alex Deucher wrote: > On Wed, Jan 18, 2017 at 10:34 AM, Jeff Smith wrote: > > Hello all, > > > > This code is very raw at this point, but wanted to get this out there > > for feedback. > > > > This uses codepaths very close to those used for HDMI audio support. > > The driver currently has this disabled, so I needed to re-enable it. > > Turning stereo 3D on without turning audio on would require a bit of > > additional condition handling. > > > > I suspect there are some non-stereo modes that will break with the > > code in its current state, such as modes that require double-scan. > > > > Thanks for the patches. We are in the process of transitioning to new > updated modesetting code (DC), so I would suggest working against that > rather than the existing code. You can find the latest DC code on the > branch below. See the display directory in drivers/gpu/drm/amd. > https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.9 Given that DAL is still a bit away from getting merged I'm not sure it's a good idea to block new features from outsiders on it landing ... That means AMD will need to port this, but that's part of the price to pay for a wholesale rewrite of the display driver. -Daniel > > Alex > > > > Regards, > > Jeff > > > > > > Jeff Smith (2): > > amdgpu: Stereo 3D support requires enabling audio > > amdgpu: Add stereo 3D support > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 15 +++-- > > drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 27 > > drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 2 +- > > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 86 > > -- > > 4 files changed, 106 insertions(+), 24 deletions(-) > > > > -- > > 2.9.3 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/24] drm/bridge/sii8620: add continuations to messages
On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
Due to asynchronous nature of MHL flow of execution is dispersed. Logical
continuation of some actions happens after response of peer, i.e in interrupt
handler. To simplify coding continuation mechanism has been added - it is now
possible to provide continuation callback, which will be called after peer
responds to given action.
Could you wrap this to 75 chars?
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sil-sii8620.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 75867c0..cde0074 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -78,12 +78,15 @@ struct sii8620_mt_msg;
typedef void (*sii8620_mt_msg_cb)(struct sii8620 *ctx,
struct sii8620_mt_msg *msg);
+typedef void (*sii8620_cb)(struct sii8620 *ctx, int ret);
+
struct sii8620_mt_msg {
struct list_head node;
u8 reg[4];
u8 ret;
sii8620_mt_msg_cb send;
sii8620_mt_msg_cb recv;
+ sii8620_cb continuation;
};
static const u8 sii8620_i2c_page[] = {
@@ -258,6 +261,8 @@ static void sii8620_mt_work(struct sii8620 *ctx)
node);
if (msg->recv)
msg->recv(ctx, msg);
+ if (msg->continuation)
+ msg->continuation(ctx, msg->ret);
I was wondering if instead of executing the continuation via a callback,
would it make sense to insert them as a new message instead?
I don't have the complete context of this, so feel free to ignore the suggestion
if doesn't make sense.
Thanks,
Archit
list_del(&msg->node);
kfree(msg);
}
@@ -310,6 +315,21 @@ static struct sii8620_mt_msg *sii8620_mt_msg_new(struct
sii8620 *ctx)
return msg;
}
+static void sii8620_mt_set_cont(struct sii8620 *ctx, sii8620_cb cont)
+{
+ struct sii8620_mt_msg *msg;
+
+ if (ctx->error)
+ return;
+
+ if (list_empty(&ctx->mt_queue)) {
+ ctx->error = -EINVAL;
+ return;
+ }
+ msg = list_last_entry(&ctx->mt_queue, struct sii8620_mt_msg, node);
+ msg->continuation = cont;
+}
+
static void sii8620_mt_msc_cmd(struct sii8620 *ctx, u8 cmd, u8 arg1, u8 arg2)
{
struct sii8620_mt_msg *msg = sii8620_mt_msg_new(ctx);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] Time to update GSoC/EVoC ideas page
On Fri, Jan 20, 2017 at 08:44:19AM -0800, Jason Ekstrand wrote: > On Fri, Jan 20, 2017 at 2:15 AM, Nicolai Hähnle wrote: > > > Hi Rob, > > > > On 19.01.2017 23:32, Rob Clark wrote: > > > >> Just a friendly reminder that now would be a good time to update the > >> wiki page for GSoC/EVoC ideas: > >> > >> https://www.x.org/wiki/SummerOfCodeIdeas/ > >> > >> There are currently still some stale ideas there (and probably plenty > >> of missing good ideas). > >> > >> Also, I've added a "Potential Mentors" section. Please add yourself > >> if you are willing to be a mentor (and what sorts of projects you > >> would be willing to mentor) > >> > > > > I'd be happy to be listed as a possible mentor on the DriConf replacement > > project (nha on IRC/freenode), but I either don't have a Wiki account or > > forgot it a long time ago. Could you put my name down on the page? > > > > Pro tip: You can just git clone the wiki, change a markdown file, and git > push it back up. That's the way I always make edits. Way nicer than a web > GUI. :-) And if you have a shell account, it's easy to resurrect your web wiki account: https://wiki.freedesktop.org/sitewranglers/wiki/401/ Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC simple allocator v1 0/2] Simple allocator
On Fri, Jan 20, 2017 at 04:32:29PM +0100, Benjamin Gaignard wrote:
> The goal of this RFC is to understand if a common ioctl for specific memory
> regions allocations is needed/welcome.
>
> Obviously it will not replace allocation done in linux kernel frameworks like
> v4l2, drm/kms or others, but offer an alternative when you don't want/need to
> use them for buffer allocation.
> To keep a compatibility with what already exist allocated buffers are exported
> in userland as dmabuf file descriptor (like ION is doing).
>
> "Unix Device Memory Allocator" project [1] wants to create a userland library
> which may allow to select, depending of the devices constraint, the best
> back-end for allocation. With this RFC I would to propose to have common ioctl
> for a maximum of allocators to avoid to duplicated back-ends for this library.
>
> One of the issues that lead me to propose this RFC it is that since the
> beginning
> it is a problem to allocate contiguous memory (CMA) without using v4l2 or
> drm/kms so the first allocator available in this RFC use CMA memory.
>
> An other question is: do we have others memory regions that could be
> interested
> by this new framework ? I have in mind that some title memory regions could
> use
> it or replace ION heaps (system, carveout, etc...).
> Maybe it only solve CMA allocation issue, in this case there is no need to
> create
> a new framework but only a dedicated ioctl.
>
> Maybe the first thing to do is to change the name and the location of this
> module, suggestions are welcome.
>
> I have testing this code with the following program:
I'm still maintaining that we should just destage ION (with the todo items
fixed), since that is already an uabi to do this (afaiui at least), and
it's used on a few devices ... Please chat with Laura Abott.
-Daniel
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include "simple-allocator.h"
>
> #define LENGTH 1024*16
>
> void main (void)
> {
> struct simple_allocate_data data;
> int fd = open("/dev/cma0", O_RDWR, 0);
> int ret;
> void *mem;
>
> if (fd < 0) {
> printf("Can't open /dev/cma0\n");
> return;
> }
>
> memset(&data, 0, sizeof(data));
>
> data.length = LENGTH;
> data.flags = O_RDWR | O_CLOEXEC;
>
> ret = ioctl(fd, SA_IOC_ALLOC, &data);
> if (ret) {
> printf("Buffer allocation failed\n");
> goto end;
> }
>
> mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
> if (mem == MAP_FAILED) {
> printf("mmap failed\n");
> }
>
> memset(mem, 0xFF, LENGTH);
> munmap(mem, LENGTH);
>
> printf("test simple allocator CMA OK\n");
> end:
> close(fd);
> }
>
> [1] https://github.com/cubanismo/allocator
>
> Benjamin Gaignard (2):
> Create Simple Allocator module
> add CMA simple allocator module
>
> Documentation/simple-allocator.txt | 81 ++
> drivers/Kconfig | 2 +
> drivers/Makefile| 1 +
> drivers/simpleallocator/Kconfig | 17 +++
> drivers/simpleallocator/Makefile| 2 +
> drivers/simpleallocator/simple-allocator-cma.c | 187
>
> drivers/simpleallocator/simple-allocator-priv.h | 33 +
> drivers/simpleallocator/simple-allocator.c | 180 +++
> include/uapi/linux/simple-allocator.h | 35 +
> 9 files changed, 538 insertions(+)
> create mode 100644 Documentation/simple-allocator.txt
> create mode 100644 drivers/simpleallocator/Kconfig
> create mode 100644 drivers/simpleallocator/Makefile
> create mode 100644 drivers/simpleallocator/simple-allocator-cma.c
> create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
> create mode 100644 drivers/simpleallocator/simple-allocator.c
> create mode 100644 include/uapi/linux/simple-allocator.h
>
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/exynos: Remove Kconfig deps for FIMD and DECON7
On Fri, Jan 20, 2017 at 05:02:50PM +0100, Tobias Jakobi wrote: > While the Kconfig entries of FIMD and DECON7 both select > FB_MODE_HELPERS, the code doesn't use any of the functionality. > > Signed-off-by: Tobias Jakobi Applied (just this patch) to drm-misc, since that Kconfig stuff also went in through drm-misc. I'll leave the other 2 for exynos drivers for proper review. Thanks, Daniel > --- > drivers/gpu/drm/exynos/Kconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig > index d706ca4..1d18534 100644 > --- a/drivers/gpu/drm/exynos/Kconfig > +++ b/drivers/gpu/drm/exynos/Kconfig > @@ -19,7 +19,6 @@ comment "CRTCs" > config DRM_EXYNOS_FIMD > bool "FIMD" > depends on !FB_S3C > - select FB_MODE_HELPERS > select MFD_SYSCON > help > Choose this option if you want to use Exynos FIMD for DRM. > @@ -32,7 +31,6 @@ config DRM_EXYNOS5433_DECON > config DRM_EXYNOS7_DECON > bool "DECON on Exynos7" > depends on !FB_S3C > - select FB_MODE_HELPERS > help > Choose this option if you want to use Exynos DECON for DRM. > > -- > 2.7.3 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Warning at drivers/gpu/drm/drm_atomic_helper.c
On Sun, Jan 22, 2017 at 11:10:06PM -0200, Fabio Estevam wrote:
> On Sun, Jan 22, 2017 at 12:26 PM, Fabio Estevam wrote:
> > On Sat, Jan 21, 2017 at 2:40 PM, Fabio Estevam wrote:
> >> Hi,
> >>
> >> Stopping kmscube application on mx6q through CTRL + C sometimes leads
> >> to the following kernel warning:
> >>
> >> ^C[ 3939.785516] [ cut here ]
> >> [ 3939.790313] WARNING: CPU: 1 PID: 67 at
> >> drivers/gpu/drm/drm_atomic_helper.c:1032
> >> drm_atomic_helper_wait_for_fences+0xe4/0x104
> >> [ 3939.801626] Modules linked in:
> >> [ 3939.804762] CPU: 1 PID: 67 Comm: kworker/1:1 Tainted: GW
> >>4.9.4 #1
> >
> > Just tested 4.9.5 and the kernel warning is gone.
>
> Actually 4.9.5 shows the same warning.
>
> If I change .atomic_commit like in 782ea2a493ba90800 ("drm/imx: Switch
> to drm_fb_cma_prepare_fb() helper") from 4.10-rc1
>
> - .atomic_commit = imx_drm_atomic_commit,
> + .atomic_commit = drm_atomic_helper_commit,
>
> it fixes the problem.
Please submit that as a patch (of course needs to remove the function
itself too) for review by the maintainers.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Update drm_cache.c to pull in the new drm_cache.h
On Sat, Jan 21, 2017 at 06:05:05PM -0200, Gabriel Krisman Bertazi wrote:
> Chris Wilson writes:
>
> > The prototypes were moved to a new header, but the function definitions
> > were not updated to pull in the declarations.
> >
> > drivers/gpu/drm/drm_cache.c:79:1: warning: no previous prototype for
> > ‘drm_clflush_pages’ [-Wmissing-prototypes]
> > drivers/gpu/drm/drm_cache.c:120:1: warning: no previous prototype for
> > ‘drm_clflush_sg’ [-Wmissing-prototypes]
> > drivers/gpu/drm/drm_cache.c:152:1: warning: no previous prototype for
> > ‘drm_clflush_virt_range’ [-Wmissing-prototypes]
> >
> > Fixes: f9a87bd7d5b6 ("drm: Move drm_clflush prototypes to drm_cache header
> > file")
> > Signed-off-by: Chris Wilson
> > Cc: Gabriel Krisman Bertazi
> > Cc: Alex Deucher
> > Cc: Daniel Vetter
>
> Patch is good, though I'm Embarrassed that I didn't have -Wmissing-prototypes
> enabled when testing this. Thanks Chris.
>
> Reviewed-by: Gabriel Krisman Bertazi
Applied to drm-misc, thx.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97338] Black squares in the Spec Ops: The Line chapter select screen
https://bugs.freedesktop.org/show_bug.cgi?id=97338 --- Comment #8 from Aaron Paden --- (In reply to Samuel Pitoiset from comment #6) > A possible fix here: > https://lists.freedesktop.org/archives/mesa-dev/2017-January/139686.html I get a build failure after applying this patch: si_shader_tgsi_alu.c: In function ‘emit_rsq’: si_shader_tgsi_alu.c:759:43: error: ‘TGSI_OPCODE_ABS’ undeclared (first use in this function) abs = lp_build_emit_llvm_unary(bld_base, TGSI_OPCODE_ABS, ^~~ si_shader_tgsi_alu.c:759:43: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [Makefile:701: si_shader_tgsi_alu.lo] Error 1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/7] drm/atomic: Add new iterators over all state, v3.
On Thu, Jan 19, 2017 at 12:56:29AM +0200, Laurent Pinchart wrote: > On Tuesday 17 Jan 2017 08:41:03 Maarten Lankhorst wrote: > > Op 17-01-17 om 00:11 schreef Laurent Pinchart: > > > On Monday 16 Jan 2017 10:37:38 Maarten Lankhorst wrote: > > >> @@ -2512,6 +2518,47 @@ struct drm_atomic_state > > >> *drm_atomic_helper_suspend(struct drm_device *dev) > > >> EXPORT_SYMBOL(drm_atomic_helper_suspend); > > >> > > >> /** > > >> + * drm_atomic_helper_commit_duplicated_state - commit duplicated state > > >> + * @state: duplicated atomic state to commit > > >> + * @ctx: pointer to acquire_ctx to use for commit. > > >> + * > > >> + * The state returned by drm_atomic_helper_duplicate_state() and > > >> + * drm_atomic_helper_suspend() is partially invalid, and needs to > > >> + * be fixed up before commit. > > > > > > Can't you fix the state in drm_atomic_helper_suspend() to avoid the need > > > for this function ? > > > > We would have to fix up other areas that duplicate state too, like i915 > > suspend and load detect. This means moving it to a helper. > > > > It was my original approach, but Daniel preferred this approach. > > We have to fix it somewhere, that's for sure. I think it's better to fix it > as > close as possible to state duplication, instead of carrying a state that we > know is invalid and fix it at the last minute. The drawback of this approach > is that the window during which the state will be invalid is much larger, > which could cause bugs later when new code will try to touch that state. > > Daniel, is there a specific reason why you prefer this approach ? You can't fix it in suspend? The issue is that on resume, we have reset states (to reflect the hw state of everything being off), so we can only do this on commit. That holds in general for the duplicate, do something nasty, restore state pattern. And then I think a dedicated helper to commit duplicated state makes sense. The kernel-doc might need a bit of work to explain this better though. I think it should explain what exactly is partially invalid with duplicated states. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3 0/7] drm/atomic: Add accessor macros for all atomic state.
On Tue, Jan 17, 2017 at 02:45:32AM +0200, Laurent Pinchart wrote: > Hi Maarten, > > Thank you for the patches. > > On Monday 16 Jan 2017 10:37:37 Maarten Lankhorst wrote: > > Fourth iteration. Instead of trying to convert all drivers straight away, > > implement all macros that are required to get state working. > > > > Old situation: > > Use obj->state, which can refer to old or new state. > > Use drm_atomic_get_(existing_)obj_state, which can refer to new or old > > state. Use for_each_obj_in_state, which refers to new or old state. > > > > New situation: > > > > During atomic check: > > - Use drm_atomic_get_obj_state to add a object to the atomic state, > > or get the new state. > > - Use drm_atomic_get_(old/new)_obj_state to peek at the new/old state, > > without adding the object. This will return NULL if the object is > > not part of the state. For planes and connectors the relevant crtc_state > > is added, so this will work to get the crtc_state from obj_state->crtc > > too, this means not having to write some error handling. > > > > During atomic commit: > > - Do not use drm_atomic_get_obj_state, obj->state or > > drm_atomic_get_(existing_)obj_state any more, replace with > > drm_atomic_get_old/new_obj_state calls as required. > > That will make driver code quite complicated :-/ I wonder if that's really a > good solution. Maybe we should maintain obj->state only for the duration of > the commit as a way to simplify drivers, and set it to NULL at all other > times > to avoid misusing it ? I know this contradicts the comment I've made in my > review of patch 1/7, you can now choose which one to ignore :-) We still need a state pointer to track the current logical state all the time (ignoring nonblocking commits or other async magic). We might do that in obj->_state or something to discourage use, but it needs to be there. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] Allow ASYNC flip with atomic helpers.
On Tue, Jan 17, 2017 at 12:14:24AM +0200, Laurent Pinchart wrote: > Hi Harry, > > On Monday 16 Jan 2017 16:13:39 Harry Wentland wrote: > > On 2017-01-16 03:39 PM, Laurent Pinchart wrote: > > > On Monday 16 Jan 2017 10:44:54 Andrey Grodzovsky wrote: > > >> This series is a folow-up on > > >> https://patchwork.kernel.org/patch/9501787/ > > >> > > >> The first patch makes changes to atomic helpers > > >> to allow for drives with ASYNC flip support to use them. > > >> Patches 2 and 3 are to use this in AMDGPU/DC and > > >> patch 4 is possible cleanup in nouveau/kms who seems > > >> to have the duplicate the helper as we did to support > > >> ASYNC flips. > > > > > > I have my doubts regarding this. I'd much rather see userspace moving to > > > the atomic API instead of extending support for legacy APIs. > > > > This change is not about introducing the async flag but cleaning up the > > legacy helpers to make sure drivers that currently use it through the > > legacy IOCTLs can benefit from the helpers and not have to roll their own. > > > > If the problem is with the pflip_flags, wouldn't drivers still need that > > after moving userspace to the atomic IOCTL? > > > > I don't disagree with you on having userspace move to atomic but I don't > > expect to see all userspace drivers move to atomic in the next couple > > months. Why not clean this up in the meantime? > > If this patch series was just about moving common driver code into the core, > sure, but it goes beyond that. Or, actually, it needs to go beyond that, but > doesn't yet. Removing the DRM_MODE_PAGE_FLIP_ASYNC test in patch 1/4 means > that the DRM core will not reject async page flips anymore, for any driver > that uses the helper. You thus need to either patch all drivers that use the > helper to reject the flag, or implement the feature in the drivers (and > preferably in the helpers then). The current version of this patch series > will > make all existing users of the helpers accept async page flips without > actually implementing them. "How do we check for this driver feature" was one of the opens I raised here on irc, even before Andrey started typing :-) Definitely needs to be addressed. What's imo optional is exposing async flips through the atomic ioctl, since atm no atomic userspace seems to be in need of async flips yet. And the semantics of multi-plane async flips are tricky to define properly, so definitely want that userspace validation. That's why I think just doing the compat stuff is ok. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/atomic: Save flip flags in drm_plane_state
On Mon, Jan 16, 2017 at 10:44:55AM -0500, Andrey Grodzovsky wrote:
> Allows using atomic flip helpers for drivers
> using ASYNC flip.
> Remove ASYNC_FLIP restriction in helpers and
> caches the page flip flags in drm_plane_state
> to be used in the low level drivers.
>
> Signed-off-by: Andrey Grodzovsky
It's mostly guesswork, but I think we should have the flip flags in the
crtc, not in each plane. Similar to how we move the event from planes to
crtc.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 10 +++---
> include/drm/drm_plane.h | 8
> 2 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a4e5477..f83dc43 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2737,7 +2737,8 @@ static int page_flip_common(
> struct drm_atomic_state *state,
> struct drm_crtc *crtc,
> struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event)
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
> {
> struct drm_plane *plane = crtc->primary;
> struct drm_plane_state *plane_state;
> @@ -2754,6 +2755,7 @@ static int page_flip_common(
> if (IS_ERR(plane_state))
> return PTR_ERR(plane_state);
>
> + plane_state->pflip_flags = flags;
>
> ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> if (ret != 0)
> @@ -2800,9 +2802,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> struct drm_atomic_state *state;
> int ret = 0;
>
> - if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> - return -EINVAL;
> -
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> return -ENOMEM;
> @@ -2865,9 +2864,6 @@ int drm_atomic_helper_page_flip_target(
> struct drm_crtc_state *crtc_state;
> int ret = 0;
>
> - if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> - return -EINVAL;
> -
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> return -ENOMEM;
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index db3bbde..86d8ffc 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -122,6 +122,14 @@ struct drm_plane_state {
>*/
> bool visible;
>
> +
> + /**
> + * @pflip_flags:
> + *
> + * Flip related config options
> + */
> + u32 pflip_flags;
> +
> struct drm_atomic_state *state;
> };
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/exynos: use atomic helper commit
2017년 01월 20일 22:05에 Tobias Jakobi 이(가) 쓴 글:
> Inki Dae wrote:
>> Hi Tobias,
>>
>> 2017년 01월 19일 21:49에 Tobias Jakobi 이(가) 쓴 글:
>>> What about Laurent's comment stating that drm_atomic_helper_commit() is
>>> broken at the moment? Shouldn't there be some kind of warning in the
>>> commit message that this patch is only safe to apply once the fixes for
>>> drm_atomic_helper_commit() have landed? I'm already seeing this getting
>>> merged by accident, without Maarten's series even being reviewed.
>>
>> What patches you mean?
> The patchset that Laurent mentioned.
> [PATCH v3 0/7] drm/atomic: Add accessor macros for all atomic state.
> https://www.spinics.net/lists/dri-devel/msg129537.html
>
>
>> According to Laurent's comment, async commit support of
>> drm_atomic_helper_commit is subect to a race condition.
>> So I'm checking whether there is any case to use async commit in Exynos DRM
>> driver.
> I'm not sure what you're exactly checking here, because it is userspace
> that requests a atomic commit to be executed asynchronously.
Hm... See the below code from mainline,
nt drm_mode_atomic_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
...
if ((arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) &&
!dev->mode_config.async_page_flip)
return -EINVAL;
...
I'm not sure you checked Exynos drm driver but Exynos drm driver doesn't
support async page flip.
And you are right. userspace requests async commit but that is also depend on
specific driver.
>
>
>> As of now, I don't see any case. even without Maarten's patch set, it works
>> well - actually, I had a test with atomic test app more than 10 hours..
> Can you provide this test application? In particular I'm asking this
> because libdrm currently doesn't provide any tests using the atomic API.
> So this application might be of interest also for other people.
Below is the app I tested. Know that this application is from chromiumOS tree
and I just fixed some parts for internal test.
https://review.tizen.org/git/?p=platform/upstream/libdrm.git;a=commitdiff;h=9d3bd95f2c5a9b4b69062a3ff008947054b94f55
>
>
>> And important thing is that this posting is just for review not merge.
> In this case the patches should be tagged as 'RFC', something which I
> don't see here.
>
>
>> So if there is any critical problem with this patch, I will stop to merge
>> it. This would be my role, maintainer.
> Let me phrase it this way. Your patch is not fixing a bug, it is a
This patch definitely phrased 'This patch replaces specific atomic commit
function with atomic helper commit one' not fixing a bug.
Thanks.
> cleanup patch that reduces driver specific code with DRM core code. But
> as Laurent has pointed out this core code currently has some known (!)
> issues. In the interest of not breaking anything I would advise against
> merging this before Maarten's patches have landed.
>
>
> With best wishes,
> Tobias
>
>
>>
>> Thanks.
>>
>>>
>>> The commit message looks much better now. Still some spelling issues remain:
>>> implemention -> implementation
>>>
>>>
>>> With best wishes,
>>> Tobias
>>>
>>>
>>> Inki Dae wrote:
This patch replaces specific atomic commit function
with atomic helper commit one.
For this, it removes existing atomic commit function
and relevant code specific to Exynos DRM and makes
atomic helper commit to be used instead.
Below are changes for the use of atomic helper commit:
- add atomic_commit_tail callback specific to Exynos DRM
. default implemention of atomic helper doesn't mesh well
with runtime PM so the device driver which supports runtime
PM should call drm_atomic_helper_commit_modeset_enables function
prior to drm_atomic_helper_commit_planes function call.
atomic_commit_tail callback implements this call ordering.
- allow plane commit only in case that CRTC device is enabled.
. for this, it calls atomic_helper_commit_planes function
with DRM_PLANE_COMMIT_ACTIVE_ONLY flag in atomic_commit_tail callback.
Changelog v1:
- fix comment
- fix trivial things
- revive existing comment which explains why plane commit should be
called after crtc and encoder device are enabled.
Signed-off-by: Inki Dae
Reviewed-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 10 ++-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 109
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 32 -
3 files changed, 40 insertions(+), 111 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 2530bf5..8f13bce 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -39,6 +39,14 @@ static void
Re: [PATCH 1/9] drm/fb-cma-helper: Add drm_fbdev_cma_set_suspend_unlocked()
On Sun, Jan 22, 2017 at 07:11:09PM +0100, Noralf Trønnes wrote:
> Add a CMA version of drm_fb_helper_set_suspend_unlocked().
>
> Cc: laurent.pinch...@ideasonboard.com
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 18 ++
> include/drm/drm_fb_cma_helper.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 4364abf..0ef8b28 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -622,3 +622,21 @@ void drm_fbdev_cma_set_suspend(struct drm_fbdev_cma
> *fbdev_cma, int state)
> drm_fb_helper_set_suspend(&fbdev_cma->fb_helper, state);
> }
> EXPORT_SYMBOL(drm_fbdev_cma_set_suspend);
Random idea for a cleanup series: Getting rid of
drm_fb_helper_set_suspend. I thinkf for almost all drivers we can use the
unlocked one, which has the upside that it doesn't stall the resume path
on the contended console_lock.
Anyway, applied this one here, thanks.
-Daniel
> +
> +/**
> + * drm_fbdev_cma_set_suspend_unlocked - wrapper around
> + * drm_fb_helper_set_suspend_unlocked
> + * @fbdev_cma: The drm_fbdev_cma struct, may be NULL
> + * @state: desired state, zero to resume, non-zero to suspend
> + *
> + * Calls drm_fb_helper_set_suspend, which is a wrapper around
> + * fb_set_suspend implemented by fbdev core.
> + */
> +void drm_fbdev_cma_set_suspend_unlocked(struct drm_fbdev_cma *fbdev_cma,
> + int state)
> +{
> + if (fbdev_cma)
> + drm_fb_helper_set_suspend_unlocked(&fbdev_cma->fb_helper,
> +state);
> +}
> +EXPORT_SYMBOL(drm_fbdev_cma_set_suspend_unlocked);
> diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
> index 9f4e34e..8dd6e55 100644
> --- a/include/drm/drm_fb_cma_helper.h
> +++ b/include/drm/drm_fb_cma_helper.h
> @@ -26,6 +26,8 @@ void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma);
> void drm_fbdev_cma_restore_mode(struct drm_fbdev_cma *fbdev_cma);
> void drm_fbdev_cma_hotplug_event(struct drm_fbdev_cma *fbdev_cma);
> void drm_fbdev_cma_set_suspend(struct drm_fbdev_cma *fbdev_cma, int state);
> +void drm_fbdev_cma_set_suspend_unlocked(struct drm_fbdev_cma *fbdev_cma,
> + int state);
>
> void drm_fb_cma_destroy(struct drm_framebuffer *fb);
> int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
> --
> 2.10.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] arm64: dts: exynos: configure TV path clocks for Ultra HD modes
Hi Andrzej, On 2017-01-23 08:56, Andrzej Hajda wrote: Ultra HD modes requires clock ticking at increased rate. Signed-off-by: Andrzej Hajda --- arch/arm64/boot/dts/exynos/exynos5433.dtsi | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi index f120d99..4d28e93 100644 --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi I think that exynos5433-tm2-common.dtsi is a better place for such definitions. They can be also moved to &cmu_disp node to match convention for the clocks configuration used on particular board. @@ -764,6 +764,17 @@ clock-names = "pclk", "aclk_decon", "aclk_smmu_decon0x", "aclk_xiu_decon0x", "pclk_smmu_decon0x", "sclk_decon_vclk", "sclk_decon_eclk"; + assigned-clocks = + <&cmu_mif CLK_MOUT_SCLK_DECON_TV_ECLK_A>, + <&cmu_mif CLK_DIV_SCLK_DECON_TV_ECLK>, + <&cmu_disp CLK_MOUT_SCLK_DECON_TV_ECLK_USER>, + <&cmu_disp CLK_MOUT_SCLK_DECON_TV_ECLK>; + assigned-clock-parents = + <&cmu_mif CLK_MOUT_BUS_PLL_DIV2>, + <0>, + <&cmu_mif CLK_SCLK_DECON_TV_ECLK_DISP>, + <&cmu_disp CLK_MOUT_SCLK_DECON_TV_ECLK_USER>; + assigned-clock-rates = <0>, <4>; samsung,disp-sysreg = <&syscon_disp>; interrupt-names = "fifo", "vsync", "lcd_sys"; interrupts = , Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] drm: debugfs: Remove all files automatically on cleanup
On Sun, Jan 22, 2017 at 07:11:10PM +0100, Noralf Trønnes wrote:
> Instead of having the drivers call drm_debugfs_remove_files() in
> their drm_driver->debugfs_cleanup hook, do it automatically by
> traversing minor->debugfs_list.
> Also use debugfs_remove_recursive() so drivers who add their own
> debugfs files don't have to keep track of them for removal.
>
> Signed-off-by: Noralf Trønnes
Makes sense, but that leaves us with a pile of dead code in drivers? Can
you pls go through them and remove this all (including the debugfs_cleanup
hook), and then removing the remaining (now dead) code in the core?
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_debugfs.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 37fd612..0510ce2 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -218,6 +218,19 @@ int drm_debugfs_remove_files(const struct drm_info_list
> *files, int count,
> }
> EXPORT_SYMBOL(drm_debugfs_remove_files);
>
> +static void drm_debugfs_remove_all_files(struct drm_minor *minor)
> +{
> + struct drm_info_node *node, *tmp;
> +
> + mutex_lock(&minor->debugfs_lock);
> + list_for_each_entry_safe(node, tmp, &minor->debugfs_list, list) {
> + debugfs_remove(node->dent);
> + list_del(&node->list);
> + kfree(node);
> + }
> + mutex_unlock(&minor->debugfs_lock);
> +}
> +
> /**
> * Cleanup the debugfs filesystem resources.
> *
> @@ -245,9 +258,9 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
> }
> }
>
> - drm_debugfs_remove_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES, minor);
> + drm_debugfs_remove_all_files(minor);
>
> - debugfs_remove(minor->debugfs_root);
> + debugfs_remove_recursive(minor->debugfs_root);
> minor->debugfs_root = NULL;
>
> return 0;
> --
> 2.10.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/error: use rb_entry()
On Fri, Jan 20, 2017 at 10:36:55PM +0800, Geliang Tang wrote: > To make the code clearer, use rb_entry() instead of container_of() to > deal with rbtree. > > Signed-off-by: Geliang Tang Applied, thanks. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: g2d: fix overflow of cmdlist size
2017년 01월 23일 17:22에 Joonyoung Shim 이(가) 쓴 글: > Hi Tobias, > > On 01/21/2017 01:05 AM, Tobias Jakobi wrote: >> Hello Joonyoung, >> >> >> Joonyoung Shim wrote: >>> Hi Tobias, >>> >>> On 01/19/2017 10:16 PM, Tobias Jakobi wrote: Hello Joonyoung, Joonyoung Shim wrote: > Hi Tobias, > > On 01/17/2017 11:24 PM, Tobias Jakobi wrote: >> Joonyoung Shim wrote: >>> The size of cmdlist is integer type, so it can be overflowed by cmd and >>> cmd_buf that has too big size. This patch will fix overflow issue as >>> checking maximum size of cmd and cmd_buf. >> I don't understand/see the issue here. Could you point out for which >> input of the set_cmdlist ioctl you see this particular overflow? >> >> In particular it is not clear to me which size field you're talking >> about. struct g2d_cmdlist does not have any field named 'size'. >> > > I mean size of cmdlist is > size = cmdlist->last + req->cmd_nr * 2 + req->cmd_buf_nr * 2 + 2; > in exynos_g2d_set_cmdlist_ioctl(). ok, that makes things more clear. But then you need to fix the commit message. The current message implies that this 'size' you're talking about is some property of the cmdlist. Also the new comment is wrong. /* Check size of cmd and cmdlist: last 2 is about G2D_BITBLT_START */ What is cmd and cmdlist? You're mixing two different things here. We are still checking the size of 'cmdlist' (which is a struct g2d_cmdlist) here. What you add is a check for the fields of 'req' (which is a struct drm_exynos_g2d_set_cmdlist). With all that said, I don't like the changes. I see the issue, but the current solution should be cleaner. I propose this. We just check req->cmd_buf_nr and req->cmd_nr against G2D_CMDLIST_DATA_NUM. This leaves us enough headrom so that the later computation (i.e. what is ending up in the local variable 'size') can never overflow. >>> >>> Agree, it's more clear to check req->cmd_buf_nr and req->cmd_nr against >>> G2D_CMDLIST_DATA_NUM. >>> For a comment for the check I propose this: "To avoid an integer overflow for the later size computations, we enforce a maximum number of submitted commands here. This limit is sufficient for all conceivable usage cases of the G2D." >>> >>> Could you post your patch to ML about this if you want? >> Sure, I've just send it together with two other small patches. Let me >> know if the current version is OK with you. I hope I did the order of >> SoB correctly (I know that Krzysztof has pointed this out lately). >> > > I don't know exactly about order of SoB but it's ok to me except > WARNING: line over 80 characters from checkpatch.pl. Trivial thing. I can fix it. Thanks. > > Thanks for posting. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] drm/exynos/decon5433: signal vblank only on odd fields
On 20.01.2017 14:55, Ville Syrjälä wrote: > On Fri, Jan 20, 2017 at 07:52:24AM +0100, Andrzej Hajda wrote: >> In case of interlace mode irq is generated for odd and even fields, but >> vblank should be signaled only for the last emitted field. > I'm pretty sure most drivers signal it for both fields. At least i915 > does. The question is which behavior is correct? I have not found any clear statement in the documentation, or drm core code. I have guessed that since vblank event is used to signal end of scan-out of buffer it should be called after scan-out of whole buffer - in case of interlaced mode after scan-out of 2nd field. Maybe my assumption is wrong, in such case this patch should be dropped and mixer driver also should be fixed, but before doing that it would be good to know for sure how it should be handled correctly. Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/24] drm/bridge/sii8620: rewrite hdmi start sequence
On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
MHL3 protocol requires registry adjustments depending on chosen video mode.
Necessary information is gathered in mode_fixup callback. In case of HDMI
video modes driver should also send special AVI and MHL infoframes.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sil-sii8620.c | 249 +++
drivers/gpu/drm/bridge/sil-sii8620.h | 15 ++-
2 files changed, 231 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 1c76905..2c7b5b9 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -32,6 +32,8 @@
#define SII8620_BURST_BUF_LEN 288
#define VAL_RX_HDMI_CTRL2_DEFVAL VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
+#define MHL1_MAX_LCLK 225000
+#define MHL3_MAX_LCLK 60
enum sii8620_mode {
CM_DISCONNECTED,
@@ -62,6 +64,9 @@ struct sii8620 {
struct regulator_bulk_data supplies[2];
struct mutex lock; /* context lock, protects fields below */
int error;
+ int pixel_clock;
+ unsigned int use_packed_pixel:1;
+ int video_code;
enum sii8620_mode mode;
enum sii8620_sink_type sink_type;
u8 cbus_status;
@@ -69,7 +74,7 @@ struct sii8620 {
u8 xstat[MHL_XDS_SIZE];
u8 devcap[MHL_DCAP_SIZE];
u8 xdevcap[MHL_XDC_SIZE];
- u8 avif[19];
+ u8 avif[HDMI_INFOFRAME_SIZE(AVI)];
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
@@ -685,6 +690,40 @@ static void sii8620_burst_tx_rbuf_info(struct sii8620
*ctx, int size)
d->size = cpu_to_le16(size);
}
+static u8 sii8620_checksum(void *ptr, int size)
+{
+ u8 *d = ptr, sum = 0;
+
+ while (size--)
+ sum += *d++;
+
+ return sum;
+}
+
+static void sii8620_mhl_burst_hdr_set(struct mhl3_burst_header *h,
+ enum mhl_burst_id id)
+{
+ h->id = cpu_to_be16(id);
+ h->total_entries = 1;
+ h->sequence_index = 1;
+}
+
+static void sii8620_burst_tx_bits_per_pixel_fmt(struct sii8620 *ctx, u8 fmt)
+{
+ struct mhl_burst_bits_per_pixel_fmt *d;
+ const int size = sizeof(*d) + sizeof(d->desc[0]);
+
+ d = sii8620_burst_get_tx_buf(ctx, size);
+ if (!d)
+ return;
+
+ sii8620_mhl_burst_hdr_set(&d->hdr, MHL_BURST_ID_BITS_PER_PIXEL_FMT);
+ d->num_entries = 1;
+ d->desc[0].stream_id = 0;
+ d->desc[0].pixel_format = fmt;
+ d->hdr.checksum -= sii8620_checksum(d, size);
+}
+
static void sii8620_burst_rx_all(struct sii8620 *ctx)
{
u8 *d = ctx->burst.rx_buf;
@@ -949,32 +988,162 @@ static void sii8620_stop_video(struct sii8620 *ctx)
sii8620_write(ctx, REG_TPI_SC, val);
}
+static void sii8620_set_format(struct sii8620 *ctx)
+{
+ u8 out_fmt;
+
+ if (sii8620_is_mhl3(ctx)) {
+ sii8620_setbits(ctx, REG_M3_P0CTRL,
+ BIT_M3_P0CTRL_MHL3_P0_PIXEL_MODE_PACKED,
+ ctx->use_packed_pixel ? ~0 : 0);
+ } else {
+ if (ctx->use_packed_pixel)
+ sii8620_write_seq_static(ctx,
+ REG_VID_MODE, BIT_VID_MODE_M1080P,
+ REG_MHL_TOP_CTL, BIT_MHL_TOP_CTL_MHL_PP_SEL | 1,
+ REG_MHLTX_CTL6, 0x60
+ );
+ else
+ sii8620_write_seq_static(ctx,
+ REG_VID_MODE, 0,
+ REG_MHL_TOP_CTL, 1,
+ REG_MHLTX_CTL6, 0xa0
+ );
+ }
+
+ if (ctx->use_packed_pixel)
+ out_fmt = VAL_TPI_FORMAT(YCBCR422, FULL) |
+ BIT_TPI_OUTPUT_CSCMODE709;
+ else
+ out_fmt = VAL_TPI_FORMAT(RGB, FULL);
+
+ sii8620_write_seq(ctx,
+ REG_TPI_INPUT, VAL_TPI_FORMAT(RGB, FULL),
+ REG_TPI_OUTPUT, out_fmt,
+ );
+}
+
+#define MHL3_VSIF_TYPE 0x81
+#define MHL3_VSIF_VERSION 0x03
+#define MHL3_VSIF_LENGTH 0x0f
+#define IEEE_OUI_MHL3 0x7CA61D
Should these be in mhl.h?
Some of these seem similar to the infoframe related defs
in include/linux/hdmi.h
Do you think there should be equivalent helpers for mhl infoframes
similar to hdmi_vendor_infoframe_init
and hdmi_vendor_infoframe_pack()?
Thanks,
Archit
+
+static void sii8620_mhl_infoframe_init(void *ptr, int size)
+{
+ u8 *buf = ptr;
+
+ memset(buf, 0, size);
+ buf[0] = MHL3_VSIF_TYPE;
+ buf[1] = MHL3_VSIF_VERSION;
+ buf[2] = MHL3_VSIF_LENGTH;
+ buf[4] = IEEE_OUI_MHL3 & 0xff;
+ buf[5] = (IEEE_OUI_MHL3 >> 8) & 0xff;
+ buf[6] = (IEEE_OUI_MHL3 >> 16) & 0xff;
+ buf[3] -= sii8620_checksum(buf, MHL3_VSIF_LENGTH);
+}
+
+static void sii8620_set_infoframes(struct sii8620 *ctx)
+{
+ union
[Bug 98856] [Regression, SI] DIRT: Showdown broken graphics
https://bugs.freedesktop.org/show_bug.cgi?id=98856 --- Comment #6 from Gregor Münch --- Problem is still there as of mesa git from Friday. Also, the trying replaying my trace hangs the GPU. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off
https://bugs.freedesktop.org/show_bug.cgi?id=99418 --- Comment #21 from Michel Dänzer --- (In reply to lei.pero from comment #18) > I didn't know that about modesetting driver, anyway, even with > LIBGL_DRI3_DISABLE=1 same thing happens. Maybe chromium doesn't pass on the environment variable to its GPU helper process, or maybe there was still a chromium process around. > I don't how to disable tripple buffering to test it and if it's possible, Only by changing the code, mesa/src/loader/loader_dri3_helper.c:dri3_update_num_back(). E.g. set num_back = 1 in the else case. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm: Add DRM support for tiny LCD displays
On Sun, Jan 22, 2017 at 07:11:12PM +0100, Noralf Trønnes wrote: > tinydrm provides helpers for very simple displays that can use > CMA backed framebuffers and need flushing on changes. > > Signed-off-by: Noralf Trønnes Looks all pretty. A bunch of ideas below, but all optional. For merging I think simplest to first get the core patches in through drm-misc, and then you can submit a pull request to Dave for tinydrm+backends (just needs an ack for the dt parts from dt maintainers), including MAINTAINERS entry. Ack from my side. Thanks, Daniel > --- > Documentation/gpu/drm-kms-helpers.rst | 15 ++ > MAINTAINERS | 7 + > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/tinydrm/Kconfig | 8 + > drivers/gpu/drm/tinydrm/Makefile| 1 + > drivers/gpu/drm/tinydrm/core/Makefile | 3 + > drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 374 > > drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 244 ++ > include/drm/tinydrm/tinydrm.h | 115 + > 10 files changed, 770 insertions(+) > create mode 100644 drivers/gpu/drm/tinydrm/Kconfig > create mode 100644 drivers/gpu/drm/tinydrm/Makefile > create mode 100644 drivers/gpu/drm/tinydrm/core/Makefile > create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-core.c > create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c > create mode 100644 include/drm/tinydrm/tinydrm.h > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > b/Documentation/gpu/drm-kms-helpers.rst > index 03040aa..a86bd7f 100644 > --- a/Documentation/gpu/drm-kms-helpers.rst > +++ b/Documentation/gpu/drm-kms-helpers.rst > @@ -272,3 +272,18 @@ Auxiliary Modeset Helpers > > .. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c > :export: > + > +tinydrm Helper Reference > + > + > +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-core.c > + :doc: overview > + > +.. kernel-doc:: include/drm/tinydrm/tinydrm.h > + :internal: > + > +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-core.c > + :export: > + > +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c > + :export: Since tinydrm is more like a special driver than a helper I think it would make sense to move the docs into the driver section, next to the include for the i915 stuff. That means a new tinydrm.rst and including it in gpu/index.rst. > diff --git a/MAINTAINERS b/MAINTAINERS > index 741f35f..817e0fe 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4365,6 +4365,13 @@ DRM DRIVER FOR TDFX VIDEO CARDS > S: Orphan / Obsolete > F: drivers/gpu/drm/tdfx/ > > +DRM DRIVERS FOR TINY DISPLAYS > +M: Noralf Trønnes > +W: https://github.com/notro/tinydrm/wiki > +S: Maintained > +F: drivers/gpu/drm/tinydrm/ > +F: include/drm/tinydrm/ > + > DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS > M: Dave Airlie > S: Odd Fixes > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 90bc65d..88e01e08e 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -263,6 +263,8 @@ source "drivers/gpu/drm/mxsfb/Kconfig" > > source "drivers/gpu/drm/meson/Kconfig" > > +source "drivers/gpu/drm/tinydrm/Kconfig" > + > # Keep legacy drivers last > > menuconfig DRM_LEGACY > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 92de399..3ee9579 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -94,3 +94,4 @@ obj-$(CONFIG_DRM_ARCPGU)+= arc/ > obj-y+= hisilicon/ > obj-$(CONFIG_DRM_ZTE)+= zte/ > obj-$(CONFIG_DRM_MXSFB) += mxsfb/ > +obj-$(CONFIG_DRM_TINYDRM) += tinydrm/ > diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig > new file mode 100644 > index 000..ffb873f > --- /dev/null > +++ b/drivers/gpu/drm/tinydrm/Kconfig > @@ -0,0 +1,8 @@ > +menuconfig DRM_TINYDRM > + tristate "Support for simple displays" > + depends on DRM > + select DRM_KMS_HELPER > + select DRM_KMS_CMA_HELPER > + help > + Choose this option if you have a tinydrm supported display. > + If M is selected the module will be called tinydrm. > diff --git a/drivers/gpu/drm/tinydrm/Makefile > b/drivers/gpu/drm/tinydrm/Makefile > new file mode 100644 > index 000..7476ed1 > --- /dev/null > +++ b/drivers/gpu/drm/tinydrm/Makefile > @@ -0,0 +1 @@ > +obj-$(CONFIG_DRM_TINYDRM)+= core/ > diff --git a/drivers/gpu/drm/tinydrm/core/Makefile > b/drivers/gpu/drm/tinydrm/core/Makefile > new file mode 100644 > index 000..4f14a0f > --- /dev/null > +++ b/drivers/gpu/drm/tinydrm/core/Makefile > @@ -0,0 +1,3 @@ > +tinydrm-y := tinydrm-core.o tinydrm-pipe.o > + > +obj-$(CONFIG_DRM_TINYDRM) += tinydrm.o > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c > b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c > new file mode 1006
Re: [PATCH] drm/exynos: fix a timeout loop
2017년 01월 21일 01:54에 Tobias Jakobi 이(가) 쓴 글:
> From: Dan Carpenter
>
> We were trying to print an error message if we timed out here, but the
> loop actually ends with "tries" set to UINT_MAX and not zero. Fix this
> by changing from tries-- to --tries.
Sorry but I already know this patch from long ago but I'm not clear yet.
How the variable, tries, could have UNIT_MAX?
Seems something I'm missing.
Thanks.
>
> A for loop would actually be the most natural way to do this. My fix
> means we only loop 99 times instead of 100 but that's probably ok.
>
> Fixes: a696394c5224 ('drm/exynos: mixer: simplify loop in vp_win_reset()')
> Signed-off-by: Dan Carpenter
> Reviewed-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index edb20a3..fcc7e4f 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -701,7 +701,7 @@ static void vp_win_reset(struct mixer_context *ctx)
> unsigned int tries = 100;
>
> vp_reg_write(res, VP_SRESET, VP_SRESET_PROCESSING);
> - while (tries--) {
> + while (--tries) {
> /* waiting until VP_SRESET_PROCESSING is 0 */
> if (~vp_reg_read(res, VP_SRESET) & VP_SRESET_PROCESSING)
> break;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] drm/tinydrm: Add helper functions
On Sun, Jan 22, 2017 at 07:11:13PM +0100, Noralf Trønnes wrote:
> Add common functionality needed by many tinydrm drivers.
>
> Signed-off-by: Noralf Trønnes
Bunch of comments below, all optional.
-Daniel
> ---
> Documentation/gpu/drm-kms-helpers.rst | 6 +
> drivers/gpu/drm/tinydrm/core/Makefile | 2 +-
> drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 490
> +
> include/drm/tinydrm/tinydrm-helpers.h | 100 +
> 4 files changed, 597 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> create mode 100644 include/drm/tinydrm/tinydrm-helpers.h
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index a86bd7f..be07e76 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -287,3 +287,9 @@ tinydrm Helper Reference
>
> .. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
> :export:
> +
> +.. kernel-doc:: include/drm/tinydrm/tinydrm-helpers.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> + :export:
> diff --git a/drivers/gpu/drm/tinydrm/core/Makefile
> b/drivers/gpu/drm/tinydrm/core/Makefile
> index 4f14a0f..fb221e6 100644
> --- a/drivers/gpu/drm/tinydrm/core/Makefile
> +++ b/drivers/gpu/drm/tinydrm/core/Makefile
> @@ -1,3 +1,3 @@
> -tinydrm-y := tinydrm-core.o tinydrm-pipe.o
> +tinydrm-y := tinydrm-core.o tinydrm-pipe.o tinydrm-helpers.o
>
> obj-$(CONFIG_DRM_TINYDRM) += tinydrm.o
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> new file mode 100644
> index 000..fc02e01
> --- /dev/null
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> @@ -0,0 +1,490 @@
> +/*
> + * Copyright (C) 2016 Noralf Trønnes
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static unsigned int spi_max;
> +module_param(spi_max, uint, 0400);
> +MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
> +
> +/**
> + * tinydrm_merge_clips - Merge clip rectangles
> + * @dst: Destination clip rectangle
> + * @src: Source clip rectangle(s)
> + * @num_clips: Number of @src clip rectangles
> + * @flags: Dirty fb ioctl flags
> + * @max_width: Maximum width of @dst
> + * @max_height: Maximum height of @dst
> + *
> + * This function merges @src clip rectangle(s) into @dst. If @src is NULL,
> + * @max_width and @min_width is used to set a full @dst clip rectangle.
> + *
> + * Returns:
> + * true if it's a full clip, false otherwise
> + */
> +bool tinydrm_merge_clips(struct drm_clip_rect *dst,
> + struct drm_clip_rect *src, unsigned int num_clips,
> + unsigned int flags, u32 max_width, u32 max_height)
> +{
> + unsigned int i;
> +
> + if (!src || !num_clips) {
> + dst->x1 = 0;
> + dst->x2 = max_width;
> + dst->y1 = 0;
> + dst->y2 = max_height;
> + return true;
> + }
> +
> + dst->x1 = ~0;
> + dst->y1 = ~0;
> + dst->x2 = 0;
> + dst->y2 = 0;
> +
> + for (i = 0; i < num_clips; i++) {
> + if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
> + i++;
> + dst->x1 = min(dst->x1, src[i].x1);
> + dst->x2 = max(dst->x2, src[i].x2);
> + dst->y1 = min(dst->y1, src[i].y1);
> + dst->y2 = max(dst->y2, src[i].y2);
> + }
> +
> + if (dst->x2 > max_width || dst->y2 > max_height ||
> + dst->x1 >= dst->x2 || dst->y1 >= dst->y2) {
> + DRM_DEBUG_KMS("Illegal clip: x1=%u, x2=%u, y1=%u, y2=%u\n",
> + dst->x1, dst->x2, dst->y1, dst->y2);
> + dst->x1 = 0;
> + dst->y1 = 0;
> + dst->x2 = max_width;
> + dst->y2 = max_height;
> + }
> +
> + return (dst->x2 - dst->x1) == max_width &&
> +(dst->y2 - dst->y1) == max_height;
> +}
> +EXPORT_SYMBOL(tinydrm_merge_clips);
Argh, the drm_clip_rect vs. drm_rect confusion strikes again :(
> +
> +/**
> + * tinydrm_memcpy - Copy clip buffer
> + * @dst: Destination buffer
> + * @vaddr: Source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + */
> +void tinydrm_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
> + struct drm_clip_rect *clip)
> +{
> + unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
> + unsigned int pitch = fb->pitches[0];
> + void *src = vaddr + (clip->y1 * pitch) + (clip->x1 * cpp);
> + size_t len = (clip->x2 - clip->x1) * cpp;
> + unsigned int y;
> +
> + for
Re: [PATCH] drm/exynos: fix a timeout loop
On Mon, Jan 23, 2017 at 06:32:16PM +0900, Inki Dae wrote: > > > 2017년 01월 21일 01:54에 Tobias Jakobi 이(가) 쓴 글: > > From: Dan Carpenter > > > > We were trying to print an error message if we timed out here, but the > > loop actually ends with "tries" set to UINT_MAX and not zero. Fix this > > by changing from tries-- to --tries. > > Sorry but I already know this patch from long ago but I'm not clear yet. > How the variable, tries, could have UNIT_MAX? The value of tries after the final loop is -1u. The WARN fires on a succesful read on the final loop, instead of the complete failure. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/color: un-inline drm_color_lut_extract()
The function is not that big, but it's also not used for anything
performance critical. Make it a normal function.
As a side effect, this apparently makes sparse smarter about what it's
doing, and gets rid of the warning:
./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295) for
type unsigned long
./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
constant value (8000 becomes 0)
Cc: Lionel Landwerlin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_color_mgmt.c | 24
include/drm/drm_color_mgmt.h | 27 ++-
2 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 789b4c65cd69..5618f60c7690 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -88,6 +88,30 @@
*/
/**
+ * drm_color_lut_extract - clamp&round LUT entries
+ * @user_input: input value
+ * @bit_precision: number of bits the hw LUT supports
+ *
+ * Extract a degamma/gamma LUT value provided by user (in the form of
+ * &drm_color_lut entries) and round it to the precision supported by the
+ * hardware.
+ */
+uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
+{
+ uint32_t val = user_input;
+ uint32_t max = 0x >> (16 - bit_precision);
+
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 16) {
+ val += 1UL << (16 - bit_precision - 1);
+ val >>= 16 - bit_precision;
+ }
+
+ return clamp_val(val, 0, max);
+}
+EXPORT_SYMBOL(drm_color_lut_extract);
+
+/**
* drm_crtc_enable_color_mgmt - enable color management properties
* @crtc: DRM CRTC
* @degamma_lut_size: the size of the degamma lut (before CSC)
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index c767238ac9d5..bce4a532836d 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -25,6 +25,8 @@
#include
+uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
+
void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
uint degamma_lut_size,
bool has_ctm,
@@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
int gamma_size);
-/**
- * drm_color_lut_extract - clamp&round LUT entries
- * @user_input: input value
- * @bit_precision: number of bits the hw LUT supports
- *
- * Extract a degamma/gamma LUT value provided by user (in the form of
- * &drm_color_lut entries) and round it to the precision supported by the
- * hardware.
- */
-static inline uint32_t drm_color_lut_extract(uint32_t user_input,
-uint32_t bit_precision)
-{
- uint32_t val = user_input;
- uint32_t max = 0x >> (16 - bit_precision);
-
- /* Round only if we're not using full precision. */
- if (bit_precision < 16) {
- val += 1UL << (16 - bit_precision - 1);
- val >>= 16 - bit_precision;
- }
-
- return clamp_val(val, 0, max);
-}
-
-
#endif
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: Provide a driver hook for drm_dev_release()
On Sat, Jan 21, 2017 at 11:21:28PM +0200, Laurent Pinchart wrote: > Hi Chris, > > Thank you for the patch. > > On Saturday 21 Jan 2017 10:58:25 Chris Wilson wrote: > > Some state is coupled into the device lifetime outside of the > > load/unload timeframe and requires teardown during final unreference > > from drm_dev_release(). For example, dmabufs hold both a device and > > module reference and may live longer than expected (i.e. the current > > pattern of the driver tearing down its state and then releasing a > > reference to the drm device) and yet touch driver private state when > > destroyed. > > > > v2: Export drm_dev_fini() and move the responsible for finalizing the > > drm_device and freeing it to the release callback. (If no callback is > > provided, the core will call drm_dev_fini() and kfree(dev) as before.) > > v3: Remember to add drm_dev_fini() to drm_drv.h > > This takes my comments into account, thank you for that. Do you have a patch > that shows usage of the release callback in a driver ? I haven't yet dared start to split i915 between pci-device teardown and system teardown, but https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=prescheduler&id=00a6ab3689ad09a0f2ea1df8e4a03a38721d2328 shows a use of driver->release to avoid the memory corruption with dmabuf versus the virtual device. vgem should also provide a useful example. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vgem: Switch to reservation_object_lock() helpers
For the convenience of encapsulation the reservation object's ww_mutex
was wrapped in pair of lock/unlock helpers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/vgem/vgem_fence.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c
b/drivers/gpu/drm/vgem/vgem_fence.c
index da25dfe7b80e..3109c8308eb5 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -190,12 +190,12 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
/* Expose the fence via the dma-buf */
ret = 0;
- ww_mutex_lock(&resv->lock, NULL);
+ reservation_object_lock(resv, NULL);
if (arg->flags & VGEM_FENCE_WRITE)
reservation_object_add_excl_fence(resv, fence);
else if ((ret = reservation_object_reserve_shared(resv)) == 0)
reservation_object_add_shared_fence(resv, fence);
- ww_mutex_unlock(&resv->lock);
+ reservation_object_unlock(resv);
/* Record the fence in our idr for later signaling */
if (ret == 0) {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99492] [intel_gpu_tools] intel_gpu_frequency's parsing of parameters broken
https://bugs.freedesktop.org/show_bug.cgi?id=99492 yann changed: What|Removed |Added Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Component|DRM/Intel |IGT -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: sii902x: fix get edid may fail
From: Andrea Merello
The standard DRM function to get the edid from the i2c bus performs
(at least) two transfers.
By experiments it seems that the sii9022a have problems with the
2nd I2C start, at least unless a wait is introduced detween the
two transfers.
So we perform one single I2C transfer, and if the transfer must be
split, then we introduce a delay.
Signed-off-by: Andrea Merello
Cc: Andrea Merello
Cc: Boris Brezillon
Cc: Archit Taneja
Cc: David Airlie
---
drivers/gpu/drm/bridge/sii902x.c | 70 +++-
1 file changed, 69 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 9126d03..042d7e2 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -133,6 +133,62 @@ static const struct drm_connector_funcs
sii902x_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
+#define DDC_SEGMENT_ADDR 0x30
+static int sii902x_do_probe_ddc_edid(void *data, u8 *buf,
+unsigned int block, size_t len)
+{
+ struct i2c_adapter *adapter = data;
+ unsigned char start = block * EDID_LENGTH;
+ unsigned char segment = block >> 1;
+ unsigned char xfers = segment ? 3 : 2;
+ int ret, retries = 5;
+
+ /*
+* The core I2C driver will automatically retry the transfer if the
+* adapter reports EAGAIN. However, we find that bit-banging transfers
+* are susceptible to errors under a heavily loaded machine and
+* generate spurious NAKs and timeouts. Retrying the transfer
+* of the individual block a few times seems to overcome this.
+*/
+ while (1) {
+ struct i2c_msg msgs[] = {
+ {
+ .addr = DDC_SEGMENT_ADDR,
+ .flags = 0,
+ .len= 1,
+ .buf= &segment,
+ }, {
+ .addr = DDC_ADDR,
+ .flags = 0,
+ .len= 1,
+ .buf= &start,
+ }, {
+ .addr = DDC_ADDR,
+ .flags = I2C_M_RD,
+ .len= len,
+ .buf= buf,
+ }
+ };
+
+ /*
+* Avoid sending the segment addr to not upset non-compliant
+* DDC monitors.
+*/
+ ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
+
+ if (ret == -ENXIO) {
+ DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
+ adapter->name);
+ break;
+ }
+ if (ret == xfers || --retries == 0)
+ break;
+
+ udelay(100);
+ }
+
+ return ret == xfers ? 0 : -1;
+}
static int sii902x_get_modes(struct drm_connector *connector)
{
struct sii902x *sii902x = connector_to_sii902x(connector);
@@ -168,8 +224,20 @@ static int sii902x_get_modes(struct drm_connector
*connector)
if (ret)
return ret;
- edid = drm_get_edid(connector, sii902x->i2c->adapter);
+ /* drm_get_edid() runs two I2C transfers. The sii902x seems
+* to have problem with the 2nd I2C start. A wait seems needed.
+* So, we don't perform use drm_get_edid(). We don't perform
+* the first "probe" transfer, and we use a custom block read
+* function that, in case the trasfer is split, does introduce
+* a delay.
+*/
+ edid = drm_do_get_edid(connector, sii902x_do_probe_ddc_edid,
+ sii902x->i2c->adapter);
+ if (!edid)
+ return num;
+
drm_mode_connector_update_edid_property(connector, edid);
+
if (edid) {
num = drm_add_edid_modes(connector, edid);
kfree(edid);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/7] arm64: dts: exynos: configure TV path clocks for Ultra HD modes
Ultra HD modes requires clock ticking at increased rate.
Signed-off-by: Andrzej Hajda
---
v2: long lines wrapped
v3: moved assigned clocks to cmu_disp node in tm2-common
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index cd8847b..5f1e172 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -217,6 +217,18 @@
assigned-clock-parents = <&cmu_top CLK_FOUT_AUD_PLL>;
};
+&cmu_disp {
+ assigned-clocks = <&cmu_mif CLK_MOUT_SCLK_DECON_TV_ECLK_A>,
+ <&cmu_mif CLK_DIV_SCLK_DECON_TV_ECLK>,
+ <&cmu_disp CLK_MOUT_SCLK_DECON_TV_ECLK_USER>,
+ <&cmu_disp CLK_MOUT_SCLK_DECON_TV_ECLK>;
+ assigned-clock-parents = <&cmu_mif CLK_MOUT_BUS_PLL_DIV2>,
+<0>,
+<&cmu_mif CLK_SCLK_DECON_TV_ECLK_DISP>,
+<&cmu_disp CLK_MOUT_SCLK_DECON_TV_ECLK_USER>;
+ assigned-clock-rates = <0>, <4>;
+};
+
&cmu_fsys {
assigned-clocks = <&cmu_top CLK_MOUT_SCLK_USBDRD30>,
<&cmu_top CLK_MOUT_SCLK_USBHOST30>,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Show leaked connectors upon unload
On Thu, Jan 19, 2017 at 03:17:36PM +0100, Maarten Lankhorst wrote:
> Op 19-01-17 om 10:05 schreef Chris Wilson:
> > After warning that the connector list is not empty on device
> > unregistration (i.e. module unload) also print out which connectors are
> > still hanging around to aide finding the leak.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/drm_mode_config.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > b/drivers/gpu/drm/drm_mode_config.c
> > index ed1ee5a44a7b..884cc4d26fb5 100644
> > --- a/drivers/gpu/drm/drm_mode_config.c
> > +++ b/drivers/gpu/drm/drm_mode_config.c
> > @@ -421,7 +421,12 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> > drm_connector_unreference(connector);
> > }
> > drm_connector_list_iter_put(&conn_iter);
> > - WARN_ON(!list_empty(&dev->mode_config.connector_list));
> > + if (WARN_ON(!list_empty(&dev->mode_config.connector_list))) {
> > + drm_connector_list_iter_get(dev, &conn_iter);
> > + drm_for_each_connector_iter(connector, &conn_iter)
> > + DRM_ERROR("connector %s leaked!\n", connector->name);
> > + drm_connector_list_iter_put(&conn_iter);
> > + }
> >
> > list_for_each_entry_safe(property, pt, &dev->mode_config.property_list,
> > head) {
>
> Bikeshed perhaps, but maybe change to [CONNECTOR:%d:%s] connector leaked on
> cleanup?
This patch isn't in my tree, so if a drm-misc maintainer would pick it
and make the minor change, please do so :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave, Just one bugfix from Gustavo, but the pull request script is confused since you didn't update your drm-fixes branch. Cheers, Daniel The following changes since commit 9afe69d5a9495f8b023017e4c328fa717e00f092: Merge tag 'drm-misc-fixes-2017-01-09' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-01-10 08:18:53 +1000) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-01-23 for you to fetch changes up to 7e9081c5aac73b8a0bc22e0b3e7a12c3e9cf5256: drm/fence: fix memory overwrite when setting out_fence fd (2017-01-16 20:00:54 -0200) Daniel Vetter (1): drm/probe-helpers: Drop locking from poll_enable Gustavo Padovan (1): drm/fence: fix memory overwrite when setting out_fence fd Peter Ujfalusi (1): drm: Schedule the output_poll_work with 1s delay if we have delayed event Takashi Iwai (1): drm: Fix broken VT switch with video=1366x768 option drivers/gpu/drm/drm_atomic.c | 12 +++ drivers/gpu/drm/drm_modes.c | 7 drivers/gpu/drm/drm_probe_helper.c | 63 ++-- drivers/gpu/drm/i915/intel_hotplug.c | 4 +-- include/drm/drm_atomic.h | 2 +- include/drm/drm_crtc_helper.h| 1 - include/drm/drm_mode_config.h| 2 +- 7 files changed, 48 insertions(+), 43 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm: Show leaked connectors upon unload
On Mon, Jan 23, 2017 at 10:06:07AM +, Chris Wilson wrote:
> On Thu, Jan 19, 2017 at 03:17:36PM +0100, Maarten Lankhorst wrote:
> > Op 19-01-17 om 10:05 schreef Chris Wilson:
> > > After warning that the connector list is not empty on device
> > > unregistration (i.e. module unload) also print out which connectors are
> > > still hanging around to aide finding the leak.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/drm_mode_config.c | 7 ++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > b/drivers/gpu/drm/drm_mode_config.c
> > > index ed1ee5a44a7b..884cc4d26fb5 100644
> > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > @@ -421,7 +421,12 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> > > drm_connector_unreference(connector);
> > > }
> > > drm_connector_list_iter_put(&conn_iter);
> > > - WARN_ON(!list_empty(&dev->mode_config.connector_list));
> > > + if (WARN_ON(!list_empty(&dev->mode_config.connector_list))) {
> > > + drm_connector_list_iter_get(dev, &conn_iter);
> > > + drm_for_each_connector_iter(connector, &conn_iter)
> > > + DRM_ERROR("connector %s leaked!\n", connector->name);
> > > + drm_connector_list_iter_put(&conn_iter);
> > > + }
> > >
> > > list_for_each_entry_safe(property, pt, &dev->mode_config.property_list,
> > >head) {
> >
> > Bikeshed perhaps, but maybe change to [CONNECTOR:%d:%s] connector leaked on
> > cleanup?
>
> This patch isn't in my tree, so if a drm-misc maintainer would pick it
> and make the minor change, please do so :)
Hm, drm-misc maintainer picked it, but failed to do the minor bikeshed :(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 4/4] s5p-cec: add hpd-notifier support, move out of staging
On 01/04/2017 09:44 AM, Andrzej Hajda wrote: > On 03.01.2017 09:11, Hans Verkuil wrote: >> On 01/03/2017 09:00 AM, Andrzej Hajda wrote: >>> Is there a reason to split registration into two steps? >>> Wouldn't be better to integrate hpd_notifier_get into >>> cec_register_hpd_notifier. >> One problem is that hpd_notifier_get can fail, whereas >> cec_register_hpd_notifier can't. >> And I rather not have to register a CEC device only to unregister it again >> if the >> hpd_notifier_get would fail. > > hpd_notifier_get can fail only due to lack of memory for about 150 bytes > so if it happens whole system will probably fail anyway :) > > >> >> Another reason is that this keeps the responsibility of the hpd_notifier >> life-time >> handling in the driver instead of hiding it in the CEC framework, which is >> IMHO >> unexpected. > > Notifier is used only by CEC framework, so IMHO it would be desirable to > put CEC specific things into CEC framework. The CEC framework is just the first that needs it. But especially audio drivers also want to use it. It was designed to help out both subsystems since both need the EDID/ELD. Regards, Hans > Drivers duty is just to find notifier device. > Leaving it as is will just put little more burden on drivers, so this is > not big deal, do as you wish :) > > Regards > Andrzej > >> >> I think I want to keep this as-is, at least for now. >> >> Regards, >> >> Hans >> >> >> >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/color: un-inline drm_color_lut_extract()
On Mon, Jan 23, 2017 at 11:42:59AM +0200, Jani Nikula wrote:
> The function is not that big, but it's also not used for anything
> performance critical. Make it a normal function.
>
> As a side effect, this apparently makes sparse smarter about what it's
> doing, and gets rid of the warning:
>
> ./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295) for
> type unsigned long
> ./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
> constant value (8000 becomes 0)
Not really clear to me what's going on, but if it helps ...
> Cc: Lionel Landwerlin
> Signed-off-by: Jani Nikula
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 24
> include/drm/drm_color_mgmt.h | 27 ++-
> 2 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 789b4c65cd69..5618f60c7690 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -88,6 +88,30 @@
> */
>
> /**
> + * drm_color_lut_extract - clamp&round LUT entries
> + * @user_input: input value
> + * @bit_precision: number of bits the hw LUT supports
> + *
> + * Extract a degamma/gamma LUT value provided by user (in the form of
> + * &drm_color_lut entries) and round it to the precision supported by the
> + * hardware.
> + */
> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
> +{
> + uint32_t val = user_input;
> + uint32_t max = 0x >> (16 - bit_precision);
> +
> + /* Round only if we're not using full precision. */
> + if (bit_precision < 16) {
> + val += 1UL << (16 - bit_precision - 1);
> + val >>= 16 - bit_precision;
> + }
> +
> + return clamp_val(val, 0, max);
> +}
> +EXPORT_SYMBOL(drm_color_lut_extract);
> +
> +/**
> * drm_crtc_enable_color_mgmt - enable color management properties
> * @crtc: DRM CRTC
> * @degamma_lut_size: the size of the degamma lut (before CSC)
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index c767238ac9d5..bce4a532836d 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -25,6 +25,8 @@
>
> #include
>
> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
> +
> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> uint degamma_lut_size,
> bool has_ctm,
> @@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>int gamma_size);
>
> -/**
> - * drm_color_lut_extract - clamp&round LUT entries
> - * @user_input: input value
> - * @bit_precision: number of bits the hw LUT supports
> - *
> - * Extract a degamma/gamma LUT value provided by user (in the form of
> - * &drm_color_lut entries) and round it to the precision supported by the
> - * hardware.
> - */
> -static inline uint32_t drm_color_lut_extract(uint32_t user_input,
> - uint32_t bit_precision)
> -{
> - uint32_t val = user_input;
> - uint32_t max = 0x >> (16 - bit_precision);
> -
> - /* Round only if we're not using full precision. */
> - if (bit_precision < 16) {
> - val += 1UL << (16 - bit_precision - 1);
> - val >>= 16 - bit_precision;
> - }
> -
> - return clamp_val(val, 0, max);
> -}
> -
> -
> #endif
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: sii902x: fix get edid may fail
Hi Andrea,
On Mon, 23 Jan 2017 11:00:02 +0100
Andrea Merello wrote:
> From: Andrea Merello
>
> The standard DRM function to get the edid from the i2c bus performs
> (at least) two transfers.
>
> By experiments it seems that the sii9022a have problems with the
> 2nd I2C start, at least unless a wait is introduced detween the
^ between
> two transfers.
>
> So we perform one single I2C transfer, and if the transfer must be
> split, then we introduce a delay.
That's not exactly what this patch does: you're introducing a delay
between each retry. So, if the transceiver really requires a delay
between each transfer, you'll have to retry at least once on the 2nd
transfer.
I guess a better solution would be to add a delay even in case of
success, or maybe modify drm_do_get_edid() to optionally wait for a
specified time between each transfer.
BTW, sii902x_do_probe_ddc_edid() and drm_do_probe_ddc_edid() are almost
identical (except for the extra delay()), so maybe we should export
drm_do_probe_ddc_edid() and add an extra delay_us to it.
>
> Signed-off-by: Andrea Merello
> Cc: Andrea Merello
> Cc: Boris Brezillon
> Cc: Archit Taneja
> Cc: David Airlie
> ---
> drivers/gpu/drm/bridge/sii902x.c | 70
> +++-
> 1 file changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> b/drivers/gpu/drm/bridge/sii902x.c
> index 9126d03..042d7e2 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -133,6 +133,62 @@ static const struct drm_connector_funcs
> sii902x_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> +#define DDC_SEGMENT_ADDR 0x30
> +static int sii902x_do_probe_ddc_edid(void *data, u8 *buf,
> + unsigned int block, size_t len)
> +{
> + struct i2c_adapter *adapter = data;
> + unsigned char start = block * EDID_LENGTH;
> + unsigned char segment = block >> 1;
> + unsigned char xfers = segment ? 3 : 2;
> + int ret, retries = 5;
> +
> + /*
> + * The core I2C driver will automatically retry the transfer if the
> + * adapter reports EAGAIN. However, we find that bit-banging transfers
> + * are susceptible to errors under a heavily loaded machine and
> + * generate spurious NAKs and timeouts. Retrying the transfer
> + * of the individual block a few times seems to overcome this.
> + */
> + while (1) {
> + struct i2c_msg msgs[] = {
> + {
> + .addr = DDC_SEGMENT_ADDR,
> + .flags = 0,
> + .len= 1,
> + .buf= &segment,
> + }, {
> + .addr = DDC_ADDR,
> + .flags = 0,
> + .len= 1,
> + .buf= &start,
> + }, {
> + .addr = DDC_ADDR,
> + .flags = I2C_M_RD,
> + .len= len,
> + .buf= buf,
> + }
> + };
> +
> + /*
> + * Avoid sending the segment addr to not upset non-compliant
> + * DDC monitors.
> + */
> + ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
> +
> + if (ret == -ENXIO) {
> + DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
> + adapter->name);
> + break;
> + }
> + if (ret == xfers || --retries == 0)
> + break;
> +
> + udelay(100);
> + }
> +
> + return ret == xfers ? 0 : -1;
> +}
Missing empty line here.
> static int sii902x_get_modes(struct drm_connector *connector)
> {
> struct sii902x *sii902x = connector_to_sii902x(connector);
> @@ -168,8 +224,20 @@ static int sii902x_get_modes(struct drm_connector
> *connector)
> if (ret)
> return ret;
>
> - edid = drm_get_edid(connector, sii902x->i2c->adapter);
> + /* drm_get_edid() runs two I2C transfers. The sii902x seems
Please use kernel comment style:
/*
* ...
> + * to have problem with the 2nd I2C start. A wait seems needed.
> + * So, we don't perform use drm_get_edid(). We don't perform
> + * the first "probe" transfer, and we use a custom block read
> + * function that, in case the trasfer is split, does introduce
> + * a delay.
> + */
> + edid = drm_do_get_edid(connector, sii902x_do_probe_ddc_edid,
> +sii902x->i2c->adapter);
> + if (!edid)
> + return num;
> +
drm_get_edid() calls drm_get_displayid() just after drm_do_get_edid().
Are y
[PATCHv3 3/5] cec: integrate HPD notifier support
From: Hans Verkuil
Support the HPD notifier framework, simplifying drivers that
depend on this.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
drivers/media/cec/cec-core.c | 50
include/media/cec.h | 15 +
2 files changed, 65 insertions(+)
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index aca3ab83a8a1..dd2c4a17aff5 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -195,6 +195,52 @@ static void cec_devnode_unregister(struct cec_devnode
*devnode)
put_device(&devnode->dev);
}
+#ifdef CONFIG_HPD_NOTIFIER
+static u16 parse_hdmi_addr(const struct edid *edid)
+{
+ if (!edid || edid->extensions == 0)
+ return CEC_PHYS_ADDR_INVALID;
+
+ return cec_get_edid_phys_addr((u8 *)edid,
+ EDID_LENGTH * (edid->extensions + 1), NULL);
+}
+
+static int cec_hpd_notify(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+ struct cec_adapter *adap = container_of(nb, struct cec_adapter, nb);
+ struct hpd_notifier *n = data;
+ unsigned int phys;
+
+ dprintk(1, "event %lu\n", event);
+
+ switch (event) {
+ case HPD_DISCONNECTED:
+ cec_s_phys_addr(adap, CEC_PHYS_ADDR_INVALID, false);
+ break;
+
+ case HPD_NEW_EDID:
+ phys = parse_hdmi_addr(n->edid);
+ cec_s_phys_addr(adap, phys, false);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+void cec_register_hpd_notifier(struct cec_adapter *adap,
+ struct hpd_notifier *notifier)
+{
+ if (WARN_ON(!adap->devnode.registered))
+ return;
+
+ adap->nb.notifier_call = cec_hpd_notify;
+ adap->notifier = notifier;
+ hpd_notifier_register(adap->notifier, &adap->nb);
+}
+EXPORT_SYMBOL_GPL(cec_register_hpd_notifier);
+#endif
+
struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
void *priv, const char *name, u32 caps,
u8 available_las)
@@ -344,6 +390,10 @@ void cec_unregister_adapter(struct cec_adapter *adap)
adap->rc = NULL;
#endif
debugfs_remove_recursive(adap->cec_dir);
+#ifdef CONFIG_HPD_NOTIFIER
+ if (adap->notifier)
+ hpd_notifier_unregister(adap->notifier, &adap->nb);
+#endif
cec_devnode_unregister(&adap->devnode);
}
EXPORT_SYMBOL_GPL(cec_unregister_adapter);
diff --git a/include/media/cec.h b/include/media/cec.h
index 96a0aa770d61..f87a07ee36b3 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -28,6 +28,11 @@
#include
#include
#include
+#ifdef CONFIG_HPD_NOTIFIER
+#include
+#include
+#include
+#endif
#include
#include
@@ -173,6 +178,11 @@ struct cec_adapter {
bool passthrough;
struct cec_log_addrs log_addrs;
+#ifdef CONFIG_HPD_NOTIFIER
+ struct hpd_notifier *notifier;
+ struct notifier_block nb;
+#endif
+
struct dentry *cec_dir;
struct dentry *status_file;
@@ -213,6 +223,11 @@ void cec_transmit_done(struct cec_adapter *adap, u8
status, u8 arb_lost_cnt,
u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);
void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
+#ifdef CONFIG_HPD_NOTIFIER
+void cec_register_hpd_notifier(struct cec_adapter *adap,
+ struct hpd_notifier *notifier);
+#endif
+
#else
static inline int cec_register_adapter(struct cec_adapter *adap,
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 0/5] video/exynos/cec: add HPD state notifier & use in s5p-cec
From: Hans Verkuil
This patch series adds the hotplug detect notifier code, based on Russell's
code:
https://patchwork.kernel.org/patch/9277043/
It adds support for it to the exynos_hdmi drm driver, adds support for
it to the CEC framework and finally adds support to the s5p-cec driver,
which now can be moved out of staging.
Tested with my Odroid U3 exynos4 devboard.
Comments are welcome. I'd like to get this in for the 4.11 kernel as
this is a missing piece needed to integrate CEC drivers.
Changes since v2:
- Split off the dts changes of the s5p-cec patch into a separate patch
- Renamed HPD_NOTIFIERS to HPD_NOTIFIER to be consistent with the name
of the source.
Changes since v1:
Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is
not HDMI specific, but is interesting for any video source that has to
deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ).
Only the use with CEC adapters is HDMI specific, but the HPD notifier
is more generic.
Regards,
Hans
Hans Verkuil (5):
video: add hotplug detect notifier support
exynos_hdmi: add HPD notifier support
cec: integrate HPD notifier support
exynos4.dtsi: add HDMI controller phandle
s5p-cec: add hpd-notifier support, move out of staging
.../devicetree/bindings/media/s5p-cec.txt | 2 +
arch/arm/boot/dts/exynos4.dtsi | 1 +
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 23 +++-
drivers/media/cec/cec-core.c | 50
drivers/media/platform/Kconfig | 18 +++
drivers/media/platform/Makefile| 1 +
.../media => media/platform}/s5p-cec/Makefile | 0
.../platform}/s5p-cec/exynos_hdmi_cec.h| 0
.../platform}/s5p-cec/exynos_hdmi_cecctrl.c| 0
.../media => media/platform}/s5p-cec/regs-cec.h| 0
.../media => media/platform}/s5p-cec/s5p_cec.c | 35 +-
.../media => media/platform}/s5p-cec/s5p_cec.h | 3 +
drivers/staging/media/Kconfig | 2 -
drivers/staging/media/Makefile | 1 -
drivers/staging/media/s5p-cec/Kconfig | 9 --
drivers/staging/media/s5p-cec/TODO | 7 --
drivers/video/Kconfig | 3 +
drivers/video/Makefile | 1 +
drivers/video/hpd-notifier.c | 134 +
include/linux/hpd-notifier.h | 109 +
include/media/cec.h| 15 +++
22 files changed, 388 insertions(+), 27 deletions(-)
rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
delete mode 100644 drivers/staging/media/s5p-cec/TODO
create mode 100644 drivers/video/hpd-notifier.c
create mode 100644 include/linux/hpd-notifier.h
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 1/5] video: add hotplug detect notifier support
From: Hans Verkuil
Add support for video hotplug detect and EDID/ELD notifiers, which is used
to convey information from video drivers to their CEC and audio counterparts.
Based on an earlier version from Russell King:
https://patchwork.kernel.org/patch/9277043/
The hpd_notifier is a reference counted object containing the HPD/EDID/ELD state
of a video device.
When a new notifier is registered the current state will be reported to
that notifier at registration time.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
drivers/video/Kconfig| 3 +
drivers/video/Makefile | 1 +
drivers/video/hpd-notifier.c | 134 +++
include/linux/hpd-notifier.h | 109 +++
4 files changed, 247 insertions(+)
create mode 100644 drivers/video/hpd-notifier.c
create mode 100644 include/linux/hpd-notifier.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af999893..a3a58d8481e9 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
config HDMI
bool
+config HPD_NOTIFIER
+ bool
+
if VT
source "drivers/video/console/Kconfig"
endif
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9ad3c17d6456..2697ae5c4166 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_VGASTATE)+= vgastate.o
obj-$(CONFIG_HDMI)+= hdmi.o
+obj-$(CONFIG_HPD_NOTIFIER)+= hpd-notifier.o
obj-$(CONFIG_VT) += console/
obj-$(CONFIG_LOGO) += logo/
diff --git a/drivers/video/hpd-notifier.c b/drivers/video/hpd-notifier.c
new file mode 100644
index ..971e823ead00
--- /dev/null
+++ b/drivers/video/hpd-notifier.c
@@ -0,0 +1,134 @@
+#include
+#include
+#include
+#include
+#include
+
+static LIST_HEAD(hpd_notifiers);
+static DEFINE_MUTEX(hpd_notifiers_lock);
+
+struct hpd_notifier *hpd_notifier_get(struct device *dev)
+{
+ struct hpd_notifier *n;
+
+ mutex_lock(&hpd_notifiers_lock);
+ list_for_each_entry(n, &hpd_notifiers, head) {
+ if (n->dev == dev) {
+ mutex_unlock(&hpd_notifiers_lock);
+ kref_get(&n->kref);
+ return n;
+ }
+ }
+ n = kzalloc(sizeof(*n), GFP_KERNEL);
+ if (!n)
+ goto unlock;
+ n->dev = dev;
+ mutex_init(&n->lock);
+ BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
+ kref_init(&n->kref);
+ list_add_tail(&n->head, &hpd_notifiers);
+unlock:
+ mutex_unlock(&hpd_notifiers_lock);
+ return n;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_get);
+
+static void hpd_notifier_release(struct kref *kref)
+{
+ struct hpd_notifier *n =
+ container_of(kref, struct hpd_notifier, kref);
+
+ list_del(&n->head);
+ kfree(n->edid);
+ kfree(n);
+}
+
+void hpd_notifier_put(struct hpd_notifier *n)
+{
+ mutex_lock(&hpd_notifiers_lock);
+ kref_put(&n->kref, hpd_notifier_release);
+ mutex_unlock(&hpd_notifiers_lock);
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_put);
+
+int hpd_notifier_register(struct hpd_notifier *n, struct notifier_block *nb)
+{
+ int ret = blocking_notifier_chain_register(&n->notifiers, nb);
+
+ if (ret)
+ return ret;
+ kref_get(&n->kref);
+ mutex_lock(&n->lock);
+ if (n->connected) {
+ blocking_notifier_call_chain(&n->notifiers, HPD_CONNECTED, n);
+ if (n->edid_size)
+ blocking_notifier_call_chain(&n->notifiers,
HPD_NEW_EDID, n);
+ if (n->has_eld)
+ blocking_notifier_call_chain(&n->notifiers,
HPD_NEW_ELD, n);
+ }
+ mutex_unlock(&n->lock);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_register);
+
+int hpd_notifier_unregister(struct hpd_notifier *n, struct notifier_block *nb)
+{
+ int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
+
+ if (ret == 0)
+ hpd_notifier_put(n);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_unregister);
+
+void hpd_event_connect(struct hpd_notifier *n)
+{
+ mutex_lock(&n->lock);
+ n->connected = true;
+ blocking_notifier_call_chain(&n->notifiers, HPD_CONNECTED, n);
+ mutex_unlock(&n->lock);
+}
+EXPORT_SYMBOL_GPL(hpd_event_connect);
+
+void hpd_event_disconnect(struct hpd_notifier *n)
+{
+ mutex_lock(&n->lock);
+ n->connected = false;
+ n->has_eld = false;
+ n->edid_size = 0;
+ blocking_notifier_call_chain(&n->notifiers, HPD_DISCONNECTED, n);
+ mutex_unlock(&n->lock);
+}
+EXPORT_SYMBOL_GPL(hpd_event_disconnect);
+
+int hpd_event_new_edid(struct hpd_notifier *n, const void *edid, size_t size)
+{
+ mutex_lock(&n->lock);
+ if (n->edid_allocated_size < size) {
+ void *p = kmalloc(size, GFP_KERNEL);
+
+
[PATCHv3 2/5] exynos_hdmi: add HPD notifier support
From: Hans Verkuil
Implement the HPD notifier support to allow CEC drivers to
be informed when there is a new EDID and when a connect or
disconnect happens.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 23 ---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index d706ca4e2f02..50309409d450 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -77,6 +77,7 @@ config DRM_EXYNOS_DP
config DRM_EXYNOS_HDMI
bool "HDMI"
depends on DRM_EXYNOS_MIXER || DRM_EXYNOS5433_DECON
+ select HPD_NOTIFIER
help
Choose this option if you want to use Exynos HDMI for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5ed8b1effe71..8d48a0a21565 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -118,6 +119,7 @@ struct hdmi_context {
booldvi_mode;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
+ struct hpd_notifier *notifier;
const struct hdmi_driver_data *drv_data;
void __iomem*regs;
@@ -807,9 +809,12 @@ static enum drm_connector_status hdmi_detect(struct
drm_connector *connector,
{
struct hdmi_context *hdata = connector_to_hdmi(connector);
- if (gpiod_get_value(hdata->hpd_gpio))
+ if (gpiod_get_value(hdata->hpd_gpio)) {
+ hpd_event_connect(hdata->notifier);
return connector_status_connected;
+ }
+ hpd_event_disconnect(hdata->notifier);
return connector_status_disconnected;
}
@@ -848,6 +853,8 @@ static int hdmi_get_modes(struct drm_connector *connector)
edid->width_cm, edid->height_cm);
drm_mode_connector_update_edid_property(connector, edid);
+ hpd_event_new_edid(hdata->notifier, edid,
+ EDID_LENGTH * (1 + edid->extensions));
ret = drm_add_edid_modes(connector, edid);
@@ -1483,6 +1490,7 @@ static void hdmi_disable(struct drm_encoder *encoder)
if (funcs && funcs->disable)
(*funcs->disable)(crtc);
+ hpd_event_disconnect(hdata->notifier);
cancel_delayed_work(&hdata->hotplug_work);
hdmiphy_disable(hdata);
@@ -1832,15 +1840,22 @@ static int hdmi_probe(struct platform_device *pdev)
}
}
+ hdata->notifier = hpd_notifier_get(&pdev->dev);
+ if (hdata->notifier == NULL) {
+ ret = -ENOMEM;
+ goto err_hdmiphy;
+ }
+
pm_runtime_enable(dev);
ret = component_add(&pdev->dev, &hdmi_component_ops);
if (ret)
- goto err_disable_pm_runtime;
+ goto err_notifier_put;
return ret;
-err_disable_pm_runtime:
+err_notifier_put:
+ hpd_notifier_put(hdata->notifier);
pm_runtime_disable(dev);
err_hdmiphy:
@@ -1859,9 +1874,11 @@ static int hdmi_remove(struct platform_device *pdev)
struct hdmi_context *hdata = platform_get_drvdata(pdev);
cancel_delayed_work_sync(&hdata->hotplug_work);
+ hpd_event_disconnect(hdata->notifier);
component_del(&pdev->dev, &hdmi_component_ops);
+ hpd_notifier_put(hdata->notifier);
pm_runtime_disable(&pdev->dev);
if (!IS_ERR(hdata->reg_hdmi_en))
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 4/5] exynos4.dtsi: add HDMI controller phandle
From: Hans Verkuil
Update the bindings documenting the new hdmi phandle and
update exynos4.dtsi accordingly. This phandle is needed by the
s5p-cec driver to initialize the HPD notifier framework.
Tested with my Odroid U3.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
CC: linux-samsung-...@vger.kernel.org
---
Documentation/devicetree/bindings/media/s5p-cec.txt | 2 ++
arch/arm/boot/dts/exynos4.dtsi | 1 +
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt
b/Documentation/devicetree/bindings/media/s5p-cec.txt
index 925ab4d72eaa..710fc005150c 100644
--- a/Documentation/devicetree/bindings/media/s5p-cec.txt
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -15,6 +15,7 @@ Required properties:
- clock-names : from common clock binding: must contain "hdmicec",
corresponding to entry in the clocks property.
- samsung,syscon-phandle - phandle to the PMU system controller
+ - samsung,hdmi-phandle - phandle to the HDMI controller
Example:
@@ -25,6 +26,7 @@ hdmicec: cec@100B {
clocks = <&clock CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <&pmu_system_controller>;
+ samsung,hdmi-phandle = <&hdmi>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_cec>;
status = "okay";
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index c64737baa45e..51dfcbb51b6b 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -762,6 +762,7 @@
clocks = <&clock CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <&pmu_system_controller>;
+ samsung,hdmi-phandle = <&hdmi>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_cec>;
status = "disabled";
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 5/5] s5p-cec: add hpd-notifier support, move out of staging
From: Hans Verkuil
By using the HPD notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.
Update the bindings documenting the new hdmi phandle and
update exynos4.dtsi accordingly.
Tested with my Odroid U3.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
CC: linux-samsung-...@vger.kernel.org
---
drivers/media/platform/Kconfig | 18 +++
drivers/media/platform/Makefile| 1 +
.../media => media/platform}/s5p-cec/Makefile | 0
.../platform}/s5p-cec/exynos_hdmi_cec.h| 0
.../platform}/s5p-cec/exynos_hdmi_cecctrl.c| 0
.../media => media/platform}/s5p-cec/regs-cec.h| 0
.../media => media/platform}/s5p-cec/s5p_cec.c | 35 ++
.../media => media/platform}/s5p-cec/s5p_cec.h | 3 ++
drivers/staging/media/Kconfig | 2 --
drivers/staging/media/Makefile | 1 -
drivers/staging/media/s5p-cec/Kconfig | 9 --
drivers/staging/media/s5p-cec/TODO | 7 -
12 files changed, 52 insertions(+), 24 deletions(-)
rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
delete mode 100644 drivers/staging/media/s5p-cec/TODO
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421e392d..0d7acf10b32a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -392,6 +392,24 @@ config VIDEO_TI_SC
config VIDEO_TI_CSC
tristate
+menuconfig V4L_CEC_DRIVERS
+ bool "Platform HDMI CEC drivers"
+ depends on MEDIA_CEC_SUPPORT
+
+if V4L_CEC_DRIVERS
+
+config VIDEO_SAMSUNG_S5P_CEC
+ tristate "Samsung S5P CEC driver"
+ depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (PLAT_S5P || ARCH_EXYNOS
|| COMPILE_TEST)
+ select HPD_NOTIFIER
+ ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
+endif #V4L_CEC_DRIVERS
+
menuconfig V4L_TEST_DRIVERS
bool "Media test drivers"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 5b3cb271d2b8..ad3bf22bfeae 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
obj-$(CONFIG_VIDEO_STI_BDISP) += sti/bdisp/
diff --git a/drivers/staging/media/s5p-cec/Makefile
b/drivers/media/platform/s5p-cec/Makefile
similarity index 100%
rename from drivers/staging/media/s5p-cec/Makefile
rename to drivers/media/platform/s5p-cec/Makefile
diff --git a/drivers/staging/media/s5p-cec/exynos_hdmi_cec.h
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
similarity index 100%
rename from drivers/staging/media/s5p-cec/exynos_hdmi_cec.h
rename to drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
diff --git a/drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c
b/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
similarity index 100%
rename from drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c
rename to drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
diff --git a/drivers/staging/media/s5p-cec/regs-cec.h
b/drivers/media/platform/s5p-cec/regs-cec.h
similarity index 100%
rename from drivers/staging/media/s5p-cec/regs-cec.h
rename to drivers/media/platform/s5p-cec/regs-cec.h
diff --git a/drivers/staging/media/s5p-cec/s5p_cec.c
b/drivers/media/platform/s5p-cec/s5p_cec.c
similarity index 89%
rename from drivers/staging/media/s5p-cec/s5p_cec.c
rename to drivers/media/platform/s5p-cec/s5p_cec.c
index 2a07968b5ac6..2014f792eceb 100644
--- a/drivers/staging/media/s5p-cec/s5p_cec.c
+++ b/drivers/media/platform/s5p-cec/s5p_cec.c
@@ -14,15 +14,18 @@
*/
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include "exynos_hdmi_cec.h"
@@ -167,10 +170,22 @@ static const struct cec_adap_ops s5p_cec_adap_ops = {
static int s5p_cec_probe(struct platform
Re: [Intel-gfx] [PATCH] drm: Show leaked connectors upon unload
On Mon, Jan 23, 2017 at 11:12:31AM +0100, Daniel Vetter wrote:
> On Mon, Jan 23, 2017 at 10:06:07AM +, Chris Wilson wrote:
> > On Thu, Jan 19, 2017 at 03:17:36PM +0100, Maarten Lankhorst wrote:
> > > Op 19-01-17 om 10:05 schreef Chris Wilson:
> > > > After warning that the connector list is not empty on device
> > > > unregistration (i.e. module unload) also print out which connectors are
> > > > still hanging around to aide finding the leak.
> > > >
> > > > Signed-off-by: Chris Wilson
> > > > ---
> > > > drivers/gpu/drm/drm_mode_config.c | 7 ++-
> > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > > b/drivers/gpu/drm/drm_mode_config.c
> > > > index ed1ee5a44a7b..884cc4d26fb5 100644
> > > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > > @@ -421,7 +421,12 @@ void drm_mode_config_cleanup(struct drm_device
> > > > *dev)
> > > > drm_connector_unreference(connector);
> > > > }
> > > > drm_connector_list_iter_put(&conn_iter);
> > > > - WARN_ON(!list_empty(&dev->mode_config.connector_list));
> > > > + if (WARN_ON(!list_empty(&dev->mode_config.connector_list))) {
> > > > + drm_connector_list_iter_get(dev, &conn_iter);
> > > > + drm_for_each_connector_iter(connector, &conn_iter)
> > > > + DRM_ERROR("connector %s leaked!\n",
> > > > connector->name);
> > > > + drm_connector_list_iter_put(&conn_iter);
> > > > + }
> > > >
> > > > list_for_each_entry_safe(property, pt,
> > > > &dev->mode_config.property_list,
> > > > head) {
> > >
> > > Bikeshed perhaps, but maybe change to [CONNECTOR:%d:%s] connector leaked
> > > on cleanup?
> >
> > This patch isn't in my tree, so if a drm-misc maintainer would pick it
> > and make the minor change, please do so :)
>
> Hm, drm-misc maintainer picked it, but failed to do the minor bikeshed :(
Ah, I was worried I had actually squashed it into a random patch and was
starting to go mad.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/24] drm/bridge/sii8620: add continuations to messages
On 23.01.2017 09:31, Archit Taneja wrote:
>
> On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
>> Due to asynchronous nature of MHL flow of execution is dispersed. Logical
>> continuation of some actions happens after response of peer, i.e in interrupt
>> handler. To simplify coding continuation mechanism has been added - it is now
>> possible to provide continuation callback, which will be called after peer
>> responds to given action.
> Could you wrap this to 75 chars?
OK
>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/bridge/sil-sii8620.c | 20
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>> index 75867c0..cde0074 100644
>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>> @@ -78,12 +78,15 @@ struct sii8620_mt_msg;
>> typedef void (*sii8620_mt_msg_cb)(struct sii8620 *ctx,
>>struct sii8620_mt_msg *msg);
>>
>> +typedef void (*sii8620_cb)(struct sii8620 *ctx, int ret);
>> +
>> struct sii8620_mt_msg {
>> struct list_head node;
>> u8 reg[4];
>> u8 ret;
>> sii8620_mt_msg_cb send;
>> sii8620_mt_msg_cb recv;
>> +sii8620_cb continuation;
>> };
>>
>> static const u8 sii8620_i2c_page[] = {
>> @@ -258,6 +261,8 @@ static void sii8620_mt_work(struct sii8620 *ctx)
>> node);
>> if (msg->recv)
>> msg->recv(ctx, msg);
>> +if (msg->continuation)
>> +msg->continuation(ctx, msg->ret);
> I was wondering if instead of executing the continuation via a callback,
> would it make sense to insert them as a new message instead?
>
> I don't have the complete context of this, so feel free to ignore the
> suggestion
> if doesn't make sense.
My assumption was that continuation should be tied to the message it was
attached to - ie it should be called after response for the message and
it should be called with the result of the response.
If we assume messages are fully serialized (as it is now) it could be
done as you suggested, but I prefer to leave possibility to de-serialize
message queue in the future.
Regards
Andrzej
>
> Thanks,
> Archit
>
>> list_del(&msg->node);
>> kfree(msg);
>> }
>> @@ -310,6 +315,21 @@ static struct sii8620_mt_msg *sii8620_mt_msg_new(struct
>> sii8620 *ctx)
>> return msg;
>> }
>>
>> +static void sii8620_mt_set_cont(struct sii8620 *ctx, sii8620_cb cont)
>> +{
>> +struct sii8620_mt_msg *msg;
>> +
>> +if (ctx->error)
>> +return;
>> +
>> +if (list_empty(&ctx->mt_queue)) {
>> +ctx->error = -EINVAL;
>> +return;
>> +}
>> +msg = list_last_entry(&ctx->mt_queue, struct sii8620_mt_msg, node);
>> +msg->continuation = cont;
>> +}
>> +
>> static void sii8620_mt_msc_cmd(struct sii8620 *ctx, u8 cmd, u8 arg1, u8
>> arg2)
>> {
>> struct sii8620_mt_msg *msg = sii8620_mt_msg_new(ctx);
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT
On Fri, 20 Jan 2017, Hans de Goede wrote:
> Hi,
>
> On 31-12-16 17:00, Hans de Goede wrote:
>> Hi,
>>
>> On 27-12-16 11:58, Jani Nikula wrote:
>>> On Sun, 25 Dec 2016, Hans de Goede wrote:
If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may
use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation
for a vbt in mailbox #4 for this.
This fixes the driver not finding the VBT on a jumper ezpad mini3
cherrytrail tablet.
>>>
>>> Thanks for the patch. I think you're onto something, but I don't think
>>> the patch is quite correct. That said, I'm not sure myself yet what
>>> would be. ;)
>>>
>>> Without the change, does intel_bios_is_valid_vbt() return true anyway?
>>
>> No.
>>
>>> I.e. do you get "Found valid VBT in ACPI OpRegion (Mailbox #4)\n" in
>>> log?
>>
>> No.
>>
>>> If not, which of the debug messages in intel_bios_is_valid_vbt() do
>>> you get?
>>
>> I get "BDB incomplete", which is why I wrote this patch and believe
>> this patch is the right solution. With this patch everything works,
>>
>>> In the latter case, I suspect you'll end up with failure in intel_bios.c
>>> with either "No MIPI config BDB found" or "No MIPI Sequence found,
>>> parsing complete\n".
>>
>> I don't remember the exact error, other then getting the
>> "BDB incomplete" error, and the i915 driver not listing the DSI connector
>> under /sys/class drm.
>>
>> What makes you say: "but I don't think the patch is quite correct" why
>> should the code still keep the OPREGION_ASLE_EXT start as end of the
>> mailbox #4 vbt if there is the ASLE extenstion is not used ?
>
> Ping, any progress on this ? I still believe my original patch is
> correct. Eitherway I would like to see a fix for this, be it this fix
> or something else, as a fix is necessary to get the LCD panel to work
> on jumper ezpad mini3 tablets.
Please send me /sys/kernel/debug/dri/0/i915_opregion on that machine.
Perusing the opregion spec (which I regret I can't share with you), I
found this:
* On mailboxes in general, "Mail-box locations are fixed and should
always be allocated irrespective of the support for a given mail box
is available or not."
* On opregion->asle->rvda, "This is mainly used when VBT size exceeds
6KB and can't be stored in Mailbox4." It isn't clear to me whether
->rvda was used or not. The opregion dump should shed light on
this. You can of course check that by adding debug prints in the code
too.
* On mailbox 4 (the VBT), "Holds a maximum of 6KB sized Raw VBT data
(not VBIOS image) from VBIOS image."
Clearly the patch is against the spec. Let's see if the opregion you
have there is against the spec too, and proceed from there...
BR,
Jani.
>
> Regards,
>
> Hans
>
>
>
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede
---
Note even with this fixed the panel still does not work with 4.9,
but it does with drm-intel-next-queued :) I believe the missing bit in
4.9 is the "drm/915: Parsing the missed out DTD fields from the VBT"
commit, but I've not verified this.
---
drivers/gpu/drm/i915/intel_opregion.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index f4429f6..eff35ae 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -982,7 +982,9 @@ int intel_opregion_setup(struct drm_i915_private
*dev_priv)
opregion->vbt_size = vbt_size;
} else {
vbt = base + OPREGION_VBT_OFFSET;
-vbt_size = OPREGION_ASLE_EXT_OFFSET - OPREGION_VBT_OFFSET;
+vbt_size = (mboxes & MBOX_ASLE_EXT) ?
+OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
+vbt_size -= OPREGION_VBT_OFFSET;
if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (Mailbox
#4)\n");
opregion->vbt = vbt;
>>>
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/24] drm/bridge/sii8620: add support for burst eMSC transmissions
On 23.01.2017 09:20, Archit Taneja wrote:
(...)
>> static void sii8620_fetch_edid(struct sii8620 *ctx)
>> {
>> u8 lm_ddc, ddc_cmd, int3, cbus;
>> @@ -1041,7 +1181,7 @@ static int sii8620_wait_for_fsm_state(struct sii8620
>> *ctx, u8 state)
>>
>> if ((s & MSK_COC_STAT_0_FSM_STATE) == state)
>> return 0;
>> -if (s & BIT_COC_STAT_0_PLL_LOCKED)
>> +if (!(s & BIT_COC_STAT_0_PLL_LOCKED))
> Should this be a part of patch #5?
Yes, of course, it is just fix for patch #5.
>
>> return -EBUSY;
>> usleep_range(4000, 6000);
>> }
>> @@ -1417,6 +1557,19 @@ static void sii8620_irq_coc(struct sii8620 *ctx)
>> {
>> u8 stat = sii8620_readb(ctx, REG_COC_INTR);
>>
>> +if (stat & BIT_COC_CALIBRATION_DONE) {
>> +u8 cstat = sii8620_readb(ctx, REG_COC_STAT_0);
>> +
>> +cstat &= BIT_COC_STAT_0_PLL_LOCKED | MSK_COC_STAT_0_FSM_STATE;
>> +if (cstat == (BIT_COC_STAT_0_PLL_LOCKED | 0x02)) {
>> +sii8620_write_seq_static(ctx,
>> +REG_COC_CTLB, 0,
>> +REG_TRXINTMH, BIT_TDM_INTR_SYNC_DATA
>> + | BIT_TDM_INTR_SYNC_WAIT
>> +);
>> +}
>> +}
>> +
>> sii8620_write(ctx, REG_COC_INTR, stat);
>> }
>>
>> @@ -1507,6 +1660,41 @@ static void sii8620_irq_infr(struct sii8620 *ctx)
>> sii8620_start_video(ctx);
>> }
>>
>> +static void sii8620_irq_tdm(struct sii8620 *ctx)
>> +{
>> +u8 stat = sii8620_readb(ctx, REG_TRXINTH);
>> +u8 tdm = sii8620_readb(ctx, REG_TRXSTA2);
>> +
>> +if ((tdm & MSK_TDM_SYNCHRONIZED) == VAL_TDM_SYNCHRONIZED) {
>> +ctx->mode = CM_ECBUS_S;
>> +ctx->burst.rx_ack = 0;
>> +ctx->burst.r_size = SII8620_BURST_BUF_LEN;
>> +sii8620_burst_tx_rbuf_info(ctx, SII8620_BURST_BUF_LEN);
>> +sii8620_mt_read_devcap(ctx, true);
>> +} else {
>> +sii8620_write_seq_static(ctx,
>> +REG_MHL_PLL_CTL2, 0,
>> +REG_MHL_PLL_CTL2, BIT_MHL_PLL_CTL2_CLKDETECT_EN
>> +);
>> +}
>> +
>> +sii8620_write(ctx, REG_TRXINTH, stat);
>> +}
>> +
>> +static void sii8620_irq_block(struct sii8620 *ctx)
>> +{
>> +u8 stat = sii8620_readb(ctx, REG_EMSCINTR);
>> +
>> +if (stat & BIT_EMSCINTR_SPI_DVLD) {
>> +u8 bstat = sii8620_readb(ctx, REG_SPIBURSTSTAT);
>> +
>> +if (bstat & BIT_SPIBURSTSTAT_EMSC_NORMAL_MODE)
>> +sii8620_burst_receive(ctx);
>> +}
>> +
>> +sii8620_write(ctx, REG_EMSCINTR, stat);
>> +}
>> +
>> /* endian agnostic, non-volatile version of test_bit */
>> static bool sii8620_test_bit(unsigned int nr, const u8 *addr)
>> {
>> @@ -1522,8 +1710,10 @@ static irqreturn_t sii8620_irq_thread(int irq, void
>> *data)
>> { BIT_FAST_INTR_STAT_DISC, sii8620_irq_disc },
>> { BIT_FAST_INTR_STAT_G2WB, sii8620_irq_g2wb },
>> { BIT_FAST_INTR_STAT_COC, sii8620_irq_coc },
>> +{ BIT_FAST_INTR_STAT_TDM, sii8620_irq_tdm },
>> { BIT_FAST_INTR_STAT_MSC, sii8620_irq_msc },
>> { BIT_FAST_INTR_STAT_MERR, sii8620_irq_merr },
>> +{ BIT_FAST_INTR_STAT_BLOCK, sii8620_irq_block },
>> { BIT_FAST_INTR_STAT_EDID, sii8620_irq_edid },
>> { BIT_FAST_INTR_STAT_SCDT, sii8620_irq_scdt },
>> { BIT_FAST_INTR_STAT_INFR, sii8620_irq_infr },
>> @@ -1539,7 +1729,9 @@ static irqreturn_t sii8620_irq_thread(int irq, void
>> *data)
>> if (sii8620_test_bit(irq_vec[i].bit, stats))
>> irq_vec[i].handler(ctx);
>>
>> +sii8620_burst_rx_all(ctx);
>> sii8620_mt_work(ctx);
>> +sii8620_burst_send(ctx);
>>
>> ret = sii8620_clear_error(ctx);
>> if (ret) {
>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.h
>> b/drivers/gpu/drm/bridge/sil-sii8620.h
>> index 3ee4e7e..f7bfbc3 100644
>> --- a/drivers/gpu/drm/bridge/sil-sii8620.h
>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.h
>> @@ -403,12 +403,16 @@
>>
>> /* TDM RX Status 2nd, default value: 0x00 */
>> #define REG_TRXSTA2 0x015c
>> +#define MSK_TDM_SYNCHRONIZED0xC0
> Would be nice to not have the hex digits in caps here.
OK, this one somehow sneaked out :)
Regards
Andrzej
>
> Thanks,
> Archit
>
>> +#define VAL_TDM_SYNCHRONIZED0x80
>>
>> /* TDM RX INT Low, default value: 0x00 */
>> #define REG_TRXINTL 0x0163
>>
>> /* TDM RX INT High, default value: 0x00 */
>> #define REG_TRXINTH 0x0164
>> +#define BIT_TDM_INTR_SYNC_DATA BIT(0)
>> +#define BIT_TDM_INTR_SYNC_WAIT BIT(1)
>>
>> /* TDM RX INTMASK High, default value: 0x00 */
>> #define REG_TRXINTMH0x0166
>>
_
[Bug 98520] System randomly crashes / freezes while playing certain games
https://bugs.freedesktop.org/show_bug.cgi?id=98520 --- Comment #33 from Samuel Pitoiset --- (In reply to Eugenij Shkrigunov from comment #31) > (In reply to Samuel Pitoiset from comment #30) > > The following commit can probably help if you have a VI+ card. > > > > https://cgit.freedesktop.org/mesa/mesa/commit/ > > ?id=e490b7812cae778c61004971d86dc8299b6cd240 > > > > At least, it fixes a bunch of other games. > > mesa-13.0.3 + llvm-3.9.1 + this patch: "Star Conflict" (federation station) > still hangs graphics subsystem - only reboot helps ( + , + > + ). You don't have a VI+ card, because your is R9 280x. This patch doesn't affect you. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97338] Black squares in the Spec Ops: The Line chapter select screen
https://bugs.freedesktop.org/show_bug.cgi?id=97338 --- Comment #9 from Samuel Pitoiset --- Makes sense. TGSI_OPCODE_ABS has been removed after this patch, but it fixes the issue (I tested myself). The patch is still pending for some reasons, I will let you know when something change. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 90481] Radeonsi driver, X crash while playing "Spec ops: the line"
https://bugs.freedesktop.org/show_bug.cgi?id=90481 --- Comment #27 from Samuel Pitoiset --- (In reply to Ryan Williams from comment #26) > Tested with recent mesa git, Ubuntu 16.04 Padoka PPA, kernel 4.8.11, no gpu > lockup with ~2 hour play. Probably fixed by same commit that fixed Arkham > Origins in Wine and XCOM:EU. If you have a VI+ card and this commit e490b7812cae778c61004971d86dc8299b6cd240 in your build, that would make sense. But the original ticket is for SI. Should probably be closed because mesa 10.5 is very old though. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99444] [radeonsi] The Witcher 3 (GOG/1.31) [Wine] starting menu is distorted
https://bugs.freedesktop.org/show_bug.cgi?id=99444 --- Comment #7 from Samuel Pitoiset --- Thanks for reporting the issue. I can reproduce it with mesa/llvm git on my rx 480. Needs investigation. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99484] Crusader Kings 2 - Loading bars, siege bars, morale bars, etc. do not render correctly
https://bugs.freedesktop.org/show_bug.cgi?id=99484 --- Comment #1 from Samuel Pitoiset --- Can you try recording an apitrace which reproduces the issue? Thanks! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 00/12] MT2701 DRM support
This is MT2701 DRM support PATCH v12, based on 4.10-rc1. We add DSI interrupt control, transfer function for MIPI DSI panel support. Most codes are the same, except some register changed. For example: - DISP_OVL address offset changed, color format definition changed. - DISP_RDMA fifo size changed. - DISP_COLOR offset changed. - MIPI_TX setting changed. We add a new component DDP_COMPONENT_BLS, and the connections are updated. OVL -> RDMA -> COLOR -> BLS -> DSI RDMA -> DPI And we have shadow register support in MT2701. Changes since v11: - Update mtk_dsi_poweron() and mtk_output_dsi_enable() to symmetric flow Changes since v10: - Add binding descriptions for newly added bindings - Remove color data pointer from generic mtk_ddp_comp - Remove "drm/mediatek: add mipi_tx data rate check" from the patch series - Remove "drm/mediatek: add dsi ulp mode control" from the patch series - Update descriptions for "drm/mediatek: add non-continuous clock mode and EOT packet control" - Fix DSI disable flow Changes since v9: - Split DSI patches into smaller parts - Use a real linux errno for return value - Add error handling in mtk_output_dsi_enable() - Remove unused changes and redundant delays - Add helpers and macros for configuration - Combine "drm/mediatek: rename macros, add chip prefix" and "drm/mediatek: add *driver_data for different hardware setting" Changes since v8: - enable 3 DSI interrupts only - move mtk_dsi_wait_for_irq_done() to the patch of irq control - use the name BLS in DRM driver part - move BLS declaration to a separate patch - update mtk_dsi_switch_to_cmd_mode() - update mtk_output_dsi_enable() and mtk_output_dsi_disable() Changes since v7: - Remove redundant codes - Move the definition of DDP_COMPONENT_BLS to patch of "drm/mediatek: update display module connections" - Move _dsi_irq_wait_queue into platform driver data - Move mtk_dsi_irq_data_clear() to patch of "drm/mediatek: add dsi interrupt control" - Add more descriptions in the commit messages Changes since v6: - Change data type of irq_data to u32 - Rewrite mtk_dsi_host_transfer() for simplify - Move some MIPI_TX config to patch of "drm/mediatek: add *driver_data for different hardware settings". - Remove device tree from this patch series Changes since v5: - Remove DPI device tree and compatible string - Use one wait queue to handle interrupt status - Update the interrupt check flow and DSI_INT_ALL_BITS - Use same function for host read/write command - various fixes Changes since v4: - Add messages when timeout in mtk_disp_mutex_acquire() - Add descriptions for DISP_REG_MUTEX registers - Move connection settings for display modules to a separate patch - Remove 'mt2701-disp-wdma' because it is unused - Move cleaning up and renaming to a separate patch - Use wait_event_interruptible_timeout() to replace polling - Remove irq_num from mtk_dsi structure - Remove redundant and debug codes Changes since v3: - Add DSI support for MIPI DSI panels - Update BLS binding to PWM nodes - Remove ufoe device nodes - Remove redundant parentheses - Remove global variable initialization Changes since v2: - Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel - Update mt2701_mtk_ddp_ext components - Changed to prefix naming - Reorder the patch series - Use of_device_get_match_data() to get driver private data - Use iopoll macros to implement mtk_disp_mutex_acquire() - Removed empty device tree nodes Changes since v1: - Removed BLS bindings and codes, which belong to pwm driver - Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config() - Split patch into smaller parts - Added const keyword to constant structure - Removed codes for special memory align Thanks, yt.shen YT Shen (10): dt-bindings: display: mediatek: update supported chips drm/mediatek: add helpers for coverting from the generic components drm/mediatek: add *driver_data for different hardware settings drm/mediatek: add shadow register support drm/mediatek: add BLS component drm/mediatek: update display module connections drm/mediatek: cleaning up and refine drm/mediatek: add non-continuous clock mode and EOT packet control drm/mediatek: update DSI sub driver flow for sending commands to panel drm/mediatek: add support for Mediatek SoC MT2701 shaoming chen (2): drm/mediatek: add dsi interrupt control drm/mediatek: add dsi transfer function .../bindings/display/mediatek/mediatek,disp.txt| 2 + .../bindings/display/mediatek/mediatek,dsi.txt | 2 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 64 ++- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 39 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 75 +-- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 138 +++-- drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 2 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 69 ++- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 2 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 54 +- drivers/gpu
[PATCH v12 01/12] dt-bindings: display: mediatek: update supported chips
Add decriptions about supported chips, including MT2701 & MT8173 Signed-off-by: YT Shen Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 ++ Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index db6e77e..acf61f1 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -40,6 +40,7 @@ Required properties (all function blocks): "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt "mediatek,-disp-mutex" - display mutex "mediatek,-disp-od"- overdrive + the supported chips are mt2701 and mt8173. - reg: Physical base address and length of the function block register space - interrupts: The interrupt signal from the function block (required, except for merge and split function blocks). @@ -54,6 +55,7 @@ Required properties (DMA function blocks): "mediatek,-disp-ovl" "mediatek,-disp-rdma" "mediatek,-disp-wdma" + the supported chips are mt2701 and mt8173. - larb: Should contain a phandle pointing to the local arbiter device as defined in Documentation/devicetree/bindings/soc/mediatek/mediatek,smi-larb.txt - iommus: Should point to the respective IOMMU block with master port as diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt index 2b1585a..fadf327 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt @@ -7,6 +7,7 @@ channel output. Required properties: - compatible: "mediatek,-dsi" + the supported chips are mt2701 and mt8173. - reg: Physical base address and length of the controller's registers - interrupts: The interrupt signal from the function block. - clocks: device clocks @@ -25,6 +26,7 @@ The MIPI TX configuration module controls the MIPI D-PHY. Required properties: - compatible: "mediatek,-mipi-tx" + the supported chips are mt2701 and mt8173. - reg: Physical base address and length of the controller's registers - clocks: PLL reference clock - clock-output-names: name of the output clock line to the DSI encoder -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 03/12] drm/mediatek: add *driver_data for different hardware settings
There are some hardware settings changed, between MT8173 & MT2701:
DISP_OVL address offset changed, color format definition changed.
DISP_RDMA fifo size changed.
DISP_COLOR offset changed.
MIPI_TX pll setting changed.
And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
Signed-off-by: YT Shen
Acked-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 41 -
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 18 +++-
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 71 +++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 57 +++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 25 +++---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 8
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 24 +-
7 files changed, 181 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index ce2759f..4552178 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -35,18 +35,27 @@
#define DISP_REG_OVL_PITCH(n) (0x0044 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
-#define DISP_REG_OVL_ADDR(n) (0x0f40 + 0x20 * (n))
+#define DISP_REG_OVL_ADDR_MT8173 0x0f40
+#define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20 * (n))
#defineOVL_RDMA_MEM_GMC0x40402020
#define OVL_CON_BYTE_SWAP BIT(24)
-#define OVL_CON_CLRFMT_RGB565 (0 << 12)
-#define OVL_CON_CLRFMT_RGB888 (1 << 12)
+#define OVL_CON_CLRFMT_RGB (1 << 12)
#define OVL_CON_CLRFMT_RGBA(2 << 12)
#define OVL_CON_CLRFMT_ARGB(3 << 12)
+#define OVL_CON_CLRFMT_RGB565(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
+ 0 : OVL_CON_CLRFMT_RGB)
+#define OVL_CON_CLRFMT_RGB888(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
+ OVL_CON_CLRFMT_RGB : 0)
#defineOVL_CON_AEN BIT(8)
#defineOVL_CON_ALPHA 0xff
+struct mtk_disp_ovl_data {
+ unsigned int addr;
+ bool fmt_rgb565_is_0;
+};
+
/**
* struct mtk_disp_ovl - DISP_OVL driver structure
* @ddp_comp - structure containing type enum and hardware resources
@@ -55,6 +64,7 @@
struct mtk_disp_ovl {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
+ const struct mtk_disp_ovl_data *data;
};
static inline struct mtk_disp_ovl *comp_to_ovl(struct mtk_ddp_comp *comp)
@@ -141,18 +151,18 @@ static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp,
unsigned int idx)
writel(0x0, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
}
-static unsigned int ovl_fmt_convert(unsigned int fmt)
+static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt)
{
switch (fmt) {
default:
case DRM_FORMAT_RGB565:
- return OVL_CON_CLRFMT_RGB565;
+ return OVL_CON_CLRFMT_RGB565(ovl);
case DRM_FORMAT_BGR565:
- return OVL_CON_CLRFMT_RGB565 | OVL_CON_BYTE_SWAP;
+ return OVL_CON_CLRFMT_RGB565(ovl) | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGB888:
- return OVL_CON_CLRFMT_RGB888;
+ return OVL_CON_CLRFMT_RGB888(ovl);
case DRM_FORMAT_BGR888:
- return OVL_CON_CLRFMT_RGB888 | OVL_CON_BYTE_SWAP;
+ return OVL_CON_CLRFMT_RGB888(ovl) | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGBX:
case DRM_FORMAT_RGBA:
return OVL_CON_CLRFMT_ARGB;
@@ -171,6 +181,7 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
struct mtk_plane_state *state)
{
+ struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
struct mtk_plane_pending_state *pending = &state->pending;
unsigned int addr = pending->addr;
unsigned int pitch = pending->pitch & 0x;
@@ -182,7 +193,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp,
unsigned int idx,
if (!pending->enable)
mtk_ovl_layer_off(comp, idx);
- con = ovl_fmt_convert(fmt);
+ con = ovl_fmt_convert(ovl, fmt);
if (idx != 0)
con |= OVL_CON_AEN | OVL_CON_ALPHA;
@@ -190,7 +201,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp,
unsigned int idx,
writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
writel_relaxed(offset, comp->regs + DISP_REG_OVL_OFFSET(idx));
- writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(idx));
+ writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(ovl, idx));
if (pending->enable)
mtk_ovl_la
[PATCH v12 04/12] drm/mediatek: add shadow register support
We need to acquire mutex before using the resources,
and need to release it after finished.
So we don't need to write registers in the blanking period.
Signed-off-by: YT Shen
Acked-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 75 -
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +++
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 2 +
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
4 files changed, 74 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 01a21dd..b9b82e5 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -329,6 +329,42 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
pm_runtime_put(drm->dev);
}
+static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
+{
+ struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
+ struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
+ unsigned int i;
+
+ /*
+* TODO: instead of updating the registers here, we should prepare
+* working registers in atomic_commit and let the hardware command
+* queue update module registers on vblank.
+*/
+ if (state->pending_config) {
+ mtk_ddp_comp_config(ovl, state->pending_width,
+ state->pending_height,
+ state->pending_vrefresh, 0);
+
+ state->pending_config = false;
+ }
+
+ if (mtk_crtc->pending_planes) {
+ for (i = 0; i < OVL_LAYER_NR; i++) {
+ struct drm_plane *plane = &mtk_crtc->planes[i];
+ struct mtk_plane_state *plane_state;
+
+ plane_state = to_mtk_plane_state(plane->state);
+
+ if (plane_state->pending.config) {
+ mtk_ddp_comp_layer_config(ovl, i, plane_state);
+ plane_state->pending.config = false;
+ }
+ }
+ mtk_crtc->pending_planes = false;
+ }
+}
+
static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
@@ -405,6 +441,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ struct mtk_drm_private *priv = crtc->dev->dev_private;
unsigned int pending_planes = 0;
int i;
@@ -426,6 +463,12 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
if (crtc->state->color_mgmt_changed)
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
+
+ if (priv->data->shadow_register) {
+ mtk_disp_mutex_acquire(mtk_crtc->mutex);
+ mtk_crtc_ddp_config(crtc);
+ mtk_disp_mutex_release(mtk_crtc->mutex);
+ }
}
static const struct drm_crtc_funcs mtk_crtc_funcs = {
@@ -471,36 +514,10 @@ static int mtk_drm_crtc_init(struct drm_device *drm,
void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
- struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
- unsigned int i;
+ struct mtk_drm_private *priv = crtc->dev->dev_private;
- /*
-* TODO: instead of updating the registers here, we should prepare
-* working registers in atomic_commit and let the hardware command
-* queue update module registers on vblank.
-*/
- if (state->pending_config) {
- mtk_ddp_comp_config(ovl, state->pending_width,
- state->pending_height,
- state->pending_vrefresh, 0);
-
- state->pending_config = false;
- }
-
- if (mtk_crtc->pending_planes) {
- for (i = 0; i < OVL_LAYER_NR; i++) {
- struct drm_plane *plane = &mtk_crtc->planes[i];
- struct mtk_plane_state *plane_state;
-
- plane_state = to_mtk_plane_state(plane->state);
-
- if (plane_state->pending.config) {
- mtk_ddp_comp_layer_config(ovl, i, plane_state);
- plane_state->pending.config = false;
- }
- }
- mtk_crtc->pending_planes = false;
- }
+ if (!priv->data->shadow_register)
+ mtk_crtc_ddp_config(crtc);
mtk_drm_finish_page_flip(mtk_crtc);
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8030769..b77d456 100644
--
[PATCH v12 02/12] drm/mediatek: add helpers for coverting from the generic components
define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_ovl'
define helpers for converting from 'mtk_ddp_comp' to 'mtk_disp_rdma'
Signed-off-by: YT Shen
Acked-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 15 +--
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 15 +--
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index c703102..ce2759f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -57,6 +57,11 @@ struct mtk_disp_ovl {
struct drm_crtc *crtc;
};
+static inline struct mtk_disp_ovl *comp_to_ovl(struct mtk_ddp_comp *comp)
+{
+ return container_of(comp, struct mtk_disp_ovl, ddp_comp);
+}
+
static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void *dev_id)
{
struct mtk_disp_ovl *priv = dev_id;
@@ -76,20 +81,18 @@ static irqreturn_t mtk_disp_ovl_irq_handler(int irq, void
*dev_id)
static void mtk_ovl_enable_vblank(struct mtk_ddp_comp *comp,
struct drm_crtc *crtc)
{
- struct mtk_disp_ovl *priv = container_of(comp, struct mtk_disp_ovl,
-ddp_comp);
+ struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
- priv->crtc = crtc;
+ ovl->crtc = crtc;
writel(0x0, comp->regs + DISP_REG_OVL_INTSTA);
writel_relaxed(OVL_FME_CPL_INT, comp->regs + DISP_REG_OVL_INTEN);
}
static void mtk_ovl_disable_vblank(struct mtk_ddp_comp *comp)
{
- struct mtk_disp_ovl *priv = container_of(comp, struct mtk_disp_ovl,
-ddp_comp);
+ struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
- priv->crtc = NULL;
+ ovl->crtc = NULL;
writel_relaxed(0x0, comp->regs + DISP_REG_OVL_INTEN);
}
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 0df05f9..21eff6f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -49,6 +49,11 @@ struct mtk_disp_rdma {
struct drm_crtc *crtc;
};
+static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
+{
+ return container_of(comp, struct mtk_disp_rdma, ddp_comp);
+}
+
static irqreturn_t mtk_disp_rdma_irq_handler(int irq, void *dev_id)
{
struct mtk_disp_rdma *priv = dev_id;
@@ -77,20 +82,18 @@ static void rdma_update_bits(struct mtk_ddp_comp *comp,
unsigned int reg,
static void mtk_rdma_enable_vblank(struct mtk_ddp_comp *comp,
struct drm_crtc *crtc)
{
- struct mtk_disp_rdma *priv = container_of(comp, struct mtk_disp_rdma,
- ddp_comp);
+ struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
- priv->crtc = crtc;
+ rdma->crtc = crtc;
rdma_update_bits(comp, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT,
RDMA_FRAME_END_INT);
}
static void mtk_rdma_disable_vblank(struct mtk_ddp_comp *comp)
{
- struct mtk_disp_rdma *priv = container_of(comp, struct mtk_disp_rdma,
- ddp_comp);
+ struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
- priv->crtc = NULL;
+ rdma->crtc = NULL;
rdma_update_bits(comp, DISP_REG_RDMA_INT_ENABLE, RDMA_FRAME_END_INT, 0);
}
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 06/12] drm/mediatek: update display module connections
update connections for OVL, RDMA, BLS, DSI
Signed-off-by: YT Shen
Acked-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index b77d456..a9b209c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -32,6 +32,10 @@
#define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100
+#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
+#define DISP_REG_CONFIG_OUT_SEL0x04c
+#define DISP_REG_CONFIG_DSI_SEL0x050
+
#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
#define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
@@ -71,6 +75,10 @@
#define DPI0_SEL_IN_RDMA1 0x1
#define COLOR1_SEL_IN_OVL1 0x1
+#define OVL_MOUT_EN_RDMA 0x1
+#define BLS_TO_DSI_RDMA1_TO_DPI1 0x8
+#define DSI_SEL_IN_BLS 0x0
+
struct mtk_disp_mutex {
int id;
bool claimed;
@@ -111,6 +119,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
cur,
if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
*addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
value = OVL0_MOUT_EN_COLOR0;
+ } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
+ *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
+ value = OVL_MOUT_EN_RDMA;
} else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD_MOUT_EN_RDMA0;
@@ -148,6 +159,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
*addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
value = COLOR1_SEL_IN_OVL1;
+ } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
+ *addr = DISP_REG_CONFIG_DSI_SEL;
+ value = DSI_SEL_IN_BLS;
} else {
value = 0;
}
@@ -155,6 +169,15 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id
cur,
return value;
}
+static void mtk_ddp_sout_sel(void __iomem *config_regs,
+enum mtk_ddp_comp_id cur,
+enum mtk_ddp_comp_id next)
+{
+ if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
+ writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
+ config_regs + DISP_REG_CONFIG_OUT_SEL);
+}
+
void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next)
@@ -167,6 +190,8 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
writel_relaxed(reg, config_regs + addr);
}
+ mtk_ddp_sout_sel(config_regs, cur, next);
+
value = mtk_ddp_sel_in(cur, next, &addr);
if (value) {
reg = readl_relaxed(config_regs + addr) | value;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 08/12] drm/mediatek: add dsi interrupt control
From: shaoming chen
add dsi interrupt control
Signed-off-by: shaoming chen
Acked-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 6f4b3bb..474861a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,6 +30,16 @@
#define DSI_START 0x00
+#define DSI_INTEN 0x08
+
+#define DSI_INTSTA 0x0c
+#define LPRX_RD_RDY_INT_FLAG BIT(0)
+#define CMD_DONE_INT_FLAG BIT(1)
+#define TE_RDY_INT_FLAGBIT(2)
+#define VM_DONE_INT_FLAG BIT(3)
+#define EXT_TE_RDY_INT_FLAGBIT(4)
+#define DSI_BUSY BIT(31)
+
#define DSI_CON_CTRL 0x10
#define DSI_RESET BIT(0)
#define DSI_EN BIT(1)
@@ -71,6 +82,9 @@
#define DSI_HSTX_CKL_WC0x64
+#define DSI_RACK 0x84
+#define RACK BIT(0)
+
#define DSI_PHY_LCCON 0x104
#define LC_HS_TX_ENBIT(0)
#define LC_ULPM_EN BIT(1)
@@ -137,6 +151,8 @@ struct mtk_dsi {
struct videomode vm;
int refcount;
bool enabled;
+ u32 irq_data;
+ wait_queue_head_t irq_wait_queue;
};
static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
@@ -469,6 +485,64 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
writel(1, dsi->regs + DSI_START);
}
+static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
+{
+ u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
+
+ writel(inten, dsi->regs + DSI_INTEN);
+}
+
+static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32 irq_bit)
+{
+ dsi->irq_data |= irq_bit;
+}
+
+static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32
irq_bit)
+{
+ dsi->irq_data &= ~irq_bit;
+}
+
+static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32
irq_flag,
+unsigned int timeout)
+{
+ s32 ret = 0;
+ unsigned long jiffies = msecs_to_jiffies(timeout);
+
+ ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
+ dsi->irq_data & irq_flag,
+ jiffies);
+ if (ret == 0) {
+ DRM_WARN("Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
+
+ mtk_dsi_enable(dsi);
+ mtk_dsi_reset_engine(dsi);
+ }
+
+ return ret;
+}
+
+static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
+{
+ struct mtk_dsi *dsi = dev_id;
+ u32 status, tmp;
+ u32 flag = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
+
+ status = readl(dsi->regs + DSI_INTSTA) & flag;
+
+ if (status) {
+ do {
+ mtk_dsi_mask(dsi, DSI_RACK, RACK, RACK);
+ tmp = readl(dsi->regs + DSI_INTSTA);
+ } while (tmp & DSI_BUSY);
+
+ mtk_dsi_mask(dsi, DSI_INTSTA, status, 0);
+ mtk_dsi_irq_data_set(dsi, status);
+ wake_up_interruptible(&dsi->irq_wait_queue);
+ }
+
+ return IRQ_HANDLED;
+}
+
static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
{
if (WARN_ON(dsi->refcount == 0))
@@ -517,6 +591,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
mtk_dsi_ps_control_vact(dsi);
mtk_dsi_config_vdo_timing(dsi);
+ mtk_dsi_set_interrupt_enable(dsi);
mtk_dsi_set_mode(dsi);
mtk_dsi_clk_hs_mode(dsi, 1);
@@ -818,6 +893,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *remote_node, *endpoint;
struct resource *regs;
+ int irq_num;
int comp_id;
int ret;
@@ -894,6 +970,22 @@ static int mtk_dsi_probe(struct platform_device *pdev)
return ret;
}
+ irq_num = platform_get_irq(pdev, 0);
+ if (irq_num < 0) {
+ dev_err(&pdev->dev, "failed to request dsi irq resource\n");
+ return -EPROBE_DEFER;
+ }
+
+ irq_set_status_flags(irq_num, IRQ_TYPE_LEVEL_LOW);
+ ret = devm_request_irq(&pdev->dev, irq_num, mtk_dsi_irq,
+ IRQF_TRIGGER_LOW, dev_name(&pdev->dev), dsi);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request mediatek dsi irq\n");
+ return -EPROBE_DEFER;
+ }
+
+ init_waitqueue_head(&dsi->irq_wait_queue);
+
platform_set_drvdata(pdev, dsi);
return component_add(&pdev->dev, &mtk_dsi_component_ops);
--
1.9.1
___
dri-d
[PATCH v12 05/12] drm/mediatek: add BLS component
Add BLS component for PWM + GAMMA function
Signed-off-by: YT Shen
Acked-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 5 -
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 3ff788c..f6e853a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -255,6 +255,7 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
[MTK_DISP_PWM] = "pwm",
[MTK_DISP_MUTEX] = "mutex",
[MTK_DISP_OD] = "od",
+ [MTK_DISP_BLS] = "bls",
};
struct mtk_ddp_comp_match {
@@ -265,6 +266,7 @@ struct mtk_ddp_comp_match {
static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] =
{
[DDP_COMPONENT_AAL] = { MTK_DISP_AAL, 0, &ddp_aal },
+ [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
[DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, &ddp_color },
[DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, &ddp_color },
[DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
@@ -336,7 +338,8 @@ int mtk_ddp_comp_init(struct device *dev, struct
device_node *node,
comp->id = comp_id;
comp->funcs = funcs ?: mtk_ddp_matches[comp_id].funcs;
- if (comp_id == DDP_COMPONENT_DPI0 ||
+ if (comp_id == DDP_COMPONENT_BLS ||
+ comp_id == DDP_COMPONENT_DPI0 ||
comp_id == DDP_COMPONENT_DSI0 ||
comp_id == DDP_COMPONENT_PWM0) {
comp->regs = NULL;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 22a33ee..0828cf8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -36,11 +36,13 @@ enum mtk_ddp_comp_type {
MTK_DISP_PWM,
MTK_DISP_MUTEX,
MTK_DISP_OD,
+ MTK_DISP_BLS,
MTK_DDP_COMP_TYPE_MAX,
};
enum mtk_ddp_comp_id {
DDP_COMPONENT_AAL,
+ DDP_COMPONENT_BLS,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_COLOR1,
DDP_COMPONENT_DPI0,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 07/12] drm/mediatek: cleaning up and refine
cleaning up unused define and refine function name and variable
Signed-off-by: shaoming chen
Signed-off-by: YT Shen
Acked-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 73 --
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 8 ++--
2 files changed, 39 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 2c42f90..6f4b3bb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -27,9 +27,6 @@
#include "mtk_drm_ddp_comp.h"
-#define DSI_VIDEO_FIFO_DEPTH (1920 / 4)
-#define DSI_HOST_FIFO_DEPTH64
-
#define DSI_START 0x00
#define DSI_CON_CTRL 0x10
@@ -46,7 +43,7 @@
#define MIX_MODE BIT(17)
#define DSI_TXRX_CTRL 0x18
-#define VC_NUM (2 << 0)
+#define VC_NUM BIT(1)
#define LANE_NUM (0xf << 2)
#define DIS_EOTBIT(6)
#define NULL_ENBIT(7)
@@ -164,7 +161,7 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset,
u32 mask, u32 data)
writel((temp & ~mask) | (data & mask), dsi->regs + offset);
}
-static void dsi_phy_timconfig(struct mtk_dsi *dsi)
+static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
u32 ui, cycle_time;
@@ -196,7 +193,7 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
}
-static void mtk_dsi_reset(struct mtk_dsi *dsi)
+static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, 0);
@@ -267,8 +264,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
}
mtk_dsi_enable(dsi);
- mtk_dsi_reset(dsi);
- dsi_phy_timconfig(dsi);
+ mtk_dsi_reset_engine(dsi);
+ mtk_dsi_phy_timconfig(dsi);
return 0;
@@ -281,33 +278,33 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
return ret;
}
-static void dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
+static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
}
-static void dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
+static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, LC_WAKEUP_EN);
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, 0);
}
-static void dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
+static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
}
-static void dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
+static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, LD0_WAKEUP_EN);
mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, 0);
}
-static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
+static bool mtk_dsi_clk_hs_state(struct mtk_dsi *dsi)
{
u32 tmp_reg1;
@@ -315,15 +312,15 @@ static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
return ((tmp_reg1 & LC_HS_TX_EN) == 1) ? true : false;
}
-static void dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
+static void mtk_dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
{
- if (enter && !dsi_clk_hs_state(dsi))
+ if (enter && !mtk_dsi_clk_hs_state(dsi))
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, LC_HS_TX_EN);
- else if (!enter && dsi_clk_hs_state(dsi))
+ else if (!enter && mtk_dsi_clk_hs_state(dsi))
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
}
-static void dsi_set_mode(struct mtk_dsi *dsi)
+static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
{
u32 vid_mode = CMD_MODE;
@@ -338,7 +335,7 @@ static void dsi_set_mode(struct mtk_dsi *dsi)
writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
}
-static void dsi_ps_control_vact(struct mtk_dsi *dsi)
+static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
{
struct videomode *vm = &dsi->vm;
u32 dsi_buf_bpp, ps_wc;
@@ -372,7 +369,7 @@ static void dsi_ps_control_vact(struct mtk_dsi *dsi)
writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
}
-static void dsi_rxtx_control(struct mtk_dsi *dsi)
+static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
{
u32 tmp_reg;
@@ -397,9 +394,9 @@ static void dsi_rxtx_control(struct mtk_dsi *dsi)
writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
}
-static void dsi_ps_control(struct mtk_dsi *dsi)
+static void mtk_dsi_ps_control(struct mtk_dsi *dsi)
{
- unsigned int dsi_
[PATCH v12 10/12] drm/mediatek: add non-continuous clock mode and EOT packet control
This patch will update dsi clock control method. 1. dsi non-continue clock mode will enhance antistatic effect for panel 2. EOT packet control will judge whether dsi send end of packet or not by customize Signed-off-by: shaoming chen Signed-off-by: YT Shen Acked-by: CK Hu --- drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c index b3c7fd8..85f22d2 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -431,6 +431,9 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi) break; } + tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6; + tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3; + writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL); } -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 09/12] drm/mediatek: add dsi transfer function
From: shaoming chen
add dsi read/write commands for transfer function
Signed-off-by: shaoming chen
Acked-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 168 -
1 file changed, 166 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 474861a..b3c7fd8 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include "mtk_drm_ddp_comp.h"
@@ -80,8 +81,16 @@
#define DSI_HBP_WC 0x54
#define DSI_HFP_WC 0x58
+#define DSI_CMDQ_SIZE 0x60
+#define CMDQ_SIZE 0x3f
+
#define DSI_HSTX_CKL_WC0x64
+#define DSI_RX_DATA0 0x74
+#define DSI_RX_DATA1 0x78
+#define DSI_RX_DATA2 0x7c
+#define DSI_RX_DATA3 0x80
+
#define DSI_RACK 0x84
#define RACK BIT(0)
@@ -117,6 +126,15 @@
#define CLK_HS_POST(0xff << 8)
#define CLK_HS_EXIT(0xff << 16)
+#define DSI_CMDQ0 0x180
+#define CONFIG (0xff << 0)
+#define SHORT_PACKET 0
+#define LONG_PACKET2
+#define BTABIT(2)
+#define DATA_ID(0xff << 8)
+#define DATA_0 (0xff << 16)
+#define DATA_1 (0xff << 24)
+
#define T_LPX 5
#define T_HS_PREP 6
#define T_HS_TRAIL 8
@@ -125,6 +143,12 @@
#define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
+#define MTK_DSI_HOST_IS_READ(type) \
+ ((type == MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM) || \
+ (type == MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM) || \
+ (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
+ (type == MIPI_DSI_DCS_READ))
+
struct phy;
struct mtk_dsi {
@@ -497,12 +521,12 @@ static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32
irq_bit)
dsi->irq_data |= irq_bit;
}
-static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32
irq_bit)
+static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
{
dsi->irq_data &= ~irq_bit;
}
-static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32
irq_flag,
+static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
unsigned int timeout)
{
s32 ret = 0;
@@ -832,9 +856,149 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host *host,
return 0;
}
+static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
+{
+ u32 timeout_ms = 50; /* total 1s ~ 2s timeout */
+
+ while (timeout_ms--) {
+ if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
+ break;
+
+ usleep_range(2, 4);
+ }
+
+ if (timeout_ms == 0) {
+ DRM_WARN("polling dsi wait not busy timeout!\n");
+
+ mtk_dsi_enable(dsi);
+ mtk_dsi_reset_engine(dsi);
+ }
+}
+
+static u32 mtk_dsi_recv_cnt(u8 type, u8 *read_data)
+{
+ switch (type) {
+ case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
+ case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
+ return 1;
+ case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
+ case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
+ return 2;
+ case MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE:
+ case MIPI_DSI_RX_DCS_LONG_READ_RESPONSE:
+ return read_data[1] + read_data[2] * 16;
+ case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
+ DRM_INFO("type is 0x02, try again\n");
+ break;
+ default:
+ DRM_INFO("type(0x%x) cannot be non-recognite\n", type);
+ break;
+ }
+
+ return 0;
+}
+
+static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
+{
+ const char *tx_buf = msg->tx_buf;
+ u8 config, cmdq_size, cmdq_off, type = msg->type;
+ u32 reg_val, cmdq_mask, i;
+
+ if (MTK_DSI_HOST_IS_READ(type))
+ config = BTA;
+ else
+ config = (msg->tx_len > 2) ? LONG_PACKET : SHORT_PACKET;
+
+ if (msg->tx_len > 2) {
+ cmdq_size = 1 + (msg->tx_len + 3) / 4;
+ cmdq_off = 4;
+ cmdq_mask = CONFIG | DATA_ID | DATA_0 | DATA_1;
+ reg_val = (msg->tx_len << 16) | (type << 8) | config;
+ } else {
+ cmdq_size = 1;
+ cmdq_off = 2;
+ cmdq_mask = CONFIG | DATA_ID;
+ reg_val = (type << 8) | config;
+ }
+
+ for (i = 0; i < msg->tx_len; i++)
+ writeb(tx_buf[i], dsi->regs + DSI_CMDQ0 + cmdq_off + i);
+
+ mtk_dsi_mask(dsi, DSI_CMDQ0, cmdq_mask, reg_val);
+ mtk_dsi_mask(dsi, DSI_CMDQ_SIZ
[PATCH v12 12/12] drm/mediatek: add support for Mediatek SoC MT2701
This patch add support for the Mediatek MT2701 DISP subsystem.
There is only one OVL engine in MT2701.
Signed-off-by: YT Shen
Acked-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 6 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 17 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 7 +++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 29 +
drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 6 ++
7 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 4552178..a14d7d6 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -35,6 +35,7 @@
#define DISP_REG_OVL_PITCH(n) (0x0044 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
+#define DISP_REG_OVL_ADDR_MT2701 0x0040
#define DISP_REG_OVL_ADDR_MT8173 0x0f40
#define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20 * (n))
@@ -303,12 +304,19 @@ static int mtk_disp_ovl_remove(struct platform_device
*pdev)
return 0;
}
+static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT2701,
+ .fmt_rgb565_is_0 = false,
+};
+
static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT8173,
.fmt_rgb565_is_0 = true,
};
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
+ { .compatible = "mediatek,mt2701-disp-ovl",
+ .data = &mt2701_ovl_driver_data},
{ .compatible = "mediatek,mt8173-disp-ovl",
.data = &mt8173_ovl_driver_data},
{},
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index e5e5318..b68a513 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -236,11 +236,17 @@ static int mtk_disp_rdma_remove(struct platform_device
*pdev)
return 0;
}
+static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
+ .fifo_size = SZ_4K,
+};
+
static const struct mtk_disp_rdma_data mt8173_rdma_driver_data = {
.fifo_size = SZ_8K,
};
static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
+ { .compatible = "mediatek,mt2701-disp-rdma",
+ .data = &mt2701_rdma_driver_data},
{ .compatible = "mediatek,mt8173-disp-rdma",
.data = &mt8173_rdma_driver_data},
{},
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index a9b209c..8130f3d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -60,6 +60,13 @@
#define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
#define MT8173_MUTEX_MOD_DISP_OD BIT(25)
+#define MT2701_MUTEX_MOD_DISP_OVL BIT(3)
+#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
+#define MT2701_MUTEX_MOD_DISP_COLORBIT(7)
+#define MT2701_MUTEX_MOD_DISP_BLS BIT(9)
+#define MT2701_MUTEX_MOD_DISP_RDMA0BIT(10)
+#define MT2701_MUTEX_MOD_DISP_RDMA1BIT(12)
+
#define MUTEX_SOF_SINGLE_MODE 0
#define MUTEX_SOF_DSI0 1
#define MUTEX_SOF_DSI1 2
@@ -92,6 +99,15 @@ struct mtk_ddp {
const unsigned int *mutex_mod;
};
+static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
+ [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
+ [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
+ [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
+};
+
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
@@ -390,6 +406,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
}
static const struct of_device_id ddp_driver_dt_match[] = {
+ { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
{ .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
{},
};
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index f6e853a..8b52416 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -39,6 +39,7 @@
#define DISP_REG_UFO_START 0x
#define DISP_COLOR_CFG_MAIN0x0400
+#define DISP_COLOR_START_MT2701
[PATCH v12 11/12] drm/mediatek: update DSI sub driver flow for sending commands to panel
This patch update enable/disable flow of DSI module.
Original flow works on there is a bridge chip: DSI -> bridge -> panel.
In this case: DSI -> panel, the DSI sub driver flow should be updated.
We need to initialize DSI first so that we can send commands to panel.
Signed-off-by: shaoming chen
Signed-off-by: YT Shen
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 266 ++---
1 file changed, 161 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 85f22d2..aa3541e 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -126,6 +126,10 @@
#define CLK_HS_POST(0xff << 8)
#define CLK_HS_EXIT(0xff << 16)
+#define DSI_VM_CMD_CON 0x130
+#define VM_CMD_EN BIT(0)
+#define TS_VFP_EN BIT(5)
+
#define DSI_CMDQ0 0x180
#define CONFIG (0xff << 0)
#define SHORT_PACKET 0
@@ -239,85 +243,6 @@ static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, 0);
}
-static int mtk_dsi_poweron(struct mtk_dsi *dsi)
-{
- struct device *dev = dsi->dev;
- int ret;
- u64 pixel_clock, total_bits;
- u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
-
- if (++dsi->refcount != 1)
- return 0;
-
- switch (dsi->format) {
- case MIPI_DSI_FMT_RGB565:
- bit_per_pixel = 16;
- break;
- case MIPI_DSI_FMT_RGB666_PACKED:
- bit_per_pixel = 18;
- break;
- case MIPI_DSI_FMT_RGB666:
- case MIPI_DSI_FMT_RGB888:
- default:
- bit_per_pixel = 24;
- break;
- }
-
- /**
-* vm.pixelclock is in kHz, pixel_clock unit is Hz, so multiply by 1000
-* htotal_time = htotal * byte_per_pixel / num_lanes
-* overhead_time = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
-* mipi_ratio = (htotal_time + overhead_time) / htotal_time
-* data_rate = pixel_clock * bit_per_pixel * mipi_ratio / num_lanes;
-*/
- pixel_clock = dsi->vm.pixelclock * 1000;
- htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
- dsi->vm.hsync_len;
- htotal_bits = htotal * bit_per_pixel;
-
- overhead_cycles = T_LPX + T_HS_PREP + T_HS_ZERO + T_HS_TRAIL +
- T_HS_EXIT;
- overhead_bits = overhead_cycles * dsi->lanes * 8;
- total_bits = htotal_bits + overhead_bits;
-
- dsi->data_rate = DIV_ROUND_UP_ULL(pixel_clock * total_bits,
- htotal * dsi->lanes);
-
- ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
- if (ret < 0) {
- dev_err(dev, "Failed to set data rate: %d\n", ret);
- goto err_refcount;
- }
-
- phy_power_on(dsi->phy);
-
- ret = clk_prepare_enable(dsi->engine_clk);
- if (ret < 0) {
- dev_err(dev, "Failed to enable engine clock: %d\n", ret);
- goto err_phy_power_off;
- }
-
- ret = clk_prepare_enable(dsi->digital_clk);
- if (ret < 0) {
- dev_err(dev, "Failed to enable digital clock: %d\n", ret);
- goto err_disable_engine_clk;
- }
-
- mtk_dsi_enable(dsi);
- mtk_dsi_reset_engine(dsi);
- mtk_dsi_phy_timconfig(dsi);
-
- return 0;
-
-err_disable_engine_clk:
- clk_disable_unprepare(dsi->engine_clk);
-err_phy_power_off:
- phy_power_off(dsi->phy);
-err_refcount:
- dsi->refcount--;
- return ret;
-}
-
static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
{
mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
@@ -365,16 +290,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
u32 vid_mode = CMD_MODE;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
- vid_mode = SYNC_PULSE_MODE;
-
- if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
- !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
vid_mode = BURST_MODE;
+ else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
+ vid_mode = SYNC_PULSE_MODE;
+ else
+ vid_mode = SYNC_EVENT_MODE;
}
writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
}
+static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
+{
+ mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
+ mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
+}
+
static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
{
struct videomode *vm = &dsi->vm;
@@ -512,6 +444,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
writel(1, dsi->regs
Re: [PATCH 19/24] drm/bridge/sii8620: rewrite hdmi start sequence
On 23.01.2017 10:17, Archit Taneja wrote:
>
> On 01/20/2017 01:08 PM, Andrzej Hajda wrote:
>> MHL3 protocol requires registry adjustments depending on chosen video mode.
>> Necessary information is gathered in mode_fixup callback. In case of HDMI
>> video modes driver should also send special AVI and MHL infoframes.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/bridge/sil-sii8620.c | 249
>> +++
>> drivers/gpu/drm/bridge/sil-sii8620.h | 15 ++-
>> 2 files changed, 231 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>> index 1c76905..2c7b5b9 100644
>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>> @@ -32,6 +32,8 @@
>>
>> #define SII8620_BURST_BUF_LEN 288
>> #define VAL_RX_HDMI_CTRL2_DEFVAL VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
>> +#define MHL1_MAX_LCLK 225000
>> +#define MHL3_MAX_LCLK 60
>>
>> enum sii8620_mode {
>> CM_DISCONNECTED,
>> @@ -62,6 +64,9 @@ struct sii8620 {
>> struct regulator_bulk_data supplies[2];
>> struct mutex lock; /* context lock, protects fields below */
>> int error;
>> +int pixel_clock;
>> +unsigned int use_packed_pixel:1;
>> +int video_code;
>> enum sii8620_mode mode;
>> enum sii8620_sink_type sink_type;
>> u8 cbus_status;
>> @@ -69,7 +74,7 @@ struct sii8620 {
>> u8 xstat[MHL_XDS_SIZE];
>> u8 devcap[MHL_DCAP_SIZE];
>> u8 xdevcap[MHL_XDC_SIZE];
>> -u8 avif[19];
>> +u8 avif[HDMI_INFOFRAME_SIZE(AVI)];
>> struct edid *edid;
>> unsigned int gen2_write_burst:1;
>> enum sii8620_mt_state mt_state;
>> @@ -685,6 +690,40 @@ static void sii8620_burst_tx_rbuf_info(struct sii8620
>> *ctx, int size)
>> d->size = cpu_to_le16(size);
>> }
>>
>> +static u8 sii8620_checksum(void *ptr, int size)
>> +{
>> +u8 *d = ptr, sum = 0;
>> +
>> +while (size--)
>> +sum += *d++;
>> +
>> +return sum;
>> +}
>> +
>> +static void sii8620_mhl_burst_hdr_set(struct mhl3_burst_header *h,
>> +enum mhl_burst_id id)
>> +{
>> +h->id = cpu_to_be16(id);
>> +h->total_entries = 1;
>> +h->sequence_index = 1;
>> +}
>> +
>> +static void sii8620_burst_tx_bits_per_pixel_fmt(struct sii8620 *ctx, u8 fmt)
>> +{
>> +struct mhl_burst_bits_per_pixel_fmt *d;
>> +const int size = sizeof(*d) + sizeof(d->desc[0]);
>> +
>> +d = sii8620_burst_get_tx_buf(ctx, size);
>> +if (!d)
>> +return;
>> +
>> +sii8620_mhl_burst_hdr_set(&d->hdr, MHL_BURST_ID_BITS_PER_PIXEL_FMT);
>> +d->num_entries = 1;
>> +d->desc[0].stream_id = 0;
>> +d->desc[0].pixel_format = fmt;
>> +d->hdr.checksum -= sii8620_checksum(d, size);
>> +}
>> +
>> static void sii8620_burst_rx_all(struct sii8620 *ctx)
>> {
>> u8 *d = ctx->burst.rx_buf;
>> @@ -949,32 +988,162 @@ static void sii8620_stop_video(struct sii8620 *ctx)
>> sii8620_write(ctx, REG_TPI_SC, val);
>> }
>>
>> +static void sii8620_set_format(struct sii8620 *ctx)
>> +{
>> +u8 out_fmt;
>> +
>> +if (sii8620_is_mhl3(ctx)) {
>> +sii8620_setbits(ctx, REG_M3_P0CTRL,
>> +BIT_M3_P0CTRL_MHL3_P0_PIXEL_MODE_PACKED,
>> +ctx->use_packed_pixel ? ~0 : 0);
>> +} else {
>> +if (ctx->use_packed_pixel)
>> +sii8620_write_seq_static(ctx,
>> +REG_VID_MODE, BIT_VID_MODE_M1080P,
>> +REG_MHL_TOP_CTL, BIT_MHL_TOP_CTL_MHL_PP_SEL | 1,
>> +REG_MHLTX_CTL6, 0x60
>> +);
>> +else
>> +sii8620_write_seq_static(ctx,
>> +REG_VID_MODE, 0,
>> +REG_MHL_TOP_CTL, 1,
>> +REG_MHLTX_CTL6, 0xa0
>> +);
>> +}
>> +
>> +if (ctx->use_packed_pixel)
>> +out_fmt = VAL_TPI_FORMAT(YCBCR422, FULL) |
>> +BIT_TPI_OUTPUT_CSCMODE709;
>> +else
>> +out_fmt = VAL_TPI_FORMAT(RGB, FULL);
>> +
>> +sii8620_write_seq(ctx,
>> +REG_TPI_INPUT, VAL_TPI_FORMAT(RGB, FULL),
>> +REG_TPI_OUTPUT, out_fmt,
>> +);
>> +}
>> +
>> +#define MHL3_VSIF_TYPE 0x81
>> +#define MHL3_VSIF_VERSION 0x03
>> +#define MHL3_VSIF_LENGTH0x0f
>> +#define IEEE_OUI_MHL3 0x7CA61D
> Should these be in mhl.h?
>
> Some of these seem similar to the infoframe related defs
> in include/linux/hdmi.h
>
> Do you think there should be equivalent helpers for mhl infoframes
> similar to hdmi_vendor_infoframe_init
> and hdmi_vendor_infoframe_pack()?
Answer is yes, IMHO, for both questions, but since the only
documentation I have access to is vendor code I am little bit hesitant
in pushing such things into mhl header.
I am not sure if I can properly describe all fields of MHL3 VSIF
infoframe, but beside this I have no
Re: [Intel-gfx] [PATCH] drm/color: un-inline drm_color_lut_extract()
On Mon, 23 Jan 2017, Daniel Vetter wrote:
> On Mon, Jan 23, 2017 at 11:42:59AM +0200, Jani Nikula wrote:
>> The function is not that big, but it's also not used for anything
>> performance critical. Make it a normal function.
>>
>> As a side effect, this apparently makes sparse smarter about what it's
>> doing, and gets rid of the warning:
>>
>> ./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295)
>> for type unsigned long
>> ./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
>> constant value (8000 becomes 0)
>
> Not really clear to me what's going on, but if it helps ...
Apparently sparse is clever enough to notice bit_precision < 16 when
this is a regular function, but not when it's an inline function. The
second warning we could get rid of just by changing s/1UL/1U/.
BR,
Jani.
>
>> Cc: Lionel Landwerlin
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Daniel Vetter
>
>> ---
>> drivers/gpu/drm/drm_color_mgmt.c | 24
>> include/drm/drm_color_mgmt.h | 27 ++-
>> 2 files changed, 26 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
>> b/drivers/gpu/drm/drm_color_mgmt.c
>> index 789b4c65cd69..5618f60c7690 100644
>> --- a/drivers/gpu/drm/drm_color_mgmt.c
>> +++ b/drivers/gpu/drm/drm_color_mgmt.c
>> @@ -88,6 +88,30 @@
>> */
>>
>> /**
>> + * drm_color_lut_extract - clamp&round LUT entries
>> + * @user_input: input value
>> + * @bit_precision: number of bits the hw LUT supports
>> + *
>> + * Extract a degamma/gamma LUT value provided by user (in the form of
>> + * &drm_color_lut entries) and round it to the precision supported by the
>> + * hardware.
>> + */
>> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
>> +{
>> +uint32_t val = user_input;
>> +uint32_t max = 0x >> (16 - bit_precision);
>> +
>> +/* Round only if we're not using full precision. */
>> +if (bit_precision < 16) {
>> +val += 1UL << (16 - bit_precision - 1);
>> +val >>= 16 - bit_precision;
>> +}
>> +
>> +return clamp_val(val, 0, max);
>> +}
>> +EXPORT_SYMBOL(drm_color_lut_extract);
>> +
>> +/**
>> * drm_crtc_enable_color_mgmt - enable color management properties
>> * @crtc: DRM CRTC
>> * @degamma_lut_size: the size of the degamma lut (before CSC)
>> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
>> index c767238ac9d5..bce4a532836d 100644
>> --- a/include/drm/drm_color_mgmt.h
>> +++ b/include/drm/drm_color_mgmt.h
>> @@ -25,6 +25,8 @@
>>
>> #include
>>
>> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
>> +
>> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>> uint degamma_lut_size,
>> bool has_ctm,
>> @@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>> int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>> int gamma_size);
>>
>> -/**
>> - * drm_color_lut_extract - clamp&round LUT entries
>> - * @user_input: input value
>> - * @bit_precision: number of bits the hw LUT supports
>> - *
>> - * Extract a degamma/gamma LUT value provided by user (in the form of
>> - * &drm_color_lut entries) and round it to the precision supported by the
>> - * hardware.
>> - */
>> -static inline uint32_t drm_color_lut_extract(uint32_t user_input,
>> - uint32_t bit_precision)
>> -{
>> -uint32_t val = user_input;
>> -uint32_t max = 0x >> (16 - bit_precision);
>> -
>> -/* Round only if we're not using full precision. */
>> -if (bit_precision < 16) {
>> -val += 1UL << (16 - bit_precision - 1);
>> -val >>= 16 - bit_precision;
>> -}
>> -
>> -return clamp_val(val, 0, max);
>> -}
>> -
>> -
>> #endif
>> --
>> 2.1.4
>>
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: sii902x: fix get edid may fail
On Mon, 23 Jan 2017, Boris Brezillon wrote:
> Hi Andrea,
>
> On Mon, 23 Jan 2017 11:00:02 +0100
> Andrea Merello wrote:
>
>> From: Andrea Merello
>>
>> The standard DRM function to get the edid from the i2c bus performs
>> (at least) two transfers.
>>
>> By experiments it seems that the sii9022a have problems with the
>> 2nd I2C start, at least unless a wait is introduced detween the
>
> ^ between
>
>> two transfers.
>>
>> So we perform one single I2C transfer, and if the transfer must be
>> split, then we introduce a delay.
>
> That's not exactly what this patch does: you're introducing a delay
> between each retry. So, if the transceiver really requires a delay
> between each transfer, you'll have to retry at least once on the 2nd
> transfer.
>
> I guess a better solution would be to add a delay even in case of
> success, or maybe modify drm_do_get_edid() to optionally wait for a
> specified time between each transfer.
Is the problem related specifically to EDID reads, or generally to I2C
transfers? Perhaps this should be fixed at the adapter master_xfer layer
instead? Does the master_xfer perhaps return -EAGAIN, have you looked
into i2c_adapter timeout member? (See __i2c_transfer in i2c-core.c.)
The intention of drm_do_get_edid() is to facilitate *alternative*
methods to doing I2C, not to workaround quirks like this.
BR,
Jani.
>
> BTW, sii902x_do_probe_ddc_edid() and drm_do_probe_ddc_edid() are almost
> identical (except for the extra delay()), so maybe we should export
> drm_do_probe_ddc_edid() and add an extra delay_us to it.
>
>>
>> Signed-off-by: Andrea Merello
>> Cc: Andrea Merello
>> Cc: Boris Brezillon
>> Cc: Archit Taneja
>> Cc: David Airlie
>> ---
>> drivers/gpu/drm/bridge/sii902x.c | 70
>> +++-
>> 1 file changed, 69 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/sii902x.c
>> b/drivers/gpu/drm/bridge/sii902x.c
>> index 9126d03..042d7e2 100644
>> --- a/drivers/gpu/drm/bridge/sii902x.c
>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>> @@ -133,6 +133,62 @@ static const struct drm_connector_funcs
>> sii902x_connector_funcs = {
>> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> };
>>
>> +#define DDC_SEGMENT_ADDR 0x30
>> +static int sii902x_do_probe_ddc_edid(void *data, u8 *buf,
>> + unsigned int block, size_t len)
>> +{
>> +struct i2c_adapter *adapter = data;
>> +unsigned char start = block * EDID_LENGTH;
>> +unsigned char segment = block >> 1;
>> +unsigned char xfers = segment ? 3 : 2;
>> +int ret, retries = 5;
>> +
>> +/*
>> + * The core I2C driver will automatically retry the transfer if the
>> + * adapter reports EAGAIN. However, we find that bit-banging transfers
>> + * are susceptible to errors under a heavily loaded machine and
>> + * generate spurious NAKs and timeouts. Retrying the transfer
>> + * of the individual block a few times seems to overcome this.
>> + */
>> +while (1) {
>> +struct i2c_msg msgs[] = {
>> +{
>> +.addr = DDC_SEGMENT_ADDR,
>> +.flags = 0,
>> +.len= 1,
>> +.buf= &segment,
>> +}, {
>> +.addr = DDC_ADDR,
>> +.flags = 0,
>> +.len= 1,
>> +.buf= &start,
>> +}, {
>> +.addr = DDC_ADDR,
>> +.flags = I2C_M_RD,
>> +.len= len,
>> +.buf= buf,
>> +}
>> +};
>> +
>> +/*
>> + * Avoid sending the segment addr to not upset non-compliant
>> + * DDC monitors.
>> + */
>> +ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
>> +
>> +if (ret == -ENXIO) {
>> +DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
>> + adapter->name);
>> +break;
>> +}
>> +if (ret == xfers || --retries == 0)
>> +break;
>> +
>> +udelay(100);
>> +}
>> +
>> +return ret == xfers ? 0 : -1;
>> +}
>
> Missing empty line here.
>
>> static int sii902x_get_modes(struct drm_connector *connector)
>> {
>> struct sii902x *sii902x = connector_to_sii902x(connector);
>> @@ -168,8 +224,20 @@ static int sii902x_get_modes(struct drm_connector
>> *connector)
>> if (ret)
>> return ret;
>>
>> -edid = drm_get_edid(connector, sii902x->i2c->adapter);
>> +/* drm_get_edid() runs two I2C transfers. The sii902x seems
>
> Please use kernel comment style:
>
> /*
>* ...
>
>> + *
[Bug 66731] ACPI + kworker high CPU usage
https://bugzilla.kernel.org/show_bug.cgi?id=66731 Aray changed: What|Removed |Added CC||aray.ger...@gmail.com --- Comment #19 from Aray --- I have the T460p running RHEL and have this same exact issue when I wake the laptop up from sleep while it's docked. Undocking makes it go away. I tried unplugging everything but the power cord from the docking station but that didn't help. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/3] DRM: add help to get ELD speaker allocation
On Mon, Jan 23, 2017 at 08:49:11AM +0100, Daniel Vetter wrote: > On Thu, Jan 19, 2017 at 10:29:01AM +, Mark Brown wrote: > > I see. For most subsystems you need to actually copy a human to make > > sure that things are seen - just the list isn't enough. In terms of it > > being reviewed one of the problems with DRM not listing the reviwers in > > the MAINTAINERS file or anything is that it's very hard for anyone to > > tell if something is considered a good enough review or if it's just a > > review from someone who happens to contribute to DRM sometimes. > Jani is now officially listed as drm-misc maintainer in MAINTAINERS. We > also have official entries for other major areas (like bridge drivers or > similar). Where do you see a gap? > Note that before KS this was indeed not there, because of the committer > model hanging in the air a bit ... This bit also wasn't there when the series started grinding on IIRC. It does look clear enough now though, thanks. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Warning at drivers/gpu/drm/drm_atomic_helper.c
On Mon, Jan 23, 2017 at 1:15 AM, Marek Vasut wrote:
> IMHO this will no longer handle the fences correctly and you'll see
> rendering artifacts sometimes.
Ok, for 4.9.x stable we cannot apply your 782ea2a493ba90800 ("drm/imx: Switch
to drm_fb_cma_prepare_fb() helper") as it depends on many things that
only show up on 4.10-rc1, so we need to provide a different fix for
4.9.x.
What I did not figure out so far is why are we getting sometimes the
WARN_ON(!plane_state->fb); inside drm_atomic_helper_wait_for_fences()?
The way to reproduce this issue on 4.9.x:
1. Start kmscube
2. Stop kmscube with CTRL + C
Repeate this sequence several times (10 to 20 times) and the
WARN_ON(!plane_state->fb) will trigger about 20% of the times.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: sii902x: fix get edid may fail
On Mon, Jan 23, 2017 at 11:20 AM, Boris Brezillon
wrote:
> Hi Andrea,
>
> On Mon, 23 Jan 2017 11:00:02 +0100
> Andrea Merello wrote:
>
>> From: Andrea Merello
>>
>> The standard DRM function to get the edid from the i2c bus performs
>> (at least) two transfers.
>>
>> By experiments it seems that the sii9022a have problems with the
>> 2nd I2C start, at least unless a wait is introduced detween the
>
> ^ between
OK
>> two transfers.
>>
>> So we perform one single I2C transfer, and if the transfer must be
>> split, then we introduce a delay.
>
> That's not exactly what this patch does: you're introducing a delay
> between each retry. So, if the transceiver really requires a delay
> between each transfer, you'll have to retry at least once on the 2nd
> transfer.
You are right. I've missed that. The delay should be placed just after
(or maybe before) i2c_transfer()
> I guess a better solution would be to add a delay even in case of
> success, or maybe modify drm_do_get_edid() to optionally wait for a
> specified time between each transfer.
I thought the requirement for delay to be specific to this HDMI
encoder; if you think that it can be useful even for other chips then
IMHO it might worth to add the optional delay in the core code, such
as drm_do_get_edid() as you suggested.
> BTW, sii902x_do_probe_ddc_edid() and drm_do_probe_ddc_edid() are almost
> identical (except for the extra delay()), so maybe we should export
> drm_do_probe_ddc_edid() and add an extra delay_us to it.
I like the idea, but this would not introduce any delay between
retries, that I would assume to be required.
>>
>> Signed-off-by: Andrea Merello
>> Cc: Andrea Merello
>> Cc: Boris Brezillon
>> Cc: Archit Taneja
>> Cc: David Airlie
>> ---
>> drivers/gpu/drm/bridge/sii902x.c | 70
>> +++-
>> 1 file changed, 69 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/sii902x.c
>> b/drivers/gpu/drm/bridge/sii902x.c
>> index 9126d03..042d7e2 100644
>> --- a/drivers/gpu/drm/bridge/sii902x.c
>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>> @@ -133,6 +133,62 @@ static const struct drm_connector_funcs
>> sii902x_connector_funcs = {
>> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> };
>>
>> +#define DDC_SEGMENT_ADDR 0x30
>> +static int sii902x_do_probe_ddc_edid(void *data, u8 *buf,
>> + unsigned int block, size_t len)
>> +{
>> + struct i2c_adapter *adapter = data;
>> + unsigned char start = block * EDID_LENGTH;
>> + unsigned char segment = block >> 1;
>> + unsigned char xfers = segment ? 3 : 2;
>> + int ret, retries = 5;
>> +
>> + /*
>> + * The core I2C driver will automatically retry the transfer if the
>> + * adapter reports EAGAIN. However, we find that bit-banging transfers
>> + * are susceptible to errors under a heavily loaded machine and
>> + * generate spurious NAKs and timeouts. Retrying the transfer
>> + * of the individual block a few times seems to overcome this.
>> + */
>> + while (1) {
>> + struct i2c_msg msgs[] = {
>> + {
>> + .addr = DDC_SEGMENT_ADDR,
>> + .flags = 0,
>> + .len= 1,
>> + .buf= &segment,
>> + }, {
>> + .addr = DDC_ADDR,
>> + .flags = 0,
>> + .len= 1,
>> + .buf= &start,
>> + }, {
>> + .addr = DDC_ADDR,
>> + .flags = I2C_M_RD,
>> + .len= len,
>> + .buf= buf,
>> + }
>> + };
>> +
>> + /*
>> + * Avoid sending the segment addr to not upset non-compliant
>> + * DDC monitors.
>> + */
>> + ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
>> +
>> + if (ret == -ENXIO) {
>> + DRM_DEBUG_KMS("drm: skipping non-existent adapter
>> %s\n",
>> + adapter->name);
>> + break;
>> + }
>> + if (ret == xfers || --retries == 0)
>> + break;
>> +
>> + udelay(100);
>> + }
>> +
>> + return ret == xfers ? 0 : -1;
>> +}
>
> Missing empty line here.
OK
>
>> static int sii902x_get_modes(struct drm_connector *connector)
>> {
>> struct sii902x *sii902x = connector_to_sii902x(connector);
>> @@ -168,8 +224,20 @@ static int sii902x_get_modes(struct drm_connector
>> *connector)
>> if (ret)
>> return ret;
>>
>> - edid = drm_get_edid(connector, sii902x->i2c->adapter);
>> + /* drm_get_edid() runs two I2C tr
Re: [PATCH] drm/bridge: sii902x: fix get edid may fail
On Mon, Jan 23, 2017 at 12:32 PM, Jani Nikula
wrote:
> On Mon, 23 Jan 2017, Boris Brezillon
> wrote:
>> Hi Andrea,
>>
>> On Mon, 23 Jan 2017 11:00:02 +0100
>> Andrea Merello wrote:
>>
>>> From: Andrea Merello
>>>
>>> The standard DRM function to get the edid from the i2c bus performs
>>> (at least) two transfers.
>>>
>>> By experiments it seems that the sii9022a have problems with the
>>> 2nd I2C start, at least unless a wait is introduced detween the
>>
>> ^ between
>>
>>> two transfers.
>>>
>>> So we perform one single I2C transfer, and if the transfer must be
>>> split, then we introduce a delay.
>>
>> That's not exactly what this patch does: you're introducing a delay
>> between each retry. So, if the transceiver really requires a delay
>> between each transfer, you'll have to retry at least once on the 2nd
>> transfer.
>>
>> I guess a better solution would be to add a delay even in case of
>> success, or maybe modify drm_do_get_edid() to optionally wait for a
>> specified time between each transfer.
>
> Is the problem related specifically to EDID reads, or generally to I2C
> transfers? Perhaps this should be fixed at the adapter master_xfer layer
> instead? Does the master_xfer perhaps return -EAGAIN, have you looked
> into i2c_adapter timeout member? (See __i2c_transfer in i2c-core.c.)
>
> The intention of drm_do_get_edid() is to facilitate *alternative*
> methods to doing I2C, not to workaround quirks like this.
This problem seems not related to the I2C master itself. I saw the I2C
master to TX correctly by looking at the I2C bus before the sii9022a
with the scope, and I saw the same I2C transfer to be corrupted after
the sii9022a; actually the sii9022a seems to gate the bus damaging the
I2C start of the 2nd transfer, unless we place this delay.
This happened with two different I2C master (the one on the SoC as
well as another different one implemented on FPGA).
So IMHO this quirk should be done in the sii902x dirver. Said that, I
admit that I've not looked at i2c_adapter timeout member or other
details in upper layers.
> BR,
> Jani.
>
>
>>
>> BTW, sii902x_do_probe_ddc_edid() and drm_do_probe_ddc_edid() are almost
>> identical (except for the extra delay()), so maybe we should export
>> drm_do_probe_ddc_edid() and add an extra delay_us to it.
>>
>>>
>>> Signed-off-by: Andrea Merello
>>> Cc: Andrea Merello
>>> Cc: Boris Brezillon
>>> Cc: Archit Taneja
>>> Cc: David Airlie
>>> ---
>>> drivers/gpu/drm/bridge/sii902x.c | 70
>>> +++-
>>> 1 file changed, 69 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/sii902x.c
>>> b/drivers/gpu/drm/bridge/sii902x.c
>>> index 9126d03..042d7e2 100644
>>> --- a/drivers/gpu/drm/bridge/sii902x.c
>>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>>> @@ -133,6 +133,62 @@ static const struct drm_connector_funcs
>>> sii902x_connector_funcs = {
>>> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>>> };
>>>
>>> +#define DDC_SEGMENT_ADDR 0x30
>>> +static int sii902x_do_probe_ddc_edid(void *data, u8 *buf,
>>> + unsigned int block, size_t len)
>>> +{
>>> +struct i2c_adapter *adapter = data;
>>> +unsigned char start = block * EDID_LENGTH;
>>> +unsigned char segment = block >> 1;
>>> +unsigned char xfers = segment ? 3 : 2;
>>> +int ret, retries = 5;
>>> +
>>> +/*
>>> + * The core I2C driver will automatically retry the transfer if the
>>> + * adapter reports EAGAIN. However, we find that bit-banging transfers
>>> + * are susceptible to errors under a heavily loaded machine and
>>> + * generate spurious NAKs and timeouts. Retrying the transfer
>>> + * of the individual block a few times seems to overcome this.
>>> + */
>>> +while (1) {
>>> +struct i2c_msg msgs[] = {
>>> +{
>>> +.addr = DDC_SEGMENT_ADDR,
>>> +.flags = 0,
>>> +.len= 1,
>>> +.buf= &segment,
>>> +}, {
>>> +.addr = DDC_ADDR,
>>> +.flags = 0,
>>> +.len= 1,
>>> +.buf= &start,
>>> +}, {
>>> +.addr = DDC_ADDR,
>>> +.flags = I2C_M_RD,
>>> +.len= len,
>>> +.buf= buf,
>>> +}
>>> +};
>>> +
>>> +/*
>>> + * Avoid sending the segment addr to not upset non-compliant
>>> + * DDC monitors.
>>> + */
>>> +ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
>>> +
>>> +if (ret == -ENXIO) {
>>> +DRM_DEBUG_KMS("drm: skipping non-existent adapter
>>> %s\n",
[PATCH] drm: bridge: dw-hdmi: fix building without CONFIG_OF
The of_node member in struct drm_bridge is hidden when CONFIG_OF
is disabled, causing a build error:
drivers/gpu/drm/bridge/dw-hdmi.c: In function '__dw_hdmi_probe':
drivers/gpu/drm/bridge/dw-hdmi.c:2063:14: error: 'struct drm_bridge' has no
member named 'of_node'
We could fix this either using a Kconfig dependency on CONFIG_OF
or making the one line conditional. The latter gives us better
compile test coverage, so this is what I'm doing here.
Fixes: 69497eb9234e ("drm: bridge: dw-hdmi: Implement DRM bridge registration")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/bridge/dw-hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 4fda0717e789..9a9ec27d9e28 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -2060,7 +2060,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->bridge.driver_private = hdmi;
hdmi->bridge.funcs = &dw_hdmi_bridge_funcs;
+#ifdef CONFIG_OF
hdmi->bridge.of_node = pdev->dev.of_node;
+#endif
ret = dw_hdmi_fb_registered(hdmi);
if (ret)
--
2.9.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: sii902x: fix get edid may fail
On Mon, 23 Jan 2017 13:12:12 +0100 Andrea Merello wrote: > On Mon, Jan 23, 2017 at 12:32 PM, Jani Nikula > wrote: > > On Mon, 23 Jan 2017, Boris Brezillon > > wrote: > >> Hi Andrea, > >> > >> On Mon, 23 Jan 2017 11:00:02 +0100 > >> Andrea Merello wrote: > >> > >>> From: Andrea Merello > >>> > >>> The standard DRM function to get the edid from the i2c bus performs > >>> (at least) two transfers. > >>> > >>> By experiments it seems that the sii9022a have problems with the > >>> 2nd I2C start, at least unless a wait is introduced detween the > >> > >> ^ between > >> > >>> two transfers. > >>> > >>> So we perform one single I2C transfer, and if the transfer must be > >>> split, then we introduce a delay. > >> > >> That's not exactly what this patch does: you're introducing a delay > >> between each retry. So, if the transceiver really requires a delay > >> between each transfer, you'll have to retry at least once on the 2nd > >> transfer. > >> > >> I guess a better solution would be to add a delay even in case of > >> success, or maybe modify drm_do_get_edid() to optionally wait for a > >> specified time between each transfer. > > > > Is the problem related specifically to EDID reads, or generally to I2C > > transfers? Perhaps this should be fixed at the adapter master_xfer layer > > instead? Does the master_xfer perhaps return -EAGAIN, have you looked > > into i2c_adapter timeout member? (See __i2c_transfer in i2c-core.c.) > > > > The intention of drm_do_get_edid() is to facilitate *alternative* > > methods to doing I2C, not to workaround quirks like this. Yes, I tend to agree with that. > > This problem seems not related to the I2C master itself. I saw the I2C > master to TX correctly by looking at the I2C bus before the sii9022a > with the scope, and I saw the same I2C transfer to be corrupted after > the sii9022a; actually the sii9022a seems to gate the bus damaging the > I2C start of the 2nd transfer, unless we place this delay. > > This happened with two different I2C master (the one on the SoC as > well as another different one implemented on FPGA). Actually, I faced the same problem on an at91-based platform, and came up with pretty much the same fix (add a delay after each transfer), except mine was uglier and I never took the time to clean it up and submit it. > > So IMHO this quirk should be done in the sii902x dirver. Said that, I > admit that I've not looked at i2c_adapter timeout member or other > details in upper layers. Well, let's sum up the situation: the sii902x device is acting both as a regular i2c device and as an i2c 'pass-through' device. In the pass-through mode, the si902x has a new constraint: the i2c transfers have to be separated by an idle period. Maybe we should expose the pass-through mode as separate i2c adapter, that would be registered when entering pass-through mode and de-registered when leaving this mode. This way, we can implement the ->master_xfer() as we need (add a delay after each xfer), and still use the generic drm_get_edid(). What do you think? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/exynos: use atomic helper commit
Inki Dae wrote:
>
>
> 2017년 01월 20일 22:05에 Tobias Jakobi 이(가) 쓴 글:
>> Inki Dae wrote:
>>> Hi Tobias,
>>>
>>> 2017년 01월 19일 21:49에 Tobias Jakobi 이(가) 쓴 글:
What about Laurent's comment stating that drm_atomic_helper_commit() is
broken at the moment? Shouldn't there be some kind of warning in the
commit message that this patch is only safe to apply once the fixes for
drm_atomic_helper_commit() have landed? I'm already seeing this getting
merged by accident, without Maarten's series even being reviewed.
>>>
>>> What patches you mean?
>> The patchset that Laurent mentioned.
>> [PATCH v3 0/7] drm/atomic: Add accessor macros for all atomic state.
>> https://www.spinics.net/lists/dri-devel/msg129537.html
>>
>>
>>> According to Laurent's comment, async commit support of
>>> drm_atomic_helper_commit is subect to a race condition.
>>> So I'm checking whether there is any case to use async commit in Exynos DRM
>>> driver.
>> I'm not sure what you're exactly checking here, because it is userspace
>> that requests a atomic commit to be executed asynchronously.
>
> Hm... See the below code from mainline,
>
> nt drm_mode_atomic_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv)
> {
> ...
>
> if ((arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) &&
> !dev->mode_config.async_page_flip)
> return -EINVAL;
> ...
>
> I'm not sure you checked Exynos drm driver but Exynos drm driver doesn't
> support async page flip.
> And you are right. userspace requests async commit but that is also depend on
> specific driver.
OK, I assumed that this mandatory by now. Nevermind then.
>>> As of now, I don't see any case. even without Maarten's patch set, it works
>>> well - actually, I had a test with atomic test app more than 10 hours..
>> Can you provide this test application? In particular I'm asking this
>> because libdrm currently doesn't provide any tests using the atomic API.
>> So this application might be of interest also for other people.
>
> Below is the app I tested. Know that this application is from chromiumOS tree
> and I just fixed some parts for internal test.
> https://review.tizen.org/git/?p=atform/upstream/libdrm.git;a=commitdiff;h�3bd95f2c5a9b4b69062a3ff008947054b94f55
Thanks, any chance this is going to be submitted upstream?
>>> And important thing is that this posting is just for review not merge.
>> In this case the patches should be tagged as 'RFC', something which I
>> don't see here.
>>
>>
>>> So if there is any critical problem with this patch, I will stop to merge
>>> it. This would be my role, maintainer.
>> Let me phrase it this way. Your patch is not fixing a bug, it is a
>
> This patch definitely phrased 'This patch replaces specific atomic commit
> function with atomic helper commit one' not fixing a bug.
Please read the sentences in full.
- Tobias
>
> Thanks.
>
>> cleanup patch that reduces driver specific code with DRM core code. But
>> as Laurent has pointed out this core code currently has some known (!)
>> issues. In the interest of not breaking anything I would advise against
>> merging this before Maarten's patches have landed.
>>
>>
>> With best wishes,
>> Tobias
>>
>>
>>>
>>> Thanks.
>>>
The commit message looks much better now. Still some spelling issues
remain:
implemention -> implementation
With best wishes,
Tobias
Inki Dae wrote:
> This patch replaces specific atomic commit function
> with atomic helper commit one.
>
> For this, it removes existing atomic commit function
> and relevant code specific to Exynos DRM and makes
> atomic helper commit to be used instead.
>
> Below are changes for the use of atomic helper commit:
> - add atomic_commit_tail callback specific to Exynos DRM
> . default implemention of atomic helper doesn't mesh well
> with runtime PM so the device driver which supports runtime
> PM should call drm_atomic_helper_commit_modeset_enables function
> prior to drm_atomic_helper_commit_planes function call.
> atomic_commit_tail callback implements this call ordering.
> - allow plane commit only in case that CRTC device is enabled.
> . for this, it calls atomic_helper_commit_planes function
> with DRM_PLANE_COMMIT_ACTIVE_ONLY flag in atomic_commit_tail callback.
>
> Changelog v1:
> - fix comment
> - fix trivial things
> - revive existing comment which explains why plane commit should be
> called after crtc and encoder device are enabled.
>
> Signed-off-by: Inki Dae
> Reviewed-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 10 ++-
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 109
> ---
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 32 -
> 3 files changed, 40 insertions(+), 11
Re: [PATCH] drm/exynos: g2d: fix overflow of cmdlist size
Joonyoung Shim wrote: > Hi Tobias, > > On 01/21/2017 01:05 AM, Tobias Jakobi wrote: >> Hello Joonyoung, >> >> >> Joonyoung Shim wrote: >>> Hi Tobias, >>> >>> On 01/19/2017 10:16 PM, Tobias Jakobi wrote: Hello Joonyoung, Joonyoung Shim wrote: > Hi Tobias, > > On 01/17/2017 11:24 PM, Tobias Jakobi wrote: >> Joonyoung Shim wrote: >>> The size of cmdlist is integer type, so it can be overflowed by cmd and >>> cmd_buf that has too big size. This patch will fix overflow issue as >>> checking maximum size of cmd and cmd_buf. >> I don't understand/see the issue here. Could you point out for which >> input of the set_cmdlist ioctl you see this particular overflow? >> >> In particular it is not clear to me which size field you're talking >> about. struct g2d_cmdlist does not have any field named 'size'. >> > > I mean size of cmdlist is > size = cmdlist->last + req->cmd_nr * 2 + req->cmd_buf_nr * 2 + 2; > in exynos_g2d_set_cmdlist_ioctl(). ok, that makes things more clear. But then you need to fix the commit message. The current message implies that this 'size' you're talking about is some property of the cmdlist. Also the new comment is wrong. /* Check size of cmd and cmdlist: last 2 is about G2D_BITBLT_START */ What is cmd and cmdlist? You're mixing two different things here. We are still checking the size of 'cmdlist' (which is a struct g2d_cmdlist) here. What you add is a check for the fields of 'req' (which is a struct drm_exynos_g2d_set_cmdlist). With all that said, I don't like the changes. I see the issue, but the current solution should be cleaner. I propose this. We just check req->cmd_buf_nr and req->cmd_nr against G2D_CMDLIST_DATA_NUM. This leaves us enough headrom so that the later computation (i.e. what is ending up in the local variable 'size') can never overflow. >>> >>> Agree, it's more clear to check req->cmd_buf_nr and req->cmd_nr against >>> G2D_CMDLIST_DATA_NUM. >>> For a comment for the check I propose this: "To avoid an integer overflow for the later size computations, we enforce a maximum number of submitted commands here. This limit is sufficient for all conceivable usage cases of the G2D." >>> >>> Could you post your patch to ML about this if you want? >> Sure, I've just send it together with two other small patches. Let me >> know if the current version is OK with you. I hope I did the order of >> SoB correctly (I know that Krzysztof has pointed this out lately). >> > > I don't know exactly about order of SoB but it's ok to me except > WARNING: line over 80 characters from checkpatch.pl. Thanks for checking! I guess I should accustom myself to using checkpath more regularly. - Tobias > > Thanks for posting. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 19/26] drm/rockchip: dw-mipi-dsi: improve PLL configuration
Hi Chris,
On Mon, 23 Jan 2017 09:38:54 +0800, Chris Zhong wrote:
> On 01/22/2017 12:31 AM, John Keeping wrote:
> > The multiplication ratio for the PLL is required to be even due to the
> > use of a "by 2 pre-scaler". Currently we are likely to end up with an
> > odd multiplier even though there is an equivalent set of parameters with
> > an even multiplier.
> >
> > For example, using the 324MHz bit rate with a reference clock of 24MHz
> > we end up with M = 27, N = 2 whereas the example in the PHY databook
> > gives M = 54, N = 4 for this bit rate and reference clock.
> >
> > By walking down through the available multiplier instead of up we are
> > more likely to hit an even multiplier. With the above example we do now
> > get M = 54, N = 4 as given by the databook.
> >
> > While doing this, change the loop limits to encode the actual limits on
> > the divisor, which are:
> >
> > 40MHz >= (pllref / N) >= 5MHz
>
> This formula is limit for N, but we still can not guarantee to get an
> even M.
> Do you think we should do a check for M.
> such as:
> if (m % 2)
> continue;
> ...
> for (i = pllref / 5; i > (pllref / 40); i--) {
> pre = pllref / i;
> if ((tmp > (target_mbps % pre)) && (target_mbps / pre < 512)) {
> tmp = target_mbps % pre;
> n = i;
> m = target_mbps / pre;
> if (m % 2)
> continue;
> }
> if (tmp == 0)
> break;
> }
>
> if (m % 2)
> m++;
>
> dsi->lane_mbps = pllref / n * m;
> dsi->input_div = n;
> dsi->feedback_div = m;
Yes, I agree that there should be a check for M, but I'm not sure if
the version above is sufficient. The "m % 2" check inside the loop
means that we don't break immediately when tmp=0 but then we are
guaranteed to break next time without having modified n, m because now
tmp=0 so "tmp > (target_mbps % pre)" is always false and we just hit the
"if (tmp == 0) break" case next time.
Given that the descending loop already means that if we can hit "tmp"
exactly we are more likely to do so with a bigger N and even M, I think
it might be better to just fix M after the loop like:
if (m % 2) {
if (m < 256 && (n * 2) <= (pllref / 5)) {
n *= 2;
m *= 2;
} else {
m++;
}
}
but I haven't thought about this too carefully.
For this series, I'd rather either keep this patch as it is or drop it
in favour of a more comprehensive solution. I don't want to block the
other fixes waiting for a perfect fix here and we can always improve
this further with a follow-up patch.
> > Signed-off-by: John Keeping
> > ---
> > Unchanged in v2
> > ---
> > drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > index 12432e41971b..f2320cf1366c 100644
> > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > @@ -519,7 +519,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi
> > *dsi,
> > pllref = DIV_ROUND_UP(clk_get_rate(dsi->pllref_clk), USEC_PER_SEC);
> > tmp = pllref;
> >
> > - for (i = 1; i < 6; i++) {
> > + for (i = pllref / 5; i > (pllref / 40); i--) {
> > pre = pllref / i;
> > if ((tmp > (target_mbps % pre)) && (target_mbps / pre < 512)) {
> > tmp = target_mbps % pre;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99504] Victor Vran and Tropico 5 flicker when refresh rate is above 60 Hz
https://bugs.freedesktop.org/show_bug.cgi?id=99504 Bug ID: 99504 Summary: Victor Vran and Tropico 5 flicker when refresh rate is above 60 Hz Product: Mesa Version: 17.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: freedesktop@lanig.email QA Contact: dri-devel@lists.freedesktop.org Both games don't go above 60Hz with resolutions over 1080p on my setup but I will report this to the devs. Just for the case you like to reproduce the issue. With the newest driver version from the Padoka PPA, RX 480 and EIZO FS-2735 flickering happens when the refresh rate is set to 119Hz or 143Hz. (Ingame settings in Tropico and xrandr for Victor Vran). As far as I remember this happend also in the beginning, has been fixed at some point(but I am not 100% sure) and now happens again. The desktop doesn't suffer the same issue. OpenGL version string: 3.0 Mesa 17.1.0-devel - padoka PPA -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99499] [REGRESSION, bisected] KMS hard-freezes around fbcon initialization on NV1A
https://bugs.freedesktop.org/show_bug.cgi?id=99499 Ilia Mirkin changed: What|Removed |Added Component|DRM/other |Driver/nouveau Product|DRI |xorg QA Contact||xorg-t...@lists.x.org Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o |.org|rg -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: sii902x: fix get edid may fail
On Mon, Jan 23, 2017 at 1:36 PM, Boris Brezillon wrote: > On Mon, 23 Jan 2017 13:12:12 +0100 > Andrea Merello wrote: > >> On Mon, Jan 23, 2017 at 12:32 PM, Jani Nikula >> wrote: >> > On Mon, 23 Jan 2017, Boris Brezillon >> > wrote: >> >> Hi Andrea, >> >> >> >> On Mon, 23 Jan 2017 11:00:02 +0100 >> >> Andrea Merello wrote: >> >> >> >>> From: Andrea Merello >> >>> >> >>> The standard DRM function to get the edid from the i2c bus performs >> >>> (at least) two transfers. >> >>> >> >>> By experiments it seems that the sii9022a have problems with the >> >>> 2nd I2C start, at least unless a wait is introduced detween the >> >> >> >> ^ between >> >> >> >>> two transfers. >> >>> >> >>> So we perform one single I2C transfer, and if the transfer must be >> >>> split, then we introduce a delay. >> >> >> >> That's not exactly what this patch does: you're introducing a delay >> >> between each retry. So, if the transceiver really requires a delay >> >> between each transfer, you'll have to retry at least once on the 2nd >> >> transfer. >> >> >> >> I guess a better solution would be to add a delay even in case of >> >> success, or maybe modify drm_do_get_edid() to optionally wait for a >> >> specified time between each transfer. >> > >> > Is the problem related specifically to EDID reads, or generally to I2C >> > transfers? Perhaps this should be fixed at the adapter master_xfer layer >> > instead? Does the master_xfer perhaps return -EAGAIN, have you looked >> > into i2c_adapter timeout member? (See __i2c_transfer in i2c-core.c.) >> > >> > The intention of drm_do_get_edid() is to facilitate *alternative* >> > methods to doing I2C, not to workaround quirks like this. > > Yes, I tend to agree with that. > >> >> This problem seems not related to the I2C master itself. I saw the I2C >> master to TX correctly by looking at the I2C bus before the sii9022a >> with the scope, and I saw the same I2C transfer to be corrupted after >> the sii9022a; actually the sii9022a seems to gate the bus damaging the >> I2C start of the 2nd transfer, unless we place this delay. >> >> This happened with two different I2C master (the one on the SoC as >> well as another different one implemented on FPGA). > > Actually, I faced the same problem on an at91-based platform, and came > up with pretty much the same fix (add a delay after each transfer), > except mine was uglier and I never took the time to clean it up and > submit it. > >> >> So IMHO this quirk should be done in the sii902x dirver. Said that, I >> admit that I've not looked at i2c_adapter timeout member or other >> details in upper layers. > > Well, let's sum up the situation: the sii902x device is acting both as > a regular i2c device and as an i2c 'pass-through' device. In the > pass-through mode, the si902x has a new constraint: the i2c transfers > have to be separated by an idle period. > > Maybe we should expose the pass-through mode as separate i2c adapter, > that would be registered when entering pass-through mode and > de-registered when leaving this mode. > This way, we can implement the ->master_xfer() as we need (add a delay > after each xfer), and still use the generic drm_get_edid(). > > What do you think? IMHO this could be a good way to go.. Although honestly the current quirk doesn't seem so much bad to me :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99392] Ark survival evolved won't start
https://bugs.freedesktop.org/show_bug.cgi?id=99392 --- Comment #3 from Obiwan72 --- maybe it helps to force Steam to use a specific OpenGL version. Start Steam from the command prompt, enforcing OpenGL 3.3: $>MESA_GL_VERSION_OVERRIDE=3.3COMPAT steam Then try start Ark again from your steam client. This way I can start Ark. Unfortunately all living creatures are invisible... Still searching for a workaround to make animals visible again. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99078] Desktop icons oversaturated with red after December 11 2016 update
https://bugs.freedesktop.org/show_bug.cgi?id=99078 --- Comment #27 from Nicolai Hähnle --- I can reproduce this now. Setting R600_DEBUG=mono in the environment of the X server works around the problem. I'm still trying to understand the exact problem and why it wasn't caught by piglit testing. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99078] Desktop icons oversaturated with red after December 11 2016 update
https://bugs.freedesktop.org/show_bug.cgi?id=99078 --- Comment #28 from Matt Whitlock --- (In reply to Nicolai Hähnle from comment #27) > R600_DEBUG=mono Does this workaround have any negative consequences (e.g., performance regressions), or is it suitable for use in a daily-driver environment? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off
https://bugs.freedesktop.org/show_bug.cgi?id=99418 --- Comment #22 from lei.p...@gmail.com --- (In reply to Michel Dänzer from comment #21) > (In reply to lei.pero from comment #18) > > I didn't know that about modesetting driver, anyway, even with > > LIBGL_DRI3_DISABLE=1 same thing happens. > > Maybe chromium doesn't pass on the environment variable to its GPU helper > process, or maybe there was still a chromium process around. > > > > I don't how to disable tripple buffering to test it and if it's possible, > > Only by changing the code, > mesa/src/loader/loader_dri3_helper.c:dri3_update_num_back(). E.g. set > num_back = 1 in the else case. Ok, I've built mesa with that parameter changed and installed, same behavior. I've cloned just "git://anongit.freedesktop.org/git/mesa/mesa" , it should be enough. On the side note, if default is glamor, EXA definitively works better on my config (not huge difference, but there is difference). I will try to investiate more, but I'm really not sure where to look. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99078] Desktop icons oversaturated with red after December 11 2016 update
https://bugs.freedesktop.org/show_bug.cgi?id=99078 --- Comment #29 from Nicolai Hähnle --- It's almost certainly because we missed 01a133c760ebb8db1e204f76ba55c19558b1ce01 "AMDGPU: Do not clobber SCC in SIWholeQuadMode" when back-porting -- probably because that one is not straight-forward at all to back-port. The best course of action would indeed be to revert that commit; IIRC it fixes a bug in Kodi, but the impact of that is much less than widespread weird tints. The part that really sucks is that I don't think an LLVM 3.9.2 is planned. We need to keep an eye out on whether this causes a problem in any distribution default installation. FWIW, I haven't seen a problem in Ubuntu 16.10 even though it does have LLVM 3.9.1, probably because the default installation of Mesa is ancient. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] dt: add bindings for ZTE tvenc device
On Fri, Jan 20, 2017 at 12:24:59AM +0800, Shawn Guo wrote: > From: Shawn Guo > > It adds bindings doc for ZTE VOU TV Encoder device. > > Signed-off-by: Shawn Guo > --- > Documentation/devicetree/bindings/display/zte,vou.txt | 15 +++ > 1 file changed, 15 insertions(+) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99078] Desktop icons oversaturated with red after December 11 2016 update
https://bugs.freedesktop.org/show_bug.cgi?id=99078 --- Comment #30 from Nicolai Hähnle --- Re Matt, comment #28, that setting can result in more time spent on shader compiles. I don't think those are an issue in typical X server loads. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/exynos: use atomic helper commit
> >>> As of now, I don't see any case. even without Maarten's patch set, it > >>> works well - actually, I had a test with atomic test app more than 10 > >>> hours.. > >> Can you provide this test application? In particular I'm asking this > >> because libdrm currently doesn't provide any tests using the atomic API. > >> So this application might be of interest also for other people. > > > > Below is the app I tested. Know that this application is from chromiumOS > > tree and I just fixed some parts for internal test. > > https://review.tizen.org/git/?p=atform/upstream/libdrm.git;a=commitdiff;h�3bd95f2c5a9b4b69062a3ff008947054b94f55 > Thanks, any chance this is going to be submitted upstream? > Probably not in its current form. I just wrote it to quickly test out some stuff we didn't yet support in CrOS. I don't really think it's fit for inclusion upstream. Sean ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
