[git pull] drm fixes

[Dave Airlie]

Hi Linus,

a bunch of fixes across drivers,
radeon: disable two ended allocation for now, it breaks some stuff
amdkfd: misc fixes
nouveau: fix irq loop problem, add basic support for GM206 (new hw)
i915: fix some WARNs people were seeing
exynos: fix some iommu interactions causing boot failures

In other news I've some problem with my git tree and git request-pull
[airlied at dreadlord-bne-redhat-com linux]$ git request-pull linus/master 
origin
warn: No match for commit 8265d4486d5c2448a1c645fdc20d4e62873d9c3d found at 
origin
warn: Are you sure you pushed 'HEAD' there?

is happening when I just had my branch on drm-fixes, I've made it master
to generate this pull request so the branch name isn't missing, this
might be due to my attempt to remove my own master branch, using 
git symbolic-ref HEAD refs/heads/drm-next, so I'll have to regen it next
week I suppose.

Dave.

The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda:

  Linux 4.0-rc4 (2015-03-15 17:38:20 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux 

for you to fetch changes up to 8265d4486d5c2448a1c645fdc20d4e62873d9c3d:

  Merge tag 'drm-intel-fixes-2015-03-19' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-03-20 17:32:21 
+1000)


Alex Deucher (1):
  drm/radeon: drop ttm two ended allocation

Andrzej Hajda (1):
  drm/exynos: remove unused files

Ben Goz (3):
  drm/amdkfd: destroy mqd when destroying kernel queue
  drm/amdkfd: Fix SDMA queue init. in non-HWS mode
  drm/radeon: Changing number of compute pipe lines

Ben Skeggs (3):
  drm/nouveau/fifo/nv04: remove the loop from the interrupt handler
  drm/nouveau/gr/gf100: fix some accidental or'ing of buffer addresses
  drm/nouveau/device: post write to NV_PMC_BOOT_1 when flipping endian 
switch

Charles Keepax (1):
  drm/exynos: Check for NULL dereference of crtc

Damien Lespiau (1):
  drm/i915: Make sure the primary plane is enabled before reading out the 
fb state

Dan Carpenter (1):
  drm/exynos: IS_ERR() vs NULL bug

Dave Airlie (5):
  Merge branch 'linux-4.0' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
  Merge branch 'exynos-drm-fixes' of 
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes
  Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge tag 'drm-amdkfd-fixes-2015-03-19' of 
git://people.freedesktop.org/~gabbayo/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2015-03-19' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes

Hyungwon Hwang (1):
  drm/exynos: fix the initialization order in FIMD

Inki Dae (1):
  drm/exynos: fix typo config name correctly.

Stefan Huehner (2):
  drm/nouveau/device/gm100: Basic GM206 bring up (as copy of GM204)
  drm/nouveau/bios: fix i2c table parsing for dcb 4.1

Xi Ruoyao (1):
  drm/i915: Ensure plane->state->fb stays in sync with plane->fb

 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |  10 +-
 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c  |  22 +-
 drivers/gpu/drm/exynos/Kconfig |   2 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_connector.c  | 245 -
 drivers/gpu/drm/exynos/exynos_drm_connector.h  |  20 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  29 +--
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |   2 +-
 drivers/gpu/drm/i915/intel_display.c   |  32 ++-
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |   6 +-
 drivers/gpu/drm/nouveau/nvkm/engine/device/gm100.c |  43 
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv04.c|  85 +++
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c  |   4 +-
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c  |   4 +-
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c  |   4 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/i2c.c |   6 +-
 drivers/gpu/drm/radeon/radeon_kfd.c|   2 +-
 drivers/gpu/drm/radeon/radeon_object.c |  11 -
 18 files changed, 159 insertions(+), 372 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_connector.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_connector.h

[PATCH libdrm] android: remove explicit include to libpciaccess

[Emil Velikov]

Both android-x86 and android-ia versions of libpciacccess correctly
"export" the include. If anyone else is wrapping up their own version
they should do so as well.

Remove this fixed location hack from the build.

Cc: Chih-Wei Huang 
Signed-off-by: Emil Velikov 
---
 intel/Android.mk | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/intel/Android.mk b/intel/Android.mk
index 0f498ec..6582dfd 100644
--- a/intel/Android.mk
+++ b/intel/Android.mk
@@ -33,9 +33,6 @@ LOCAL_MODULE_TAGS := optional
 LOCAL_SRC_FILES := $(LIBDRM_INTEL_FILES)
 LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)

-LOCAL_C_INCLUDES := \
-   external/libpciaccess/include
-
 LOCAL_CFLAGS := \
-DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1

-- 
2.3.1

[Bug 89034] Firefox crashing xserver and some major rendering bugs

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

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

--- Comment #41 from smoki  ---
 Tried svn232842 with subreg liveness enabled + mesa
a04b520890c669ce012b4b18165392dcabe0b27b

 Nothing, still same bugs are there.

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

[PATCH libdrm 9/8] Remove drmSetDebugMsgFunction and related infrastructure

[Emil Velikov]

On 18 March 2015 at 18:37, Jan Vesely  wrote:
> Not used anywhere
>
Some information from my digging around:

Function was added with commit 79038751ffe(libdrm: add support for
server side functionality in libdrm).
It's not referenced even once in the history of the following projects
 - xserver
 - plymouth
 - mesa
 - xf86-video-ati
  -xf86-video-freedreno
 - xf86-video-i128
 - xf86-video-i740
 - xf86-video-intel
 - xf86-video-mach64
 - xf86-video-mga
 - xf86-video-nouveau
 - xf86-video-r128
 - xf86-video-tdfx
 - xf86-video-savage
 - xf86-video-sis
 - xf86-video-via

So I'm pretty confident that we're safe to nuke it. The above ddx list
should consist of all the drivers/hardware that was ever officially
supported by drm - from dri1 era until now.

Reviewed-by: Emil Velikov 

-Emil

[PATCH 05/45] drm.h: include stdlib.h in userspace

[Emil Velikov]

On 23 February 2015 at 10:35, Mikko Rapeli  wrote:
> On Mon, Feb 23, 2015 at 10:26:58AM +, Emil Velikov wrote:
>> On 16/02/15 23:05, Mikko Rapeli wrote:
>> > Fixes  compilation error:
>> >
>> > drm/drm.h:132:2: error: unknown type name ‘size_t’
>> >
>> Hi Mikko,
>>
>> Can you let us know how you're getting these (series-wise) errors ? I've
>> been meaning to sync the uapi/drm and libdrm headers and would be nice
>> to have an extra step to test things.
>
> This should have everything needed to reproduce these compile errors,
> though some of the errors hide behind other errors and fixes:
>
> https://lkml.org/lkml/2015/2/16/525
>
Thanks for the link Mikko.

Afaict the general consensus seems to be that one should avoid using
stdint's uint8_t, but stick to __u8 and friends. Did you had the
chance to roll out another series that does so ?

That aside I'm not 100% sure that doing the UAPI split, as is, was the
perfect solution. Afaik drm used to live as an out of tree userspace
library(libdrm). Not sure at which point the major restructuring took
part, but one is certain - libdrm remains the only authoritative
sources of the headers. It's possible that some buggy programs pull
the UAPI headers while linking against the library, but I'd say that
won't end up well in the long term. Additionally since the UAPI split
the `make update-headers' target used to sync libdrm's headers have
been broken leading people to copy misc. hunks and/or files. Leading
to greater chance of things going sour.

All that said, I will need to gather some opinions for drm developers
and maintainers if the idea of part revering 718dcedd7e8(UAPI:
(Scripted) Disintegrate include/drm) will be the way forward.

Thanks
Emil

[RFC v3 5/9] cec: add new driver for cec support.

[Hans Verkuil]

Hi Kamil,

Once again thank you for continuing this work!

I do have some comments, see below.

On 03/20/2015 05:52 PM, Kamil Debski wrote:
> Add the CEC framework.
> 
> Signed-off-by: Hans Verkuil 
> [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
> [k.debski at samsung.com: Merged Update author commit by Hans Verkuil]
> [k.debski at samsung.com: change kthread handling when setting logical
> address]
> [k.debski at samsung.com: code cleanup and fixes]
> [k.debski at samsung.com: add missing CEC commands to match spec]
> [k.debski at samsung.com: add RC framework support]
> [k.debski at samsung.com: move and edit documentation]
> [k.debski at samsung.com: add vendor id reporting]
> [k.debski at samsung.com: add promiscuous mode]
> [k.debski at samsung.com: add possibility to clear assigned logical
> addresses]
> Signed-off-by: Kamil Debski 
> ---
>  Documentation/cec.txt|  321 +
>  drivers/media/Kconfig|6 +
>  drivers/media/Makefile   |2 +
>  drivers/media/cec.c  | 1158 
> ++
>  include/media/cec.h  |  137 ++
>  include/uapi/linux/cec.h |  283 +++
>  6 files changed, 1907 insertions(+)
>  create mode 100644 Documentation/cec.txt
>  create mode 100644 drivers/media/cec.c
>  create mode 100644 include/media/cec.h
>  create mode 100644 include/uapi/linux/cec.h
> 
> diff --git a/Documentation/cec.txt b/Documentation/cec.txt
> new file mode 100644
> index 000..e96fcc0
> --- /dev/null
> +++ b/Documentation/cec.txt
> @@ -0,0 +1,321 @@
> +CEC Kernel Support
> +==
> +
> +The CEC framework provides a unified kernel interface for use with HDMI CEC
> +hardware. It is designed to handle a multiple variants of hardware. Adding to
> +the flexibility of the framework it enables to set which parts of the CEC
> +protocol processing is handled by the hardware, by the driver and by the
> +userspace application.
> +
> +
> +The CEC Protocol
> +
> +
> +The CEC protocol enables cosumer electronic devices to communicate with each

cosumer -> consumer

> +other through the HDMI connection. The protocol uses logical addresses in the
> +communication. The logical address is strictly connected with the 
> functionality
> +provided by the device. The TV acting as the communication hub is always
> +assigned address 0. The physicall addressis determined by physical connection

'physicall addressis' -> 'physical address is'
s/by/by the/

> +between devices.
> +
> +The protocol enables control of compatible devices with a single remote.
> +Synchronous power on/standby, instant playback with changing the content 
> source
> +on the TV.
> +
> +The Kernel Interface
> +
> +
> +CEC Adaptor

s/Adaptor/Adapter/

> +---
> +
> +#define CEC_LOG_ADDR_INVALID 0xff
> +
> +/* The maximum number of logical addresses one device can be assigned to.
> + * The CEC 2.0 spec allows for only 2 logical addresses at the moment. The
> + * Analog Devices CEC hardware supports 3. So let's go wild and go for 4. */
> +#define CEC_MAX_LOG_ADDRS 4
> +
> +/* The "Primary Device Type" */
> +#define CEC_PRIM_DEVTYPE_TV  0
> +#define CEC_PRIM_DEVTYPE_RECORD  1
> +#define CEC_PRIM_DEVTYPE_TUNER   3
> +#define CEC_PRIM_DEVTYPE_PLAYBACK4
> +#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM 5
> +#define CEC_PRIM_DEVTYPE_SWITCH  6
> +#define CEC_PRIM_DEVTYPE_VIDEOPROC   7
> +
> +/* The "All Device Types" flags (CEC 2.0) */
> +#define CEC_FL_ALL_DEVTYPE_TV(1 << 7)
> +#define CEC_FL_ALL_DEVTYPE_RECORD(1 << 6)
> +#define CEC_FL_ALL_DEVTYPE_TUNER (1 << 5)
> +#define CEC_FL_ALL_DEVTYPE_PLAYBACK  (1 << 4)
> +#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM   (1 << 3)
> +#define CEC_FL_ALL_DEVTYPE_SWITCH(1 << 2)
> +/* And if you wondering what happened to VIDEOPROC devices: those should
> + * be mapped to a SWITCH. */
> +
> +/* The logical address types that the CEC device wants to claim */
> +#define CEC_LOG_ADDR_TYPE_TV 0
> +#define CEC_LOG_ADDR_TYPE_RECORD 1
> +#define CEC_LOG_ADDR_TYPE_TUNER  2
> +#define CEC_LOG_ADDR_TYPE_PLAYBACK   3
> +#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM4
> +#define CEC_LOG_ADDR_TYPE_SPECIFIC   5
> +#define CEC_LOG_ADDR_TYPE_UNREGISTERED   6
> +/* Switches should use UNREGISTERED.
> + * Video processors should use SPECIFIC. */
> +
> +/* The CEC version */
> +#define CEC_VERSION_1_4B 5
> +#define CEC_VERSION_2_0  6
> +
> +struct cec_adapter {
> + /* internal fields removed */
> +
> + u16 phys_addr;
> + u32 capabilities;
> + u8 version;
> + u8 num_log_addrs;
> + u8 prim_device[CEC_MAX_LOG_ADDRS];
> + u8 log_addr_type[CEC_MAX_LOG_ADDRS];
> + u8 log_addr[CEC_MAX_LOG_ADDRS];
> +
> + int (*adap_enable)(struct cec_adapter *adap, bool enable);
> + int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
> + int 

[PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

[Javi Merino]

On Fri, Mar 20, 2015 at 06:19:26PM +, Emil Velikov wrote:
> On 20 March 2015 at 11:14, Javi Merino  wrote:
> > We have grown a number of different implementations of
> > DIV_ROUND_CLOSEST_ULL throughout the kernel.  Move the i915 one to
> > kernel.h so that it can be reused.
> >
> > Cc: Daniel Vetter 
> > Cc: Jani Nikula 
> > Cc: David Airlie 
> > Cc: Darrick J. Wong 
> > Cc: Guenter Roeck 
> > Cc: Andrew Morton 
> > Signed-off-by: Javi Merino 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h |  4 +---
> >  include/linux/kernel.h   | 11 +++
> >  2 files changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index eef79ccd0b7c..346e28fdd7dd 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -28,6 +28,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> Hi Javi,
> 
> Small suggestion - can we include the header only where needed ?
> i915/intel_panel.c seems to be the only user of DIV_ROUND_CLOSEST
> which will need an update.
> 
> Somewhat trivial pick but it will prevent ~40 unnecessary dives in kernel.h.

Sure, I'll fix it in the next version of the series.

Cheers,
Javi

[PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

[Emil Velikov]

On 20 March 2015 at 11:14, Javi Merino  wrote:
> We have grown a number of different implementations of
> DIV_ROUND_CLOSEST_ULL throughout the kernel.  Move the i915 one to
> kernel.h so that it can be reused.
>
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: David Airlie 
> Cc: Darrick J. Wong 
> Cc: Guenter Roeck 
> Cc: Andrew Morton 
> Signed-off-by: Javi Merino 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |  4 +---
>  include/linux/kernel.h   | 11 +++
>  2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index eef79ccd0b7c..346e28fdd7dd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
Hi Javi,

Small suggestion - can we include the header only where needed ?
i915/intel_panel.c seems to be the only user of DIV_ROUND_CLOSEST
which will need an update.

Somewhat trivial pick but it will prevent ~40 unnecessary dives in kernel.h.

Cheers,
Emil

[PATCH libdrm 1/1] tests/exynos: Fix warnings

[Jan Vesely]

On Wed, 2015-03-18 at 20:23 +0100, Tobias Jakobi wrote:
> Hello Jan,
> 
> Jan Vesely wrote:
> > Signed-off-by: Jan Vesely 
> > ---
> >  tests/exynos/exynos_fimg2d_test.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tests/exynos/exynos_fimg2d_test.c 
> > b/tests/exynos/exynos_fimg2d_test.c
> > index e7d9b72..dfb34ac 100644
> > --- a/tests/exynos/exynos_fimg2d_test.c
> > +++ b/tests/exynos/exynos_fimg2d_test.c
> > @@ -183,7 +183,7 @@ static struct exynos_bo *exynos_create_buffer(struct 
> > exynos_device *dev,
> >  
> >  /* Allocate buffer and fill it with checkerboard pattern, where the tiles *
> >   * have a random color. The caller has to free the buffer.
> > */
> > -void *create_checkerboard_pattern(unsigned int num_tiles_x,
> > +static void *create_checkerboard_pattern(unsigned int num_tiles_x,
> > unsigned int num_tiles_y, 
> > unsigned int tile_size)
> >  {
> > unsigned int *buf;
> Good catch with the missing static!

May I consider this a R-b for this change?
I have moved the switch-enum fix to a separate patch (that covers all
switch-enum warnings)

jan

> 
> 
> > @@ -573,6 +573,7 @@ static int g2d_checkerboard_test(struct exynos_device 
> > *dev,
> > src_img.user_ptr[0].userptr = (unsigned long)checkerboard;
> > src_img.user_ptr[0].size = img_w * img_h * 4;
> > break;
> > +   case G2D_IMGBUF_COLOR:
> > default:
> > ret = -EFAULT;
> > goto fail;
> > 
> Hmm, I don't see the reason why this label should be added to the switch
> statement?
> 
> With best wishes,
> Tobias
> 

-- 
Jan Vesely 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150320/159baaa6/attachment.sig>

[PATCH libdrm 4/4] drmSL: Remove test parts

[Jan Vesely]

Signed-off-by: Jan Vesely 
---
 xf86drmSL.c | 172 +++-
 1 file changed, 6 insertions(+), 166 deletions(-)

diff --git a/xf86drmSL.c b/xf86drmSL.c
index cf588ac..bb9ca7f 100644
--- a/xf86drmSL.c
+++ b/xf86drmSL.c
@@ -41,13 +41,7 @@
 #include 
 #include 

-#define SL_MAIN 0
-
-#if !SL_MAIN
-# include "xf86drm.h"
-#else
-# include 
-#endif
+#include "xf86drm.h"

 #define SL_LIST_MAGIC  0xfacade00LU
 #define SL_ENTRY_MAGIC 0x00fab1edLU
@@ -56,21 +50,10 @@
 #define SL_DEBUG   0
 #define SL_RANDOM_SEED 0xc01055a1LU

-#if SL_MAIN
-#define SL_ALLOC malloc
-#define SL_FREE  free
-#define SL_RANDOM_DECLstatic int state = 0;
-#define SL_RANDOM_INIT(seed)  if (!state) { srandom(seed); ++state; }
-#define SL_RANDOM random()
-#else
-#define SL_ALLOC drmMalloc
-#define SL_FREE  drmFree
 #define SL_RANDOM_DECLstatic void *state = NULL
 #define SL_RANDOM_INIT(seed)  if (!state) state = drmRandomCreate(seed)
 #define SL_RANDOM drmRandom(state)

-#endif
-
 typedef struct SLEntry {
 unsigned long magic;  /* SL_ENTRY_MAGIC */
 unsigned long key;
@@ -87,27 +70,13 @@ typedef struct SkipList {
 SLEntryPtr   p0;   /* Position for iteration */
 } SkipList, *SkipListPtr;

-#if SL_MAIN
-extern void *drmSLCreate(void);
-extern int  drmSLDestroy(void *l);
-extern int  drmSLLookup(void *l, unsigned long key, void **value);
-extern int  drmSLInsert(void *l, unsigned long key, void *value);
-extern int  drmSLDelete(void *l, unsigned long key);
-extern int  drmSLNext(void *l, unsigned long *key, void **value);
-extern int  drmSLFirst(void *l, unsigned long *key, void **value);
-extern void drmSLDump(void *l);
-extern int  drmSLLookupNeighbors(void *l, unsigned long key,
-unsigned long *prev_key, void **prev_value,
-unsigned long *next_key, void **next_value);
-#endif
-
 static SLEntryPtr SLCreateEntry(int max_level, unsigned long key, void *value)
 {
 SLEntryPtr entry;

 if (max_level < 0 || max_level > SL_MAX_LEVEL) max_level = SL_MAX_LEVEL;

-entry = SL_ALLOC(sizeof(*entry)
+entry = drmMalloc(sizeof(*entry)
 + (max_level + 1) * sizeof(entry->forward[0]));
 if (!entry) return NULL;
 entry->magic  = SL_ENTRY_MAGIC;
@@ -134,7 +103,7 @@ void *drmSLCreate(void)
 SkipListPtr  list;
 int  i;

-list   = SL_ALLOC(sizeof(*list));
+list   = drmMalloc(sizeof(*list));
 if (!list) return NULL;
 list->magic= SL_LIST_MAGIC;
 list->level= 0;
@@ -158,11 +127,11 @@ int drmSLDestroy(void *l)
if (entry->magic != SL_ENTRY_MAGIC) return -1; /* Bad magic */
next = entry->forward[0];
entry->magic = SL_FREED_MAGIC;
-   SL_FREE(entry);
+   drmFree(entry);
 }

 list->magic = SL_FREED_MAGIC;
-SL_FREE(list);
+drmFree(list);
 return 0;
 }

@@ -236,7 +205,7 @@ int drmSLDelete(void *l, unsigned long key)
 }

 entry->magic = SL_FREED_MAGIC;
-SL_FREE(entry);
+drmFree(entry);

 while (list->level && !list->head->forward[list->level]) --list->level;
 --list->count;
@@ -348,132 +317,3 @@ void drmSLDump(void *l)
}
 }
 }
-
-#if SL_MAIN
-static void print(SkipListPtr list)
-{
-unsigned long key;
-void  *value;
-
-if (drmSLFirst(list, , )) {
-   do {
-   printf("key = %5lu, value = %p\n", key, value);
-   } while (drmSLNext(list, , ));
-}
-}
-
-static double do_time(int size, int iter)
-{
-SkipListPtrlist;
-inti, j;
-unsigned long  keys[100];
-unsigned long  previous;
-unsigned long  key;
-void   *value;
-struct timeval start, stop;
-double usec;
-SL_RANDOM_DECL;
-
-SL_RANDOM_INIT(12345);
-
-list = drmSLCreate();
-
-for (i = 0; i < size; i++) {
-   keys[i] = SL_RANDOM;
-   drmSLInsert(list, keys[i], NULL);
-}
-
-previous = 0;
-if (drmSLFirst(list, , )) {
-   do {
-   if (key <= previous) {
-   printf( "%lu !< %lu\n", previous, key);
-   }
-   previous = key;
-   } while (drmSLNext(list, , ));
-}
-
-gettimeofday(, NULL);
-for (j = 0; j < iter; j++) {
-   for (i = 0; i < size; i++) {
-   if (drmSLLookup(list, keys[i], ))
-   printf("Error %lu %d\n", keys[i], i);
-   }
-}
-gettimeofday(, NULL);
-
-usec = (double)(stop.tv_sec * 100 + stop.tv_usec
-   - start.tv_sec * 100 - start.tv_usec) / (size * iter);
-
-printf("%0.2f microseconds for list length %d\n", usec, size);
-
-drmSLDestroy(list);
-
-return usec;
-}
-
-static void print_neighbors(void *list, unsigned long key)
-{
-unsigned long prev_key = 0;
-unsigned long next_key = 0;
-void  *prev_value;
-

[PATCH libdrm 3/4] drmsltest: Check expected neighbours

[Jan Vesely]

Signed-off-by: Jan Vesely 
---
 tests/drmsltest.c | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/tests/drmsltest.c b/tests/drmsltest.c
index d193008..d871fbf 100644
--- a/tests/drmsltest.c
+++ b/tests/drmsltest.c
@@ -106,7 +106,9 @@ static double do_time(int size, int iter)
 return usec;
 }

-static void print_neighbors(void *list, unsigned long key)
+static void print_neighbors(void *list, unsigned long key,
+unsigned long expected_prev,
+unsigned long expected_next)
 {
 unsigned long prev_key = 0;
 unsigned long next_key = 0;
@@ -119,6 +121,16 @@ static void print_neighbors(void *list, unsigned long key)
  _key, _value);
 printf("Neighbors of %5lu: %d %5lu %5lu\n",
   key, retval, prev_key, next_key);
+if (prev_key != expected_prev) {
+fprintf(stderr, "Unexpected neighbor: %5lu. Expected: %5lu\n",
+prev_key, expected_prev);
+   exit(1);
+}
+if (next_key != expected_next) {
+fprintf(stderr, "Unexpected neighbor: %5lu. Expected: %5lu\n",
+next_key, expected_next);
+   exit(1);
+}
 }

 int main(void)
@@ -138,13 +150,13 @@ int main(void)
 print(list);
 printf("\n==\n\n");

-print_neighbors(list, 0);
-print_neighbors(list, 50);
-print_neighbors(list, 51);
-print_neighbors(list, 123);
-print_neighbors(list, 200);
-print_neighbors(list, 213);
-print_neighbors(list, 256);
+print_neighbors(list, 0, 0, 50);
+print_neighbors(list, 50, 0, 50);
+print_neighbors(list, 51, 50, 123);
+print_neighbors(list, 123, 50, 123);
+print_neighbors(list, 200, 123, 213);
+print_neighbors(list, 213, 123, 213);
+print_neighbors(list, 256, 213, 256);
 printf("\n==\n\n");

 drmSLDelete(list, 50);
-- 
2.1.0

[PATCH libdrm 2/4] drmSL: Split tests to a separate file

[Jan Vesely]

Signed-off-by: Jan Vesely 
---
 .gitignore|   1 +
 tests/Makefile.am |   3 +-
 tests/drmsltest.c | 172 ++
 3 files changed, 175 insertions(+), 1 deletion(-)
 create mode 100644 tests/drmsltest.c

diff --git a/.gitignore b/.gitignore
index 06cc928..9c6ecd7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -75,6 +75,7 @@ via.kld
 tests/auth
 tests/dristat
 tests/drmstat
+tests/drmsltest
 tests/getclient
 tests/getstats
 tests/getversion
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 10f54e3..ca0f3c7 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -59,7 +59,8 @@ TESTS =   \
getstats\
setversion  \
updatedraw  \
-   name_from_fd
+   name_from_fd\
+   drmsltest

 check_PROGRAMS += $(TESTS)

diff --git a/tests/drmsltest.c b/tests/drmsltest.c
new file mode 100644
index 000..d193008
--- /dev/null
+++ b/tests/drmsltest.c
@@ -0,0 +1,172 @@
+/* xf86drmSL.c -- Skip list support
+ * Created: Mon May 10 09:28:13 1999 by faith at precisioninsight.com
+ *
+ * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ * 
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ * 
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * PRECISION INSIGHT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ * 
+ * Authors: Rickard E. (Rik) Faith 
+ *
+ * DESCRIPTION
+ *
+ * This file contains a straightforward skip list implementation.n
+ *
+ * FUTURE ENHANCEMENTS
+ *
+ * REFERENCES
+ *
+ * [Pugh90] William Pugh.  Skip Lists: A Probabilistic Alternative to
+ * Balanced Trees. CACM 33(6), June 1990, pp. 668-676.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include "xf86drm.h"
+
+static void print(void* list)
+{
+unsigned long key;
+void  *value;
+
+if (drmSLFirst(list, , )) {
+   do {
+   printf("key = %5lu, value = %p\n", key, value);
+   } while (drmSLNext(list, , ));
+}
+}
+
+static double do_time(int size, int iter)
+{
+void   *list;
+inti, j;
+unsigned long  keys[100];
+unsigned long  previous;
+unsigned long  key;
+void   *value;
+struct timeval start, stop;
+double usec;
+void   *ranstate;
+
+list = drmSLCreate();
+ranstate = drmRandomCreate(12345);
+
+for (i = 0; i < size; i++) {
+   keys[i] = drmRandom(ranstate);
+   drmSLInsert(list, keys[i], NULL);
+}
+
+previous = 0;
+if (drmSLFirst(list, , )) {
+   do {
+   if (key <= previous) {
+   printf( "%lu !< %lu\n", previous, key);
+   }
+   previous = key;
+   } while (drmSLNext(list, , ));
+}
+
+gettimeofday(, NULL);
+for (j = 0; j < iter; j++) {
+   for (i = 0; i < size; i++) {
+   if (drmSLLookup(list, keys[i], ))
+   printf("Error %lu %d\n", keys[i], i);
+   }
+}
+gettimeofday(, NULL);
+
+usec = (double)(stop.tv_sec * 100 + stop.tv_usec
+   - start.tv_sec * 100 - start.tv_usec) / (size * iter);
+
+printf("%0.2f microseconds for list length %d\n", usec, size);
+
+drmRandomDouble(ranstate);
+drmSLDestroy(list);
+
+return usec;
+}
+
+static void print_neighbors(void *list, unsigned long key)
+{
+unsigned long prev_key = 0;
+unsigned long next_key = 0;
+void  *prev_value;
+void  *next_value;
+int   retval;
+
+retval = drmSLLookupNeighbors(list, key,
+ _key, _value,
+ _key, _value);
+printf("Neighbors of %5lu: %d %5lu %5lu\n",
+  key, retval, prev_key, next_key);
+}
+
+int main(void)
+{
+void*list;
+double   usec, usec2, usec3, usec4;
+
+list = drmSLCreate();
+printf( "list at %p\n", list);
+
+print(list);
+

[PATCH libdrm 1/4] drmSL: Fix neighbor printing

[Jan Vesely]

v2: zero the update array instead of checking the return value.
SLLocate returns NULL both on failure and if the element is greater
than everything in the list

Signed-off-by: Jan Vesely 
---
 xf86drmSL.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xf86drmSL.c b/xf86drmSL.c
index acddb54..cf588ac 100644
--- a/xf86drmSL.c
+++ b/xf86drmSL.c
@@ -264,12 +264,14 @@ int drmSLLookupNeighbors(void *l, unsigned long key,
 unsigned long *next_key, void **next_value)
 {
 SkipListPtr   list = (SkipListPtr)l;
-SLEntryPtrupdate[SL_MAX_LEVEL + 1];
+SLEntryPtrupdate[SL_MAX_LEVEL + 1] = {0};
 int   retcode = 0;

+SLLocate(list, key, update);
+
 *prev_key   = *next_key   = key;
 *prev_value = *next_value = NULL;
-   
+
 if (update[0]) {
*prev_key   = update[0]->key;
*prev_value = update[0]->value;
-- 
2.1.0

[PATCH libdrm 4/8] xf86drmSL: Fix neighbour printing

[Jan Vesely]

On Fri, 2015-03-20 at 14:01 -0400, Jan Vesely wrote:
> On Fri, 2015-03-20 at 17:38 +, Emil Velikov wrote:
> > On 27/02/15 18:07, Jan Vesely wrote:
> > > Signed-off-by: Jan Vesely 
> > > ---
> > >  xf86drmSL.c | 7 +--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/xf86drmSL.c b/xf86drmSL.c
> > > index acddb54..2160bb8 100644
> > > --- a/xf86drmSL.c
> > > +++ b/xf86drmSL.c
> > > @@ -266,11 +266,14 @@ int drmSLLookupNeighbors(void *l, unsigned long key,
> > >  SkipListPtr   list = (SkipListPtr)l;
> > >  SLEntryPtrupdate[SL_MAX_LEVEL + 1];
> > >  int   retcode = 0;
> > > +SLEntryPtrentry;
> > > +
> > > +entry = SLLocate(list, key, update);
> > >  
> > >  *prev_key   = *next_key   = key;
> > >  *prev_value = *next_value = NULL;
> > > - 
> > > -if (update[0]) {
> > > +
> > > +if (entry && update[0]) {
> > From a very brief look at git log, the entry check should not be needed.
> > Must admit that I've not looked at all in the implementation of either
> > SLLocate or drmSLLookupNeighbors.
> 
> SLLocate might return early and leave the array uninitialized. All other
> calls to it check the return value. I guess the warning that the
> previous commit tried to fix was "set-but-unused" variable.

I take this back. You were right. SLLocate might return NULL in
non-failing case, and we cannot rely on the return value. I'll post an
updated patch (and a move to tests) shortly

jan

> 
> > 
> > That said it seems that none of the three files
> > (xf86drm{SL,Hash,Random}) has been build as a program for a while. Maybe
> > we could split it out as a standalone test and let it churn at make
> > check time ?
> 
> Sounds like a good idea. I'll try to take a look when time permits, but
> I'd leave that as a separate patch.
> 
> thanks,
> jan
> 
> > 
> > Cheers,
> > Emil
> 

-- 
Jan Vesely 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150320/8257aacf/attachment.sig>

[RFC v3 9/9] s5p-cec: Add s5p-cec driver

[Kamil Debski]

Add CEC interface driver present in the Samsung Exynos range of
SoCs.

The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c

Signed-off-by: Kamil Debski 
---
 drivers/media/platform/Kconfig |7 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/s5p-cec/Makefile|4 +
 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h   |   37 +++
 .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c   |  208 ++
 drivers/media/platform/s5p-cec/regs-cec.h  |   96 +++
 drivers/media/platform/s5p-cec/s5p_cec.c   |  290 
 drivers/media/platform/s5p-cec/s5p_cec.h   |  113 
 8 files changed, 756 insertions(+)
 create mode 100644 drivers/media/platform/s5p-cec/Makefile
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
 create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 2e30be5..016ae9d 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -155,6 +155,13 @@ config VIDEO_MEM2MEM_DEINTERLACE
help
Generic deinterlacing V4L2 driver.

+config VIDEO_SAMSUNG_S5P_CEC
+   tristate "Samsung S5P CEC driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && (PLAT_S5P || ARCH_EXYNOS)
+   default n
+   ---help---
+ This is a v4l2 driver for Samsung S5P HDMI CEC interface.
+
 config VIDEO_SAMSUNG_S5P_G2D
tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
depends on VIDEO_DEV && VIDEO_V4L2
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 3ec1547..17be832 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)   += 
m2m-deinterlace.o

 obj-$(CONFIG_VIDEO_S3C_CAMIF)  += s3c-camif/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)   += s5p-jpeg/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/
diff --git a/drivers/media/platform/s5p-cec/Makefile 
b/drivers/media/platform/s5p-cec/Makefile
new file mode 100644
index 000..7f84226
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/Makefile
@@ -0,0 +1,4 @@
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec.o
+s5p-cec-y += s5p_cec.o exynos_hdmi_cecctrl.o
+
+
diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h 
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
new file mode 100644
index 000..d008695
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
@@ -0,0 +1,37 @@
+/* drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
+ *
+ * Copyright (c) 2010, 2014 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * Header file for interface of Samsung Exynos hdmi cec hardware
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _EXYNOS_HDMI_CEC_H_
+#define _EXYNOS_HDMI_CEC_H_ __FILE__
+
+#include 
+#include 
+#include "s5p_cec.h"
+
+void s5p_cec_set_divider(struct s5p_cec_dev *cec);
+void s5p_cec_enable_rx(struct s5p_cec_dev *cec);
+void s5p_cec_mask_rx_interrupts(struct s5p_cec_dev *cec);
+void s5p_cec_unmask_rx_interrupts(struct s5p_cec_dev *cec);
+void s5p_cec_mask_tx_interrupts(struct s5p_cec_dev *cec);
+void s5p_cec_unmask_tx_interrupts(struct s5p_cec_dev *cec);
+void s5p_cec_reset(struct s5p_cec_dev *cec);
+void s5p_cec_tx_reset(struct s5p_cec_dev *cec);
+void s5p_cec_rx_reset(struct s5p_cec_dev *cec);
+void s5p_cec_threshold(struct s5p_cec_dev *cec);
+void s5p_cec_copy_packet(struct s5p_cec_dev *cec, char *data, size_t count);
+void s5p_cec_set_addr(struct s5p_cec_dev *cec, u32 addr);
+u32 s5p_cec_get_status(struct s5p_cec_dev *cec);
+void s5p_clr_pending_tx(struct s5p_cec_dev *cec);
+void s5p_clr_pending_rx(struct s5p_cec_dev *cec);
+void s5p_cec_get_rx_buf(struct s5p_cec_dev *cec, u32 size, u8 *buffer);
+
+#endif /* _EXYNOS_HDMI_CEC_H_ */
diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c 
b/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
new file mode 100644
index 000..65fe55e
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
@@ -0,0 +1,208 @@
+/* drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
+ *
+ * Copyright (c) 2009, 2014 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * cec ftn file for Samsung TVOUT driver
+ *
+ * This program is free software; you can redistribute 

[RFC v3 8/9] adv7511: add cec support.

[Kamil Debski]

From: Hans Verkuil 

Add CEC support to the adv7511 driver.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
Signed-off-by: Kamil Debski 
---
 drivers/media/i2c/adv7511.c |  325 ++-
 include/media/adv7511.h |6 +-
 2 files changed, 323 insertions(+), 8 deletions(-)

diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 81736aa..63ec6c1 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 

 static int debug;
 module_param(debug, int, 0644);
@@ -91,6 +92,12 @@ struct adv7511_state {
int chip_revision;
uint8_t i2c_edid_addr;
uint8_t i2c_cec_addr;
+
+   struct i2c_client *i2c_cec;
+   u8   cec_addr[3];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
/* Is the adv7511 powered on? */
bool power_on;
/* Did we receive hotplug and rx-sense signals? */
@@ -222,7 +229,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client 
*client,
return ret;
 }

-static inline void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, 
uint8_t *buf)
+static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf)
 {
struct adv7511_state *state = get_adv7511_state(sd);
int i;
@@ -237,6 +244,33 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, 
uint16_t len, uint8_t
v4l2_err(sd, "%s: i2c read error\n", __func__);
 }

+static inline int cec_read(struct v4l2_subdev *sd, u8 reg)
+{
+   struct adv7511_state *state = get_adv7511_state(sd);
+
+   return i2c_smbus_read_byte_data(state->i2c_cec, reg);
+}
+
+static int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+   struct adv7511_state *state = get_adv7511_state(sd);
+   int ret;
+   int i;
+
+   for (i = 0; i < 3; i++) {
+   ret = i2c_smbus_write_byte_data(state->i2c_cec, reg, val);
+   if (ret == 0)
+   return 0;
+   }
+   v4l2_err(sd, "%s: I2C Write Problem\n", __func__);
+   return ret;
+}
+
+static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 
val)
+{
+   return cec_write(sd, reg, (cec_read(sd, reg) & mask) | val);
+}
+
 static inline bool adv7511_have_hotplug(struct v4l2_subdev *sd)
 {
return adv7511_rd(sd, 0x42) & MASK_ADV7511_HPD_DETECT;
@@ -381,16 +415,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = {
 #ifdef CONFIG_VIDEO_ADV_DEBUG
 static void adv7511_inv_register(struct v4l2_subdev *sd)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
v4l2_info(sd, "0x000-0x0ff: Main Map\n");
+   if (state->i2c_cec)
+   v4l2_info(sd, "0x100-0x1ff: CEC Map\n");
 }

 static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register 
*reg)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
reg->size = 1;
switch (reg->reg >> 8) {
case 0:
reg->val = adv7511_rd(sd, reg->reg & 0xff);
break;
+   case 1:
+   if (state->i2c_cec) {
+   reg->val = cec_read(sd, reg->reg & 0xff);
+   break;
+   }
+   /* fall through */
default:
v4l2_info(sd, "Register %03llx not supported\n", reg->reg);
adv7511_inv_register(sd);
@@ -401,10 +447,18 @@ static int adv7511_g_register(struct v4l2_subdev *sd, 
struct v4l2_dbg_register *

 static int adv7511_s_register(struct v4l2_subdev *sd, const struct 
v4l2_dbg_register *reg)
 {
+   struct adv7511_state *state = get_adv7511_state(sd);
+
switch (reg->reg >> 8) {
case 0:
adv7511_wr(sd, reg->reg & 0xff, reg->val & 0xff);
break;
+   case 1:
+   if (state->i2c_cec) {
+   cec_write(sd, reg->reg & 0xff, reg->val & 0xff);
+   break;
+   }
+   /* fall through */
default:
v4l2_info(sd, "Register %03llx not supported\n", reg->reg);
adv7511_inv_register(sd);
@@ -418,6 +472,7 @@ static int adv7511_log_status(struct v4l2_subdev *sd)
 {
struct adv7511_state *state = get_adv7511_state(sd);
struct adv7511_state_edid *edid = >edid;
+   int i;

static const char * const states[] = {
"in reset",
@@ -486,7 +541,20 @@ static int adv7511_log_status(struct v4l2_subdev *sd)
else
v4l2_info(sd, "no timings set\n");
v4l2_info(sd, "i2c edid addr: 0x%x\n", state->i2c_edid_addr);
+
+   if (state->i2c_cec == NULL)
+   return 0;
+
v4l2_info(sd, "i2c cec addr: 0x%x\n", state->i2c_cec_addr);
+
+   if (cec_read(sd, 0x4e) & 0x01) {
+   v4l2_info(sd, "cec: enabled\n");
+  

[RFC v3 7/9] adv7604: add cec support.

[Kamil Debski]

From: Hans Verkuil 

Add CEC support to the adv7604 driver.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
Signed-off-by: Kamil Debski 
---
 drivers/media/i2c/adv7604.c |  182 +++
 1 file changed, 182 insertions(+)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index aaab9c9..ce9d123 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 

 static int debug;
 module_param(debug, int, 0644);
@@ -159,6 +160,10 @@ struct adv76xx_state {
u16 spa_port_a[2];
struct v4l2_fract aspect_ratio;
u32 rgb_quantization_range;
+   u8   cec_addr[3];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
struct workqueue_struct *work_queues;
struct delayed_work delayed_work_enable_hotplug;
bool restart_stdi_once;
@@ -1862,6 +1867,176 @@ static int adv76xx_set_format(struct v4l2_subdev *sd, 
struct v4l2_subdev_fh *fh,
return 0;
 }

+static void adv7604_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status)
+{
+   if ((cec_read(sd, 0x11) & 0x01) == 0) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: tx disabled\n", __func__);
+   return;
+   }
+
+   if (tx_raw_status & 0x02) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: arbitration lost\n", 
__func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, (void 
*)CEC_TX_STATUS_ARB_LOST);
+   return;
+   }
+   if (tx_raw_status & 0x04) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: retry failed\n", __func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, (void 
*)CEC_TX_STATUS_RETRY_TIMEOUT);
+   return;
+   }
+   if (tx_raw_status & 0x01) {
+   v4l2_dbg(1, debug, sd, "%s: tx raw: ready ok\n", __func__);
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, (void 
*)CEC_TX_STATUS_OK);
+   return;
+   }
+}
+
+static void adv7604_cec_isr(struct v4l2_subdev *sd, bool *handled)
+{
+   struct cec_msg msg;
+   u8 cec_irq;
+
+   /* cec controller */
+   cec_irq = io_read(sd, 0x4d) & 0x0f;
+   if (!cec_irq)
+   return;
+
+   v4l2_dbg(1, debug, sd, "%s: cec: irq 0x%x\n", __func__, cec_irq);
+   adv7604_cec_tx_raw_status(sd, cec_irq);
+   if (cec_irq & 0x08) {
+   msg.len = cec_read(sd, 0x25) & 0x1f;
+   if (msg.len > 16)
+   msg.len = 16;
+
+   if (msg.len) {
+   u8 i;
+
+   for (i = 0; i < msg.len; i++)
+   msg.msg[i] = cec_read(sd, i + 0x15);
+   cec_write(sd, 0x26, 0x01); /* re-enable rx */
+   v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_RX_MSG, );
+   }
+   }
+
+   /* note: the bit order is swapped between 0x4d and 0x4e */
+   cec_irq = ((cec_irq & 0x08) >> 3) | ((cec_irq & 0x04) >> 1) |
+ ((cec_irq & 0x02) << 1) | ((cec_irq & 0x01) << 3);
+   io_write(sd, 0x4e, cec_irq);
+
+   if (handled)
+   *handled = true;
+}
+
+static int adv7604_cec_enable(struct v4l2_subdev *sd, bool enable)
+{
+   struct adv7604_state *state = to_state(sd);
+   
+   if (!state->cec_enabled_adap && enable) {
+   cec_write_and_or(sd, 0x2a, 0xfe, 0x01); /* power up cec */
+   cec_write(sd, 0x2c, 0x01);  /* cec soft reset */
+   cec_write_and_or(sd, 0x11, 0xfe, 0);  /* initially disable tx */
+   /* enabled irqs: */
+   /* tx: ready */
+   /* tx: arbitration lost */
+   /* tx: retry timeout */
+   /* rx: ready */
+   io_write_and_or(sd, 0x50, 0xf0, 0x0f);
+   cec_write(sd, 0x26, 0x01);/* enable rx */
+   } else if (state->cec_enabled_adap && !enable) {
+   io_write_and_or(sd, 0x50, 0xf0, 0x00);  /* disable cec 
interrupts */
+   cec_write_and_or(sd, 0x27, 0x8f, 0x70); /* disable address mask 
1-3 */
+   cec_write_and_or(sd, 0x2a, 0xfe, 0x00); /* power down cec 
section */
+   state->cec_valid_addrs = 0;
+   }
+   state->cec_enabled_adap = enable;
+   return 0;
+}
+
+#define ADV7604_MAX_ADDRS (3)
+
+static int adv7604_cec_log_addr(struct v4l2_subdev *sd, u8 addr)
+{
+   struct adv7604_state *state = to_state(sd);
+   unsigned i, free_idx = ADV7604_MAX_ADDRS;
+   
+   if (!state->cec_enabled_adap)
+   return -EIO;
+
+   for (i = 0; i < ADV7604_MAX_ADDRS; i++) {
+   bool is_valid = state->cec_valid_addrs & (1 << i);
+
+   if (free_idx == ADV7604_MAX_ADDRS && !is_valid)
+   free_idx = i;
+   if (is_valid && 

[RFC v3 6/9] v4l2-subdev: add cec ops.

[Kamil Debski]

From: Hans Verkuil 

Add callbacks to the v4l2_subdev_video_ops.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
Verkuil]
Signed-off-by: Kamil Debski 
---
 include/media/v4l2-subdev.h |8 
 1 file changed, 8 insertions(+)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 5beeb87..fdf620d 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -40,6 +40,9 @@
 #define V4L2_SUBDEV_IR_TX_NOTIFY   _IOW('v', 1, u32)
 #define V4L2_SUBDEV_IR_TX_FIFO_SERVICE_REQ 0x0001

+#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 2, u32)
+#define V4L2_SUBDEV_CEC_RX_MSG _IOW('v', 3, struct cec_msg)
+
 struct v4l2_device;
 struct v4l2_ctrl_handler;
 struct v4l2_event_subscription;
@@ -48,6 +51,7 @@ struct v4l2_subdev;
 struct v4l2_subdev_fh;
 struct tuner_setup;
 struct v4l2_mbus_frame_desc;
+struct cec_msg;

 /* decode_vbi_line */
 struct v4l2_decode_vbi_line {
@@ -354,6 +358,10 @@ struct v4l2_subdev_video_ops {
 const struct v4l2_mbus_config *cfg);
int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
   unsigned int *size);
+   int (*cec_enable)(struct v4l2_subdev *sd, bool enable);
+   int (*cec_log_addr)(struct v4l2_subdev *sd, u8 logical_addr);
+   int (*cec_transmit)(struct v4l2_subdev *sd, struct cec_msg *msg);
+   void (*cec_transmit_timed_out)(struct v4l2_subdev *sd);
 };

 /*
-- 
1.7.9.5

[RFC v3 5/9] cec: add new driver for cec support.

[Kamil Debski]

Add the CEC framework.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
[k.debski at samsung.com: Merged Update author commit by Hans Verkuil]
[k.debski at samsung.com: change kthread handling when setting logical
address]
[k.debski at samsung.com: code cleanup and fixes]
[k.debski at samsung.com: add missing CEC commands to match spec]
[k.debski at samsung.com: add RC framework support]
[k.debski at samsung.com: move and edit documentation]
[k.debski at samsung.com: add vendor id reporting]
[k.debski at samsung.com: add promiscuous mode]
[k.debski at samsung.com: add possibility to clear assigned logical
addresses]
Signed-off-by: Kamil Debski 
---
 Documentation/cec.txt|  321 +
 drivers/media/Kconfig|6 +
 drivers/media/Makefile   |2 +
 drivers/media/cec.c  | 1158 ++
 include/media/cec.h  |  137 ++
 include/uapi/linux/cec.h |  283 +++
 6 files changed, 1907 insertions(+)
 create mode 100644 Documentation/cec.txt
 create mode 100644 drivers/media/cec.c
 create mode 100644 include/media/cec.h
 create mode 100644 include/uapi/linux/cec.h

diff --git a/Documentation/cec.txt b/Documentation/cec.txt
new file mode 100644
index 000..e96fcc0
--- /dev/null
+++ b/Documentation/cec.txt
@@ -0,0 +1,321 @@
+CEC Kernel Support
+==
+
+The CEC framework provides a unified kernel interface for use with HDMI CEC
+hardware. It is designed to handle a multiple variants of hardware. Adding to
+the flexibility of the framework it enables to set which parts of the CEC
+protocol processing is handled by the hardware, by the driver and by the
+userspace application.
+
+
+The CEC Protocol
+
+
+The CEC protocol enables cosumer electronic devices to communicate with each
+other through the HDMI connection. The protocol uses logical addresses in the
+communication. The logical address is strictly connected with the functionality
+provided by the device. The TV acting as the communication hub is always
+assigned address 0. The physicall addressis determined by physical connection
+between devices.
+
+The protocol enables control of compatible devices with a single remote.
+Synchronous power on/standby, instant playback with changing the content source
+on the TV.
+
+The Kernel Interface
+
+
+CEC Adaptor
+---
+
+#define CEC_LOG_ADDR_INVALID 0xff
+
+/* The maximum number of logical addresses one device can be assigned to.
+ * The CEC 2.0 spec allows for only 2 logical addresses at the moment. The
+ * Analog Devices CEC hardware supports 3. So let's go wild and go for 4. */
+#define CEC_MAX_LOG_ADDRS 4
+
+/* The "Primary Device Type" */
+#define CEC_PRIM_DEVTYPE_TV0
+#define CEC_PRIM_DEVTYPE_RECORD1
+#define CEC_PRIM_DEVTYPE_TUNER 3
+#define CEC_PRIM_DEVTYPE_PLAYBACK  4
+#define CEC_PRIM_DEVTYPE_AUDIOSYSTEM   5
+#define CEC_PRIM_DEVTYPE_SWITCH6
+#define CEC_PRIM_DEVTYPE_VIDEOPROC 7
+
+/* The "All Device Types" flags (CEC 2.0) */
+#define CEC_FL_ALL_DEVTYPE_TV  (1 << 7)
+#define CEC_FL_ALL_DEVTYPE_RECORD  (1 << 6)
+#define CEC_FL_ALL_DEVTYPE_TUNER   (1 << 5)
+#define CEC_FL_ALL_DEVTYPE_PLAYBACK(1 << 4)
+#define CEC_FL_ALL_DEVTYPE_AUDIOSYSTEM (1 << 3)
+#define CEC_FL_ALL_DEVTYPE_SWITCH  (1 << 2)
+/* And if you wondering what happened to VIDEOPROC devices: those should
+ * be mapped to a SWITCH. */
+
+/* The logical address types that the CEC device wants to claim */
+#define CEC_LOG_ADDR_TYPE_TV   0
+#define CEC_LOG_ADDR_TYPE_RECORD   1
+#define CEC_LOG_ADDR_TYPE_TUNER2
+#define CEC_LOG_ADDR_TYPE_PLAYBACK 3
+#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM  4
+#define CEC_LOG_ADDR_TYPE_SPECIFIC 5
+#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6
+/* Switches should use UNREGISTERED.
+ * Video processors should use SPECIFIC. */
+
+/* The CEC version */
+#define CEC_VERSION_1_4B   5
+#define CEC_VERSION_2_06
+
+struct cec_adapter {
+   /* internal fields removed */
+
+   u16 phys_addr;
+   u32 capabilities;
+   u8 version;
+   u8 num_log_addrs;
+   u8 prim_device[CEC_MAX_LOG_ADDRS];
+   u8 log_addr_type[CEC_MAX_LOG_ADDRS];
+   u8 log_addr[CEC_MAX_LOG_ADDRS];
+
+   int (*adap_enable)(struct cec_adapter *adap, bool enable);
+   int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
+   int (*adap_transmit)(struct cec_adapter *adap, struct cec_msg *msg);
+   void (*adap_transmit_timed_out)(struct cec_adapter *adap);
+
+   int (*received_tv)(struct cec_adapter *adap, struct cec_msg *msg);
+   int (*received_record)(struct cec_adapter *adap, struct cec_msg *msg);
+   int (*received_tuner)(struct cec_adapter *adap, struct cec_msg *msg);
+   int (*received_playback)(struct cec_adapter *adap, struct cec_msg *msg);
+   int 

[RFC v3 4/9] rc: add a map for devices communicating over the HDMI CEC bus

[Kamil Debski]

This patch add a map for devices that communicate over the HDMI CEC bus.

Sgined-off-by: Kamil Debski 
---
 drivers/media/rc/keymaps/Makefile |1 +
 drivers/media/rc/keymaps/rc-cec.c |  144 +
 drivers/media/rc/rc-main.c|1 +
 include/media/rc-core.h   |1 +
 include/media/rc-map.h|5 +-
 5 files changed, 151 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/rc/keymaps/rc-cec.c

diff --git a/drivers/media/rc/keymaps/Makefile 
b/drivers/media/rc/keymaps/Makefile
index abf6079..56f10d6 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-behold.o \
rc-behold-columbus.o \
rc-budget-ci-old.o \
+   rc-cec.o \
rc-cinergy-1400.o \
rc-cinergy.o \
rc-delock-61959.o \
diff --git a/drivers/media/rc/keymaps/rc-cec.c 
b/drivers/media/rc/keymaps/rc-cec.c
new file mode 100644
index 000..cc5b318
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-cec.c
@@ -0,0 +1,144 @@
+/* Keytable for the CEC remote control
+ *
+ * Copyright (c) 2015 by Kamil Debski
+ *
+ * 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 
+
+/* CEC Spec "High-Definition Multimedia Interface Specification" can be 
obtained
+ * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
+ * The list of control codes is listed in Table 27: User Control Codes p. 95 */
+
+static struct rc_map_table cec[] = {
+   { 0x00, KEY_OK },
+   { 0x01, KEY_UP },
+   { 0x02, KEY_DOWN },
+   { 0x03, KEY_LEFT },
+   { 0x04, KEY_RIGHT },
+   { 0x05, KEY_RIGHT_UP },
+   { 0x06, KEY_RIGHT_DOWN },
+   { 0x07, KEY_LEFT_UP },
+   { 0x08, KEY_LEFT_DOWN },
+   { 0x09, KEY_CONTEXT_MENU }, /* CEC Spec: Root Menu - see Note 2 */
+   /* Note 2: This is the initial display that a device shows. It is
+* device-dependent and can be, for example, a contents menu, setup
+* menu, favorite menu or other menu. The actual menu displayed
+* may also depend on the device’s current state. */
+   { 0x0a, KEY_SETUP },
+   { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */
+   { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */
+   { 0x0d, KEY_EXIT },
+   /* 0x0e-0x1f: Reserved */
+   /* 0x20-0x29: Keys 0 to 9 */
+   { 0x20, KEY_NUMERIC_0 },
+   { 0x21, KEY_NUMERIC_1 },
+   { 0x22, KEY_NUMERIC_2 },
+   { 0x23, KEY_NUMERIC_3 },
+   { 0x24, KEY_NUMERIC_4 },
+   { 0x25, KEY_NUMERIC_5 },
+   { 0x26, KEY_NUMERIC_6 },
+   { 0x27, KEY_NUMERIC_7 },
+   { 0x28, KEY_NUMERIC_8 },
+   { 0x29, KEY_NUMERIC_9 },
+   { 0x2a, KEY_DOT },
+   { 0x2b, KEY_ENTER },
+   { 0x2c, KEY_CLEAR },
+   /* 0x2d-0x2e: Reserved */
+   { 0x2f, KEY_NEXT_FAVORITE }, /* CEC Spec: Next Favorite */
+   { 0x30, KEY_CHANNELUP },
+   { 0x31, KEY_CHANNELDOWN },
+   { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */
+   { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */
+   { 0x34, KEY_VIDEO }, /* 0x34: CEC Spec: Input Select */
+   { 0x35, KEY_INFO }, /* CEC Spec: Display Information */
+   { 0x36, KEY_HELP },
+   { 0x37, KEY_PAGEUP },
+   { 0x38, KEY_PAGEDOWN },
+   /* 0x39-0x3f: Reserved */
+   { 0x40, KEY_POWER },
+   { 0x41, KEY_VOLUMEUP },
+   { 0x42, KEY_VOLUMEDOWN },
+   { 0x43, KEY_MUTE },
+   { 0x44, KEY_PLAY },
+   { 0x45, KEY_STOP },
+   { 0x46, KEY_PAUSE },
+   { 0x47, KEY_RECORD },
+   { 0x48, KEY_REWIND },
+   { 0x49, KEY_FASTFORWARD },
+   { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */
+   { 0x4b, KEY_FORWARD },
+   { 0x4c, KEY_BACK },
+   { 0x4d, KEY_STOP_RECORD }, /* CEC Spec: Stop-Record */
+   { 0x4e, KEY_PAUSE_RECORD }, /* CEC Spec: Pause-Record */
+   /* 0x4f: Reserved */
+   { 0x50, KEY_ANGLE },
+   { 0x51, KEY_TV2 },
+   { 0x52, KEY_VOD }, /* CEC Spec: Video on Demand */
+   { 0x53, KEY_EPG },
+   { 0x54, KEY_TIME }, /* CEC Spec: Timer */
+   { 0x55, KEY_CONFIG },
+   /* 0x56-0x5f: Reserved */
+   { 0x60, KEY_PLAY }, /* CEC Spec: Play Function */
+   { 0x6024, KEY_PLAY },
+   { 0x6020, KEY_PAUSE },
+   { 0x61, KEY_PLAYPAUSE }, /* CEC Spec: Pause-Play Function */
+   { 0x62, KEY_RECORD }, /* Spec: Record Function */
+   { 0x63, KEY_PAUSE }, /* CEC Spec: Pause-Record Function */
+   { 0x64, KEY_STOP }, /* CEC Spec: Stop Function */
+   { 0x65, KEY_MUTE }, /* CEC Spec: Mute Function */
+   { 0x66, KEY_UNMUTE }, /* CEC 

[RFC v3 3/9] Input: add key codes specific to the HDMI CEC bus

[Kamil Debski]

The HDMI CEC bus allows device to communicate with one another.
This includes sending remote control key codes. Some of key codes
defined in the CEC standard are not defined in the input.h.
This patch adds the key codes that are missing.

Signed-off-by: Kamil Debski 
---
 include/uapi/linux/input.h |   12 
 1 file changed, 12 insertions(+)

diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index b0a8130..3fc6885 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -747,6 +747,18 @@ struct input_keymap_entry {
 #define KEY_KBDINPUTASSIST_ACCEPT  0x264
 #define KEY_KBDINPUTASSIST_CANCEL  0x265

+#define KEY_RIGHT_UP   0x266
+#define KEY_RIGHT_DOWN 0x267
+#define KEY_LEFT_UP0x268
+#define KEY_LEFT_DOWN  0x269
+
+#define KEY_NEXT_FAVORITE  0x270
+#define KEY_STOP_RECORD0x271
+#define KEY_PAUSE_RECORD   0x272
+#define KEY_VOD0x273
+#define KEY_UNMUTE 0x274
+#define KEY_DVB0x275
+
 #define BTN_TRIGGER_HAPPY  0x2c0
 #define BTN_TRIGGER_HAPPY1 0x2c0
 #define BTN_TRIGGER_HAPPY2 0x2c1
-- 
1.7.9.5

[RFC v3 2/9] dts: add s5p-cec to exynos4412-odroidu3

[Kamil Debski]

Add support for the s5p-mfc device to the exynos4412-odroidu3.dts.

Signed-off-by: Kamil Debski 
---
 arch/arm/boot/dts/exynos4412-odroidu3.dts |   13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 44684e5..e922789 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,19 @@
linux,default-trigger = "heartbeat";
};
};
+
+   hdmicec: cec at 100B {
+   compatible = "samsung,s5p-cec";
+   reg = <0x100B 0x200>;
+   interrupts = <0 114 0>;
+   clocks = < CLK_HDMI_CEC>;
+   clock-names = "hdmicec";
+   samsung,syscon-phandle = <_system_controller>;
+   cec-gpio = < 6 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec>;
+   status = "okay";
+   };
 };

  {
-- 
1.7.9.5

[RFC v3 1/9] dts: add hdmi-cec to to pinctrl definitions

[Kamil Debski]

Add entry for hdmi-cec to the pinctrl_1.

Signed-off-by: Kamil Debski 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index de80b5b..ca9b858 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -425,4 +425,11 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+   hdmi_cec: hdmi-cec {
+   samsung,pins = "gpx3-6";
+   samsung,pin-function = <3>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
 };
-- 
1.7.9.5

[RFC v3 0/9] HDMI CEC framework

[Kamil Debski]

Hi,

First of all - thank you so much for your comments to the two previous versions
of this RFC. This is the third version of the HDMI CEC framework patches.

In this version I have introduced a promiscuous mode in which all messages are
forwarded to the userspace. This is independent of parsing of the messages,
thus the key codes will be interpreted and sent as input events. This mode can
be used to eavesdrop on the messages transferred on the bus. This can be used
for e.g. to debug or listen look how other hardware communicates over the bus.

The original cover letter follows the changes summary.

Changes since v2
===-
- added promiscuous mode
- added new key codes to the input framework
- add vendor ID reporting
- add the possibility to clear assigned logical addresses
- cleanup of the rc cec map

Changes since v1

- documentation edited and moved to the Documentation folder
- added key up/down message handling
- add missing CEC commands to the cec.h file

Original cover letter
=

Hi,

The work on a common CEC framework was started over three years ago by Hans
Verkuil. Unfortunately the work has stalled. As I have received the task of
creating a driver for the CEC interface module present on the Exynos range of
SoCs, I got in touch with Hans. He repied that the work stalled due to his
lack of time.

The driver was done in the most part and there were only minor fixes that needed
to be implemented. I would like to bring back the discussion on a common CEC
interface framework.

There are a few things that were still left as TODO, I think they might need
some discussion - for instance the way how the remote controls should be
handled.

Best wishes,
Kamil Debski

Original RFC by Hans Verkuil/Martin Bugge
=
https://www.mail-archive.com/linux-media at vger.kernel.org/msg28735.html

Hans Verkuil (3):
  v4l2-subdev: add cec ops.
  adv7604: add cec support.
  adv7511: add cec support.

Kamil Debski (6):
  dts: add hdmi-cec to to pinctrl definitions
  dts: add s5p-cec to exynos4412-odroidu3
  Input: add key codes specific to the HDMI CEC bus
  rc: add a map for devices communicating over the HDMI CEC bus
  cec: add new driver for cec support.
  s5p-cec: Add s5p-cec driver

 Documentation/cec.txt  |  321 ++
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|7 +
 arch/arm/boot/dts/exynos4412-odroidu3.dts  |   13 +
 drivers/media/Kconfig  |6 +
 drivers/media/Makefile |2 +
 drivers/media/cec.c| 1158 
 drivers/media/i2c/adv7511.c|  325 +-
 drivers/media/i2c/adv7604.c|  182 +++
 drivers/media/platform/Kconfig |7 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/s5p-cec/Makefile|4 +
 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h   |   37 +
 .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c   |  208 
 drivers/media/platform/s5p-cec/regs-cec.h  |   96 ++
 drivers/media/platform/s5p-cec/s5p_cec.c   |  290 +
 drivers/media/platform/s5p-cec/s5p_cec.h   |  113 ++
 drivers/media/rc/keymaps/Makefile  |1 +
 drivers/media/rc/keymaps/rc-cec.c  |  144 +++
 drivers/media/rc/rc-main.c |1 +
 include/media/adv7511.h|6 +-
 include/media/cec.h|  137 +++
 include/media/rc-core.h|1 +
 include/media/rc-map.h |5 +-
 include/media/v4l2-subdev.h|8 +
 include/uapi/linux/cec.h   |  283 +
 include/uapi/linux/input.h |   12 +
 26 files changed, 3359 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/cec.txt
 create mode 100644 drivers/media/cec.c
 create mode 100644 drivers/media/platform/s5p-cec/Makefile
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
 create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
 create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c
 create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h
 create mode 100644 drivers/media/rc/keymaps/rc-cec.c
 create mode 100644 include/media/cec.h
 create mode 100644 include/uapi/linux/cec.h

-- 
1.7.9.5

[PATCH libdrm 1/1] tests/exynos: Fix warnings

[Emil Velikov]

On 18/03/15 19:41, Jan Vesely wrote:
> On Wed, 2015-03-18 at 20:23 +0100, Tobias Jakobi wrote:
>> Hello Jan,
>>
>> Jan Vesely wrote:
>>> Signed-off-by: Jan Vesely 
>>> ---
>>>  tests/exynos/exynos_fimg2d_test.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tests/exynos/exynos_fimg2d_test.c 
>>> b/tests/exynos/exynos_fimg2d_test.c
>>> index e7d9b72..dfb34ac 100644
>>> --- a/tests/exynos/exynos_fimg2d_test.c
>>> +++ b/tests/exynos/exynos_fimg2d_test.c
>>> @@ -183,7 +183,7 @@ static struct exynos_bo *exynos_create_buffer(struct 
>>> exynos_device *dev,
>>>  
>>>  /* Allocate buffer and fill it with checkerboard pattern, where the tiles *
>>>   * have a random color. The caller has to free the buffer.
>>> */
>>> -void *create_checkerboard_pattern(unsigned int num_tiles_x,
>>> +static void *create_checkerboard_pattern(unsigned int num_tiles_x,
>>> unsigned int num_tiles_y, 
>>> unsigned int tile_size)
>>>  {
>>> unsigned int *buf;
>> Good catch with the missing static!
>>
>>
>>> @@ -573,6 +573,7 @@ static int g2d_checkerboard_test(struct exynos_device 
>>> *dev,
>>> src_img.user_ptr[0].userptr = (unsigned long)checkerboard;
>>> src_img.user_ptr[0].size = img_w * img_h * 4;
>>> break;
>>> +   case G2D_IMGBUF_COLOR:
>>> default:
>>> ret = -EFAULT;
>>> goto fail;
>>>
>> Hmm, I don't see the reason why this label should be added to the switch
>> statement?
> 
> This is mostly to appease the compiler. -Wswitch-enum warns about
> missing enumeration cases even if default is present. On the other hand
> it also warns against branches that use values outside of the
> enumeration (which might be useful).
> 
> Emil, any thoughts about possibly dropping this warning? I think more
> people will scratch their heads if unused enumeration values need to be
> added to default branch.
> 
Fwiw mesa (and other projects) have addopted the approach of explicitly
handling each enum, and omitting the default statement.

Although considering that 1) this is a seldom run test and 2) things
have been as is (G2D_IMGBUF_COLOR implicitly handled by default) since
day 1, I'd say that either way is fine. Ideally Exynos people will cast
their vote, although I'm suspecting that this is not on their list.

Cheers,
Emil

[PATCH libdrm 9/8] Remove drmSetDebugMsgFunction and related infrastructure

[Jan Vesely]

On Fri, 2015-03-20 at 21:06 +, Emil Velikov wrote:
> On 18 March 2015 at 18:37, Jan Vesely  wrote:
> > Not used anywhere
> >
> Some information from my digging around:
> 
> Function was added with commit 79038751ffe(libdrm: add support for
> server side functionality in libdrm).
> It's not referenced even once in the history of the following projects
>  - xserver
>  - plymouth
>  - mesa
>  - xf86-video-ati
>   -xf86-video-freedreno
>  - xf86-video-i128
>  - xf86-video-i740
>  - xf86-video-intel
>  - xf86-video-mach64
>  - xf86-video-mga
>  - xf86-video-nouveau
>  - xf86-video-r128
>  - xf86-video-tdfx
>  - xf86-video-savage
>  - xf86-video-sis
>  - xf86-video-via
> 
> So I'm pretty confident that we're safe to nuke it. The above ddx list
> should consist of all the drivers/hardware that was ever officially
> supported by drm - from dri1 era until now.
> 
> Reviewed-by: Emil Velikov 

thanks for checking those. I still don;t have a clear idea which
projects actually use libdrm (other than mesa)

jan

> 
> -Emil

-- 
Jan Vesely 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150320/73c96ac5/attachment.sig>

[PATCH] radeon: Do not directly dereference pointers to BIOS area.

[Deucher, Alexander]

> -Original Message-
> From: David Miller [mailto:davem at davemloft.net]
> Sent: Friday, March 20, 2015 1:24 PM
> To: Koenig, Christian
> Cc: Deucher, Alexander; dri-devel at lists.freedesktop.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH] radeon: Do not directly dereference pointers to BIOS
> area.
> 
> From: Christian König 
> Date: Fri, 20 Mar 2015 10:38:32 +0100
> 
> > On 19.03.2015 17:29, David Miller wrote:
> >> From: Christian König 
> >> Date: Thu, 19 Mar 2015 09:50:58 +0100
> >>
> >>> In general I would say yes, but for this particular hardware it's a
> >>> bit questionable to do so.
> >>>
> >>> For radeon hardware to work correctly the CPU access to the PCIE BARs
> >>> should work even without using the specialized IO macros/functions,
> >>> otherwise mapping VRAM CPU accessible isn't really possible.
> >>>
> >>> What's the background of the change? Some problems on a certain CPU
> >>> platform? or just general cleanups?
> >> It's an _iomem_ pointer, it's not a virtual address.
> >>
> >> Therefore it is illegal to dereference the pointer.
> >>
> >> The value is opaque and has values that only make sense when used
> >> with the readb() et al. interfaces.
> >>
> >> This code is relying upon the fact that on x86 it happens to be
> >> a virtual address, but this won't work on many other architectures.
> >
> > In this case I'm perfectly fine with it and the patch is Reviewed-by:
> > Christian König 
> >
> > Just wanted to make sure that you're not trying to get Radeon working
> > on a platform which will never really support the necessary hardware
> > features.
> 
> I would like this to get merged via the Radeon DRM maintainer, thanks.

Already added to my tree.  Thanks!

Alex

[PATCH libdrm 4/8] xf86drmSL: Fix neighbour printing

[Emil Velikov]

On 27/02/15 18:07, Jan Vesely wrote:
> Signed-off-by: Jan Vesely 
> ---
>  xf86drmSL.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/xf86drmSL.c b/xf86drmSL.c
> index acddb54..2160bb8 100644
> --- a/xf86drmSL.c
> +++ b/xf86drmSL.c
> @@ -266,11 +266,14 @@ int drmSLLookupNeighbors(void *l, unsigned long key,
>  SkipListPtr   list = (SkipListPtr)l;
>  SLEntryPtrupdate[SL_MAX_LEVEL + 1];
>  int   retcode = 0;
> +SLEntryPtrentry;
> +
> +entry = SLLocate(list, key, update);
>  
>  *prev_key   = *next_key   = key;
>  *prev_value = *next_value = NULL;
> - 
> -if (update[0]) {
> +
> +if (entry && update[0]) {
>From a very brief look at git log, the entry check should not be needed.
Must admit that I've not looked at all in the implementation of either
SLLocate or drmSLLookupNeighbors.

That said it seems that none of the three files
(xf86drm{SL,Hash,Random}) has been build as a program for a while. Maybe
we could split it out as a standalone test and let it churn at make
check time ?

Cheers,
Emil

[PATCH libdrm v2 8/8] Fix unused function warnings

[Emil Velikov]

On 18/03/15 18:37, Jan Vesely wrote:
> v2: Remove the handler function instead of commenting out
> split debugmsg function removal to a separate patch
> 
> Signed-off-by: Jan Vesely 
Looks good thanks for the split.

Reviewed-by: Emil Velikov 

-Emil

[PATCH libdrm] tests: add rockchip to modetest, kmstest, vbltest and proptest

[Emil Velikov]

On 19/03/15 17:54, Daniel Kurtz wrote:
> On Fri, Mar 20, 2015 at 1:50 AM, Emil Velikov  
> wrote:
>> On 19/03/15 17:42, Daniel Kurtz wrote:
>>> On Fri, Mar 6, 2015 at 4:52 PM, Daniel Kurtz  
>>> wrote:
 There is a rockchip drm kms driver.
 Add "rockchip" to the static lists of driver names in the the standard
 set of tests.

 Signed-off-by: Daniel Kurtz 
>>>
>>> Ping?
>>>
>>> Can somebody please help review & push this patch.
>>>
>> Might be a silly question:
>>
>> Do we have a kernel version (or a Linus tree) where the rockchip drm
>> module landed ? Must admit I didn't pay close attention to it.
> 
> Here's the commit that added drm/rockchip to mainline:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/rockchip?id=2048e3286f347db5667708e47448176b5329e8d8
> 
> It was picked up by v3.19-rc1
> 
Thanks for the confirmation. Seems like I'm a kernel release or two out
of date :-)

I've rebased the latter patch on master and pushed them both.

-Emil

[PATCH libdrm 0/5] Yet another round of Android build cleanups

[Emil Velikov]

On 20/03/15 06:34, Chih-Wei Huang wrote:
> Is there any gating item to prevent
> these patches (5+2) from being merged?
> 
None in particular. I prefer to give it a day or two as people might
want to comment, yet their mail queue does not allow them.

I've pushed them now. Thanks !
Emil

[PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[Emil Velikov]

On 09/03/15 12:37, Emil Velikov wrote:
> The former does not imply the latter and vice-versa. One such example is
> the Sun compiler.
> 
> Cc: Alan Coopersmith 
> Cc: Thierry Reding 
> Signed-off-by: Emil Velikov 
> ---
> 
> Hi Alan,
> Can you please take a look it this series covers the symbol visibility 
> issues mentioned earlier ? In theory it should work like a charm but I 
> cannot really test it :-\
> 
[Cutting out accidental garbage]
> Additionally can you guys build libdrm (barring the patch you sent the 
> other day), or you need some parts of this ancient patch 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/files/libdrm-2.4.58-solaris.patch?view=markup
> 
Hi Alan,

Suspecting that you're quite busy. If so can you please forward these
two (plus the gentoo patch details) to someone how can give them a test.
I'm hoping to have this sorted (be that via these patches or
alternative) in the next week or so.

Thanks
Emil

[PATCH 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

[Javi Merino]

On Fri, Mar 20, 2015 at 01:51:36PM +, Alex Elder wrote:
> On 03/20/2015 06:14 AM, Javi Merino wrote:
> > Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
> > implementation and use the kernel one.
> > 
> > Cc: Antti Palosaari 
> > Cc: Mauro Carvalho Chehab 
> > Signed-off-by: Javi Merino 
> > ---
> > I've only compile-tested it, I don't have the hardware to run it.
> > 
> >  drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
> >  drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
> >  drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
> >  drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
> >  drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
> >  5 files changed, 3 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
> > b/drivers/media/dvb-frontends/cxd2820r_c.c
> > index 149fdca3fb44..72b0e2db3aab 100644
> > --- a/drivers/media/dvb-frontends/cxd2820r_c.c
> > +++ b/drivers/media/dvb-frontends/cxd2820r_c.c
> > @@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
> >  
> > num = if_freq / 1000; /* Hz => kHz */
> > num *= 0x4000;
> > -   if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
> > +   if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
> > buf[0] = (if_ctl >> 8) & 0x3f;
> > buf[1] = (if_ctl >> 0) & 0xff;
> >  
> > diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
> > b/drivers/media/dvb-frontends/cxd2820r_core.c
> > index 422e84bbb008..490e090048ef 100644
> > --- a/drivers/media/dvb-frontends/cxd2820r_core.c
> > +++ b/drivers/media/dvb-frontends/cxd2820r_core.c
> > @@ -244,12 +244,6 @@ error:
> > return ret;
> >  }
> >  
> > -/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
> > -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
> > -{
> > -   return div_u64(dividend + (divisor / 2), divisor);
> > -}
> 
> Technically, I'd say this has a bug, because the result
> needs to be 64 bits wide or your results might be much
> different from what might be desired.
> 
> Practically though, I'm pretty sure all callers provide
> values that ensure the result is valid.

All the callers are substituted in this patch so we can make sure that
they are all correct.

> I only call attention because this patch changes the return
> type of the function that gets called to do the calculation.

I'm not sure I follow.  Do you mean that this:

if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);

Should actually be:

if_ctl = 0x4000 - (u32)DIV_ROUND_CLOSEST_ULL(num, 41000);

?

if_ctl is a u16 so I don't think you gain anything by doing that.

> > -
> >  static int cxd2820r_set_frontend(struct dvb_frontend *fe)
> >  {
> > struct cxd2820r_priv *priv = fe->demodulator_priv;
> > diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
> > b/drivers/media/dvb-frontends/cxd2820r_priv.h
> > index 7ff5f60c83e1..4b428959b16e 100644
> > --- a/drivers/media/dvb-frontends/cxd2820r_priv.h
> > +++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
> > @@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 
> > reg, u8 val,
> >  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
> > int len);
> >  
> > -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
> > -
> >  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
> > int len);
> >  
> > diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
> > b/drivers/media/dvb-frontends/cxd2820r_t.c
> > index 51401d036530..008cb2ac8480 100644
> > --- a/drivers/media/dvb-frontends/cxd2820r_t.c
> > +++ b/drivers/media/dvb-frontends/cxd2820r_t.c
> > @@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)
> >  
> > num = if_freq / 1000; /* Hz => kHz */
> > num *= 0x100;
> > -   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
> > +   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);

if_ctl is a u32, so you get the same behavior that you were getting
before: the downcasting of u64 to u32 happened in
cxd2820r_div_u64_round_closest(), now it happens here.

> > buf[0] = ((if_ctl >> 16) & 0xff);
> > buf[1] = ((if_ctl >>  8) & 0xff);
> > buf[2] = ((if_ctl >>  0) & 0xff);
> > diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
> > b/drivers/media/dvb-frontends/cxd2820r_t2.c
> > index 9c0c4f42175c..35fe364c7182 100644
> > --- a/drivers/media/dvb-frontends/cxd2820r_t2.c
> > +++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
> > @@ -120,7 +120,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)
> >  
> > num = if_freq / 1000; /* Hz => kHz */
> > num *= 0x100;
> > -   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
> > +   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);

Same here if_ctl is a u32.

Cheers,
Javi

[RFC PATCH 27/37] drm: atomic: Allow setting CRTC active property

[Daniel Vetter]

On Thu, Mar 19, 2015 at 04:33:26AM +, Daniel Stone wrote:
> Before, we would set the property, but also return -EINVAL because of a
> broken fallthrough.
> 
> Signed-off-by: Daniel Stone 

Oops. Both of these merged to drm-misc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC PATCH 17/37] DRM: Atomic: Use pointer for mode in CRTC state

[Daniel Vetter]

On Thu, Mar 19, 2015 at 04:33:16AM +, Daniel Stone wrote:
> Holding a pointer to the mode, rather than an embed, allows us to get
> towards sharing refcounted modes.
> 
> XXX: atomic_destroy_state does _not_ seem to be optional - so we should
>  remove any fallback paths which compensate for its lack!
>  the crtc_state->mode handling is particularly ugly here :\

duplicate/destroy callbacks are optional in the transitional helpers. And
that's fairly intentional to avoid the need for switching to the full
state scaffolding at once.

For these couldn't we instead just store a pointer to crtc->mode instead?
Lifetimes should be fully in sync.

> @@ -2058,11 +2058,22 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
>   */
>  void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc)
>  {
> + if (crtc->state)
> + kfree(crtc->state->mode);
> +
>   kfree(crtc->state);
>   crtc->state = kzalloc(sizeof(*crtc->state), GFP_KERNEL);
>  
> - if (crtc->state)
> + if (crtc->state) {
>   crtc->state->crtc = crtc;
> + crtc->state->mode =
> + kzalloc(sizeof(*crtc->state->mode), GFP_KERNEL);

Allocating an empty mode object seems superflous. Why do we need this?

> + }
> +
> + if (crtc->state && !crtc->state->mode) {
> + kfree(crtc->state);
> + crtc->state = NULL;
> + }
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_crtc_reset);
>  
> @@ -2088,6 +2099,11 @@ drm_atomic_helper_crtc_duplicate_state(struct drm_crtc 
> *crtc)
>   state->active_changed = false;
>   state->planes_changed = false;
>   state->event = NULL;
> + state->mode = drm_mode_duplicate(crtc->dev, crtc->state->mode);
> + if (!state->mode) {
> + kfree(state);
> + state = NULL;
> + }
>   }
>  
>   return state;
> @@ -2105,6 +2121,7 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
>  void drm_atomic_helper_crtc_destroy_state(struct drm_crtc *crtc,
> struct drm_crtc_state *state)
>  {
> + kfree(state->mode);
>   kfree(state);
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_crtc_destroy_state);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 5785336..6023851 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2008,7 +2008,7 @@ int drm_mode_getcrtc(struct drm_device *dev,
>   crtc_resp->x = crtc->primary->state->src_x >> 16;
>   crtc_resp->y = crtc->primary->state->src_y >> 16;
>   if (crtc->state->enable) {
> - drm_crtc_convert_to_umode(_resp->mode, 
> >state->mode);
> + drm_crtc_convert_to_umode(_resp->mode, 
> crtc->state->mode);
>   crtc_resp->mode_valid = 1;
>  
>   } else {
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index c6063ff..8a9a045 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -943,11 +943,32 @@ int drm_helper_crtc_mode_set(struct drm_crtc *crtc,
>  
>   if (crtc->funcs->atomic_duplicate_state)
>   crtc_state = crtc->funcs->atomic_duplicate_state(crtc);
> - else if (crtc->state)
> + else if (crtc->state) {
>   crtc_state = kmemdup(crtc->state, sizeof(*crtc_state),
>GFP_KERNEL);
> - else
> + /* XXX: this is unpleasant: we should mandate dup instead */
> + if (crtc_state) {
> + crtc_state->mode =
> + drm_mode_duplicate(crtc->dev,
> +crtc->state->mode);
> + if (!crtc_state->mode) {
> + kfree(crtc_state);
> + crtc_state = NULL;
> + }
> + }
> + }
> + else {
>   crtc_state = kzalloc(sizeof(*crtc_state), GFP_KERNEL);
> + if (crtc_state) {
> + crtc_state->mode = kzalloc(sizeof(*crtc_state->mode),
> +GFP_KERNEL);
> + /* XXX: as above, but mandate a new_state */
> + if (!crtc_state->mode) {
> + kfree(crtc_state);
> + crtc_state = NULL;
> + }
> + }
> + }

I think for transitional helpers if we just do a crtc_state->mode =
crtc->mode that should be all that's needed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC PATCH 04/37] drm: crtc_helper: Update hwmode before mode_set call

[Daniel Vetter]

On Thu, Mar 19, 2015 at 04:33:03AM +, Daniel Stone wrote:
> Just as we provide crtc->mode pre-populated with the requested mode,
> move adjusted_mode into hwmode before we call the crtc's mode_set,
> making sure to restore it on failure.
> 
> Allows drivers which thoughtlessly discard adjusted_mode in their
> mode_set hooks (e.g. Exynos) to use hwmode directly, and also provides
> some neat symmetry with crtc->mode.
> 
> Signed-off-by: Daniel Stone 

Merged up to this patch to drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC PATCH 05/37] drm: Exynos: Remove mode validation inside mode_fixup

[Daniel Vetter]

On Thu, Mar 19, 2015 at 04:33:04AM +, Daniel Stone wrote:
> mode_valid is the callback we already have to check whether or not a
> mode is valid. So there's no need to validate again inside mode_fixup,
> and there's really very definitely no need to select a totally different
> mode.

There is. mode_fixup is called for modeset, mode_valid by the probe
helpers. But userspace can just ignore the mode list and add their owns.
So yeah you'll need to validate twice.

Fixing that up is somewhere on my todo ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/omap: tiler: add hibernation callback

[grygorii.stras...@linaro.org]

On 03/20/2015 01:43 PM, Tomi Valkeinen wrote:
> On 18/03/15 16:56, Grygorii.Strashko at linaro.org wrote:
>> Hi All,
>>
>> On 02/25/2015 08:08 PM, grygorii.strashko at linaro.org wrote:
>>> From: Grygorii Strashko 
>>>
>>> Setting a dev_pm_ops resume callback but not a set of
>>> hibernation handler means that pm function will not be
>>> called upon hibernation.
>>> Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
>>> assigns the suspend and hibernation handlers and move
>>> omap_dmm_resume under CONFIG_PM_SLEEP to avoid build warnings.
>>>
>>> Signed-off-by: Grygorii Strashko 
>>> ---
>>>drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 +++---
>>>1 file changed, 3 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>>> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>>> index 56c6055..afb8cfc 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>>> @@ -941,7 +941,7 @@ error:
>>>}
>>>#endif
>>>
>>> -#ifdef CONFIG_PM
>>> +#ifdef CONFIG_PM_SLEEP
>>>static int omap_dmm_resume(struct device *dev)
>>>{
>>>struct tcm_area area;
>>> @@ -965,12 +965,10 @@ static int omap_dmm_resume(struct device *dev)
>>>
>>>return 0;
>>>}
>>> -
>>> -static const struct dev_pm_ops omap_dmm_pm_ops = {
>>> -.resume = omap_dmm_resume,
>>> -};
>>>#endif
>>>
>>> +SIMPLE_DEV_PM_OPS(omap_dmm_pm_ops, NULL, omap_dmm_resume);
>>> +
>>>#if defined(CONFIG_OF)
>>>static const struct of_device_id dmm_of_match[] = {
>>>{ .compatible = "ti,omap4-dmm", },
>>> @@ -986,9 +984,7 @@ struct platform_driver omap_dmm_driver = {
>>>.owner = THIS_MODULE,
>>>.name = DMM_DRIVER_NAME,
>>>.of_match_table = of_match_ptr(dmm_of_match),
>>> -#ifdef CONFIG_PM
>>>.pm = _dmm_pm_ops,
>>> -#endif
>>>},
>>>};
>>>
>>>
>>
>> Any comments on this?
>
> Sorry, I missed this. I'll add it to my omapdrm branch.
>
Thanks.

-- 
regards,
-grygorii

[RFC PATCH 02/37] drm: fb_helper: Simplify exit condition

[Daniel Vetter]

On Thu, Mar 19, 2015 at 04:33:01AM +, Daniel Stone wrote:
> mode is always NULL at this point in the function, so make our intention
> clear.
> 
> Signed-off-by: Daniel Stone 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 1a20db7..27f5617 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1288,7 +1288,7 @@ struct drm_display_mode *drm_pick_cmdline_mode(struct 
> drm_fb_helper_connector *f
>  
>   cmdline_mode = _helper_conn->connector->cmdline_mode;
>   if (cmdline_mode->specified == false)
> - return mode;
> + return NULL;

We can stop clearing mode with this change, so I did that on top. And
there was a ugly space 2 lines below. Bikeshedding bikesheds, yay!

Applied to drm-misc, thanks.
-Daniel

>  
>   /* attempt to find a matching mode in the list of modes
>*  we have gotten so far, if not add a CVT mode that conforms
> -- 
> 2.3.2
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 1/3] RELEASING: Fix releasing instructions to match the latest release.sh

[Damien Lespiau]

On Thu, Mar 19, 2015 at 05:39:06PM +, Emil Velikov wrote:
> On 19/03/15 16:35, Damien Lespiau wrote:
> > - Running "make distcheck" should result in no warnings or errors
> > - and end with a message of the form:
> > + Verify that the code passes "make distcheck".  Running "make
> > + distcheck" should result in no warnings or errors and end with a
> > + message of the form:
> >  
> Side note: Pretty sure that current make distcheck produces a handful of
> warnings ;-)

Yup, it does, that'll have to be for another time though.

> Although we'll try to have them sorted by next release.

That'd be excellent.

> With my comment in patch 2 and Ilia's in 3 the series is
> Reviewed-by: Emil Velikov 

Done and pushed, thanks for the review!

-- 
Damien

[PATCH 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

[Alex Elder]

On 03/20/2015 12:27 PM, Javi Merino wrote:
> On Fri, Mar 20, 2015 at 01:51:36PM +, Alex Elder wrote:
>> On 03/20/2015 06:14 AM, Javi Merino wrote:
>>> Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
>>> implementation and use the kernel one.
>>>
>>> Cc: Antti Palosaari 
>>> Cc: Mauro Carvalho Chehab 
>>> Signed-off-by: Javi Merino 
>>> ---
>>> I've only compile-tested it, I don't have the hardware to run it.
>>>
>>>  drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
>>>  drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
>>>  drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
>>>  drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
>>>  drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
>>>  5 files changed, 3 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
>>> b/drivers/media/dvb-frontends/cxd2820r_c.c
>>> index 149fdca3fb44..72b0e2db3aab 100644
>>> --- a/drivers/media/dvb-frontends/cxd2820r_c.c
>>> +++ b/drivers/media/dvb-frontends/cxd2820r_c.c
>>> @@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
>>>  
>>> num = if_freq / 1000; /* Hz => kHz */
>>> num *= 0x4000;
>>> -   if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
>>> +   if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
>>> buf[0] = (if_ctl >> 8) & 0x3f;
>>> buf[1] = (if_ctl >> 0) & 0xff;
>>>  
>>> diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
>>> b/drivers/media/dvb-frontends/cxd2820r_core.c
>>> index 422e84bbb008..490e090048ef 100644
>>> --- a/drivers/media/dvb-frontends/cxd2820r_core.c
>>> +++ b/drivers/media/dvb-frontends/cxd2820r_core.c
>>> @@ -244,12 +244,6 @@ error:
>>> return ret;
>>>  }
>>>  
>>> -/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
>>> -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
>>> -{
>>> -   return div_u64(dividend + (divisor / 2), divisor);
>>> -}
>>
>> Technically, I'd say this has a bug, because the result
>> needs to be 64 bits wide or your results might be much
>> different from what might be desired.
>>
>> Practically though, I'm pretty sure all callers provide
>> values that ensure the result is valid.
> 
> All the callers are substituted in this patch so we can make sure that
> they are all correct.
> 
>> I only call attention because this patch changes the return
>> type of the function that gets called to do the calculation.
> 
> I'm not sure I follow.  Do you mean that this:
> 
>   if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
> 
> Should actually be:
> 
>   if_ctl = 0x4000 - (u32)DIV_ROUND_CLOSEST_ULL(num, 41000);

I'm merely stating that your change includes changing the
type of the value returned (cxd2820r_div_u64_round_closest()
returns u32, DIV_ROUND_CLOSEST_ULL() returns U64).  So
in that respect, your patch is not completely trivial.

That said, as you point out (and I also did a quick check)
it does not seem to be an issue here.

The bug (if you call it that) existed before your patch, and
I am not suggesting you change anything.  Just hoping for
a verification that the different return type does not
lead to any problems.  I'm convinced.

-Alex



> ?
> 
> if_ctl is a u16 so I don't think you gain anything by doing that.
> 
>>> -
>>>  static int cxd2820r_set_frontend(struct dvb_frontend *fe)
>>>  {
>>> struct cxd2820r_priv *priv = fe->demodulator_priv;
>>> diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
>>> b/drivers/media/dvb-frontends/cxd2820r_priv.h
>>> index 7ff5f60c83e1..4b428959b16e 100644
>>> --- a/drivers/media/dvb-frontends/cxd2820r_priv.h
>>> +++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
>>> @@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 
>>> reg, u8 val,
>>>  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
>>> int len);
>>>  
>>> -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
>>> -
>>>  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
>>> int len);
>>>  
>>> diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
>>> b/drivers/media/dvb-frontends/cxd2820r_t.c
>>> index 51401d036530..008cb2ac8480 100644
>>> --- a/drivers/media/dvb-frontends/cxd2820r_t.c
>>> +++ b/drivers/media/dvb-frontends/cxd2820r_t.c
>>> @@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)
>>>  
>>> num = if_freq / 1000; /* Hz => kHz */
>>> num *= 0x100;
>>> -   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
>>> +   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
> 
> if_ctl is a u32, so you get the same behavior that you were getting
> before: the downcasting of u64 to u32 happened in
> cxd2820r_div_u64_round_closest(), now it happens here.
> 
>>> buf[0] = ((if_ctl >> 16) & 0xff);
>>> buf[1] = ((if_ctl >>  8) & 0xff);
>>> buf[2] = ((if_ctl >>  0) & 0xff);
>>> diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
>>> 

[PATCH libdrm 0/5] Yet another round of Android build cleanups

[Chih-Wei Huang]

Is there any gating item to prevent
these patches (5+2) from being merged?

2015-03-19 10:56 GMT+08:00 Chih-Wei Huang :
> 2015-03-19 10:06 GMT+08:00 Emil Velikov :
>> On 18/03/15 16:38, Chih-Wei Huang wrote:
>>> 2015-03-18 9:37 GMT+08:00 Emil Velikov :
 > On 18 March 2015 at 01:19, Chih-Wei Huang  
 > wrote:
> >>
> >> I would suggest to remove all the use of LIBDRM_TOP.
> >> Do you want me to submit a patch?
 > Hmm I'm not sure that things will work correctly if we directly
 > substitute LIBDRM_TOP with LOCAL_PATH within the following.
 >
 > mkfiles := $(patsubst %,$(LIBDRM_TOP)/%/Android.mk,$(SUBDIRS))
>>> Sure. It works.
>>> But I prefer to simplify it by android build system
>>> built-in functions. See the attached 0001-* patch.
>>>
>>> 0002-* removes LIBDRM_TOP entirely.
>>>
>> I realise that most people aren't too exited about Android, but for the
>> future please try to use git send-email when sending patches to
>> dri-devel or mesa-dev. I've included them below for posterity.
>>
>> Patches look good imho. Just one question - when was the
>> all-makefiles-under macro introduced ? I haven't seen it used too often.
>
> It's introduced since very early day of android.
> (git blame shows it's in commit 88b60799)
>
> Personally I use it often.



-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org

[PATCH v2 4/6] drm/exynos: dsi: add support for Exynos5433 SoC

[Hyungwon Hwang]

Dear Andrej,

On Thu, 19 Mar 2015 10:32:10 +0100
Andrzej Hajda  wrote:

> On 03/19/2015 02:18 AM, Hyungwon Hwang wrote:
> > Dear Daniel,
> > 
> > On Thu, 19 Mar 2015 01:13:21 +
> > Daniel Stone  wrote:
> > 
> >> Hi Hyungwon,
> >>
> >> On 19 March 2015 at 01:02, Hyungwon Hwang
> >>  wrote:
> > +   /*
> > +* The input PLL clock for MIPI DSI in Exynos5433 seems
> > to be fixed
> > +* by OSC CLK.
> > +*/
> > +   fin = 24 * MHZ;
> 
>  Er, is this always true on other platforms as well? Shouldn't
>  this be a part of the DeviceTree description?
> >>>
> >>> I forgot to change the comment in development. Finally it is found
> >>> that all exynos mipi dsi's fin is OSC clk which is 24 MHz. So I
> >>> will remove the comment, but remain the code as it is.
> >>
> >> Fair enough. Should pll_clk be removed from the DT description
> >> then, if it's fixed to the oscillator?
> > 
> > Yes. It is redundant to represent pll_clk in DT, and it should be
> > removed.
> 
> Why do you think OSC clk determines value of pll_clk?
> pll_clk is mapped to SCLK_MIPI[01] or SCLK_DSIM0 gate with few
> dividers and muxes above. So at least in theory it can differ from
> osc clk. Additionally this gate should be enabled so you cannot just
> remove it from DT.
> 
> Regards
> Andrzej

As I found, pll clk is not SCLK_MIPI[01] but OSC CLK. SCLK_DSIM0 must
be controlled in this driver as it has been, as a gate clock of MIPI
DSI block, but not as a pll clk. SCLK_DSIM0 is not the input
clock of MIPI DPHY which provides fin in this code. So clock setting
and getting code was wrong, and must be removed.

OSC CLK is not soc-depedendant but board-dependant, even though I have
not seen any board which does not use OSC CLK by 24 MHz. It must be
parsed from board DT file, which in this case, we can use the value in
pll_clk_rate (the variable name must be renamed also).

Because ambiguous description in the technical document, I can be
wrong. Please let me know if I do not understand something. Thanks for
your comment.

Best regards,
Hyungwon Hwang

> 
> > 
> >>
> >>> Thanks for your review. I will send it again with the changes you
> >>> suggested.
> >>
> >> Thanks very much!
> >>
> >> Cheers,
> >> Daniel
> > 
> > Best regards,
> > Hyungwon Hwang
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > devicetree" in the body of a message to
> > majordomo-u79uwXL29TY76Z2rM5mHXA at public.gmane.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> > 
> 

[PATCH libdrm 4/8] xf86drmSL: Fix neighbour printing

[Jan Vesely]

On Fri, 2015-03-20 at 17:38 +, Emil Velikov wrote:
> On 27/02/15 18:07, Jan Vesely wrote:
> > Signed-off-by: Jan Vesely 
> > ---
> >  xf86drmSL.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xf86drmSL.c b/xf86drmSL.c
> > index acddb54..2160bb8 100644
> > --- a/xf86drmSL.c
> > +++ b/xf86drmSL.c
> > @@ -266,11 +266,14 @@ int drmSLLookupNeighbors(void *l, unsigned long key,
> >  SkipListPtr   list = (SkipListPtr)l;
> >  SLEntryPtrupdate[SL_MAX_LEVEL + 1];
> >  int   retcode = 0;
> > +SLEntryPtrentry;
> > +
> > +entry = SLLocate(list, key, update);
> >  
> >  *prev_key   = *next_key   = key;
> >  *prev_value = *next_value = NULL;
> > -   
> > -if (update[0]) {
> > +
> > +if (entry && update[0]) {
> From a very brief look at git log, the entry check should not be needed.
> Must admit that I've not looked at all in the implementation of either
> SLLocate or drmSLLookupNeighbors.

SLLocate might return early and leave the array uninitialized. All other
calls to it check the return value. I guess the warning that the
previous commit tried to fix was "set-but-unused" variable.

> 
> That said it seems that none of the three files
> (xf86drm{SL,Hash,Random}) has been build as a program for a while. Maybe
> we could split it out as a standalone test and let it churn at make
> check time ?

Sounds like a good idea. I'll try to take a look when time permits, but
I'd leave that as a separate patch.

thanks,
jan

> 
> Cheers,
> Emil

-- 
Jan Vesely 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150320/79550235/attachment-0001.sig>

[PATCH] drm/omap: tiler: add hibernation callback

[Tomi Valkeinen]

On 18/03/15 16:56, Grygorii.Strashko at linaro.org wrote:
> Hi All,
> 
> On 02/25/2015 08:08 PM, grygorii.strashko at linaro.org wrote:
>> From: Grygorii Strashko 
>>
>> Setting a dev_pm_ops resume callback but not a set of
>> hibernation handler means that pm function will not be
>> called upon hibernation.
>> Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
>> assigns the suspend and hibernation handlers and move
>> omap_dmm_resume under CONFIG_PM_SLEEP to avoid build warnings.
>>
>> Signed-off-by: Grygorii Strashko 
>> ---
>>   drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 +++---
>>   1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> index 56c6055..afb8cfc 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
>> @@ -941,7 +941,7 @@ error:
>>   }
>>   #endif
>>
>> -#ifdef CONFIG_PM
>> +#ifdef CONFIG_PM_SLEEP
>>   static int omap_dmm_resume(struct device *dev)
>>   {
>>   struct tcm_area area;
>> @@ -965,12 +965,10 @@ static int omap_dmm_resume(struct device *dev)
>>
>>   return 0;
>>   }
>> -
>> -static const struct dev_pm_ops omap_dmm_pm_ops = {
>> -.resume = omap_dmm_resume,
>> -};
>>   #endif
>>
>> +SIMPLE_DEV_PM_OPS(omap_dmm_pm_ops, NULL, omap_dmm_resume);
>> +
>>   #if defined(CONFIG_OF)
>>   static const struct of_device_id dmm_of_match[] = {
>>   { .compatible = "ti,omap4-dmm", },
>> @@ -986,9 +984,7 @@ struct platform_driver omap_dmm_driver = {
>>   .owner = THIS_MODULE,
>>   .name = DMM_DRIVER_NAME,
>>   .of_match_table = of_match_ptr(dmm_of_match),
>> -#ifdef CONFIG_PM
>>   .pm = _dmm_pm_ops,
>> -#endif
>>   },
>>   };
>>
>>
> 
> Any comments on this?

Sorry, I missed this. I'll add it to my omapdrm branch.

 Tomi


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

[PATCH] radeon: Do not directly dereference pointers to BIOS area.

[David Miller]

From: Christian König 
Date: Fri, 20 Mar 2015 10:38:32 +0100

> On 19.03.2015 17:29, David Miller wrote:
>> From: Christian König 
>> Date: Thu, 19 Mar 2015 09:50:58 +0100
>>
>>> In general I would say yes, but for this particular hardware it's a
>>> bit questionable to do so.
>>>
>>> For radeon hardware to work correctly the CPU access to the PCIE BARs
>>> should work even without using the specialized IO macros/functions,
>>> otherwise mapping VRAM CPU accessible isn't really possible.
>>>
>>> What's the background of the change? Some problems on a certain CPU
>>> platform? or just general cleanups?
>> It's an _iomem_ pointer, it's not a virtual address.
>>
>> Therefore it is illegal to dereference the pointer.
>>
>> The value is opaque and has values that only make sense when used
>> with the readb() et al. interfaces.
>>
>> This code is relying upon the fact that on x86 it happens to be
>> a virtual address, but this won't work on many other architectures.
> 
> In this case I'm perfectly fine with it and the patch is Reviewed-by:
> Christian König 
> 
> Just wanted to make sure that you're not trying to get Radeon working
> on a platform which will never really support the necessary hardware
> features.

I would like this to get merged via the Radeon DRM maintainer, thanks.

[PATCH 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

[Antti Palosaari]

On 03/20/2015 01:14 PM, Javi Merino wrote:
> Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
> implementation and use the kernel one.
>
> Cc: Antti Palosaari 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Javi Merino 

Acked-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 


Antti

> ---
> I've only compile-tested it, I don't have the hardware to run it.
>
>   drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
>   drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
>   drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
>   drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
>   drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
>   5 files changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
> b/drivers/media/dvb-frontends/cxd2820r_c.c
> index 149fdca3fb44..72b0e2db3aab 100644
> --- a/drivers/media/dvb-frontends/cxd2820r_c.c
> +++ b/drivers/media/dvb-frontends/cxd2820r_c.c
> @@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
>
>   num = if_freq / 1000; /* Hz => kHz */
>   num *= 0x4000;
> - if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
> + if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
>   buf[0] = (if_ctl >> 8) & 0x3f;
>   buf[1] = (if_ctl >> 0) & 0xff;
>
> diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
> b/drivers/media/dvb-frontends/cxd2820r_core.c
> index 422e84bbb008..490e090048ef 100644
> --- a/drivers/media/dvb-frontends/cxd2820r_core.c
> +++ b/drivers/media/dvb-frontends/cxd2820r_core.c
> @@ -244,12 +244,6 @@ error:
>   return ret;
>   }
>
> -/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
> -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
> -{
> - return div_u64(dividend + (divisor / 2), divisor);
> -}
> -
>   static int cxd2820r_set_frontend(struct dvb_frontend *fe)
>   {
>   struct cxd2820r_priv *priv = fe->demodulator_priv;
> diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
> b/drivers/media/dvb-frontends/cxd2820r_priv.h
> index 7ff5f60c83e1..4b428959b16e 100644
> --- a/drivers/media/dvb-frontends/cxd2820r_priv.h
> +++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
> @@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 
> reg, u8 val,
>   int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
>   int len);
>
> -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
> -
>   int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
>   int len);
>
> diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
> b/drivers/media/dvb-frontends/cxd2820r_t.c
> index 51401d036530..008cb2ac8480 100644
> --- a/drivers/media/dvb-frontends/cxd2820r_t.c
> +++ b/drivers/media/dvb-frontends/cxd2820r_t.c
> @@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)
>
>   num = if_freq / 1000; /* Hz => kHz */
>   num *= 0x100;
> - if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
> + if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
>   buf[0] = ((if_ctl >> 16) & 0xff);
>   buf[1] = ((if_ctl >>  8) & 0xff);
>   buf[2] = ((if_ctl >>  0) & 0xff);
> diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
> b/drivers/media/dvb-frontends/cxd2820r_t2.c
> index 9c0c4f42175c..35fe364c7182 100644
> --- a/drivers/media/dvb-frontends/cxd2820r_t2.c
> +++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
> @@ -120,7 +120,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)
>
>   num = if_freq / 1000; /* Hz => kHz */
>   num *= 0x100;
> - if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
> + if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
>   buf[0] = ((if_ctl >> 16) & 0xff);
>   buf[1] = ((if_ctl >>  8) & 0xff);
>   buf[2] = ((if_ctl >>  0) & 0xff);
>

-- 
http://palosaari.fi/

screen goes blank when loading gma500_gfx (atom D2500)

[Michael Tokarev]

19.03.2015 23:05, One Thousand Gnomes wrote:
>> Yes, with video=LVDS-1:d boot parameter, kernel boots fine and there is
>> graphics/video output on the screen, with the following message from kernel
>> when loading gma500_gfx:
>>
>> [6.472859] [drm] forcing LVDS-1 connector OFF
>>
>> (and a few others).
>>
>> There's one funky thing still -- the screen size is not calculated correctly
>> for the text (vga, d-sub) console, last text line is placed at about 3/4 of
>> the screen size, with the rest - 1/4 - of the screen being blank.
> 
> I've seen that in one other case, where what was in fact happening was
> that forcing the connector "off" was actually effectively leaving it as
> the BIOS set it.

When I use LVDS-1:d in the kernel command line, that connector is not shown
by utilities such as xrandr, at all.  There is, however, another connector,
named LVDS-0, and are also DVI-0, DVI-1, and DisplayPort-0, DisplayPort-1,
while this mobo only have DVI & D-SUB (and LVDS soldered on board too) and
no DP.  At least as far as I can see.  So at least one LVDS connector is
shown anyway (LVDS-0, not LVDS-1), and that one is "not connected".

Besides, DisplayPort-1 is shown as "connected" by xrandr, with monitor set
to 1024x768 mode, -- I think this is why the text VGA size is calculated
wrong.. Lemme see...

..nope.  Adding video=DisplayPort-1:d to the kernel command line (in
addition to video=LVDS-1:d) makes no difference, DisplayPort-1 is still
shown by xrandr as connected @1024x768.

> What happens if you then use xrandr to change the
> display sizes ?

X11 works fine as far as I can see.  Xrandr works and changes video modes.
Once I switch from X back to the text console the text size occupes 3/4 of
the screen only, as if the monitor was smaller.

I wonder if it will work with more than one monitor... ;)  I'll try hopefully
today.

Thanks,

/mjt

[PATCH 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

[Javi Merino]

Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
implementation and use the kernel one.

Cc: Antti Palosaari 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Javi Merino 
---
I've only compile-tested it, I don't have the hardware to run it.

 drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
 drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
 drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
 drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
 drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
 5 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
b/drivers/media/dvb-frontends/cxd2820r_c.c
index 149fdca3fb44..72b0e2db3aab 100644
--- a/drivers/media/dvb-frontends/cxd2820r_c.c
+++ b/drivers/media/dvb-frontends/cxd2820r_c.c
@@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz => kHz */
num *= 0x4000;
-   if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = (if_ctl >> 8) & 0x3f;
buf[1] = (if_ctl >> 0) & 0xff;

diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
b/drivers/media/dvb-frontends/cxd2820r_core.c
index 422e84bbb008..490e090048ef 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -244,12 +244,6 @@ error:
return ret;
 }

-/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
-u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
-{
-   return div_u64(dividend + (divisor / 2), divisor);
-}
-
 static int cxd2820r_set_frontend(struct dvb_frontend *fe)
 {
struct cxd2820r_priv *priv = fe->demodulator_priv;
diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
b/drivers/media/dvb-frontends/cxd2820r_priv.h
index 7ff5f60c83e1..4b428959b16e 100644
--- a/drivers/media/dvb-frontends/cxd2820r_priv.h
+++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
@@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 reg, 
u8 val,
 int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
int len);

-u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
-
 int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
int len);

diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
b/drivers/media/dvb-frontends/cxd2820r_t.c
index 51401d036530..008cb2ac8480 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t.c
@@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz => kHz */
num *= 0x100;
-   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = ((if_ctl >> 16) & 0xff);
buf[1] = ((if_ctl >>  8) & 0xff);
buf[2] = ((if_ctl >>  0) & 0xff);
diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
b/drivers/media/dvb-frontends/cxd2820r_t2.c
index 9c0c4f42175c..35fe364c7182 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t2.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
@@ -120,7 +120,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz => kHz */
num *= 0x100;
-   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = ((if_ctl >> 16) & 0xff);
buf[1] = ((if_ctl >>  8) & 0xff);
buf[2] = ((if_ctl >>  0) & 0xff);
-- 
1.9.1

[PATCH 3/4] cpuidle: menu: use DIV_ROUND_CLOSEST_ULL()

[Javi Merino]

Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
implementation and use the kernel one.

Cc: "Rafael J. Wysocki" 
Cc: Mel Gorman 
Cc: Stephen Hemminger 
Signed-off-by: Javi Merino 
---
 drivers/cpuidle/governors/menu.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 40580794e23d..b8a5fa15ca24 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -190,12 +190,6 @@ static DEFINE_PER_CPU(struct menu_device, menu_devices);

 static void menu_update(struct cpuidle_driver *drv, struct cpuidle_device 
*dev);

-/* This implements DIV_ROUND_CLOSEST but avoids 64 bit division */
-static u64 div_round64(u64 dividend, u32 divisor)
-{
-   return div_u64(dividend + (divisor / 2), divisor);
-}
-
 /*
  * Try detecting repeating patterns by keeping track of the last 8
  * intervals, and checking if the standard deviation of that set
@@ -317,7 +311,7 @@ static int menu_select(struct cpuidle_driver *drv, struct 
cpuidle_device *dev)
 * operands are 32 bits.
 * Make sure to round up for half microseconds.
 */
-   data->predicted_us = div_round64((uint64_t)data->next_timer_us *
+   data->predicted_us = 
DIV_ROUND_CLOSEST_ULL((uint64_t)data->next_timer_us *
 data->correction_factor[data->bucket],
 RESOLUTION * DECAY);

-- 
1.9.1

[PATCH 2/4] clk: bcm/kona: use DIV_ROUND_CLOSEST_ULL()

[Javi Merino]

Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
implementation and use the kernel one.

Cc: Mike Turquette 
Cc: Stephen Boyd 
Cc: Alex Elder 
Signed-off-by: Javi Merino 
---
I've only compile-tested this, I don't have the hardware to test it.

 drivers/clk/bcm/clk-kona.c | 28 +++-
 drivers/clk/bcm/clk-kona.h |  1 -
 2 files changed, 7 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/bcm/clk-kona.c b/drivers/clk/bcm/clk-kona.c
index 05abae89262e..a0ef4f75d457 100644
--- a/drivers/clk/bcm/clk-kona.c
+++ b/drivers/clk/bcm/clk-kona.c
@@ -15,6 +15,7 @@
 #include "clk-kona.h"

 #include 
+#include 

 /*
  * "Policies" affect the frequencies of bus clocks provided by a
@@ -51,21 +52,6 @@ static inline u32 bitfield_replace(u32 reg_val, u32 shift, 
u32 width, u32 val)

 /* Divider and scaling helpers */

-/*
- * Implement DIV_ROUND_CLOSEST() for 64-bit dividend and both values
- * unsigned.  Note that unlike do_div(), the remainder is discarded
- * and the return value is the quotient (not the remainder).
- */
-u64 do_div_round_closest(u64 dividend, unsigned long divisor)
-{
-   u64 result;
-
-   result = dividend + ((u64)divisor >> 1);
-   (void)do_div(result, divisor);
-
-   return result;
-}
-
 /* Convert a divider into the scaled divisor value it represents. */
 static inline u64 scaled_div_value(struct bcm_clk_div *div, u32 reg_div)
 {
@@ -87,7 +73,7 @@ u64 scaled_div_build(struct bcm_clk_div *div, u32 div_value, 
u32 billionths)
combined = (u64)div_value * BILLION + billionths;
combined <<= div->u.s.frac_width;

-   return do_div_round_closest(combined, BILLION);
+   return DIV_ROUND_CLOSEST_ULL(combined, BILLION);
 }

 /* The scaled minimum divisor representable by a divider */
@@ -731,7 +717,7 @@ static unsigned long clk_recalc_rate(struct ccu_data *ccu,
scaled_rate = scale_rate(pre_div, parent_rate);
scaled_rate = scale_rate(div, scaled_rate);
scaled_div = divider_read_scaled(ccu, pre_div);
-   scaled_parent_rate = do_div_round_closest(scaled_rate,
+   scaled_parent_rate = DIV_ROUND_CLOSEST_ULL(scaled_rate,
scaled_div);
} else  {
scaled_parent_rate = scale_rate(div, parent_rate);
@@ -743,7 +729,7 @@ static unsigned long clk_recalc_rate(struct ccu_data *ccu,
 * rate.
 */
scaled_div = divider_read_scaled(ccu, div);
-   result = do_div_round_closest(scaled_parent_rate, scaled_div);
+   result = DIV_ROUND_CLOSEST_ULL(scaled_parent_rate, scaled_div);

return (unsigned long)result;
 }
@@ -790,7 +776,7 @@ static long round_rate(struct ccu_data *ccu, struct 
bcm_clk_div *div,
scaled_rate = scale_rate(pre_div, parent_rate);
scaled_rate = scale_rate(div, scaled_rate);
scaled_pre_div = divider_read_scaled(ccu, pre_div);
-   scaled_parent_rate = do_div_round_closest(scaled_rate,
+   scaled_parent_rate = DIV_ROUND_CLOSEST_ULL(scaled_rate,
scaled_pre_div);
} else {
scaled_parent_rate = scale_rate(div, parent_rate);
@@ -802,7 +788,7 @@ static long round_rate(struct ccu_data *ccu, struct 
bcm_clk_div *div,
 * the best we can do.
 */
if (!divider_is_fixed(div)) {
-   best_scaled_div = do_div_round_closest(scaled_parent_rate,
+   best_scaled_div = DIV_ROUND_CLOSEST_ULL(scaled_parent_rate,
rate);
min_scaled_div = scaled_div_min(div);
max_scaled_div = scaled_div_max(div);
@@ -815,7 +801,7 @@ static long round_rate(struct ccu_data *ccu, struct 
bcm_clk_div *div,
}

/* OK, figure out the resulting rate */
-   result = do_div_round_closest(scaled_parent_rate, best_scaled_div);
+   result = DIV_ROUND_CLOSEST_ULL(scaled_parent_rate, best_scaled_div);

if (scaled_div)
*scaled_div = best_scaled_div;
diff --git a/drivers/clk/bcm/clk-kona.h b/drivers/clk/bcm/clk-kona.h
index 2537b3072910..6849a64baf6d 100644
--- a/drivers/clk/bcm/clk-kona.h
+++ b/drivers/clk/bcm/clk-kona.h
@@ -503,7 +503,6 @@ extern struct clk_ops kona_peri_clk_ops;

 /* Externally visible functions */

-extern u64 do_div_round_closest(u64 dividend, unsigned long divisor);
 extern u64 scaled_div_max(struct bcm_clk_div *div);
 extern u64 scaled_div_build(struct bcm_clk_div *div, u32 div_value,
u32 billionths);
-- 
1.9.1

[PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

[Javi Merino]

We have grown a number of different implementations of
DIV_ROUND_CLOSEST_ULL throughout the kernel.  Move the i915 one to
kernel.h so that it can be reused.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: David Airlie 
Cc: Darrick J. Wong 
Cc: Guenter Roeck 
Cc: Andrew Morton 
Signed-off-by: Javi Merino 
---
 drivers/gpu/drm/i915/intel_drv.h |  4 +---
 include/linux/kernel.h   | 11 +++
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index eef79ccd0b7c..346e28fdd7dd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "i915_drv.h"
 #include 
@@ -36,9 +37,6 @@
 #include 
 #include 

-#define DIV_ROUND_CLOSEST_ULL(ll, d)   \
-({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; })
-
 /**
  * _wait_for - magic (register) wait macro
  *
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d6d630d31ef3..f7d744e9d275 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -103,6 +103,17 @@
(((__x) - ((__d) / 2)) / (__d));\
 }  \
 )
+/*
+ * Same as above but for u64 dividends.  divisor must be a 32-bit
+ * number.
+ */
+#define DIV_ROUND_CLOSEST_ULL(x, divisor)( \
+{  \
+   unsigned long long _tmp = (x) + (divisor) / 2;  \
+   do_div(_tmp, divisor);  \
+   _tmp;   \
+}  \
+)

 /*
  * Multiplies an integer by a fraction, while avoiding unnecessary
-- 
1.9.1

[PATCH 0/4] Consolidate DIV_ROUND_CLOSEST_ULL()

[Javi Merino]

The kernel has grown a number of different implementations of
DIV_ROUND_CLOSEST_ULL().  That is, a macro that does the same as
DIV_ROUND_CLOSEST() but with the first operand being an unsigned long
long.  That means that you have to do the division using do_div()
instead of using the C division operator '/'.

This series move the implementation in
drivers/gpu/drm/i915/intel_drv.h to linux/kernel.h and then removes
the other similar implementations of the same code in
drivers/clk/bcm/clk-kona.h, drivers/cpuidle/governors/menu.c and
drivers/media/dvb-frontends/cxd2820r_priv.h in favor of the one in
kernel.h

Javi Merino (4):
  kernel.h: Implement DIV_ROUND_CLOSEST_ULL
  clk: bcm/kona: use DIV_ROUND_CLOSEST_ULL()
  cpuidle: menu: use DIV_ROUND_CLOSEST_ULL()
  media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

 drivers/clk/bcm/clk-kona.c  | 28 +++-
 drivers/clk/bcm/clk-kona.h  |  1 -
 drivers/cpuidle/governors/menu.c|  8 +---
 drivers/gpu/drm/i915/intel_drv.h|  4 +---
 drivers/media/dvb-frontends/cxd2820r_c.c|  2 +-
 drivers/media/dvb-frontends/cxd2820r_core.c |  6 --
 drivers/media/dvb-frontends/cxd2820r_priv.h |  2 --
 drivers/media/dvb-frontends/cxd2820r_t.c|  2 +-
 drivers/media/dvb-frontends/cxd2820r_t2.c   |  2 +-
 include/linux/kernel.h  | 11 +++
 10 files changed, 23 insertions(+), 43 deletions(-)

-- 
1.9.1

[PATCH] radeon: Do not directly dereference pointers to BIOS area.

[Christian König]

On 19.03.2015 17:29, David Miller wrote:
> From: Christian König 
> Date: Thu, 19 Mar 2015 09:50:58 +0100
>
>> In general I would say yes, but for this particular hardware it's a
>> bit questionable to do so.
>>
>> For radeon hardware to work correctly the CPU access to the PCIE BARs
>> should work even without using the specialized IO macros/functions,
>> otherwise mapping VRAM CPU accessible isn't really possible.
>>
>> What's the background of the change? Some problems on a certain CPU
>> platform? or just general cleanups?
> It's an _iomem_ pointer, it's not a virtual address.
>
> Therefore it is illegal to dereference the pointer.
>
> The value is opaque and has values that only make sense when used
> with the readb() et al. interfaces.
>
> This code is relying upon the fact that on x86 it happens to be
> a virtual address, but this won't work on many other architectures.

In this case I'm perfectly fine with it and the patch is Reviewed-by: 
Christian König 

Just wanted to make sure that you're not trying to get Radeon working on 
a platform which will never really support the necessary hardware features.

Regards,
Christian.

[PATCH] radeon: Do not directly dereference pointers to BIOS area.

[Alex Deucher]

On Fri, Mar 20, 2015 at 5:38 AM, Christian König
 wrote:
> On 19.03.2015 17:29, David Miller wrote:
>>
>> From: Christian König 
>> Date: Thu, 19 Mar 2015 09:50:58 +0100
>>
>>> In general I would say yes, but for this particular hardware it's a
>>> bit questionable to do so.
>>>
>>> For radeon hardware to work correctly the CPU access to the PCIE BARs
>>> should work even without using the specialized IO macros/functions,
>>> otherwise mapping VRAM CPU accessible isn't really possible.
>>>
>>> What's the background of the change? Some problems on a certain CPU
>>> platform? or just general cleanups?
>>
>> It's an _iomem_ pointer, it's not a virtual address.
>>
>> Therefore it is illegal to dereference the pointer.
>>
>> The value is opaque and has values that only make sense when used
>> with the readb() et al. interfaces.
>>
>> This code is relying upon the fact that on x86 it happens to be
>> a virtual address, but this won't work on many other architectures.
>
>
> In this case I'm perfectly fine with it and the patch is Reviewed-by:
> Christian König 
>
> Just wanted to make sure that you're not trying to get Radeon working on a
> platform which will never really support the necessary hardware features.
>

Applied to my tree.  Thanks!

Alex

[Bug 89374] Firefox smooth scrolling isn't smooth

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

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

--- Comment #10 from Michel Dänzer  ---
(In reply to sunweb from comment #9)
> About this non smooth scrolling issue. I feel like i am the only one here.
> If you do not have this problem than what card are you using and is it
> working as smooth as on Windows?

Not using Windows or smooth scrolling myself, I'm just not sure how smooth it's
supposed to be. Don't worry, I'm not arguing there's no problem, just making
suggestions that might improve your experience.

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

[PATCH 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

[Alex Elder]

On 03/20/2015 06:14 AM, Javi Merino wrote:
> Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
> implementation and use the kernel one.
> 
> Cc: Antti Palosaari 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Javi Merino 
> ---
> I've only compile-tested it, I don't have the hardware to run it.
> 
>  drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
>  drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
>  drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
>  drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
>  drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
>  5 files changed, 3 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
> b/drivers/media/dvb-frontends/cxd2820r_c.c
> index 149fdca3fb44..72b0e2db3aab 100644
> --- a/drivers/media/dvb-frontends/cxd2820r_c.c
> +++ b/drivers/media/dvb-frontends/cxd2820r_c.c
> @@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
>  
>   num = if_freq / 1000; /* Hz => kHz */
>   num *= 0x4000;
> - if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
> + if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
>   buf[0] = (if_ctl >> 8) & 0x3f;
>   buf[1] = (if_ctl >> 0) & 0xff;
>  
> diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
> b/drivers/media/dvb-frontends/cxd2820r_core.c
> index 422e84bbb008..490e090048ef 100644
> --- a/drivers/media/dvb-frontends/cxd2820r_core.c
> +++ b/drivers/media/dvb-frontends/cxd2820r_core.c
> @@ -244,12 +244,6 @@ error:
>   return ret;
>  }
>  
> -/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
> -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
> -{
> - return div_u64(dividend + (divisor / 2), divisor);
> -}

Technically, I'd say this has a bug, because the result
needs to be 64 bits wide or your results might be much
different from what might be desired.

Practically though, I'm pretty sure all callers provide
values that ensure the result is valid.

I only call attention because this patch changes the return
type of the function that gets called to do the calculation.

-Alex

> -
>  static int cxd2820r_set_frontend(struct dvb_frontend *fe)
>  {
>   struct cxd2820r_priv *priv = fe->demodulator_priv;
> diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
> b/drivers/media/dvb-frontends/cxd2820r_priv.h
> index 7ff5f60c83e1..4b428959b16e 100644
> --- a/drivers/media/dvb-frontends/cxd2820r_priv.h
> +++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
> @@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 
> reg, u8 val,
>  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
>   int len);
>  
> -u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
> -
>  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
>   int len);
>  
> diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
> b/drivers/media/dvb-frontends/cxd2820r_t.c
> index 51401d036530..008cb2ac8480 100644
> --- a/drivers/media/dvb-frontends/cxd2820r_t.c
> +++ b/drivers/media/dvb-frontends/cxd2820r_t.c
> @@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)
>  
>   num = if_freq / 1000; /* Hz => kHz */
>   num *= 0x100;
> - if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
> + if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
>   buf[0] = ((if_ctl >> 16) & 0xff);
>   buf[1] = ((if_ctl >>  8) & 0xff);
>   buf[2] = ((if_ctl >>  0) & 0xff);
> diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
> b/drivers/media/dvb-frontends/cxd2820r_t2.c
> index 9c0c4f42175c..35fe364c7182 100644
> --- a/drivers/media/dvb-frontends/cxd2820r_t2.c
> +++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
> @@ -120,7 +120,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)
>  
>   num = if_freq / 1000; /* Hz => kHz */
>   num *= 0x100;
> - if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
> + if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
>   buf[0] = ((if_ctl >> 16) & 0xff);
>   buf[1] = ((if_ctl >>  8) & 0xff);
>   buf[2] = ((if_ctl >>  0) & 0xff);
> 

[PATCH 1/4] kernel.h: Implement DIV_ROUND_CLOSEST_ULL

[Alex Elder]

On 03/20/2015 06:14 AM, Javi Merino wrote:
> We have grown a number of different implementations of
> DIV_ROUND_CLOSEST_ULL throughout the kernel.  Move the i915 one to
> kernel.h so that it can be reused.
> 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: David Airlie 
> Cc: Darrick J. Wong 
> Cc: Guenter Roeck 
> Cc: Andrew Morton 
> Signed-off-by: Javi Merino 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |  4 +---
>  include/linux/kernel.h   | 11 +++
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index eef79ccd0b7c..346e28fdd7dd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "i915_drv.h"
>  #include 
> @@ -36,9 +37,6 @@
>  #include 
>  #include 
>  
> -#define DIV_ROUND_CLOSEST_ULL(ll, d) \
> -({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; })
> -
>  /**
>   * _wait_for - magic (register) wait macro
>   *
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index d6d630d31ef3..f7d744e9d275 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -103,6 +103,17 @@
>   (((__x) - ((__d) / 2)) / (__d));\
>  }\
>  )
> +/*
> + * Same as above but for u64 dividends.  divisor must be a 32-bit
> + * number.
> + */
> +#define DIV_ROUND_CLOSEST_ULL(x, divisor)(   \
> +{\
> + unsigned long long _tmp = (x) + (divisor) / 2;  \
> + do_div(_tmp, divisor);  \
> + _tmp;   \
> +}\
> +)

Since you are stipulating the types of the arguments, this
should be defined as a static inline function instead.

DIV_ROUND_CLOSEST() could conceivably handle a 64-bit
dividend properly, although that macro is already a bit
hard to look at.

-Alex

>  
>  /*
>   * Multiplies an integer by a fraction, while avoiding unnecessary
> 

[Bug 89688] Gwenview hangs after opening a picture if glamor is used

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

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|DRM/Radeon  |Driver/glamor
Version|XOrg git|unspecified
   Assignee|dri-devel at lists.freedesktop |xorg-team at lists.x.org
   |.org|
Product|DRI |xorg
 QA Contact||xorg-team at lists.x.org

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

[Bug 89688] Gwenview hangs after opening a picture if glamor is used

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

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

--- Comment #1 from Michel Dänzer  ---
I can't seem to reproduce this with Gwenview/KDE 4.14.2. Can you attach
screenshots showing the problem and what it looks like with EXA?

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

[Bug 89374] Firefox smooth scrolling isn't smooth

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

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

--- Comment #9 from sunweb at hotmail.ru ---
(In reply to Michel Dänzer from comment #8)
> With current xf86-video-ati Git master, you can enable DRI3 with Option
> "DRI3" in xorg.conf. Then "Re-use screen content" should work well. The
> breakage without that sounds like a kwin issue.
I always experience some troubles using the latest versions so i stay ou of it.
But i wouldn't want to use this option because on EXA i have no tearing even
with Vsync = none.

About this non smooth scrolling issue. I feel like i am the only one here. If
you do not have this problem than what card are you using and is it working as
smooth as on Windows?

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

[Bug 89688] Gwenview hangs after opening a picture if glamor is used

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

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

Bug ID: 89688
   Summary: Gwenview hangs after opening a picture if glamor is
used
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: sunweb at hotmail.ru

Kubuntu 14.04 x64, HD5770
Qt: 4.8.6
KDE Development Platform: 4.13.3
Gwenview: 4.13.1

cat /etc/X11/xorg.conf
Section "Device"
Identifier "Device0"
Driver  "radeon"
Option  "AccelMethod" "glamor"
EndSection

After openin one picture Gwenview hangs and becomes unresponsive. And you can
see that bottom panel is not filled with mini pictures that represent the ones
in the same folder.

Reproducable only with glamor, with EXA everything works.

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

[PATCH libdrm] tests: add rockchip to modetest, kmstest, vbltest and proptest

[Daniel Kurtz]

On Fri, Mar 20, 2015 at 1:50 AM, Emil Velikov  
wrote:
> On 19/03/15 17:42, Daniel Kurtz wrote:
>> On Fri, Mar 6, 2015 at 4:52 PM, Daniel Kurtz  wrote:
>>> There is a rockchip drm kms driver.
>>> Add "rockchip" to the static lists of driver names in the the standard
>>> set of tests.
>>>
>>> Signed-off-by: Daniel Kurtz 
>>
>> Ping?
>>
>> Can somebody please help review & push this patch.
>>
> Might be a silly question:
>
> Do we have a kernel version (or a Linus tree) where the rockchip drm
> module landed ? Must admit I didn't pay close attention to it.

Here's the commit that added drm/rockchip to mainline:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/rockchip?id=2048e3286f347db5667708e47448176b5329e8d8

It was picked up by v3.19-rc1

>
> If so I'll push both patches later on today. They are quite trivial and
> has been around for quite some time.
>
> Thanks
> Emil
>

[PATCH libdrm] proptest: install it with --enable-install-test-programs

[Daniel Kurtz]

On Fri, Mar 6, 2015 at 4:54 PM, Daniel Kurtz  wrote:
> --enable-install-test-programs allows tests to be installed in $bindir.
> This is disabled by default, but very useful when cross compiling.
>
> Signed-off-by: Daniel Kurtz 

Ping?

Can somebody please help review & push this patch.

Thanks,
-Dan


> ---
>  tests/proptest/Makefile.am | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/tests/proptest/Makefile.am b/tests/proptest/Makefile.am
> index 48a84c1..0594e02 100644
> --- a/tests/proptest/Makefile.am
> +++ b/tests/proptest/Makefile.am
> @@ -3,8 +3,13 @@ AM_CFLAGS = \
> -I$(top_srcdir)/include/drm \
> -I$(top_srcdir)
>
> +if HAVE_INSTALL_TESTS
> +bin_PROGRAMS = \
> +   proptest
> +else
>  noinst_PROGRAMS = \
> proptest
> +endif
>
>  proptest_SOURCES = \
> proptest.c
> --
> 2.2.0.rc0.207.ga3a616c
>

[PATCH libdrm] tests: add rockchip to modetest, kmstest, vbltest and proptest

[Daniel Kurtz]

On Fri, Mar 6, 2015 at 4:52 PM, Daniel Kurtz  wrote:
> There is a rockchip drm kms driver.
> Add "rockchip" to the static lists of driver names in the the standard
> set of tests.
>
> Signed-off-by: Daniel Kurtz 

Ping?

Can somebody please help review & push this patch.

Thanks,
-Dan

> ---
>  tests/kmstest/main.c  | 1 +
>  tests/modetest/modetest.c | 2 +-
>  tests/proptest/proptest.c | 2 +-
>  tests/vbltest/vbltest.c   | 2 +-
>  4 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/tests/kmstest/main.c b/tests/kmstest/main.c
> index 2c87b1c..fb22354 100644
> --- a/tests/kmstest/main.c
> +++ b/tests/kmstest/main.c
> @@ -63,6 +63,7 @@ char *drivers[] = {
> "vmwgfx",
> "exynos",
> "imx-drm",
> +   "rockchip",
> NULL
>  };
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 425e528..5f46efd 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -1453,7 +1453,7 @@ int main(int argc, char **argv)
> int drop_master = 0;
> int test_vsync = 0;
> int test_cursor = 0;
> -   const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", 
> "omapdrm", "exynos", "tilcdc", "msm", "sti", "tegra", "imx-drm" };
> +   const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", 
> "omapdrm", "exynos", "tilcdc", "msm", "sti", "tegra", "imx-drm", "rockchip" };
> char *device = NULL;
> char *module = NULL;
> unsigned int i;
> diff --git a/tests/proptest/proptest.c b/tests/proptest/proptest.c
> index 7618f63..a6011bf 100644
> --- a/tests/proptest/proptest.c
> +++ b/tests/proptest/proptest.c
> @@ -303,7 +303,7 @@ static void printUsage(void)
>
>  int main(int argc, char *argv[])
>  {
> -   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "omapdrm", 
> "msm" };
> +   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "omapdrm", 
> "msm", "rockchip" };
> unsigned int i, ret = 0;
>
> for (i = 0; i < ARRAY_SIZE(modules); i++){
> diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
> index 916d494..136d8f4 100644
> --- a/tests/vbltest/vbltest.c
> +++ b/tests/vbltest/vbltest.c
> @@ -106,7 +106,7 @@ int main(int argc, char **argv)
>  {
> unsigned i;
> int c, fd, ret;
> -   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos", 
> "omapdrm", "tilcdc", "msm", "tegra", "imx-drm" };
> +   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos", 
> "omapdrm", "tilcdc", "msm", "tegra", "imx-drm", "rockchip" };
> drmVBlank vbl;
> drmEventContext evctx;
> struct vbl_info handler_info;
> --
> 2.2.0.rc0.207.ga3a616c
>

[Bug 89686] x1250 rs600m graphic problems / unreadable fonts in (gl?)- games

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #114484|text/plain  |image/png
  mime type||

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

[Bug 89686] x1250 rs600m graphic problems / unreadable fonts in (gl?)- games

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

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

Bug ID: 89686
   Summary: x1250 rs600m graphic problems / unreadable fonts in
(gl?)- games
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: highest
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: m.st at gmx.net

Created attachment 114484
  --> https://bugs.freedesktop.org/attachment.cgi?id=114484=edit
Warzone

The problem is viewable in my attached picture. It's the game Teeworlds for
example - with corrupt font.

Mint 17 Mate 64 is same as in Mint 17 Xfce 64. Problems with that
notebook-graphic also on Ubuntu (and when I remember correct Debian, too)

HalfLife and Warzone 2100 looks same.

Distros were all fresh installed. (in Ubuntu/Unity the top taskbar has the same
'striped and defect'look directly at first startup after install)

Some more informations, now Mate 17.1:

dmesg | grep -i radeon

[ 3.414242] [drm] radeon kernel modesetting enabled.
[ 3.414339] fb: switching to radeondrmfb from EFI VGA
[ 3.415143] radeon :01:05.0: VRAM: 256M 0x7000 -
0x7FFF (256M used)
[ 3.415146] radeon :01:05.0: GTT: 512M 0x8000 -
0x9FFF
[ 3.415274] [drm] radeon: 256M of VRAM memory ready
[ 3.415276] [drm] radeon: 512M of GTT memory ready.
[ 3.424768] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
[ 3.426141] radeon :01:05.0: WB enabled
[ 3.426146] radeon :01:05.0: fence driver on ring 0 use gpu addr
0x8000 and cpu addr 0x880035a38000
[ 3.426166] [drm] radeon: irq initialized.
[ 3.426387] [drm] radeon: ring at 0x80001000
[ 3.428091] [drm] radeon atom DIG backlight initialized
[ 3.428096] [drm] Radeon Display Connectors
[ 4.040201] fbcon: radeondrmfb (fb0) is primary device
[ 4.040282] radeon :01:05.0: fb0: radeondrmfb frame buffer device
[ 4.040285] radeon :01:05.0: registered panic notifier
[ 4.044113] [drm] Initialized radeon 2.39.0 20080528 for :01:05.0 on minor
0


glxinfo | grep gl

server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle,
GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB,
GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_NV_vdpau_interop,

I changed nomodeset at startup with shift, e - but it resulted
in complete garbage - the splash-screen where I normally enter my password
was completely defect, b/w and absolutely unusable.

I furthermore created xorg.conf, edited it with nano at the right place and
changed the line with 'Option "EXAPixmaps"' to "off", afther that it started
nomal - but thats all, its also unusable. Screen corrupts in a way I've never
seen before, parts were rotated completely, looked crazy. But that was not what
I looked for.


Any ideas? It is impossible to play games :( Thanks for any help!

More, maybe useful, don´t know, with 1 or two more pics, too:
https://bugs.freedesktop.org/show_bug.cgi?id=35457

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

[Bug 89034] Firefox crashing xserver and some major rendering bugs

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

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

--- Comment #40 from Tom Stellard  ---
There have been a few register allocator bugs fixed in LLVM recently, can you
re-apply the "Patch to re-enable subreg liveness" to latest LLVM and test
again?

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

[PATCH 1/3] drm/exynos: don't commit if plane scaling is required

[Tobias Jakobi]

Hello Gustavo,

Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> exynos doesn't show scaled planes properly on the screen so
> disable the feature and show a message to the user.
do you know if this is a hardware limitation/issue?

With best wishes,
Tobias

[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout

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

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

Bug ID: 89685
   Summary: Cripling Dota 2 freeze with Morphling at hero
selection or loadout
   Product: Mesa
   Version: 10.5
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: wittyman37 at yahoo.com
QA Contact: dri-devel at lists.freedesktop.org

So I am having a very bizare issue as recently. I noticed yesterday that I
cannot play Morphling! If I select him during the hero selection or even try to
view him in the loadout screen, my system completely freezes with no option but
to do a hard reset. I cannot alt-tab, minimize to desktop, switch to any TTY
and REISUB does not work. This ONLY happens with the hero morphling and seems
to be an issue with graphics because it seems to happen when I am about to see
his model loaded. I even deleted the one item I had for him. 

I verified the game files; no good. I deleted all local content and downloaded
the game again...no good. This is either an issue with my graphics drivers and
morphling or a Dota 2 and Linux issue. My wife is using Windows 8.1 and does
not have this problem.


I am running an AMD R9 270X with linux 3.19.2 and mesa 10.5.1 where everything
else works wonderfully!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: