[Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control

2015-06-29 Thread Brain WrecK
Tested by Brian Loften, "Brain Wreck" bloften80 at gmail.com confirmed working
on ASUS T100TA, kernel 20150629 -next running 15.04 i386 Ubuntu Gnome --
suspend resume is functioning normally, backlight controls work before and
after resume using slide controls and meta keys on keyboard

On Sun, Jun 28, 2015 at 4:18 PM, Paul Gortmaker <
paul.gortmaker at windriver.com> wrote:

> [Re: [Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm
> control] On 26/06/2015 (Fri 20:47) Ville Syrjälä wrote:
>
> > On Fri, Jun 26, 2015 at 06:31:37PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 26, 2015 at 02:32:03PM +0530, Shobhit Kumar wrote:
> > > > Hi,
> > > > Next update of the series reviewed at
> > > > https://lkml.org/lkml/2015/6/22/155
> > > >
> > > > Major changes are few review comments from Varka and Ville being
> addressed. Also except
> > > > for intel-gfx patches, all patches reviesion history is moved out of
> commit message.
> > > >
> > > > Hope this series finally finds its mark.
> > > >
> > > > Regards
> > > > Shobhit
> > > >
> > > > Shobhit Kumar (7):
> > > >   gpiolib: Add support for removing registered consumer lookup table
> > > >   mfd: intel_soc_pmic_core: Add lookup table for Panel Control as
> GPIO
> > > > signal
> > > >   mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC
> > > >   mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based
> PWM
> > > >   pwm: crc: Add Crystalcove (CRC) PWM driver
> > > >   drm/i915: Use the CRC gpio for panel enable/disable
> > > >   drm/i915: Backlight control using CRC PMIC based PWM driver
> > >
> > > I think we have r-b/acks on all the patches now. Ok if I pull this in
> > > through drm-intel.git for 4.3? Or should I make a topic branch with tag
> > > and then send out pull requests to everyone? Or will each maintainer
> merge
> > > on their own since it's all only coupled at runtime anyway? Any of
> these
> > > would suit me.
> >
> > I forgot to mention that I had a build failure due to
> > builtin_platform_driver() when I tried this (just changed it to
> > module_platform_driver() to get past it). So I'm not sure if this
> > now depends on some tree which isn't included in -nightly...
>
> builtin_platform_register does not yet exist in mainline; as Paul (the
> other one) said earlier.  So you can either open-code what it does for
> now, or use  module_platform_register.  If you do the latter, then
> ensure you (temorarily) also include module.h or you risk additional
> breakage in the future.
>
> Paul.
> --
>
> >
> > --
> > Ville Syrjälä
> > Intel OTC
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150629/250899ed/attachment.html>


drm: imx: multi-display support questions

2015-06-29 Thread Gary Bisson
Fabio, Eric,

On Mon, Jun 29, 2015 at 6:22 PM, Eric Nelson
 wrote:
> Thanks Fabio,
>
> On 06/29/2015 09:08 AM, Fabio Estevam wrote:
>> Hi Gary,
>>
>> On Mon, Jun 29, 2015 at 1:04 PM, Gary Bisson
>>  wrote:
>>
>>> Thank you for your e-mail and sorry for the delay in my response. I
>>> confirm this patch, ported over to my dtsi file, makes the HDMI and
>>> LVDS work together.
>>>
>>> I'll check with Eric but we will most likely use the same
>>> configuration for our platforms.
>>
>> What do you mean by "use the same configuration for our platforms"?
>>
>> I was planning to send the two attached patches.
>>
>> Are you and Eric OK with them?
>>
>
> These look good to me.
>
> Gary, did you test one of these against either of our 1280x800 panels?

Yes I've tested with both Hannstar 10" 1024x768 and 7" 1280x800. I
will answer to the patches sent for Sabrelite and Nitrogen6x.

Regards,
Gary


[ANNOUNCE] libdrm 2.4.62

2015-06-29 Thread Emil Velikov
This release introduces the atomic and blob APIs, adds support
for new devices (AMD Bonaire) and a new flag for coherent BOs
in nouveau.


Alex Deucher (1):
  radeon: add new bonaire pci id

Alexandre Courbot (1):
  nouveau: add coherent BO attribute

Boris BREZILLON (2):
  modetest: add atmel-hlcdc driver support
  tests/kmstest: support atmel-hlcdc

Damien Lespiau (1):
  intel: Add the Broxton PCI IDs

Daniel Stone (1):
  Add blob property create/destroy ioctl wrappers

Emil Velikov (7):
  modetest: explicitly zero the newly allocated memory
  modetest: replace malloc + memset with calloc
  xf86drm: simplify drmMalloc/drmFree
  Revert "Add device enumeration interface (v4)"
  xf86drmMode: remove unused valgrind(VG) macros
  xf86drmMode: include config.h before anything else
  configure.ac: bump version to 2.4.62 for release

Guillaume Desmottes (1):
  drmPrime*: initialize output args to 0

Ilia Mirkin (1):
  nouveau: add asserts to make sure krefs are there

Jammy Zhou (1):
  Fix one warning (v2)

Matt Turner (1):
  configure: Add flag to disable valgrind support.

Tobias Jakobi (11):
  modetest: make middle SMPTE colors transparent
  modetest: only select plane with matching format
  exynos: fimg2d: fix return codes
  tests/exynos: replace return by break
  exynos/fimg2d: simplify g2d_fini()
  tests/exynos: clean struct connector
  tests/exynos: remove unused define
  tests/exynos: remove struct fimg2d_test_case
  tests/exynos: simplify drm_set_crtc
  tests/exynos: remove connector_find_plane
  tests/exynos: handle G2D_IMGBUF_COLOR in switch statements

Ville Syrjälä (1):
  Support atomic modesetting ioctl

frank (1):
  Add device enumeration interface (v4)

git tag: libdrm-2.4.62

http://dri.freedesktop.org/libdrm/libdrm-2.4.62.tar.bz2
MD5:  c9291bae0e5ca65d1483821d3698d3ab  libdrm-2.4.62.tar.bz2
SHA1: 882b59a372508a301aabd6ba8f8bd124f3a69a16  libdrm-2.4.62.tar.bz2
SHA256: 906c294bdbe1c94c3ca084305d61a6e5a8367f3b4986e6cc13b1e9b3f75931dc  
libdrm-2.4.62.tar.bz2
PGP:  http://dri.freedesktop.org/libdrm/libdrm-2.4.62.tar.bz2.sig

http://dri.freedesktop.org/libdrm/libdrm-2.4.62.tar.gz
MD5:  e94fd03ad36b4154b8e10e8f6854f863  libdrm-2.4.62.tar.gz
SHA1: 270d8f3f03d605a08af7749e3762d508a3cef7b5  libdrm-2.4.62.tar.gz
SHA256: f7df6b73c8d787cdde7e49eae6e761313f606b784051004b1cb2e81bf2d490fa  
libdrm-2.4.62.tar.gz
PGP:  http://dri.freedesktop.org/libdrm/libdrm-2.4.62.tar.gz.sig


-- 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/20150629/53868c1d/attachment.sig>


drm: imx: multi-display support questions

2015-06-29 Thread Gary Bisson
Hi Fabio,

On Mon, Jun 29, 2015 at 6:08 PM, Fabio Estevam  wrote:
> Hi Gary,
>
> On Mon, Jun 29, 2015 at 1:04 PM, Gary Bisson
>  wrote:
>
>> Thank you for your e-mail and sorry for the delay in my response. I
>> confirm this patch, ported over to my dtsi file, makes the HDMI and
>> LVDS work together.
>>
>> I'll check with Eric but we will most likely use the same
>> configuration for our platforms.
>
> What do you mean by "use the same configuration for our platforms"?

I meant the clock tree configuration, having LDB under the PLL3.

> I was planning to send the two attached patches.

I am ok with it but I'd like Eric to ack it too as he might have some remarks.

Regards,
Gary


drm: imx: multi-display support questions

2015-06-29 Thread Gary Bisson
Hi Fabio,

On Tue, Jun 23, 2015 at 7:50 PM, Fabio Estevam  wrote:
> On Tue, Jun 23, 2015 at 2:49 PM, Fabio Estevam  wrote:
>> Hi Gary,
>>
>> On Wed, May 27, 2015 at 10:31 AM, Gary Bisson
>>  wrote:
>>
>>> Ok, thanks, I'll check and see what I need to get all the displays to
>>> work together.
>>
>> With this patch:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/352189.html
>>
>> I am able to get HDMI and LVDS working on a mx6q-sabresd.
>
> Sorry, the correct URL is:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/352179.html

Thank you for your e-mail and sorry for the delay in my response. I
confirm this patch, ported over to my dtsi file, makes the HDMI and
LVDS work together.

I'll check with Eric but we will most likely use the same
configuration for our platforms.

Regards,
Gary


[git pull] drm tree for 4.2

2015-06-29 Thread Jani Nikula
On Mon, 29 Jun 2015, Ander Conselvan De Oliveira  
wrote:
> On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote:
>> On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie  wrote:
>> >
>> > This is the main drm pull request for v4.2.
>> 
>> It seems to work ok for me, but it causes quite a few new warnings on
>> my Sony VAIO Pro laptop. It's (once more) a regular i5-4200U CPU (aka
>> Haswell, aka 4th gen Intel Core i5)
>> 
>> Most of them are in check_crtc_state(), and I currently have 18 of
>> these in my log:
>> 
>>   [drm:check_crtc_state [i915]] *ERROR* mismatch in
>> dpll_hw_state.wrpll (expected 0x90280202, found 0x)
>>   WARNING: CPU: 0 PID: 115 at
>> drivers/gpu/drm/i915/intel_display.c:12319
>> check_crtc_state+0x8be/0xf60 [i915]()
>>   pipe state doesn't match!
>> 
>> but there's a few others too:
>> 
>>   WARNING: CPU: 3 PID: 1871 at
>> drivers/gpu/drm/i915/intel_display.c:1362 hsw_disable_ips+0x34/0x160
>> [i915]()
>>   plane A assertion failure (expected on, current off)
>> 
>>   WARNING: CPU: 3 PID: 1871 at drivers/gpu/drm/drm_irq.c:1162
>> drm_wait_one_vblank+0x148/0x1a0 [drm]()
>>   vblank not available on crtc 0, ret=-22
>> 
>> and the backtraces aren't all that interesting, but I'm attaching the
>> cleaned-up dmesg, duplicate callchains and all.
>
> Please provide a full dmesg with drm.debug=0x1f in the kernel command
> line.

Ander, I think I was able to reproduce this on the BDW NUC here. Bisect
points at...

commit dd3cd74acf12723045a64f1f2c6298ac7b34a5d5
Author: Ander Conselvan de Oliveira 
Date:   Fri May 15 13:34:29 2015 +0300

drm/i915: Don't overwrite (e)DP PLL selection on SKL

In the following commit, the place where the contents of dpll_hw_state
in crtc_state where zeroed was changed. Prior to that commit, it
happened when the new state was allocated, but now that happens just
before the call the .crtc_compute_clock() hook. The DP code for SKL,
however, sets up the (private) PLL in the encoder compute config
function that has already run by the time that memset() is reached,
causing the previous value to be lost.

This patch fixes the issue by moving the memset() down the call chain,
so that it is only called if the values in dpll_hw_state are going to be
updated.

commit 4978cc93d9ac240b435ce60431aef24239b4c270
Author: Ander Conselvan de Oliveira 
Date:   Tue Apr 21 17:13:21 2015 +0300

drm/i915: Preserve shared DPLL information in new pipe_config

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90462
Signed-off-by: Ander Conselvan de Oliveira 
Reviewed-by: Damien Lespiau 
Reported-and-tested-by: Tvrtko Ursulin 
Signed-off-by: Daniel Vetter 

This doesn't revert cleanly on Linus' master, and I didn't have the time
to look deeper right now. However I confirmed that this commit fails and
its parent doesn't.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center


[Intel-gfx] [git pull] drm tree for 4.2

2015-06-29 Thread Daniel Vetter
On Mon, Jun 29, 2015 at 05:50:09PM +0300, Jani Nikula wrote:
> On Mon, 29 Jun 2015, Ander Conselvan De Oliveira  
> wrote:
> > On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote:
> >> On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie  wrote:
> >> >
> >> > This is the main drm pull request for v4.2.
> >> 
> >> It seems to work ok for me, but it causes quite a few new warnings on
> >> my Sony VAIO Pro laptop. It's (once more) a regular i5-4200U CPU (aka
> >> Haswell, aka 4th gen Intel Core i5)
> >> 
> >> Most of them are in check_crtc_state(), and I currently have 18 of
> >> these in my log:
> >> 
> >>   [drm:check_crtc_state [i915]] *ERROR* mismatch in
> >> dpll_hw_state.wrpll (expected 0x90280202, found 0x)
> >>   WARNING: CPU: 0 PID: 115 at
> >> drivers/gpu/drm/i915/intel_display.c:12319
> >> check_crtc_state+0x8be/0xf60 [i915]()
> >>   pipe state doesn't match!
> >> 
> >> but there's a few others too:
> >> 
> >>   WARNING: CPU: 3 PID: 1871 at
> >> drivers/gpu/drm/i915/intel_display.c:1362 hsw_disable_ips+0x34/0x160
> >> [i915]()
> >>   plane A assertion failure (expected on, current off)
> >> 
> >>   WARNING: CPU: 3 PID: 1871 at drivers/gpu/drm/drm_irq.c:1162
> >> drm_wait_one_vblank+0x148/0x1a0 [drm]()
> >>   vblank not available on crtc 0, ret=-22
> >> 
> >> and the backtraces aren't all that interesting, but I'm attaching the
> >> cleaned-up dmesg, duplicate callchains and all.
> >
> > Please provide a full dmesg with drm.debug=0x1f in the kernel command
> > line.
> 
> Ander, I think I was able to reproduce this on the BDW NUC here. Bisect
> points at...
> 
> commit dd3cd74acf12723045a64f1f2c6298ac7b34a5d5
> Author: Ander Conselvan de Oliveira 
> Date:   Fri May 15 13:34:29 2015 +0300
> 
> drm/i915: Don't overwrite (e)DP PLL selection on SKL
> 
> In the following commit, the place where the contents of dpll_hw_state
> in crtc_state where zeroed was changed. Prior to that commit, it
> happened when the new state was allocated, but now that happens just
> before the call the .crtc_compute_clock() hook. The DP code for SKL,
> however, sets up the (private) PLL in the encoder compute config
> function that has already run by the time that memset() is reached,
> causing the previous value to be lost.
> 
> This patch fixes the issue by moving the memset() down the call chain,
> so that it is only called if the values in dpll_hw_state are going to be
> updated.
> 
> commit 4978cc93d9ac240b435ce60431aef24239b4c270
> Author: Ander Conselvan de Oliveira  intel.com>
> Date:   Tue Apr 21 17:13:21 2015 +0300
> 
> drm/i915: Preserve shared DPLL information in new pipe_config
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90462
> Signed-off-by: Ander Conselvan de Oliveira  at intel.com>
> Reviewed-by: Damien Lespiau 
> Reported-and-tested-by: Tvrtko Ursulin 
> Signed-off-by: Daniel Vetter 
> 
> This doesn't revert cleanly on Linus' master, and I didn't have the time
> to look deeper right now. However I confirmed that this commit fails and
> its parent doesn't.

Note that there seems to be two bugs here: Firs one is display state
checker getting annoyed, which is probably the one Jani bisected to here
(please confirm).

The other is the two backtraces complaining that the pipe is off (both the
drm_irq.c and the one in hsw_display_ips amount to that) because we seem
to call disable_planes on a disable pipe, which is bullocks (with runtime
pm the hw is dead and will just drop the writes).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[git pull] drm tree for 4.2

2015-06-29 Thread Ander Conselvan De Oliveira
On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote:
> On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie  wrote:
> >
> > This is the main drm pull request for v4.2.
> 
> It seems to work ok for me, but it causes quite a few new warnings on
> my Sony VAIO Pro laptop. It's (once more) a regular i5-4200U CPU (aka
> Haswell, aka 4th gen Intel Core i5)
> 
> Most of them are in check_crtc_state(), and I currently have 18 of
> these in my log:
> 
>   [drm:check_crtc_state [i915]] *ERROR* mismatch in
> dpll_hw_state.wrpll (expected 0x90280202, found 0x)
>   WARNING: CPU: 0 PID: 115 at
> drivers/gpu/drm/i915/intel_display.c:12319
> check_crtc_state+0x8be/0xf60 [i915]()
>   pipe state doesn't match!
> 
> but there's a few others too:
> 
>   WARNING: CPU: 3 PID: 1871 at
> drivers/gpu/drm/i915/intel_display.c:1362 hsw_disable_ips+0x34/0x160
> [i915]()
>   plane A assertion failure (expected on, current off)
> 
>   WARNING: CPU: 3 PID: 1871 at drivers/gpu/drm/drm_irq.c:1162
> drm_wait_one_vblank+0x148/0x1a0 [drm]()
>   vblank not available on crtc 0, ret=-22
> 
> and the backtraces aren't all that interesting, but I'm attaching the
> cleaned-up dmesg, duplicate callchains and all.

Please provide a full dmesg with drm.debug=0x1f in the kernel command
line.

Thanks,
Ander



[PATCH] drm/exynos: iommu: fix potential NULL pointer dereference

2015-06-29 Thread Hyungwon Hwang
Dear Marek,

On Thu, 25 Jun 2015 15:10:12 +0200
Marek Szyprowski  wrote:

> Some drivers (like Exynos mixer) calls
> drm_iommu_attach_device_if_possible before registering crtc, so
> additional check for NULL crtc pointer is required.

It seems reasonable.

Reviewed-by: Hyungwon Hwang 

> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> b/drivers/gpu/drm/exynos/exynos_drm_iommu.c index
> d4ec7465e9cc..d4eb730ba254 100644 ---
> a/drivers/gpu/drm/exynos/exynos_drm_iommu.c +++
> b/drivers/gpu/drm/exynos/exynos_drm_iommu.c @@ -151,7 +151,7 @@ int
> drm_iommu_attach_device_if_possible(struct exynos_drm_crtc
> *exynos_crtc, int ret = 0; 
>   if (is_drm_iommu_supported(drm_dev)) {
> - if (exynos_crtc->ops->clear_channels)
> + if (exynos_crtc && exynos_crtc->ops->clear_channels)
>   exynos_crtc->ops->clear_channels(exynos_crtc);
>   return drm_iommu_attach_device(drm_dev, subdrv_dev);
>   }



[PATCH v2 2/2] drm/nouveau: add GEM_SET_TILING staging ioctl

2015-06-29 Thread Thierry Reding
On Mon, Jun 15, 2015 at 04:15:36PM +0900, Alexandre Courbot wrote:
> On 06/15/2015 04:09 PM, Alexandre Courbot wrote:
> >From: Ari Hirvonen 
> >
> >Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling
> >mode for imported dma-bufs. This ioctl is staging for now
> >and enabled with the "staging_tiling" module option.
> 
> Adding Thierry to the conversation since he knows best about exported
> buffers and attributes. I wonder if this would not better be done at the
> time the buffer gets imported. It seems to me that this would be a more
> appropriate way than having an ioctl dedicated to this. Thierry, would you
> have any input based on your experience with tegradrm? In the end, it seems
> like you have settled for a similar ioctl to set the tiling mode of
> displayed buffers.

You can't do this at the time the buffer is imported because the PRIME
API doesn't have a means to communicate this type of meta-data. The data
is also very driver-specific, so you can't easily make it generic enough
to be useful in a generic import API.

That said, I have a couple of other comments. First, the commit message
doesn't mention why this needs to be protected by a module option. Also
I think that if we go for a module option it should be more generic and
provide an umbrella if ever we want to have more code guarded by the
option. It might also be useful to introduce a Kconfig symbol that in
turn depends on the STAGING symbol so that users can't accidentally
enable this.

> >diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
> >index 28860268cf38..45a2c88ebf8e 100644
> >--- a/drm/nouveau/nouveau_drm.c
> >+++ b/drm/nouveau/nouveau_drm.c
> >@@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, "disable (0), force enable (1), 
> >optimus only default (-1
> >  int nouveau_runtime_pm = -1;
> >  module_param_named(runpm, nouveau_runtime_pm, int, 0400);
> >
> >+MODULE_PARM_DESC(staging_tiling, "enable staging GEM_SET_TILING ioctl");
> >+int nouveau_staging_tiling = 0;
> >+module_param_named(staging_tiling, nouveau_staging_tiling, int, 0600);

Perhaps make this a boolean parameter? And like I said, maybe make it
more general and provide a single option for potentially other staging
features.

A word of caution: let's only resort to this if absolutely necessary.
Doing this is going to get messy and if we want this merged I suspect
that we do have userspace that uses this. Hence if ever this gets
modified that userspace will break. Can't we find a way around it?

Note that the DRM_TEGRA_STAGING option is a bit of a special case as
there aren't any real users of it beyond proof of concept code. Nouveau,
on the other hand, has real users that will want to take advantage of
this code. So if we really need to do this, let's come up with a *very*
good rationale.

> >diff --git a/drm/nouveau/nouveau_gem.c b/drm/nouveau/nouveau_gem.c
> >index 0e690bf19fc9..0e69449798aa 100644
> >--- a/drm/nouveau/nouveau_gem.c
> >+++ b/drm/nouveau/nouveau_gem.c
> >@@ -172,6 +172,64 @@ nouveau_gem_object_close(struct drm_gem_object *gem, 
> >struct drm_file *file_priv)
> > ttm_bo_unreserve(>bo);
> >  }
> >
> >+extern int nouveau_staging_tiling;

Put this in nouveau_drm.h along with other external declarations?

> >+int
> >+nouveau_gem_ioctl_set_tiling(struct drm_device *dev, void *data,
> >+ struct drm_file *file_priv)
> >+{
> >+struct nouveau_drm *drm = nouveau_drm(dev);
> >+struct nouveau_cli *cli = nouveau_cli(file_priv);
> >+struct nvkm_fb *pfb = nvxx_fb(>device);
> >+struct drm_nouveau_gem_set_tiling *req = data;
> >+struct drm_gem_object *gem;
> >+struct nouveau_bo *nvbo;
> >+struct nvkm_vma *vma;
> >+int ret = 0;
> >+
> >+if (!nouveau_staging_tiling)
> >+return -EINVAL;
> >+
> >+if (!pfb->memtype_valid(pfb, req->tile_flags)) {
> >+NV_PRINTK(error, cli, "bad page flags: 0x%08x\n", 
> >req->tile_flags);
> >+return -EINVAL;
> >+}
> >+
> >+gem = drm_gem_object_lookup(dev, file_priv, req->handle);
> >+if (!gem)
> >+return -ENOENT;
> >+
> >+nvbo = nouveau_gem_object(gem);
> >+
> >+/* We can only change tiling on PRIME-imported buffers */
> >+if (nvbo->bo.type != ttm_bo_type_sg) {
> >+ret = -EINVAL;
> >+goto out;
> >+}

I don't think that's the right way to check for PRIME-imported buffers.
The right check is:

if (!gem->import_attach) {
ret = -EINVAL;
goto out;
}

The comment above this block should probably also say *why* we can only
change tiling on PRIME-imported buffers.

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


[PATCH v3] drm/tegra: Use 64-bit offset for tegra_gem_mmap

2015-06-29 Thread Dave Airlie
On 6 February 2015 at 22:18, Thierry Reding  wrote:
> On Fri, Jan 30, 2015 at 01:57:01PM -0500, Sean Paul wrote:
>> On 64-bit targets, tegra_gem_mmap doesn't return the
>> offset to userspace. As such, subsequent calls to mmap(2)
>> fail. Alter the args to use 64-bit offset to fix this.
>>
>> Signed-off-by: Sean Paul 
>> ---
>>  include/uapi/drm/tegra_drm.h | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> I've applied this with a slightly tweaked commit message.

Doesn't that break 32-bit ABI?

Dave.


[PATCH 4/4] drm/i915: fbdev dirty calls fb user dirty to invalidate frontbuffer.

2015-06-29 Thread Rodrigo Vivi
Now that we have fb user dirty invalidating frontbuffer and we have
the new fbdev dirty callback let's merge them.

So it doesn't matter if fbcon throught fbdev or splash screen throught
drm_ioctl_dirtyfb, in any case we will have frontbuffer properly
invalidated and power savings features that rely on frontbuffer tracking
will be able to work as expected.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_fbdev.c | 86 ++
 1 file changed, 13 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 2a1724e..f1592c7 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -45,92 +45,32 @@
 #include 
 #include "i915_drv.h"

-static int intel_fbdev_set_par(struct fb_info *info)
+static void intel_fbdev_dirty(struct fb_info *info, u32 x1, u32 y1,
+ u32 x2, u32 y2)
 {
struct drm_fb_helper *fb_helper = info->par;
struct intel_fbdev *ifbdev =
container_of(fb_helper, struct intel_fbdev, helper);
-   int ret;
-
-   ret = drm_fb_helper_set_par(info);
-
-   if (ret == 0) {
-   /*
-* FIXME: fbdev presumes that all callbacks also work from
-* atomic contexts and relies on that for emergency oops
-* printing. KMS totally doesn't do that and the locking here is
-* by far not the only place this goes wrong.  Ignore this for
-* now until we solve this for real.
-*/
-   mutex_lock(_helper->dev->struct_mutex);
-   ret = i915_gem_object_set_to_gtt_domain(ifbdev->fb->obj,
-   true);
-   mutex_unlock(_helper->dev->struct_mutex);
-   }
-
-   return ret;
-}
-
-static int intel_fbdev_blank(int blank, struct fb_info *info)
-{
-   struct drm_fb_helper *fb_helper = info->par;
-   struct intel_fbdev *ifbdev =
-   container_of(fb_helper, struct intel_fbdev, helper);
-   int ret;
-
-   ret = drm_fb_helper_blank(blank, info);
-
-   if (ret == 0) {
-   /*
-* FIXME: fbdev presumes that all callbacks also work from
-* atomic contexts and relies on that for emergency oops
-* printing. KMS totally doesn't do that and the locking here is
-* by far not the only place this goes wrong.  Ignore this for
-* now until we solve this for real.
-*/
-   mutex_lock(_helper->dev->struct_mutex);
-   intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
-   mutex_unlock(_helper->dev->struct_mutex);
-   }
-
-   return ret;
-}
-
-static int intel_fbdev_pan_display(struct fb_var_screeninfo *var,
-  struct fb_info *info)
-{
-   struct drm_fb_helper *fb_helper = info->par;
-   struct intel_fbdev *ifbdev =
-   container_of(fb_helper, struct intel_fbdev, helper);
-
-   int ret;
-   ret = drm_fb_helper_pan_display(var, info);
-
-   if (ret == 0) {
-   /*
-* FIXME: fbdev presumes that all callbacks also work from
-* atomic contexts and relies on that for emergency oops
-* printing. KMS totally doesn't do that and the locking here is
-* by far not the only place this goes wrong.  Ignore this for
-* now until we solve this for real.
-*/
-   mutex_lock(_helper->dev->struct_mutex);
-   intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
-   mutex_unlock(_helper->dev->struct_mutex);
-   }
+   struct intel_framebuffer *intel_fb = ifbdev->fb;
+   struct drm_framebuffer *fb = _fb->base;

-   return ret;
+   /*
+* Our fb dirty callback is just used to invalidate frontbuffer
+* entirely. So just fb reference is needed and rest is ignored.
+*/
+   fb->funcs->dirty(fb, NULL, 0, 0, NULL, 1);
 }

 static struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = intel_fbdev_set_par,
+   .fb_set_par = drm_fb_helper_set_par,
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
-   .fb_pan_display = intel_fbdev_pan_display,
-   .fb_blank = intel_fbdev_blank,
+   .fb_dirty = intel_fbdev_dirty,
+   .fb_pan_display = drm_fb_helper_pan_display,
+   .fb_blank = drm_fb_helper_blank,
.fb_setcmap = drm_fb_helper_setcmap,
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
-- 
2.1.0



[PATCH 3/4] drm/udl: Use fb_dirty ops to simplify damage calls

2015-06-29 Thread Rodrigo Vivi
With fb_dirty op in place we can simplify stuff here.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/udl/udl_fb.c | 34 ++
 1 file changed, 6 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 5fc16ce..68494bb 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -284,34 +284,11 @@ static int udl_fb_mmap(struct fb_info *info, struct 
vm_area_struct *vma)
return 0;
 }

-static void udl_fb_fillrect(struct fb_info *info, const struct fb_fillrect 
*rect)
+static void udl_fb_dirty(struct fb_info *info, u32 x1, u32 y1, u32 x2, u32 y2)
 {
struct udl_fbdev *ufbdev = info->par;

-   sys_fillrect(info, rect);
-
-   udl_handle_damage(>ufb, rect->dx, rect->dy, rect->width,
- rect->height);
-}
-
-static void udl_fb_copyarea(struct fb_info *info, const struct fb_copyarea 
*region)
-{
-   struct udl_fbdev *ufbdev = info->par;
-
-   sys_copyarea(info, region);
-
-   udl_handle_damage(>ufb, region->dx, region->dy, region->width,
- region->height);
-}
-
-static void udl_fb_imageblit(struct fb_info *info, const struct fb_image 
*image)
-{
-   struct udl_fbdev *ufbdev = info->par;
-
-   sys_imageblit(info, image);
-
-   udl_handle_damage(>ufb, image->dx, image->dy, image->width,
- image->height);
+   udl_handle_damage(>ufb, x1, y1, x2, y2);
 }

 /*
@@ -380,9 +357,10 @@ static struct fb_ops udlfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
-   .fb_fillrect = udl_fb_fillrect,
-   .fb_copyarea = udl_fb_copyarea,
-   .fb_imageblit = udl_fb_imageblit,
+   .fb_fillrect = sys_fillrect,
+   .fb_copyarea = sys_copyarea,
+   .fb_imageblit = sys_imageblit,
+   .fb_dirty = udl_fb_dirty,
.fb_pan_display = drm_fb_helper_pan_display,
.fb_blank = drm_fb_helper_blank,
.fb_setcmap = drm_fb_helper_setcmap,
-- 
2.1.0



[PATCH 2/4] fbdev: Introduce fb_dirty operation.

2015-06-29 Thread Rodrigo Vivi
There are cases we need to mark dirty/damaged areas, specially with
operations that touches frontbuffer directly. To cover these cases
this patch introduces the optional fb_dirty operation.

Signed-off-by: Rodrigo Vivi 
---
 drivers/video/fbdev/core/cfbcopyarea.c | 3 +++
 drivers/video/fbdev/core/cfbfillrect.c | 3 +++
 drivers/video/fbdev/core/cfbimgblt.c   | 4 
 drivers/video/fbdev/core/syscopyarea.c | 3 +++
 drivers/video/fbdev/core/sysfillrect.c | 3 +++
 drivers/video/fbdev/core/sysimgblt.c   | 4 
 include/linux/fb.h | 3 +++
 7 files changed, 23 insertions(+)

diff --git a/drivers/video/fbdev/core/cfbcopyarea.c 
b/drivers/video/fbdev/core/cfbcopyarea.c
index 6d4bfee..2e5b69f 100644
--- a/drivers/video/fbdev/core/cfbcopyarea.c
+++ b/drivers/video/fbdev/core/cfbcopyarea.c
@@ -427,6 +427,9 @@ void cfb_copyarea(struct fb_info *p, const struct 
fb_copyarea *area)
src_idx += bits_per_line;
}
}
+
+   if (p->fbops->fb_dirty)
+   p->fbops->fb_dirty(p, dx, dy, width, height);
 }

 EXPORT_SYMBOL(cfb_copyarea);
diff --git a/drivers/video/fbdev/core/cfbfillrect.c 
b/drivers/video/fbdev/core/cfbfillrect.c
index ba9f58b..c8732d5 100644
--- a/drivers/video/fbdev/core/cfbfillrect.c
+++ b/drivers/video/fbdev/core/cfbfillrect.c
@@ -362,6 +362,9 @@ void cfb_fillrect(struct fb_info *p, const struct 
fb_fillrect *rect)
dst_idx += p->fix.line_length*8;
}
}
+
+   if (p->fbops->fb_dirty)
+   p->fbops->fb_dirty(p, rect->dx, rect->dy, width, height);
 }

 EXPORT_SYMBOL(cfb_fillrect);
diff --git a/drivers/video/fbdev/core/cfbimgblt.c 
b/drivers/video/fbdev/core/cfbimgblt.c
index a2bb276..09c2dbe 100644
--- a/drivers/video/fbdev/core/cfbimgblt.c
+++ b/drivers/video/fbdev/core/cfbimgblt.c
@@ -267,6 +267,7 @@ void cfb_imageblit(struct fb_info *p, const struct fb_image 
*image)
u32 fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
u32 bpl = sizeof(u32), bpp = p->var.bits_per_pixel;
u32 width = image->width;
+   u32 height = image->height;
u32 dx = image->dx, dy = image->dy;
u8 __iomem *dst1;

@@ -303,6 +304,9 @@ void cfb_imageblit(struct fb_info *p, const struct fb_image 
*image)
start_index, pitch_index);
} else
color_imageblit(image, p, dst1, start_index, pitch_index);
+
+   if (p->fbops->fb_dirty)
+   p->fbops->fb_dirty(p, dx, dy, width, height);
 }

 EXPORT_SYMBOL(cfb_imageblit);
diff --git a/drivers/video/fbdev/core/syscopyarea.c 
b/drivers/video/fbdev/core/syscopyarea.c
index c1eda31..3f74683 100644
--- a/drivers/video/fbdev/core/syscopyarea.c
+++ b/drivers/video/fbdev/core/syscopyarea.c
@@ -360,6 +360,9 @@ void sys_copyarea(struct fb_info *p, const struct 
fb_copyarea *area)
src_idx += bits_per_line;
}
}
+
+   if (p->fbops->fb_dirty)
+   p->fbops->fb_dirty(p, dx, dy, width, height);
 }

 EXPORT_SYMBOL(sys_copyarea);
diff --git a/drivers/video/fbdev/core/sysfillrect.c 
b/drivers/video/fbdev/core/sysfillrect.c
index 33ee3d3..f2c3efa 100644
--- a/drivers/video/fbdev/core/sysfillrect.c
+++ b/drivers/video/fbdev/core/sysfillrect.c
@@ -326,6 +326,9 @@ void sys_fillrect(struct fb_info *p, const struct 
fb_fillrect *rect)
dst_idx += p->fix.line_length*8;
}
}
+
+   if (p->fbops->fb_dirty)
+   p->fbops->fb_dirty(p, rect->dx, rect->dy, width, height);
 }

 EXPORT_SYMBOL(sys_fillrect);
diff --git a/drivers/video/fbdev/core/sysimgblt.c 
b/drivers/video/fbdev/core/sysimgblt.c
index a4d05b1..d690fb5 100644
--- a/drivers/video/fbdev/core/sysimgblt.c
+++ b/drivers/video/fbdev/core/sysimgblt.c
@@ -243,6 +243,7 @@ void sys_imageblit(struct fb_info *p, const struct fb_image 
*image)
u32 bpl = sizeof(u32), bpp = p->var.bits_per_pixel;
u32 width = image->width;
u32 dx = image->dx, dy = image->dy;
+   u32 height = image->height;
void *dst1;

if (p->state != FBINFO_STATE_RUNNING)
@@ -278,6 +279,9 @@ void sys_imageblit(struct fb_info *p, const struct fb_image 
*image)
start_index, pitch_index);
} else
color_imageblit(image, p, dst1, start_index, pitch_index);
+
+   if (p->fbops->fb_dirty)
+   p->fbops->fb_dirty(p, dx, dy, width, height);
 }

 EXPORT_SYMBOL(sys_imageblit);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 043f328..e17e4b7 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -284,6 +284,9 @@ struct fb_ops {
/* wait for blit idle, optional */
int (*fb_sync)(struct fb_info *info);

+   /* Mark rect as dirty (optional) */
+   void (*fb_dirty)(struct fb_info *info, u32 x1, u32 y1, u32 x2, u32 y2);
+
/* perform fb specific ioctl (optional) */
int 

[PATCH 1/4] drm/i915: Make fb user dirty operation to invalidate frontbuffer

2015-06-29 Thread Rodrigo Vivi
This patch introduces a frontbuffer invalidation on dirty fb
user callback.

It is mainly used for DIRTYFB drm ioctl, but can be extended
for fbdev use on following patch.

This patch itself already solves the biggest PSR known issue, that is
missed screen updates during boot, mainly when there is a splash
screen involved like plymouth.

Plymoth will do a modeset over ioctl that flushes frontbuffer
tracking and PSR gets back to work while it cannot track the
screen updates and exit properly. However plymouth also uses
a dirtyfb ioctl whenever updating the screen. So let's use it
to invalidate PSR back again.

This patch also introduces the ORIGIN_FB_DIRTY to frontbuffer tracking.
The reason is that whenever using this invalidate path we don't need to
keep continuously invalidating the frontbuffer for every call. One call
between flips is enough to keep frontbuffer tracking invalidated and
let all users aware. If a sync or async flip completed it means that we
probably can flush everything and enable powersavings features back.
If this isn't the case on the next dirty call we invalidate it again
until next flip.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_display.c | 18 ++
 drivers/gpu/drm/i915/intel_frontbuffer.c | 18 ++
 3 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ea9caf2..e0591d3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -889,6 +889,7 @@ enum fb_op_origin {
ORIGIN_CPU,
ORIGIN_CS,
ORIGIN_FLIP,
+   ORIGIN_FB_DIRTY,
 };

 struct i915_fbc {
@@ -1628,6 +1629,7 @@ struct i915_frontbuffer_tracking {
 */
unsigned busy_bits;
unsigned flip_bits;
+   bool fb_dirty;
 };

 struct i915_wa_reg {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 01eaab8..19c2ab3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14330,9 +14330,27 @@ static int intel_user_framebuffer_create_handle(struct 
drm_framebuffer *fb,
return drm_gem_handle_create(file, >base, handle);
 }

+static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb,
+  struct drm_file *file,
+  unsigned flags, unsigned color,
+  struct drm_clip_rect *clips,
+  unsigned num_clips)
+{
+   struct drm_device *dev = fb->dev;
+   struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+   struct drm_i915_gem_object *obj = intel_fb->obj;
+
+   mutex_lock(>struct_mutex);
+   intel_fb_obj_invalidate(obj, ORIGIN_FB_DIRTY);
+   mutex_unlock(>struct_mutex);
+
+   return 0;
+}
+
 static const struct drm_framebuffer_funcs intel_fb_funcs = {
.destroy = intel_user_framebuffer_destroy,
.create_handle = intel_user_framebuffer_create_handle,
+   .dirty = intel_user_framebuffer_dirty,
 };

 static
diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/intel_frontbuffer.c
index 6e90e2b..329b6fc 100644
--- a/drivers/gpu/drm/i915/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
@@ -81,12 +81,28 @@ void intel_fb_obj_invalidate(struct drm_i915_gem_object 
*obj,
 {
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
+   bool fb_dirty;

WARN_ON(!mutex_is_locked(>struct_mutex));

if (!obj->frontbuffer_bits)
return;

+   /*
+* We just invalidate the frontbuffer on the first dirty and keep
+* it dirty and invalid until next flip.
+*/
+   if (origin == ORIGIN_FB_DIRTY) {
+   mutex_lock(_priv->fb_tracking.lock);
+   fb_dirty = dev_priv->fb_tracking.fb_dirty;
+   dev_priv->fb_tracking.fb_dirty = true;
+   mutex_unlock(_priv->fb_tracking.lock);
+
+   if (fb_dirty)
+   return;
+   DRM_ERROR("PSR FBT invalidate dirty\n");
+   }
+
if (origin == ORIGIN_CS) {
mutex_lock(_priv->fb_tracking.lock);
dev_priv->fb_tracking.busy_bits
@@ -207,6 +223,7 @@ void intel_frontbuffer_flip_complete(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);

mutex_lock(_priv->fb_tracking.lock);
+   dev_priv->fb_tracking.fb_dirty = false;
/* Mask any cancelled flips. */
frontbuffer_bits &= dev_priv->fb_tracking.flip_bits;
dev_priv->fb_tracking.flip_bits &= ~frontbuffer_bits;
@@ -233,6 +250,7 @@ void intel_frontbuffer_flip(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);

mutex_lock(_priv->fb_tracking.lock);
+   

[Bug 90728] dvd playback with vlc and vdpau causes segmentation fault

2015-06-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90728

--- Comment #21 from Christian König  ---
(In reply to mehmet.giritli from comment #19)
> One question: If you commit this, what is the earliest release which will
> contain this fix?

I have marked it as "CC: mesa-stable...", so it should show up in the next
stable release. But I honestly don't know of hand which release that will be.

> Marking this as fixed.

As Michel already noted please don't do so. The workflow is that I mark it as
fixes as soon as the patch is pushed and you can close it after that
acknowledging that the problem is really fixed.

Apart from that thanks for the help, that was a really long outstanding issue.

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


drm: imx: multi-display support questions

2015-06-29 Thread Fabio Estevam
On Mon, Jun 29, 2015 at 1:12 PM, Gary Bisson
 wrote:

> I am ok with it but I'd like Eric to ack it too as he might have some remarks.

Ok, I will submit it to the linux-arm mailing list with you and Eric on Cc.

Regards,

Fabio Estevam


drm: imx: multi-display support questions

2015-06-29 Thread Fabio Estevam
Hi Gary,

On Mon, Jun 29, 2015 at 1:04 PM, Gary Bisson
 wrote:

> Thank you for your e-mail and sorry for the delay in my response. I
> confirm this patch, ported over to my dtsi file, makes the HDMI and
> LVDS work together.
>
> I'll check with Eric but we will most likely use the same
> configuration for our platforms.

What do you mean by "use the same configuration for our platforms"?

I was planning to send the two attached patches.

Are you and Eric OK with them?

Regards,

Fabio Estevam
-- next part --
A non-text attachment was scrubbed...
Name: 0001-hdmiandldbsabrelite.patch
Type: text/x-diff
Size: 1307 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150629/f0226b03/attachment.patch>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-hdmiandldbnitrogen.patch
Type: text/x-diff
Size: 1313 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150629/f0226b03/attachment-0001.patch>


[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

2015-06-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91141

Christian König  changed:

   What|Removed |Added

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

--- Comment #2 from Christian König  ---
Fix is already in Alex's drm-fixes-4.2 tree and should appear in -rc1.

If you for some reason need it sooner just cherry pick "drm/radeon: fix adding
all VAs to the freed list on remove v2"

-- 
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/20150629/b391204c/attachment.html>


[v4] drm/panel: add s6e3ha2 AMOLED panel driver

2015-06-29 Thread Hyungwon Hwang
Dear Theirry,

Gentle ping. I modified as you reviewed before. Also I wrote the
reason for using passing variable by reference for error checking. Can
you share your opinion for that, and review this driver?

Best regards,
Hyungwon Hwang

On Fri, 29 May 2015 18:47:02 +0900
Hyungwon Hwang  wrote:
> 
> This patch adds MIPI-DSI based S6E3HA2 panel driver. This panel has
> 1440x2560 resolution in 5.7-inch physical panel.
> 
> Signed-off-by: Donghwa Lee 
> Signed-off-by: Hyungwon Hwang 
> Cc: Inki Dae 
> ---
> As Thierry Reding said in https://patchwork.kernel.org/patch/5714111/,
> it can be confusing to check the result of a function call using a
> variable which is not explicitly passed to function call. At the same
> time, as Andrzej Hajda said, checking the result using the return
> value in this driver makes the code too bloated. In the situation
> where many simple function calls and the result checking for them are
> needed, I thought that passing variable by reference with explicit
> variable is the best.
> 
> Changes for v2:
> - Fix errata in documentation and source code comments
> Changes for v3:
> - Remove the term LCD to clarify the sort of this panel
> - Rename lcd-en-gpios to panel-en-gpios to clarify the sort of this
> panel
> - Fix errata in documentation and source code comments
> Changes for v4:
> - Add support for brightness control
> - Adjust the sequence of turning on/off
> - Rename variable and properties for clarity
>  .../devicetree/bindings/panel/samsung,s6e3ha2.txt  |  40 +
>  drivers/gpu/drm/panel/Kconfig  |  11 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-s6e3ha2.c  | 904
> +
>  4 files changed, 956 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/panel/samsung,s6e3ha2.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-s6e3ha2.c
> 
> diff --git
> a/Documentation/devicetree/bindings/panel/samsung,s6e3ha2.txt
> b/Documentation/devicetree/bindings/panel/samsung,s6e3ha2.txt new
> file mode 100644 index 000..b8cacc0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3ha2.txt
> @@ -0,0 +1,40 @@
> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
> +
> +Required properties:
> +  - compatible: "samsung,s6e3ha2"
> +  - reg: virtual channel number assigned to the panel
> +  - vdd3-supply: core voltage supply
> +  - vci-supply: voltage supply for analog circuits
> +  - reset-gpio: GPIO spec for resetting
> +  - enable-gpio: GPIO spec for enabling
> +  - te-gpio: GPIO spec for receiving tearing effect synchronization
> signal
> +  - display-timings: resolution, clock, timing information for the
> panel [1]
> +
> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> +
> +Example:
> +
> +panel at 0 {
> +   compatible = "samsung,s6e3ha2";
> +   reg = <0>;
> +   vdd3-supply = <_reg>;
> +   vci-supply = <_reg>;
> +   reset-gpio = < 0 GPIO_ACTIVE_LOW>;
> +   enable-gpio = < 5 GPIO_ACTIVE_HIGH>;
> +   te-gpio = < 3 GPIO_ACTIVE_LOW>;
> +
> +   display-timings {
> +   timing-0 {
> +   clock-frequency = <0>;
> +   hactive = <1440>;
> +   vactive = <2560>;
> +   hfront-porch = <1>;
> +   hback-porch = <1>;
> +   hsync-len = <1>;
> +   vfront-porch = <1>;
> +   vback-porch = <15>;
> +   vsync-len = <1>;
> +   };
> +   };
> +};
> +
> diff --git a/drivers/gpu/drm/panel/Kconfig
> b/drivers/gpu/drm/panel/Kconfig index 6d64c7b..7833073 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -43,4 +43,15 @@ config DRM_PANEL_SHARP_LQ101R1SX01
>   To compile this driver as a module, choose M here: the
> module will be called panel-sharp-lq101r1sx01.
> 
> +config DRM_PANEL_S6E3HA2
> +   tristate "S6E3HA2 DSI command mode panel"
> +   depends on OF
> +   depends on BACKLIGHT_CLASS_DEVICE
> +   depends on DRM_MIPI_DSI
> +   select VIDEOMODE_HELPERS
> + Say Y here if you want to enable support for Samsung S6E3HA2
> + AMOLED panel module. This panel has a 1440x2560 resolution
> and
> + uses 32-bit RGB per pixel. It provides a 4 lane MIPI DSI
> interface
> + to the host.
> +
>  endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile
> b/drivers/gpu/drm/panel/Makefile index 4b2a043..16ff312 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -2,3 +2,4 @@ obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
>  obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
>  obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) +=
> panel-sharp-lq101r1sx01.o +obj-$(CONFIG_DRM_PANEL_S6E3HA2) +=
> panel-s6e3ha2.o diff --git a/drivers/gpu/drm/panel/panel-s6e3ha2.c
> 

[PATCH 4/4] cec-ctl: CEC control utility

2015-06-29 Thread Hans Verkuil
From: Hans Verkuil 

Generic CEC utility that can be used to send/receive/monitor CEC
messages.

Signed-off-by: Hans Verkuil 
---
 configure.ac  |1 +
 utils/Makefile.am |1 +
 utils/cec-ctl/Makefile.am |8 +
 utils/cec-ctl/cec-ctl.cpp | 1000 +
 utils/cec-ctl/msg2ctl.pl  |  330 +++
 5 files changed, 1340 insertions(+)
 create mode 100644 utils/cec-ctl/Makefile.am
 create mode 100644 utils/cec-ctl/cec-ctl.cpp
 create mode 100755 utils/cec-ctl/msg2ctl.pl

diff --git a/configure.ac b/configure.ac
index 12c2eb9..72d59bd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -27,6 +27,7 @@ AC_CONFIG_FILES([Makefile
utils/media-ctl/Makefile
utils/rds/Makefile
utils/cec-compliance/Makefile
+   utils/cec-ctl/Makefile
utils/v4l2-compliance/Makefile
utils/v4l2-ctl/Makefile
utils/v4l2-dbg/Makefile
diff --git a/utils/Makefile.am b/utils/Makefile.am
index c78e97b..617abf1 100644
--- a/utils/Makefile.am
+++ b/utils/Makefile.am
@@ -6,6 +6,7 @@ SUBDIRS = \
keytable \
media-ctl \
cec-compliance \
+   cec-ctl \
v4l2-compliance \
v4l2-ctl \
v4l2-dbg \
diff --git a/utils/cec-ctl/Makefile.am b/utils/cec-ctl/Makefile.am
new file mode 100644
index 000..378d7db
--- /dev/null
+++ b/utils/cec-ctl/Makefile.am
@@ -0,0 +1,8 @@
+bin_PROGRAMS = cec-ctl
+
+cec_ctl_SOURCES = cec-ctl.cpp
+
+cec-ctl.cpp: cec-ctl-gen.h
+
+cec-ctl-gen.h: msg2ctl.pl ../../include/linux/cec.h 
../../include/linux/cec-funcs.h
+   msg2ctl.pl ../../include/linux/cec.h ../../include/linux/cec-funcs.h 
>cec-ctl-gen.h
diff --git a/utils/cec-ctl/cec-ctl.cpp b/utils/cec-ctl/cec-ctl.cpp
new file mode 100644
index 000..1d0f663
--- /dev/null
+++ b/utils/cec-ctl/cec-ctl.cpp
@@ -0,0 +1,1000 @@
+/*
+Copyright 2015 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+Author: Hans Verkuil 
+
+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.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CEC_MAX_ARGS 16
+
+struct cec_enum_values {
+   const char *type_name;
+   __u8 value;
+};
+
+enum cec_types {
+   CEC_TYPE_U8,
+   CEC_TYPE_U16,
+   CEC_TYPE_U32,
+   CEC_TYPE_STRING,
+   CEC_TYPE_ENUM,
+};
+
+struct arg {
+   enum cec_types type;
+   __u8 num_enum_values;
+   const struct cec_enum_values *values;
+};
+
+struct message {
+   __u8 msg;
+   unsigned option;
+   __u8 num_args;
+   const char *arg_names[CEC_MAX_ARGS+1];
+   const struct arg *args[CEC_MAX_ARGS];
+   const char *msg_name;
+};
+
+static struct cec_op_digital_service_id *args2digital_service_id(__u8 
service_id_method,
+__u8 
dig_bcast_system,
+__u16 
transport_id,
+__u16 
service_id,
+__u16 
orig_network_id,
+__u16 
program_number,
+__u8 
channel_number_fmt,
+__u16 major,
+__u16 minor)
+{
+   static struct cec_op_digital_service_id dsid;
+
+   dsid.service_id_method = service_id_method;
+   dsid.dig_bcast_system = dig_bcast_system;
+   if (service_id_method == CEC_OP_SERVICE_ID_METHOD_BY_CHANNEL) {
+   dsid.channel.channel_number_fmt = channel_number_fmt;
+   dsid.channel.major = major;
+   dsid.channel.minor = minor;
+   return 
+   }
+   switch (dig_bcast_system) {
+   case CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ATSC_GEN:
+   case CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ATSC_CABLE:
+   case CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ATSC_SAT:
+   case CEC_OP_DIG_SERVICE_BCAST_SYSTEM_ATSC_T:
+   dsid.atsc.transport_id = transport_id;
+   dsid.atsc.program_number = program_number;
+   break;
+   default:
+   dsid.dvb.transport_id = transport_id;
+   dsid.dvb.service_id = 

[PATCH 3/4] cec-compliance: add new CEC compliance utility

2015-06-29 Thread Hans Verkuil
From: Hans Verkuil 

This utility will attempt to test whether the CEC protocol was
implemented correctly.

Signed-off-by: Hans Verkuil 
---
 configure.ac|   1 +
 utils/Makefile.am   |   1 +
 utils/cec-compliance/Makefile.am|   3 +
 utils/cec-compliance/cec-compliance.cpp | 943 
 utils/cec-compliance/cec-compliance.h   |  87 +++
 5 files changed, 1035 insertions(+)
 create mode 100644 utils/cec-compliance/Makefile.am
 create mode 100644 utils/cec-compliance/cec-compliance.cpp
 create mode 100644 utils/cec-compliance/cec-compliance.h

diff --git a/configure.ac b/configure.ac
index d4e312c..12c2eb9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -26,6 +26,7 @@ AC_CONFIG_FILES([Makefile
utils/keytable/Makefile
utils/media-ctl/Makefile
utils/rds/Makefile
+   utils/cec-compliance/Makefile
utils/v4l2-compliance/Makefile
utils/v4l2-ctl/Makefile
utils/v4l2-dbg/Makefile
diff --git a/utils/Makefile.am b/utils/Makefile.am
index 31b2979..c78e97b 100644
--- a/utils/Makefile.am
+++ b/utils/Makefile.am
@@ -5,6 +5,7 @@ SUBDIRS = \
decode_tm6000 \
keytable \
media-ctl \
+   cec-compliance \
v4l2-compliance \
v4l2-ctl \
v4l2-dbg \
diff --git a/utils/cec-compliance/Makefile.am b/utils/cec-compliance/Makefile.am
new file mode 100644
index 000..da4c0ef
--- /dev/null
+++ b/utils/cec-compliance/Makefile.am
@@ -0,0 +1,3 @@
+bin_PROGRAMS = cec-compliance
+
+cec_compliance_SOURCES = cec-compliance.cpp
diff --git a/utils/cec-compliance/cec-compliance.cpp 
b/utils/cec-compliance/cec-compliance.cpp
new file mode 100644
index 000..c8c51dc
--- /dev/null
+++ b/utils/cec-compliance/cec-compliance.cpp
@@ -0,0 +1,943 @@
+/*
+Copyright 2015 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+Author: Hans Verkuil 
+
+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.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cec-compliance.h"
+
+/* Short option list
+
+   Please keep in alphabetical order.
+   That makes it easier to see which short options are still free.
+
+   In general the lower case is used to set something and the upper
+   case is used to retrieve a setting. */
+enum Option {
+   OptPhysAddr = 'a',
+   OptSetDevice = 'd',
+   OptHelp = 'h',
+   OptNoWarnings = 'n',
+   OptTrace = 'T',
+   OptVerbose = 'v',
+   OptVendorID = 'V',
+
+   OptTV,
+   OptRecord,
+   OptTuner,
+   OptPlayback,
+   OptAudio,
+   OptProcessor,
+   OptSwitch,
+   OptCDCOnly,
+   OptUnregistered,
+   OptLast = 256
+};
+
+static char options[OptLast];
+
+static int app_result;
+static int tests_total, tests_ok;
+
+bool show_info;
+bool show_warnings = true;
+unsigned warnings;
+
+static struct option long_options[] = {
+   {"device", required_argument, 0, OptSetDevice},
+   {"help", no_argument, 0, OptHelp},
+   {"no-warnings", no_argument, 0, OptNoWarnings},
+   {"trace", no_argument, 0, OptTrace},
+   {"verbose", no_argument, 0, OptVerbose},
+   {"phys-addr", required_argument, 0, OptPhysAddr},
+   {"vendor-id", required_argument, 0, OptVendorID},
+
+   {"tv", no_argument, 0, OptTV},
+   {"record", no_argument, 0, OptRecord},
+   {"tuner", no_argument, 0, OptTuner},
+   {"playback", no_argument, 0, OptPlayback},
+   {"audio", no_argument, 0, OptAudio},
+   {"processor", no_argument, 0, OptProcessor},
+   {"switch", no_argument, 0, OptSwitch},
+   {"cdc-only", no_argument, 0, OptCDCOnly},
+   {"unregistered", no_argument, 0, OptUnregistered},
+   {0, 0, 0, 0}
+};
+
+static void usage(void)
+{
+   printf("Usage:\n"
+  "  -d, --device= Use device  instead of /dev/cec0\n"
+  " If  starts with a digit, then 
/dev/cec is used.\n"
+  "  -h, --help Display this help message\n"
+  "  -n, --no-warnings  Turn off warning messages.\n"
+  "  -T, --traceTrace all called ioctls.\n"
+  "  -v, --verbose  Turn on verbose reporting.\n"
+  "  -a, --phys-addr=\n"
+  " Use this physical address.\n"
+  "  -V, --vendor-id=\n"
+  " Use 

[PATCH 2/4] sync-with-kernel

2015-06-29 Thread Hans Verkuil
From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 contrib/freebsd/include/linux/input.h|   13 +
 include/linux/cec-funcs.h| 1516 ++
 include/linux/cec.h  |  709 ++
 utils/keytable/parse.h   |   10 +
 utils/keytable/rc_keymaps/cec|   77 ++
 utils/keytable/rc_keymaps/technisat_ts35 |   34 +
 utils/keytable/rc_keymaps/terratec_cinergy_c_pci |   49 +
 utils/keytable/rc_keymaps/terratec_cinergy_s2_hd |   49 +
 utils/keytable/rc_keymaps/twinhan_dtv_cab_ci |   54 +
 utils/keytable/rc_maps.cfg   |1 +
 10 files changed, 2512 insertions(+)
 create mode 100644 include/linux/cec-funcs.h
 create mode 100644 include/linux/cec.h
 create mode 100644 utils/keytable/rc_keymaps/cec
 create mode 100644 utils/keytable/rc_keymaps/technisat_ts35
 create mode 100644 utils/keytable/rc_keymaps/terratec_cinergy_c_pci
 create mode 100644 utils/keytable/rc_keymaps/terratec_cinergy_s2_hd
 create mode 100644 utils/keytable/rc_keymaps/twinhan_dtv_cab_ci

diff --git a/contrib/freebsd/include/linux/input.h 
b/contrib/freebsd/include/linux/input.h
index 19345e1..eaef6ac 100644
--- a/contrib/freebsd/include/linux/input.h
+++ b/contrib/freebsd/include/linux/input.h
@@ -786,6 +786,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
@@ -1006,6 +1018,7 @@ struct input_keymap_entry {
 #define BUS_GSC0x1A
 #define BUS_ATARI  0x1B
 #define BUS_SPI0x1C
+#define BUS_CEC0x1D

 /*
  * MT_TOOL types
diff --git a/include/linux/cec-funcs.h b/include/linux/cec-funcs.h
new file mode 100644
index 000..b74d003
--- /dev/null
+++ b/include/linux/cec-funcs.h
@@ -0,0 +1,1516 @@
+#ifndef _CEC_FUNCS_H
+#define _CEC_FUNCS_H
+
+#include 
+
+/* One Touch Play Feature */
+static __inline__ void cec_msg_active_source(struct cec_msg *msg, __u16 
phys_addr)
+{
+   msg->len = 4;
+   msg->msg[0] |= 0xf; /* broadcast */
+   msg->msg[1] = CEC_MSG_ACTIVE_SOURCE;
+   msg->msg[2] = phys_addr >> 8;
+   msg->msg[3] = phys_addr & 0xff;
+}
+
+static __inline__ void cec_ops_active_source(const struct cec_msg *msg,
+__u16 *phys_addr)
+{
+   *phys_addr = (msg->msg[2] << 8) | msg->msg[3];
+}
+
+static __inline__ void cec_msg_image_view_on(struct cec_msg *msg)
+{
+   msg->len = 2;
+   msg->msg[1] = CEC_MSG_IMAGE_VIEW_ON;
+}
+
+static __inline__ void cec_msg_text_view_on(struct cec_msg *msg)
+{
+   msg->len = 2;
+   msg->msg[1] = CEC_MSG_TEXT_VIEW_ON;
+}
+
+
+/* Routing Control Feature */
+static __inline__ void cec_msg_inactive_source(struct cec_msg *msg,
+  __u16 phys_addr)
+{
+   msg->len = 4;
+   msg->msg[1] = CEC_MSG_INACTIVE_SOURCE;
+   msg->msg[2] = phys_addr >> 8;
+   msg->msg[3] = phys_addr & 0xff;
+}
+
+static __inline__ void cec_ops_inactive_source(const struct cec_msg *msg,
+  __u16 *phys_addr)
+{
+   *phys_addr = (msg->msg[2] << 8) | msg->msg[3];
+}
+
+static __inline__ void cec_msg_request_active_source(struct cec_msg *msg,
+bool reply)
+{
+   msg->len = 2;
+   msg->msg[0] |= 0xf; /* broadcast */
+   msg->msg[1] = CEC_MSG_REQUEST_ACTIVE_SOURCE;
+   msg->reply = reply ? CEC_MSG_ACTIVE_SOURCE : 0;
+}
+
+static __inline__ void cec_msg_routing_information(struct cec_msg *msg,
+  __u16 phys_addr)
+{
+   msg->len = 4;
+   msg->msg[0] |= 0xf; /* broadcast */
+   msg->msg[1] = CEC_MSG_ROUTING_INFORMATION;
+   msg->msg[2] = phys_addr >> 8;
+   msg->msg[3] = phys_addr & 0xff;
+}
+
+static __inline__ void cec_ops_routing_information(const struct cec_msg *msg,
+  __u16 *phys_addr)
+{
+   *phys_addr = (msg->msg[2] << 8) | msg->msg[3];
+}
+
+static __inline__ void cec_msg_routing_change(struct cec_msg *msg,
+ bool reply,
+ __u16 orig_phys_addr,
+ 

[PATCH 1/4] Makefile.am: copy cec headers with make sync-with-kernel

2015-06-29 Thread Hans Verkuil
From: Hans Verkuil 

Copy the new cec headers.

Signed-off-by: Hans Verkuil 
---
 Makefile.am | 4 
 1 file changed, 4 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index 1a61592..b8c450d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -21,6 +21,8 @@ sync-with-kernel:
  ! -f $(KERNEL_DIR)/usr/include/linux/v4l2-common.h -o \
  ! -f $(KERNEL_DIR)/usr/include/linux/v4l2-subdev.h -o \
  ! -f $(KERNEL_DIR)/usr/include/linux/v4l2-mediabus.h -o \
+ ! -f $(KERNEL_DIR)/usr/include/linux/cec.h -o \
+ ! -f $(KERNEL_DIR)/usr/include/linux/cec-funcs.h -o \
  ! -f $(KERNEL_DIR)/usr/include/linux/ivtv.h -o \
  ! -f $(KERNEL_DIR)/usr/include/linux/dvb/frontend.h -o \
  ! -f $(KERNEL_DIR)/usr/include/linux/dvb/dmx.h -o \
@@ -38,6 +40,8 @@ sync-with-kernel:
cp -a $(KERNEL_DIR)/usr/include/linux/v4l2-mediabus.h 
$(top_srcdir)/include/linux
cp -a $(KERNEL_DIR)/usr/include/linux/media-bus-format.h 
$(top_srcdir)/include/linux
cp -a $(KERNEL_DIR)/usr/include/linux/media.h 
$(top_srcdir)/include/linux
+   cp -a $(KERNEL_DIR)/usr/include/linux/cec.h $(top_srcdir)/include/linux
+   cp -a $(KERNEL_DIR)/usr/include/linux/cec-funcs.h 
$(top_srcdir)/include/linux
cp -a $(KERNEL_DIR)/usr/include/linux/ivtv.h $(top_srcdir)/include/linux
cp -a $(KERNEL_DIR)/usr/include/linux/dvb/frontend.h 
$(top_srcdir)/include/linux/dvb
cp -a $(KERNEL_DIR)/usr/include/linux/dvb/dmx.h 
$(top_srcdir)/include/linux/dvb
-- 
2.1.4



[PATCH 0/4] cec-ctl/compliance: new CEC utilities

2015-06-29 Thread Hans Verkuil
From: Hans Verkuil 

This patch series adds two new utilities to the v4l-utils git repository
(http://git.linuxtv.org/cgit.cgi/v4l-utils.git/). It assumes that the new
CEC framework available in the kernel:

http://www.mail-archive.com/linux-media at vger.kernel.org/msg90085.html

The first patch adds the new cec headers to the 'sync-with-kernel' target,
the second syncs with the kernel and adds the new cec headers to v4l-utils,
the third adds the compliance utility and the last adds the cec-ctl utility.

The cec-compliance utility is by no means 100% coverage, in particular the
event API and non-blocking ioctls are untested. But it is a starting point,
and a complex protocol like CEC really needs a compliance tool.

The cec-ctl utility has almost full CEC message coverage: all generated from
the cec headers, so this is easy to keep up to date.

The main missing feature is that there is no logging of received messages.
This would be very useful to add. There is also no event handling/async message
handling yet.

But it is very useful to test CEC messages.

Regards,

Hans

Hans Verkuil (4):
  Makefile.am: copy cec headers with make sync-with-kernel
  sync-with-kernel
  cec-compliance: add new CEC compliance utility
  cec-ctl: CEC control utility

 Makefile.am  |4 +
 configure.ac |2 +
 contrib/freebsd/include/linux/input.h|   13 +
 include/linux/cec-funcs.h| 1516 ++
 include/linux/cec.h  |  709 ++
 utils/Makefile.am|2 +
 utils/cec-compliance/Makefile.am |3 +
 utils/cec-compliance/cec-compliance.cpp  |  943 ++
 utils/cec-compliance/cec-compliance.h|   87 ++
 utils/cec-ctl/Makefile.am|8 +
 utils/cec-ctl/cec-ctl.cpp| 1000 ++
 utils/cec-ctl/msg2ctl.pl |  330 +
 utils/keytable/parse.h   |   10 +
 utils/keytable/rc_keymaps/cec|   77 ++
 utils/keytable/rc_keymaps/technisat_ts35 |   34 +
 utils/keytable/rc_keymaps/terratec_cinergy_c_pci |   49 +
 utils/keytable/rc_keymaps/terratec_cinergy_s2_hd |   49 +
 utils/keytable/rc_keymaps/twinhan_dtv_cab_ci |   54 +
 utils/keytable/rc_maps.cfg   |1 +
 19 files changed, 4891 insertions(+)
 create mode 100644 include/linux/cec-funcs.h
 create mode 100644 include/linux/cec.h
 create mode 100644 utils/cec-compliance/Makefile.am
 create mode 100644 utils/cec-compliance/cec-compliance.cpp
 create mode 100644 utils/cec-compliance/cec-compliance.h
 create mode 100644 utils/cec-ctl/Makefile.am
 create mode 100644 utils/cec-ctl/cec-ctl.cpp
 create mode 100755 utils/cec-ctl/msg2ctl.pl
 create mode 100644 utils/keytable/rc_keymaps/cec
 create mode 100644 utils/keytable/rc_keymaps/technisat_ts35
 create mode 100644 utils/keytable/rc_keymaps/terratec_cinergy_c_pci
 create mode 100644 utils/keytable/rc_keymaps/terratec_cinergy_s2_hd
 create mode 100644 utils/keytable/rc_keymaps/twinhan_dtv_cab_ci

-- 
2.1.4



[PATCHv7 04/15] HID: add HDMI CEC specific keycodes

2015-06-29 Thread Dmitry Torokhov
On Mon, Jun 29, 2015 at 12:14:49PM +0200, Hans Verkuil wrote:
> From: Kamil Debski 
> 
> Add HDMI CEC specific keycodes to the keycodes definition.
> 
> Signed-off-by: Kamil Debski 
> Signed-off-by: Hans Verkuil 

Could you please describe the intended use for these keycodes for people
who do not live and breathe CEC specs?

Thanks!

> ---
>  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 731417c..7430a3f 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -752,6 +752,18 @@ struct input_keymap_entry {
>  #define KEY_KBDINPUTASSIST_ACCEPT0x264
>  #define KEY_KBDINPUTASSIST_CANCEL0x265
>  
> +#define KEY_RIGHT_UP 0x266
> +#define KEY_RIGHT_DOWN   0x267
> +#define KEY_LEFT_UP  0x268
> +#define KEY_LEFT_DOWN0x269
> +
> +#define KEY_NEXT_FAVORITE0x270
> +#define KEY_STOP_RECORD  0x271
> +#define KEY_PAUSE_RECORD 0x272
> +#define KEY_VOD  0x273
> +#define KEY_UNMUTE   0x274
> +#define KEY_DVB  0x275
> +
>  #define BTN_TRIGGER_HAPPY0x2c0
>  #define BTN_TRIGGER_HAPPY1   0x2c0
>  #define BTN_TRIGGER_HAPPY2   0x2c1
> -- 
> 2.1.4
> 

-- 
Dmitry


[PATCHv7 05/15] input.h: add BUS_CEC type

2015-06-29 Thread Dmitry Torokhov
On Mon, Jun 29, 2015 at 12:14:50PM +0200, Hans Verkuil wrote:
> Inputs can come in over the HDMI CEC bus, so add a new type for this.
> 
> Signed-off-by: Hans Verkuil 

Acked-by: Dmitry Torokhov 

> ---
>  include/uapi/linux/input.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index 7430a3f..0af80b2 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -984,6 +984,7 @@ struct input_keymap_entry {
>  #define BUS_GSC  0x1A
>  #define BUS_ATARI0x1B
>  #define BUS_SPI  0x1C
> +#define BUS_CEC  0x1D
>  
>  /*
>   * MT_TOOL types
> -- 
> 2.1.4
> 

-- 
Dmitry


[PATCHv7 15/15] cobalt: add cec support

2015-06-29 Thread Hans Verkuil
Add CEC support to the cobalt driver.

Signed-off-by: Hans Verkuil 
---
 drivers/media/pci/cobalt/cobalt-driver.c |  37 +--
 drivers/media/pci/cobalt/cobalt-driver.h |   2 +
 drivers/media/pci/cobalt/cobalt-v4l2.c   | 110 +--
 3 files changed, 138 insertions(+), 11 deletions(-)

diff --git a/drivers/media/pci/cobalt/cobalt-driver.c 
b/drivers/media/pci/cobalt/cobalt-driver.c
index b994b8e..a6d3644 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.c
+++ b/drivers/media/pci/cobalt/cobalt-driver.c
@@ -76,6 +76,7 @@ static u8 edid[256] = {
0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0x10,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x68,
+
0x02, 0x03, 0x1a, 0xc0, 0x48, 0xa2, 0x10, 0x04,
0x02, 0x01, 0x21, 0x14, 0x13, 0x23, 0x09, 0x07,
0x07, 0x65, 0x03, 0x0c, 0x00, 0x10, 0x00, 0xe2,
@@ -149,17 +150,44 @@ static void cobalt_notify(struct v4l2_subdev *sd,
struct cobalt *cobalt = to_cobalt(sd->v4l2_dev);
unsigned sd_nr = cobalt_get_sd_nr(sd);
struct cobalt_stream *s = >streams[sd_nr];
-   bool hotplug = arg ? *((int *)arg) : false;

-   if (s->is_output)
+   switch (notification) {
+   case V4L2_SUBDEV_CEC_TX_DONE:
+   cec_transmit_done(>cec_adap, (unsigned long)arg);
+   return;
+   case V4L2_SUBDEV_CEC_RX_MSG:
+   cec_received_msg(>cec_adap, arg);
+   return;
+   default:
+   break;
+   }
+
+   if (s->is_output) {
+   switch (notification) {
+   case ADV7511_EDID_DETECT: {
+   struct adv7511_edid_detect *ed = arg;
+
+   s->cec_adap.phys_addr = ed->phys_addr;
+   if (!ed->present) {
+   cec_enable(>cec_adap, false);
+   break;
+   }
+   cec_enable(>cec_adap, true);
+   break;
+   }
+   }
return;
+   }

switch (notification) {
-   case ADV76XX_HOTPLUG:
+   case ADV76XX_HOTPLUG: {
+   bool hotplug = arg ? *((int *)arg) : false;
+
cobalt_s_bit_sysctrl(cobalt,
COBALT_SYS_CTRL_HPD_TO_CONNECTOR_BIT(sd_nr), hotplug);
cobalt_dbg(1, "Set hotplug for adv %d to %d\n", sd_nr, hotplug);
break;
+   }
case V4L2_DEVICE_NOTIFY_EVENT:
cobalt_dbg(1, "Format changed for adv %d\n", sd_nr);
v4l2_event_queue(>vdev, arg);
@@ -626,8 +654,9 @@ static int cobalt_subdevs_hsma_init(struct cobalt *cobalt)
s->sd = v4l2_i2c_new_subdev_board(>v4l2_dev,
s->i2c_adap, _info, NULL);
if (s->sd) {
-   int err = v4l2_subdev_call(s->sd, pad, set_edid, _edid);
+   int err;

+   err = v4l2_subdev_call(s->sd, pad, set_edid, _edid);
if (err)
return err;
err = v4l2_subdev_call(s->sd, pad, set_fmt, NULL,
diff --git a/drivers/media/pci/cobalt/cobalt-driver.h 
b/drivers/media/pci/cobalt/cobalt-driver.h
index c206df9..151c80f 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.h
+++ b/drivers/media/pci/cobalt/cobalt-driver.h
@@ -31,6 +31,7 @@
 #include 
 #include 

+#include 
 #include 
 #include 
 #include 
@@ -221,6 +222,7 @@ struct cobalt_stream {
struct list_head bufs;
struct i2c_adapter *i2c_adap;
struct v4l2_subdev *sd;
+   struct cec_adapter cec_adap;
struct mutex lock;
spinlock_t irqlock;
struct v4l2_dv_timings timings;
diff --git a/drivers/media/pci/cobalt/cobalt-v4l2.c 
b/drivers/media/pci/cobalt/cobalt-v4l2.c
index b40c2d1..b37bfd5 100644
--- a/drivers/media/pci/cobalt/cobalt-v4l2.c
+++ b/drivers/media/pci/cobalt/cobalt-v4l2.c
@@ -1156,6 +1156,69 @@ static const struct v4l2_file_operations 
cobalt_empty_fops = {
.release = v4l2_fh_release,
 };

+static inline struct v4l2_subdev *adap_to_sd(struct cec_adapter *adap)
+{
+   struct cobalt_stream *s = container_of(adap, struct cobalt_stream, 
cec_adap);
+
+   return s->sd;
+}
+
+static int cobalt_cec_enable(struct cec_adapter *adap, bool enable)
+{
+   return v4l2_subdev_call(adap_to_sd(adap), video, cec_enable, enable);
+}
+
+static int cobalt_cec_log_addr(struct cec_adapter *adap, u8 log_addr)
+{
+   return v4l2_subdev_call(adap_to_sd(adap), video, cec_log_addr,
+   log_addr);
+}
+
+static int cobalt_cec_transmit(struct cec_adapter *adap, struct cec_msg *msg)
+{
+   return v4l2_subdev_call(adap_to_sd(adap), video, cec_transmit, msg);
+}
+
+static void cobalt_cec_transmit_timed_out(struct cec_adapter *adap)
+{
+   return v4l2_subdev_call(adap_to_sd(adap), video, 
cec_transmit_timed_out);
+}
+
+static u8 cobalt_cec_cdc_hpd(struct cec_adapter 

[PATCHv7 14/15] cec: s5p-cec: Add s5p-cec driver

2015-06-29 Thread Hans Verkuil
From: 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 
Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/s5p-cec.txt  |  31 +++
 drivers/media/platform/Kconfig |  10 +
 drivers/media/platform/Makefile|   1 +
 drivers/media/platform/s5p-cec/Makefile|   2 +
 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   | 283 +
 drivers/media/platform/s5p-cec/s5p_cec.h   |  76 ++
 9 files changed, 744 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt
 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/Documentation/devicetree/bindings/media/s5p-cec.txt 
b/Documentation/devicetree/bindings/media/s5p-cec.txt
new file mode 100644
index 000..da63a4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -0,0 +1,31 @@
+* Samsung HDMI CEC driver
+
+The HDMI CEC module is present is Samsung SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be follwoing
+   "samsung,s5p-cec"
+
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+  - interrupts : HDMI CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to HDMI CEC clock.
+  - clock-names : from common clock binding: must contain "hdmicec",
+ corresponding to entry in the clocks property.
+  - samsung,syscon-phandle - phandle to the PMU system controller
+
+Example:
+
+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>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec>;
+   status = "okay";
+};
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 4776a8c..d3843fc 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -157,6 +157,16 @@ config VIDEO_MEM2MEM_DEINTERLACE
help
Generic deinterlacing V4L2 driver.

+config VIDEO_SAMSUNG_S5P_CEC
+   tristate "Samsung S5P CEC driver"
+   depends on CEC && VIDEO_DEV && VIDEO_V4L2 && (PLAT_S5P || ARCH_EXYNOS)
+   default n
+   ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 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 114f9ab..95dd78d 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..0e2cf45
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/Makefile
@@ -0,0 +1,2 @@
+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 

[PATCHv7 13/15] cec: adv7511: add cec support.

2015-06-29 Thread 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 
Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/adv7511.c | 350 +++-
 include/media/adv7511.h |   6 +-
 2 files changed, 345 insertions(+), 11 deletions(-)

diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index 95bcd40..a0166c7 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);
@@ -59,6 +60,8 @@ MODULE_LICENSE("GPL");
 #define ADV7511_MIN_PIXELCLOCK 2000
 #define ADV7511_MAX_PIXELCLOCK 22500

+#define ADV7511_MAX_ADDRS (3)
+
 /*
 **
 *
@@ -90,8 +93,14 @@ struct adv7511_state {
struct v4l2_ctrl_handler hdl;
int chip_revision;
u8 i2c_edid_addr;
-   u8 i2c_cec_addr;
u8 i2c_pktmem_addr;
+   u8 i2c_cec_addr;
+
+   struct i2c_client *i2c_cec;
+   u8   cec_addr[ADV7511_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
/* Is the adv7511 powered on? */
bool power_on;
/* Did we receive hotplug and rx-sense signals? */
@@ -225,7 +234,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, u16 len, u8 *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;
@@ -240,6 +249,34 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, 
u16 len, u8 *buf)
v4l2_err(sd, "%s: i2c read error\n", __func__);
 }

+static inline int adv7511_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 adv7511_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 adv7511_cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 
mask,
+  u8 val)
+{
+   return adv7511_cec_write(sd, reg, (adv7511_cec_read(sd, reg) & mask) | 
val);
+}
+
 static int adv7511_pktmem_rd(struct v4l2_subdev *sd, u8 reg)
 {
struct adv7511_state *state = get_adv7511_state(sd);
@@ -413,16 +450,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 = adv7511_cec_read(sd, reg->reg & 0xff);
+   break;
+   }
+   /* fall through */
default:
v4l2_info(sd, "Register %03llx not supported\n", reg->reg);
adv7511_inv_register(sd);
@@ -433,10 +482,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) {
+   adv7511_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);
@@ -524,6 +581,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",
@@ -593,7 +651,23 @@ static int 

[PATCHv7 12/15] adv7842: add cec support

2015-06-29 Thread Hans Verkuil
Add CEC support to the adv7842 driver.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/adv7842.c | 211 +++-
 1 file changed, 208 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 4cf79b2..0ef01bd 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -78,6 +79,8 @@ MODULE_LICENSE("GPL");

 #define ADV7842_OP_SWAP_CB_CR  (1 << 0)

+#define ADV7842_MAX_ADDRS (3)
+
 /*
 **
 *
@@ -141,6 +144,10 @@ struct adv7842_state {
struct v4l2_ctrl *free_run_color_ctrl_manual;
struct v4l2_ctrl *free_run_color_ctrl;
struct v4l2_ctrl *rgb_quantization_range_ctrl;
+
+   u8   cec_addr[ADV7842_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
 };

 /* Unsupported timings. This device cannot support 720p30. */
@@ -417,9 +424,9 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 reg, 
u8 val)
return adv_smbus_write_byte_data(state->i2c_cec, reg, val);
 }

-static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 
val)
+static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, 
u8 val)
 {
-   return cec_write(sd, reg, (cec_read(sd, reg) & mask) | val);
+   return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val);
 }

 static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
@@ -2157,6 +2164,185 @@ static void adv7842_irq_enable(struct v4l2_subdev *sd, 
bool enable)
}
 }

+static void adv7842_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 adv7842_cec_isr(struct v4l2_subdev *sd, bool *handled)
+{
+   struct cec_msg msg;
+   u8 cec_irq;
+
+   /* cec controller */
+   cec_irq = io_read(sd, 0x93) & 0x0f;
+   if (!cec_irq)
+   return;
+
+   v4l2_dbg(1, debug, sd, "%s: cec: irq 0x%x\n", __func__, cec_irq);
+   adv7842_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, );
+   }
+   }
+
+   io_write(sd, 0x94, cec_irq);
+
+   if (handled)
+   *handled = true;
+}
+
+static unsigned adv7842_cec_available_log_addrs(struct v4l2_subdev *sd)
+{
+   return ADV7842_MAX_ADDRS;
+}
+
+static int adv7842_cec_enable(struct v4l2_subdev *sd, bool enable)
+{
+   struct adv7842_state *state = to_state(sd);
+
+   if (!state->cec_enabled_adap && enable) {
+   cec_write_clr_set(sd, 0x2a, 0x01, 0x01);/* power up cec 
*/
+   cec_write(sd, 0x2c, 0x01);  /* cec soft reset */
+   cec_write_clr_set(sd, 0x11, 0x01, 0);  /* initially disable tx 
*/
+   /* enabled irqs: */
+   /* tx: ready */
+   /* tx: arbitration lost */
+   /* tx: retry timeout */
+   /* rx: ready */
+   io_write_clr_set(sd, 0x96, 0x0f, 0x0f);
+   cec_write(sd, 0x26, 0x01);/* enable rx */
+   } else if (state->cec_enabled_adap && !enable) {
+   /* disable cec interrupts */
+   io_write_clr_set(sd, 0x96, 0x0f, 0x00);
+   /* disable address mask 1-3 */
+   cec_write_clr_set(sd, 0x27, 0x70, 0x00);
+   /* power down cec section */
+   cec_write_clr_set(sd, 

[PATCHv7 11/15] cec: adv7604: add cec support.

2015-06-29 Thread Hans Verkuil
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]
[k.debski at samsung.com: add missing methods cec/io_write_and_or]
[k.debski at samsung.com: change adv7604 to adv76xx in added functions]
[hansverk at cisco.com: use _clr_set instead of _and_or]
Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/adv7604.c | 219 +++-
 1 file changed, 217 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 808360f..a937391 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -39,6 +39,7 @@
 #include 

 #include 
+#include 
 #include 
 #include 
 #include 
@@ -78,6 +79,8 @@ MODULE_LICENSE("GPL");

 #define ADV76XX_OP_SWAP_CB_CR  (1 << 0)

+#define ADV76XX_MAX_ADDRS (3)
+
 enum adv76xx_type {
ADV7604,
ADV7611,
@@ -181,6 +184,10 @@ struct adv76xx_state {
u16 spa_port_a[2];
struct v4l2_fract aspect_ratio;
u32 rgb_quantization_range;
+   u8   cec_addr[ADV76XX_MAX_ADDRS];
+   u8   cec_valid_addrs;
+   bool cec_enabled_adap;
+
struct workqueue_struct *work_queues;
struct delayed_work delayed_work_enable_hotplug;
bool restart_stdi_once;
@@ -451,7 +458,8 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg, 
u8 val)
return adv_smbus_write_byte_data(state, ADV76XX_PAGE_IO, reg, val);
 }

-static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 
val)
+static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+  u8 val)
 {
return io_write(sd, reg, (io_read(sd, reg) & ~mask) | val);
 }
@@ -484,6 +492,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 
reg, u8 val)
return adv_smbus_write_byte_data(state, ADV76XX_PAGE_CEC, reg, val);
 }

+static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+  u8 val)
+{
+   return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val);
+}
+
 static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
 {
struct adv76xx_state *state = to_state(sd);
@@ -1897,6 +1911,188 @@ static int adv76xx_set_format(struct v4l2_subdev *sd,
return 0;
 }

+static void adv76xx_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 adv76xx_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);
+   adv76xx_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 unsigned adv76xx_cec_available_log_addrs(struct v4l2_subdev *sd)
+{
+   return ADV76XX_MAX_ADDRS;
+}
+
+static int adv76xx_cec_enable(struct v4l2_subdev *sd, bool enable)
+{
+   struct adv76xx_state *state = to_state(sd);
+
+   if 

[PATCHv7 10/15] v4l2-subdev: add HDMI CEC ops

2015-06-29 Thread Hans Verkuil
Add CEC callbacks to the v4l2_subdev_video_ops. These are the low-level CEC
ops that subdevs that support CEC have to implement.

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

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index dc20102..53e220d 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -42,6 +42,9 @@

 #defineV4L2_DEVICE_NOTIFY_EVENT_IOW('v', 2, struct 
v4l2_event)

+#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;
@@ -50,6 +53,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 {
@@ -338,6 +342,11 @@ struct v4l2_subdev_video_ops {
 const struct v4l2_mbus_config *cfg);
int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
   unsigned int *size);
+   unsigned (*cec_available_log_addrs)(struct v4l2_subdev *sd);
+   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);
 };

 /*
-- 
2.1.4



[PATCHv7 09/15] DocBook/media: add CEC documentation

2015-06-29 Thread Hans Verkuil
From: Hans Verkuil 

Add DocBook documentation for the CEC API.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: add documentation for passthrough mode]
[k.debski at samsung.com: minor fixes and change of reserved field sizes]
Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
---
 Documentation/DocBook/media/Makefile   |   2 +
 Documentation/DocBook/media/v4l/biblio.xml |  10 +
 Documentation/DocBook/media/v4l/cec-api.xml|  74 +
 Documentation/DocBook/media/v4l/cec-func-close.xml |  59 
 Documentation/DocBook/media/v4l/cec-func-ioctl.xml |  73 +
 Documentation/DocBook/media/v4l/cec-func-open.xml  |  94 +++
 Documentation/DocBook/media/v4l/cec-func-poll.xml  |  89 ++
 .../DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml | 299 +
 .../DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml |  78 ++
 .../DocBook/media/v4l/cec-ioc-g-adap-state.xml |  87 ++
 Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml | 138 ++
 .../DocBook/media/v4l/cec-ioc-g-event.xml  | 125 +
 .../DocBook/media/v4l/cec-ioc-g-passthrough.xml|  88 ++
 .../DocBook/media/v4l/cec-ioc-g-vendor-id.xml  |  70 +
 .../DocBook/media/v4l/cec-ioc-receive.xml  | 185 +
 Documentation/DocBook/media_api.tmpl   |   8 +-
 16 files changed, 1477 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/cec-api.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-close.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-ioctl.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-open.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-func-poll.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-log-addrs.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-phys-addr.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-adap-state.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-caps.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-event.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-passthrough.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-vendor-id.xml
 create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml

diff --git a/Documentation/DocBook/media/Makefile 
b/Documentation/DocBook/media/Makefile
index 23996f8..5c89f4b 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -64,6 +64,7 @@ IOCTLS = \
$(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/media.h) \
+   $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/cec.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
$(srctree)/include/uapi/linux/v4l2-subdev.h) \

 DEFINES = \
@@ -100,6 +101,7 @@ STRUCTS = \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/ && !/_old/)' 
$(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' 
$(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/media.h) \
+   $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/cec.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/v4l2-subdev.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
$(srctree)/include/uapi/linux/v4l2-mediabus.h)

diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
b/Documentation/DocBook/media/v4l/biblio.xml
index fdee6b3..bed940b 100644
--- a/Documentation/DocBook/media/v4l/biblio.xml
+++ b/Documentation/DocBook/media/v4l/biblio.xml
@@ -324,6 +324,16 @@ in the frequency range from 87,5 to 108,0 MHz
   Specification Version 1.4a
 

+
+  HDMI2
+  
+   HDMI Licensing LLC
+(http://www.hdmi.org;>http://www.hdmi.org)
+  
+  High-Definition Multimedia Interface
+  Specification Version 2.0
+
+
 
   DP
   
diff --git a/Documentation/DocBook/media/v4l/cec-api.xml 
b/Documentation/DocBook/media/v4l/cec-api.xml
new file mode 100644
index 000..b59f610
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/cec-api.xml
@@ -0,0 +1,74 @@
+
+  
+
+  Hans
+  Verkuil
+  hans.verkuil at 
cisco.com
+  Initial version.
+
+  
+  
+2015
+Hans Verkuil
+  
+
+  
+
+
+  1.0.0
+  2015-04-27
+  hv
+  Initial revision
+
+  
+
+
+CEC API
+
+
+  CEC: Consumer Electronics Control
+
+ 

[PATCHv7 08/15] cec.txt: add CEC framework documentation

2015-06-29 Thread Hans Verkuil
From: Hans Verkuil 

Document the new HDMI CEC framework.

Signed-off-by: Hans Verkuil 
[k.debski at samsung.com: add DocBook documentation by Hans Verkuil, with
Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
---
 Documentation/cec.txt | 166 ++
 1 file changed, 166 insertions(+)
 create mode 100644 Documentation/cec.txt

diff --git a/Documentation/cec.txt b/Documentation/cec.txt
new file mode 100644
index 000..b298249
--- /dev/null
+++ b/Documentation/cec.txt
@@ -0,0 +1,166 @@
+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 consumer 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 physical address is determined by the 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 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_OP_PRIM_DEVTYPE_TV 0
+#define CEC_OP_PRIM_DEVTYPE_RECORD 1
+#define CEC_OP_PRIM_DEVTYPE_TUNER  3
+#define CEC_OP_PRIM_DEVTYPE_PLAYBACK   4
+#define CEC_OP_PRIM_DEVTYPE_AUDIOSYSTEM5
+#define CEC_OP_PRIM_DEVTYPE_SWITCH 6
+#define CEC_OP_PRIM_DEVTYPE_VIDEOPROC  7
+
+/* The "All Device Types" flags (CEC 2.0) */
+#define CEC_OP_ALL_DEVTYPE_TV  (1 << 7)
+#define CEC_OP_ALL_DEVTYPE_RECORD  (1 << 6)
+#define CEC_OP_ALL_DEVTYPE_TUNER   (1 << 5)
+#define CEC_OP_ALL_DEVTYPE_PLAYBACK(1 << 4)
+#define CEC_OP_ALL_DEVTYPE_AUDIOSYSTEM (1 << 3)
+#define CEC_OP_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_OP_CEC_VERSION_1_3A4
+#define CEC_OP_CEC_VERSION_1_4 5
+#define CEC_OP_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 (*adap_transmit)(struct cec_adapter *adap, struct cec_msg *msg);
+   void (*adap_transmit_timed_out)(struct cec_adapter *adap);
+
+   void (*claimed_log_addr)(struct cec_adapter *adap, u8 idx);
+   int (*received)(struct cec_adapter *adap, struct cec_msg *msg);
+};
+
+int cec_create_adapter(struct cec_adapter *adap, u32 caps);
+void cec_delete_adapter(struct cec_adapter *adap);
+int cec_transmit_msg(struct cec_adapter *adap, struct cec_data *data, bool 
block);
+
+/* Called by the adapter */
+void cec_transmit_done(struct cec_adapter *adap, u32 status);
+void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
+
+int cec_receive_msg(struct cec_adapter *adap, struct cec_msg *msg, bool block);
+int cec_claim_log_addrs(struct cec_adapter *adap, struct cec_log_addrs 
*log_addrs, bool block);
+
+The device type defines are defined by the CEC standard.
+
+The cec_adapter structure represents the adapter. It has a number of
+operations that have to be implemented in the driver: adap_enable() enables
+or disables the physical adapter, adap_log_addr() tells the driver which
+logical address should be configured. This may be called multiple times
+to configure 

[PATCHv7 07/15] cec: add HDMI CEC framework

2015-06-29 Thread Hans Verkuil
The added HDMI CEC framework provides a generic kernel interface for
HDMI CEC devices.

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 possibility to clear assigned logical
addresses]
[k.debski at samsung.com: documentation fixes, clenaup and expansion]
[k.debski at samsung.com: reorder of API structs and add reserved fields]
[k.debski at samsung.com: fix handling of events and fix 32/64bit timespec
problem]
[k.debski at samsung.com: add cec.h to include/uapi/linux/Kbuild]
[k.debski at samsung.com: add sequence number handling]
[k.debski at samsung.com: add passthrough mode]
[k.debski at samsung.com: fix CEC defines, add missing CEC 2.0 commands]
minor additions]
Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
---
 MAINTAINERS|   11 +
 drivers/media/Kconfig  |6 +
 drivers/media/Makefile |2 +
 drivers/media/cec.c| 1580 
 include/media/cec.h|  161 
 include/uapi/linux/Kbuild  |2 +
 include/uapi/linux/cec-funcs.h | 1516 ++
 include/uapi/linux/cec.h   |  709 ++
 8 files changed, 3987 insertions(+)
 create mode 100644 drivers/media/cec.c
 create mode 100644 include/media/cec.h
 create mode 100644 include/uapi/linux/cec-funcs.h
 create mode 100644 include/uapi/linux/cec.h

diff --git a/MAINTAINERS b/MAINTAINERS
index de3cf29..3791979 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2444,6 +2444,17 @@ F:   drivers/net/ieee802154/cc2520.c
 F: include/linux/spi/cc2520.h
 F: Documentation/devicetree/bindings/net/ieee802154/cc2520.txt

+CEC DRIVER
+M: Hans Verkuil 
+L: linux-media at vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Supported
+F: drivers/media/cec.c
+F: include/media/cec.h
+F: include/uapi/linux/cec.h
+F: include/uapi/linux/cec-funcs.h
+
 CELL BROADBAND ENGINE ARCHITECTURE
 M: Arnd Bergmann 
 L: linuxppc-dev at lists.ozlabs.org
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 8af89b0..41dc55a 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -15,6 +15,12 @@ if MEDIA_SUPPORT

 comment "Multimedia core support"

+config CEC
+   tristate "CEC API (EXPERIMENTAL)"
+   select RC_CORE
+   ---help---
+ Enable the CEC API.
+
 #
 # Multimedia support - automatically enable V4L2 and DVB core
 #
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index e608bbc..db66014 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -2,6 +2,8 @@
 # Makefile for the kernel multimedia device drivers.
 #

+obj-$(CONFIG_CEC) += cec.o
+
 media-objs := media-device.o media-devnode.o media-entity.o

 #
diff --git a/drivers/media/cec.c b/drivers/media/cec.c
new file mode 100644
index 000..2c37675
--- /dev/null
+++ b/drivers/media/cec.c
@@ -0,0 +1,1580 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CEC_NUM_DEVICES256
+#define CEC_NAME   "cec"
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+struct cec_transmit_notifier {
+   struct completion c;
+   struct cec_data *data;
+};
+
+#define dprintk(lvl, fmt, arg...)  \
+   do {\
+   if (lvl <= debug)   \
+   pr_info("cec-%s: " fmt, adap->name, ## arg);\
+   } while (0)
+
+static dev_t cec_dev_t;
+
+/* Active devices */
+static DEFINE_MUTEX(cec_devnode_lock);
+static DECLARE_BITMAP(cec_devnode_nums, CEC_NUM_DEVICES);
+
+/* dev to cec_devnode */
+#define to_cec_devnode(cd) container_of(cd, struct cec_devnode, dev)
+
+static inline struct cec_devnode *cec_devnode_data(struct file *filp)
+{
+   return filp->private_data;
+}
+
+static bool cec_are_adjacent(const struct cec_adapter *adap, u8 la1, u8 la2)
+{
+   u16 pa1 = adap->phys_addrs[la1];
+   u16 pa2 = adap->phys_addrs[la2];
+   u16 mask = 0xf000;
+   int i;
+
+   if (pa1 == 0x || pa2 == 0x)
+   return false;
+   for (i = 0; i < 3; i++) {
+   if ((pa1 & mask) != (pa2 & mask))
+   break;
+   mask = (mask >> 4) | 0xf000;
+   }
+   if ((pa1 & ~mask) 

[PATCHv7 06/15] rc: Add HDMI CEC protocol handling

2015-06-29 Thread Hans Verkuil
From: Kamil Debski 

Add handling of remote control events coming from the HDMI CEC bus.
This patch includes a new keymap that maps values found in the CEC
messages to the keys pressed and released. Also, a new protocol has
been added to the core.

Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
---
 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 fbbd3bb..9cffcc6 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 */
+   

[PATCHv7 05/15] input.h: add BUS_CEC type

2015-06-29 Thread Hans Verkuil
Inputs can come in over the HDMI CEC bus, so add a new type for this.

Signed-off-by: Hans Verkuil 
---
 include/uapi/linux/input.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 7430a3f..0af80b2 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -984,6 +984,7 @@ struct input_keymap_entry {
 #define BUS_GSC0x1A
 #define BUS_ATARI  0x1B
 #define BUS_SPI0x1C
+#define BUS_CEC0x1D

 /*
  * MT_TOOL types
-- 
2.1.4



[PATCHv7 04/15] HID: add HDMI CEC specific keycodes

2015-06-29 Thread Hans Verkuil
From: Kamil Debski 

Add HDMI CEC specific keycodes to the keycodes definition.

Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
---
 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 731417c..7430a3f 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -752,6 +752,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
-- 
2.1.4



[PATCHv7 03/15] dts: exynos4412-odroid*: enable the HDMI CEC device

2015-06-29 Thread Hans Verkuil
From: Kamil Debski 

Add a dts node entry and enable the HDMI CEC device present in the Exynos4
family of SoCs.

Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
Acked-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index d6b49e5..a97362a 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -472,6 +472,10 @@
status = "okay";
};

+   cec at 100B {
+   status = "okay";
+   };
+
hdmi_ddc: i2c at 1388 {
status = "okay";
pinctrl-names = "default";
-- 
2.1.4



[PATCHv7 02/15] dts: exynos4: add node for the HDMI CEC device

2015-06-29 Thread Hans Verkuil
From: Kamil Debski 

This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series.

Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
Acked-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e20cdc2..8776db9 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -704,6 +704,18 @@
status = "disabled";
};

+   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>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_cec>;
+   status = "disabled";
+   };
+
mixer: mixer at 12C1 {
compatible = "samsung,exynos4210-mixer";
interrupts = <0 91 0>;
-- 
2.1.4



[PATCHv7 01/15] dts: exynos4*: add HDMI CEC pin definition to pinctrl

2015-06-29 Thread Hans Verkuil
From: Kamil Debski 

Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
Exynos4x12 SoCs. These are required by the HDMI CEC device.

Signed-off-by: Kamil Debski 
Signed-off-by: Hans Verkuil 
Acked-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 7 +++
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
index a7c2128..9331c62 100644
--- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -820,6 +820,13 @@
samsung,pin-pud = <1>;
samsung,pin-drv = <0>;
};
+
+   hdmi_cec: hdmi-cec {
+   samsung,pins = "gpx3-6";
+   samsung,pin-function = <3>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
};

pinctrl at 0386 {
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index c141931..875464e 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -885,6 +885,13 @@
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>;
+   };
};

pinctrl at 0386 {
-- 
2.1.4



[PATCHv7 00/15] HDMI CEC framework

2015-06-29 Thread Hans Verkuil
Hi all,

The seventh version of this patchset addresses comments on the mailing list
and many changes due to the work I did on the cec-compliance and cec-ctl
utilities (will be posted in a separate patch series). Please see the
changelog below for details.

Note: I have taken over from Kamil: he no longer had the time to work on this,
whereas I needed to get this working. Many thanks to Kamil for the work he did!

While this is now in pretty good shape, there are a few TO DOs left before it
can be merged:

- Support for CDC messages needs to be improved (wrapper functions are needed,
  and the 'reply' functionality isn't working at the moment).
- The documentation is out-of-sync and needs to be updated.
- I need to verify the current driver against the CEC 2.0 spec.
- Standby handling will need more work (should be a high-level callback, but I
  need to check which messages would cause the device to go out of standby).
- More testing.
- The CEC core currently stores physical addresses that were broadcast. But 
these
  are not yet communicated to userspace. I need to think about this (and how to
  handle similar broadcast messages).

Best regards,

Hans

Changes since v6

- added cec-funcs.h to provide wrapper functions that fill in the cec_msg 
struct.
  This header is needed both by the kernel and by applications.
- fix a missing rc_unregister_device call.
- added CEC support for the adv7842 and cobalt drivers.
- added CEC operand defines. Rename CEC message defines to CEC_MSG_ and operand
  defines now use CEC_OP_.
- the CEC_VERSION defines are dropped since we now have the CEC_OP_VERSION 
defines.
- ditto: CEC_PRIM_DEVTYPE_ is now CEC_OP_PRIM_DEVTYPE.
- ditto: CEC_FL_ALL_DEVTYPE_ is now CEC_OP_ALL_DEVTYPE.
- cec-ioc-g-adap-log-addrs.xml: document cec_versions field.
- cec-ioc-g-caps.xml: drop vendor_id and version fields.
- add MAINTAINERS entry.
- add CDC support (not yet fully functional).
- add a second debug level for message debugging.
- fix a nasty kernel Oops in cec_transmit_msg while waiting for transmit 
completion
  (adap->tx_queue[idx].func wasn't set to NULL).
- add support for CEC_MSG_REPORT_FEATURES (CEC 2.0 only).
- correctly abort unsupported messages.
- add support for the device power status feature.
- add support for the audio return channel (preliminary).
- add support for the CDC hotplug message (preliminary).
- added osd_name to struct cec_log_addrs.
- reported physical addresses are stored internally.
- fix enabling/disabling the CEC adapter (internal fields weren't cleared 
correctly).
- zero reserved fields.
- return an error if you try to receive/transmit and the adapter isn't 
configured.
- when creating the adapter provide the owner module and the parent device.
- add a CEC_VENDOR_ID_NONE define to signal if no vendor ID was set.
- add new capabilities: RC (remote control), ARC (audio return channel) and CDC
  (Capability Discovery and Control).
- applications that want to handle messages for a logical address need to set 
the
  CEC_LOG_ADDRS_FL_HANDLE_MSGS flag. Otherwise the CEC core will be the one 
handling
  all messages.
- Each logical address has its own all_device_types value. So this should be an 
array,
  not a single value.
- I'm sure I've forgotten some changes...

Changes since v5

- drop struct cec_timeval in favour of a __u64 that keeps the timestamp in ns
- remove userspace documentation from Documentation/cec.txt as userspace API
  is described in the DocBook
- add missing documentation for the passthrough mode to the DocBook
- add information about the number of events that can be queued
- fix misspelling of reply
- fix behaviour of posting an event in cec_received_msg, such that the behaviour
  is consistent with the documentation

Changes since v4

- add sequence numbering to transmitted messages
- add sequence number handling to event hanlding
- add passthrough mode
- change reserved field sizes
- fixed CEC version defines and addec CEC 2.0 commands
- add DocBook documentation

Changes since v3

- remove the promiscuous mode
- rewrite the devicetree patches
- fixes, expansion and partial rewrite of the documentation
- reorder of API structures and addition of reserved fields
- use own struct to report time (32/64 bit safe)
- fix of handling events
- add cec.h to include/uapi/linux/Kbuild
- fixes in the adv76xx driver (add missing methods, change adv7604 to adv76xx)
- cleanup of debug messages in s5p-cec driver
- remove non necessary claiming of a gpio in the s5p-cec driver
- cleanup headers of the s5p-cec driver

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 

[PATCH] drm/amdgpu: Delete an unnecessary check before the function call "kfree"

2015-06-29 Thread Alex Deucher
On Sun, Jun 28, 2015 at 4:45 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Sun, 28 Jun 2015 10:27:35 +0200
>
> The kfree() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 

I already have the same patch from Maninder Singh.

Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index fec487d..a85cd08 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1575,8 +1575,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
> amdgpu_fence_driver_fini(adev);
> amdgpu_fbdev_fini(adev);
> r = amdgpu_fini(adev);
> -   if (adev->ip_block_enabled)
> -   kfree(adev->ip_block_enabled);
> +   kfree(adev->ip_block_enabled);
> adev->ip_block_enabled = NULL;
> adev->accel_working = false;
> /* free i2c buses */
> --
> 2.4.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3] drm/tegra: Use 64-bit offset for tegra_gem_mmap

2015-06-29 Thread Thierry Reding
On Mon, Jun 29, 2015 at 02:16:17PM +1000, Dave Airlie wrote:
> On 6 February 2015 at 22:18, Thierry Reding  
> wrote:
> > On Fri, Jan 30, 2015 at 01:57:01PM -0500, Sean Paul wrote:
> >> On 64-bit targets, tegra_gem_mmap doesn't return the
> >> offset to userspace. As such, subsequent calls to mmap(2)
> >> fail. Alter the args to use 64-bit offset to fix this.
> >>
> >> Signed-off-by: Sean Paul 
> >> ---
> >>  include/uapi/drm/tegra_drm.h | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > I've applied this with a slightly tweaked commit message.
> 
> Doesn't that break 32-bit ABI?

Yes it does. This was discussed earlier in this thread. The original
patch was to add a separate IOCTL to be used on 64-bit architectures
because the 32-bit IOCTL was broken. After some discussion everybody
involved agreed that it'd be best to fix the IOCTL while we can (the
driver-specific IOCTLs in the Tegra driver are all guarded by the
STAGING Kconfig symbol).

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


[PATCH v3] drm/tegra: Use 64-bit offset for tegra_gem_mmap

2015-06-29 Thread Thierry Reding
On Sun, Jun 28, 2015 at 11:54:12PM +0300, Dmitry wrote:
> 06.02.2015 15:18, Thierry Reding пишет:
> >On Fri, Jan 30, 2015 at 01:57:01PM -0500, Sean Paul wrote:
> >>On 64-bit targets, tegra_gem_mmap doesn't return the
> >>offset to userspace. As such, subsequent calls to mmap(2)
> >>fail. Alter the args to use 64-bit offset to fix this.
> >>
> >>Signed-off-by: Sean Paul 
> >>---
> >>  include/uapi/drm/tegra_drm.h | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >I've applied this with a slightly tweaked commit message.
> >
> >Thanks,
> >Thierry
> >
> >
> >
> >___
> >dri-devel mailing list
> >dri-devel at lists.freedesktop.org
> >http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> Why it doesn't have stable tag?

It's an experimental feature (guarded by STAGING) that doesn't have any
users except proof of concept code, hence I didn't think it appropriate
to burden stable kernel maintainers with it.

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


[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

2015-06-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91141

--- Comment #1 from hadack at gmx.de ---
Created attachment 116790
  --> https://bugs.freedesktop.org/attachment.cgi?id=116790=edit
errors

-- 
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/20150629/5ac80215/attachment.html>


[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

2015-06-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91141

Bug ID: 91141
   Summary: Lots of *ERROR* Couldn't update BO_VA (-22) since
drm/radeon: stop using addr to check for BO move
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: hadack at gmx.de

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

This is with latest kernel from linus git tree on a CAPE VERDE card.
When the errors appears I get screen corruption when scrolling in a
browser/file-manager and missing/changed letters in a terminal.

A bisect led to the commit 161ab658a611df14fb0365b7b70a8c5fed3e4870 and
reverting it on master makes everything work normal 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/20150629/4678783e/attachment.html>


[RFC][PATCH 1/1] drm/amdkfd: Remove redundant pdd validation

2015-06-29 Thread Maninder Singh
pdd is already dereferenced before this check.
So it is redundtant to validate pdd here.

Signed-off-by: Maninder Singh 
---
 drivers/gpu/drm/amd/amdkfd/kfd_process.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 8a1f999..4dbc4e5 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -431,8 +431,7 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev, 
unsigned int pasid)
 * We don't call amd_iommu_unbind_pasid() here
 * because the IOMMU called us.
 */
-   if (pdd)
-   pdd->bound = false;
+   pdd->bound = false;

mutex_unlock(>mutex);
 }
-- 
1.7.9.5



[PATCH] gpu/drm/amdgpu: Fix build when CONFIG_DEBUG_FS is not set

2015-06-29 Thread Christian König
On 27.06.2015 09:16, Alexander Kuleshov wrote:
> If the CONFIG_DEBUG_FS is not selected, compilation of the
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c provides two warnings that
> amdgpu_debugfs_regs_init and amdgpu_debugfs_regs_cleanup are used but
> never defined. And as result:
>
> ERROR: "amdgpu_debugfs_regs_cleanup" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] 
> undefined!
> ERROR: "amdgpu_debugfs_regs_init" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] 
> undefined!
>  ^
>
> Signed-off-by: Alexander Kuleshov 

Reviewed-by: Christian König 

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 ++
>   1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index fec487d..6896798 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2000,5 +2000,10 @@ int amdgpu_debugfs_init(struct drm_minor *minor)
>   void amdgpu_debugfs_cleanup(struct drm_minor *minor)
>   {
>   }
> +#else
> +static int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
> +{
> + return 0;
> +}
> +static void amdgpu_debugfs_regs_cleanup(struct amdgpu_device *adev) { }
>   #endif
> --
> 2.4.4.410.gc71d752
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



drm: imx: multi-display support questions

2015-06-29 Thread Eric Nelson
Thanks Fabio,

On 06/29/2015 09:08 AM, Fabio Estevam wrote:
> Hi Gary,
> 
> On Mon, Jun 29, 2015 at 1:04 PM, Gary Bisson
>  wrote:
> 
>> Thank you for your e-mail and sorry for the delay in my response. I
>> confirm this patch, ported over to my dtsi file, makes the HDMI and
>> LVDS work together.
>>
>> I'll check with Eric but we will most likely use the same
>> configuration for our platforms.
> 
> What do you mean by "use the same configuration for our platforms"?
> 
> I was planning to send the two attached patches.
> 
> Are you and Eric OK with them?
> 

These look good to me.

Gary, did you test one of these against either of our 1280x800 panels?




[PATCH] staging: imx-drm: Fix pixel clock polarity

2015-06-29 Thread David Jander

Hi Philipp,

On Fri, 26 Jun 2015 17:31:18 +0200
Philipp Zabel  wrote:

> Hi David,
> 
> Am Freitag, den 26.06.2015, 13:26 +0200 schrieb David Jander:
> > This is odd. We started investigating because one of our customers (using
> > an LVDS connected panel) reported some boards causing color errors in
> > gradients. If you displayed for example a horizontal red gradient from 0
> > to 255, you would see 3 stripes through the gradient (dividing it into 4
> > parts) of pixels that are too bright. Not all the boards had this issue,
> > and in many of them itwas an unstable symptom, which immediately pointed
> > at a problem related to process variations. The symptoms can be explained
> > by a latch in the LDB (LVDS bridge) that latches the individual bits in
> > the shift register on the same clock-edge that those signals change. So
> > the internal signal delay can cause either the old or the new value of the
> > pixel-bit getting latched. The color stripes are then caused by the
> > roll-over from xx0111 to xx1000, where bit 3 gets latched at it's new
> > value, while all lower bits get latched at their previous value. Most of
> > the time this situation was unstable. I even have scope images showing the
> > anomaly on the LVDS signal. This patch fixes the issue for all boards.
> 
> I have seen similar artifacts in the red channel of LVDS0 on an i.MX6S
> once where changing clock polarity didn't have any effect, but switching
> from DI0 to DI1 helped.

That's weird, but I assume unrelated to this issue.

> > If you are confident that your code is correct, then maybe the LDB expects
> > an inverted clock signal?
> 
> There are parallel panels that sample on the rising pixel clock edge,
> for those this information should be part of the panel descriptor. 

Yes, I have seen those.

> For
> LVDS the clock waveform is standardized, so this should be an issue in
> the LDB. On the other hand, the serializer in the LDB shouldn't care
> about the pixel clock polarity if it uses the 7x serializer clock and an
> internal counter compared to the counter_reset_val field to determine at
> which point to load the shift registers. But that's my understanding

I assume the 7x serializer clock is synchronized with the pixel clock. On
external LVDS transceivers, there's a PLL to generate the 7x clock derived
from the pixel-clock, but since this is an internal LVDS bridge, it uses a
generated clock for the serializer that's set to 7x the pixel clock. I think
that the clock _output_ of the LVDS interface is a synthesized signal that is
generated from the serializer clock. This is easier to design. That makes the
whole LDB block synchronous to the pixel-clock and it will always generate a
standards-compliant clock signal to the panel, BUT... if the input pixel clock
is out of phase, strange things can happen. I am pretty sure that the LDB
latches the pixel data to the shift registers on the wrong edge. The scope
images are clear as water. I don't know whether this is a silicon-bug or a
driver bug, but definitely inverting the pixel clock fixes the problem.
Just to make this entirely clear: The LVDS signal that comes out of the LVDS0
channel is clearly broken (on a small percentage of boards). It is NOT the
display panel that is misinterpreting an otherwise valid LVDS signal.

> from the reference manual, which doesn't necessarily have to be the same
> as reality. Maybe the pixel clock latches the input bus signal onto an
> internal register.

Yes, I am pretty sure it does. Problem is that this latch is supposed to work
on the other edge of the clock.

> I have just tried three different devices with LVDS displays, that show
> no reaction to changes of the clk_pol setting.

I know. It appears on one out of ten boards maybe, and sometimes it takes a
while for the problem to appear...

> > I must admit that this patch is rather old. I tested it thoroughly on 3.17,
> > but AFAICS, the patch you mention is also included in 3.17, so I suppose
> > the situation has not changed.
> 
> Do you still have devices that show this issue available to test? I'd be
> very interested to know whether switching DIs or using the LDB_DI parent
> selection procedure described in 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313618.html
> makes any difference.

We can try this out. I'll try to find a board that has this issue. It was on a
i.MX6U (Dual-light). Unfortunately I don't think I manage to do it this week,
and from next week on I'll be on vacation, so it can take a while...
Again, all this testing was on mainline 3.17, so it will be good to check that
we still can reproduce this problem with 4.1.

Best regards,

-- 
David Jander
Protonic Holland.


[Bug 74329] Please expose OES_texture_float and OES_texture_half_float on the ES3 context

2015-06-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=74329

Sergey Kondakov  changed:

   What|Removed |Added

 CC||virtuousfox at gmail.com

--- Comment #4 from Sergey Kondakov  ---
Is anything holding off r600 from using it ? I was just trying to see
http://madebyevan.com/webgl-water/ WebGL demo and was surprised that recent
Mesa 10.6 doesn't have OES_texture_float while having GL_ARB_texture_float.

-- 
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/20150629/3ca30bd1/attachment.html>


[Bug 89699] Regression in 10.5.1 causes flickering/artifacting in a particular video game

2015-06-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89699

--- Comment #15 from andre35822 at yahoo.com ---
So I came to check out if there was anything new and I see that there are some
of you working on fixing the bug? Thank You! I really appreciate it as I have
no clue how to do this on my own. I don't know what else I can do to help, only
that (you guys probably know this already) the bug is still present on Mesa
10.6...just thought I would let you know in case you guys didnt (you probably
do).

Thanks a lot again for looking into the issue.

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


[Bug 91110] Textures missing iff character in specific areas in dolphin running Xenoblades Chronicles

2015-06-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91110

--- Comment #5 from Christian Weinz  ---
No.

I tested the replay of the trace and the game both with mesa from Sid and
mesa-git, each time with R600_DEBUG=switch_on_eop set. The issue remained
unaffected.

Are you sure you meant R600_DEBUG=switch_on_eop? I'm asking because I'm using
radeonsi.

-- 
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/20150629/f6ed4e8e/attachment.html>


[Bug 91110] Textures missing iff character in specific areas in dolphin running Xenoblades Chronicles

2015-06-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91110

--- Comment #4 from Christian Weinz  ---
Created attachment 116777
  --> https://bugs.freedesktop.org/attachment.cgi?id=116777=edit
frame 2 of the apitrace dump with R600_DEBUG=switch_on_eop

-- 
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/20150629/7498dd60/attachment-0001.html>


[Bug 91110] Textures missing iff character in specific areas in dolphin running Xenoblades Chronicles

2015-06-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91110

--- Comment #3 from Christian Weinz  ---
Created attachment 116776
  --> https://bugs.freedesktop.org/attachment.cgi?id=116776=edit
frame 1 of the apitrace dump with R600_DEBUG=switch_on_eop

-- 
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/20150629/e85675b8/attachment.html>


[Bug 91110] Textures missing iff character in specific areas in dolphin running Xenoblades Chronicles

2015-06-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=91110

--- Comment #2 from Michel Dänzer  ---
Does setting the environment variable R600_DEBUG=switch_on_eop work around the
problem when playing back the apitrace or running the game?

-- 
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/20150629/27721851/attachment.html>


[Bug 90728] dvd playback with vlc and vdpau causes segmentation fault

2015-06-29 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=90728

Michel Dänzer  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #20 from Michel Dänzer  ---
Please don't resolve bug reports before the fix has landed in Git.

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


[PATCH v3] drm/tegra: Use 64-bit offset for tegra_gem_mmap

2015-06-29 Thread Dmitry
06.02.2015 15:18, Thierry Reding пишет:
> On Fri, Jan 30, 2015 at 01:57:01PM -0500, Sean Paul wrote:
>> On 64-bit targets, tegra_gem_mmap doesn't return the
>> offset to userspace. As such, subsequent calls to mmap(2)
>> fail. Alter the args to use 64-bit offset to fix this.
>>
>> Signed-off-by: Sean Paul 
>> ---
>>   include/uapi/drm/tegra_drm.h | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> I've applied this with a slightly tweaked commit message.
>
> Thanks,
> Thierry
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Why it doesn't have stable tag?

-- 
Dmitry